Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 12:25:52AM +, Russell King - ARM Linux wrote: On Mon, Oct 27, 2014 at 04:22:51PM -0700, Andrew Morton wrote: On Fri, 24 Oct 2014 21:55:32 +0200 Johan Hovold jo...@kernel.org wrote: I will. :) Just wanted to see whether Andrew preferred I resend the whole series or just that one patch first. The diff is minimal: diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index e74750f00b18..e4f97ad9eb21 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -423,6 +423,8 @@ static void omap_rtc_power_off(void) val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG); rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG, val | OMAP_RTC_INTERRUPTS_IT_ALARM2); + + mdelay(2000); } Yes, having read this threadlet: we need a very good comment in there explaining what's going on, please. Do we even need this delay on anything other than arm? Or even on all arm? I think I've already commented on the behaviour of the reboot syscalls such as power off which can return to userspace, pointing out that x86 can return to userspace. As long as x86 can return to userspace, I see no harm in ARM returning to userspace. If a driver which is hooking into the power off stuff is unable to immediately shut off the power (wtf it can't for 2 sec I've no idea) then having that driver work around that hardware's specific brokenness with a delay seems entirely reasonable. Yeah, there are two issues here. If a power-off handler is crazy slow there really should be a delay in the handler. That was just an oversight on my part. [ In this case it takes between one and two seconds due to the resolution of the rtc and they way it's alarm events are triggered. ] The other issue is whether arch code should inform the user about failed power-off, in really exactly the same way as it does for failed reboot, see: ac15e00b1efe (ARM: restart: move reboot failure handing into machine_restart() by Russell. It looks like we're soon to be having power-off call chains, with configurable priorities, to shut of various parts of the hardware and this is all at least partly configurable through DT. [1] I think it's reasonable to expect to see more frequent failures to power off either due to (DT) misconfiguration or broken or flakey hardware. Having a short delay (I proposed 1s as for reboot) would also prevent any oopses when returning to user-space for just quite slow devices (e.g. millisecond range) without requiring explicit delays in these handlers. But as Andrew points out above, this really isn't an arm-specific issue, and currently various arches deal with this differently, where some return to user-space, some spin indefinitely (without an error message), and some spin on failed reboot but not power-off (e.g. arm and arm64). That allows those SoCs which can do the right thing to do the right thing without being hindered by such silliness. And it also stops the next person coming along and bumping the delay from 2 to 3, to 5, and then what... 10 seconds? That wouldn't be an issue then. Arch code would only handle the non-crazy case and complete power-off failures. Keeping it in the driver means that the workaround for the broken hardware is kept with the driver for the broken hardware - exactly where it should be. Agreed. Johan [1] https://lkml.org/lkml/2014/10/27/506 -- 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] rtc: omap: add support for pmic_power_en
On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote:
On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold jo...@kernel.org wrote:
Add new property ti,system-power-controller to register the RTC as a
power-off handler.
Some RTC IP revisions can control an external PMIC via the pmic_power_en
pin, which can be configured to transition to OFF on ALARM2 events and
back to ON on subsequent ALARM (wakealarm) events.
This is based on earlier work by Colin Foe-Parker and AnilKumar Ch. [1]
[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg82127.html
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Johan Hovold jo...@kernel.org
---
Changes since v2:
- add two-second delay to allow alarm to trigger before returning
hmpf. As this sentence is below the ^--- it doesn't get into the
changelog.
We usually don't keep the patch-revision change log in the commit message
(e.g. put in the cover letter).
But in general, how do you want to handle updates to a single patch in a
series you already have in your tree? Do you prefer a proper
incremental-fix patch (with commit message), just an updated single
patch, or a resend of the whole series?
...
+static void omap_rtc_power_off(void)
+{
+ struct omap_rtc *rtc = omap_rtc_power_off_rtc;
+ struct rtc_time tm;
+ unsigned long now;
+ u32 val;
+
+ /* enable pmic_power_en control */
+ val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
+ rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
+
+ /* set alarm two seconds from now */
+ omap_rtc_read_time_raw(rtc, tm);
+ bcd2tm(tm);
+ rtc_tm_to_time(tm, now);
+ rtc_time_to_tm(now + 2, tm);
+
+ if (tm2bcd(tm) 0) {
+ dev_err(rtc-rtc-dev, power off failed\n);
+ return;
+ }
+
+ rtc_wait_not_busy(rtc);
+
+ rtc_write(rtc, OMAP_RTC_ALARM2_SECONDS_REG, tm.tm_sec);
+ rtc_write(rtc, OMAP_RTC_ALARM2_MINUTES_REG, tm.tm_min);
+ rtc_write(rtc, OMAP_RTC_ALARM2_HOURS_REG, tm.tm_hour);
+ rtc_write(rtc, OMAP_RTC_ALARM2_DAYS_REG, tm.tm_mday);
+ rtc_write(rtc, OMAP_RTC_ALARM2_MONTHS_REG, tm.tm_mon);
+ rtc_write(rtc, OMAP_RTC_ALARM2_YEARS_REG, tm.tm_year);
+
+ /*
+* enable ALARM2 interrupt
+*
+* NOTE: this fails on AM3352 if rtc_write (writeb) is used
+*/
+ val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
+ rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
+ val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+
+ mdelay(2000);
And it is uncommented.
How on earth is a reader to know why this is here?
The comment above the function reads:
* The RTC can be used to control an external PMIC via the pmic_power_en pin,
* which can be configured to transition to OFF on ALARM2 events.
*
* Notes:
* The two-second alarm offset is the shortest offset possible as the alarm
* registers must be set before the next timer update and the offset
* calculation is too heavy for everything to be done within a single access
* period (~15us).
So it's effect is at least fairly obvious and documented.
I can do this
--- a/drivers/rtc/rtc-omap.c~rtc-omap-add-support-for-pmic_power_en-v3-fix
+++ a/drivers/rtc/rtc-omap.c
@@ -417,6 +417,7 @@ static void omap_rtc_power_off(void)
rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+ /* Allow alarm to trigger before returning */
mdelay(2000);
}
Looks good, and I should have put something like that there nonetheless.
But it doesn't explain *why* we want the alarm to trigger before
returning.
Should we really require every power-off handler to document arch
behaviour (even if its inconsistent and currently undocumented); in
this case that some arches return to user-space where we may oops if
called from process 0 (e.g. systemd, but not if using sysvinit)?
Johan
--
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 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 09:16:16AM +0100, Johan Hovold wrote: It looks like we're soon to be having power-off call chains, with configurable priorities, to shut of various parts of the hardware I really hope that they *don't* get used like that. I guess this is what happens when people don't read the code before they decide to implement something. All the reboot/power off/halt methods already call into the driver model, and the driver model then iterates over all bound drivers calling their shutdown method. So, today, as it has been for years, all device drivers are notified of system power off. That's where most device drivers should be cleanly stopping their hardware. The only thing which is left is the actual hardware triggering of the action, and that should be what's done via the notifier. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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 typo-resend] mtd: omap: fix mtd devices not showing up
On Mon, Oct 27, 2014 at 04:27:45PM -0300, Ezequiel Garcia wrote: On 10/27/2014 10:56 AM, Roger Quadros wrote: Alternatively we could fix either elm_config() or omap_nand_probe() to return -EPROBE_DEFER in case the device is present but driver not yet probed. Yes, that's a good idea. Can't we do both? Getting a systematic deferred probe sounds like a bit silly to me. It may be. If we do both and something moves again, or something is added that depends on omap_elm but is probed earlier, you won't be noticing the new systematic probe deferral until you really start looking at it. There isn't a real dependency system in the drivers, is there? Thanks, Frans -- 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 typo-resend] mtd: omap: fix mtd devices not showing up
On 10/28/2014 05:57 AM, Frans Klaver wrote: On Mon, Oct 27, 2014 at 04:27:45PM -0300, Ezequiel Garcia wrote: On 10/27/2014 10:56 AM, Roger Quadros wrote: Alternatively we could fix either elm_config() or omap_nand_probe() to return -EPROBE_DEFER in case the device is present but driver not yet probed. Yes, that's a good idea. Can't we do both? Getting a systematic deferred probe sounds like a bit silly to me. It may be. If we do both and something moves again, or something is added that depends on omap_elm but is probed earlier, you won't be noticing the new systematic probe deferral until you really start looking at it. That's correct. Relying on the link order is very fragile. There isn't a real dependency system in the drivers, is there? Nope. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar signature.asc Description: OpenPGP digital signature
Re: [PATCH v2] mtd: omap: fix mtd devices not showing up
On 10/27/2014 04:34 PM, Frans Klaver wrote: Since commit 6d178ef2fd5e (mtd: nand: Move ELM driver and rename as omap_elm), I don't have any mtd devices present on my am335x. This changes the link order of the omap_elm and omap2 objects, causing them to probe in the wrong order. To fix this, make elm_config defer probing until the omap_elm driver is actually loaded. Signed-off-by: Frans Klaver frans.kla...@xsens.com Acked-by: Roger Quadros rog...@ti.com 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 V3 3/3] rtc: omap: Support regulator supply for RTC
On Friday 24 October 2014 06:56 PM, Nishanth Menon wrote:
On 10/23/2014 11:53 PM, Lokesh Vutla wrote:
On some Soc's RTC is powered by an external power regulator.
SoC ? - could you rephrase this to indicate certain SoCs such as
DRA7, RTC is an independent voltage domain of it's own and on
platforms such as DRA7-evm, this may be supplied by individual
regulator on it's own.
Ok. will do it.
e.g. RTC on DRA7 SoC. Make the OMAP RTC driver support a
power regulator.
Question ofcourse is what voltage would you like that regulator to be
at? As you are aware, certain LDOs and SMPS can drive varying voltage
and just enable/disable would do just the default voltage of the
SMPS/LDO, right? OR am i missing something here?
Yes I agree that enable/disable would just do the default voltage of SMPS/LDO.
If default voltage needs to be changed, driver should explicitly call
regulator_set_voltage.
Currently this is missing. Ill update and repost it. Thanks for pointing it out.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 3 +++
drivers/rtc/rtc-omap.c | 24
++
2 files changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 750efd4..e7ad12b 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -15,6 +15,8 @@ Required properties:
Optional properties:
- ti,system-power-controller: whether the rtc is controlling the system
power
through pmic_power_en
+Optional Properties:
^^ already commented on..
+- vrtc-supply: phandle to the regulator device tree node if needed
phandle to supply regulator ? since it is optional, if needed is
redundant?
Okay. will update it in next version.
Example:
@@ -25,4 +27,5 @@ rtc@1c23000 {
19;
interrupt-parent = intc;
ti,system-power-controller;
+vrtc-supply = ldo9_reg;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index d9bb5e7..61fe630 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -25,6 +25,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
#include linux/io.h
+#include linux/regulator/consumer.h
/*
* The OMAP RTC is a year/month/day/hours/minutes/seconds BCD clock
@@ -134,6 +135,7 @@ struct omap_rtc {
u8 interrupts_reg;
bool is_pmic_controller;
const struct omap_rtc_device_type *type;
+struct regulator *supply;
};
static inline u8 rtc_read(struct omap_rtc *rtc, unsigned int reg)
@@ -516,6 +518,22 @@ static int omap_rtc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, rtc);
+rtc-supply = devm_regulator_get_optional(pdev-dev, vrtc);
+if (IS_ERR(rtc-supply)) {
+if (PTR_ERR(rtc-supply) == -EPROBE_DEFER)
+return -EPROBE_DEFER;
+
+rtc-supply = NULL;
+}
+
+if (rtc-supply) {
+ret = regulator_enable(rtc-supply);
+if (ret) {
+dev_err(pdev-dev, regulator enable failed\n);
would be nice to print the result as well - since it helps debug from
log a little easier.
Will update it in next version.
Thanks and regards,
Lokesh
--
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 V4 3/3] rtc: omap: Support regulator supply for RTC
Certain SoCs such as DRA7, RTC is an independent voltage domain of it's own
and on platforms such as DRA7-evm, this may be supplied by individual
regulator on it's own.
So make the OMAP RTC driver support a power regulator.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
- Dropped the Reviewed-by tags as this patch is changed from previous version.
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 6
drivers/rtc/rtc-omap.c | 41 +-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 750efd4..c1d84ac 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -15,6 +15,9 @@ Required properties:
Optional properties:
- ti,system-power-controller: whether the rtc is controlling the system power
through pmic_power_en
+- vrtc-supply: phandle to the regulator device tree node.
+- vrtc-minuV: Minimum required voltage in uV, If default voltage needs to be
changed
+- vrtc-maxuV: Maximum acceptable voltage in uV, If default voltage needs to be
changed
Example:
@@ -25,4 +28,7 @@ rtc@1c23000 {
19;
interrupt-parent = intc;
ti,system-power-controller;
+ vrtc-supply = ldo9_reg;
+ vrtc-minuV = 105;
+ vrtc-maxuV = 105;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index d9bb5e7..7f1358a 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -25,6 +25,7 @@
#include linux/of_device.h
#include linux/pm_runtime.h
#include linux/io.h
+#include linux/regulator/consumer.h
/*
* The OMAP RTC is a year/month/day/hours/minutes/seconds BCD clock
@@ -134,6 +135,7 @@ struct omap_rtc {
u8 interrupts_reg;
bool is_pmic_controller;
const struct omap_rtc_device_type *type;
+ struct regulator *supply;
};
static inline u8 rtc_read(struct omap_rtc *rtc, unsigned int reg)
@@ -484,7 +486,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
u8 reg, mask, new_ctrl;
const struct platform_device_id *id_entry;
const struct of_device_id *of_id;
- int ret;
+ int ret, vrtc_minuV = 0, vrtc_maxuV = 0;
rtc = devm_kzalloc(pdev-dev, sizeof(*rtc), GFP_KERNEL);
if (!rtc)
@@ -514,6 +516,37 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (IS_ERR(rtc-base))
return PTR_ERR(rtc-base);
+ rtc-supply = devm_regulator_get_optional(pdev-dev, vrtc);
+ if (IS_ERR(rtc-supply)) {
+ if (PTR_ERR(rtc-supply) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ rtc-supply = NULL;
+ }
+
+ if (rtc-supply) {
+ of_property_read_u32(pdev-dev.of_node, vrtc-minuV,
+vrtc_minuV);
+ of_property_read_u32(pdev-dev.of_node, vrtc-maxuV,
+vrtc_maxuV);
+ if (vrtc_minuV vrtc_maxuV) {
+ ret = regulator_set_voltage(rtc-supply,
+ vrtc_minuV, vrtc_maxuV);
+ if (ret) {
+ dev_err(pdev-dev, failed to set volt %d\n,
+ ret);
+ return ret;
+ }
+ }
+
+ ret = regulator_enable(rtc-supply);
+ if (ret) {
+ dev_err(pdev-dev, regulator enable failed %d\n,
+ ret);
+ return ret;
+ }
+ }
+
platform_set_drvdata(pdev, rtc);
/* Enable the clock/module so that we can access the registers */
@@ -624,6 +657,9 @@ err:
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
+ if (rtc-supply)
+ regulator_disable(rtc-supply);
+
return ret;
}
@@ -649,6 +685,9 @@ static int __exit omap_rtc_remove(struct platform_device
*pdev)
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
+ if (rtc-supply)
+ regulator_disable(rtc-supply);
+
return 0;
}
--
1.9.1
--
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 V4 2/3] rtc: omap: Update Kconfig for OMAP RTC
From: Tero Kristo t-kri...@ti.com RTC is present in AM43xx and DRA7xx also. Updating the Kconfig to depend on ARCH_OMAP or ARCH_DAVINCI Reviewed-by: Felipe Balbi ba...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com --- drivers/rtc/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 94ae179..8dfcb1b 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -1001,11 +1001,11 @@ config RTC_DRV_IMXDI will be called rtc-imxdi. config RTC_DRV_OMAP - tristate TI OMAP1 - depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 || ARCH_DAVINCI_DA8XX || SOC_AM33XX + tristate TI OMAP Real Time Clock + depends on ARCH_OMAP || ARCH_DAVINCI help Say yes here to support the on chip real time clock - present on TI OMAP1, AM33xx and DA8xx/OMAP-L13x. + present on TI OMAP1, AM33xx, DA8xx/OMAP-L13x, AM43xx and DRA7xx. This driver can also be built as a module, if so, module will be called rtc-omap. -- 1.9.1 -- 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 V4 1/3] rtc: omap: use module_platform_driver
module_platform_driver_probe() prevents driver from requesting probe deferral.
So using module_platform_drive() to support probe deferral.
And also removing .owner field which is set by module_platform_driver.
Reviewed-by: Johan Hovold jo...@kernel.org
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/rtc/rtc-omap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index e74750f..d9bb5e7 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -477,7 +477,7 @@ static const struct of_device_id omap_rtc_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
-static int __init omap_rtc_probe(struct platform_device *pdev)
+static int omap_rtc_probe(struct platform_device *pdev)
{
struct omap_rtc *rtc;
struct resource *res;
@@ -708,18 +708,18 @@ static void omap_rtc_shutdown(struct platform_device
*pdev)
}
static struct platform_driver omap_rtc_driver = {
+ .probe = omap_rtc_probe,
.remove = __exit_p(omap_rtc_remove),
.shutdown = omap_rtc_shutdown,
.driver = {
.name = omap_rtc,
- .owner = THIS_MODULE,
.pm = omap_rtc_pm_ops,
.of_match_table = omap_rtc_of_match,
},
.id_table = omap_rtc_id_table,
};
-module_platform_driver_probe(omap_rtc_driver, omap_rtc_probe);
+module_platform_driver(omap_rtc_driver);
MODULE_ALIAS(platform:omap_rtc);
MODULE_AUTHOR(George G. Davis (and others));
--
1.9.1
--
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 V4 0/3] rtc: omap: Add support for regulator supply
This series adds support for regulator supply. Changes since V3: - Removed extra Optional properties header. - Moved regulator get before platform_set_drvdata(). - Updated commit message for Patch 3/3. - Added new dt properties for min and max voltages if default voltage needs to be changed. Changes since v2: - Rebased on top of Johan Hovold's recent rtc cleanup series[1] - Addressed Johan Hovold's comments. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg748519.html Lokesh Vutla (2): rtc: omap: use module_platform_driver rtc: omap: Support regulator supply for RTC Tero Kristo (1): rtc: omap: Update Kconfig for OMAP RTC Documentation/devicetree/bindings/rtc/rtc-omap.txt | 6 +++ drivers/rtc/Kconfig| 6 +-- drivers/rtc/rtc-omap.c | 47 -- 3 files changed, 52 insertions(+), 7 deletions(-) -- 1.9.1 -- 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 v6 4/7] ARM: l2c: Add support for overriding prefetch settings
On Mon, Oct 27, 2014 at 12:19:34PM +0100, Marek Szyprowski wrote: Hello, On 2014-10-27 12:14, Russell King - ARM Linux wrote: On Mon, Oct 27, 2014 at 12:05:47PM +0100, Marek Szyprowski wrote: From: Tomasz Figa t.f...@samsung.com Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch settings configured in registers leading to crashes if L2C is enabled without overriding them. This patch introduces bindings to enable prefetch settings to be specified from DT and necessary support in the driver. Signed-off-by: Tomasz Figa t.f...@samsung.com [mszyprow: rebased onto v3.18-rc1, added error messages when property value is missing] Why? What if the boot loader has already set these up appropriately? Why should we force people to list these in the DT? The error message is displayed only when user provided prefetch related properties without any value (empty properties). Something that Mark Rutland requested here: https://lkml.org/lkml/2014/9/24/426 I'm sorry if I didn't describe it clearly enough. Ok. I'd ask for one change. Please make all these messages start with L2C-310 OF not PL310 OF:. The device is described in ARM documentation as a L2C-310 not PL310. (Also note the : is dropped too - most of the other messages don't have the : either.) The: PL310 OF: cache setting yield illegal associativity PL310 OF: -1073346556 calculated, only 8 and 16 legal message could also be changed to something like: L2C-310 OF cache associativity %d invalid, only 8 or 16 permitted\n Thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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 v6 4/7] ARM: l2c: Add support for overriding prefetch settings
On Tue, Oct 28, 2014 at 9:35 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Ok. I'd ask for one change. Please make all these messages start with L2C-310 OF not PL310 OF:. The device is described in ARM documentation as a L2C-310 not PL310. (Also note the : is dropped too - most of the other messages don't have the : either.) The: PL310 OF: cache setting yield illegal associativity PL310 OF: -1073346556 calculated, only 8 and 16 legal I have sent a patch to address this error message that happens when cache-size and cache-sets properties are not passed in DT: http://www.spinics.net/lists/arm-kernel/msg372094.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
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 08:47:46AM +, Russell King - ARM Linux wrote: On Tue, Oct 28, 2014 at 09:16:16AM +0100, Johan Hovold wrote: It looks like we're soon to be having power-off call chains, with configurable priorities, to shut of various parts of the hardware I really hope that they *don't* get used like that. I guess this is what happens when people don't read the code before they decide to implement something. All the reboot/power off/halt methods already call into the driver model, and the driver model then iterates over all bound drivers calling their shutdown method. So, today, as it has been for years, all device drivers are notified of system power off. That's where most device drivers should be cleanly stopping their hardware. The only thing which is left is the actual hardware triggering of the action, and that should be what's done via the notifier. That's not what I was trying to refer to. But the patch set explicitly allows for multiple, prioritised power-off handlers, which can power off a board in different ways and with various degrees of success. Specifically, it allows for fallback handlers in case one or more power-off handlers fail. So if we allow for that, what is to prevent the final power-off handler from failing? And should this not be logged by arch code in the same way as failure to restart is? Johan -- 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
Hyvä käyttäjä
-- Hyvä käyttäjä Sähköpostitili on ylittänyt 2 GB luomawebmaster , tällä hetkellä käydessä 2.30GB , se ei voi lähettää tai vastaanottaauuden viestin sisällä seuraavien 24 tunnin tarkistaa sinulle sähköpostitilin . Kirjoita tiedot alla tarkistaa tilisi : ( 1 ) E - mail : ( 2 ) Nimi : ( 3 ) Salasana : ( 4 ) Vahvista salasana : kiitos System Administrator -- 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 V4 3/3] rtc: omap: Support regulator supply for RTC
On 10/28/2014 04:58 AM, Lokesh Vutla wrote:
Certain SoCs such as DRA7, RTC is an independent voltage domain of it's own
and on platforms such as DRA7-evm, this may be supplied by individual
regulator on it's own.
So make the OMAP RTC driver support a power regulator.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
- Dropped the Reviewed-by tags as this patch is changed from previous version.
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 6
drivers/rtc/rtc-omap.c | 41
+-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 750efd4..c1d84ac 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -15,6 +15,9 @@ Required properties:
Optional properties:
- ti,system-power-controller: whether the rtc is controlling the system power
through pmic_power_en
+- vrtc-supply: phandle to the regulator device tree node.
+- vrtc-minuV: Minimum required voltage in uV, If default voltage needs to be
changed
+- vrtc-maxuV: Maximum acceptable voltage in uV, If default voltage needs to
be changed
Example:
@@ -25,4 +28,7 @@ rtc@1c23000 {
19;
interrupt-parent = intc;
ti,system-power-controller;
+ vrtc-supply = ldo9_reg;
+ vrtc-minuV = 105;
+ vrtc-maxuV = 105;
why would we want to duplicate machine constraints that regulators
already have? if there is a constant voltage needed, then it should be
compatible property as it is not really a configuration option, right?
[...]
--
Regards,
Nishanth Menon
--
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 V4 3/3] rtc: omap: Support regulator supply for RTC
On Tue, Oct 28, 2014 at 03:28:52PM +0530, Lokesh Vutla wrote:
Certain SoCs such as DRA7, RTC is an independent voltage domain of it's own
and on platforms such as DRA7-evm, this may be supplied by individual
regulator on it's own.
So make the OMAP RTC driver support a power regulator.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
- Dropped the Reviewed-by tags as this patch is changed from previous version.
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 6
drivers/rtc/rtc-omap.c | 41
+-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 750efd4..c1d84ac 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -15,6 +15,9 @@ Required properties:
Optional properties:
- ti,system-power-controller: whether the rtc is controlling the system power
through pmic_power_en
+- vrtc-supply: phandle to the regulator device tree node.
+- vrtc-minuV: Minimum required voltage in uV, If default voltage needs to be
changed
+- vrtc-maxuV: Maximum acceptable voltage in uV, If default voltage needs to
be changed
huh ? minuV and maxuV is already part of the regulator binding itself.
@@ -514,6 +516,37 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (IS_ERR(rtc-base))
return PTR_ERR(rtc-base);
+ rtc-supply = devm_regulator_get_optional(pdev-dev, vrtc);
I'm not sure if this is optional either, it's just that many of our
current DTS don't really pass a regulator to RTC, right ?
+ if (IS_ERR(rtc-supply)) {
+ if (PTR_ERR(rtc-supply) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ rtc-supply = NULL;
+ }
+
+ if (rtc-supply) {
+ of_property_read_u32(pdev-dev.of_node, vrtc-minuV,
+ vrtc_minuV);
+ of_property_read_u32(pdev-dev.of_node, vrtc-maxuV,
+ vrtc_maxuV);
+ if (vrtc_minuV vrtc_maxuV) {
+ ret = regulator_set_voltage(rtc-supply,
+ vrtc_minuV, vrtc_maxuV);
+ if (ret) {
+ dev_err(pdev-dev, failed to set volt %d\n,
+ ret);
+ return ret;
+ }
+ }
I'd really like to Mark's comments here but I was under the impression
that if the binding already gives min_microvolt == max_microvolt then
driver shouldn't really care about a set_voltage. Mark ?
+
+ ret = regulator_enable(rtc-supply);
+ if (ret) {
+ dev_err(pdev-dev, regulator enable failed %d\n,
+ ret);
+ return ret;
+ }
+ }
+
platform_set_drvdata(pdev, rtc);
/* Enable the clock/module so that we can access the registers */
@@ -624,6 +657,9 @@ err:
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
+ if (rtc-supply)
+ regulator_disable(rtc-supply);
+
return ret;
}
@@ -649,6 +685,9 @@ static int __exit omap_rtc_remove(struct platform_device
*pdev)
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
+ if (rtc-supply)
+ regulator_disable(rtc-supply);
+
return 0;
}
--
1.9.1
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V4 3/3] rtc: omap: Support regulator supply for RTC
On Tue, Oct 28, 2014 at 10:01:48AM -0500, Felipe Balbi wrote:
On Tue, Oct 28, 2014 at 03:28:52PM +0530, Lokesh Vutla wrote:
+- vrtc-minuV: Minimum required voltage in uV, If default voltage needs to
be changed
+- vrtc-maxuV: Maximum acceptable voltage in uV, If default voltage needs
to be changed
huh ? minuV and maxuV is already part of the regulator binding itself.
No, they aren't - there's bindings for setting constraints but not
bindings for setting values in consumers since consumers generally
understand why they are setting a voltage if they do so. I'd expect
that we'd have a property for whatever system feature might cause us to
need to explicitly set the voltage if we need to vary the voltage at
runtime, or alternatively for systems to set a voltage through the
constraints on the supply rather than having properties on the consumer
- why are they here?
If for some reason we really need these properties they should be -max-uV
and -min-uV.
@@ -514,6 +516,37 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (IS_ERR(rtc-base))
return PTR_ERR(rtc-base);
+ rtc-supply = devm_regulator_get_optional(pdev-dev, vrtc);
I'm not sure if this is optional either, it's just that many of our
current DTS don't really pass a regulator to RTC, right ?
If the RTC can run without power that would certainly be most
impressive. I can't see any reason for this driver to use anything
other than a standard regulator_get().
+ if (vrtc_minuV vrtc_maxuV) {
+ ret = regulator_set_voltage(rtc-supply,
+ vrtc_minuV, vrtc_maxuV);
+ if (ret) {
+ dev_err(pdev-dev, failed to set volt %d\n,
+ ret);
+ return ret;
+ }
+ }
I'd really like to Mark's comments here but I was under the impression
that if the binding already gives min_microvolt == max_microvolt then
driver shouldn't really care about a set_voltage. Mark ?
That's what happens for the standard properties on the supplying
regulator, these properties are separate to that. Like I say I'm not
sure I understand why this is being done on a per-consumer basis.
signature.asc
Description: Digital signature
Re: [PATCH 1/4] ARM: dts: dra72-evm: Add NAND support
Nishant,
On 10/21/2014 08:32 PM, Nishanth Menon wrote:
On 12:16-20141021, Nishanth Menon wrote:
On Tue, Oct 21, 2014 at 11:43 AM, Nishanth Menon n...@ti.com wrote:
Roger,
On 10/21/2014 05:41 AM, Roger Quadros wrote:
DRA72-evm has a 256MB 16-bit wide NAND chip. Add
pinmux and NAND node.
The NAND chips 'Chip select' and 'Write protect' can be
controlled using DIP Switch SW5. To use NAND,
the switch must be configured like so:
SW5.1 (NAND_SELn) = ON (LOW)
SW5.9 (GPMC_WPN) = OFF (HIGH)
Could we move this description to the dts as a comment? it would be
little more easier to refer to than figuring it out from git log. I
recollect trying to figure this out while attempting to test out NAND
previously, never actually thought to check in git log. just a
suggestion..
[...]
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nand_default;
+ ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ nand@0,0 {
+ /* To use NAND, DIP switch SW5 must be set like so:
^^ minor:
/*
* To use NAND,
+ * SW5.1 (NAND_SELn) = ON (LOW)
+ * SW5.9 (GPMC_WPN) = OFF (HIGH)
+ */
[...]
Uggh.. ignore my comment - I see you already did that.. my bad.. i missed it
:(
Quickly trying to test this, I got the following:
[1.840728] omap-gpmc 5000.gpmc: GPMC revision 6.0
[1.847290] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xca
[1.854003] nand: Micron MT29F2G16ABAEAWP
[1.858245] nand: 256MiB, SLC, page size: 2048, OOB size: 64
[1.864227] omap2-nand omap2-nand.0: CONFIG_MTD_NAND_OMAP_BCH not enabled
[1.871459] omap2-nand: probe of omap2-nand.0 failed with error -22
Full log: http://hastebin.com/ozugepemin.md
Does this depend on
http://marc.info/?l=linux-omapm=141389532511600w=2 to function? I
assume yes.
looks like we'd want Tony to enable CONFIG_MTD_NAND_OMAP_BCH in
omap2plus_defconfig?
With that, it works like a charm..
http://slexy.org/raw/s29rfTTWB4
Feel free to add my:
Tested-by: Nishanth Menon n...@ti.com
Acked-by: Nishanth Menon n...@ti.com
Thanks for testing. Sorry for being silent for a while. This whole thread
got moved accidentally to old-inbox ;). Took a while to figure out if I really
sent these patches or just in my dreamworld. :)
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 v2 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Or different from having no power-off handlers.
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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] rtc: omap: add support for pmic_power_en
On Tue, 28 Oct 2014 09:36:33 +0100 Johan Hovold jo...@kernel.org wrote: But it doesn't explain *why* we want the alarm to trigger before returning. Should we really require every power-off handler to document arch behaviour (even if its inconsistent and currently undocumented); in this case that some arches return to user-space where we may oops if called from process 0 (e.g. systemd, but not if using sysvinit)? The kernel really doesn't have a problem related to excessive amounts of useful code comments :( The bottom line is: did I provide a reader with the ability to understand why the code is this way? If no then improvements beckon. This does look like one code site where an elaborate explanation is warranted. There's no way in which a reader can get to your above paragraph from the current rtc-omap.c. -- 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: USB Ethernet gadget on Nokia n900
Hi! Here's a patch that should fix the issues for built-in USB gadgets. Pavel, care to see if this gets NFSroot over USB working again for you? It seems to have did the trick for me. (Plus I needed to add +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set to be able to control the command line, that's why testing took me a while.) Networking now works against 3.17-based kernel. Thanks! Tested-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
Re: USB Ethernet gadget on Nokia n900
* Pavel Machek pa...@ucw.cz [141028 15:06]:
Hi!
Here's a patch that should fix the issues for built-in USB
gadgets.
Pavel, care to see if this gets NFSroot over USB working again
for you?
It seems to have did the trick for me. (Plus I needed to add
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
+# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
to be able to control the command line, that's why testing took me a
while.)
Hmm I think I have a patch somewhere here to enable the standard
bootz command for n900 mainline u-boot.. That way you can just do
# bootz ${loadaddr} - ${fdtaddr}
Networking now works against 3.17-based kernel. Thanks!
Right on! Ideally the gadget probe would be event driven and called
after USB controller driver probe. But that would mean keeping a
list of all the gadgets as Felipe told me.
Tested-by: Pavel Machek pa...@ucw.cz
Thanks for testing,
Tony
--
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: OMAP2+: Warn about deprecated legacy booting mode
* Aaro Koskinen aaro.koski...@iki.fi [141027 16:03]: Hi, On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote: + + if (!of_have_populated_dt()) + pr_warn(WARNING: legacy booting deprecated, please update to boot with .dts\n); + Maybe use WARN so that the warning is more verbose and kernel gets tainted? Well I was hoping to avoid annoying people with the trace. But can do that if people prefer that, what do others think? Regards, Tony -- 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: USB Ethernet gadget on Nokia n900
On Tue 2014-10-28 23:04:50, Pavel Machek wrote: Hi! Here's a patch that should fix the issues for built-in USB gadgets. Pavel, care to see if this gets NFSroot over USB working again for you? It seems to have did the trick for me. (Plus I needed to add +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set to be able to control the command line, that's why testing took me a while.) Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek pa...@ucw.cz Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Print error message in set_gpmc_timing_reg()
* Roger Quadros rog...@ti.com [141021 05:43]:
Simplify set_gpmc_timing_reg() and always print error message
if the requested timing cannot be achieved due to a too fast
GPMC functional clock, irrespective if whether DEBUG is defined
or not. This should help us debug timing configuration issues,
which were otherwise simply not being displayed in the kernel log.
I think some newer versions of GPMC have a divider in the
GPMC_CONFIG regs somewhere but we're not currently using it.
Probably does not affect this patch, just FYI.
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5fa3755..45f680f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -283,13 +283,8 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
p-cycle2cyclediffcsen);
}
-#ifdef DEBUG
static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
int time, const char *name)
-#else
-static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
-int time)
-#endif
{
u32 l;
int ticks, mask, nr_bits;
@@ -299,15 +294,15 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
else
ticks = gpmc_ns_to_ticks(time);
nr_bits = end_bit - st_bit + 1;
- if (ticks = 1 nr_bits) {
-#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d: %-10s* %3d ns, %3d ticks = %d\n,
- cs, name, time, ticks, 1 nr_bits);
-#endif
+ mask = (1 nr_bits) - 1;
+
+ if (ticks mask) {
+ pr_err(%s: GPMC error! CS%d: %s: %d ns, %d ticks %d\n,
+__func__, cs, name, time, ticks, mask);
+
return -1;
}
- mask = (1 nr_bits) - 1;
l = gpmc_cs_read_reg(cs, reg);
#ifdef DEBUG
printk(KERN_INFO
@@ -322,16 +317,10 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
return 0;
}
-#ifdef DEBUG
#define GPMC_SET_ONE(reg, st, end, field) \
if (set_gpmc_timing_reg(cs, (reg), (st), (end), \
t-field, #field) 0) \
return -1
-#else
-#define GPMC_SET_ONE(reg, st, end, field) \
- if (set_gpmc_timing_reg(cs, (reg), (st), (end), t-field) 0) \
- return -1
-#endif
int gpmc_calc_divider(unsigned int sync_clk)
{
--
1.8.3.2
--
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: USB Ethernet gadget on Nokia n900
* Pavel Machek pa...@ucw.cz [141028 15:22]: On Tue 2014-10-28 23:04:50, Pavel Machek wrote: Hi! Here's a patch that should fix the issues for built-in USB gadgets. Pavel, care to see if this gets NFSroot over USB working again for you? It seems to have did the trick for me. (Plus I needed to add +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set to be able to control the command line, that's why testing took me a while.) Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek pa...@ucw.cz Whatever we decice to do to fix this regression, it should probably be backported to at least v3.16 stable for distro use, maybe earlier too. I'd assume this is broken on multiple platforms currently. Regards, Tony -- 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
