* [PATCH v3 2/4] ARM: EXYNOS: pm_domain: Fix power domain name initialization
From: Tomasz Figa @ 2012-11-13 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352811115-1198-1-git-send-email-t.figa@samsung.com>
This patch adds initialization of name field in generic power domain
struct.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/mach-exynos/pm_domains.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
index d1abc1a..5b7ce7e 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -98,7 +98,8 @@ static __init int exynos_pm_dt_parse_domains(void)
return -ENOMEM;
}
- pd->name = np->name;
+ pd->pd.name = kstrdup(np->name, GFP_KERNEL);
+ pd->name = pd->pd.name;
pd->base = of_iomap(np, 0);
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;
--
1.8.0
^ permalink raw reply related
* [PATCH v3 1/4] ARM: EXYNOS: pm_domain: Detect domain state on registration from DT
From: Tomasz Figa @ 2012-11-13 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352811115-1198-1-git-send-email-t.figa@samsung.com>
Initial state of power domains might vary on different boards and with
different bootloaders.
This patch adds detection of initial state of power domains when being
registered from DT.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 4 ----
arch/arm/mach-exynos/pm_domains.c | 8 +++++---
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 6528e21..843b546 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -9,10 +9,6 @@ Required Properties:
- reg: physical base address of the controller and length of memory mapped
region.
-Optional Properties:
-- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
- state during boot and remains to be turned-off until explicitly turned-on.
-
Example:
lcd0: power-domain-lcd0 {
diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
index c0bc83a..d1abc1a 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -89,6 +89,7 @@ static __init int exynos_pm_dt_parse_domains(void)
for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
struct exynos_pm_domain *pd;
+ int on;
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
if (!pd) {
@@ -97,14 +98,15 @@ static __init int exynos_pm_dt_parse_domains(void)
return -ENOMEM;
}
- if (of_get_property(np, "samsung,exynos4210-pd-off", NULL))
- pd->is_off = true;
pd->name = np->name;
pd->base = of_iomap(np, 0);
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;
pd->pd.of_node = np;
- pm_genpd_init(&pd->pd, NULL, false);
+
+ on = __raw_readl(pd->base + 0x4) & S5P_INT_LOCAL_PWR_EN;
+
+ pm_genpd_init(&pd->pd, NULL, !on);
}
return 0;
}
--
1.8.0
^ permalink raw reply related
* [PATCH v3 0/4] ARM: EXYNOS: Power domain DT support extension
From: Tomasz Figa @ 2012-11-13 12:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch series fixes two issues with existing DT support for Exynos
power domains and extends it with the ability of binding devices to domains,
basically making it possible to use power domains with DT.
Based on for-next branch of Kgene's tree.
Changes since v2:
- Rebased to for-next of Kgene's tree.
Changes since v1:
- Added "samsung," prefix to "power-domain" property.
- Added power domain nodes to Exynos4 device tree sources.
Tomasz Figa (4):
ARM: EXYNOS: pm_domain: Detect domain state on registration from DT
ARM: EXYNOS: pm_domain: Fix power domain name initialization
ARM: EXYNOS: pm_domain: Bind devices to power domains using DT
ARM: dts: exynos4: Set up power domains
.../bindings/arm/exynos/power_domain.txt | 15 +++-
arch/arm/boot/dts/exynos4.dtsi | 30 +++++++
arch/arm/boot/dts/exynos4210.dtsi | 5 ++
arch/arm/mach-exynos/pm_domains.c | 93 +++++++++++++++++++++-
4 files changed, 135 insertions(+), 8 deletions(-)
--
1.8.0
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC for v3.8 #4
From: Arnd Bergmann @ 2012-11-13 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352776212-3211-1-git-send-email-horms@verge.net.au>
On Tuesday 13 November 2012, Simon Horman wrote:
> please consider the following SoC fixes for 3.8.
> Its a little embarrassing, but they all fix problems introduced
> in previous pull-requests for 3.8 that have been merged.
No problem at all, thanks for the quick follow-up!
> * The three Revert patches back-out secondary CPU initialisation
> changes from Bastian Hecht which he as advised me are incorrect
> and break secondary CPU initialisation.
>
> * The clkfwk patch from Morimoto-san resolves a build warning.
>
> This pull-request is based on the renesas/soc3 branch in the arm-soc tree.
Pulled into next/soc2, on top of the previous branch.
Arnd
^ permalink raw reply
* [PATCHv3 0/7] i2c: omap: updates
From: Shubhrajyoti Datta @ 2012-11-13 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352118223-3796-1-git-send-email-shubhrajyoti@ti.com>
On Mon, Nov 5, 2012 at 5:53 PM, Shubhrajyoti D <shubhrajyoti@ti.com> wrote:
>
> Does the followiing
> - Make the revision a 32- bit consisting of rev_lo amd rev_hi each
> of 16 bits.
>
> - Also use the revision register for the erratum i207.
> - Refactor the i2c_omap_init code.
>
> Adds a patch to remove the hardcoding sysc register. Instead
> read register ,reset and then writeback the read value.
>
> Also more cleanup is possible will check on that subsequently.
>
> Previous discussions can be found
> http://www.spinics.net/lists/linux-omap/msg81265.html
>
>
> Tested on OMAP4430sdp ,4460 ,omap3630 ,3430 and omap2430.
>
> For omap2 testing the below patch was used
> [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
>
If there are no further comments can this be considered for next.
Thanks and Regards,
^ permalink raw reply
* [PATCH] ARM: kirkwood: Add Plat'Home OpenBlocks A6 support
From: Jason Cooper @ 2012-11-13 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352792590-20052-1-git-send-email-iwamatsu@nigauri.org>
Nobuhiro,
On Tue, Nov 13, 2012 at 04:43:09PM +0900, Nobuhiro Iwamatsu wrote:
> Add support for Plat'Home OpenBlocks A6 using the device tree
> where possible.
> This commit supports SATA, USB, ether and serial console.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> V2:
> - Remove unnecessary value from bootargs.
> - Update comment for MPP table.
> - Remove kirkwood_uart0_init().
Thanks for the patch. One small note. In the future, please add a 'V2'
to the subject line, eg "[PATCH V2] ...". It really helps us keep track of
which one to merge.
No need to resend, I'll keep track of it since I'm about to pull
everything together over the next few days.
thx,
Jason.
^ permalink raw reply
* [PATCH V2] ARM: tegra: retain L2 content over CPU suspend/resume
From: Pavel Machek @ 2012-11-13 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352772288-2290-1-git-send-email-josephl@nvidia.com>
On Tue 2012-11-13 10:04:48, Joseph Lo wrote:
> The L2 RAM is in different power domain from the CPU cluster. So the
> L2 content can be retained over CPU suspend/resume. To do that, we
> need to disable L2 after the MMU is disabled, and enable L2 before
> the MMU is enabled. But the L2 controller is in the same power domain
> with the CPU cluster. We need to restore it's settings and re-enable
> it after the power be resumed.
Is it good idea to retain L2 over suspend? I guess this is
power-vs-speed balance...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v4] Network driver for the Armada 370 and Armada XP ARM Marvell SoCs
From: Thomas Petazzoni @ 2012-11-13 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121103115321.GA4539@electric-eye.fr.zoreil.com>
Fran?ois,
Thanks for your detailed review. I have a few comments/questions below
on specific topics.
On Sat, 3 Nov 2012 12:53:21 +0100, Francois Romieu wrote:
> > + if (rxq->descs == NULL) {
> > + netdev_err(pp->dev,
> > + "rxQ=%d: Can't allocate %d bytes for %d RX descr\n",
> > + rxq->id, rxq->size * MVNETA_DESC_ALIGNED_SIZE,
> > + rxq->size);
> > + return -ENOMEM;
> > + }
> > +
> > + BUG_ON(rxq->descs !=
> > + PTR_ALIGN(rxq->descs, MVNETA_CPU_D_CACHE_LINE_SIZE));
>
> There is no reason to crash.
Well, there is a reason: the hardware will not work properly if
rxq->descs is not aligned on a MVNETA_CPU_D_CACHE_LINE_SIZE boundary.
So one solution is to over-allocated to guarantee the alignment, but
since practically speaking MVNETA_CPU_D_CACHE_LINE_SIZE=32 and
dma_alloc_coherent() returns things that seem at least 32 bytes
aligned, it sounded overkill to include more code to fix a problem that
doesn't exist. This BUG_ON() is here solely for the purpose of noisily
letting the user know if this implicit assumption on the alignment of
dma_alloc_coherent() allocated buffer changes in the future. I can turn
this into an error if you prefer:
if (rxq->descs != PTR_ALIGN(rxq->descs, MVNETA_CPU_D_CACHE_LINE_SIZE)) {
netdev_err(pp->dev, "improper buffer alignement assumption, driver needs fixing\n");
dma_free_coherent(...);
return -EINVAL;
}
> (...]
> > +static int mvneta_txq_init(struct mvneta_port *pp,
> > + struct mvneta_tx_queue *txq)
> > +{
> > + txq->size = pp->tx_ring_size;
> > +
> > + /* Allocate memory for TX descriptors */
> > + txq->descs = dma_alloc_coherent(pp->dev->dev.parent,
> > + txq->size * MVNETA_DESC_ALIGNED_SIZE,
> > + &txq->descs_phys,
> > + DMA_BIDIRECTIONAL);
>
> &txq->descs_phys, DMA_BIDIRECTIONAL);
Aaah, thanks for pointing this one! It should have been GFP_KERNEL, not
DMA_BIDIRECTIONAL here.
> > + if (txq->descs == NULL) {
> > + netdev_err(pp->dev,
> > + "txQ=%d: Can't allocate %d bytes for %d TX descr\n",
> > + txq->id, txq->size * MVNETA_DESC_ALIGNED_SIZE,
> > + txq->size);
> > + return -ENOMEM;
> > + }
> > +
> > + /* Make sure descriptor address is cache line size aligned */
> > + BUG_ON(txq->descs !=
> > + PTR_ALIGN(txq->descs, MVNETA_CPU_D_CACHE_LINE_SIZE));
>
> There is no reason to crash.
Same as above :-)
> [...]
> > +static int mvneta_setup_rxqs(struct mvneta_port *pp)
> > +{
> > + int queue;
> > +
> > + for (queue = 0; queue < rxq_number; queue++) {
> > + int err = mvneta_rxq_init(pp, &pp->rxqs[queue]);
> > + if (err) {
> > + netdev_err(pp->dev,
> > + "%s: can't create RxQ rxq=%d\n",
>
> netdev_err(pp->dev, "%s: can't create RxQ rxq=%d\n",
>
> > + __func__, queue);
> > + mvneta_cleanup_rxqs(pp);
> > + return -ENODEV;
>
> mvneta_rxq_init should return a proper error code and it should be
> propagated (option: break instead of return and mvneta_setup_rxqs scoped
> err variable)
Besides turning the "return -ENODEV;" into "return err;", I don't see
what is the other problem here? mvneta_rxq_init() properly returns
-ENOMEM where there is a memory allocation failure, and
mvneta_cleanup_rxqs() properly cleans up *all* initialized rxqs. Is
there something I'm missing?
Thanks again for your review!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Russell King - ARM Linux @ 2012-11-13 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211130911.09613.arnd@arndb.de>
On Tue, Nov 13, 2012 at 09:11:09AM +0000, Arnd Bergmann wrote:
> On Tuesday 13 November 2012, Rob Clark wrote:
> > right, that is what I was worried about.. but what about something
> > along the lines of:
> >
> > case 8: { \
> > if (sizeof(x) < 8) \
> > __get_user_x(__r2, __p, __e, __l, 4); \
> > else \
> > __get_user_x(__r2, __p, __e, __l, 8); \
> > break; \
> > } \
>
> I guess that's still broken if x is 8 or 16 bits wide.
Actually, it isn't - because if x is 8 or 16 bits wide, and we load
a 32-bit quantity, all that follows is a narrowing cast which is exactly
what happens today. We don't have a problem with register allocation
like we have in the 32-bit x vs 64-bit pointer target type, which is what
the above code works around.
> > maybe we need a special variant of __get_user_8() instead to get the
> > right 32bits on big vs little endian systems, but I think something
> > roughly along these lines could work.
> >
> > Or maybe in sizeof(x)<8 case, we just __get_user_bad().. I'm not 100%
> > sure on whether this is supposed to be treated as an error case at
> > compile time or not.
>
> We know that nobody is using that at the moment, so we could define
> it to be a compile-time error.
>
> But I still think this is a pointless exercise, a number of people have
> concluded independently that it's not worth trying to come up with a
> solution, whether one exists or not. Why can't you just use copy_from_user()
> anyway?
You're missing something; that is one of the greatest powers of open
source. The many eyes (and minds) effect. Someone out there probably
has a solution to whatever problem, the trick is to find that person. :)
I think we have a working solution for this for ARM. It won't be suitable
for every arch, where they have 8-bit and 16-bit registers able to be
allocated by the compiler, but for architectures where the minimum register
size is 32-bit, what we have below should work.
In other words, I don't think this will work for x86-32 where ax, al, ah
as well as eax are still available.
What I have currently in my test file, which appears to work correctly,
is (bear in mind this is based upon an older version of get_user() which
pre-dates Will's cleanups):
#define __get_user_x(__r2,__p,__e,__s,__i...) \
__asm__ __volatile__ ( \
"bl __get_user_" #__s \
: "=&r" (__e), "=r" (__r2) \
: "0" (__p) \
: __i, "cc")
#ifdef BIG_ENDIAN
#define __get_user_xb(__r2,__p,__e,__s,__i...) \
__get_user_x(__r2,(uintptr_t)__p + 4,__s,__i)
#else
#define __get_user_xb __get_user_x
#endif
#define get_user(x,p) \
({ \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
register int __e asm("r0"); \
register typeof(x) __r2 asm("r2"); \
switch (sizeof(*(__p))) { \
case 1: \
__get_user_x(__r2, __p, __e, 1, "lr"); \
break; \
case 2: \
__get_user_x(__r2, __p, __e, 2, "r3", "lr"); \
break; \
case 4: \
__get_user_x(__r2, __p, __e, 4, "lr"); \
break; \
case 8: \
if (sizeof((x)) < 8) \
__get_user_xb(__r2, __p, __e, 4, "lr"); \
else \
__get_user_x(__r2, __p, __e, 8, "lr"); \
break; \
default: __e = __get_user_bad(); break; \
} \
x = (typeof(*(__p))) __r2; \
__e; \
})
Tested with 8, 16, 32, 64 ints, 32bit int with const p, pointers, const
pointers, pointer to 64bit with 32bit target, pointer-to-const-pointer
to non-const pointer (which should and does warn).
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Russell King - ARM Linux @ 2012-11-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGvoXR3YJomjV1YOeNvjr46aYJ2mVxS+jZfH+41+v1nAvw@mail.gmail.com>
On Mon, Nov 12, 2012 at 06:31:50PM -0600, Rob Clark wrote:
> right, that is what I was worried about.. but what about something
> along the lines of:
>
> case 8: { \
> if (sizeof(x) < 8) \
> __get_user_x(__r2, __p, __e, __l, 4); \
> else \
> __get_user_x(__r2, __p, __e, __l, 8); \
> break; \
> } \
>
> maybe we need a special variant of __get_user_8() instead to get the
> right 32bits on big vs little endian systems, but I think something
> roughly along these lines could work.
The problem with that is... big endian systems - where the 32-bit word we
want is the second one, so you can't just reduce that down to a 32-bit
access like that. You also need to add an offset to the pointer in the BE
case (which can be done.)
I'd suggest calling the 4-byte version in there __get_user_xb() and doing
the 4-byte offset for BE inside that (or aliasing it to __get_user_x for
LE systems).
^ permalink raw reply
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
From: Will Deacon @ 2012-11-13 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A15A33.60405@free-electrons.com>
On Mon, Nov 12, 2012 at 08:21:07PM +0000, Gregory CLEMENT wrote:
> On 11/05/2012 03:02 PM, Will Deacon wrote:
> > On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
> >> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> >> +{
> >> + int reg;
> >> +
> >> + if (!coherency_base) {
> >> + pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
> >> + pr_warn("Coherency fabric is not initialized\n");
> >> + return 1;
> >> + }
> >> +
> >> + /* Enable the CPU in coherency fabric */
> >> + reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> >> + reg |= 1 << (24 + hw_cpu_id);
> >> + writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
> >> +
> >> + /* Add CPU to SMP group */
> >> + reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> >> + reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
> >> + writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
> >> +
> >> + return 0;
> >> +}
> >
> > These writels may expand to code containing calls to outer_sync(), which
> > will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> > coherent, how does this play out with the exclusive store instruction in the
> > lock?
>
> I dug a little this subject: and I am not sure there is problem. In SMP mode,
> only the system cache mode of Aurora is used. In this mode, outer_cache.sync
> is void then outer_sync() won't call any function, so there will be no
> access to any spinlock.
Hmm, that is pretty subtle and it doesn't really solve the bigger picture.
printk takes logbuf_lock, for example, and I'm sure that by the time you get
to this code you will have relied on exclusives behaving correctly.
Will
^ permalink raw reply
* [PATCH] ARM: implement optimized percpu variable access
From: Will Deacon @ 2012-11-13 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A163C6.6080208@gmail.com>
On Mon, Nov 12, 2012 at 09:01:58PM +0000, Rob Herring wrote:
> On 11/12/2012 10:51 AM, Will Deacon wrote:
> > Ok, similar numbers over here so it looks like this is definitely worth
> > doing. However, I still object to the "cc", particularly after discussion
> > with the tools guys here who agree that the behaviour you're seeing is
> > indicative of a buggy compiler. It may even be part of a larger issue with
> > GCC's definition of `reachability' for kernel entry points. For interest, I
> > failed to reproduce with:
> >
> > gcc version 4.7.3 20121001 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.10-20121022 - Linaro GCC 2012.10)
> > (http://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2)
> >
> > which sounds fairly close to the tools that you are using. Please can you
> > file a bug in launchpad?
>
> Strangely, I can't reproduce it either now...
Reproduce what? :)
If you remove the "cc" clobber, you can add my ack:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] ARM: OMAP: board-4430sdp: Proper support for TWL6030 PWM LED/Backlight
From: Peter Ujfalusi @ 2012-11-13 10:38 UTC (permalink / raw)
To: linux-arm-kernel
New PWM drivers are being prepared for twl series which will enable the use
of all PWMs (PWMs and LEDs).
They are implemented as generic PWM drivers to be able to use them for different
purposes.
The current platform code was broken: the leds_pwm driver was not able to pick
up the PWM since the pwm_id was incorrect.
With the other patches we will be able to control the followings:
LCD backlight via pwm-backlight driver
Keypad leds via leds_pwm driver as normal LED
Charging indicator via leds_pwm driver as normal LED
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Hello,
This patch needs the following series to work:
- twl regmap IO conversion series:
http://lkml.org/lkml/2012/11/13/97
- PWM drivers for twl4030/6030 (v2):
https://lkml.org/lkml/2012/11/8/219
- leds-pwm series (v2):
https://lkml.org/lkml/2012/11/12/222
With these in place we can have keypad light and LCD backlight working on Blaze
when booting in legacy mode.
I will send the DT patches after the leds-pwm DT support has been accepted.
Regards,
Peter
arch/arm/mach-omap2/board-4430sdp.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..8cf781e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -24,8 +24,10 @@
#include <linux/gpio_keys.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
+#include <linux/pwm.h>
#include <linux/leds.h>
#include <linux/leds_pwm.h>
+#include <linux/pwm_backlight.h>
#include <linux/platform_data/omap4-keypad.h>
#include <asm/hardware/gic.h>
@@ -263,10 +265,20 @@ static struct gpio_led_platform_data sdp4430_led_data = {
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static struct pwm_lookup sdp4430_pwm_lookup[] = {
+ PWM_LOOKUP("twl-pwm", 0, "leds_pwm", "omap4::keypad"),
+ PWM_LOOKUP("twl-pwm", 1, "pwm-backlight", "backlight"),
+ PWM_LOOKUP("twl-pwmled", 0, "leds_pwm", "omap4:green:chrg"),
+};
+
static struct led_pwm sdp4430_pwm_leds[] = {
{
+ .name = "omap4::keypad",
+ .max_brightness = 127,
+ .pwm_period_ns = 7812500,
+ },
+ {
.name = "omap4:green:chrg",
- .pwm_id = 1,
.max_brightness = 255,
.pwm_period_ns = 7812500,
},
@@ -285,6 +297,21 @@ static struct platform_device sdp4430_leds_pwm = {
},
};
+static struct platform_pwm_backlight_data sdp4430_backlight_data = {
+ .pwm_id = 1,
+ .max_brightness = 127,
+ .dft_brightness = 127,
+ .pwm_period_ns = 7812500,
+};
+
+static struct platform_device sdp4430_backlight_pwm = {
+ .name = "pwm-backlight",
+ .id = -1,
+ .dev = {
+ .platform_data = &sdp4430_backlight_data,
+ },
+};
+
static int omap_prox_activate(struct device *dev)
{
gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
@@ -419,6 +446,7 @@ static struct platform_device *sdp4430_devices[] __initdata = {
&sdp4430_gpio_keys_device,
&sdp4430_leds_gpio,
&sdp4430_leds_pwm,
+ &sdp4430_backlight_pwm,
&sdp4430_vbat,
&sdp4430_dmic_codec,
&sdp4430_abe_audio,
@@ -862,6 +890,7 @@ static void __init omap_4430sdp_init(void)
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ pwm_add_table(sdp4430_pwm_lookup, ARRAY_SIZE(sdp4430_pwm_lookup));
status = omap4_keyboard_init(&sdp4430_keypad_data, &keypad_data);
if (status)
pr_err("Keypad initialization failed: %d\n", status);
--
1.8.0
^ permalink raw reply related
* [PATCH] i2c: i2c-s3c2410: Add support for pinctrl
From: Tomasz Figa @ 2012-11-13 10:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for pin configuration using pinctrl subsystem
to the i2c-s3c2410 driver.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
.../devicetree/bindings/i2c/samsung-i2c.txt | 20 ++++++++++++++++----
drivers/i2c/busses/i2c-s3c2410.c | 12 ++++++++----
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
index b6cb5a1..e9611ac 100644
--- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt
@@ -13,11 +13,17 @@ Required properties:
- interrupts: interrupt number to the cpu.
- samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges.
+Required for all cases except "samsung,s3c2440-hdmiphy-i2c":
+ - Samsung GPIO variant (deprecated):
+ - gpios: The order of the gpios should be the following: <SDA, SCL>.
+ The gpio specifier depends on the gpio controller. Required in all
+ cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
+ lines are permanently wired to the respective clienta
+ - Pinctrl variant (preferred, if available):
+ - pinctrl-0: Pin control group to be used for this controller.
+ - pinctrl-names: Should contain only one value - "default".
+
Optional properties:
- - gpios: The order of the gpios should be the following: <SDA, SCL>.
- The gpio specifier depends on the gpio controller. Required in all
- cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
- lines are permanently wired to the respective client
- samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
@@ -31,8 +37,14 @@ Example:
interrupts = <345>;
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <100000>;
+ /* Samsung GPIO variant begins here */
gpios = <&gpd1 2 0 /* SDA */
&gpd1 3 0 /* SCL */>;
+ /* Samsung GPIO variant ends here */
+ /* Pinctrl variant begins here */
+ pinctrl-0 = <&i2c3_bus>;
+ pinctrl-names = "default";
+ /* Pinctrl variant ends here */
#address-cells = <1>;
#size-cells = <0>;
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 3e0335f..ae4304b 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -38,6 +38,7 @@
#include <linux/io.h>
#include <linux/of_i2c.h>
#include <linux/of_gpio.h>
+#include <linux/pinctrl/consumer.h>
#include <asm/irq.h>
@@ -83,6 +84,7 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
+ struct pinctrl *pctrl;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -861,9 +863,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
if (pdata->cfg_gpio)
pdata->cfg_gpio(to_platform_device(i2c->dev));
- else
- if (s3c24xx_i2c_parse_dt_gpio(i2c))
- return -EINVAL;
+ else if (IS_ERR(i2c->pctrl) && s3c24xx_i2c_parse_dt_gpio(i2c))
+ return -EINVAL;
/* write slave address */
@@ -1013,6 +1014,8 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
i2c->adap.algo_data = i2c;
i2c->adap.dev.parent = &pdev->dev;
+ i2c->pctrl = devm_pinctrl_get_select_default(i2c->dev);
+
/* initialise the i2c controller */
ret = s3c24xx_i2c_init(i2c);
@@ -1112,7 +1115,8 @@ static int s3c24xx_i2c_remove(struct platform_device *pdev)
iounmap(i2c->regs);
release_resource(i2c->ioarea);
- s3c24xx_i2c_dt_gpio_free(i2c);
+ if (pdev->dev.of_node && IS_ERR(i2c->pctrl))
+ s3c24xx_i2c_dt_gpio_free(i2c);
kfree(i2c->ioarea);
return 0;
--
1.8.0
^ permalink raw reply related
* [GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2
From: Arnd Bergmann @ 2012-11-13 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113100144.GX18224@opensource.wolfsonmicro.com>
On Tuesday 13 November 2012, Mark Brown wrote:
> On Tue, Nov 13, 2012 at 08:48:03AM +0000, Arnd Bergmann wrote:
> > On Tuesday 13 November 2012, Mark Brown wrote:
>
> > > Please never pull anything from me unless there's a signed tag for it,
> > > anything else I won't know about and may be rebased or vanish or
> > > something.
>
> > Ok, thanks for the reminder. Do you have a signed tag containing ab6f6d8521?
>
> Nope, your e-mail was the first I'd heard of the cross-merge. I guess I
> could create one if this is going to get redone for some reason...
I'm not planning to pull this one into somewhere else, just want to make
sure that you remeber it's been pulled into arm-soc. You mentioned above
that having a tag helps you with your bookkeeping.
Arnd
^ permalink raw reply
* [PATCH v2 2/5] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-11-13 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112172753.GB2111@linaro.org>
On Mon, Nov 12, 2012 at 05:27:53PM +0000, Dave Martin wrote:
> On Fri, Nov 09, 2012 at 02:34:11PM +0000, Lorenzo Pieralisi wrote:
[...]
> > +Every cpu node is required to set its device_type to "cpu".
> > +
> > +Example:
> > +
> > + cpus {
> > + #size-cells = <0>;
> > + #address-cells = <1>;
> > +
> > + CPU0: cpu at 0 {
> > + device_type = "cpu";
> > + compatible = <arm, cortex-a15>;
> > + reg = <0x0>;
> > + };
> > +
> > + CPU1: cpu at 1 {
> > + device_type = "cpu";
> > + compatible = <arm, cortex-a15>;
> > + reg = <0x1>;
> > + };
> > +
> > + CPU2: cpu at 100 {
> > + device_type = "cpu";
> > + compatible = <arm, cortex-a7>;
> > + reg = <0x100>;
> > + };
> > +
> > + CPU3: cpu at 101 {
>
> Should we document the unit address convention as part of the binding
> documentation?
>
> Using the MPIDR value here is a bit cumbersome, but I'm not sure if
> there's a better alternative, unless we make a multi-element vector
> out of the MPIDR to use as the address -- sounds like overkill.
I just followed the booting-without-of.txt convention for /cpu nodes,
where the unit-address is just the reg property stripped of its leading
zeros. I think it is the default way of defining the unit-address I do not
know if I need to add to this, I certainly can.
> > + device_type = "cpu";
> > + compatible = <arm, cortex-a7>;
> > + reg = <0x101>;
> > + };
> > + };
> > diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> > index aeae9c6..8dd51dc 100644
> > --- a/arch/arm/include/asm/prom.h
> > +++ b/arch/arm/include/asm/prom.h
> > @@ -15,6 +15,7 @@
> >
> > extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> > extern void arm_dt_memblock_reserve(void);
> > +extern void __init arm_dt_init_cpu_maps(void);
> >
> > #else /* CONFIG_OF */
> >
> > @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
> > }
> >
> > static inline void arm_dt_memblock_reserve(void) { }
> > +static inline void arm_dt_init_cpu_maps(void) { }
> >
> > #endif /* CONFIG_OF */
> > #endif /* ASMARM_PROM_H */
> > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > index bee7f9d..d64d222 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -19,8 +19,10 @@
> > #include <linux/of_irq.h>
> > #include <linux/of_platform.h>
> >
> > +#include <asm/cputype.h>
> > #include <asm/setup.h>
> > #include <asm/page.h>
> > +#include <asm/smp_plat.h>
> > #include <asm/mach/arch.h>
> > #include <asm/mach-types.h>
> >
> > @@ -61,6 +63,80 @@ void __init arm_dt_memblock_reserve(void)
> > }
> > }
> >
> > +/*
> > + * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
> > + * and builds the cpu logical map array containing MPIDR values related to
> > + * logical cpus
> > + *
> > + * Updates the cpu possible mask with the number of parsed cpu nodes
> > + */
>
> Can this function sanity-check that we do not assign the same MPIDR
> value for multiple logical CPUs?
>
> It turns out to be surprisingly easy to write a DT with duplicate reg
> properties in the CPUs node due to careless cut-and-paste. (i.e., I
> did it, but have been getting away with it up to now).
Check added. Waiting for some comments on the compatible list of ids to
post v3.
Thanks a lot,
Lorenzo
^ permalink raw reply
* [GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2
From: Mark Brown @ 2012-11-13 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211130848.03800.arnd@arndb.de>
On Tue, Nov 13, 2012 at 08:48:03AM +0000, Arnd Bergmann wrote:
> On Tuesday 13 November 2012, Mark Brown wrote:
> > Please never pull anything from me unless there's a signed tag for it,
> > anything else I won't know about and may be rebased or vanish or
> > something.
> Ok, thanks for the reminder. Do you have a signed tag containing ab6f6d8521?
Nope, your e-mail was the first I'd heard of the cross-merge. I guess I
could create one if this is going to get redone for some reason...
> > > I have taken Mark on Cc to let him know about the dependency now, and I've
> > > merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
> > > specific ASoC patches) into the next/boards2 branch before merging your
> > > branch. This is still not perfect because it breaks bisection, but it's
> > > the best I could do aside from forcing you do do another round-trip.
> > What's the bisection problem?
> I merged ab6f6d8521 first, and then Simon's branch, which means that the
> linear (first-parent) history is ok, but bisecting the entire state of
> the tree may end up in a commit in his branch in a state before it was
> merged into mine, where it doesn't contain the patches it depends on,
> and as Simon mentioned in his pull request, that will cause a build
> failure.
Oh, I'd missed the fact that this wasn't coming in via a merge into
Simon's tree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/498f1a12/attachment.sig>
^ permalink raw reply
* [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Bo Shen @ 2012-11-13 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113094145.GV18224@opensource.wolfsonmicro.com>
On 11/13/2012 17:41, Mark Brown wrote:
> On Tue, Nov 13, 2012 at 05:38:04PM +0800, Bo Shen wrote:
>> On 11/13/2012 17:20, Mark Brown wrote:
>
>>> The machine driver should know which SSC it is using all by itself, it's
>>> specific to a particular machine. This is how it's been doing it since
>>> it was written...
>
>> So, you mean, I should hard code this into machine driver, am I right?
>
> Yes, exactly.
Ok, I will hard code it.
Thanks.
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH] ARM: backtrace: avoid crash on large invalid fp value
From: Dave Martin @ 2012-11-13 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRQM5FyGum1s-YE+e4XrnqHn+acH89fjJsoMLGueKjhepQ@mail.gmail.com>
On Fri, Nov 09, 2012 at 10:17:01AM -0800, Colin Cross wrote:
> On Fri, Nov 9, 2012 at 2:56 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > On Thu, Nov 08, 2012 at 06:05:52PM -0800, Colin Cross wrote:
> >> On Mon, Nov 5, 2012 at 2:54 AM, Dave Martin <dave.martin@linaro.org> wrote:
> >> > On Fri, Nov 02, 2012 at 04:47:38PM -0700, Colin Cross wrote:
> >> >> On Wed, Oct 10, 2012 at 4:15 AM, Dave Martin <dave.martin@linaro.org> wrote:
> >> >> > On Tue, Oct 09, 2012 at 11:46:12PM -0700, Todd Poynor wrote:
> >> >> >> Invalid frame pointer (signed) -4 <= fp <= -1 defeats check for too high
> >> >> >> on overflow.
> >> >> >>
> >> >> >> Signed-off-by: Todd Poynor <toddpoynor@google.com>
> >> >> >> ---
> >> >> >> arch/arm/kernel/stacktrace.c | 2 +-
> >> >> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >> >>
> >> >> >> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> >> >> >> index 00f79e5..6315162 100644
> >> >> >> --- a/arch/arm/kernel/stacktrace.c
> >> >> >> +++ b/arch/arm/kernel/stacktrace.c
> >> >> >> @@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackframe *frame)
> >> >> >> high = ALIGN(low, THREAD_SIZE);
> >> >> >>
> >> >> >> /* check current frame pointer is within bounds */
> >> >> >> - if (fp < (low + 12) || fp + 4 >= high)
> >> >> >> + if (fp < (low + 12) || fp >= high - 4)
> >> >> >> return -EINVAL;
> >> >> >>
> >> >> >> /* restore the registers from the stack frame */
> >> >> >
> >> >> > sp and fp can still be complete garbage in the case of a corrupted frame,
> >> >> > so low + 12 can still overflow and cause us to read beyond the stack base.
> >> >> >
> >> >> > A more robust patch might be as follows. This also checks for misaligned
> >> >> > fp and sp values, since those indicate corruption and there can be no
> >> >> > sensible way to interpret the resulting frame in that case.
> >> >> >
> >> >> > Also, according to the definition of current_thread_info(),
> >> >> > IS_ALIGNED(sp, THREAD_SIZE) indicates a full stack extending from sp
> >> >> > to sp + THREAD_SIZE, and not an empty stack extending from sp -
> >> >> > THREAD_SIZE to sp. We cannot backtrace this situation anyway, since
> >> >> > that would imply that the frame record extends beyond the stack...
> >> >> > but this patch tidies it up in the interest of clarity.
> >> >> >
> >> >> > Cheers
> >> >> > ---Dave
> >> >> >
> >> >> > (untested)
> >> >> >
> >> >> > diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> >> >> > index 00f79e5..fec82be 100644
> >> >> > --- a/arch/arm/kernel/stacktrace.c
> >> >> > +++ b/arch/arm/kernel/stacktrace.c
> >> >> > @@ -28,10 +28,20 @@ int notrace unwind_frame(struct stackframe *frame)
> >> >> >
> >> >> > /* only go to a higher address on the stack */
> >> >> > low = frame->sp;
> >> >> > - high = ALIGN(low, THREAD_SIZE);
> >> >> > + if (!IS_ALIGNED(fp, 4))
> >> >> > + return -EINVAL;
> >> >> > +
> >> >> > + /*
> >> >> > + * low + 1 here ensures that high > sp, consistent with the
> >> >> > + * definition of current_thread_info().
> >> >> > + * We subtract 1 to compute the highest allowable byte address.
> >> >> > + * Otherwise, we might get high == 0 which would confuse our
> >> >> > + * comparisons.
> >> >> > + */
> >> >> > + high = ALIGN(low + 1, THREAD_SIZE) - 1;
> >>
> >> ARM eabi stacks are full-descending, meaning that if the sp is a
> >> multiple of THREAD_SIZE, the stack is empty. current_thread_info
> >> takes a short-cut and assumes it can never be called on an empty
> >> stack, but better not to propagate that anywhere else.
> >
> > The effect of the code is consistent with current_thread_info():
> >
> > low = THREAD_SIZE * X --> high = THREAD_SIZE * (X + 1) - 1
> > low = THREAD_SIZE * (X + 1) - 1 --> high = THREAD_SIZE * (X + 1) - 1
> >
> > i.e., low = THREAD_SIZE * X is treated as a full stack.
>
> current_thread_info() is assuming a sane stack, where the sp is
> between [THREAD_SIZE * X + sizeof(struct thread_info), THREAD_SIZE *
> (X + 1) - 8] (see THREAD_START_SP). It should never see sp =
> THREAD_SIZE * X, so we shouldn't be copying its behavior in that case.
>
> sp = THREAD_SIZE * x being a full stack would mean that the stack has
> passed all the way through the struct thread_info stored at the lower
> addresses of the stack, corrupting the task struct, saved registers,
> and likely the stack too. On the other hand, sp = THREAD_SIZE * x
> being an empty stack would mean somebody started a stack higher than
> THREAD_START_SP. Neither one really makes sense, maybe I should just
> validate the sp above the thread_info and below THREAD_START_SP.
>
> > The comment relates to the case where the stack is right at the top
> > of the address space: if we define high as ALIGN(low + 1, THREAD_SIZE),
> > then high overflow to zero in this case, giving unexpected results
> > for comparisons "some_address >= high".
> >
> > Definig high as the address of the last byte of the stack (instead of
> > the first byte after the stack) avoids this kind of problem, providing
> > that "some_address >= high" is rewritten as "some_address > high" in
> > our comparisons.
>
> I agree with using - 1 (or - 4) to prevent high wrapping, but maybe
> capping at THREAD_START_SP would simplify the code.
Having a more precise check as you describe seems to be a good thing.
I'm happy to go with your judgement.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 2/3] serial: mxs-auart: add the DMA support for mx28
From: Lauri Hintsala @ 2012-11-13 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351074456-25863-3-git-send-email-b32955@freescale.com>
Hi Huang,
DMA support doesn't work with latest stable v3.6.5 or development
3.7-rc5 kernels. I get following error message when I open the serial
port /dev/ttyAPP0:
[ 48.730000] mxs-auart 8006a000.serial: step 1 error
[ 48.750000] mxs-auart 8006a000.serial: We can not start up the DMA.
On 10/24/2012 01:27 PM, Huang Shijie wrote:
> Only we meet the following conditions, we can enable the DMA support for
> auart:
>
> (1) We enable the DMA support in the dts file, such as
> arch/arm/boot/dts/imx28.dtsi.
>
> (2) We enable the hardware flow control.
Why HW flow control is required?
We need high speed auart without flow control. I have tested kernel from
Freescale's BSP and the performance was good without HW flow control.
Best Regards,
Lauri Hintsala
> (3) We use the mx28, not the mx23. Due to hardware bug(see errata: 2836),
> we can not add the DMA support to mx23.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
> .../bindings/tty/serial/fsl-mxs-auart.txt | 8 +
> drivers/tty/serial/mxs-auart.c | 318 +++++++++++++++++++-
> 2 files changed, 321 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> index 2ee903f..273a8d5 100644
> --- a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt
> @@ -6,11 +6,19 @@ Required properties:
> - reg : Address and length of the register set for the device
> - interrupts : Should contain the auart interrupt numbers
>
> +Optional properties:
> +- fsl,auart-dma-channel : The DMA channels, the first is for RX, the other
> + is for TX. If you add this property, it also means that you
> + will enable the DMA support for the auart.
> + Note: due to the hardware bug in imx23(see errata : 2836),
> + only the imx28 can enable the DMA support for the auart.
> +
> Example:
> auart0: serial at 8006a000 {
> compatible = "fsl,imx28-auart", "fsl,imx23-auart";
> reg = <0x8006a000 0x2000>;
> interrupts = <112 70 71>;
> + fsl,auart-dma-channel = <8 9>;
> };
>
> Note: Each auart port should have an alias correctly numbered in "aliases"
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 06d7271..d593e0a 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -34,6 +34,8 @@
> #include <linux/io.h>
> #include <linux/pinctrl/consumer.h>
> #include <linux/of_device.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/fsl/mxs-dma.h>
>
> #include <asm/cacheflush.h>
>
> @@ -71,6 +73,15 @@
>
> #define AUART_CTRL0_SFTRST (1 << 31)
> #define AUART_CTRL0_CLKGATE (1 << 30)
> +#define AUART_CTRL0_RXTO_ENABLE (1 << 27)
> +#define AUART_CTRL0_RXTIMEOUT(v) (((v) & 0x7ff) << 16)
> +#define AUART_CTRL0_XFER_COUNT(v) ((v) & 0xffff)
> +
> +#define AUART_CTRL1_XFER_COUNT(v) ((v) & 0xffff)
> +
> +#define AUART_CTRL2_DMAONERR (1 << 26)
> +#define AUART_CTRL2_TXDMAE (1 << 25)
> +#define AUART_CTRL2_RXDMAE (1 << 24)
>
> #define AUART_CTRL2_CTSEN (1 << 15)
> #define AUART_CTRL2_RTSEN (1 << 14)
> @@ -111,6 +122,7 @@
> #define AUART_STAT_BERR (1 << 18)
> #define AUART_STAT_PERR (1 << 17)
> #define AUART_STAT_FERR (1 << 16)
> +#define AUART_STAT_RXCOUNT_MASK 0xffff
>
> static struct uart_driver auart_driver;
>
> @@ -122,7 +134,10 @@ enum mxs_auart_type {
> struct mxs_auart_port {
> struct uart_port port;
>
> - unsigned int flags;
> +#define MXS_AUART_DMA_CONFIG 0x1
> +#define MXS_AUART_DMA_ENABLED 0x2
> +#define MXS_AUART_DMA_TX_SYNC 2 /* bit 2 */
> + unsigned long flags;
> unsigned int ctrl;
> enum mxs_auart_type devtype;
>
> @@ -130,6 +145,20 @@ struct mxs_auart_port {
>
> struct clk *clk;
> struct device *dev;
> +
> + /* for DMA */
> + struct mxs_dma_data dma_data;
> + int dma_channel_rx, dma_channel_tx;
> + int dma_irq_rx, dma_irq_tx;
> + int dma_channel;
> +
> + struct scatterlist tx_sgl;
> + struct dma_chan *tx_dma_chan;
> + void *tx_dma_buf;
> +
> + struct scatterlist rx_sgl;
> + struct dma_chan *rx_dma_chan;
> + void *rx_dma_buf;
> };
>
> static struct platform_device_id mxs_auart_devtype[] = {
> @@ -155,14 +184,107 @@ static inline int is_imx28_auart(struct mxs_auart_port *s)
> return s->devtype == IMX28_AUART;
> }
>
> +static inline bool auart_dma_enabled(struct mxs_auart_port *s)
> +{
> + return s->flags & MXS_AUART_DMA_ENABLED;
> +}
> +
> static void mxs_auart_stop_tx(struct uart_port *u);
>
> #define to_auart_port(u) container_of(u, struct mxs_auart_port, port)
>
> -static inline void mxs_auart_tx_chars(struct mxs_auart_port *s)
> +static void mxs_auart_tx_chars(struct mxs_auart_port *s);
> +
> +static void dma_tx_callback(void *param)
> {
> + struct mxs_auart_port *s = param;
> struct circ_buf *xmit = &s->port.state->xmit;
>
> + dma_unmap_sg(s->dev, &s->tx_sgl, 1, DMA_TO_DEVICE);
> +
> + /* clear the bit used to serialize the DMA tx. */
> + clear_bit(MXS_AUART_DMA_TX_SYNC, &s->flags);
> + smp_mb__after_clear_bit();
> +
> + /* wake up the possible processes. */
> + if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> + uart_write_wakeup(&s->port);
> +
> + mxs_auart_tx_chars(s);
> +}
> +
> +static int mxs_auart_dma_tx(struct mxs_auart_port *s, int size)
> +{
> + struct dma_async_tx_descriptor *desc;
> + struct scatterlist *sgl = &s->tx_sgl;
> + struct dma_chan *channel = s->tx_dma_chan;
> + u32 pio;
> +
> + /* [1] : send PIO. Note, the first pio word is CTRL1. */
> + pio = AUART_CTRL1_XFER_COUNT(size);
> + desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)&pio,
> + 1, DMA_TRANS_NONE, 0);
> + if (!desc) {
> + dev_err(s->dev, "step 1 error\n");
> + return -EINVAL;
> + }
> +
> + /* [2] : set DMA buffer. */
> + sg_init_one(sgl, s->tx_dma_buf, size);
> + dma_map_sg(s->dev, sgl, 1, DMA_TO_DEVICE);
> + desc = dmaengine_prep_slave_sg(channel, sgl,
> + 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!desc) {
> + dev_err(s->dev, "step 2 error\n");
> + return -EINVAL;
> + }
> +
> + /* [3] : submit the DMA */
> + desc->callback = dma_tx_callback;
> + desc->callback_param = s;
> + dmaengine_submit(desc);
> + dma_async_issue_pending(channel);
> + return 0;
> +}
> +
> +static void mxs_auart_tx_chars(struct mxs_auart_port *s)
> +{
> + struct circ_buf *xmit = &s->port.state->xmit;
> +
> + if (auart_dma_enabled(s)) {
> + int i = 0;
> + int size;
> + void *buffer = s->tx_dma_buf;
> +
> + if (test_and_set_bit(MXS_AUART_DMA_TX_SYNC, &s->flags))
> + return;
> +
> + while (!uart_circ_empty(xmit) && !uart_tx_stopped(&s->port)) {
> + size = min_t(u32, UART_XMIT_SIZE - i,
> + CIRC_CNT_TO_END(xmit->head,
> + xmit->tail,
> + UART_XMIT_SIZE));
> + memcpy(buffer + i, xmit->buf + xmit->tail, size);
> + xmit->tail = (xmit->tail + size) & (UART_XMIT_SIZE - 1);
> +
> + i += size;
> + if (i >= UART_XMIT_SIZE)
> + break;
> + }
> +
> + if (uart_tx_stopped(&s->port))
> + mxs_auart_stop_tx(&s->port);
> +
> + if (i) {
> + mxs_auart_dma_tx(s, i);
> + } else {
> + clear_bit(MXS_AUART_DMA_TX_SYNC, &s->flags);
> + smp_mb__after_clear_bit();
> + }
> + return;
> + }
> +
> +
> while (!(readl(s->port.membase + AUART_STAT) &
> AUART_STAT_TXFF)) {
> if (s->port.x_char) {
> @@ -316,10 +438,155 @@ static u32 mxs_auart_get_mctrl(struct uart_port *u)
> return mctrl;
> }
>
> +static bool mxs_auart_dma_filter(struct dma_chan *chan, void *param)
> +{
> + struct mxs_auart_port *s = param;
> +
> + if (!mxs_dma_is_apbx(chan))
> + return false;
> +
> + if (s->dma_channel == chan->chan_id) {
> + chan->private = &s->dma_data;
> + return true;
> + }
> + return false;
> +}
> +
> +static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s);
> +static void dma_rx_callback(void *arg)
> +{
> + struct mxs_auart_port *s = (struct mxs_auart_port *) arg;
> + struct tty_struct *tty = s->port.state->port.tty;
> + int count;
> + u32 stat;
> +
> + stat = readl(s->port.membase + AUART_STAT);
> + stat &= ~(AUART_STAT_OERR | AUART_STAT_BERR |
> + AUART_STAT_PERR | AUART_STAT_FERR);
> +
> + count = stat & AUART_STAT_RXCOUNT_MASK;
> + tty_insert_flip_string(tty, s->rx_dma_buf, count);
> +
> + writel(stat, s->port.membase + AUART_STAT);
> + tty_flip_buffer_push(tty);
> +
> + /* start the next DMA for RX. */
> + mxs_auart_dma_prep_rx(s);
> +}
> +
> +static int mxs_auart_dma_prep_rx(struct mxs_auart_port *s)
> +{
> + struct dma_async_tx_descriptor *desc;
> + struct scatterlist *sgl = &s->rx_sgl;
> + struct dma_chan *channel = s->rx_dma_chan;
> + u32 pio[1];
> +
> + /* [1] : send PIO */
> + pio[0] = AUART_CTRL0_RXTO_ENABLE
> + | AUART_CTRL0_RXTIMEOUT(0x80)
> + | AUART_CTRL0_XFER_COUNT(UART_XMIT_SIZE);
> + desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)pio,
> + 1, DMA_TRANS_NONE, 0);
> + if (!desc) {
> + dev_err(s->dev, "step 1 error\n");
> + return -EINVAL;
> + }
> +
> + /* [2] : send DMA request */
> + sg_init_one(sgl, s->rx_dma_buf, UART_XMIT_SIZE);
> + dma_map_sg(s->dev, sgl, 1, DMA_FROM_DEVICE);
> + desc = dmaengine_prep_slave_sg(channel, sgl, 1, DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!desc) {
> + dev_err(s->dev, "step 2 error\n");
> + return -1;
> + }
> +
> + /* [3] : submit the DMA, but do not issue it. */
> + desc->callback = dma_rx_callback;
> + desc->callback_param = s;
> + dmaengine_submit(desc);
> + dma_async_issue_pending(channel);
> + return 0;
> +}
> +
> +static void mxs_auart_dma_exit_channel(struct mxs_auart_port *s)
> +{
> + if (s->tx_dma_chan) {
> + dma_release_channel(s->tx_dma_chan);
> + s->tx_dma_chan = NULL;
> + }
> + if (s->rx_dma_chan) {
> + dma_release_channel(s->rx_dma_chan);
> + s->rx_dma_chan = NULL;
> + }
> +
> + kfree(s->tx_dma_buf);
> + kfree(s->rx_dma_buf);
> + s->tx_dma_buf = NULL;
> + s->rx_dma_buf = NULL;
> +}
> +
> +static void mxs_auart_dma_exit(struct mxs_auart_port *s)
> +{
> +
> + writel(AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE | AUART_CTRL2_DMAONERR,
> + s->port.membase + AUART_CTRL2_CLR);
> +
> + mxs_auart_dma_exit_channel(s);
> + s->flags &= ~MXS_AUART_DMA_ENABLED;
> +}
> +
> +static int mxs_auart_dma_init(struct mxs_auart_port *s)
> +{
> + dma_cap_mask_t mask;
> +
> + if (auart_dma_enabled(s))
> + return 0;
> +
> + /* We do not get the right DMA channels. */
> + if (s->dma_channel_rx == -1 || s->dma_channel_rx == -1)
> + return -EINVAL;
> +
> + /* init for RX */
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_SLAVE, mask);
> + s->dma_channel = s->dma_channel_rx;
> + s->dma_data.chan_irq = s->dma_irq_rx;
> + s->rx_dma_chan = dma_request_channel(mask, mxs_auart_dma_filter, s);
> + if (!s->rx_dma_chan)
> + goto err_out;
> + s->rx_dma_buf = kzalloc(UART_XMIT_SIZE, GFP_KERNEL | GFP_DMA);
> + if (!s->rx_dma_buf)
> + goto err_out;
> +
> + /* init for TX */
> + s->dma_channel = s->dma_channel_tx;
> + s->dma_data.chan_irq = s->dma_irq_tx;
> + s->tx_dma_chan = dma_request_channel(mask, mxs_auart_dma_filter, s);
> + if (!s->tx_dma_chan)
> + goto err_out;
> + s->tx_dma_buf = kzalloc(UART_XMIT_SIZE, GFP_KERNEL | GFP_DMA);
> + if (!s->tx_dma_buf)
> + goto err_out;
> +
> + /* set the flags */
> + s->flags |= MXS_AUART_DMA_ENABLED;
> + dev_dbg(s->dev, "enabled the DMA support.");
> +
> + return 0;
> +
> +err_out:
> + mxs_auart_dma_exit_channel(s);
> + return -EINVAL;
> +
> +}
> +
> static void mxs_auart_settermios(struct uart_port *u,
> struct ktermios *termios,
> struct ktermios *old)
> {
> + struct mxs_auart_port *s = to_auart_port(u);
> u32 bm, ctrl, ctrl2, div;
> unsigned int cflag, baud;
>
> @@ -391,10 +658,23 @@ static void mxs_auart_settermios(struct uart_port *u,
> ctrl |= AUART_LINECTRL_STP2;
>
> /* figure out the hardware flow control settings */
> - if (cflag & CRTSCTS)
> + if (cflag & CRTSCTS) {
> + /*
> + * The DMA has a bug(see errata:2836) in mx23.
> + * So we can not implement the DMA for auart in mx23,
> + * we can only implement the DMA support for auart
> + * in mx28.
> + */
> + if (is_imx28_auart(s) && (s->flags & MXS_AUART_DMA_CONFIG)) {
> + if (!mxs_auart_dma_init(s))
> + /* enable DMA tranfer */
> + ctrl2 |= AUART_CTRL2_TXDMAE | AUART_CTRL2_RXDMAE
> + | AUART_CTRL2_DMAONERR;
> + }
> ctrl2 |= AUART_CTRL2_CTSEN | AUART_CTRL2_RTSEN;
> - else
> + } else {
> ctrl2 &= ~(AUART_CTRL2_CTSEN | AUART_CTRL2_RTSEN);
> + }
>
> /* set baud rate */
> baud = uart_get_baud_rate(u, termios, old, 0, u->uartclk);
> @@ -406,6 +686,17 @@ static void mxs_auart_settermios(struct uart_port *u,
> writel(ctrl2, u->membase + AUART_CTRL2);
>
> uart_update_timeout(u, termios->c_cflag, baud);
> +
> + /* prepare for the DMA RX. */
> + if (auart_dma_enabled(s)) {
> + if (!mxs_auart_dma_prep_rx(s)) {
> + /* Disable the normal RX interrupt. */
> + writel(AUART_INTR_RXIEN, u->membase + AUART_INTR_CLR);
> + } else {
> + mxs_auart_dma_exit(s);
> + dev_err(s->dev, "We can not start up the DMA.\n");
> + }
> + }
> }
>
> static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
> @@ -484,6 +775,9 @@ static void mxs_auart_shutdown(struct uart_port *u)
> {
> struct mxs_auart_port *s = to_auart_port(u);
>
> + if (auart_dma_enabled(s))
> + mxs_auart_dma_exit(s);
> +
> writel(AUART_CTRL2_UARTEN, u->membase + AUART_CTRL2_CLR);
>
> writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
> @@ -717,6 +1011,7 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
> struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> + u32 dma_channel[2];
> int ret;
>
> if (!np)
> @@ -730,6 +1025,20 @@ static int serial_mxs_probe_dt(struct mxs_auart_port *s,
> }
> s->port.line = ret;
>
> + s->dma_irq_rx = platform_get_irq(pdev, 1);
> + s->dma_irq_tx = platform_get_irq(pdev, 2);
> +
> + ret = of_property_read_u32_array(np, "fsl,auart-dma-channel",
> + dma_channel, 2);
> + if (ret == 0) {
> + s->dma_channel_rx = dma_channel[0];
> + s->dma_channel_tx = dma_channel[1];
> +
> + s->flags |= MXS_AUART_DMA_CONFIG;
> + } else {
> + s->dma_channel_rx = -1;
> + s->dma_channel_tx = -1;
> + }
> return 0;
> }
>
> @@ -787,7 +1096,6 @@ static int __devinit mxs_auart_probe(struct platform_device *pdev)
> s->port.type = PORT_IMX;
> s->port.dev = s->dev = get_device(&pdev->dev);
>
> - s->flags = 0;
> s->ctrl = 0;
>
> s->irq = platform_get_irq(pdev, 0);
>
^ permalink raw reply
* [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Mark Brown @ 2012-11-13 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A214FC.90201@atmel.com>
On Tue, Nov 13, 2012 at 05:38:04PM +0800, Bo Shen wrote:
> On 11/13/2012 17:20, Mark Brown wrote:
> >The machine driver should know which SSC it is using all by itself, it's
> >specific to a particular machine. This is how it's been doing it since
> >it was written...
> So, you mean, I should hard code this into machine driver, am I right?
Yes, exactly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/eb88c307/attachment.sig>
^ permalink raw reply
* [PATCH v5 2/3] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Bo Shen @ 2012-11-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113092038.GU18224@opensource.wolfsonmicro.com>
On 11/13/2012 17:20, Mark Brown wrote:
> On Tue, Nov 13, 2012 at 05:10:26PM +0800, Bo Shen wrote:
>> On 11/13/2012 16:30, Mark Brown wrote:
>
>>> Why are you changing this? Single devices are supposed to specify -1 as
>>> their id.
>
>> This is for non-dt support, using the id to tell which ssc will be
>> used to remap into audio subsystem. Maybe this is a mixed up usage,
>> however I can not find good solution, any suggestions?
>
> The machine driver should know which SSC it is using all by itself, it's
> specific to a particular machine. This is how it's been doing it since
> it was written...
So, you mean, I should hard code this into machine driver, am I right?
>> This is a similar implement as 7840487cd6298f9f931103b558290d8d98d41c49
>
> Don't quote raw commit IDs, they're not legible by humans.
>
>> Yes, this patch is a little more than registration, however when
>> change the registration method, the related code will be affected,
>> so also clean up them in this patch, do I need to split this patch?
>
> Yes, one change per patch. Having many unrelated changes in one patch
> makes it very difficult to review anything.
OK, I will split this patch.
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH] ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER
From: Peter Ujfalusi @ 2012-11-13 9:32 UTC (permalink / raw)
To: linux-arm-kernel
To facilitate upcoming cleanup in twl stack.
No functional change.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-omap2/omap_twl.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 2bf35dc..018abb4 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -337,8 +337,8 @@ int __init omap3_twl_set_sr_bit(bool enable)
if (twl_sr_enable_autoinit)
pr_warning("%s: unexpected multiple calls\n", __func__);
- ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, &temp,
- TWL4030_DCDC_GLOBAL_CFG);
+ ret = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER, &temp,
+ TWL4030_DCDC_GLOBAL_CFG);
if (ret)
goto err;
@@ -347,8 +347,8 @@ int __init omap3_twl_set_sr_bit(bool enable)
else
temp &= ~SMARTREFLEX_ENABLE;
- ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
- TWL4030_DCDC_GLOBAL_CFG);
+ ret = twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
if (!ret) {
twl_sr_enable_autoinit = true;
return 0;
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: dts: exynos4210-trats: Remove broken-voltage property from sdhci node
From: Tomasz Figa @ 2012-11-13 9:27 UTC (permalink / raw)
To: linux-arm-kernel
The broken voltage property has been replaced with auto detection based
on voltages available on vmmc voltage regulator, so there is no use for
it now.
This patch removes the now unused property from Trats Device Tree
sources.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/boot/dts/exynos4210-trats.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts
index a21511c..9d5d27a 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -42,7 +42,6 @@
sdhci_emmc: sdhci at 12510000 {
bus-width = <8>;
non-removable;
- broken-voltage;
gpios = <&gpk0 0 2 0 3>,
<&gpk0 1 2 0 3>,
<&gpk0 3 2 2 3>,
--
1.8.0
^ permalink raw reply related
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Tomasz Figa @ 2012-11-13 9:26 UTC (permalink / raw)
To: linux-arm-kernel
On Exynos SoCs all cores share the same frequency setting, so changing
frequency of one core will affect rest of cores.
This patch modifies the exynos-cpufreq driver to inform cpufreq core
about this behavior and broadcast frequency change notifications for all
cores.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
drivers/cpufreq/exynos-cpufreq.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index af2d81e..c0d54a8 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy *policy,
}
arm_volt = volt_table[index];
- cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ for_each_cpu(freqs.cpu, policy->cpus)
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
/* When the new frequency is higher than current frequency */
if ((freqs.new > freqs.old) && !safe_arm_volt) {
@@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy *policy,
if (freqs.new != freqs.old)
exynos_info->set_freq(old_index, index);
- cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ for_each_cpu(freqs.cpu, policy->cpus)
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
/* When the new frequency is lower than current frequency */
if ((freqs.new < freqs.old) ||
@@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
cpumask_copy(policy->related_cpus, cpu_possible_mask);
cpumask_copy(policy->cpus, cpu_online_mask);
} else {
+ policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
cpumask_setall(policy->cpus);
}
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox