* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Will Deacon @ 2012-11-07 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211071035220.21033@xanadu.home>
On Wed, Nov 07, 2012 at 06:03:40PM +0000, Nicolas Pitre wrote:
> On Wed, 7 Nov 2012, Will Deacon wrote:
> > On Wed, Nov 07, 2012 at 09:56:35AM +0000, Russell King - ARM Linux wrote:
> > > On Wed, Nov 07, 2012 at 09:51:06AM +0000, Will Deacon wrote:
> > > > Wouldn't the L2 flush in this case be included with the code that turns off
> > > > caching? For reboot, that's currently done in __sort_restart -- the cache
> > > > flush in setup_mm_for_reboot is just to ensure that the idmap tables are
> > > > visible to the hardware walker iirc.
> > >
> > > Good point - but it does raise another issue. Why do we do this flush and
> > > TLB invalidate afterwards in setup_mm_for_reboot() ? It makes sense if
> > > we change existing page tables, but we don't anymore, we're just switching
> > > them, and cpu_switch_mm() will do whatever's necessary to make the new
> > > page tables visible. So I think we can get rid of that flusing in there.
> >
> > Hmm, I'm not sure about that. Looking at cpu_v7_switch_mm (the 2-level
> > version) for example, we set the ASID and then set the new TTBR. There's no
> > flushing of page tables like we get in set_pte and no TLB flushing either.
> >
> > Now, given that the idmap_pgd is populated as an early_initcall, I really
> > doubt we need that flush_cache_all but the TLB invalidate is surely
> > required?
>
> Why wouldn't cpu_switch_mm() take care of that already if that is
> necessary? Hmmm, I suppose the asid of the init task isn't associated
> with the idmap in any way, hence the need for flushing the tlbs.
Yes, cpu_switch_mm can't know about whether tables are visible or an ASID is
dirty so all it can do is defer that to the caller or do the cleaning and
invalidation every time.
> I'd not rely on the early_initcall to assume the new page table is moved
> out of the cache though.
Yeah, it's not nice, I was just pointing out that it's all hanging off an
initcall now (before it was created ad-hoc by its users).
> What about this alternate patch:
>
> diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
> index ab88ed4f8e..1ab429761c 100644
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -92,6 +92,9 @@ static int __init init_static_idmap(void)
> (long long)idmap_start, (long long)idmap_end);
> identity_mapping_add(idmap_pgd, idmap_start, idmap_end);
>
> + /* Flush L1 for the hardware to see this page table content */
> + flush_cache_louis();
> +
> return 0;
> }
Yep, we can do this now. Good thinking! At some point I'll get around to
making this conditional, as I don't think it's needed on A5, A7, A9 or A15.
> early_initcall(init_static_idmap);
> @@ -103,12 +106,12 @@ early_initcall(init_static_idmap);
> */
> void setup_mm_for_reboot(void)
> {
> - /* Clean and invalidate L1. */
> - flush_cache_all();
> -
> /* Switch to the identity mapping. */
> cpu_switch_mm(idmap_pgd, &init_mm);
>
> - /* Flush the TLB. */
> + /*
> + * On ARMv7, the ASID of the init task is not associated with
> + * this mapping. TLBs must be flushed.
> + */
> local_flush_tlb_all();
> }
Can we change this comment slightly please? Basically, we don't have a clean
ASID for the identity mapping, which may clash with virtual addresses of the
previous page tables and therefore potentially in the TLB. That's why
we need the invalidation: so that we don't hit stale entries from before.
Other than that, looks good to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply
* [PATCHv9 0/8] ARM: OMAP4: core retention support
From: Paul Walmsley @ 2012-11-07 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d2zrg04t.fsf@deeprootsystems.com>
Hi,
On Mon, 5 Nov 2012, Kevin Hilman wrote:
> # echo mem > /sys/power/state
> [ 102.271087] PM: Syncing filesystems ... done.
> [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [ 102.343353] Suspending console(s) (use no_console_suspend to debug)
> ???[ 102.363433] PM: suspend of devices complete after 10.650 msecs
> [ 102.365631] PM: late suspend of devices complete after 2.166 msecs
> [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs
> [ 102.369232] Disabling non-boot CPUs ...
> [ 102.373016] CPU1: shutdown
[...]
By the way, looks like you're seeing the same garbage character generated
as I was on v3.6 with these patches. It's the first character of the line
that's dated "102.363433". At 230kbps, it comes across as a "5" that the
OMAP thinks originates from the host computer, sent to the Panda.
Would be useful if someone could identify what's causing this. None of
the OMAP3 boards currently exhibit this behavior. Would na?vely assume
that the OMAP4 is waking up fast enough to capture some of the bits of the
serial wakeup character, but have not confirmed this.
- Paul
^ permalink raw reply
* [PATCH v4 0/3] ocp2scp: add non-dt support
From: Tony Lindgren @ 2012-11-07 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351844088-27059-1-git-send-email-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [121102 01:16]:
> This patch series allows ocp2scp driver to create its child devices
> from the platform data.
>
> In omap platforms, usb phy is connected to ocp2scp and usb phy is needed
> for MUSB to be functional. When ocp2scp driver was added, it had only dt
> support which means it wont create usb phy devices for non-dt boot.
>
> This patch series adds non-dt support to ocp2scp and this series is needed
> for getting MUSB functional in non-dt boot.
Thanks I've pushed these into omap-for-v3.7-rc4/musb-regression with
updated description to describe the regression for the -rc cycle.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Tony Lindgren @ 2012-11-07 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211071819160.20704@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121107 10:21]:
> On Wed, 7 Nov 2012, Paul Walmsley wrote:
>
> > If you're asking for a test build of the base commit,
> > 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33, I just kicked off a test build
> > of that; will post when done.
>
> Just confirmed that this one passes all build tests here.
OK good to know so no need to merge in anything into
cleanup-prcm before pulling in your part2 then.
Thanks,
Tony
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Paul Walmsley @ 2012-11-07 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211070227500.8758@utopia.booyaka.com>
On Wed, 7 Nov 2012, Paul Walmsley wrote:
> If you're asking for a test build of the base commit,
> 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33, I just kicked off a test build
> of that; will post when done.
Just confirmed that this one passes all build tests here.
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc4
From: Jon Hunter @ 2012-11-07 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211071728310.20704@utopia.booyaka.com>
On 11/07/2012 11:32 AM, Paul Walmsley wrote:
> On Wed, 7 Nov 2012, Jon Hunter wrote:
>
>> On 11/04/2012 08:46 PM, Paul Walmsley wrote:
>>
>>> * 4460pandaes: boot fails early
>>> - Appears to be due to X-loader problems here
>>> - Need to note the X-loader version so we know it's broken
>>
>> Are you still planning to investigate this further or migrate to a new
>> bootloader?
>
> Yes. The problem with the current boot setup is that the new
> bootloader is breaking as well! :-(
Ugh!
> This can be seen by comparing:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/4460pandaes/4460pandaes_log.txt
>
> (the old bootloader)
>
> with
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/boot/4460pandaes/4460pandaes_log.txt
>
> (the new bootloader)
If you get chance, it would be good to test u-boot v2012.10 release, as
I am using this and it is working fine. I see the "new" bootloader you
are using is v2012.07 (however, I though this was working too). Weird ...
> Dealing with this will require hands-on access, and unfortunately, right
> now I am traveling and away from my testbed. Next week, will take a
> closer look.
>
>> With 4460 and 3.7-rc4, I am seeing that resume from suspend is not
>> working (not sure when this broke though). I am just curious if anyone
>> else sees this. My u-boot version is v2012.10.
>
> If you have the chance, it would be useful to know if any of the v3.7-rcs
> worked. Otherwise, will look at this next week.
Ok, I will see if I can figure out where this broke.
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: setup_mm_for_reboot(): use flush_cache_louis()
From: Nicolas Pitre @ 2012-11-07 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107100835.GB23305@mudshark.cambridge.arm.com>
On Wed, 7 Nov 2012, Will Deacon wrote:
> On Wed, Nov 07, 2012 at 09:56:35AM +0000, Russell King - ARM Linux wrote:
> > On Wed, Nov 07, 2012 at 09:51:06AM +0000, Will Deacon wrote:
> > > Wouldn't the L2 flush in this case be included with the code that turns off
> > > caching? For reboot, that's currently done in __sort_restart -- the cache
> > > flush in setup_mm_for_reboot is just to ensure that the idmap tables are
> > > visible to the hardware walker iirc.
> >
> > Good point - but it does raise another issue. Why do we do this flush and
> > TLB invalidate afterwards in setup_mm_for_reboot() ? It makes sense if
> > we change existing page tables, but we don't anymore, we're just switching
> > them, and cpu_switch_mm() will do whatever's necessary to make the new
> > page tables visible. So I think we can get rid of that flusing in there.
>
> Hmm, I'm not sure about that. Looking at cpu_v7_switch_mm (the 2-level
> version) for example, we set the ASID and then set the new TTBR. There's no
> flushing of page tables like we get in set_pte and no TLB flushing either.
>
> Now, given that the idmap_pgd is populated as an early_initcall, I really
> doubt we need that flush_cache_all but the TLB invalidate is surely
> required?
Why wouldn't cpu_switch_mm() take care of that already if that is
necessary? Hmmm, I suppose the asid of the init task isn't associated
with the idmap in any way, hence the need for flushing the tlbs.
I'd not rely on the early_initcall to assume the new page table is moved
out of the cache though.
What about this alternate patch:
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index ab88ed4f8e..1ab429761c 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -92,6 +92,9 @@ static int __init init_static_idmap(void)
(long long)idmap_start, (long long)idmap_end);
identity_mapping_add(idmap_pgd, idmap_start, idmap_end);
+ /* Flush L1 for the hardware to see this page table content */
+ flush_cache_louis();
+
return 0;
}
early_initcall(init_static_idmap);
@@ -103,12 +106,12 @@ early_initcall(init_static_idmap);
*/
void setup_mm_for_reboot(void)
{
- /* Clean and invalidate L1. */
- flush_cache_all();
-
/* Switch to the identity mapping. */
cpu_switch_mm(idmap_pgd, &init_mm);
- /* Flush the TLB. */
+ /*
+ * On ARMv7, the ASID of the init task is not associated with
+ * this mapping. TLBs must be flushed.
+ */
local_flush_tlb_all();
}
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: Make s3c_device_i2c0 always use id 0
From: Sylwester Nawrocki @ 2012-11-07 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4039915.8GOx0SKq2B@amdc1227>
On 11/07/2012 02:00 PM, Tomasz Figa wrote:
> This patch removes compatibility definitions added long time ago when
> clock ids were used instead of devnames that were needed for platforms
> with only one i2c controller with id -1 (some s3c24xx's).
>
> Because currently devname field is used for matching device instances to
> clocks and if no devname is provided (as in clock-s3c2412.c and
> common-s3c2443.c for i2c clock, both in arch/arm/mach-s3c24xx) the clock
> is being matched only by name, so s3c_device_i2c0 can always have id 0.
>
> This patch solves the issue with i2c0 broken on boards where its the
> only i2c controller used, tested on Origen.
>
> Signed-off-by: Tomasz Figa<t.figa@samsung.com>
> Signed-off-by: Kyungmin Park<kyungmin.park@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
Thanks,
Sylwester
^ permalink raw reply
* Testing i2c in 3.6.0-next-20121012 for i.mx233
From: Fabio Estevam @ 2012-11-07 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350096488.12723.YahooMailNeo@web162606.mail.bf1.yahoo.com>
Hi Tim,
On Sat, Oct 13, 2012 at 4:48 AM, Tim michals <tcmichals@yahoo.com> wrote:
> Using the 3.6.0-next-20121012 to test i2c DMA support on a
> imx233-Olinuxino-micro board. When using the i2cdetect -r 0 to scan a
> devices on the i2c bus, the following message is displayed on the console:
>
> -- [ 129.130000] mxs-i2c 80058000.i2c: Failed to get PIO reg. write
> descriptor.
>
> imx23.dtsi support for i2c:
> i2c0_pins_a: i2c0 at 0 {
> reg = <0>;
> fsl,pinmux-ids = <
> 0x1171 /* MX23_PAD_LCD_ENABLE__LCD_ENABLE */
> 0x1181 /* MX23_PAD_LCD_HSYNC__LCD_HSYNC */
>>;
> fsl,drive-strength = <1>;
> fsl,voltage = <1>;
> fsl,pull-up = <1>;
> };
> ...
> i2c at 80058000 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,imx28-i2c";
This shoulbe be imx23-i2c instead.
Regards,
Fabio Estevam
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-11-07 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107153529.GT23305@mudshark.cambridge.arm.com>
On Wed, Nov 07, 2012 at 03:35:30PM +0000, Will Deacon wrote:
> On Wed, Nov 07, 2012 at 12:00:52PM +0000, Lorenzo Pieralisi wrote:
> > On Wed, Nov 07, 2012 at 11:05:42AM +0000, Will Deacon wrote:
> > > No, I was thinking about what happens if the devicetree doesn't contain an
> > > mpidr property that matches the boot cpu. In this case, we will fail to
> > > assign logical ID 0, right? If this happens, we should complain about an
> > > invalid devicetree and try to fall back on the logical_map that was
> > > generated earlier on.
> >
> > Good point. What I could do, I can assign the MPIDR of the boot CPU to
> > the logical index 0 before even starting to parse the DT (that's what it
> > is done in smp_setup_processor_id(), with a couple of twists). Then, if I
> > find a node that matches the boot CPU mpidr I just skip over it. This
> > way the boot CPU MPIDR will always be correct the only difference with
> > the current approach will be that instead of generating the secondaries
> > MPIDRs we will read them from DT.
>
> That should work, although I'm not sure why you can't just give up
> altogether and use the initial mapping from smp_setup_processor_id?
Since I need to either stash the values to avoid reparsing the tree or
at first I just parse to check for correctness, second pass I update the map.
I will stash the reg values, and if the boot CPU MPIDR is correct I will
copy the stashed map to the cpu_logical_map. If that's unacceptable we
will change it.
> > The problem with this approach is that if we need a pointer (phandle) to the
> > boot CPU DT node through the MPIDR and the boot CPU node is botched or missing
> > we still behave as if the DT CPU nodes were ok.
>
> Does any code do this? Wouldn't it be much better to lookup logical CPU 0 if
> you want to find anything out about the boot CPU?
Formulated my point in a horrible way sorry.
In order to retrieve the logical id of a CPU (eg IRQ affinity list) we need
its MPIDR for the reverse look-up and for that to work the reg property in the
/cpu nodes must be correct. Let's gloss over this for now.
> > I think I'd better stick a warning condition in there if the boot CPU
> > node is not present or botched (from a MPIDR perspective at least).
Done, IMHO I wrote some code that is too convoluted, I will post it anyway for
review to get further feeback.
Thanks !!
Lorenzo
^ permalink raw reply
* [RFC PATCH 0/2] Kirkwood 98dx4122 pinctrl variant
From: Andrew Lunn @ 2012-11-07 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352304792-22443-1-git-send-email-valentin.longchamp@keymile.com>
On Wed, Nov 07, 2012 at 05:13:10PM +0100, Valentin Longchamp wrote:
> These two patches add a pinctrl variant for the kirkwood embedded in the
> 98dx4122 SoC. Although it is based on a 6281 kirkwood, a lot of pins and
> functionalities are absent ant that's why a new variant is needed.
>
> These two patches are based on Andrew's v2 pinctrl branch:
>
> git://github.com/lunn/linux.git v3.7-rc2-pinctrl-v2
>
> Valentin Longchamp (2):
> ARM: support 98DX412x kirkwoods with pinctrl
> ARM: convert the km_kirkwood board to pinctrl
>
> .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt | 39 ++
> arch/arm/boot/dts/kirkwood-98dx4122.dtsi | 31 ++
> arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 17 +
> arch/arm/mach-kirkwood/board-km_kirkwood.c | 11 -
> drivers/pinctrl/mvebu/pinctrl-kirkwood.c | 568 ++++++++++----------
> 5 files changed, 377 insertions(+), 289 deletions(-)
> create mode 100644 arch/arm/boot/dts/kirkwood-98dx4122.dtsi
Hi Valentin
Thanks for doing this. It looks great. I will pull them into my
pinctrl tree and if nobody makes any comments see about passing them
up to Jason.
Thanks
Andrew
^ permalink raw reply
* [PATCH 2/5 v3] ARM: AT91SAM9G45: same platform data structure for all crypto peripherals
From: Nicolas Royer @ 2012-11-07 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107164523.GG4576@game.jcrosoft.org>
Only AES use DMA in AT91SAM9G45 (TDES and SHA use PDC).
However latest Atmel TDES and SHA IP releases use DMA instead of PDC.
--> Atmel TDES and SHA drivers need DMA platform data for those IP releases.
Goal of this patch is to use the same platform data structure for all Atmel
crypto peripherals. This structure contains information about DMA interface.
Signed-off-by: Nicolas Royer <nicolas@eukrea.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Eric B?nard <eric@eukrea.com>
Tested-by: Eric B?nard <eric@eukrea.com>
---
v2 : check kzalloc return value.
v3 : alt_atslave structure declared as static.
arch/arm/mach-at91/at91sam9g45_devices.c | 14 ++++++--------
include/linux/platform_data/atmel-aes.h | 22 ----------------------
include/linux/platform_data/crypto-atmel.h | 22 ++++++++++++++++++++++
3 files changed, 28 insertions(+), 30 deletions(-)
delete mode 100644 include/linux/platform_data/atmel-aes.h
create mode 100644 include/linux/platform_data/crypto-atmel.h
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index fcd233c..1501e58 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -18,7 +18,7 @@
#include <linux/platform_device.h>
#include <linux/i2c-gpio.h>
#include <linux/atmel-mci.h>
-#include <linux/platform_data/atmel-aes.h>
+#include <linux/platform_data/crypto-atmel.h>
#include <linux/platform_data/at91_adc.h>
@@ -1900,7 +1900,8 @@ static void __init at91_add_device_tdes(void) {}
* -------------------------------------------------------------------- */
#if defined(CONFIG_CRYPTO_DEV_ATMEL_AES) || defined(CONFIG_CRYPTO_DEV_ATMEL_AES_MODULE)
-static struct aes_platform_data aes_data;
+static struct crypto_platform_data aes_data;
+static struct crypto_dma_data alt_atslave;
static u64 aes_dmamask = DMA_BIT_MASK(32);
static struct resource aes_resources[] = {
@@ -1931,23 +1932,20 @@ static struct platform_device at91sam9g45_aes_device = {
static void __init at91_add_device_aes(void)
{
struct at_dma_slave *atslave;
- struct aes_dma_data *alt_atslave;
-
- alt_atslave = kzalloc(sizeof(struct aes_dma_data), GFP_KERNEL);
/* DMA TX slave channel configuration */
- atslave = &alt_atslave->txdata;
+ atslave = &alt_atslave.txdata;
atslave->dma_dev = &at_hdmac_device.dev;
atslave->cfg = ATC_FIFOCFG_ENOUGHSPACE | ATC_SRC_H2SEL_HW |
ATC_SRC_PER(AT_DMA_ID_AES_RX);
/* DMA RX slave channel configuration */
- atslave = &alt_atslave->rxdata;
+ atslave = &alt_atslave.rxdata;
atslave->dma_dev = &at_hdmac_device.dev;
atslave->cfg = ATC_FIFOCFG_ENOUGHSPACE | ATC_DST_H2SEL_HW |
ATC_DST_PER(AT_DMA_ID_AES_TX);
- aes_data.dma_slave = alt_atslave;
+ aes_data.dma_slave = &alt_atslave;
platform_device_register(&at91sam9g45_aes_device);
}
#else
diff --git a/include/linux/platform_data/atmel-aes.h b/include/linux/platform_data/atmel-aes.h
deleted file mode 100644
index ab68082..0000000
--- a/include/linux/platform_data/atmel-aes.h
+++ /dev/null
@@ -1,22 +0,0 @@
-#ifndef __LINUX_ATMEL_AES_H
-#define __LINUX_ATMEL_AES_H
-
-#include <linux/platform_data/dma-atmel.h>
-
-/**
- * struct aes_dma_data - DMA data for AES
- */
-struct aes_dma_data {
- struct at_dma_slave txdata;
- struct at_dma_slave rxdata;
-};
-
-/**
- * struct aes_platform_data - board-specific AES configuration
- * @dma_slave: DMA slave interface to use in data transfers.
- */
-struct aes_platform_data {
- struct aes_dma_data *dma_slave;
-};
-
-#endif /* __LINUX_ATMEL_AES_H */
diff --git a/include/linux/platform_data/crypto-atmel.h b/include/linux/platform_data/crypto-atmel.h
new file mode 100644
index 0000000..b46e0d9
--- /dev/null
+++ b/include/linux/platform_data/crypto-atmel.h
@@ -0,0 +1,22 @@
+#ifndef __LINUX_CRYPTO_ATMEL_H
+#define __LINUX_CRYPTO_ATMEL_H
+
+#include <linux/platform_data/dma-atmel.h>
+
+/**
+ * struct crypto_dma_data - DMA data for AES/TDES/SHA
+ */
+struct crypto_dma_data {
+ struct at_dma_slave txdata;
+ struct at_dma_slave rxdata;
+};
+
+/**
+ * struct crypto_platform_data - board-specific AES/TDES/SHA configuration
+ * @dma_slave: DMA slave interface to use in data transfers.
+ */
+struct crypto_platform_data {
+ struct crypto_dma_data *dma_slave;
+};
+
+#endif /* __LINUX_CRYPTO_ATMEL_H */
--
1.7.6.5
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Tony Lindgren @ 2012-11-07 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352299344-8011-1-git-send-email-grinberg@compulab.co.il>
* Igor Grinberg <grinberg@compulab.co.il> [121107 06:44]:
> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
> setting.
> To remove the dependancy, several conversions/additions had to be done:
> 1) Timer structures and initialization functions are named by the platform
> name and the clock source in use. The decision which timer is
> used is done statically from the machine_desc structure. In the
> future it should come from DT.
> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
> separate timer structures along with the timer init functions.
> This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
I think this should be the default for the timers as that counter
does not stop during deeper idle states.
> 3) Since we have all the timers defined inside machine_desc structure
> and we no longer need the fallback to gp_timer clock source in case
> 32k_timer clock source is unavailable (namely on AM33xx), we no
> longer need the #ifdef around __omap2_sync32k_clocksource_init()
> function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
> __omap2_sync32k_clocksource_init() function.
>
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
> Finally I'm sending this out...
> I've lost following Tony's branches and deciding which one to base on,
> so I used linux-omap/master as a base for the patch.
> Tony, tell me if you want it based on some other branch.
> This has been compile tested on omap1|2plus_defconfig only.
Yes sorry it's been a bit crazy with branches to get this
header clean up done.. If it applies to master it should
be easy to apply on others.
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
> .handle_irq = omap2_intc_handle_irq,
> .init_machine = omap_2430sdp_init,
> .init_late = omap2430_init_late,
> - .timer = &omap2_timer,
> + .timer = &omap2_sync32k_timer,
> .restart = omap_prcm_restart,
> MACHINE_END
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
> .handle_irq = omap3_intc_handle_irq,
> .init_machine = omap_3430sdp_init,
> .init_late = omap3430_init_late,
> - .timer = &omap3_timer,
> + .timer = &omap3_sync32k_timer,
> .restart = omap_prcm_restart,
> MACHINE_END
...
Can't we assume that the default timer is omap[234]_sync32k_timer to
avoid renaming the timer entries in all the board files?
Then we just need a new timer entries for the hardware that does
not have the sycn32k_timer available?
Regards,
Tony
^ permalink raw reply
* OMAP baseline test results for v3.7-rc4
From: Paul Walmsley @ 2012-11-07 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A96DA.2010003@ti.com>
On Wed, 7 Nov 2012, Jon Hunter wrote:
> On 11/04/2012 08:46 PM, Paul Walmsley wrote:
>
> > * 4460pandaes: boot fails early
> > - Appears to be due to X-loader problems here
> > - Need to note the X-loader version so we know it's broken
>
> Are you still planning to investigate this further or migrate to a new
> bootloader?
Yes. The problem with the current boot setup is that the new
bootloader is breaking as well! :-(
This can be seen by comparing:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/4460pandaes/4460pandaes_log.txt
(the old bootloader)
with
http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/boot/4460pandaes/4460pandaes_log.txt
(the new bootloader)
Dealing with this will require hands-on access, and unfortunately, right
now I am traveling and away from my testbed. Next week, will take a
closer look.
> With 4460 and 3.7-rc4, I am seeing that resume from suspend is not
> working (not sure when this broke though). I am just curious if anyone
> else sees this. My u-boot version is v2012.10.
If you have the chance, it would be useful to know if any of the v3.7-rcs
worked. Otherwise, will look at this next week.
- Paul
^ permalink raw reply
* [PATCH RESEND] ARM/SPI: New driver for SPI master controller for CLPS711X-target
From: Alexander Shiyan @ 2012-11-07 17:30 UTC (permalink / raw)
To: linux-arm-kernel
This patch add new driver for CLPS711X SPI master controller.
Due to platform limitations driver supports only 8 bit transfer mode.
Chip select control is handled via GPIO.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-clps711x.c | 296 ++++++++++++++++++++++++++++
include/linux/platform_data/spi-clps711x.h | 21 ++
4 files changed, 325 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/spi-clps711x.c
create mode 100644 include/linux/platform_data/spi-clps711x.h
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 25290d9..fd95dd8 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -123,6 +123,13 @@ config SPI_BUTTERFLY
inexpensive battery powered microcontroller evaluation board.
This same cable can be used to flash new firmware.
+config SPI_CLPS711X
+ tristate "CLPS711X host SPI controller"
+ depends on ARCH_CLPS711X
+ help
+ This enables dedicated general purpose SPI/Microwire1-compatible
+ master mode interface (SSI1) for CLPS711X-based CPUs.
+
config SPI_COLDFIRE_QSPI
tristate "Freescale Coldfire QSPI controller"
depends on (M520x || M523x || M5249 || M525x || M527x || M528x || M532x)
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index f87c0f1..b6bb740 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SPI_BFIN5XX) += spi-bfin5xx.o
obj-$(CONFIG_SPI_BFIN_SPORT) += spi-bfin-sport.o
obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY) += spi-butterfly.o
+obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
obj-$(CONFIG_SPI_COLDFIRE_QSPI) += spi-coldfire-qspi.o
obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
obj-$(CONFIG_SPI_DESIGNWARE) += spi-dw.o
diff --git a/drivers/spi/spi-clps711x.c b/drivers/spi/spi-clps711x.c
new file mode 100644
index 0000000..59677eb
--- /dev/null
+++ b/drivers/spi/spi-clps711x.c
@@ -0,0 +1,296 @@
+/*
+ * CLPS711X SPI bus driver
+ *
+ * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/init.h>
+#include <linux/gpio.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/platform_data/spi-clps711x.h>
+
+#include <mach/hardware.h>
+
+#define DRIVER_NAME "spi-clps711x"
+
+struct spi_clps711x_data {
+ struct completion done;
+
+ struct clk *spi_clk;
+ u32 max_speed_hz;
+
+ u8 *tx_buf;
+ u8 *rx_buf;
+ int count;
+ int len;
+
+ int chipselect[0];
+};
+
+static int spi_clps711x_setup(struct spi_device *spi)
+{
+ struct spi_clps711x_data *hw = spi_master_get_devdata(spi->master);
+
+ if (spi->bits_per_word != 8) {
+ dev_err(&spi->dev, "Unsupported master bus width %i\n",
+ spi->bits_per_word);
+ return -EINVAL;
+ }
+
+ /* We are expect that SPI-device is not selected */
+ gpio_direction_output(hw->chipselect[spi->chip_select],
+ !(spi->mode & SPI_CS_HIGH));
+
+ return 0;
+}
+
+static void spi_clps711x_setup_mode(struct spi_device *spi)
+{
+ /* Setup edge for transfer */
+ if (spi->mode & SPI_CPHA)
+ clps_writew(clps_readw(SYSCON3) | SYSCON3_ADCCKNSEN, SYSCON3);
+ else
+ clps_writew(clps_readw(SYSCON3) & ~SYSCON3_ADCCKNSEN, SYSCON3);
+}
+
+static int spi_clps711x_setup_xfer(struct spi_device *spi,
+ struct spi_transfer *xfer)
+{
+ u32 speed = xfer->speed_hz ? : spi->max_speed_hz;
+ u8 bpw = xfer->bits_per_word ? : spi->bits_per_word;
+ struct spi_clps711x_data *hw = spi_master_get_devdata(spi->master);
+
+ if (bpw != 8) {
+ dev_err(&spi->dev, "Unsupported master bus width %i\n", bpw);
+ return -EINVAL;
+ }
+
+ /* Setup SPI frequency divider */
+ if (!speed || (speed >= hw->max_speed_hz))
+ clps_writel((clps_readl(SYSCON1) & ~SYSCON1_ADCKSEL_MASK) |
+ SYSCON1_ADCKSEL(3), SYSCON1);
+ else if (speed >= (hw->max_speed_hz / 2))
+ clps_writel((clps_readl(SYSCON1) & ~SYSCON1_ADCKSEL_MASK) |
+ SYSCON1_ADCKSEL(2), SYSCON1);
+ else if (speed >= (hw->max_speed_hz / 8))
+ clps_writel((clps_readl(SYSCON1) & ~SYSCON1_ADCKSEL_MASK) |
+ SYSCON1_ADCKSEL(1), SYSCON1);
+ else
+ clps_writel((clps_readl(SYSCON1) & ~SYSCON1_ADCKSEL_MASK) |
+ SYSCON1_ADCKSEL(0), SYSCON1);
+
+ return 0;
+}
+
+static int spi_clps711x_transfer_one_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct spi_clps711x_data *hw = spi_master_get_devdata(master);
+ struct spi_transfer *xfer;
+ int status = 0, cs = hw->chipselect[msg->spi->chip_select];
+ u32 data;
+
+ spi_clps711x_setup_mode(msg->spi);
+
+ list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+ if (spi_clps711x_setup_xfer(msg->spi, xfer)) {
+ status = -EINVAL;
+ goto out_xfr;
+ }
+
+ gpio_set_value(cs, !!(msg->spi->mode & SPI_CS_HIGH));
+
+ INIT_COMPLETION(hw->done);
+
+ hw->count = 0;
+ hw->len = xfer->len;
+ hw->tx_buf = (u8 *)xfer->tx_buf;
+ hw->rx_buf = (u8 *)xfer->rx_buf;
+
+ /* Initiate transfer */
+ data = hw->tx_buf ? hw->tx_buf[hw->count] : 0;
+ clps_writel(data | SYNCIO_FRMLEN(8) | SYNCIO_TXFRMEN, SYNCIO);
+
+ wait_for_completion(&hw->done);
+
+ if (xfer->delay_usecs)
+ udelay(xfer->delay_usecs);
+
+ if (xfer->cs_change ||
+ list_is_last(&xfer->transfer_list, &msg->transfers))
+ gpio_set_value(cs, !(msg->spi->mode & SPI_CS_HIGH));
+
+ msg->actual_length += xfer->len;
+ }
+
+out_xfr:
+ msg->status = status;
+ spi_finalize_current_message(master);
+
+ return 0;
+}
+
+static irqreturn_t spi_clps711x_isr(int irq, void *dev_id)
+{
+ struct spi_clps711x_data *hw = (struct spi_clps711x_data *)dev_id;
+ u32 data;
+
+ /* Handle RX */
+ data = clps_readb(SYNCIO);
+ if (hw->rx_buf)
+ hw->rx_buf[hw->count] = (u8)data;
+
+ hw->count++;
+
+ /* Handle TX */
+ if (hw->count < hw->len) {
+ data = hw->tx_buf ? hw->tx_buf[hw->count] : 0;
+ clps_writel(data | SYNCIO_FRMLEN(8) | SYNCIO_TXFRMEN, SYNCIO);
+ } else
+ complete(&hw->done);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit spi_clps711x_probe(struct platform_device *pdev)
+{
+ int i, ret;
+ struct spi_master *master;
+ struct spi_clps711x_data *hw;
+ struct spi_clps711x_pdata *pdata = dev_get_platdata(&pdev->dev);
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platform data supplied\n");
+ return -EINVAL;
+ }
+
+ if (pdata->num_chipselect < 1) {
+ dev_err(&pdev->dev, "At least one CS must be defined\n");
+ return -EINVAL;
+ }
+
+ master = spi_alloc_master(&pdev->dev,
+ sizeof(struct spi_clps711x_data) +
+ sizeof(int) * pdata->num_chipselect);
+ if (!master) {
+ dev_err(&pdev->dev, "SPI allocating memory error\n");
+ return -ENOMEM;
+ }
+
+ master->bus_num = pdev->id;
+ master->mode_bits = SPI_CPHA | SPI_CS_HIGH;
+ master->num_chipselect = pdata->num_chipselect;
+ master->setup = spi_clps711x_setup;
+ master->transfer_one_message = spi_clps711x_transfer_one_message;
+
+ hw = spi_master_get_devdata(master);
+
+ for (i = 0; i < master->num_chipselect; i++) {
+ hw->chipselect[i] = pdata->chipselect[i];
+ if (!gpio_is_valid(hw->chipselect[i])) {
+ dev_err(&pdev->dev, "Invalid CS GPIO %i\n", i);
+ ret = -EINVAL;
+ goto err_out;
+ }
+ if (gpio_request(hw->chipselect[i], DRIVER_NAME)) {
+ dev_err(&pdev->dev, "Can't get CS GPIO %i\n", i);
+ ret = -EINVAL;
+ goto err_out;
+ }
+ }
+
+ hw->spi_clk = devm_clk_get(&pdev->dev, "spi");
+ if (IS_ERR(hw->spi_clk)) {
+ dev_err(&pdev->dev, "Can't get clocks\n");
+ ret = PTR_ERR(hw->spi_clk);
+ goto err_out;
+ }
+ hw->max_speed_hz = clk_get_rate(hw->spi_clk);
+
+ init_completion(&hw->done);
+ platform_set_drvdata(pdev, master);
+
+ /* Disable extended mode due hardware problems */
+ clps_writew(clps_readw(SYSCON3) & ~SYSCON3_ADCCON, SYSCON3);
+
+ /* Clear possible pending interrupt */
+ clps_readl(SYNCIO);
+
+ ret = devm_request_irq(&pdev->dev, IRQ_SSEOTI, spi_clps711x_isr, 0,
+ dev_name(&pdev->dev), hw);
+ if (ret) {
+ dev_err(&pdev->dev, "Can't request IRQ\n");
+ clk_put(hw->spi_clk);
+ goto clk_out;
+ }
+
+ ret = spi_register_master(master);
+ if (!ret) {
+ dev_info(&pdev->dev,
+ "SPI bus driver initialized. Master clock %u Hz\n",
+ hw->max_speed_hz);
+ return 0;
+ }
+
+ dev_err(&pdev->dev, "Failed to register master\n");
+ devm_free_irq(&pdev->dev, IRQ_SSEOTI, hw);
+
+clk_out:
+ devm_clk_put(&pdev->dev, hw->spi_clk);
+
+err_out:
+ while (--i >= 0)
+ if (gpio_is_valid(hw->chipselect[i]))
+ gpio_free(hw->chipselect[i]);
+
+ platform_set_drvdata(pdev, NULL);
+ spi_master_put(master);
+ kfree(master);
+
+ return ret;
+}
+
+static int __devexit spi_clps711x_remove(struct platform_device *pdev)
+{
+ int i;
+ struct spi_master *master = platform_get_drvdata(pdev);
+ struct spi_clps711x_data *hw = spi_master_get_devdata(master);
+
+ devm_free_irq(&pdev->dev, IRQ_SSEOTI, hw);
+
+ for (i = 0; i < master->num_chipselect; i++)
+ if (gpio_is_valid(hw->chipselect[i]))
+ gpio_free(hw->chipselect[i]);
+
+ devm_clk_put(&pdev->dev, hw->spi_clk);
+ platform_set_drvdata(pdev, NULL);
+ spi_unregister_master(master);
+ kfree(master);
+
+ return 0;
+}
+
+static struct platform_driver clps711x_spi_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = spi_clps711x_probe,
+ .remove = __devexit_p(spi_clps711x_remove),
+};
+module_platform_driver(clps711x_spi_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alexander Shiyan <shc_work@mail.ru>");
+MODULE_DESCRIPTION("CLPS711X SPI bus driver");
diff --git a/include/linux/platform_data/spi-clps711x.h b/include/linux/platform_data/spi-clps711x.h
new file mode 100644
index 0000000..301956e
--- /dev/null
+++ b/include/linux/platform_data/spi-clps711x.h
@@ -0,0 +1,21 @@
+/*
+ * CLPS711X SPI bus driver definitions
+ *
+ * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef ____LINUX_PLATFORM_DATA_SPI_CLPS711X_H
+#define ____LINUX_PLATFORM_DATA_SPI_CLPS711X_H
+
+/* Board specific platform_data */
+struct spi_clps711x_pdata {
+ int *chipselect; /* Array of GPIO-numbers */
+ int num_chipselect; /* Total count of GPIOs */
+};
+
+#endif
--
1.7.8.6
^ permalink raw reply related
* [PATCH] pwm: lpc32xx - Add a driver for the motor PWM
From: Roland Stigge @ 2012-11-07 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352305828-25298-1-git-send-email-alban.bedel@avionic-design.de>
On 07/11/12 17:30, Alban Bedel wrote:
> Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
> ---
> .../devicetree/bindings/pwm/lpc32xx-motor-pwm.txt | 24 ++
> arch/arm/boot/dts/lpc32xx.dtsi | 7 +
Is all this supposed to go via mach-lpc32xx -> arm-soc.git? Then, I can
take this into the lpc32xx tree. Otherwise, you can split off the .dtsi
file and I include it via lpc32xx.
Thanks,
Roland
> drivers/pwm/Kconfig | 10 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-lpc32xx-motor.c | 230 ++++++++++++++++++++
> 5 files changed, 272 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pwm/lpc32xx-motor-pwm.txt
> create mode 100644 drivers/pwm/pwm-lpc32xx-motor.c
>
> diff --git a/Documentation/devicetree/bindings/pwm/lpc32xx-motor-pwm.txt b/Documentation/devicetree/bindings/pwm/lpc32xx-motor-pwm.txt
> new file mode 100644
> index 0000000..e19b0a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/lpc32xx-motor-pwm.txt
> @@ -0,0 +1,24 @@
> +LPC32XX Motor PWM controller
> +
> +The LPC32xx motor PWMs have two output pin, A and B, with B=!A.
> +Per default the output A should be used, if the output B is used the
> +PWM polarity should be inverted using the linux,polarity property.
> +
> +Required properties:
> +- compatible: should be "nxp,lpc3220-motor-pwm"
> +- reg: physical base address and length of the controller's registers
> +
> +Optional properites:
> +- linux,polarity: Bit mask of the polarity to use for each output,
> + a bit set to 0 indicate the default polarity, a bit set to 1
> + indicate an inverted polarity. In other word this set if output
> + A or output B has the correct polarity.
> +
> +Examples:
> +
> +mpwm at 400e8000 {
> + compatible = "nxp,lpc3220-motor-pwm";
> + reg = <0x400E8000 0x78>;
> + linux,polarity = 5; /* Use outputs B0, A1 and B2 */
> + #pwm-cells = <2>;
> +};
> diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
> index ef0fdc7..a1e6a9b 100644
> --- a/arch/arm/boot/dts/lpc32xx.dtsi
> +++ b/arch/arm/boot/dts/lpc32xx.dtsi
> @@ -182,6 +182,13 @@
> pnx,timeout = <0x64>;
> };
>
> + mpwm: mpwm at 400E8000 {
> + compatible = "nxp,lpc3220-motor-pwm";
> + reg = <0x400E8000 0x78>;
> + status = "disabled";
> + #pwm-cells = <2>;
> + };
> +
> i2cusb: i2c at 31020300 {
> compatible = "nxp,pnx-i2c";
> reg = <0x31020300 0x100>;
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 90c5c73..90fc167 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -57,6 +57,16 @@ config PWM_LPC32XX
> To compile this driver as a module, choose M here: the module
> will be called pwm-lpc32xx.
>
> +config PWM_LPC32XX_MOTOR
> + tristate "LPC32XX Motor PWM support"
> + depends on ARCH_LPC32XX
> + help
> + Generic PWM framework driver for LPC32XX motor PWM. The LPC32XX SOC
> + has one motor PWM controllers.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-motor-lpc32xx.
> +
> config PWM_MXS
> tristate "Freescale MXS PWM support"
> depends on ARCH_MXS && OF
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index e4b2c89..510bad8 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -2,6 +2,7 @@ obj-$(CONFIG_PWM) += core.o
> obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
> obj-$(CONFIG_PWM_IMX) += pwm-imx.o
> obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
> +obj-$(CONFIG_PWM_LPC32XX_MOTOR) += pwm-lpc32xx-motor.o
> obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
> obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
> obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
> diff --git a/drivers/pwm/pwm-lpc32xx-motor.c b/drivers/pwm/pwm-lpc32xx-motor.c
> new file mode 100644
> index 0000000..e1b4d46
> --- /dev/null
> +++ b/drivers/pwm/pwm-lpc32xx-motor.c
> @@ -0,0 +1,230 @@
> +/*
> + * Copyright 2012 Alban Bedel <alban.bedel@avionic-design.de>
> + *
> + * Based on pwm-lpc32xx.c from Alexandre Pereira da Silva
> + * <aletes.xgr@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2.
> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/slab.h>
> +
> +struct lpc32xx_motor_pwm_chip {
> + struct pwm_chip chip;
> + struct clk *clk;
> + spinlock_t lock;
> + unsigned int clk_enabled;
> + unsigned int pins;
> + void __iomem *base;
> +};
> +
> +#define to_lpc32xx_motor_pwm_chip(_chip) \
> + container_of(_chip, struct lpc32xx_motor_pwm_chip, chip)
> +
> +/* Register mapping for MCPWM modules */
> +#define LPC32XX_MCPWM_MCCON 0x00
> +#define LPC32XX_MCPWM_MCCON_SET 0x04
> +#define LPC32XX_MCPWM_MCCON_CLR 0x08
> +#define LPC32XX_MCPWM_MCCAPCON 0x0C
> +#define LPC32XX_MCPWM_MCCAPCON_SET 0x10
> +#define LPC32XX_MCPWM_MCCAPCON_CLR 0x14
> +#define LPC32XX_MCPWM_MCLIM0 0x24
> +#define LPC32XX_MCPWM_MCLIM1 0x28
> +#define LPC32XX_MCPWM_MCLIM2 0x2C
> +#define LPC32XX_MCPWM_MCMAT0 0x30
> +#define LPC32XX_MCPWM_MCMAT1 0x34
> +#define LPC32XX_MCPWM_MCMAT2 0x38
> +#define LPC32XX_MCPWM_MCINTEN_CLR 0x58
> +
> +#define LPC32XX_MCPWM_COUNT 3
> +
> +#define PWM_EN_MASK(pwm) BIT(0 + (pwm)->hwpwm*8)
> +#define MCLIM_REG_OFFSET(pwm) (LPC32XX_MCPWM_MCLIM0 + (pwm)->hwpwm*4)
> +#define MCMAT_REG_OFFSET(pwm) (LPC32XX_MCPWM_MCMAT0 + (pwm)->hwpwm*4)
> +
> +static int lpc32xx_motor_pwm_enable_clock(
> + struct lpc32xx_motor_pwm_chip *lpc32xx)
> +{
> + int err = 0;
> + spin_lock(&lpc32xx->lock);
> + if (lpc32xx->clk_enabled == 0)
> + err = clk_enable(lpc32xx->clk);
> + lpc32xx->clk_enabled += 1;
> + spin_unlock(&lpc32xx->lock);
> + return err;
> +}
> +
> +static void lpc32xx_motor_pwm_disable_clock(
> + struct lpc32xx_motor_pwm_chip *lpc32xx)
> +{
> + spin_lock(&lpc32xx->lock);
> + if (lpc32xx->clk_enabled > 0) {
> + lpc32xx->clk_enabled -= 1;
> + if (lpc32xx->clk_enabled == 0)
> + clk_disable(lpc32xx->clk);
> + }
> + spin_unlock(&lpc32xx->lock);
> +}
> +
> +static int lpc32xx_motor_pwm_config(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> +{
> + struct lpc32xx_motor_pwm_chip *lpc32xx =
> + to_lpc32xx_motor_pwm_chip(chip);
> + u64 rate, per, duty;
> + int err = 0;
> +
> + /* The clock is needed to access the registers */
> + err = lpc32xx_motor_pwm_enable_clock(lpc32xx);
> + if (err)
> + return err;
> +
> + /* Calculate period */
> + rate = clk_get_rate(lpc32xx->clk);
> + per = (u64)period_ns * rate;
> + duty = (u64)duty_ns * rate;
> + do_div(per, 1000000000);
> + do_div(duty, 1000000000);
> +
> + /* Write to limit register -> period */
> + __raw_writel(per, lpc32xx->base + MCLIM_REG_OFFSET(pwm));
> +
> + /* Write to match register -> duty */
> + __raw_writel(per - duty, lpc32xx->base + MCMAT_REG_OFFSET(pwm));
> +
> + /* Disable the clock now that we are done */
> + lpc32xx_motor_pwm_disable_clock(lpc32xx);
> + return 0;
> +}
> +
> +static int lpc32xx_motor_pwm_enable(struct pwm_chip *chip,
> + struct pwm_device *pwm)
> +{
> + struct lpc32xx_motor_pwm_chip *lpc32xx =
> + to_lpc32xx_motor_pwm_chip(chip);
> + int err;
> +
> + err = lpc32xx_motor_pwm_enable_clock(lpc32xx);
> + if (err)
> + return err;
> +
> + __raw_writel(PWM_EN_MASK(pwm), lpc32xx->base + LPC32XX_MCPWM_MCCON_SET);
> +
> + return 0;
> +}
> +
> +static void lpc32xx_motor_pwm_disable(struct pwm_chip *chip,
> + struct pwm_device *pwm)
> +{
> + struct lpc32xx_motor_pwm_chip *lpc32xx =
> + to_lpc32xx_motor_pwm_chip(chip);
> +
> + __raw_writel(PWM_EN_MASK(pwm), lpc32xx->base + LPC32XX_MCPWM_MCCON_CLR);
> +
> + lpc32xx_motor_pwm_disable_clock(lpc32xx);
> +}
> +
> +static const struct pwm_ops lpc32xx_motor_pwm_ops = {
> + .config = lpc32xx_motor_pwm_config,
> + .enable = lpc32xx_motor_pwm_enable,
> + .disable = lpc32xx_motor_pwm_disable,
> + .owner = THIS_MODULE,
> +};
> +
> +static int lpc32xx_motor_pwm_probe(struct platform_device *pdev)
> +{
> + struct lpc32xx_motor_pwm_chip *lpc32xx;
> + struct resource *res;
> + int ret;
> +
> + lpc32xx = devm_kzalloc(&pdev->dev, sizeof(*lpc32xx), GFP_KERNEL);
> + if (!lpc32xx)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + lpc32xx->base = devm_request_and_ioremap(&pdev->dev, res);
> + if (!lpc32xx->base)
> + return -EADDRNOTAVAIL;
> +
> + lpc32xx->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(lpc32xx->clk))
> + return PTR_ERR(lpc32xx->clk);
> +
> + spin_lock_init(&lpc32xx->lock);
> +
> + /* Configure the pins polarity */
> + ret = of_property_read_u32(pdev->dev.of_node, "linux,polarity",
> + &lpc32xx->pins);
> + if (!ret) {
> + u32 set = 0, clr = 0;
> + int i;
> + for (i = 0 ; i < LPC32XX_MCPWM_COUNT ; i += 1)
> + if (lpc32xx->pins & BIT(i))
> + set |= BIT(2 + i*8);
> + else
> + clr |= BIT(2 + i*8);
> + __raw_writel(set, lpc32xx->base + LPC32XX_MCPWM_MCCON_SET);
> + __raw_writel(clr, lpc32xx->base + LPC32XX_MCPWM_MCCON_CLR);
> + }
> +
> + lpc32xx->chip.dev = &pdev->dev;
> + lpc32xx->chip.ops = &lpc32xx_motor_pwm_ops;
> + lpc32xx->chip.npwm = LPC32XX_MCPWM_COUNT;
> + lpc32xx->chip.base = -1;
> +
> + ret = pwmchip_add(&lpc32xx->chip);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to add PWM chip, error %d\n", ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, lpc32xx);
> +
> + return 0;
> +}
> +
> +static int __devexit lpc32xx_motor_pwm_remove(struct platform_device *pdev)
> +{
> + struct lpc32xx_motor_pwm_chip *lpc32xx = platform_get_drvdata(pdev);
> +
> + clk_disable(lpc32xx->clk);
> + return pwmchip_remove(&lpc32xx->chip);
> +}
> +
> +static const struct of_device_id lpc32xx_motor_pwm_dt_ids[] __devinitconst = {
> + { .compatible = "nxp,lpc3220-motor-pwm", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, lpc32xx_motor_pwm_dt_ids);
> +
> +static struct platform_driver lpc32xx_motor_pwm_driver = {
> + .driver = {
> + .name = "lpc32xx-motor-pwm",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(lpc32xx_motor_pwm_dt_ids),
> + },
> + .probe = lpc32xx_motor_pwm_probe,
> + .remove = __devexit_p(lpc32xx_motor_pwm_remove),
> +};
> +module_platform_driver(lpc32xx_motor_pwm_driver);
> +
> +MODULE_ALIAS("platform:lpc32xx-motor-pwm");
> +MODULE_AUTHOR("Alban Bedel <alban.bedel@avionic-design.de>");
> +MODULE_DESCRIPTION("LPC32XX Motor PWM Driver");
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply
* gic_set_affinity
From: Robert Beckett @ 2012-11-07 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107171359.GB15349@mudshark.cambridge.arm.com>
On 7 November 2012 17:13, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Nov 07, 2012 at 05:08:36PM +0000, Robert Beckett wrote:
>> On 5 November 2012 12:05, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Nov 02, 2012 at 11:32:50AM +0000, Robert Beckett wrote:
>> >> (CC maintainers)
>> >>
>> >> On 1 November 2012 17:54, Robert Beckett <bob.beckett@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > I was looking through the arm gic code while debugging a problem I am
>> >> > having, and noticed something in gic_set_affinity.
>> >> >
>> >> > When something comes along and setts an irq affinity mask (e.g.
>> >> > through /proc/irq/<irq>/smp_affinity_mask), the calls goes like so :
>> >> >
>> >> > ...
>> >> > 1. irq_set_affinity : grabs the desc->lock
>> >> > 2. __irq_set_affinity_locked : calls chip->irq_set_affinity
>> >> > 3. gic_set_affinity : writes a new mask to the gic distributor
>> >> >
>> >> > my question is, what happens if an interrupt is raised between 1 and 3?
>> >> > To me, it looks like the interrupt could end up being handled on 2
>> >> > cpus. When it is raised, the handler will be called and sit spinning
>> >> > for desc->lock (e.g. in handle_fasteoi_irq). The mask will be set to
>> >> > set the affinity to the new cpu, the new cpu will receive the
>> >> > interrupt as it has not been ackd or disabled yet
>> >
>> > The interrupt will have been acked in gic_handle_irq before the flow handler
>> > is invoked, so it will transition to the active state and will not get
>> > signalled to another CPU. Since we never set more than one target CPU at the
>> > distributor level, the interrupt will only be forwarded to one CPU interface
>> > at any given time.
>> >
>> > Will
>>
>> Thanks for the response,
>>
>> I cant see anything in gic_handle_irq that would ack the interrupt
>> (unless it is an IPI interrupt).
>> For irqnr > 15, it just calls handle_IRQ, which would call the desc
>> handler, which would sit and wait on the desc->lock at the top of
>> handle_fasteoi_irq.
>> Which code are you referring to that is meant to ack the interrupt?
>
> Reading the interrupt ID signifies an ACK in GIC terminology:
>
> irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
>
> Will
Ah, I see. I hadnt realised that is was an ack on read (yuck!)
Thanks for clearing it up for me.
Bob
^ permalink raw reply
* [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
From: Kevin Hilman @ 2012-11-07 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC085EE@DBDE01.ent.ti.com>
"Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
> Hi Kevin,
>
> On Wed, Nov 07, 2012 at 06:36:06, Kevin Hilman wrote:
>> "Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
>>
>> > On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
>>
>> [...]
>>
>> >>
>> >> Also, if there are drivers for these devices, won't this interfere?
>> >>
>> >
>> > Hmm, I can think of the following scenarios
>> >
>> > 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that
>> > in their suspend callbacks they end up doing omap_hwmod_idle() via the
>> > runtime PM APIs.
>>
>> That already happens for all omap_devices.
>>
>> > In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is
>> > not necessary in the PM code.
>>
>> Correct.
>>
>> > 2. The drivers are not compiled in - In this case, the hwmod code puts
>> > the IPs in standby during bootup so the first suspend-resume iteration
>> > will pass. During resuming, the SYSC configuration for forced standby will
>> > be lost,
>>
>> Please clarify how the SYSC is lost in this case.
>
> The register configuration of IPs in the PER domain is lost when we enter
> the suspend state. So the forced standby configuration from SYSC is lost
> and we need to do this for every successful suspend-resume cycle.
>
>>
>> > so in the subsequent iterations these IPs won't go standby and the
>> > hwmod code does not touch them since they never got enabled. In this case
>> > we do need the sequence that is there currently.
>> >
>> > 3. For some reason the respective drivers don't idle the IPs during suspend -
>> > (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think
>> > we should abort the suspend process since we know that the suspend is not
>> > going to work.
>>
>> Agreed.
>>
>> > Is there some other scenario that needs to be covered?
>>
>> You covered the ones I was thinking of.
>>
>> > How about adding some flag in hwmod code for handling this? Something
>> > similar to what was done for MMC [1]. I think the problem that we have
>> > is in some ways similar to the one addressed in [1].
>>
>> Except that in the absence of drivers, no hwmod code is executed on the
>> suspend/resume path.
>>
>
> We could perhaps add a couple of APIs to check the SYSC values when coming
> out of suspend and take appropriate action if the sysc cache does not match?
Yes, for IPs with only SW support and no drivers, we may need something
like this. But again, it needs to be suspend and idle aware, not just
suspend.
Kevin
^ permalink raw reply
* OMAP baseline test results for v3.7-rc4
From: Jon Hunter @ 2012-11-07 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211050241410.23228@utopia.booyaka.com>
On 11/04/2012 08:46 PM, Paul Walmsley wrote:
>
> Here are some basic OMAP test results for Linux v3.7-rc4.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc4/20121104142910/
>
>
> Passing tests
> -------------
>
> Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
> 4430es2panda, 5912osk, am335xbone
>
> PM ret/off, suspend + dynamic idle: (none)
>
>
> Failing tests: fixed by posted patches
> --------------------------------------
>
> Boot tests:
>
> * 2430sdp: vfp_reload_hw oops during MMC initialization
> - Kernel attempts to save FP registers that don't exist; fix posted:
> - http://www.spinics.net/lists/arm-kernel/msg200646.html
> - added to rmk's patch system as 7566/1
>
> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> - Due to GPMC missing support for DT
> - Temporary workaround at
> http://www.spinics.net/lists/arm-kernel/msg200787.html
> - May be fixed now, pending retest:
> - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> - Not yet part of the automated test suite
> * May be due to an old U-boot with FDT support problems?
>
> PM tests:
>
> * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend
> - Causes MMC to become unusable since regulators are not reenabled
> - Caused by RT throttling
> - Fixed by http://www.spinics.net/lists/arm-kernel/msg202224.html
> - Patch in rmk's patch system as 7565/1
>
> * 3530es3beagle: hangs during off-mode dynamic idle test
> - Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c:
> - http://marc.info/?l=linux-omap&m=135075364705188&w=2
> - Fixed by http://www.spinics.net/lists/arm-kernel/msg202116.html
>
> Other:
>
> * 2420N800: powers down 30 seconds after boot
> - Presumably due to missing CBUS patches for watchdog control
> - http://lkml.org/lkml/2012/9/3/265
>
> * 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3)
> - clock source is from an external I2C-controlled source
> - must skip reset until the switchover to hwmod late init
> - http://www.spinics.net/lists/arm-kernel/msg178138.html
>
>
> Failing tests: needing investigation
> ------------------------------------
>
> Boot tests:
>
> * CM-T3517: L3 in-band error with IPSS during boot
> - Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
> - Longstanding issue; does not occur on the 3517EVM
>
> * 3517EVM & CM-T3517: boot hangs with NFS root
> - Likely some Kconfig, board file, and PM issues with EMAC
>
> * CM-T3517: boot hangs with MMC boot
> - Due to missing MMC setup in board file
>
> * 4460pandaes: boot fails early
> - Appears to be due to X-loader problems here
> - Need to note the X-loader version so we know it's broken
Are you still planning to investigate this further or migrate to a new
bootloader?
With 4460 and 3.7-rc4, I am seeing that resume from suspend is not
working (not sure when this broke though). I am just curious if anyone
else sees this. My u-boot version is v2012.10.
Cheers
Jon
^ permalink raw reply
* gic_set_affinity
From: Will Deacon @ 2012-11-07 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOmFF10qn=JaNmjpkR3GjZ1dp2MVXqdxT=pdPrbPTijCejf79A@mail.gmail.com>
On Wed, Nov 07, 2012 at 05:08:36PM +0000, Robert Beckett wrote:
> On 5 November 2012 12:05, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Nov 02, 2012 at 11:32:50AM +0000, Robert Beckett wrote:
> >> (CC maintainers)
> >>
> >> On 1 November 2012 17:54, Robert Beckett <bob.beckett@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I was looking through the arm gic code while debugging a problem I am
> >> > having, and noticed something in gic_set_affinity.
> >> >
> >> > When something comes along and setts an irq affinity mask (e.g.
> >> > through /proc/irq/<irq>/smp_affinity_mask), the calls goes like so :
> >> >
> >> > ...
> >> > 1. irq_set_affinity : grabs the desc->lock
> >> > 2. __irq_set_affinity_locked : calls chip->irq_set_affinity
> >> > 3. gic_set_affinity : writes a new mask to the gic distributor
> >> >
> >> > my question is, what happens if an interrupt is raised between 1 and 3?
> >> > To me, it looks like the interrupt could end up being handled on 2
> >> > cpus. When it is raised, the handler will be called and sit spinning
> >> > for desc->lock (e.g. in handle_fasteoi_irq). The mask will be set to
> >> > set the affinity to the new cpu, the new cpu will receive the
> >> > interrupt as it has not been ackd or disabled yet
> >
> > The interrupt will have been acked in gic_handle_irq before the flow handler
> > is invoked, so it will transition to the active state and will not get
> > signalled to another CPU. Since we never set more than one target CPU at the
> > distributor level, the interrupt will only be forwarded to one CPU interface
> > at any given time.
> >
> > Will
>
> Thanks for the response,
>
> I cant see anything in gic_handle_irq that would ack the interrupt
> (unless it is an IPI interrupt).
> For irqnr > 15, it just calls handle_IRQ, which would call the desc
> handler, which would sit and wait on the desc->lock at the top of
> handle_fasteoi_irq.
> Which code are you referring to that is meant to ack the interrupt?
Reading the interrupt ID signifies an ACK in GIC terminology:
irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
Will
^ permalink raw reply
* [PATCH 2/5 v2] ARM: AT91SAM9G45: same platform data structure for all crypto peripherals
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-07 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107175946.01f9dc78@eb-e6520>
On 17:59 Wed 07 Nov , Eric B?nard wrote:
> Hi Jean-Christophe,
>
> Le Wed, 7 Nov 2012 17:45:23 +0100,
> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> a ?crit :
> > > @@ -1900,7 +1900,7 @@ static void __init at91_add_device_tdes(void) {}
> > > * -------------------------------------------------------------------- */
> > >
> > > #if defined(CONFIG_CRYPTO_DEV_ATMEL_AES) || defined(CONFIG_CRYPTO_DEV_ATMEL_AES_MODULE)
> > > -static struct aes_platform_data aes_data;
> > > +static struct crypto_platform_data aes_data;
> > > static u64 aes_dmamask = DMA_BIT_MASK(32);
> > >
> > > static struct resource aes_resources[] = {
> > > @@ -1931,9 +1931,11 @@ static struct platform_device at91sam9g45_aes_device = {
> > > static void __init at91_add_device_aes(void)
> > > {
> > > struct at_dma_slave *atslave;
> > > - struct aes_dma_data *alt_atslave;
> > > + struct crypto_dma_data *alt_atslave;
> > >
> > > - alt_atslave = kzalloc(sizeof(struct aes_dma_data), GFP_KERNEL);
> > > + alt_atslave = kzalloc(sizeof(struct crypto_dma_data), GFP_KERNEL);
> > I still not understand why we need to allocate it
> >
> > just declare it as static
> >
> last time we had some data static and you asked to alloc them (and
> didn't bother to answer why you required that :
> http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/02779.html ), now
> you ask to declare static something which is allocated (and
> that's already done this way for the mci) : may you please explain why
> so that we get it the right way for next time ?
in the driver yes we write multi instance and generic code but in the platfrom I do not see why
Best Regards,
J.
^ permalink raw reply
* gic_set_affinity
From: Robert Beckett @ 2012-11-07 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105120548.GH3351@mudshark.cambridge.arm.com>
On 5 November 2012 12:05, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Nov 02, 2012 at 11:32:50AM +0000, Robert Beckett wrote:
>> (CC maintainers)
>>
>> On 1 November 2012 17:54, Robert Beckett <bob.beckett@gmail.com> wrote:
>> > Hello,
>> >
>> > I was looking through the arm gic code while debugging a problem I am
>> > having, and noticed something in gic_set_affinity.
>> >
>> > When something comes along and setts an irq affinity mask (e.g.
>> > through /proc/irq/<irq>/smp_affinity_mask), the calls goes like so :
>> >
>> > ...
>> > 1. irq_set_affinity : grabs the desc->lock
>> > 2. __irq_set_affinity_locked : calls chip->irq_set_affinity
>> > 3. gic_set_affinity : writes a new mask to the gic distributor
>> >
>> > my question is, what happens if an interrupt is raised between 1 and 3?
>> > To me, it looks like the interrupt could end up being handled on 2
>> > cpus. When it is raised, the handler will be called and sit spinning
>> > for desc->lock (e.g. in handle_fasteoi_irq). The mask will be set to
>> > set the affinity to the new cpu, the new cpu will receive the
>> > interrupt as it has not been ackd or disabled yet
>
> The interrupt will have been acked in gic_handle_irq before the flow handler
> is invoked, so it will transition to the active state and will not get
> signalled to another CPU. Since we never set more than one target CPU at the
> distributor level, the interrupt will only be forwarded to one CPU interface
> at any given time.
>
> Will
Thanks for the response,
I cant see anything in gic_handle_irq that would ack the interrupt
(unless it is an IPI interrupt).
For irqnr > 15, it just calls handle_IRQ, which would call the desc
handler, which would sit and wait on the desc->lock at the top of
handle_fasteoi_irq.
Which code are you referring to that is meant to ack the interrupt?
Bob
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Tony Lindgren @ 2012-11-07 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211071655000.20704@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121107 08:57]:
> On Wed, 7 Nov 2012, Paul Walmsley wrote:
>
> > On Tue, 6 Nov 2012, Tony Lindgren wrote:
> >
> > > I'm getting errors with the allnoconfig ones, there are total four
> > > omap defconfigs there not counting the randconfigs.
> >
> > That might indeed explain the discrepancy; so far only have been building
> > his oldconfig seeds here. Will add his allnoconfig seeds and test again.
>
> Can reproduce this here. Thanks for catching this. Will fix and send a
> new pull request today and ensure that the two allnoconfigs are added to
> the build tests from now on.
OK thanks!
Tony
^ permalink raw reply
* [PATCH 2/5 v2] ARM: AT91SAM9G45: same platform data structure for all crypto peripherals
From: Eric Bénard @ 2012-11-07 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107164523.GG4576@game.jcrosoft.org>
Hi Jean-Christophe,
Le Wed, 7 Nov 2012 17:45:23 +0100,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> a ?crit :
> > @@ -1900,7 +1900,7 @@ static void __init at91_add_device_tdes(void) {}
> > * -------------------------------------------------------------------- */
> >
> > #if defined(CONFIG_CRYPTO_DEV_ATMEL_AES) || defined(CONFIG_CRYPTO_DEV_ATMEL_AES_MODULE)
> > -static struct aes_platform_data aes_data;
> > +static struct crypto_platform_data aes_data;
> > static u64 aes_dmamask = DMA_BIT_MASK(32);
> >
> > static struct resource aes_resources[] = {
> > @@ -1931,9 +1931,11 @@ static struct platform_device at91sam9g45_aes_device = {
> > static void __init at91_add_device_aes(void)
> > {
> > struct at_dma_slave *atslave;
> > - struct aes_dma_data *alt_atslave;
> > + struct crypto_dma_data *alt_atslave;
> >
> > - alt_atslave = kzalloc(sizeof(struct aes_dma_data), GFP_KERNEL);
> > + alt_atslave = kzalloc(sizeof(struct crypto_dma_data), GFP_KERNEL);
> I still not understand why we need to allocate it
>
> just declare it as static
>
last time we had some data static and you asked to alloc them (and
didn't bother to answer why you required that :
http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/02779.html ), now
you ask to declare static something which is allocated (and
that's already done this way for the mci) : may you please explain why
so that we get it the right way for next time ?
Thanks
Eric
^ permalink raw reply
* [GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Paul Walmsley @ 2012-11-07 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211070227500.8758@utopia.booyaka.com>
On Wed, 7 Nov 2012, Paul Walmsley wrote:
> On Tue, 6 Nov 2012, Tony Lindgren wrote:
>
> > I'm getting errors with the allnoconfig ones, there are total four
> > omap defconfigs there not counting the randconfigs.
>
> That might indeed explain the discrepancy; so far only have been building
> his oldconfig seeds here. Will add his allnoconfig seeds and test again.
Can reproduce this here. Thanks for catching this. Will fix and send a
new pull request today and ensure that the two allnoconfigs are added to
the build tests from now on.
- Paul
^ 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