* OMAP baseline test results for v3.7-rc3
From: Vaibhav Hiremath @ 2012-10-30 4:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210300229590.12697@utopia.booyaka.com>
On 10/30/2012 8:06 AM, Paul Walmsley wrote:
>
> Here are some basic OMAP test results for Linux v3.7-rc3.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/
>
>
> 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
>
This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform
and its booting up for me without any issues.
Jon had submitted another patch which fixes boot issue on Bone.
https://patchwork.kernel.org/patch/1606471/
======================Boot Log================
U-Boot#
U-Boot#
U-Boot#
U-Boot#
U-Boot#
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 80000000 am335x-bone.dtb
reading am335x-bone.dtb
4391 bytes read
U-Boot# fatload mmc 0 81000000 uImage
reading uImage
3841320 bytes read
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz
2022580 bytes read
U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw
initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
U-Boot# bootm 81000000 - 80000000
## Booting kernel from Legacy Image at 81000000 ...
Image Name: Linux-3.7.0-rc3
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3841256 Bytes = 3.7 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
Loading Kernel Image ... OK
OK
Loading Device Tree to 8fe65000, end 8fe69126 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0
[ 0.000000] Linux version 3.7.0-rc3 (a0393758 at psplinux064) (gcc
version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Oct 30 09:46:04
IST 2012
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model:
TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192
d15744 u36864
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 64768
[ 0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M
root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536
earlyprintk=serial
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072
bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 255MB = 255MB total
[ 0.000000] Memory: 229112k/229112k available, 33032k reserved, 0K
highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06c4b68 (6899 kB)
[ 0.000000] .init : 0xc06c5000 - 0xc0715280 ( 321 kB)
[ 0.000000] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB)
[ 0.000000] .bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128
interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
every 178956ms
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768
[ 0.000000] ... CHAINHASH_SIZE: 16384
[ 0.000000] memory used by lock dependency info: 3695 kB
[ 0.000000] per task-struct memory footprint: 1152 bytes
[ 0.001132] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[ 0.107570] pid_max: default: 32768 minimum: 301
[ 0.108239] Security Framework initialized
[ 0.108448] Mount-cache hash table entries: 512
[ 0.118568] CPU: Testing write buffer coherency: ok
[ 0.119689] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.119779] Setting up static identity map for 0x804d5ee0 - 0x804d5f50
[ 0.122980] Brought up 1 CPUs
[ 0.123011] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[ 0.147810] pinctrl core: initialized pinctrl subsystem
[ 0.156141] regulator-dummy: no parameters
[ 0.158749] NET: Registered protocol family 16
[ 0.159728] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[ 0.161208] omap-gpmc omap-gpmc: GPMC revision 6.0
[ 0.161436] omap-gpmc omap-gpmc: failed to reserve memory
[ 0.161536] omap-gpmc: probe of omap-gpmc failed with error -16
[ 0.190579] OMAP GPIO hardware version 0.1
[ 0.206252] No ATAGs?
[ 0.206283] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.293742] bio: create slab <bio-0> at 0
[ 0.400896] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[ 0.408799] SCSI subsystem initialized
[ 0.411752] usbcore: registered new interface driver usbfs
[ 0.413025] usbcore: registered new interface driver hub
[ 0.414113] usbcore: registered new device driver usb
[ 0.431103] omap_i2c 44e0b000.i2c: bus 0 rev2.4.0 at 400 kHz
[ 0.442630] Switching to clocksource gp_timer
[ 0.597669] NET: Registered protocol family 2
[ 0.600545] TCP established hash table entries: 8192 (order: 4, 65536
bytes)
[ 0.601064] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[ 0.605997] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.606290] TCP: reno registered
[ 0.606333] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 0.606678] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 0.607821] NET: Registered protocol family 1
[ 0.609499] RPC: Registered named UNIX socket transport module.
[ 0.609529] RPC: Registered udp transport module.
[ 0.609545] RPC: Registered tcp transport module.
[ 0.609561] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.610891] Trying to unpack rootfs image as initramfs...
[ 0.613489] rootfs image is not initramfs (no cpio magic); looks like
an initrd
[ 0.755899] Freeing initrd memory: 16384K
[ 0.756108] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.756747] CPU PMU: probing PMU on CPU 0
[ 0.756984] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5
counters available
[ 0.963611] VFS: Disk quotas dquot_6.5.2
[ 0.963913] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.967591] NFS: Registering the id_resolver key type
[ 0.968222] Key type id_resolver registered
[ 0.968255] Key type id_legacy registered
[ 0.968449] jffs2: version 2.2. (NAND) (SUMMARY) ? 2001-2006 Red
Hat, Inc.
[ 0.969172] msgmni has been set to 479
[ 0.973697] io scheduler noop registered
[ 0.973729] io scheduler deadline registered
[ 0.973866] io scheduler cfq registered (default)
[ 0.977713] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.985692] omap_uart 44e09000.serial: did not get pins for uart0
error: -19
[ 0.986374] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a
OMAP UART0
[ 1.590551] console [ttyO0] enabled
[ 1.634342] brd: module loaded
[ 1.663009] loop: module loaded
[ 1.673903] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.682057] OneNAND driver initializing
[ 1.693805] usbcore: registered new interface driver asix
[ 1.700157] usbcore: registered new interface driver cdc_ether
[ 1.707228] usbcore: registered new interface driver smsc95xx
[ 1.714312] usbcore: registered new interface driver net1080
[ 1.721103] usbcore: registered new interface driver cdc_subset
[ 1.728096] usbcore: registered new interface driver zaurus
[ 1.734875] usbcore: registered new interface driver cdc_ncm
[ 1.743641] usbcore: registered new interface driver cdc_wdm
[ 1.749802] Initializing USB Mass Storage driver...
[ 1.755830] usbcore: registered new interface driver usb-storage
[ 1.762172] USB Mass Storage support registered.
[ 1.767796] usbcore: registered new interface driver usbtest
[ 1.776135] mousedev: PS/2 mouse device common for all mice
[ 1.787377] i2c /dev entries driver
[ 1.793669] Driver for 1-wire Dallas network protocol.
[ 1.803608] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout
60 sec
[ 1.816899] usbcore: registered new interface driver usbhid
[ 1.823040] usbhid: USB HID core driver
[ 1.828816] oprofile: using arm/armv7
[ 1.833658] TCP: cubic registered
[ 1.837422] Initializing XFRM netlink socket
[ 1.842165] NET: Registered protocol family 17
[ 1.846984] NET: Registered protocol family 15
[ 1.852261] Key type dns_resolver registered
[ 1.856941] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[ 1.865272] ThumbEE CPU extension supported.
[ 1.882344] clock: disabling unused clocks to save power
[ 1.895621] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.907005] RAMDISK: gzip image found at block 0
[ 2.380009] VFS: Mounted root (ext2 filesystem) on device 1:0.
[ 2.387220] Freeing init memory: 320K
mount: mounting none on /var/shm failed: No such file or directory
::
:: Enabling hot-plug : [SUCCESS]
::
::
: Populating /dev : [SUCCESS]
[SUCCESS]
::
::
:: Setting PATH
::
: syslogd : [SUCCESS]
: telnetd : [SUCCESS]
Please press Enter to activate this console.
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH 3/4] arm: mvebu: add Ethernet controllers using mvneta driver for Armada 370/XP
From: Nobuhiro Iwamatsu @ 2012-10-30 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351245804-31478-4-git-send-email-thomas.petazzoni@free-electrons.com>
On Fri, Oct 26, 2012 at 7:03 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> The Armada 370 SoC has two network units, while the Armada XP has four
> network units. The first two network units are common to both the
> Armada XP and Armada 370, so they are added to armada-370-xp.dtsi,
> while the other two network units are specific to the Armada XP and
> therefore added to armada-xp.dtsi.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-370-xp.dtsi | 14 ++++++++++++++
> arch/arm/boot/dts/armada-xp.dtsi | 14 ++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 16cc82c..d484492 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -68,6 +68,20 @@
> compatible = "marvell,armada-addr-decoding-controller";
> reg = <0xd0020000 0x258>;
> };
> +
> + ethernet at d0070000 {
> + compatible = "marvell,armada-370-neta";
> + reg = <0xd0070000 0x2500>;
> + interrupts = <8>;
> + status = "disabled";
> + };
> +
> + ethernet at d0074000 {
> + compatible = "marvell,armada-370-neta";
> + reg = <0xd0074000 0x2500>;
> + interrupts = <10>;
> + status = "disabled";
> + };
Could you fit an indent?
> };
> };
>
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 71d6b5d..c77a43e 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -51,5 +51,19 @@
> compatible = "marvell,armada-370-xp-system-controller";
> reg = <0xd0018200 0x500>;
> };
> +
> + ethernet at d0030000 {
> + compatible = "marvell,armada-370-neta";
> + reg = <0xd0030000 0x2500>;
> + interrupts = <12>;
> + status = "disabled";
> + };
> +
> + ethernet at d0034000 {
> + compatible = "marvell,armada-370-neta";
> + reg = <0xd0034000 0x2500>;
> + interrupts = <14>;
> + status = "disabled";
> + };
likewise.
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-30 4:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORVsuV9_4oc6+voEM9PkqzkXKHipor5XJqaXfDNxAWLofXcxg@mail.gmail.com>
Hello Jean,
On Tue, 23 Oct 2012, Jean Pihet wrote:
> Let me try with the same setup as yours (bootloader images,
> omap2pus_defconfig, angstrom roots).
Had any luck reproducing this one that Aaro & I are seeing?
- Paul
^ permalink raw reply
* linux-next: manual merge of the clk tree with the arm-soc tree
From: Stephen Rothwell @ 2012-10-30 4:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
arch/arm/include/asm/hardware/sp810.h between commit 0891642cf117 ("ARM:
vexpress: Start using new Versatile Express infrastructure") from the
arm-soc tree and commit 05e3659135a4 ("clk: Common clocks implementation
for Versatile Express") from the clk tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc arch/arm/include/asm/hardware/sp810.h
index 2cdcf44,afd7e91..0000000
--- a/arch/arm/include/asm/hardware/sp810.h
+++ b/arch/arm/include/asm/hardware/sp810.h
@@@ -50,6 -50,14 +50,8 @@@
#define SCPCELLID2 0xFF8
#define SCPCELLID3 0xFFC
-#define SCCTRL_TIMEREN0SEL_REFCLK (0 << 15)
-#define SCCTRL_TIMEREN0SEL_TIMCLK (1 << 15)
-
-#define SCCTRL_TIMEREN1SEL_REFCLK (0 << 17)
-#define SCCTRL_TIMEREN1SEL_TIMCLK (1 << 17)
-
+ #define SCCTRL_TIMERENnSEL_SHIFT(n) (15 + ((n) * 2))
+
static inline void sysctl_soft_reset(void __iomem *base)
{
/* switch to slow mode */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/0d88bf1b/attachment.sig>
^ permalink raw reply
* [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
From: Paul Walmsley @ 2012-10-30 4:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4FD5C04F.2040509@ti.com>
Hi,
On Mon, 11 Jun 2012, Cousson, Benoit wrote:
> On 6/11/2012 2:46 AM, Paul Walmsley wrote:
>
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > index 3613054..86fc513 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -2091,6 +2091,18 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
> > .name = "mcpdm",
> > .class = &omap44xx_mcpdm_hwmod_class,
> > .clkdm_name = "abe_clkdm",
> > + /*
> > + * It's suspected that the McPDM requires an off-chip main
> > + * functional clock, controlled via I2C.
>
> Nit: Is it not suspected, it is a fact. The clock tree clearly indicate that
> the mcpdm fclk is generated from the pad_clks.
> The IP is a custom link for the Audio IC control / data. using the Audio IC as
> a source clock is standard. Since that IP is done only for that purpose, there
> is no optional clock path from the PRCM like it is the case for the McASP /
> McBSP.
>
> > This IP block is
> > + * currently reset very early during boot, before I2C is
> > + * available, so it doesn't seem that we have any choice in
> > + * the kernel other than to avoid resetting it. XXX This is
> > + * really a hardware issue workaround: every IP block should
> > + * be able to source its main functional clock from either
> > + * on-chip or off-chip sources. McPDM seems to be the only
> > + * current exception.
>
> I do not think this is the right place to put some complaint about the HW :-).
> I guess we should just describe the facts.
>
> > + */
> > + .flags = HWMOD_EXT_OPT_MAIN_CLK,
I've updated this one to take your comments into account for 3.7-rc fixes.
But...
> Could you please update the hints for this IP in the autogen scripts?
> I added a comment attribute to add a custom comment on top of the flags entry.
> The latest branch is "omap5430_for_3.6".
... could you please take care of updating the autogen side? Updated
patch is below.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 29 Oct 2012 22:02:14 -0600
Subject: [PATCH] ARM: OMAP4: hwmod data: do not enable or reset the McPDM
during kernel init
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Resolve this kernel boot message:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
The McPDM on OMAP4 can only receive its functional clock from an
off-chip source. This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C. This would
introduce a board dependency to the early hwmod code which it was not
designed to handle. Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks. This effectively
makes it impossible to enable and reset this device during hwmod init.
At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source. (This is true for almost
every IP block on the chip. As far as I know, McPDM is the only
exception.) If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state. Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.
This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: P?ter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Beno?t Cousson <b-cousson@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..7bddfa5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2125,6 +2125,14 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = "mcpdm",
.class = &omap44xx_mcpdm_hwmod_class,
.clkdm_name = "abe_clkdm",
+ /*
+ * It's suspected that the McPDM requires an off-chip main
+ * functional clock, controlled via I2C. This IP block is
+ * currently reset very early during boot, before I2C is
+ * available, so it doesn't seem that we have any choice in
+ * the kernel other than to avoid resetting it.
+ */
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
.mpu_irqs = omap44xx_mcpdm_irqs,
.sdma_reqs = omap44xx_mcpdm_sdma_reqs,
.main_clk = "mcpdm_fck",
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/6] DMA: AT91: Serial: Add parameter for serial dma use
From: Elen Song @ 2012-10-30 3:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029114221.GA31214@game.jcrosoft.org>
On 2012-10-29 19:42, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:09 Mon 29 Oct , Elen Song wrote:
>> Signed-off-by: Elen Song <elen.song@atmel.com>
>> ---
>> arch/arm/mach-at91/include/mach/board.h | 2 ++
>> drivers/tty/serial/atmel_serial.c | 1 +
>> include/linux/platform_data/dma-atmel.h | 10 ++++++++++
>> 3 files changed, 13 insertions(+)
> you will have to rebase this over a clean if the platofrm_data I'll send today
> or tomorrow that will move all the platform_data to inclide/linux
ok, please cc me in the mail list.
>
> btw your patch broke the avr32
You mean compile error, driver crash, or I need a macro to distinguish
avr32 to at91sam9 ?
I only add a few variables that avr32 will not use, it seems no
affection to avr32, you think?
>
> Best Regards.
> J.
>> diff --git a/arch/arm/mach-at91/include/mach/board.h b/arch/arm/mach-at91/include/mach/board.h
>> index c55a436..a2188a6 100644
>> --- a/arch/arm/mach-at91/include/mach/board.h
>> +++ b/arch/arm/mach-at91/include/mach/board.h
>> @@ -129,6 +129,8 @@ struct atmel_uart_data {
>> short use_dma_tx; /* use transmit DMA? */
>> short use_dma_rx; /* use receive DMA? */
>> void __iomem *regs; /* virt. base address, if any */
>> + struct at_dma_slave *dma_tx_slave;
>> + struct at_dma_slave *dma_rx_slave;
>> struct serial_rs485 rs485; /* rs485 settings */
>> };
>> extern void __init at91_add_device_serial(void);
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index 3d7e1ee..1b1bd4f 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -45,6 +45,7 @@
>>
>> #include <asm/mach/serial_at91.h>
>> #include <mach/board.h>
>> +#include <linux/platform_data/dma-atmel.h>
>>
>> #ifdef CONFIG_ARM
>> #include <mach/cpu.h>
>> diff --git a/include/linux/platform_data/dma-atmel.h b/include/linux/platform_data/dma-atmel.h
>> index cab0997..bb05302 100644
>> --- a/include/linux/platform_data/dma-atmel.h
>> +++ b/include/linux/platform_data/dma-atmel.h
>> @@ -26,11 +26,21 @@ struct at_dma_platform_data {
>> /**
>> * struct at_dma_slave - Controller-specific information about a slave
>> * @dma_dev: required DMA master device
>> + * @tx_reg: physical address of data register used for
>> + * memory-to-peripheral transfers
>> + * @rx_reg: physical address of data register used for
>> + * peripheral-to-memory transfers
>> + * @reg_width: peripheral register width
>> * @cfg: Platform-specific initializer for the CFG register
>> + * @ctrla: Platform-specific initializer for the CTRLA register
>> */
>> struct at_dma_slave {
>> struct device *dma_dev;
>> + dma_addr_t tx_reg;
>> + dma_addr_t rx_reg;
>> + u32 reg_width;
>> u32 cfg;
>> + u32 ctrla;
>> };
>>
>>
>> --
>> 1.7.9.5
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/3743f6ff/attachment-0001.html>
^ permalink raw reply
* [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
From: Paul Walmsley @ 2012-10-30 3:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350979419.2143.71.camel@sokoban>
Hi Tero,
On Tue, 23 Oct 2012, Tero Kristo wrote:
> Looks good to me. Only reason I pushed the reset wait to the end of the
> function was a minimal potential timing optimization. As the beginning
> of the function will write a register, it will consume a bit of time
> (especially if in 32k domain), so it can maybe save a single register
> read in the delay loop if ordered that way.
Ah, OK.
> Your way is probably safer, it might cause problems in some cases if the
> config is written before reset has completed (can it?)
Not sure, but seems to make sense to wait until the reset is done before
doing anything to the IP block's registers. Queuing for 3.7-rc fixes,
- Paul
^ permalink raw reply
* [PATCH] ARM: dts: mxs: Add PWM3 muxing options for i.MX28
From: Shawn Guo @ 2012-10-30 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351332946-5933-1-git-send-email-julien.boibessot@free.fr>
On Sat, Oct 27, 2012 at 12:15:46PM +0200, julien.boibessot at free.fr wrote:
> From: Julien Boibessot <julien.boibessot@armadeus.com>
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
> Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 0/4] pinctrl: samsung: Add support for Exynos4x12 SoCs
From: Thomas Abraham @ 2012-10-30 2:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089457-8205-1-git-send-email-t.figa@samsung.com>
On 24 October 2012 20:07, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch series adds pinctrl support for SoCs from Exynos4x12 family.
>
> First two patches make necessary preperations to skip legacy GPIO and
> GPIO interrupt registration in case of Exynos4x12 SoCs which are not
> supported by legacy (non-DT) code.
>
> Third patch adds Exynos4x12-specific definitions to pinctrl-samsung driver.
>
> Fourth patch adds device nodes for pin controllers available on Exynos4x12
> SoCs to Exynos4x12 device tree sources.
>
> This series depends on:
> - [PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs
>
> Tomasz Figa (4):
> ARM: EXYNOS: Skip wakeup-int setup if pinctrl driver is used on
> Exynos4x12
> gpio: samsung: Skip registration if pinctrl driver is present on
> Exynos4x12
> pinctrl: samsung: Add support for Exynos4x12
> ARM: dts: exynos4x12: Add nodes for pin controllers
>
> .../bindings/pinctrl/samsung-pinctrl.txt | 1 +
> arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 965 +++++++++++++++++++++
> arch/arm/boot/dts/exynos4x12.dtsi | 38 +
> arch/arm/mach-exynos/common.c | 7 +-
> drivers/gpio/gpio-samsung.c | 43 +-
> drivers/pinctrl/pinctrl-exynos.c | 110 +++
> drivers/pinctrl/pinctrl-samsung.c | 2 +
> drivers/pinctrl/pinctrl-samsung.h | 1 +
> 8 files changed, 1144 insertions(+), 23 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
>
> --
> 1.7.12
>
For this series:
Acked-by: Thomas Abraham <thomas.abraham@linaro.org>
^ permalink raw reply
* [PATCH 1/2] ARM: mach-imx: imx53.dtsi: pinctl update
From: Shawn Guo @ 2012-10-30 2:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029211359.GZ1641@pengutronix.de>
On Mon, Oct 29, 2012 at 10:13:59PM +0100, Sascha Hauer wrote:
> On Thu, Oct 25, 2012 at 01:26:39PM +0200, Roland Stigge wrote:
> > This patch supplements pinctl support on i.MX53.
> >
> > Signed-off-by: Roland Stigge <stigge@antcom.de>
>
> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Shawn, probably better when you take this patch as it's quite likely
> that you collect other patches to this file.
>
Applied with patch subject changed to
ARM: dts: imx53: pinctl update
Shawn
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Paul Walmsley @ 2012-10-30 2:36 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.7-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/
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
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
* 37xx EVM: CORE not entering dynamic off-idle
- Dynamic retention-idle seems to work; system suspend to off works
- Happens on both MMC root and NFS root
- Can be detected by comparing the CORE off/ret counts from
/debug/pm_debug/count before & after serial autosuspend occurs
- Fixed by http://marc.info/?l=linux-arm-kernel&m=135127961519817&w=2
* 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
* 3530ES3 Beagle: I2C timeouts during userspace init
- Intermittent, appears on 5 out of 6 boots here
- Aaro Koskinen observes this also on N900
- Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
- http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
PM tests:
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock gate ("debug ignore_loglevel")
- Not shown in the current test logs; cause unknown
- Pending re-test
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent
vmlinux object size
(delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556)):
text data bss total kernel
+1141 +88 -64 +1165 am33xx_only
+1037 +32 -48 +1021 n800_multi_omap2xxx
+1053 +32 -48 +1037 n800_only_a
+1317 +40 0 +1357 omap1_defconfig
+1285 +8 0 +1293 omap1_defconfig_1510innovator_only
+1333 +40 0 +1373 omap1_defconfig_5912osk_only
+1433 +80 -64 +1449 omap2plus_defconfig
+1089 0 -32 +1057 omap2plus_defconfig_2430sdp_only
+1429 +56 -64 +1421 omap2plus_defconfig_cpupm
+1377 +88 0 +1465 omap2plus_defconfig_no_pm
+1273 -24 0 +1249 omap2plus_defconfig_omap2_4_only
+1509 0 0 +1509 omap2plus_defconfig_omap3_4_only
+17468 0 0 +17468 rmk_omap3430_ldp_oldconfig
+1033 +56 0 +1089 rmk_omap4430_sdp_oldconfig
The 17k increase in the rmk_omap3430_ldp_oldconfig text appears to be due
to the automatic selection of CONFIG_PINCTRL by 'make oldnoconfig', new in
v3.7-rc3.
Boot-time memory difference
(delta in bytes from test_v3.7-rc2 (6f0c0580b70c89094b3422ba81118c7b959c7556))
avail rsrvd high freed board kconfig
-8k 8k . . 5912osk omap2plus_defconfig
-8k 8k . . am335xbone omap2plus_defconfig
--------------------------------------------------------------
Branch: test_v3.7-rc3
Test-Serial: 20121028162003
Commit-ID: 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64
Test-Target-Board-Count: 11
- Paul
^ permalink raw reply
* [PATCH 2/2] arm: bcm2835: properly use IOMEM() to define virtual address constants
From: Stephen Warren @ 2012-10-30 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351419853-25146-2-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/28/2012 04:24 AM, Thomas Petazzoni wrote:
> Like we now do for all ARM platforms, use IOMEM() to define virtual
> address constants, so that they get typed as 'void __iomem *'
> pointers. It for now requires a cast when defining the map_desc entry,
> but that cast should disappear once we switch map_desc to the usage of
> 'void __iomem *' pointers.
> diff --git a/arch/arm/mach-bcm2835/bcm2835.c b/arch/arm/mach-bcm2835/bcm2835.c
> static struct map_desc io_map __initdata = {
> - .virtual = BCM2835_PERIPH_VIRT,
> + .virtual = (unsigned long) BCM2835_PERIPH_VIRT,
Very nit-picky, but there shouldn't be a space after the cast there.
^ permalink raw reply
* [PATCH 1/2] arm: bcm2835: move to the multiplatform support
From: Stephen Warren @ 2012-10-30 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351419853-25146-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/28/2012 04:24 AM, Thomas Petazzoni wrote:
> This commit integrates the bcm2835 into the list of platforms
> supported by the multiplatform mechanism, which makes it possible to
> build a single kernel binary image that boots on various SoCs.
...
> Note that if you have CONFIG_VFP enabled, you need "[PATCH v3] ARM:
> vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3
> set" to be applied in order to avoid a VFP-related kernel panic when
> starting the first userspace application. Thanks to Albin Tonnerre for
> pointing me to the right fix for this problem!
Since CONFIG_VFP is enabled in bcm2835_defconfig (or in general, could
be enabled in anyone's .config), I guess that means I can't apply the
patch yet, because the VFP fix you mention above doesn't seem to have
been applied anywhere, so applying it would cause bcm2835_defconfig to
be unbootable. To apply this, I'd need to merge in a branch containing
the VFP fix first.
What branch is this patch series based on? Neither "git am" not "git am
-3" will apply the series; apparently my repo doesn't have the blobs to
perform the 3-way merge -3 invokes even though I have a remote for
linux-next which should pick up most blob sources.
A couple minor comments on the code itself:
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> + config DEBUG_BCM2835_UART
> + bool "Kernel low-level debugging messages via BCM2835 UART"
> + depends on ARCH_BCM2835
> + help
> + Say Y here if you want kernel low-level debugging support
> + on BCM2835 based platforms.
> +
Since the SoC has multiple UARTs, does it make sense to rename that
something like DEBUG_BM2835_PL011_UART?
> diff --git a/arch/arm/mach-bcm2835/include/mach/debug-macro.S b/arch/arm/include/debug/bcm2835.S
> -#include <mach/bcm2835_soc.h>
> +#define BCM2835_DEBUG_PHYS 0x20201000
> +#define BCM2835_DEBUG_VIRT 0xf0201000
Especially since I have to wait to apply this anyway, I'd prefer to
avoid that part of this patch, by calling debug_ll_io_init() from
bcm2835_map_io(). That patch unfortunately also isn't checked in yet,
but I'll try to chase it down.
^ permalink raw reply
* [PATCH V2] ARM: mx28: Skip OCOTP FEC MAC setup if in DT
From: Shawn Guo @ 2012-10-30 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210261201.58778.marex@denx.de>
On Fri, Oct 26, 2012 at 12:01:58PM +0200, Marek Vasut wrote:
> Can we apply this for 3.7?
You meant for 3.8?
Shawn
> I believe it is harmless and beneficial for some
> parties at least.
>
^ permalink raw reply
* [PATCH v2] ARM: Dove: update defconfig
From: Sebastian Hesselbarth @ 2012-10-30 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351539916-29561-1-git-send-email-sebastian.hesselbarth@gmail.com>
It has been a while since dove_defconfig was updated to recent development.
This patch adds all currently available Dove boards, including a DT-enabled
machine.
DT support requires to allow ATAGS passed by boot loader as most of them are
not yet capable of passing DT blobs. Also OF_SERIAL is enabled to actually
see the bootlog.
Finally, sdhci driver for Dove, mv_cesa, GPIO LEDs, and highmem support is
added.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- also add mv_cesa crypto engine
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/configs/dove_defconfig | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
index 40db34c..0b7ee92 100644
--- a/arch/arm/configs/dove_defconfig
+++ b/arch/arm/configs/dove_defconfig
@@ -8,11 +8,19 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_DOVE=y
CONFIG_MACH_DOVE_DB=y
+CONFIG_MACH_CM_A510=y
+CONFIG_MACH_DOVE_DT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_AEABI=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_HIGHMEM=y
+CONFIG_USE_OF=y
+CONFIG_ATAGS=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
CONFIG_VFP=y
CONFIG_NET=y
CONFIG_PACKET=y
@@ -62,6 +70,9 @@ CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
@@ -74,6 +85,18 @@ CONFIG_USB_DEVICEFS=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_STORAGE=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_IO_ACCESSORS=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_DOVE=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MV=y
CONFIG_DMADEVICES=y
@@ -122,6 +145,7 @@ CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_MV_CESA=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_LIBCRC32C=y
--
1.7.10.4
^ permalink raw reply related
* [PULL REQ] IXP4xx changes for Linux 3.7
From: Ryan Mallon @ 2012-10-30 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m3a9vkahci.fsf@intrepid.localdomain>
On 18/10/12 09:01, Krzysztof Halasa wrote:
> Hi,
>
<snip>
>
> Unfortunately, as I already explained to you in
> https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very
> limited (and this isn't a paid job) and I'm in no way able to do what
> you require. This, coupled with my inability to make the patches end up
> upstream any other way, will make me post relevant MAINTAINERS changes
> shortly.
>
> Don't get me wrong. If I had time for this it could be different.
> Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at
> this point. Given the raised barriers to participate, probably aimed at
> paid maintainers, I have to quit doing this.
>
> BTW since Imre has probably even much less time, it would be a good time
> to find someone to maintain IXP4xx code. I will be publishing (from time
> to time) my tree (I'm using the hw myself), so even simple
> cherry-picking would probably make some sense.
I maintain a tree for the ep93xx, which is another legacy arm soc. I
also do this as a hobbyist, not as a paid position. Pushing patches to
mainline via arm-soc has been very easy. Basically I branch from Linus's
tree (typically 3.x-rc1), apply patches to one of a bunch of branches
(-devel, -fixes, etc) and then send pull requests to the arm-soc
maintainers prior to the merge window. I also have a aggregate branch
which is tested in next.
It takes very little of my time to maintain this tree. I cannot see how
it could be any harder than sending to Linus directly. Also, the arm-soc
maintainers, Arnd and Olof, have been very helpful in getting me started
with my maintainer tree, and in learning the development flow.
I would also rather get flamed by the arm-soc guys than Linus when I
make a mistake :-).
~Ryan
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Joel A Fernandes @ 2012-10-30 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EAB8596@DBDE01.ent.ti.com>
[resending, because the first post got rejected due to non-plaintext]
Hi Guraraja,
I am interested in this thread. I've been trying Gururaja's patches for
audio as well.
I rebased ?Guraja's patches on top of Matt's EDMA patches which were
applied to the beaglebone 3.7 kernel repo. With some fixes to make it
compile with CONFIG_DUMMY_REGULATOR enabled, Currently it breaks at
set_dai_fmt in davinci-mcasp.c when an audio file is played.
Could you try my tree on EVM? ?dts changes may be required to use mcasp1 on
EVM, https://github.com/joelagnel/linux-kernel/commits/3.7
v3.7-rc2-fixes to v3.7-rc2-audio commits are Gururaja's patches which I
applied, and after that are my commits to enable config , add dt data and
some fixes.
Thanks,
Joel
On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
<gururaja.hebbar@ti.com> wrote:
>
> Matt,
>
> On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> > exposes a bug in the AM33XX clock data for mcasp. After moving to
> > clk_get() usage, the _init() of all registered hwmods fails on mcasp0
> > due to incorrect clock data causing clk_get() to fail. This causes all
> > successive hwmods to fail to _init() leaving them in a bad state.
> >
> > This patch updates the mcasp clock entries so clk_get() will succeed.
> > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
> > boot.
>
>
> I want to test Audio on AM335x Evm with your EDMA patches. I have few
> patches for AM335x.
> Can you share the link to the repo & branch on which I need to rebase?
> The patches are related to mcasp dt node, mcasp pinmux in dt, etc...
>
> >
> ..snip..
> ..snip..
> >
>
>
> Thanks & Regards,
> Gururaja
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Joel A Fernandes @ 2012-10-30 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EAB8596@DBDE01.ent.ti.com>
Hi Guraraja,
I am interested in this thread. I've been trying Gururaja's patches for
audio as well.
I rebased Guraja's patches on top of Matt's EDMA patches which were
applied to the beaglebone 3.7 kernel repo. With some fixes to make it
compile with CONFIG_DUMMY_REGULATOR enabled, Currently it breaks at
set_dai_fmt in davinci-mcasp.c when an audio file is played.
Could you try my tree on EVM? dts changes may be required to use mcasp1 on
EVM,
https://github.com/joelagnel/linux-kernel/commits/3.7
v3.7-rc2-fixes to v3.7-rc2-audio commits are Gururaja's patches which I
applied, and after that are my commits to enable config , add dt data and
some fixes.
Thanks,
Joel
On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
<gururaja.hebbar@ti.com>wrote:
> Matt,
>
> On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
> > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
> > exposes a bug in the AM33XX clock data for mcasp. After moving to
> > clk_get() usage, the _init() of all registered hwmods fails on mcasp0
> > due to incorrect clock data causing clk_get() to fail. This causes all
> > successive hwmods to fail to _init() leaving them in a bad state.
> >
> > This patch updates the mcasp clock entries so clk_get() will succeed.
> > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
> > boot.
>
>
> I want to test Audio on AM335x Evm with your EDMA patches. I have few
> patches for AM335x.
> Can you share the link to the repo & branch on which I need to rebase?
> The patches are related to mcasp dt node, mcasp pinmux in dt, etc...
>
> >
> ..snip..
> ..snip..
> >
>
>
> Thanks & Regards,
> Gururaja
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121029/dcae992c/attachment-0001.html>
^ permalink raw reply
* [PATCH] ARM: kirkwood: Increase NAND chip-delay for DNS-320
From: Jamie Lentin @ 2012-10-29 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029064632.GJ15143@lunn.ch>
On Mon, 29 Oct 2012, Andrew Lunn wrote:
>> The chip markings are: SAMSUNG 146 K9F1G08U0D SCB0 (FKJ554PWN)
>>
>> Unfortunately the other NAS is too far away to get at, but D-link
>> haven't stuck to exactly the same chip. This DNS-320 review shows a
>> different Samsung part:
>>
>> http://diit.cz/data/images/thumb/67491_2b9e5e4fbd.jpg?1307884464
>>
>> The datasheet for the K9F1G08U0D says max 35usecs "Data Transfer
>> from Cell to Register", whereas K9F1G08U0C (what the DNS-320 review
>> shows) says 25usecs. If this is the value in the datasheet to check,
>> then this would explain the problems.
>
> Seems sensible.
>
> I'm currently downloading the GPL sources from dlink. If the kernel
> sources are included, we can see how dlink sets this. If its also 35,
> then there is no argument.
Rummaging myself, my best guess is:
linux-2.6.22.18/arch/arm/mach-feroceon-kw/nand.c
173: this->chip_delay = 30;
u-boot-1.1.4/board/mv_feroceon/USP/mv_nand.c
68: nand->chip_delay = 30;
However, this is too fast for my NAS when using a mainline kernel. 31usecs
seems to work though. It's probably worth noting that the original
firmware wasn't without it's problems on this particular board---I
couldn't get it to reflash the NAND with a new firmware image. It could
certainly read the NAND though.
This chip_delay value seems to be there in both the DNS320 and DNS325 GPL
source. Maybe increasing chip_delay for both would be safest.
> The only thing you could think about is probing the nand device, and
> if it is not K9F1G08U0D put the delay back to 25.
That would be good, although the challenge will be a neat place to hang
the code.
>
> Andrew
>
--
Jamie Lentin
^ permalink raw reply
* Representation of external memory-mapped devices in DT (gpmc)
From: Daniel Mack @ 2012-10-29 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508EF9E3.5090507@gmail.com>
Hi Rob,
On Oct 29, 2012 10:49 PM, "Rob Herring" <robherring2@gmail.com> wrote:
>
> On 10/29/2012 12:22 PM, Daniel Mack wrote:
> > On 29.10.2012 16:09, Rob Herring wrote:
> >> On 10/29/2012 09:39 AM, Daniel Mack wrote:
> >>> Hi,
> >>>
> >>> we're currently working on a DT binding for the GPMC bus that is found
> >>> on SoCs by TI. The implementation is based on CS lines and an 8, 16 or
> >>> 32 bit parallel interface. That IP is quite flexible, and it can for
> >>> example be used for physmap flash, external peripherals or even NAND.
> >>>
> >>> Depending on which CS is used to control the device, different memory
> >>> regions are reserved, and there's code to calculate the location and
> >>> size of them, given a CS number (see arch/arm/mach-omap2/gpmc.c).
> >>
> >> I don't know the details of the h/w, but I would think the DT core code
> >> should be able work out the addresses. This can be done using ranges
> >> property which defines the mapping of a child bus into the parent bus
> >> addresses.
> >
> > In this case, the controller is @0x50000000 while the external device is
> > mapped to address 0x0.
>
> Okay, so it's not fixed or some sub-range of the memory map.
It still haz a fixed position i the memory map (0 - 0x1fffffff), but how
that space is divided for peripherals depends on the configuration.
>
> >>> The binding will use one top-level node to describe the GPMC
controller
> >>> itself and register the actual devices as sub-nodes to it. The NAND
type
> >>> is the only one that is currently supported. This is how it currently
looks:
> >>>
> >>> gpmc: gpmc at 50000000 {
> >>> compatible = "ti,gpmc";
> >>> ti,hwmods = "gpmc";
> >>> reg = <0x50000000 0x2000>;
> >>> interrupt-parent = <&intc>;
> >>> interrupts = <100>;
> >>> #address-cells = <1>;
> >>> #size-cells = <0>;
> >>>
> >>> nand at 0 {
> >>
> >> You may want a CS0 node with nand as a child node of that.
> >
> > Hmm, I don't see what that would buy us. The question is which way is
> > feasible for storing both the memory region and the cs number in the
> > device tree. The CS number should certainly go to the child node, no?
>
> I was thinking of if you had per CS properties you needed to setup each
> CS. So something like this (using non-zero address to show the
> translation better):
>
> gpmc {
> compatible = "ti,gpmc", "simple-bus";
> ti,hwmods = "gpmc";
> reg = <0x50000000 0x2000>;
>
> CS0 {
> // map 1MB @ gpmc offset 0 to host address 0x10000000
> ranges = <0x10000000 0x0 <0x100000>;
The most important bit has a syntax error ;-) Was that property meant to
carry 3 values?
> // other gpmc specific per CS properties.
> nand {
> reg = <0x0 0x100000>;
> }
> };
>
so that way, the child has the awareness about the gpmc controller config
(the offset in the memory map), and is agnostic to the cs number in use,
right? I think this is not really the most convenient approach from a
user's perspective.
> The core code will look at parents' ranges properties to translate the
> local offset of 0 into host address of 0x10000000 Then the nand node's
> reg address will get translated to 0x10000000.
That part is understood, I'm just not sure whether this is the most useful
way of describing the h/w capabilities.
Thanks,
Daniel
>
> The gpmc code can then use the ranges properties to setup the mapping of
> each chip select to the host address. You don't need a new property to
> describe the cs mapping.
>
> Rob
>
> >
> > IOW, would it be a good idea to have something like the following
layout?
> >
> > gpmc: gpmc at 50000000 {
> > compatible = "ti,gpmc";
> > ti,hwmods = "gpmc";
> > reg = <0x50000000 0x2000>;
> >
> > /* cs-reg stores the setup of the controller's
> > memory map */
> >
> > /* offset size */
> > cs-reg = <0x0 0x1000000
> > .... .....
> > .... .....>;
> >
> > nand: child at 0 {
> > /* timings */
> > /* peripheral specifics */
> > };
> > };
> >
> > I would actually much prefer that approach.
> >
> > Afzal, because because that way, we can leave the code as-is for now and
> > add the "cs-reg" property once the code is switched to dynamic handling.
> > What do you think?
> >
> >
> > Thanks,
> > Daniel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121029/0729e0f3/attachment-0001.html>
^ permalink raw reply
* [PATCH] MMC: fix sdhci-dove removal
From: Chris Ball @ 2012-10-29 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508F0027.1010102@gmail.com>
Hi,
On Mon, Oct 29 2012, Sebastian Hesselbarth wrote:
> On 10/29/2012 10:49 PM, Chris Ball wrote:
>> On Mon, Oct 29 2012, Russell King - ARM Linux wrote:
>>> Anyway, here's a replacement patch, updated against my cubox tree but
>>> lacking the cubox gpio changes for it. Un-tested through: (a) I can't
>>> test this on its own on the cubox, (b) I don't have a separate dove
>>> tree to test it against and my disk space is all but out at the moment
>>> for yet another build tree...
>>
>> Compile-tested and pushed to mmc-next, and I'll submit it for 3.7 if
>> I get a Tested-by from someone like Sebastian (CC'd), or for 3.8 if I
>> don't. (I'll add sdhci-pltfm API rework to my TODO list, too.)
>
> Chris, Russell,
>
> obviously I am not the one to ask for a Tested-by because it was my
> patch that originally caused all the trouble. My apologies for this!
>
> Anyway, I did test the patch on 3.7-rc3 and except that you need a
> 3-way git am because of a one-line offset, sdhci-dove runs just fine.
>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Great, thanks -- will push to 3.7.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] MMC: fix sdhci-dove removal
From: Sebastian Hesselbarth @ 2012-10-29 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vcdtosnx.fsf@octavius.laptop.org>
On 10/29/2012 10:49 PM, Chris Ball wrote:
> On Mon, Oct 29 2012, Russell King - ARM Linux wrote:
>> Anyway, here's a replacement patch, updated against my cubox tree but
>> lacking the cubox gpio changes for it. Un-tested through: (a) I can't
>> test this on its own on the cubox, (b) I don't have a separate dove
>> tree to test it against and my disk space is all but out at the moment
>> for yet another build tree...
>
> Compile-tested and pushed to mmc-next, and I'll submit it for 3.7 if
> I get a Tested-by from someone like Sebastian (CC'd), or for 3.8 if I
> don't. (I'll add sdhci-pltfm API rework to my TODO list, too.)
Chris, Russell,
obviously I am not the one to ask for a Tested-by because it was my
patch that originally caused all the trouble. My apologies for this!
Anyway, I did test the patch on 3.7-rc3 and except that you need a
3-way git am because of a one-line offset, sdhci-dove runs just fine.
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
^ permalink raw reply
* Representation of external memory-mapped devices in DT (gpmc)
From: Rob Herring @ 2012-10-29 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508EBB47.8070405@gmail.com>
On 10/29/2012 12:22 PM, Daniel Mack wrote:
> On 29.10.2012 16:09, Rob Herring wrote:
>> On 10/29/2012 09:39 AM, Daniel Mack wrote:
>>> Hi,
>>>
>>> we're currently working on a DT binding for the GPMC bus that is found
>>> on SoCs by TI. The implementation is based on CS lines and an 8, 16 or
>>> 32 bit parallel interface. That IP is quite flexible, and it can for
>>> example be used for physmap flash, external peripherals or even NAND.
>>>
>>> Depending on which CS is used to control the device, different memory
>>> regions are reserved, and there's code to calculate the location and
>>> size of them, given a CS number (see arch/arm/mach-omap2/gpmc.c).
>>
>> I don't know the details of the h/w, but I would think the DT core code
>> should be able work out the addresses. This can be done using ranges
>> property which defines the mapping of a child bus into the parent bus
>> addresses.
>
> In this case, the controller is @0x50000000 while the external device is
> mapped to address 0x0.
Okay, so it's not fixed or some sub-range of the memory map.
>>> The binding will use one top-level node to describe the GPMC controller
>>> itself and register the actual devices as sub-nodes to it. The NAND type
>>> is the only one that is currently supported. This is how it currently looks:
>>>
>>> gpmc: gpmc at 50000000 {
>>> compatible = "ti,gpmc";
>>> ti,hwmods = "gpmc";
>>> reg = <0x50000000 0x2000>;
>>> interrupt-parent = <&intc>;
>>> interrupts = <100>;
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> nand at 0 {
>>
>> You may want a CS0 node with nand as a child node of that.
>
> Hmm, I don't see what that would buy us. The question is which way is
> feasible for storing both the memory region and the cs number in the
> device tree. The CS number should certainly go to the child node, no?
I was thinking of if you had per CS properties you needed to setup each
CS. So something like this (using non-zero address to show the
translation better):
gpmc {
compatible = "ti,gpmc", "simple-bus";
ti,hwmods = "gpmc";
reg = <0x50000000 0x2000>;
CS0 {
// map 1MB @ gpmc offset 0 to host address 0x10000000
ranges = <0x10000000 0x0 <0x100000>;
// other gpmc specific per CS properties.
nand {
reg = <0x0 0x100000>;
}
};
The core code will look at parents' ranges properties to translate the
local offset of 0 into host address of 0x10000000 Then the nand node's
reg address will get translated to 0x10000000.
The gpmc code can then use the ranges properties to setup the mapping of
each chip select to the host address. You don't need a new property to
describe the cs mapping.
Rob
>
> IOW, would it be a good idea to have something like the following layout?
>
> gpmc: gpmc at 50000000 {
> compatible = "ti,gpmc";
> ti,hwmods = "gpmc";
> reg = <0x50000000 0x2000>;
>
> /* cs-reg stores the setup of the controller's
> memory map */
>
> /* offset size */
> cs-reg = <0x0 0x1000000
> .... .....
> .... .....>;
>
> nand: child at 0 {
> /* timings */
> /* peripheral specifics */
> };
> };
>
> I would actually much prefer that approach.
>
> Afzal, because because that way, we can leave the code as-is for now and
> add the "cs-reg" property once the code is switched to dynamic handling.
> What do you think?
>
>
> Thanks,
> Daniel
>
^ permalink raw reply
* [PATCH] MMC: fix sdhci-dove removal
From: Chris Ball @ 2012-10-29 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029214307.GH21164@n2100.arm.linux.org.uk>
Hi,
On Mon, Oct 29 2012, Russell King - ARM Linux wrote:
> Anyway, here's a replacement patch, updated against my cubox tree but
> lacking the cubox gpio changes for it. Un-tested through: (a) I can't
> test this on its own on the cubox, (b) I don't have a separate dove
> tree to test it against and my disk space is all but out at the moment
> for yet another build tree...
Compile-tested and pushed to mmc-next, and I'll submit it for 3.7 if
I get a Tested-by from someone like Sebastian (CC'd), or for 3.8 if I
don't. (I'll add sdhci-pltfm API rework to my TODO list, too.)
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH 1/4] DMA: PL330: fix locking in pl330_free_chan_resources()
From: Jassi Brar @ 2012-10-29 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351504796-24788-2-git-send-email-b.zolnierkie@samsung.com>
On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> tasklet_kill() may sleep so call it before taking pch->lock.
>
> Fixes following lockup:
>
> [ 345.470000] BUG: scheduling while atomic: cat/2383/0x00000002
> [ 345.470000] Modules linked in:
> [ 345.470000] [<c0015858>] (unwind_backtrace+0x0/0xfc) from [<c004d980>] (__schedule_bug+0x4c/0x58)
> [ 345.470000] [<c004d980>] (__schedule_bug+0x4c/0x58) from [<c0360b6c>] (__schedule+0x690/0x6e0)
> [ 345.470000] [<c0360b6c>] (__schedule+0x690/0x6e0) from [<c004f2b4>] (sys_sched_yield+0x70/0x78)
> [ 345.470000] [<c004f2b4>] (sys_sched_yield+0x70/0x78) from [<c002acec>] (tasklet_kill+0x34/0x8c)
> [ 345.470000] [<c002acec>] (tasklet_kill+0x34/0x8c) from [<c01da4cc>] (pl330_free_chan_resources+0x24/0x88)
> [ 345.470000] [<c01da4cc>] (pl330_free_chan_resources+0x24/0x88) from [<c01d81f4>] (dma_chan_put+0x4c/0x50)
> [ 345.470000] [<c01d81f4>] (dma_chan_put+0x4c/0x50) from [<c01d82c0>] (dma_release_channel+0x28/0x98)
> [...]
> [ 368.335000] BUG: spinlock lockup suspected on CPU#0, swapper/0/0
> [ 368.340000] lock: 0xe52aa04c, .magic: dead4ead, .owner: cat/2383, .owner_cpu: 1
> [ 368.350000] [<c0015858>] (unwind_backtrace+0x0/0xfc) from [<c01b3d78>] (do_raw_spin_lock+0x194/0x204)
> [ 368.360000] [<c01b3d78>] (do_raw_spin_lock+0x194/0x204) from [<c0361adc>] (_raw_spin_lock_irqsave+0x20/0x28)
> [ 368.365000] [<c0361adc>] (_raw_spin_lock_irqsave+0x20/0x28) from [<c01da80c>] (pl330_tasklet+0x2c/0x5a8)
> [ 368.375000] [<c01da80c>] (pl330_tasklet+0x2c/0x5a8) from [<c002ac04>] (tasklet_action+0xfc/0x114)
> [ 368.385000] [<c002ac04>] (tasklet_action+0xfc/0x114) from [<c002b204>] (__do_softirq+0xe4/0x19c)
> [ 368.395000] [<c002b204>] (__do_softirq+0xe4/0x19c) from [<c002b398>] (irq_exit+0x98/0x9c)
> [ 368.405000] [<c002b398>] (irq_exit+0x98/0x9c) from [<c0013ebc>] (handle_IPI+0x124/0x16c)
> [ 368.410000] [<c0013ebc>] (handle_IPI+0x124/0x16c) from [<c000857c>] (gic_handle_irq+0x64/0x68)
> [ 368.420000] [<c000857c>] (gic_handle_irq+0x64/0x68) from [<c000e740>] (__irq_svc+0x40/0x70)
> [ 368.430000] Exception stack(0xc04a3f00 to 0xc04a3f48)
> [ 368.435000] 3f00: c04a3f48 00000000 6f9e23e8 00000050 c07492c8 c04a3f48 00000000 c04ccc88
> [ 368.440000] 3f20: 6f9dbac3 00000050 6f9e23e8 00000050 3b9aca00 c04a3f48 c005cfa4 c02946d4
> [ 368.450000] 3f40: 60000013 ffffffff
> [ 368.455000] [<c000e740>] (__irq_svc+0x40/0x70) from [<c02946d4>] (cpuidle_wrap_enter+0x4c/0xa0)
> [ 368.460000] [<c02946d4>] (cpuidle_wrap_enter+0x4c/0xa0) from [<c02940dc>] (cpuidle_enter_state+0x18/0x68)
> [ 368.470000] [<c02940dc>] (cpuidle_enter_state+0x18/0x68) from [<c02948e0>] (cpuidle_idle_call+0xac/0xe0)
> [ 368.480000] [<c02948e0>] (cpuidle_idle_call+0xac/0xe0) from [<c00102f8>] (cpu_idle+0xac/0xf0)
> [ 368.490000] [<c00102f8>] (cpu_idle+0xac/0xf0) from [<c04796a0>] (start_kernel+0x28c/0x294)
>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Vinod Koul <vinod.koul@linux.intel.com>
> Cc: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> drivers/dma/pl330.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 665668b..db7574b 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2459,10 +2459,10 @@ static void pl330_free_chan_resources(struct dma_chan *chan)
> struct dma_pl330_chan *pch = to_pchan(chan);
> unsigned long flags;
>
> - spin_lock_irqsave(&pch->lock, flags);
> -
> tasklet_kill(&pch->task);
>
> + spin_lock_irqsave(&pch->lock, flags);
> +
> pl330_release_channel(pch->pl330_chid);
> pch->pl330_chid = NULL;
>
Thanks.
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
^ 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