Re: [PATCH v2] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
On Wednesday 13 March 2013 11:12 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: Kevin, On Wednesday 13 February 2013 02:25 PM, Santosh Shilimkar wrote: Current CPU PM code code make use of common cpu_suspend() path for all the CPU power states which is not optimal. In fact cpu_suspend() path is needed only when we put CPU power domain to off state where the CPU context is lost. Update the code accordingly so that the expensive cpu_suspend() path can be avoided for the shallow CPU power states like CPU PD INA/CSWR. The patch has been tested on OMAP4430 and OMAP5430(with few out of tree patches) devices for suspend and CPUidle. Cc: Kevin Hilman khil...@deeprootsystems.com Reported-by: Richard Woodruff r-woodru...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Update changelog to include testing details as suggested by Kevin Hilman. Ping. It can get into rc's but since it is not strict regression, and if it has to wait for 3.10 then I can add this one along with rest of the PM patches posted towards 3.10 Either way, let me know. I have this updated one queued for v3.10 in my PM cleanup branch (for_3.10/cleanup/pm) Thanks Kevin. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy
On Thursday 14 March 2013 12:01 AM, Thomas Gleixner wrote: On Wed, 13 Mar 2013, Santosh Shilimkar wrote: On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote: Though making the rating of the dummy lower is definitely a good thing, so a real hardware device which is detected later can replace the dummy device. So yes, the rating should be low for the dummy timer. Exactly. As Mark pointed out, you have already applied Mark's patch. I was just wondering whether you can take the $subject patch as well with ack from Russell, Mark. It can go through the ARM tree as well, no dependencies on my stuff. Sure. I will push that through ARM tree. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data
On Wednesday 13 March 2013 10:16 PM, Benoit Cousson wrote: Hi Sourav, I've just applied your branch after a minor subject cleanup for consistency. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.10/dts Thanks for the tree Benoit. I shall update my v2 DT series against this branch then. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] usb: otg: twl4030: use devres API for regulator get and request irq
Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 04b732e2..5b20bb4 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -470,7 +470,7 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 3.1V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
- twl-usb3v1 = regulator_get(twl-dev, usb3v1);
+ twl-usb3v1 = devm_regulator_get(twl-dev, usb3v1);
if (IS_ERR(twl-usb3v1))
return -ENODEV;
@@ -479,18 +479,18 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 1.5V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
- twl-usb1v5 = regulator_get(twl-dev, usb1v5);
+ twl-usb1v5 = devm_regulator_get(twl-dev, usb1v5);
if (IS_ERR(twl-usb1v5))
- goto fail1;
+ return -ENODEV;
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
/* Initialize 1.8V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
- twl-usb1v8 = regulator_get(twl-dev, usb1v8);
+ twl-usb1v8 = devm_regulator_get(twl-dev, usb1v8);
if (IS_ERR(twl-usb1v8))
- goto fail2;
+ return -ENODEV;
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
@@ -499,14 +499,6 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
TWL4030_PM_MASTER_PROTECT_KEY);
return 0;
-
-fail2:
- regulator_put(twl-usb1v5);
- twl-usb1v5 = NULL;
-fail1:
- regulator_put(twl-usb3v1);
- twl-usb3v1 = NULL;
- return -ENODEV;
}
static ssize_t twl4030_usb_vbus_show(struct device *dev,
@@ -695,9 +687,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* need both handles, otherwise just one suffices.
*/
twl-irq_enabled = true;
- status = request_threaded_irq(twl-irq, NULL, twl4030_usb_irq,
- IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
- IRQF_ONESHOT, twl4030_usb, twl);
+ status = devm_request_threaded_irq(twl-dev, twl-irq, NULL,
+ twl4030_usb_irq, IRQF_TRIGGER_FALLING |
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, twl4030_usb, twl);
if (status 0) {
dev_dbg(pdev-dev, can't get IRQ %d, err %d\n,
twl-irq, status);
@@ -716,7 +708,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
int val;
cancel_delayed_work(twl-id_workaround_work);
- free_irq(twl-irq, twl);
device_remove_file(twl-dev, dev_attr_vbus);
/* set transceiver mode to power on defaults */
@@ -738,9 +729,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
if (!twl-asleep)
twl4030_phy_power(twl, 0);
- regulator_put(twl-usb1v5);
- regulator_put(twl-usb1v8);
- regulator_put(twl-usb3v1);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] usb: musb: omap: add usb_phy_init in omap2430_musb_init
Some PHYs load too early (twl4030) making omap glue to miss cable connect events if the board is booted with cable connected. So adding usb_phy_init in omap2430_musb_init lets PHYs to report events once glue is ready. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/musb/omap2430.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 6071484..8876741 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb) if (glue-status != OMAP_MUSB_UNKNOWN) omap_musb_set_mailbox(glue); + usb_phy_init(musb-xceiv); + pm_runtime_put_noidle(musb-controller); return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] usb: otg: twl4030: fix cold plug on OMAP3
Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is ready.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 5b20bb4..4040124 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -565,8 +565,9 @@ static void twl4030_id_workaround_work(struct work_struct
*work)
}
}
-static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+static int twl4030_usb_phy_init(struct usb_phy *phy)
{
+ struct twl4030_usb *twl = phy_to_twl(phy);
enum omap_musb_vbus_id_status status;
/*
@@ -581,6 +582,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
omap_musb_mailbox(twl-linkstat);
sysfs_notify(twl-dev-kobj, NULL, vbus);
+ return 0;
}
static int twl4030_set_suspend(struct usb_phy *x, int suspend)
@@ -657,6 +659,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.otg= otg;
twl-phy.type = USB_PHY_TYPE_USB2;
twl-phy.set_suspend= twl4030_set_suspend;
+ twl-phy.init = twl4030_usb_phy_init;
otg-phy= twl-phy;
otg-set_host = twl4030_set_host;
@@ -696,8 +699,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
- twl4030_usb_phy_init(twl);
-
dev_info(pdev-dev, Initialized TWL4030 USB module\n);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] usb: musb/otg: cleanup and fixes
This series has some misc cleanup and fixes. The fix solves the cold plug issue in omap3 which some have reported. Developed these patches on fixes-for-v3.9-rc3 after applying http://www.spinics.net/lists/linux-usb/msg81563.html (Grazvydas Ignotas patch series) Tested for g_zero enumeration in pandaboard and beagleboard in both cold plug and hot plug case. Any kind of testing for this series is welcome. Changes from v1: * removed *usb: musb: omap: remove the check before calling otg_set_vbus* a similar patch is already merged. Kishon Vijay Abraham I (4): usb: musb: omap: remove the check before calling otg_set_vbus usb: otg: twl4030: use devres API for regulator get and request irq usb: musb: omap: add usb_phy_init in omap2430_musb_init usb: otg: twl4030: fix cold plug on OMAP3 drivers/usb/musb/omap2430.c | 11 +-- drivers/usb/otg/twl4030-usb.c | 35 --- 2 files changed, 17 insertions(+), 29 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] usb: musb: omap: remove the check before calling otg_set_vbus
No functional change. otg_set_vbus is already protected so removed the
check before calling otg_set_vbus.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 29014c0..6071484 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -174,8 +174,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int
is_on)
}
}
- if (otg-set_vbus)
- otg_set_vbus(otg, 1);
+ otg_set_vbus(otg, 1);
} else {
musb-is_active = 1;
otg-default_a = 1;
@@ -297,10 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
}
omap2430_musb_set_vbus(musb, 0);
- if (data-interface_type == MUSB_INTERFACE_UTMI) {
- if (musb-xceiv-otg-set_vbus)
- otg_set_vbus(musb-xceiv-otg, 0);
- }
+ if (data-interface_type == MUSB_INTERFACE_UTMI)
+ otg_set_vbus(musb-xceiv-otg, 0);
omap_control_usb_set_mode(glue-control_otghs,
USB_MODE_DISCONNECT);
break;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
Will,
On Wednesday 13 March 2013 05:59 PM, Lokesh Vutla wrote:
Hi Dietmar,
On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote:
On 13/03/13 06:52, Lokesh Vutla wrote:
Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for
self-hosted
debug} introduces debug powerdown support for self-hosted debug.
While merging the patch 'has_ossr' check was removed which
was needed for hardwares which doesn't support self-hosted debug.
Pandaboard (A9) is one such hardware and Dietmar's orginial
patch did mention this issue.
Without that check on Panda with CPUIDLE enabled, a flood of
below messages thrown.
[ 3.597930] hw-breakpoint: CPU 0 failed to disable vector catch
[ 3.597991] hw-breakpoint: CPU 1 failed to disable vector catch
Hi Lokesh,
I confirm that this has_ossr condition has to go back into the
pm_init(void) call. I just verified it again on my Panda board and I get
the same issue like you without it.
I guess what was happening is that Will asked me if this check is really
necessary and I said No without re-testing on my Panda board as an V7
debug architecture example where OSSR is not implemented. Since then I
only tested in on V7.1 debug architectures where OSSR is mandatory.
Sorry about this and thanks for catching this.
Thanks for confirming..:)
Can you please queue this one for 3.9-rc2+ ? Without this patch
CPUIDLE is unusable on OMAP4 devices because of those flood
of warning messages.
I was also wondering whether we should just warn once rather
than continuous warnings in the notifier. Patch is end of the
email.
Regards,
Santosh
From b8db63f786719aef835f1ef4e20f3b3406b99b62 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Thu, 14 Mar 2013 13:03:25 +0530
Subject: [PATCH] ARM: hw_breakpoints: Use warn_once to avoid message flood on
unsupported ossr machines
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/kernel/hw_breakpoint.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 96093b7..5dc1aa6 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -966,7 +966,7 @@ static void reset_ctrl_regs(void *unused)
}
if (err) {
- pr_warning(CPU %d debug is powered down!\n, cpu);
+ pr_warn_once(CPU %d debug is powered down!\n, cpu);
cpumask_or(debug_err_mask, debug_err_mask, cpumask_of(cpu));
return;
}
@@ -987,7 +987,7 @@ clear_vcr:
isb();
if (cpumask_intersects(debug_err_mask, cpumask_of(cpu))) {
- pr_warning(CPU %d failed to disable vector catch\n, cpu);
+ pr_warn_once(CPU %d failed to disable vector catch\n, cpu);
return;
}
@@ -1007,7 +1007,7 @@ clear_vcr:
}
if (cpumask_intersects(debug_err_mask, cpumask_of(cpu))) {
- pr_warning(CPU %d failed to clear debug register pairs\n,
cpu);
+ pr_warn_once(CPU %d failed to clear debug register pairs\n,
cpu);
return;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop select MACH_NOKIA_RM696
On Mon, 2013-03-11 at 09:33 -0700, Tony Lindgren wrote: * Paul Bolle pebo...@tiscali.nl [130309 11:52]: In the meantime, how do you prefer I solve the (trivial) issue of an useless select for MACH_NOKIA_RM696? Drop that select or add an (equally useless) config entry for MACH_NOKIA_RM696? Or should I try to ignore it for the time being? Just adding the config MACH_NOKIA_RM696 to Kconfig as bool should fix this unless I'm missing something here. Yes, that should do. I already promised to draft that small patch last week. I hope to actually do that shortly. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 03/14] mailbox: OMAP: introduce mailbox framework
On Wed, Mar 13, 2013 at 10:34 PM, Anna, Suman s-a...@ti.com wrote: On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna s-a...@ti.com wrote: From: Omar Ramirez Luna omar.l...@linaro.org (...) Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org [s-a...@ti.com: Kconfig fixes for build errors] Signed-off-by: Suman Anna s-a...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Linus Walleij linus.wall...@linaro.org It's not like I care super-much, but I think your SoB should be at the bottom. It's a simple git rebase -i anyway... Sure, will do. Only this patch, right? I have my SoB only on one another original patch, will adjust on that as well, but all the remaining ones will have yours at the bottom. No I mean that the SoB-order should reflect the code flow path, and yours should be at the bottom of all of them, but as noted I don't care much. In my case the only thing I did was to pass the code :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/2] Add mandatory regulator for all users of pwm-backlight.
On 03/13/2013 11:33 PM, Andrew Chew wrote: Many backlights are enabled via GPIO. We can generalize the GPIO to a fixed regulator. The enable regulator needs to be mandatory because there was no good way to determine the difference between opting out of the regulator, and probe deferral. This series of patches is intended to add a dummy regulator (or a GPIO regulator) for all users of the pwm-backlight. The last patch in the series will always be the pwm-backlight change to add this mandatory regulator. Patches following up to that patch add the mandatory regulator on a per mach family basis. Once all users of pwm-backlight have been patched, this series can be applied in order to maintain bisectability. I'm not really happy with the mandatory regulator since for example the SDP4430 should not need one... Other than that the backlight works after the series. To both patch: Tested-by: Peter Ujfalusi peter.ujfal...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy
On Thu, 14 Mar 2013, Santosh Shilimkar wrote: On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote: On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote: On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 03:46 PM, Mark Rutland wrote: Hi Santosh, [..] Is the problem that the dummy timer is being registered as the broadcast source, or that it is selected as a local timer in preference of real timers? Dummy timer is preferred over real broadcast timer. Ok. [...] I do agree it'd be worth lowering the dummy timer's rating to ensure it doesn't override a real timer elsewhere. Yep. Can I add you acked-by tag then for $subject patch ? Would be good to get this one merged as well. Sure. Though could you reword the commit message? The patch solves the more general issue of a dummy being preferred over real hardware even outside of choosing the broadcast device. Acked-by: Mark Rutland mark.rutl...@arm.com Thanks. For record, patch is in end of the email which I plan to put into patch system. Regards, Santosh From 57c501bcdc88c7ff26a5c63956be07e94a5083c5 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Wed, 13 Mar 2013 12:33:16 +0530 Subject: [PATCH 1/2] ARM: smp: Avoid dummy clockevent being preferred over real hardware clock-event With recent arm broadcast time clean-up from Mark Rutland, the dummy broadcast device is always registered with timer subsystem. And since the rating of the dummy clock event is very high, it may be preferred over a real clock event. This is a change in behavior from past and not an intended one. So reduce the rating of the dummy clockevent so that real clockevent device is selected when available. Acked-by: Mark Rutland mark.rutl...@arm.com Acked-by: Thomas Gleixner t...@linutronix.de Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/smp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 31644f1..79078ed 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -480,7 +480,7 @@ static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt) evt-features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_DUMMY; - evt-rating = 400; + evt-rating = 100; evt-mult = 1; evt-set_mode = broadcast_timer_set_mode; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.
I think what you treat as lockup is the fixup process. UBIFS basically
reads the entire UBI volume and writes it back. And it uses the atomic
change UBI service, which means it also calculates CRC of everything it
writes. And this all just takes a lot of time. This has to be done only
once on the first mount.
I've attached the following:
1. The patch which fixes the issue when I use nandsim. It is also
inlined in the end. Please, give it a try and be more patient -
wait longer. Please, do report your results back.
2. 'reproduce.sh' - a quick and dirty shell script which reproduces the
problem
3. ubinize.cfg - is needed for 'reproduce.sh'.
Thanks!
From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Thu, 14 Mar 2013 10:49:23 +0200
Subject: [PATCH] UBIFS: make space fixup work in the remount case
The UBIFS space fixup is a useful feature which allows to fixup the broken
flash space at the time of the first mount. The broken space is usually the
result of using a dumb industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.
The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
(see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
flag and re-writes the entire media atomically, which may take really a lot
of time.
3. UBIFS clears the fixup flag in the superblock.
This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Cc: sta...@vger.kernel.org # 3.0+
---
fs/ubifs/super.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..fa4aec6 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,10 +1568,17 @@ static int ubifs_remount_rw(struct ubifs_info *c)
c-remounting_rw = 1;
c-ro_mount = 0;
+ if (c-space_fixup) {
+ err = ubifs_fixup_free_space(c);
+ if (err)
+ return err;
+ }
+
err = check_free_space(c);
if (err)
goto out;
+
if (c-old_leb_cnt != c-leb_cnt) {
struct ubifs_sb_node *sup;
@@ -1684,12 +1691,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
err = dbg_check_space_info(c);
}
- if (c-space_fixup) {
- err = ubifs_fixup_free_space(c);
- if (err)
- goto out;
- }
-
mutex_unlock(c-umount_mutex);
return err;
--
1.7.7.6
--
Best Regards,
Artem Bityutskiy
From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Thu, 14 Mar 2013 10:49:23 +0200
Subject: [PATCH] UBIFS: make space fixup work in the remount case
The UBIFS space fixup is a useful feature which allows to fixup the broken
flash space at the time of the first mount. The broken space is usually the
result of using a dumb industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.
The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
(see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
flag and re-writes the entire media atomically, which may take really a lot
of time.
3. UBIFS clears the fixup flag in the superblock.
This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.0+
---
fs/ubifs/super.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index
Re: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver
(Looping Greg KH.)
Greg,
On Wednesday 20 February 2013 09:14 PM, Santosh Shilimkar wrote:
On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART IP slave idle handling now taken care by runtime pm backend(hwmod
layer)
so remove the hackery from the driver.
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Rajendra nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/tty/serial/omap-serial.c | 23 ---
1 file changed, 23 deletions(-)
This patch should also remove the hooks from
linux/platform_data/serial-omap.h
Right. Will fix that in next version. Thanks.
Sorry for not CC'ing first place
The subject patch is part of the series which cleans up the slave
idle handling from OMAP serial driver. It will be best to queue
it along with rest of the patches with your ack on $subject patch.
Here is the updated version which also removed the hooks
from 'linux/platform_data/serial-omap.h' as per Kevin suggestion.
From 92916b8e0d895962c88fefbf99284967a4b94426 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 15 Feb 2013 15:50:37 +0530
Subject: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from the
driver
UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Tested-by: Vaibhav Bedia vaibhav.be...@ti.com
Tested-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Rajendra nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/tty/serial/omap-serial.c | 23 ---
include/linux/platform_data/serial-omap.h |2 --
2 files changed, 25 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 4dc4140..08332f3 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -202,26 +202,6 @@ static int serial_omap_get_context_loss_count(struct
uart_omap_port *up)
return pdata-get_context_loss_count(up-dev);
}
-static void serial_omap_set_forceidle(struct uart_omap_port *up)
-{
- struct omap_uart_port_info *pdata = up-dev-platform_data;
-
- if (!pdata || !pdata-set_forceidle)
- return;
-
- pdata-set_forceidle(up-dev);
-}
-
-static void serial_omap_set_noidle(struct uart_omap_port *up)
-{
- struct omap_uart_port_info *pdata = up-dev-platform_data;
-
- if (!pdata || !pdata-set_noidle)
- return;
-
- pdata-set_noidle(up-dev);
-}
-
static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
{
struct omap_uart_port_info *pdata = up-dev-platform_data;
@@ -298,8 +278,6 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
- serial_omap_set_forceidle(up);
-
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
}
@@ -364,7 +342,6 @@ static void serial_omap_start_tx(struct uart_port *port)
pm_runtime_get_sync(up-dev);
serial_omap_enable_ier_thri(up);
- serial_omap_set_noidle(up);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
}
diff --git a/include/linux/platform_data/serial-omap.h
b/include/linux/platform_data/serial-omap.h
index ff9b0aa..c860c1b 100644
--- a/include/linux/platform_data/serial-omap.h
+++ b/include/linux/platform_data/serial-omap.h
@@ -43,8 +43,6 @@ struct omap_uart_port_info {
int DTR_present;
int (*get_context_loss_count)(struct device *);
- void (*set_forceidle)(struct device *);
- void (*set_noidle)(struct device *);
void (*enable_wakeup)(struct device *, bool);
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On 14/03/13 09:13, Artem Bityutskiy wrote: On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote: Sorry ... this just locks up the unit. OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details below. The patch I proposed did not get the error path correctly, but it does fix the issue. I think what you treat as lockup is the fixup process. UBIFS basically reads the entire UBI volume and writes it back. And it uses the atomic change UBI service, which means it also calculates CRC of everything it writes. And this all just takes a lot of time. This has to be done only once on the first mount. Okay ... I've retried, but how long is a lot of time ? I've waited 15 minutes and still nothing. And I can see that there's no activity on the NAND chip select !?! I'll put some debug info into the fixup routines to see if I can trace what's going on. Regards Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
On 3/13/2013 3:04 PM, Mark Jackson wrote: On 18/02/13 08:19, Mugunthan V N wrote: CPDMA interrupts are not properly acknowledged which leads to interrupt storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are used for rx and tx respectively. Reported-by: Pantelis Antonioupa...@antoniou-consulting.com Signed-off-by: Mugunthan V Nmugunthan...@ti.com Not sure if I'm seeing this same problem [1], but it doesn't appear fixed to me. I've tried both mainline -rc2 and -next. [1]https://lkml.org/lkml/2013/3/12/376 Without this patch, PG2.0 was not usable as CPSW interrupt was never acked and CPU spent most of the time in CPSW ISR. I have checked -rc2 and it is working fine. Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
On 14/03/13 10:21, Mugunthan V N wrote: On 3/13/2013 3:04 PM, Mark Jackson wrote: On 18/02/13 08:19, Mugunthan V N wrote: CPDMA interrupts are not properly acknowledged which leads to interrupt storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver. Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are used for rx and tx respectively. Reported-by: Pantelis Antonioupa...@antoniou-consulting.com Signed-off-by: Mugunthan V Nmugunthan...@ti.com Not sure if I'm seeing this same problem [1], but it doesn't appear fixed to me. I've tried both mainline -rc2 and -next. [1]https://lkml.org/lkml/2013/3/12/376 Without this patch, PG2.0 was not usable as CPSW interrupt was never acked and CPU spent most of the time in CPSW ISR. I have checked -rc2 and it is working fine. I needed to add patch [1] to fix my problem. See thread [2]. [1] https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0 [2] https://lkml.org/lkml/2013/3/13/146 Cheers Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy
On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote: On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote: On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 03:46 PM, Mark Rutland wrote: Hi Santosh, [..] Is the problem that the dummy timer is being registered as the broadcast source, or that it is selected as a local timer in preference of real timers? Dummy timer is preferred over real broadcast timer. Ok. [...] I do agree it'd be worth lowering the dummy timer's rating to ensure it doesn't override a real timer elsewhere. Yep. Can I add you acked-by tag then for $subject patch ? Would be good to get this one merged as well. Sure. Though could you reword the commit message? The patch solves the more general issue of a dummy being preferred over real hardware even outside of choosing the broadcast device. Acked-by: Mark Rutland mark.rutl...@arm.com Thanks. For record, patch is in end of the email which I plan to put into patch system. Regards, Santosh The below patch seems fine. Are you intending for this to go in as a fix for 3.9-rc*, or as a cleanup for 3.10? If you're aiming for the latter, it's going to clash with Stephen Boyd's local timer API removal [1], in which the generic dummy timer driver [2] (replacing the arm-specific dummy [3]) also has a rating of 100. It would be nice if we could reduce the possibility of a conflict. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/154724.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/154725.html [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/154726.html Thanks, Mark. From 57c501bcdc88c7ff26a5c63956be07e94a5083c5 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Wed, 13 Mar 2013 12:33:16 +0530 Subject: [PATCH 1/2] ARM: smp: Avoid dummy clockevent being preferred over real hardware clock-event With recent arm broadcast time clean-up from Mark Rutland, the dummy broadcast device is always registered with timer subsystem. And since the rating of the dummy clock event is very high, it may be preferred over a real clock event. This is a change in behavior from past and not an intended one. So reduce the rating of the dummy clockevent so that real clockevent device is selected when available. Acked-by: Mark Rutland mark.rutl...@arm.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/kernel/smp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 31644f1..79078ed 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -480,7 +480,7 @@ static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt) evt-features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_DUMMY; - evt-rating = 400; + evt-rating = 100; evt-mult = 1; evt-set_mode = broadcast_timer_set_mode; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote: On 14/03/13 09:13, Artem Bityutskiy wrote: On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote: Sorry ... this just locks up the unit. OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details below. The patch I proposed did not get the error path correctly, but it does fix the issue. I think what you treat as lockup is the fixup process. UBIFS basically reads the entire UBI volume and writes it back. And it uses the atomic change UBI service, which means it also calculates CRC of everything it writes. And this all just takes a lot of time. This has to be done only once on the first mount. Okay ... I've retried, but how long is a lot of time ? I've waited 15 minutes and still nothing. And I can see that there's no activity on the NAND chip select !?! I'll put some debug info into the fixup routines to see if I can trace what's going on. Just to make sure - try this last patch I sent. I did test it with nandsim at least, and I am sure it works. I did not test at all the first one. And yes, debug messages would be useful, just do not forget to add the 'ignore_loglevel' kernel boot option, otherwise you won't see the messages on your console, since they are of KERN_DEBUG level. You may have other issues which cause lockup, e.g., in driver level. It makes sense to validate your flash with MTD test modules. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/1] omap usb host platform_data cleanup
Hello guys, This is v2 of my patch https://patchwork.kernel.org/patch/1232871/ rebased on v3.9-rc2. Removes deprecated flags and structures and saves few bytes of memory. Regards, Ruslan Ruslan Bilovol (1): omap: usb: host: remove deprecated flags and structures include/linux/platform_data/usb-omap.h | 20 1 file changed, 20 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] omap: usb: host: remove deprecated flags and structures
These flags and structures are deprecated and there is
no anymore users of them, so it's safe to remove them.
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
include/linux/platform_data/usb-omap.h | 20
1 file changed, 20 deletions(-)
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index fa579b4..4c7acbe 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -38,34 +38,14 @@ enum usbhs_omap_port_mode {
OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
};
-struct usbtll_omap_platform_data {
- enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
-};
-
-struct ehci_hcd_omap_platform_data {
- enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
- int reset_gpio_port[OMAP3_HS_USB_PORTS];
- struct regulator*regulator[OMAP3_HS_USB_PORTS];
- unsignedphy_reset:1;
-};
-
-struct ohci_hcd_omap_platform_data {
- enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
- unsignedes2_compatibility:1;
-};
-
struct usbhs_omap_platform_data {
int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
int reset_gpio_port[OMAP3_HS_USB_PORTS];
struct regulator*regulator[OMAP3_HS_USB_PORTS];
- struct ehci_hcd_omap_platform_data *ehci_data;
- struct ohci_hcd_omap_platform_data *ohci_data;
-
/* OMAP3 = ES2.1 have a single ulpi bypass control bit */
unsigned single_ulpi_bypass:1;
- unsigned es2_compatibility:1;
unsigned phy_reset:1;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Felipe Balbi ba...@ti.com
CC: Kukjin Kim kgene@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 66ca9ac..b03f609 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos-dev = dev;
exynos-clk = clk;
- clk_enable(exynos-clk);
+ clk_prepare_enable(exynos-clk);
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
@@ -146,7 +146,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return 0;
err2:
- clk_disable(clk);
+ clk_disable_unprepare(clk);
err1:
return ret;
}
@@ -158,7 +158,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
- clk_disable(exynos-clk);
+ clk_disable_unprepare(exynos-clk);
return 0;
}
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] dwc3: exynos: Device tree fixes
This patch-set modifies dwc3-exynos as per latest bindings available for dwc3. Now the dwc3 core also has device support, there's no need to add platform device for core in glue layers. This change has come as a result of discussion happened in: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node. Additionally, now that Samsung exynos series has moved to common clock framework, we use clock_prepare_enable() and clock_disable_unprepare() APIs. Some cleanup is also done here. Based on 'usb-next' plus Felipe's 'testing' branch patches; (some 194 patches in fact ;-), on top of 3.9rc2 tag). Also based on: usb: dwc3: set dma_mask for dwc3_omap device by Kishon in which DMA mask for dwc3-core is being set from its parent. Vivek Gautam (2): usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare drivers/usb/dwc3/dwc3-exynos.c | 54 ++-- 1 files changed, 19 insertions(+), 35 deletions(-) -- 1.7.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: dwc3: exynos: use clk_prepare_enable and clk_disable_unprepare
Hi, On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote: Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Felipe Balbi ba...@ti.com CC: Kukjin Kim kgene@samsung.com --- drivers/usb/dwc3/dwc3-exynos.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 66ca9ac..b03f609 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -129,7 +129,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev) exynos-dev = dev; exynos-clk = clk; - clk_enable(exynos-clk); + clk_prepare_enable(exynos-clk); eventually we need to pass this clock handling to dwc3/core.c. Just make sure it's optional since not all platforms need it. I guess the best way would be to handle clocks via -runtime_suspend()/-runtime_resume() ?? -- balbi signature.asc Description: Digital signature
Re: MTD : Kernel oops when remounting ubifs as read/write
On 14/03/13 10:30, Artem Bityutskiy wrote:
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
On 14/03/13 09:13, Artem Bityutskiy wrote:
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.
I think what you treat as lockup is the fixup process. UBIFS basically
reads the entire UBI volume and writes it back. And it uses the atomic
change UBI service, which means it also calculates CRC of everything it
writes. And this all just takes a lot of time. This has to be done only
once on the first mount.
Okay ... I've retried, but how long is a lot of time ?
I've waited 15 minutes and still nothing.
And I can see that there's no activity on the NAND chip select !?!
I'll put some debug info into the fixup routines to see if I can trace
what's going on.
Just to make sure - try this last patch I sent. I did test it with
nandsim at least, and I am sure it works. I did not test at all the
first one.
And yes, debug messages would be useful, just do not forget to add the
'ignore_loglevel' kernel boot option, otherwise you won't see the
messages on your console, since they are of KERN_DEBUG level.
You may have other issues which cause lockup, e.g., in driver level. It
makes sense to validate your flash with MTD test modules.
My first initial findings ...
I added some simple printk(KERN_INFO) lines to fixup_free_space(), and when
I remount, it gets as far as:-
printk(KERN_INFO ffs 7\n);
/* Fixup LEBs in the main area */
for (lnum = c-main_first; lnum c-leb_cnt; lnum++) {
lprops = ubifs_lpt_lookup(c, lnum);
if (IS_ERR(lprops)) {
err = PTR_ERR(lprops);
goto out;
}
if (lprops-free 0) {
err = fixup_leb(c, lnum, c-leb_size - lprops-free);
if (err)
goto out;
}
}
out:
printk(KERN_INFO ffs x\n);
ubifs_release_lprops(c);
return err;
}
... before we get an oops with crc32_le(). See the full log below.
I'll keep digging ...
Regards
Mark J.
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-next-20130225-2-g678576f-dirty
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #40 Thu Mar 14
10:58:28 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
AM335x BeagleBone
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c059c7b0, node_mem_map
c0ac6000
[0.00] Normal zone: 512 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off
mem=256M rootwait=1 ubi.mtd=6,2048 rootfstype=ubifs root=ubi0:rootfs
ignore_loglevel
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247768k/247768k available, 14376k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] .text : 0xc0008000 - 0xc05194ac (5190 kB)
[0.00] .init : 0xc051a000 - 0xc054bfbc ( 200 kB)
[0.00] .data : 0xc054c000 - 0xc059d360 ( 325 kB)
[0.00].bss : 0xc059d360 - 0xc0ac21a0 (5268 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 2600 Hz
[0.00] sched_clock: 32 bits at 26MHz,
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote: [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte= [ 28.545173] Internal error: Oops: 7 [#1] ARM [ 28.549685] CPU: 0Not tainted (3.8.0-next-20130225-2-g678576f-dirty #40) [ 28.557595] PC is at crc32_le+0x50/0x168 [ 28.561735] LR is at ubi_eba_atomic_leb_change+0x1b4/0x410 [ 28.567523] pc : [c01e7244]lr : [c026dd9c]psr: 2013 [ 28.567523] sp : cf385de0 ip : 180a985a fp : c054f840 [ 28.579632] r10: c054f040 r9 : c054fc40 r8 : 158a1232 [ 28.585141] r7 : 4d506705 r6 : 9324fd72 r5 : 4dc8a10b r4 : 4c162691 [ 28.592025] r3 : c054e040 r2 : c054f440 r1 : d08ea000 r0 : 4c8ee09f [ 28.598912] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 28.606439] Control: 10c5387d Table: 8f3b8019 DAC: 0015 [ 28.612501] Process mount (pid: 659, stack limit = 0xcf384238) [ 28.618652] Stack: (0xcf385de0 to 0xcf386000) [ 28.623254] 5de0: cf2f8554 d08e6e8c 180a9e88 5a257c4f 58399ee9 c8d98a08 bb0ee864 [ 28.631886] 5e00: eae10678 c054fc40 c054f040 c054f840 cf2f8000 d08caffc 3c00 [ 28.640517] 5e20: cf2f8000 cf357c00 000c cf2ec000 000c cf2f8554 [ 28.649148] 5e40: d08cb000 0001e000 d08cb000 8000 0001e000 [ 28.657779] 5e60: 000c d08cb000 0080 000c 000c 0020 [ 28.666409] 5e80: 8000 c026c41c 0001e000 cf33 cf33 d08cb000 0001e000 c0179b14 [ 28.675042] 5ea0: 000d c0177a68 0001e000 cf33 cf330b20 000d c0179698 [ 28.683672] 5ec0: cf33 cf330a9c cf385f48 c0175170 0001 6013 [ 28.692303] 5ee0: cf32c800 cf385f48 0020 c00c9e24 [ 28.700934] 5f00: 00100100 00200200 cf3a6c80 8000 cf384000 00208020 cf01a200 [ 28.709564] 5f20: cf32c800 c00e3d6c 000c cf32c840 c0013968 cf31fb80 [ 28.718195] 5f40: 000c cf01a210 ce828858 000c cf3ac000 000a18b4 [ 28.726827] 5f60: 00208020 c0013968 cf384000 0003 c00e3e40 c0071e24 [ 28.735459] 5f80: cf31fb80 cf31fbc0 a010 bed87b68 b6ff148c [ 28.744091] 5fa0: 0015 c00137c0 bed87b68 000a18b4 000a18c0 000a18c2 00208020 [ 28.752720] 5fc0: bed87b68 b6ff148c 0015 0003 [ 28.761350] 5fe0: b6fa3f48 bed87a64 00042994 b6fa3f58 a010 000a18b4 [ 28.769989] [c01e7244] (crc32_le+0x50/0x168) from [cf2f8000] (0xcf2f8000) [ 28.777522] Code: e58d8008 0a26 e1a0c005 e58d2004 (e5916004) [ 28.784029] ---[ end trace f50f53afffe647f1 ]--- OK, this is an independent problem which, as I think, has nothing to do with the first one. I do not know why crc32 oopses on your system. You need to investigate this. I believe this is not UBI/UBIFS's fault. One theory could be that UBI uses vmalloc'ed buffers for the atomic update operation, and submits the buffer to the MTD layer for the I/O. If your NAND driver is trying to DMA this memory, you may be in trouble, because vmalloced memory is often not DMA-able on many systems, especially ARM systems which do not have coherent cache support. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control
-Original Message- From: Hiremath, Vaibhav Sent: Monday, March 04, 2013 5:06 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; khil...@linaro.org; p...@pwsan.com; Nayak, Rajendra; linux-arm-ker...@lists.infradead.org; Hiremath, Vaibhav Subject: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control From: Vaibhav Hiremath hvaib...@ti.com Currently there is no clean mechanism to control debugSS module and you have to always keep clocks enabled, either, - By enabling it during boot as part of clk_init function (post common-clock migration). Or - By having HWMOD_INIT_NO_IDLE flag in hwmod data (Joel submitted patch for AM335x earlier). Based on the discussion with Kevin H, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg81771.html This patch introduces new kernel parameter omap_debugss_en, which will allow user to control debugSS module enable/disable part during boot-time. In case of OMAP3, the debugSS is part of EMU domain and is currently controlled by clock tree alone. In case of OMAP4, the debugSS is part of EMU domain and is currently controlled by clock tree, as MODULEMODE_SWCTRL is not defined for hwmod. In case of AM335x, the debugSS is in wakeup domain and is currently controlled through hwmod alone. Currently we keep it always enabled. Testing: - Tested on AM335x based EVM and BeagleBone platform As required, without this flag the debugSS module will be disabled during kernel boot. OMAP (2/3/4) may require some changes from clock/hwmod perspective in order to use this new parameter. I am still looking into OMAP spec and this RFC version of patch-series is to get comments or opinion from list. Vaibhav Hiremath (3): ARM: AM33XX: clock: Add debugSS clock nodes to clock tree ARM: AM33XX: hwmod: Add hwmod data for debugSS ARM: OMAP2+: Add command line parameter for debugSS module control Documentation/kernel-parameters.txt|3 + arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/cclock33xx_data.c | 47 +++-- arch/arm/mach-omap2/debugss.c | 80 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 5 files changed, 173 insertions(+), 28 deletions(-) create mode 100644 arch/arm/mach-omap2/debugss.c Kevin/Tony, Any comments or input on this patch series? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.9-rc1
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, March 12, 2013 10:10 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: OMAP baseline test results for v3.9-rc1 Here are some basic OMAP test results for Linux v3.9-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/ Test summary Build: FAIL ( 4/16): am33xx_only, omap1_defconfig, This requires some cleanup in Makefile and Kconfig handling, Either you disable SMP support for non-SMP devices like AM33xx OR Fix the Makefile to resolve the build dependencies (may not be trivial) OR Make functions __weak so that build will go through. I have created below patch, if it is ok with you then I can Submit patch for the same (build tested with am33xx_only and omap2plus_defconfig). diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 0a6b9c7..cb0d55d 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -233,9 +233,9 @@ extern void omap_do_wfi(void); /* Needed for secondary core boot */ extern void omap_secondary_startup(void); extern void omap_secondary_startup_4460(void); -extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); -extern void omap_auxcoreboot_addr(u32 cpu_addr); -extern u32 omap_read_auxcoreboot0(void); +extern u32 __weak omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask); +extern void __weak omap_auxcoreboot_addr(u32 cpu_addr); +extern u32 __weak omap_read_auxcoreboot0(void); extern void omap4_cpu_die(unsigned int cpu); @@ -249,7 +249,7 @@ extern int omap4_mpuss_init(void); extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state); extern int omap4_finish_suspend(unsigned long cpu_state); extern void omap4_cpu_resume(void); -extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state); +extern int __weak omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state); extern u32 omap4_mpuss_read_prev_context_state(void); #else static inline int omap4_enter_lowpower(unsigned int cpu, diff --git a/arch/arm/mach-omap2/omap-wakeupgen.h b/arch/arm/mach-omap2/omap-wakeupgen.h index b0fd16f..94f5281 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.h +++ b/arch/arm/mach-omap2/omap-wakeupgen.h @@ -33,6 +33,6 @@ #define OMAP_TIMESTAMPCYCLEHI 0xc0c extern int __init omap_wakeupgen_init(void); -extern void __iomem *omap_get_wakeupgen_base(void); -extern int omap_secure_apis_support(void); +extern void __weak __iomem *omap_get_wakeupgen_base(void); +extern int __weak omap_secure_apis_support(void); #endif Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.9-rc1
On Thursday 14 March 2013 04:59 PM, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, March 12, 2013 10:10 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Subject: OMAP baseline test results for v3.9-rc1 Here are some basic OMAP test results for Linux v3.9-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/ Test summary Build: FAIL ( 4/16): am33xx_only, omap1_defconfig, This requires some cleanup in Makefile and Kconfig handling, Either you disable SMP support for non-SMP devices like AM33xx OR Fix the Makefile to resolve the build dependencies (may not be trivial) This one... Better things is not to build the OMAP4 files for AM33XX only build. Even if it is not trivial, its right way of fixing the issue. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: dwc3: exynos: Use of_platform API to create dwc3 core pdev
On Thu, Mar 14, 2013 at 4:21 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
@@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
*pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
- platform_device_unregister(exynos-dwc3);
don't you want to do what Kishon did here and have:
static int dwc3_exynos_remove_child(struct device *dev, void *unused)
{
struct platform_device *pdev = to_platform_device(dev);
platform_device_unregister(pdev);
return 0;
}
device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
???
Hmm, right. We need to do that. :-)
--
balbi
--
Thanks Regards
Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MTD : Kernel oops when remounting ubifs as read/write
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote: But there's also a call to crc with a size of 122880 bytes, and that's when the oops occurs. This is when we do the atomic LEB change. Is this size larger than the allocated buffer ? I believe so. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Fix crash on OMAP with CONFIG_DEBUG_SLAB
These patches mainly fix the crash that was reported with CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock initializations. Tested on Panda ES (omap4460), beagle Xm (omap3630) and BeagleBoneBlack (AM335x) Rajendra Nayak (2): ARM: OMAP2+: clocks: Have consistent naming for parent name arrays ARM: OMAP2+: clocks: Pass static parent pointers to common clock core arch/arm/mach-omap2/cclock2420_data.c | 314 ++--- arch/arm/mach-omap2/cclock2430_data.c | 332 ++ arch/arm/mach-omap2/cclock33xx_data.c | 74 +++- arch/arm/mach-omap2/cclock3xxx_data.c | 599 ++--- arch/arm/mach-omap2/cclock44xx_data.c | 240 ++--- arch/arm/mach-omap2/clock.h | 15 +- 6 files changed, 965 insertions(+), 609 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix crash on OMAP with CONFIG_DEBUG_SLAB
Missed out Mike, copied now. On Thursday 14 March 2013 06:06 PM, Rajendra Nayak wrote: These patches mainly fix the crash that was reported with CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock initializations. Tested on Panda ES (omap4460), beagle Xm (omap3630) and BeagleBoneBlack (AM335x) Rajendra Nayak (2): ARM: OMAP2+: clocks: Have consistent naming for parent name arrays ARM: OMAP2+: clocks: Pass static parent pointers to common clock core arch/arm/mach-omap2/cclock2420_data.c | 314 ++--- arch/arm/mach-omap2/cclock2430_data.c | 332 ++ arch/arm/mach-omap2/cclock33xx_data.c | 74 +++- arch/arm/mach-omap2/cclock3xxx_data.c | 599 ++--- arch/arm/mach-omap2/cclock44xx_data.c | 240 ++--- arch/arm/mach-omap2/clock.h | 15 +- 6 files changed, 965 insertions(+), 609 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] omap: usb: host: remove deprecated flags and structures
On Thu, Mar 14, 2013 at 12:41:13PM +0200, Ruslan Bilovol wrote: These flags and structures are deprecated and there is no anymore users of them, so it's safe to remove them. Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 0/4] usb: musb/otg: cleanup and fixes
On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote: This series has some misc cleanup and fixes. The fix solves the cold plug issue in omap3 which some have reported. Developed these patches on fixes-for-v3.9-rc3 after applying http://www.spinics.net/lists/linux-usb/msg81563.html (Grazvydas Ignotas patch series) Tested for g_zero enumeration in pandaboard and beagleboard in both cold plug and hot plug case. Any kind of testing for this series is welcome. Changes from v1: * removed *usb: musb: omap: remove the check before calling otg_set_vbus* it's still on your list of patches :-p a similar patch is already merged. Kishon Vijay Abraham I (4): usb: musb: omap: remove the check before calling otg_set_vbus see ^^ please fix it up and when resending add Grazvydas' Tested-by since he has tested this patchset -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 3/4] USB: Palmas OTG Transceiver Driver
On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote: From: Graeme Gregory g...@slimlogic.co.uk This is the driver for the OTG transceiver built into the Palmas chip. It handles the various USB OTG events that can be generated by cable insertion/removal. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Ruchika Kharwar ruch...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Sebastien Guiriec s-guir...@ti.com --- .../devicetree/bindings/usb/twl-usb.txt| 15 + drivers/usb/otg/Kconfig|6 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/palmas-usb.c | 396 this has to go to drivers/usb/phy/ and should be named phy-palmas.c or phy-twl$(whatever number palmas is).c :-) -- balbi signature.asc Description: Digital signature
Re: MTD : Kernel oops when remounting ubifs as read/write
On 14/03/13 12:23, Artem Bityutskiy wrote: On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote: Is this size larger than the allocated buffer ? I believe so. Err, I mean, the buffer is large enough. I do not believe there is a stupid bug like too small buffer. This code has worked for years and I do not think it was changes much. The oops may be cause by memory corruption - some of your drivers may corrupt memory. You need to spend more time debugging this carefully. It can handle 64k, but not 122880 bytes ... # mount -o remount,rw / [ 19.208302] UBIFS: start fixing up free space [ 19.235881] uealc crc32 : d08cb000 2048 [ 19.240015] uealc crc32 : d08cb000 4096 [ 19.244091] uealc crc32 : d08cb000 8192 [ 19.248184] uealc crc32 : d08cb000 16384 [ 19.252448] uealc crc32 : d08cb000 32768 [ 19.256772] uealc crc32 : d08cb000 65536 [ 19.260133] uealc crc32 : d08cb000 122880 [ 19.261117] Unable to handle kernel paging request at virtual address e79381bc [ 19.268741] pgd = cf40c000 [ 19.271598] [e79381bc] *pgd= [ 19.275387] Internal error: Oops: 5 [#1] ARM [ 19.279902] CPU: 0Not tainted (3.8.0-next-20130225-2-g678576f-dirty #47) [ 19.287819] PC is at crc32_le+0xf8/0x168 [ 19.291965] LR is at ubi_eba_atomic_leb_change+0x3ac/0x4f8 [ 19.297760] pc : [c01e724c]lr : [c026def4]psr: 2013 [ 19.297760] sp : cf3bbe08 ip : 0e4e fp : c054f840 [ 19.309882] r10: e7938104 r9 : c054fc40 r8 : 65e95c1c [ 19.315396] r7 : 322e315f r6 : 352e332e r5 : 002e r4 : 0035 [ 19.322288] r3 : c054e040 r2 : 0033 r1 : d08d3d90 r0 : 63c3884e [ 19.329180] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 19.336713] Control: 10c5387d Table: 8f40c019 DAC: 0015 [ 19.342781] Process mount (pid: 659, stack limit = 0xcf3ba238) [ 19.348939] Stack: (0xcf3bbe08 to 0xcf3bc000) [ 19.353542] be00: cf2f8554 d08caffc 2000 cf2f8000 cf357a00 [ 19.362183] be20: 000c cf2ec000 000c cf2f8554 [ 19.370823] be40: d08cb000 d08cb000 0700 8000 c026c168 0001e000 [ 19.379463] be60: 000c d08cb000 0080 000c cf3bbf48 0020 [ 19.388101] be80: 8000 c026c37c 0001e000 cf33 cf33 d08cb000 0001e000 c0179a78 [ 19.396738] bea0: 000d c0177a68 0001e000 cf33 cf330b20 000d c01794b4 [ 19.405376] bec0: cf33 cf330a9c c0175170 0001 6013 [ 19.414012] bee0: cf32c800 cf3bbf48 0020 c00c9e24 [ 19.422648] bf00: 00100100 00200200 cf390300 8000 cf3ba000 00208020 cf01a200 [ 19.431284] bf20: cf32c800 c00e3d6c 000c cf32c840 c0013968 cf325800 [ 19.439921] bf40: 000c cf01a210 ce828858 000c cf053000 000a18b4 [ 19.448559] bf60: 00208020 c0013968 cf3ba000 0003 c00e3e40 c0071e24 [ 19.457197] bf80: cf325800 cf328380 a010 beb83b68 b6f8348c [ 19.465838] bfa0: 0015 c00137c0 beb83b68 000a18b4 000a18c0 000a18c2 00208020 [ 19.474475] bfc0: beb83b68 b6f8348c 0015 0003 [ 19.483108] bfe0: b6f35f48 beb83a64 00042994 b6f35f58 a010 000a18b4 [ 19.491758] [c01e724c] (crc32_le+0xf8/0x168) from [] ( (null)) [ 19.499115] Code: 0a08 e59da008 e28a1003 e5f1c001 (e2522001) [ 19.50] ---[ end trace 84a04423f0bc8388 ]--- Do you have fastmap UBI feature enabled? No ... # # LPDDR flash memory drivers # # CONFIG_MTD_LPDDR is not set CONFIG_MTD_UBI=y CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_LIMIT=20 # CONFIG_MTD_UBI_FASTMAP is not set # CONFIG_MTD_UBI_GLUEBI is not set CONFIG_DTC=y CONFIG_OF=y -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] USB: ehci-omap: Try to get PHY even if not in PHY mode
On Tue, Mar 12, 2013 at 11:57:56AM -0400, Alan Stern wrote:
On Tue, 12 Mar 2013, Roger Quadros wrote:
Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
/* get the PHY device */
if (dev-of_node)
phy = devm_usb_get_phy_by_phandle(dev, phys, i);
else
phy = devm_usb_get_phy_dev(dev, i);
if (IS_ERR(phy) || !phy) {
+ /* Don't bail out if PHY is not absolutely necessary */
+ if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
+ continue;
+
ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
dev_err(dev, Can't get PHY device for port %d: %d\n,
i, ret);
Felipe, this is a strange interface. Why do we sometimes get an
error-pointer and sometimes get just NULL? Why not always an
error-pointer?
looks like we get NULL when PHY layer is disabled. Sounds like an
oversight to me. Do you want to send a patch, or do I cook one and put
yourself as Reported-by ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 0/4] usb: musb/otg: cleanup and fixes
On Thursday 14 March 2013 07:03 PM, Felipe Balbi wrote: On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote: This series has some misc cleanup and fixes. The fix solves the cold plug issue in omap3 which some have reported. Developed these patches on fixes-for-v3.9-rc3 after applying http://www.spinics.net/lists/linux-usb/msg81563.html (Grazvydas Ignotas patch series) Tested for g_zero enumeration in pandaboard and beagleboard in both cold plug and hot plug case. Any kind of testing for this series is welcome. Changes from v1: * removed *usb: musb: omap: remove the check before calling otg_set_vbus* er.. removed *usb: musb: omap: always glue have the correct vbus/id status* since a patch similar to it is already merged. it's still on your list of patches :-p a similar patch is already merged. Kishon Vijay Abraham I (4): usb: musb: omap: remove the check before calling otg_set_vbus see ^^ please fix it up and when resending add Grazvydas' Tested-by since he has tested this patchset Ok. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] USB: ehci-omap: Try to get PHY even if not in PHY mode
On Thu, 14 Mar 2013, Felipe Balbi wrote:
if (IS_ERR(phy) || !phy) {
+ /* Don't bail out if PHY is not absolutely necessary */
+ if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
+ continue;
+
ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
dev_err(dev, Can't get PHY device for port %d: %d\n,
i, ret);
Felipe, this is a strange interface. Why do we sometimes get an
error-pointer and sometimes get just NULL? Why not always an
error-pointer?
looks like we get NULL when PHY layer is disabled. Sounds like an
oversight to me. Do you want to send a patch, or do I cook one and put
yourself as Reported-by ?
You're more familiar with that code. Reported-by is good enough for
me. :-)
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/mach-omap2/gpmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index d594e1d..8799aed 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1505,6 +1505,7 @@ static int gpmc_probe_nor_child(struct platform_device *pdev, return 0; dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); + ret = -ENODEV; err: gpmc_cs_free(cs); -- 1.7.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
On 03/13/2013 06:57 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130313 09:40]:
On 03/13/2013 06:24 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130313 06:46]:
On 03/12/2013 06:40 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130312 04:47]:
Hi Tony,
These patches provide the SoC side code required to support
the changes in the OMAP USB Host drivers done in [1], [2] [3].
...
arch/arm/mach-omap2/board-3430sdp.c| 97
+++-
arch/arm/mach-omap2/board-3630sdp.c| 100
+++-
arch/arm/mach-omap2/board-am3517crane.c| 95
+--
arch/arm/mach-omap2/board-am3517evm.c | 66 ++-
arch/arm/mach-omap2/board-cm-t35.c | 95
++-
arch/arm/mach-omap2/board-cm-t3517.c | 97
+++-
arch/arm/mach-omap2/board-devkit8000.c | 20 ++--
arch/arm/mach-omap2/board-generic.c| 67 +++
arch/arm/mach-omap2/board-igep0020.c | 112
---
arch/arm/mach-omap2/board-omap3beagle.c| 93
+--
arch/arm/mach-omap2/board-omap3evm.c | 62 --
arch/arm/mach-omap2/board-omap3pandora.c | 52 +++--
arch/arm/mach-omap2/board-omap3stalker.c | 52 +++-
arch/arm/mach-omap2/board-omap3touchbook.c | 62 +-
arch/arm/mach-omap2/board-omap4panda.c | 122
++--
arch/arm/mach-omap2/board-overo.c | 54 -
arch/arm/mach-omap2/board-zoom.c | 56 -
Can't you have some mach-omap2/ehci-common.c that takes care
of the initializiation to avoid this much addition to the
board-*.c files? You may be able to have just a common function
to do it and pass few parameters?
Since we moved reset and power handling for the USB PHYs from omap-echi
driver into the USB PHY driver we need to define the regulator data
for RESET and Power line of each PHY. So most of the code added is just
regulator data for the PHY rather than omap-ehci.
It seems that you're now repeating minor variations of the same PHY
over and over again though.
Yes it is the vcc and reset regulator data for the PHY that
is getting repeated with variations in the GPIO number.
Instead of a common function, I can implement some macros that make it
easier to define the regulators for the PHY in the board files.
Does this sound OK?
Personally I don't like such macros because it hides the implementation
and is difficult to read/debug.
I'd prefer a common function to initialize the PHY though as it sounds
like using macros would just allocate similar PHY many times which seems
unnecessary.
OK, so we want to create the regulator data at runtime to save some memory?
I'll come up with something.
Or I guess you can have just one instance that gets filled in by some PHY
platform init function.
OK. Let me know how the below patch looks. After that, the board code
will look like.
static struct usbhs_phy_data phy_data[] = {
{
.reset_gpio = 147,
.vcc_gpio = 148
.vcc_polarity = 1,
.phy_id = nop_usb_xceiv.2,
},
{}, /* Terminator */
};
usbhs_init_phys(phy_data);
Patch to implement usbhs_init_phys();
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..b9d6bff 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,12 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/dma-mapping.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/string.h
#include asm/io.h
+#include asm/gpio.h
#include soc.h
#include omap_device.h
@@ -472,6 +476,141 @@ void __init setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
}
}
+static const char *reset_supply = reset;
+static const char *vcc_supply = vcc;
+
+/* Template for PHY regulators */
+static struct regulator_consumer_supply hsusb_reg_supplies[] = {
+ { /* .supply .dev_name filled later */ },
+};
+
+static struct regulator_init_data hsusb_reg_data = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .consumer_supplies = hsusb_reg_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hsusb_reg_supplies),
+};
+
+static struct fixed_voltage_config hsusb_reg_config = {
+ /* .supply_name filled later */
+ .microvolts = 330,
+ .gpio = -1, /* updated later */
+ .startup_delay = 7, /* 70msec */
+ .enable_high = 1, /* updated later */
+ .enabled_at_boot = 0, /* keep in RESET */
+ /* .init_data filled later */
+};
+
+static struct platform_device_info hsusb_reg_pdev_info = {
+ .name =
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
+- compatible:Compatible string property for the ethernet
child device.
+- gpmc,cs-on:Chip-select assertion time
+- gpmc,cs-rd-off:Chip-select de-assertion time for reads
+- gpmc,cs-wr-off:Chip-select de-assertion time for writes
+- gpmc,oe-on:Output-enable assertion time
+- gpmc,oe-offOutput-enable de-assertion time
+- gpmc,we-on:Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to
chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus = 90;
+ gpmc,wr-access = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 2;
+
+ smsc,save-mac-address;
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 898b44d..2bc276b 100644
Re: [PATCH v2 1/1] omap: usb: host: remove deprecated flags and structures
On 03/14/2013 12:41 PM, Ruslan Bilovol wrote: These flags and structures are deprecated and there is no anymore users of them, so it's safe to remove them. Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com Acked-by: Roger Quadros rog...@ti.com Tony, Do you prefer to take this directly or want me to queue it up for you? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter jon-hun...@ti.com wrote: Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? My personal vote is: according to hardware documentation is the right thing, and it's what we're doing in mvebu. -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 04:50 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Well, in theory both are supposed to be identical :-) I'm just applying a rounding to the closet power of two, that's why it cannot be 0x2d0. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
On 03/14/2013 10:45 AM, Florian Vaussard wrote: Hi Benoit, On 03/14/2013 03:57 PM, Benoit Cousson wrote: Salut Jon, On 03/08/2013 06:27 PM, Jon Hunter wrote: Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ I've tried to follow the series review, and it seems that Florian was considering sending some other patches. It is not clear if this is a new version of the series or some additional patches. A bit of both. Sorry for the confusion :-) Concerning patch [1], it can be merged to add the GPMC binding for OMAP3. But please discard the rest of my original series, I will repost something later. Benoit, if you pick up Florian's patch, I will re-post my remaining patches for you to pick up. By the way, I see that you have picked up the PMU bindings, however, ideally we should merge the pmu prepare patch first. We agreed with Tony for you to take this with his ack [1]. Let me know if you just want me to re-post that one on top of your branch. Cheers Jon [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/91036 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/14/2013 05:00 PM, Jon Hunter wrote: On 03/14/2013 10:58 AM, Benoit Cousson wrote: On 03/14/2013 04:50 PM, Jon Hunter wrote: On 03/14/2013 10:45 AM, Benoit Cousson wrote: On 03/11/2013 06:56 PM, Jon Hunter wrote: On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? Well, in theory both are supposed to be identical :-) I'm just applying a rounding to the closet power of two, that's why it cannot be 0x2d0. Ok I understand. However, still not clear what you want me to use :-( That's on purpose :-) Take 0x2d0, we could always remove the rounding in the generation part to stick to the HW documentation. Regards Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson b-cous...@ti.com wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2].
[1] https://patchwork.kernel.org/patch/2057111/
I've tried to follow the series review, and it seems that Florian was
considering sending some other patches. It is not clear if this is a new
version of the series or some additional patches.
Hi Benoit,
According to [1] Jon suggested that it was not necessary to map all
the 16MB for the GPMC mapped register address space since in practice
is a very small fraction of that size is used.
I had the following patch but I did never post it because Jon said
that the I/O memory mapping is page-aligned and the minimum page
size for ARM is 4KB anyways, so there is no functional difference
between using 0x1000 or 0x02d0.
But now reading [2] I see that you prefer to do what the documentation
said and don't assume any the page size / alignment.
[2]: https://patchwork.kernel.org/patch/2239741/
From 68edff5a102bb8fc81e006738baa456eb69f080a Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
Date: Wed, 27 Feb 2013 02:30:51 +0100
Subject: [PATCH] ARM: dts: OMAP3: reduce GPMC mapped registers address space
Currently the OMAP General-Purpose Memory Controller (GPMC) device
node maps 16 MB of address space for its hardware registers.
This is because the OMAP Technical Reference Manual says that the
GPMC module register address space size is 16 MB. But in practice
the maximum address offset used by a GPMC register is 0x02d0.
So, there is no need to map such a big address space for GPMC regs.
This change was suggested by Jon Hunter [1].
[1]: https://patchwork.kernel.org/patch/2057111/
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Thanks for that super fast patch :-)
Applied.
Regards,
Benoit
---
arch/arm/boot/dts/omap3.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..a60eaf1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -407,7 +407,7 @@
gpmc: gpmc@6e00 {
compatible = ti,omap3430-gpmc;
ti,hwmods = gpmc;
- reg = 0x6e00 0x100;
+ reg = 0x6e00 0x02d0;
interrupts = 20;
gpmc,num-cs = 8;
gpmc,num-waitpins = 4;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
Hi Jon,
Well now I'm confused. I thought that both were needed since a
combination of bank-width 16-bit / reg-io-width 32-bit is also
possible (in fact that is how I'm testing on my IGEPv2) and we have
talked about this before [1].
By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it
seems that the reg-io-width is not about the data bus address width
but the CPU address width. The smsc data-sheet says:
The simple, yet highly functional host bus interface provides a
glue-less connection to most common 16-bit microprocessors and
microcontrollers as well as 32-bit microprocessors with a 16-bit
external bus
By looking at the smsc911x driver
(drivers/net/ethernet/smsc/smsc911x.c) I see that if you use
reg-io-width = 4 (SMSC911X_USE_32BIT) then the smsc911x hardware
registers can be read in one operation and if you use reg-io-width =
2 (SMSC911X_USE_16BIT) then you need two operations to read the
register:
static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
if (pdata-config.flags SMSC911X_USE_32BIT)
return readl(pdata-ioaddr + reg);
if (pdata-config.flags SMSC911X_USE_16BIT)
return ((readw(pdata-ioaddr + reg) 0x) |
((readw(pdata-ioaddr + reg + 2) 0x) 16));
BUG();
return 0;
}
Also, by reading at the OMAP3 TRM, I understand that even when the
GPMC has a maximum 16-bit address width, it support devices that has
32-bit registers by doing some sort of access adaptation.
So, as far as I understand the bank-width is to configure the GPMC
if is going to use a 8-bit or 16-bit width access and the
reg-io-width is how the smsc911x driver is going to read its
registers. So, I think we need both properties and there is no need to
change gpmc_probe_generic_child() neither pass the child name to it.
But to be honest I can be wrong here since data-sheet and technical
reference manuals can be quite confusing sometimes :-)
Thanks a lot for your feedback and best regards,
Javier
[1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85597.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v2 0/1] usb: musb: improve throughput in HOST mode
Hi guys, This is a resend of my patch: http://permalink.gmane.org/gmane.linux.usb.general/67238 At this moment it has been successfully tested and used on top of 3.0 and 3.4 kernels on omap4 devices so it would be great to have it in upstream too. Regards, Ruslan Ruslan Bilovol (1): usb: musb: implement (un)map_urb_for_dma hooks drivers/usb/musb/musb_core.c | 14 ++ drivers/usb/musb/musb_host.c | 102 +- drivers/usb/musb/musb_host.h |2 +- 3 files changed, 116 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v2 1/1] usb: musb: implement (un)map_urb_for_dma hooks
MUSB controller cannot work in DMA mode with misaligned buffers,
switching in PIO mode.
HCD core has hooks that allow to override the default DMA
mapping and unmapping routines for host controllers that have
special DMA requirements, such as alignment contraints.
It is observed that work in PIO mode is slow and it's better
to align buffers properly before passing them to MUSB
This increased throughput 80-120 MBits/s over musb@omap4 with
USB Gigabit ethernet adapter attached.
Some ideas taken from ehci-tegra.c
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/usb/musb/musb_core.c | 14 ++
drivers/usb/musb/musb_host.c | 102 +-
drivers/usb/musb/musb_host.h |2 +-
3 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 60b41cc..91ac166 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1431,6 +1431,20 @@ static int musb_core_init(u16 musb_type, struct musb
*musb)
/* log release info */
musb-hwvers = musb_read_hwvers(mbase);
+
+#ifndef CONFIG_MUSB_PIO_ONLY
+ /*
+* The DMA engine in RTL1.8 and above cannot handle
+* DMA addresses that are not aligned to a 4 byte boundary.
+* For such engine implemented (un)map_urb_for_dma hooks.
+* Do not use these hooks for RTL1.8
+*/
+ if (musb-hwvers MUSB_HWVERS_1800) {
+ musb_hc_driver.map_urb_for_dma = NULL;
+ musb_hc_driver.unmap_urb_for_dma = NULL;
+ }
+#endif
+
snprintf(aRevision, 32, %d.%d%s, MUSB_HWVERS_MAJOR(musb-hwvers),
MUSB_HWVERS_MINOR(musb-hwvers),
(musb-hwvers MUSB_HWVERS_RC) ? RC : );
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 1ce1fcf..b55bb36 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2465,7 +2465,102 @@ static int musb_bus_resume(struct usb_hcd *hcd)
return 0;
}
-const struct hc_driver musb_hc_driver = {
+
+#ifndef CONFIG_MUSB_PIO_ONLY
+
+#define MUSB_USB_DMA_ALIGN 4
+
+struct musb_temp_buffer {
+ void *kmalloc_ptr;
+ void *old_xfer_buffer;
+ u8 data[0];
+};
+
+static void musb_free_temp_buffer(struct urb *urb)
+{
+ enum dma_data_direction dir;
+ struct musb_temp_buffer *temp;
+
+ if (!(urb-transfer_flags URB_ALIGNED_TEMP_BUFFER))
+ return;
+
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ temp = container_of(urb-transfer_buffer, struct musb_temp_buffer,
+ data);
+
+ if (dir == DMA_FROM_DEVICE) {
+ memcpy(temp-old_xfer_buffer, temp-data,
+ urb-transfer_buffer_length);
+ }
+ urb-transfer_buffer = temp-old_xfer_buffer;
+ kfree(temp-kmalloc_ptr);
+
+ urb-transfer_flags = ~URB_ALIGNED_TEMP_BUFFER;
+}
+
+static int musb_alloc_temp_buffer(struct urb *urb, gfp_t mem_flags)
+{
+ enum dma_data_direction dir;
+ struct musb_temp_buffer *temp;
+ void *kmalloc_ptr;
+ size_t kmalloc_size;
+
+ if (urb-num_sgs || urb-sg ||
+ urb-transfer_buffer_length == 0 ||
+ !((uintptr_t)urb-transfer_buffer (MUSB_USB_DMA_ALIGN - 1)))
+ return 0;
+
+ dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ /* Allocate a buffer with enough padding for alignment */
+ kmalloc_size = urb-transfer_buffer_length +
+ sizeof(struct musb_temp_buffer) + MUSB_USB_DMA_ALIGN - 1;
+
+ kmalloc_ptr = kmalloc(kmalloc_size, mem_flags);
+ if (!kmalloc_ptr)
+ return -ENOMEM;
+
+ /* Position our struct temp_buffer such that data is aligned */
+ temp = PTR_ALIGN(kmalloc_ptr, MUSB_USB_DMA_ALIGN);
+
+
+ temp-kmalloc_ptr = kmalloc_ptr;
+ temp-old_xfer_buffer = urb-transfer_buffer;
+ if (dir == DMA_TO_DEVICE)
+ memcpy(temp-data, urb-transfer_buffer,
+ urb-transfer_buffer_length);
+ urb-transfer_buffer = temp-data;
+
+ urb-transfer_flags |= URB_ALIGNED_TEMP_BUFFER;
+
+ return 0;
+}
+
+static int musb_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
+ gfp_t mem_flags)
+{
+ int ret;
+
+ ret = musb_alloc_temp_buffer(urb, mem_flags);
+ if (ret)
+ return ret;
+
+ ret = usb_hcd_map_urb_for_dma(hcd, urb, mem_flags);
+ if (ret)
+ musb_free_temp_buffer(urb);
+
+ return ret;
+}
+
+static void musb_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+ usb_hcd_unmap_urb_for_dma(hcd, urb);
+ musb_free_temp_buffer(urb);
+}
+#endif /* !CONFIG_MUSB_PIO_ONLY */
+
+struct hc_driver musb_hc_driver = {
.description= musb-hcd,
.product_desc = MUSB HDRC host driver,
.hcd_priv_size
Re: [PATCH 1/3] ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote: gpmc_probe_nor_child() calls of_platform_device_create() to create a platform device for the NOR child. If this function fails the value of ret is returned to the caller but this value is zero since it was assigned the return of a previous call to gpmc_cs_program_settings() that had to succeed or otherwise gpmc_probe_nor_child() would have returned before. This means that if of_platform_device_create() fails, 0 will be returned to the caller instead of an appropriate error code. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/mach-omap2/gpmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index d594e1d..8799aed 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1505,6 +1505,7 @@ static int gpmc_probe_nor_child(struct platform_device *pdev, return 0; dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); + ret = -ENODEV; err: gpmc_cs_free(cs); Good catch! Thanks for the fix, I will pick this up. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.9-rc2
Here are some basic OMAP test results for Linux v3.9-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc2/20130314094808/
Test summary
Build:
FAIL ( 4/16): am33xx_only, omap1_defconfig,
omap1_defconfig_5912osk_only,
omap2plus_defconfig_2430sdp_only
Pass (12/16): n800_multi_omap2xxx, n800_only_a,
omap1_defconfig_1510innovator_only,
omap2plus_defconfig, omap2plus_defconfig_cpupm,
omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 4/11): 2430sdp, 37xxevm, 5912osk, am335xbone
Pass ( 7/11): 2420n800, 3517evm, 3530es3beagle,
3730beaglexm, 4430es2panda, 4460pandaes,
cmt3517
PM ret, suspend:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM ret, dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM off, suspend:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
PM off, dynamic idle:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
Failing tests: fixed by posted patches
--
Build:
* omap1_defconfig: several problems with mach-omap1/board-h2.c
- Fixed by Tony: http://www.spinics.net/lists/arm-kernel/msg224133.html
* omap1_defconfig_5912osk_only: implicit declaration of function
'cpu_is_omap15xx'
- Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html
PM:
* 4460pandaes: CORE, L3INIT didn't enter target state
- Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
(ARM: OMAP4: clock/hwmod data: start to remove some IP block control
clocks)
- Fixed by ARM: OMAP4: PM: fix PM regression introduced by recent clock
cleanup
- http://www.spinics.net/lists/arm-kernel/msg224419.html
Failing tests: needing investigation
Build:
* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
errors
Boot tests:
* 2430sdp 37xxevm: hang during MMC partition probe
- Cause unknown
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
Boot warnings:
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
- (am assuming it's still there; does not boot to userspace)
* 2430sdp: power domains not entering retention
- Cause unknown
- (am assuming it's still there; does not boot to userspace)
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent
vmlinux object size
(delta in bytes from test_v3.9-rc1
(6dbe51c251a327e012439c4772097a13df43c5b8)):
text data bsstotal kernel
+13528 +640 +13592 omap1_defconfig
+9440 +1200+9560 omap2plus_defconfig
+13472 +1280 +13600 omap2plus_defconfig_cpupm
+13472 +1280 +13600 omap2plus_defconfig_omap2_4_only
+9756 +1200+9876 omap2plus_defconfig_omap3_4_only
+704 -64 -188 +452 rmk_omap3430_ldp_allnoconfig
+556 -640 +492 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.9-rc1
Re: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy
On 03/14/13 03:28, Mark Rutland wrote: On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote: On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote: On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote: I do agree it'd be worth lowering the dummy timer's rating to ensure it doesn't override a real timer elsewhere. Yep. Can I add you acked-by tag then for $subject patch ? Would be good to get this one merged as well. Sure. Though could you reword the commit message? The patch solves the more general issue of a dummy being preferred over real hardware even outside of choosing the broadcast device. Acked-by: Mark Rutland mark.rutl...@arm.com Thanks. For record, patch is in end of the email which I plan to put into patch system. Regards, Santosh The below patch seems fine. Are you intending for this to go in as a fix for 3.9-rc*, or as a cleanup for 3.10? If you're aiming for the latter, it's going to clash with Stephen Boyd's local timer API removal [1], in which the generic dummy timer driver [2] (replacing the arm-specific dummy [3]) also has a rating of 100. Thanks for the heads up. Looks like the conflict will be trivial, but I wonder why need to put the patch at all? Per my understanding the regression has been fixed by your patch in Thomas' tree and then in 3.10 we can merge the local timer removal patches and fix up the rating at the same time. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On Thu, Mar 14, 2013 at 7:49 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Documentation/devicetree/bindings/net/gpmc-eth.txt | 90
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..c45363c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,90 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM
devices
+such as ethernet controllers to processors using the TI GPMC as a data
bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes
of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties
are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width:Address width of the device in bytes. GPMC
supports 8-bit
+ and 16-bit devices and so must be either 1 or 2
bytes.
I am wondering if we should use reg-io-width here. The smsc driver is
using this to determine the width of the device. And so I am wondering
if this could cause problems.
Obviously this complicates gpmc_probe_generic_child() a little, but may
be would could pass the name of the width property to
gpmc_probe_generic_child() as well. What do you think?
Hi Jon,
Well now I'm confused. I thought that both were needed since a
combination of bank-width 16-bit / reg-io-width 32-bit is also
possible (in fact that is how I'm testing on my IGEPv2) and we have
talked about this before [1].
Yes you are right. Sorry about that ...
By reading both the OMAP3 TRM and the smsc LAN9221 data-sheet, it
seems that the reg-io-width is not about the data bus address width
but the CPU address width. The smsc data-sheet says:
The simple, yet highly functional host bus interface provides a
glue-less connection to most common 16-bit microprocessors and
microcontrollers as well as 32-bit microprocessors with a 16-bit
external bus
By looking at the smsc911x driver
(drivers/net/ethernet/smsc/smsc911x.c) I see that if you use
reg-io-width = 4 (SMSC911X_USE_32BIT) then the smsc911x hardware
registers can be read in one operation and if you use reg-io-width =
2 (SMSC911X_USE_16BIT) then you need two operations to read the
register:
static inline u32 __smsc911x_reg_read(struct smsc911x_data *pdata, u32 reg)
{
if (pdata-config.flags SMSC911X_USE_32BIT)
return readl(pdata-ioaddr + reg);
if (pdata-config.flags SMSC911X_USE_16BIT)
return ((readw(pdata-ioaddr + reg) 0x) |
((readw(pdata-ioaddr + reg + 2) 0x) 16));
BUG();
return 0;
}
Looking at the above, then I don't see any issue with this then.
Also, by reading at the OMAP3 TRM, I understand that even when the
GPMC has a maximum 16-bit address width, it support devices that has
32-bit registers by doing some sort of access adaptation.
Yes I believe that is correct.
So, as far as I understand the bank-width is to configure the GPMC
if is going to use a 8-bit or 16-bit width access and the
reg-io-width is how the smsc911x driver is going to read its
registers. So, I think we need both properties and there is no need to
change gpmc_probe_generic_child() neither pass the child name to it.
But to be honest I can be wrong here since data-sheet and technical
reference manuals can be quite confusing sometimes :-)
Ok, so do you think that we should add some documentation to the
gpmc-eth.txt so say that set reg-io-width = 4; for OMAP regardless
of bank-width?
Yes, I think we can improve the documentation. I'll send a v2 with
this delta patch squashed:
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
index c45363c..711d28d 100644
--- a/Documentation/devicetree/bindings/net/gpmc-eth.txt
+++
[PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device node.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v1:
- Improve the DT binding documentation explaining that even when the GPMC
maximum bus address width is 16-bit, it supports devices with 32-bit
registers address width and the device property especifying this has to
be set accordingly; suggested by Jon Hunter.
Documentation/devicetree/bindings/net/gpmc-eth.txt | 101
arch/arm/mach-omap2/gpmc.c |8 ++
2 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt
diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
new file mode 100644
index 000..8c8be58
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -0,0 +1,101 @@
+Device tree bindings for Ethernet chip connected to TI GPMC
+
+Besides being used to interface with external memory devices, the
+General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices
+such as ethernet controllers to processors using the TI GPMC as a data bus.
+
+Ethernet controllers connected to TI GPMC are represented as child nodes of
+the GPMC controller with an ethernet name.
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For the properties relevant to the ethernet controller connected to the GPMC
+refer to the binding documentation of the device. For example, the
documentation
+for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt
+
+Child nodes need to specify the GPMC bus address width using the bank-width
+property but is possible that an ethernet controller also has a property to
+specify the I/O registers address width. Even when the GPMC has a maximum
16-bit
+address width, it supports devices with 32-bit word registers.
+For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an
+OMAP2+ board, bank-width = 2; and reg-io-width = 4;.
+
+Required properties:
+- bank-width: Address width of the device in bytes. GPMC supports
8-bit
+ and 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Compatible string property for the ethernet child
device.
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- reg: Chip-select, base address (relative to chip-select)
+ and size of the memory mapped for the device.
+ Note that base address will be typically 0 as this
+ is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x1000;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = 5 0 0x2c00 0x100;
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 186;
+ gpmc,cs-wr-off = 186;
+ gpmc,adv-on = 12;
+ gpmc,adv-rd-off = 48;
+ gpmc,adv-wr-off = 48;
+ gpmc,oe-on = 54;
+ gpmc,oe-off = 168;
+ gpmc,we-on = 54;
+ gpmc,we-off = 168;
+ gpmc,rd-cycle = 186;
+ gpmc,wr-cycle = 186;
+ gpmc,access = 114;
+ gpmc,page-burst-access = 6;
+ gpmc,bus-turnaround = 12;
+ gpmc,cycle2cycle-delay = 18;
+ gpmc,wr-data-mux-bus
[PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in migrating the cpufreq support only through device tree (part of the effort to migrate away from non-DT configurations for OMAP). Unfortunately, as already known, we have a bunch of legacy code and mutually dependent device tree conversion that is pending. Key features pending: A) clock framework transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series B) on processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Note: Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements there as well. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to DT. As a result of this series, CPUFreq feature will not be available for non-DT boot systems. Original discussion thread which triggered this series: http://marc.info/?l=linux-pmm=136304313700602w=2 https://patchwork.kernel.org/patch/2251841/ https://patchwork.kernel.org/patch/2251851/ Test coverage: test script: http://pastebin.com/MpCRY0SB Platforms verified: beaglebone(rev A6a) - AM33xx compatible beagleboard (rev C1D) - OMAP3430 compatible omap3-beagle-xm -OMAP3630 compatible Pandaboard -(OMAP4430 ES2.3) verified with omapconf Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf Series is based on v3.9-rc2 tag Also available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 git link: git://github.com/nmenon/linux-2.6-playground.git branch: cpufreq-cpu0-omap-all-v1 Nishanth Menon (8): ARM: dts: OMAP34xx: move CPU OPP tables to device tree ARM: dts: OMAP36xx: move CPU OPP tables to device tree ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU ARM: dts: OMAP443x: move CPU OPP tables to device tree ARM: dts: omap4-panda: move generic sections to panda-common ARM: dts: OMAP446x: move CPU OPP tables to device tree ARM: OMAP3+: use cpu0-cpufreq driver cpufreq: omap: remove omap-cpufreq MAINTAINERS |1 - arch/arm/boot/dts/omap3-beagle-xm.dts |6 + arch/arm/boot/dts/omap3-beagle.dts|6 + arch/arm/boot/dts/omap3-evm.dts |6 + arch/arm/boot/dts/omap3.dtsi | 10 + arch/arm/boot/dts/omap36xx.dtsi | 12 ++ arch/arm/boot/dts/omap4-panda-a4.dts |5 +- arch/arm/boot/dts/omap4-panda-common.dtsi | 205 arch/arm/boot/dts/omap4-panda-es.dts |5 +- arch/arm/boot/dts/omap4-panda.dts | 200 +--- arch/arm/boot/dts/omap4.dtsi | 10 + arch/arm/boot/dts/omap446x.dtsi | 27 +++ arch/arm/boot/dts/twl4030.dtsi|6 + arch/arm/mach-omap2/board-generic.c |4 + arch/arm/mach-omap2/cclock33xx_data.c |2 +- arch/arm/mach-omap2/cclock3xxx_data.c |2 +- arch/arm/mach-omap2/cclock44xx_data.c |2 +- arch/arm/mach-omap2/opp3xxx_data.c| 20 -- arch/arm/mach-omap2/opp4xxx_data.c| 23 --- drivers/cpufreq/Kconfig.arm |6 - drivers/cpufreq/Makefile |1 - drivers/cpufreq/omap-cpufreq.c| 291 - 22 files changed, 305 insertions(+), 545 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-panda-common.dtsi create mode 100644 arch/arm/boot/dts/omap446x.dtsi delete mode 100644 drivers/cpufreq/omap-cpufreq.c Size change information: add/remove: 0/0 grow/shrink: 3/5 up/down: 74/-291 (-217) function old new delta omap_generic_init 96 140 +44 vermagic 49 64 +15 linux_banner 130 145 +15 kernel_config_data 18333 18330 -3 omap443x_opp_def_list144 80 -64 omap36xx_opp_def_list
[PATCH 4/8] ARM: dts: OMAP443x: move CPU OPP tables to device tree
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 10 ++
arch/arm/mach-omap2/opp4xxx_data.c |8
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..08983a3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,16 @@
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
+ /* OMAP4430 variants OPP50-OPPNT */
+ operating-points =
+ /* kHzuV */
+ 30 1025000
+ 60 120
+ 80 1313000
+ 1008000 1375000
+ ;
+ clock-latency = 30; /* From omap-cpufreq driver */
+ voltage-tolerance = 2; /* 2 % */
};
cpu@1 {
compatible = arm,cortex-a9;
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 1ef7a3e..478e2ee 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -65,14 +65,6 @@ struct omap_volt_data omap443x_vdd_core_volt_data[] = {
static struct omap_opp_def __initdata omap443x_opp_def_list[] = {
- /* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, OMAP4430_VDD_MPU_OPP50_UV),
- /* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, OMAP4430_VDD_MPU_OPP100_UV),
- /* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, true, 8, OMAP4430_VDD_MPU_OPPTURBO_UV),
- /* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, true, 100800, OMAP4430_VDD_MPU_OPPNITRO_UV),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4430_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] ARM: OMAP3+: use cpu0-cpufreq driver
With OMAP3+ and AM33xx supported SoC having defined CPU DT
entries with operating-points defined, we can now
use the SoC generic cpu0-cpufreq driver to start
using it, lets now switch to the generic driver.
As part of this change, switch the dummy clock node to use
cpufreq-cpu0. This is an suggested solution till we have
OMAP clock nodes in DT. Once the DT conversion is complete,
we can then do: clocks = dpll_mpu_ck; or the SoC specific
equivalent.
Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-generic.c |4
arch/arm/mach-omap2/cclock33xx_data.c |2 +-
arch/arm/mach-omap2/cclock3xxx_data.c |2 +-
arch/arm/mach-omap2/cclock44xx_data.c |2 +-
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..970c6f4 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,10 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+ if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+ struct platform_device_info devinfo = { .name = cpufreq-cpu0,
};
+ platform_device_register_full(devinfo);
+ }
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck,
CK_AM33XX),
CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_ck, dpll_mpu_ck, CK_AM33XX),
- CLK(cpu0, NULL, dpll_mpu_ck, CK_AM33XX),
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck,
CK_AM33XX),
CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL, dpll_ddr_ck, dpll_ddr_ck, CK_AM33XX),
CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck,
CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5f68286 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(NULL, timer_32k_ck, omap_32k_fck, CK_3XXX),
CLK(NULL, timer_sys_ck, sys_ck,CK_3XXX),
- CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX),
+ CLK(cpufreq-cpu0.0, NULL, dpll1_ck, CK_3XXX),
};
static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..6e933e3 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
+ CLK(cpufreq-cpu0.0, NULL, dpll_mpu_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] ARM: dts: OMAP34xx: move CPU OPP tables to device tree
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 10 ++
arch/arm/mach-omap2/opp3xxx_data.c | 11 ---
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9a15066 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,16 @@
cpus {
cpu@0 {
compatible = arm,cortex-a8;
+ /* OMAP3430 variants OPP1-5 */
+ operating-points =
+ /* kHzuV */
+ 125000 975000
+ 25 1075000
+ 50 120
+ 55 127
+ 60 135
+ ;
+ clock-latency = 30; /* From legacy driver */
};
};
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index fc67add..1de18c2 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -87,17 +87,6 @@ struct omap_volt_data omap36xx_vddcore_volt_data[] = {
/* OPP data */
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
- /* MPU OPP1 */
- OPP_INITIALIZER(mpu, true, 12500, OMAP3430_VDD_MPU_OPP1_UV),
- /* MPU OPP2 */
- OPP_INITIALIZER(mpu, true, 25000, OMAP3430_VDD_MPU_OPP2_UV),
- /* MPU OPP3 */
- OPP_INITIALIZER(mpu, true, 5, OMAP3430_VDD_MPU_OPP3_UV),
- /* MPU OPP4 */
- OPP_INITIALIZER(mpu, true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
- /* MPU OPP5 */
- OPP_INITIALIZER(mpu, true, 6, OMAP3430_VDD_MPU_OPP5_UV),
-
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
* almost the same than the one at 83MHz thus providing very little
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap36xx.dtsi| 12
arch/arm/mach-omap2/opp3xxx_data.c |9 -
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 96bf028..743eaa1 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -15,6 +15,18 @@
serial3 = uart4;
};
+ cpus {
+ /* OMAP3630 'standard device' variants OPP50 to OPP130 */
+ cpu@0 {
+ operating-points =
+ /* kHzuV */
+ 30 975000
+ 60 1075000
+ 80 120
+ ;
+ clock-latency = 30; /* From omap-cpufreq driver */
+ };
+ };
ocp {
uart4: serial@49042000 {
compatible = ti,omap3-uart;
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 1de18c2..cf7b3ab 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -114,15 +114,6 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
- /* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 3, OMAP3630_VDD_MPU_OPP50_UV),
- /* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 6, OMAP3630_VDD_MPU_OPP100_UV),
- /* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, false, 8, OMAP3630_VDD_MPU_OPP120_UV),
- /* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER(mpu, false, 10, OMAP3630_VDD_MPU_OPP1G_UV),
-
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main, true, 1, OMAP3630_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
Add DT OPP table for OMAP446x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap4-panda-es.dts |2 +-
arch/arm/boot/dts/omap446x.dtsi | 27 +++
arch/arm/mach-omap2/opp4xxx_data.c | 15 ---
3 files changed, 28 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/boot/dts/omap446x.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 6422d7c..c52455b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -7,7 +7,7 @@
*/
/dts-v1/;
-/include/ omap4.dtsi
+/include/ omap446x.dtsi
/include/ omap4-panda-common.dtsi
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
diff --git a/arch/arm/boot/dts/omap446x.dtsi b/arch/arm/boot/dts/omap446x.dtsi
new file mode 100644
index 000..8f7a080
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP446x SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap4.dtsi
+
+/ {
+ cpus {
+ /* OMAP446x 'standard device' variants OPP50 to OPPTurbo */
+ cpu@0 {
+ operating-points =
+ /* kHzuV */
+ 35 975000
+ 70 1075000
+ 92 120
+ ;
+ clock-latency = 30; /* From omap-cpufreq driver */
+ voltage-tolerance = 2; /* 2 % */
+ };
+ };
+};
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
index 478e2ee..4c5c038 100644
--- a/arch/arm/mach-omap2/opp4xxx_data.c
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -116,21 +116,6 @@ struct omap_volt_data omap446x_vdd_core_volt_data[] = {
};
static struct omap_opp_def __initdata omap446x_opp_def_list[] = {
- /* MPU OPP1 - OPP50 */
- OPP_INITIALIZER(mpu, true, 35000, OMAP4460_VDD_MPU_OPP50_UV),
- /* MPU OPP2 - OPP100 */
- OPP_INITIALIZER(mpu, true, 7, OMAP4460_VDD_MPU_OPP100_UV),
- /* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER(mpu, true, 92000, OMAP4460_VDD_MPU_OPPTURBO_UV),
- /*
-* MPU OPP4 - OPP-Nitro + Disabled as the reference schematics
-* recommends TPS623631 - confirm and enable the opp in board file
-* XXX: May be we should enable these based on mpu capability and
-* Exception board files disable it...
-*/
- OPP_INITIALIZER(mpu, false, 12, OMAP4460_VDD_MPU_OPPNITRO_UV),
- /* MPU OPP4 - OPP-Nitro SpeedBin */
- OPP_INITIALIZER(mpu, false, 15, OMAP4460_VDD_MPU_OPPNITRO_UV),
/* L3 OPP1 - OPP50 */
OPP_INITIALIZER(l3_main_1, true, 1,
OMAP4460_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100 */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] cpufreq: omap: remove omap-cpufreq
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
MAINTAINERS|1 -
drivers/cpufreq/Kconfig.arm|6 -
drivers/cpufreq/Makefile |1 -
drivers/cpufreq/omap-cpufreq.c | 291
4 files changed, 299 deletions(-)
delete mode 100644 drivers/cpufreq/omap-cpufreq.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..d9c11bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5654,7 +5654,6 @@ M:Kevin Hilman khil...@ti.com
L: linux-omap@vger.kernel.org
S: Maintained
F: arch/arm/*omap*/*pm*
-F: drivers/cpufreq/omap-cpufreq.c
OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT
M: Rajendra Nayak rna...@ti.com
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..1cb810a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -2,12 +2,6 @@
# ARM CPU Frequency scaling drivers
#
-config ARM_OMAP2PLUS_CPUFREQ
- bool TI OMAP2+
- depends on ARCH_OMAP2PLUS
- default ARCH_OMAP2PLUS
- select CPU_FREQ_TABLE
-
config ARM_S3C2416_CPUFREQ
bool S3C2416 CPU Frequency scaling support
depends on CPU_S3C2416
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..d52076c 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -53,7 +53,6 @@ obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
-obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
deleted file mode 100644
index 9128c07..000
--- a/drivers/cpufreq/omap-cpufreq.c
+++ /dev/null
@@ -1,291 +0,0 @@
-/*
- * CPU frequency scaling for OMAP using OPP information
- *
- * Copyright (C) 2005 Nokia Corporation
- * Written by Tony Lindgren t...@atomide.com
- *
- * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King
- *
- * Copyright (C) 2007-2011 Texas Instruments, Inc.
- * - OMAP3/4 support by Rajendra Nayak, Santosh Shilimkar
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include linux/types.h
-#include linux/kernel.h
-#include linux/sched.h
-#include linux/cpufreq.h
-#include linux/delay.h
-#include linux/init.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/opp.h
-#include linux/cpu.h
-#include linux/module.h
-#include linux/regulator/consumer.h
-
-#include asm/smp_plat.h
-#include asm/cpu.h
-
-/* OPP tolerance in percentage */
-#defineOPP_TOLERANCE 4
-
-static struct cpufreq_frequency_table *freq_table;
-static atomic_t freq_table_users = ATOMIC_INIT(0);
-static struct clk *mpu_clk;
-static struct device *mpu_dev;
-static struct regulator *mpu_reg;
-
-static int omap_verify_speed(struct cpufreq_policy *policy)
-{
- if (!freq_table)
- return -EINVAL;
- return cpufreq_frequency_table_verify(policy, freq_table);
-}
-
-static unsigned int omap_getspeed(unsigned int cpu)
-{
- unsigned long rate;
-
- if (cpu = NR_CPUS)
- return 0;
-
- rate = clk_get_rate(mpu_clk) / 1000;
- return rate;
-}
-
-static int omap_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- unsigned int i;
- int r, ret = 0;
- struct cpufreq_freqs freqs;
- struct opp *opp;
- unsigned long freq, volt = 0, volt_old = 0, tol = 0;
-
- if (!freq_table) {
- dev_err(mpu_dev, %s: cpu%d: no freq table!\n, __func__,
- policy-cpu);
- return -EINVAL;
- }
-
- ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
- relation, i);
- if (ret) {
- dev_dbg(mpu_dev, %s: cpu%d: no freq match for %d(ret=%d)\n,
- __func__, policy-cpu, target_freq, ret);
- return
[PATCH 3/8] ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP3 platforms.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: Keerthy j-keer...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-beagle.dts|6 ++
arch/arm/boot/dts/omap3-evm.dts |6 ++
arch/arm/boot/dts/twl4030.dtsi|6 ++
4 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3705a81..7152746 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 BeagleBoard xM;
compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..8886617 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 BeagleBoard;
compatible = ti,omap3-beagle, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..d36d19f 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -13,6 +13,12 @@
model = TI OMAP3 EVM (OMAP3530, AM/DM37x);
compatible = ti,omap3-evm, ti,omap3;
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
memory {
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..608f2e6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -23,6 +23,12 @@
compatible = ti,twl4030-wdt;
};
+ vcc: regulator-vdd1 {
+ compatible = ti,twl4030-vdd1;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 145;
+ };
+
vdac: regulator-vdac {
compatible = ti,twl4030-vdac;
regulator-min-microvolt = 180;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
Javier Hi Jon, On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit +and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off:Write-enable de-assertion time +- gpmc,access:Start cycle to first data capture (read access) +- gpmc,rd-cycle:Total read cycle time +- gpmc,wr-cycle:Total write cycle time +- reg:Chip-select, base address (relative to chip-select) +and size of the memory mapped for the device. +Note that base address will be typically 0 as this +is the start of the chip-select. + +Optional properties: +- gpmc,XXXAdditional GPMC timings and settings parameters. See +Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? I'm not sure about that, this property is not used (neither relevant) to the GPMC driver but is used by the smsc911x driver. Other Ethernet chips could not need that (e.g: supports only 32 bit word accesses) or can have a different property. Uses should check the documentation binding for the connected device. + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. I should have catch that before sending the first version! I took the properties from your gpmc-nor.txt documentation and this is a left over. Will send a v3 removing that. Sorry for being so carelessly... Otherwise looks good. Cheers Jon Thanks a lot and best regards, Javier-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes
On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote: Javier Hi Jon, On 14/03/2013, at 21:43, Jon Hunter jon-hun...@ti.com wrote: On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote: Besides being used to interface with external memory devices, the General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices such as ethernet controllers to OMAP2+ processors using the TI GPMC as a data bus. This patch allows an ethernet chip to be defined as an GPMC child device node. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v1: - Improve the DT binding documentation explaining that even when the GPMC maximum bus address width is 16-bit, it supports devices with 32-bit registers address width and the device property especifying this has to be set accordingly; suggested by Jon Hunter. Documentation/devicetree/bindings/net/gpmc-eth.txt | 101 arch/arm/mach-omap2/gpmc.c |8 ++ 2 files changed, 109 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/gpmc-eth.txt diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt new file mode 100644 index 000..8c8be58 --- /dev/null +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -0,0 +1,101 @@ +Device tree bindings for Ethernet chip connected to TI GPMC + +Besides being used to interface with external memory devices, the +General-Purpose Memory Controller can be used to connect Pseudo-SRAM devices +such as ethernet controllers to processors using the TI GPMC as a data bus. + +Ethernet controllers connected to TI GPMC are represented as child nodes of +the GPMC controller with an ethernet name. + +All timing relevant properties as well as generic GPMC child properties are +explained in a separate documents. Please refer to +Documentation/devicetree/bindings/bus/ti-gpmc.txt + +For the properties relevant to the ethernet controller connected to the GPMC +refer to the binding documentation of the device. For example, the documentation +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt + +Child nodes need to specify the GPMC bus address width using the bank-width +property but is possible that an ethernet controller also has a property to +specify the I/O registers address width. Even when the GPMC has a maximum 16-bit +address width, it supports devices with 32-bit word registers. +For example with an SMSC LAN911x/912x controller connected to the TI GPMC on an +OMAP2+ board, bank-width = 2; and reg-io-width = 4;. + +Required properties: +- bank-width:Address width of the device in bytes. GPMC supports 8-bit +and 16-bit devices and so must be either 1 or 2 bytes. +- compatible:Compatible string property for the ethernet child device. +- gpmc,cs-on:Chip-select assertion time +- gpmc,cs-rd-off:Chip-select de-assertion time for reads +- gpmc,cs-wr-off:Chip-select de-assertion time for writes +- gpmc,oe-on:Output-enable assertion time +- gpmc,oe-offOutput-enable de-assertion time +- gpmc,we-on:Write-enable assertion time +- gpmc,we-off:Write-enable de-assertion time +- gpmc,access:Start cycle to first data capture (read access) +- gpmc,rd-cycle:Total read cycle time +- gpmc,wr-cycle:Total write cycle time +- reg:Chip-select, base address (relative to chip-select) +and size of the memory mapped for the device. +Note that base address will be typically 0 as this +is the start of the chip-select. + +Optional properties: +- gpmc,XXXAdditional GPMC timings and settings parameters. See +Documentation/devicetree/bindings/bus/ti-gpmc.txt Should we add reg-io-width here and say can be 2 or 4 and to refer to the above description? I'm not sure about that, this property is not used (neither relevant) to the GPMC driver but is used by the smsc911x driver. Other Ethernet chips could not need that (e.g: supports only 32 bit word accesses) or can have a different property. Uses should check the documentation binding for the connected device. Good point. Let's not bother adding that. + +Optional properties for partiton table parsing: +- #address-cells: should be set to 1 +- #size-cells: should be set to 1 Sorry should have caught this earlier. The above is not relevant for ethernet. I should have catch that before sending the first version! I took the properties from your gpmc-nor.txt documentation and this is a left over. Will send a v3 removing that. Sorry for being so carelessly... No problem. Thanks for getting this done. Now just to figure out how to handle the darn gpio interrupt ;-) Jon -- To unsubscribe from this list: send the line unsubscribe
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 03/14/2013 03:58 PM, Nishanth Menon wrote: The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in migrating the cpufreq support only through device tree (part of the effort to migrate away from non-DT configurations for OMAP). Unfortunately, as already known, we have a bunch of legacy code and mutually dependent device tree conversion that is pending. Key features pending: A) clock framework transition to DT - this should happen soon, so this series hacks the clock node for the time being as suggested in review of original series B) on processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias and SmartReflex AVS conversion to DT. As a result of these pending features: - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no regulators associated at the moment - fortunately, we boot at highest voltage, so things still work. - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have not added those OPPs in DT yet - this also needs alignment with iMX, AM series like pending work, where certain OPPs need enabling based on efuse programmed bit sequences - since it is an add-on work, it is not addressed here. Note: Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements there as well. OMAP has been converted to the common clock framework (CCF). Are you referring to clock framework transition to DT or something else? Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] ARM: dts: OMAP34xx: move CPU OPP tables to device tree
On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP34xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This is in preparation to use generic cpu0-cpufreq driver. No mention here about what you are removing ;-) Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] ARM: dts: OMAP36xx: move CPU OPP tables to device tree
On 03/14/2013 03:58 PM, Nishanth Menon wrote: Add DT OPP table for OMAP36xx family of devices. This data is decoded by OF with of_init_opp_table() helper function. This overrides the default OMAP34xx CPU OPP table definition. Not sure I following the last sentence. The tables are in a different dtsi file and only the relevant file should be included, right? Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] ARM: dts: OMAP446x: move CPU OPP tables to device tree
On 03/14/2013 03:58 PM, Nishanth Menon wrote: OMAP4430 and 4460 have different OPP definitions. So, create an SoC variant dtsi file for 4460 and move the OPP definitions to it. FYI, I had to create a similar file for PMU [1]. However, I called it omap4460.dtsi and not omap446x.dtsi as there is only one omap446x device. That should go into to v3.10 and so may be worth basing this on top. I do like your omap4-panda-common.dtsi that is a nice clean-up. Cheers Jon [1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/commit/?h=for_3.10/dtsid=5e64b6b1137a54f353528d6da60071c1ef0043ba -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] cpufreq: omap: remove omap-cpufreq
On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon n...@ti.com wrote: We can now use cpufreq-cpu0 driver using DT entries. remove the redundant omap-cpufreq driver from the tree. Remove MAINTAINERS file entry for the same as well. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Benoît Cousson b-cous...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Shawn Guo shawn@linaro.org Cc: Keerthy j-keer...@ti.com Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: cpuf...@vger.kernel.org Cc: linux...@vger.kernel.org Signed-off-by: Nishanth Menon n...@ti.com --- MAINTAINERS|1 - drivers/cpufreq/Kconfig.arm|6 - drivers/cpufreq/Makefile |1 - drivers/cpufreq/omap-cpufreq.c | 291 4 files changed, 299 deletions(-) delete mode 100644 drivers/cpufreq/omap-cpufreq.c Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
