* OMAP baseline test results for v3.8-rc4
From: Paul Walmsley @ 2013-01-20 21:38 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.8-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/
Test summary
------------
Boot to userspace:
Pass ( 9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 5912osk,
4460pandaes
FAIL ( 2/11): am335xbone, cmt3517
PM ret/off, suspend + dynamic idle:
Pass (3/3): 3530es3beagle, 3730beaglexm, 37xxevm
PM ret, suspend + dynamic idle:
Pass (1/2): 4460pandaes
FAIL (1/2): 4430es2panda
PM ret, dynamic idle:
FAIL (1/1): 2430sdp
Failing tests: fixed by posted patches
--------------------------------------
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
- http://marc.info/?l=linux-omap&m=135274739624125&w=2
- http://marc.info/?l=linux-omap&m=135664195831104&w=2
Failing tests: needing investigation
------------------------------------
Boot tests:
* am335xbone: hangs after "Starting kernel"
- Cause unknown
- http://www.mail-archive.com/linux-omap at vger.kernel.org/msg82297.html
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
* CM-T3517: boot hangs with MMC root
- Due to missing MMC setup in board file
- http://www.spinics.net/lists/arm-kernel/msg211471.html
Boot warnings:
* 3530es3beagle, 3730beaglexm, 37xxevm: nand_scan_ident() warning
- "at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()"
- http://marc.info/?l=linux-omap&m=135630897110185&w=2
* 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
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
* 2430sdp: power domains not entering retention
- Cause unknown
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock gate ("debug ignore_loglevel")
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
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
Failing tests: needing local investigation (may be due to testbed issues)
-------------------------------------------------------------------------
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omap&m=135082257727502&w=2
- Not yet part of the automated test suite
- Nishanth Menon & Vaibhav Hiremath report that it works for them
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
Problems reported by others
---------------------------
* I2C intermittent failures on N900; can break boot
- "omap_i2c omap_i2c.1: timeout waiting for bus ready"
- Reported by Aaro Koskinen
- http://www.spinics.net/lists/arm-kernel/msg216859.html
* 2420H4: reports "Could not set MPU rate to 4294MHz" on reboot
- Reported and fixed by Jon Hunter
- http://www.spinics.net/lists/arm-kernel/msg216121.html
--------------------------------------------------------------
Branch: test_v3.8-rc4
Test-Serial: 20130120122039
Commit-ID: 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619
Test-Target-Board-Count: 11
^ permalink raw reply
* [PATCH] power: reset: qnap-poweroff: Fix License String
From: Anton Vorontsov @ 2013-01-20 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130120201336.GO8668@pengutronix.de>
On Sun, Jan 20, 2013 at 09:13:36PM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Jan 08, 2013 at 07:15:26PM +0100, Andrew Lunn wrote:
> > GPLv2+ is not a valid license string. Replace it with one that is.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > drivers/power/reset/qnap-poweroff.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/power/reset/qnap-poweroff.c b/drivers/power/reset/qnap-poweroff.c
> > index ca0b476..8af772b 100644
> > --- a/drivers/power/reset/qnap-poweroff.c
> > +++ b/drivers/power/reset/qnap-poweroff.c
> > @@ -121,4 +121,4 @@ module_platform_driver(qnap_power_off_driver);
> >
> > MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch>");
> > MODULE_DESCRIPTION("QNAP Power off driver");
> > -MODULE_LICENSE("GPLv2+");
> > +MODULE_LICENSE("GPL v2");
> This change is wrong.
>
> According to include/linux/module.h "GPL v2" means exactly that: version
> 2. As the file specifies v2 or later in the header you have to use "GPL"
> which means v2 or later.
Does it even make sense to have the two separate things ("GPL v2" and
"GPL")?
Suppose there is a global change that modifies a bunch of drivers, some of
them are GPLv2+. Now, the author of the global change is submitting it
under "GPL v2 only" license, which, by definition, turns any GPLv2+ code
into "GPL v2 only", right?
So, changing from GPLv2+ to "GPL v2 only" is OK, but not the other way
around.
IANAL, tho.
Anton
p.s. Yes, in this particular driver it also makes sense to remove "or
later" words from the header, just to be consistent.
^ permalink raw reply
* [PATCH] power: reset: qnap-poweroff: Fix License String
From: Uwe Kleine-König @ 2013-01-20 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357668926-20598-1-git-send-email-andrew@lunn.ch>
On Tue, Jan 08, 2013 at 07:15:26PM +0100, Andrew Lunn wrote:
> GPLv2+ is not a valid license string. Replace it with one that is.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/power/reset/qnap-poweroff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/reset/qnap-poweroff.c b/drivers/power/reset/qnap-poweroff.c
> index ca0b476..8af772b 100644
> --- a/drivers/power/reset/qnap-poweroff.c
> +++ b/drivers/power/reset/qnap-poweroff.c
> @@ -121,4 +121,4 @@ module_platform_driver(qnap_power_off_driver);
>
> MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch>");
> MODULE_DESCRIPTION("QNAP Power off driver");
> -MODULE_LICENSE("GPLv2+");
> +MODULE_LICENSE("GPL v2");
This change is wrong.
According to include/linux/module.h "GPL v2" means exactly that: version
2. As the file specifies v2 or later in the header you have to use "GPL"
which means v2 or later.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Diamond segments Supply与您共享了照片
From: Diamond segments Supply @ 2013-01-20 16:47 UTC (permalink / raw)
To: linux-arm-kernel
Dear Sir,
Now we are very gald to inform you that we have a promotion for our Diamond
Segments with attractive price and good cutting speed with long life.
We can supply different grit of : 20# to 300# , and soft to hard bond for
different purpose.
These segments are used for HTC PAD, HUSQVARNA PAD and other type of
Grinding cup wheel .
Please check the ATTACHED PICTURE.If you need any diamond segments in other
size,please kindly send us the Length,Width and Height for your diamond
segments,we will make the good quotation for you soon!
If you have any other inquiry for diamond tools,please kindly send us,we
will give you competitive price to support you!
I am looking forward to seeing your early reply,thanks for your time!
Have a good day!
Best Regards!
selina wang
PROTEC TOOLS CO.,LTD
Add: No24 Lane 99 Xinzhe east road,Fengxian,Shanghai,China 201424
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QQ??20130109212555.jpg
Type: image/jpeg
Size: 21893 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130120/84f37a67/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.jpg
Type: image/jpeg
Size: 38739 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130120/84f37a67/attachment-0003.jpg>
^ permalink raw reply
* Introducing Aggressive Low Memory Booster [1]
From: PINTU KUMAR @ 2013-01-20 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358091177.96940.YahooMailNeo@web160103.mail.bf1.yahoo.com>
Hi,
Can anybody provide any inputs/suggestions/improvements on the following.
According to my experiments these proved to be a useful utility during low memory condition on the embedded devices.
Is there something wrong I am doing?
Please provide your suggestions.
Thanks,
Pintu
>________________________________
> From: PINTU KUMAR <pintu_agarwal@yahoo.com>
>To: "linux-mm at kvack.org" <linux-mm@kvack.org>; "linux-kernel at vger.kernel.org" <linux-kernel@vger.kernel.org>
>Cc: "linux-arm-kernel at lists.infradead.org" <linux-arm-kernel@lists.infradead.org>; "pintu.k at samsung.com" <pintu.k@samsung.com>; Anton Vorontsov <anton.vorontsov@linaro.org>; Alan Cox <alan@lxorguk.ukuu.org.uk>; richard -rw- weinberger <richard.weinberger@gmail.com>; "patches at linaro.org" <patches@linaro.org>; Mel Gorman <mgorman@suse.de>; Wanpeng Li <liwanp@linux.vnet.ibm.com>
>Sent: Sunday, 13 January 2013 9:02 PM
>Subject: Introducing Aggressive Low Memory Booster [1]
>
>
>Hi,
>
>
>Here I am trying to introduce a new feature in kernel called "Aggressive Low Memory Booster".
>The main advantage of this will be to boost the available free memory of the system to "certain level" during extremely low memory condition.
>
>
>Please provide your comments to improve further.
>Can it be used along with vmpressure_fd ???
>
>
>
>It can be invoked as follows:
>??? a) Automatically by kernel memory management when the memory threshold falls below 10MB.
>??? b) From user space program/scripts by passing the "required amount of memory to be reclaimed".
>??? Example: echo 100 > /dev/shrinkmem
>??? c) using sys interface - /sys/kernel/debug/shrinkallmem
>??? d) using an ioctl call and returning number of pages reclaimed.
>??? e) using a new system call - shrinkallmem(&nrpages);
>??? f) During CMA to reclaim and shrink a specific CMA regions.
>
>
>
>I have developed a kernel module to verify the (b) part.
>
>
>Here is the snapshot of the write call:
>+static ssize_t shrinkmem_write(struct file *file, const char *buff,
>+??????????????????????????????? size_t length, loff_t *pos)
>+{
>+??????? int ret = -1;
>+??????? unsigned long memsize = 0;
>+??????? unsigned long nr_reclaim = 0;
>+??????? unsigned long pages = 0;
>+??????? ret = kstrtoul_from_user(buff, length, 0, &memsize);
>+??????? if (ret < 0) {
>+??????????????? printk(KERN_ERR "[SHRINKMEM]: kstrtoul_from_user: Failed !\n");
>+??????????????? return
-1;
>+??????? }
>+??????? printk(KERN_INFO "[SHRINKMEM]: memsize(in MB) = %ld\n",
>+??????????????????????????????? (unsigned long)memsize);
>+??????? memsize = memsize*(1024UL*1024UL);
>+??????? nr_reclaim = memsize / PAGE_SIZE;
>+??????? pages = shrink_all_memory(nr_reclaim);
>+??????? printk(KERN_INFO "<SHRINKMEM>: Number of Pages Freed: %lu\n", pages);
>+??????? return pages;
>+}
>Please note: This requires CONFIG_HIBERNATION to be permanently enabled in the kernel.
>
>
>Several experiments have been performed on Ubuntu(kernel 3.3) to verify it under low memory conditions.
>
>
>Following are some results obtained:
>-------------------------------------
>
>Node 0, zone????? DMA??? 290??? 115????? 0????? 0????? 0????? 0????? 0????? 0????? 0????? 0????? 0
>Node 0, zone?? Normal??? 304??? 540??? 116???? 13????? 2????? 2????? 0????? 0????? 0????? 0????? 0
>=========================
>???????????? total??????
used?????? free???? shared??? buffers???? cached
>Mem:?????????? 497??????? 487???????? 10????????? 0???????? 63??????? 303
>-/+ buffers/cache:??????? 120??????? 376
>Swap:???????? 1458???????? 34?????? 1424
>Total:??????? 1956??????? 522?????? 1434
>=========================
>Total Memory Freed: 342 MB
>Total Memory Freed: 53 MB
>Total
Memory Freed: 23 MB
>Total Memory Freed: 10 MB
>Total Memory Freed: 15 MB
>Total Memory Freed: -1 MB
>Node 0, zone????? DMA????? 6????? 6????? 7????? 8???? 10????? 9????? 7????? 4????? 1????? 0????? 0
>Node 0, zone?? Normal?? 2129?? 2612?? 2166?? 1723?? 1260??? 759??? 359??? 108???? 10????? 0????? 0
>=========================
>???????????? total??????
used?????? free???? shared??? buffers???? cached
>Mem:?????????? 497???????? 47??????? 449????????? 0????????? 0????????? 5
>-/+ buffers/cache:???????? 41??????? 455
>Swap:???????? 1458???????? 97?????? 1361
>Total:??????? 1956??????? 145?????? 1811
>=========================
>
>
>It was verified using a sample shell script "reclaim_memory.sh" which keeps recovering memory by doing "echo 500 > /dev/shrinkmem" until no further reclaim is possible.
>
>
>The experiments were performed with various scenarios as follows:
>a) Just after the boot up - (could recover around 150MB with 512MB RAM)
>b) After running many applications include youtube videos, large tar files download -
>
>?? [until free mem becomes < 10MB]
>?? [Could recover around 300MB in one shot]
>c) Run reclaim, while download is in progress and video still playing - (Not applications killed)
>
>d) revoke all background applications again, after running reclaim - (No impact, normal behavior)
>?? [Just it took little extra time to launch, as if it was launched for first time]
>
>
>
>
>Please see more discussions on this in the last year mailing list:
>
>https://lkml.org/lkml/2012/4/15/35
>
>
>
>Thank You!
>With regards,
>Pintu Kumar
>Samsung - India
>
>
>
>
>
>
^ permalink raw reply
* Mirabox tree
From: Thomas Petazzoni @ 2013-01-20 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD7Jr4=E9qqzfaLi2RMTrX5ODLH16gUHQ2sk6t9tOc7L2Z=Gew@mail.gmail.com>
Dear Michael Lawson,
On Sat, 19 Jan 2013 19:21:12 +0100, Michael Lawson wrote:
> Feel free to tell me to go away. But I am quite keen to get this sd card
> working, so did not snooping around.
> To the mirabox dts file, I added (This I found in a patch somewhere from
> quite recent)
>
> usb at d0050000 {
> status = "okay";
> };
>
> usb at d0051000 {
> status = "okay";
> };
This is not sufficient. The nodes must also be added in the
corresponding .dtsi file. You should rather take 3.8-rcX and apply the
Armada 370/XP USB series posted by Ezequiel Garcia on January 15th.
> and then support for ehci in the .config file. This made no difference to
> being able to mount the drive.
Before attempting to mount anything, you should rather have a look at
the output of "lsusb" to see if at least devices are detected. Until
they are detected, it doesn't make sense to go further.
> What I found was that the sd card reader is a pretty standard device,
> root at mirabox-debian:~# lsusb
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 003: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash
> Card Reader
> Bus 001 Device 004: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash
> Card Reader
> Bus 001 Device 002: ID 1a40:0101 TERMINUS TECHNOLOGY INC. USB-2.0 4-Port HUB
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> root at ubuntu:~/mainline-public-marvell-pcie-v1# grep -i -R -l 05e3 drivers/
> drivers/media/usb/uvc/uvc_driver.c
> drivers/media/usb/gspca/gl860/gl860.c
> drivers/usb/storage/usb-storage.mod.c
> drivers/usb/storage/unusual_devs.h
> drivers/usb/storage/usb-storage.mod.o
I remember we had some discussion with other developers of the Marvell
kernel community, and I think the conclusion was that there wasn't a
kernel driver for the Genesys Logic controller. But I haven't checked
again (and being at the moment in the train with a clumsy Internet
connection makes even a basic Google search impractical).
> It would appear the drivers are included in my kernel. This is where I am
> bit confused, if the usb devices are properly mapped in the dts file, and
> the kernel modules for the flash card reader, and usb_storage are also
> loaded, what is preventing this guy from working.
>
> How do you guys actually determine the bus addresses to use in the dts
> files? Is this something provided by the hardware supplier, or via another
> way? I have tried hunting for these numbers in U-Boot and the other kernel,
> but cant see much.
You need the Armada 370 datasheet, which for now, is only available
under NDA to selected companies and developers, if I'm correct.
However, as far as USB support on Armada 370 is concerned, the patch
series for Ezequiel Garcia that I mentioned earlier is sufficient.
Then, it is a matter of finding or writing a device driver for the
Genesys Logic USB device.
Hope this helps,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] ste_dma40 updates for 3.9
From: Vinod Koul @ 2013-01-20 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115191450.GA28615@quad.lixom.net>
On Tue, Jan 15, 2013 at 11:14:50AM -0800, Olof Johansson wrote:
> On Tue, Jan 15, 2013 at 09:53:05AM +0100, Linus Walleij wrote:
> > On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:
> >
> > > This series of patches only modify the ste_dma40 driver, there are no
> > > corresponding changes under arch/arm that need to be coordinated or
> > > considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> > > to only the driver.
> > >
> > > So is there a specific reason for why these shouldn't just go in
> > > through the dmaengine tree?
> >
> > One reason would be if there are DMA bindings to device tree coming
> > this merge window, as I'm told, and it implicates a lot of platform code
> > changes on top of this as we adopt to it.
> >
> > But maybe this will be wholly confined to the DMAengine tree?
>
> Changing platform code in the driver trees is asking for conflicts at
> merge time and a grumpy Linus, I'd prefer to merge arch/arm/* through
> arm-soc in that case.
>
> Either way, this branch can be merged into dmaengine as a branch pull,
> and if needed we can bring it in as a dependency on arm-soc. We would
> need the same for the dmaengine DT bindings branch as a base. Of course,
> that requires that Vinod doesn't rebase his branch and keeps the merge
> intact. Vinod, is that compatible with your workflow?
Yes it is.
Is this series dependent on dmaengine dt-bindings. If so then it wont apply to
arm tree. Btw I dont mind it getting merged to any of the trees as long as we
keep dependecies and avoid major conflicts :)
--
~Vinod
^ permalink raw reply
* [RESEND][PATCH] dma: edma: fix slave config dependency on direction
From: Vinod Koul @ 2013-01-20 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357843264-27045-1-git-send-email-mporter@ti.com>
On Thu, Jan 10, 2013 at 01:41:04PM -0500, Matt Porter wrote:
> The edma_slave_config() implementation depends on the
> direction field such that it will not properly configure
> a slave channel when called without direction set.
>
> This fixes the implementation so that the slave config
> is copied as is and prep_slave_sg() handles the
> direction dependent handling. spi-omap2-mcspi and
> omap_hsmmc both expose this bug as they configure the
> slave channel config from a common path with an unconfigured
> direction field.
>
> Signed-off-by: Matt Porter <mporter@ti.com>
Applied, Thanks
--
~Vinod
^ permalink raw reply
* [PATCH 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-20 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=kF2RfM3UrFGC7aX6Tn=etkPce_ix5934Q+wu2XjOCJfw@mail.gmail.com>
On Sun, Jan 20, 2013 at 09:41:34AM +0530, Viresh Kumar wrote:
> On Fri, Jan 18, 2013 at 7:50 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > The Marvell Kirkwood SoCs have simple cpufreq support in hardware. The
> > CPU can either use the a high speed cpu clock, or the slower DDR
> > clock. Add a driver to swap between these two clock sources.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > drivers/clk/mvebu/clk-gating-ctrl.c | 1 +
> > drivers/cpufreq/Kconfig.arm | 6 +
> > drivers/cpufreq/Makefile | 1 +
> > drivers/cpufreq/kirkwood-cpufreq.c | 273 +++++++++++++++++++++++++++++++++++
> > 4 files changed, 281 insertions(+)
> > create mode 100644 drivers/cpufreq/kirkwood-cpufreq.c
> >
> > diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> > index 8fa5408..ebf141d 100644
> > --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> > +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> > @@ -193,6 +193,7 @@ static const struct mvebu_soc_descr __initconst kirkwood_gating_descr[] = {
> > { "runit", NULL, 7 },
> > { "xor0", NULL, 8 },
> > { "audio", NULL, 9 },
> > + { "powersave", "cpuclk", 11 },
> > { "sata0", NULL, 14 },
> > { "sata1", NULL, 15 },
> > { "xor1", NULL, 16 },
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index a0b3661..08ca366 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -77,6 +77,12 @@ config ARM_EXYNOS5250_CPUFREQ
> > This adds the CPUFreq driver for Samsung EXYNOS5250
> > SoC.
> >
> > +config ARM_KIRKWOOD_CPUFREQ
> > + def_bool ARCH_KIRKWOOD && OF
> > + help
> > + This adds the CPUFreq driver for Marvell Kirkwood
> > + SoCs.
> > +
> > config ARM_SPEAR_CPUFREQ
> > bool "SPEAr CPUFreq support"
> > depends on PLAT_SPEAR
> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> > index fadc4d4..39a0ffe 100644
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
> > @@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
> > obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
> > obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
> > obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
> > +obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
> > obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> > obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
> >
> > diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> > new file mode 100644
> > index 0000000..4f0a435
> > --- /dev/null
> > +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> > @@ -0,0 +1,273 @@
> > +/*
> > + * kirkwood_freq.c: cpufreq driver for the Marvell kirkwood
> > + *
> > + * Copyright (C) 2013 Andrew Lunn <andrew@lunn.ch>
> > + *
> > + * 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/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/init.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/clk-provider.h>
>
> why do you need this one?
I need __clk_is_enabled() in order to know the current state of the
clock. What i found is that if the state does not change, the CPU
never wakes up from the WFI. So i want to read back from the hardware
what state the clock is in.
>
> > +#include <linux/of.h>
> > +#include <linux/delay.h>
> > +#include <linux/clk.h>
> > +#include <linux/cpufreq.h>
> > +#include <linux/timex.h>
> > +#include <linux/io.h>
> > +#include <asm/proc-fns.h>
>
> would be better to keep them in alphabetical order to guarantee that we don't
> include anything twice.
O.K.
> > +#define CPU_SW_INT_BLK BIT(28)
> > +
> > +
> > +#include <linux/clk-private.h>
> > +
> > +static struct priv
> > +{
> > + struct clk *cpu_clk;
> > + struct clk *ddr_clk;
> > + struct clk *powersave_clk;
> > + struct device *dev;
> > + void __iomem *base;
> > +} priv;
> > +
> > +#define STATE_CPU_FREQ 0x01
> > +#define STATE_DDR_FREQ 0x02
> > +
> > +/* Kirkwood can swap the clock to the CPU between two clocks:
> > + *
> > + * - cpu clk
> > + * - ddr clk
> > + *
> > + * The frequencies are set at runtime before registering this *
> > + * table. */
>
> wrong multiline comment style.
>
> /*
> * ....
> * ....
> */
>
> > +static struct cpufreq_frequency_table kirkwood_freq_table[] = {
> > + {STATE_CPU_FREQ, 0}, /* CPU uses cpuclk */
> > + {STATE_DDR_FREQ, 0}, /* CPU uses ddrclk */
> > + {0, CPUFREQ_TABLE_END},
> > +};
>
> I don't know if anything is broken now, but i would like to keep index
> in freq_table.index
> field as the actual index in the table.
>
> i.e, currently you have order as 1,2,0 .. but should have been 0, 1, 2
Documentation/cpu-freq/cpu-drivers.txt says:
2. Frequency Table Helpers
==========================
As most cpufreq processors only allow for being set to a few specific
frequencies, a "frequency table" with some functions might assist in
some work of the processor driver. Such a "frequency table" consists
of an array of struct cpufreq_freq_table entries, with any value in
"index" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And
if you want to skip one entry in the table, set the frequency to
CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending
order.
> > +static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
> > +{
> > + if (__clk_is_enabled(priv.powersave_clk))
> > + return kirkwood_freq_table[1].frequency;
> > + return kirkwood_freq_table[0].frequency;
> > +}
> > +
> > +static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
> > +{
> > +
> > + struct cpufreq_freqs freqs;
> > + unsigned int state = kirkwood_freq_table[index].index;
> > + unsigned long reg;
> > +
> > + freqs.old = kirkwood_cpufreq_get_cpu_frequency(0);
> > + freqs.new = kirkwood_freq_table[index].frequency;
> > + freqs.cpu = 0; /* Kirkwood is UP */
> > +
> > + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > +
> > + dev_dbg(priv.dev, "Attempting to set frequency to %i KHz\n",
> > + kirkwood_freq_table[index].frequency);
> > + dev_dbg(priv.dev, "old frequency was %i KHz\n",
> > + kirkwood_cpufreq_get_cpu_frequency(0));
> > +
> > + if (freqs.old != freqs.new) {
> > + local_irq_disable();
> > +
> > + /* Disable interrupts to the CPU */
> > + reg = readl_relaxed(priv.base);
> > + reg |= CPU_SW_INT_BLK;
> > + writel(reg, priv.base);
> > +
> > + switch (state) {
> > + case STATE_CPU_FREQ:
> > + clk_disable(priv.powersave_clk);
> > + break;
> > + case STATE_DDR_FREQ:
> > + clk_enable(priv.powersave_clk);
> > + break;
> > + default:
> > + dev_err(priv.dev, "Unexpected cpufreq state");
> > + }
> > +
> > + /* Wait-for-Interrupt, which the hardware changes frequency */
> > + cpu_do_idle();
> > +
> > + /* Enable interrupts to the CPU */
> > + reg = readl_relaxed(priv.base);
> > + reg &= ~CPU_SW_INT_BLK;
> > + writel(reg, priv.base);
> > +
> > + local_irq_enable();
> > + }
> > + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > +};
> > +
> > +static int kirkwood_cpufreq_verify(struct cpufreq_policy *policy)
> > +{
> > + return cpufreq_frequency_table_verify(policy, &kirkwood_freq_table[0]);
> > +}
> > +
> > +static int kirkwood_cpufreq_target(struct cpufreq_policy *policy,
> > + unsigned int target_freq,
> > + unsigned int relation)
> > +{
> > + unsigned int index = 0;
> > +
> > + if (cpufreq_frequency_table_target(policy, kirkwood_freq_table,
> > + target_freq, relation, &index))
> > + return -EINVAL;
> > +
> > + kirkwood_cpufreq_set_cpu_state(index);
>
> You can get this function inlined here.. as it is only called from
> this location.
Yes, i could. gcc will inline it anyway. But look at other
drivers. elan, gx-suspmod, longhaul, maple, p4, powernow-k6,
powernow-k7, powernow-k8, etc, all have a helper function to do the
actual change, which is called from the target function. So i'm just
following the normal convention.
> > + return 0;
> > +}
> > +
> > +/*
> > + * Module init and exit code
> > + */
> > +static int kirkwood_cpufreq_cpu_init(struct cpufreq_policy *policy)
> > +{
> > + int result;
> > +
> > + /* cpuinfo and default policy values */
> > + policy->cpuinfo.transition_latency = 5000; /* 5uS */
> > + policy->cur = kirkwood_cpufreq_get_cpu_frequency(0);
> > +
> > + result = cpufreq_frequency_table_cpuinfo(policy, kirkwood_freq_table);
> > + if (result)
> > + return result;
> > +
> > + cpufreq_frequency_table_get_attr(kirkwood_freq_table, policy->cpu);
> > +
> > + return 0;
> > +}
> > +
> > +static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> > +{
> > + cpufreq_frequency_table_put_attr(policy->cpu);
> > + return 0;
> > +}
> > +
> > +static struct freq_attr *kirkwood_cpufreq_attr[] = {
> > + &cpufreq_freq_attr_scaling_available_freqs,
> > + NULL,
> > +};
> > +
> > +
> > +static struct cpufreq_driver kirkwood_cpufreq_driver = {
> > + .get = kirkwood_cpufreq_get_cpu_frequency,
> > + .verify = kirkwood_cpufreq_verify,
> > + .target = kirkwood_cpufreq_target,
> > + .init = kirkwood_cpufreq_cpu_init,
> > + .exit = kirkwood_cpufreq_cpu_exit,
> > + .name = "kirkwood_freq",
> > + .owner = THIS_MODULE,
> > + .attr = kirkwood_cpufreq_attr,
> > +};
> > +
> > +static int kirkwood_cpufreq_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = of_find_compatible_node(
> > + NULL, NULL, "marvell,kirkwood-core-clock");
>
> Is cpu0 a better location for adding this entry?
I'm not adding an entry here. I'm using an existing entry.
> > + struct of_phandle_args clkspec;
> > + struct resource *res;
> > + int err;
> > +
> > + priv.dev = &pdev->dev;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res) {
> > + dev_err(&pdev->dev, "Cannot get memory resource\n");
> > + return -ENODEV;
> > + }
> > + priv.base = devm_request_and_ioremap(&pdev->dev, res);
> > + if (!priv.base) {
> > + dev_err(&pdev->dev, "Cannot ioremap\n");
> > + return -ENOMEM;
> > + }
> > +
> > + clkspec.np = np;
> > + clkspec.args_count = 1;
> > + clkspec.args[0] = 1;
> > +
> > + priv.cpu_clk = of_clk_get_from_provider(&clkspec);
> > + if (IS_ERR(priv.cpu_clk)) {
> > + dev_err(priv.dev, "Unable to get cpuclk");
> > + return PTR_ERR(priv.cpu_clk);
> > + }
> > +
> > + clk_prepare_enable(priv.cpu_clk);
> > + kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
> > +
> > + clkspec.args[0] = 3;
> > + priv.ddr_clk = of_clk_get_from_provider(&clkspec);
> > + if (IS_ERR(priv.ddr_clk)) {
> > + dev_err(priv.dev, "Unable to get ddrclk");
> > + err = PTR_ERR(priv.ddr_clk);
> > + goto out_cpu;
> > + }
> > +
> > + clk_prepare_enable(priv.ddr_clk);
> > + kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
> > +
> > + np = of_find_compatible_node(NULL, NULL,
> > + "marvell,kirkwood-gating-clock");
> > + clkspec.np = np;
> > + clkspec.args[0] = 11;
> > + priv.powersave_clk = of_clk_get_from_provider(&clkspec);
> > + if (IS_ERR(priv.powersave_clk)) {
> > + dev_err(priv.dev, "Unable to get powersave");
> > + err = PTR_ERR(priv.powersave_clk);
> > + goto out_ddr;
> > + }
> > + clk_prepare(priv.powersave_clk);
>
> want to check return value?
Not much point. Gated clock drivers don't actually have a prepare
function, so it cannot fail. The parent clock is a fixed clock, which
also does not have a prepare function. All this call is doing is
updating the reference counters.
Andrew
^ permalink raw reply
* [PATCH 0/4] gpio: introduce descriptor-based interface
From: Alex Courbot @ 2013-01-20 6:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301170850.43655.sfking@fdwdc.com>
Hi Steven,
On 01/18/2013 01:50 AM, Steven King wrote:
> Well, my concern is the small, single chip platforms with limited ram and
> speeds measured in MHz. My goal was that these platforms that had very basic
> gpio needs, no offboard gpio, just toggling a few pins for spi or whatever,
> could do that without pulling in a bunch of code they dont need. I realize
> that for x86 or arm people with their giga Hz cpus with gigabytes of ram, its
> no big deal, but my little 60 MHz coldfire v2s with only 16 megs of ram (and
> even more constraining, 2 megs of flash) need all the help they can get.
Running readelf on gpiolib.o built for Tegra, here are the footprints:
.text: 9412B
.data: 260B
.bss: 12312B
.rodata: 268B
Total: 22252B or 22KB.
... of which more than half is the BSS section which consists of a
static array of 1024 GPIO descriptors, an arbitrary number that you can
tune and is way too large even for Tegra (but we have to use these
gigabytes somehow). Say you only need to use 256 GPIOs and .bss is down
to ~3KB, for a total overhead of 15kB or 0.09% of your 16MB which, in
perspective, suddenly seem gigantic. :)
If you are concerned about the additional indirection that GPIOlib
introduces and the potential slowdown for bitbanging, you can always
define custom gpio_set_value() and gpio_get_value() macros to shortcut
GPIOlib when the GPIO is in the range you want performance for.
> I haven't been keeping up with the kernel list of late, can someone point me
> to what''s being discussed so I can see what were talking about here?
Arnd explained it already, but basically we'd like to consolidate the
GPIO subsystem around GPIOlib and introduce safer interfaces (while
preserving backward compatibility). Good progress in that direction
would be achieved if all users of the GENERIC_GPIO interface relied on
GPIOlib (making GENERIC_GPIO require GPIOLIB).
Actually the question of switching to GPIOlib is only worth being asked
if you are making use of drivers that require GENERIC_GPIO. If this is
not the case and your GPIOs are only used by your own platform code, you
can always give up using defining GENERIC_GPIO and continue implementing
them your own way.
Thanks,
Alex.
^ permalink raw reply
* [PATCH 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-20 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358518846-16251-2-git-send-email-andrew@lunn.ch>
On Fri, Jan 18, 2013 at 7:50 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> The Marvell Kirkwood SoCs have simple cpufreq support in hardware. The
> CPU can either use the a high speed cpu clock, or the slower DDR
> clock. Add a driver to swap between these two clock sources.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/clk/mvebu/clk-gating-ctrl.c | 1 +
> drivers/cpufreq/Kconfig.arm | 6 +
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/kirkwood-cpufreq.c | 273 +++++++++++++++++++++++++++++++++++
> 4 files changed, 281 insertions(+)
> create mode 100644 drivers/cpufreq/kirkwood-cpufreq.c
>
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> index 8fa5408..ebf141d 100644
> --- a/drivers/clk/mvebu/clk-gating-ctrl.c
> +++ b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -193,6 +193,7 @@ static const struct mvebu_soc_descr __initconst kirkwood_gating_descr[] = {
> { "runit", NULL, 7 },
> { "xor0", NULL, 8 },
> { "audio", NULL, 9 },
> + { "powersave", "cpuclk", 11 },
> { "sata0", NULL, 14 },
> { "sata1", NULL, 15 },
> { "xor1", NULL, 16 },
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index a0b3661..08ca366 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -77,6 +77,12 @@ config ARM_EXYNOS5250_CPUFREQ
> This adds the CPUFreq driver for Samsung EXYNOS5250
> SoC.
>
> +config ARM_KIRKWOOD_CPUFREQ
> + def_bool ARCH_KIRKWOOD && OF
> + help
> + This adds the CPUFreq driver for Marvell Kirkwood
> + SoCs.
> +
> config ARM_SPEAR_CPUFREQ
> bool "SPEAr CPUFreq support"
> depends on PLAT_SPEAR
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index fadc4d4..39a0ffe 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
> obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
> +obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
>
> diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> new file mode 100644
> index 0000000..4f0a435
> --- /dev/null
> +++ b/drivers/cpufreq/kirkwood-cpufreq.c
> @@ -0,0 +1,273 @@
> +/*
> + * kirkwood_freq.c: cpufreq driver for the Marvell kirkwood
> + *
> + * Copyright (C) 2013 Andrew Lunn <andrew@lunn.ch>
> + *
> + * 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/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk-provider.h>
why do you need this one?
> +#include <linux/of.h>
> +#include <linux/delay.h>
> +#include <linux/clk.h>
> +#include <linux/cpufreq.h>
> +#include <linux/timex.h>
> +#include <linux/io.h>
> +#include <asm/proc-fns.h>
would be better to keep them in alphabetical order to guarantee that we don't
include anything twice.
> +#define CPU_SW_INT_BLK BIT(28)
> +
> +
> +#include <linux/clk-private.h>
> +
> +static struct priv
> +{
> + struct clk *cpu_clk;
> + struct clk *ddr_clk;
> + struct clk *powersave_clk;
> + struct device *dev;
> + void __iomem *base;
> +} priv;
> +
> +#define STATE_CPU_FREQ 0x01
> +#define STATE_DDR_FREQ 0x02
> +
> +/* Kirkwood can swap the clock to the CPU between two clocks:
> + *
> + * - cpu clk
> + * - ddr clk
> + *
> + * The frequencies are set at runtime before registering this *
> + * table. */
wrong multiline comment style.
/*
* ....
* ....
*/
> +static struct cpufreq_frequency_table kirkwood_freq_table[] = {
> + {STATE_CPU_FREQ, 0}, /* CPU uses cpuclk */
> + {STATE_DDR_FREQ, 0}, /* CPU uses ddrclk */
> + {0, CPUFREQ_TABLE_END},
> +};
I don't know if anything is broken now, but i would like to keep index
in freq_table.index
field as the actual index in the table.
i.e, currently you have order as 1,2,0 .. but should have been 0, 1, 2
> +static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
> +{
> + if (__clk_is_enabled(priv.powersave_clk))
> + return kirkwood_freq_table[1].frequency;
> + return kirkwood_freq_table[0].frequency;
> +}
> +
> +static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
> +{
> +
> + struct cpufreq_freqs freqs;
> + unsigned int state = kirkwood_freq_table[index].index;
> + unsigned long reg;
> +
> + freqs.old = kirkwood_cpufreq_get_cpu_frequency(0);
> + freqs.new = kirkwood_freq_table[index].frequency;
> + freqs.cpu = 0; /* Kirkwood is UP */
> +
> + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> +
> + dev_dbg(priv.dev, "Attempting to set frequency to %i KHz\n",
> + kirkwood_freq_table[index].frequency);
> + dev_dbg(priv.dev, "old frequency was %i KHz\n",
> + kirkwood_cpufreq_get_cpu_frequency(0));
> +
> + if (freqs.old != freqs.new) {
> + local_irq_disable();
> +
> + /* Disable interrupts to the CPU */
> + reg = readl_relaxed(priv.base);
> + reg |= CPU_SW_INT_BLK;
> + writel(reg, priv.base);
> +
> + switch (state) {
> + case STATE_CPU_FREQ:
> + clk_disable(priv.powersave_clk);
> + break;
> + case STATE_DDR_FREQ:
> + clk_enable(priv.powersave_clk);
> + break;
> + default:
> + dev_err(priv.dev, "Unexpected cpufreq state");
> + }
> +
> + /* Wait-for-Interrupt, which the hardware changes frequency */
> + cpu_do_idle();
> +
> + /* Enable interrupts to the CPU */
> + reg = readl_relaxed(priv.base);
> + reg &= ~CPU_SW_INT_BLK;
> + writel(reg, priv.base);
> +
> + local_irq_enable();
> + }
> + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> +};
> +
> +static int kirkwood_cpufreq_verify(struct cpufreq_policy *policy)
> +{
> + return cpufreq_frequency_table_verify(policy, &kirkwood_freq_table[0]);
> +}
> +
> +static int kirkwood_cpufreq_target(struct cpufreq_policy *policy,
> + unsigned int target_freq,
> + unsigned int relation)
> +{
> + unsigned int index = 0;
> +
> + if (cpufreq_frequency_table_target(policy, kirkwood_freq_table,
> + target_freq, relation, &index))
> + return -EINVAL;
> +
> + kirkwood_cpufreq_set_cpu_state(index);
You can get this function inlined here.. as it is only called from
this location.
> + return 0;
> +}
> +
> +/*
> + * Module init and exit code
> + */
> +static int kirkwood_cpufreq_cpu_init(struct cpufreq_policy *policy)
> +{
> + int result;
> +
> + /* cpuinfo and default policy values */
> + policy->cpuinfo.transition_latency = 5000; /* 5uS */
> + policy->cur = kirkwood_cpufreq_get_cpu_frequency(0);
> +
> + result = cpufreq_frequency_table_cpuinfo(policy, kirkwood_freq_table);
> + if (result)
> + return result;
> +
> + cpufreq_frequency_table_get_attr(kirkwood_freq_table, policy->cpu);
> +
> + return 0;
> +}
> +
> +static int kirkwood_cpufreq_cpu_exit(struct cpufreq_policy *policy)
> +{
> + cpufreq_frequency_table_put_attr(policy->cpu);
> + return 0;
> +}
> +
> +static struct freq_attr *kirkwood_cpufreq_attr[] = {
> + &cpufreq_freq_attr_scaling_available_freqs,
> + NULL,
> +};
> +
> +
> +static struct cpufreq_driver kirkwood_cpufreq_driver = {
> + .get = kirkwood_cpufreq_get_cpu_frequency,
> + .verify = kirkwood_cpufreq_verify,
> + .target = kirkwood_cpufreq_target,
> + .init = kirkwood_cpufreq_cpu_init,
> + .exit = kirkwood_cpufreq_cpu_exit,
> + .name = "kirkwood_freq",
> + .owner = THIS_MODULE,
> + .attr = kirkwood_cpufreq_attr,
> +};
> +
> +static int kirkwood_cpufreq_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = of_find_compatible_node(
> + NULL, NULL, "marvell,kirkwood-core-clock");
Is cpu0 a better location for adding this entry?
> + struct of_phandle_args clkspec;
> + struct resource *res;
> + int err;
> +
> + priv.dev = &pdev->dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "Cannot get memory resource\n");
> + return -ENODEV;
> + }
> + priv.base = devm_request_and_ioremap(&pdev->dev, res);
> + if (!priv.base) {
> + dev_err(&pdev->dev, "Cannot ioremap\n");
> + return -ENOMEM;
> + }
> +
> + clkspec.np = np;
> + clkspec.args_count = 1;
> + clkspec.args[0] = 1;
> +
> + priv.cpu_clk = of_clk_get_from_provider(&clkspec);
> + if (IS_ERR(priv.cpu_clk)) {
> + dev_err(priv.dev, "Unable to get cpuclk");
> + return PTR_ERR(priv.cpu_clk);
> + }
> +
> + clk_prepare_enable(priv.cpu_clk);
> + kirkwood_freq_table[0].frequency = clk_get_rate(priv.cpu_clk) / 1000;
> +
> + clkspec.args[0] = 3;
> + priv.ddr_clk = of_clk_get_from_provider(&clkspec);
> + if (IS_ERR(priv.ddr_clk)) {
> + dev_err(priv.dev, "Unable to get ddrclk");
> + err = PTR_ERR(priv.ddr_clk);
> + goto out_cpu;
> + }
> +
> + clk_prepare_enable(priv.ddr_clk);
> + kirkwood_freq_table[1].frequency = clk_get_rate(priv.ddr_clk) / 1000;
> +
> + np = of_find_compatible_node(NULL, NULL,
> + "marvell,kirkwood-gating-clock");
> + clkspec.np = np;
> + clkspec.args[0] = 11;
> + priv.powersave_clk = of_clk_get_from_provider(&clkspec);
> + if (IS_ERR(priv.powersave_clk)) {
> + dev_err(priv.dev, "Unable to get powersave");
> + err = PTR_ERR(priv.powersave_clk);
> + goto out_ddr;
> + }
> + clk_prepare(priv.powersave_clk);
want to check return value?
> + err = cpufreq_register_driver(&kirkwood_cpufreq_driver);
> + if (!err)
> + return 0;
> + dev_err(priv.dev, "Failed to register cpufreq driver");
> +
> + clk_disable_unprepare(priv.powersave_clk);
> +out_ddr:
> + clk_disable_unprepare(priv.ddr_clk);
> +out_cpu:
> + clk_disable_unprepare(priv.cpu_clk);
> +
> + return err;
> +}
> +
> +
> +static int kirkwood_cpufreq_remove(struct platform_device *pdev)
> +{
> + cpufreq_unregister_driver(&kirkwood_cpufreq_driver);
> +
> + clk_disable_unprepare(priv.powersave_clk);
> + clk_disable_unprepare(priv.ddr_clk);
> + clk_disable_unprepare(priv.cpu_clk);
> +
> + return 0;
> +}
> +
> +static struct platform_driver kirkwood_cpufreq_platform_driver = {
> + .probe = kirkwood_cpufreq_probe,
> + .remove = kirkwood_cpufreq_remove,
> + .driver = {
> + .name = "kirkwood-cpufreq",
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +module_platform_driver(kirkwood_cpufreq_platform_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch");
> +MODULE_DESCRIPTION("cpufreq driver for Marvell's kirkwood CPU");
> +MODULE_ALIAS("platform:kirkwood-cpufreq");
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" 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] RX-51: Register twl4030-madc device
From: Pali Rohár @ 2013-01-20 2:54 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9a0dbb7..286292e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1364,6 +1364,16 @@ static void __init rx51_init_lirc(void)
}
#endif
+static struct platform_device madc_hwmon = {
+ .name = "twl4030_madc_hwmon",
+ .id = -1,
+};
+
+static void __init rx51_init_twl4030_hwmon(void)
+{
+ platform_device_register(&madc_hwmon);
+}
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1386,5 +1396,6 @@ void __init rx51_peripherals_init(void)
omap_hsmmc_init(mmc);
rx51_charger_init();
+ rx51_init_twl4030_hwmon();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH] RX-51: Add leds lp5523 names from Maemo 5 2.6.28 kernel
From: Pali Rohár @ 2013-01-20 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 7611958..9a0dbb7 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -168,30 +168,39 @@ static struct tsl2563_platform_data rx51_tsl2563_platform_data = {
#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
static struct lp5523_led_config rx51_lp5523_led_config[] = {
{
+ .name = "lp5523:kb1",
.chan_nr = 0,
.led_current = 50,
}, {
+ .name = "lp5523:kb2",
.chan_nr = 1,
.led_current = 50,
}, {
+ .name = "lp5523:kb3",
.chan_nr = 2,
.led_current = 50,
}, {
+ .name = "lp5523:kb4",
.chan_nr = 3,
.led_current = 50,
}, {
+ .name = "lp5523:b",
.chan_nr = 4,
.led_current = 50,
}, {
+ .name = "lp5523:g",
.chan_nr = 5,
.led_current = 50,
}, {
+ .name = "lp5523:r",
.chan_nr = 6,
.led_current = 50,
}, {
+ .name = "lp5523:kb5",
.chan_nr = 7,
.led_current = 50,
}, {
+ .name = "lp5523:kb6",
.chan_nr = 8,
.led_current = 50,
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH] power: reset: qnap-poweroff: Fix License String
From: Anton Vorontsov @ 2013-01-20 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357668926-20598-1-git-send-email-andrew@lunn.ch>
On Tue, Jan 08, 2013 at 07:15:26PM +0100, Andrew Lunn wrote:
> GPLv2+ is not a valid license string. Replace it with one that is.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
Applied, thanks a lot!
> drivers/power/reset/qnap-poweroff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/reset/qnap-poweroff.c b/drivers/power/reset/qnap-poweroff.c
> index ca0b476..8af772b 100644
> --- a/drivers/power/reset/qnap-poweroff.c
> +++ b/drivers/power/reset/qnap-poweroff.c
> @@ -121,4 +121,4 @@ module_platform_driver(qnap_power_off_driver);
>
> MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch>");
> MODULE_DESCRIPTION("QNAP Power off driver");
> -MODULE_LICENSE("GPLv2+");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH] crypto: omap-sham - Fix compile errors when CONFIG_OF not defined
From: Herbert Xu @ 2013-01-20 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358283182-29392-1-git-send-email-mgreer@animalcreek.com>
On Tue, Jan 15, 2013 at 01:53:02PM -0700, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Fix the compile errors created by commit 2545e8d
> (crypto: omap-sham - Add Device Tree Support)
> when CONFIG_OF is not defined. This includes
> changing omap_sham_get_res_dev() to omap_sham_get_res_of()
> and creating an empty version of omap_sham_of_match[].
>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Also applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 00/10] crypto: omap-aes - Updates & New Functionality
From: Herbert Xu @ 2013-01-20 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357671467-32363-1-git-send-email-mgreer@animalcreek.com>
On Tue, Jan 08, 2013 at 11:57:37AM -0700, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Changes from v1:
> - Addressed comments by Russ Dill by defining omap_aes_of_match[] to
> contain an empty entry (end of list indicator) and defining
> omap_aes_get_res_of() instead of incorrectly defining
> omap_aes_get_res_dev() when CONFIG_OF is not defined.
>
> This patch series does several things to the omap-aes crypto
> driver including:
> - converting to use pm_runtime
> - adding suspend/resume support
> - converting to use dmaengine API
> - adding device tree support
> - adding OMAP4/AM33XX support
> - adding CTR support
> - some misc. cleanups
>
> The patches are based on the current k.o. 54e37b8 (Merge tag
> 'vfio-for-v3.8-v2' of git://github.com/awilliam/linux-vfio), plus:
> - the ARM hwmod, etc patches from
> "[PATCH 00/15] OMAP SHAM & AES Crypto Updates"
> (http://marc.info/?l=linux-omap&m=135610732120447&w=2)
> - the EDMA dmaengine patches submitted by Matt Porter
> "[RFC PATCH v3 00/16] DMA Engine support for AM33XX]"
> (https://lkml.org/lkml/2012/10/18/256)
> - some misc patches required by the EDMA patches
> - a hack to fix the compilation error that the current k.o. kernel has
>
> A working examle is here:
>
> git at github.com:mgreeraz/linux-mag.git submitted/crypto/aes
>
> This patch series does several things to the omap-aes crypto
> driver including:
> - converting to use pm_runtime
> - adding suspend/resume support
> - converting to use dmaengine API
> - adding device tree support
> - adding OMAP4/AM33XX support
> - adding CTR support
> - some misc. cleanups
>
> The patches are based on the current k.o. kernel, plus:
> - the ARM hwmod, etc patches from
> "[PATCH 00/15] OMAP SHAM & AES Crypto Updates"
> (http://marc.info/?l=linux-omap&m=135610732120447&w=2)
> - the EDMA dmaengine patches submitted by Matt Porter
> "[RFC PATCH v3 00/16] DMA Engine support for AM33XX]"
> (https://lkml.org/lkml/2012/10/18/256)
> - some misc patches required by the EDMA patches
> - a hack to fix the compilation error that the current k.o. kernel has
All applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3 4/8] MFD: ti_am335x_tscadc: add device tree binding information
From: Lars-Peter Clausen @ 2013-01-19 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <daf18b4779ac3c6b69b1e7e2d1a4abd18b13fee5.1358502134.git.rachna@ti.com>
Hi,
On 01/18/2013 11:48 AM, Patil, Rachna wrote:
> From: "Patil, Rachna" <rachna@ti.com>
>
> Signed-off-by: Patil, Rachna <rachna@ti.com>
> ---
> .../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 35 ++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> new file mode 100644
> index 0000000..c13c492
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> @@ -0,0 +1,35 @@
> +Texas Instruments - TSC / ADC multi-functional device
> +
> +ti_tscadc is a multi-function device with touchscreen and ADC on chip.
> +This document describes the binding for mfd device.
> +
> +Required properties:
> +- compatible: "ti,ti-tscadc"
> +- reg: Specifies the address of MFD block
> +- interrupts: IRQ line connected to the main SoC
> +- interrupt-parent: The parent interrupt controller
The subnodes and their properties also need documentation.
> +
> +Optional properties:
> +- ti,hwmods: Hardware information related to TSC/ADC MFD device
> +
> +Example:
> +
> + tscadc: tscadc at 44e0d000 {
> + compatible = "ti,ti-tscadc";
> + reg = <0x44e0d000 0x1000>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <16>;
> + ti,hwmods = "adc_tsc";
> +
> + tsc {
> + wires = <4>;
> + x-plate-resistance = <200>;
> + steps-to-configure = <5>;
> + wire-config = <0x00 0x11 0x22 0x33>;
Non-standard properties should have a vendor prefix.
> + };
> +
> + adc {
> + adc-channels = <4>;
> + };
> + };
^ permalink raw reply
* [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Ezequiel Garcia @ 2013-01-19 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358634477-25868-1-git-send-email-ezequiel.garcia@free-electrons.com>
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Changes from v1:
* Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
.../devicetree/bindings/mtd/gpmc-onenand.txt | 43 +++++++++++++++++++
arch/arm/mach-omap2/gpmc.c | 44 ++++++++++++++++++++
2 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 0000000..deec9da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,43 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "onenand".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel: DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc at 6e000000 {
+ compatible = "ti,omap3430-gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x6e000000 0x1000000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ onenand at 0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* partitions go here */
+ };
+ };
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include "omap_device.h"
#include "gpmc.h"
#include "gpmc-nand.h"
+#include "gpmc-onenand.h"
#define DEVICE_NAME "omap-gpmc"
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, "reg", &val) < 0) {
+ dev_err(&pdev->dev, "%s has no 'reg' property\n",
+ child->full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data->cs = val;
+ gpmc_onenand_data->of_node = child;
+ gpmc_onenand_data->dma_channel = -1;
+
+ if (!of_property_read_u32(child, "dma-channel", &val))
+ gpmc_onenand_data->dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ for_each_node_by_name(child, "onenand") {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret < 0)
+ return ret;
+ }
return 0;
}
#else
--
1.7.8.6
^ permalink raw reply related
* [PATCH v2 2/3] arm: omap2: gpmc-onenand: drop __init annotation
From: Ezequiel Garcia @ 2013-01-19 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358634477-25868-1-git-send-email-ezequiel.garcia@free-electrons.com>
gpmc_onenand_init() will be called from another driver's probe() function,
so drop the __init annotation, in order to prevent section mismatches.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/mach-omap2/gpmc-onenand.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 94a349e..fadd8743 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -356,7 +356,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base, int *freq_ptr)
return ret;
}
-void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
+void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
--
1.7.8.6
^ permalink raw reply related
* [PATCH v2 1/3] mtd: omap-onenand: pass device_node in platform data
From: Ezequiel Garcia @ 2013-01-19 22:27 UTC (permalink / raw)
To: linux-arm-kernel
Pass an optional device_node pointer in the platform data,
which in turn will be put into a mtd_part_parser_data.
This way, code that sets up the platform devices can pass
along the node from DT so that the partitions can be parsed.
For non-DT boards, this change has no effect.
Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/mtd/onenand/omap2.c | 4 +++-
include/linux/platform_data/mtd-onenand-omap2.h | 3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 065f3fe..eec2aed 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
struct onenand_chip *this;
int r;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev->dev.platform_data;
if (pdata == NULL) {
@@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
if ((r = onenand_scan(&c->mtd, 1)) < 0)
goto err_release_regulator;
- r = mtd_device_parse_register(&c->mtd, NULL, NULL,
+ ppdata.of_node = pdata->of_node;
+ r = mtd_device_parse_register(&c->mtd, NULL, &ppdata,
pdata ? pdata->parts : NULL,
pdata ? pdata->nr_parts : 0);
if (r)
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h b/include/linux/platform_data/mtd-onenand-omap2.h
index 685af7e..e9a9fb1 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
u8 flags;
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
+
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.8.6
^ permalink raw reply related
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Arnd Bergmann @ 2013-01-19 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FABBED.1020905@web.de>
On Saturday 19 January 2013, Soeren Moch wrote:
> What I can see in the log: a lot of coherent mappings from sata_mv and
> orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> All coherent mappings are page aligned, some of them (from orion_ehci)
> are not really small (as claimed in __alloc_from_pool).
Right. Unfortunately, the output does not show which of the mappings
are atomic, so we still need to look through those that can be atomic
to understand what's going on. There are a few megabytes of coherent
mappings in total according to the output, but it seems that a significant
portion of them is atomic, which is a bit unexpected.
> I don't believe in a memory leak. When I restart vdr (the application
> utilizing the dvb sticks) then there is enough dma memory available
> again.
I found at least one source line that incorrectly uses an atomic
allocation, in ehci_mem_init():
dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
ehci->periodic_size * sizeof(__le32),
&ehci->periodic_dma, 0);
The last argument is the GFP_ flag, which should never be zero, as
that is implicit !wait. This function is called only once, so it
is not the actual culprit, but there could be other instances
where we accidentally allocate something as GFP_ATOMIC.
The total number of allocations I found for each type are
sata_mv: 66 pages (270336 bytes)
mv643xx_eth: 4 pages == (16384 bytes)
orion_ehci: 154 pages (630784 bytes)
orion_ehci (atomic): 256 pages (1048576 bytes)
from the distribution of the numbers, it seems that there is exactly 1 MB
of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
in individual pages. This matches the size of your pool, so it's definitely
something coming from USB, and no single other allocation, but it does not
directly point to a specific line of code.
One thing I found was that the ARM dma-mapping code seems buggy in the way
that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.
I believe we need the patch below, but it is not clear to me if that issue
is related to your problem or now.
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..c57975f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -640,7 +641,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
if (is_coherent || nommu())
addr = __alloc_simple_buffer(dev, size, gfp, &page);
- else if (gfp & GFP_ATOMIC)
+ else if (!(gfp & __GFP_WAIT))
addr = __alloc_from_pool(size, &page);
else if (!IS_ENABLED(CONFIG_CMA))
addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, caller);
@@ -1272,7 +1273,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
*handle = DMA_ERROR_CODE;
size = PAGE_ALIGN(size);
- if (gfp & GFP_ATOMIC)
+ if (!(gfp & __GFP_WAIT))
return __iommu_alloc_atomic(dev, size, handle);
pages = __iommu_alloc_buffer(dev, size, gfp, attrs);
8<-------
There is one more code path I could find, which is usb_submit_urb() =>
usb_hcd_submit_urb => ehci_urb_enqueue() => submit_async() =>
qh_append_tds() => qh_make(GFP_ATOMIC) => ehci_qh_alloc() =>
dma_pool_alloc() => pool_alloc_page() => dma_alloc_coherent()
So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
causes the low-level allocation to be GFP_ATOMIC, because
qh_append_tds() is called under a spinlock. If we have hundreds
of URBs in flight, that will exhaust the pool rather quickly.
Arnd
^ permalink raw reply related
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Andrew Lunn @ 2013-01-19 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FABBED.1020905@web.de>
> Please find attached a debug log generated with your patch.
>
> I used the sata disk and two em28xx dvb sticks, no other usb devices,
> no ethernet cable connected, tuners on saa716x-based card not used.
>
> What I can see in the log: a lot of coherent mappings from sata_mv
> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> All coherent mappings are page aligned, some of them (from orion_ehci)
> are not really small (as claimed in __alloc_from_pool).
>
> I don't believe in a memory leak. When I restart vdr (the application
> utilizing the dvb sticks) then there is enough dma memory available
> again.
Hi Soeren
We should be able to rule out a leak. Mount debugfg and then:
while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done
while you are capturing. See if the number goes down.
Andrew
^ permalink raw reply
* [PATCH] of: fix incorrect return value of of_find_matching_node_and_match()
From: Thomas Abraham @ 2013-01-19 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358619642-23607-1-git-send-email-thomas.abraham@linaro.org>
On 19 January 2013 10:20, Thomas Abraham <thomas.abraham@linaro.org> wrote:
> The of_find_matching_node_and_match() function incorrectly sets the matched
> entry to 'matches' when the compatible value of a node matches one of the
> possible values. This results in incorrectly selecting the the first entry in
> the 'matches' list as the matched entry. Fix this by noting down the result of
> the call to of_match_node() and setting that as the matched entry.
>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> drivers/of/base.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
[Adding devicetree-discuss at lists.ozlabs.org to the cc list]
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 2390ddb..960ae5b 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -612,6 +612,7 @@ struct device_node *of_find_matching_node_and_match(struct device_node *from,
> const struct of_device_id **match)
> {
> struct device_node *np;
> + const struct of_device_id *m;
>
> if (match)
> *match = NULL;
> @@ -619,9 +620,10 @@ struct device_node *of_find_matching_node_and_match(struct device_node *from,
> read_lock(&devtree_lock);
> np = from ? from->allnext : of_allnodes;
> for (; np; np = np->allnext) {
> - if (of_match_node(matches, np) && of_node_get(np)) {
> + m = of_match_node(matches, np);
> + if (m && of_node_get(np)) {
> if (match)
> - *match = matches;
> + *match = m;
> break;
> }
> }
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH] of: fix incorrect return value of of_find_matching_node_and_match()
From: Thomas Abraham @ 2013-01-19 18:20 UTC (permalink / raw)
To: linux-arm-kernel
The of_find_matching_node_and_match() function incorrectly sets the matched
entry to 'matches' when the compatible value of a node matches one of the
possible values. This results in incorrectly selecting the the first entry in
the 'matches' list as the matched entry. Fix this by noting down the result of
the call to of_match_node() and setting that as the matched entry.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
drivers/of/base.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 2390ddb..960ae5b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -612,6 +612,7 @@ struct device_node *of_find_matching_node_and_match(struct device_node *from,
const struct of_device_id **match)
{
struct device_node *np;
+ const struct of_device_id *m;
if (match)
*match = NULL;
@@ -619,9 +620,10 @@ struct device_node *of_find_matching_node_and_match(struct device_node *from,
read_lock(&devtree_lock);
np = from ? from->allnext : of_allnodes;
for (; np; np = np->allnext) {
- if (of_match_node(matches, np) && of_node_get(np)) {
+ m = of_match_node(matches, np);
+ if (m && of_node_get(np)) {
if (match)
- *match = matches;
+ *match = m;
break;
}
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer
From: Santosh Shilimkar @ 2013-01-19 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e76a7048f02560a90f1e9cdc0181fd43@localhost>
On Saturday 19 January 2013 08:16 PM, Marc Zyngier wrote:
> On Sat, 19 Jan 2013 00:21:22 +0530, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> On Friday 18 January 2013 10:38 PM, Marc Zyngier wrote:
>>> On 18/01/13 17:00, Santosh Shilimkar wrote:
>>>> On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
>>>>> On 18/01/13 15:32, Santosh Shilimkar wrote:
>>>>>> From: Rajendra Nayak <rnayak@ti.com>
>>>>>>
>>>>>> Specify both secure as well as nonsecure PPI IRQ for arch
>>>>>> timer. This fixes the following errors seen on DT OMAP5 boot..
>>>>>>
>>>>>> [ 0.000000] arch_timer: No interrupt available, giving up
>>>>>>
>>>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>>>>>
>>>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++----
>>>>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi
>>>>>> b/arch/arm/boot/dts/omap5.dtsi
>>>>>> index 790bb2a..7a78d1b 100644
>>>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>>>> @@ -35,8 +35,12 @@
>>>>>> compatible = "arm,cortex-a15";
>>>>>> timer {
>>>>>> compatible = "arm,armv7-timer";
>>>>>> - /* 14th PPI IRQ, active low level-sensitive */
>>>>>> - interrupts = <1 14 0x308>;
>>>>>> + /*
>>>>>> + * PPI secure/nonsecure IRQ,
>>>>>> + * active low level-sensitive
>>>>>> + */
>>>>>> + interrupts = <1 13 0x308>,
>>>>>> + <1 14 0x308>;
>>>>>
>>>>> Care to add the virtual and HYP timer interrupts? So KVM can get a
>>>>> chance to run on this HW...
>>>>>
>>>> Thanks Marc for spotting it. Will take care of it.
>>>
>>> I just realised something silly... You have one timer node *per cpu*,
>>> and this is not really expected.
>>>
>> This was discussed on the list here [1]
>> Benoit suggested to add per CPU node since arch timer is per
>> CPU and DT should describe the hw the way it is. Did we miss
>> something ?
>
> The current approach is not to duplicate banked resources. We do not have
> duplicated twd-timer nodes on Cortex A9, we do not expose multiple CPU
> interfaces for the GIC...
>
Yes, I have observed that. The arch/twd timer DT extraction code doesn't
expect per CPU DT node and on that basis only, initial patch was
adding single timer node outside cpu node. Benoit comment was that
the DT should describe the way hardware is and probably the DT
extraction code should be updated accordingly.
> And speaking of the GIC: how do you interpret the CPU mask in the
> interrupt field of the timer? The value 0x3xx in the third field is there
> to indicate that CPU0 and CPU1 are getting interrupted by the timer. What
> does it mean when you duplicate it?> M.
>
>
Here too I have to keep mask for both CPUs because of the current DT
extraction code. I some how forgot to bring that discussion to your
notice. I can update the DT files to go back to the single timer
node if the plan is not to duplicate the per CPU resources.
Benoit,
Whats your take on it ?
Regards
Santosh
^ 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