* [PATCH 2/3] serial: omap: Remove the default setting of special character
From: Shubhrajyoti D @ 2012-10-03 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349265278-27763-1-git-send-email-shubhrajyoti@ti.com>
Special character detect enable if enabled by default.Received data
comparison with XOFF2 data happens by default.
tty provides only XOFF1 no X0FF2 is provided so no need
to enable check for XOFF2.
Keeping this enabled might give some slow transfers due to dummy xoff2
comparison with xoff2 reset value.
Since not all want the XOFF2 support lets not enable it by
default.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index fd0fb8c..caf49a6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -702,11 +702,7 @@ serial_omap_configure_xonxoff
serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
- /* Enable special char function UARTi.EFR_REG[5] and
- * load the new software flow control mode IXON or IXOFF
- * and restore the UARTi.EFR_REG[4] ENHANCED_EN value.
- */
- serial_out(up, UART_EFR, up->efr | UART_EFR_SCD);
+
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
serial_out(up, UART_MCR, up->mcr & ~UART_MCR_TCRTLR);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/3] serial: omap: Make context_loss_cnt signed
From: Shubhrajyoti D @ 2012-10-03 11:54 UTC (permalink / raw)
To: linux-arm-kernel
get_context_loss_count returns an int however it is stored in
unsigned integer context_loss_cnt . This patch tries to make
context_loss_cnt int. So that in case of errors the value
(which may be negative) is not interpreted wrongly.
In serial_omap_runtime_resume in case of errors returned by
get_context_loss_count print a warning and do a restore.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/tty/serial/omap-serial.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6ede6fd..fd0fb8c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -96,7 +96,7 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
char name[20];
unsigned long port_activity;
- u32 context_loss_cnt;
+ int context_loss_cnt;
u32 errata;
u8 wakeups_enabled;
unsigned int irq_pending:1;
@@ -1556,11 +1556,15 @@ static int serial_omap_runtime_resume(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
- u32 loss_cnt = serial_omap_get_context_loss_count(up);
+ int loss_cnt = serial_omap_get_context_loss_count(up);
- if (up->context_loss_cnt != loss_cnt)
+ if (loss_cnt < 0) {
+ dev_err(dev, "serial_omap_get_context_loss_count failed : %d\n",
+ loss_cnt);
serial_omap_restore_context(up);
-
+ } else if (up->context_loss_cnt != loss_cnt) {
+ serial_omap_restore_context(up);
+ }
up->latency = up->calc_latency;
schedule_work(&up->qos_work);
--
1.7.5.4
^ permalink raw reply related
* [alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant
From: Daniel Mack @ 2012-10-03 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EA99A40@DBDE01.ent.ti.com>
On 03.10.2012 09:16, Hebbar, Gururaja wrote:
> On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
>> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
>>> The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
>>> register offset and missing generic SRAM APIs support
>>>
>>> Changes
>>> - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
>>> "ti,omap2-mcasp-audio" to identify version 3 controller.
>>> - The register offsets are handled depending on the version.
>>> - Provide a config option to indicate missing SRAM API support.
>>
>> Could you give some insight which hardware this was tested on? I'm
>> trying to get this up and running on a AM33xx board, and the patches
>> look all reasonable to me. My problem is that I can't make the DMA
>> engine move forward, I fail to receive a single interrupt on this
>> peripheral after the stream starts. I will continue searching for the
>> reason of this tomorrow, but maybe you can give me some hint by
>> explaining your setup?
>>
>> Note that I'm using your patches together with Matt's from this series:
>>
>> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
>>
>> ... but it doesn't work without those either.
>
>
> When I started working on adding DT support to McASP driver, Matt Porter
> EDMA port was not yet ready.
>
> So
> 1. I took existing edma driver from AM335x Arago release [1] (driver + edma
> device init).
> 2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
>
> 3. Added DT support to McASP driver.
>
> I tested this on AM335x EVM board.
Hmm, so I think there's a tiny bit missing for the EDMA conversion on DT
kernels.
> If you need the code, I can share it as a patch (I will send the patch as a
> private mail since the patch is huge).
Please do :) Or just push your entire tree somewhere.
Thanks,
Daniel
^ permalink raw reply
* [PATCH v2] leds: leds-gpio: adopt pinctrl support
From: AnilKumar, Chimata @ 2012-10-03 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaib2M1_UwSbyUG8qwZC2h7xaT5VU7WMj=y+h4S4LianQ@mail.gmail.com>
On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:
> On Mon, Oct 1, 2012 at 5:44 PM, Tony Lindgren <tony@atomide.com> wrote:
>
> >> OK that is typical pinctrl driver implementation work.
> >> I hope Tony can advice on this?
> >
> > I think we're best off to just stick to alternative named modes
> > passed from device tree. For example, for GPIO wake-ups you can
> > have named modes such as "default", "enabled" and "idle" where
> > "idle" muxes things for GPIO wake-ups for the duration of idle.
> >
In this case we need to add three different values according
to three modes (default, enabled, idle) and for each node.
> > It seems that should also work for leds-gpio. And you can
> > define more named modes as needed.
If we want to implement pinctrl_gpio functionality we have to
separate "function-mask" bits to
1. pinmux-mask
2. pinconf-mask, to make it generic we need following bit masks
a. receiver enable/disable bit
b. slew rate fast/slow bit
c. pull-up/down bit
....
I have gone through nvidia pinctrl dt data (tegra20-seaboard.dts,
node drive_sdio1) which has different pinconfig values, those
are mapping to pinconf values.
With the above bit masks and function-mask we can identify
pull-up/down, slow/high speed slew rate and direction in/out.
(or)
Named modes:-
Are you saying named modes like this?
default-input-up
default-input-down
default-output-up
default-output-down
This 1, 2 and 2.a or named modes are required to implement
pinctrl_gpio_direction_input/output and
pinctrl_request/free_gpio.
>
>
> This is what we're doing for ux500 and should be a good model.
I have looked into this, but not seen any named modes.
Thanks
AnilKumar
^ permalink raw reply
* [RESEND][PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card()
From: Janusz Krzysztofik @ 2012-10-03 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120906073633.GC22330@opensource.wolfsonmicro.com>
The old method of registering with the ASoC core by creating a
"soc-audio" platform device no longer works for Amstrad Delta sound card
after recent changes to drvdata handling (commit
0998d0631001288a5974afc0b2a5f568bcdecb4d, 'device-core: Ensure drvdata =
NULL when no driver is bound'.
Use snd_soc_register_card() method instead, as suggested by the ASoC
core generated warning message, and move both the card and codec
platform device registration to the arch board file where those belong.
Created and tested against linux-3.6-rc5.
Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
---
On Thu, 6 Sep 2012 15:36:35 Mark Brown wrote:
> On Sat, Sep 01, 2012 at 11:09:18AM +0200, Janusz Krzysztofik wrote:
>
> > I see your point, however for now I can see no better way of referencing
> > the data (of type struct snd_soc_card) then passing it to
> > snd_soc_register_card(). But for this to work, I would have to register
> > successfully an ams-delta specific platform device first, not the soc-
> > audio. This, even if still done from the sound/soc/omap/ams-delta.c, not
> > from an arch board file, would require now not existing ams-delta ASoC
> > platform driver probe/remove callbacks at least. I'm still not convinced
> > if such modification would be acceptable in the middle of the rc cycle.
>
> > If there is a simpler, less intrusive way to do this, then sorry, I
> > still can't see it.
>
> Like I already said just make it a static variable.
Mark,
Sorry, I was still not able to understand what you actually meant, and
to come out with a working fix other than I initially proposed. If what
I've prepared now is not acceptable as a fix, than hard luck, please
consider queueing it for 3.7, and 3.6 must go with Amstrad Delta sound
not working unless someone else is still able to fix it.
Tony,
Please give your ack on the arch/arm/mach-omap1 bits if acceptable. I
believe there should be no merge conflicts if this change goes through
sound/soc.
Thanks,
Janusz
arch/arm/mach-omap1/board-ams-delta.c | 12 ++++++
sound/soc/omap/ams-delta.c | 63 +++++++++++++++-----------------
2 files changed, 42 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index c534698..5ab9c6b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -444,16 +444,28 @@ static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+static struct platform_device ams_delta_audio_device = {
+ .name = "ams-delta-audio",
+ .id = -1,
+};
+
+static struct platform_device cx20442_codec_device = {
+ .name = "cx20442-codec",
+ .id = -1,
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
&latch1_gpio_device,
&latch2_gpio_device,
&ams_delta_kp_device,
&ams_delta_camera_device,
+ &ams_delta_audio_device,
};
static struct platform_device *late_devices[] __initdata = {
&ams_delta_nand_device,
&ams_delta_lcd_device,
+ &cx20442_codec_device,
};
static void __init ams_delta_init(void)
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index 7d4fa8e..7b18b74 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -575,56 +575,53 @@ static struct snd_soc_card ams_delta_audio_card = {
};
/* Module init/exit */
-static struct platform_device *ams_delta_audio_platform_device;
-static struct platform_device *cx20442_platform_device;
-
-static int __init ams_delta_module_init(void)
+static __devinit int ams_delta_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = &ams_delta_audio_card;
int ret;
- if (!(machine_is_ams_delta()))
- return -ENODEV;
-
- ams_delta_audio_platform_device =
- platform_device_alloc("soc-audio", -1);
- if (!ams_delta_audio_platform_device)
- return -ENOMEM;
+ card->dev = &pdev->dev;
- platform_set_drvdata(ams_delta_audio_platform_device,
- &ams_delta_audio_card);
-
- ret = platform_device_add(ams_delta_audio_platform_device);
- if (ret)
- goto err;
-
- /*
- * Codec platform device could be registered from elsewhere (board?),
- * but I do it here as it makes sense only if used with the card.
- */
- cx20442_platform_device =
- platform_device_register_simple("cx20442-codec", -1, NULL, 0);
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
+ card->dev = NULL;
+ return ret;
+ }
return 0;
-err:
- platform_device_put(ams_delta_audio_platform_device);
- return ret;
}
-late_initcall(ams_delta_module_init);
-static void __exit ams_delta_module_exit(void)
+static int __devexit ams_delta_remove(struct platform_device *pdev)
{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
if (tty_unregister_ldisc(N_V253) != 0)
- dev_warn(&ams_delta_audio_platform_device->dev,
+ dev_warn(&pdev->dev,
"failed to unregister V253 line discipline\n");
snd_soc_jack_free_gpios(&ams_delta_hook_switch,
ARRAY_SIZE(ams_delta_hook_switch_gpios),
ams_delta_hook_switch_gpios);
- platform_device_unregister(cx20442_platform_device);
- platform_device_unregister(ams_delta_audio_platform_device);
+ snd_soc_unregister_card(card);
+ card->dev = NULL;
+ return 0;
}
-module_exit(ams_delta_module_exit);
+
+#define DRV_NAME "ams-delta-audio"
+
+static struct platform_driver ams_delta_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = ams_delta_probe,
+ .remove = __devexit_p(ams_delta_remove),
+};
+
+module_platform_driver(ams_delta_driver);
MODULE_AUTHOR("Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>");
MODULE_DESCRIPTION("ALSA SoC driver for Amstrad E3 (Delta) videophone");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:" DRV_NAME);
--
1.7.3.4
^ permalink raw reply related
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Dave Martin @ 2012-10-03 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002174759.GC23733@obsidianresearch.com>
[Nicolas, do you have a view on this thread with regard to XIP?]
Hi,
On Tue, Oct 02, 2012 at 11:47:59AM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 02, 2012 at 11:23:46AM +0100, Dave Martin wrote:
>
> > > Well, no, it boots ELFs, so it can boot anything, with any memory
> > > layout. A 2nd stage loader would be required to boot standard kernels,
> > > that loader would be an ELF with 1 section for the 2nd stage, 1
> > > section for the zImage and 1 section for the initrd, with proper load
> > > headers.
> >
> > Don't you already have to treat Linux as a special case though? How
> > do you know where to load ATAGs, DT and/or initramfs, and how to
> > initalise the registers? None of that is part of any ELF specification,
> > and would be inappropriate if you boot any non-linux images.
>
> Experience with our PPC systems has been that linking the DTB into
> vmlinux is the way to go - so we have a trivally small,
> non-upstreamble change (for PPC and ARM) to put the DTB(s) in vmlinux
> and capture the CPU registers values (entry call function arguments)
> that are set from the bootloader.
>
> Some DTB fixup code (supported by the OF kernel routines) in vmlinux
> edits the DTB chosen node to include the information from the
> bootloader.
>
> From there any other DTB fixups (eg fetching a MAC address from I2C)
> plus other register initializations are done in Linux (typically by
> the upstream drivers, though not 100%), with the MMU on, with full
> kernel services. This is a much easier development environment :)
>
> All in all it is basically about 100 lines of code to do what I've
> described in vmlinux. This is dramatically less code than would be
> required if we tried to conform to the standard vmlinux boot protocol.
[1]
I'm not sure exactly what you mean by linking the DTB into vmlinux.
I don't think this is supported upstream, at least for ARM. It could
be done externally by post-processing vmlinux to add extra sections
and some boot shim code which initialises the registers appropriately
for kernel entry ... but you're really inventing a bootloader if you
start to do that.
For ARM, I believe that bootloaders that do not pass the dtb properly are
considered considered legacy, or broken (in the case of platforms which
are DT-based). We don't really attempt to support this.
ARM_APPENDED_DTB is the workaround for that, but that is only available
as part of the zImage loader. This is meant to ease migration, not as
a permanent solution... but it will probably be available for quite
a while yet.
Making a simple bootloader DT-aware is not actually that hard: libfdt
is intentionally pretty straightforward to integrate.
For an example of how this might look in a simple scenario, you could
take a look at the zImage loader implementation, or
git://git.linaro.org/arm/models/boot-wrapper.git
(Particularly update_fdt() and load_kernel() in semi_loader.c)
It's more than 100 lines, but not _that_ much more, and contains
some implementation features you probably don't need.
There may still be an argument against this if your bootloader is
exteremely space-constrained.
> > As you observe, GNU ld behaviour in this area tends to be rather patchily
> > specified, buggy or both. That does argue in favour of reusing the
> > same techniques already used for other arches, though.
>
> It is good to know PHDRS seems to be working better now, maybe things
> can migrate someday!
I guess we shouldn't rush to do that unnecessarily. Old tools hang
around for a long, long time...
> > A question does occur to me: do your changes work with XIP_KERNEL?
> > I'm not very familiar with XIP_KERNEL myself, so I'm currently not
> > clear on whether there's an impact here.
>
> I looked at the XIP defines and they didn't seem to conflict. Since
> this change only effects the values in the LOAD headers, not the
> actual image I doubt it has any impact.
>
> > Beyond this, I think the approach doesn't look unreasonable.
>
> Great, should I do anything further to get this patch into mainline.
I think that someone more familiar with XIP should at least comment on
it.
Since you admit [1] that you are deliberately not following the boot
protocol proper, you may get some pushback about whether the change
is justified.
>From my side, I think that the fact this takes arch/arm/vmlinux.lds.S
closer to some other common arches means that this is low risk and should
be mostly harmless, but I will take another look at the patch first.
> > You store vmlinux.gz in a cramfs? Is that a typo, or have you already
> > compressed the kernel twice?
>
> The compression can either be intrisic to cramfs or a raw elf that has
> been gzip'd.
If you can have files with intrinsic compression such that they don't
get double-compressed, why can you not do this for zImage?
Am I still misunderstanding something?
Cheers
---Dave
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: Register clocks via common clock framework
From: Tomasz Figa @ 2012-10-03 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349093361-18820-3-git-send-email-thomas.abraham@linaro.org>
Hi Chander, Thomas,
I can see one more problem here.
Based on the fact that sdhci-s3c driver receives only the endpoint gate
clock (hsmmc), doesn't the following setup make the driver unable to change
the frequency of this clock?
On Monday 01 of October 2012 17:39:21 chander.kashyap at linaro.org wrote:
> +static struct samsung_mux_clock exynos4_mux_clks[] = {
[snip]
> + MUXCLK("exynos4-sdhci.0", "mout_mmc0", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 0, 4, 0),
> + MUXCLK("exynos4-sdhci.1", "mout_mmc1", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 4, 4, 0),
> + MUXCLK("exynos4-sdhci.1", "mout_mmc2", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 8, 4, 0),
> + MUXCLK("exynos4-sdhci.1", "mout_mmc3", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 12, 4, 0),
[snip]
> +};
> +
> +static struct samsung_div_clock exynos4_div_clks[] = {
[snip]
> + DIVCLK("exynos4-sdhci.0", "div_mmc0", "mout_mmc0", 0,
> + EXYNOS4_CLKDIV_FSYS1, 0, 4, 0),
> + DIVCLK("exynos4-sdhci.0", "div_mmc0_pre", "div_mmc0", 0,
> + EXYNOS4_CLKDIV_FSYS1, 8, 8, 0),
> + DIVCLK("exynos4-sdhci.1", "div_mmc1", "mout_mmc1", 0,
> + EXYNOS4_CLKDIV_FSYS1, 16, 4, 0),
> + DIVCLK("exynos4-sdhci.1", "div_mmc1_pre", "div_mmc1", 0,
> + EXYNOS4_CLKDIV_FSYS1, 24, 8, 0),
> + DIVCLK("exynos4-sdhci.2", "div_mmc2", "mout_mmc2", 0,
> + EXYNOS4_CLKDIV_FSYS2, 0, 4, 0),
> + DIVCLK("exynos4-sdhci.2", "div_mmc2_pre", "div_mmc2", 0,
> + EXYNOS4_CLKDIV_FSYS2, 8, 8, 0),
> + DIVCLK("exynos4-sdhci.3", "div_mmc3", "mout_mmc3", 0,
> + EXYNOS4_CLKDIV_FSYS2, 16, 4, 0),
> + DIVCLK("exynos4-sdhci.3", "div_mmc3_pre", "div_mmc3", 0,
> + EXYNOS4_CLKDIV_FSYS2, 24, 8, 0),
[snip]
> +};
> +
> +struct samsung_gate_clock exynos4_gate_clks[] = {
[snip]
> + GATECLK("exynos4-sdhci.0", "hsmmc0", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 5, "hsmmc"),
> + GATECLK("exynos4-sdhci.1", "hsmmc1", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 6, "hsmmc"),
> + GATECLK("exynos4-sdhci.2", "hsmmc2", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 7, "hsmmc"),
> + GATECLK("exynos4-sdhci.3", "hsmmc3", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 8, "hsmmc"),
[snip]
> +};
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] ASoC: ams-delta: Convert to use snd_soc_register_card()
From: Mark Brown @ 2012-10-03 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3016923.ExzrZjbreL@vclass>
On Tue, Oct 02, 2012 at 11:07:30PM +0200, Janusz Krzysztofik wrote:
> Is something wrong with this patch? Any chance for it to find its way into 3.7?
I don't have the patch.
^ permalink raw reply
* [PATCH] ARM: davinci: dm644x: fix out range signal for ED
From: Sekhar Nori @ 2012-10-03 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349246100-7477-1-git-send-email-prabhakar.lad@ti.com>
On 10/3/2012 12:05 PM, Prabhakar wrote:
> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>
> while testing display on dm644x, for ED out-range signals
> was observed. This patch fixes appropriate clock setting
> for ED.
Can you please clarify what you mean by "out range signal"? Are there
any user visible artifacts on the display? What was the clock being
provided earlier and what is the value after this patch?
Also, is the issue severe enough that this patch should be applied to
stable tree as well?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 0/4] cpufreq: db8500: Use platform data to provide cpufreq table
From: Ulf Hansson @ 2012-10-03 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb-SWkysKGQrJBL1hJLucQ=aN59Sfxe6rxrvtR0HsOJ_g@mail.gmail.com>
On 2 October 2012 13:45, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Sep 28, 2012 at 4:16 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> Since the cpufreq table is dependant on the prmcu fw, it make sense to
>> keep the table there. Moreover since the cpufreq is already a mfd child
>> device added by the prcmu this make even more logic.
>
> Better there than elsewhere.
>
>> The next step after these patches will be to implement an "arm_clk" to be
>> used from cpufreq to update the opp instead of using the prcmu opp API directly.
>> This will then remove the last hard dependency to the prcmu API from cpufreq.
>
> Sounds like a plan.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Is this going to be merged through the cpufreq tree or the MFD tree?
Good question! Actually I would prefer to go through Mike Turquette
clock tree, if he feel it is OK of course.
My idea is then get the Ack from Rafael for cpufreq patches and from
Samuel for the mfd patches.
The reason for doing this in a quite complicated manner is that my
soon upcoming clock and mfd patches will functionality wise depend on
these patches, and don't want to be sitting around and waiting for a
new rc before being able to push the next series.
Kind regards
Ulf Hansson
^ permalink raw reply
* [GIT PULL FOR v3.7] Davinci VPBE feature enhancement and fixes
From: Prabhakar Lad @ 2012-10-03 10:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mauro,
Can you please pull the following patches for davinci VPBE driver.
Some of the patches include platform changes for which Sekhar has Acked it.
Thanks and Regards,
--Prabhakar Lad
The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4:
em28xx: regression fix: use DRX-K sync firmware requests on em28xx
(2012-10-02 17:15:22 -0300)
are available in the git repository at:
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git vpbe_3.7_pull
Hans Verkuil (1):
dm644x: replace the obsolete preset API by the timings API.
Lad, Prabhakar (2):
media: davinci: vpbe: fix build warning
davinci: vpbe: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with
V4L2_OUT_CAP_DV_TIMINGS
Manjunath Hadli (1):
ths7303: enable THS7303 for HD modes
arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++--
arch/arm/mach-davinci/dm644x.c | 17 +---
drivers/media/i2c/ths7303.c | 106
++++++++++++++++++++----
drivers/media/platform/davinci/vpbe.c | 110
+++++++++++--------------
drivers/media/platform/davinci/vpbe_display.c | 80 +++++++++---------
drivers/media/platform/davinci/vpbe_venc.c | 25 +++---
include/media/davinci/vpbe.h | 14 ++--
include/media/davinci/vpbe_types.h | 8 +--
include/media/davinci/vpbe_venc.h | 2 +-
9 files changed, 211 insertions(+), 166 deletions(-)
^ permalink raw reply
* [PATCH] ARM: MMUless Core: Fix insmod error - module relocation out of range
From: Catalin Marinas @ 2012-10-03 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003094801.GG6933@n2100.arm.linux.org.uk>
On Wed, Oct 03, 2012 at 10:48:02AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 03, 2012 at 10:25:09AM +0100, Catalin Marinas wrote:
> > On 3 October 2012 04:43, Pratyush Anand <pratyush.anand@st.com> wrote:
> > > From: Neha MAKHIJA <neha.makhija-ext@st.com>
> > >
> > > ARM supports 32Mb jump. Hence branch instruction has a limited range.
> > >
> > > For MMU systems, the module area is located just before the kernel memory
> > > because this allows function calls to be linked directly without any indirect
> > > branches.
> > >
> > > In case of MMU-less system, Module area is given whole of the DDR address
> > > space. Since, module_alloc() calls vmalloc(), the module area goes outside the
> > > allowed jump range. Due to this insmod will not be able to load the modules
> > > giving out of range relocation errors.
> > >
> > > Solution - Add the mlong-calls flags while compiling the modules. This tells
> > > the compiler to perform function calls by first loading the address of the
> > > function and then performing a subroutine function call on this register.
> >
> > Do we need the module loader to handle additional relocations or they
> > are all already handled?
>
> I have explained this extensively when the 2.6 module loader came into
> being. It's not about additional relocations, it's about the addressible
> range of the 'b' instruction.
But doesn't -mlong-calls generate the function calls by first loading
the address in a register?
--
Catalin
^ permalink raw reply
* [kvmarm] [PATCH v2 08/10] ARM: KVM: VGIC initialisation code
From: Will Deacon @ 2012-10-03 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA-KL36kwaFFrOA0NG0y1qGhkXZ+bm5FA0LhJsmKDk66Hg@mail.gmail.com>
On Tue, Oct 02, 2012 at 08:45:54PM +0100, Peter Maydell wrote:
> On 2 October 2012 20:28, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Oct 02, 2012 at 07:31:43PM +0100, Peter Maydell wrote:
> >> We probably want to be passing in the "base of the cpu-internal
> >> peripherals", rather than "base of the GIC" specifically. For the
> >> A15 these are the same thing, but that's not inherent [compare the
> >> A9 which has more devices at fixed offsets from a configurable
> >> base address].
> >
> > If you do that, userspace will need a way to probe the emulated CPU so
> > that is knows exactly which set of peripherals there are and which ones it
> > needs to emulate. This feels pretty nasty, given that the vgic is handled
> > more or less completely by the kernel-side of things.
>
> Userspace knows what the emulated CPU is because it tells the
> kernel which CPU to provide -- the kernel can say "yes" or "no" but
> it can't provide a different CPU to the one we ask for, or
> one with bits mising...
Aha, ok, I didn't realise that's how it works. Does userspace just pass the
CPUID or is there an identifier provided by kvm?
/me jumps back into the code.
Thanks,
Will
^ permalink raw reply
* [PATCH] ARM: MMUless Core: Fix insmod error - module relocation out of range
From: Russell King - ARM Linux @ 2012-10-03 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkRjk5gLSWG0uiSAK9wnLDi19bEPMpFAFfbqXjz6xNH1W4HXw@mail.gmail.com>
On Wed, Oct 03, 2012 at 10:25:09AM +0100, Catalin Marinas wrote:
> On 3 October 2012 04:43, Pratyush Anand <pratyush.anand@st.com> wrote:
> > From: Neha MAKHIJA <neha.makhija-ext@st.com>
> >
> > ARM supports 32Mb jump. Hence branch instruction has a limited range.
> >
> > For MMU systems, the module area is located just before the kernel memory
> > because this allows function calls to be linked directly without any indirect
> > branches.
> >
> > In case of MMU-less system, Module area is given whole of the DDR address
> > space. Since, module_alloc() calls vmalloc(), the module area goes outside the
> > allowed jump range. Due to this insmod will not be able to load the modules
> > giving out of range relocation errors.
> >
> > Solution - Add the mlong-calls flags while compiling the modules. This tells
> > the compiler to perform function calls by first loading the address of the
> > function and then performing a subroutine function call on this register.
>
> Do we need the module loader to handle additional relocations or they
> are all already handled?
I have explained this extensively when the 2.6 module loader came into
being. It's not about additional relocations, it's about the addressible
range of the 'b' instruction.
Please search the archives for the explanation.
^ permalink raw reply
* [PATCH] ARM: proc-v7: Ensure correct instruction set after cpu_reset
From: Will Deacon @ 2012-10-03 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349256170-4367-1-git-send-email-dave.martin@linaro.org>
On Wed, Oct 03, 2012 at 10:22:50AM +0100, Dave Martin wrote:
> Because mov pc,<Rn> never switches instruction set when executed in
> Thumb code, Thumb-2 kernels will silently execute the target code
> after cpu_reset as Thumb code, even if the passed code pointer
> denotes ARM (bit 0 clear).
>
> This patch uses bx instead, ensuring the correct instruction set
> for the target code.
>
> Thumb code in the kernel is not supported prior to ARMv7, so other
> CPUs are not affected.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> ---
> arch/arm/mm/proc-v7.S | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
I pondered why kexec was working, but we have the following in the
purgatory code:
/* Jump to relocated kernel */
mov lr,r1
mov r0,#0
ldr r1,kexec_mach_type
ldr r2,kexec_boot_atags
ARM( mov pc, lr )
THUMB( bx lr )
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index c2e2b66..ca5b575 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -57,7 +57,7 @@ ENTRY(cpu_v7_reset)
> THUMB( bic r1, r1, #1 << 30 ) @ SCTLR.TE (Thumb exceptions)
> mcr p15, 0, r1, c1, c0, 0 @ disable MMU
> isb
> - mov pc, r0
> + bx r0
> ENDPROC(cpu_v7_reset)
> .popsection
So this looks fine to me:
Acked-by: Will Deacon <will.deacon@arm.com>
Cheers,
Will
^ permalink raw reply
* [PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
From: Praveen Paneri @ 2012-10-03 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6zSYOCJ2wV82-oeX5xo2COMKMQMsPfgeesPhq+Ui_3_PU5ag@mail.gmail.com>
>From v6:
Added TODO for phy bindings with controller
Dropped platform_set_drvdata() from driver probe
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri <p.paneri@samsung.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 11 +
drivers/usb/phy/Kconfig | 8 +
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/samsung-usbphy.c | 355 ++++++++++++++++++++
include/linux/platform_data/samsung-usbphy.h | 27 ++
5 files changed, 402 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
create mode 100644 drivers/usb/phy/samsung-usbphy.c
create mode 100644 include/linux/platform_data/samsung-usbphy.h
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 0000000..7d54d59
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,11 @@
+* Samsung's usb phy transceiver
+
+The Samsung's phy transceiver is used for controlling usb otg phy for
+s3c-hsotg usb device controller.
+TODO: Adding the PHY binding with controller(s) according to the under
+developement generic PHY driver.
+
+Required properties:
+- compatible : should be "samsung,exynos4210-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..313685f 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -32,3 +32,11 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config SAMSUNG_USBPHY
+ bool "Samsung USB PHY controller Driver"
+ depends on USB_S3C_HSOTG
+ select USB_OTG_UTILS
+ help
+ Enable this to support Samsung USB phy controller for samsung
+ SoCs.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..55dcfc1 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
+obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
new file mode 100644
index 0000000..ee2dee0
--- /dev/null
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -0,0 +1,355 @@
+/* linux/drivers/usb/phy/samsung-usbphy.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Praveen Paneri <p.paneri@samsung.com>
+ *
+ * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/usb/otg.h>
+#include <linux/platform_data/samsung-usbphy.h>
+
+/* Register definitions */
+
+#define S3C_PHYPWR (0x00)
+
+#define S3C_PHYPWR_NORMAL_MASK (0x19 << 0)
+#define S3C_PHYPWR_OTG_DISABLE (1 << 4)
+#define S3C_PHYPWR_ANALOG_POWERDOWN (1 << 3)
+#define S3C_PHYPWR_FORCE_SUSPEND (1 << 1)
+/* For Exynos4 */
+#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 << 0)
+#define EXYNOS4_PHYPWR_SLEEP (1 << 5)
+
+#define S3C_PHYCLK (0x04)
+
+#define S3C_PHYCLK_MODE_SERIAL (1 << 6)
+#define S3C_PHYCLK_EXT_OSC (1 << 5)
+#define S3C_PHYCLK_COMMON_ON_N (1 << 4)
+#define S3C_PHYCLK_ID_PULL (1 << 2)
+#define S3C_PHYCLK_CLKSEL_MASK (0x3 << 0)
+#define S3C_PHYCLK_CLKSEL_SHIFT (0)
+#define S3C_PHYCLK_CLKSEL_48M (0x0 << 0)
+#define S3C_PHYCLK_CLKSEL_12M (0x2 << 0)
+#define S3C_PHYCLK_CLKSEL_24M (0x3 << 0)
+
+#define S3C_RSTCON (0x08)
+
+#define S3C_RSTCON_PHYCLK (1 << 2)
+#define S3C_RSTCON_HCLK (1 << 1)
+#define S3C_RSTCON_PHY (1 << 0)
+
+#ifndef MHZ
+#define MHZ (1000*1000)
+#endif
+
+enum samsung_cpu_type {
+ TYPE_S3C64XX,
+ TYPE_EXYNOS4210,
+};
+
+/*
+ * struct samsung_usbphy - transceiver driver state
+ * @phy: transceiver structure
+ * @plat: platform data
+ * @dev: The parent device supplied to the probe function
+ * @clk: usb phy clock
+ * @regs: usb phy register memory base
+ * @ref_clk_freq: reference clock frequency selection
+ * @cpu_type: machine identifier
+ */
+struct samsung_usbphy {
+ struct usb_phy phy;
+ struct samsung_usbphy_data *plat;
+ struct device *dev;
+ struct clk *clk;
+ void __iomem *regs;
+ int ref_clk_freq;
+ int cpu_type;
+};
+
+#define phy_to_sphy(x) container_of((x), struct samsung_usbphy, phy)
+
+/*
+ * Returns reference clock frequency selection value
+ */
+static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
+{
+ struct clk *ref_clk;
+ int refclk_freq = 0;
+
+ ref_clk = clk_get(sphy->dev, "xusbxti");
+ if (IS_ERR(ref_clk)) {
+ dev_err(sphy->dev, "Failed to get reference clock\n");
+ return PTR_ERR(ref_clk);
+ }
+
+ switch (clk_get_rate(ref_clk)) {
+ case 12 * MHZ:
+ refclk_freq |= S3C_PHYCLK_CLKSEL_12M;
+ break;
+ case 24 * MHZ:
+ refclk_freq |= S3C_PHYCLK_CLKSEL_24M;
+ break;
+ default:
+ case 48 * MHZ:
+ /* default reference clock */
+ refclk_freq |= S3C_PHYCLK_CLKSEL_48M;
+ break;
+ }
+ clk_put(ref_clk);
+
+ return refclk_freq;
+}
+
+static void samsung_usbphy_enable(struct samsung_usbphy *sphy)
+{
+ void __iomem *regs = sphy->regs;
+ u32 phypwr;
+ u32 phyclk;
+ u32 rstcon;
+
+ /* set clock frequency for PLL */
+ phyclk = sphy->ref_clk_freq;
+ phypwr = readl(regs + S3C_PHYPWR);
+ rstcon = readl(regs + S3C_RSTCON);
+
+ switch (sphy->cpu_type) {
+ case TYPE_S3C64XX:
+ phyclk &= ~(S3C_PHYCLK_COMMON_ON_N);
+ phypwr &= ~S3C_PHYPWR_NORMAL_MASK;
+ rstcon |= S3C_RSTCON_PHY;
+ break;
+ case TYPE_EXYNOS4210:
+ phypwr &= ~EXYNOS4_PHYPWR_NORMAL_MASK;
+ rstcon |= S3C_RSTCON_PHY;
+ default:
+ break;
+ }
+
+ writel(phyclk, regs + S3C_PHYCLK);
+ /* set to normal of PHY0 */
+ writel(phypwr, regs + S3C_PHYPWR);
+ /* reset all ports of PHY and Link */
+ writel(rstcon, regs + S3C_RSTCON);
+ udelay(10);
+ rstcon &= ~S3C_RSTCON_PHY;
+ writel(rstcon, regs + S3C_RSTCON);
+}
+
+static void samsung_usbphy_disable(struct samsung_usbphy *sphy)
+{
+ void __iomem *regs = sphy->regs;
+ u32 phypwr;
+
+ phypwr = readl(regs + S3C_PHYPWR);
+
+ switch (sphy->cpu_type) {
+ case TYPE_S3C64XX:
+ phypwr |= S3C_PHYPWR_NORMAL_MASK;
+ break;
+ case TYPE_EXYNOS4210:
+ phypwr |= EXYNOS4_PHYPWR_NORMAL_MASK;
+ default:
+ break;
+ }
+
+ /* unset to normal of PHY0 */
+ writel(phypwr, regs + S3C_PHYPWR);
+}
+
+/*
+ * The function passed to the usb driver for phy initialization
+ */
+static int samsung_usbphy_init(struct usb_phy *phy)
+{
+ struct samsung_usbphy *sphy;
+ int ret = 0;
+
+ sphy = phy_to_sphy(phy);
+
+ /* Enable the phy clock */
+ ret = clk_prepare_enable(sphy->clk);
+ if (ret) {
+ dev_err(sphy->dev, "%s: clk_prepare_enable failed\n", __func__);
+ return ret;
+ }
+
+ /* Disable phy isolation */
+ if (sphy->plat && sphy->plat->pmu_isolation)
+ sphy->plat->pmu_isolation(false);
+
+ /* Initialize usb phy registers */
+ samsung_usbphy_enable(sphy);
+
+ /* Disable the phy clock */
+ clk_disable_unprepare(sphy->clk);
+ return ret;
+}
+
+/*
+ * The function passed to the usb driver for phy shutdown
+ */
+static void samsung_usbphy_shutdown(struct usb_phy *phy)
+{
+ struct samsung_usbphy *sphy;
+
+ sphy = phy_to_sphy(phy);
+
+ if (clk_prepare_enable(sphy->clk)) {
+ dev_err(sphy->dev, "%s: clk_prepare_enable failed\n", __func__);
+ return;
+ }
+
+ /* De-initialize usb phy registers */
+ samsung_usbphy_disable(sphy);
+
+ /* Enable phy isolation */
+ if (sphy->plat && sphy->plat->pmu_isolation)
+ sphy->plat->pmu_isolation(true);
+
+ clk_disable_unprepare(sphy->clk);
+}
+
+static const struct of_device_id samsung_usbphy_dt_match[];
+
+static inline int samsung_usbphy_get_driver_data(struct platform_device *pdev)
+{
+ if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+ int data;
+ const struct of_device_id *match;
+ match = of_match_node(samsung_usbphy_dt_match,
+ pdev->dev.of_node);
+ data = (int) match->data;
+ return data;
+ }
+
+ return platform_get_device_id(pdev)->driver_data;
+}
+
+static int __devinit samsung_usbphy_probe(struct platform_device *pdev)
+{
+ struct samsung_usbphy *sphy;
+ struct samsung_usbphy_data *pdata;
+ struct device *dev = &pdev->dev;
+ struct resource *phy_mem;
+ void __iomem *phy_base;
+ struct clk *clk;
+ int ret = 0;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ dev_err(&pdev->dev, "%s: no platform data defined\n", __func__);
+ return -EINVAL;
+ }
+
+ phy_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!phy_mem) {
+ dev_err(dev, "%s: missing mem resource\n", __func__);
+ return -ENODEV;
+ }
+
+ phy_base = devm_request_and_ioremap(dev, phy_mem);
+ if (!phy_base) {
+ dev_err(dev, "%s: register mapping failed\n", __func__);
+ return -ENXIO;
+ }
+
+ sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
+ if (!sphy)
+ return -ENOMEM;
+
+ clk = devm_clk_get(dev, "otg");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "Failed to get otg clock\n");
+ return PTR_ERR(clk);
+ }
+
+ sphy->dev = &pdev->dev;
+ sphy->plat = pdata;
+ sphy->regs = phy_base;
+ sphy->clk = clk;
+ sphy->phy.dev = sphy->dev;
+ sphy->phy.label = "samsung-usbphy";
+ sphy->phy.init = samsung_usbphy_init;
+ sphy->phy.shutdown = samsung_usbphy_shutdown;
+ sphy->cpu_type = samsung_usbphy_get_driver_data(pdev);
+ sphy->ref_clk_freq = samsung_usbphy_get_refclk_freq(sphy);
+
+ ret = usb_add_phy(&sphy->phy, USB_PHY_TYPE_USB2);
+ return ret;
+}
+
+static int __exit samsung_usbphy_remove(struct platform_device *pdev)
+{
+ struct samsung_usbphy *sphy = platform_get_drvdata(pdev);
+
+ usb_remove_phy(&sphy->phy);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id samsung_usbphy_dt_match[] = {
+ {
+ .compatible = "samsung,s3c64xx-usbphy",
+ .data = (void *)TYPE_S3C64XX,
+ }, {
+ .compatible = "samsung,exynos4210-usbphy",
+ .data = (void *)TYPE_EXYNOS4210,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, samsung_usbphy_dt_match);
+#else
+#define samsung_usbphy_dt_match NULL
+#endif
+
+static struct platform_device_id samsung_usbphy_driver_ids[] = {
+ {
+ .name = "s3c64xx-usbphy",
+ .driver_data = TYPE_S3C64XX,
+ }, {
+ .name = "exynos4210-usbphy",
+ .driver_data = TYPE_EXYNOS4210,
+ },
+ {},
+};
+
+MODULE_DEVICE_TABLE(platform, samsung_usbphy_driver_ids);
+
+static struct platform_driver samsung_usbphy_driver = {
+ .probe = samsung_usbphy_probe,
+ .remove = __devexit_p(samsung_usbphy_remove),
+ .id_table = samsung_usbphy_driver_ids,
+ .driver = {
+ .name = "samsung-usbphy",
+ .owner = THIS_MODULE,
+ .of_match_table = samsung_usbphy_dt_match,
+ },
+};
+
+module_platform_driver(samsung_usbphy_driver);
+
+MODULE_DESCRIPTION("Samsung USB phy controller");
+MODULE_AUTHOR("Praveen Paneri <p.paneri@samsung.com>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:samsung-usbphy");
diff --git a/include/linux/platform_data/samsung-usbphy.h b/include/linux/platform_data/samsung-usbphy.h
new file mode 100644
index 0000000..1bd24cb
--- /dev/null
+++ b/include/linux/platform_data/samsung-usbphy.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * http://www.samsung.com/
+ * Author: Praveen Paneri <p.paneri@samsung.com>
+ *
+ * Defines platform data for samsung usb phy driver.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __SAMSUNG_USBPHY_PLATFORM_H
+#define __SAMSUNG_USBPHY_PLATFORM_H
+
+/**
+ * samsung_usbphy_data - Platform data for USB PHY driver.
+ * @pmu_isolation: Function to control usb phy isolation in PMU.
+ */
+struct samsung_usbphy_data {
+ void (*pmu_isolation)(int on);
+};
+
+extern void samsung_usbphy_set_pdata(struct samsung_usbphy_data *pd);
+
+#endif /* __SAMSUNG_USBPHY_PLATFORM_H */
--
1.7.1
^ permalink raw reply related
* [PATCH] ARM: MMUless Core: Fix insmod error - module relocation out of range
From: Catalin Marinas @ 2012-10-03 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4995c6bc655337598b88bef025cd48b320c2ada0.1349235619.git.pratyush.anand@st.com>
On 3 October 2012 04:43, Pratyush Anand <pratyush.anand@st.com> wrote:
> From: Neha MAKHIJA <neha.makhija-ext@st.com>
>
> ARM supports 32Mb jump. Hence branch instruction has a limited range.
>
> For MMU systems, the module area is located just before the kernel memory
> because this allows function calls to be linked directly without any indirect
> branches.
>
> In case of MMU-less system, Module area is given whole of the DDR address
> space. Since, module_alloc() calls vmalloc(), the module area goes outside the
> allowed jump range. Due to this insmod will not be able to load the modules
> giving out of range relocation errors.
>
> Solution - Add the mlong-calls flags while compiling the modules. This tells
> the compiler to perform function calls by first loading the address of the
> function and then performing a subroutine function call on this register.
Do we need the module loader to handle additional relocations or they
are all already handled?
--
Catalin
^ permalink raw reply
* [PATCH] ARM: proc-v7: Ensure correct instruction set after cpu_reset
From: Dave Martin @ 2012-10-03 9:22 UTC (permalink / raw)
To: linux-arm-kernel
Because mov pc,<Rn> never switches instruction set when executed in
Thumb code, Thumb-2 kernels will silently execute the target code
after cpu_reset as Thumb code, even if the passed code pointer
denotes ARM (bit 0 clear).
This patch uses bx instead, ensuring the correct instruction set
for the target code.
Thumb code in the kernel is not supported prior to ARMv7, so other
CPUs are not affected.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
arch/arm/mm/proc-v7.S | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index c2e2b66..ca5b575 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -57,7 +57,7 @@ ENTRY(cpu_v7_reset)
THUMB( bic r1, r1, #1 << 30 ) @ SCTLR.TE (Thumb exceptions)
mcr p15, 0, r1, c1, c0, 0 @ disable MMU
isb
- mov pc, r0
+ bx r0
ENDPROC(cpu_v7_reset)
.popsection
--
1.7.4.1
^ permalink raw reply related
* [RFC PATCH 1/2] ARM: use generic strnlen_user and strncpy_from_user functions
From: Will Deacon @ 2012-10-03 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003060042.GB598@pengutronix.de>
On Wed, Oct 03, 2012 at 07:00:42AM +0100, Uwe Kleine-K?nig wrote:
> On Tue, Oct 02, 2012 at 08:18:51PM +0100, Will Deacon wrote:
> > Ok, thanks for the heads-up. I didn't test it with an M-class CPU, but
> > hopefully that's understandable :)
>
> I think so, yes. But I intend to change that, and I heard your coworker
> gets an efm32 :-)
Yep, he'll be in charge of testing for us (!)
> > > > +#define user_addr_max() \
> > > > + (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
> > > > +
> > > I think this is the problem as for no-mmu USER_DS == KERNEL_DS. I will
> > > take a look tomorrow.
> >
> > I can't immediately see why that would cause a problem, so please let me
> > know if you get more information.
> BTW, I once saw the call to sys_mount fail:
>
> sys_mount ->
> copy_mount_string ->
> strndup_user ->
> strnlen_user returns 0 which makes sys_mount fail with -EFAULT.
>
> but that was not the problem I hit when I bisected (using merges instead
> of rebasing).
Was this also on your M3?
> We have a bank holiday today in Germany, so it's still tomorrow when I
> will look into the problem. So I hope to be able to give more details
> soon.
Ok, have a good day off.
Will
^ permalink raw reply
* [PATCH] ARM: arch timer: Export 'read_current_timer' symbol
From: Will Deacon @ 2012-10-03 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003005218.GA23874@animalcreek.com>
Hi Mark,
On Wed, Oct 03, 2012 at 01:52:18AM +0100, Mark A. Greer wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Commit 923df96b9f31b7d08d8438ff9677326d9537accf
> (ARM: 7451/1: arch timer: implement read_current_timer and get_cycles)
> modifies get_cycles() such that it calls read_current_timer().
> Unfortunately, the 'read_current_timer' symbol is not exported so when
> a driver that calls get_cycles() is built as a module, an undefined
> reference error occurs.
>
> A good example is the crypto/tcrypt.c (CONFIG_CRYPTO_TEST) driver
> because it calls get_cycles() and can only be built as a module.
>
> Fix this error by exporting the 'read_current_timer' symbol.
This was already reported over on the kernel-janitors list, I assumed they'd
CC'd LAK, but it looks like it didn't happen.
http://marc.info/?l=kernel-janitors&m=134910841909057&w=2
Anyway, I've got a fix in the works (I don't think you need the ifdef).
Will
^ permalink raw reply
* [PATCH] davinci: vpbe: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Sekhar Nori @ 2012-10-03 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349245973-7377-1-git-send-email-prabhakar.lad@ti.com>
On 10/3/2012 12:02 PM, Prabhakar wrote:
> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>
> This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
> V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
> out.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Hans Verkuil <hansverk@cisco.com>
> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
For the DaVinci platform change:
Acked-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/2] ARM: Exynos4: Register clocks via common clock framework
From: Tomasz Figa @ 2012-10-03 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349093361-18820-3-git-send-email-thomas.abraham@linaro.org>
Hi Chander, Thomas,
I think this patch could be split into several smaller, while retaining logical integrity of particular patches, e.g.:
- the change introduced to __clk_init (with proper description and rationale why the generic code is being touched)
- generic exynos4 code
- exynos4210-specific code
- exynos4x12-specific code
- patch enabling common clock framework on exynos4.
Also, see some nitpicks inline.
On Monday 01 of October 2012 17:39:21 chander.kashyap at linaro.org wrote:
> From: Thomas Abraham <thomas.abraham@linaro.org>
>
> Register clocks for Exynos4 platfotms using common clock framework.
> Also included are set of helper functions for clock registration
> that can be reused on other Samsung platforms as well.
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> arch/arm/mach-exynos/Kconfig | 1 +
> arch/arm/mach-exynos/common.h | 3 +
> arch/arm/mach-exynos/mct.c | 11 +-
> arch/arm/plat-samsung/Kconfig | 4 +-
> drivers/clk/Makefile | 1 +
> drivers/clk/clk.c | 12 +-
> drivers/clk/samsung/Makefile | 6 +
> drivers/clk/samsung/clk-exynos4.c | 585
> +++++++++++++++++++++++++++++++++++++ drivers/clk/samsung/clk.c
> | 231 +++++++++++++++
> drivers/clk/samsung/clk.h | 190 ++++++++++++
> 10 files changed, 1037 insertions(+), 7 deletions(-)
> create mode 100644 drivers/clk/samsung/Makefile
> create mode 100644 drivers/clk/samsung/clk-exynos4.c
> create mode 100644 drivers/clk/samsung/clk.c
> create mode 100644 drivers/clk/samsung/clk.h
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index b5b4c8c..4866ec7 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -15,6 +15,7 @@ config ARCH_EXYNOS4
> bool "SAMSUNG EXYNOS4"
> default y
> select HAVE_SMP
> + select COMMON_CLK
> select MIGHT_HAVE_CACHE_L2X0
> help
> Samsung EXYNOS4 SoCs based systems
> diff --git a/arch/arm/mach-exynos/common.h
> b/arch/arm/mach-exynos/common.h index aed2eeb..2274431 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -21,6 +21,9 @@ void exynos4_restart(char mode, const char *cmd);
> void exynos5_restart(char mode, const char *cmd);
> void exynos_init_late(void);
>
> +void exynos4210_clk_init(void);
> +void exynos4212_clk_init(void);
exynos4x12_clk_init?
> +
> #ifdef CONFIG_PM_GENERIC_DOMAINS
> int exynos_pm_late_initcall(void);
> #else
> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> index b601fb8..a7cace0 100644
> --- a/arch/arm/mach-exynos/mct.c
> +++ b/arch/arm/mach-exynos/mct.c
> @@ -30,6 +30,8 @@
> #include <mach/regs-mct.h>
> #include <asm/mach/time.h>
>
> +#include "common.h"
> +
> #define TICK_BASE_CNT 1
>
> enum {
> @@ -457,7 +459,7 @@ static struct local_timer_ops exynos4_mct_tick_ops
> __cpuinitdata = { static void __init exynos4_timer_resources(void)
> {
> struct clk *mct_clk;
> - mct_clk = clk_get(NULL, "xtal");
> + mct_clk = clk_get(NULL, "fin_pll");
>
> clk_rate = clk_get_rate(mct_clk);
>
> @@ -478,6 +480,13 @@ static void __init exynos4_timer_resources(void)
>
> static void __init exynos4_timer_init(void)
> {
> +#ifdef CONFIG_COMMON_CLK
> + if (soc_is_exynos4210())
> + exynos4210_clk_init();
> + else if (soc_is_exynos4212() || soc_is_exynos4412())
> + exynos4212_clk_init();
exynos4x12_clk_init?
> +#endif
> +
> if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
> mct_int_type = MCT_INT_SPI;
> else
> diff --git a/arch/arm/plat-samsung/Kconfig
> b/arch/arm/plat-samsung/Kconfig index 9c3b90c..35b4cb8 100644
> --- a/arch/arm/plat-samsung/Kconfig
> +++ b/arch/arm/plat-samsung/Kconfig
> @@ -26,7 +26,7 @@ config PLAT_S5P
> select S5P_GPIO_DRVSTR
> select SAMSUNG_GPIOLIB_4BIT
> select PLAT_SAMSUNG
> - select SAMSUNG_CLKSRC
> + select SAMSUNG_CLKSRC if !COMMON_CLK
> select SAMSUNG_IRQ_VIC_TIMER
> help
> Base platform code for Samsung's S5P series SoC.
> @@ -89,7 +89,7 @@ config SAMSUNG_CLKSRC
> used by newer systems such as the S3C64XX.
>
> config S5P_CLOCK
> - def_bool (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
> + def_bool ((ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
> && !COMMON_CLK) help
> Support common clock part for ARCH_S5P and ARCH_EXYNOS SoCs
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 6327536..5f5b060 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_MMP) += mmp/
> endif
> obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
> obj-$(CONFIG_ARCH_U8500) += ux500/
> +obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
>
> # Chip specific
> obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 56e4495..456c50b 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1196,6 +1196,7 @@ EXPORT_SYMBOL_GPL(clk_set_parent);
> int __clk_init(struct device *dev, struct clk *clk)
> {
> int i, ret = 0;
> + u8 index;
> struct clk *orphan;
> struct hlist_node *tmp, *tmp2;
>
> @@ -1259,6 +1260,7 @@ int __clk_init(struct device *dev, struct clk *clk)
> __clk_lookup(clk->parent_names[i]);
> }
>
> +
Unnecessary extra blank line?
> clk->parent = __clk_init_parent(clk);
>
> /*
> @@ -1298,11 +1300,13 @@ int __clk_init(struct device *dev, struct clk
> *clk) * this clock
> */
> hlist_for_each_entry_safe(orphan, tmp, tmp2, &clk_orphan_list,
> child_node) - for (i = 0; i < orphan->num_parents; i++)
> - if (!strcmp(clk->name, orphan->parent_names[i])) {
> + if (orphan->num_parents > 1) {
> + index = orphan->ops->get_parent(orphan->hw);
> + if (!strcmp(clk->name, orphan->parent_names[index]))
> __clk_reparent(orphan, clk);
> - break;
> - }
> + } else if (!strcmp(clk->name, orphan->parent_names[0])) {
> + __clk_reparent(orphan, clk);
> + }
>
> /*
> * optional platform-specific magic
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> new file mode 100644
> index 0000000..69487f7
> --- /dev/null
> +++ b/drivers/clk/samsung/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Samsung Clock specific Makefile
> +#
> +
> +obj-$(CONFIG_PLAT_SAMSUNG) += clk.o
> +obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c new file mode 100644
> index 0000000..74a6f03
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -0,0 +1,585 @@
> +/*
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * Copyright (c) 2012 Linaro Ltd.
> + *
> + * 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.
> + *
> + * Common Clock Framework support for all Exynos4 platforms
> +*/
> +
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/io.h>
> +#include <linux/clk-provider.h>
> +
> +#include <plat/pll.h>
> +#include <plat/cpu.h>
> +#include <mach/regs-clock.h>
> +#include <mach/sysmmu.h>
> +#include <plat/map-s5p.h>
> +
> +#include "clk.h"
> +
> +#define EXYNOS4_OP_MODE (S5P_VA_CHIPID + 8)
> +
> +static const char *pll_parent_names[] __initdata = { "fin_pll" };
> +static const char *fin_pll_parents[] __initdata = { "xxti", "xusbxti" };
> +static const char *mout_apll_parents[] __initdata = { "fin_pll",
> "fout_apll", }; +static const char *mout_mpll_parents[] __initdata = {
> "fin_pll", "fout_mpll", }; +static const char *mout_epll_parents[]
> __initdata = { "fin_pll", "fout_epll", }; +
> +static const char *sclk_ampll_parents[] __initdata = {
> + "mout_mpll", "sclk_apll", };
> +
> +static const char *sclk_evpll_parents[] __initdata = {
> + "mout_epll", "mout_vpll", };
> +
> +static const char *mout_core_parents[] __initdata = {
> + "mout_apll", "mout_mpll", };
> +
> +static const char *mout_mfc_parents[] __initdata = {
> + "mout_mfc0", "mout_mfc1", };
> +
> +static const char *mout_dac_parents[] __initdata = {
> + "mout_vpll", "sclk_hdmiphy", };
> +
> +static const char *mout_hdmi_parents[] __initdata = {
> + "sclk_pixel", "sclk_hdmiphy", };
> +
> +static const char *mout_mixer_parents[] __initdata = {
> + "sclk_dac", "sclk_hdmi", };
> +
> +static const char *group1_parents[] __initdata = {
> + "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
> + "none", "sclk_hdmiphy", "mout_mpll", "mout_epll",
> + "mout_vpll" };
> +
> +static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] = {
> + FRATE_CLK(NULL, "xxti", NULL, CLK_IS_ROOT, 24000000),
> + FRATE_CLK(NULL, "xusbxti", NULL, CLK_IS_ROOT, 24000000),
> + FRATE_CLK(NULL, "sclk_hdmi24m", NULL, CLK_IS_ROOT, 24000000),
> + FRATE_CLK(NULL, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 27000000),
> + FRATE_CLK(NULL, "sclk_usbphy0", NULL, CLK_IS_ROOT, 48000000),
> +};
> +
> +static struct samsung_mux_clock exynos4_mux_clks[] = {
> + MUXCLK(NULL, "fin_pll", fin_pll_parents, 0,
> + EXYNOS4_OP_MODE, 0, 1, 0),
> + MUXCLK(NULL, "mout_apll", mout_apll_parents, 0,
> + EXYNOS4_CLKSRC_CPU, 0, 1, 0),
> + MUXCLK(NULL, "mout_epll", mout_epll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 4, 1, 0),
> + MUXCLK(NULL, "mout_core", mout_core_parents, 0,
> + EXYNOS4_CLKSRC_CPU, 16, 1, 0),
> + MUXCLK(NULL, "mout_aclk_200", sclk_ampll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 12, 1, 0),
> + MUXCLK(NULL, "mout_aclk_100", sclk_ampll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 16, 1, 0),
> + MUXCLK(NULL, "mout_aclk_160", sclk_ampll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 20, 1, 0),
> + MUXCLK(NULL, "mout_aclk_133", sclk_ampll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 24, 1, 0),
> + MUXCLK("exynos4210-uart.0", "mout_uart0", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL0, 0, 4, 0),
> + MUXCLK("exynos4210-uart.1", "mout_uart1", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL0, 4, 4, 0),
> + MUXCLK("exynos4210-uart.2", "mout_uart2", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL0, 8, 4, 0),
> + MUXCLK("exynos4210-uart.3", "mout_uart3", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL0, 12, 4, 0),
> + MUXCLK("exynos4-sdhci.0", "mout_mmc0", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 0, 4, 0),
> + MUXCLK("exynos4-sdhci.1", "mout_mmc1", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 4, 4, 0),
> + MUXCLK("exynos4-sdhci.1", "mout_mmc2", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 8, 4, 0),
> + MUXCLK("exynos4-sdhci.1", "mout_mmc3", group1_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 12, 4, 0),
> + MUXCLK("exynos4210-spi.0", "mout_spi0", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL1, 16, 4, 0),
> + MUXCLK("exynos4210-spi.1", "mout_spi1", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL1, 20, 4, 0),
> + MUXCLK("exynos4210-spi.2", "mout_spi2", group1_parents, 0,
> + EXYNOS4_CLKSRC_PERIL1, 24, 4, 0),
> + MUXCLK(NULL, "mout_sata", sclk_ampll_parents, 0,
> + EXYNOS4_CLKSRC_FSYS, 24, 1, 0),
> + MUXCLK(NULL, "mout_mfc0", sclk_ampll_parents, 0,
> + EXYNOS4_CLKSRC_MFC, 0, 1, 0),
> + MUXCLK(NULL, "mout_mfc1", sclk_evpll_parents, 0,
> + EXYNOS4_CLKSRC_MFC, 4, 1, 0),
> + MUXCLK("s5p-mfc", "mout_mfc", mout_mfc_parents, 0,
> + EXYNOS4_CLKSRC_MFC, 8, 1, 0),
> + MUXCLK("s5p-mipi-csis.0", "mout_csis0", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 24, 4, 0),
> + MUXCLK("s5p-mipi-csis.1", "mout_csis1", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 28, 4, 0),
> + MUXCLK(NULL, "mout_cam0", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 16, 4, 0),
> + MUXCLK(NULL, "mout_cam1", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 20, 4, 0),
> + MUXCLK("exynos4-fimc.0", "mout_fimc0", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 0, 4, 0),
> + MUXCLK("exynos4-fimc.1", "mout_fimc1", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 4, 4, 0),
> + MUXCLK("exynos4-fimc.2", "mout_fimc2", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 8, 4, 0),
> + MUXCLK("exynos4-fimc.3", "mout_fimc3", group1_parents, 0,
> + EXYNOS4_CLKSRC_CAM, 12, 4, 0),
> + MUXCLK("exynos4-fb.0", "mout_fimd0", group1_parents, 0,
> + EXYNOS4_CLKSRC_LCD0, 0, 4, 0),
> + MUXCLK(NULL, "sclk_dac", mout_dac_parents, 0,
> + EXYNOS4_CLKSRC_TV, 8, 1, 0),
> + MUXCLK(NULL, "sclk_hdmi", mout_hdmi_parents, 0,
> + EXYNOS4_CLKSRC_TV, 0, 1, 0),
> + MUXCLK(NULL, "sclk_mixer", mout_mixer_parents, 0,
> + EXYNOS4_CLKSRC_TV, 4, 1, 0),
> +};
> +
> +static struct samsung_div_clock exynos4_div_clks[] = {
> + DIVCLK(NULL, "sclk_apll", "mout_apll", 0,
> + EXYNOS4_CLKDIV_CPU, 24, 3, 0),
> + DIVCLK(NULL, "div_core", "mout_core", 0,
> + EXYNOS4_CLKDIV_CPU, 0, 3, 0),
> + DIVCLK(NULL, "armclk", "div_core", 0,
> + EXYNOS4_CLKDIV_CPU, 28, 3, 0),
> + DIVCLK(NULL, "aclk_200", "mout_aclk_200", 0,
> + EXYNOS4_CLKDIV_TOP, 0, 3, 0),
> + DIVCLK(NULL, "aclk_100", "mout_aclk_100", 0,
> + EXYNOS4_CLKDIV_TOP, 4, 4, 0),
> + DIVCLK(NULL, "aclk_160", "mout_aclk_160", 0,
> + EXYNOS4_CLKDIV_TOP, 8, 3, 0),
> + DIVCLK(NULL, "aclk_133", "mout_aclk_133", 0,
> + EXYNOS4_CLKDIV_TOP, 12, 3, 0),
> + DIVCLK("exynos4210-uart.0", "div_uart0", "mout_uart0", 0,
> + EXYNOS4_CLKDIV_PERIL0, 0, 4, 0),
> + DIVCLK("exynos4210-uart.1", "div_uart1", "mout_uart1", 0,
> + EXYNOS4_CLKDIV_PERIL0, 4, 4, 0),
> + DIVCLK("exynos4210-uart.2", "div_uart2", "mout_uart2", 0,
> + EXYNOS4_CLKDIV_PERIL0, 8, 4, 0),
> + DIVCLK("exynos4210-uart.3", "div_uart3", "mout_uart3", 0,
> + EXYNOS4_CLKDIV_PERIL0, 12, 4, 0),
> + DIVCLK("exynos4-sdhci.0", "div_mmc0", "mout_mmc0", 0,
> + EXYNOS4_CLKDIV_FSYS1, 0, 4, 0),
> + DIVCLK("exynos4-sdhci.0", "div_mmc0_pre", "div_mmc0", 0,
> + EXYNOS4_CLKDIV_FSYS1, 8, 8, 0),
> + DIVCLK("exynos4-sdhci.1", "div_mmc1", "mout_mmc1", 0,
> + EXYNOS4_CLKDIV_FSYS1, 16, 4, 0),
> + DIVCLK("exynos4-sdhci.1", "div_mmc1_pre", "div_mmc1", 0,
> + EXYNOS4_CLKDIV_FSYS1, 24, 8, 0),
> + DIVCLK("exynos4-sdhci.2", "div_mmc2", "mout_mmc2", 0,
> + EXYNOS4_CLKDIV_FSYS2, 0, 4, 0),
> + DIVCLK("exynos4-sdhci.2", "div_mmc2_pre", "div_mmc2", 0,
> + EXYNOS4_CLKDIV_FSYS2, 8, 8, 0),
> + DIVCLK("exynos4-sdhci.3", "div_mmc3", "mout_mmc3", 0,
> + EXYNOS4_CLKDIV_FSYS2, 16, 4, 0),
> + DIVCLK("exynos4-sdhci.3", "div_mmc3_pre", "div_mmc3", 0,
> + EXYNOS4_CLKDIV_FSYS2, 24, 8, 0),
> + DIVCLK("exynos4210-spi.0", "div_spi0", "mout_spi0", 0,
> + EXYNOS4_CLKDIV_PERIL1, 0, 4, 0),
> + DIVCLK("exynos4210-spi.1", "div_spi1", "mout_spi1", 0,
> + EXYNOS4_CLKDIV_PERIL1, 16, 4, 0),
> + DIVCLK("exynos4210-spi.2", "div_spi2", "mout_spi2", 0,
> + EXYNOS4_CLKDIV_PERIL2, 0, 4, 0),
> + DIVCLK("exynos4210-spi.0", "div_spi0_pre", "div_spi0", 0,
> + EXYNOS4_CLKDIV_PERIL1, 8, 8, 0),
> + DIVCLK("exynos4210-spi.1", "div_spi1_pre", "div_spi1", 0,
> + EXYNOS4_CLKDIV_PERIL1, 24, 8, 0),
> + DIVCLK("exynos4210-spi.2", "div_spi2_pre", "div_spi2", 0,
> + EXYNOS4_CLKDIV_PERIL2, 8, 8, 0),
> + DIVCLK(NULL, "div_sata", "mout_sata", 0,
> + EXYNOS4_CLKDIV_FSYS0, 20, 4, 0),
> + DIVCLK("s5p-mfc", "div_mfc", "mout_mfc", 0,
> + EXYNOS4_CLKDIV_MFC, 0, 4, 0),
> + DIVCLK("s5p-mipi-csis.0", "div_csis0", "mout_csis0", 0,
> + EXYNOS4_CLKDIV_CAM, 24, 4, 0),
> + DIVCLK("s5p-mipi-csis.1", "div_csis1", "mout_csis1", 0,
> + EXYNOS4_CLKDIV_CAM, 28, 4, 0),
> + DIVCLK(NULL, "div_cam0", "mout_cam0", 0,
> + EXYNOS4_CLKDIV_CAM, 16, 4, 0),
> + DIVCLK(NULL, "div_cam1", "mout_cam1", 0,
> + EXYNOS4_CLKDIV_CAM, 20, 4, 0),
> + DIVCLK("exynos4-fimc.0", "div_fimc0", "mout_fimc0", 0,
> + EXYNOS4_CLKDIV_CAM, 0, 4, 0),
> + DIVCLK("exynos4-fimc.1", "div_fimc1", "mout_fimc1", 0,
> + EXYNOS4_CLKDIV_CAM, 4, 4, 0),
> + DIVCLK("exynos4-fimc.2", "div_fimc2", "mout_fimc2", 0,
> + EXYNOS4_CLKDIV_CAM, 4, 4, 0),
> + DIVCLK("exynos4-fimc.3", "div_fimc3", "mout_fimc3", 0,
> + EXYNOS4_CLKDIV_CAM, 4, 4, 0),
> + DIVCLK("exynos4-fb.0", "div_fimd0", "mout_fimd0", 0,
> + EXYNOS4_CLKDIV_LCD0, 0, 4, 0),
> + DIVCLK(NULL, "sclk_pixel", "mout_vpll", 0,
> + EXYNOS4_CLKDIV_TV, 0, 4, 0),
> +};
> +
> +struct samsung_gate_clock exynos4_gate_clks[] = {
> + GATECLK("exynos4210-uart.0", "uart0", "aclk_100", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKGATE_IP_PERIL, 0, "uart"),
> + GATECLK("exynos4210-uart.1", "uart1", "aclk_100", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKGATE_IP_PERIL, 1, "uart"),
> + GATECLK("exynos4210-uart.2", "uart2", "aclk_100", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKGATE_IP_PERIL, 2, "uart"),
> + GATECLK("exynos4210-uart.3", "uart3", "aclk_100", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKGATE_IP_PERIL, 3, "uart"),
> + GATECLK("exynos4210-uart.4", "uart4", "aclk_100", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKGATE_IP_PERIL, 4, "uart"),
> + GATECLK("exynos4210-uart.5", "uart5", "aclk_100", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKGATE_IP_PERIL, 5, "uart"),
> + GATECLK("exynos4210-uart.0", "uclk0", "div_uart0", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKSRC_MASK_PERIL0, 0, "clk_uart_baud0"),
> + GATECLK("exynos4210-uart.1", "uclk1", "div_uart1", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKSRC_MASK_PERIL0, 4, "clk_uart_baud0"),
> + GATECLK("exynos4210-uart.2", "uclk2", "div_uart2", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKSRC_MASK_PERIL0, 8, "clk_uart_baud0"),
> + GATECLK("exynos4210-uart.3", "uclk3", "div_uart3", CLK_SET_RATE_PARENT,
> + EXYNOS4_CLKSRC_MASK_PERIL0, 12, "clk_uart_baud0"),
> + GATECLK(NULL, "timers", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 24, NULL),
> + GATECLK("s5p-mipi-csis.0", "csis", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 5, NULL),
> + GATECLK(NULL, "jpeg", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 6, NULL),
> + GATECLK("exynos4-fimc.0", "fimc0", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 0, "fimc"),
> + GATECLK("exynos4-fimc.1", "fimc1", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 1, "fimc"),
> + GATECLK("exynos4-fimc.2", "fimc2", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 2, "fimc"),
> + GATECLK("exynos4-fimc.3", "fimc3", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 3, "fimc"),
> + GATECLK("exynos4-sdhci.0", "hsmmc0", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 5, "hsmmc"),
> + GATECLK("exynos4-sdhci.1", "hsmmc1", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 6, "hsmmc"),
> + GATECLK("exynos4-sdhci.2", "hsmmc2", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 7, "hsmmc"),
> + GATECLK("exynos4-sdhci.3", "hsmmc3", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 8, "hsmmc"),
> + GATECLK(NULL, "dwmmc", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 9, NULL),
> + GATECLK("s5p-sdo", "dac", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_TV, 2, NULL),
> + GATECLK("s5p-mixer", "mixer", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_TV, 1, NULL),
> + GATECLK("s5p-mixer", "vp", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_TV, 0, NULL),
> + GATECLK("exynos4-hdmi", "hdmi", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_TV, 3, NULL),
> + GATECLK("exynos4-hdmi", "hdmiphy", "aclk_160", 0,
> + S5P_HDMI_PHY_CONTROL, 0, NULL),
> + GATECLK("s5p-sdo", "dacphy", "aclk_160", 0,
> + S5P_DAC_PHY_CONTROL, 0, NULL),
> + GATECLK(NULL, "adc", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 15, NULL),
> + GATECLK(NULL, "keypad", "aclk_100", 0,
> + EXYNOS4210_CLKGATE_IP_PERIR, 16, NULL),
> + GATECLK(NULL, "rtc", "aclk_100", 0,
> + EXYNOS4210_CLKGATE_IP_PERIR, 15, NULL),
> + GATECLK(NULL, "watchdog", "aclk_100", 0,
> + EXYNOS4210_CLKGATE_IP_PERIR, 14, NULL),
> + GATECLK(NULL, "usbhost", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 12, NULL),
> + GATECLK(NULL, "otg", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 13, NULL),
> + GATECLK("exynos4210-spi.0", "spi0", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 16, "spi"),
> + GATECLK("exynos4210-spi.1", "spi1", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 17, "spi"),
> + GATECLK("exynos4210-spi.2", "spi2", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 18, "spi"),
> + GATECLK("samsung-i2s.0", "iis0", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 19, "iis"),
> + GATECLK("samsung-i2s.1", "iis1", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 20, "iis"),
> + GATECLK("samsung-i2s.2", "iis2", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 21, "iis"),
> + GATECLK("samsung-ac97", "ac97", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 27, NULL),
> + GATECLK("s5p-mfc", "mfc", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_MFC, 0, NULL),
> + GATECLK("s3c2440-i2c.0", "i2c0", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 6, "i2c"),
> + GATECLK("s3c2440-i2c.1", "i2c1", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 7, "i2c"),
> + GATECLK("s3c2440-i2c.2", "i2c2", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 8, "i2c"),
> + GATECLK("s3c2440-i2c.3", "i2c3", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 9, "i2c"),
> + GATECLK("s3c2440-i2c.4", "i2c4", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 10, "i2c"),
> + GATECLK("s3c2440-i2c.5", "i2c5", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 11, "i2c"),
> + GATECLK("s3c2440-i2c.6", "i2c6", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 12, "i2c"),
> + GATECLK("s3c2440-i2c.7", "i2c7", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 13, "i2c"),
> + GATECLK("s3c2440-hdmiphy-i2c", "i2c", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_PERIL, 14, NULL),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(mfc_l, 0), "sysmmu0", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_MFC, 1, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(mfc_r, 1), "sysmmu1", "aclk_100", 0,
> + EXYNOS4_CLKGATE_IP_MFC, 2, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(tv, 2), "sysmmu2", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_TV, 4, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(jpeg, 3), "sysmmu3", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 11, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(rot, 4), "sysmmu4", "aclk_200", 0,
> + EXYNOS4210_CLKGATE_IP_IMAGE, 4, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(fimc0, 5), "sysmmu5", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 7, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(fimc1, 6), "sysmmu6", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 8, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(fimc2, 7), "sysmmu7", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 9, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(fimc3, 8), "sysmmu8", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_CAM, 10, "sysmmu"),
> + GATECLK(SYSMMU_CLOCK_DEVNAME(fimd, 10), "sysmmu10", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_LCD0, 4, "sysmmu"),
> + GATECLK("dma-pl330.0", "dma0", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 0, "dma"),
> + GATECLK("dma-pl330.1", "dma1", "aclk_133", 0,
> + EXYNOS4_CLKGATE_IP_FSYS, 1, "dma"),
> + GATECLK("exynos4-fb.0", "fimd", "aclk_160", 0,
> + EXYNOS4_CLKGATE_IP_LCD0, 0, "lcd"),
> + GATECLK("exynos4210-spi.0", "sclk_spi0", "div_spi0_pre", 0,
> + EXYNOS4_CLKSRC_MASK_PERIL1, 16, "spi_busclk0"),
> + GATECLK("exynos4210-spi.1", "sclk_spi1", "div_spi1_pre", 0,
> + EXYNOS4_CLKSRC_MASK_PERIL1, 20, "spi_busclk0"),
> + GATECLK("exynos4210-spi.2", "sclk_spi2", "div_spi2_pre", 0,
> + EXYNOS4_CLKSRC_MASK_PERIL1, 24, "spi_busclk0"),
> + GATECLK("exynos4-sdhci.0", "sclk_mmc0", "div_mmc0_pre", 0,
> + EXYNOS4_CLKSRC_MASK_FSYS, 0, "mmc_busclk.2"),
> + GATECLK("exynos4-sdhci.1", "sclk_mmc1", "div_mmc1_pre", 0,
> + EXYNOS4_CLKSRC_MASK_FSYS, 4, "mmc_busclk.2"),
> + GATECLK("exynos4-sdhci.2", "sclk_mmc2", "div_mmc2_pre", 0,
> + EXYNOS4_CLKSRC_MASK_FSYS, 8, "mmc_busclk.2"),
> + GATECLK("exynos4-sdhci.3", "sclk_mmc3", "div_mmc3_pre", 0,
> + EXYNOS4_CLKSRC_MASK_FSYS, 12, "mmc_busclk.2"),
> + GATECLK("s5p-mipi-csis.0", "sclk_csis0", "div_csis0", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 24, "sclk_csis"),
> + GATECLK("s5p-mipi-csis.1", "sclk_csis1", "div_csis1", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 28, "sclk_csis"),
> + GATECLK(NULL, "sclk_cam0", "div_cam0", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 16, NULL),
> + GATECLK(NULL, "sclk_cam1", "div_cam1", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 20, NULL),
> + GATECLK("exynos4-fimc.0", "sclk_fimc", "div_fimc0", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 0, "sclk_fimc"),
+ GATECLK("exynos4-fimc.0", "sclk_fimc0", "div_fimc0", 0,
+ EXYNOS4_CLKSRC_MASK_CAM, 0, "sclk_fimc"),
> + GATECLK("exynos4-fimc.1", "sclk_fimc", "div_fimc1", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 4, "sclk_fimc"),
+ GATECLK("exynos4-fimc.1", "sclk_fimc1", "div_fimc1", 0,
+ EXYNOS4_CLKSRC_MASK_CAM, 4, "sclk_fimc"),
> + GATECLK("exynos4-fimc.2", "sclk_fimc", "div_fimc2", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 8, "sclk_fimc"),
+ GATECLK("exynos4-fimc.2", "sclk_fimc2", "div_fimc2", 0,
+ EXYNOS4_CLKSRC_MASK_CAM, 8, "sclk_fimc"),
> + GATECLK("exynos4-fimc.3", "sclk_fimc", "div_fimc3", 0,
> + EXYNOS4_CLKSRC_MASK_CAM, 12, "sclk_fimc"),
+ GATECLK("exynos4-fimc.3", "sclk_fimc3", "div_fimc3", 0,
+ EXYNOS4_CLKSRC_MASK_CAM, 12, "sclk_fimc"),
> + GATECLK("exynos4-fb.0", "sclk_fimd", "div_fimd0", 0,
> + EXYNOS4_CLKSRC_MASK_LCD0, 0, "sclk_fimd"),
> +};
> +
> +/* register clock common to all Exynos4 platforms */
> +void __init exynos4_clk_init(void)
> +{
> + samsung_clk_register_fixed_rate(exynos4_fixed_rate_clks,
> + ARRAY_SIZE(exynos4_fixed_rate_clks));
> + samsung_clk_register_mux(exynos4_mux_clks,
> + ARRAY_SIZE(exynos4_mux_clks));
> + samsung_clk_register_div(exynos4_div_clks,
> + ARRAY_SIZE(exynos4_div_clks));
> + samsung_clk_register_gate(exynos4_gate_clks,
> + ARRAY_SIZE(exynos4_gate_clks));
> +}
> +
> +/*
> + * Exynos4210 Specific Clocks
> + */
> +
> +static const char *exynos4210_vpll_parent_names[] __initdata = {
> + "mout_vpll_src" };
> +static const char *mout_vpll_src_parents[] __initdata = {
> + "fin_pll", "sclk_hdmi24m" };
> +static const char *exynos4210_mout_vpll_parents[] __initdata = {
> + "mout_vpll_src", "fout_vpll", };
> +
> +/* Exynos4210 specific fixed rate clocks */
> +static struct samsung_fixed_rate_clock exynos4210_fixed_rate_clks[] = {
> + FRATE_CLK(NULL, "sclk_usbphy1", NULL, CLK_IS_ROOT, 48000000),
> +};
> +
> +/* Exynos4210 specific mux-type clocks */
> +static struct samsung_mux_clock exynos4210_mux_clks[] = {
> + MUXCLK(NULL, "mout_vpll_src", mout_vpll_src_parents, 0,
> + EXYNOS4_CLKSRC_TOP1, 0, 1, 0),
> + MUXCLK(NULL, "mout_vpll", exynos4210_mout_vpll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 8, 1, 0),
> + MUXCLK(NULL, "mout_mpll", mout_mpll_parents, 0,
> + EXYNOS4_CLKSRC_CPU, 8, 1, 0),
> +};
> +
> +static unsigned long exynos4210_get_rate_apll(unsigned long xtal_rate)
> +{
> + return s5p_get_pll45xx(xtal_rate,
> + __raw_readl(EXYNOS4_APLL_CON0), pll_4508);
> +}
> +
> +static unsigned long exynos4210_get_rate_mpll(unsigned long xtal_rate)
> +{
> + return s5p_get_pll45xx(xtal_rate,
> + __raw_readl(EXYNOS4_MPLL_CON0), pll_4508);
> +}
> +
> +static unsigned long exynos4210_get_rate_epll(unsigned long xtal_rate)
> +{
> + return s5p_get_pll46xx(xtal_rate, __raw_readl(EXYNOS4_EPLL_CON0),
> + __raw_readl(EXYNOS4_EPLL_CON1), pll_4600);
> +}
> +
> +static unsigned long exynos4210_get_rate_vpll(unsigned long
> vpllsrc_rate) +{
> + return s5p_get_pll46xx(vpllsrc_rate, __raw_readl(EXYNOS4_VPLL_CON0),
> + __raw_readl(EXYNOS4_VPLL_CON1), pll_4650c);
> +}
> +
> +static u32 exynos4_vpll_div[][8] = {
> + { 54000000, 3, 53, 3, 1024, 0, 17, 0 },
> + { 108000000, 3, 53, 2, 1024, 0, 17, 0 },
> +};
> +
> +static int exynos4210_vpll_set_rate(unsigned long rate)
> +{
> + unsigned int vpll_con0, vpll_con1 = 0;
> + unsigned int i;
> +
> + vpll_con0 = __raw_readl(EXYNOS4_VPLL_CON0);
> + vpll_con0 &= ~(0x1 << 27 | \
> + PLL90XX_MDIV_MASK << PLL46XX_MDIV_SHIFT | \
> + PLL90XX_PDIV_MASK << PLL46XX_PDIV_SHIFT | \
> + PLL90XX_SDIV_MASK << PLL46XX_SDIV_SHIFT);
> +
> + vpll_con1 = __raw_readl(EXYNOS4_VPLL_CON1);
> + vpll_con1 &= ~(PLL46XX_MRR_MASK << PLL46XX_MRR_SHIFT | \
> + PLL46XX_MFR_MASK << PLL46XX_MFR_SHIFT | \
> + PLL4650C_KDIV_MASK << PLL46XX_KDIV_SHIFT);
> +
> + for (i = 0; i < ARRAY_SIZE(exynos4_vpll_div); i++) {
> + if (exynos4_vpll_div[i][0] == rate) {
> + vpll_con0 |= exynos4_vpll_div[i][1] << PLL46XX_PDIV_SHIFT;
> + vpll_con0 |= exynos4_vpll_div[i][2] << PLL46XX_MDIV_SHIFT;
> + vpll_con0 |= exynos4_vpll_div[i][3] << PLL46XX_SDIV_SHIFT;
> + vpll_con1 |= exynos4_vpll_div[i][4] << PLL46XX_KDIV_SHIFT;
> + vpll_con1 |= exynos4_vpll_div[i][5] << PLL46XX_MFR_SHIFT;
> + vpll_con1 |= exynos4_vpll_div[i][6] << PLL46XX_MRR_SHIFT;
> + vpll_con0 |= exynos4_vpll_div[i][7] << 27;
> + break;
> + }
> + }
> +
> + if (i == ARRAY_SIZE(exynos4_vpll_div)) {
> + pr_err("%s: Invalid Clock VPLL Frequency\n", __func__);
> + return -EINVAL;
> + }
> +
> + __raw_writel(vpll_con0, EXYNOS4_VPLL_CON0);
> + __raw_writel(vpll_con1, EXYNOS4_VPLL_CON1);
> +
> + /* Wait for VPLL lock */
> + while (!(__raw_readl(EXYNOS4_VPLL_CON0) & (1 << PLL46XX_LOCKED_SHIFT)))
> + continue;
Is it guaranteed to lock in some reasonable time? Maybe some kind of
timeout should be added?
> +
> + return 0;
> +}
> +
> +/* Exynos4210 specific clock registration */
> +void __init exynos4210_clk_init(void)
> +{
> + group1_parents[4] = "sclk_usbphy1";
> +
> + exynos4_clk_init();
> +
> + samsung_clk_register_pll("fout_apll", pll_parent_names,
> + NULL, exynos4210_get_rate_apll);
> + samsung_clk_register_pll("fout_mpll", pll_parent_names,
> + NULL, exynos4210_get_rate_mpll);
> + samsung_clk_register_pll("fout_epll", pll_parent_names,
> + NULL, exynos4210_get_rate_epll);
> + samsung_clk_register_pll("fout_vpll", exynos4210_vpll_parent_names,
> + exynos4210_vpll_set_rate, exynos4210_get_rate_vpll);
> +
> + samsung_clk_register_fixed_rate(exynos4210_fixed_rate_clks,
> + ARRAY_SIZE(exynos4210_fixed_rate_clks));
> + samsung_clk_register_mux(exynos4210_mux_clks,
> + ARRAY_SIZE(exynos4210_mux_clks));
> +
> + pr_info("EXYNOS4210: PLL settings: A=%ld, M=%ld, E=%ld, V=%ld\n",
> + _get_rate("fout_apll"), _get_rate("fout_mpll"),
> + _get_rate("fout_epll"), _get_rate("fout_vpll"));
> +
> + pr_info("EXYNOS4210: ARMCLK=%ld, ACLK200=%ld, ACLK100=%ld\n"
> + " ACLK160=%ld, ACLK133=%ld\n", _get_rate("armclk"),
> + _get_rate("aclk_200"), _get_rate("aclk_100"),
> + _get_rate("aclk_160"), _get_rate("aclk_133"));
> +}
> +
> +/*
> + * Exynos4212 Specific Clocks
> + */
> +
> +static const char *exynos4212_mout_vpll_parents[] __initdata = {
> + "fin_pll", "fout_vpll", };
> +
> +/* Exynos4212 specific mux clocks */
> +static struct samsung_mux_clock exynos4212_mux_clks[] = {
> + MUXCLK(NULL, "mout_mpll", mout_mpll_parents, 0,
> + EXYNOS4_CLKSRC_DMC, 12, 1, 0),
> + MUXCLK(NULL, "mout_vpll", exynos4212_mout_vpll_parents, 0,
> + EXYNOS4_CLKSRC_TOP0, 8, 1, 0),
> +};
> +
> +static unsigned long exynos4212_get_rate_apll(unsigned long xtal_rate)
> +{
> + return s5p_get_pll35xx(xtal_rate, __raw_readl(EXYNOS4_APLL_CON0));
> +}
> +
> +static unsigned long exynos4212_get_rate_mpll(unsigned long xtal_rate)
> +{
> + return s5p_get_pll35xx(xtal_rate, __raw_readl(EXYNOS4_MPLL_CON0));
> +}
> +
> +static unsigned long exynos4212_get_rate_epll(unsigned long xtal_rate)
> +{
> + return s5p_get_pll36xx(xtal_rate, __raw_readl(EXYNOS4_EPLL_CON0),
> + __raw_readl(EXYNOS4_EPLL_CON1));
> +}
> +
> +static unsigned long exynos4212_get_rate_vpll(unsigned long
> vpllsrc_rate) +{
> + return s5p_get_pll36xx(vpllsrc_rate, __raw_readl(EXYNOS4_VPLL_CON0),
> + __raw_readl(EXYNOS4_VPLL_CON1));
> +}
> +
> +/* Exynos4212 specific clock registeration */
> +void __init exynos4212_clk_init(void)
> +{
> + exynos4_clk_init();
> +
> + samsung_clk_register_pll("fout_apll", pll_parent_names,
> + NULL, exynos4212_get_rate_apll);
> + samsung_clk_register_pll("fout_mpll", pll_parent_names,
> + NULL, exynos4212_get_rate_mpll);
> + samsung_clk_register_pll("fout_epll", pll_parent_names,
> + NULL, exynos4212_get_rate_epll);
> + samsung_clk_register_pll("fout_vpll", pll_parent_names,
> + NULL, exynos4212_get_rate_vpll);
> +
> + samsung_clk_register_mux(exynos4212_mux_clks,
> + ARRAY_SIZE(exynos4212_mux_clks));
> +
> + pr_info("EXYNOS4210: PLL settings: A=%ld, M=%ld, E=%ld, V=%ld\n",
> + _get_rate("fout_apll"), _get_rate("fout_mpll"),
> + _get_rate("fout_epll"), _get_rate("fout_vpll"));
> +
> + pr_info("EXYNOS4210: ARMCLK=%ld, ACLK200=%ld, ACLK100=%ld\n"
> + " ACLK160=%ld, ACLK133=%ld\n", _get_rate("armclk"),
> + _get_rate("aclk_200"), _get_rate("aclk_100"),
> + _get_rate("aclk_160"), _get_rate("aclk_133"));
> +}
> diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
> new file mode 100644
> index 0000000..65156b9
> --- /dev/null
> +++ b/drivers/clk/samsung/clk.c
> @@ -0,0 +1,231 @@
> +/*
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * Copyright (c) 2012 Linaro Ltd.
> + *
> + * 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.
> + *
> + * This file includes utility functions to register clocks to common
> + * clock framework for Samsung platforms. This includes an
> implementation + * of Samsung 'pll type' clock to represent the
> implementation of the + * pll found on Samsung platforms. In addition to
> that, utility functions + * to register mux, div, gate and fixed rate
> types of clocks are included. +*/
> +
> +#include "clk.h"
> +
> +static DEFINE_SPINLOCK(lock);
> +
> +#define to_clk_pll(_hw) container_of(_hw, struct samsung_clk_pll, hw)
> +
> +/* determine the output clock speed of the pll */
> +static unsigned long samsung_clk_pll_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct samsung_clk_pll *clk_pll = to_clk_pll(hw);
> +
> + if (clk_pll->get_rate)
> + return to_clk_pll(hw)->get_rate(parent_rate);
> +
> + return 0;
> +}
> +
> +/* round operation not supported */
> +static long samsung_clk_pll_round_rate(struct clk_hw *hw, unsigned long
> drate, + unsigned long *prate)
> +{
> + return samsung_clk_pll_recalc_rate(hw, *prate);
> +}
> +
> +/* set the clock output rate of the pll */
> +static int samsung_clk_pll_set_rate(struct clk_hw *hw, unsigned long
> drate, + unsigned long prate)
> +{
> + struct samsung_clk_pll *clk_pll = to_clk_pll(hw);
> +
> + if (clk_pll->set_rate)
> + return to_clk_pll(hw)->set_rate(drate);
> +
> + return 0;
> +}
> +
> +/* clock operations for samsung pll clock type */
> +static const struct clk_ops samsung_clk_pll_ops = {
> + .recalc_rate = samsung_clk_pll_recalc_rate,
> + .round_rate = samsung_clk_pll_round_rate,
> + .set_rate = samsung_clk_pll_set_rate,
> +};
> +
> +/* register a samsung pll type clock */
> +void __init samsung_clk_register_pll(const char *name, const char
> **pnames, + int (*set_rate)(unsigned long rate),
> + unsigned long (*get_rate)(unsigned long rate))
> +{
> + struct samsung_clk_pll *clk_pll;
> + struct clk *clk;
> + struct clk_init_data init;
> + int ret;
> +
> + clk_pll = kzalloc(sizeof(*clk_pll), GFP_KERNEL);
> + if (!clk_pll) {
> + pr_err("%s: could not allocate pll clk %s\n", __func__, name);
> + return;
> + }
> +
> + init.name = name;
> + init.ops = &samsung_clk_pll_ops;
> + init.flags = CLK_GET_RATE_NOCACHE;
> + init.parent_names = pnames;
> + init.num_parents = 1;
> +
> + clk_pll->set_rate = set_rate;
> + clk_pll->get_rate = get_rate;
> + clk_pll->hw.init = &init;
> +
> + /* register the clock */
> + clk = clk_register(NULL, &clk_pll->hw);
> + if (IS_ERR(clk)) {
> + pr_err("%s: failed to register pll clock %s\n", __func__,
> + name);
> + kfree(clk_pll);
> + return;
> + }
> +
> + ret = clk_register_clkdev(clk, name, NULL);
> + if (ret)
> + pr_err("%s: failed to register clock lookup for %s", __func__,
> + name);
> +}
> +
> +/* register a list of fixed clocks */
> +void __init samsung_clk_register_fixed_rate(
> + struct samsung_fixed_rate_clock *clk_list, unsigned int nr_clk)
> +{
> + struct clk *clk;
> + unsigned int idx, ret;
> +
> + for (idx = 0; idx < nr_clk; idx++, clk_list++) {
> + clk = clk_register_fixed_rate(NULL, clk_list->name,
> + clk_list->parent_name, clk_list->flags,
> + clk_list->fixed_rate);
> + if (IS_ERR_OR_NULL(clk)) {
Is the check for NULL needed here? Looking at samsung_fixed_rate_clock
and clk_register, the convention is to always return ERR_PTR on error.
> + pr_err("clock: failed to register clock %s\n",
> + clk_list->name);
> + continue;
> + }
> +
> + ret = clk_register_clkdev(clk, clk_list->name,
> + clk_list->dev_name);
> + if (ret)
> + pr_err("clock: failed to register clock lookup for %s",
> + clk_list->name);
> + }
> +}
> +
> +/* register a list of mux clocks */
> +void __init samsung_clk_register_mux(struct samsung_mux_clock *clk_list,
> + unsigned int nr_clk)
> +{
> + struct clk *clk;
> + unsigned int idx, ret;
> +
> + for (idx = 0; idx < nr_clk; idx++, clk_list++) {
> + clk = clk_register_mux(NULL, clk_list->name,
> + clk_list->parent_names, clk_list->num_parents,
> + clk_list->flags, clk_list->reg, clk_list->shift,
> + clk_list->width, clk_list->mux_flags, &lock);
> + if (IS_ERR_OR_NULL(clk)) {
See my comment for samsung_clk_register_fixed_rate .
> + pr_err("clock: failed to register clock %s\n",
> + clk_list->name);
> + continue;
> + }
> +
> + ret = clk_register_clkdev(clk, clk_list->name,
> + clk_list->dev_name);
> + if (ret)
> + pr_err("clock: failed to register clock lookup for %s",
> + clk_list->name);
> +
> + if (clk_list->alias)
> + clk_register_clkdev(clk, clk_list->alias,
> + clk_list->dev_name);
> + }
> +}
> +
> +/* reguster a list of div clocks */
> +void __init samsung_clk_register_div(struct samsung_div_clock *clk_list,
> + unsigned int nr_clk)
> +{
> + struct clk *clk;
> + unsigned int idx, ret;
> +
> + for (idx = 0; idx < nr_clk; idx++, clk_list++) {
> + clk = clk_register_divider(NULL, clk_list->name,
> + clk_list->parent_name, clk_list->flags, clk_list->reg,
> + clk_list->shift, clk_list->width, clk_list->div_flags,
> + &lock);
> + if (IS_ERR_OR_NULL(clk)) {
See my comment for samsung_clk_register_fixed_rate .
> + pr_err("clock: failed to register clock %s\n",
> + clk_list->name);
> + continue;
> + }
> +
> + ret = clk_register_clkdev(clk, clk_list->name,
> + clk_list->dev_name);
> + if (ret)
> + pr_err("clock: failed to register clock lookup for %s",
> + clk_list->name);
> +
> + if (clk_list->alias)
> + clk_register_clkdev(clk, clk_list->alias,
> + clk_list->dev_name);
> + }
> +}
> +
> +/* register a list of gate clocks */
> +void __init samsung_clk_register_gate(struct samsung_gate_clock
> *clk_list, + unsigned int nr_clk)
> +{
> + struct clk *clk;
> + unsigned int idx, ret;
> +
> + for (idx = 0; idx < nr_clk; idx++, clk_list++) {
> + clk = clk_register_gate(NULL, clk_list->name,
> + clk_list->parent_name, clk_list->flags, clk_list->reg,
> + clk_list->bit_idx, clk_list->gate_flags, &lock);
> + if (IS_ERR_OR_NULL(clk)) {
See my comment for samsung_clk_register_fixed_rate .
> + pr_err("clock: failed to register clock %s\n",
> + clk_list->name);
> + continue;
> + }
> +
> + ret = clk_register_clkdev(clk, clk_list->name,
> + clk_list->dev_name);
> + if (ret) {
> + pr_err("clock: failed to register clock lookup for %s",
> + clk_list->name);
> + continue;
> + }
> +
> + ret = clk_register_clkdev(clk, clk_list->alias,
> + clk_list->dev_name);
> + if (ret)
> + pr_err("clock: failed to register alias %s for clock "
> + " %s", clk_list->alias, clk_list->name);
> + }
> +}
> +
> +/* utility function to get the rate of a specified clock */
> +unsigned long _get_rate(const char *clk_name)
> +{
> + struct clk *clk;
> + unsigned long rate;
> +
> + clk = clk_get(NULL, clk_name);
> + if (IS_ERR(clk))
> + return 0;
> + rate = clk_get_rate(clk);
> + clk_put(clk);
> + return rate;
> +}
Shouldn't it be moved to clk-exynos4.c and made static?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH v3 0/2] ARM: davinci: da850/omap-l138: add support for VPIF driver
From: Sekhar Nori @ 2012-10-03 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347344709-6180-1-git-send-email-prabhakar.lad@ti.com>
Hi Prabhakar,
On 9/11/2012 11:55 AM, Prabhakar Lad wrote:
> This patch series adds support for VPIF
> capture and display driver on da850/omap-l138.
> Enables SD capture and display.
>
> This patch series is dependent on the following patch:
> https://patchwork.kernel.org/patch/1332311/
>
> Changes for v3:
> 1: Clubbed the code for DA850_UI_SD_VIDEO_PORT config
> as pointed by Sekhar.
> 2: Define the resource structure outside the function as pointed
> by Sekhar.
>
> Changes for v2:
> 1: Avoid breaking of print messages.
> 2: Removed the handlers which just returned zero (which did nothing).
> 3: Clubbed the code where ever possible for DA850_UI_SD_VIDEO_PORT
> config option.
> 4: Removed the dma_declare_coherent_memory() calls and used
> global CMA.
> 5: Added the base address in increasing order.
>
> Manjunath Hadli (2):
> ARM: da850/omap-l138: Add SoC related definitions for VPIF
> ARM: da850/omap-l138: Add EVM specific code for VPIF to work
>
> Manjunath Hadli (2):
> ARM: da850/omap-l138: Add SoC related definitions for VPIF
> ARM: da850/omap-l138: Add EVM specific code for VPIF to work
>
> arch/arm/mach-davinci/Kconfig | 7 ++
> arch/arm/mach-davinci/board-da850-evm.c | 156 ++++++++++++++++++++++++++++
> arch/arm/mach-davinci/da850.c | 152 +++++++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/da8xx.h | 11 ++
> arch/arm/mach-davinci/include/mach/mux.h | 42 ++++++++
> arch/arm/mach-davinci/include/mach/psc.h | 1 +
> 6 files changed, 369 insertions(+), 0 deletions(-)
The patches look good to me. In case you want to queue them through the
media tree to manage the dependencies, feel free to add my:
Acked-by: Sekhar Nori <nsekhar@ti.com>
Note that the subject like prefix for DA850 soc patches should be
"ARM: davinci: da850: .."
and that for DA850 EVM patches should be:
"ARM: davinci: da850 evm: .."
instead of what you have used here. Please fix these if you are queuing
them and take care of this in future.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 0/2] ARM: Exynos4: Migrate to common clock framework.
From: Tomasz Figa @ 2012-10-03 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349093361-18820-1-git-send-email-thomas.abraham@linaro.org>
Hi Chander, Thomas,
On Monday 01 of October 2012 17:39:19 chander.kashyap at linaro.org wrote:
> From: Thomas Abraham <thomas.abraham@linaro.org>
>
> This patch series migrates Exynos4 clock support to common clock
> framework. The first patch in this series removes the existing Exynos4
> clock support that uses the Samsung specific clock framework. The second
> patch in this series add Exynos4 clock support using common clock
> framework.
>
> Thomas Abraham (2):
> ARM: Exynos4: Remove Samsung clock type support
> ARM: Exynos4: Register clocks via common clock framework
I think the order of changes is a little bit off here:
- patch 1 will break all exynos4-based boards (what about bisects?)
- patch 2 will be still broken until all related drivers get converted to
use clk_prepare(_enable) and clk_(disable_)unprepare.
Shouldn't the order be exactly opposite, i.e.:
- all the patches for prepare/unprepare first
- then the patch adding common clock frameworks support for exynos4
(disabling the old clock code)
- and finally the patch removing remaining (disabled by previous patch)
code.
Also, I assume that these patches doesn't consider native device tree
support (without auxdata, using OF-based clock lookup), correct me if I'm
wrong. If I'm right, since Exynos SoCs are going to be DT-only, is there
really a point for adding common clock framework support for non-DT
platforms (which are going to be eventually dropped anyway)?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant
From: Hebbar, Gururaja @ 2012-10-03 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506B6A9D.3090100@gmail.com>
On Wed, Oct 03, 2012 at 03:58:45, Daniel Mack wrote:
> On 31.08.2012 14:50, Hebbar, Gururaja wrote:
> > The OMAP2+ variant of McASP is different from Davinci variant w.r.to some
> > register offset and missing generic SRAM APIs support
> >
> > Changes
> > - Add new MCASP_VERSION_3 to identify new variant. New DT compatible
> > "ti,omap2-mcasp-audio" to identify version 3 controller.
> > - The register offsets are handled depending on the version.
> > - Provide a config option to indicate missing SRAM API support.
>
> Could you give some insight which hardware this was tested on? I'm
> trying to get this up and running on a AM33xx board, and the patches
> look all reasonable to me. My problem is that I can't make the DMA
> engine move forward, I fail to receive a single interrupt on this
> peripheral after the stream starts. I will continue searching for the
> reason of this tomorrow, but maybe you can give me some hint by
> explaining your setup?
>
> Note that I'm using your patches together with Matt's from this series:
>
> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
>
> ... but it doesn't work without those either.
When I started working on adding DT support to McASP driver, Matt Porter
EDMA port was not yet ready.
So
1. I took existing edma driver from AM335x Arago release [1] (driver + edma
device init).
2. Added this to Vaibhav's Local (linux-next + AM335x patches) tree [2]
3. Added DT support to McASP driver.
I tested this on AM335x EVM board.
If you need the code, I can share it as a patch (I will send the patch as a
private mail since the patch is huge).
[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commit;h=d7e124e8074cccf9958290e773c88a4b2b36412b
[2]
https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging
>
>
>
> Thanks,
> Daniel
>
>
Regards,
Gururaja
^ 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