Re: [PATCH v2] omap: i2c: Add calls for pinctrl state select
On 23.04.2015 02:32, Nishanth Menon wrote: few nitpicks: i2c: omap: in $subject instead of omap: i2c: I usually would do: git log --no-merges --oneline drivers/i2c/busses/i2c-omap.c and look for common usage. Aargh, thanks for pointing that out, I'll fix that. On 04/22/2015 04:07 AM, pascal.hue...@gmail.com wrote: From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_20x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } +pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); +pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 Build tested with omap2plus_defconfig on linus master (27cf3a16b253) and next-20150422 While I do understand that the sleep state and default states are optional - might be nice to state it in commit message (as a result of which we dont do error checks). Thanks for testing. I'll fix the commit message and send in v3. Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. I'm not sure about that. Actually this is all handled by the pinctrl subsystem, so I would guess that documentation belongs there, since in: Documentation/devicetree/bindings/i2c/i2c-at91.txt Documentation/devicetree/bindings/i2c/i2c-nomadik.txt is no documentation about that as well. But there is documentation in: Documentation/pinctrl.txt right? Otherwise, I would say we should add documentation for all devices, so it is consistent. -- 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 v3] i2c: omap: Add calls for pinctrl state select
From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. If no sleep state is provided in the DT, these calls turn to NOPs, so we don't need error checking here. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 -- 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] omap: i2c: Add calls for pinctrl state select
On 04/28/2015 06:05 AM, Pascal Huerst wrote: [...] On 23.04.2015 02:32, Nishanth Menon wrote: [...] Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. I'm not sure about that. Actually this is all handled by the pinctrl subsystem, so I would guess that documentation belongs there, since in: Documentation/devicetree/bindings/i2c/i2c-at91.txt Documentation/devicetree/bindings/i2c/i2c-nomadik.txt is no documentation about that as well. But there is documentation in: Documentation/pinctrl.txt right? Otherwise, I would say we should add documentation for all devices, so it is consistent. that is probably good since drivers may or maynot support the sleep configuration. -- 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 v2] omap: i2c: Add calls for pinctrl state select
On 04/28/2015 06:05 AM, Pascal Huerst wrote: [...] On 23.04.2015 02:32, Nishanth Menon wrote: [...] Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. I'm not sure about that. Actually this is all handled by the pinctrl subsystem, so I would guess that documentation belongs there, since in: Documentation/devicetree/bindings/i2c/i2c-at91.txt Documentation/devicetree/bindings/i2c/i2c-nomadik.txt is no documentation about that as well. But there is documentation in: Documentation/pinctrl.txt right? Otherwise, I would say we should add documentation for all devices, so it is consistent. that is probably good since drivers may or maynot support support the sleep configuration. -- 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] mfd: Constify regmap and irq configuration data
On Mon, 27 Apr 2015, Krzysztof Kozlowski wrote:
Constify in various drivers configuration data which is not modified:
- regmap_irq_chip,
- individual regmap_irq's in array,
- regmap_config,
- irq_domain_ops,
Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com
---
drivers/mfd/88pm860x-core.c | 2 +-
drivers/mfd/ab8500-core.c | 2 +-
drivers/mfd/arizona-irq.c | 2 +-
drivers/mfd/da9052-irq.c | 4 ++--
drivers/mfd/da9055-core.c | 6 +++---
drivers/mfd/da9063-irq.c | 4 ++--
drivers/mfd/da9150-core.c | 4 ++--
drivers/mfd/db8500-prcmu.c| 2 +-
drivers/mfd/intel_soc_pmic_core.h | 2 +-
drivers/mfd/intel_soc_pmic_crc.c | 2 +-
drivers/mfd/lp8788-irq.c | 2 +-
drivers/mfd/max8925-core.c| 2 +-
drivers/mfd/max8997-irq.c | 2 +-
drivers/mfd/max8998-irq.c | 2 +-
drivers/mfd/mt6397-core.c | 2 +-
drivers/mfd/stmpe.c | 2 +-
drivers/mfd/tc3589x.c | 2 +-
drivers/mfd/tps6586x.c| 2 +-
drivers/mfd/twl6030-irq.c | 2 +-
drivers/mfd/wm831x-irq.c | 2 +-
drivers/mfd/wm8994-irq.c | 6 +++---
include/linux/mfd/da9055/core.h | 2 +-
22 files changed, 29 insertions(+), 29 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index d2a85cde68da..e03b7f45b8f7 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -566,7 +566,7 @@ static int pm860x_irq_domain_map(struct irq_domain *d,
unsigned int virq,
return 0;
}
-static struct irq_domain_ops pm860x_irq_domain_ops = {
+static const struct irq_domain_ops pm860x_irq_domain_ops = {
.map= pm860x_irq_domain_map,
.xlate = irq_domain_xlate_onetwocell,
};
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index c80a2925f8e5..000da72a0ae9 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -574,7 +574,7 @@ static int ab8500_irq_map(struct irq_domain *d, unsigned
int virq,
return 0;
}
-static struct irq_domain_ops ab8500_irq_ops = {
+static const struct irq_domain_ops ab8500_irq_ops = {
.map= ab8500_irq_map,
.xlate = irq_domain_xlate_twocell,
};
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index d063b94b94b5..2b9965d53e4e 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -186,7 +186,7 @@ static int arizona_irq_map(struct irq_domain *h, unsigned
int virq,
return 0;
}
-static struct irq_domain_ops arizona_domain_ops = {
+static const struct irq_domain_ops arizona_domain_ops = {
.map= arizona_irq_map,
.xlate = irq_domain_xlate_twocell,
};
diff --git a/drivers/mfd/da9052-irq.c b/drivers/mfd/da9052-irq.c
index e65ca194fa98..f4cb4613140b 100644
--- a/drivers/mfd/da9052-irq.c
+++ b/drivers/mfd/da9052-irq.c
@@ -35,7 +35,7 @@
#define DA9052_IRQ_MASK_POS_70x40
#define DA9052_IRQ_MASK_POS_80x80
-static struct regmap_irq da9052_irqs[] = {
+static const struct regmap_irq da9052_irqs[] = {
[DA9052_IRQ_DCIN] = {
.reg_offset = 0,
.mask = DA9052_IRQ_MASK_POS_1,
@@ -166,7 +166,7 @@ static struct regmap_irq da9052_irqs[] = {
},
};
-static struct regmap_irq_chip da9052_regmap_irq_chip = {
+static const struct regmap_irq_chip da9052_regmap_irq_chip = {
.name = da9052_irq,
.status_base = DA9052_EVENT_A_REG,
.mask_base = DA9052_IRQ_MASK_A_REG,
diff --git a/drivers/mfd/da9055-core.c b/drivers/mfd/da9055-core.c
index b4d920c1ead1..177e65a12c12 100644
--- a/drivers/mfd/da9055-core.c
+++ b/drivers/mfd/da9055-core.c
@@ -222,7 +222,7 @@ static bool da9055_register_volatile(struct device *dev,
unsigned int reg)
}
}
-static struct regmap_irq da9055_irqs[] = {
+static const struct regmap_irq da9055_irqs[] = {
[DA9055_IRQ_NONKEY] = {
.reg_offset = 0,
.mask = DA9055_IRQ_NONKEY_MASK,
@@ -245,7 +245,7 @@ static struct regmap_irq da9055_irqs[] = {
},
};
-struct regmap_config da9055_regmap_config = {
+const struct regmap_config da9055_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -367,7 +367,7 @@ static const struct mfd_cell da9055_devs[] = {
},
};
-static struct regmap_irq_chip da9055_regmap_irq_chip = {
+static const struct regmap_irq_chip da9055_regmap_irq_chip = {
.name = da9055_irq,
.status_base = DA9055_REG_EVENT_A,
.mask_base = DA9055_REG_IRQ_MASK_A,
diff --git a/drivers/mfd/da9063-irq.c b/drivers/mfd/da9063-irq.c
index 822922602ce9..eaf1ec9208b2 100644
--- a/drivers/mfd/da9063-irq.c
+++ b/drivers/mfd/da9063-irq.c
@@ -34,7 +34,7 @@ struct da9063_irq_data {
u8 mask;
};
-static struct regmap_irq da9063_irqs[] = {
+static const struct regmap_irq da9063_irqs[] = {
Re: [PATCH 1/2] clk: change clk_ops' -round_rate() prototype
The series Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi on Jetson-TK1. I rebased my cpufreq series on top of this and everything's working well now. :) Thanks, Mikko. On 04/17/2015 10:29 AM, Boris Brezillon wrote: ... -- 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/3] Introduce SET_NOIRQ_SYSTEM_SLEEP_PM_OPS and use it
grygorii.stras...@linaro.org writes: From: Grygorii Strashko grygorii.stras...@linaro.org While working on suspend-to-disk functionality on TI dra7-evm (DRA7xx SoC) i've found that the most common problem I have to dial with is absence of corresponding PM callbacks in drivers and, in particular, noirq callbacks. So, I've fixed one driver first commit 6248015d6867 ARM: omap-device: add missed callback for suspend-to-disk but then found another one which need to be fixed too (omap_l3_noc.c). At this moment I decided to make my life easier and added new macro SET_NOIRQ_SYSTEM_SLEEP_PM_OPS using the same approach as for the existing SET_SYSTEM_SLEEP_PM_OPS macro. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS: defined for CONFIG_PM_SLEEP and assigns -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same function. Vice versa happens for -resume_noirq, -thaw_noirq and -restore_noirq. Further two patches reuse this newly introduced macro. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will point -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same function. Vice versa happens for -resume_noirq, -thaw_noirq and -restore_noirq. For the series: Reviewed-by: Kevin Hilman khil...@linaro.org And for the omap_device changes: Acked-by: Kevin Hilman khil...@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
[PATCH] ARM: dts: omap3-gta04: Add hdqw1 support
Enable omap-hdq for battery fuel gauge access.
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index b9f6881..6ea1257 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -200,6 +200,12 @@
OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE0) /*
dss_data23.dss_data23 */
;
};
+
+ hdq_pins: hdq_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x21c6, PIN_INPUT_PULLUP | MUX_MODE0)
/* i2c3_sda.hdq */
+ ;
+ };
};
omap3_pmx_core2 {
@@ -517,3 +523,8 @@
mcbsp2 {
status = okay;
};
+
+hdqw1w {
+pinctrl-names = default;
+pinctrl-0 = hdq_pins;
+};
--
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 1/1] gpio: omap: Fix PM runtime issue and remove most BANK_USED macros
Hi Tony,
Sorry for delayed reply.
On 04/23/2015 05:39 PM, Tony Lindgren wrote:
* grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150423 04:13]:
On 04/21/2015 07:08 PM, Tony Lindgren wrote:
@@ -438,11 +447,30 @@ static void omap_enable_gpio_module(struct gpio_bank
*bank, unsigned offset)
writel_relaxed(ctrl, reg);
bank-context.ctrl = ctrl;
}
+
+ if (is_irq) {
+ omap_set_gpio_direction(bank, offset, 1);
+ bank-irq_usage |= BIT(offset);
+ } else {
+ omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
+ bank-mod_usage |= BIT(offset);
+ }
The OMAP GPIO driver implements two Core interfaces IRQ-chip and GPIO-chip
which, in general,
more or less independent.
So, I don't think, that it's good to mix GPIO-IRQ-chip specific code with
GPIO-chip code.
And this even don't really correspond the purpose of
omap_enable_gpio_module() :( and might
introduce misunderstanding of code. The worst thing is that future fixes in
IRQ-chip may
affect on on GPIO-chip and vise versa :(
Hmm I'm thinking omap_enable/disable_gpio_module() eventually becomes
our runtime_resume/suspend(). Currently the enabling and disabling is
buggy for GPIO for some corner cases.. AFAIK the only difference between
It might be very helpful if you'd able to share additional info about
any corner cases you know.
enabling GPIO vs GPIO-IRQ is the calling of omap_set_gpio_direction
vs omap_set_gpio_triggering. Or at least that's the way it should be
unless I'm missing something?
I think yes. what i'd like to say, first of all, is that it might be not good
idea to mix
too much functionality in omap_enable/disable_gpio_module() - especially
GPIO-IRQ vs
GPIO-chip ( Very easy to get lost ;)
For example (1) - your change of omap_gpio_request() looks like invalid:
static int omap_gpio_request(struct gpio_chip *chip, unsigned offset)
{
struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
- unsigned long flags;
- /*
-* If this is the first gpio_request for the bank,
-* enable the bank module.
-*/
- if (!BANK_USED(bank))
- pm_runtime_get_sync(bank-dev);
-
- spin_lock_irqsave(bank-lock, flags);
- /* Set trigger to none. You need to enable the desired trigger with
-* request_irq() or set_irq_type(). Only do this if the IRQ line has
-* not already been requested.
-*/
- if (!LINE_USED(bank-irq_usage, offset)) {
- omap_set_gpio_triggering(bank, offset, IRQ_TYPE_NONE);
- omap_enable_gpio_module(bank, offset);
^^ above two line should be executed only if GPIO line was not
requested as IRQ before
- }
- bank-mod_usage |= BIT(offset);
- spin_unlock_irqrestore(bank-lock, flags);
+ omap_enable_gpio_module(bank, offset, false);
^^ after your change, it looks like omap_set_gpio_triggering(bank, offset,
IRQ_TYPE_NONE)
will be called always and GPIO triggering configuration might be lost
return 0;
}
Example (2)
I've found commit 55b6019ae294 OMAP: GPIO: clear/restore level/edge detect
settings on mask/unmask
which does the following
gpio_mask_irq()
|- _set_gpio_triggering(bank, get_gpio_index(gpio), IRQ_TYPE_NONE);
gpio_unmask_irq()
|- u32 trigger = irqd_get_trigger_type(d);
if (trigger)
omap_set_gpio_triggering(bank, offset, trigger);
As result, it seems unreasonable to physically configure IRQ triggering type
in GPIO bank registers
inside omap_gpio_irq_type(). Of course, such assumption should be double
checked taking into account that
__irq_set_trigger() can be called any time even before request_irq().
Also, seems the same could be applied to omap_enable_gpio_module and
omap_set_gpio_direction and they
could be removed from omap_gpio_irq_type().
Could we keep omap_xxx_gpio_module() functions responsible only for GPIO
bank PM and
enabling/disabling?
If you're thinking about just thinking about having separate wrappers around
it like this::
static void omap_enable_gpio_module(struct gpio_bank *bank, unsigned offset,
bool is_irq)
{
...
}
static void omap_enable_gpio((struct gpio_bank *bank, unsigned offset)
{
omap_enable_gpio_module(bpio_bank, offset, 0);
}
static void omap_enable_gpio_irq((struct gpio_bank *bank, unsigned offset)
{
omap_enable_gpio_module(bpio_bank, offset, 1);
}
Then yes makes sense to me. Or do you have something else in mind?
Yep. Commented above.
Also, it probably could work if we will set GPIO_CTRL.DISABLEMODULE=1
in omap_gpio_runtime_resume and GPIO_CTRL.DISABLEMODULE=0 in _runtime_suspend,
but it may require from us to split CPUIdle and suspend code path (
--
regards,
-grygorii
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Re: [PATCH 0/3] Introduce SET_NOIRQ_SYSTEM_SLEEP_PM_OPS and use it
On 27 April 2015 at 20:24, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org While working on suspend-to-disk functionality on TI dra7-evm (DRA7xx SoC) i've found that the most common problem I have to dial with is absence of corresponding PM callbacks in drivers and, in particular, noirq callbacks. So, I've fixed one driver first commit 6248015d6867 ARM: omap-device: add missed callback for suspend-to-disk but then found another one which need to be fixed too (omap_l3_noc.c). At this moment I decided to make my life easier and added new macro SET_NOIRQ_SYSTEM_SLEEP_PM_OPS using the same approach as for the existing SET_SYSTEM_SLEEP_PM_OPS macro. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS: defined for CONFIG_PM_SLEEP and assigns -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same function. Vice versa happens for -resume_noirq, -thaw_noirq and -restore_noirq. Further two patches reuse this newly introduced macro. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, defined for CONFIG_PM_SLEEP, will point -suspend_noirq, -freeze_noirq and -poweroff_noirq to the same function. Vice versa happens for -resume_noirq, -thaw_noirq and -restore_noirq. Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com Cc: Kevin Hilman khil...@linaro.org Cc: Santosh Shilimkar ssant...@kernel.org Grygorii Strashko (3): PM / Sleep: Add macro to define common noirq system PM callbacks bus: omap_l3_noc: add missed callbacks for suspend-to-disk ARM: omap-device: use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS arch/arm/mach-omap2/omap_device.c | 7 ++- drivers/bus/omap_l3_noc.c | 4 ++-- include/linux/pm.h| 12 3 files changed, 16 insertions(+), 7 deletions(-) -- 1.9.1 For the patchset. Reviewed-by: Ulf Hansson ulf.hans...@linaro.org Kind regards Uffe -- 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: ARM errata 430973 on multi platform kernels
On Thu, Apr 23, 2015 at 07:17:28AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [150423 03:26]: However, I don't think anyone is willing to say that they have a solution to this problem - obviously, you can't build OMAP as a non-multiplatform kernel anymore, so in effect you can never have the kernel enable this errata. And you can't detect whether you're running in secure mode or not. We could do the only write the bit if it was originally clear but we still have the problem that doing so may cause other people regressions. How about we keep the bit writing part !multiplatform conditional (or even remove it) but always do the flush for ca-8? Then we could also do a warning for a misconfigured ca-8 later on. Yes, we could do this - we'll have to rely on the boot loader doing the right thing and setting this bit appropriately. For those platforms where this doesn't apply, I don't see any solution as (iirc) OMAP now requires MULTIPLATFORM to be enabled. -- FTTC broadband for 0.8mile line: currently at 10.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: ARM errata 430973 on multi platform kernels
On Fri, Apr 24, 2015 at 10:54:29AM +0200, Matthijs van Duin wrote: On 23 April 2015 at 12:25, Russell King - ARM Linux li...@arm.linux.org.uk wrote: And you can't detect whether you're running in secure mode or not. If not, you get an undefined instruction exception, which you could trap. This may not be convenient, but can't detect is an overstatement. It's these kinds of statements that really piss me off. At this stage in the boot, there's no memory allocators. There's no MMU. There's really not very much. There's no guarantee that the location where the vectors are is writable on all platforms. It's pretty much _impossible_ to do generically. Can't detect is _not_ an overstatement. It's a statement that I'm giving you through my experience and knowledge of the Linux kernel, the ARM archtecture, the capabilities of the platforms we have to deal with, and how we want the kernel to work. Sure, we _can_ detect it if (and only if) we code specifically for a platform which has RAM at the CPU vector location. Unfortunately, that's a _very_ small proportion which approximates a number very close to zero. -- FTTC broadband for 0.8mile line: currently at 10.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
