* [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.
From: Padma Venkat @ 2013-02-02 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201302011523.25771.arnd@arndb.de>
Hi Arnd,
On Fri, Feb 1, 2013 at 8:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 01 February 2013, Padmavathi Venna wrote:
>> This patch modify the filter function to filter the required channel
>> based on new filter params.
>>
>> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
>
> The result of this looks good, but I fear that changing the filter function
> like this wil break all drivers that currently use the plat-samsung/dma-ops.c
> code. For migration purposes, I think the best way is to change
> samsung_dmadev_request() to match the new filter_param format.
>
> After that is done, you can migrate all the drivers using samsung_dma_get_ops
> over to the new dma_request_slave_channel interface without breaking
> anything when only part of the series is applied.
>
> Arnd
Please check the below link where I made the dma request compatible to
both DT and non-DT
http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065
http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=b5be04d35dbb2e00ab27a97bfd26e17019e857ef
Please let me know if any changes required.
Thanks for the suggestions.
Padma
^ permalink raw reply
* [PATCH v6 05/12] iommu/exynos: support for device tree
From: KyongHo Cho @ 2013-02-02 5:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201135114.GF25591@8bytes.org>
On Fri, Feb 1, 2013 at 10:51 PM, Joerg Roedel <joro@8bytes.org> wrote:
> Cho,
>
> On Wed, Jan 02, 2013 at 02:53:49PM +0900, KyongHo Cho wrote:
>> On Tuesday, January 1, 2013, Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
>
>> > Cc: devicetree-discuss at lists.ozlabs.org
>
> Since patch 7 of this set is already merged, do you mind to re-post the
> rest of this patch-set with the latest comments addressed? I can have a
> look at it again then and consider it for 3.9.
>
Thank you for your considerations.
I also think that I need to post the patch set again with some fixes that are
addressed in the comments.
Due to the heavy workload in my business I have hardly had a chance to
handle this patch-set.
As soon as the business lets me handle other pending issues, I will
work on this patchset.
I think I can start to it in the next 2 weeks.
Thank you.
KyongHo.
^ permalink raw reply
* [PATCH v3 11/15] ARM: vexpress/dcscb: do not hardcode number of CPUs per cluster
From: Santosh Shilimkar @ 2013-02-02 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1302011222320.6300@xanadu.home>
On Friday 01 February 2013 10:54 PM, Nicolas Pitre wrote:
> On Fri, 1 Feb 2013, Santosh Shilimkar wrote:
>
>> On Tuesday 29 January 2013 01:21 PM, Nicolas Pitre wrote:
>>> If 4 CPUs are assumed, the A15x1-A7x1 model configuration would never
>>> shut down the initial cluster as the 0xf reset bit mask will never be
>>> observed. Let's construct this mask based on the provided information
>>> in the DCSCB config register for the number of CPUs per cluster.
>>>
>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>> ---
>>> arch/arm/mach-vexpress/dcscb.c | 14 ++++++++++----
>>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
>>> index f993608944..8d363357ef 100644
>>> --- a/arch/arm/mach-vexpress/dcscb.c
>>> +++ b/arch/arm/mach-vexpress/dcscb.c
>>> @@ -46,10 +46,12 @@ static arch_spinlock_t dcscb_lock =
>>> __ARCH_SPIN_LOCK_UNLOCKED;
>>>
>>> static void __iomem *dcscb_base;
>>> static int dcscb_use_count[4][2];
>>> +static int dcscb_mcpm_cpu_mask[2];
>> s/2/MAX_CLUSTERS ?
>
> No. The DCSCB (*dual* cluster system control block) does manage only 2
> clusters, regardless of the MAX_CLUSTERS definition which might increase
> in the future.
>
OK. Thanks for clarification.
Regards
Santosh
^ permalink raw reply
* [PATCHv3 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-02-02 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359740758-29703-4-git-send-email-dinguyen@altera.com>
On Friday 01 February 2013 11:15 PM, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> mach-socfpga is another platform that needs to use
> v7_invalidate_l1 to bringup additional cores. There was a comment that
> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> ---
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH] [RFC] arm: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
From: Ivan Djelic @ 2013-02-02 8:33 UTC (permalink / raw)
To: linux-arm-kernel
Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.
For instance in the following function:
void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}
compiled as:
800554d0 <debug_mutex_lock_common>:
800554d0: e92d4008 push {r3, lr}
800554d4: e1a00001 mov r0, r1
800554d8: e3a02010 mov r2, #16 ; 0x10
800554dc: e3a01011 mov r1, #17 ; 0x11
800554e0: eb04426e bl 80165ea0 <memset>
800554e4: e1a03000 mov r3, r0
800554e8: e583000c str r0, [r3, #12]
800554ec: e5830000 str r0, [r3]
800554f0: e5830004 str r0, [r3, #4]
800554f4: e8bd8008 pop {r3, pc}
GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.
This patch fixes the return value of the assembly version of memset.
Could you please review, or suggest better alternatives ?
Thanks,
--
Ivan
(this is a shorter and (hopefully) clearer repost of
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/144916.html)
The patch adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:
Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).
Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
save r8:
- str lr, [sp, #-4]!
+ stmfd sp!, {r8, lr}
and restore r8 on both exit paths:
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
(...)
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
- ldr lr, [sp], #4
+ ldmfd sp!, {r8, lr}
Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
save r8:
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
and restore r8 on both exit paths:
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
(...)
tst r2, #16
stmneia ip!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ ldmfd sp!, {r4-r8, lr}
Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
---
arch/arm/lib/memset.S | 85 +++++++++++++++++++++++++------------------------
1 file changed, 44 insertions(+), 41 deletions(-)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index 650d592..eafd5ee 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -19,9 +19,9 @@
1: subs r2, r2, #4 @ 1 do we have enough
blt 5f @ 1 bytes to align with?
cmp r3, #2 @ 1
- strltb r1, [r0], #1 @ 1
- strleb r1, [r0], #1 @ 1
- strb r1, [r0], #1 @ 1
+ strltb r1, [ip], #1 @ 1
+ strleb r1, [ip], #1 @ 1
+ strb r1, [ip], #1 @ 1
add r2, r2, r3 @ 1 (r2 = r2 - (4 - r3))
/*
* The pointer is now aligned and the length is adjusted. Try doing the
@@ -29,10 +29,14 @@
*/
ENTRY(memset)
- ands r3, r0, #3 @ 1 unaligned?
+/*
+ * Preserve the contents of r0 for the return value.
+ */
+ mov ip, r0
+ ands r3, ip, #3 @ 1 unaligned?
bne 1b @ 1
/*
- * we know that the pointer in r0 is aligned to a word boundary.
+ * we know that the pointer in ip is aligned to a word boundary.
*/
orr r1, r1, r1, lsl #8
orr r1, r1, r1, lsl #16
@@ -43,29 +47,28 @@ ENTRY(memset)
#if ! CALGN(1)+0
/*
- * We need an extra register for this loop - save the return address and
- * use the LR
+ * We need an 2 extra registers for this loop - use r8 and the LR
*/
- str lr, [sp, #-4]!
- mov ip, r1
+ stmfd sp!, {r8, lr}
+ mov r8, r1
mov lr, r1
2: subs r2, r2, #64
- stmgeia r0!, {r1, r3, ip, lr} @ 64 bytes at a time.
- stmgeia r0!, {r1, r3, ip, lr}
- stmgeia r0!, {r1, r3, ip, lr}
- stmgeia r0!, {r1, r3, ip, lr}
+ stmgeia ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
+ stmgeia ip!, {r1, r3, r8, lr}
+ stmgeia ip!, {r1, r3, r8, lr}
+ stmgeia ip!, {r1, r3, r8, lr}
bgt 2b
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
/*
* No need to correct the count; we're only testing bits from now on
*/
tst r2, #32
- stmneia r0!, {r1, r3, ip, lr}
- stmneia r0!, {r1, r3, ip, lr}
+ stmneia ip!, {r1, r3, r8, lr}
+ stmneia ip!, {r1, r3, r8, lr}
tst r2, #16
- stmneia r0!, {r1, r3, ip, lr}
- ldr lr, [sp], #4
+ stmneia ip!, {r1, r3, r8, lr}
+ ldmfd sp!, {r8, lr}
#else
@@ -74,54 +77,54 @@ ENTRY(memset)
* whole cache lines@once.
*/
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
mov r4, r1
mov r5, r1
mov r6, r1
mov r7, r1
- mov ip, r1
+ mov r8, r1
mov lr, r1
cmp r2, #96
- tstgt r0, #31
+ tstgt ip, #31
ble 3f
- and ip, r0, #31
- rsb ip, ip, #32
- sub r2, r2, ip
- movs ip, ip, lsl #(32 - 4)
- stmcsia r0!, {r4, r5, r6, r7}
- stmmiia r0!, {r4, r5}
- tst ip, #(1 << 30)
- mov ip, r1
- strne r1, [r0], #4
+ and r8, ip, #31
+ rsb r8, r8, #32
+ sub r2, r2, r8
+ movs r8, r8, lsl #(32 - 4)
+ stmcsia ip!, {r4, r5, r6, r7}
+ stmmiia ip!, {r4, r5}
+ tst r8, #(1 << 30)
+ mov r8, r1
+ strne r1, [ip], #4
3: subs r2, r2, #64
- stmgeia r0!, {r1, r3-r7, ip, lr}
- stmgeia r0!, {r1, r3-r7, ip, lr}
+ stmgeia ip!, {r1, r3-r8, lr}
+ stmgeia ip!, {r1, r3-r8, lr}
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
tst r2, #32
- stmneia r0!, {r1, r3-r7, ip, lr}
+ stmneia ip!, {r1, r3-r8, lr}
tst r2, #16
- stmneia r0!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ stmneia ip!, {r4-r7}
+ ldmfd sp!, {r4-r8, lr}
#endif
4: tst r2, #8
- stmneia r0!, {r1, r3}
+ stmneia ip!, {r1, r3}
tst r2, #4
- strne r1, [r0], #4
+ strne r1, [ip], #4
/*
* When we get here, we've got less than 4 bytes to zero. We
* may have an unaligned pointer as well.
*/
5: tst r2, #2
- strneb r1, [r0], #1
- strneb r1, [r0], #1
+ strneb r1, [ip], #1
+ strneb r1, [ip], #1
tst r2, #1
- strneb r1, [r0], #1
+ strneb r1, [ip], #1
mov pc, lr
ENDPROC(memset)
--
1.7.10.4
^ permalink raw reply related
* backport patches to 2.6.34 to remove __ARCH_WANT_INTERRUPTS_ON_CTXSW?
From: Li Zefan @ 2013-02-02 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51077966.1060703@huawei.com>
On 2013/1/29 15:25, Li Zefan wrote:
> Hi Catalin,
>
> We got system crashes, and then we managed to trigger the bug within minutes,
> and we found this in upstream, which also backported to 2.6.34 stable:
>
> commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d
> Author: Chanho Min <chanho0207@gmail.com>
> Date: Thu Jan 5 20:00:19 2012 +0900
>
> sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
>
> The bug described in this commit resembles to ours. Unfortunately After applying
> the fix, we still get crash in hours. We tried to bind each real-time task to a
> single cpu to make sure no cpu migration will happen, and it ran without any
> problem for ~20 hours.
>
> We're still investigating this issue. One thing I'm doing is backporting patches
> that removes __ARCH_WANT_INTERRUPTS_ON_CTXSW. With those patches, I can boot
> the kernel, but it hung up when the system automatically start nfs and later
> soft-lockup was reported. Things are fine if I disable nfs startup and start it
> manually.
>
> So did I miss something when backporting, or is it infeasible to backport them
> to 2.6.34? We're using ARMv7. I've attached the patches I backported.
For anyone who might be interested in this bug, and for those who might encouter
the bug in the future and find this thread, here's the story continued.
It turns out I some how missed this one:
commit d427958a46af24f75d0017c45eadd172273bbf33
Author: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu May 26 11:22:44 2011 +0100
ARM: 6942/1: mm: make TTBR1 always point to swapper_pg_dir on ARMv6/7
With those 4 patches backported, we've run two machines for 55 hours and
45 hours, and everything's fine.
problem solved.
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Russell King - ARM Linux @ 2013-02-02 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510C7554.3060800@mvista.com>
On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 4:44, Russell King - ARM Linux wrote:
>
>>>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>>>> good point, do you wanna send some patches ?
>
>>>>>> I have already sent them countless times and even stuck CPPI 4.1 support (in
>>>>>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
>>>>>> patch. :-(
>
>>>>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
>>>>> wasn't asking for the patch to be removed :-s
>
>>>> Err, patches don't get removed, they get moved to 'discarded'.
>
>>> Any chance to bring it back to life? :-)
>>> Although... drivers/usb/musb/cppi41.c would need to be somewhat
>>> reworked for at least AM35x and I don't have time. But that may change,
>>> of course.
>
>> Right, I've just looked back at the various meeting minutes from December
>> 2010 when the CPPI stuff was discussed. Yes, I archive these things and
>> all email discussions for referencing in cases like this.
>
> Thanks.
>
>> Unfortunately, they do not contain any useful information other than the
>> topic having been brought up. At that point, the CPPI stuff was in
>> mach-davinci, and I had suggested moving it into drivers/dma.
>
> I don't remember that, probably was out of the loop again.
>
>> The result of that was to say that it doesn't fit the DMA engine APIs.
>
> I remember this as a discussion happening post me sending the patch to
> the patch system and it being discarded...
>
>> So someone came up with the idea of putting it in arch/arm/common - which
>
> Probably was me. There was also idea of putting it into
> drivers/usb/musb/ -- which TI indeed followed in its Arago prject. I
> firmly denied that suggestion.
>
>> I frankly ignored by email (how long have we been saying "no drivers in
>> arch/arm" ?)
>
> But there *are* drivers there! And look at edma.c which is about to be
> moved there... Anyway, I haven't seen such warnings, probably was too
> late in the game.
I've already objected about the header moving to some random place in
arch/arm/include. Really, edma.c needs to find another home too - but
there's a difference here. edma.c is already present under arch/arm.
CPPI is _not_. CPPI is new code appearing under arch/arm (you can see
that for yourself by looking at the diffstat of 6305/1... it doesn't
move files, it adds new code.)
>> Now, it would've been discussed in that meeting, but unfortunately no
>> record exists of that. What does follow that meeting is a discussion
>> trail. From what I can see there, but it looks to me like the decision
>> was taken to move it to the DMA engine API, and work on sorting out MUSB
>> was going to commence.
>
>> The last email in that says "I'll get to that soon"... and that is also
>> the final email I have on this topic. I guess if nothing has happened...
>> Shrug, that's someone elses problem.
>
> Well, as usual... :-(
>
>> Anyway, the answer for putting it in arch/arm/common hasn't changed,
>> and really, where we are now, post Linus having a moan about the size
>> of arch/arm, that answer is even more concrete in the negative. It's
>> 54K of code which should not be under arch/arm at all.
>
>> Anyway, if you need to look at the patch, it's 6305/1. Typing into the
>> summary search box 'cppi' found it in one go.
>
> Thanks, I remember this variant was under arch/arm/common/.
> Now however, I see what happened to that variant in somewhat different
> light. Looks like it was entirely your decision to discard the patch,
> without TI's request...
Firstly, it is *my* perogative to say no to anything in arch/arm, and I
really don't have to give reasons for it if I choose to.
Secondly, it *was* discussed with TI, and the following thread of
discussion (threaded to the minutes email) shows that *something* was
going to happen _as a result of that meeting_ to address the problem of
it being under arch/arm. And *therefore* it was discarded from the patch
system - because there was expectation that it was going to get fixed.
For christ sake, someone even agreed to do it. Even a target was mentioned,
of 2.6.39. That was mentioned on 7th December 2010. And 6305/1 was
discarded on 8th December 2010. Cause and effect.
And yes, *you* were not part of that discussion. You work for Montavista
which contracts with TI to provide this support. It is up to TI to pass
stuff like this on to their contractors.
There are two people on this thread CC list who were also involved or
CC'd on the mails from the thread in 2010... Tony and Felipe.
Unfortunately, the person who agreed to do the work is no longer in the
land of the living. Yes I know it's inconvenient for people to die
when they've still got lots of important work to do but that's what can
happen...
^ permalink raw reply
* [PATCH v2 1/6] usb: otg: Add an API to bind the USB controller and PHY
From: kishon @ 2013-02-02 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510C2FEA.1080207@pengutronix.de>
Hi,
On Saturday 02 February 2013 02:43 AM, Marc Kleine-Budde wrote:
> On 01/25/2013 03:33 AM, Kishon Vijay Abraham I wrote:
>> In order to support platforms which has multiple PHY's (of same type) and
>> which has multiple USB controllers, a new design is adopted wherin the binding
>> information (between the PHY and the USB controller) should be passed to the
>> PHY library from platform specific file (board file).
>> So added a new API to pass the binding information.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/otg/otg.c | 37 +++++++++++++++++++++++++++++++++++++
>> include/linux/usb/phy.h | 22 ++++++++++++++++++++++
>> 2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
>> index a30c041..8e756d9 100644
>> --- a/drivers/usb/otg/otg.c
>> +++ b/drivers/usb/otg/otg.c
>> @@ -18,6 +18,7 @@
>> #include <linux/usb/otg.h>
>>
>> static LIST_HEAD(phy_list);
>> +static LIST_HEAD(phy_bind_list);
>> static DEFINE_SPINLOCK(phy_lock);
>>
>> static struct usb_phy *__usb_find_phy(struct list_head *list,
>> @@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
>> }
>> EXPORT_SYMBOL(usb_remove_phy);
>>
>> +/**
>> + * usb_bind_phy - bind the phy and the controller that uses the phy
>> + * @dev_name: the device name of the device that will bind to the phy
>> + * @index: index to specify the port number
>> + * @phy_dev_name: the device name of the phy
>> + *
>> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
>> + * be used when the phy driver registers the phy and when the controller
>> + * requests this phy.
>> + *
>> + * To be used by platform specific initialization code.
>> + */
>> +int __init usb_bind_phy(const char *dev_name, u8 index,
>> + const char *phy_dev_name)
>> +{
>> + struct usb_phy_bind *phy_bind;
>> + unsigned long flags;
>> +
>> + phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
>> + if (!phy_bind) {
>> + pr_err("phy_bind(): No memory for phy_bind");
>> + return -ENOMEM;
>> + }
>> +
>> + phy_bind->dev_name = dev_name;
>> + phy_bind->phy_dev_name = phy_dev_name;
>> + phy_bind->index = index;
>> +
>> + spin_lock_irqsave(&phy_lock, flags);
>> + list_add_tail(&phy_bind->list, &phy_bind_list);
>> + spin_unlock_irqrestore(&phy_lock, flags);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_bind_phy);
>> +
>> const char *otg_state_string(enum usb_otg_state state)
>> {
>> switch (state) {
>> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
>> index a29ae1e..e7eb429 100644
>> --- a/include/linux/usb/phy.h
>> +++ b/include/linux/usb/phy.h
>> @@ -106,6 +106,21 @@ struct usb_phy {
>> enum usb_device_speed speed);
>> };
>>
>> +/**
>> + * struct usb_phy_bind - represent the binding for the phy
>> + * @dev_name: the device name of the device that will bind to the phy
>> + * @phy_dev_name: the device name of the phy
>> + * @index: used if a single controller uses multiple phys
>> + * @phy: reference to the phy
>> + * @list: to maintain a linked list of the binding information
>> + */
>> +struct usb_phy_bind {
>> + const char *dev_name;
>> + const char *phy_dev_name;
>> + u8 index;
>> + struct usb_phy *phy;
>> + struct list_head list;
>> +};
>>
>> /* for board-specific init logic */
>> extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
>> @@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
>> enum usb_phy_type type);
>> extern void usb_put_phy(struct usb_phy *);
>> extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
>> +extern int usb_bind_phy(const char *dev_name, u8 index,
>> + const char *phy_dev_name);
>> #else
>> static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
>> {
>> @@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev, struct usb_phy *x)
>> {
>> }
>>
>> +static inline int usb_bind_phy(const char *dev_name, u8 index,
>> + const char *phy_dev_name)
>> +{
>> + return NULL;
>
> The return value looks bogus.
Yes. Felipe has fixed this and has merged the patch already.
Thanks
Kishon
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Russell King - ARM Linux @ 2013-02-02 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130202101851.GY2637@n2100.arm.linux.org.uk>
On Sat, Feb 02, 2013 at 10:18:51AM +0000, Russell King - ARM Linux wrote:
> On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02-02-2013 4:44, Russell King - ARM Linux wrote:
> >
> >>>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> >>>>>>> good point, do you wanna send some patches ?
> >
> >>>>>> I have already sent them countless times and even stuck CPPI 4.1 support (in
> >>>>>> arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
> >>>>>> patch. :-(
> >
> >>>>> sticking into arch/arm/common/ wasn't a nice move. But then again, so
> >>>>> wasn't asking for the patch to be removed :-s
> >
> >>>> Err, patches don't get removed, they get moved to 'discarded'.
> >
> >>> Any chance to bring it back to life? :-)
> >>> Although... drivers/usb/musb/cppi41.c would need to be somewhat
> >>> reworked for at least AM35x and I don't have time. But that may change,
> >>> of course.
> >
> >> Right, I've just looked back at the various meeting minutes from December
> >> 2010 when the CPPI stuff was discussed. Yes, I archive these things and
> >> all email discussions for referencing in cases like this.
> >
> > Thanks.
> >
> >> Unfortunately, they do not contain any useful information other than the
> >> topic having been brought up. At that point, the CPPI stuff was in
> >> mach-davinci, and I had suggested moving it into drivers/dma.
> >
> > I don't remember that, probably was out of the loop again.
Here you go - this goes back even _further_ - November 2009 - on the
mailing list. The entire thread:
http://lists.arm.linux.org.uk/lurker/thread/20091102.105759.a54cf3f5.en.html
And selected emails from it:
http://lists.arm.linux.org.uk/lurker/message/20091102.103706.38c029b5.en.html
On Mon, Nov 02, 2009 at 10:37:06AM +0000, I wrote:
| On Mon, Nov 02, 2009 at 04:27:59PM +0530, Gupta, Ajay Kumar wrote:
| > Another option is to create arch/arm/ti-common to place all TI platform's
| > common software, such as CPPI4.1 used both in DA8xx and AM3517.
|
| No thanks. I really don't see why we should allow TI to have yet more
| directories scattered throughout the tree that are out of place with
| existing conventions.
|
| And what is this CPPI thing anyway?
|
| http://acronyms.thefreedictionary.com/CPPI
|
| "Communications Port Programming Interface" seems to be about the best
| applicable one from that list!
|
| If it's a USB DMA device (from the patches I can find, that seems to be
| the case) then why can't it live in drivers/usb or drivers/dma ?
And again:
http://lists.arm.linux.org.uk/lurker/message/20091102.115458.61cde450.en.html
On Mon, Nov 02, 2009 at 11:54:58AM +0000, I wrote:
| On Mon, Nov 02, 2009 at 04:27:59PM +0530, Gupta, Ajay Kumar wrote:
| > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
| > currently only USB is using it but in future even Ethernet devices may use it.
|
| drivers/dma does seem to be the right place for this.
http://lists.arm.linux.org.uk/lurker/message/20091102.110217.adec3ca7.en.html
Even Felipe Balbi said so:
| you might want to provide support for it via drivers/dma and for the
| musb stuff, you just add the wrappers musb uses. See how tusb6010_omap.c
| uses OMAP's system dma which is also used by any other driver which
| requests a dma channel.
And it seems that _YOU_ did get the message - see your quoted text in:
http://lists.arm.linux.org.uk/lurker/message/20091230.132240.ecd56b3d.en.html
> We're currently having it there but the matter is it should be shred
> between different platforms, so arch/arm/common/ seems like the right
> place (which Russell didn't like, suggesting ill suited for that
> drivers/dma/ instead).
See - you acknowledge here that I don't like it. So you _KNOW_ my views
on it in December 2009, contary to what you're saying in this thread.
Yet, you persisted with putting it in arch/arm/common:
http://lists.arm.linux.org.uk/lurker/message/20100515.181453.472c7c10.en.html
| Changes since the previous version:
| - moved everything from arch/arm/mach-davinci/ to arch/arm/common/;
| - s/CONFIG_CPPI41/CONFIG_TI_CPPI41/, made that option invisible;
| - added #include <linux/slab.h> for kzalloc();
| - switched alloc_queue() and cppi41_queue_free() to using bit operations;
| - replaced 'static' linking_ram[] by local variable in cppi41_queue_mgr_init();
| - fixed pr_debug() in cppi41_dma_ctrlr_init() to print the real queue manager #.
So, see, I had already objected to it being in arch/arm well before
you stuck your patch into the patch system. And somehow you think
that ignoring my previous comments and doing it anyway will result in
progress?
So, let's recap. The timeline behind this is:
+ 2 Nov 2009: Question asked about putting it in arch/arm/ti-common
+ I responded saying a clear no to that, suggesting other locations
all of which were outside arch/arm.
+ I responded again saying an hour or two later saying the same thing.
+ Felipe Balbi agreed with drivers/dma.
+ 15 May 2010: v5 posted with it in arch/arm/common
+ 06 Aug 2010: put into patch system sa 6305/1
+ 06 Dec 2010: TI meeting.
+ Pre-meeting notes show that my views on this are known:
+ I'll quote this from it: "Russell suggested to move the driver at
drivers/dma/".
+ Raises concern that DMA engine API may not fit.
+ I respond to that concern as work has been done on the DMA engine API
to improve the slave mode support recently as a result of Linus Walleij's
work on AMBA PL08x DMA support.
(I would _not_ have done so if I had changed my view about it being
under drivers/dma/).
+ 07 Dec 2010: emails talking about moving MUSB over to DMA engine API
so that MUSB should not care about its DMA backend (that being CPPI
or some other one.)
+ Email with "Let's see if I can get it all done by 2.6.39."
+ 08 Dec 2010: patch 6305/1 discarded from the patch system as there now
seems to be concensus on the issue.
+ 03 Jan 2011: you ask me why it was discarded
http://lists.arm.linux.org.uk/lurker/thread/20110103.160610.8cbe8e7d.en.html
+ I respond "It may have been that it's inventing its own API rather
than using something like the DMA engine API."
+ Ajay said: "This issue was discussed recently at TI and proposal was
to place it to drivers/dma folder. Moreover, even Felipe also seems
to move other musb DMAs (Inventra, CPPI3.0, TUSB) to drivers/dma."
Oh, and then we come to this interesting email from Felipe to you, in
response to your reluctance to put it in drivers/dma.
| Do I really have to spell it out ? Really ?
|
| You don't need to physically move the part of the code to drivers/dma,
| but it has to use the API. The mentor DMA is internal to MUSB.
| tusb6010_omap.c isn't.
|
| Where it makes sense to move the code under drivers/dma, it will be
| done, where it doesn't, it won't be done, but it will use the same API.
| That's all.
|
| The end goal is just to drop all these ad-hoc "APIs" for accessing DMA
| on musb code.
See the common theme here? I don't like it under arch/arm. I've been
pretty _consistent_ in suggesting drivers/dma/ all through that...
Others have said it. People even acknowledge that's what I've been
saying, people who were not in the original discussion.
What I think is this: it is _YOU_ who don't want to hear that message,
so _YOU_ are intentionally ignoring it, and _YOU_ are looking for
someone to blame for it. You've decided I'm to blame because _YOU_
aren't listening.
The reason there hasn't been any progress on this is _NOT_ down to me.
I've provided my feedback, and promptly been ignored. Others have told
you the same thing, and promptly been ignored. Sorry, this is not my
problem. This is entirely YOUR problem, one of your own making.
But whatever. We are NOT going to put CPPI under arch/arm. Not now that
during the last merge window Linus complained to Arnd about the amount of
code coming through for arch/arm _AGAIN_. Not after last time Linus
complained about TI OMAP which prompted the creation of arm-soc. AND THAT
IS *FINAL*. CPPI DMA SUPPORT IS *NOT* GOING UNDER ARCH/ARM. PERIOD. NOT
GOING TO HAPPEN.
Is this clear enough yet, or how many more years of emails do you need
yet more emails to get this message through?
^ permalink raw reply
* linux-next: manual merge of the clk tree with the arm-soc tree
From: Stephen Rothwell @ 2013-02-02 12:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
include/asm-generic/vmlinux.lds.h between commit ae278a935f08
("clocksource: add common of_clksrc_init() function") from the arm-soc
tree and commit f2f6c2556dcc ("clk: add common of_clk_init() function")
from the clk tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc include/asm-generic/vmlinux.lds.h
index fc62ac5,c1fe60a..0000000
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@@ -149,25 -149,16 +149,34 @@@
#define TRACE_SYSCALLS()
#endif
+#ifdef CONFIG_CLKSRC_OF
+#define CLKSRC_OF_TABLES() . = ALIGN(8); \
+ VMLINUX_SYMBOL(__clksrc_of_table) = .; \
+ *(__clksrc_of_table) \
+ *(__clksrc_of_table_end)
+#else
+#define CLKSRC_OF_TABLES()
+#endif
+
+#ifdef CONFIG_IRQCHIP
+#define IRQCHIP_OF_MATCH_TABLE() \
+ . = ALIGN(8); \
+ VMLINUX_SYMBOL(__irqchip_begin) = .; \
+ *(__irqchip_of_table) \
+ *(__irqchip_of_end)
+#else
+#define IRQCHIP_OF_MATCH_TABLE()
+#endif
+ #ifdef CONFIG_COMMON_CLK
+ #define CLK_OF_TABLES() . = ALIGN(8); \
+ VMLINUX_SYMBOL(__clk_of_table) = .; \
+ *(__clk_of_table) \
+ *(__clk_of_table_end)
+ #else
+ #define CLK_OF_TABLES()
+ #endif
+
#define KERNEL_DTB() \
STRUCT_ALIGN(); \
VMLINUX_SYMBOL(__dtb_start) = .; \
@@@ -511,9 -502,8 +520,10 @@@
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
MEM_DISCARD(init.rodata) \
+ CLKSRC_OF_TABLES() \
+ CLK_OF_TABLES() \
- KERNEL_DTB()
+ KERNEL_DTB() \
+ IRQCHIP_OF_MATCH_TABLE()
#define INIT_TEXT \
*(.init.text) \
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130202/4d3892b6/attachment.sig>
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Russell King - ARM Linux @ 2013-02-02 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201185959.GQ2244@beef>
On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote:
> On Fri, Feb 01, 2013 at 07:52:46PM +0000, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02/01/2013 09:49 PM, Matt Porter wrote:
> >
> > >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> > >>> by OMAP (specifically AM33xx) as well.
> >
> > >> I think this should rather go to drivers/dma/?
> >
> > > No, this is the private EDMA API. It's the analogous thing to
> > > the private OMAP dma API that is in plat-omap/dma.c. The actual
> > > dmaengine driver is in drivers/dma/edma.c as a wrapper around
> > > this...same way OMAP DMA engine conversion is being done.
> >
> > Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
> > that, instead of waiting indefinitely for TI to convert it to drivers/dma/
> > directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... Sigh.
>
> That is a shame. Yeah, I've pointed out that I was doing this exactly
> the same way as was acceptable for the OMAP DMA conversion since it was
> in RFC. The reasons are sound since in both cases, we have many drivers
> to convert that need to continue using the private DMA APIs.
It's very simple.
The OMAP DMA stuff in plat-omap/dma.c has existed for a long time, well
before things like the DMA engine API came into being. Same with a lot
of the DMA code in arch/arm. It is therefore in the privileged position
of having "grandfather" rights when it comes to existing in mainline.
However, today what we're finding is that these private per-platform APIs
are sub-optimal; they prevent the peripheral drivers in the drivers/
subtree from being re-used on other SoCs. So, even through they pre-exist
the DMA engine support, they're being gradually converted to the API.
Moreover, we have _far_ too much code in arch/arm. It's something that
has been attracted complaints from Linus. It's something that's got us
close to having updates to arch/arm refused during merge windows. It's
got us close to having parts of arch/arm deleted from the mainline kernel.
The long term plan is _still_ to remove arch/arm/*omap*/dma.c and move
the whole thing to drivers/dma. That can only happen when everything is
converted (or the drivers which aren't converted have been retired and
deleted) - and provided that TI decide to continue funding that work.
That's still uncertain since the whole TI OMAP thing imploded two months
ago.
Now, CPPI is brand new code to arch/arm - always has been. It post-dates
the DMA engine API. And it's been said many times about moving it to
drivers/dma. The problem is Sergei doesn't want to do it - he's anti the
DMA engine API for whatever reasons he can dream up. He professes no
knowledge of my dislike for having it in arch/arm, yet there's emails
from years back showing that he knew about it. TI knows about it; Ajay
about it. Yet... well... history speaks volumes about this.
Now, there may be a new problem with CPPI. That being we're now requiring
DT support. _Had_ this been done prior to the push for DT, then it would
not have been a concern, because then the problem becomes one for DT.
But now that OMAP is being converted to DT, and DT is The Way To Go now,
that's an additional problem that needs to be grappled with - or it may
make things easier.
However, as I've said now many times: CPPI is _not_ going in arch/arm.
Period. That makes it not my problem. Period.
I really have nothing further to say on CPPI; everything that can be said
has already been said. If there's still pressure to have it in arch/arm,
I will _NOT_ respond to it, because there's nothing to be said about it
which hasn't been said before. The only reason it's still being pressed
for is a total reluctance to do anything about it being in arch/arm.
^ permalink raw reply
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Russell King - ARM Linux @ 2013-02-02 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201184107.GM22517@atomide.com>
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> * Matt Porter <mporter@ti.com> [130201 10:25]:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx) as well.
>
> I think this should rather go to drivers/dma/?
Yes, it should, but just like OMAP, there's a conversion effort that needs
to be gone through. It has one point - and only one point - which allows
its continued existence under arch/arm, and that is it already exists
there.
If it was new code, the answer would be a definite NACK, but it isn't.
It's pre-existing code which is already in mainline. It's merely being
moved.
Another plus point for it is that there does seem to be a DMA engine
driver for it, so hopefully we'll see it killed off in arch/arm soon.
^ permalink raw reply
* [PATCH v3 0/4] Kirkwood and Dove Thermal drivers
From: Andrew Lunn @ 2013-02-02 14:35 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds thermal support for Kirkwood and Dove SoCs.
Changes since v2
* More marvel -> marvell
* Dove driver. Debugged by Sebastian Hesselbarth
Changes since v1
* Temperature Reading in milligrad
* marvel -> marvell
* generalized to Orion
* Compatibility string marvell,kirkwood-thermal
* Arithmetic using unsigned long
Andrew Lunn (2):
Thermal: Dove: Add Themal sensor support for Dove.
Dove: Thermal: Add DT node and enable in defconfig
Nobuhiro Iwamatsu (2):
thermal: Add support for the thermal sensor on Kirkwood SoCs
ARM: Kirkwood: Add support thermal sensor for 88F6282 and 88F6283
.../devicetree/bindings/thermal/dove-thermal.txt | 18 ++
.../bindings/thermal/kirkwood-thermal.txt | 15 ++
arch/arm/boot/dts/dove.dtsi | 5 +
arch/arm/boot/dts/kirkwood-6282.dtsi | 6 +
arch/arm/configs/dove_defconfig | 2 +
arch/arm/configs/kirkwood_defconfig | 2 +
drivers/thermal/Kconfig | 14 ++
drivers/thermal/Makefile | 2 +
drivers/thermal/dove_thermal.c | 211 ++++++++++++++++++++
drivers/thermal/kirkwood_thermal.c | 136 +++++++++++++
10 files changed, 411 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/dove-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
create mode 100644 drivers/thermal/dove_thermal.c
create mode 100644 drivers/thermal/kirkwood_thermal.c
--
1.7.10.4
^ permalink raw reply
* [PATCH v3 1/4] thermal: Add support for the thermal sensor on Kirkwood SoCs
From: Andrew Lunn @ 2013-02-02 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359815749-27705-1-git-send-email-andrew@lunn.ch>
From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
This patch adds support for Kirkwood 88F6282 and 88F6283 thermal sensor.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
.../bindings/thermal/kirkwood-thermal.txt | 15 +++
drivers/thermal/Kconfig | 7 +
drivers/thermal/Makefile | 1 +
drivers/thermal/kirkwood_thermal.c | 136 ++++++++++++++++++++
4 files changed, 159 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
create mode 100644 drivers/thermal/kirkwood_thermal.c
diff --git a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
new file mode 100644
index 0000000..8c0f5eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt
@@ -0,0 +1,15 @@
+* Kirkwood Thermal
+
+This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods
+don't contain a thermal sensor.
+
+Required properties:
+- compatible : "marvell,kirkwood-thermal"
+- reg : Address range of the thermal registers
+
+Example:
+
+ thermal at 10078 {
+ compatible = "marvell,kirkwood-thermal";
+ reg = <0x10078 0x4>;
+ };
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index c2c77d1..e691500 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -93,6 +93,13 @@ config RCAR_THERMAL
Enable this to plug the R-Car thermal sensor driver into the Linux
thermal framework
+config KIRKWOOD_THERMAL
+ tristate "Temperature sensor on Marvell Kirkwood SoCs"
+ depends on ARCH_KIRKWOOD
+ help
+ Support for the Kirkwood thermal sensor driver into the Linux thermal
+ framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
+
config EXYNOS_THERMAL
tristate "Temperature sensor on Samsung EXYNOS"
depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5)
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index d8da683..99026b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
# platform thermal drivers
obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
+obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
diff --git a/drivers/thermal/kirkwood_thermal.c b/drivers/thermal/kirkwood_thermal.c
new file mode 100644
index 0000000..000cfc9
--- /dev/null
+++ b/drivers/thermal/kirkwood_thermal.c
@@ -0,0 +1,136 @@
+/*
+ * Kirkwood thermal sensor driver
+ *
+ * Copyright (C) 2012 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define KIRKWOOD_THERMAL_VALID_OFFSET 9
+#define KIRKWOOD_THERMAL_VALID_MASK 0x1
+#define KIRKWOOD_THERMAL_TEMP_OFFSET 10
+#define KIRKWOOD_THERMAL_TEMP_MASK 0x1FF
+
+/* Kirkwood Thermal Sensor Dev Structure */
+struct kirkwood_thermal_priv {
+ void __iomem *sensor;
+};
+
+static int kirkwood_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ unsigned long reg;
+ struct kirkwood_thermal_priv *priv = thermal->devdata;
+
+ reg = readl_relaxed(priv->sensor);
+
+ /* Valid check */
+ if (!(reg >> KIRKWOOD_THERMAL_VALID_OFFSET) &
+ KIRKWOOD_THERMAL_VALID_MASK) {
+ dev_err(&thermal->device,
+ "Temperature sensor reading not valid\n");
+ return -EIO;
+ }
+
+ /*
+ * Calculate temperature. See Section 8.10.1 of the 88AP510,
+ * datasheet, which has the same sensor.
+ * Documentation/arm/Marvell/README
+ */
+ reg = (reg >> KIRKWOOD_THERMAL_TEMP_OFFSET) &
+ KIRKWOOD_THERMAL_TEMP_MASK;
+ *temp = ((2281638UL - (7298*reg)) / 10);
+
+ return 0;
+}
+
+static struct thermal_zone_device_ops ops = {
+ .get_temp = kirkwood_get_temp,
+};
+
+static const struct of_device_id kirkwood_thermal_id_table[] = {
+ { .compatible = "marvell,kirkwood-thermal" },
+ {}
+};
+
+static int kirkwood_thermal_probe(struct platform_device *pdev)
+{
+ struct thermal_zone_device *thermal = NULL;
+ struct kirkwood_thermal_priv *priv;
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get platform resource\n");
+ return -ENODEV;
+ }
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(&pdev->dev, "kzalloc fail\n");
+ return -ENOMEM;
+ }
+
+ priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
+ if (!priv->sensor) {
+ dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
+ return -EADDRNOTAVAIL;
+ }
+
+ thermal = thermal_zone_device_register("kirkwood_thermal", 0, 0,
+ priv, &ops, NULL, 0, 0);
+ if (IS_ERR(thermal)) {
+ dev_err(&pdev->dev,
+ "Failed to register thermal zone device\n");
+ return PTR_ERR(thermal);
+ }
+
+ platform_set_drvdata(pdev, thermal);
+
+ return 0;
+}
+
+static int kirkwood_thermal_exit(struct platform_device *pdev)
+{
+ struct thermal_zone_device *kirkwood_thermal =
+ platform_get_drvdata(pdev);
+
+ thermal_zone_device_unregister(kirkwood_thermal);
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+MODULE_DEVICE_TABLE(of, kirkwood_thermal_id_table);
+
+static struct platform_driver kirkwood_thermal_driver = {
+ .probe = kirkwood_thermal_probe,
+ .remove = kirkwood_thermal_exit,
+ .driver = {
+ .name = "kirkwood_thermal",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(kirkwood_thermal_id_table),
+ },
+};
+
+module_platform_driver(kirkwood_thermal_driver);
+
+MODULE_AUTHOR("Nobuhiro Iwamatsu <iwamatsu@nigauri.org>");
+MODULE_DESCRIPTION("kirkwood thermal driver");
+MODULE_LICENSE("GPL");
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 2/4] ARM: Kirkwood: Add support thermal sensor for 88F6282 and 88F6283
From: Andrew Lunn @ 2013-02-02 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359815749-27705-1-git-send-email-andrew@lunn.ch>
From: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Kirkwood 88F6282 and 88F6283 have a thermal sensor.
This patch adds a DT node and enables the driver in the kernel config.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-6282.dtsi | 6 ++++++
arch/arm/configs/kirkwood_defconfig | 2 ++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/kirkwood-6282.dtsi b/arch/arm/boot/dts/kirkwood-6282.dtsi
index 4ccea21..bd168b6 100644
--- a/arch/arm/boot/dts/kirkwood-6282.dtsi
+++ b/arch/arm/boot/dts/kirkwood-6282.dtsi
@@ -32,6 +32,12 @@
};
};
+ thermal at 10078 {
+ compatible = "marvell,kirkwood-thermal";
+ reg = <0x10078 0x4>;
+ status = "okay";
+ };
+
i2c at 11100 {
compatible = "marvell,mv64xxx-i2c";
reg = <0x11100 0x20>;
diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
index 93f3794..3d8667f 100644
--- a/arch/arm/configs/kirkwood_defconfig
+++ b/arch/arm/configs/kirkwood_defconfig
@@ -118,6 +118,8 @@ CONFIG_SPI=y
CONFIG_SPI_ORION=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_KIRKWOOD_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_ORION_WATCHDOG=y
CONFIG_HID_DRAGONRISE=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 3/4] Thermal: Dove: Add Themal sensor support for Dove.
From: Andrew Lunn @ 2013-02-02 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359815749-27705-1-git-send-email-andrew@lunn.ch>
The Marvell Dove SoC has a thermal sensor. Add a driver using the
thermal framework.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
.../devicetree/bindings/thermal/dove-thermal.txt | 18 ++
drivers/thermal/Kconfig | 7 +
drivers/thermal/Makefile | 1 +
drivers/thermal/dove_thermal.c | 211 ++++++++++++++++++++
4 files changed, 237 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/dove-thermal.txt
create mode 100644 drivers/thermal/dove_thermal.c
diff --git a/Documentation/devicetree/bindings/thermal/dove-thermal.txt b/Documentation/devicetree/bindings/thermal/dove-thermal.txt
new file mode 100644
index 0000000..6f47467
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/dove-thermal.txt
@@ -0,0 +1,18 @@
+* Dove Thermal
+
+This driver is for Dove SoCs which contain a thermal sensor.
+
+Required properties:
+- compatible : "marvell,dove-thermal"
+- reg : Address range of the thermal registers
+
+The reg properties should contain two ranges. The first is for the
+three Thermal Manager registers, while the second range contains the
+Thermal Diode Control Registers.
+
+Example:
+
+ thermal at 10078 {
+ compatible = "marvell,dove-thermal";
+ reg = <0xd001c 0x0c>, <0xd005c 0x08>;
+ };
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e691500..cdc267e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -108,6 +108,13 @@ config EXYNOS_THERMAL
If you say yes here you get support for TMU (Thermal Management
Unit) on SAMSUNG EXYNOS series of SoC.
+config DOVE_THERMAL
+ tristate "Temperature sensor on Marvell Dove SoCs"
+ depends on ARCH_DOVE
+ help
+ Support for the Dove thermal sensor driver in the Linux thermal
+ framework.
+
config DB8500_THERMAL
bool "DB8500 thermal management"
depends on ARCH_U8500
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 99026b2..5ed357e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -17,5 +17,6 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
+obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
diff --git a/drivers/thermal/dove_thermal.c b/drivers/thermal/dove_thermal.c
new file mode 100644
index 0000000..3a92b55
--- /dev/null
+++ b/drivers/thermal/dove_thermal.c
@@ -0,0 +1,211 @@
+/*
+ * Dove thermal sensor driver
+ *
+ * Copyright (C) 2013 Andrew Lunn <andrew@lunn.ch>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define DOVE_THERMAL_TEMP_OFFSET 1
+#define DOVE_THERMAL_TEMP_MASK 0x1FF
+
+/* Dove Thermal Manager Control and Status Register */
+#define PMU_TM_DISABLE_OFFS 0
+#define PMU_TM_DISABLE_MASK (0x1 << PMU_TM_DISABLE_OFFS)
+
+/* Dove Theraml Diode Control 0 Register */
+#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
+#define PMU_TDC0_SEL_VCAL_OFFS 5
+#define PMU_TDC0_SEL_VCAL_MASK (0x3 << PMU_TDC0_SEL_VCAL_OFFS)
+#define PMU_TDC0_REF_CAL_CNT_OFFS 11
+#define PMU_TDC0_REF_CAL_CNT_MASK (0x1FF << PMU_TDC0_REF_CAL_CNT_OFFS)
+#define PMU_TDC0_AVG_NUM_OFFS 25
+#define PMU_TDC0_AVG_NUM_MASK (0x7 << PMU_TDC0_AVG_NUM_OFFS)
+
+/* Dove Thermal Diode Control 1 Register */
+#define PMU_TEMP_DIOD_CTRL1_REG 0x04
+#define PMU_TDC1_TEMP_VALID_MASK (0x1 << 10)
+
+/* Dove Thermal Sensor Dev Structure */
+struct dove_thermal_priv {
+ void __iomem *sensor;
+ void __iomem *control;
+};
+
+static int dove_init_sensor(const struct dove_thermal_priv *priv)
+{
+ u32 reg;
+ u32 i;
+
+ /* Configure the Diode Control Register #0 */
+ reg = readl_relaxed(priv->control);
+
+ /* Use average of 2 */
+ reg &= ~PMU_TDC0_AVG_NUM_MASK;
+ reg |= (0x1 << PMU_TDC0_AVG_NUM_OFFS);
+
+ /* Reference calibration value */
+ reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
+ reg |= (0x0F1 << PMU_TDC0_REF_CAL_CNT_OFFS);
+
+ /* Set the high level reference for calibration */
+ reg &= ~PMU_TDC0_SEL_VCAL_MASK;
+ reg |= (0x2 << PMU_TDC0_SEL_VCAL_OFFS);
+ writel(reg, priv->control);
+
+ /* Reset the sensor */
+ reg = readl_relaxed(priv->control);
+ writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+ writel(reg, priv->control);
+
+ /* Enable the sensor */
+ reg = readl_relaxed(priv->sensor);
+ reg &= ~PMU_TM_DISABLE_MASK;
+ writel(reg, priv->sensor);
+
+ /* Poll the sensor for the first reading */
+ for (i = 0; i < 1000000; i++) {
+ reg = readl_relaxed(priv->sensor);
+ if (reg & DOVE_THERMAL_TEMP_MASK)
+ break;
+ }
+
+ if (i == 1000000)
+ return -EIO;
+
+ return 0;
+}
+
+static int dove_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ unsigned long reg;
+ struct dove_thermal_priv *priv = thermal->devdata;
+
+ /* Valid check */
+ reg = readl_relaxed(priv->control + PMU_TEMP_DIOD_CTRL1_REG);
+ if ((reg & PMU_TDC1_TEMP_VALID_MASK) == 0x0) {
+ dev_err(&thermal->device,
+ "Temperature sensor reading not valid\n");
+ return -EIO;
+ }
+
+ /*
+ * Calculate temperature. See Section 8.10.1 of 88AP510,
+ * Documentation/arm/Marvell/README
+ */
+ reg = readl_relaxed(priv->sensor);
+ reg = (reg >> DOVE_THERMAL_TEMP_OFFSET) & DOVE_THERMAL_TEMP_MASK;
+ *temp = ((2281638UL - (7298*reg)) / 10);
+
+ return 0;
+}
+
+static struct thermal_zone_device_ops ops = {
+ .get_temp = dove_get_temp,
+};
+
+static const struct of_device_id dove_thermal_id_table[] = {
+ { .compatible = "marvell,dove-thermal" },
+ {}
+};
+
+static int dove_thermal_probe(struct platform_device *pdev)
+{
+ struct thermal_zone_device *thermal = NULL;
+ struct dove_thermal_priv *priv;
+ struct resource *res;
+ int ret;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get platform resource\n");
+ return -ENODEV;
+ }
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(&pdev->dev, "kzalloc fail\n");
+ return -ENOMEM;
+ }
+
+ priv->sensor = devm_request_and_ioremap(&pdev->dev, res);
+ if (!priv->sensor) {
+ dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
+ return -EADDRNOTAVAIL;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get platform resource\n");
+ return -ENODEV;
+ }
+ priv->control = devm_request_and_ioremap(&pdev->dev, res);
+ if (!priv->control) {
+ dev_err(&pdev->dev, "Failed to request_ioremap memory\n");
+ return -EADDRNOTAVAIL;
+ }
+
+ ret = dove_init_sensor(priv);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to initialize sensor\n");
+ return ret;
+ }
+
+ thermal = thermal_zone_device_register("dove_thermal", 0, 0,
+ priv, &ops, NULL, 0, 0);
+ if (IS_ERR(thermal)) {
+ dev_err(&pdev->dev,
+ "Failed to register thermal zone device\n");
+ return PTR_ERR(thermal);
+ }
+
+ platform_set_drvdata(pdev, thermal);
+
+ return 0;
+}
+
+static int dove_thermal_exit(struct platform_device *pdev)
+{
+ struct thermal_zone_device *dove_thermal =
+ platform_get_drvdata(pdev);
+
+ thermal_zone_device_unregister(dove_thermal);
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+MODULE_DEVICE_TABLE(of, dove_thermal_id_table);
+
+static struct platform_driver dove_thermal_driver = {
+ .probe = dove_thermal_probe,
+ .remove = dove_thermal_exit,
+ .driver = {
+ .name = "dove_thermal",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(dove_thermal_id_table),
+ },
+};
+
+module_platform_driver(dove_thermal_driver);
+
+MODULE_AUTHOR("Andrew Lunn <andrew@lunn.ch>");
+MODULE_DESCRIPTION("Dove thermal driver");
+MODULE_LICENSE("GPL");
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 4/4] Dove: Thermal: Add DT node and enable in defconfig
From: Andrew Lunn @ 2013-02-02 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359815749-27705-1-git-send-email-andrew@lunn.ch>
Add a device tree node to instantiate the dove thermal driver.
Enable the driver and the thermal framework in dove_defconfig.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/dove.dtsi | 5 +++++
arch/arm/configs/dove_defconfig | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 42eac1f..3584a00 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -50,6 +50,11 @@
#clock-cells = <1>;
};
+ thermal: thermal at d001c {
+ compatible = "marvell,dove-thermal";
+ reg = <0xd001c 0x0c>, <0xd005c 0x08>;
+ };
+
uart0: serial at 12000 {
compatible = "ns16550a";
reg = <0x12000 0x100>;
diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
index 0b7ee92..9713b5b 100644
--- a/arch/arm/configs/dove_defconfig
+++ b/arch/arm/configs/dove_defconfig
@@ -80,6 +80,8 @@ CONFIG_I2C_MV64XXX=y
CONFIG_SPI=y
CONFIG_SPI_ORION=y
# CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_DOVE_THERMAL=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_EHCI_HCD=y
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] gpiolib: remove gpiochip_reserve()
From: Alexandre Courbot @ 2013-02-02 14:44 UTC (permalink / raw)
To: linux-arm-kernel
The Tosa (Sharp SL-C6000x) target is the last remaining user of
gpiochip_reserve(). I would like to get rid of this function as part of my
project to totally remove the big static gpio_desc[] array of gpiolib. Patches
that achieve this are written and working, but the presence of
gpiochip_reserve() makes it necessary to maintain a list of "reserved" ranges
in the GPIO space, which complexifies code that would be much simpler
otherwise.
Even for Tosa the use of gpiochip_reserve() does not seem necessary - all GPIO
controllers have their own base GPIO set AFAICT, so there should be no need to
use it. And without any user in the kernel, there should be no reason to keep
this function.
If Dmitri could give his Acked-by or Tested-by and one of the GPIO maintainers
merge this series, I could go ahead with the deeper changes to gpiolib.
Thanks,
Alexandre Courbot (2):
arm: pxa: tosa: do not use gpiochip_reserve()
gpiolib: remove gpiochip_reserve()
arch/arm/mach-pxa/tosa.c | 6 -----
drivers/gpio/gpiolib.c | 58 +++++++---------------------------------------
include/asm-generic/gpio.h | 1 -
3 files changed, 8 insertions(+), 57 deletions(-)
--
1.8.1.1
^ permalink raw reply
* [PATCH 1/2] arm: pxa: tosa: do not use gpiochip_reserve()
From: Alexandre Courbot @ 2013-02-02 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359816246-3979-1-git-send-email-acourbot@nvidia.com>
GPIO address space reservation during early platform initialization is
not needed anymore for Tosa. Remove the calls to gpiochip_reserve()
which is due to be removed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/mach-pxa/tosa.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 9e7998d..3d91d2e 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -927,8 +927,6 @@ static void tosa_restart(char mode, const char *cmd)
static void __init tosa_init(void)
{
- int dummy;
-
pxa2xx_mfp_config(ARRAY_AND_SIZE(tosa_pin_config));
pxa_set_ffuart_info(NULL);
@@ -947,10 +945,6 @@ static void __init tosa_init(void)
/* enable batt_fault */
PMCR = 0x01;
- dummy = gpiochip_reserve(TOSA_SCOOP_GPIO_BASE, 12);
- dummy = gpiochip_reserve(TOSA_SCOOP_JC_GPIO_BASE, 12);
- dummy = gpiochip_reserve(TOSA_TC6393XB_GPIO_BASE, 16);
-
pxa_set_mci_info(&tosa_mci_platform_data);
pxa_set_ficp_info(&tosa_ficp_platform_data);
pxa_set_i2c_info(NULL);
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/2] gpiolib: remove gpiochip_reserve()
From: Alexandre Courbot @ 2013-02-02 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359816246-3979-1-git-send-email-acourbot@nvidia.com>
gpiochip_reserve() has no user and stands in the way of the removal of
the static gpio_desc[] array. Remove this function as well as the now
unneeded RESERVED flag of struct gpio_desc.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
drivers/gpio/gpiolib.c | 58 +++++++---------------------------------------
include/asm-generic/gpio.h | 1 -
2 files changed, 8 insertions(+), 51 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 199fca1..e27877a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -52,14 +52,13 @@ struct gpio_desc {
/* flag symbols are bit numbers */
#define FLAG_REQUESTED 0
#define FLAG_IS_OUT 1
-#define FLAG_RESERVED 2
-#define FLAG_EXPORT 3 /* protected by sysfs_lock */
-#define FLAG_SYSFS 4 /* exported via /sys/class/gpio/control */
-#define FLAG_TRIG_FALL 5 /* trigger on falling edge */
-#define FLAG_TRIG_RISE 6 /* trigger on rising edge */
-#define FLAG_ACTIVE_LOW 7 /* sysfs value has active low */
-#define FLAG_OPEN_DRAIN 8 /* Gpio is open drain type */
-#define FLAG_OPEN_SOURCE 9 /* Gpio is open source type */
+#define FLAG_EXPORT 2 /* protected by sysfs_lock */
+#define FLAG_SYSFS 3 /* exported via /sys/class/gpio/control */
+#define FLAG_TRIG_FALL 4 /* trigger on falling edge */
+#define FLAG_TRIG_RISE 5 /* trigger on rising edge */
+#define FLAG_ACTIVE_LOW 6 /* sysfs value has active low */
+#define FLAG_OPEN_DRAIN 7 /* Gpio is open drain type */
+#define FLAG_OPEN_SOURCE 8 /* Gpio is open source type */
#define ID_SHIFT 16 /* add new flags before this one */
@@ -132,7 +131,7 @@ static int gpiochip_find_base(int ngpio)
struct gpio_desc *desc = &gpio_desc[i];
struct gpio_chip *chip = desc->chip;
- if (!chip && !test_bit(FLAG_RESERVED, &desc->flags)) {
+ if (!chip) {
spare++;
if (spare == ngpio) {
base = i;
@@ -150,47 +149,6 @@ static int gpiochip_find_base(int ngpio)
return base;
}
-/**
- * gpiochip_reserve() - reserve range of gpios to use with platform code only
- * @start: starting gpio number
- * @ngpio: number of gpios to reserve
- * Context: platform init, potentially before irqs or kmalloc will work
- *
- * Returns a negative errno if any gpio within the range is already reserved
- * or registered, else returns zero as a success code. Use this function
- * to mark a range of gpios as unavailable for dynamic gpio number allocation,
- * for example because its driver support is not yet loaded.
- */
-int __init gpiochip_reserve(int start, int ngpio)
-{
- int ret = 0;
- unsigned long flags;
- int i;
-
- if (!gpio_is_valid(start) || !gpio_is_valid(start + ngpio - 1))
- return -EINVAL;
-
- spin_lock_irqsave(&gpio_lock, flags);
-
- for (i = start; i < start + ngpio; i++) {
- struct gpio_desc *desc = &gpio_desc[i];
-
- if (desc->chip || test_bit(FLAG_RESERVED, &desc->flags)) {
- ret = -EBUSY;
- goto err;
- }
-
- set_bit(FLAG_RESERVED, &desc->flags);
- }
-
- pr_debug("%s: reserved gpios from %d to %d\n",
- __func__, start, start + ngpio - 1);
-err:
- spin_unlock_irqrestore(&gpio_lock, flags);
-
- return ret;
-}
-
/* caller ensures gpio is valid and requested, chip->get_direction may sleep */
static int gpio_get_direction(unsigned gpio)
{
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 45b8916..2034e69 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -152,7 +152,6 @@ struct gpio_chip {
extern const char *gpiochip_is_requested(struct gpio_chip *chip,
unsigned offset);
extern struct gpio_chip *gpio_to_chip(unsigned gpio);
-extern int __must_check gpiochip_reserve(int start, int ngpio);
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
--
1.8.1.1
^ permalink raw reply related
* [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
From: Matt Porter @ 2013-02-02 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130202124906.GB2637@n2100.arm.linux.org.uk>
On Sat, Feb 02, 2013 at 12:49:06PM +0000, Russell King wrote:
> On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> > * Matt Porter <mporter@ti.com> [130201 10:25]:
> > > Move mach-davinci/dma.c to common/edma.c so it can be used
> > > by OMAP (specifically AM33xx) as well.
> >
> > I think this should rather go to drivers/dma/?
>
> Yes, it should, but just like OMAP, there's a conversion effort that needs
> to be gone through. It has one point - and only one point - which allows
> its continued existence under arch/arm, and that is it already exists
> there.
>
> If it was new code, the answer would be a definite NACK, but it isn't.
> It's pre-existing code which is already in mainline. It's merely being
> moved.
>
> Another plus point for it is that there does seem to be a DMA engine
> driver for it, so hopefully we'll see it killed off in arch/arm soon.
That's definitely the plan. I was able to start this effort
independently by converting the Davinci mmc and spi drivers to dmaengine
before I took this step. I've got the next micro-step of addressing
omap_hsmmc in process (pending on agreement on a dmaengine api change
with Vinod), cleaning up the mcasp driver is also pending this series so
that it can also be converted to dmaengine. Once mcasp (or "davinci
audio") is converted, we're rid of all the in-kernel users of the
private API and can get rid of this...which also is helping clean up
mach-davinci, of course.
If I can get your ack on this patch that should move things along to
these next steps.
Thanks,
Matt
^ permalink raw reply
* [PATCH v3] USB: add devicetree helpers for determining dr_mode and phy_type
From: Greg KH @ 2013-02-02 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201175352.GA2553@pengutronix.de>
On Fri, Feb 01, 2013 at 06:53:52PM +0100, Sascha Hauer wrote:
> Apparantly I was not fully awake while sending this series :(
>
> On Fri, Feb 01, 2013 at 08:52:03AM +0100, Sascha Hauer wrote:
> > (resend because I got the linux-usb address wrong)
> >
> > Here's another round of the dr_mode/phy_type patches. I think they should
> > be ready for merging now. Greg, will you apply them should there be no
> > problems anymore?
I need all chipidea patches to come from the maintainer of the driver, I
don't take git pull requests, sorry.
greg k-h
^ permalink raw reply
* [PATCH 0/2] gpiolib: remove gpiochip_reserve()
From: Linus Walleij @ 2013-02-02 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359816246-3979-1-git-send-email-acourbot@nvidia.com>
On Sat, Feb 2, 2013 at 3:44 PM, Alexandre Courbot <acourbot@nvidia.com> wrote:
> If Dmitri could give his Acked-by or Tested-by and one of the GPIO maintainers
> merge this series, I could go ahead with the deeper changes to gpiolib.
Good riddance.
Both patches applied to get some rotation in linux-next.
This is too good stuff to wait and I like to push this work ahead
a bit. I can still back them out if there is some problem on the
TOSA.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] More highbank fixes for 3.8
From: Rob Herring @ 2013-02-02 15:05 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Please pull these fixes needed for highbank. Secondary core boot is
broken when using an updated DT with correct cpu cluster id.
Rob
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://sources.calxeda.com/kernel/linux.git tags/highbank-fixes-for-3.8
for you to fetch changes up to 63fc1370c19052fa5bec9593557431efc7ecc9fe:
ARM: highbank: mask cluster id from cpu_logical_map (2013-01-31
13:54:30 -0600)
----------------------------------------------------------------
highbank fixes for 3.8
-Compile fix for !SMP
-More cpu cluster id related fixes
----------------------------------------------------------------
Rob Herring (3):
ARM: scu: add empty scu_enable for !CONFIG_SMP
ARM: scu: mask cluster id from cpu_logical_map
ARM: highbank: mask cluster id from cpu_logical_map
arch/arm/include/asm/smp_scu.h | 8 +++++++-
arch/arm/kernel/smp_scu.c | 2 +-
arch/arm/mach-highbank/highbank.c | 3 ++-
arch/arm/mach-highbank/sysregs.h | 4 ++--
4 files changed, 12 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.
From: Arnd Bergmann @ 2013-02-02 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAgF-Bf55eN2WOgU5nQa=nF76fHvBHR7NdmvoBpF-n4ke6rd1g@mail.gmail.com>
On Saturday 02 February 2013 08:00:54 Padma Venkat wrote:
> > The result of this looks good, but I fear that changing the filter function
> > like this wil break all drivers that currently use the plat-samsung/dma-ops.c
> > code. For migration purposes, I think the best way is to change
> > samsung_dmadev_request() to match the new filter_param format.
> >
> > After that is done, you can migrate all the drivers using samsung_dma_get_ops
> > over to the new dma_request_slave_channel interface without breaking
> > anything when only part of the series is applied.
> >
> > Arnd
>
> Please check the below link where I made the dma request compatible to
> both DT and non-DT
>
> http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065
> http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=b5be04d35dbb2e00ab27a97bfd26e17019e857ef
>
> Please let me know if any changes required.
>
Those two changes by themselves still look ok, I think but you
still break the non-DT case in this 4/4 patch by changing the
pl330_filter function in an incompatible way. You will still
have to either change the filter_param argument in the
samsung_dmadev_request() function, or provide separate filter
functions, one to be used by samsung_dmadev_request and
one for the pl330_xlate function.
In the long run, I think it would be better to move the slave
drivers away from the samsung_dma wrappers and use
dma_request_slave_channel directly, but that is an independent
discussion.
Arnd
^ 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