Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
Оригинално писмо От: Pavel Machek Относно: Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode До: Pali Rohár Изпратено на: Понеделник, 2013, Ноември 25 17:18:39 EET On Mon 2013-11-25 15:10:00, Pali Rohár wrote: On Monday 25 November 2013 15:01:27 Pavel Machek wrote: Where can I get dsme sources? Pavel dsme daemon: https://gitorious.org/community-ssu/dsme dsme thermal plugin: https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface dsme thermal plugin is responsible for checking temperature of battery and send it to dsme damon. dsme daemon itself checking temperature limits and do something (e.g reboot device) Thanks for links! AFAICT dsme daemon does some kind of system management, not directly controlling charging, right? It does monitor system temperature. Now.. Imagine phone left in car in charger (on sun). Likely temperature will reach high values, kernel is charging, dsme will reboot the system, but kernel will start charging again, dsme will reboot again, ... And it is not only high temperatures that are problem for li-ion charging; battery should not be fast charged below 5C and should not be charged below 0C. (Again, both are likely to happen if you leave your phone in car). AFAICT, we should simply disable charging below 5C or above 45C. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html AFAIK dsme will not restart it, but power it off, so the above scenario won't happen. Regards, Ivo -- 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 2/3] bq2415x_charger: Use power_supply notifier for automode
Оригинално писмо От: Sebastian Reichel Относно: Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode До: Ивайло Димитров Изпратено на: Понеделник, 2013, Ноември 25 19:14:21 EET On Mon, Nov 25, 2013 at 07:01:54PM +0200, Ивайло Димитров wrote: Now.. Imagine phone left in car in charger (on sun). Likely temperature will reach high values, kernel is charging, dsme will reboot the system, but kernel will start charging again, dsme will reboot again, ... And it is not only high temperatures that are problem for li-ion charging; battery should not be fast charged below 5C and should not be charged below 0C. (Again, both are likely to happen if you leave your phone in car). AFAICT, we should simply disable charging below 5C or above 45C. AFAIK dsme will not restart it, but power it off, so the above scenario won't happen. Just assume what happens, when dsme does not start (e.g. system boot hangs). If everything is controlled from userspace, charger would not start (- safe!). If everything is controlled by the kernel, temperature safety checks are taken (- safe!). But in the currently proposed variant: No safety checks. -- Sebastian Hmm, you have a point here :) So, AIUI there are 2 options: 1. charger driver polls the battery driver every n (60?) seconds. 2. battery driver sends PSY_EVENT_PROP_CHANGED on every degree up or down In both cases if the temperature is outside of the safe margins, the charging should be stopped. 2 seems more generic to me, but as rx51-battery is missing the functionality to send events on temperature change, I guess 1 will be easier to implement. And I think there should be some method (sysfs entry?, /dev/bqxxx opened?) to tell the charger driver to stop polling the battery driver once (and if) the userspace has started to take care of the battery temperature - makes no sense to duplicate the checks IMO. -- 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 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v3 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Понеделник, 2013, Август 5 16:29:44 EEST
On Sun, Aug 04, 2013 at 10:45:00AM +0200, Pali Rohár wrote:
Here is new version (v3) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling instruction smc
#0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..7bbc043 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* 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
@@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb @ Memory Barrier
Can you explain _why_ the barrier is there? The reader doesn't need to
be told that a barrier instruction is a barrier instruction.
Cheers
---Dave
Hi Dave,
Would quoting Santosh's explanation DSBs were needed on OMAP for power
sequencing. do the job?
Something like @ Needed on OMAP for power sequencing instead of @ Memory
Barrier.
I want to be sure I correctly understand your requirement.
Regards,
Ivo
--
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/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
Оригинално писмо
От: Dave Martin
Относно: Re: [PATCH v2 1/2] ARM: OMAP: Add secure function omap_smc3() which
calling instruction smc #1
До: Pali Rohár
Изпратено на: Сряда, 2013, Юли 10 20:45:26 EEST
On Wed, Jul 10, 2013 at 02:59:04PM +0200, Pali Rohár wrote:
Other secure functions omap_smc1() and omap_smc2() calling instruction smc
#0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/omap-secure.h |1 +
arch/arm/mach-omap2/omap-smc.S| 22 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..5c02b8d 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* 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
@@ -54,6 +56,24 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r12, lr}
You don't need to save/restore r12. The ABI allows it to be clobbered
across function calls.
+ mov r12, r0 @ Copy the secure service ID
+ mov r6, #0xff @ Indicate new Task call
+ dsb
+ dmb
dsb synchronises a superset of what dmb synchronises, so the dmb here is
not useful.
In any case, any code calling this must flush the region addressed by
r3 beforehand anyway, which will include a dsb as part of its semantics
-- this is how you call it from rx51_secure_dispatcher().
So I think the dsb may not be needed here (?)
Cheers
---Dave
Could be, but I wonder why almost all the kernel code(I am aware of) that uses
SMC and is written by TI, is storing r12 and is using both DSB and DMB. See
arch/arm/mach-omap2/sleep34xx.S or arch/arm/mach-omap2/omap-smc.S for examples.
I'd rather play it safe and leave it that way, unless someone confirms the
other code using SMC has extra DSB/DMB instructions too. I wouldn't risk
passing invalid/stale data to the Secure Monitor to just save 8 bytes and
barriers in a performance non-critical code which will be called only a couple
of times during the boot-up process. r12 save/restore is a legacy from
omap_smc2 in omap-smc.S, so I guess it can go away without much of a trouble.
--
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] OMAP3 ROM Random Number Generator support
It could be that I am misreading something, but RX51 is OMAP3.
Regards,
Ivo
Оригинално писмо
От: Tony Lindgren
Относно: Re: [PATCH] OMAP3 ROM Random Number Generator support
До: Ивайло Димитров
Изпратено на: Понеделник, 2013, Април 1 19:59:50 EEST
* Ивайло Димитров [130331 05:10]:
Hi Pali,
Yep, the code looks almost identical, I guess with some tweaks all SMC code
from that patch could be removed and instead used the one from SMC PPA API.
What I don't get, is why one needs to disable/enable fiqs/irqs:
+static int call_sec_rom(u32 appl_id, u32 proc_id, u32 flag, ...)
+{
+ va_list ap;
+ u32 ret;
+ u32 val;
+
+ va_start(ap, flag);
+ val = *(u32 *) amp;ap;
+ local_irq_disable();
+ local_fiq_disable();
+ ret = omap3_rom_rng_call(appl_id, proc_id, flag,
+(u32) virt_to_phys((void *) val));
+ local_fiq_enable();
+ local_irq_enable();
+ va_end(ap);
+
+ return ret;
+}
Do you have any idea why is that needed? Any other code I've ever seen to
call SM, does not disable fiqs/irqs, is RNG SMC somehow special? I know
this is Nokia's code, but still, if we can get some understanding...
Sounds like the fiq handling can be dropped based on what
the TI guys posted recently about FIQs only be available in
the secure mode starting with omap2.
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: [PATCH] OMAP3 ROM Random Number Generator support
Hi Pali,
Yep, the code looks almost identical, I guess with some tweaks all SMC code
from that patch could be removed and instead used the one from SMC PPA API.
What I don't get, is why one needs to disable/enable fiqs/irqs:
+static int call_sec_rom(u32 appl_id, u32 proc_id, u32 flag, ...)
+{
+ va_list ap;
+ u32 ret;
+ u32 val;
+
+ va_start(ap, flag);
+ val = *(u32 *) ap;
+ local_irq_disable();
+ local_fiq_disable();
+ ret = omap3_rom_rng_call(appl_id, proc_id, flag,
+(u32) virt_to_phys((void *) val));
+ local_fiq_enable();
+ local_irq_enable();
+ va_end(ap);
+
+ return ret;
+}
Do you have any idea why is that needed? Any other code I've ever seen to call
SM, does not disable fiqs/irqs, is RNG SMC somehow special? I know this is
Nokia's code, but still, if we can get some understanding...
Regards,
Ivo
Оригинално писмо
От: Pali Rohár
Относно: Re: [PATCH] OMAP3 ROM Random Number Generator support
До: Tony Lindgren
Изпратено на: Неделя, 2013, Март 31 12:28:12 EEST
On Thursday 28 March 2013 22:44:11 Tony Lindgren wrote:
* Pali Rohár [130328 10:58]:
Here is new version of patch:
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -486,6 +486,23 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
+extern u32 *omap3_rom_rng_call(u32 id, u32 proc, u32 flags,
u32 va_ptr); +
+static struct platform_device omap3_rom_rng_device = {
+ .name = quot;omap3-rom-rngquot;,
+ .id = -1,
+ .dev= {
+ .platform_data = omap3_rom_rng_call,
+ },
+};
+
+static void omap_init_rom_rng(void)
+{
+ if (!cpu_is_omap34xx() || omap_type() ==
OMAP2_DEVICE_TYPE_GP) + return;
+ platform_device_register(amp;omap3_rom_rng_device);
+}
+
/**
* omap_init_rng - bind the RNG hwmod to the RNG
omap_device *
This driver probably only works on Nokia boards because of the
different SMC call numbering. Until it's been verified on some
other HS omap34xx, I'd probably register this only from the
Nokia board-*.c file.
Freemangordon, can you look at this smc and errara 430973 code if
they could be merged? Really omap3_rom_rng_call function looks
like n900 specific.
Link: https://lkml.org/lkml/2013/3/28/398
--- /dev/null
+++ b/drivers/char/hw_random/omap3-rom-rng.c
+static int omap3_rom_rng_probe(struct platform_device
*pdev) +{
+ printk(KERN_INFO quot;%s: initializing#92;nquot;,
omap3_rom_rng_name); +
+ omap3_rom_rng_call = pdev-dev.platform_data;
+ if (!omap3_rom_rng_call) {
+ printk(KERN_ERR quot;%s: omap3_rom_rng_call is
NULL#92;nquot;,
+omap3_rom_rng_name);
+ return -EINVAL;
+ }
+
+ setup_timer(amp;idle_timer, omap3_rom_idle_rng, 0);
+ rng_clk = clk_get_sys(quot;omap_rngquot;, quot;ickquot;);
+ if (IS_ERR(rng_clk)) {
+ printk(KERN_ERR quot;%s: unable to get RNG clock#92;nquot;,
+omap3_rom_rng_name);
+ return IS_ERR(rng_clk);
+ }
You can use regular clk_get if you add the alias to
struct omap_clk omap3xxx_clks table.
Regards,
Tony
Tony, can you show me how?
--
Pali Rohár
pali.ro...@gmail.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: omap: RX-51: ARM errata 430973 workaround
Hi,
Оригинално писмо
От: Pavel Machek
Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
До: Pali Rohár
Изпратено на: Събота, 2013, Март 30 20:36:54 EET
Hi!
+u32 rx51_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32
arg2,
+ u32 arg3, u32 arg4)
+{
+ u32 ret;
+ u32 param[5];
+
+ param[0] = nargs+1;
+ param[1] = arg1;
+ param[2] = arg2;
+ param[3] = arg3;
+ param[4] = arg4;
+
+ /*
+* Secure API needs physical address
+* pointer for the parameters
+*/
+ flush_cache_all();
+ outer_clean_range(__pa(param), __pa(param + 5));
+ ret = rx51_ppa_smc(idx, flag, __pa(param));
+
+ return ret;
+}
You can do without ret variable... Also more detailed changelog would
be nice... like what exact problem this works around.
Sure i can, but I don't see a reason to ignore SM's return value. Changelog of
what?
So... some CPU errata where code sharing virtual addresses could be
executed improperly?
@@ -103,6 +104,12 @@ static void __init rx51_init(void)
rx51_peripherals_init();
rx51_camera_init();
+#ifdef CONFIG_ARM_ERRATA_430973
+ printk(KERN_INFO quot;Enabling ARM errata 430973
workaround.#92;nquot;);
+ /* set IBE to 1 */
+ rx51_secure_update_aux_cr(1 6, 0);
+#endif
+
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
I guess if you read the thread over the ML you'll have your questions already
answered.
Or google for ARM errata 430973 workaround :).
Regards,
Ivo
--
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: RX-51: ARM errata 430973 workaround
Tony, Who do you expect to make that code merge? Do you expect us to mechanically merge RX51 PPA API patch with the existing generic OMAP PPA API code putting #ifdefs all over the place? Not that it is impossible, but the only real piece of HW I have here is n900, so I just can't be sure the code will still work on the other platforms besides RX51, once the code modified. Please, advice on how to proceed. Regards, Ivo Оригинално писмо От: Tony Lindgren Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround До: Pali Rohár Изпратено на: Сряда, 2013, Март 27 23:12:09 EET * Pali Rohár [130327 14:09]: On Wednesday 27 March 2013 21:56:07 Tony Lindgren wrote: * Pali Rohár [130324 07:31]: it is possible to upstream errata 430973 workaround for RX-51? I think we should make the SMC handling a generic function for ARM. AFAIK just the SMC call numbering is different for various implementations. So the handler and passing of the parameters seems like it should be generic. Not only, look at freemangordon's email: https://lkml.org/lkml/2013/3/1/62 Seem like you may need some SoC specific wrapper to the generic function to deal with the params. But still seems like we can have an ARM generic smc funtion. 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: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Оригинално писмо От: Aaro Koskinen Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround До: Ивайло Димитров Изпратено на: Събота, 2013, Март 2 01:51:39 EET On Fri, Mar 01, 2013 at 12:09:12PM +0200, Ивайло Димитров wrote: Unfortunately it is necessary, on RX-51 PPA/NOLO leaves IBE bit unset. You sure? I think you need to explain this more - the commit message in the original patch is empty/missing... A. Yes, I am sure, NOLO leaves IBE bit in ACR unset, I've verified that by reading/printing the contents of ACR from both u-boot and the kernel itself. With IBE bit unset, mcr p15, 0, rX, c7, c5, 6 - flush BTAC/BTB instruction(which is needed to workaround errata 430973) is a noop. Yes, I am sure, IBE but must be set by using a call to PPA, on RX-51 setting that bit from the kernel (as it is done in the ARM errata: Stale prediction on replaced interworking branch kernel patch, see http://kerneltrap.org/mailarchive/git-commits-head/2009/5/3/5622724) does not work, see the comment at the end: Note that setting specific bits in the ACTLR register may not be available in non-secure mode.. This is exactly the case for RX-51. I've verified that too. If you need anything else elaborated on, I'm fine, just ask :) Regards, Ivo -- 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: RX-51: ARM errata 430973 workaround
Unfortunately it is necessary, on RX-51 PPA/NOLO leaves IBE bit unset. Оригинално писмо От: Peter De Schrijver Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround До: Pali Rohár Изпратено на: Петък, 2013, Март 1 11:43:14 EET On Thu, Feb 28, 2013 at 10:42:28AM +0100, Pali Rohár wrote: Signed-off-by: Ivaylo Dimitrov Signed-off-by: Pali Rohár --- arch/arm/mach-omap2/Makefile|1 + arch/arm/mach-omap2/board-rx51-secure.c | 66 +++ arch/arm/mach-omap2/board-rx51-secure.h | 36 + arch/arm/mach-omap2/board-rx51-smc.S| 34 arch/arm/mach-omap2/board-rx51.c|7 5 files changed, 144 insertions(+) create mode 100644 arch/arm/mach-omap2/board-rx51-secure.c create mode 100644 arch/arm/mach-omap2/board-rx51-secure.h create mode 100644 arch/arm/mach-omap2/board-rx51-smc.S Is this necessary? I thought the PPA sets this bit? Cheers, Peter. -- 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: RX-51: ARM errata 430973 workaround
They look similar, but they are not equivalent :). The first major difference
is here (code taken from omap-smc.S)
ENTRY(omap_smc2)
stmfd sp!, {r4-r12, lr}
mov r3, r2
mov r2, r1
mov r1, #0x0@ Process ID
mov r6, #0xff
mov r12, #0x00 @ Secure Service ID
Always zero, while RX51 PPA expects a real value. I wonder if it is a bug, but
anyway I don't see the id parameter (R0) used.
mov r7, #0
mcr p15, 0, r7, c7, c5, 6
According to ARM TRM, this is Invalidate entire branch predictor array(IIUC).
NFC why it is needed here, but this will not work on RX-51 until IBE bit in ACR
is set.
dsb
dmb
smc #0
RX-51 needs smc #1 ;)
ldmfd sp!, {r4-r12, pc}
The next major difference is that RX-51 expects parameter count passed in R3[0]
to be the count of the remaining parameters +1, but omap_secure_dispatcher (in
omap-secure.c) is passing the exact count of the remaining parameters.
I guess all of the above problems can be fixed/workarounded, but I wonder does
it worth. Not to say that I don't have BB around to test if the code still
works if I make changes to omap2-secure.c/omap-smc.S :)
Оригинално писмо
От: Nishanth Menon
Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
До: Pali Rohár
Изпратено на: Четвъртък, 2013, Февруари 28 16:40:05 EET
On 10:42-20130228, Pali Rohár wrote:
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-rx51-secure.c | 66
+++
arch/arm/mach-omap2/board-rx51-secure.h | 36 +
arch/arm/mach-omap2/board-rx51-smc.S| 34
arch/arm/mach-omap2/board-rx51.c|7
Wondering if we can integrate these into
arch/arm/mach-omap2/omap-smc.S
and
arch/arm/mach-omap2/omap-secure.c
on a quick look, it does seem there are commonalities.
5 files changed, 144 insertions(+)
create mode 100644 arch/arm/mach-omap2/board-rx51-secure.c
create mode 100644 arch/arm/mach-omap2/board-rx51-secure.h
create mode 100644 arch/arm/mach-omap2/board-rx51-smc.S
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0ebbdd50..8eb4fb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -241,6 +241,7 @@ obj-#36;(CONFIG_MACH_NOKIA_RX51) +=
board-rx51.o sdram-nokia.o
obj-#36;(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o
obj-#36;(CONFIG_MACH_NOKIA_RX51) += board-rx51-video.o
obj-#36;(CONFIG_MACH_NOKIA_RX51) += board-rx51-camera.o
+obj-#36;(CONFIG_MACH_NOKIA_RX51) += board-rx51-smc.o
board-rx51-secure.o
obj-#36;(CONFIG_MACH_OMAP_ZOOM2) += board-zoom.o
board-zoom-peripherals.o
obj-#36;(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-display.o
obj-#36;(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-rx51-secure.c
b/arch/arm/mach-omap2/board-rx51-secure.c
new file mode 100644
index 000..361dc78
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-secure.c
@@ -0,0 +1,66 @@
+/*
+ * RX51 Secure PPA API.
+ *
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ *
+ *
+ * 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
+
+#include quot;board-rx51-secure.hquot;
+
+/**
+ * rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
+ * @idx: The PPA API index
+ * @flag: The flag indicating criticality of operation
+ * @nargs: Number of valid arguments out of four.
+ * @arg1, arg2, arg3 args4: Parameters passed to secure API
+ *
+ * Return the non-zero error value on failure.
+ */
+u32 rx51_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32
arg2,
+ u32 arg3, u32 arg4)
+{
+ u32 ret;
+ u32 param[5];
+
+ param[0] = nargs+1;
+ param[1] = arg1;
+ param[2] = arg2;
+ param[3] = arg3;
+ param[4] = arg4;
+
+ /*
+* Secure API needs physical address
+* pointer for the parameters
+*/
+ flush_cache_all();
+ outer_clean_range(__pa(param), __pa(param + 5));
+ ret = rx51_ppa_smc(idx, flag, __pa(param));
+
+ return ret;
+}
+
+/**
+ * rx51_secure_update_aux_cr: Routine to modify the contents of Auxiliary
Control Register
+ * @set_bits: bits to set in ACR
+ * @clr_bits: bits to clear in ACR
+ *
+ * Return the non-zero error value on failure.
+*/
+u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits)
+{
+ u32 acr;
+
+ /* Read ACR */
+ asm volatile (quot;mrc p15, 0,
