* [PATCH 3/5] i2c: i2c-sh_mobile: fix ICCH to avoid violation of the tHD;STA timing spec
From: Shinya Kuribayashi @ 2012-10-24 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087C93F.6080601@renesas.com>
The optimized ICCH/ICCL values in the previous commit afterward turned
out to violate tHD;STA timing spec. We had to take into account the
fall time of SDA signal (tf) at START condition. Fix it accordingly.
With this change, sh_mobile_i2c_icch() is virtually identical to
sh_mobile_i2c_iccl(), but they're providing good descriptions of
SH-/R-Mobile I2C hardware spec, and I'd leave them as separated.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/i2c/busses/i2c-sh_mobile.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 1ad80c9..4dc0cc3 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -203,18 +203,23 @@ static u32 sh_mobile_i2c_iccl(unsigned long count_khz, u32 tLOW, u32 tf, int off
return (((count_khz * (tLOW + tf)) + 5000) / 10000) + offset;
}
-static u32 sh_mobile_i2c_icch(unsigned long count_khz, u32 tHIGH, int offset)
+static u32 sh_mobile_i2c_icch(unsigned long count_khz, u32 tHIGH, u32 tf, int offset)
{
/*
* Conditional expression:
- * ICCH >= COUNT_CLK * tHIGH
+ * ICCH >= COUNT_CLK * (tHIGH + tf)
*
* SH-Mobile IIC hardware is aware of SCL transition period 'tr',
* and can ignore it. SH-Mobile IIC controller starts counting
* the HIGH period of the SCL signal (tHIGH) after the SCL input
* voltage increases at VIH.
+ *
+ * Afterward it turned out calculating ICCH using only tHIGH spec
+ * will result in violation of the tHD;STA timing spec. We need
+ * to take into account the fall time of SDA signal (tf) at START
+ * condition, in order to meet both tHIGH and tHD;STA specs.
*/
- return ((count_khz * tHIGH) + 5000) / 10000 + offset;
+ return (((count_khz * (tHIGH + tf)) + 5000) / 10000) + offset;
}
static void sh_mobile_i2c_init(struct sh_mobile_i2c_data *pd)
@@ -250,7 +255,7 @@ static void sh_mobile_i2c_init(struct sh_mobile_i2c_data *pd)
else
pd->icic &= ~ICIC_ICCLB8;
- pd->icch = sh_mobile_i2c_icch(i2c_clk_khz, tHIGH, offset);
+ pd->icch = sh_mobile_i2c_icch(i2c_clk_khz, tHIGH, tf, offset);
/* one more bit of ICCH in ICIC */
if ((pd->icch > 0xff) && (pd->flags & IIC_FLAG_HAS_ICIC67))
pd->icic |= ICIC_ICCHB8;
--
1.7.12.4
^ permalink raw reply related
* [PATCH 4/5] i2c: i2c-sh_mobile: support I2C hardware block with a faster operating clock
From: Shinya Kuribayashi @ 2012-10-24 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087C93F.6080601@renesas.com>
On newer SH-/R-Mobile SoCs, a clock supply to the I2C hardware block,
which is used to generate the SCL clock output, is getting faster than
before, while on the other hand, the SCL clock control registers, ICCH
and ICCL, stay unchanged in 9-bit-wide (8+1).
On such silicons, the internal SCL clock counter gets incremented every
2 clocks of the operating clock.
This patch makes it configurable through platform data.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/i2c/busses/i2c-sh_mobile.c | 5 +++++
include/linux/i2c/i2c-sh_mobile.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 4dc0cc3..4c28358 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -120,6 +120,7 @@ struct sh_mobile_i2c_data {
void __iomem *reg;
struct i2c_adapter adap;
unsigned long bus_speed;
+ unsigned int clks_per_count;
struct clk *clk;
u_int8_t icic;
u_int8_t flags;
@@ -231,6 +232,7 @@ static void sh_mobile_i2c_init(struct sh_mobile_i2c_data *pd)
/* Get clock rate after clock is enabled */
clk_enable(pd->clk);
i2c_clk_khz = clk_get_rate(pd->clk) / 1000;
+ i2c_clk_khz /= pd->clks_per_count;
if (pd->bus_speed == STANDARD_MODE) {
tLOW = 47; /* tLOW = 4.7 us */
@@ -658,6 +660,9 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
pd->bus_speed = STANDARD_MODE;
if (pdata && pdata->bus_speed)
pd->bus_speed = pdata->bus_speed;
+ pd->clks_per_count = 1;
+ if (pdata && pdata->clks_per_count)
+ pd->clks_per_count = pdata->clks_per_count;
/* The IIC blocks on SH-Mobile ARM processors
* come with two new bits in ICIC.
diff --git a/include/linux/i2c/i2c-sh_mobile.h b/include/linux/i2c/i2c-sh_mobile.h
index beda708..06e3089 100644
--- a/include/linux/i2c/i2c-sh_mobile.h
+++ b/include/linux/i2c/i2c-sh_mobile.h
@@ -5,6 +5,7 @@
struct i2c_sh_mobile_platform_data {
unsigned long bus_speed;
+ unsigned int clks_per_count;
};
#endif /* __I2C_SH_MOBILE_H__ */
--
1.7.12.4
^ permalink raw reply related
* [PATCH 5/5] i2c: i2c-sh_mobile: fix spurious transfer request timed out
From: Shinya Kuribayashi @ 2012-10-24 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087C93F.6080601@renesas.com>
Ensure that any of preceding register write operations to the I2C
hardware block reached the module, and the write data is reflected
in the registers, before leaving the interrupt handler.
Otherwise, we'll suffer from spurious WAIT interrupts that lead to
'Transfer request timed out' message, and the transaction failed.
Tracked-down-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/i2c/busses/i2c-sh_mobile.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 4c28358..9411c1b 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -469,6 +469,9 @@ static irqreturn_t sh_mobile_i2c_isr(int irq, void *dev_id)
wake_up(&pd->wait);
}
+ /* defeat write posting to avoid spurious WAIT interrupts */
+ iic_rd(pd, ICSR);
+
return IRQ_HANDLED;
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH 3/3] dmaengine: sirf: enable the driver support new SiRFmarco SoC
From: Vinod Koul @ 2012-10-24 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348734996-20086-1-git-send-email-Barry.Song@csr.com>
On Thu, 2012-09-27 at 16:36 +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> The driver supports old up SiRFprimaII SoCs, this patch makes it support
> the new SiRFmarco as well.
> SiRFmarco, as a SMP SoC, adds new DMA_INT_EN_CLR and DMA_CH_LOOP_CTRL_CLR
> registers, to disable IRQ/Channel, we should write 1 to the corresponding
> bit in the two CLEAR register.
>
> Tested on SiRFmarco using SPI driver:
> $ /mnt/spidev-sirftest -D /dev/spidev32766.0
> spi mode: 0
> bits per word: 8
> max speed: 500000 Hz (500 KHz)
>
> 00 00 00 00 00 00
> 00 00 00 00 00 00
> 00 00 00 00 00 00
> 00 00 00 00 00 00
> 00 00 00 00 00 00
> 00 00 00 00 00 00
> 00 00 00 00
>
> $ cat /proc/interrupts
> CPU0 CPU1
> 32: 1593 0 GIC sirfsoc_timer0
> 33: 0 3533 GIC sirfsoc_timer1
> 44: 0 0 GIC sirfsoc_dma
> 45: 16 0 GIC sirfsoc_dma
> 47: 6 0 GIC sirfsoc_spi
> 50: 5654 0 GIC sirfsoc-uart
> ...
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> depends on pulled CSR SiRFmarco preparing patches:
> http://www.spinics.net/lists/arm-kernel/msg191412.html
>
> drivers/dma/Kconfig | 2 +-
> drivers/dma/sirf-dma.c | 25 +++++++++++++++++++------
> 2 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index d06ea29..bf5f405 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -203,7 +203,7 @@ config TIMB_DMA
>
> config SIRF_DMA
> tristate "CSR SiRFprimaII DMA support"
> - depends on ARCH_PRIMA2
> + depends on ARCH_SIRF
patch description says adding support, but now your are removing for
PRIMA2, did I miss anything?
> select DMA_ENGINE
> help
> Enable support for the CSR SiRFprimaII DMA engine.
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index c439489..fbb0199 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -32,7 +32,9 @@
> #define SIRFSOC_DMA_CH_VALID 0x140
> #define SIRFSOC_DMA_CH_INT 0x144
> #define SIRFSOC_DMA_INT_EN 0x148
> +#define SIRFSOC_DMA_INT_EN_CLR 0x14C
can you pls align this
> #define SIRFSOC_DMA_CH_LOOP_CTRL 0x150
> +#define SIRFSOC_DMA_CH_LOOP_CTRL_CLR 0x15C
>
> #define SIRFSOC_DMA_MODE_CTRL_BIT 4
> #define SIRFSOC_DMA_DIR_CTRL_BIT 5
> @@ -76,6 +78,7 @@ struct sirfsoc_dma {
> struct sirfsoc_dma_chan channels[SIRFSOC_DMA_CHANNELS];
> void __iomem *base;
> int irq;
> + bool is_marco;
> };
>
> #define DRV_NAME "sirfsoc_dma"
> @@ -288,13 +291,19 @@ static int sirfsoc_dma_terminate_all(struct sirfsoc_dma_chan *schan)
> int cid = schan->chan.chan_id;
> unsigned long flags;
>
> - writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) &
> - ~(1 << cid), sdma->base + SIRFSOC_DMA_INT_EN);
> - writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_CH_VALID);
> -
> - writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
> - & ~((1 << cid) | 1 << (cid + 16)),
> + if (!sdma->is_marco) {
> + writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) &
> + ~(1 << cid), sdma->base + SIRFSOC_DMA_INT_EN);
> + writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
> + & ~((1 << cid) | 1 << (cid + 16)),
> sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
> + } else {
> + writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_INT_EN_CLR);
> + writel_relaxed((1 << cid) | 1 << (cid + 16),
> + sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
> + }
> +
> + writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_CH_VALID);
>
> spin_lock_irqsave(&schan->lock, flags);
> list_splice_tail_init(&schan->active, &schan->free);
> @@ -568,6 +577,9 @@ static int __devinit sirfsoc_dma_probe(struct platform_device *op)
> return -ENOMEM;
> }
>
> + if (of_device_is_compatible(dn, "sirf,marco-dmac"))
not a DT expert, but wouldn't there be a space after comma?
> + sdma->is_marco = true;
> +
> if (of_property_read_u32(dn, "cell-index", &id)) {
> dev_err(dev, "Fail to get DMAC index\n");
> ret = -ENODEV;
> @@ -677,6 +689,7 @@ static int __devexit sirfsoc_dma_remove(struct platform_device *op)
>
> static struct of_device_id sirfsoc_dma_match[] = {
> { .compatible = "sirf,prima2-dmac", },
> + { .compatible = "sirf,marco-dmac", },
> {},
> };
>
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH 1/3] dmaengine: sirf: fix a typo in dma_prep_interleaved
From: Vinod Koul @ 2012-10-24 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348734938-20014-1-git-send-email-Barry.Song@csr.com>
On Thu, 2012-09-27 at 16:35 +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> either DEV_TO_MEM or MEM_TO_DEV is supported, so change
> OR to AND.
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> drivers/dma/sirf-dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index 434ad31..35a329d 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -428,7 +428,7 @@ static struct dma_async_tx_descriptor *sirfsoc_dma_prep_interleaved(
> unsigned long iflags;
> int ret;
>
> - if ((xt->dir != DMA_MEM_TO_DEV) || (xt->dir != DMA_DEV_TO_MEM)) {
> + if ((xt->dir != DMA_MEM_TO_DEV) && (xt->dir != DMA_DEV_TO_MEM)) {
> ret = -EINVAL;
> goto err_dir;
> }
applied thanks
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH 2/3] dmaengine: sirf: fix a typo in moving running dma_desc to active queue
From: Vinod Koul @ 2012-10-24 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348734970-20050-1-git-send-email-Barry.Song@csr.com>
On Thu, 2012-09-27 at 16:36 +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> list_move_tail(&schan->queued, &schan->active) makes the list_empty(schan->queued)
> undefined, we either should change it to:
> list_move_tail(schan->queued.next, &schan->active)
> or
> list_move_tail(&sdesc->node, &schan->active)
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> drivers/dma/sirf-dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index 35a329d..c439489 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -109,7 +109,7 @@ static void sirfsoc_dma_execute(struct sirfsoc_dma_chan *schan)
> sdesc = list_first_entry(&schan->queued, struct sirfsoc_dma_desc,
> node);
> /* Move the first queued descriptor to active list */
> - list_move_tail(&schan->queued, &schan->active);
> + list_move_tail(&sdesc->node, &schan->active);
>
> /* Start the DMA transfer */
> writel_relaxed(sdesc->width, sdma->base + SIRFSOC_DMA_WIDTH_0 +
applied thanks
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH] usb: remove CONFIG_USB_MUSB_HOST etc
From: Sekhar Nori @ 2012-10-24 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023123927.GB29281@arwen.pp.htv.fi>
On 10/23/2012 6:09 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 06:04:53PM +0530, Sekhar Nori wrote:
>> On 10/8/2012 6:47 PM, Constantine Shulyupin wrote:
>>> From: Constantine Shulyupin <const@MakeLinux.com>
>>>
>>> Remove USB configuration in arch/arm/mach-davinci/usb.c accordingly
>>> CONFIG_USB_MUSB_OTG CONFIG_USB_MUSB_PERIPHERAL CONFIG_USB_MUSB_HOST
>>> and set MUSB_OTG configuration by default
>>> because this configuration options are removed from Kconfig.
>>>
>>> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
>>
>> Queuing this patch for v3.8. Since the config options are removed there
>> is no use having code which refers to them. The patch has been tested on
>> DM644x and DM365 in both host and gadget mode (I will add this
>> information to commit text while committing). Without this patch .mode
>> seems to be defaulting to MUSB_UNDEFINED which I think is definitely wrong.
>
> sorry for the delay, this looks ok:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
Thanks Felipe, I added your ack.
Constantine,
Patches touching arch/arm/* should be prefixed with 'ARM:' and those
touching mach-davinci should be prefixed with 'davinci:'. I added these
two while committing the patch this time. Please take care next time on.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Sekhar Nori @ 2012-10-24 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350998273-19769-1-git-send-email-prabhakar.lad@ti.com>
On 10/23/2012 6:47 PM, Prabhakar Lad wrote:
> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>
> This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
> V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
> out.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Patches for mach-davinci should have a 'davinci:' prefix after 'ARM:'.
Can you please resend with that fixed?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Sergei Shtylyov @ 2012-10-24 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087CEDC.9050103@ti.com>
On 24.10.2012 15:19, Sekhar Nori wrote:
>> This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
>> V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
>> out.
>> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
>> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Sergei Shtylyov <sshtylyov@mvista.com>
> Patches for mach-davinci should have a 'davinci:' prefix after 'ARM:'.
> Can you please resend with that fixed?
Also, the patch is for DM365 EVM board, not DM365 SoC.
> Thanks,
> Sekhar
WBR, Sergei
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Arnd Bergmann @ 2012-10-24 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-3-git-send-email-gregory.clement@free-electrons.com>
On Wednesday 24 October 2012, Gregory CLEMENT wrote:
> +void __init armada_370_xp_coherency_iocache_init(void)
> +{
> + /* When the coherency fabric is available, the Armada XP and
> + * Aramada 370 are close to a coherent architecture, so we based
> + * our dma ops on the coherent one, and just changes the
> + * operations which need a arch io sync */
> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric")) {
> + struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
> + memcpy(dma_ops, &arm_coherent_dma_ops, sizeof(*dma_ops));
> + dma_ops->map_page = armada_xp_dma_map_page;
> + dma_ops->unmap_page = armada_xp_dma_unmap_page;
> + dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
> + dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
> + dma_ops->sync_single_for_device = armada_xp_dma_sync;
> + dma_ops->sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
> + dma_ops->sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
> + }
> + bus_register_notifier(&platform_bus_type, &armada_xp_platform_nb);
I think it would be cleaner to statically define the operations in a constant
structure and point directly to the functions you need. If necessary, use
multiple structures.
Arnd
^ permalink raw reply
* [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
From: Peter Korsgaard @ 2012-10-24 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087A8E5.8050103@free-electrons.com>
>>>>> "MR" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
Hi,
MR> +* Standard I2C mux properties. See mux.txt in this directory.
MR> +* I2C child bus nodes. See mux.txt in this directory.
MR> +
MR> +Optional properties:
MR> +- idle-state: value to set to the muxer when idle. When no value is
>>
>> How about 'bitmask defining mux state when idle' instead?
MR> Since the array documented as using the bitmasks in the platform_data
MR> and described as an array of bitmasks is called "values", and the file
MR> mux.txt talks about "numbers" to put into reg, won't this be confusing
MR> to have three names for the exact same thing?
Yeah, the mess is less than perfect. To my defense I did use bitmask in
the platform data documentation:
@values: Array of bitmasks of GPIO settings (low/high) for each position
@idle: Bitmask to write to MUX when idle or GPIO_I2CMUX_NO_IDLE if not used
But ok, I don't feel strongly about it.
>> Why this change? I don't see why it is needed and the patch would be a
>> lot easier to review without all the s/.data/->data/ noise.
MR> Ah yes, since mux is already allocated using kcalloc, we don't need to
MR> do it for data as well. I will remove it.
Ok, great.
--
Sorry about disclaimer - It's out of my control.
Bye, Peter Korsgaard
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Gregory CLEMENT @ 2012-10-24 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210241136.12779.arnd@arndb.de>
On 10/24/2012 01:36 PM, Arnd Bergmann wrote:
> On Wednesday 24 October 2012, Gregory CLEMENT wrote:
>> +void __init armada_370_xp_coherency_iocache_init(void)
>> +{
>> + /* When the coherency fabric is available, the Armada XP and
>> + * Aramada 370 are close to a coherent architecture, so we based
>> + * our dma ops on the coherent one, and just changes the
>> + * operations which need a arch io sync */
>> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric")) {
>> + struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
>> + memcpy(dma_ops, &arm_coherent_dma_ops, sizeof(*dma_ops));
>> + dma_ops->map_page = armada_xp_dma_map_page;
>> + dma_ops->unmap_page = armada_xp_dma_unmap_page;
>> + dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
>> + dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
>> + dma_ops->sync_single_for_device = armada_xp_dma_sync;
>> + dma_ops->sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
>> + dma_ops->sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
>> + }
>> + bus_register_notifier(&platform_bus_type, &armada_xp_platform_nb);
>
> I think it would be cleaner to statically define the operations in a constant
> structure and point directly to the functions you need. If necessary, use
> multiple structures.
My problem was that these functions are not exposed, only arm_dma_op and
arm_coherent_dma_ops are exported.
Or do you think about something like this:
struct dma_map_ops *dma_ops = {
.alloc = arm_dma_ops.arm_coherent_dma_alloc,
.free = arm_dma_ops.arm_coherent_dma_free,
.mmap = arm_dma_ops.arm_dma_mmap,
.get_sgtable = arm_dma_ops.arm_dma_get_sgtable,
.map_sg = arm_dma_ops.arm_dma_map_sg,
.set_dma_mask = arm_dma_ops.arm_dma_set_mask,
.map_page = armada_xp_dma_map_page,
.unmap_page = armada_xp_dma_unmap_page,
.unmap_sg = arm_dma_ops.unmap_sg,
.sync_single_for_cpu = armada_xp_dma_sync,
.sync_single_for_device = armada_xp_dma_sync,
.sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
};
>
> Arnd
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Gregory CLEMENT @ 2012-10-24 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024082529.GZ11837@lunn.ch>
On 10/24/2012 10:25 AM, Andrew Lunn wrote:
> On Wed, Oct 24, 2012 at 10:04:01AM +0200, Gregory CLEMENT wrote:
>> Armada 370 and XP come with an unit called coherency fabric. This unit
>> allows to use the Armada XP as a nearly coherent architecture. The
>> coherency mechanism uses snoop filters to ensure the coherency between
>> caches, DRAM and devices. This mechanism needs a synchronization
>> barrier which guarantees that all memory write initiated by the
>> devices has reached their target and do not reside in intermediate
>> write buffers. That's why the architecture is not totally coherent and
>> we need to provide our own functions for some DMA operations.
>>
>> Beside the use of the coherency fabric, the device units will have to
>> set the attribute flag to select the accurate coherency process for
>> the memory transaction. This is done each device driver programs the
>> DRAM address windows. The value of the attribute set by the driver is
>> retrieved through the orion_addr_map_cfg struct filled during the
>> early initialization of the platform.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
>> ---
>> arch/arm/boot/dts/armada-370-xp.dtsi | 3 +-
>> arch/arm/mach-mvebu/addr-map.c | 3 ++
>> arch/arm/mach-mvebu/armada-370-xp.c | 1 +
>> arch/arm/mach-mvebu/coherency.c | 87 ++++++++++++++++++++++++++++++++++
>> arch/arm/mach-mvebu/common.h | 2 +
>> 5 files changed, 95 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>> index 18ba60b..af22e53 100644
>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>> @@ -38,7 +38,8 @@
>>
>> coherency-fabric at d0020200 {
>> compatible = "marvell,coherency-fabric";
>> - reg = <0xd0020200 0xb0>;
>> + reg = <0xd0020200 0xb0>,
>> + <0xd0021010 0x1c>;
>> };
>
> ...
>
>> int __init armada_370_xp_coherency_init(void)
>> {
>> struct device_node *np;
>> @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
>> if (np) {
>> pr_info("Initializing Coherency fabric\n");
>> coherency_base = of_iomap(np, 0);
>> + coherency_cpu_base = of_iomap(np, 1);
>
> Is this already in the binding documentation?
No indeed, the documentation should be completed. I will do it
the V2
>
> Thanks
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Gregory CLEMENT @ 2012-10-24 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087D574.4030503@free-electrons.com>
On 10/24/2012 01:48 PM, Gregory CLEMENT wrote:
> On 10/24/2012 01:36 PM, Arnd Bergmann wrote:
>> On Wednesday 24 October 2012, Gregory CLEMENT wrote:
>>> +void __init armada_370_xp_coherency_iocache_init(void)
>>> +{
>>> + /* When the coherency fabric is available, the Armada XP and
>>> + * Aramada 370 are close to a coherent architecture, so we based
>>> + * our dma ops on the coherent one, and just changes the
>>> + * operations which need a arch io sync */
>>> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric")) {
>>> + struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
>>> + memcpy(dma_ops, &arm_coherent_dma_ops, sizeof(*dma_ops));
>>> + dma_ops->map_page = armada_xp_dma_map_page;
>>> + dma_ops->unmap_page = armada_xp_dma_unmap_page;
>>> + dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
>>> + dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
>>> + dma_ops->sync_single_for_device = armada_xp_dma_sync;
>>> + dma_ops->sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
>>> + dma_ops->sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
>>> + }
>>> + bus_register_notifier(&platform_bus_type, &armada_xp_platform_nb);
>>
>> I think it would be cleaner to statically define the operations in a constant
>> structure and point directly to the functions you need. If necessary, use
>> multiple structures.
>
> My problem was that these functions are not exposed, only arm_dma_op and
> arm_coherent_dma_ops are exported.
> Or do you think about something like this:
>
> struct dma_map_ops *dma_ops = {
> .alloc = arm_dma_ops.arm_coherent_dma_alloc,
> .free = arm_dma_ops.arm_coherent_dma_free,
> .mmap = arm_dma_ops.arm_dma_mmap,
> .get_sgtable = arm_dma_ops.arm_dma_get_sgtable,
> .map_sg = arm_dma_ops.arm_dma_map_sg,
> .set_dma_mask = arm_dma_ops.arm_dma_set_mask,
> .map_page = armada_xp_dma_map_page,
> .unmap_page = armada_xp_dma_unmap_page,
> .unmap_sg = arm_dma_ops.unmap_sg,
> .sync_single_for_cpu = armada_xp_dma_sync,
> .sync_single_for_device = armada_xp_dma_sync,
> .sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu,
> .sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
> };
I was too fast to reply this struct is wrong, it should be as this one:
struct dma_map_ops *dma_ops = {
.alloc = arm_coherent_dma_ops.arm_coherent_dma_alloc,
.free = arm_coherent_dma_ops.arm_coherent_dma_free,
.mmap = arm_coherent_dma_ops.arm_dma_mmap,
.get_sgtable = arm_coherent_dma_ops.arm_dma_get_sgtable,
.map_sg = arm_coherent_dma_ops.arm_dma_map_sg,
.set_dma_mask = arm_coherent_dma_ops.arm_dma_set_mask,
.map_page = armada_xp_dma_map_page,
.unmap_page = armada_xp_dma_unmap_page,
.unmap_sg = arm_dma_ops.unmap_sg,
.sync_single_for_cpu = armada_xp_dma_sync,
.sync_single_for_device = armada_xp_dma_sync,
.sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
};
Thanks,
Gregory
^ permalink raw reply
* [PATCH 1/2] arm: plat-orion: Add coherency attribute when setup mbus target
From: Thomas Petazzoni @ 2012-10-24 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-2-git-send-email-gregory.clement@free-electrons.com>
On Wed, 24 Oct 2012 10:04:00 +0200, Gregory CLEMENT wrote:
> Recent SoC such as Armada 370/XP came with the possibility to deal
> with the I/O coherency by hardware. In this case the transaction
> attribute of the window must be flagged as "Shared transaction". Once
> this flag is set, then the transactions will be forced to be sent
> through the coherency block, in other case transaction is driven
> directly to DRAM.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 3/3] dmaengine: sirf: enable the driver support new SiRFmarco SoC
From: Barry Song @ 2012-10-24 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351076581.5263.56.camel@vkoul-udesk3>
Hi Vinod,
Thanks a lot!
2012/10/24 Vinod Koul <vkoul@infradead.org>
>
> On Thu, 2012-09-27 at 16:36 +0800, Barry Song wrote:
> > From: Barry Song <Baohua.Song@csr.com>
> >
> > The driver supports old up SiRFprimaII SoCs, this patch makes it support
> > the new SiRFmarco as well.
> > SiRFmarco, as a SMP SoC, adds new DMA_INT_EN_CLR and DMA_CH_LOOP_CTRL_CLR
> > registers, to disable IRQ/Channel, we should write 1 to the corresponding
> > bit in the two CLEAR register.
> >
> > Tested on SiRFmarco using SPI driver:
> > $ /mnt/spidev-sirftest -D /dev/spidev32766.0
> > spi mode: 0
> > bits per word: 8
> > max speed: 500000 Hz (500 KHz)
> >
> > 00 00 00 00 00 00
> > 00 00 00 00 00 00
> > 00 00 00 00 00 00
> > 00 00 00 00 00 00
> > 00 00 00 00 00 00
> > 00 00 00 00 00 00
> > 00 00 00 00
> >
> > $ cat /proc/interrupts
> > CPU0 CPU1
> > 32: 1593 0 GIC sirfsoc_timer0
> > 33: 0 3533 GIC sirfsoc_timer1
> > 44: 0 0 GIC sirfsoc_dma
> > 45: 16 0 GIC sirfsoc_dma
> > 47: 6 0 GIC sirfsoc_spi
> > 50: 5654 0 GIC sirfsoc-uart
> > ...
> >
> > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > ---
> > depends on pulled CSR SiRFmarco preparing patches:
> > http://www.spinics.net/lists/arm-kernel/msg191412.html
> >
> > drivers/dma/Kconfig | 2 +-
> > drivers/dma/sirf-dma.c | 25 +++++++++++++++++++------
> > 2 files changed, 20 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index d06ea29..bf5f405 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -203,7 +203,7 @@ config TIMB_DMA
> >
> > config SIRF_DMA
> > tristate "CSR SiRFprimaII DMA support"
> > - depends on ARCH_PRIMA2
> > + depends on ARCH_SIRF
> patch description says adding support, but now your are removing for
> PRIMA2, did I miss anything?
this is not removing PRIMA2, as you see the newest kernel, SIRF
includes PRIMA2 and coming MARCO. so let the driver depend on SIRF
since it supports both PRIMA2 and MARCO. see commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=156a09979710f260f4482961869d6260148341e9
> > select DMA_ENGINE
> > help
> > Enable support for the CSR SiRFprimaII DMA engine.
> > diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> > index c439489..fbb0199 100644
> > --- a/drivers/dma/sirf-dma.c
> > +++ b/drivers/dma/sirf-dma.c
> > @@ -32,7 +32,9 @@
> > #define SIRFSOC_DMA_CH_VALID 0x140
> > #define SIRFSOC_DMA_CH_INT 0x144
> > #define SIRFSOC_DMA_INT_EN 0x148
> > +#define SIRFSOC_DMA_INT_EN_CLR 0x14C
> can you pls align this
> > #define SIRFSOC_DMA_CH_LOOP_CTRL 0x150
> > +#define SIRFSOC_DMA_CH_LOOP_CTRL_CLR 0x15C
> >
> > #define SIRFSOC_DMA_MODE_CTRL_BIT 4
> > #define SIRFSOC_DMA_DIR_CTRL_BIT 5
> > @@ -76,6 +78,7 @@ struct sirfsoc_dma {
> > struct sirfsoc_dma_chan channels[SIRFSOC_DMA_CHANNELS];
> > void __iomem *base;
> > int irq;
> > + bool is_marco;
> > };
> >
> > #define DRV_NAME "sirfsoc_dma"
> > @@ -288,13 +291,19 @@ static int sirfsoc_dma_terminate_all(struct sirfsoc_dma_chan *schan)
> > int cid = schan->chan.chan_id;
> > unsigned long flags;
> >
> > - writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) &
> > - ~(1 << cid), sdma->base + SIRFSOC_DMA_INT_EN);
> > - writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_CH_VALID);
> > -
> > - writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
> > - & ~((1 << cid) | 1 << (cid + 16)),
> > + if (!sdma->is_marco) {
> > + writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) &
> > + ~(1 << cid), sdma->base + SIRFSOC_DMA_INT_EN);
> > + writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
> > + & ~((1 << cid) | 1 << (cid + 16)),
> > sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
> > + } else {
> > + writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_INT_EN_CLR);
> > + writel_relaxed((1 << cid) | 1 << (cid + 16),
> > + sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
> > + }
> > +
> > + writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_CH_VALID);
> >
> > spin_lock_irqsave(&schan->lock, flags);
> > list_splice_tail_init(&schan->active, &schan->free);
> > @@ -568,6 +577,9 @@ static int __devinit sirfsoc_dma_probe(struct platform_device *op)
> > return -ENOMEM;
> > }
> >
> > + if (of_device_is_compatible(dn, "sirf,marco-dmac"))
> not a DT expert, but wouldn't there be a space after comma?
compatible fields in .dts don't have space after comma:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=arch/arm/boot/dts;
> > + sdma->is_marco = true;
> > +
> > if (of_property_read_u32(dn, "cell-index", &id)) {
> > dev_err(dev, "Fail to get DMAC index\n");
> > ret = -ENODEV;
> > @@ -677,6 +689,7 @@ static int __devexit sirfsoc_dma_remove(struct platform_device *op)
> >
> > static struct of_device_id sirfsoc_dma_match[] = {
> > { .compatible = "sirf,prima2-dmac", },
> > + { .compatible = "sirf,marco-dmac", },
> > {},
> > };
> >
>
>
> --
> Vinod Koul
> Intel Corp.
-barry
^ permalink raw reply
* [PATCH 1/1] pinctrl: at91: fix typo on PULL_UP
From: Linus Walleij @ 2012-10-24 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351009680-15892-1-git-send-email-plagnioj@jcrosoft.com>
On Tue, Oct 23, 2012 at 6:28 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
Applied to the at91 branch, thanks!
Linus Walleij
^ permalink raw reply
* [PATCH 1/1] gpio/at91: auto request and configure the pio as input when the interrupt is used via DT
From: Linus Walleij @ 2012-10-24 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351000601-3141-1-git-send-email-plagnioj@jcrosoft.com>
On Tue, Oct 23, 2012 at 3:56 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> If we do this
>
> interrupt-parent = <&pioA>;
> interrupts = <7 0x0>;
>
> The current core map the irq correctly but the gpio is not configured as input.
> The pinctrl configure the pin as gpio with the correct mux parameter but is
> not responsible to configure it as input.
>
> So do it during the xlate
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Applied to my at91 branch, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Grazvydas Ignotas @ 2012-10-24 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351015771-6308-1-git-send-email-khilman@deeprootsystems.com>
On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> When debounce clocks are disabled, ensure that the banks
> dbck_enable_mask is cleared also. Otherwise, context restore on
> subsequent off-mode transition will restore previous value from the
> shadow copies (bank->context.debounce*) leading to mismatch state
> between driver state and hardware state.
This doesn't look right to me, aren't you effectively disabling
debounce forever here? _gpio_dbck_disable is called from
omap_gpio_runtime_suspend() and nothing will ever restore
dbck_enable_mask back to what it was set by _set_gpio_debounce and
debounce functionality is lost.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state.
> Then, enabling off mode causing bogus state to be restored, leaving
> GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies on v3.7-rc2, targetted for v3.7.
>
> drivers/gpio/gpio-omap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 94cbc84..dee2856 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank *bank)
> * to detect events and generate interrupts at least on OMAP3.
> */
> __raw_writel(0, bank->base + bank->regs->debounce_en);
> + bank->dbck_enable_mask = 0;
>
> clk_disable(bank->dbck);
> bank->dbck_enabled = false;
> --
> 1.8.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gra?vydas
^ permalink raw reply
* [PATCH v3 1/5] zynq: use GIC device tree bindings
From: Arnd Bergmann @ 2012-10-24 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003353.GB31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> The Zynq uses the cortex-a9-gic. This eliminates the need to hardcode
> register addresses.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 2/5] zynq: use pl310 device tree bindings
From: Arnd Bergmann @ 2012-10-24 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003416.GC31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> The Zynq has a PL310 L2 cache controller. Convert in-tree uses to using
> the device tree.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 3/5] zynq: remove use of CLKDEV_LOOKUP
From: Arnd Bergmann @ 2012-10-24 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003442.GD31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> The Zynq support in mainline does not (yet) make use of any of the
> generic clk or clk lookup functionality. Remove what is upstream for
> now, until the out-of-tree implementation is in suitable form for
> merging.
>
> An important side effect of this patch is that it allows the building of
> a Zynq kernel without running into unresolved symbol problems:
>
> drivers/built-in.o: In function `amba_get_enable_pclk':
> clkdev.c:(.text+0x444): undefined reference to `clk_enable'
> drivers/built-in.o: In function `amba_remove':
> clkdev.c:(.text+0x488): undefined reference to `clk_disable'
> drivers/built-in.o: In function `amba_probe':
> clkdev.c:(.text+0x540): undefined reference to `clk_disable'
> drivers/built-in.o: In function `amba_device_add':
> clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
> drivers/built-in.o: In function `enable_clock':
> clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
> drivers/built-in.o: In function `disable_clock':
> clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
> drivers/built-in.o: In function `__pm_clk_remove':
> clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
> drivers/built-in.o: In function `pm_clk_suspend':
> clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
> drivers/built-in.o: In function `pm_clk_resume':
> clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
> make[2]: *** [vmlinux] Error 1
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
I think I forgot to mention in the previous review round that it would be nice
to just enable CONFIG_COMMON_CLK right away. Not important though.
Arnd
^ permalink raw reply
* [PATCH v3 4/5] ARM: annotate VMALLOC_END definition with _AC
From: Arnd Bergmann @ 2012-10-24 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003502.GE31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> This makes the definition of VMALLOC_END suitable for use within
> assembly code. This is necessary to allow the use of VMALLOC_END in
> defining where the early uart is mapped for use with DEBUG_LL.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 5/5] zynq: move static peripheral mappings
From: Arnd Bergmann @ 2012-10-24 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003523.GF31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> Shifting them up into the vmalloc region prevents the following warning,
> when booting a zynq qemu target with more than 512mb of RAM:
>
> BUG: mapping for 0xe0000000 at 0xe0000000 out of vmalloc space
>
> In addition, it allows for reuse of these mappings when the proper
> drivers issue requests via ioremap().
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 0/5] zynq subarch cleanups
From: Arnd Bergmann @ 2012-10-24 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024003218.GA31625@beefymiracle.amer.corp.natinst.com>
On Wednesday 24 October 2012, Josh Cartwright wrote:
> Things have been relatively quiet on the Zynq front lately. This patchset does
> a bit of cleanup of the Zynq subarchitecture. It was the necessary set of
> things I had to do to get a zynq target booting with the upstream qemu model.
>
> Patches 1 and 2 move zynq to use the GIC and pl310 L2 cache controller device
> tree mappings respectively.
>
> Patch 3 removes unused clock infrastructure. the plan is to rework the
> out-of-tree Xilinx generic clk support into something suitable for merging.
> What's in tree now just isn't used at all, and can be removed.
>
> Patch 4 and 5 move around the static peripheral mappings into the vmalloc area.
Looks all good to me now.
>
> I intentionally did not Cc stable on patch 5, even though you had
> suggested otherwise. I do not think it will apply cleanly to the stable
> trees independent of the other patches. Additionally, with the current
> state of zynq upstream, I'm not convinced there would be enough users to
> make it worth the effort.
Ok, fair enough.
> Additionally, I've left the SCU static mapping around, even though its
> currently unused. We'll eventually need it around (maybe in a different form)
> when SMP support is added.
Right.
John, are you going to pick up these patches and send a pull request?
Arnd
^ 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