* [PATCH v2 2/5] ARM: S5P: Remove system MMU driver from arm/plat-s5p
From: Roedel, Joerg @ 2011-09-30 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016d01cc7f42$e58a0aa0$b09e1fe0$%kim@samsung.com>
On Fri, Sep 30, 2011 at 03:30:57AM -0400, Kukjin Kim wrote:
> From: KyongHo Cho <pullip.cho@samsung.com>
>
> Due to Ohad Ben-Cohen gathered IOMMU drivers in drivers/iommu directory,
> System MMU driver is moved to drivers/iommu directory and removed
> from arch/arm/plat-s5p directory.
>
> Please see
> https://lkml.org/lkml/2011/6/8/69
>
> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
> arch/arm/plat-s5p/Kconfig | 8 -
> arch/arm/plat-s5p/Makefile | 1 -
> arch/arm/plat-s5p/include/plat/sysmmu.h | 95 ----------
> arch/arm/plat-s5p/sysmmu.c | 312 -------------------------------
You can use 'git mv' to just move the file. This ensures bisectability
of your patches. No need to delete the code in one patch and re-add it
in the next one (which breaks bisectability).
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* [PATCH v2 5/5] iommu/exynos: Use bus_set_iommu instead of register_iommu
From: Roedel, Joerg @ 2011-09-30 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <017001cc7f43$04a2db60$0de89220$%kim@samsung.com>
On Fri, Sep 30, 2011 at 03:31:49AM -0400, Kukjin Kim wrote:
> From: KyongHo Cho <pullip.cho@samsung.com>
>
> This replaces register_iommu() with bus_set_iommu() according to the
> suggestion of Joerg Roedel.
This should be part of patch 3 already when the bus_set_iommu() change
is merged. Otherwise it breaks bisectability too.
Joerg
>
> Cc: Joerg Roedel <joerg.roedel@amd.com>
> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
> drivers/iommu/exynos_iommu.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/exynos_iommu.c b/drivers/iommu/exynos_iommu.c
> index d355a2e..e36f7b2 100644
> --- a/drivers/iommu/exynos_iommu.c
> +++ b/drivers/iommu/exynos_iommu.c
> @@ -912,7 +912,7 @@ static int __init exynos_iommu_init(void)
> if (!l2table_cachep)
> return -ENOMEM;
>
> - register_iommu(&exynos_iommu_ops);
> + bus_set_iommu(&platform_bus_type, &exynos_iommu_ops);
>
> return 0;
> }
> --
> 1.7.1
>
>
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* [PATCH 1/2] arm/mx5: add device tree support for imx53 boards
From: Fabio Estevam @ 2011-09-30 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317389747-24589-2-git-send-email-shawn.guo@linaro.org>
On Fri, Sep 30, 2011 at 10:35 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> From: Shawn Guo <shawn.guo@freescale.com>
>
> It adds device tree support for imx53 boards.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> ?Documentation/devicetree/bindings/arm/fsl.txt | ? 15 ++
> ?arch/arm/boot/dts/imx53-ard.dts ? ? ? ? ? ? ? | ?113 ++++++++++
> ?arch/arm/boot/dts/imx53-evk.dts ? ? ? ? ? ? ? | ?120 +++++++++++
> ?arch/arm/boot/dts/imx53-qsb.dts ? ? ? ? ? ? ? | ?125 +++++++++++
Can't you call it imx53-loco.dts instead so that it is consistent with
mach-mx53_loco.c ?
^ permalink raw reply
* ARM SoC tree: OMAP PM dependency on tip irq/core
From: Kevin Hilman @ 2011-09-30 13:57 UTC (permalink / raw)
To: linux-arm-kernel
Arnd,
The upcoming OMAP4 PM series from Santosh[1] that we're planning to
queue for v3.2 has a dependency[2] on a patch currently queued for v3.2
in the irq/core branch of Thomas' tip tree[3].
In the past, I noticed you merged external trees like this to solve
dependencies.
Could you pull the irq/core branch into your tree to meet this
dependency?
Thanks,
Kevin
[1] http://marc.info/?l=linux-omap&m=131684489920440&w=2
[2] http://marc.info/?l=linux-omap&m=131581416908252&w=2
[3] currently here: git://tesla.tglx.de/git/linux-2.6-tip
^ permalink raw reply
* [PATCH] arm/imx: rename MX51_MXC_INT_ATA to MX51_INT_ATA
From: Arnaud Patard (Rtp) @ 2011-09-30 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317384355-24481-1-git-send-email-shawn.guo@linaro.org>
Shawn Guo <shawn.guo@linaro.org> writes:
[ adding Uwe Kleine-Koning in CC: ]
Hi,
> This change is to fix the compile error below.
>
> CC arch/arm/plat-mxc/devices/platform-pata_imx.o
> arch/arm/plat-mxc/devices/platform-pata_imx.c:33:1: error: ?MX51_INT_ATA? undeclared here (not in a function)
> make[3]: *** [arch/arm/plat-mxc/devices/platform-pata_imx.o] Error 1
It's weird. All interrupt are supposed to be like MX51_INT_*. At least
it does on the old checkout from Sascha's tree here.
The renaming comes from
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/059666.html
which afaik has been merged.
Arnaud
^ permalink raw reply
* [RFC] Need help deciphering reboot modes!
From: Will Deacon @ 2011-09-30 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930125725.GG3895@e102144-lin.cambridge.arm.com>
On Fri, Sep 30, 2011 at 01:57:25PM +0100, Will Deacon wrote:
> 'g' -> A supported option by spitz and tosa (both mach-pxa). I can't
> begin to imagine what it might stand for.
Aha! Some digging revealed this is a reset via GPIO and is specific to
mach-pxa. Maybe we can eliminate it with something like below:
Signed-off-by: Will Deacon <will.deacon@arm.com>
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 832888d..e85d31e 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -107,6 +107,9 @@ extern void __show_regs(struct pt_regs *);
extern int cpu_architecture(void);
extern void cpu_init(void);
+#define ARM_REBOOT_MODE_HARD 'h'
+#define ARM_REBOOT_MODE_SOFT 's'
+
void arm_machine_restart(char mode, const char *cmd);
extern void (*arm_pm_restart)(char str, const char *cmd);
diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
index 01e9d64..18556da 100644
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -9,6 +9,7 @@
#include <linux/gpio.h>
#include <linux/io.h>
#include <asm/proc-fns.h>
+#include <asm/system.h>
#include <mach/regs-ost.h>
#include <mach/reset.h>
@@ -54,8 +55,6 @@ out:
*/
static void do_gpio_reset(void)
{
- BUG_ON(reset_gpio == -1);
-
/* drive it low */
gpio_direction_output(reset_gpio, 0);
mdelay(2);
@@ -69,8 +68,6 @@ static void do_gpio_reset(void)
mdelay(10);
WARN_ON(1);
- /* fallback */
- do_hw_reset();
}
static void do_hw_reset(void)
@@ -86,15 +83,14 @@ void arch_reset(char mode, const char *cmd)
clear_reset_status(RESET_STATUS_ALL);
switch (mode) {
- case 's':
+ case ARM_REBOOT_MODE_SOFT:
/* Jump into ROM at address 0 */
cpu_reset(0);
break;
- case 'g':
- do_gpio_reset();
- break;
- case 'h':
+ case ARM_REBOOT_MODE_HARD:
default:
+ if (reset_gpio != -1)
+ do_gpio_reset();
do_hw_reset();
break;
}
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 438c7b5..34be135 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -925,7 +925,7 @@ static inline void spitz_i2c_init(void) {}
******************************************************************************/
static void spitz_poweroff(void)
{
- arm_machine_restart('g', NULL);
+ arm_machine_restart(ARM_REBOOT_MODE_HARD, NULL);
}
static void spitz_restart(char mode, const char *cmd)
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 9f69a26..e118933 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -905,7 +905,7 @@ static struct platform_device *devices[] __initdata = {
static void tosa_poweroff(void)
{
- arm_machine_restart('g', NULL);
+ arm_machine_restart(ARM_REBOOT_MODE_HARD, NULL);
}
static void tosa_restart(char mode, const char *cmd)
^ permalink raw reply related
* [PATCH 1/2] arm/mx5: add device tree support for imx53 boards
From: Shawn Guo @ 2011-09-30 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317389747-24589-2-git-send-email-shawn.guo@linaro.org>
On Fri, Sep 30, 2011 at 09:35:46PM +0800, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@freescale.com>
Hi Sascha,
This line was added by accident. If you plan to apply this patch,
please help remove the line.
Regards,
Shawn
>
> It adds device tree support for imx53 boards.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
^ permalink raw reply
* [PATCH 1/2] arm/mx5: add device tree support for imx53 boards
From: Shawn Guo @ 2011-09-30 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Cn3MvvoejPDyfz4gQZipNKASZoscsZn5ahzrV240HB_A@mail.gmail.com>
On Fri, Sep 30, 2011 at 10:56:48AM -0300, Fabio Estevam wrote:
> On Fri, Sep 30, 2011 at 10:35 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > From: Shawn Guo <shawn.guo@freescale.com>
> >
> > It adds device tree support for imx53 boards.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> > ?Documentation/devicetree/bindings/arm/fsl.txt | ? 15 ++
> > ?arch/arm/boot/dts/imx53-ard.dts ? ? ? ? ? ? ? | ?113 ++++++++++
> > ?arch/arm/boot/dts/imx53-evk.dts ? ? ? ? ? ? ? | ?120 +++++++++++
> > ?arch/arm/boot/dts/imx53-qsb.dts ? ? ? ? ? ? ? | ?125 +++++++++++
>
> Can't you call it imx53-loco.dts instead so that it is consistent with
> mach-mx53_loco.c ?
>
No. I was taking this opportunity to fix the naming. "loco" is a bad
name and is not recommended any more. Eventually, board-mx53_loco.c
will be killed by imx53-dt.c, which means "loco" will be killed
eventually.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v4 6/7] arm/imx6q: add device tree machine support
From: Shawn Guo @ 2011-09-30 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930090156.GS17204@pulham.picochip.com>
On Fri, Sep 30, 2011 at 10:01:56AM +0100, Jamie Iles wrote:
> Hi Shawn,
>
> On Wed, Sep 28, 2011 at 05:06:47PM +0800, Shawn Guo wrote:
> > It adds generic device tree based machine support for imx6q.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > ---
> [...]
> > diff --git a/arch/arm/mach-imx/mach-imx6q.c
> > b/arch/arm/mach-imx/mach-imx6q.c
> > new file mode 100644
> > index 0000000..8bf5fa3
> > --- /dev/null
> > +++ b/arch/arm/mach-imx/mach-imx6q.c
> [...]
> > +static void __init imx6q_gpio_add_irq_domain(struct device_node *np,
> > + struct device_node *interrupt_parent)
> > +{
> > + static int gpio_irq_base = MXC_GPIO_IRQ_START + ARCH_NR_GPIOS -
> > + 32 * 7; /* imx6q gets 7 gpio ports */
> > +
> > + irq_domain_add_simple(np, gpio_irq_base);
> > + gpio_irq_base += 32;
>
> Doesn't this rely on imx6q_gpio_add_irq_domain() being called for each
> gpio bank in the order that they appear in the device tree (and that the
> dt is correctly ordered)?
>
Not really. In case of DT, gpio core will dynamically assign gpio
range from the end of total number (MXC_GPIO_IRQ_START + ARCH_NR_GPIOS
for imx case) for each gpio bank that gets probed. Supposing we have
gpio0 ~ gpio6 sorted in dts, we will have the following gpio ranges
assigned by gpio core.
gpio0: MXC_GPIO_IRQ_START + ARCH_NR_GPIOS - 32
gpio1: MXC_GPIO_IRQ_START + ARCH_NR_GPIOS - 32 * 2
...
gpio6: MXC_GPIO_IRQ_START + ARCH_NR_GPIOS - 32 * 7
Regards,
Shawn
> > +}
> > +
> > +static const struct of_device_id imx6q_irq_match[] __initconst = {
> > + { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> > + { .compatible = "fsl,imx6q-gpio", .data = imx6q_gpio_add_irq_domain, },
> > + { /* sentinel */ }
> > +};
> > +
> > +static void __init imx6q_init_irq(void)
> > +{
> > + l2x0_of_init(0, ~0UL);
> > + imx_src_init();
> > + imx_gpc_init();
> > + of_irq_init(imx6q_irq_match);
> > +}
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-09-30 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930020754.GK12606@ponder.secretlab.ca>
On Fri, Sep 30, 2011 at 4:07 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Comments below, some a bit nitpicky, but overall I think it looks
> good. ?I haven't dug into it nearly deeply enough though. ?:-(
Hopefully we can patch the remaining bugs as we go along :-)
>> +/**
>> + * Looks up a pin control device matching a certain device name or
>> + * pure device pointer.
>
> May as well actually do kerneldoc formatting here on the comment
> blocks.
OK.
>> +struct pinctrl_dev *get_pctldev_from_dev(struct device *dev,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const char *devname)
>
> Nit: I'm not too fond of a single function doing both name and pointer
> lookup at the same time. ?Presumably the caller would have one or the
> other and know what it needs to do. ?I'd prefer to see one by-name
> function and one by-reference. ?I'm not going to make a big deal about
> it though.
The caller currently does not know what it has or
what to do.
This is basically an interator function that is called on
a member tuple of device and device name to check
which one you have and return a matching controller
device for the key you do have.
>> + ? ? /* Register device with sysfs */
>> + ? ? pctldev->dev.parent = dev;
>> + ? ? pctldev->dev.bus = &pinctrl_bus;
>
> I don't think there is an actual need for a pinctrl bus type. ?There
> aren't any drivers that are going to be bound to these things which is
> the primary functionality that a bus type provides. ?Am I missing
> something?
That is not the reason it's there actually, what we have
discussed on the mailing list is getting sysfs entries for the same
reason gpiolib registers a class: handle pin control from userspace,
we can already see that coming and I already have a use case
for it. (Modem SIM connector control from userspace daemon.)
So first it was registering a class, then Greg said classes are
deprecated and we should use a bus instead. So it is
registering a bus to get sysfs so we can get userspace
controls.
>> +out_err:
>> + ? ? put_device(&pctldev->dev);
>> + ? ? kfree(pctldev);
>
> Once a device is initialized, it cannot be kfree()'ed directly. ?The
> .release method needs to do that.
OK. And I already had a proper .release() method doing
exactly that, so deleting this.
>> +/**
>> + * pin_free() - release a single muxed in pin so something else can be muxed in
>> + * ? instead
>
> Nit: the summary line in kerneldoc should fit on one line.
OK.
Went over the code and fixed a few other sites too.
>> +int __init
>> +pinmux_register_mappings(struct pinmux_map const *maps, unsigned num_maps)
>
> Nit: keep line breaks in the parameter lists. ?More grep friendly.
OK fixed it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: mxs: Consolidate mm-mx23.c and mm-mx28.c into a single file
From: Fabio Estevam @ 2011-09-30 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930151725.GG19807@S2100-06.ap.freescale.net>
On Fri, Sep 30, 2011 at 12:17 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> Beside reducing one file, the benefit of the consolidation includes
> that we have the chance to consolidate the common pattern between mx23
> and mx28. ?I see mx23_init_irq() and mx28_init_irq() have something in
> common. ?Not sure if you care to consolidate it.
Yes, I can look at it also if this current patch gets accepted.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 1/2] arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
From: T Krishnamoorthy, Balaji @ 2011-09-30 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110929162006.GG6324@atomide.com>
On Thu, Sep 29, 2011 at 9:50 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Balaji T K <balajitk@ti.com> [110929 07:11]:
>> MMC1 data line IO's are powered down in before set regulator function.
>> IO's should not be powered ON when regulator is OFF.
>> Keep the IO's in power pown mode after regulator OFF.
>> Delete incorrect comments which are not applicable for OMAP4.
>
> Care to check how this is different from what I added into fixes
> branch as commit 3fe8df93b0992199e3a0026fc51e90b705f94e40?
>
> Is this a separate issue?
Yes.
commit 3fe8df93b fixes USBC1 configuration.
USBC1 IO was configured unnecessarily for MMC IO.
This patch keeps the MMC IO's in power down after regulator OFF
otherwise it generates VMODE_ERROR due to mismatch in input (regulator)
voltage and MMC IO drive voltage.
>
> Tony
>
>
>> Signed-off-by: Balaji T K <balajitk@ti.com>
>> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
>> Reported-by: Viswanath Puttagunta <vishp@ti.com>
>> ---
>> ?arch/arm/mach-omap2/hsmmc.c | ? 14 ++------------
>> ?1 files changed, 2 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
>> index 097a42d..9cc2eb7 100644
>> --- a/arch/arm/mach-omap2/hsmmc.c
>> +++ b/arch/arm/mach-omap2/hsmmc.c
>> @@ -129,15 +129,11 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
>> ? ? ? ?* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
>> ? ? ? ?* card with Vcc regulator (from twl4030 or whatever). ?OMAP has both
>> ? ? ? ?* 1.8V and 3.0V modes, controlled by the PBIAS register.
>> - ? ? ?*
>> - ? ? ?* In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
>> - ? ? ?* is most naturally TWL VSIM; those pins also use PBIAS.
>> - ? ? ?*
>> - ? ? ?* FIXME handle VMMC1A as needed ...
>> ? ? ? ?*/
>> ? ? ? reg = omap4_ctrl_pad_readl(control_pbias_offset);
>> ? ? ? reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
>> - ? ? ? ? ? ? OMAP4_MMC1_PWRDNZ_MASK);
>> + ? ? ? ? ? ? OMAP4_MMC1_PWRDNZ_MASK |
>> + ? ? ? ? ? ? OMAP4_MMC1_PBIASLITE_VMODE_MASK);
>> ? ? ? omap4_ctrl_pad_writel(reg, control_pbias_offset);
>> ?}
>>
>> @@ -172,12 +168,6 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
>> ? ? ? ? ? ? ? ? ? ? ? reg &= ~(OMAP4_MMC1_PWRDNZ_MASK);
>> ? ? ? ? ? ? ? ? ? ? ? omap4_ctrl_pad_writel(reg, control_pbias_offset);
>> ? ? ? ? ? ? ? }
>> - ? ? } else {
>> - ? ? ? ? ? ? reg = omap4_ctrl_pad_readl(control_pbias_offset);
>> - ? ? ? ? ? ? reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
>> - ? ? ? ? ? ? ? ? ? ? OMAP4_MMC1_PWRDNZ_MASK |
>> - ? ? ? ? ? ? ? ? ? ? OMAP4_MMC1_PBIASLITE_VMODE_MASK);
>> - ? ? ? ? ? ? omap4_ctrl_pad_writel(reg, control_pbias_offset);
>> ? ? ? }
>> ?}
>>
>> --
>> 1.7.0.4
>>
^ permalink raw reply
* [PATCH] ARM: mxs: Consolidate mm-mx23.c and mm-mx28.c into a single file
From: Shawn Guo @ 2011-09-30 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317385328-14529-1-git-send-email-fabio.estevam@freescale.com>
On Fri, Sep 30, 2011 at 09:22:08AM -0300, Fabio Estevam wrote:
> Consolidate mm-mx23.c and mm-mx28.c into a single file.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-mxs/Makefile | 6 ++--
> arch/arm/mach-mxs/mm-mx23.c | 44 ------------------------------
> arch/arm/mach-mxs/mm-mx28.c | 44 ------------------------------
> arch/arm/mach-mxs/mm-mxs.c | 63 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 66 insertions(+), 91 deletions(-)
> delete mode 100644 arch/arm/mach-mxs/mm-mx23.c
> delete mode 100644 arch/arm/mach-mxs/mm-mx28.c
> create mode 100644 arch/arm/mach-mxs/mm-mxs.c
>
> diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
> index 6c38262..7474064 100644
> --- a/arch/arm/mach-mxs/Makefile
> +++ b/arch/arm/mach-mxs/Makefile
> @@ -1,11 +1,11 @@
> # Common support
> -obj-y := clock.o devices.o icoll.o iomux.o system.o timer.o
> +obj-y := clock.o devices.o icoll.o iomux.o system.o timer.o mm-mxs.o
>
> obj-$(CONFIG_MXS_OCOTP) += ocotp.o
> obj-$(CONFIG_PM) += pm.o
>
> -obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
> -obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
> +obj-$(CONFIG_SOC_IMX23) += clock-mx23.o
> +obj-$(CONFIG_SOC_IMX28) += clock-mx28.o
>
> obj-$(CONFIG_MACH_STMP378X_DEVB) += mach-stmp378x_devb.o
> obj-$(CONFIG_MACH_MX23EVK) += mach-mx23evk.o
> diff --git a/arch/arm/mach-mxs/mm-mx23.c b/arch/arm/mach-mxs/mm-mx23.c
> deleted file mode 100644
> index 1b2345a..0000000
> --- a/arch/arm/mach-mxs/mm-mx23.c
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -/*
> - * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 or later at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - *
> - * Create static mapping between physical to virtual memory.
> - */
> -
> -#include <linux/mm.h>
> -#include <linux/init.h>
> -
> -#include <asm/mach/map.h>
> -
> -#include <mach/mx23.h>
> -#include <mach/common.h>
> -#include <mach/iomux.h>
> -
> -/*
> - * Define the MX23 memory map.
> - */
> -static struct map_desc mx23_io_desc[] __initdata = {
> - mxs_map_entry(MX23, OCRAM, MT_DEVICE),
> - mxs_map_entry(MX23, IO, MT_DEVICE),
> -};
> -
> -/*
> - * This function initializes the memory map. It is called during the
> - * system startup to create static physical to virtual memory mappings
> - * for the IO modules.
> - */
> -void __init mx23_map_io(void)
> -{
> - iotable_init(mx23_io_desc, ARRAY_SIZE(mx23_io_desc));
> -}
> -
> -void __init mx23_init_irq(void)
> -{
> - icoll_init_irq();
> -}
> diff --git a/arch/arm/mach-mxs/mm-mx28.c b/arch/arm/mach-mxs/mm-mx28.c
> deleted file mode 100644
> index b6e18dd..0000000
> --- a/arch/arm/mach-mxs/mm-mx28.c
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -/*
> - * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 or later at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - *
> - * Create static mapping between physical to virtual memory.
> - */
> -
> -#include <linux/mm.h>
> -#include <linux/init.h>
> -
> -#include <asm/mach/map.h>
> -
> -#include <mach/mx28.h>
> -#include <mach/common.h>
> -#include <mach/iomux.h>
> -
> -/*
> - * Define the MX28 memory map.
> - */
> -static struct map_desc mx28_io_desc[] __initdata = {
> - mxs_map_entry(MX28, OCRAM, MT_DEVICE),
> - mxs_map_entry(MX28, IO, MT_DEVICE),
> -};
> -
> -/*
> - * This function initializes the memory map. It is called during the
> - * system startup to create static physical to virtual memory mappings
> - * for the IO modules.
> - */
> -void __init mx28_map_io(void)
> -{
> - iotable_init(mx28_io_desc, ARRAY_SIZE(mx28_io_desc));
> -}
> -
> -void __init mx28_init_irq(void)
> -{
> - icoll_init_irq();
> -}
> diff --git a/arch/arm/mach-mxs/mm-mxs.c b/arch/arm/mach-mxs/mm-mxs.c
> new file mode 100644
> index 0000000..50af5ce
> --- /dev/null
> +++ b/arch/arm/mach-mxs/mm-mxs.c
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * Create static mapping between physical to virtual memory.
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/init.h>
> +
> +#include <asm/mach/map.h>
> +
> +#include <mach/mx23.h>
> +#include <mach/mx28.h>
> +#include <mach/common.h>
> +#include <mach/iomux.h>
> +
> +/*
> + * Define the MX23 memory map.
> + */
> +static struct map_desc mx23_io_desc[] __initdata = {
> + mxs_map_entry(MX23, OCRAM, MT_DEVICE),
> + mxs_map_entry(MX23, IO, MT_DEVICE),
> +};
> +
> +/*
> + * Define the MX28 memory map.
> + */
> +static struct map_desc mx28_io_desc[] __initdata = {
> + mxs_map_entry(MX28, OCRAM, MT_DEVICE),
> + mxs_map_entry(MX28, IO, MT_DEVICE),
> +};
> +
> +/*
> + * This function initializes the memory map. It is called during the
> + * system startup to create static physical to virtual memory mappings
> + * for the IO modules.
> + */
> +void __init mx23_map_io(void)
> +{
> + iotable_init(mx23_io_desc, ARRAY_SIZE(mx23_io_desc));
> +}
> +
> +void __init mx23_init_irq(void)
> +{
> + icoll_init_irq();
> +}
> +
> +void __init mx28_map_io(void)
> +{
> + iotable_init(mx28_io_desc, ARRAY_SIZE(mx28_io_desc));
> +}
> +
> +void __init mx28_init_irq(void)
> +{
> + icoll_init_irq();
> +}
Beside reducing one file, the benefit of the consolidation includes
that we have the chance to consolidate the common pattern between mx23
and mx28. I see mx23_init_irq() and mx28_init_irq() have something in
common. Not sure if you care to consolidate it.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] ARM: mxs: Consolidate mm-mx23.c and mm-mx28.c into a single file
From: Shawn Guo @ 2011-09-30 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317385328-14529-1-git-send-email-fabio.estevam@freescale.com>
On Fri, Sep 30, 2011 at 09:22:08AM -0300, Fabio Estevam wrote:
> Consolidate mm-mx23.c and mm-mx28.c into a single file.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-mxs/Makefile | 6 ++--
> arch/arm/mach-mxs/mm-mx23.c | 44 ------------------------------
> arch/arm/mach-mxs/mm-mx28.c | 44 ------------------------------
> arch/arm/mach-mxs/mm-mxs.c | 63 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 66 insertions(+), 91 deletions(-)
> delete mode 100644 arch/arm/mach-mxs/mm-mx23.c
> delete mode 100644 arch/arm/mach-mxs/mm-mx28.c
> create mode 100644 arch/arm/mach-mxs/mm-mxs.c
I do not see the need of '-mxs' suffix.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2] ARM: mxs: Consolidate mm-mx23.c and mm-mx28.c into a single file
From: Fabio Estevam @ 2011-09-30 16:03 UTC (permalink / raw)
To: linux-arm-kernel
Consolidate mm-mx23.c and mm-mx28.c into a single file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Rename from mm-mxs.c to mm.c
arch/arm/mach-mxs/Makefile | 6 ++--
arch/arm/mach-mxs/mm-mx23.c | 44 ------------------------------
arch/arm/mach-mxs/mm-mx28.c | 44 ------------------------------
arch/arm/mach-mxs/mm.c | 63 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 66 insertions(+), 91 deletions(-)
delete mode 100644 arch/arm/mach-mxs/mm-mx23.c
delete mode 100644 arch/arm/mach-mxs/mm-mx28.c
create mode 100644 arch/arm/mach-mxs/mm.c
diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
index 6c38262..7474064 100644
--- a/arch/arm/mach-mxs/Makefile
+++ b/arch/arm/mach-mxs/Makefile
@@ -1,11 +1,11 @@
# Common support
-obj-y := clock.o devices.o icoll.o iomux.o system.o timer.o
+obj-y := clock.o devices.o icoll.o iomux.o system.o timer.o mm.o
obj-$(CONFIG_MXS_OCOTP) += ocotp.o
obj-$(CONFIG_PM) += pm.o
-obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
-obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
+obj-$(CONFIG_SOC_IMX23) += clock-mx23.o
+obj-$(CONFIG_SOC_IMX28) += clock-mx28.o
obj-$(CONFIG_MACH_STMP378X_DEVB) += mach-stmp378x_devb.o
obj-$(CONFIG_MACH_MX23EVK) += mach-mx23evk.o
diff --git a/arch/arm/mach-mxs/mm-mx23.c b/arch/arm/mach-mxs/mm-mx23.c
deleted file mode 100644
index 1b2345a..0000000
--- a/arch/arm/mach-mxs/mm-mx23.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- *
- * Create static mapping between physical to virtual memory.
- */
-
-#include <linux/mm.h>
-#include <linux/init.h>
-
-#include <asm/mach/map.h>
-
-#include <mach/mx23.h>
-#include <mach/common.h>
-#include <mach/iomux.h>
-
-/*
- * Define the MX23 memory map.
- */
-static struct map_desc mx23_io_desc[] __initdata = {
- mxs_map_entry(MX23, OCRAM, MT_DEVICE),
- mxs_map_entry(MX23, IO, MT_DEVICE),
-};
-
-/*
- * This function initializes the memory map. It is called during the
- * system startup to create static physical to virtual memory mappings
- * for the IO modules.
- */
-void __init mx23_map_io(void)
-{
- iotable_init(mx23_io_desc, ARRAY_SIZE(mx23_io_desc));
-}
-
-void __init mx23_init_irq(void)
-{
- icoll_init_irq();
-}
diff --git a/arch/arm/mach-mxs/mm-mx28.c b/arch/arm/mach-mxs/mm-mx28.c
deleted file mode 100644
index b6e18dd..0000000
--- a/arch/arm/mach-mxs/mm-mx28.c
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- *
- * Create static mapping between physical to virtual memory.
- */
-
-#include <linux/mm.h>
-#include <linux/init.h>
-
-#include <asm/mach/map.h>
-
-#include <mach/mx28.h>
-#include <mach/common.h>
-#include <mach/iomux.h>
-
-/*
- * Define the MX28 memory map.
- */
-static struct map_desc mx28_io_desc[] __initdata = {
- mxs_map_entry(MX28, OCRAM, MT_DEVICE),
- mxs_map_entry(MX28, IO, MT_DEVICE),
-};
-
-/*
- * This function initializes the memory map. It is called during the
- * system startup to create static physical to virtual memory mappings
- * for the IO modules.
- */
-void __init mx28_map_io(void)
-{
- iotable_init(mx28_io_desc, ARRAY_SIZE(mx28_io_desc));
-}
-
-void __init mx28_init_irq(void)
-{
- icoll_init_irq();
-}
diff --git a/arch/arm/mach-mxs/mm.c b/arch/arm/mach-mxs/mm.c
new file mode 100644
index 0000000..50af5ce
--- /dev/null
+++ b/arch/arm/mach-mxs/mm.c
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * Create static mapping between physical to virtual memory.
+ */
+
+#include <linux/mm.h>
+#include <linux/init.h>
+
+#include <asm/mach/map.h>
+
+#include <mach/mx23.h>
+#include <mach/mx28.h>
+#include <mach/common.h>
+#include <mach/iomux.h>
+
+/*
+ * Define the MX23 memory map.
+ */
+static struct map_desc mx23_io_desc[] __initdata = {
+ mxs_map_entry(MX23, OCRAM, MT_DEVICE),
+ mxs_map_entry(MX23, IO, MT_DEVICE),
+};
+
+/*
+ * Define the MX28 memory map.
+ */
+static struct map_desc mx28_io_desc[] __initdata = {
+ mxs_map_entry(MX28, OCRAM, MT_DEVICE),
+ mxs_map_entry(MX28, IO, MT_DEVICE),
+};
+
+/*
+ * This function initializes the memory map. It is called during the
+ * system startup to create static physical to virtual memory mappings
+ * for the IO modules.
+ */
+void __init mx23_map_io(void)
+{
+ iotable_init(mx23_io_desc, ARRAY_SIZE(mx23_io_desc));
+}
+
+void __init mx23_init_irq(void)
+{
+ icoll_init_irq();
+}
+
+void __init mx28_map_io(void)
+{
+ iotable_init(mx28_io_desc, ARRAY_SIZE(mx28_io_desc));
+}
+
+void __init mx28_init_irq(void)
+{
+ icoll_init_irq();
+}
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 0/3] ARM: amba: defining module aliases for AMBA driver autoloading
From: Dave Martin @ 2011-09-30 16:56 UTC (permalink / raw)
To: linux-arm-kernel
There's no special reason why AMBA device drivers should not be
auto-loadable via udev, but udev currently has no way to map AMBA
device IDs to drivers.
As part of the effort to help enable the building of multiple
platforms into a single kernel image in the future, it's desirable
to be able to build any non-critical platform-specific drivers as
modules.
A straightforward solution is to use modaliases to allow udev to
identify the correct driver module to load.
This series adds the needed MODALIAS uevent property when sending
events concerning amba bus devices, and adds appropriate
MODULE_ALIAS() declarations to a couple of modules.
Briefly tested on Versatile Express.
Any comments and feedback are welcome.
Issues:
* Do new module alises need to be globally agreed/registered
somewhere?
* Because a driver's ID table is in match-and-mask format whereas
udev uses string pattern matching, we effectively have to
maintain two ID tables per driver, containing the same
information in different formats. The patch to mmci.c gives an
example.
I predict that maintenance of those duplicated tables will be
somewhat painful and error-prone. However, the necessary
transformations, while simple, are beyond the scope of the C
preprocessor.
In order to avoid this duplication of information, an extra
(but simple) bit of build-time infrastructure would be needed.
I think this effort would be worth it -- does anyone have
strong views on this?
Dave Martin (3):
ARM: amba: pass a suitable modalias to udev
ARM: sound/arm/aaci.c: Define amba module alias
ARM: drivers/mmc/host/mmci.c: Define amba module alias
drivers/amba/bus.c | 9 ++++++++-
drivers/mmc/host/mmci.c | 8 ++++++++
sound/arm/aaci.c | 2 ++
3 files changed, 18 insertions(+), 1 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [RFC PATCH 1/3] ARM: amba: pass a suitable modalias to udev
From: Dave Martin @ 2011-09-30 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317401802-24362-1-git-send-email-dave.martin@linaro.org>
This patch defines and imlpements a new modalias for AMBA devices:
MODALIAS=amba:xxxxxxxx
where 'x' is a hex digit in lower case.
This enables udev to auto-load modules transparently for AMBA
devices, provided that each driver makes suitable MODULE_ALIAS()
declarations based on the supported AMBA device IDs.
Without this, drivers built as modules never get loaded, unless
they are loaded manually.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
drivers/amba/bus.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index d74926e..7d2ba0b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -52,7 +52,14 @@ static int amba_uevent(struct device *dev, struct kobj_uevent_env *env)
int retval = 0;
retval = add_uevent_var(env, "AMBA_ID=%08x", pcdev->periphid);
- return retval;
+ if (retval)
+ return retval;
+
+ retval = add_uevent_var(env, "MODALIAS=amba:%08x", pcdev->periphid);
+ if (retval)
+ return retval;
+
+ return 0;
}
#else
#define amba_uevent NULL
--
1.7.4.1
^ permalink raw reply related
* [RFC PATCH 2/3] ARM: sound/arm/aaci.c: Define amba module alias
From: Dave Martin @ 2011-09-30 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317401802-24362-1-git-send-email-dave.martin@linaro.org>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
sound/arm/aaci.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/arm/aaci.c b/sound/arm/aaci.c
index d0cead3..2e68bfd 100644
--- a/sound/arm/aaci.c
+++ b/sound/arm/aaci.c
@@ -1097,6 +1097,8 @@ static struct amba_id aaci_ids[] = {
{ 0, 0 },
};
+MODULE_ALIAS("amba:???41041");
+
static struct amba_driver aaci_driver = {
.drv = {
.name = DRIVER_NAME,
--
1.7.4.1
^ permalink raw reply related
* [RFC PATCH 3/3] ARM: drivers/mmc/host/mmci.c: Define amba module alias
From: Dave Martin @ 2011-09-30 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317401802-24362-1-git-send-email-dave.martin@linaro.org>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
drivers/mmc/host/mmci.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 56e9a41..ea2a72c 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1477,6 +1477,14 @@ static struct amba_id mmci_ids[] = {
{ 0, 0 },
};
+MODULE_ALIAS("amba:00?41180");
+MODULE_ALIAS("amba:01?41180");
+MODULE_ALIAS("amba:???41181");
+MODULE_ALIAS("amba:??180180");
+MODULE_ALIAS("amba:??280180");
+MODULE_ALIAS("amba:0?480180");
+MODULE_ALIAS("amba:1?480180");
+
static struct amba_driver mmci_driver = {
.drv = {
.name = DRIVER_NAME,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] ARM: CLKDEV: Add Common Macro for clk_lookup
From: H Hartley Sweeten @ 2011-09-30 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317381097-2691-2-git-send-email-padma.v@samsung.com>
On Friday, September 30, 2011 4:12 AM, Padmavathi Venna wrote:
>
> Added a standardized macro CLKDEV_INIT which can used across all
> the platforms to support clkdev
>
> Suggested by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> ---
> include/linux/clkdev.h | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
> index 457bcb0..f2db158 100644
> --- a/include/linux/clkdev.h
> +++ b/include/linux/clkdev.h
> @@ -14,6 +14,13 @@
>
> #include <asm/clkdev.h>
>
> +#define CLKDEV_INIT(d, n, c) \
> + { \
> + .dev_id = d, \
> + .con_id = n, \
> + .clk = &c, \
> + },
> +
> struct clk;
> struct device;
^ permalink raw reply
* [PATCH 2/2] ARM: Switch to using CLKDEV_INIT macro for creating clk_lookup instance
From: H Hartley Sweeten @ 2011-09-30 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317381097-2691-3-git-send-email-padma.v@samsung.com>
On Friday, September 30, 2011 4:12 AM, Padmavathi Venna wrote:
>
> Replace platform specific macros that creates struct clk_lookup
> instance with the new common CLKDEV_INIT macro
>
> Suggested by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
> ---
For the ep93xx part:
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> arch/arm/mach-ep93xx/clock.c | 61 ++++++-------
>
> diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
> index ca4de71..118c905 100644
> --- a/arch/arm/mach-ep93xx/clock.c
> +++ b/arch/arm/mach-ep93xx/clock.c
> @@ -198,39 +198,36 @@ static struct clk clk_m2m1 = {
> .enable_mask = EP93XX_SYSCON_PWRCNT_DMA_M2M1,
> };
>
> -#define INIT_CK(dev,con,ck) \
> - { .dev_id = dev, .con_id = con, .clk = ck }
> -
> static struct clk_lookup clocks[] = {
> - INIT_CK(NULL, "xtali", &clk_xtali),
> - INIT_CK("apb:uart1", NULL, &clk_uart1),
> - INIT_CK("apb:uart2", NULL, &clk_uart2),
> - INIT_CK("apb:uart3", NULL, &clk_uart3),
> - INIT_CK(NULL, "pll1", &clk_pll1),
> - INIT_CK(NULL, "fclk", &clk_f),
> - INIT_CK(NULL, "hclk", &clk_h),
> - INIT_CK(NULL, "apb_pclk", &clk_p),
> - INIT_CK(NULL, "pll2", &clk_pll2),
> - INIT_CK("ep93xx-ohci", NULL, &clk_usb_host),
> - INIT_CK("ep93xx-keypad", NULL, &clk_keypad),
> - INIT_CK("ep93xx-fb", NULL, &clk_video),
> - INIT_CK("ep93xx-spi.0", NULL, &clk_spi),
> - INIT_CK("ep93xx-i2s", "mclk", &clk_i2s_mclk),
> - INIT_CK("ep93xx-i2s", "sclk", &clk_i2s_sclk),
> - INIT_CK("ep93xx-i2s", "lrclk", &clk_i2s_lrclk),
> - INIT_CK(NULL, "pwm_clk", &clk_pwm),
> - INIT_CK(NULL, "m2p0", &clk_m2p0),
> - INIT_CK(NULL, "m2p1", &clk_m2p1),
> - INIT_CK(NULL, "m2p2", &clk_m2p2),
> - INIT_CK(NULL, "m2p3", &clk_m2p3),
> - INIT_CK(NULL, "m2p4", &clk_m2p4),
> - INIT_CK(NULL, "m2p5", &clk_m2p5),
> - INIT_CK(NULL, "m2p6", &clk_m2p6),
> - INIT_CK(NULL, "m2p7", &clk_m2p7),
> - INIT_CK(NULL, "m2p8", &clk_m2p8),
> - INIT_CK(NULL, "m2p9", &clk_m2p9),
> - INIT_CK(NULL, "m2m0", &clk_m2m0),
> - INIT_CK(NULL, "m2m1", &clk_m2m1),
> + CLKDEV_INIT(NULL, "xtali", clk_xtali)
> + CLKDEV_INIT("apb:uart1", NULL, clk_uart1)
> + CLKDEV_INIT("apb:uart2", NULL, clk_uart2)
> + CLKDEV_INIT("apb:uart3", NULL, clk_uart3)
> + CLKDEV_INIT(NULL, "pll1", clk_pll1)
> + CLKDEV_INIT(NULL, "fclk", clk_f)
> + CLKDEV_INIT(NULL, "hclk", clk_h)
> + CLKDEV_INIT(NULL, "apb_pclk", clk_p)
> + CLKDEV_INIT(NULL, "pll2", clk_pll2)
> + CLKDEV_INIT("ep93xx-ohci", NULL, clk_usb_host)
> + CLKDEV_INIT("ep93xx-keypad", NULL, clk_keypad)
> + CLKDEV_INIT("ep93xx-fb", NULL, clk_video)
> + CLKDEV_INIT("ep93xx-spi.0", NULL, clk_spi)
> + CLKDEV_INIT("ep93xx-i2s", "mclk", clk_i2s_mclk)
> + CLKDEV_INIT("ep93xx-i2s", "sclk", clk_i2s_sclk)
> + CLKDEV_INIT("ep93xx-i2s", "lrclk", clk_i2s_lrclk)
> + CLKDEV_INIT(NULL, "pwm_clk", clk_pwm)
> + CLKDEV_INIT(NULL, "m2p0", clk_m2p0)
> + CLKDEV_INIT(NULL, "m2p1", clk_m2p1)
> + CLKDEV_INIT(NULL, "m2p2", clk_m2p2)
> + CLKDEV_INIT(NULL, "m2p3", clk_m2p3)
> + CLKDEV_INIT(NULL, "m2p4", clk_m2p4)
> + CLKDEV_INIT(NULL, "m2p5", clk_m2p5)
> + CLKDEV_INIT(NULL, "m2p6", clk_m2p6)
> + CLKDEV_INIT(NULL, "m2p7", clk_m2p7)
> + CLKDEV_INIT(NULL, "m2p8", clk_m2p8)
> + CLKDEV_INIT(NULL, "m2p9", clk_m2p9)
> + CLKDEV_INIT(NULL, "m2m0", clk_m2m0)
> + CLKDEV_INIT(NULL, "m2m1", clk_m2m1)
> };
>
> static DEFINE_SPINLOCK(clk_lock);
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Grant Likely @ 2011-09-30 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYyyqB6=5M8reqgwpMxXJz5ttXWyOav6K58dQ0CrxwCNA@mail.gmail.com>
On Fri, Sep 30, 2011 at 9:05 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Sep 30, 2011 at 4:07 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> Comments below, some a bit nitpicky, but overall I think it looks
>> good. ?I haven't dug into it nearly deeply enough though. ?:-(
>
> Hopefully we can patch the remaining bugs as we go along ?:-)
>
>>> +/**
>>> + * Looks up a pin control device matching a certain device name or
>>> + * pure device pointer.
>>
>> May as well actually do kerneldoc formatting here on the comment
>> blocks.
>
> OK.
>
>>> +struct pinctrl_dev *get_pctldev_from_dev(struct device *dev,
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const char *devname)
>>
>> Nit: I'm not too fond of a single function doing both name and pointer
>> lookup at the same time. ?Presumably the caller would have one or the
>> other and know what it needs to do. ?I'd prefer to see one by-name
>> function and one by-reference. ?I'm not going to make a big deal about
>> it though.
>
> The caller currently does not know what it has or
> what to do.
>
> This is basically an interator function that is called on
> a member tuple of device and device name to check
> which one you have and return a matching controller
> device for the key you do have.
>
>>> + ? ? /* Register device with sysfs */
>>> + ? ? pctldev->dev.parent = dev;
>>> + ? ? pctldev->dev.bus = &pinctrl_bus;
>>
>> I don't think there is an actual need for a pinctrl bus type. ?There
>> aren't any drivers that are going to be bound to these things which is
>> the primary functionality that a bus type provides. ?Am I missing
>> something?
>
> That is not the reason it's there actually, what we have
> discussed on the mailing list is getting sysfs entries for the same
> reason gpiolib registers a class: handle pin control from userspace,
> we can already see that coming and I already have a use case
> for it. (Modem SIM connector control from userspace daemon.)
>
> So first it was registering a class, then Greg said classes are
> deprecated and we should use a bus instead. So it is
> registering a bus to get sysfs so we can get userspace
> controls.
Sure, but you don't need the bus yet. It can be added when it is
actually needed. I'm not convinced that the sysfs approach is
actually the right interface here (I'm certainly not a fan of the gpio
sysfs i/f), and I'd rather not be putting in unneeded stuff until the
userspace i/f is hammered out.
g.
^ permalink raw reply
* [PATCH 2/2] ARM: Switch to using CLKDEV_INIT macro for creating clk_lookup instance
From: H Hartley Sweeten @ 2011-09-30 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E85B779.7030402@gmail.com>
On Friday, September 30, 2011 5:35 AM, Ryan Mallon wrote:
> On 30/09/11 21:11, Padmavathi Venna wrote:
>> Replace platform specific macros that creates struct clk_lookup
>> instance with the new common CLKDEV_INIT macro
>>
>> Suggested by: Russell King <rmk+kernel@arm.linux.org.uk>
>> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
>> ---
[...]
>> static struct clk_lookup cdce_clks[] = {
>> - CLK(NULL, "xin", &cdce_clk_in),
>> - CLK(NULL, NULL, NULL),
>> + CLKDEV_INIT(NULL, "xin", cdce_clk_in)
>> + {.dev_id = NULL, .con_id = NULL, .clk = NULL,},
>
> Why not CLKDEV_INIT(NULL, NULL, NULL)? Or create another macro
> CLKDEV_NULL (or similar) for the last entry in the list rather than
> duplicating this everywhere.
The CLKDEV_INIT macro does this with the third parameter:
.clk = &c,
I'm not sure &NULL is valid.
Is the sentinel entry actually needed? ep93xx does not have one.
Regards,
Hartley
^ permalink raw reply
* [PATCH-V3 2/4] arm:omap:am33xx: Update common OMAP machine specific sources
From: Kevin Hilman @ 2011-09-30 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930257840691@dbde02.ent.ti.com>
"Premi, Sanjeev" <premi@ti.com> writes:
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org
>> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Hilman, Kevin
>> Sent: Tuesday, September 27, 2011 12:16 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-omap at vger.kernel.org; paul at pwsan.com;
>> tony at atomide.com; linux-arm-kernel at lists.infradead.org;
>> Mohammed, Afzal
>> Subject: Re: [PATCH-V3 2/4] arm:omap:am33xx: Update common
>> OMAP machine specific sources
>>
>> <hvaibhav@ti.com> writes:
>>
>> > From: Afzal Mohammed <afzal@ti.com>
>> >
>> > This patch updates the common machine specific source files for
>> > support for AM33XX/AM335x with cpu type, macros for
>> identification of
>> > AM33XX/AM335X device.
>> >
>> > Signed-off-by: Afzal Mohammed <afzal@ti.com>
>> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>>
>> [...]
>>
>> > @@ -3576,7 +3579,8 @@ int __init omap3xxx_clk_init(void)
>> > * Lock DPLL5 -- here only until other device init code can
>> > * handle this
>> > */
>> > - if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
>> > + if (!cpu_is_ti816x() && !cpu_is_am33xx() &&
>> > + (omap_rev() >= OMAP3430_REV_ES2_0))
>> > omap3_clk_lock_dpll5();
>>
>> This is getting ugly.
>>
>> Instead of continuing to expand this if-list, I think it's time for a
>> new feature-flag for whether or not an SoC has DPLL5 instead.
>
> I agree that the code is really getting ugly here. But, isn't
> feature-flag going to be over-used with this and similar features?
>
> Just thinking ahead, for these possible cases:
> 1) An soc adds DPLL6.
> 2) An soc uses DPLL5, but mechanism to lock is different.
You're right.
> Wouldn't it be better to have a scheme like this:
> 1) Define a simple structure for DPLLs.
> 2) Initialize the unused DPLLs to be null/ -1 early
> in arch/soc specific init.
> 3) The DPLL functions check for corresponding flag on
> entry.
Actually, looking at this closer, I think the infrastructure is already
there to handle this cleanly.
Basically, dpll5 should not even be registered for SoCs where it doesn't
exist. Then, any attempts to use DPLL5 would know it doesn't exist
because the call to clk_get() in omap3_clk_lock_dpll5() would fail.
I think the clock3xxx_data.c needs a bit more cleanup so that only
clocks that exist for a given SoC are registered.
Paul already did a similar cleanup for the powerdomain data files by
creating separate lists for common ones and unique ones. Looks like we
need the same for the clock data.
Patches welcome.
Kevin
^ permalink raw reply
* [PATCH 1/2] ARM: CLKDEV: Add Common Macro for clk_lookup
From: H Hartley Sweeten @ 2011-09-30 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317381097-2691-2-git-send-email-padma.v@samsung.com>
On Friday, September 30, 2011 4:12 AM, Padmavathi Venna wrote:
>
> Added a standardized macro CLKDEV_INIT which can used across all
> the platforms to support clkdev
>
> Suggested by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
> ---
> include/linux/clkdev.h | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
> index 457bcb0..f2db158 100644
> --- a/include/linux/clkdev.h
> +++ b/include/linux/clkdev.h
> @@ -14,6 +14,13 @@
>
> #include <asm/clkdev.h>
>
> +#define CLKDEV_INIT(d, n, c) \
> + { \
> + .dev_id = d, \
> + .con_id = n, \
> + .clk = &c, \
> + },
Padmavathi,
I just noticed you have the ending ',' in the macro. This makes the
clk_lookup tables look a bit strange and hides what each entry in the
table is.
static struct clk_lookup foo_clks[] = {
CLKDEV("bar1_dev", "bar1_con", bar1_clk)
CLKDEV("bar2_dev", "bar2_con", bar2_clk)
...
};
I think this is a bit clearer:
static struct clk_lookup foo_clks[] = {
CLKDEV("bar1_dev", "bar1_con", bar1_clk),
CLKDEV("bar2_dev", "bar2_con", bar2_clk),
...
};
Also, having the macro automatically add the '&' to the clk parameter
hides the fact that it's a pointer. If you remove it CLKDEV(NULL, NULL, NULL)
would then work for the sentinel entry's in mach0-davinci.
Care to remove that comma, and possibly the '&', and redo the patch set?
Regards,
Hartley
^ 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