* [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: Mark Brown @ 2012-11-14 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <331ABD5ECB02734CA317220B2BBEABC13EA6AE51@DBDE01.ent.ti.com>
On Wed, Nov 14, 2012 at 05:01:45AM +0000, AnilKumar, Chimata wrote:
> +Mark
...without any words as to why I'm being added or what the content in
the message is?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121114/770b6120/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/5] clk: exynos4: register clocks using common clock framework
From: Kukjin Kim @ 2012-11-14 5:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349629855-4962-3-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
>
> For legacy Exynos4 platforms, the available clocks are statically
> listed and then registered using the common clock framework. On device
> tree enabled exynos platfotms, the device tree is searched and all
> clock nodes found are registered. Support for Exynos4210 and
> Exynos4x12 platforms is included.
>
> Cc: Mike Turquette <mturquette@ti.com>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> drivers/clk/samsung/Makefile | 1 +
> drivers/clk/samsung/clk-exynos4.c | 647
> +++++++++++++++++++++++++++++++++++++
> 2 files changed, 648 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/samsung/clk-exynos4.c
[...]
> +
> +/* base address of io remapped clock controller register space */
> +static void __iomem *clk_base;
> +
I didn't look at the full details. BTW, you know, clock naming is very
important and there are some comments about that below...
> +static const char *pll_parent_names[] __initdata = { "fin_pll" };
Why is this only 'xxx_parent_names'? not just 'xxx_parents' like others?
> +static const char *fin_pll_parents[] __initdata = { "xxti", "xusbxti" };
> +static const char *mout_apll_parents[] __initdata = { "fin_pll",
> "fout_apll", };
According to original naming, how about clk_src_apll here?
+static const char *clk_src_apll[] __initdata = { "fin_pll", "fout_apll", };
> +static const char *mout_mpll_parents[] __initdata = { "fin_pll",
clk_src_mpll?
> "fout_mpll", };
> +static const char *mout_epll_parents[] __initdata = { "fin_pll",
clk_src_epll?
> "fout_epll", };
> +
> +static const char *sclk_ampll_parents[] __initdata = {
clk_src_aclk?
> + "mout_mpll", "sclk_apll", };
> +
> +static const char *sclk_evpll_parents[] __initdata = {
> + "mout_epll", "mout_vpll", };
> +
> +static const char *mout_core_parents[] __initdata = {
clk_src_core?
Hmm... most of the 'sources' is from out of MUX so mout is not required?...
> + "mout_apll", "mout_mpll", };
> +
> +static const char *mout_mfc_parents[] __initdata = {
> + "mout_mfc0", "mout_mfc1", };
Should be following?
+static const char *clk_src_mfc0[] __initdata = {"mout_mpll", "sclk_apll",
};
+static const char *clk_src_mfc1[] __initdata = {"mout_epll", "sclk_vpll",
};
> +
> +static const char *mout_dac_parents[] __initdata = {
> + "mout_vpll", "sclk_hdmiphy", };
sclk_vpll?
+static const char *clk_src_sclk_dac[] __initdata = {"sclk_vpll",
"sclk_hdmiphy", };
> +
> +static const char *mout_hdmi_parents[] __initdata = {
clk_src_sclk_hdmi?
> + "sclk_pixel", "sclk_hdmiphy", };
> +
> +static const char *mout_mixer_parents[] __initdata = {
clk_src_sclk_mixer?
> + "sclk_dac", "sclk_hdmi", };
> +
> +static const char *group1_parents[] __initdata = {
According to original clock-exynos4.c, just 'group_parents' not
'group1_parents'?
> + "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
Should be 'sclk_hdmi27m' instead of 'sclk_hdmi24m'
+ "xxti", "xusbxti", "sclk_hdmi24m", "sclk_usbphy0",
> + "none", "sclk_hdmiphy", "mout_mpll", "mout_epll",
Missed 'sclk_usbphy1'?
+ "sclk_usbphy1", "sclk_hdmiphy", "mout_mpll", "mout_epll",
> + "mout_vpll" };
> +
> +static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] = {
> + FRATE_CLK(NULL, "xxti", NULL, CLK_IS_ROOT, 24000000),
> + FRATE_CLK(NULL, "xusbxti", NULL, CLK_IS_ROOT, 24000000),
Well, above clock rate depends on board and it means it is not a fixed
value.
> + FRATE_CLK(NULL, "sclk_hdmi24m", NULL, CLK_IS_ROOT, 24000000),
> + FRATE_CLK(NULL, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 27000000),
> + FRATE_CLK(NULL, "sclk_usbphy0", NULL, CLK_IS_ROOT, 48000000),
Missed sclk_hdmi27m?
+ FRATE_CLK(NULL, "sclk_hdmi27m", NULL, CLK_IS_ROOT, 27000000),
> +};
> +
> +static struct samsung_mux_clock exynos4_mux_clks[] = {
[...]
> +};
> +
> +static struct samsung_div_clock exynos4_div_clks[] = {
[...]
> +};
> +
> +struct samsung_gate_clock exynos4_gate_clks[] = {
[...]
> + clk = clk_get(NULL, "fout_apll");
> + samsung_pll_clk_set_cb(clk, NULL, exynos4210_get_rate_apll);
+ samsung_pll_clk_set_cb(clk, NULL, exynos4210_apll_get_rate);
> + clk = clk_get(NULL, "fout_mpll");
+ samsung_pll_clk_set_cb(clk, NULL, exynos4210_mpll_get_rate);
> + samsung_pll_clk_set_cb(clk, NULL, exynos4210_get_rate_mpll);
> + clk = clk_get(NULL, "fout_epll");
> + samsung_pll_clk_set_cb(clk, NULL, exynos4210_get_rate_epll);
+ samsung_pll_clk_set_cb(clk, NULL, exynos4210_epll_get_rate);
> + clk = clk_get(NULL, "fout_vpll");
> + samsung_pll_clk_set_cb(clk, exynos4210_vpll_set_rate,
> + exynos4210_get_rate_mpll);
mpll? Should be vpll?
+ exynos4210_vpll_get_rate); ???
[...]
> + samsung_clk_register_pll("fout_apll", pll_parent_names, NULL,
> + NULL, exynos4210_get_rate_apll);
+ NULL, exynos4210_apll_get_rate);
> + samsung_clk_register_pll("fout_mpll", pll_parent_names, NULL,
> + NULL, exynos4210_get_rate_mpll);
+ NULL, exynos4210_mpll_get_rate);
> + samsung_clk_register_pll("fout_epll", pll_parent_names, NULL,
> + NULL, exynos4210_get_rate_epll);
+ NULL, exynos4210_epll_get_rate);
> + samsung_clk_register_pll("fout_vpll", exynos4210_vpll_parent_names,
> + NULL, exynos4210_vpll_set_rate, exynos4210_get_rate_vpll);
+ NULL, exynos4210_vpll_set_rate, exynos4210_vpll_get_rate);
[...]
> +static unsigned long exynos4x12_get_rate_apll(unsigned long xtal_rate)
exynos4x12_apll_get_rate()
> +{
> + return s5p_get_pll35xx(xtal_rate, __raw_readl(EXYNOS4_APLL_CON0));
> +}
> +
> +static unsigned long exynos4x12_get_rate_mpll(unsigned long xtal_rate)
exynos4x12_mpll_get_rate()
> +{
> + return s5p_get_pll35xx(xtal_rate, __raw_readl(EXYNOS4_MPLL_CON0));
> +}
> +
> +static unsigned long exynos4x12_get_rate_epll(unsigned long xtal_rate)
exynos4x12_epll_get_rate()
> +{
> + return s5p_get_pll36xx(xtal_rate, __raw_readl(EXYNOS4_EPLL_CON0),
> + __raw_readl(EXYNOS4_EPLL_CON1));
> +}
> +
> +static unsigned long exynos4x12_get_rate_vpll(unsigned long vpllsrc_rate)
exynos4x12_vpll_get_rate()
> +{
> + return s5p_get_pll36xx(vpllsrc_rate, __raw_readl(EXYNOS4_VPLL_CON0),
> + __raw_readl(EXYNOS4_VPLL_CON1));
> +}
> +
> +/* Exynos4x12 specific clock registeration */
> +void __init exynos4x12_clk_init(void)
> +{
> + exynos4_clk_init();
> +
> + samsung_clk_register_pll("fout_apll", pll_parent_names, NULL,
> + NULL, exynos4x12_get_rate_apll);
+ NULL, exynos4x12_apll_get_rate);
> + samsung_clk_register_pll("fout_mpll", pll_parent_names, NULL,
> + NULL, exynos4x12_get_rate_mpll);
+ NULL, exynos4x12_mpll_get_rate);
> + samsung_clk_register_pll("fout_epll", pll_parent_names, NULL,
> + NULL, exynos4x12_get_rate_epll);
+ NULL, exynos4x12_epll_get_rate);
> + samsung_clk_register_pll("fout_vpll", pll_parent_names, NULL,
> + NULL, exynos4x12_get_rate_vpll);
+ NULL, exynos4x12_vpll_get_rate);
> +
> + samsung_clk_register_mux(exynos4x12_mux_clks,
> + ARRAY_SIZE(exynos4x12_mux_clks));
> +
> + pr_info("EXYNOS4210: PLL settings: A=%ld, M=%ld, E=%ld, V=%ld\n",
pr_info("EXYNOS4X12:...
> + _get_rate("fout_apll"), _get_rate("fout_mpll"),
> + _get_rate("fout_epll"), _get_rate("fout_vpll"));
> +
> + pr_info("EXYNOS4210: ARMCLK=%ld, ACLK200=%ld, ACLK100=%ld\n"
pr_info("EXYNOS4X12:...
> + " ACLK160=%ld, ACLK133=%ld\n", _get_rate("armclk"),
> + _get_rate("aclk_200"), _get_rate("aclk_100"),
> + _get_rate("aclk_160"), _get_rate("aclk_133"));
> +}
> --
> 1.7.5.4
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
From: AnilKumar, Chimata @ 2012-11-14 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121114022341.GM4415@opensource.wolfsonmicro.com>
On Wed, Nov 14, 2012 at 07:53:42, Mark Brown wrote:
> On Mon, Nov 05, 2012 at 05:59:36PM +0100, Benoit Cousson wrote:
> > On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
>
> > > +Optional properties:
> > > +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
>
> > That sounds like a generic functionality to me. Don't we have some more
> > generic way to handle that?
>
> > If not, that should probably not be a TI only attribute.
>
> It's pretty unusual to have this configurable as a single thing rather
> than as part of flexible power sequencing or something that's just fixed
> in silicon.
>
"[PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver" thread
have the details of how PMIC is connected to RTC module of SoC.
As part of the power_off sequence we have
1. To write STATUS_OFF in TPS65217 PMIC. If we do so then PMIC will
go to shutdown if PWR_EN is pulled-down. (This patch doing this)
2. To pull down the PWR_EN signal we have to set PMIC_PWR_EN in RTC
module and trigger ALARM2 event. (This piece of code in 2/4 patch).
Thanks
AnilKumar
^ permalink raw reply
* [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: AnilKumar, Chimata @ 2012-11-14 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50994156.4080305@ti.com>
+Mark
On Mon, Nov 12, 2012 at 15:17:13, AnilKumar, Chimata wrote:
> On Tue, Nov 06, 2012 at 22:26:54, Cousson, Benoit wrote:
> > Hi Anil,
> >
> > On 11/06/2012 06:07 AM, AnilKumar, Chimata wrote:
> > > On Mon, Nov 05, 2012 at 22:13:25, Cousson, Benoit wrote:
> > >> Hi Anil / Colin,
> > >>
> > >> On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> > >>> From: Colin Foe-Parker <colin.foeparker@logicpd.com>
> > >>>
> > >>> Add system power off control to rtc driver which is the in-charge
> > >>> of controlling the BeagleBone system power. The power_off routine
> > >>> can be hooked up to "pm_power_off" system call.
> > >>>
> > >>> System power off sequence:-
> > >>> * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
> > >>> * Enable PMIC_POWER_EN in rtc module
> > >>> * Set rtc ALARM2 time
> > >>> * Enable ALARM2 interrupt
> > >>>
> > >>> Added while (1); after the above steps to make sure that no other
> > >>> process acquire cpu. Otherwise we might see an unexpected behaviour
> > >>> because we are shutting down all the power rails of SoC except RTC.
> > >>>
> > >>> Signed-off-by: Colin Foe-Parker <colin.foeparker@logicpd.com>
> > >>> [anilkumar at ti.com: move poweroff additions to rtc driver]
> > >>> Signed-off-by: AnilKumar Ch <anilkumar@ti.com>
> > >>> ---
> > >>> Documentation/devicetree/bindings/rtc/rtc-omap.txt | 5 ++
> > >>> drivers/rtc/rtc-omap.c | 79 +++++++++++++++++++-
> > >>> 2 files changed, 83 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > >>> index b47aa41..8d9f4f9 100644
> > >>> --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > >>> +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
> > >>> @@ -6,6 +6,10 @@ Required properties:
> > >>> - interrupts: rtc timer, alarm interrupts in order
> > >>> - interrupt-parent: phandle for the interrupt controller
> > >>>
> > >>> +Optional properties:
> > >>> +- ti,system-power-controller: Telling whether or not rtc is controlling
> > >>> + the system power.
> > >>
> > >> I don't know how it is connected at board level, but I'm not sure the
> > >> binding is the proper one.
> > >
> > > Hi Benoit,
> > > ________________________________
> > > | ______ _______ |
> > > | | | | | |
> > > | |RTC | | | |
> > > | |PMIC | Line | | |
> > > | |PWR_EN|=======>|PWR_EN | |
> > > | |______| |_______| |
> > > | AM335x SoC TPS65217 |
> > > | |
> > > |________________________________|
> > > BeagleBone
> > >
> > > This is how RTC PMIC_PWR_EN is connected to PWR_EN of TPS65217 PMIC. Only when
> > > RTC pull low in PMIC_PWR_EN then PMIC will go to power off state provided TPS65217
> > > status should be changed to STATUS_OFF.
> > >
> > > ALARM2 event should be trigger to configure PMIC_PWR_EN properly then the "Line"
> > > driven low so that PMIC will go to shutdown mode.
> >
> > Thanks for the nice diagram :-)
>
> I missed this mail thread so delayed in response
>
> >
> > I'm wondering if we cannot abuse the gpio binding to describe that
> > connection instead of creating two custom attributes (PMIC + RTC).
> >
> > Ideally we should do that without having to change the RTC to use the
> > gpiolib at all.
> >
> >
> > rtc: rtc at 44e3e000 {
> > compatible = "ti,da830-rtc";
> > reg = <0x44e3e000 0x1000>;
> > interrupts = <75, 76>;
> > ti,hwmods = "rtc";
> >
> > /* expose the PWR_EN functionality of this RTC*/
> > gpio-controller;
> > #gpio-cells = <0>; /* assuming we can use 0 ??? */
> > };
> >
> > ...
> >
> > tps: tps at 24 {
> > compatible = "ti,tps65217";
> > /*
> > * Enable the power enable feature from
> > * the input line if that attribute is there.
> > */
> > gpio-power-en = <&rtc>; /* PWR_EN */
> >
> > ...
> > }
> >
> > Any thought?
>
> No, these two are independent controllers. PMIC can go to power
> off mode if we pull PWR_EN to low. We can pull down that line
> by any means like PRCM or GPIO or some other. So these two flags
> should be independent from each other.
>
> Thanks
> AnilKumar
>
^ permalink raw reply
* [PATCH v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
From: Praveen Paneri @ 2012-11-14 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6zSYM5-GdGHYH=W-My34oXRfH0M+rfettFa0fiit3-_V1RDA@mail.gmail.com>
Hi Kukjin, Felipe,
Since the issue is only with arch patches, which I am going to resolve
asap, Will it be possible for you to consider taking only driver
patches? I can resend arch patches separately to linux-samsung after
updating if Kukjin is also fine with that?
Thanks,
Praveen
On Wed, Nov 14, 2012 at 9:38 AM, Praveen Paneri <p.paneri@samsung.com> wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 10:11 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>> Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>> Hi :-)
>>
>> [...]
>>
>>> Sure, but I still need Kukjin's 'say-so' for the arch/arm/plat-samsung
>>> and arch/arm/mach-exynos part.
>>>
>> Basically, this approach looks OK to me.
>>
>> BTW, I have some comments and need to update...
> Thanks! I highly appreciate your comments. It would have been even
> better if I had got these before the closing bell.
>>
>> From 4th patch...
>>
>>> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-
>>> s3c64xx/mach-smdk6410.c
>>
>> [...]
>>
>>> @@ -72,6 +73,8 @@
>>> #include <linux/platform_data/touchscreen-s3c2410.h>
>>> #include <plat/keypad.h>
>>> #include <plat/backlight.h>
>>> +#include <plat/regs-fb-v4.h>
> Well it comes from an older state where without this it was giving a
> build error. Although it shouldn't have been here. Will fix it.
>>
>> Why? In addition, this causes build error with s3c6400_defconfig.
>>
>> [...]
>>
>>> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
>>> index 03f654d..9cdb666 100644
>>
>> [...]
>>
>>> @@ -1370,6 +1371,30 @@ struct platform_device s5p_device_mixer = {
>>>
>>> /* USB */
>>>
>>> +#ifdef CONFIG_S3C_DEV_USB_HSOTG
>>> +/* USB PHY*/
>>> +static struct resource samsung_usbphy_resource[] = {
>>> + [0] = {
>>> + .start = S3C_PA_USB_PHY,
>>> + .end = S3C_PA_USB_PHY + SZ_16 - 1,
>>> + .flags = IORESOURCE_MEM,
>>> + },
>>> +};
>>
>> +static struct resource samsung_usbphy_resource[] = {
>> + [0] = DEFINED_RES_MEM(S3C_PA_USB_PHY, SZ_16),
>> +};
>>
>> [...]
>>
>> Happens build error with s5pv210_defconfig
>>
>> arch/arm/plat-samsung/devs.c:1375: error: 'S3C_PA_USB_PHY' undeclared here
>> (not in a function)
>> make[2]: *** [arch/arm/plat-samsung/devs.o] Error 1
>> make[1]: *** [arch/arm/plat-samsung] Error 2
>> make[1]: *** Waiting for unfinished jobs....
>>
>> And another build error with exynos_defconfig...
> Will check for both the configs and resolve it.
>
> Thanks,
> Praveen
>>
>> arch/arm/mach-exynos/built-in.o: In function `.LANCHOR1':
>> setup-i2c0.c:(.data+0x8080): undefined reference to
>> `s5p_usb_phy_pmu_isolation'
>>
>> From 5th patch....
>>
>> If possible, please to use 'ARM: [sub-arch dir name]: [subject]' format.
>> So I preferred to use 'ARM: EXYNOS: Enabling samsung-usbphy driver for
>> EXYNOS4210' on that.
>>
>> Please make sure your patch has no problem for kernel compilation before
>> submitting...
>>
>> Thanks.
>>
>> Best regards,
>> Kgene.
>> --
>> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
>> SW Solution Development Team, Samsung Electronics Co., Ltd.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 v7 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
From: Praveen Paneri @ 2012-11-14 4:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004201cdc08f$fa0fd3d0$ee2f7b70$%kim@samsung.com>
Hi,
On Mon, Nov 12, 2012 at 10:11 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Felipe Balbi wrote:
>>
>> Hi,
>>
> Hi :-)
>
> [...]
>
>> Sure, but I still need Kukjin's 'say-so' for the arch/arm/plat-samsung
>> and arch/arm/mach-exynos part.
>>
> Basically, this approach looks OK to me.
>
> BTW, I have some comments and need to update...
Thanks! I highly appreciate your comments. It would have been even
better if I had got these before the closing bell.
>
> From 4th patch...
>
>> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-
>> s3c64xx/mach-smdk6410.c
>
> [...]
>
>> @@ -72,6 +73,8 @@
>> #include <linux/platform_data/touchscreen-s3c2410.h>
>> #include <plat/keypad.h>
>> #include <plat/backlight.h>
>> +#include <plat/regs-fb-v4.h>
Well it comes from an older state where without this it was giving a
build error. Although it shouldn't have been here. Will fix it.
>
> Why? In addition, this causes build error with s3c6400_defconfig.
>
> [...]
>
>> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
>> index 03f654d..9cdb666 100644
>
> [...]
>
>> @@ -1370,6 +1371,30 @@ struct platform_device s5p_device_mixer = {
>>
>> /* USB */
>>
>> +#ifdef CONFIG_S3C_DEV_USB_HSOTG
>> +/* USB PHY*/
>> +static struct resource samsung_usbphy_resource[] = {
>> + [0] = {
>> + .start = S3C_PA_USB_PHY,
>> + .end = S3C_PA_USB_PHY + SZ_16 - 1,
>> + .flags = IORESOURCE_MEM,
>> + },
>> +};
>
> +static struct resource samsung_usbphy_resource[] = {
> + [0] = DEFINED_RES_MEM(S3C_PA_USB_PHY, SZ_16),
> +};
>
> [...]
>
> Happens build error with s5pv210_defconfig
>
> arch/arm/plat-samsung/devs.c:1375: error: 'S3C_PA_USB_PHY' undeclared here
> (not in a function)
> make[2]: *** [arch/arm/plat-samsung/devs.o] Error 1
> make[1]: *** [arch/arm/plat-samsung] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> And another build error with exynos_defconfig...
Will check for both the configs and resolve it.
Thanks,
Praveen
>
> arch/arm/mach-exynos/built-in.o: In function `.LANCHOR1':
> setup-i2c0.c:(.data+0x8080): undefined reference to
> `s5p_usb_phy_pmu_isolation'
>
> From 5th patch....
>
> If possible, please to use 'ARM: [sub-arch dir name]: [subject]' format.
> So I preferred to use 'ARM: EXYNOS: Enabling samsung-usbphy driver for
> EXYNOS4210' on that.
>
> Please make sure your patch has no problem for kernel compilation before
> submitting...
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 01/17] of: add dma-mask binding
From: Rob Herring @ 2012-11-14 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352710357-3265-2-git-send-email-wenyou.yang@atmel.com>
On 11/12/2012 02:52 AM, Wenyou Yang wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> This will allow each device to specify its dma-mask for this we use the
> coherent_dma_mask as pointer. By default the dma-mask will be set to
> DMA_BIT_MASK(32).
Do you really have a use case this is not DMA_BIT_MASK(32)?
> The microblaze architecture hook is drop
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: grant.likely at secretlab.ca
> Cc: rob.herring at calxeda.com
> Cc: devicetree-discuss at lists.ozlabs.org
> ---
> drivers/of/platform.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b80891b..31ed405 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -130,6 +130,21 @@ void of_device_make_bus_id(struct device *dev)
> dev_set_name(dev, "%s.%d", node->name, magic - 1);
> }
>
> +static void of_get_dma_mask(struct device *dev, struct device_node *np)
> +{
> + const __be32 *prop;
> + int len;
> +
> + prop = of_get_property(np, "dma-mask", &len);
dma-ranges may work for this purpose.
> +
> + dev->dma_mask = &dev->coherent_dma_mask;
I don't really know, but I suspect this is wrong.
> +
> + if (!prop)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + else
> + dev->coherent_dma_mask = of_read_number(prop, len / 4);
> +}
> +
> /**
> * of_device_alloc - Allocate and initialize an of_device
> * @np: device node to assign to device
> @@ -171,10 +186,8 @@ struct platform_device *of_device_alloc(struct device_node *np,
> WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
> }
>
> + of_get_dma_mask(&dev->dev, np);
> dev->dev.of_node = of_node_get(np);
> -#if defined(CONFIG_MICROBLAZE)
> - dev->dev.dma_mask = &dev->archdata.dma_mask;
> -#endif
> dev->dev.parent = parent;
>
> if (bus_id)
> @@ -211,10 +224,6 @@ struct platform_device *of_platform_device_create_pdata(
> if (!dev)
> return NULL;
>
> -#if defined(CONFIG_MICROBLAZE)
> - dev->archdata.dma_mask = 0xffffffffUL;
> -#endif
> - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> dev->dev.bus = &platform_bus_type;
> dev->dev.platform_data = platform_data;
>
>
^ permalink raw reply
* [PATCH 2/3] ARM: prima2: Replace include linux/module.h with linux/export.h
From: Barry Song @ 2012-11-14 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352821789-6640-1-git-send-email-s.syam@samsung.com>
> -----Original Message-----
> From: Syam Sidhardhan [mailto:syamsidhardh at gmail.com]
> Sent: Tuesday, November 13, 2012 11:50 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Barry Song
> Subject: [PATCH 2/3] ARM: prima2: Replace include linux/module.h with
> linux/export.h
>
> include <linux/export.h> is the right to go here.
>
> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Acked. Thanks!
> ---
> arch/arm/mach-prima2/pm.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-prima2/pm.c b/arch/arm/mach-prima2/pm.c
> index fb5a791..f4a2270 100644
> --- a/arch/arm/mach-prima2/pm.c
> +++ b/arch/arm/mach-prima2/pm.c
> @@ -9,7 +9,7 @@
> #include <linux/kernel.h>
> #include <linux/suspend.h>
> #include <linux/slab.h>
> -#include <linux/module.h>
> +#include <linux/export.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_device.h>
> --
> 1.7.4.1
-barry
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply
* [PATCH] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
From: Omar Ramirez Luna @ 2012-11-14 2:39 UTC (permalink / raw)
To: linux-arm-kernel
This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk->enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.
According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.
[1] http://lkml.org/lkml/2012/8/20/226
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/clock44xx_data.c | 22 ----------------------
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 ++--
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..067c486 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1316,16 +1316,6 @@ static struct clk dmic_fck = {
.clkdm_name = "abe_clkdm",
};
-static struct clk dsp_fck = {
- .name = "dsp_fck",
- .ops = &clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = "tesla_clkdm",
- .parent = &dpll_iva_m4x2_ck,
- .recalc = &followparent_recalc,
-};
-
static struct clk dss_sys_clk = {
.name = "dss_sys_clk",
.ops = &clkops_omap2_dflt,
@@ -1696,16 +1686,6 @@ static struct clk i2c4_fck = {
.recalc = &followparent_recalc,
};
-static struct clk ipu_fck = {
- .name = "ipu_fck",
- .ops = &clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = "ducati_clkdm",
- .parent = &ducati_clk_mux_ck,
- .recalc = &followparent_recalc,
-};
-
static struct clk iss_ctrlclk = {
.name = "iss_ctrlclk",
.ops = &clkops_omap2_dflt,
@@ -3151,7 +3131,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "div_ts_ck", &div_ts_ck, CK_446X),
CLK(NULL, "dmic_sync_mux_ck", &dmic_sync_mux_ck, CK_443X),
CLK(NULL, "dmic_fck", &dmic_fck, CK_443X),
- CLK(NULL, "dsp_fck", &dsp_fck, CK_443X),
CLK(NULL, "dss_sys_clk", &dss_sys_clk, CK_443X),
CLK(NULL, "dss_tv_clk", &dss_tv_clk, CK_443X),
CLK(NULL, "dss_48mhz_clk", &dss_48mhz_clk, CK_443X),
@@ -3183,7 +3162,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "i2c2_fck", &i2c2_fck, CK_443X),
CLK(NULL, "i2c3_fck", &i2c3_fck, CK_443X),
CLK(NULL, "i2c4_fck", &i2c4_fck, CK_443X),
- CLK(NULL, "ipu_fck", &ipu_fck, CK_443X),
CLK(NULL, "iss_ctrlclk", &iss_ctrlclk, CK_443X),
CLK(NULL, "iss_fck", &iss_fck, CK_443X),
CLK(NULL, "iva_fck", &iva_fck, CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aab5c12..1f61093 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -650,7 +650,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.mpu_irqs = omap44xx_dsp_irqs,
.rst_lines = omap44xx_dsp_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
- .main_clk = "dsp_fck",
+ .main_clk = "dpll_iva_m4x2_ck",
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
@@ -1677,7 +1677,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.mpu_irqs = omap44xx_ipu_irqs,
.rst_lines = omap44xx_ipu_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
- .main_clk = "ipu_fck",
+ .main_clk = "ducati_clk_mux_ck",
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
--
1.7.4.1
^ permalink raw reply related
* [PATCH v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
From: Omar Ramirez Luna @ 2012-11-14 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352860489-19960-1-git-send-email-omar.luna@linaro.org>
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/omap-iommu.c | 1 -
drivers/iommu/omap-iommu.c | 45 ++++++++++++-----------------
drivers/iommu/omap-iommu.h | 3 --
drivers/iommu/omap-iommu2.c | 17 -----------
include/linux/platform_data/iommu-omap.h | 1 -
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
return -ENOMEM;
pdata->name = oh->name;
- pdata->clk_name = oh->main_clk;
pdata->nr_tlb_entries = a->nr_tlb_entries;
pdata->da_start = a->da_start;
pdata->da_end = a->da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 0a6a901..b42b3d1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
#include <linux/slab.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
-#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/iommu.h>
#include <linux/omap-iommu.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
#include <linux/io.h>
+#include <linux/pm_runtime.h>
#include <asm/cacheflush.h>
@@ -160,11 +160,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
err = arch_iommu->enable(obj);
- clk_disable(obj->clk);
return err;
}
@@ -176,11 +175,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj->clk);
-
arch_iommu->disable(obj);
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
if (pdata->assert_reset)
pdata->assert_reset(pdev, pdata->reset_name);
@@ -306,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct iotlb_entry *e)
if (!obj || !obj->nr_tlb_entries || !e)
return -EINVAL;
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
iotlb_lock_get(obj, &l);
if (l.base == obj->nr_tlb_entries) {
@@ -336,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct iotlb_entry *e)
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
return PTR_ERR(cr);
}
@@ -350,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, &l);
out:
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
return err;
}
@@ -380,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
for_each_iotlb_cr(obj, obj->nr_tlb_entries, i, cr) {
u32 start;
@@ -399,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
if (i == obj->nr_tlb_entries)
dev_dbg(obj->dev, "%s: no page for %08x\n", __func__, da);
@@ -413,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
{
struct iotlb_lock l;
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
l.base = 0;
l.vict = 0;
@@ -421,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
iommu_write_reg(obj, 1, MMU_GFLUSH);
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
}
#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -431,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
bytes = arch_iommu->dump_ctx(obj, buf, bytes);
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
return bytes;
}
@@ -449,7 +446,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs *crs, int num)
struct cr_regs tmp;
struct cr_regs *p = crs;
- clk_enable(obj->clk);
+ pm_runtime_get_sync(obj->dev);
iotlb_lock_get(obj, &saved);
for_each_iotlb_cr(obj, num, i, tmp) {
@@ -459,7 +456,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs *crs, int num)
}
iotlb_lock_set(obj, &saved);
- clk_disable(obj->clk);
+ pm_runtime_put_sync(obj->dev);
return p - crs;
}
@@ -816,9 +813,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
if (!obj->refcount)
return IRQ_NONE;
- clk_enable(obj->clk);
errs = iommu_report_fault(obj, &da);
- clk_disable(obj->clk);
if (errs == 0)
return IRQ_HANDLED;
@@ -944,10 +939,6 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev)
if (!obj)
return -ENOMEM;
- obj->clk = clk_get(&pdev->dev, pdata->clk_name);
- if (IS_ERR(obj->clk))
- goto err_clk;
-
obj->nr_tlb_entries = pdata->nr_tlb_entries;
obj->name = pdata->name;
obj->dev = &pdev->dev;
@@ -990,6 +981,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev)
goto err_irq;
platform_set_drvdata(pdev, obj);
+ pm_runtime_irq_safe(obj->dev);
+ pm_runtime_enable(obj->dev);
+
dev_info(&pdev->dev, "%s registered\n", obj->name);
return 0;
@@ -998,8 +992,6 @@ err_irq:
err_ioremap:
release_mem_region(res->start, resource_size(res));
err_mem:
- clk_put(obj->clk);
-err_clk:
kfree(obj);
return err;
}
@@ -1020,7 +1012,8 @@ static int __devexit omap_iommu_remove(struct platform_device *pdev)
release_mem_region(res->start, resource_size(res));
iounmap(obj->regbase);
- clk_put(obj->clk);
+ pm_runtime_disable(obj->dev);
+
dev_info(&pdev->dev, "%s removed\n", obj->name);
kfree(obj);
return 0;
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 2b5f3c0..1200842 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -29,7 +29,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem *regbase;
struct device *dev;
void *isr_priv;
@@ -116,8 +115,6 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index 4a3a1c7..d745094 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -28,15 +28,6 @@
*/
#define IOMMU_ARCH_VERSION 0x00000011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 << MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 << MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 << MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 << MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS & IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 << 4)
#define MMU_IRQ_TABLEWALKFAULT (1 << 3)
@@ -105,11 +96,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj->dev, "%s: version %d.%d\n", obj->name,
(l >> 4) & 0xf, l & 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l &= ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -123,7 +109,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l &= ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj->dev, "%s is shutting down\n", obj->name);
}
@@ -252,8 +237,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/include/linux/platform_data/iommu-omap.h b/include/linux/platform_data/iommu-omap.h
index ef2060d..5b429c4 100644
--- a/include/linux/platform_data/iommu-omap.h
+++ b/include/linux/platform_data/iommu-omap.h
@@ -44,7 +44,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
--
1.7.4.1
^ permalink raw reply related
* [PATCH v4 1/2] ARM: OMAP3/4: iommu: migrate to hwmod framework
From: Omar Ramirez Luna @ 2012-11-14 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352860489-19960-1-git-send-email-omar.luna@linaro.org>
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/omap-iommu.c | 168 +++++++-----------------------
drivers/iommu/omap-iommu.c | 23 +++-
drivers/iommu/omap-iommu2.c | 19 ----
include/linux/platform_data/iommu-omap.h | 8 ++-
5 files changed, 64 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = "isp",
+ .name = "mmu_isp",
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/slab.h>
#include <linux/platform_data/iommu-omap.h>
+#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
-#include "soc.h"
-#include "common.h"
-
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = "isp",
- .nr_tlb_entries = 8,
- .clk_name = "cam_ick",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d000000,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = "iva2",
- .nr_tlb_entries = 32,
- .clk_name = "iva2_ck",
- .da_start = 0x11000000,
- .da_end = 0xFFFFF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = "ducati",
- .nr_tlb_entries = 32,
- .clk_name = "ipu_fck",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
- {
- .base = OMAP4_MMU2_BASE,
- .irq = 28 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = "tesla",
- .nr_tlb_entries = 32,
- .clk_name = "dsp_fck",
- .da_start = 0x0,
- .da_end = 0xFFFFF000,
- },
- },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ struct platform_device *pdev;
+ struct iommu_platform_data *pdata;
+ struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr;
+ static int i;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->name = oh->name;
+ pdata->clk_name = oh->main_clk;
+ pdata->nr_tlb_entries = a->nr_tlb_entries;
+ pdata->da_start = a->da_start;
+ pdata->da_end = a->da_end;
+
+ if (oh->rst_lines_cnt == 1) {
+ pdata->reset_name = oh->rst_lines->name;
+ pdata->assert_reset = omap_device_assert_hardreset;
+ pdata->deassert_reset = omap_device_deassert_hardreset;
+ }
- if (cpu_is_omap34xx()) {
- devices = omap3_devices;
- omap_iommu_pdev = omap3_iommu_pdev;
- num_iommu_devices = NR_OMAP3_IOMMU_DEVICES;
- } else if (cpu_is_omap44xx()) {
- devices = omap4_devices;
- omap_iommu_pdev = omap4_iommu_pdev;
- num_iommu_devices = NR_OMAP4_IOMMU_DEVICES;
- } else
- return -ENODEV;
+ pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata),
+ NULL, 0, 0);
- for (i = 0; i < num_iommu_devices; i++) {
- struct platform_device *pdev;
- const struct iommu_device *d = &devices[i];
+ kfree(pdata);
- pdev = platform_device_alloc("omap-iommu", i);
- if (!pdev) {
- err = -ENOMEM;
- goto err_out;
- }
+ if (IS_ERR(pdev)) {
+ pr_err("%s: device build err: %ld\n", __func__, PTR_ERR(pdev));
+ return PTR_ERR(pdev);
+ }
- res[0].start = d->base;
- res[0].end = d->base + MMU_REG_SIZE - 1;
- res[1].start = res[1].end = d->irq;
+ i++;
- err = platform_device_add_resources(pdev, res,
- ARRAY_SIZE(res));
- if (err)
- goto err_out;
- err = platform_device_add_data(pdev, &d->pdata,
- sizeof(d->pdata));
- if (err)
- goto err_out;
- err = platform_device_add(pdev);
- if (err)
- goto err_out;
- omap_iommu_pdev[i] = pdev;
- }
return 0;
+}
-err_out:
- while (i--)
- platform_device_put(omap_iommu_pdev[i]);
- return err;
+static int __init omap_iommu_init(void)
+{
+ return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
subsys_initcall(omap_iommu_init);
static void __exit omap_iommu_exit(void)
{
- int i;
-
- for (i = 0; i < num_iommu_devices; i++)
- platform_device_unregister(omap_iommu_pdev[i]);
+ /* Do nothing */
}
module_exit(omap_iommu_exit);
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f0aba5b..0a6a901 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -143,13 +143,23 @@ EXPORT_SYMBOL_GPL(omap_iommu_arch_version);
static int iommu_enable(struct omap_iommu *obj)
{
int err;
+ struct platform_device *pdev = to_platform_device(obj->dev);
+ struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (!obj)
+ if (!obj || !pdata)
return -EINVAL;
if (!arch_iommu)
return -ENODEV;
+ if (pdata->deassert_reset) {
+ err = pdata->deassert_reset(pdev, pdata->reset_name);
+ if (err) {
+ dev_err(obj->dev, "deassert_reset failed: %d\n", err);
+ return err;
+ }
+ }
+
clk_enable(obj->clk);
err = arch_iommu->enable(obj);
@@ -160,7 +170,10 @@ static int iommu_enable(struct omap_iommu *obj)
static void iommu_disable(struct omap_iommu *obj)
{
- if (!obj)
+ struct platform_device *pdev = to_platform_device(obj->dev);
+ struct iommu_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!obj || !pdata)
return;
clk_enable(obj->clk);
@@ -168,6 +181,9 @@ static void iommu_disable(struct omap_iommu *obj)
arch_iommu->disable(obj);
clk_disable(obj->clk);
+
+ if (pdata->assert_reset)
+ pdata->assert_reset(pdev, pdata->reset_name);
}
/*
@@ -924,9 +940,6 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev)
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (pdev->num_resources != 2)
- return -EINVAL;
-
obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index c020202..4a3a1c7 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -35,12 +35,8 @@
#define MMU_SYS_IDLE_SMART (2 << MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 << MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 << 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS & IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 << 4)
#define MMU_IRQ_TABLEWALKFAULT (1 << 3)
@@ -97,7 +93,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd, SZ_16K))
return -EINVAL;
@@ -106,20 +101,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l & MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l & MMU_SYS_RESETDONE)) {
- dev_err(obj->dev, "can't take mmu out of reset\n");
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj->dev, "%s: version %d.%d\n", obj->name,
(l >> 4) & 0xf, l & 0xf);
diff --git a/include/linux/platform_data/iommu-omap.h b/include/linux/platform_data/iommu-omap.h
index c677b9f..ef2060d 100644
--- a/include/linux/platform_data/iommu-omap.h
+++ b/include/linux/platform_data/iommu-omap.h
@@ -10,6 +10,8 @@
* published by the Free Software Foundation.
*/
+#include <linux/platform_device.h>
+
#define MMU_REG_SIZE 256
/**
@@ -43,7 +45,11 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
const char *clk_name;
- const int nr_tlb_entries;
+ const char *reset_name;
+ int nr_tlb_entries;
u32 da_start;
u32 da_end;
+
+ int (*assert_reset)(struct platform_device *pdev, const char *name);
+ int (*deassert_reset)(struct platform_device *pdev, const char *name);
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH v4 0/2] OMAP: iommu: hwmod, reset handling and runtime PM
From: Omar Ramirez Luna @ 2012-11-14 2:34 UTC (permalink / raw)
To: linux-arm-kernel
These patches are needed for remoteproc to work on OMAP4.
Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
and routines to deassert reset lines, enable/disable clocks
and configure sysc registers.
For this series I dropped the patches already included in
mainline, along with cleanup and refactoring patches for save and
restore of mmu context, and DT bindings.
Due to single Image support, I rebased these on top of k3.7-rc5 and
DEPEND on:
[PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
http://thread.gmane.org/gmane.linux.kernel/1387788
Minor rebasing might be needed if these are included on top of
linux-omap, since they are affected by changes on headers being
moved to include/linux/platform_data and arch/arm/mach-omap2.
Omar Ramirez Luna (2):
ARM: OMAP3/4: iommu: migrate to hwmod framework
ARM: OMAP3/4: iommu: adapt to runtime pm
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/omap-iommu.c | 167 +++++++-----------------------
drivers/iommu/omap-iommu.c | 68 +++++++------
drivers/iommu/omap-iommu.h | 3 -
drivers/iommu/omap-iommu2.c | 36 -------
include/linux/platform_data/iommu-omap.h | 9 ++-
6 files changed, 82 insertions(+), 203 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH] arm: zynq: add system level control register manager
From: Peter Crosthwaite @ 2012-11-14 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6jFUTYZFHzK5rB578WuTZt9_vUDwW3tieJzifb9-Ch0r2PrQ@mail.gmail.com>
> -----Original Message-----
> From: Daniel Borkmann [mailto:danborkmann at iogearbox.net]
> Sent: Wednesday, November 14, 2012 5:25 AM
> To: Josh Cartwright
> Cc: Josh Cartwright; Arnd Bergmann; Michal Simek; John Linn; linux-arm-
> kernel at lists.infradead.org; Peter Crosthwaite
> Subject: Re: [PATCH] arm: zynq: add system level control register
> manager
>
> On Tue, Nov 13, 2012 at 7:37 PM, Josh Cartwright
> <josh.cartwright@ni.com> wrote:
> > On Fri, Nov 09, 2012 at 10:49:07AM +0100, Daniel Borkmann wrote:
> >> On Thu, Nov 8, 2012 at 5:01 PM, Josh Cartwright <joshc@eso.teric.us>
> wrote:
> >> > On Wed, Oct 31, 2012 at 07:36:12PM +0100, Daniel Borkmann wrote:
> >> >> This patch for the Xilinx Zynq ARM architecture adds management
> of system
> >> >> level control register. The code is taken from the Xilinx-
> internal Linux
> >> >> Git tree and cleaned up a bit for mainline integration. Besides
> others,
> >> >> this patch is needed in order to integrate further drivers for
> Zynq such as
> >> >> the Zynq xemacps networking device driver. The patch is aganst
> the latest
> >> >> arm-soc tree.
> >> >>
> >> >> Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
> >> >> Cc: Michal Simek <michals@xilinx.com>
> >> >> Cc: John Linn <john.linn@xilinx.com>
> >> >> Cc: Arnd Bergmann <arnd@arndb.de>
> >> >> ---
> >> >
> >> > These changes will conflict with my pending clk patchset [1], as
> I'm
> >> > introducing bindings for the SLCR (and its clk interfaces).
> >>
> >> Oops, okay. Then your's has priority, of course.
> >
> > I did not mean to discourage. I just meant to say that we should
> work
> > out how this work can be done on top of the clk changes.
> >
> >> > It seems like a hefty chunk of the out-of-tree slcr driver is
> related to
> >> > configuring MIO. I think it would be really nice if this driver
> was
> >> > reworked to use the pinctrl subsystem, and also to provide
> suitable
> >> > device tree bindings.
> >>
> >> Agreed. If there's a chance to help with further Zynq integration
> and
> >> to develop this driver with testing on Qemu for ARM Zynq, I'd like
> to
> >> give it a try. (The board is a bit expensive as a hobby only.)
> >
> > My concern is that, especially regarding the configuration of MIO,
> being
> > able to do adequate testing will require real hardware. It isn't
> clear
> > to me what the state of qemu's slcr/mio model is.
>
> I added Peter Crosthwaite into CC, since he could provide an answer to
> that (I've been told).
Hi Daniel, Josh,
MIO functionality is not modeled at all in QEMU SLCR. The bounds of QEMU zynq stop before the MIO switch so all devices are always present and connected concurrently (impossible with real hw). There are dummy registers for all the MIO controls in SLCR, so your driver shouldn't crash anything, but everything will just be a NOP.
SLCR Peripheral resets and clock controls are also not modeled (the latter doesn't mean a lot anyway). SLCR doesn't really do much in the end, apart from the CPU reset and halt capabilities needed for SMP linux, and we have a few bits for the bootmode switch and the OCM remapping that are still out of tree.
Regards,
Peter
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
From: Mark Brown @ 2012-11-14 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097F078.50701@ti.com>
On Mon, Nov 05, 2012 at 05:59:36PM +0100, Benoit Cousson wrote:
> On 11/05/2012 10:42 AM, AnilKumar Ch wrote:
> > +Optional properties:
> > +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
> That sounds like a generic functionality to me. Don't we have some more
> generic way to handle that?
> If not, that should probably not be a TI only attribute.
It's pretty unusual to have this configurable as a single thing rather
than as part of flexible power sequencing or something that's just fixed
in silicon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121114/dbbb5772/attachment.sig>
^ permalink raw reply
* [GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2
From: Mark Brown @ 2012-11-14 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211131027.11062.arnd@arndb.de>
On Tue, Nov 13, 2012 at 10:27:10AM +0000, Arnd Bergmann wrote:
> I'm not planning to pull this one into somewhere else, just want to make
> sure that you remeber it's been pulled into arm-soc. You mentioned above
> that having a tag helps you with your bookkeeping.
It's not that it's particularly helpful for my bookkeeping (I rarely if
ever look at the tags), it's more that if I've not signed a tag then it
means that I'm either not aware of or not OK with the branch being used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121114/44a0a8ca/attachment.sig>
^ permalink raw reply
* [PATCH V2] ARM: tegra: retain L2 content over CPU suspend/resume
From: Joseph Lo @ 2012-11-14 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113115809.GA18622@elf.ucw.cz>
On Tue, 2012-11-13 at 19:58 +0800, Pavel Machek wrote:
> On Tue 2012-11-13 10:04:48, Joseph Lo wrote:
> > The L2 RAM is in different power domain from the CPU cluster. So the
> > L2 content can be retained over CPU suspend/resume. To do that, we
> > need to disable L2 after the MMU is disabled, and enable L2 before
> > the MMU is enabled. But the L2 controller is in the same power domain
> > with the CPU cluster. We need to restore it's settings and re-enable
> > it after the power be resumed.
>
> Is it good idea to retain L2 over suspend? I guess this is
> power-vs-speed balance...?
>
Hi Pavel,
Thanks for your review. Because one of the Tegra's CPU idle state will
shut off the CPU power, it only contain CPU cluster, L1$, GIC and L2
controller. The L2 ram is still powered. The L2 flush is a slow
operation at low frequency. The CPU idle "power-down" state is likely to
happen often at low frequency for low power use case (e.g. low power
audio playback). So yes, it's power-vs-speed balance.
For the system-wide sleep mode (i.e. suspend), the power of L2 RAM would
be shut off at the deepest sleep mode. There would be different
procedure to handle L2.
Thanks,
Joseph
^ permalink raw reply
* [PATCH v4 9/9] pinctrl: single: dump pinmux register value
From: Haojian Zhuang @ 2012-11-14 1:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113173444.GB6801@atomide.com>
On Wed, Nov 14, 2012 at 1:34 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [121113 05:10]:
>> On Thu, Nov 8, 2012 at 2:25 AM, Tony Lindgren <tony@atomide.com> wrote:
>>
>> > * Haojian Zhuang <haojian.zhuang@gmail.com> [121107 07:22]:
>> >> Dump pinmux register value, not only function part in the pinmux
>> >> register.
>> >>
>> >> Also fix the issue on caluclating pin offset. The last parameter
>> >> should be pin number, not register offset.
>> >
>> > Acked-by: Tony Lindgren <tony@atomide.com>
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Shall I apply this to the pinctrl tree?
>
> Yes please.
>
> Regards,
>
> Tony
Yes, this patch doesn't impact others. Please help to merge.
^ permalink raw reply
* [PATCH v4 2/9] pinctrl: single: support gpio request and free
From: Haojian Zhuang @ 2012-11-14 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121113173404.GA6801@atomide.com>
On Wed, Nov 14, 2012 at 1:34 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [121113 05:09]:
>> On Wed, Nov 7, 2012 at 11:27 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Haojian Zhuang <haojian.zhuang@gmail.com> [121107 07:21]:
>> >> Marvell's PXA/MMP silicon also match the behavior of pinctrl-single.
>> >> Each pin binds to one register. A lot of pins could be configured
>> >> as gpio.
>> >>
>> >> Now add these properties in below.
>> >> <gpio range phandle>:
>> >> include "pinctrl-single,gpio" & "pinctrl,gpio-func" properties.
>> >>
>> >> pinctrl-single,gpio: <gpio base, npins in range, register offset>
>> >>
>> >> pinctrl-single,gpio-func: <gpio function value in mux>
>> >>
>> >> pinctrl-single,gpio-ranges: phandle list of gpio range array
>> >
>> > This one looks OK to me now:
>> >
>> > Acked-by: Tony Lindgren <tony@atomide.com>
>> >
>>
>> So:
>> - Will this patch in isolation apply to my pinctrl tree?
>> - In that case, do you want me to apply it?
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> I guess the best way to go is if Linus applies this and
> the debugfs fix one into some immutable pinctrl branch that
> various SoC branches can pull in as needed.
>
> The generic pinconf patch still needs few updates.
>
> Regards,
>
> Tony
>
I prefer to hold on this patch since I found some gpio range code are
also contained in the
pinconf patch. I'll merge them together in the next round.
^ permalink raw reply
* [GIT PULL] ARM: OMAP4: PM: basic support for core retention in suspend
From: Tony Lindgren @ 2012-11-14 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zk2ldlt6.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121113 17:20]:
> Tony,
>
> The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
>
> Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-omap4-core-ret
>
> for you to fetch changes up to 4fd7a41233eac62b10ede394b35d8919086f94ec:
>
> ARM: OMAP4: USB: power down MUSB PHY during boot (2012-11-13 15:57:09 -0800)
>
> ----------------------------------------------------------------
> Add support for full-chip retention in suspend for OMAP4 SoCs.
Thanks pulling into omap-for-v3.8/pm-part2.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] ARM: OMAP4: PM: basic support for core retention in suspend
From: Kevin Hilman @ 2012-11-14 1:18 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-omap4-core-ret
for you to fetch changes up to 4fd7a41233eac62b10ede394b35d8919086f94ec:
ARM: OMAP4: USB: power down MUSB PHY during boot (2012-11-13 15:57:09 -0800)
----------------------------------------------------------------
Add support for full-chip retention in suspend for OMAP4 SoCs.
----------------------------------------------------------------
Rajendra Nayak (1):
ARM: OMAP4: suspend: Program all domains to retention
Tero Kristo (1):
ARM: OMAP4: USB: power down MUSB PHY during boot
arch/arm/mach-omap2/omap_phy_internal.c | 32 ++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/pm44xx.c | 7 -------
2 files changed, 32 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH v3 5/7] crypto: omap-sham: Convert to use pm_runtime API
From: Kevin Hilman @ 2012-11-14 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352257033-32495-6-git-send-email-mgreer@animalcreek.com>
Hi Mark,
"Mark A. Greer" <mgreer@animalcreek.com> writes:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Convert the omap-sham crypto driver to use the
> pm_runtime API instead of the clk API.
>
> CC: Kevin Hilman <khilman@deeprootsystems.com>
> CC: Paul Walmsley <paul@pwsan.com>
> CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: Kevin Hilman <khilman@ti.com>
This looks much better and is more obviously a straight forward clock
API --> runtime PM conversion.
Thanks,
Kevin
> ---
> drivers/crypto/omap-sham.c | 28 +++++++++++-----------------
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index a3fd6fc..85d43b2 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -22,12 +22,12 @@
> #include <linux/errno.h>
> #include <linux/interrupt.h>
> #include <linux/kernel.h>
> -#include <linux/clk.h>
> #include <linux/irq.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> #include <linux/scatterlist.h>
> #include <linux/dma-mapping.h>
> +#include <linux/pm_runtime.h>
> #include <linux/delay.h>
> #include <linux/crypto.h>
> #include <linux/cryptohash.h>
> @@ -141,7 +141,6 @@ struct omap_sham_dev {
> struct device *dev;
> void __iomem *io_base;
> int irq;
> - struct clk *iclk;
> spinlock_t lock;
> int err;
> int dma;
> @@ -238,7 +237,7 @@ static void omap_sham_copy_ready_hash(struct ahash_request *req)
>
> static int omap_sham_hw_init(struct omap_sham_dev *dd)
> {
> - clk_enable(dd->iclk);
> + pm_runtime_get_sync(dd->dev);
>
> if (!test_bit(FLAGS_INIT, &dd->flags)) {
> omap_sham_write_mask(dd, SHA_REG_MASK,
> @@ -653,7 +652,8 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
> /* atomic operation is not needed here */
> dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
> BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
> - clk_disable(dd->iclk);
> +
> + pm_runtime_put_sync(dd->dev);
>
> if (req->base.complete)
> req->base.complete(&req->base, err);
> @@ -1198,14 +1198,6 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> if (err)
> goto dma_err;
>
> - /* Initializing the clock */
> - dd->iclk = clk_get(dev, "ick");
> - if (IS_ERR(dd->iclk)) {
> - dev_err(dev, "clock intialization failed.\n");
> - err = PTR_ERR(dd->iclk);
> - goto clk_err;
> - }
> -
> dd->io_base = ioremap(dd->phys_base, SZ_4K);
> if (!dd->io_base) {
> dev_err(dev, "can't ioremap\n");
> @@ -1213,11 +1205,14 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> goto io_err;
> }
>
> - clk_enable(dd->iclk);
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
> +
> dev_info(dev, "hw accel on OMAP rev %u.%u\n",
> (omap_sham_read(dd, SHA_REG_REV) & SHA_REG_REV_MAJOR) >> 4,
> omap_sham_read(dd, SHA_REG_REV) & SHA_REG_REV_MINOR);
> - clk_disable(dd->iclk);
> +
> + pm_runtime_put_sync(&pdev->dev);
>
> spin_lock(&sham.lock);
> list_add_tail(&dd->list, &sham.dev_list);
> @@ -1235,9 +1230,8 @@ err_algs:
> for (j = 0; j < i; j++)
> crypto_unregister_ahash(&algs[j]);
> iounmap(dd->io_base);
> + pm_runtime_disable(dev);
> io_err:
> - clk_put(dd->iclk);
> -clk_err:
> omap_sham_dma_cleanup(dd);
> dma_err:
> if (dd->irq >= 0)
> @@ -1266,7 +1260,7 @@ static int __devexit omap_sham_remove(struct platform_device *pdev)
> crypto_unregister_ahash(&algs[i]);
> tasklet_kill(&dd->done_task);
> iounmap(dd->io_base);
> - clk_put(dd->iclk);
> + pm_runtime_disable(&pdev->dev);
> omap_sham_dma_cleanup(dd);
> if (dd->irq >= 0)
> free_irq(dd->irq, dd);
^ permalink raw reply
* OMAP baseline test results for v3.7-rc5
From: Kevin Hilman @ 2012-11-14 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112225830.GW6801@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Paul Walmsley <paul@pwsan.com> [121112 11:33]:
>>
>> Here are some basic OMAP test results for Linux v3.7-rc5.
>> Logs and other details at:
>>
>> http://www.pwsan.com/omap/testlogs/test_v3.7-rc5/20121111081034/
>>
>>
>> Passing tests
>> -------------
>>
>> Boot to userspace (9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
>> 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone
>>
>> PM ret/off, suspend + dynamic idle (2/4): 3730beaglexm, 37xxevm
>>
>>
>> Failing tests: fixed by posted patches
>> --------------------------------------
>>
>> Boot tests:
>>
>> * 3530ES3 Beagle: I2C timeouts during userspace init
>> - Intermittent, appears on 5 out of 6 boots here
>> - Aaro Koskinen observes this also on N900
>> - Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
>> - http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
>> - http://marc.info/?l=linux-omap&m=135197877112220&w=2
>> - Revert posted, pending I2C maintainers:
>> - http://marc.info/?l=linux-arm-kernel&m=135221953727077&w=2
>
> Here's one more booting issue I recently ran into:
>
> - If DEBUG_LL and earlyprintk are enabled, and omap-serial.c
> is compiled as a module, the kernel boot hangs early as the
> clocks for serial port are cut while earlyprintk still uses
> the port. This might be regression from v3.6.
>
Can you test if the patch below[1] helps? With that, it seems to finish
booting for me (based solely on a ping test.)
The problem is a race between the late_initcall for omap_device (which
idles devices that have no drivers) and the late_initcall in
kernel/printk.c which turns off the earlyconsole. Any printks
that happen between this omap_device late initcall and the earlyconsole
late initcall will crash when accessing the UART.
Kevin
[1]
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7a7d1f2..138114a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -1275,4 +1275,4 @@ static int __init omap_device_late_init(void)
bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle);
return 0;
}
-late_initcall(omap_device_late_init);
+late_initcall_sync(omap_device_late_init);
^ permalink raw reply related
* [PATCH V2 4/5] arm: mm: Added support for PJ4B cpu and init routines
From: Russell King - ARM Linux @ 2012-11-14 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351545108-18954-5-git-send-email-gregory.clement@free-electrons.com>
On Mon, Oct 29, 2012 at 10:11:47PM +0100, Gregory CLEMENT wrote:
> + /* Auxiliary Debug Modes Control 2 Register */
> + mrc p15, 1, r0, c15, c1, 2
> + bic r0, r0, #(1 << 23) @ Enable fast LDR.
> + orr r0, r0, #(1 << 25) @ Dont interleave write and snoop data.
> + orr r0, r0, #(1 << 27) @ Disable Critical Word First feature.
> + orr r0, r0, #(1 << 29) @ Disable outstanding non cacheable request
> + orr r0, r0, #(1 << 30) @ L1 replacement - Strict round robin
This just looks silly to me - setting five bits with five instructions
when they can all be done in one instruction. Yes, I know you want
to comment it, but there's other ways to achieve that.
> +__v7_pj4b_proc_info:
> + .long 0x562f5842
> + .long 0xffffffff
Same comment here as Will :)
^ permalink raw reply
* [PATCH V2 2/5] arm: mvebu: Added initial support for power managmement service unit
From: Russell King - ARM Linux @ 2012-11-14 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105140558.GP3351@mudshark.cambridge.arm.com>
On Mon, Nov 05, 2012 at 02:05:58PM +0000, Will Deacon wrote:
> On Mon, Oct 29, 2012 at 09:11:45PM +0000, Gregory CLEMENT wrote:
> > +#ifdef CONFIG_SMP
> > +int armada_xp_boot_cpu(unsigned int cpu_id, void __iomem *boot_addr)
> > +{
> > + int reg, hw_cpu;
> > +
> > + if (!pmsu_mp_base || !pmsu_reset_base) {
> > + pr_warn("Can't boot CPU. PMSU is uninitialized\n");
> > + return 1;
> > + }
> > +
> > + hw_cpu = cpu_logical_map(cpu_id);
> > +
> > + writel(virt_to_phys(boot_addr), pmsu_mp_base +
> > + PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
>
> virt_to_phys on an __iomem * doesn't feel right to me...
It isn't correct - I suspect the __iomem there is just wrong - and it
needs the callsite also checking.
> > + /* Make sure value hits memory before reset */
> > + dsb();
>
> writel has barrier semantics -- you shouldn't need this dsb.
writel has a barrier before the write (to ensure that DMA agents see data
that was written to memory when they are enabled by the write). There
isn't a barrier after the write.
^ permalink raw reply
* [PATCHv2] ARM: OMAP4: USB: power down MUSB PHY during boot
From: Kevin Hilman @ 2012-11-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109143033.GB10718@arwen.pp.htv.fi>
Felipe Balbi <balbi@ti.com> writes:
> HI,
>
> On Fri, Nov 09, 2012 at 04:30:35PM +0200, Tero Kristo wrote:
>> Commit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB
>> PHY functions for OMAP4, but this causes a problem with core retention
>> as the MUSB module remains enabled if omap-usb2 phy driver is not used.
>> This keeps the USB DPLL enabled and prevents l3_init pwrdm from idling.
>>
>> Fixed by adding a minimal function back that disables the USB PHY during
>> boot.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Cc: Kishon Vijay Abraham I <kishon@ti.com>
>> Cc: Felipe Balbi <balbi@ti.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Kevin Hilman <khilman@ti.com>
>
> looks good to me. I would still suggest adding a REVISIT or FIXME note
> stating that this should be moved to SCM driver eventually ;-)
>
> Other than that:
>
> Acked-by: Felipe Balbi <balbi@ti.com>
Thanks will try to get this in for v3.8 along with the original patch
4/9 which gets full-chip retention working on OMAP4.
Kevin
^ 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