* [PATCH] ARM: ux500: de-globalize <mach/id.h>
From: Samuel Ortiz @ 2013-01-22 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357546827-10154-1-git-send-email-linus.walleij@stericsson.com>
Hi Linus,
On Mon, Jan 07, 2013 at 09:20:27AM +0100, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This removes the file <mach/id.h> from the global kernel include
> scope, making it a pure mach-ux500 detail. All ASIC specifics
> needed by drivers shall henceforth be passed from either platform
> data or the device tree.
>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> I'm sending this as a preview, collecting ACKs for the next
> merge window.
>
> Sam, Rafael, could you ACK this?
>
> Linus Walleij
> ---
> arch/arm/mach-ux500/board-mop500-uib.c | 1 +
> arch/arm/mach-ux500/cache-l2x0.c | 3 +-
> arch/arm/mach-ux500/cpu-db8500.c | 2 +
> arch/arm/mach-ux500/cpu.c | 1 +
> arch/arm/mach-ux500/id.c | 2 +
> arch/arm/mach-ux500/id.h | 144 ++++++++++++++++++++++++++++
> arch/arm/mach-ux500/include/mach/hardware.h | 1 -
> arch/arm/mach-ux500/include/mach/id.h | 144 ----------------------------
> arch/arm/mach-ux500/platsmp.c | 3 +
> arch/arm/mach-ux500/timer.c | 2 +
> drivers/cpufreq/db8500-cpufreq.c | 3 -
> drivers/mfd/db8500-prcmu.c | 17 ++--
> include/linux/mfd/dbx500-prcmu.h | 2 -
For the MFD bits:
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [V4 PATCH 18/26] usb: phy: mv_usb2_phy: add externel chip support
From: Chao Xie @ 2013-01-22 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121155156.GM23505@n2100.arm.linux.org.uk>
On Mon, Jan 21, 2013 at 11:51 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 21, 2013 at 05:07:36AM -0500, Chao Xie wrote:
>> + mv_phy->extern_chip.head = devm_kzalloc(&pdev->dev,
>> + sizeof(*mv_phy->extern_chip.head),
>> + GFP_KERNEL);
>> + if (mv_phy->extern_chip.head == NULL)
>> + return -ENOMEM;
>> + ATOMIC_INIT_NOTIFIER_HEAD(mv_phy->extern_chip.head);
>
> Why do you need to allocate an atomic notifier list head as an entirely
> separate data structure?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Th reason is that the original code seperate the extern_chip and phy
support. So it depends
on the ->head to detect whether extern_chip is initialized or not.
Now it is combined with phy, the ->phy pointer can do the job.
^ permalink raw reply
* [PATCH] mfd: remove redundant devm_* for 88pm80x PMIC
From: Yi Zhang @ 2013-01-22 2:43 UTC (permalink / raw)
To: linux-arm-kernel
devm_* functions are device managed and make error handling
and code simpler; it also fix error exit paths
Signed-off-by: Yi Zhang <yizhang@marvell.com>
---
drivers/mfd/88pm800.c | 10 +++-------
drivers/mfd/88pm805.c | 4 ++--
drivers/mfd/88pm80x.c | 22 ++++------------------
include/linux/mfd/88pm80x.h | 2 +-
4 files changed, 10 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 391e23e..582bda5 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -531,7 +531,7 @@ static int pm800_probe(struct i2c_client *client,
ret = device_800_init(chip, pdata);
if (ret) {
dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
- goto err_800_init;
+ goto err_subchip_alloc;
}
ret = pm800_pages_init(chip);
@@ -546,10 +546,8 @@ static int pm800_probe(struct i2c_client *client,
err_page_init:
mfd_remove_devices(chip->dev);
device_irq_exit_800(chip);
-err_800_init:
- devm_kfree(&client->dev, subchip);
err_subchip_alloc:
- pm80x_deinit(client);
+ pm80x_deinit();
out_init:
return ret;
}
@@ -562,9 +560,7 @@ static int pm800_remove(struct i2c_client *client)
device_irq_exit_800(chip);
pm800_pages_exit(chip);
- devm_kfree(&client->dev, chip->subchip);
-
- pm80x_deinit(client);
+ pm80x_deinit();
return 0;
}
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index e671230..65d7ac0 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -257,7 +257,7 @@ static int pm805_probe(struct i2c_client *client,
pdata->plat_config(chip, pdata);
err_805_init:
- pm80x_deinit(client);
+ pm80x_deinit();
out_init:
return ret;
}
@@ -269,7 +269,7 @@ static int pm805_remove(struct i2c_client *client)
mfd_remove_devices(chip->dev);
device_irq_exit_805(chip);
- pm80x_deinit(client);
+ pm80x_deinit();
return 0;
}
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 1adb355..f736a46 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -48,14 +48,12 @@ int pm80x_init(struct i2c_client *client,
ret = PTR_ERR(map);
dev_err(&client->dev, "Failed to allocate register map: %d\n",
ret);
- goto err_regmap_init;
+ return ret;
}
chip->id = id->driver_data;
- if (chip->id < CHIP_PM800 || chip->id > CHIP_PM805) {
- ret = -EINVAL;
- goto err_chip_id;
- }
+ if (chip->id < CHIP_PM800 || chip->id > CHIP_PM805)
+ return -EINVAL;
chip->client = client;
chip->regmap = map;
@@ -82,19 +80,11 @@ int pm80x_init(struct i2c_client *client,
}
return 0;
-
-err_chip_id:
- regmap_exit(map);
-err_regmap_init:
- devm_kfree(&client->dev, chip);
- return ret;
}
EXPORT_SYMBOL_GPL(pm80x_init);
-int pm80x_deinit(struct i2c_client *client)
+int pm80x_deinit(void)
{
- struct pm80x_chip *chip = i2c_get_clientdata(client);
-
/*
* workaround: clear the dependency between pm800 and pm805.
* would remove it after HW chip fixes the issue.
@@ -103,10 +93,6 @@ int pm80x_deinit(struct i2c_client *client)
g_pm80x_chip->companion = NULL;
else
g_pm80x_chip = NULL;
-
- regmap_exit(chip->regmap);
- devm_kfree(&client->dev, chip);
-
return 0;
}
EXPORT_SYMBOL_GPL(pm80x_deinit);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 478672e..e94537b 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -365,5 +365,5 @@ static inline int pm80x_dev_resume(struct device *dev)
extern int pm80x_init(struct i2c_client *client,
const struct i2c_device_id *id);
-extern int pm80x_deinit(struct i2c_client *client);
+extern int pm80x_deinit(void);
#endif /* __LINUX_MFD_88PM80X_H */
--
1.7.0.4
^ permalink raw reply related
* OMAP4 PM bootloader dependency problems
From: Paul Walmsley @ 2013-01-22 2:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tero, Rajendra, Santosh,
As we've discussed, there are known bootloader dependencies with the OMAP4
PM retention idle code, introduced in v3.8. Boards booted with u-boot
versions even as recent as 2011 won't enter retention idle correctly; for
example:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt
The right thing for you all to do is what was done for OMAP3: to add code
to correctly reset and initialize these on-chip devices. However, since
it's already late in the v3.8-rc cycle, this seems unlikely to happen in
time for the v3.8 release -- and that's assuming that you guys are working
on this, which I'm unsure of.
Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds
a warning, printed to the kernel console, during boot. The warning should
state that the OMAP4 PM code only works with certain bootloaders, and
should identify the minimum u-boot release needed for OMAP4 full-chip
retention idle to work.
Could you guys please put that together ASAP so we can get it merged
during the v3.8-rc cycle? Otherwise we're going to frustrate users when
people expect PM to work correctly with their existing bootloaders. The
least we can do for them is warn them that problems exist.
This should take priority over any new features.
- Paul
---------- Forwarded message ----------
Date: Mon, 7 Jan 2013 18:40:02 +0000 (UTC)
From: Paul Walmsley <paul@pwsan.com>
To: Madhusudhan.Gowda at elektrobit.com
Cc: linux-omap at vger.kernel.org, t-kristo at ti.com, rnayak at ti.com
Subject: RE: Querry on UART wakeup on Linux 3.8-rc1
Hi,
On Sun, 6 Jan 2013, Madhusudhan.Gowda at elektrobit.com wrote:
> Could someone point me if it has been working in any of the releases ?
Serial wakeup from retention suspend seems to work on the OMAP4460
Panda-ES here as of v3.8-rc1, with a really recent U-boot[*]:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4460pandaes/4460pandaes_log.txt
http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/README.txt
(There are some warnings present from the power state debugging
code, so there's probably something that could use a closer look.)
The problem is, you need a really recent bootloader for this to work.
This is because the mainline kernel is missing code to idle several
on-chip devices (IVAHD, DSP, etc.). This can be seen with the OMAP4430
boot logs:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4430es2panda/4430es2panda_log.txt
That board is running an "older" bootloader - from July 2012!
The hope is that some of the folks still working for TI can post the
appropriate reset and idle code for these devices. Or at least, we'd
better add a console warning to the OMAP44xx PM init code that warns about
the bootloader dependencies. Any comments from the TI folks here?
- Paul
>
> Thanks,
> Gowda
>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org
> [mailto:linux-omap-owner at vger.kernel.org]
> Sent: 01. tammikuuta 2013 22:08
> To: linux-omap at vger.kernel.org
> Subject: Querry on UART wakeup on Linux 3.8-rc1
>
> Hi,
>
> I tried to wakeup OMAP430 ES2.1 Panda from static suspend retention
> using console uart2, it doesn't wakeup.
> But could configure GPIO_121 button to wake up from retention fine.
>
> On the serial uart side I have manually enabled wakeup by echo enabled >
> /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
>
> I could see the wakeup enable bit (1<<14) of uart irrx pad register is
> being set properly before it does static suspend fine.
>
> Should I need to do any more thing to get it work?
>
> Thanks,
> Gowda
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org More majordomo info
> at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] mfd: remove redundant devm_* for 88pm80x PMIC
From: y at marvell.com @ 2013-01-22 2:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Yi Zhang <yizhang@marvell.com>
devm_* functions are device managed and make error handling
and code simpler; it also fix error exit paths
Signed-off-by: Yi Zhang <yizhang@marvell.com>
---
drivers/mfd/88pm800.c | 10 +++-------
drivers/mfd/88pm805.c | 4 ++--
drivers/mfd/88pm80x.c | 22 ++++------------------
include/linux/mfd/88pm80x.h | 2 +-
4 files changed, 10 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 391e23e..582bda5 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -531,7 +531,7 @@ static int pm800_probe(struct i2c_client *client,
ret = device_800_init(chip, pdata);
if (ret) {
dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
- goto err_800_init;
+ goto err_subchip_alloc;
}
ret = pm800_pages_init(chip);
@@ -546,10 +546,8 @@ static int pm800_probe(struct i2c_client *client,
err_page_init:
mfd_remove_devices(chip->dev);
device_irq_exit_800(chip);
-err_800_init:
- devm_kfree(&client->dev, subchip);
err_subchip_alloc:
- pm80x_deinit(client);
+ pm80x_deinit();
out_init:
return ret;
}
@@ -562,9 +560,7 @@ static int pm800_remove(struct i2c_client *client)
device_irq_exit_800(chip);
pm800_pages_exit(chip);
- devm_kfree(&client->dev, chip->subchip);
-
- pm80x_deinit(client);
+ pm80x_deinit();
return 0;
}
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index e671230..65d7ac0 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -257,7 +257,7 @@ static int pm805_probe(struct i2c_client *client,
pdata->plat_config(chip, pdata);
err_805_init:
- pm80x_deinit(client);
+ pm80x_deinit();
out_init:
return ret;
}
@@ -269,7 +269,7 @@ static int pm805_remove(struct i2c_client *client)
mfd_remove_devices(chip->dev);
device_irq_exit_805(chip);
- pm80x_deinit(client);
+ pm80x_deinit();
return 0;
}
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 1adb355..f736a46 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -48,14 +48,12 @@ int pm80x_init(struct i2c_client *client,
ret = PTR_ERR(map);
dev_err(&client->dev, "Failed to allocate register map: %d\n",
ret);
- goto err_regmap_init;
+ return ret;
}
chip->id = id->driver_data;
- if (chip->id < CHIP_PM800 || chip->id > CHIP_PM805) {
- ret = -EINVAL;
- goto err_chip_id;
- }
+ if (chip->id < CHIP_PM800 || chip->id > CHIP_PM805)
+ return -EINVAL;
chip->client = client;
chip->regmap = map;
@@ -82,19 +80,11 @@ int pm80x_init(struct i2c_client *client,
}
return 0;
-
-err_chip_id:
- regmap_exit(map);
-err_regmap_init:
- devm_kfree(&client->dev, chip);
- return ret;
}
EXPORT_SYMBOL_GPL(pm80x_init);
-int pm80x_deinit(struct i2c_client *client)
+int pm80x_deinit(void)
{
- struct pm80x_chip *chip = i2c_get_clientdata(client);
-
/*
* workaround: clear the dependency between pm800 and pm805.
* would remove it after HW chip fixes the issue.
@@ -103,10 +93,6 @@ int pm80x_deinit(struct i2c_client *client)
g_pm80x_chip->companion = NULL;
else
g_pm80x_chip = NULL;
-
- regmap_exit(chip->regmap);
- devm_kfree(&client->dev, chip);
-
return 0;
}
EXPORT_SYMBOL_GPL(pm80x_deinit);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 478672e..e94537b 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -365,5 +365,5 @@ static inline int pm80x_dev_resume(struct device *dev)
extern int pm80x_init(struct i2c_client *client,
const struct i2c_device_id *id);
-extern int pm80x_deinit(struct i2c_client *client);
+extern int pm80x_deinit(void);
#endif /* __LINUX_MFD_88PM80X_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH v5 7/9] ARM: davinci: Remoteproc platform device creation data/code
From: Tivy, Robert @ 2013-01-22 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FCFD89.2070109@ti.com>
> -----Original Message-----
> From: Nori, Sekhar
> Sent: Monday, January 21, 2013 12:34 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> kernel at lists.infradead.org; Ring, Chris; Grosen, Mark; ohad at wizery.com;
> rob at landley.net; linux-doc at vger.kernel.org
> Subject: Re: [PATCH v5 7/9] ARM: davinci: Remoteproc platform device
> creation data/code
>
>
> On 1/11/2013 5:53 AM, Robert Tivy wrote:
> > Added a new remoteproc platform device for DA8XX. Contains CMA-based
> > reservation of physical memory block. A new kernel command-line
> > parameter has been added to allow boot-time specification of the
> > physical memory block.
> >
> > Signed-off-by: Robert Tivy <rtivy@ti.com>
> > ---
> > Documentation/kernel-parameters.txt | 7 +++
> > arch/arm/mach-davinci/devices-da8xx.c | 93
> +++++++++++++++++++++++++++-
> > arch/arm/mach-davinci/include/mach/da8xx.h | 4 ++
> > 3 files changed, 103 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> > index 363e348..e95afb1 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -44,6 +44,7 @@ parameter is applicable:
> > AVR32 AVR32 architecture is enabled.
> > AX25 Appropriate AX.25 support is enabled.
> > BLACKFIN Blackfin architecture is enabled.
> > + CMA Contiguous Memory Area support is enabled.
> > DRM Direct Rendering Management support is enabled.
> > DYNAMIC_DEBUG Build in debug messages and enable them at runtime
> > EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
> > @@ -2634,6 +2635,12 @@ bytes respectively. Such letter suffixes can
> also be entirely omitted.
> > Useful for devices that are detected asynchronously
> > (e.g. USB and MMC devices).
> >
> > + rproc_mem=nn[KMG][@address]
> > + [KNL,ARM,CMA] Remoteproc physical memory block.
> > + Memory area to be used by remote processor image,
> > + managed by CMA. Suitable defaults exist if not
> > + specified.
>
> There are no defaults now, right?
That's right, booter must specify rproc_mem in u-boot bootargs.
>
> > +
> > rw [KNL] Mount root device read-write on boot
> >
> > S [KNL] Run init in single mode
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
> davinci/devices-da8xx.c
> > index fb2f51b..e8016ca 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -12,10 +12,11 @@
> > */
> > #include <linux/init.h>
> > #include <linux/platform_device.h>
> > -#include <linux/dma-mapping.h>
> > +#include <linux/dma-contiguous.h>
> > #include <linux/serial_8250.h>
> > #include <linux/ahci_platform.h>
> > #include <linux/clk.h>
> > +#include <linux/platform_data/da8xx-remoteproc.h>
> >
> > #include <mach/cputype.h>
> > #include <mach/common.h>
> > @@ -706,6 +707,96 @@ int __init da850_register_mmcsd1(struct
> davinci_mmc_config *config)
> > }
> > #endif
> >
> > +static struct resource da8xx_rproc_resources[] = {
> > + { /* DSP boot address */
> > + .start = DA8XX_SYSCFG0_BASE +
> DA8XX_HOST1CFG_REG,
> > + .end = DA8XX_SYSCFG0_BASE + DA8XX_HOST1CFG_REG + 3,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + { /* dsp irq */
> > + .start = IRQ_DA8XX_CHIPINT0,
> > + .end = IRQ_DA8XX_CHIPINT0,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > +};
> > +
> > +static struct da8xx_rproc_pdata rproc_pdata = {
> > + .name = "dsp",
> > +};
>
> Since the driver is only for da850 so the name of the remote processor
> is fixed and can probably be hardcoded in the driver itself.
In which case I wouldn't even need the da8xx_rproc_pdata at all, which would be nice.
>
> > +
> > +static struct platform_device da8xx_dsp = {
> > + .name = "davinci-rproc",
> > + .id = 0,
> > + .dev = {
> > + .platform_data = &rproc_pdata,
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + },
> > + .num_resources = ARRAY_SIZE(da8xx_rproc_resources),
> > + .resource = da8xx_rproc_resources,
> > +};
> > +
> > +#if IS_ENABLED(CONFIG_DAVINCI_REMOTEPROC)
> > +
> > +static phys_addr_t rproc_base __initdata;
> > +static unsigned long rproc_size __initdata;
> > +
> > +static int __init early_rproc_mem(char *p)
> > +{
> > + char *endp;
> > +
> > + if (p == NULL)
> > + return 0;
> > +
> > + rproc_size = memparse(p, &endp);
> > + if (*endp == '@')
> > + rproc_base = memparse(endp + 1, NULL);
> > +
> > + return 0;
> > +}
> > +early_param("rproc_mem", early_rproc_mem);
> > +
> > +void __init da8xx_rproc_reserve_cma(void)
> > +{
> > + int ret;
> > +
> > + if (!rproc_base || !rproc_size) {
> > + pr_err("%s: 'rproc_mem=nn at address' badly specified\n"
> > + " 'nn' and 'address' must both be non-zero\n",
> > + __func__);
> > +
> > + return;
> > + }
> > +
> > + pr_info("%s: reserving 0x%lx @ 0x%lx...\n",
> > + __func__, rproc_size, (unsigned long)rproc_base);
> > +
> > + ret = dma_declare_contiguous(&da8xx_dsp.dev, rproc_size,
> rproc_base, 0);
> > + if (ret)
> > + pr_err("%s: dma_declare_contiguous failed %d\n", __func__,
> ret);
> > +}
> > +
> > +#else
> > +
> > +void __init da8xx_rproc_reserve_cma(void)
> > +{
> > +}
> > +
> > +#endif
> > +
> > +int __init da8xx_register_rproc(void)
> > +{
> > + int ret;
> > +
> > + ret = platform_device_register(&da8xx_dsp);
> > + if (ret) {
> > + pr_err("%s: platform_device_register: %d\n", __func__,
> ret);
> > +
> > + return ret;
> > + }
> > +
> > + return 0;
> > +};
> > +
> > static struct resource da8xx_rtc_resources[] = {
> > {
> > .start = DA8XX_RTC_BASE,
> > diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
> b/arch/arm/mach-davinci/include/mach/da8xx.h
> > index 700d311..e9295bd 100644
> > --- a/arch/arm/mach-davinci/include/mach/da8xx.h
> > +++ b/arch/arm/mach-davinci/include/mach/da8xx.h
> > @@ -54,6 +54,7 @@ extern unsigned int da850_max_speed;
> > #define DA8XX_SYSCFG0_BASE (IO_PHYS + 0x14000)
> > #define DA8XX_SYSCFG0_VIRT(x) (da8xx_syscfg0_base + (x))
> > #define DA8XX_JTAG_ID_REG 0x18
> > +#define DA8XX_HOST1CFG_REG 0x44
> > #define DA8XX_CFGCHIP0_REG 0x17c
> > #define DA8XX_CFGCHIP2_REG 0x184
> > #define DA8XX_CFGCHIP3_REG 0x188
> > @@ -105,6 +106,9 @@ int __init da850_register_vpif_display
> > int __init da850_register_vpif_capture
> > (struct vpif_capture_config *capture_config);
> > void da8xx_restart(char mode, const char *cmd);
> > +void __init da8xx_rproc_reserve_cma(void);
>
> No need of __init qualifier in function prototypes.
>
> The patch looks good to me otherwise, but I will not apply it right
> away
> and instead wait for the driver to get accepted first.
Sounds like a plan.
Thanks & Regards,
- Rob
>
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH] ARM: shmobile: ipmmu: Add basic PMB support
From: Damian Hobson-Garcia @ 2013-01-22 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1788080.QuLk5ExqBm@avalon>
Hi Laurent,
Thanks for your comments.
On 2013/01/21 22:12, Laurent Pinchart wrote:
> Hi Damian,
>
> Thank you for the patch.
>
> On Friday 18 January 2013 15:35:10 Damian Hobson-Garcia wrote:
>> The PMB can be used to remap 16, 64, 128 or 512 MiB pages from
>> the 0x80000000-0xffffffff address range to anywhere in the
>> 0x00000000-0x7fffffff range.
>
> Isn't it 0x80000000 - 0xbfffffff to 0x00000000 - 0xffffffff ?
Yes, looking again at the spec, your values are the correct ones.
>
>> It also has the ability to perform tiled-linear address translation,
>> which can be used to access a memory buffer as a series of n x m tiles,
>> useful for image encoding/decoding.
>> Currently only the userspace API via character device is supported.
>
> If I understand this correctly, you're allowing userspace to remap a virtual
> address block to a physical address block without performing any sanity check.
> Isn't that a major security issue ?
No, not really. The PMB will only remap physical addresses, not virtual
addresses. Moreover, the remapped address is only accessible from the
IP blocks which are on the ICB bus, not the CPU. I will update the
comment to mention this. These IP blocks already have access to the
entire physical memory address space, so I don't think that adding the
the PMB into mix introduces any new security issues.
...
>
>> +
>> +#define PMB_DEVICE_NAME "pmb"
>> +
>> +#define PMB_NR 16
>> +/* the smallest size that can be reserverd in the pmb */
>> +#define PMB_GRANULARITY (16 << 20)
>> +#define PMB_START_ADDR 0x80000000
>> +#define PMB_SIZE 0x40000000
>> +#define NUM_BITS(x) ((x) / PMB_GRANULARITY)
>> +#define NR_BITMAPS ((NUM_BITS(PMB_SIZE) + BITS_PER_LONG - 1) \
>> + >> ilog2(BITS_PER_LONG))
>
> Does ilog2(BITS_PER_LONG) resolve to a compile-time constant ?
Yes it does.
Thanks for your other comments too. I'll look into making those changes.
Damian
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Paul Walmsley @ 2013-01-22 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87boci9str.fsf@dell.be.48ers.dk>
Hi guys,
Regarding the AM33xx test failures with appended DTBs, it would be very
helpful if especially the TI people could try reproducing the problem.
Otherwise it's going to cause problems with merging any new AM33xx
patches, since I won't be able to test them without additional work.
Plus, this is something that used to work up until d01e4afd, so something
isn't right.
You'll need to use the bootloader that TI originally shipped with the
BeagleBones:
U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)
This is because many folks don't replace their bootloader. I do plan to
add a test with a recent version of u-boot, but the kernel should not be
dependent on the bootloader in any way to work correctly. If it is, then
we need to document what u-boot version the kernel started to work with.
The Kconfig that I use is here:
http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only
It's possible that there's something wrong with the Kconfig. It's
basically just omap2plus_defconfig, but with all OMAP support for
non-AM33xx turned off, and with the appended DTB and ATAG compatibility
options turned on.
Let's try to do this ASAP. That way, if it's some bootloader dependency
or bug in the kernel, some fix can be merged during the v3.8-rc series,
which is rapidly drawing to a close.
- Paul
^ permalink raw reply
* [PATCH] mfd: remove redundant devm_* for 88pm80x PMIC
From: Yi Zhang @ 2013-01-22 2:23 UTC (permalink / raw)
To: linux-arm-kernel
devm_* functions are device managed and make error handling
and code simpler; it also fix error exit paths
Signed-off-by: Yi Zhang <yizhang@marvell.com>
---
drivers/mfd/88pm800.c | 10 +++-------
drivers/mfd/88pm805.c | 4 ++--
drivers/mfd/88pm80x.c | 22 ++++------------------
include/linux/mfd/88pm80x.h | 2 +-
4 files changed, 10 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 391e23e..582bda5 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -531,7 +531,7 @@ static int pm800_probe(struct i2c_client *client,
ret = device_800_init(chip, pdata);
if (ret) {
dev_err(chip->dev, "%s id 0x%x failed!\n", __func__, chip->id);
- goto err_800_init;
+ goto err_subchip_alloc;
}
ret = pm800_pages_init(chip);
@@ -546,10 +546,8 @@ static int pm800_probe(struct i2c_client *client,
err_page_init:
mfd_remove_devices(chip->dev);
device_irq_exit_800(chip);
-err_800_init:
- devm_kfree(&client->dev, subchip);
err_subchip_alloc:
- pm80x_deinit(client);
+ pm80x_deinit();
out_init:
return ret;
}
@@ -562,9 +560,7 @@ static int pm800_remove(struct i2c_client *client)
device_irq_exit_800(chip);
pm800_pages_exit(chip);
- devm_kfree(&client->dev, chip->subchip);
-
- pm80x_deinit(client);
+ pm80x_deinit();
return 0;
}
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index e671230..65d7ac0 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -257,7 +257,7 @@ static int pm805_probe(struct i2c_client *client,
pdata->plat_config(chip, pdata);
err_805_init:
- pm80x_deinit(client);
+ pm80x_deinit();
out_init:
return ret;
}
@@ -269,7 +269,7 @@ static int pm805_remove(struct i2c_client *client)
mfd_remove_devices(chip->dev);
device_irq_exit_805(chip);
- pm80x_deinit(client);
+ pm80x_deinit();
return 0;
}
diff --git a/drivers/mfd/88pm80x.c b/drivers/mfd/88pm80x.c
index 1adb355..f736a46 100644
--- a/drivers/mfd/88pm80x.c
+++ b/drivers/mfd/88pm80x.c
@@ -48,14 +48,12 @@ int pm80x_init(struct i2c_client *client,
ret = PTR_ERR(map);
dev_err(&client->dev, "Failed to allocate register map: %d\n",
ret);
- goto err_regmap_init;
+ return ret;
}
chip->id = id->driver_data;
- if (chip->id < CHIP_PM800 || chip->id > CHIP_PM805) {
- ret = -EINVAL;
- goto err_chip_id;
- }
+ if (chip->id < CHIP_PM800 || chip->id > CHIP_PM805)
+ return -EINVAL;
chip->client = client;
chip->regmap = map;
@@ -82,19 +80,11 @@ int pm80x_init(struct i2c_client *client,
}
return 0;
-
-err_chip_id:
- regmap_exit(map);
-err_regmap_init:
- devm_kfree(&client->dev, chip);
- return ret;
}
EXPORT_SYMBOL_GPL(pm80x_init);
-int pm80x_deinit(struct i2c_client *client)
+int pm80x_deinit(void)
{
- struct pm80x_chip *chip = i2c_get_clientdata(client);
-
/*
* workaround: clear the dependency between pm800 and pm805.
* would remove it after HW chip fixes the issue.
@@ -103,10 +93,6 @@ int pm80x_deinit(struct i2c_client *client)
g_pm80x_chip->companion = NULL;
else
g_pm80x_chip = NULL;
-
- regmap_exit(chip->regmap);
- devm_kfree(&client->dev, chip);
-
return 0;
}
EXPORT_SYMBOL_GPL(pm80x_deinit);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 478672e..e94537b 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -365,5 +365,5 @@ static inline int pm80x_dev_resume(struct device *dev)
extern int pm80x_init(struct i2c_client *client,
const struct i2c_device_id *id);
-extern int pm80x_deinit(struct i2c_client *client);
+extern int pm80x_deinit(void);
#endif /* __LINUX_MFD_88PM80X_H */
--
1.7.0.4
^ permalink raw reply related
* One of these things (CONFIG_HZ) is not like the others..
From: Matt Sealey @ 2013-01-22 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FDEBF8.3090902@linaro.org>
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
On Mon, Jan 21, 2013 at 7:31 PM, John Stultz <john.stultz@linaro.org> wrote:
> On 01/21/2013 05:06 PM, Matt Sealey wrote:
>>
>> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz <john.stultz@linaro.org>
>> wrote:
>>>
>>> On 01/21/2013 02:54 PM, Matt Sealey wrote:
>>>>
>>>> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz <john.stultz@linaro.org>
>>>> wrote:
>>>>>
>>>>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>>>
>>> As far as jiffies rating, from jiffies.c:
>>> .rating = 1, /* lowest valid rating*/
>>>
>>> So I'm not sure what you mean by "the debug on the kernel log is telling
>>> me
>>> it has a higher resolution".
>>
>> Oh, it is just if I actually don't run setup_sched_clock on my
>> platform, it gives a little message (with #define DEBUG 1 in
>> sched_clock.c) about who setup the last sched_clock. Since you only
>> get one chance, and I was fiddling with setup_sched_clock being probed
>> from multiple possible timers from device tree (i.MX3 has a crapload
>> of valid timers, which one you use right now is basically forced by
>> the not-quite-fully-DT-only code and some funky iomap tricks).
>>
>> And what I got was, if I use the real hardware timer, it runs at 66MHz
>> and says it has 15ns resolution and wraps every 500 seconds or so. The
>> jiffies timer says it's 750MHz, with a 2ns resoluton.. you get the
>> drift. The generic reporting of how "good" the sched_clock source is
>> kind of glosses over the quality rating of the clock source and at
>> first glance (if you're not paying that much attention), it is a
>> little bit misleading..
>
>
> I've got no clue on this. sched_clock is arch specific, and while ARM does
> use clocksources for sched_clock, what you're seeing is a detail of the ARM
> implementation and not the clocksource code (one complication is that
> clocksources rating values are for the requirements of timekeeping, which
> are different then the requirements for sched_clock - so the confusion is
> understandable).
>
>
>
>>> Yes, in the case I was remembering, the 60HZ was driven by the electrical
>>> line.
>>
>> While I have your attention, what would be the minimum "good" speed to
>> run the sched_clock or delay timer implementation from? My rudimentary
>> scribblings in my notebook give me a value of "don't bother" with less
>> than 10KHz based on HZ=100, so I'm wondering if a direct 32.768KHz
>> clock would do (i.MX osc clock input if I can supply it to one of the
>> above myriad timers) since this would be low-power compared to a 66MHz
>> one (by a couple mA anyway). I also have a bunch of questions about
>> the delay timer requirements.. I might mail you personally.. or would
>> you prefer on-list?
>
> So there are probably other folks who could better comment on sched_clock()
> or the delay timer (I'm guessing the delay() implementation is what you mean
> by that) design trade-offs.
I'm specifically talking about if I do
static struct delay_timer imx_gpt_delay_timer = {
.read_current_timer = imx_gpt_read_current_timer,
};
and then something like:
imx_gpt_delay_timer.freq = clk_get_rate(clk_per);
register_current_timer_delay(&imx_gpt_delay_timer);
In the sense that now (as of kernel 3.7 iirc), I have an ability to
have the delay implementation use this awesome fast accessor (which is
nothing to do with a 'clocksource' as in the subsystem..) to get to my
(here at least) 66.5MHz counter (up or down, i.MX has both, but I
dunno if you can use a down counter for delay_timer, or if that's
preferred, or what.. there are no examples of it.. but it seems to
work.. that said I can't imagine what would be an immediately visible
and not totally random effect of doing it "wrong", maybe that delays
are instantly returned, that could be very hard or impossible to ever
notice compared to not being able to browse the internet on the target
device.. it might pop up on some randomly-not-resetting platform
device or so, though..)
And I can also put sched_clock on a completely different timer. Does
that make any sense at all? I wouldn't know, it's not documented.
And if I wanted to I could register 8 more timers. That seems rather
excessive, but the ability to use those extra 8 as clock outputs from
the SoC or otherwise directly use comparators is useful to some
people, does Linux in general really give a damn about having 8 timers
of the same quality being available when most systems barely have two
clocksources anyway (on x86, tsc and hpet - on ARM I guess twd and
some SoC-specific timer). I dunno how many people might actually want
to define in a device tree, but I figure every single one is not a bad
thing and which ones end up as sched_clock, delay_timer or just plain
registered clocksources, or not registered as a clocksource and
accessed as some kind of comparator through some kooky ioctl API, is
something you would also configure...
> But again, someone more familiar with the scheduler and driver requirements
> would probably be more informational.
Okay. I assume that's a combination of Russell and Thomas..
--
Matt Sealey
^ permalink raw reply
* [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Tivy, Robert @ 2013-01-22 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FCD463.5000006@ti.com>
> -----Original Message-----
> From: Nori, Sekhar
> Sent: Sunday, January 20, 2013 9:39 PM
>
> On 1/11/2013 5:53 AM, Robert Tivy wrote:
> > Adding a remoteproc driver implementation for OMAP-L138 DSP
> >
> > Signed-off-by: Robert Tivy <rtivy@ti.com>
> > ---
> > drivers/remoteproc/Kconfig | 23 ++
> > drivers/remoteproc/Makefile | 1 +
> > drivers/remoteproc/davinci_remoteproc.c | 307
> ++++++++++++++++++++++++
> > include/linux/platform_data/da8xx-remoteproc.h | 33 +++
>
> naming the driver davinci_remoteproc.c and platform data as
> da8xx-remoteproc.h is odd. The driver looks really specific to omap-
> l138
> so may be call the driver da8xx-remoteproc.c?
At first when I started working on this stuff we intended to unify this naming, to either "davinci"-based or "da8xx"-based, but after looking at it for a while we realized that it is already so hopelessly mixed in many areas that it wasn't worth the effort.
But for new stuff that's directly tied to omap-l138 we should be consistent, so I agree. I'll change it to da8xx-remoteproc.c, at the same time changing all the code/data names to be prefixed with "da8xx_".
>
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 96ce101..7d3a5e0 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -41,4 +41,27 @@ config STE_MODEM_RPROC
> > This can be either built-in or a loadable module.
> > If unsure say N.
> >
> > +config DAVINCI_REMOTEPROC
> > + tristate "DaVinci DA850/OMAPL138 remoteproc support
> (EXPERIMENTAL)"
> > + depends on ARCH_DAVINCI_DA850
> > + select REMOTEPROC
> > + select RPMSG
> > + select FW_LOADER
> > + select CMA
> > + default n
> > + help
> > + Say y here to support DaVinci DA850/OMAPL138 remote processors
> > + via the remote processor framework.
> > +
> > + You want to say y here in order to enable AMP
> > + use-cases to run on your platform (multimedia codecs are
> > + offloaded to remote DSP processors using this framework).
> > +
> > + It's safe to say n here if you're not interested in multimedia
> > + offloading or just want a bare minimum kernel.
>
> > + This feature is considered EXPERIMENTAL, due to it not having
> > + any previous exposure to the general public and therefore
> > + limited developer-based testing.
>
> This is probably true in general for remoteproc (I am being warned a
> lot
> by the framework when using it) so may be you can drop this specific
> reference.
OK, we'll let the overlying REMOTEPROC EXPERIMENTAL status preside.
>
> > diff --git a/drivers/remoteproc/davinci_remoteproc.c
> b/drivers/remoteproc/davinci_remoteproc.c
> > new file mode 100644
> > index 0000000..fc6fd72
> > --- /dev/null
> > +++ b/drivers/remoteproc/davinci_remoteproc.c
> > @@ -0,0 +1,307 @@
> > +/*
> > + * Remote processor machine-specific module for Davinci
> > + *
> > + * Copyright (C) 2011-2012 Texas Instruments, Inc.
>
> 2013?
Yep.
>
> > + *
> > + * 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.
> > + */
> > +
> > +#define pr_fmt(fmt) "%s: " fmt, __func__
>
> You dont seem to be using this anywhere.
Will remove.
>
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/err.h>
> > +#include <linux/printk.h>
> > +#include <linux/bitops.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +#include <linux/platform_data/da8xx-remoteproc.h>
> > +#include <linux/clk.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
>
> It will be nice to keep this sorted. It avoids duplicate includes
> later.
OK
>
> > +static char *fw_name;
> > +module_param(fw_name, charp, S_IRUGO);
> > +MODULE_PARM_DESC(fw_name, "\n\t\tName of DSP firmware file in
> /lib/firmware");
> > +
> > +/*
> > + * OMAP-L138 Technical References:
> > + * http://www.ti.com/product/omap-l138
> > + */
> > +#define SYSCFG_CHIPSIG_OFFSET 0x174
> > +#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178
> > +#define SYSCFG_CHIPINT0 (1 << 0)
> > +#define SYSCFG_CHIPINT1 (1 << 1)
> > +#define SYSCFG_CHIPINT2 (1 << 2)
> > +#define SYSCFG_CHIPINT3 (1 << 3)
>
> You can use BIT(x) here.
Will do.
>
> > +
> > +/**
> > + * struct davinci_rproc - davinci remote processor state
> > + * @rproc: rproc handle
> > + */
> > +struct davinci_rproc {
> > + struct rproc *rproc;
> > + struct clk *dsp_clk;
> > +};
> > +
> > +static void __iomem *syscfg0_base;
> > +static struct platform_device *remoteprocdev;
> > +static struct irq_data *irq_data;
> > +static void (*ack_fxn)(struct irq_data *data);
> > +static int irq;
> > +
> > +/**
> > + * handle_event() - inbound virtqueue message workqueue function
> > + *
> > + * This funciton is registered as a kernel thread and is scheduled
> by the
> > + * kernel handler.
> > + */
> > +static irqreturn_t handle_event(int irq, void *p)
> > +{
> > + struct rproc *rproc = platform_get_drvdata(remoteprocdev);
> > +
> > + /* Process incoming buffers on our vring */
> > + while (IRQ_HANDLED == rproc_vq_interrupt(rproc, 0))
> > + ;
> > +
> > + /* Must allow wakeup of potenitally blocking senders: */
> > + rproc_vq_interrupt(rproc, 1);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +/**
> > + * davinci_rproc_callback() - inbound virtqueue message handler
> > + *
> > + * This handler is invoked directly by the kernel whenever the
> remote
> > + * core (DSP) has modified the state of a virtqueue. There is no
> > + * "payload" message indicating the virtqueue index as is the case
> with
> > + * mailbox-based implementations on OMAP4. As such, this handler
> "polls"
> > + * each known virtqueue index for every invocation.
> > + */
> > +static irqreturn_t davinci_rproc_callback(int irq, void *p)
> > +{
> > + if (readl(syscfg0_base + SYSCFG_CHIPSIG_OFFSET) &
> SYSCFG_CHIPINT0) {
>
> personally I think using a variable to read the register and then
> testing its value inside if() is more readable.
Agreed.
>
> > + /* Clear interrupt level source */
> > + writel(SYSCFG_CHIPINT0,
> > + syscfg0_base + SYSCFG_CHIPSIG_CLR_OFFSET);
> > +
> > + /*
> > + * ACK intr to AINTC.
> > + *
> > + * It has already been ack'ed by the kernel before calling
> > + * this function, but since the ARM<->DSP interrupts in the
> > + * CHIPSIG register are "level" instead of "pulse" variety,
> > + * we need to ack it after taking down the level else we'll
> > + * be called again immediately after returning.
> > + */
> > + ack_fxn(irq_data);
>
> Don't really like interrupt controller functions being invoked like
> this
> but I don't understand the underlying issue well enough to suggest an
> alternate.
I've looked for an alternative with no success, but will start a discussion in earnest after tackling this initial commit.
>
> > +
> > + return IRQ_WAKE_THREAD;
> > + }
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int davinci_rproc_start(struct rproc *rproc)
> > +{
> > + struct platform_device *pdev = to_platform_device(rproc-
> >dev.parent);
> > + struct device *dev = rproc->dev.parent;
> > + struct davinci_rproc *drproc = rproc->priv;
> > + struct clk *dsp_clk;
> > + struct resource *r;
> > + unsigned long host1cfg_physaddr;
> > + unsigned int host1cfg_offset;
> > + int ret;
> > +
> > + remoteprocdev = pdev;
> > +
> > + /* hw requires the start (boot) address be on 1KB boundary */
> > + if (rproc->bootaddr & 0x3ff) {
> > + dev_err(dev, "invalid boot address: must be aligned to
> 1KB\n");
> > +
> > + return -EINVAL;
> > + }
> > +
> > + r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> Along with moving this to probe as Ohad requested, you can use
> devm_request_and_ioremap() to simplify the error paths here. Have a
> look
> at: Documentation/driver-model/devres.txt
So it seems that I should also use devm_request_threaded_irq()?
In general, should I always use the "devm_*" APIs when available?
>
> > + if (IS_ERR_OR_NULL(r)) {
> > + dev_err(dev, "platform_get_resource() error: %ld\n",
> > + PTR_ERR(r));
> > +
> > + return PTR_ERR(r);
> > + }
> > + host1cfg_physaddr = (unsigned long)r->start;
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(dev, "platform_get_irq(pdev, 0) error: %d\n", irq);
> > +
> > + return irq;
> > + }
> > +
> > + irq_data = irq_get_irq_data(irq);
> > + if (IS_ERR_OR_NULL(irq_data)) {
> > + dev_err(dev, "irq_get_irq_data(%d) error: %ld\n",
> > + irq, PTR_ERR(irq_data));
> > +
> > + return PTR_ERR(irq_data);
> > + }
> > + ack_fxn = irq_data->chip->irq_ack;
> > +
> > + ret = request_threaded_irq(irq, davinci_rproc_callback,
> handle_event,
> > + 0, "davinci-remoteproc", drproc);
> > + if (ret) {
> > + dev_err(dev, "request_threaded_irq error: %d\n", ret);
> > +
> > + return ret;
> > + }
> > +
> > + syscfg0_base = ioremap(host1cfg_physaddr & PAGE_MASK, SZ_4K);
> > + host1cfg_offset = offset_in_page(host1cfg_physaddr);
> > + writel(rproc->bootaddr, syscfg0_base + host1cfg_offset);
> > +
> > + dsp_clk = clk_get(dev, NULL);
>
> devm_clk_get() here.
OK.
>
> > + if (IS_ERR_OR_NULL(dsp_clk)) {
> > + dev_err(dev, "clk_get error: %ld\n", PTR_ERR(dsp_clk));
> > + ret = PTR_ERR(dsp_clk);
> > + goto fail;
> > + }
> > + clk_enable(dsp_clk);
> > + davinci_clk_reset_deassert(dsp_clk);
> > +
> > + drproc->dsp_clk = dsp_clk;
> > +
> > + return 0;
> > +fail:
> > + free_irq(irq, drproc);
> > + iounmap(syscfg0_base);
> > +
> > + return ret;
> > +}
> > +
> > +static int davinci_rproc_stop(struct rproc *rproc)
> > +{
> > + struct davinci_rproc *drproc = rproc->priv;
> > + struct clk *dsp_clk = drproc->dsp_clk;
> > +
> > + clk_disable(dsp_clk);
> > + clk_put(dsp_clk);
> > + iounmap(syscfg0_base);
> > + free_irq(irq, drproc);
> > +
> > + return 0;
> > +}
> > +
> > +/* kick a virtqueue */
> > +static void davinci_rproc_kick(struct rproc *rproc, int vqid)
> > +{
> > + int timed_out;
> > + unsigned long timeout;
> > +
> > + timed_out = 0;
> > + timeout = jiffies + HZ/100;
> > +
> > + /* Poll for ack from other side first */
> > + while (readl(syscfg0_base + SYSCFG_CHIPSIG_OFFSET) &
> > + SYSCFG_CHIPINT2)
>
> If there is a context switch here long enough ..
>
> > + if (time_after(jiffies, timeout)) {
>
>
> .. then time_after() might return true and you will erroneously report
> a
> timeout even though hardware is working perfectly fine.
I will probably drop the whole check completely.
Otherwise I'll add another check after detecting timeout.
Thanks & Regards,
- Rob
>
> Thanks,
> Sekhar
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Matt Sealey @ 2013-01-22 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122011808.GF23505@n2100.arm.linux.org.uk>
On Mon, Jan 21, 2013 at 7:18 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 21, 2013 at 07:06:59PM -0600, Matt Sealey wrote:
>> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz <john.stultz@linaro.org> wrote:
>> > On 01/21/2013 02:54 PM, Matt Sealey wrote:
>
> sched_clock() has nothing to do with time keeping, and that
> HZ/NO_HZ/HRTIMERS don't affect it (when it isn't being derived from
> jiffies).
>
> Now, sched_clock() is there to give the scheduler a _fast_ to access,
> higher resolution clock than is available from other sources, so that
> there's ways of accurately measuring the amount of time processes run
> for,
That depends on what you meant by timekeeping, right?
I'm really not concerned about the wallclock time, more about the
accuracy of the scheduler clock (tick?), preemption, accurate delays
(i.e. if I msleep(10) does it delay for 10ms or for 40ms because my
delay timer is inaccurate? I'd rather it was better but closer to
10ms), and whether the scheduler (the thing that tells my userspace
whether firefox is running now, or totem, or any other task) is using
the correct high resolution periodic, oneshot, repeatable (however it
repeats) timers *properly* given that this magic config item is
missing on ARM.
That magic config item being CONFIG_SCHED_HRTICK which is referenced a
bunch in kernel/sched/*.[ch] but *ONLY* defined as a Kconfig item in
kernel/Kconfig.hz.
Do we need to copy that Kconfig item out to arch/arm/Kconfig, that's
the question?
> and other such measurements - and it uses that to determine how
> to schedule a particular task and when to preempt it.
>
> Not providing it means you get those measurements at HZ-based resolution,
> which is suboptimal for tasks which run often for sub-HZ periods (which
> can end up accumulating zero run time.)
Okay, and John said earlier:
John Stultz:
> So I'm actually not super familiar with SCHED_HRTICK details, but from my
> brief skim of it it looks like its useful for turning off the periodic timer
> tick, and allowing the scheduler tick to be triggered by an hrtimer itself
> (There's a number of these interesting inversions that go on in switching to
> HRT mode - for instance, standard timer ticks are switched to being hrtimer
> events themselves).
>
> This likely has the benefit of time-accurate preemption (well, long term, as
> if the timer granularity isn't matching you could be delayed up to a tick -
> but it wouldn't drift).
>
> I'm guessing Thomas would probably know best what the potential issues would
> be from running ((CONFIG_HRTIMER || CONFIG_NO_HZ) && !CONFIG_SCHED_HRTICK).
If SCHED_HRTICK isn't enabled but setup_sched_clock has been given an
accessor for a real, hardware, fast, high resolution counter that
meets all the needs of sched_clock, what's going on? If it's enabled,
what extra is it doing that, say, my_plat_read_sched_clock doesn't?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
From: Kukjin Kim @ 2013-01-22 1:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Thomas Abraham <thomas.ab@samsung.com>
Need to be changed requirements in the 'cpus' node for exynos5440
to specify all the per-cpu interrupts of arch timer.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/boot/dts/exynos5440.dtsi | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 5406689..c5bd8ed 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -28,7 +28,10 @@
compatible = "arm,cortex-a15";
timer {
compatible = "arm,armv7-timer";
- interrupts = <1 13 0xf08>;
+ interrupts = <1 13 0xf08>,
+ <1 14 0xf08>,
+ <1 11 0xf08>,
+ <1 10 0xf08>;
clock-frequency = <1000000>;
};
};
@@ -36,7 +39,10 @@
compatible = "arm,cortex-a15";
timer {
compatible = "arm,armv7-timer";
- interrupts = <1 14 0xf08>;
+ interrupts = <1 13 0xf08>;
+ <1 14 0xf08>,
+ <1 11 0xf08>,
+ <1 10 0xf08>;
clock-frequency = <1000000>;
};
};
@@ -44,7 +50,10 @@
compatible = "arm,cortex-a15";
timer {
compatible = "arm,armv7-timer";
- interrupts = <1 14 0xf08>;
+ interrupts = <1 13 0xf08>;
+ <1 14 0xf08>,
+ <1 11 0xf08>,
+ <1 10 0xf08>;
clock-frequency = <1000000>;
};
};
@@ -52,7 +61,10 @@
compatible = "arm,cortex-a15";
timer {
compatible = "arm,armv7-timer";
- interrupts = <1 14 0xf08>;
+ interrupts = <1 13 0xf08>;
+ <1 14 0xf08>,
+ <1 11 0xf08>,
+ <1 10 0xf08>;
clock-frequency = <1000000>;
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Daniel Mack @ 2013-01-22 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121183348.GI22517@atomide.com>
Hi Tony, Mark, Ezequiel,
Tony Lindgren <tony@atomide.com> wrote:
>* Ezequiel Garcia <elezegarcia@gmail.com> [130121 09:00]:
>> Hi Mark,
>>
>> On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland <mark.rutland@arm.com>
>wrote:
>> > [...]
>> >
>> >> diff --git a/arch/arm/mach-omap2/gpmc.c
>b/arch/arm/mach-omap2/gpmc.c
>> >> index 01ce462..f7de9eb 100644
>> >> --- a/arch/arm/mach-omap2/gpmc.c
>> >> +++ b/arch/arm/mach-omap2/gpmc.c
>> >> @@ -39,6 +39,7 @@
>> >> #include "omap_device.h"
>> >> #include "gpmc.h"
>> >> #include "gpmc-nand.h"
>> >> +#include "gpmc-onenand.h"
>> >>
>> >> #define DEVICE_NAME "omap-gpmc"
>> >>
>> >> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
>platform_device *pdev,
>> >> }
>> >> #endif
>> >>
>> >> +#ifdef CONFIG_MTD_ONENAND
>> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> >> + struct device_node *child)
>> >> +{
>> >> + u32 val;
>> >> + struct omap_onenand_platform_data *gpmc_onenand_data;
>> >> +
>> >> + if (of_property_read_u32(child, "reg", &val) < 0) {
>> >> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> >> + child->full_name);
>> >> + return -ENODEV;
>> >> + }
>> >> +
>> >> + gpmc_onenand_data = devm_kzalloc(&pdev->dev,
>sizeof(*gpmc_onenand_data),
>> >> + GFP_KERNEL);
>> >> + if (!gpmc_onenand_data)
>> >> + return -ENOMEM;
>> >> +
>> >> + gpmc_onenand_data->cs = val;
>> >> + gpmc_onenand_data->of_node = child;
>> >> + gpmc_onenand_data->dma_channel = -1;
>> >> +
>> >> + if (!of_property_read_u32(child, "dma-channel", &val))
>> >> + gpmc_onenand_data->dma_channel = val;
>> >> +
>> >> + gpmc_onenand_init(gpmc_onenand_data);
>> >> +
>> >> + return 0;
>> >> +}
>> >> +#else
>> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> >> + struct device_node *child)
>> >> +{
>> >> + return 0;
>> >> +}
>> >> +#endif
>> >> +
>> >> static int gpmc_probe_dt(struct platform_device *pdev)
>> >> {
>> >> int ret;
>> >> @@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct
>platform_device *pdev)
>> >> return ret;
>> >> }
>> >>
>> >
>> > This doesn't look right to me:
>> >
>> >> + for_each_node_by_name(child, "onenand") {
>> >> + ret = gpmc_probe_onenand_child(pdev, child);
>> >> + of_node_put(child);
>> >> + if (ret < 0)
>> >> + return ret;
>> >> + }
>> >
>> > for_each_node_by_name automatically calls of_node_put on each node
>once passed,
>> > and as far as I can tell, gpmc_probe_onenand_child doesn't do
>anything that'd
>> > increment a node's refcount.
>> >
>> > As far as I can see, you only need the of_node_put in the error
>case:
>> >
>> > for_each_node_by_name(child, "onenand") {
>> > ret = gpmc_probe_onenand_child(pdev, child);
>> > if (ret < 0) {
>> > of_node_put(child);
>> > return ret;
>> > }
>> > }
>> >
>> > Have I missed something here?
>> >
>>
>> Mmm... perhaps I've overlooked that code.
>>
>> After some digging through source and reading for_each_node_by_name()
>> it seems to me you're right.
>>
>> @Daniel: It seems this would also apply to the NAND binding.
>> What do you think?
>
>Would prefer this done as a fix against the omap-for-v3.9/gpmc
>branch before we apply Ezequiel's patches.
I'm currently far away from my computer and can't prepare a patch for this, sorry. But I think you are right, so please just submit a patch for that, anyone :-)
Best regards,
Daniel
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: John Stultz @ 2013-01-22 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1bkXx2qn+c6sKqXsty-aFe1r-W79uyem0O8p6JNeeq6zxQ@mail.gmail.com>
On 01/21/2013 05:06 PM, Matt Sealey wrote:
> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On 01/21/2013 02:54 PM, Matt Sealey wrote:
>>> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz <john.stultz@linaro.org>
>>> wrote:
>>>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>> As far as jiffies rating, from jiffies.c:
>> .rating = 1, /* lowest valid rating*/
>>
>> So I'm not sure what you mean by "the debug on the kernel log is telling me
>> it has a higher resolution".
> Oh, it is just if I actually don't run setup_sched_clock on my
> platform, it gives a little message (with #define DEBUG 1 in
> sched_clock.c) about who setup the last sched_clock. Since you only
> get one chance, and I was fiddling with setup_sched_clock being probed
> from multiple possible timers from device tree (i.MX3 has a crapload
> of valid timers, which one you use right now is basically forced by
> the not-quite-fully-DT-only code and some funky iomap tricks).
>
> And what I got was, if I use the real hardware timer, it runs at 66MHz
> and says it has 15ns resolution and wraps every 500 seconds or so. The
> jiffies timer says it's 750MHz, with a 2ns resoluton.. you get the
> drift. The generic reporting of how "good" the sched_clock source is
> kind of glosses over the quality rating of the clock source and at
> first glance (if you're not paying that much attention), it is a
> little bit misleading..
I've got no clue on this. sched_clock is arch specific, and while ARM
does use clocksources for sched_clock, what you're seeing is a detail of
the ARM implementation and not the clocksource code (one complication is
that clocksources rating values are for the requirements of timekeeping,
which are different then the requirements for sched_clock - so the
confusion is understandable).
>> Yes, in the case I was remembering, the 60HZ was driven by the electrical
>> line.
> While I have your attention, what would be the minimum "good" speed to
> run the sched_clock or delay timer implementation from? My rudimentary
> scribblings in my notebook give me a value of "don't bother" with less
> than 10KHz based on HZ=100, so I'm wondering if a direct 32.768KHz
> clock would do (i.MX osc clock input if I can supply it to one of the
> above myriad timers) since this would be low-power compared to a 66MHz
> one (by a couple mA anyway). I also have a bunch of questions about
> the delay timer requirements.. I might mail you personally.. or would
> you prefer on-list?
So there are probably other folks who could better comment on
sched_clock() or the delay timer (I'm guessing the delay()
implementation is what you mean by that) design trade-offs.
My first *guess* would be that for delay, you probably want a counter
that has half-usec granularity or finer (~5Mhz), since udelay is likely
the most common usage, and coarser then that and you might cause driver
issues. Though you could probably get away with a cpu loop based delay
and avoid requiring a high res counter.
For sched_clock(), the standard reply is probably "as fast and as
fine-graned as you can get". But as far as a lower-bound, I'd expect
the CONFIG_HZ value would be a good bet, as many systems use jiffies for
their sched_clock without major issue, though I'm sure there are
interactivity trade-offs.
But again, someone more familiar with the scheduler and driver
requirements would probably be more informational.
thanks
-john
^ permalink raw reply
* [PATCH 08/15] drm/exynos: fimd and ipp are broken on multiplatform
From: Inki Dae @ 2013-01-22 1:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-9-git-send-email-arnd@arndb.de>
Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.
Thanks,
Inki Dae
2013/1/22 Arnd Bergmann <arnd@arndb.de>:
> While the exynos DRM support in principle can work on
> multiplatform, the FIMD and IPP sections of it both
> include the plat/map-base.h header file, which is
> not available on multiplatform. Rather than disabling
> the entire driver, we can just conditionally build
> these two parts.
>
> Without this patch, building allyesconfig results in:
>
> drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory
> drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/exynos/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 1d1f1e5..046bcda 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -24,7 +24,7 @@ config DRM_EXYNOS_DMABUF
>
> config DRM_EXYNOS_FIMD
> bool "Exynos DRM FIMD"
> - depends on DRM_EXYNOS && !FB_S3C
> + depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
> help
> Choose this option if you want to use Exynos FIMD for DRM.
>
> @@ -48,7 +48,7 @@ config DRM_EXYNOS_G2D
>
> config DRM_EXYNOS_IPP
> bool "Exynos DRM IPP"
> - depends on DRM_EXYNOS
> + depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM
> help
> Choose this option if you want to use IPP feature for DRM.
>
> --
> 1.7.10.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Russell King - ARM Linux @ 2013-01-22 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1bkXx2qn+c6sKqXsty-aFe1r-W79uyem0O8p6JNeeq6zxQ@mail.gmail.com>
On Mon, Jan 21, 2013 at 07:06:59PM -0600, Matt Sealey wrote:
> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz <john.stultz@linaro.org> wrote:
> > On 01/21/2013 02:54 PM, Matt Sealey wrote:
> >>
> >> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz <john.stultz@linaro.org>
> >> wrote:
> >>>
> >>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
> >
> > As far as jiffies rating, from jiffies.c:
> > .rating = 1, /* lowest valid rating*/
> >
> > So I'm not sure what you mean by "the debug on the kernel log is telling me
> > it has a higher resolution".
>
> Oh, it is just if I actually don't run setup_sched_clock on my
> platform, it gives a little message (with #define DEBUG 1 in
> sched_clock.c)
sched_clock() has nothing to do with time keeping, and that
HZ/NO_HZ/HRTIMERS don't affect it (when it isn't being derived from
jiffies).
Now, sched_clock() is there to give the scheduler a _fast_ to access,
higher resolution clock than is available from other sources, so that
there's ways of accurately measuring the amount of time processes run
for, and other such measurements - and it uses that to determine how
to schedule a particular task and when to preempt it.
Not providing it means you get those measurements at HZ-based resolution,
which is suboptimal for tasks which run often for sub-HZ periods (which
can end up accumulating zero run time.)
^ permalink raw reply
* [PATCH 6/6] ARM: S3C24XX: Move mach-s3c2440/ pll into mach-s3c24xx/
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358817131-27169-1-git-send-email-kgene.kim@samsung.com>
This patch moves mach-s3c2440/pll into mach-s3c24xx/
and removes arch/arm/mach-s3c2440/ directory in kernel.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/Kconfig | 3 --
arch/arm/Makefile | 2 +-
arch/arm/mach-s3c2440/Kconfig | 29 --------------------
arch/arm/mach-s3c2440/Makefile | 13 ---------
arch/arm/mach-s3c24xx/Kconfig | 26 ++++++++++++++++++
arch/arm/mach-s3c24xx/Makefile | 2 ++
.../pll-s3c2440-12000000.c} | 5 +---
.../pll-s3c2440-16934400.c} | 5 +---
8 files changed, 31 insertions(+), 54 deletions(-)
delete mode 100644 arch/arm/mach-s3c2440/Kconfig
delete mode 100644 arch/arm/mach-s3c2440/Makefile
rename arch/arm/{mach-s3c2440/s3c2440-pll-12000000.c => mach-s3c24xx/pll-s3c2440-12000000.c} (98%)
rename arch/arm/{mach-s3c2440/s3c2440-pll-16934400.c => mach-s3c24xx/pll-s3c2440-16934400.c} (99%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5d566bf..f22c510 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1094,9 +1094,6 @@ source "arch/arm/mach-socfpga/Kconfig"
source "arch/arm/plat-spear/Kconfig"
source "arch/arm/mach-s3c24xx/Kconfig"
-if ARCH_S3C24XX
-source "arch/arm/mach-s3c2440/Kconfig"
-endif
if ARCH_S3C64XX
source "arch/arm/mach-s3c64xx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 29e8fae..0935dac 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -173,7 +173,7 @@ machine-$(CONFIG_ARCH_PRIMA2) += prima2
machine-$(CONFIG_ARCH_PXA) += pxa
machine-$(CONFIG_ARCH_REALVIEW) += realview
machine-$(CONFIG_ARCH_RPC) += rpc
-machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx s3c2440
+machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx
machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx
machine-$(CONFIG_ARCH_S5P64X0) += s5p64x0
machine-$(CONFIG_ARCH_S5PC100) += s5pc100
diff --git a/arch/arm/mach-s3c2440/Kconfig b/arch/arm/mach-s3c2440/Kconfig
deleted file mode 100644
index ad06fa2..0000000
--- a/arch/arm/mach-s3c2440/Kconfig
+++ /dev/null
@@ -1,29 +0,0 @@
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-config S3C2440_XTAL_12000000
- bool
- help
- Indicate that the build needs to support 12MHz system
- crystal.
-
-config S3C2440_XTAL_16934400
- bool
- help
- Indicate that the build needs to support 16.9344MHz system
- crystal.
-
-config S3C2440_PLL_12000000
- bool
- depends on S3C2440_CPUFREQ && S3C2440_XTAL_12000000
- default y if CPU_FREQ_S3C24XX_PLL
- help
- PLL tables for S3C2440 or S3C2442 CPUs with 12MHz crystals.
-
-config S3C2440_PLL_16934400
- bool
- depends on S3C2440_CPUFREQ && S3C2440_XTAL_16934400
- default y if CPU_FREQ_S3C24XX_PLL
- help
- PLL tables for S3C2440 or S3C2442 CPUs with 16.934MHz crystals.
diff --git a/arch/arm/mach-s3c2440/Makefile b/arch/arm/mach-s3c2440/Makefile
deleted file mode 100644
index d76e4b9..0000000
--- a/arch/arm/mach-s3c2440/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-# arch/arm/mach-s3c2440/Makefile
-#
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-obj-y :=
-obj-m :=
-obj-n :=
-obj- :=
-
-obj-$(CONFIG_S3C2440_PLL_12000000) += s3c2440-pll-12000000.o
-obj-$(CONFIG_S3C2440_PLL_16934400) += s3c2440-pll-16934400.o
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index edf6549..67df58b 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -400,6 +400,32 @@ config S3C2440_DMA
help
Support for S3C2440 specific DMA code5A
+config S3C2440_XTAL_12000000
+ bool
+ help
+ Indicate that the build needs to support 12MHz system
+ crystal.
+
+config S3C2440_XTAL_16934400
+ bool
+ help
+ Indicate that the build needs to support 16.9344MHz system
+ crystal.
+
+config S3C2440_PLL_12000000
+ bool
+ depends on S3C2440_CPUFREQ && S3C2440_XTAL_12000000
+ default y if CPU_FREQ_S3C24XX_PLL
+ help
+ PLL tables for S3C2440 or S3C2442 CPUs with 12MHz crystals.
+
+config S3C2440_PLL_16934400
+ bool
+ depends on S3C2440_CPUFREQ && S3C2440_XTAL_16934400
+ default y if CPU_FREQ_S3C24XX_PLL
+ help
+ PLL tables for S3C2440 or S3C2442 CPUs with 16.934MHz crystals.
+
comment "S3C2440 Boards"
#
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 6d4b9ad..08b87cd 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -36,6 +36,8 @@ obj-$(CONFIG_CPU_S3C2442) += s3c2442.o
obj-$(CONFIG_CPU_S3C244X) += s3c244x.o irq-s3c244x.o clock-s3c244x.o
obj-$(CONFIG_S3C2440_CPUFREQ) += cpufreq-s3c2440.o
obj-$(CONFIG_S3C2440_DMA) += dma-s3c2440.o
+obj-$(CONFIG_S3C2440_PLL_12000000) += pll-s3c2440-12000000.o
+obj-$(CONFIG_S3C2440_PLL_16934400) += pll-s3c2440-16934400.o
obj-$(CONFIG_CPU_S3C2443) += s3c2443.o irq-s3c2443.o clock-s3c2443.o
diff --git a/arch/arm/mach-s3c2440/s3c2440-pll-12000000.c b/arch/arm/mach-s3c24xx/pll-s3c2440-12000000.c
similarity index 98%
rename from arch/arm/mach-s3c2440/s3c2440-pll-12000000.c
rename to arch/arm/mach-s3c24xx/pll-s3c2440-12000000.c
index 551fb43..6737817 100644
--- a/arch/arm/mach-s3c2440/s3c2440-pll-12000000.c
+++ b/arch/arm/mach-s3c24xx/pll-s3c2440-12000000.c
@@ -1,5 +1,4 @@
-/* arch/arm/mach-s3c2440/s3c2440-pll-12000000.c
- *
+/*
* Copyright (c) 2006-2007 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
@@ -83,7 +82,6 @@ static int __init s3c2440_pll_12mhz(void)
return subsys_interface_register(&s3c2440_plls12_interface);
}
-
arch_initcall(s3c2440_pll_12mhz);
static struct subsys_interface s3c2442_plls12_interface = {
@@ -97,5 +95,4 @@ static int __init s3c2442_pll_12mhz(void)
return subsys_interface_register(&s3c2442_plls12_interface);
}
-
arch_initcall(s3c2442_pll_12mhz);
diff --git a/arch/arm/mach-s3c2440/s3c2440-pll-16934400.c b/arch/arm/mach-s3c24xx/pll-s3c2440-16934400.c
similarity index 99%
rename from arch/arm/mach-s3c2440/s3c2440-pll-16934400.c
rename to arch/arm/mach-s3c24xx/pll-s3c2440-16934400.c
index 3f15bcf..debfa10 100644
--- a/arch/arm/mach-s3c2440/s3c2440-pll-16934400.c
+++ b/arch/arm/mach-s3c24xx/pll-s3c2440-16934400.c
@@ -1,5 +1,4 @@
-/* arch/arm/mach-s3c2440/s3c2440-pll-16934400.c
- *
+/*
* Copyright (c) 2006-2008 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
@@ -111,7 +110,6 @@ static int __init s3c2440_pll_16934400(void)
{
return subsys_interface_register(&s3c2440_plls169344_interface);
}
-
arch_initcall(s3c2440_pll_16934400);
static struct subsys_interface s3c2442_plls169344_interface = {
@@ -124,5 +122,4 @@ static int __init s3c2442_pll_16934400(void)
{
return subsys_interface_register(&s3c2442_plls169344_interface);
}
-
arch_initcall(s3c2442_pll_16934400);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/6] ARM: S3C24XX: Move mach-s3c2440/ cpufreq driver into mach-s3c24xx/
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358817131-27169-1-git-send-email-kgene.kim@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/mach-s3c2440/Kconfig | 8 --------
arch/arm/mach-s3c2440/Makefile | 2 --
arch/arm/mach-s3c24xx/Kconfig | 8 ++++++++
arch/arm/mach-s3c24xx/Makefile | 1 +
.../s3c2440-cpufreq.c => mach-s3c24xx/cpufreq-s3c2440.c} | 4 +---
5 files changed, 10 insertions(+), 13 deletions(-)
rename arch/arm/{mach-s3c2440/s3c2440-cpufreq.c => mach-s3c24xx/cpufreq-s3c2440.c} (99%)
diff --git a/arch/arm/mach-s3c2440/Kconfig b/arch/arm/mach-s3c2440/Kconfig
index a4d7fd2..ad06fa2 100644
--- a/arch/arm/mach-s3c2440/Kconfig
+++ b/arch/arm/mach-s3c2440/Kconfig
@@ -2,14 +2,6 @@
#
# Licensed under GPLv2
-config S3C2440_CPUFREQ
- bool "S3C2440/S3C2442 CPU Frequency scaling support"
- depends on CPU_FREQ_S3C24XX && (CPU_S3C2440 || CPU_S3C2442)
- default y
- select S3C2410_CPUFREQ_UTILS
- help
- CPU Frequency scaling support for S3C2440 and S3C2442 SoC CPUs.
-
config S3C2440_XTAL_12000000
bool
help
diff --git a/arch/arm/mach-s3c2440/Makefile b/arch/arm/mach-s3c2440/Makefile
index 0ddd17f..d76e4b9 100644
--- a/arch/arm/mach-s3c2440/Makefile
+++ b/arch/arm/mach-s3c2440/Makefile
@@ -9,7 +9,5 @@ obj-m :=
obj-n :=
obj- :=
-obj-$(CONFIG_S3C2440_CPUFREQ) += s3c2440-cpufreq.o
-
obj-$(CONFIG_S3C2440_PLL_12000000) += s3c2440-pll-12000000.o
obj-$(CONFIG_S3C2440_PLL_16934400) += s3c2440-pll-16934400.o
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index f1d3951..edf6549 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -387,6 +387,14 @@ endif # CPU_S3C2416
if CPU_S3C2440
+config S3C2440_CPUFREQ
+ bool "S3C2440/S3C2442 CPU Frequency scaling support"
+ depends on CPU_FREQ_S3C24XX && (CPU_S3C2440 || CPU_S3C2442)
+ default y
+ select S3C2410_CPUFREQ_UTILS
+ help
+ CPU Frequency scaling support for S3C2440 and S3C2442 SoC CPUs.
+
config S3C2440_DMA
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 0f042d1..6d4b9ad 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_S3C2416_PM) += pm-s3c2416.o
obj-$(CONFIG_CPU_S3C2440) += s3c2440.o irq-s3c2440.o clock-s3c2440.o
obj-$(CONFIG_CPU_S3C2442) += s3c2442.o
obj-$(CONFIG_CPU_S3C244X) += s3c244x.o irq-s3c244x.o clock-s3c244x.o
+obj-$(CONFIG_S3C2440_CPUFREQ) += cpufreq-s3c2440.o
obj-$(CONFIG_S3C2440_DMA) += dma-s3c2440.o
obj-$(CONFIG_CPU_S3C2443) += s3c2443.o irq-s3c2443.o clock-s3c2443.o
diff --git a/arch/arm/mach-s3c2440/s3c2440-cpufreq.c b/arch/arm/mach-s3c24xx/cpufreq-s3c2440.c
similarity index 99%
rename from arch/arm/mach-s3c2440/s3c2440-cpufreq.c
rename to arch/arm/mach-s3c24xx/cpufreq-s3c2440.c
index 6177676..72b2cc8 100644
--- a/arch/arm/mach-s3c2440/s3c2440-cpufreq.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-s3c2440.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/s3c2440-cpufreq.c
- *
+/*
* Copyright (c) 2006-2009 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
@@ -310,5 +309,4 @@ static int s3c2442_cpufreq_init(void)
{
return subsys_interface_register(&s3c2442_cpufreq_interface);
}
-
subsys_initcall(s3c2442_cpufreq_init);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/6] ARM: S3C24XX: Move mach-s3c2412/ cpufreq driver into mach-s3c24xx/
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358817131-27169-1-git-send-email-kgene.kim@samsung.com>
This patch moves mach-s3c2412/cpufreq driver into mach-s3c24xx/
and removes arch/arm/mach-s3c2412/ directory in kernel.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/Kconfig | 1 -
arch/arm/Makefile | 2 +-
arch/arm/mach-s3c2412/Kconfig | 13 -------------
arch/arm/mach-s3c2412/Makefile | 12 ------------
arch/arm/mach-s3c24xx/Kconfig | 8 ++++++++
arch/arm/mach-s3c24xx/Makefile | 1 +
.../cpu-freq.c => mach-s3c24xx/cpufreq-s3c2412.c} | 6 ++----
7 files changed, 12 insertions(+), 31 deletions(-)
delete mode 100644 arch/arm/mach-s3c2412/Kconfig
delete mode 100644 arch/arm/mach-s3c2412/Makefile
rename arch/arm/{mach-s3c2412/cpu-freq.c => mach-s3c24xx/cpufreq-s3c2412.c} (99%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f95ba14..5d566bf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1095,7 +1095,6 @@ source "arch/arm/plat-spear/Kconfig"
source "arch/arm/mach-s3c24xx/Kconfig"
if ARCH_S3C24XX
-source "arch/arm/mach-s3c2412/Kconfig"
source "arch/arm/mach-s3c2440/Kconfig"
endif
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30c443c..29e8fae 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -173,7 +173,7 @@ machine-$(CONFIG_ARCH_PRIMA2) += prima2
machine-$(CONFIG_ARCH_PXA) += pxa
machine-$(CONFIG_ARCH_REALVIEW) += realview
machine-$(CONFIG_ARCH_RPC) += rpc
-machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx s3c2412 s3c2440
+machine-$(CONFIG_ARCH_S3C24XX) += s3c24xx s3c2440
machine-$(CONFIG_ARCH_S3C64XX) += s3c64xx
machine-$(CONFIG_ARCH_S5P64X0) += s5p64x0
machine-$(CONFIG_ARCH_S5PC100) += s5pc100
diff --git a/arch/arm/mach-s3c2412/Kconfig b/arch/arm/mach-s3c2412/Kconfig
deleted file mode 100644
index 495f692..0000000
--- a/arch/arm/mach-s3c2412/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-# Note, the S3C2412 IOtiming support is in plat-s3c24xx
-
-config S3C2412_CPUFREQ
- bool
- depends on CPU_FREQ_S3C24XX && CPU_S3C2412
- default y
- select S3C2412_IOTIMING
- help
- CPU Frequency scaling support for S3C2412 and S3C2413 SoC CPUs.
diff --git a/arch/arm/mach-s3c2412/Makefile b/arch/arm/mach-s3c2412/Makefile
deleted file mode 100644
index 41a6c27..0000000
--- a/arch/arm/mach-s3c2412/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-# arch/arm/mach-s3c2412/Makefile
-#
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-obj-y :=
-obj-m :=
-obj-n :=
-obj- :=
-
-obj-$(CONFIG_S3C2412_CPUFREQ) += cpu-freq.o
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 5cc740c..f1d3951 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -280,6 +280,14 @@ config CPU_S3C2412_ONLY
!CPU_S3C2443 && CPU_S3C2412
default y
+config S3C2412_CPUFREQ
+ bool
+ depends on CPU_FREQ_S3C24XX && CPU_S3C2412
+ default y
+ select S3C2412_IOTIMING
+ help
+ CPU Frequency scaling support for S3C2412 and S3C2413 SoC CPUs.
+
config S3C2412_DMA
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index ecace54..0f042d1 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_S3C2410_PLL) += pll-s3c2410.o
obj-$(CONFIG_S3C2410_PM) += pm-s3c2410.o sleep-s3c2410.o
obj-$(CONFIG_CPU_S3C2412) += s3c2412.o irq-s3c2412.o clock-s3c2412.o
+obj-$(CONFIG_S3C2412_CPUFREQ) += cpufreq-s3c2412.o
obj-$(CONFIG_S3C2412_DMA) += dma-s3c2412.o
obj-$(CONFIG_S3C2412_PM) += pm-s3c2412.o
obj-$(CONFIG_S3C2412_PM_SLEEP) += sleep-s3c2412.o
diff --git a/arch/arm/mach-s3c2412/cpu-freq.c b/arch/arm/mach-s3c24xx/cpufreq-s3c2412.c
similarity index 99%
rename from arch/arm/mach-s3c2412/cpu-freq.c
rename to arch/arm/mach-s3c24xx/cpufreq-s3c2412.c
index 125be7d..c8f05f3 100644
--- a/arch/arm/mach-s3c2412/cpu-freq.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-s3c2412.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/mach-s3c2412/cpu-freq.c
- *
+/*
* Copyright 2008 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
@@ -111,7 +110,7 @@ static int s3c2412_cpufreq_calcdivs(struct s3c_cpufreq_config *cfg)
return 0;
- invalid:
+invalid:
return -EINVAL;
}
@@ -255,5 +254,4 @@ static int s3c2412_cpufreq_init(void)
{
return subsys_interface_register(&s3c2412_cpufreq_interface);
}
-
arch_initcall(s3c2412_cpufreq_init);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/6] ARM: S3C2412: Remove useless codes mach-s3c2412/gpio.c
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358817131-27169-1-git-send-email-kgene.kim@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/mach-s3c2412/gpio.c | 62 -------------------------
arch/arm/mach-s3c24xx/include/mach/hardware.h | 6 ---
2 files changed, 68 deletions(-)
delete mode 100644 arch/arm/mach-s3c2412/gpio.c
diff --git a/arch/arm/mach-s3c2412/gpio.c b/arch/arm/mach-s3c2412/gpio.c
deleted file mode 100644
index 4526f6b..0000000
--- a/arch/arm/mach-s3c2412/gpio.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/* linux/arch/arm/mach-s3c2412/gpio.c
- *
- * Copyright (c) 2007 Simtec Electronics
- * Ben Dooks <ben@simtec.co.uk>
- *
- * http://armlinux.simtec.co.uk/.
- *
- * S3C2412/S3C2413 specific GPIO support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include <linux/kernel.h>
-#include <linux/types.h>
-#include <linux/module.h>
-#include <linux/interrupt.h>
-#include <linux/gpio.h>
-
-#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
-
-#include <mach/regs-gpio.h>
-#include <mach/hardware.h>
-
-#include <plat/gpio-core.h>
-
-int s3c2412_gpio_set_sleepcfg(unsigned int pin, unsigned int state)
-{
- struct samsung_gpio_chip *chip = samsung_gpiolib_getchip(pin);
- unsigned long offs = pin - chip->chip.base;
- unsigned long flags;
- unsigned long slpcon;
-
- offs *= 2;
-
- if (pin < S3C2410_GPB(0))
- return -EINVAL;
-
- if (pin >= S3C2410_GPF(0) &&
- pin <= S3C2410_GPG(16))
- return -EINVAL;
-
- if (pin > S3C2410_GPH(16))
- return -EINVAL;
-
- local_irq_save(flags);
-
- slpcon = __raw_readl(chip->base + 0x0C);
-
- slpcon &= ~(3 << offs);
- slpcon |= state << offs;
-
- __raw_writel(slpcon, chip->base + 0x0C);
-
- local_irq_restore(flags);
-
- return 0;
-}
-
-EXPORT_SYMBOL(s3c2412_gpio_set_sleepcfg);
diff --git a/arch/arm/mach-s3c24xx/include/mach/hardware.h b/arch/arm/mach-s3c24xx/include/mach/hardware.h
index aef5631..a6cc14a 100644
--- a/arch/arm/mach-s3c24xx/include/mach/hardware.h
+++ b/arch/arm/mach-s3c24xx/include/mach/hardware.h
@@ -23,12 +23,6 @@ extern int s3c2440_set_dsc(unsigned int pin, unsigned int value);
#endif /* CONFIG_CPU_S3C2440 */
-#ifdef CONFIG_CPU_S3C2412
-
-extern int s3c2412_gpio_set_sleepcfg(unsigned int pin, unsigned int state);
-
-#endif /* CONFIG_CPU_S3C2412 */
-
#endif /* __ASSEMBLY__ */
#include <asm/sizes.h>
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/6] ARM: S3C24XX: Move mach-s3c2410/ pll into mach-s3c24xx/
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358817131-27169-1-git-send-email-kgene.kim@samsung.com>
This patch moves mach-s3c2410/pll into mach-s3c24xx/
and removes arch/arm/mach-s3c2410/ directory in kernel.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/mach-s3c2410/Kconfig | 13 -------------
arch/arm/mach-s3c2410/Makefile | 13 -------------
arch/arm/mach-s3c24xx/Kconfig | 7 +++++++
arch/arm/mach-s3c24xx/Makefile | 1 +
.../{mach-s3c2410/pll.c => mach-s3c24xx/pll-s3c2410.c} | 5 +----
5 files changed, 9 insertions(+), 30 deletions(-)
delete mode 100644 arch/arm/mach-s3c2410/Kconfig
delete mode 100644 arch/arm/mach-s3c2410/Makefile
rename arch/arm/{mach-s3c2410/pll.c => mach-s3c24xx/pll-s3c2410.c} (99%)
diff --git a/arch/arm/mach-s3c2410/Kconfig b/arch/arm/mach-s3c2410/Kconfig
deleted file mode 100644
index 910b8d2..0000000
--- a/arch/arm/mach-s3c2410/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-# cpu frequency scaling support
-
-config S3C2410_PLLTABLE
- bool
- depends on S3C2410_CPUFREQ && CPU_FREQ_S3C24XX_PLL
- default y
- help
- Select the PLL table for the S3C2410
-
diff --git a/arch/arm/mach-s3c2410/Makefile b/arch/arm/mach-s3c2410/Makefile
deleted file mode 100644
index 2a160a5..0000000
--- a/arch/arm/mach-s3c2410/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-# arch/arm/mach-s3c2410/Makefile
-#
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-obj-y :=
-obj-m :=
-obj-n :=
-obj- :=
-
-obj-$(CONFIG_S3C2410_PLLTABLE) += pll.o
-
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 04921b9..5cc740c 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -134,6 +134,13 @@ config S3C2410_CPUFREQ
help
CPU Frequency scaling support for S3C2410
+config S3C2410_PLL
+ bool
+ depends on S3C2410_CPUFREQ && CPU_FREQ_S3C24XX_PLL
+ default y
+ help
+ Select the PLL table for the S3C2410
+
config S3C24XX_SIMTEC_NOR
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 3c9fd51..ecace54 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -19,6 +19,7 @@ obj-y += common.o
obj-$(CONFIG_CPU_S3C2410) += s3c2410.o
obj-$(CONFIG_S3C2410_CPUFREQ) += cpufreq-s3c2410.o
obj-$(CONFIG_S3C2410_DMA) += dma-s3c2410.o
+obj-$(CONFIG_S3C2410_PLL) += pll-s3c2410.o
obj-$(CONFIG_S3C2410_PM) += pm-s3c2410.o sleep-s3c2410.o
obj-$(CONFIG_CPU_S3C2412) += s3c2412.o irq-s3c2412.o clock-s3c2412.o
diff --git a/arch/arm/mach-s3c2410/pll.c b/arch/arm/mach-s3c24xx/pll-s3c2410.c
similarity index 99%
rename from arch/arm/mach-s3c2410/pll.c
rename to arch/arm/mach-s3c24xx/pll-s3c2410.c
index e0b3b34..dcf3420 100644
--- a/arch/arm/mach-s3c2410/pll.c
+++ b/arch/arm/mach-s3c24xx/pll-s3c2410.c
@@ -1,5 +1,4 @@
-/* arch/arm/mach-s3c2410/pll.c
- *
+/*
* Copyright (c) 2006-2007 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
@@ -82,7 +81,6 @@ static int __init s3c2410_pll_init(void)
return subsys_interface_register(&s3c2410_plls_interface);
}
-
arch_initcall(s3c2410_pll_init);
static struct subsys_interface s3c2410a_plls_interface = {
@@ -95,5 +93,4 @@ static int __init s3c2410a_pll_init(void)
{
return subsys_interface_register(&s3c2410a_plls_interface);
}
-
arch_initcall(s3c2410a_pll_init);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/6] ARM: S3C24XX: Move mach-s3c2410/ cpufreq into mach-s3c24xx/
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358817131-27169-1-git-send-email-kgene.kim@samsung.com>
Basically, the cpufreq driver for s3c2410 should be implemented into
drivers/cpufreq, but we don't need to keep the mach-s3c2410 directory.
So this patch moves current cpufreq driver into mach-s3c24xx/.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/mach-s3c2410/Kconfig | 7 -------
arch/arm/mach-s3c2410/Makefile | 1 -
arch/arm/mach-s3c24xx/Kconfig | 7 +++++++
arch/arm/mach-s3c24xx/Makefile | 1 +
.../{mach-s3c2410/cpu-freq.c => mach-s3c24xx/cpufreq-s3c2410.c} | 7 ++-----
5 files changed, 10 insertions(+), 13 deletions(-)
rename arch/arm/{mach-s3c2410/cpu-freq.c => mach-s3c24xx/cpufreq-s3c2410.c} (98%)
diff --git a/arch/arm/mach-s3c2410/Kconfig b/arch/arm/mach-s3c2410/Kconfig
index 68d89cb..910b8d2 100644
--- a/arch/arm/mach-s3c2410/Kconfig
+++ b/arch/arm/mach-s3c2410/Kconfig
@@ -4,13 +4,6 @@
# cpu frequency scaling support
-config S3C2410_CPUFREQ
- bool
- depends on CPU_FREQ_S3C24XX && CPU_S3C2410
- select S3C2410_CPUFREQ_UTILS
- help
- CPU Frequency scaling support for S3C2410
-
config S3C2410_PLLTABLE
bool
depends on S3C2410_CPUFREQ && CPU_FREQ_S3C24XX_PLL
diff --git a/arch/arm/mach-s3c2410/Makefile b/arch/arm/mach-s3c2410/Makefile
index 6b9a316..2a160a5 100644
--- a/arch/arm/mach-s3c2410/Makefile
+++ b/arch/arm/mach-s3c2410/Makefile
@@ -9,6 +9,5 @@ obj-m :=
obj-n :=
obj- :=
-obj-$(CONFIG_S3C2410_CPUFREQ) += cpu-freq.o
obj-$(CONFIG_S3C2410_PLLTABLE) += pll.o
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 25df14a..04921b9 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -127,6 +127,13 @@ config S3C2410_PM
if CPU_S3C2410
+config S3C2410_CPUFREQ
+ bool
+ depends on CPU_FREQ_S3C24XX && CPU_S3C2410
+ select S3C2410_CPUFREQ_UTILS
+ help
+ CPU Frequency scaling support for S3C2410
+
config S3C24XX_SIMTEC_NOR
bool
help
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 0ab6ab1..3c9fd51 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -17,6 +17,7 @@ obj- :=
obj-y += common.o
obj-$(CONFIG_CPU_S3C2410) += s3c2410.o
+obj-$(CONFIG_S3C2410_CPUFREQ) += cpufreq-s3c2410.o
obj-$(CONFIG_S3C2410_DMA) += dma-s3c2410.o
obj-$(CONFIG_S3C2410_PM) += pm-s3c2410.o sleep-s3c2410.o
diff --git a/arch/arm/mach-s3c2410/cpu-freq.c b/arch/arm/mach-s3c24xx/cpufreq-s3c2410.c
similarity index 98%
rename from arch/arm/mach-s3c2410/cpu-freq.c
rename to arch/arm/mach-s3c24xx/cpufreq-s3c2410.c
index 5404535..cfa0dd8 100644
--- a/arch/arm/mach-s3c2410/cpu-freq.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-s3c2410.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/mach-s3c2410/cpu-freq.c
- *
+/*
* Copyright (c) 2006-2008 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
@@ -81,7 +80,7 @@ static int s3c2410_cpufreq_calcdivs(struct s3c_cpufreq_config *cfg)
cfg->divs.p_divisor = pdiv;
cfg->divs.h_divisor = hdiv;
- return 0 ;
+ return 0;
}
static struct s3c_cpufreq_info s3c2410_cpufreq_info = {
@@ -131,7 +130,6 @@ static int __init s3c2410_cpufreq_init(void)
{
return subsys_interface_register(&s3c2410_cpufreq_interface);
}
-
arch_initcall(s3c2410_cpufreq_init);
static int s3c2410a_cpufreq_add(struct device *dev,
@@ -159,5 +157,4 @@ static int __init s3c2410a_cpufreq_init(void)
{
return subsys_interface_register(&s3c2410a_cpufreq_interface);
}
-
arch_initcall(s3c2410a_cpufreq_init);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/6] ARM: S3C24XX: Cleanup mach-s3c2410, mach-s3c2412 and mach-s3c2440
From: Kukjin Kim @ 2013-01-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
This is for cleanup mach-s3c2410, mach-s3c2412 and mach-s3c2440 directories.
Basically, cpufreq driver in there should be implemented into drivers/cpufreq/
but I think, would be better if we could cleanup the mach- directories.
arch/arm/Kconfig | 4 ----
arch/arm/Makefile | 2 +-
arch/arm/mach-s3c2410/Kconfig | 20 ----------------
arch/arm/mach-s3c2410/Makefile | 14 -----------
arch/arm/mach-s3c2412/Kconfig | 13 -----------
arch/arm/mach-s3c2412/Makefile | 12 ----------
arch/arm/mach-s3c2412/gpio.c | 62 -------------------------------------------------
arch/arm/mach-s3c2440/Kconfig | 37 -----------------------------
arch/arm/mach-s3c2440/Makefile | 15 ------------
arch/arm/mach-s3c24xx/Kconfig | 56 ++++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-s3c24xx/Makefile | 6 +++++
arch/arm/{mach-s3c2410/cpu-freq.c => mach-s3c24xx/cpufreq-s3c2410.c} | 7 ++----
arch/arm/{mach-s3c2412/cpu-freq.c => mach-s3c24xx/cpufreq-s3c2412.c} | 6 ++---
arch/arm/{mach-s3c2440/s3c2440-cpufreq.c => mach-s3c24xx/cpufreq-s3c2440.c} | 4 +---
arch/arm/mach-s3c24xx/include/mach/hardware.h | 6 -----
arch/arm/{mach-s3c2410/pll.c => mach-s3c24xx/pll-s3c2410.c} | 5 +---
arch/arm/{mach-s3c2440/s3c2440-pll-12000000.c => mach-s3c24xx/pll-s3c2440-12000000.c} | 5 +---
arch/arm/{mach-s3c2440/s3c2440-pll-16934400.c => mach-s3c24xx/pll-s3c2440-16934400.c} | 5 +---
18 files changed, 71 insertions(+), 208 deletions(-)
[PATCH 1/6] ARM: S3C24XX: Move mach-s3c2410/ cpufreq into
[PATCH 2/6] ARM: S3C24XX: Move mach-s3c2410/ pll into mach-s3c24xx/
[PATCH 3/6] ARM: S3C2412: Remove useless codes mach-s3c2412/gpio.c
[PATCH 4/6] ARM: S3C24XX: Move mach-s3c2412/ cpufreq driver into
[PATCH 5/6] ARM: S3C24XX: Move mach-s3c2440/ cpufreq driver into
[PATCH 6/6] ARM: S3C24XX: Move mach-s3c2440/ pll into mach-s3c24xx/
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Matt Sealey @ 2013-01-22 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FDE2AE.8030608@linaro.org>
On Mon, Jan 21, 2013 at 6:51 PM, John Stultz <john.stultz@linaro.org> wrote:
> On 01/21/2013 02:54 PM, Matt Sealey wrote:
>>
>> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz <john.stultz@linaro.org>
>> wrote:
>>>
>>> On 01/21/2013 01:14 PM, Matt Sealey wrote:
>
> As far as jiffies rating, from jiffies.c:
> .rating = 1, /* lowest valid rating*/
>
> So I'm not sure what you mean by "the debug on the kernel log is telling me
> it has a higher resolution".
Oh, it is just if I actually don't run setup_sched_clock on my
platform, it gives a little message (with #define DEBUG 1 in
sched_clock.c) about who setup the last sched_clock. Since you only
get one chance, and I was fiddling with setup_sched_clock being probed
from multiple possible timers from device tree (i.MX3 has a crapload
of valid timers, which one you use right now is basically forced by
the not-quite-fully-DT-only code and some funky iomap tricks).
And what I got was, if I use the real hardware timer, it runs at 66MHz
and says it has 15ns resolution and wraps every 500 seconds or so. The
jiffies timer says it's 750MHz, with a 2ns resoluton.. you get the
drift. The generic reporting of how "good" the sched_clock source is
kind of glosses over the quality rating of the clock source and at
first glance (if you're not paying that much attention), it is a
little bit misleading..
> Yes, in the case I was remembering, the 60HZ was driven by the electrical
> line.
While I have your attention, what would be the minimum "good" speed to
run the sched_clock or delay timer implementation from? My rudimentary
scribblings in my notebook give me a value of "don't bother" with less
than 10KHz based on HZ=100, so I'm wondering if a direct 32.768KHz
clock would do (i.MX osc clock input if I can supply it to one of the
above myriad timers) since this would be low-power compared to a 66MHz
one (by a couple mA anyway). I also have a bunch of questions about
the delay timer requirements.. I might mail you personally.. or would
you prefer on-list?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ 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