* [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 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 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 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] 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 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 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 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/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 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 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: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 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: 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 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 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] 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 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 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 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 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 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 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 2/5] i2c: i2c-sh_mobile: optimize ICCH/ICCL values according to I2C bus speed
From: Shinya Kuribayashi @ 2012-10-24 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087C93F.6080601@renesas.com>
ICCH/ICCL values is supposed to be calculated/optimized to strictly meet
the timing specs required by the I2C standard. The resulting I2C bus
speed does not matter at all, if it's less than 100 or 400 kHz.
Also fix a typo in the comment, print icch/iccl values at probe, etc.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/i2c/busses/i2c-sh_mobile.c | 121 ++++++++++++++++++++++---------------
1 file changed, 72 insertions(+), 49 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 309d0d5..1ad80c9 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -122,9 +122,9 @@ struct sh_mobile_i2c_data {
unsigned long bus_speed;
struct clk *clk;
u_int8_t icic;
- u_int8_t iccl;
- u_int8_t icch;
u_int8_t flags;
+ u_int16_t iccl;
+ u_int16_t icch;
spinlock_t lock;
wait_queue_head_t wait;
@@ -135,7 +135,8 @@ struct sh_mobile_i2c_data {
#define IIC_FLAG_HAS_ICIC67 (1 << 0)
-#define NORMAL_SPEED 100000 /* FAST_SPEED 400000 */
+#define STANDARD_MODE 100000
+#define FAST_MODE 400000
/* Register offsets */
#define ICDR 0x00
@@ -187,55 +188,76 @@ static void iic_set_clr(struct sh_mobile_i2c_data *pd, int offs,
iic_wr(pd, offs, (iic_rd(pd, offs) | set) & ~clr);
}
+static u32 sh_mobile_i2c_iccl(unsigned long count_khz, u32 tLOW, u32 tf, int offset)
+{
+ /*
+ * Conditional expression:
+ * ICCL >= COUNT_CLK * (tLOW + tf)
+ *
+ * SH-Mobile IIC hardware starts counting the LOW period of
+ * the SCL signal (tLOW) as soon as it pulls the SCL line.
+ * In order to meet the tLOW timing spec, we need to take into
+ * account the fall time of SCL signal (tf). Default tf value
+ * should be 0.3 us, for safety.
+ */
+ return (((count_khz * (tLOW + tf)) + 5000) / 10000) + offset;
+}
+
+static u32 sh_mobile_i2c_icch(unsigned long count_khz, u32 tHIGH, int offset)
+{
+ /*
+ * Conditional expression:
+ * ICCH >= COUNT_CLK * tHIGH
+ *
+ * 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.
+ */
+ return ((count_khz * tHIGH) + 5000) / 10000 + offset;
+}
+
static void sh_mobile_i2c_init(struct sh_mobile_i2c_data *pd)
{
- unsigned long i2c_clk;
- u_int32_t num;
- u_int32_t denom;
- u_int32_t tmp;
+ unsigned long i2c_clk_khz;
+ u32 tHIGH, tLOW, tf;
+ int offset;
/* Get clock rate after clock is enabled */
clk_enable(pd->clk);
- i2c_clk = clk_get_rate(pd->clk);
-
- /* Calculate the value for iccl. From the data sheet:
- * iccl = (p clock / transfer rate) * (L / (L + H))
- * where L and H are the SCL low/high ratio (5/4 in this case).
- * We also round off the result.
- */
- num = i2c_clk * 5;
- denom = pd->bus_speed * 9;
- tmp = num * 10 / denom;
- if (tmp % 10 >= 5)
- pd->iccl = (u_int8_t)((num/denom) + 1);
- else
- pd->iccl = (u_int8_t)(num/denom);
-
- /* one more bit of ICCL in ICIC */
- if (pd->flags & IIC_FLAG_HAS_ICIC67) {
- if ((num/denom) > 0xff)
- pd->icic |= ICIC_ICCLB8;
- else
- pd->icic &= ~ICIC_ICCLB8;
+ i2c_clk_khz = clk_get_rate(pd->clk) / 1000;
+
+ if (pd->bus_speed == STANDARD_MODE) {
+ tLOW = 47; /* tLOW = 4.7 us */
+ tHIGH = 40; /* tHD;STA = tHIGH = 4.0 us */
+ tf = 3; /* tf = 0.3 us */
+ offset = 0; /* No offset */
+ } else if (pd->bus_speed == FAST_MODE) {
+ tLOW = 13; /* tLOW = 1.3 us */
+ tHIGH = 6; /* tHD;STA = tHIGH = 0.6 us */
+ tf = 3; /* tf = 0.3 us */
+ offset = 0; /* No offset */
+ } else {
+ dev_err(pd->dev, "unrecognized bus speed %lu Hz\n",
+ pd->bus_speed);
+ goto out;
}
- /* Calculate the value for icch. From the data sheet:
- icch = (p clock / transfer rate) * (H / (L + H)) */
- num = i2c_clk * 4;
- tmp = num * 10 / denom;
- if (tmp % 10 >= 5)
- pd->icch = (u_int8_t)((num/denom) + 1);
+ pd->iccl = sh_mobile_i2c_iccl(i2c_clk_khz, tLOW, tf, offset);
+ /* one more bit of ICCL in ICIC */
+ if ((pd->iccl > 0xff) && (pd->flags & IIC_FLAG_HAS_ICIC67))
+ pd->icic |= ICIC_ICCLB8;
else
- pd->icch = (u_int8_t)(num/denom);
+ pd->icic &= ~ICIC_ICCLB8;
+ pd->icch = sh_mobile_i2c_icch(i2c_clk_khz, tHIGH, offset);
/* one more bit of ICCH in ICIC */
- if (pd->flags & IIC_FLAG_HAS_ICIC67) {
- if ((num/denom) > 0xff)
- pd->icic |= ICIC_ICCHB8;
- else
- pd->icic &= ~ICIC_ICCHB8;
- }
+ if ((pd->icch > 0xff) && (pd->flags & IIC_FLAG_HAS_ICIC67))
+ pd->icic |= ICIC_ICCHB8;
+ else
+ pd->icic &= ~ICIC_ICCHB8;
+out:
clk_disable(pd->clk);
}
@@ -252,8 +274,8 @@ static void activate_ch(struct sh_mobile_i2c_data *pd)
iic_wr(pd, ICIC, 0);
/* Set the clock */
- iic_wr(pd, ICCL, pd->iccl);
- iic_wr(pd, ICCH, pd->icch);
+ iic_wr(pd, ICCL, pd->iccl & 0xff);
+ iic_wr(pd, ICCH, pd->icch & 0xff);
}
static void deactivate_ch(struct sh_mobile_i2c_data *pd)
@@ -457,8 +479,8 @@ static int start_ch(struct sh_mobile_i2c_data *pd, struct i2c_msg *usr_msg)
iic_set_clr(pd, ICCR, ICCR_ICE, 0);
/* Set the clock */
- iic_wr(pd, ICCL, pd->iccl);
- iic_wr(pd, ICCH, pd->icch);
+ iic_wr(pd, ICCL, pd->iccl & 0xff);
+ iic_wr(pd, ICCH, pd->icch & 0xff);
pd->msg = usr_msg;
pd->pos = -1;
@@ -627,8 +649,8 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
goto err_irq;
}
- /* Use platformd data bus speed or NORMAL_SPEED */
- pd->bus_speed = NORMAL_SPEED;
+ /* Use platform data bus speed or STANDARD_MODE */
+ pd->bus_speed = STANDARD_MODE;
if (pdata && pdata->bus_speed)
pd->bus_speed = pdata->bus_speed;
@@ -675,8 +697,9 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
goto err_all;
}
- dev_info(&dev->dev, "I2C adapter %d with bus speed %lu Hz\n",
- adap->nr, pd->bus_speed);
+ dev_info(&dev->dev,
+ "I2C adapter %d with bus speed %lu Hz (L/H=%x/%x)\n",
+ adap->nr, pd->bus_speed, pd->iccl, pd->icch);
of_i2c_register_devices(adap);
return 0;
--
1.7.12.4
^ permalink raw reply related
* [PATCH 1/5] i2c: i2c-sh_mobile: calculate clock parameters at driver probing time
From: Shinya Kuribayashi @ 2012-10-24 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087C93F.6080601@renesas.com>
Currently SCL clock parameters (ICCH/ICCL) are calculated in
activate_ch(), which gets called every time sh_mobile_i2c_xfer() is
processed, while each I2C bus speed is system-defined and in general
those parameters do not have to be updated over I2C transactions.
The only reason I could see having it transaction-time is to adjust
ICCH/ICCL values according to the operating frequency of the I2C
hardware block, in the face of DFS (Dynamic Frequency Scaling).
However, this won't be necessary.
The operating frequency of the I2C hardware block can change _even_
in the middle of I2C transactions. There is no way to prevent it
from happening, and I2C hardware block can work with such dynamic
frequency change, of course.
Another is that ICCH/ICCL clock parameters optimized for the faster
operating frequency, can also be applied to the slower operating
frequency, as long as slave devices work. However, the converse is
not true. It would violate SCL timing specs of the I2C standard.
What we can do now is to calculate the ICCH/ICCL clock parameters
according to the fastest operating clock of the I2C hardware block.
And if that's the case, that calculation should be done just once
at driver-module-init time.
This patch moves ICCH/ICCL calculating part from activate_ch() into
sh_mobile_i2c_init(), and call it from sh_mobile_i2c_probe().
Note that sh_mobile_i2c_init() just prepares clock parameters using
the clock rate and platform data provided, but does _not_ make any
hardware I/O accesses. We don't have to care about run-time PM
maintenance here.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/i2c/busses/i2c-sh_mobile.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 8110ca4..309d0d5 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -187,18 +187,15 @@ static void iic_set_clr(struct sh_mobile_i2c_data *pd, int offs,
iic_wr(pd, offs, (iic_rd(pd, offs) | set) & ~clr);
}
-static void activate_ch(struct sh_mobile_i2c_data *pd)
+static void sh_mobile_i2c_init(struct sh_mobile_i2c_data *pd)
{
unsigned long i2c_clk;
u_int32_t num;
u_int32_t denom;
u_int32_t tmp;
- /* Wake up device and enable clock */
- pm_runtime_get_sync(pd->dev);
- clk_enable(pd->clk);
-
/* Get clock rate after clock is enabled */
+ clk_enable(pd->clk);
i2c_clk = clk_get_rate(pd->clk);
/* Calculate the value for iccl. From the data sheet:
@@ -239,6 +236,15 @@ static void activate_ch(struct sh_mobile_i2c_data *pd)
pd->icic &= ~ICIC_ICCHB8;
}
+ clk_disable(pd->clk);
+}
+
+static void activate_ch(struct sh_mobile_i2c_data *pd)
+{
+ /* Wake up device and enable clock */
+ pm_runtime_get_sync(pd->dev);
+ clk_enable(pd->clk);
+
/* Enable channel and configure rx ack */
iic_set_clr(pd, ICCR, ICCR_ICE, 0);
@@ -632,6 +638,8 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
if (size > 0x17)
pd->flags |= IIC_FLAG_HAS_ICIC67;
+ sh_mobile_i2c_init(pd);
+
/* Enable Runtime PM for this device.
*
* Also tell the Runtime PM core to ignore children
--
1.7.12.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox