* [PATCH v2 5/5] regulator: map consumer regulator based on device tree
From: Nayak, Rajendra @ 2011-10-11 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111010173506.GH3607@opensource.wolfsonmicro.com>
>
>> + ? ? if (supply) {
>> + ? ? ? ? ? ? struct regulator_dev *r;
>> + ? ? ? ? ? ? struct device_node *node;
>> +
>> + ? ? ? ? ? ? /* first do a dt based lookup */
>> + ? ? ? ? ? ? if (dev) {
>> + ? ? ? ? ? ? ? ? ? ? node = of_get_regulator(dev, supply);
>> + ? ? ? ? ? ? ? ? ? ? if (node)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? list_for_each_entry(r, ®ulator_list, list)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if (node == r->dev.parent->of_node)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? goto found;
>> ? ? ? ? ? ? ? }
>>
>> - ? ? ? ? ? ? if (!found) {
>> - ? ? ? ? ? ? ? ? ? ? dev_err(dev, "Failed to find supply %s\n",
>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? init_data->supply_regulator);
>> - ? ? ? ? ? ? ? ? ? ? ret = -ENODEV;
>> - ? ? ? ? ? ? ? ? ? ? goto scrub;
>> - ? ? ? ? ? ? }
>> + ? ? ? ? ? ? /* next try doing it non-dt way */
>> + ? ? ? ? ? ? list_for_each_entry(r, ®ulator_list, list)
>> + ? ? ? ? ? ? ? ? ? ? if (strcmp(rdev_get_name(r), supply) == 0)
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? goto found;
>>
>> + ? ? ? ? ? ? dev_err(dev, "Failed to find supply %s\n", supply);
>> + ? ? ? ? ? ? ret = -ENODEV;
>> + ? ? ? ? ? ? goto scrub;
>> +
>> +found:
>
> This is all getting *really* complicated and illegible. ?I'm not sure
> what the best way to structure is but erroring out early looks useful.
>
How about this updated patch?
^ permalink raw reply
* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Santosh Shilimkar @ 2011-10-11 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ty7ghgiw.fsf@ti.com>
On Monday 10 October 2011 11:31 PM, Kevin Hilman wrote:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
>> suspend (S2R), CPU hotplug and CPUidle.
>
> There are a few more compile errors when doing OMAP1-only builds.
> You'll need a way to eliminate the secure calls for OMAP1.
>
> This series causes a couple build errors when doing OMAP1-only builds
> (I used omap1_defconfig):
>
OK. Thanks for catching it.
> First:
>
> /work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error: mach/omap-secure.h: No such file or directory
>
> And trying creating a dummy header to see if it would continue to build gives:
>
> /work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve':
> /work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit declaration of function 'omap_secure_ram_reserve_memblock'
> make[2]: *** [arch/arm/plat-omap/common.o] Error 1
> make[1]: *** [arch/arm/plat-omap] Error 2
>
For OMAP1 build, omap_secure_ram_reserve_memblock() definition is
needed since common.c is built for OMAP1 as well.
The trivial change in the end of this email fixes the omap1 build.
Have folded that change in original patch and updated the OMAP4
PM branch - for_3_2/omap4-mpuss-pm_2
Regards
Santosh
P.S : Even with this fix, omap1_defconfig build breaks because of USB.
I removed USB from build to check rest of the build and it was
fine then.
---
diff --git a/arch/arm/mach-omap2/include/mach/omap-secure.h
b/arch/arm/mach-omap2/include/mach/omap-secure.h
index 6e929c5..48247ce 100644
--- a/arch/arm/mach-omap2/include/mach/omap-secure.h
+++ b/arch/arm/mach-omap2/include/mach/omap-secure.h
@@ -51,7 +51,6 @@ extern u32 omap_secure_dispatcher(u32 idx, u32 flag,
u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
-extern int omap_secure_ram_reserve_memblock(void);
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 827f896..d5ef8dc 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,7 +21,7 @@
#include <plat/vram.h>
#include <plat/dsp.h>
-#include <mach/omap-secure.h>
+#include <plat/omap-secure.h>
#define NO_LENGTH_CHECK 0xffffffff
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
new file mode 100644
index 0000000..64f9d1c
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -0,0 +1,13 @@
+#ifndef __OMAP_SECURE_H__
+#define __OMAP_SECURE_H__
+
+#include <linux/types.h>
+
+#ifdef CONFIG_ARCH_OMAP2PLUS
+extern int omap_secure_ram_reserve_memblock(void);
+#else
+static inline void omap_secure_ram_reserve_memblock(void)
+{ }
+#endif
+
+#endif /* __OMAP_SECURE_H__ */
^ permalink raw reply related
* sched: ARM: arch_scale_freq_power
From: Amit Kucheria @ 2011-10-11 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtB3sLWq5fHOTrFg6vfHSKnz2i17oYx9Btr0u_tWV2bsjQ@mail.gmail.com>
Adding Peter to the discussion..
On Thu, Oct 6, 2011 at 5:06 PM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
> I work to link the cpu_power of ARM cores to their frequency by using
> arch_scale_freq_power. It's explained in the kernel that cpu_power is
> used to distribute load on cpus and a cpu with more cpu_power will
> pick up more load. The default value is SCHED_POWER_SCALE and I
> increase the value if I want a cpu to have more load than another one.
> Is there an advised range for cpu_power value as well as some time
> scale constraints for updating the cpu_power value ?
> I'm also wondering why this scheduler feature is currently disable by default ?
>
> Regards,
> Vincent
In discussions with Vincent regarding this, I've wondered whether
cpu_power wouldn't be better renamed to cpu_capacity since that is
what it really seems to describe.
^ permalink raw reply
* [Linaro-mm-sig] [PATCHv16 0/9] Contiguous Memory Allocator
From: Marek Szyprowski @ 2011-10-11 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E92E003.4060901@stericsson.com>
Hello,
On Monday, October 10, 2011 2:08 PM Maxime Coquelin wrote:
> On 10/06/2011 03:54 PM, Marek Szyprowski wrote:
> > Welcome everyone again,
> >
> > Once again I decided to post an updated version of the Contiguous Memory
> > Allocator patches.
> >
> > This version provides mainly a bugfix for a very rare issue that might
> > have changed migration type of the CMA page blocks resulting in dropping
> > CMA features from the affected page block and causing memory allocation
> > to fail. Also the issue reported by Dave Hansen has been fixed.
> >
> > This version also introduces basic support for x86 architecture, what
> > allows wide testing on KVM/QEMU emulators and all common x86 boxes. I
> > hope this will result in wider testing, comments and easier merging to
> > mainline.
> >
> > I've also dropped an examplary patch for s5p-fimc platform device
> > private memory declaration and added the one from real life. CMA device
> > private memory regions are defined for s5p-mfc device to let it allocate
> > buffers from two memory banks.
> >
> > ARM integration code has not been changed since last version, it
> > provides implementation of all the ideas that has been discussed during
>
> Hello Marek,
>
> We are currently testing CMA (v16) on Snowball platform.
> This feature is very promising, thanks for pushing it!
>
> During our stress tests, we encountered some problems :
>
> 1) Contiguous allocation lockup:
> When system RAM is full of Anon pages, if we try to allocate a
> contiguous buffer greater than the min_free value, we face a
> dma_alloc_from_contiguous lockup.
> The expected result would be dma_alloc_from_contiguous() to fail.
> The problem is reproduced systematically on our side.
Thanks for the report. Do you use Android's lowmemorykiller? I haven't
tested CMA on Android kernel yet. I have no idea how it will interfere
with Android patches.
>
> 2) Contiguous allocation fail:
> We have developed a small driver and a shell script to
> allocate/release contiguous buffers.
> Sometimes, dma_alloc_from_contiguous() fails to allocate the
> contiguous buffer (about once every 30 runs).
> We have 270MB Memory passed to the kernel in our configuration,
> and the CMA pool is 90MB large.
> In this setup, the overall memory is either free or full of
> reclaimable pages.
Yeah. We also did such stress tests recently and faced this issue. I've
spent some time investigating it but I have no solution yet.
The problem is caused by a page, which is put in the CMA area. This page
is movable, but it's address space provides no 'migratepage' method. In
such case mm subsystem uses fallback_migrate_page() function. Sadly this
function only returns -EAGAIN. The migration loops a few times over it
and fails causing the fail in the allocation procedure.
We are investing now which kernel code created/allocated such problematic
pages and how to add real migration support for them.
> For now, we didn't had time to investigate further theses problems.
> Have you already faced this kind of issues?
> Could someone testing CMA on other boards confirm/infirm theses
> problems?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [Linaro-mm-sig] [PATCHv16 0/9] Contiguous Memory Allocator
From: Maxime Coquelin @ 2011-10-11 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00b001cc87e5$dc818cc0$9584a640$%szyprowski@samsung.com>
On 10/11/2011 09:17 AM, Marek Szyprowski wrote:
> On Monday, October 10, 2011 2:08 PM Maxime Coquelin wrote:
>
> During our stress tests, we encountered some problems :
>
> 1) Contiguous allocation lockup:
> When system RAM is full of Anon pages, if we try to allocate a
> contiguous buffer greater than the min_free value, we face a
> dma_alloc_from_contiguous lockup.
> The expected result would be dma_alloc_from_contiguous() to fail.
> The problem is reproduced systematically on our side.
> Thanks for the report. Do you use Android's lowmemorykiller? I haven't
> tested CMA on Android kernel yet. I have no idea how it will interfere
> with Android patches.
>
The software used for this test (v16) is a generic 3.0 Kernel and a
minimal filesystem using Busybox.
With v15 patchset, I also tested it with Android.
IIRC, sometimes the lowmemorykiller succeed to get free space and the
contiguous allocation succeed, sometimes we faced the lockup.
>> 2) Contiguous allocation fail:
>> We have developed a small driver and a shell script to
>> allocate/release contiguous buffers.
>> Sometimes, dma_alloc_from_contiguous() fails to allocate the
>> contiguous buffer (about once every 30 runs).
>> We have 270MB Memory passed to the kernel in our configuration,
>> and the CMA pool is 90MB large.
>> In this setup, the overall memory is either free or full of
>> reclaimable pages.
> Yeah. We also did such stress tests recently and faced this issue. I've
> spent some time investigating it but I have no solution yet.
>
> The problem is caused by a page, which is put in the CMA area. This page
> is movable, but it's address space provides no 'migratepage' method. In
> such case mm subsystem uses fallback_migrate_page() function. Sadly this
> function only returns -EAGAIN. The migration loops a few times over it
> and fails causing the fail in the allocation procedure.
>
> We are investing now which kernel code created/allocated such problematic
> pages and how to add real migration support for them.
>
Ok, thanks for pointing this out.
Regards,
Maxime
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Shawn Guo @ 2011-10-11 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111010133246.GG2451@mudshark.cambridge.arm.com>
On Mon, Oct 10, 2011 at 02:32:46PM +0100, Will Deacon wrote:
> On Mon, Oct 10, 2011 at 12:20:24PM +0100, Arnd Bergmann wrote:
> > On Monday 10 October 2011, Will Deacon wrote:
> > > Do you have any other ideas?
> >
> > I think the best solution would be to ask Russell to put all the dependencies
> > into a non-rebasing branch and publish that, or to alternatively merge your
> > patches through his tree instead, with my Ack.
>
> I don't think asking Russell to maintain a stable branch for each series
> scales very well if multiple people are doing cross-platform work at the
> same time. If he's happy merging platform code via his tree, then I'd prefer
> to go down that route. In this case, it might make sense to try and catch
> conflicts between his tree and arm-soc before they hit Linus (I guess -next
> will take care of this?).
>
> > Both of these will also have to wait for a few more days until Russell
> > is back online.
>
> Ok, I wasn't aware that we was away.
>
> > Can you check if the devel-stable branch in his tree already contains the
> > dependencies?
>
> I just had a quick look and I can't seem them outside of the unstable for-next
> branch.
>
I also have a number of patches that imx6q series depends on only
showing on rmk's for-next branch, and I have to hold imx6q pull request
until these patches show up on some non-rebased tree.
--
Regards,
Shawn
^ permalink raw reply
* sched: ARM: arch_scale_freq_power
From: Peter Zijlstra @ 2011-10-11 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAP245DX8b45Nj5SAwtLivp_vMKpwfeUrqnR2sqjnVyqiRd61gg@mail.gmail.com>
On Tue, 2011-10-11 at 12:46 +0530, Amit Kucheria wrote:
> Adding Peter to the discussion..
Right, CCing the folks who actually wrote the code you're asking
questions about always helps ;-)
> On Thu, Oct 6, 2011 at 5:06 PM, Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> > I work to link the cpu_power of ARM cores to their frequency by using
> > arch_scale_freq_power.
Why and how? In particular note that if you're using something like the
on-demand cpufreq governor this isn't going to work.
> It's explained in the kernel that cpu_power is
> > used to distribute load on cpus and a cpu with more cpu_power will
> > pick up more load. The default value is SCHED_POWER_SCALE and I
> > increase the value if I want a cpu to have more load than another one.
> > Is there an advised range for cpu_power value as well as some time
> > scale constraints for updating the cpu_power value ?
Basically 1024 is the unit and denotes the capacity of a full core at
'normal' speed.
Typically cpufreq would down-clock a core and thus you'd end up with a
smaller number (linearly proportional to the freq ratio etc. although if
you want to go really fancy you could determine the actual
throughput/freq curves).
Things like x86 turbo mode would result in a >1024 value.
Things like SMT would typically result in <1024 and the SMT sum over the
core >1024 (if you're lucky).
> > I'm also wondering why this scheduler feature is currently disable by default ?
Because the only implementation in existence (x86) is broken and I
haven't gotten around to fixing it. Arguable we should disable that for
the time being, see below.
> In discussions with Vincent regarding this, I've wondered whether
> cpu_power wouldn't be better renamed to cpu_capacity since that is
> what it really seems to describe.
Possibly, but its been cpu_power for ages and we use capacity to
describe something else.
---
arch/x86/kernel/cpu/sched.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/sched.c b/arch/x86/kernel/cpu/sched.c
index a640ae5..90ae68c 100644
--- a/arch/x86/kernel/cpu/sched.c
+++ b/arch/x86/kernel/cpu/sched.c
@@ -6,7 +6,14 @@
#include <asm/cpufeature.h>
#include <asm/processor.h>
-#ifdef CONFIG_SMP
+#if 0 /* def CONFIG_SMP */
+
+/*
+ * Currently broken, we need to filter out idle time because the aperf/mperf
+ * ratio measures actual throughput, not capacity. This means that if a logical
+ * cpu idles it will report less capacity and receive less work, which isn't
+ * what we want.
+ */
static DEFINE_PER_CPU(struct aperfmperf, old_perf_sched);
^ permalink raw reply related
* [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices
From: Koyamangalath, Abhilash @ 2011-10-11 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874nztfw6w.fsf@ti.com>
hi Kevin,
Apologies for the delayed response, I was on vacation.
On October 01, 2011 4:57 AM, Hilman, Kevin wrote:
>
> Abhilash,
>
> Kevin Hilman <khilman@ti.com> writes:
>
>> Abhilash K V <abhilash.kv@ti.com> writes:
>>
>>> From: Abhilash K V <abhilash.kv@ti.com>
>>>
>>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>>> we must not enable it. So omap3_twl_init() is now not called
>>> when the processor does not support SR.
>>
>> This still isn't right.
>>
>> The reason to skip the TWL PMIC init is not because SR is not available
>> (TWL PMICs are quite usable without SR). The reason to skip TWL PMIC
>> init is because the PMIC is not present.
[Abhilash K V] yes, I understand now.
>>
>> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
>> only registered if a TWL driver is registered.
>>
>
> Below is a test patch that is a first pass at implementing what I
> suggested above. I tested this (along with your patch 3/3) on a
> 3430/n900 after removing the omap_pmic_init() call frome the board file.
[Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not already
pulled it into your branch).
>
> Can you let me know if this solves the problem you're seeing on
> platforms that don't have TWL PMICs?
[Abhilash K V] It should, I have validated on am3517_evm
>
> After digging into this more, I'm increasingly aware that the way we're
> managing the init of PMIC stuff is a mess. Guess I need another round
> of voltage layer cleanups to fix that up.
[Abhilash K V] True, and to add to this, the changes required to support only
ONE voltage-domain for am35xx would be too many, I believe.
>
>
> Kevin
>
> From 1cd49077829a262155b96f8fdcdcdd6c54d83ed5 Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@ti.com>
> Date: Fri, 30 Sep 2011 11:24:04 -0700
> Subject: [PATCH] ARM: OMAP2+: PM: only register TWL with voltage layer when
> device is present
>
> Current code registers voltage layer details for TWL PMIC even when a TWL
> has not been registered. Fix this to only register the TWL with voltage
> layer when the TWL PMIC is initialized by board-level code.
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/pm.c | 6 ++----
> arch/arm/mach-omap2/twl-common.c | 11 +++++++++++
> arch/arm/mach-omap2/twl-common.h | 3 +++
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index d34fc52..602fc66 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -23,6 +23,7 @@
> #include "powerdomain.h"
> #include "clockdomain.h"
> #include "pm.h"
> +#include "twl-common.h"
>
> static struct omap_device_pm_latency *pm_lats;
>
> @@ -251,11 +252,8 @@ postcore_initcall(omap2_common_pm_init);
>
> static int __init omap2_common_pm_late_init(void)
> {
> - /* Init the OMAP TWL parameters */
> - omap3_twl_init();
> - omap4_twl_init();
> -
> /* Init the voltage layer */
> + omap_pmic_late_init();
> omap_voltage_late_init();
>
> /* Initialize the voltages */
> diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
> index daa056e..47133fa 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -30,6 +30,7 @@
> #include <plat/usb.h>
>
> #include "twl-common.h"
> +#include "pm.h"
>
> static struct i2c_board_info __initdata pmic_i2c_board_info = {
> .addr = 0x48,
> @@ -48,6 +49,16 @@ void __init omap_pmic_init(int bus, u32 clkrate,
> omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
> }
>
> +void __init omap_pmic_late_init(void)
> +{
> + /* Init the OMAP TWL parameters (if PMIC has been registerd) */
> + if (!pmic_i2c_board_info.irq)
> + return;
> +
> + omap3_twl_init();
> + omap4_twl_init();
> +}
> +
> #if defined(CONFIG_ARCH_OMAP3)
> static struct twl4030_usb_data omap3_usb_pdata = {
> .usb_mode = T2_USB_MODE_ULPI,
> diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
> index 5e83a5b..275dde8 100644
> --- a/arch/arm/mach-omap2/twl-common.h
> +++ b/arch/arm/mach-omap2/twl-common.h
> @@ -1,6 +1,8 @@
> #ifndef __OMAP_PMIC_COMMON__
> #define __OMAP_PMIC_COMMON__
>
> +#include <plat/irqs.h>
> +
> #define TWL_COMMON_PDATA_USB (1 << 0)
> #define TWL_COMMON_PDATA_BCI (1 << 1)
> #define TWL_COMMON_PDATA_MADC (1 << 2)
> @@ -30,6 +32,7 @@ struct twl4030_platform_data;
>
> void omap_pmic_init(int bus, u32 clkrate, const char *pmic_type, int pmic_irq,
> struct twl4030_platform_data *pmic_data);
> +void omap_pmic_late_init(void);
>
> static inline void omap2_pmic_init(const char *pmic_type,
> struct twl4030_platform_data *pmic_data)
> --
> 1.7.6
>
>
^ permalink raw reply
* [PATCH] arm: mx23: add machine_is_stmp_378x()
From: Uwe Kleine-König @ 2011-10-11 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318255873-17370-1-git-send-email-w.sang@pengutronix.de>
On Mon, Oct 10, 2011 at 04:11:13PM +0200, Wolfram Sang wrote:
> Adding this line was forgotten when converting mach-stmp378x to
> mach-mxs.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
IMHO the Subject is misleading. What about:
ARM: mxs: recognise stmp378x as mx23
?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH V2 0/3] ARM: SAMSUNG: Add support for sdhci clock lookup using generic names
From: Rajeshwari Shinde @ 2011-10-11 8:15 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds support for sdhci controller clock lookup using
generic names. With this patchset, there will be no need to pass clock
names in sdhci platform data.
This patchset depends on the patchset:
Add a common macro for creating struct clk_lookup entries
V2 Changes:
-Added HCLK instance for HSMMC instance 1 as suggested by Heiko.
-Rebased on UART clkdev patches. So these patches should be applied
after UART clkdev patches are applied.
Rajeshwari Shinde (3):
SDHCI: S3C: Use generic clock names for sdhci bus clock options
ARM: SAMSUNG: Remove SDHCI bus clocks from platform data
ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
arch/arm/mach-exynos4/Makefile | 1 -
arch/arm/mach-exynos4/clock.c | 88 +++++++++------
arch/arm/mach-exynos4/setup-sdhci.c | 22 ----
arch/arm/mach-s3c2416/Makefile | 1 -
arch/arm/mach-s3c2416/clock.c | 85 +++++++++------
arch/arm/mach-s3c2416/setup-sdhci.c | 24 ----
arch/arm/mach-s3c64xx/Makefile | 1 -
arch/arm/mach-s3c64xx/clock.c | 126 +++++++++++++--------
arch/arm/mach-s3c64xx/setup-sdhci.c | 24 ----
arch/arm/mach-s5pc100/Makefile | 1 -
arch/arm/mach-s5pc100/clock.c | 130 +++++++++++++---------
arch/arm/mach-s5pc100/setup-sdhci.c | 23 ----
arch/arm/mach-s5pv210/Makefile | 1 -
arch/arm/mach-s5pv210/clock.c | 167 +++++++++++++++++-----------
arch/arm/mach-s5pv210/setup-sdhci.c | 22 ----
arch/arm/plat-samsung/include/plat/sdhci.h | 31 -----
drivers/mmc/host/sdhci-s3c.c | 6 +-
17 files changed, 366 insertions(+), 387 deletions(-)
delete mode 100644 arch/arm/mach-exynos4/setup-sdhci.c
delete mode 100644 arch/arm/mach-s3c2416/setup-sdhci.c
delete mode 100644 arch/arm/mach-s3c64xx/setup-sdhci.c
delete mode 100644 arch/arm/mach-s5pc100/setup-sdhci.c
delete mode 100644 arch/arm/mach-s5pv210/setup-sdhci.c
^ permalink raw reply
* [PATCH V2 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options
From: Rajeshwari Shinde @ 2011-10-11 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318320907-8580-1-git-send-email-rajeshwari.s@samsung.com>
This patch modifies the driver to stop depending on the clock names
being passed from the platform and switch over to bus clock lookup
using generic clock names.
Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
---
drivers/mmc/host/sdhci-s3c.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 82709b6..a5fde87 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
struct clk *clk;
- char *name = pdata->clocks[ptr];
+ char name[14];
- if (name == NULL)
- continue;
+ sprintf(name, "mmc_busclk.%d", ptr);
clk = clk_get(dev, name);
if (IS_ERR(clk)) {
- dev_err(dev, "failed to get clock %s\n", name);
continue;
}
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH V2 2/3] ARM: SAMSUNG: Remove SDHCI bus clocks from platform data
From: Rajeshwari Shinde @ 2011-10-11 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318320907-8580-1-git-send-email-rajeshwari.s@samsung.com>
The bus clocks previously sent through platform data to SDHCI controller
are removed.
Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
---
arch/arm/mach-exynos4/Makefile | 1 -
arch/arm/mach-exynos4/setup-sdhci.c | 22 -------------------
arch/arm/mach-s3c2416/Makefile | 1 -
arch/arm/mach-s3c2416/setup-sdhci.c | 24 ---------------------
arch/arm/mach-s3c64xx/Makefile | 1 -
arch/arm/mach-s3c64xx/setup-sdhci.c | 24 ---------------------
arch/arm/mach-s5pc100/Makefile | 1 -
arch/arm/mach-s5pc100/setup-sdhci.c | 23 --------------------
arch/arm/mach-s5pv210/Makefile | 1 -
arch/arm/mach-s5pv210/setup-sdhci.c | 22 -------------------
arch/arm/plat-samsung/include/plat/sdhci.h | 31 ----------------------------
11 files changed, 0 insertions(+), 151 deletions(-)
delete mode 100644 arch/arm/mach-exynos4/setup-sdhci.c
delete mode 100644 arch/arm/mach-s3c2416/setup-sdhci.c
delete mode 100644 arch/arm/mach-s3c64xx/setup-sdhci.c
delete mode 100644 arch/arm/mach-s5pc100/setup-sdhci.c
delete mode 100644 arch/arm/mach-s5pv210/setup-sdhci.c
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 2bb18f4..c47aae3 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_EXYNOS4_SETUP_I2C5) += setup-i2c5.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C6) += setup-i2c6.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C7) += setup-i2c7.o
obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_EXYNOS4_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY) += setup-usb-phy.o
diff --git a/arch/arm/mach-exynos4/setup-sdhci.c b/arch/arm/mach-exynos4/setup-sdhci.c
deleted file mode 100644
index 92937b4..0000000
--- a/arch/arm/mach-exynos4/setup-sdhci.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/* linux/arch/arm/mach-exynos4/setup-sdhci.c
- *
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/types.h>
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *exynos4_hsmmc_clksrcs[4] = {
- [0] = NULL,
- [1] = NULL,
- [2] = "sclk_mmc", /* mmc_bus */
- [3] = NULL,
-};
diff --git a/arch/arm/mach-s3c2416/Makefile b/arch/arm/mach-s3c2416/Makefile
index 7b805b2..ca0cd22 100644
--- a/arch/arm/mach-s3c2416/Makefile
+++ b/arch/arm/mach-s3c2416/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_S3C2416_PM) += pm.o
#obj-$(CONFIG_S3C2416_DMA) += dma.o
# Device setup
-obj-$(CONFIG_S3C2416_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
# Machine support
diff --git a/arch/arm/mach-s3c2416/setup-sdhci.c b/arch/arm/mach-s3c2416/setup-sdhci.c
deleted file mode 100644
index cee5395..0000000
--- a/arch/arm/mach-s3c2416/setup-sdhci.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/* linux/arch/arm/mach-s3c2416/setup-sdhci.c
- *
- * Copyright 2010 Promwad Innovation Company
- * Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
- *
- * S3C2416 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * Based on mach-s3c64xx/setup-sdhci.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/types.h>
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *s3c2416_hsmmc_clksrcs[4] = {
- [0] = "hsmmc",
- [1] = "hsmmc",
- [2] = "hsmmc-if",
- /* [3] = "48m", - note not successfully used yet */
-};
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 902ab9a..94de24b 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -32,7 +32,6 @@ obj-$(CONFIG_S3C64XX_SETUP_I2C0) += setup-i2c0.o
obj-$(CONFIG_S3C64XX_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S3C64XX_SETUP_IDE) += setup-ide.o
obj-$(CONFIG_S3C64XX_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_S3C64XX_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S3C64XX_SETUP_FB_24BPP) += setup-fb-24bpp.o
obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c b/arch/arm/mach-s3c64xx/setup-sdhci.c
deleted file mode 100644
index c75a71b..0000000
--- a/arch/arm/mach-s3c64xx/setup-sdhci.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/* linux/arch/arm/mach-s3c64xx/setup-sdhci.c
- *
- * Copyright 2008 Simtec Electronics
- * Copyright 2008 Simtec Electronics
- * Ben Dooks <ben@simtec.co.uk>
- * http://armlinux.simtec.co.uk/
- *
- * S3C6400/S3C6410 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/types.h>
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *s3c64xx_hsmmc_clksrcs[4] = {
- [0] = "hsmmc",
- [1] = "hsmmc",
- [2] = "mmc_bus",
- /* [3] = "48m", - note not successfully used yet */
-};
diff --git a/arch/arm/mach-s5pc100/Makefile b/arch/arm/mach-s5pc100/Makefile
index a5e6e60..2320e54 100644
--- a/arch/arm/mach-s5pc100/Makefile
+++ b/arch/arm/mach-s5pc100/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_S5PC100_SETUP_FB_24BPP) += setup-fb-24bpp.o
obj-$(CONFIG_S5PC100_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5PC100_SETUP_IDE) += setup-ide.o
obj-$(CONFIG_S5PC100_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_S5PC100_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S5PC100_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
# device support
diff --git a/arch/arm/mach-s5pc100/setup-sdhci.c b/arch/arm/mach-s5pc100/setup-sdhci.c
deleted file mode 100644
index 6418c6e..0000000
--- a/arch/arm/mach-s5pc100/setup-sdhci.c
+++ /dev/null
@@ -1,23 +0,0 @@
-/* linux/arch/arm/mach-s5pc100/setup-sdhci.c
- *
- * Copyright 2008 Samsung Electronics
- *
- * S5PC100 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * Based on mach-s3c6410/setup-sdhci.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/types.h>
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *s5pc100_hsmmc_clksrcs[4] = {
- [0] = "hsmmc", /* HCLK */
- /* [1] = "hsmmc", - duplicate HCLK entry */
- [2] = "sclk_mmc", /* mmc_bus */
- /* [3] = "48m", - note not successfully used yet */
-};
diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile
index 009fbe5..53c346a 100644
--- a/arch/arm/mach-s5pv210/Makefile
+++ b/arch/arm/mach-s5pv210/Makefile
@@ -35,5 +35,4 @@ obj-$(CONFIG_S5PV210_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5PV210_SETUP_I2C2) += setup-i2c2.o
obj-$(CONFIG_S5PV210_SETUP_IDE) += setup-ide.o
obj-$(CONFIG_S5PV210_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_S5PV210_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S5PV210_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
diff --git a/arch/arm/mach-s5pv210/setup-sdhci.c b/arch/arm/mach-s5pv210/setup-sdhci.c
deleted file mode 100644
index 6b8ccc4..0000000
--- a/arch/arm/mach-s5pv210/setup-sdhci.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/* linux/arch/arm/mach-s5pv210/setup-sdhci.c
- *
- * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- *
- * S5PV210 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/types.h>
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *s5pv210_hsmmc_clksrcs[4] = {
- [0] = "hsmmc", /* HCLK */
- /* [1] = "hsmmc", - duplicate HCLK entry */
- [2] = "sclk_mmc", /* mmc_bus */
- /* [3] = NULL, - reserved */
-};
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-samsung/include/plat/sdhci.h
index e7b3c75..dcff7dd 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -66,8 +66,6 @@ struct s3c_sdhci_platdata {
enum cd_types cd_type;
enum clk_types clk_type;
- char **clocks; /* set of clock sources */
-
int ext_cd_gpio;
bool ext_cd_gpio_invert;
int (*ext_cd_init)(void (*notify_func)(struct platform_device *,
@@ -129,12 +127,9 @@ extern void exynos4_setup_sdhci3_cfg_gpio(struct platform_device *, int w);
/* S3C2416 SDHCI setup */
#ifdef CONFIG_S3C2416_SETUP_SDHCI
-extern char *s3c2416_hsmmc_clksrcs[4];
-
static inline void s3c2416_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.clocks = s3c2416_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c2416_setup_sdhci0_cfg_gpio;
#endif /* CONFIG_S3C_DEV_HSMMC */
}
@@ -142,7 +137,6 @@ static inline void s3c2416_default_sdhci0(void)
static inline void s3c2416_default_sdhci1(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.clocks = s3c2416_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c2416_setup_sdhci1_cfg_gpio;
#endif /* CONFIG_S3C_DEV_HSMMC1 */
}
@@ -155,12 +149,9 @@ static inline void s3c2416_default_sdhci1(void) { }
/* S3C64XX SDHCI setup */
#ifdef CONFIG_S3C64XX_SETUP_SDHCI
-extern char *s3c64xx_hsmmc_clksrcs[4];
-
static inline void s3c6400_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c64xx_setup_sdhci0_cfg_gpio;
#endif
}
@@ -168,7 +159,6 @@ static inline void s3c6400_default_sdhci0(void)
static inline void s3c6400_default_sdhci1(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c64xx_setup_sdhci1_cfg_gpio;
#endif
}
@@ -176,7 +166,6 @@ static inline void s3c6400_default_sdhci1(void)
static inline void s3c6400_default_sdhci2(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC2
- s3c_hsmmc2_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s3c64xx_setup_sdhci2_cfg_gpio;
#endif
}
@@ -184,7 +173,6 @@ static inline void s3c6400_default_sdhci2(void)
static inline void s3c6410_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s3c64xx_setup_sdhci0_cfg_gpio;
#endif
}
@@ -192,7 +180,6 @@ static inline void s3c6410_default_sdhci0(void)
static inline void s3c6410_default_sdhci1(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s3c64xx_setup_sdhci1_cfg_gpio;
#endif
}
@@ -200,7 +187,6 @@ static inline void s3c6410_default_sdhci1(void)
static inline void s3c6410_default_sdhci2(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC2
- s3c_hsmmc2_def_platdata.clocks = s3c64xx_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s3c64xx_setup_sdhci2_cfg_gpio;
#endif
}
@@ -218,12 +204,9 @@ static inline void s3c6400_default_sdhci2(void) { }
/* S5PC100 SDHCI setup */
#ifdef CONFIG_S5PC100_SETUP_SDHCI
-extern char *s5pc100_hsmmc_clksrcs[4];
-
static inline void s5pc100_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.clocks = s5pc100_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s5pc100_setup_sdhci0_cfg_gpio;
#endif
}
@@ -231,7 +214,6 @@ static inline void s5pc100_default_sdhci0(void)
static inline void s5pc100_default_sdhci1(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.clocks = s5pc100_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s5pc100_setup_sdhci1_cfg_gpio;
#endif
}
@@ -239,7 +221,6 @@ static inline void s5pc100_default_sdhci1(void)
static inline void s5pc100_default_sdhci2(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC2
- s3c_hsmmc2_def_platdata.clocks = s5pc100_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s5pc100_setup_sdhci2_cfg_gpio;
#endif
}
@@ -254,12 +235,9 @@ static inline void s5pc100_default_sdhci2(void) { }
/* S5PV210 SDHCI setup */
#ifdef CONFIG_S5PV210_SETUP_SDHCI
-extern char *s5pv210_hsmmc_clksrcs[4];
-
static inline void s5pv210_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = s5pv210_setup_sdhci0_cfg_gpio;
#endif
}
@@ -267,7 +245,6 @@ static inline void s5pv210_default_sdhci0(void)
static inline void s5pv210_default_sdhci1(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = s5pv210_setup_sdhci1_cfg_gpio;
#endif
}
@@ -275,7 +252,6 @@ static inline void s5pv210_default_sdhci1(void)
static inline void s5pv210_default_sdhci2(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC2
- s3c_hsmmc2_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = s5pv210_setup_sdhci2_cfg_gpio;
#endif
}
@@ -283,7 +259,6 @@ static inline void s5pv210_default_sdhci2(void)
static inline void s5pv210_default_sdhci3(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC3
- s3c_hsmmc3_def_platdata.clocks = s5pv210_hsmmc_clksrcs;
s3c_hsmmc3_def_platdata.cfg_gpio = s5pv210_setup_sdhci3_cfg_gpio;
#endif
}
@@ -298,12 +273,9 @@ static inline void s5pv210_default_sdhci3(void) { }
/* EXYNOS4 SDHCI setup */
#ifdef CONFIG_EXYNOS4_SETUP_SDHCI
-extern char *exynos4_hsmmc_clksrcs[4];
-
static inline void exynos4_default_sdhci0(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC
- s3c_hsmmc0_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc0_def_platdata.cfg_gpio = exynos4_setup_sdhci0_cfg_gpio;
#endif
}
@@ -311,7 +283,6 @@ static inline void exynos4_default_sdhci0(void)
static inline void exynos4_default_sdhci1(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC1
- s3c_hsmmc1_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc1_def_platdata.cfg_gpio = exynos4_setup_sdhci1_cfg_gpio;
#endif
}
@@ -319,7 +290,6 @@ static inline void exynos4_default_sdhci1(void)
static inline void exynos4_default_sdhci2(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC2
- s3c_hsmmc2_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc2_def_platdata.cfg_gpio = exynos4_setup_sdhci2_cfg_gpio;
#endif
}
@@ -327,7 +297,6 @@ static inline void exynos4_default_sdhci2(void)
static inline void exynos4_default_sdhci3(void)
{
#ifdef CONFIG_S3C_DEV_HSMMC3
- s3c_hsmmc3_def_platdata.clocks = exynos4_hsmmc_clksrcs;
s3c_hsmmc3_def_platdata.cfg_gpio = exynos4_setup_sdhci3_cfg_gpio;
#endif
}
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH V3 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
From: Rajeshwari Shinde @ 2011-10-11 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318320907-8580-1-git-send-email-rajeshwari.s@samsung.com>
Add support for lookup of sdhci-s3c controller clocks using generic names
for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
Signed-off-by: Rajeshwari Shinde <rajeshwari.s@samsung.com>
---
arch/arm/mach-exynos4/clock.c | 88 +++++++++++++---------
arch/arm/mach-s3c2416/clock.c | 85 +++++++++++++--------
arch/arm/mach-s3c64xx/clock.c | 126 +++++++++++++++++++------------
arch/arm/mach-s5pc100/clock.c | 130 +++++++++++++++++++-------------
arch/arm/mach-s5pv210/clock.c | 167 +++++++++++++++++++++++++----------------
5 files changed, 364 insertions(+), 232 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 9f50e33..c6383b9 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
}, {
.clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.0",
- .parent = &clk_dout_mmc0.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 << 0),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.1",
- .parent = &clk_dout_mmc1.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 << 4),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.2",
- .parent = &clk_dout_mmc2.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 << 8),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.3",
- .parent = &clk_dout_mmc3.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 << 12),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
- }, {
- .clk = {
.name = "sclk_dwmmc",
.parent = &clk_dout_mmc4.clk,
.enable = exynos4_clksrc_mask_fsys_ctrl,
@@ -1250,6 +1214,50 @@ static struct clksrc_clk clk_sclk_uart3 = {
.reg_div = { .reg = S5P_CLKDIV_PERIL0, .shift = 12, .size = 4 },
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.0",
+ .parent = &clk_dout_mmc0.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 << 0),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.1",
+ .parent = &clk_dout_mmc1.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 << 4),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.2",
+ .parent = &clk_dout_mmc2.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 << 8),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.3",
+ .parent = &clk_dout_mmc3.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 << 12),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
+};
+
/* Clock initialization code */
static struct clksrc_clk *sysclks[] = {
&clk_mout_apll,
@@ -1289,6 +1297,10 @@ static struct clksrc_clk *clksrc_cdev[] = {
&clk_sclk_uart1,
&clk_sclk_uart2,
&clk_sclk_uart3,
+ &clk_sclk_mmc0,
+ &clk_sclk_mmc1,
+ &clk_sclk_mmc2,
+ &clk_sclk_mmc3,
};
static struct clk_lookup exynos4_clk_lookup[] = {
@@ -1296,6 +1308,10 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT("exynos4210-uart.1", "clk_uart_baud0", &clk_sclk_uart1.clk),
CLKDEV_INIT("exynos4210-uart.2", "clk_uart_baud0", &clk_sclk_uart2.clk),
CLKDEV_INIT("exynos4210-uart.3", "clk_uart_baud0", &clk_sclk_uart3.clk),
+ CLKDEV_INIT("exynos4-sdhci.0", "mmc_busclk.2", &clk_sclk_mmc0.clk),
+ CLKDEV_INIT("exynos4-sdhci.1", "mmc_busclk.2", &clk_sclk_mmc1.clk),
+ CLKDEV_INIT("exynos4-sdhci.2", "mmc_busclk.2", &clk_sclk_mmc2.clk),
+ CLKDEV_INIT("exynos4-sdhci.3", "mmc_busclk.2", &clk_sclk_mmc3.clk),
};
static int xtal_rate;
diff --git a/arch/arm/mach-s3c2416/clock.c b/arch/arm/mach-s3c2416/clock.c
index 72b7c62..4d84b15 100644
--- a/arch/arm/mach-s3c2416/clock.c
+++ b/arch/arm/mach-s3c2416/clock.c
@@ -82,39 +82,38 @@ static struct clksrc_clk hsmmc_div[] = {
},
};
-static struct clksrc_clk hsmmc_mux[] = {
- [0] = {
- .clk = {
- .name = "hsmmc-if",
- .devname = "s3c-sdhci.0",
- .ctrlbit = (1 << 6),
- .enable = s3c2443_clkcon_enable_s,
- },
- .sources = &(struct clksrc_sources) {
- .nr_sources = 2,
- .sources = (struct clk *[]) {
- [0] = &hsmmc_div[0].clk,
- [1] = NULL, /* to fix */
- },
- },
- .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
+static struct clksrc_clk hsmmc_mux0 = {
+ .clk = {
+ .name = "hsmmc-if",
+ .devname = "s3c-sdhci.0",
+ .ctrlbit = (1 << 6),
+ .enable = s3c2443_clkcon_enable_s,
},
- [1] = {
- .clk = {
- .name = "hsmmc-if",
- .devname = "s3c-sdhci.1",
- .ctrlbit = (1 << 12),
- .enable = s3c2443_clkcon_enable_s,
+ .sources = &(struct clksrc_sources) {
+ .nr_sources = 2,
+ .sources = (struct clk * []) {
+ [0] = &hsmmc_div[0].clk,
+ [1] = NULL, /* to fix */
},
- .sources = &(struct clksrc_sources) {
- .nr_sources = 2,
- .sources = (struct clk *[]) {
- [0] = &hsmmc_div[1].clk,
- [1] = NULL, /* to fix */
- },
+ },
+ .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
+};
+
+static struct clksrc_clk hsmmc_mux1 = {
+ .clk = {
+ .name = "hsmmc-if",
+ .devname = "s3c-sdhci.1",
+ .ctrlbit = (1 << 12),
+ .enable = s3c2443_clkcon_enable_s,
+ },
+ .sources = &(struct clksrc_sources) {
+ .nr_sources = 2,
+ .sources = (struct clk * []) {
+ [0] = &hsmmc_div[1].clk,
+ [1] = NULL, /* to fix */
},
- .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
},
+ .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
};
static struct clk hsmmc0_clk = {
@@ -125,6 +124,14 @@ static struct clk hsmmc0_clk = {
.ctrlbit = S3C2416_HCLKCON_HSMMC0,
};
+static struct clk hsmmc1_clk = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.1",
+ .parent = &clk_h,
+ .enable = s3c2443_clkcon_enable_h,
+ .ctrlbit = S3C2443_HCLKCON_HSMMC,
+};
+
static inline unsigned int s3c2416_fclk_div(unsigned long clkcon0)
{
clkcon0 &= 7 << S3C2443_CLKDIV0_ARMDIV_SHIFT;
@@ -137,14 +144,25 @@ void __init_or_cpufreq s3c2416_setup_clocks(void)
s3c2443_common_setup_clocks(s3c2416_get_pll, s3c2416_fclk_div);
}
-
static struct clksrc_clk *clksrcs[] __initdata = {
&hsspi_eplldiv,
&hsspi_mux,
&hsmmc_div[0],
&hsmmc_div[1],
- &hsmmc_mux[0],
- &hsmmc_mux[1],
+ &hsmmc_mux0,
+ &hsmmc_mux1,
+};
+
+static struct clk *clk_cdev[] = {
+ &hsmmc0_clk,
+ &hsmmc1_clk,
+};
+
+static struct clk_lookup s3c2416_clk_lookup[] = {
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &hsmmc0_clk),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &hsmmc1_clk),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &hsmmc_mux0.clk),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &hsmmc_mux1.clk),
};
void __init s3c2416_init_clocks(int xtal)
@@ -163,7 +181,8 @@ void __init s3c2416_init_clocks(int xtal)
for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
s3c_register_clksrc(clksrcs[ptr], 1);
- s3c24xx_register_clock(&hsmmc0_clk);
+ s3c24xx_register_clocks(clk_cdev, ARRAY_SIZE(clk_cdev));
+ clkdev_add_table(s3c2416_clk_lookup, ARRAY_SIZE(s3c2416_clk_lookup));
s3c_pwmclk_init();
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 2addd98..415c540 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -243,24 +243,6 @@ static struct clk init_clocks[] = {
.enable = s3c64xx_hclk_ctrl,
.ctrlbit = S3C_CLKCON_HCLK_UHOST,
}, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.0",
- .parent = &clk_h,
- .enable = s3c64xx_hclk_ctrl,
- .ctrlbit = S3C_CLKCON_HCLK_HSMMC0,
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.1",
- .parent = &clk_h,
- .enable = s3c64xx_hclk_ctrl,
- .ctrlbit = S3C_CLKCON_HCLK_HSMMC1,
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.2",
- .parent = &clk_h,
- .enable = s3c64xx_hclk_ctrl,
- .ctrlbit = S3C_CLKCON_HCLK_HSMMC2,
- }, {
.name = "otg",
.parent = &clk_h,
.enable = s3c64xx_hclk_ctrl,
@@ -310,6 +292,29 @@ static struct clk init_clocks[] = {
}
};
+static struct clk clk_hsmmc0 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.0",
+ .parent = &clk_h,
+ .enable = s3c64xx_hclk_ctrl,
+ .ctrlbit = S3C_CLKCON_HCLK_HSMMC0,
+};
+
+static struct clk clk_hsmmc1 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.1",
+ .parent = &clk_h,
+ .enable = s3c64xx_hclk_ctrl,
+ .ctrlbit = S3C_CLKCON_HCLK_HSMMC1,
+};
+
+static struct clk clk_hsmmc2 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.2",
+ .parent = &clk_h,
+ .enable = s3c64xx_hclk_ctrl,
+ .ctrlbit = S3C_CLKCON_HCLK_HSMMC2,
+};
static struct clk clk_fout_apll = {
.name = "fout_apll",
@@ -578,36 +583,6 @@ static struct clksrc_sources clkset_camif = {
static struct clksrc_clk clksrcs[] = {
{
.clk = {
- .name = "mmc_bus",
- .devname = "s3c-sdhci.0",
- .ctrlbit = S3C_CLKCON_SCLK_MMC0,
- .enable = s3c64xx_sclk_ctrl,
- },
- .reg_src = { .reg = S3C_CLK_SRC, .shift = 18, .size = 2 },
- .reg_div = { .reg = S3C_CLK_DIV1, .shift = 0, .size = 4 },
- .sources = &clkset_spi_mmc,
- }, {
- .clk = {
- .name = "mmc_bus",
- .devname = "s3c-sdhci.1",
- .ctrlbit = S3C_CLKCON_SCLK_MMC1,
- .enable = s3c64xx_sclk_ctrl,
- },
- .reg_src = { .reg = S3C_CLK_SRC, .shift = 20, .size = 2 },
- .reg_div = { .reg = S3C_CLK_DIV1, .shift = 4, .size = 4 },
- .sources = &clkset_spi_mmc,
- }, {
- .clk = {
- .name = "mmc_bus",
- .devname = "s3c-sdhci.2",
- .ctrlbit = S3C_CLKCON_SCLK_MMC2,
- .enable = s3c64xx_sclk_ctrl,
- },
- .reg_src = { .reg = S3C_CLK_SRC, .shift = 22, .size = 2 },
- .reg_div = { .reg = S3C_CLK_DIV1, .shift = 8, .size = 4 },
- .sources = &clkset_spi_mmc,
- }, {
- .clk = {
.name = "usb-bus-host",
.ctrlbit = S3C_CLKCON_SCLK_UHOST,
.enable = s3c64xx_sclk_ctrl,
@@ -697,6 +672,42 @@ static struct clksrc_clk clk_sclk_uclk = {
.sources = &clkset_uart,
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk = {
+ .name = "mmc_bus",
+ .devname = "s3c-sdhci.0",
+ .ctrlbit = S3C_CLKCON_SCLK_MMC0,
+ .enable = s3c64xx_sclk_ctrl,
+ },
+ .reg_src = { .reg = S3C_CLK_SRC, .shift = 18, .size = 2 },
+ .reg_div = { .reg = S3C_CLK_DIV1, .shift = 0, .size = 4 },
+ .sources = &clkset_spi_mmc,
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk = {
+ .name = "mmc_bus",
+ .devname = "s3c-sdhci.1",
+ .ctrlbit = S3C_CLKCON_SCLK_MMC1,
+ .enable = s3c64xx_sclk_ctrl,
+ },
+ .reg_src = { .reg = S3C_CLK_SRC, .shift = 20, .size = 2 },
+ .reg_div = { .reg = S3C_CLK_DIV1, .shift = 4, .size = 4 },
+ .sources = &clkset_spi_mmc,
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk = {
+ .name = "mmc_bus",
+ .devname = "s3c-sdhci.2",
+ .ctrlbit = S3C_CLKCON_SCLK_MMC2,
+ .enable = s3c64xx_sclk_ctrl,
+ },
+ .reg_src = { .reg = S3C_CLK_SRC, .shift = 22, .size = 2 },
+ .reg_div = { .reg = S3C_CLK_DIV1, .shift = 8, .size = 4 },
+ .sources = &clkset_spi_mmc,
+};
+
/* Clock initialisation code */
static struct clksrc_clk *init_parents[] = {
@@ -707,11 +718,26 @@ static struct clksrc_clk *init_parents[] = {
static struct clksrc_clk *clksrc_cdev[] = {
&clk_sclk_uclk,
+ &clk_sclk_mmc0,
+ &clk_sclk_mmc1,
+ &clk_sclk_mmc2,
+};
+
+static struct clk *clk_cdev[] = {
+ &clk_hsmmc0,
+ &clk_hsmmc1,
+ &clk_hsmmc2,
};
static struct clk_lookup s3c64xx_clk_lookup[] = {
CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
CLKDEV_INIT(NULL, "clk_uart_baud3", &clk_sclk_uclk.clk),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &clk_hsmmc0),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &clk_hsmmc1),
+ CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.0", &clk_hsmmc2),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &clk_sclk_mmc0.clk),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_sclk_mmc1.clk),
+ CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.2", &clk_sclk_mmc2.clk),
};
#define GET_DIV(clk, field) ((((clk) & field##_MASK) >> field##_SHIFT) + 1)
@@ -834,6 +860,10 @@ void __init s3c64xx_register_clocks(unsigned long xtal,
s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
+ s3c24xx_register_clocks(clk_cdev, ARRAY_SIZE(clk_cdev));
+ for (cnt = 0; cnt < ARRAY_SIZE(clk_cdev); cnt++)
+ s3c_disable_clocks(clk_cdev[cnt], 1);
+
s3c24xx_register_clocks(clks1, ARRAY_SIZE(clks1));
s3c_register_clksrc(clksrcs, ARRAY_SIZE(clksrcs));
for (cnt = 0; cnt < ARRAY_SIZE(clksrc_cdev); cnt++)
diff --git a/arch/arm/mach-s5pc100/clock.c b/arch/arm/mach-s5pc100/clock.c
index 9d644ec..69829ba 100644
--- a/arch/arm/mach-s5pc100/clock.c
+++ b/arch/arm/mach-s5pc100/clock.c
@@ -426,24 +426,6 @@ static struct clk init_clocks_off[] = {
.enable = s5pc100_d0_2_ctrl,
.ctrlbit = (1 << 1),
}, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.2",
- .parent = &clk_div_d1_bus.clk,
- .enable = s5pc100_d1_0_ctrl,
- .ctrlbit = (1 << 7),
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.1",
- .parent = &clk_div_d1_bus.clk,
- .enable = s5pc100_d1_0_ctrl,
- .ctrlbit = (1 << 6),
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.0",
- .parent = &clk_div_d1_bus.clk,
- .enable = s5pc100_d1_0_ctrl,
- .ctrlbit = (1 << 5),
- }, {
.name = "modemif",
.parent = &clk_div_d1_bus.clk,
.enable = s5pc100_d1_0_ctrl,
@@ -711,6 +693,30 @@ static struct clk init_clocks_off[] = {
},
};
+static struct clk clk_hsmmc2 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.2",
+ .parent = &clk_div_d1_bus.clk,
+ .enable = s5pc100_d1_0_ctrl,
+ .ctrlbit = (1 << 7),
+};
+
+static struct clk clk_hsmmc1 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.1",
+ .parent = &clk_div_d1_bus.clk,
+ .enable = s5pc100_d1_0_ctrl,
+ .ctrlbit = (1 << 6),
+};
+
+static struct clk clk_hsmmc0 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.0",
+ .parent = &clk_div_d1_bus.clk,
+ .enable = s5pc100_d1_0_ctrl,
+ .ctrlbit = (1 << 5),
+};
+
static struct clk clk_vclk54m = {
.name = "vclk_54m",
.rate = 54000000,
@@ -1014,39 +1020,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLK_DIV3, .shift = 24, .size = 4 },
}, {
.clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.0",
- .ctrlbit = (1 << 12),
- .enable = s5pc100_sclk1_ctrl,
-
- },
- .sources = &clk_src_mmc0,
- .reg_src = { .reg = S5P_CLK_SRC2, .shift = 0, .size = 2 },
- .reg_div = { .reg = S5P_CLK_DIV3, .shift = 0, .size = 4 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.1",
- .ctrlbit = (1 << 13),
- .enable = s5pc100_sclk1_ctrl,
-
- },
- .sources = &clk_src_mmc12,
- .reg_src = { .reg = S5P_CLK_SRC2, .shift = 4, .size = 2 },
- .reg_div = { .reg = S5P_CLK_DIV3, .shift = 4, .size = 4 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.2",
- .ctrlbit = (1 << 14),
- .enable = s5pc100_sclk1_ctrl,
-
- },
- .sources = &clk_src_mmc12,
- .reg_src = { .reg = S5P_CLK_SRC2, .shift = 8, .size = 2 },
- .reg_div = { .reg = S5P_CLK_DIV3, .shift = 8, .size = 4 },
- }, {
- .clk = {
.name = "sclk_irda",
.ctrlbit = (1 << 10),
.enable = s5pc100_sclk0_ctrl,
@@ -1099,6 +1072,42 @@ static struct clksrc_clk clk_sclk_uart = {
.reg_div = { .reg = S5P_CLK_DIV2, .shift = 0, .size = 4 },
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.0",
+ .ctrlbit = (1 << 12),
+ .enable = s5pc100_sclk1_ctrl,
+ },
+ .sources = &clk_src_mmc0,
+ .reg_src = { .reg = S5P_CLK_SRC2, .shift = 0, .size = 2 },
+ .reg_div = { .reg = S5P_CLK_DIV3, .shift = 0, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.1",
+ .ctrlbit = (1 << 13),
+ .enable = s5pc100_sclk1_ctrl,
+ },
+ .sources = &clk_src_mmc12,
+ .reg_src = { .reg = S5P_CLK_SRC2, .shift = 4, .size = 2 },
+ .reg_div = { .reg = S5P_CLK_DIV3, .shift = 4, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.2",
+ .ctrlbit = (1 << 14),
+ .enable = s5pc100_sclk1_ctrl,
+ },
+ .sources = &clk_src_mmc12,
+ .reg_src = { .reg = S5P_CLK_SRC2, .shift = 8, .size = 2 },
+ .reg_div = { .reg = S5P_CLK_DIV3, .shift = 8, .size = 4 },
+};
+
/* Clock initialisation code */
static struct clksrc_clk *sysclks[] = {
&clk_mout_apll,
@@ -1128,8 +1137,17 @@ static struct clksrc_clk *sysclks[] = {
&clk_sclk_spdif,
};
+static struct clk *clk_cdev[] = {
+ &clk_hsmmc0,
+ &clk_hsmmc1,
+ &clk_hsmmc2,
+};
+
static struct clksrc_clk *clksrc_cdev[] = {
&clk_sclk_uart,
+ &clk_sclk_mmc0,
+ &clk_sclk_mmc1,
+ &clk_sclk_mmc2,
};
void __init_or_cpufreq s5pc100_setup_clocks(void)
@@ -1274,6 +1292,12 @@ static struct clk *clks[] __initdata = {
static struct clk_lookup s5pc100_clk_lookup[] = {
CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
CLKDEV_INIT(NULL, "clk_uart_baud3", &clk_sclk_uart.clk),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &clk_hsmmc0),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &clk_hsmmc1),
+ CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.0", &clk_hsmmc2),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &clk_sclk_mmc0.clk),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_sclk_mmc1.clk),
+ CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.2", &clk_sclk_mmc2.clk),
};
void __init s5pc100_register_clocks(void)
@@ -1294,6 +1318,10 @@ void __init s5pc100_register_clocks(void)
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
clkdev_add_table(s5pc100_clk_lookup, ARRAY_SIZE(s5pc100_clk_lookup));
+ s3c24xx_register_clocks(clk_cdev, ARRAY_SIZE(clk_cdev));
+ for (ptr = 0; ptr < ARRAY_SIZE(clk_cdev); ptr++)
+ s3c_disable_clocks(clk_cdev[ptr], 1);
+
s3c24xx_register_clock(&dummy_apb_pclk);
s3c_pwmclk_init();
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index 43a045d..dc4586b 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -399,30 +399,6 @@ static struct clk init_clocks_off[] = {
.enable = s5pv210_clk_ip1_ctrl,
.ctrlbit = (1<<25),
}, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.0",
- .parent = &clk_hclk_psys.clk,
- .enable = s5pv210_clk_ip2_ctrl,
- .ctrlbit = (1<<16),
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.1",
- .parent = &clk_hclk_psys.clk,
- .enable = s5pv210_clk_ip2_ctrl,
- .ctrlbit = (1<<17),
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.2",
- .parent = &clk_hclk_psys.clk,
- .enable = s5pv210_clk_ip2_ctrl,
- .ctrlbit = (1<<18),
- }, {
- .name = "hsmmc",
- .devname = "s3c-sdhci.3",
- .parent = &clk_hclk_psys.clk,
- .enable = s5pv210_clk_ip2_ctrl,
- .ctrlbit = (1<<19),
- }, {
.name = "systimer",
.parent = &clk_pclk_psys.clk,
.enable = s5pv210_clk_ip3_ctrl,
@@ -559,6 +535,38 @@ static struct clk init_clocks[] = {
},
};
+static struct clk clk_hsmmc0 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.0",
+ .parent = &clk_hclk_psys.clk,
+ .enable = s5pv210_clk_ip2_ctrl,
+ .ctrlbit = (1<<16),
+};
+
+static struct clk clk_hsmmc1 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.1",
+ .parent = &clk_hclk_psys.clk,
+ .enable = s5pv210_clk_ip2_ctrl,
+ .ctrlbit = (1<<17),
+};
+
+static struct clk clk_hsmmc2 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.2",
+ .parent = &clk_hclk_psys.clk,
+ .enable = s5pv210_clk_ip2_ctrl,
+ .ctrlbit = (1<<18),
+};
+
+static struct clk clk_hsmmc3 = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.3",
+ .parent = &clk_hclk_psys.clk,
+ .enable = s5pv210_clk_ip2_ctrl,
+ .ctrlbit = (1<<19),
+};
+
static struct clk *clkset_uart_list[] = {
[6] = &clk_mout_mpll.clk,
[7] = &clk_mout_epll.clk,
@@ -866,46 +874,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLK_DIV1, .shift = 20, .size = 4 },
}, {
.clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.0",
- .enable = s5pv210_clk_mask0_ctrl,
- .ctrlbit = (1 << 8),
- },
- .sources = &clkset_group2,
- .reg_src = { .reg = S5P_CLK_SRC4, .shift = 0, .size = 4 },
- .reg_div = { .reg = S5P_CLK_DIV4, .shift = 0, .size = 4 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.1",
- .enable = s5pv210_clk_mask0_ctrl,
- .ctrlbit = (1 << 9),
- },
- .sources = &clkset_group2,
- .reg_src = { .reg = S5P_CLK_SRC4, .shift = 4, .size = 4 },
- .reg_div = { .reg = S5P_CLK_DIV4, .shift = 4, .size = 4 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.2",
- .enable = s5pv210_clk_mask0_ctrl,
- .ctrlbit = (1 << 10),
- },
- .sources = &clkset_group2,
- .reg_src = { .reg = S5P_CLK_SRC4, .shift = 8, .size = 4 },
- .reg_div = { .reg = S5P_CLK_DIV4, .shift = 8, .size = 4 },
- }, {
- .clk = {
- .name = "sclk_mmc",
- .devname = "s3c-sdhci.3",
- .enable = s5pv210_clk_mask0_ctrl,
- .ctrlbit = (1 << 11),
- },
- .sources = &clkset_group2,
- .reg_src = { .reg = S5P_CLK_SRC4, .shift = 12, .size = 4 },
- .reg_div = { .reg = S5P_CLK_DIV4, .shift = 12, .size = 4 },
- }, {
- .clk = {
.name = "sclk_mfc",
.devname = "s5p-mfc",
.enable = s5pv210_clk_ip0_ctrl,
@@ -1030,11 +998,70 @@ static struct clksrc_clk clk_sclk_uart3 = {
.reg_div = { .reg = S5P_CLK_DIV4, .shift = 28, .size = 4 },
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.0",
+ .enable = s5pv210_clk_mask0_ctrl,
+ .ctrlbit = (1 << 8),
+ },
+ .sources = &clkset_group2,
+ .reg_src = { .reg = S5P_CLK_SRC4, .shift = 0, .size = 4 },
+ .reg_div = { .reg = S5P_CLK_DIV4, .shift = 0, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.1",
+ .enable = s5pv210_clk_mask0_ctrl,
+ .ctrlbit = (1 << 9),
+ },
+ .sources = &clkset_group2,
+ .reg_src = { .reg = S5P_CLK_SRC4, .shift = 4, .size = 4 },
+ .reg_div = { .reg = S5P_CLK_DIV4, .shift = 4, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.2",
+ .enable = s5pv210_clk_mask0_ctrl,
+ .ctrlbit = (1 << 10),
+ },
+ .sources = &clkset_group2,
+ .reg_src = { .reg = S5P_CLK_SRC4, .shift = 8, .size = 4 },
+ .reg_div = { .reg = S5P_CLK_DIV4, .shift = 8, .size = 4 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+ .clk = {
+ .name = "sclk_mmc",
+ .devname = "s3c-sdhci.3",
+ .enable = s5pv210_clk_mask0_ctrl,
+ .ctrlbit = (1 << 11),
+ },
+ .sources = &clkset_group2,
+ .reg_src = { .reg = S5P_CLK_SRC4, .shift = 12, .size = 4 },
+ .reg_div = { .reg = S5P_CLK_DIV4, .shift = 12, .size = 4 },
+};
+
static struct clksrc_clk *clksrc_cdev[] = {
&clk_sclk_uart0,
&clk_sclk_uart1,
&clk_sclk_uart2,
&clk_sclk_uart3,
+ &clk_sclk_mmc0,
+ &clk_sclk_mmc1,
+ &clk_sclk_mmc2,
+ &clk_sclk_mmc3,
+};
+
+static struct clk *clk_cdev[] = {
+ &clk_hsmmc0,
+ &clk_hsmmc1,
+ &clk_hsmmc2,
+ &clk_hsmmc3,
};
/* Clock initialisation code */
@@ -1282,6 +1309,14 @@ static struct clk_lookup s5pv210_clk_lookup[] = {
CLKDEV_INIT("s5pv210-uart.1", "clk_uart_baud1", &clk_sclk_uart1.clk),
CLKDEV_INIT("s5pv210-uart.2", "clk_uart_baud1", &clk_sclk_uart2.clk),
CLKDEV_INIT("s5pv210-uart.3", "clk_uart_baud1", &clk_sclk_uart3.clk),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &clk_hsmmc0),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &clk_hsmmc1),
+ CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.0", &clk_hsmmc2),
+ CLKDEV_INIT("s3c-sdhci.3", "mmc_busclk.0", &clk_hsmmc3),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &clk_sclk_mmc0.clk),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_sclk_mmc1.clk),
+ CLKDEV_INIT("s3c-sdhci.2", "mmc_busclk.2", &clk_sclk_mmc2.clk),
+ CLKDEV_INIT("s3c-sdhci.3", "mmc_busclk.2", &clk_sclk_mmc3.clk),
};
void __init s5pv210_register_clocks(void)
@@ -1306,6 +1341,10 @@ void __init s5pv210_register_clocks(void)
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
clkdev_add_table(s5pv210_clk_lookup, ARRAY_SIZE(s5pv210_clk_lookup));
+ s3c24xx_register_clocks(clk_cdev, ARRAY_SIZE(clk_cdev));
+ for (ptr = 0; ptr < ARRAY_SIZE(clk_cdev); ptr++)
+ s3c_disable_clocks(clk_cdev[ptr], 1);
+
s3c24xx_register_clock(&dummy_apb_pclk);
s3c_pwmclk_init();
}
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH] gpio: exynos4: Add device tree support
From: Thomas Abraham @ 2011-10-11 8:16 UTC (permalink / raw)
To: linux-arm-kernel
As gpio chips get registered, a device tree node which represents the
gpio chip is searched and attached to it. A translate function is also
provided to convert the gpio specifier into actual platform settings
for pin function selection, pull up/down and driver strength settings.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
This patch is based on the latest consolidated Samsung GPIO driver available
in the following tree:
https://github.com/kgene/linux-samsung.git branch: for-next
.../devicetree/bindings/gpio/gpio-samsung.txt | 30 +++++++++++
drivers/gpio/gpio-samsung.c | 53 ++++++++++++++++++++
2 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-samsung.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
new file mode 100644
index 0000000..883faeb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
@@ -0,0 +1,30 @@
+Samsung Exynos4 GPIO Controller
+
+Required properties:
+- compatible: Format of compatible property value should be
+ "samsung,exynos4-gpio-<controller_name>". Example: For GPA0 controller, the
+ compatible property value should be "samsung,exynos4-gpio-gpa0".
+
+- reg: Physical base address of the controller and length of memory mapped region.
+
+- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
+ should be the following with values derived from the SoC user manual.
+ <[phandle of the gpio controller node] <pin number within the gpio controller]
+ [mux function] [pull up/down] [drive strength]>
+
+- gpio-controller: Specifies that the node is a gpio controller.
+
+- #address-cells: should be 1.
+
+- #size-cells: should be 1.
+
+Example:
+
+ gpa0: gpio-controller at 11400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "samsung,exynos4-gpio-gpa0";
+ reg = <0x11400000 0x20>;
+ #gpio-cells = <4>;
+ gpio-controller;
+ };
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b6be77a..037d3bb 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -24,6 +24,10 @@
#include <linux/interrupt.h>
#include <linux/sysdev.h>
#include <linux/ioport.h>
+#ifdef CONFIG_OF
+#include <linux/of.h>
+#include <linux/slab.h>
+#endif
#include <asm/irq.h>
@@ -2353,6 +2357,52 @@ static struct samsung_gpio_chip exynos4_gpios_3[] = {
#endif
};
+#if defined(CONFIG_ARCH_EXYNOS4) && defined(CONFIG_OF)
+int exynos4_gpio_xlate(struct gpio_chip *gc, struct device_node *np,
+ const void *gpio_spec, u32 *flags)
+{
+ const __be32 *gpio = gpio_spec;
+ const u32 n = be32_to_cpup(gpio);
+ unsigned int pin = gc->base + be32_to_cpu(gpio[0]);
+
+ if (gc->of_gpio_n_cells < 4) {
+ WARN_ON(1);
+ return -EINVAL;
+ }
+
+ if (n > gc->ngpio)
+ return -EINVAL;
+
+ s3c_gpio_cfgpin(pin, S3C_GPIO_SFN(be32_to_cpu(gpio[1])));
+ s3c_gpio_setpull(pin, be32_to_cpu(gpio[2]));
+ s5p_gpio_set_drvstr(pin, be32_to_cpu(gpio[3]));
+ return n;
+}
+
+static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *gc)
+{
+ const char exynos4_gpio_compat_base[] = "samsung,exynos4-gpio-";
+ char *exynos4_gpio_compat;
+
+ exynos4_gpio_compat = kzalloc(strlen(exynos4_gpio_compat_base) +
+ strlen(gc->label), GFP_KERNEL);
+ if (!exynos4_gpio_compat)
+ return;
+
+ strcpy(exynos4_gpio_compat, exynos4_gpio_compat_base);
+ strcat(exynos4_gpio_compat, gc->label);
+ gc->of_node = of_find_compatible_node(NULL, NULL, exynos4_gpio_compat);
+ gc->of_gpio_n_cells = 4;
+ gc->of_xlate = exynos4_gpio_xlate;
+ kfree(exynos4_gpio_compat);
+}
+#else
+static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *chip)
+{
+ return;
+}
+#endif /* defined(CONFIG_ARCH_EXYNOS4) && defined(CONFIG_OF) */
+
/* TODO: cleanup soc_is_* */
static __init int samsung_gpiolib_init(void)
{
@@ -2434,6 +2484,7 @@ static __init int samsung_gpiolib_init(void)
chip->config = &exynos4_gpio_cfg;
chip->group = group++;
}
+ exynos4_gpiolib_attach_ofnode(&chip->chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpios_1, nr_chips, S5P_VA_GPIO1);
@@ -2446,6 +2497,7 @@ static __init int samsung_gpiolib_init(void)
chip->config = &exynos4_gpio_cfg;
chip->group = group++;
}
+ exynos4_gpiolib_attach_ofnode(&chip->chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpios_2, nr_chips, S5P_VA_GPIO2);
@@ -2458,6 +2510,7 @@ static __init int samsung_gpiolib_init(void)
chip->config = &exynos4_gpio_cfg;
chip->group = group++;
}
+ exynos4_gpiolib_attach_ofnode(&chip->chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpios_3, nr_chips, S5P_VA_GPIO3);
--
1.6.6.rc2
^ permalink raw reply related
* Realtek ALC530 codec driver
From: 卞磊 @ 2011-10-11 8:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi ALL,
I can't find the Realtek ALC530 codec driver in current kernel.
Where can i get it? Thanks.
BRs,
Lei.Bian
^ permalink raw reply
* [Linaro-mm-sig] [PATCH 1/2] ARM: initial proof-of-concept IOMMU mapper for DMA-mapping
From: Marek Szyprowski @ 2011-10-11 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <401E54CE964CD94BAE1EB4A729C7087E37225197F8@HQMAIL04.nvidia.com>
Hello,
On Monday, October 10, 2011 11:57 PM Krishna Reddy wrote:
> Marek,
> Here is a patch that has fixes to get SDHC driver work as a DMA IOMMU client. Here is the
> overview of changes.
>
> 1. Converted the mutex to spinlock to handle atomic context calls and used spinlock in
> necessary places.
> 2. Implemented arm_iommu_map_page and arm_iommu_unmap_page, which are used by MMC host stack.
> 3. Fixed the bugs identified during testing with SDHC driver.
Thanks for your work! I agree that spinlock protection is the correct approach. However
I have some comments on your changes. Please see the code.
> From: Krishna Reddy <vdumpa@nvidia.com>
> Date: Fri, 7 Oct 2011 17:25:59 -0700
> Subject: [PATCH] ARM: dma-mapping: Implement arm_iommu_map_page/unmap_page and fix issues.
>
> Change-Id: I47a1a0065538fa0a161dd6d551b38079bd8f84fd
> ---
> arch/arm/include/asm/dma-iommu.h | 3 +-
> arch/arm/mm/dma-mapping.c | 182 +++++++++++++++++++++-----------------
> 2 files changed, 102 insertions(+), 83 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
> index 0b2677e..ad1a4d9 100644
> --- a/arch/arm/include/asm/dma-iommu.h
> +++ b/arch/arm/include/asm/dma-iommu.h
> @@ -7,6 +7,7 @@
> #include <linux/scatterlist.h>
> #include <linux/dma-debug.h>
> #include <linux/kmemcheck.h>
> +#include <linux/spinlock_types.h>
>
> #include <asm/memory.h>
>
> @@ -19,7 +20,7 @@ struct dma_iommu_mapping {
> unsigned int order;
> dma_addr_t base;
>
> - struct mutex lock;
> + spinlock_t lock;
> };
>
> int arm_iommu_attach_device(struct device *dev, dma_addr_t base,
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 020bde1..0befd88 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -739,32 +739,42 @@ fs_initcall(dma_debug_do_init);
>
> /* IOMMU */
>
> -static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping, size_t size)
> +static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
> + size_t size)
> {
> - unsigned int order = get_order(size);
> unsigned int align = 0;
> unsigned int count, start;
> + unsigned long flags;
>
> - if (order > mapping->order)
> - align = (1 << (order - mapping->order)) - 1;
> + count = ((PAGE_ALIGN(size) >> PAGE_SHIFT) +
> + (1 << mapping->order) - 1) >> mapping->order;
>
> - count = ((size >> PAGE_SHIFT) + (1 << mapping->order) - 1) >> mapping->order;
> -
> - start = bitmap_find_next_zero_area(mapping->bitmap, mapping->bits, 0, count, align);
> - if (start > mapping->bits)
> + spin_lock_irqsave(&mapping->lock, flags);
> + start = bitmap_find_next_zero_area(mapping->bitmap, mapping->bits,
> + 0, count, align);
> + if (start > mapping->bits) {
> + spin_unlock_irqrestore(&mapping->lock, flags);
> return ~0;
> + }
>
> bitmap_set(mapping->bitmap, start, count);
> + spin_unlock_irqrestore(&mapping->lock, flags);
>
> return mapping->base + (start << (mapping->order + PAGE_SHIFT));
> }
>
> -static inline void __free_iova(struct dma_iommu_mapping *mapping, dma_addr_t addr, size_t
> size)
> +static inline void __free_iova(struct dma_iommu_mapping *mapping,
> + dma_addr_t addr, size_t size)
> {
> - unsigned int start = (addr - mapping->base) >> (mapping->order + PAGE_SHIFT);
> - unsigned int count = ((size >> PAGE_SHIFT) + (1 << mapping->order) - 1) >> mapping-
> >order;
> + unsigned int start = (addr - mapping->base) >>
> + (mapping->order + PAGE_SHIFT);
> + unsigned int count = ((PAGE_ALIGN(size) >> PAGE_SHIFT) +
> + (1 << mapping->order) - 1) >> mapping->order;
> + unsigned long flags;
>
> + spin_lock_irqsave(&mapping->lock, flags);
> bitmap_clear(mapping->bitmap, start, count);
> + spin_unlock_irqrestore(&mapping->lock, flags);
> }
>
> static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, gfp_t gfp)
> @@ -867,7 +877,7 @@ __iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t
> prot)
> static dma_addr_t __iommu_create_mapping(struct device *dev, struct page **pages, size_t
> size)
> {
> struct dma_iommu_mapping *mapping = dev->archdata.mapping;
> - unsigned int count = size >> PAGE_SHIFT;
> + unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> dma_addr_t dma_addr, iova;
> int i, ret = ~0;
>
> @@ -892,13 +902,12 @@ fail:
> static int __iommu_remove_mapping(struct device *dev, dma_addr_t iova, size_t size)
> {
> struct dma_iommu_mapping *mapping = dev->archdata.mapping;
> - unsigned int count = size >> PAGE_SHIFT;
> + unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> int i;
>
> - for (i=0; i<count; i++) {
> - iommu_unmap(mapping->domain, iova, 0);
> - iova += PAGE_SIZE;
> - }
> + iova = iova & PAGE_MASK;
> + for (i=0; i<count; i++)
> + iommu_unmap(mapping->domain, iova + i * PAGE_SIZE, 0);
> __free_iova(mapping, iova, size);
> return 0;
> }
> @@ -906,7 +915,6 @@ static int __iommu_remove_mapping(struct device *dev, dma_addr_t iova,
> size_t si
> static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
> dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
> {
> - struct dma_iommu_mapping *mapping = dev->archdata.mapping;
> pgprot_t prot = __get_dma_pgprot(attrs, pgprot_kernel);
> struct page **pages;
> void *addr = NULL;
> @@ -914,11 +922,9 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
> *handle = ~0;
> size = PAGE_ALIGN(size);
>
> - mutex_lock(&mapping->lock);
> -
> pages = __iommu_alloc_buffer(dev, size, gfp);
> if (!pages)
> - goto err_unlock;
> + goto exit;
>
> *handle = __iommu_create_mapping(dev, pages, size);
> if (*handle == ~0)
> @@ -928,15 +934,13 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
> if (!addr)
> goto err_mapping;
>
> - mutex_unlock(&mapping->lock);
> return addr;
>
> err_mapping:
> __iommu_remove_mapping(dev, *handle, size);
> err_buffer:
> __iommu_free_buffer(dev, pages, size);
> -err_unlock:
> - mutex_unlock(&mapping->lock);
> +exit:
> return NULL;
> }
>
> @@ -944,11 +948,9 @@ static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct
> *vma,
> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> struct dma_attrs *attrs)
> {
> - unsigned long user_size;
> struct arm_vmregion *c;
>
> vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
> - user_size = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
>
> c = arm_vmregion_find(&consistent_head, (unsigned long)cpu_addr);
> if (c) {
> @@ -981,11 +983,9 @@ static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct
> *vma,
> void arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
> dma_addr_t handle, struct dma_attrs *attrs)
> {
> - struct dma_iommu_mapping *mapping = dev->archdata.mapping;
> struct arm_vmregion *c;
> size = PAGE_ALIGN(size);
>
> - mutex_lock(&mapping->lock);
> c = arm_vmregion_find(&consistent_head, (unsigned long)cpu_addr);
> if (c) {
> struct page **pages = c->priv;
> @@ -993,7 +993,6 @@ void arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
> __iommu_remove_mapping(dev, handle, size);
> __iommu_free_buffer(dev, pages, size);
> }
> - mutex_unlock(&mapping->lock);
> }
>
> static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
> @@ -1001,80 +1000,93 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
> enum dma_data_direction dir)
> {
> struct dma_iommu_mapping *mapping = dev->archdata.mapping;
> - dma_addr_t dma_addr, iova;
> + dma_addr_t iova;
> int ret = 0;
> + unsigned long i;
> + phys_addr_t phys = page_to_phys(sg_page(sg));
>
> + size = PAGE_ALIGN(size);
> *handle = ~0;
> - mutex_lock(&mapping->lock);
>
> - iova = dma_addr = __alloc_iova(mapping, size);
> - if (dma_addr == 0)
> - goto fail;
> -
> - while (size) {
> - unsigned int phys = page_to_phys(sg_page(sg));
> - unsigned int len = sg->offset + sg->length;
> + iova = __alloc_iova(mapping, size);
> + if (iova == 0)
> + return -ENOMEM;
>
> - if (!arch_is_coherent())
> - __dma_page_cpu_to_dev(sg_page(sg), sg->offset, sg->length, dir);
> -
> - while (len) {
> - ret = iommu_map(mapping->domain, iova, phys, 0, 0);
> - if (ret < 0)
> - goto fail;
> - iova += PAGE_SIZE;
> - len -= PAGE_SIZE;
> - size -= PAGE_SIZE;
> - }
> - sg = sg_next(sg);
> + if (!arch_is_coherent())
> + __dma_page_cpu_to_dev(sg_page(sg), sg->offset,
> + sg->length, dir);
> + for (i = 0; i < (size >> PAGE_SHIFT); i++) {
> + ret = iommu_map(mapping->domain, iova + i * PAGE_SIZE,
> + phys + i * PAGE_SIZE, 0, 0);
> + if (ret < 0)
> + goto fail;
> }
> -
> - *handle = dma_addr;
> - mutex_unlock(&mapping->lock);
> + *handle = iova;
>
> return 0;
> fail:
> + while (i--)
> + iommu_unmap(mapping->domain, iova + i * PAGE_SIZE, 0);
> +
> __iommu_remove_mapping(dev, iova, size);
> - mutex_unlock(&mapping->lock);
> return ret;
> }
>
> +static dma_addr_t arm_iommu_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size, enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + dma_addr_t dma_addr;
> +
> + if (!arch_is_coherent())
> + __dma_page_cpu_to_dev(page, offset, size, dir);
> +
> + BUG_ON((offset+size) > PAGE_SIZE);
> + dma_addr = __iommu_create_mapping(dev, &page, PAGE_SIZE);
> + return dma_addr + offset;
> +}
> +
> +static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + struct dma_iommu_mapping *mapping = dev->archdata.mapping;
> + phys_addr_t phys;
> +
> + phys = iommu_iova_to_phys(mapping->domain, handle);
> + __iommu_remove_mapping(dev, handle, size);
> + if (!arch_is_coherent())
> + __dma_page_dev_to_cpu(pfn_to_page(__phys_to_pfn(phys)),
> + phys & ~PAGE_MASK, size, dir);
> +}
> +
> int arm_iommu_map_sg(struct device *dev, struct scatterlist *sg, int nents,
> enum dma_data_direction dir, struct dma_attrs *attrs)
> {
> - struct scatterlist *s = sg, *dma = sg, *start = sg;
> - int i, count = 1;
> - unsigned int offset = s->offset;
> - unsigned int size = s->offset + s->length;
> + struct scatterlist *s;
> + unsigned int size;
> + int i, count = 0;
>
> - for (i = 1; i < nents; i++) {
> + for_each_sg(sg, s, nents, i) {
> s->dma_address = ~0;
> s->dma_length = 0;
> + size = s->offset + s->length;
>
> - s = sg_next(s);
> -
> - if (s->offset || (size & (PAGE_SIZE - 1))) {
> - if (__map_sg_chunk(dev, start, size, &dma->dma_address, dir) < 0)
> - goto bad_mapping;
> -
> - dma->dma_address += offset;
> - dma->dma_length = size;
> + if (__map_sg_chunk(dev, s, size, &s->dma_address, dir) < 0)
> + goto bad_mapping;
>
> - size = offset = s->offset;
> - start = s;
> - dma = sg_next(dma);
> - count += 1;
> - }
> - size += sg->length;
> + s->dma_address += s->offset;
> + s->dma_length = s->length;
> + count++;
> }
> - __map_sg_chunk(dev, start, size, &dma->dma_address, dir);
> - d->dma_address += offset;
>
> return count;
>
> bad_mapping:
> - for_each_sg(sg, s, count-1, i)
> - __iommu_remove_mapping(dev, sg_dma_address(s), sg_dma_len(s));
> + for_each_sg(sg, s, count, i) {
> + __iommu_remove_mapping(dev, sg_dma_address(s),
> + PAGE_ALIGN(sg_dma_len(s)));
> + }
> return 0;
> }
It looks that You have simplified arm_iommu_map_sg() function too much.
The main advantage of the iommu is to map scattered memory pages into
contiguous dma address space. DMA-mapping is allowed to merge consecutive
entries in the scatter list if hardware supports that. With IOMMU a call
to map_sg() might create only one dma element if the memory described by
the scatter list can be seen as contiguous (all chunks start and end on
page boundary). This means that arm_iommu_map_sg() should map all pages
into dma address returned in sg_dma_address(sg[0]) sg_dma_len(sg[0])
pair. I'm also not convinced that this is the best approach, but that's
how I was told to implement it:
http://article.gmane.org/gmane.linux.kernel/1128416
I agree that the API will be a bit cleaner if there is separate function
to map a scatter list into dma address space chunk-by-chunk (like
dma_map_sg() does it in most cases) and a function to map a scatter list
into one contiguous dma address. This would also simplify the buffer
management in the device drivers.
I'm not sure if mmc drivers are aware of coalescing the SG entries together.
If not the code must be updated to use dma_sg_len() and the dma entries
number returned from dma_map_sg() call.
(snipped)
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* Realtek ALC530 codec driver
From: Uwe Kleine-König @ 2011-10-11 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORxB+AE51evM8o_hMjo-Af0hezHw6MsdD+S6y8K_MsEdki1dw@mail.gmail.com>
On Tue, Oct 11, 2011 at 04:17:25PM +0800, ?? wrote:
> Hi ALL,
> I can't find the Realtek ALC530 codec driver in current kernel.
> Where can i get it? Thanks.
The usual way is to either open an editor, download the datasheet and
start coding or find someone who does exactly that for you (usually in
return for some money).
Other than that the alsa mailing list seem to be more appropriate for
development conversation about codecs than this list.
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Realtek ALC530 codec driver
From: Baruch Siach @ 2011-10-11 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORxB+AE51evM8o_hMjo-Af0hezHw6MsdD+S6y8K_MsEdki1dw@mail.gmail.com>
Hi ??,
On Tue, Oct 11, 2011 at 04:17:25PM +0800, ?? wrote:
> I can't find the Realtek ALC530 codec driver in current kernel.
> Where can i get it? Thanks.
The right list for these questions is alsa-devel. See
http://alsa-project.org/main/index.php/ASoC and
http://alsa-project.org/main/index.php/Mailing-lists.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* sched: ARM: arch_scale_freq_power
From: Vincent Guittot @ 2011-10-11 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318319852.14400.65.camel@laptop>
On 11 October 2011 09:57, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Tue, 2011-10-11 at 12:46 +0530, Amit Kucheria wrote:
>> Adding Peter to the discussion..
>
> Right, CCing the folks who actually wrote the code you're asking
> questions about always helps ;-)
>
>> On Thu, Oct 6, 2011 at 5:06 PM, Vincent Guittot
>> <vincent.guittot@linaro.org> wrote:
>> > I work to link the cpu_power of ARM cores to their frequency by using
>> > arch_scale_freq_power.
>
> Why and how? In particular note that if you're using something like the
> on-demand cpufreq governor this isn't going to work.
>
I have several goals. The 1st one is that I need to put more load on
some cpus when I have packages with different cpu frequency.
I also study if I can follow the real cpu frequency but it seems to be
not so easy. I have noticed that the cpu_power is updated periodical
except when we have a lot of newly_idle events.
Then, I have some use cases which have several running tasks but a low
cpu load. In this case, the small tasks are spread on several cpu by
the load_balance whereas they could be easily handled by one cpu
without significant performance modification. If the cpu_power is
higher than 1024, the cpu is no more seen out of capacity by the
load_balance as soon as a short process is running and teh main result
is that the small tasks will stay on the same cpu. This configuration
is mainly usefull for ARM dual core system when we want to power gate
one cpu. I use cyclictest to simulate such use case.
>> It's explained in the kernel that cpu_power is
>> > used to distribute load on cpus and a cpu with more cpu_power will
>> > pick up more load. The default value is SCHED_POWER_SCALE and I
>> > increase the value if I want a cpu to have more load than another one.
>> > Is there an advised range for cpu_power value as well as some time
>> > scale constraints for updating the cpu_power value ?
>
> Basically 1024 is the unit and denotes the capacity of a full core at
> 'normal' speed.
>
> Typically cpufreq would down-clock a core and thus you'd end up with a
> smaller number (linearly proportional to the freq ratio etc. although if
> you want to go really fancy you could determine the actual
> throughput/freq curves).
>
> Things like x86 turbo mode would result in a >1024 value.
>
> Things like SMT would typically result in <1024 and the SMT sum over the
> core >1024 (if you're lucky).
>
>> > I'm also wondering why this scheduler feature is currently disable by default ?
>
> Because the only implementation in existence (x86) is broken and I
> haven't gotten around to fixing it. Arguable we should disable that for
> the time being, see below.
>
>> In discussions with Vincent regarding this, I've wondered whether
>> cpu_power wouldn't be better renamed to cpu_capacity since that is
>> what it really seems to describe.
>
> Possibly, but its been cpu_power for ages and we use capacity to
> describe something else.
>
> ---
> ?arch/x86/kernel/cpu/sched.c | ? ?9 ++++++++-
> ?1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/sched.c b/arch/x86/kernel/cpu/sched.c
> index a640ae5..90ae68c 100644
> --- a/arch/x86/kernel/cpu/sched.c
> +++ b/arch/x86/kernel/cpu/sched.c
> @@ -6,7 +6,14 @@
> ?#include <asm/cpufeature.h>
> ?#include <asm/processor.h>
>
> -#ifdef CONFIG_SMP
> +#if 0 /* def CONFIG_SMP */
> +
> +/*
> + * Currently broken, we need to filter out idle time because the aperf/mperf
> + * ratio measures actual throughput, not capacity. This means that if a logical
> + * cpu idles it will report less capacity and receive less work, which isn't
> + * what we want.
> + */
>
> ?static DEFINE_PER_CPU(struct aperfmperf, old_perf_sched);
>
>
>
>
^ permalink raw reply
* sched: ARM: arch_scale_freq_power
From: Peter Zijlstra @ 2011-10-11 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtB_eXgggeEYmNsXkvL8NsoEoz_NJFgA4E5WtAm74F515Q@mail.gmail.com>
On Tue, 2011-10-11 at 10:51 +0200, Vincent Guittot wrote:
> I have several goals. The 1st one is that I need to put more load on
> some cpus when I have packages with different cpu frequency.
That should be rather easy.
> I also study if I can follow the real cpu frequency but it seems to be
> not so easy.
Why not?
> I have noticed that the cpu_power is updated periodical
> except when we have a lot of newly_idle events.
We can certainly fix that.
> Then, I have some use cases which have several running tasks but a low
> cpu load. In this case, the small tasks are spread on several cpu by
> the load_balance whereas they could be easily handled by one cpu
> without significant performance modification.
That shouldn't be done using cpu_power, we have sched_smt_power_savings
and sched_mc_power_savings for stuff like that.
Although I would really like to kill all those different
sched_*_power_savings knobs and reduce it to one.
> If the cpu_power is
> higher than 1024, the cpu is no more seen out of capacity by the
> load_balance as soon as a short process is running and teh main result
> is that the small tasks will stay on the same cpu. This configuration
> is mainly usefull for ARM dual core system when we want to power gate
> one cpu. I use cyclictest to simulate such use case.
Yeah, but that's wrong.
^ permalink raw reply
* [PATCH V3 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
From: Heiko Stübner @ 2011-10-11 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318320907-8580-4-git-send-email-rajeshwari.s@samsung.com>
Hi,
somehow this did not apply against linux-next for me:
error: patch failed: arch/arm/mach-exynos4/clock.c:1250
error: arch/arm/mach-exynos4/clock.c: patch does not apply
error: patch failed: arch/arm/mach-s3c64xx/clock.c:697
error: arch/arm/mach-s3c64xx/clock.c: patch does not apply
error: patch failed: arch/arm/mach-s5pc100/clock.c:1099
error: arch/arm/mach-s5pc100/clock.c: patch does not apply
error: patch failed: arch/arm/mach-s5pv210/clock.c:1030
error: arch/arm/mach-s5pv210/clock.c: patch does not apply
and:
Am Dienstag, 11. Oktober 2011, 10:15:07 schrieb Rajeshwari Shinde:
> Add support for lookup of sdhci-s3c controller clocks using generic names
> for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
[...]
> @@ -125,6 +124,14 @@ static struct clk hsmmc0_clk = {
> .ctrlbit = S3C2416_HCLKCON_HSMMC0,
> };
>
> +static struct clk hsmmc1_clk = {
> + .name = "hsmmc",
> + .devname = "s3c-sdhci.1",
> + .parent = &clk_h,
> + .enable = s3c2443_clkcon_enable_h,
> + .ctrlbit = S3C2443_HCLKCON_HSMMC,
> +};
> +
this would lead to the hsmmc1 hclk being registered twice, as it is already
registered in plat-s3c24xx/clock-2443.c .
How about the following, which also adds the lookup for the s3c2443-specific
hsmmc-sclk.
Heiko
diff --git a/arch/arm/mach-s3c2416/clock.c b/arch/arm/mach-s3c2416/clock.c
index 72b7c62..0b0b7c2 100644
--- a/arch/arm/mach-s3c2416/clock.c
+++ b/arch/arm/mach-s3c2416/clock.c
@@ -82,39 +82,38 @@ static struct clksrc_clk hsmmc_div[] = {
},
};
-static struct clksrc_clk hsmmc_mux[] = {
- [0] = {
- .clk = {
- .name = "hsmmc-if",
- .devname = "s3c-sdhci.0",
- .ctrlbit = (1 << 6),
- .enable = s3c2443_clkcon_enable_s,
- },
- .sources = &(struct clksrc_sources) {
- .nr_sources = 2,
- .sources = (struct clk *[]) {
- [0] = &hsmmc_div[0].clk,
- [1] = NULL, /* to fix */
- },
- },
- .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
+static struct clksrc_clk hsmmc_mux0 = {
+ .clk = {
+ .name = "hsmmc-if",
+ .devname = "s3c-sdhci.0",
+ .ctrlbit = (1 << 6),
+ .enable = s3c2443_clkcon_enable_s,
},
- [1] = {
- .clk = {
- .name = "hsmmc-if",
- .devname = "s3c-sdhci.1",
- .ctrlbit = (1 << 12),
- .enable = s3c2443_clkcon_enable_s,
+ .sources = &(struct clksrc_sources) {
+ .nr_sources = 2,
+ .sources = (struct clk * []) {
+ [0] = &hsmmc_div[0].clk,
+ [1] = NULL, /* to fix */
},
- .sources = &(struct clksrc_sources) {
- .nr_sources = 2,
- .sources = (struct clk *[]) {
- [0] = &hsmmc_div[1].clk,
- [1] = NULL, /* to fix */
- },
+ },
+ .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
+};
+
+static struct clksrc_clk hsmmc_mux1 = {
+ .clk = {
+ .name = "hsmmc-if",
+ .devname = "s3c-sdhci.1",
+ .ctrlbit = (1 << 12),
+ .enable = s3c2443_clkcon_enable_s,
+ },
+ .sources = &(struct clksrc_sources) {
+ .nr_sources = 2,
+ .sources = (struct clk * []) {
+ [0] = &hsmmc_div[1].clk,
+ [1] = NULL, /* to fix */
},
- .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
},
+ .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
};
static struct clk hsmmc0_clk = {
@@ -137,14 +136,19 @@ void __init_or_cpufreq s3c2416_setup_clocks(void)
s3c2443_common_setup_clocks(s3c2416_get_pll, s3c2416_fclk_div);
}
-
static struct clksrc_clk *clksrcs[] __initdata = {
&hsspi_eplldiv,
&hsspi_mux,
&hsmmc_div[0],
&hsmmc_div[1],
- &hsmmc_mux[0],
- &hsmmc_mux[1],
+ &hsmmc_mux0,
+ &hsmmc_mux1,
+};
+
+static struct clk_lookup s3c2416_clk_lookup[] = {
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &hsmmc0_clk),
+ CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &hsmmc_mux0.clk),
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &hsmmc_mux1.clk),
};
void __init s3c2416_init_clocks(int xtal)
@@ -164,6 +168,7 @@ void __init s3c2416_init_clocks(int xtal)
s3c_register_clksrc(clksrcs[ptr], 1);
s3c24xx_register_clock(&hsmmc0_clk);
+ clkdev_add_table(s3c2416_clk_lookup, ARRAY_SIZE(s3c2416_clk_lookup));
s3c_pwmclk_init();
diff --git a/arch/arm/mach-s3c2443/clock.c b/arch/arm/mach-s3c2443/clock.c
index cd51d04..38ca7df 100644
--- a/arch/arm/mach-s3c2443/clock.c
+++ b/arch/arm/mach-s3c2443/clock.c
@@ -275,6 +275,8 @@ void __init_or_cpufreq s3c2443_setup_clocks(void)
s3c2443_common_setup_clocks(s3c2443_get_mpll, s3c2443_fclk_div);
}
+static struct clk_lookup hsmmc_lookup = CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_hsmmc);
+
void __init s3c2443_init_clocks(int xtal)
{
unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
@@ -292,6 +294,8 @@ void __init s3c2443_init_clocks(int xtal)
for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
s3c_register_clksrc(clksrcs[ptr], 1);
+ clkdev_add(&hsmmc_lookup);
+
/* register clocks from clock array */
s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
diff --git a/arch/arm/plat-s3c24xx/s3c2443-clock.c b/arch/arm/plat-s3c24xx/s3c2443-clock.c
index 07a4c81..6997819 100644
--- a/arch/arm/plat-s3c24xx/s3c2443-clock.c
+++ b/arch/arm/plat-s3c24xx/s3c2443-clock.c
@@ -307,11 +307,6 @@ static struct clk init_clocks[] = {
.enable = s3c2443_clkcon_enable_h,
.ctrlbit = S3C2443_HCLKCON_DMA5,
}, {
- .name = "hsmmc",
- .parent = &clk_h,
- .enable = s3c2443_clkcon_enable_h,
- .ctrlbit = S3C2443_HCLKCON_HSMMC,
- }, {
.name = "gpio",
.parent = &clk_p,
.enable = s3c2443_clkcon_enable_p,
@@ -393,6 +388,14 @@ static struct clk init_clocks[] = {
}
};
+static struct clk hsmmc1_clk = {
+ .name = "hsmmc",
+ .devname = "s3c-sdhci.1",
+ .parent = &clk_h,
+ .enable = s3c2443_clkcon_enable_h,
+ .ctrlbit = S3C2443_HCLKCON_HSMMC,
+};
+
static inline unsigned long s3c2443_get_hdiv(unsigned long clkcon0)
{
clkcon0 &= S3C2443_CLKDIV0_HCLKDIV_MASK;
@@ -469,6 +472,8 @@ static struct clksrc_clk *clksrcs[] __initdata = {
&clk_msysclk,
};
+static struct clk_lookup hsmmc_lookup = CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &hsmmc1_clk);
+
void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
fdiv_fn get_fdiv)
{
@@ -490,6 +495,9 @@ void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
s3c_register_clksrc(clksrc_clks, ARRAY_SIZE(clksrc_clks));
s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
+ s3c24xx_register_clock(&hsmmc1_clk);
+ clkdev_add(&hsmmc_lookup);
+
/* See s3c2443/etc notes on disabling clocks@init time */
s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
--
^ permalink raw reply related
* [RFC 0/2] Introduce dma buffer sharing mechanism
From: Sumit Semwal @ 2011-10-11 9:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello Everyone,
Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.
This need comes forth from a variety of use cases including cameras, image
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.
This RFC is the first attempt in defining such a buffer sharing mechanism- it is
the result of discussions from a couple of memory-management mini-summits held
by Linaro to understand and address common needs around memory management. [1]
A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
allocator-defined operations on that buffer. This operation is called the
'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist using get_scatterlist and
put_scatterlist operations.
Documentation present in the patch-set gives more details.
This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
Daniel Vetter <daniel@ffwll.ch>.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
between two v4l2 devices. [2]
References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Sumit Semwal (2):
dma-buf: Introduce dma buffer sharing mechanism
dma-buf: Documentation for buffer sharing framework
Documentation/dma-buf-sharing.txt | 210 ++++++++++++++++++++++++++++++++
drivers/base/Kconfig | 10 ++
drivers/base/Makefile | 1 +
drivers/base/dma-buf.c | 242 +++++++++++++++++++++++++++++++++++++
include/linux/dma-buf.h | 162 +++++++++++++++++++++++++
5 files changed, 625 insertions(+), 0 deletions(-)
create mode 100644 Documentation/dma-buf-sharing.txt
create mode 100644 drivers/base/dma-buf.c
create mode 100644 include/linux/dma-buf.h
--
1.7.4.1
^ permalink raw reply
* sched: ARM: arch_scale_freq_power
From: Amit Kucheria @ 2011-10-11 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318324399.14400.71.camel@laptop>
On Tue, Oct 11, 2011 at 2:43 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Tue, 2011-10-11 at 10:51 +0200, Vincent Guittot wrote:
>> I have several goals. The 1st one is that I need to put more load on
>> some cpus when I have packages with different cpu frequency.
>
> That should be rather easy.
>
>> I also study if I can follow the real cpu frequency but it seems to be
>> not so easy.
>
> Why not?
>
>> ?I have noticed that the cpu_power is updated periodical
>> except when we have a lot of newly_idle events.
>
> We can certainly fix that.
>
>> Then, I have some use cases which have several running tasks but a low
>> cpu load. In this case, the small tasks are spread on several cpu by
>> the load_balance whereas they could be easily handled by one cpu
>> without significant performance modification.
>
> That shouldn't be done using cpu_power, we have sched_smt_power_savings
> and sched_mc_power_savings for stuff like that.
AFAICT, sched_mc assume all cores to have the same capacity - which is
certainly true of the x86 architecture. But in ARM you can see hybrid
cores[1] designed using different fab technology, so that some cores
can run at 'n' GHz and some at 'm' GHz. The idea being that when there
isn't much to do (e.g periodic keep alives for messaging, email, etc.)
you don't wake up the higher power-consuming cores.
^ permalink raw reply
* sched: ARM: arch_scale_freq_power
From: Vincent Guittot @ 2011-10-11 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318324399.14400.71.camel@laptop>
On 11 October 2011 11:13, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Tue, 2011-10-11 at 10:51 +0200, Vincent Guittot wrote:
>> I have several goals. The 1st one is that I need to put more load on
>> some cpus when I have packages with different cpu frequency.
>
> That should be rather easy.
>
I agree, I was mainly wondering If I should use a [1-1024] or a
[1024-xxxx] range and it seems that both can be used according : SMT
uses <1024 and x86 turbo mode uses >1024
>> I also study if I can follow the real cpu frequency but it seems to be
>> not so easy.
>
> Why not?
>
In fact, the problem is not really to follow the frequency but to be
sure that update_group_power is called often enough by load_balance.
The newly_idle event was also one main problem.
>> ?I have noticed that the cpu_power is updated periodical
>> except when we have a lot of newly_idle events.
>
> We can certainly fix that.
>
That's a good news.
>> Then, I have some use cases which have several running tasks but a low
>> cpu load. In this case, the small tasks are spread on several cpu by
>> the load_balance whereas they could be easily handled by one cpu
>> without significant performance modification.
>
> That shouldn't be done using cpu_power, we have sched_smt_power_savings
> and sched_mc_power_savings for stuff like that.
>
sched_mc_power_saving works fine when we have more than 2 cpus but
can't apply on a dual core because it needs at least 2 sched_groups
and the nr_running of these sched_groups must be higher than 0 but
smaller than group_capacity which is 1 on a dual core system.
> Although I would really like to kill all those different
> sched_*_power_savings knobs and reduce it to one.
>
>> If the cpu_power is
>> higher than 1024, the cpu is no more seen out of capacity by the
>> load_balance as soon as a short process is running and teh main result
>> is that the small tasks will stay on the same cpu. This configuration
>> is mainly usefull for ARM dual core system when we want to power gate
>> one cpu. I use cyclictest to simulate such use case.
>
> Yeah, but that's wrong.
That's the only way I have found to gathers small task without any
relationship on one cpu. Do you know any better solution ?
>
>
Regards,
Vincent
^ permalink raw reply
* [RFC/PATCH 3/7] ARM: ARM11 MPCore: {clean,flush}_pmd_entry are not preempt safe
From: Catalin Marinas @ 2011-10-11 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317955121-28047-4-git-send-email-gdavis@mvista.com>
On Fri, Oct 07, 2011 at 03:38:37AM +0100, gdavis at mvista.com wrote:
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 594d677..3c8253f 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -567,12 +567,24 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,
> if (addr & SECTION_SIZE)
> pmd++;
>
> + if (cache_ops_need_broadcast())
> + preempt_disable();
> do {
> *pmd = __pmd(phys | type->prot_sect);
> phys += SECTION_SIZE;
> } while (pmd++, addr += SECTION_SIZE, addr != end);
>
> + /* FIXME: Multiple PMD entries may be written above
> + * but only one cache line, up to 8 PMDs depending
> + * on the alignment of this mapping, is flushed below.
> + * IFF this mapping spans >8MiB, then only the first
> + * 8MiB worth of entries will be flushed. Entries
> + * above the 8MiB limit will not be flushed if I
> + * read this correctly.
> + */
> flush_pmd_entry(p);
> + if (cache_ops_need_broadcast())
> + preempt_enable();
My reading of the create_mapping() code is that alloc_init_pud() and
alloc_init_section() are called with a 2MB range only (that's 2
entries) given by pgd_addr_end().
--
Catalin
^ 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