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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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, 

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 




  Оригинално писмо 
 От:  Tomi Valkeinen 
 Относно: Re: OMAPFB: CMA allocation failures
 До: Ивайло Димитров
 Изпратено на: Сряда, 2013, Октомври 30 14:19:32 EET
 
 I really dislike the idea of adding the omap vram allocator back. Then
 again, if the CMA doesn't work, something has to be done.
 

If I got Minchan Kim's explanation correctly, CMA simply can't be used
for allocation of framebuffer memory, because it is unreliable.

 Pre-allocating is possible, but that won't work if there's any need to
 re-allocating the framebuffers. Except if the omapfb would retain and
 manage the pre-allocated buffers, but that would just be more or less
 the old vram allocator again.
 
 So, as I see it, the best option would be to have the standard dma_alloc
 functions get the memory for omapfb from a private pool, which is not
 used for anything else.
 
 I wonder if that's possible already? It sounds quite trivial to me.
 
dma_alloc functions use either CMA or (iirc) get_pages_exact if CMA is
disabled. Both of those fail easily. AFAIK there are several 
implementations with similar functionality, like CMEM and ION but
(correct me if I am wrong) neither of them is upstreamed. In the 
current kernel I don't see anything that can be used for the purpose 
of reliable allocation of big chunks of contiguous memory.
So, something should be done, but honestly, I can't think of anything
but bringing VRAM allocator back. Not that I like the idea of bringing
back ~700 lines of code, but I see no other option if omapfb driver is
to be actually useful.

Regards,
Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi Tomi,

 I think we should somehow find out what the pages are that cannot be
 migrated, and where they come from.
 
 So there are quot;anonymous pages without mappingquot; with 
 page_count(page) !=
 1. I have to say I don't know what that means =). I need to find some
 time to study the mm.

I put some more traces in the point of failure, the result:

page_count(page) == 2, page-flags == 0x0008025D, which is:

PG_locked, PG_referenced, PG_uptodate, PG_dirty, PG_active, PG_arch_1, 
PG_unevictable

Whatever those mean :). I have no idea how to identify where those pages come 
from.

 Well, as I said, you're the first one to report any errors, after the
 change being in use for a year. Maybe people just haven't used recent
 enough kernels, and the issue is only now starting to emerge, but I
 wouldn't draw any conclusions yet.

I am (almost) sure I am the first one to test video playback on OMAP3 with DSP 
video
acceleration, using recent kernel and Maemo5 on n900 :). So there is high 
probability the issue was not reported earlier because noone have tested it 
thoroughly after the change.

 If the CMA would have big generic issues, I think we would've seen
 issues earlier. So I'm guessing it's some driver or app in your setup
 that's causing the issues. Maybe the driver/app is broken, or maybe that
 specific behavior is not handled well by CMA. In both case I think we
 need to identify what that driver/app is.

What I know is going on, is that there is heavy fs I/O at the same time - there 
is
a thumbnailer process running in background which tries to extract thumbnails 
of all video
files in the system. Also, there are other processes doing various jobs (e-mail 
fetching, IM
accounts login, whatnot). And in addition Xorg mlocks parts of its address 
space. Of course all
this happens with lots of memory being swapped in and out. I guess all this is 
related.

However, even after the system has settled, the CMA failures continue to 
happen. It looks like
some pages are allocated from CMA which should not be.

 I wonder how I could try to reproduce this with a generic omap3 board...

I can always reproduce it here (well, not on generic board, but I guess it is 
even better to test in real-life conditions), so if you need some specific 
tests or traces or whatever, I
can do them for you.

Regards,
Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Staging: tidspbridge: make mmap root-only so it is not a security problem

[Ивайло Димитров]

I can (and will) test whatever patches is needed. Also will try to get rid of 
uuid helpers and send a patch today.

On Sun Dec   1 11:41:39 2013 Pali Rohár pali.ro...@gmail.com wrote:
 On Saturday 30 November 2013 23:58:23 Pavel Machek wrote:
  On Sat 2013-11-30 14:05:53, Greg KH wrote:
   On Sat, Nov 30, 2013 at 09:42:37PM +0100, Pavel Machek wrote:
mmap in tidspbridge is missing range-checks. For now, make
this interface root-only, so that it does not cause
security problems.
   
   Please fix this properly and don't paper over the real
   problem here.
  
  Well, if the driver is left uncompilable, I'm pretty sure it
  will bitrot.
  
 
 If you want to compile tidspbridge driver, you need this patch:
 https://gitorious.org/linux-n900/linux-n900/commit/b9adde42d5351467fa9d281190213bb652499577
 
 Removing BROKEN is not enough.
 
  I do have the hardware, but I'm pretty sure current mailine
  does not have enough support to boot Maemo, so it is non
  trivial for me to test changes here.
  
 
 Use linux-n900 tree, there are patches also for tidspbridge
 driver, so old maemo and new harmattan userspace can use it. But
 HD videos not working yet (due to another problem, search for
 OMAPFB: CMA allocation failures).
 
 -- 
 Pali Rohár
 pali.ro...@gmail.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi Tomi,

patch 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html 
modifies
omapfb driver to use DMA API to allocate framebuffer memory instead of 
preallocating VRAM.

With this patch I see a lot of:

Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
dma_alloc_from_contiguous(): returned   (null)
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed to 
allocate framebuffer

errors while trying to play a video on N900 with Maemo 5 (Fremantle) on top of 
linux-3.12rc1.
It is deffinitely the CMA that fails to allocate the memory most of the times, 
but I wonder
how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, but 
that made no
difference. If CMA is disabled, the memory allocation still fails as obviously 
it is highly
unlikely there will be such a big chunk of continuous free memory on RAM 
limited device like
N900. 

One obvious solution is to just revert the removal of VRAM memory allocator, 
but that would
mean I'll have to maintain a separate tree with all the implications that 
brings.

What would you advise on how to deal with the issue?

Regards,
Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi

  Оригинално писмо 
 От:  Tomi Valkeinen 
 Относно: Re: OMAPFB: CMA allocation failures
 До: Ивайло Димитров

 Изпратено на: Понеделник, 2013, Октомври 14 09:04:35 EEST
 
 
 Hi,
 
 On 12/10/13 17:43, Ивайло Димитров wrote:
   Hi Tomi,
  
  patch 
  http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html
   modifies
  omapfb driver to use DMA API to allocate framebuffer memory instead of 
  preallocating VRAM.
  
  With this patch I see a lot of:
  
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
  dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
  dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
  dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
  dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
  dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
  dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
  dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
  dma_alloc_from_contiguous(): returned   (null)
  Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed to 
  allocate framebuffer
  
  errors while trying to play a video on N900 with Maemo 5 (Fremantle) on top 
  of linux-3.12rc1.
  It is deffinitely the CMA that fails to allocate the memory most of the 
  times, but I wonder
  how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, but 
  that made no
  difference. If CMA is disabled, the memory allocation still fails as 
  obviously it is highly
  unlikely there will be such a big chunk of continuous free memory on RAM 
  limited device like
  N900. 
  
  One obvious solution is to just revert the removal of VRAM memory 
  allocator, but that would
  mean I'll have to maintain a separate tree with all the implications that 
  brings.
  
  What would you advise on how to deal with the issue?
 
 I've not seen such errors, and I'm no expert on CMA. But I guess the
 contiguous memory area can get fragmented enough no matter how hard one
 tries to avoid it. The old VRAM system had the same issue, although it
 was quite difficult to hit it.

I am using my n900 as a daily/only device since the beginning of 2010, never 
seen such an 
issue with video playback. And as a maintainer of one of the community 
supported kernels for
n900 (kernel-power) I've never had such an issue reported. On stock kernel and 
derivatives of
course. It seems VRAM allocator is virtually impossible to fail, while with CMA 
OMAPFB fails on
the first video after boot-up.

When saying you've not seen such an issue - did you actually test video 
playback, on what
device and using which distro? Did you use DSP accelerated decoding?

 64MB does sound quite a lot, though. I wonder what other drivers are
 using CMA, and how do they manage to allocate so much memory and
 fragment it so badly... With double buffering, N900 should only need
 something like 3MB for the frame buffer.

Sure, 64 MB is a lot, but I just wanted to see if that would make any 
difference. And for 720p 
3MB is not enough, something like 8MB is needed.

 With a quick glance I didn't find any debugfs or such files to show
 information about the CMA area. It'd be helpful to find out what's going
 on there. Or maybe normal allocations are fragmenting the CMA area, but
 for some reason they cannot be moved? Just guessing.

I was able to track down the failures to:
http://lxr.free-electrons.com/source/mm/migrate.c#L320

So it seems the problem is not that CMA gets fragmented, rather some pages 
cannot be migrated.
Unfortunately, my knowledge stops here. Someone from the mm guys should be 
involved in the
issue as well? I am starting to think there is some serious issue with CMA 
and/or mm I am
hitting on n900. As it is not the lack of free RAM that is the problem - 
echo 3/proc/sys/vm/drop_caches results in more that 45MB of free RAM 
according to free.

 There's also dma_declare_contiguous() that could be used to reserve
 memory for omapfb. I have not used it, and I have no idea if it would
 help here. But it's something you could try.

dma_declare_contiguous() won't help IMO, it just reserves CMA area that is 
private to the
driver, so it is used instead of the global CMA area, but I don't see how that 
would help in my
case.

Anyway, what about reverting VRAM allocator removal and migrating it to DMA 
API, the same way
DMA coherent pool is allocated and managed? Or simply revering VRAM allocator 
removal :) ?

Regards,
Ivo
--
To unsubscribe

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 
Hi,


  Оригинално писмо 
 От:  Minchan Kim 
 Относно: Re: OMAPFB: CMA allocation failures
 До: Ивайло Димитров 
 Изпратено на: Понеделник, 2013, Октомври 28 09:37:48 EET
 
 
 Hello,
 
 On Tue, Oct 15, 2013 at 09:49:51AM +0300, Ивайло Димитров wrote:
   Hi
  
    Оригинално писмо 
   От:  Tomi Valkeinen 
   Относно: Re: OMAPFB: CMA allocation failures
   До: Ивайло Димитров
  
   Изпратено на: Понеделник, 2013, Октомври 14 09:04:35 EEST
   
   
   Hi,
   
   On 12/10/13 17:43, Ивайло Димитров wrote:
 Hi Tomi,

patch 
  http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html
   modifies
omapfb driver to use DMA API to allocate framebuffer memory instead of 
  preallocating VRAM.

With this patch I see a lot of:

Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
  dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
  dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
  dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
  dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
  dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
  dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
  dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
  dma_alloc_from_contiguous(): returned   (null)
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed 
  to allocate framebuffer

errors while trying to play a video on N900 with Maemo 5 (Fremantle) on 
  top of linux-3.12rc1.
It is deffinitely the CMA that fails to allocate the memory most of the 
  times, but I wonder
how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, 
  but that made no
difference. If CMA is disabled, the memory allocation still fails as 
  obviously it is highly
unlikely there will be such a big chunk of continuous free memory on 
  RAM limited device like
N900. 

One obvious solution is to just revert the removal of VRAM memory 
  allocator, but that would
mean I'll have to maintain a separate tree with all the implications 
  that brings.

What would you advise on how to deal with the issue?
   
   I've not seen such errors, and I'm no expert on CMA. But I guess the
   contiguous memory area can get fragmented enough no matter how hard one
   tries to avoid it. The old VRAM system had the same issue, although it
   was quite difficult to hit it.
  
  I am using my n900 as a daily/only device since the beginning of 2010, 
  never seen such an 
  issue with video playback. And as a maintainer of one of the community 
  supported kernels for
  n900 (kernel-power) I've never had such an issue reported. On stock kernel 
  and derivatives of
  course. It seems VRAM allocator is virtually impossible to fail, while with 
  CMA OMAPFB fails on
  the first video after boot-up.
  
  When saying you've not seen such an issue - did you actually test video 
  playback, on what
  device and using which distro? Did you use DSP accelerated decoding?
  
   64MB does sound quite a lot, though. I wonder what other drivers are
   using CMA, and how do they manage to allocate so much memory and
   fragment it so badly... With double buffering, N900 should only need
   something like 3MB for the frame buffer.
  
  Sure, 64 MB is a lot, but I just wanted to see if that would make any 
  difference. And for 720p 
  3MB is not enough, something like 8MB is needed.
  
   With a quick glance I didn't find any debugfs or such files to show
   information about the CMA area. It'd be helpful to find out what's going
   on there. Or maybe normal allocations are fragmenting the CMA area, but
   for some reason they cannot be moved? Just guessing.
  
  I was able to track down the failures to:
  http://lxr.free-electrons.com/source/mm/migrate.c#L320
 
 That path is for anonymous page migration so the culprit I can think of
 is that you did get_user_pages on those anonymous pages for pin them.
 Right?
 

I grepped through the code and there are lots of places where get_user_pages is 
called, though
I suspect either SGX or DSP (or both) drivers to be the ones to blame. Both of 
them are active
and needed for HW accelerated video decoding.

 If so, it's no surpse that fails the migration and CMA doesn't work.
 
 -- 
 Kind regards,
 Minchan Kim
 

Well, if CMA is to be reliable, I would expect some logic to take care about 
get_user_pages
causing MIGRATE_CMA pages

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi,

I wonder if there is any progress on the issue? Do you need me to send more 
data? Or
should I raise the issue with the CMA maintainer?

Regards,
Ivo

  Оригинално писмо 
 От:  Ивайло Димитров 
 Относно: Re: OMAPFB: CMA allocation failures
 До: Tomi Valkeinen 
 Изпратено на: Сряда, 2013, Октомври 16 09:33:51 EEST
 
 
  Hi Tomi,
 
 I think we should somehow find out what the pages are that cannot be
 migrated, and where they come from.
 
 So there are amp;quot;anonymous pages without mappingamp;quot; with 
 page_count(page) !=
 1. I have to say I don't know what that means =). I need to find some
 time to study the mm.
 
 I put some more traces in the point of failure, the result:
 page_count(page) == 2, page-flags == 0x0008025D, which is:
 PG_locked, PG_referenced, PG_uptodate, PG_dirty, PG_active, PG_arch_1, 
 PG_unevictable
 Whatever those mean :). I have no idea how to identify where those pages come 
 from.
 
 Well, as I said, you're the first one to report any errors, after the
 change being in use for a year. Maybe people just haven't used recent
 enough kernels, and the issue is only now starting to emerge, but I
 wouldn't draw any conclusions yet.
 
 I am (almost) sure I am the first one to test video playback on OMAP3 with 
 DSP video
 acceleration, using recent kernel and Maemo5 on n900 :). So there is high 
 probability the
 issue was not reported earlier because noone have tested it thoroughly after 
 the change.
 
 If the CMA would have big generic issues, I think we would've seen
 issues earlier. So I'm guessing it's some driver or app in your setup
 that's causing the issues. Maybe the driver/app is broken, or maybe that
 specific behavior is not handled well by CMA. In both case I think we
 need to identify what that driver/app is.
 
 What I know is going on, is that there is heavy fs I/O at the same time - 
 there is
 a thumbnailer process running in background which tries to extract thumbnails 
 of all video
 files in the system. Also, there are other processes doing various jobs 
 (e-mail fetching, IM
 accounts login, whatnot). And in addition Xorg mlocks parts of its address 
 space. Of course
 all this happens with lots of memory being swapped in and out. I guess all 
 this is related.
 
 However, even after the system has settled, the CMA failures continue to 
 happen. It looks like
 some pages are allocated from CMA which should not be.
 
 I wonder how I could try to reproduce this with a generic omap3 board...
 
 I can always reproduce it here (well, not on generic board, but I guess it is 
 even better to
 test in real-life conditions), so if you need some specific tests or traces 
 or whatever, I
 can do them for you.
 
 Regards,
 Ivo
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 01/16] wl1251: fix scan behaviour while not associated

[Ивайло Димитров]

   Оригинално писмо 
 От:  Pali Rohár 
 Относно: Re: [PATCH v2 01/16] wl1251: fix scan behaviour while not associated
 До: Kalle Valo ,
 Pavel Machek 
 Изпратено на: Вторник, 2013, Декември 10 19:08:44 EET
 
 
 On Tuesday 10 December 2013 16:41:04 Kalle Valo wrote:
  Pavel Machek  writes:
   ssids can have #92;0s in them... and what is worse, they may
   not be 0 terminated AFAICT.
   
   Potential solution is at
   http://www.spinics.net/lists/linux-wireless/msg98640.html .
  
  I just use print_hex_dump_bytes() to print SSIDs.
 
 Ok and has kernel printf modifier for size_t?
 
 -- 
 Pali Rohár
 pali.ro...@gmail.com
 

If I read lib/vsprintf.c correctly, you can use 'z'

Regards,
Ivo

PS: Please use my gmail address when cc-ing me, LKML really hates my abv dot bg 
account :)

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900 - audio TPA6130A2 problems

[Ивайло Димитров]

Hi

On Fri Mar 18 12:33:14 2016 Peter Ujfalusi  wrote:
> 
> But enabling the pull via DT for the i2c2 works?
> 

No :(. I even migrated the driver to regmap - no gain. Maybe i2c bus is blocked 
by another device held in reset. The next thing I am going to try is to 
deassert reset/power gpios on all the devices on i2c-2 bus, to see if it will 
make any difference. Or if you have any other ideas, please share.

Ivo

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 *) 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 




 > Оригинално писмо 
 >От:  Tomi Valkeinen 
 >Относно: Re: OMAPFB: CMA allocation failures
 >До: Ивайло Димитров
 >Изпратено на: Сряда, 2013, Октомври 30 14:19:32 EET
 >
 >I really dislike the idea of adding the omap vram allocator back. Then
 >again, if the CMA doesn't work, something has to be done.
 >

If I got Minchan Kim's explanation correctly, CMA simply can't be used
for allocation of framebuffer memory, because it is unreliable.

 >Pre-allocating is possible, but that won't work if there's any need to
 >re-allocating the framebuffers. Except if the omapfb would retain and
 >manage the pre-allocated buffers, but that would just be more or less
 >the old vram allocator again.
 >
 >So, as I see it, the best option would be to have the standard dma_alloc
 >functions get the memory for omapfb from a private pool, which is not
 >used for anything else.
 >
 >I wonder if that's possible already? It sounds quite trivial to me.
 
dma_alloc functions use either CMA or (iirc) get_pages_exact if CMA is
disabled. Both of those fail easily. AFAIK there are several 
implementations with similar functionality, like CMEM and ION but
(correct me if I am wrong) neither of them is upstreamed. In the 
current kernel I don't see anything that can be used for the purpose 
of reliable allocation of big chunks of contiguous memory.
So, something should be done, but honestly, I can't think of anything
but bringing VRAM allocator back. Not that I like the idea of bringing
back ~700 lines of code, but I see no other option if omapfb driver is
to be actually useful.

Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi Tomi,

 >I think we should somehow find out what the pages are that cannot be
 >migrated, and where they come from.
 >
 >So there are anonymous pages without mapping with 
 >page_count(page) !=
 >1. I have to say I don't know what that means =). I need to find some
 >time to study the mm.

I put some more traces in the point of failure, the result:

page_count(page) == 2, page->flags == 0x0008025D, which is:

PG_locked, PG_referenced, PG_uptodate, PG_dirty, PG_active, PG_arch_1, 
PG_unevictable

Whatever those mean :). I have no idea how to identify where those pages come 
from.

 >Well, as I said, you're the first one to report any errors, after the
 >change being in use for a year. Maybe people just haven't used recent
 >enough kernels, and the issue is only now starting to emerge, but I
 >wouldn't draw any conclusions yet.

I am (almost) sure I am the first one to test video playback on OMAP3 with DSP 
video
acceleration, using recent kernel and Maemo5 on n900 :). So there is high 
probability the issue was not reported earlier because noone have tested it 
thoroughly after the change.

 >If the CMA would have big generic issues, I think we would've seen
 >issues earlier. So I'm guessing it's some driver or app in your setup
 >that's causing the issues. Maybe the driver/app is broken, or maybe that
 >specific behavior is not handled well by CMA. In both case I think we
 >need to identify what that driver/app is.

What I know is going on, is that there is heavy fs I/O at the same time - there 
is
a thumbnailer process running in background which tries to extract thumbnails 
of all video
files in the system. Also, there are other processes doing various jobs (e-mail 
fetching, IM
accounts login, whatnot). And in addition Xorg mlocks parts of its address 
space. Of course all
this happens with lots of memory being swapped in and out. I guess all this is 
related.

However, even after the system has settled, the CMA failures continue to 
happen. It looks like
some pages are allocated from CMA which should not be.

 >I wonder how I could try to reproduce this with a generic omap3 board...

I can always reproduce it here (well, not on generic board, but I guess it is 
even better to test in real-life conditions), so if you need some specific 
tests or traces or whatever, I
can do them for you.

Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Staging: tidspbridge: make mmap root-only so it is not a security problem

[Ивайло Димитров]

I can (and will) test whatever patches is needed. Also will try to get rid of 
uuid helpers and send a patch today.

On Sun Dec   1 11:41:39 2013 Pali Rohár  wrote:
> On Saturday 30 November 2013 23:58:23 Pavel Machek wrote:
> > On Sat 2013-11-30 14:05:53, Greg KH wrote:
> > > On Sat, Nov 30, 2013 at 09:42:37PM +0100, Pavel Machek wrote:
> > > > mmap in tidspbridge is missing range-checks. For now, make
> > > > this interface root-only, so that it does not cause
> > > > security problems.
> > > 
> > > Please fix this properly and don't paper over the real
> > > problem here.
> > 
> > Well, if the driver is left uncompilable, I'm pretty sure it
> > will bitrot.
> > 
> 
> If you want to compile tidspbridge driver, you need this patch:
> https://gitorious.org/linux-n900/linux-n900/commit/b9adde42d5351467fa9d281190213bb652499577
> 
> Removing BROKEN is not enough.
> 
> > I do have the hardware, but I'm pretty sure current mailine
> > does not have enough support to boot Maemo, so it is non
> > trivial for me to test changes here.
> > 
> 
> Use linux-n900 tree, there are patches also for tidspbridge
> driver, so old maemo and new harmattan userspace can use it. But
> HD videos not working yet (due to another problem, search for
> OMAPFB: CMA allocation failures).
> 
> -- 
> Pali Rohár
> pali.ro...@gmail.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 
Hi,


 > Оригинално писмо 
 >От:  Minchan Kim 
 >Относно: Re: OMAPFB: CMA allocation failures
 >До: Ивайло Димитров 
 >Изпратено на: Понеделник, 2013, Октомври 28 09:37:48 EET
 >
 >
 >Hello,
 >
 >On Tue, Oct 15, 2013 at 09:49:51AM +0300, Ивайло Димитров wrote:
 >>  Hi
 >> 
 >>  > Оригинално писмо 
 >>  >От:  Tomi Valkeinen 
 >>  >Относно: Re: OMAPFB: CMA allocation failures
 >>  >До: Ивайло Димитров
 >> 
 >>  >Изпратено на: Понеделник, 2013, Октомври 14 09:04:35 EEST
 >>  >
 >>  >
 >>  >Hi,
 >>  >
 >>  >On 12/10/13 17:43, Ивайло Димитров wrote:
 >>  >>  Hi Tomi,
 >>  >> 
 >>  >> patch 
 >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html
 >>  modifies
 >>  >> omapfb driver to use DMA API to allocate framebuffer memory instead of 
 >> preallocating VRAM.
 >>  >> 
 >>  >> With this patch I see a lot of:
 >>  >> 
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
 >> dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
 >> dma_alloc_from_contiguous(): returned   (null)
 >>  >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed 
 >> to allocate framebuffer
 >>  >> 
 >>  >> errors while trying to play a video on N900 with Maemo 5 (Fremantle) on 
 >> top of linux-3.12rc1.
 >>  >> It is deffinitely the CMA that fails to allocate the memory most of the 
 >> times, but I wonder
 >>  >> how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, 
 >> but that made no
 >>  >> difference. If CMA is disabled, the memory allocation still fails as 
 >> obviously it is highly
 >>  >> unlikely there will be such a big chunk of continuous free memory on 
 >> RAM limited device like
 >>  >> N900. 
 >>  >> 
 >>  >> One obvious solution is to just revert the removal of VRAM memory 
 >> allocator, but that would
 >>  >> mean I'll have to maintain a separate tree with all the implications 
 >> that brings.
 >>  >> 
 >>  >> What would you advise on how to deal with the issue?
 >>  >
 >>  >I've not seen such errors, and I'm no expert on CMA. But I guess the
 >>  >contiguous memory area can get fragmented enough no matter how hard one
 >>  >tries to avoid it. The old VRAM system had the same issue, although it
 >>  >was quite difficult to hit it.
 >> 
 >> I am using my n900 as a daily/only device since the beginning of 2010, 
 >> never seen such an 
 >> issue with video playback. And as a maintainer of one of the community 
 >> supported kernels for
 >> n900 (kernel-power) I've never had such an issue reported. On stock kernel 
 >> and derivatives of
 >> course. It seems VRAM allocator is virtually impossible to fail, while with 
 >> CMA OMAPFB fails on
 >> the first video after boot-up.
 >> 
 >> When saying you've not seen such an issue - did you actually test video 
 >> playback, on what
 >> device and using which distro? Did you use DSP accelerated decoding?
 >> 
 >>  >64MB does sound quite a lot, though. I wonder what other drivers are
 >>  >using CMA, and how do they manage to allocate so much memory and
 >>  >fragment it so badly... With double buffering, N900 should only need
 >>  >something like 3MB for the frame buffer.
 >> 
 >> Sure, 64 MB is a lot, but I just wanted to see if that would make any 
 >> difference. And for 720p 
 >> 3MB is not en

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-(CONFIG_MACH_NOKIA_RX51)   += 
 >> board-rx51.o sdram-nokia.o
 >>  obj-(CONFIG_MACH_NOKIA_RX51)  += board-rx51-peripherals.o
 >>  obj-(CONFIG_MACH_NOKIA_RX51)  += board-rx51-video.o
 >>  obj-(CONFIG_MACH_NOKIA_RX51)  += board-rx51-camera.o
 >> +obj-(CONFIG_MACH_NOKIA_RX51)  += board-rx51-smc.o 
 >> board-rx51-secure.o
 >>  obj-(CONFIG_MACH_OMAP_ZOOM2)  += board-zoom.o 
 >> board-zoom-peripherals.o
 >>  obj-(CONFIG_MACH_OMAP_ZOOM2)  += board-zoom-display.o
 >>  obj-(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 board-rx51-secure.h
 >> +
 >> +/**
 >> + * 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 

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi Tomi,

patch 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html 
modifies
omapfb driver to use DMA API to allocate framebuffer memory instead of 
preallocating VRAM.

With this patch I see a lot of:

Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
dma_alloc_from_contiguous(): returned   (null)
Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed to 
allocate framebuffer

errors while trying to play a video on N900 with Maemo 5 (Fremantle) on top of 
linux-3.12rc1.
It is deffinitely the CMA that fails to allocate the memory most of the times, 
but I wonder
how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, but 
that made no
difference. If CMA is disabled, the memory allocation still fails as obviously 
it is highly
unlikely there will be such a big chunk of continuous free memory on RAM 
limited device like
N900. 

One obvious solution is to just revert the removal of VRAM memory allocator, 
but that would
mean I'll have to maintain a separate tree with all the implications that 
brings.

What would you advise on how to deal with the issue?

Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi

 > Оригинално писмо 
 >От:  Tomi Valkeinen 
 >Относно: Re: OMAPFB: CMA allocation failures
 >До: Ивайло Димитров

 >Изпратено на: Понеделник, 2013, Октомври 14 09:04:35 EEST
 >
 >
 >Hi,
 >
 >On 12/10/13 17:43, Ивайло Димитров wrote:
 >>  Hi Tomi,
 >> 
 >> patch 
 >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html
 >>  modifies
 >> omapfb driver to use DMA API to allocate framebuffer memory instead of 
 >> preallocating VRAM.
 >> 
 >> With this patch I see a lot of:
 >> 
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: 
 >> dma_alloc_from_contiguous(cma c05f5844, count 192, align 8)
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: 
 >> dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: 
 >> dma_alloc_from_contiguous(): returned   (null)
 >> Jan  1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed to 
 >> allocate framebuffer
 >> 
 >> errors while trying to play a video on N900 with Maemo 5 (Fremantle) on top 
 >> of linux-3.12rc1.
 >> It is deffinitely the CMA that fails to allocate the memory most of the 
 >> times, but I wonder
 >> how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, but 
 >> that made no
 >> difference. If CMA is disabled, the memory allocation still fails as 
 >> obviously it is highly
 >> unlikely there will be such a big chunk of continuous free memory on RAM 
 >> limited device like
 >> N900. 
 >> 
 >> One obvious solution is to just revert the removal of VRAM memory 
 >> allocator, but that would
 >> mean I'll have to maintain a separate tree with all the implications that 
 >> brings.
 >> 
 >> What would you advise on how to deal with the issue?
 >
 >I've not seen such errors, and I'm no expert on CMA. But I guess the
 >contiguous memory area can get fragmented enough no matter how hard one
 >tries to avoid it. The old VRAM system had the same issue, although it
 >was quite difficult to hit it.

I am using my n900 as a daily/only device since the beginning of 2010, never 
seen such an 
issue with video playback. And as a maintainer of one of the community 
supported kernels for
n900 (kernel-power) I've never had such an issue reported. On stock kernel and 
derivatives of
course. It seems VRAM allocator is virtually impossible to fail, while with CMA 
OMAPFB fails on
the first video after boot-up.

When saying you've not seen such an issue - did you actually test video 
playback, on what
device and using which distro? Did you use DSP accelerated decoding?

 >64MB does sound quite a lot, though. I wonder what other drivers are
 >using CMA, and how do they manage to allocate so much memory and
 >fragment it so badly... With double buffering, N900 should only need
 >something like 3MB for the frame buffer.

Sure, 64 MB is a lot, but I just wanted to see if that would make any 
difference. And for 720p 
3MB is not enough, something like 8MB is needed.

 >With a quick glance I didn't find any debugfs or such files to show
 >information about the CMA area. It'd be helpful to find out what's going
 >on there. Or maybe normal allocations are fragmenting the CMA area, but
 >for some reason they cannot be moved? Just guessing.

I was able to track down the failures to:
http://lxr.free-electrons.com/source/mm/migrate.c#L320

So it seems the problem is not that CMA gets fragmented, rather some pages 
cannot be migrated.
Unfortunately, my knowledge stops here. Someone from the mm guys should be 
involved in the
issue as well? I am starting to think there is some serious issue with CMA 
and/or mm I am
hitting on n900. As it is not the lack of free RAM that is the problem - 
"echo 3>/proc/sys/vm/drop_caches" results in more that 45MB of free RAM 
according to free.

 >There's also dma_declare_contiguous() that could be used to reserve
 >memory for omapfb. I have not used it

Re: OMAPFB: CMA allocation failures

[Ивайло Димитров]

 Hi,

I wonder if there is any progress on the issue? Do you need me to send more 
data? Or
should I raise the issue with the CMA maintainer?

Regards,
Ivo

 > Оригинално писмо 
 >От:  Ивайло Димитров 
 >Относно: Re: OMAPFB: CMA allocation failures
 >До: Tomi Valkeinen 
 >Изпратено на: Сряда, 2013, Октомври 16 09:33:51 EEST
 >
 >
 > Hi Tomi,
 >
 >>I think we should somehow find out what the pages are that cannot be
 >>migrated, and where they come from.
 >>
 >>So there are quot;anonymous pages without mappingquot; with 
 >>page_count(page) !=
 >>1. I have to say I don't know what that means =). I need to find some
 >>time to study the mm.
 >
 >I put some more traces in the point of failure, the result:
 >page_count(page) == 2, page->flags == 0x0008025D, which is:
 >PG_locked, PG_referenced, PG_uptodate, PG_dirty, PG_active, PG_arch_1, 
 >PG_unevictable
 >Whatever those mean :). I have no idea how to identify where those pages come 
 >from.
 >
 >>Well, as I said, you're the first one to report any errors, after the
 >>change being in use for a year. Maybe people just haven't used recent
 >>enough kernels, and the issue is only now starting to emerge, but I
 >>wouldn't draw any conclusions yet.
 >
 >I am (almost) sure I am the first one to test video playback on OMAP3 with 
 >DSP video
 >acceleration, using recent kernel and Maemo5 on n900 :). So there is high 
 >probability the
 >issue was not reported earlier because noone have tested it thoroughly after 
 >the change.
 >
 >>If the CMA would have big generic issues, I think we would've seen
 >>issues earlier. So I'm guessing it's some driver or app in your setup
 >>that's causing the issues. Maybe the driver/app is broken, or maybe that
 >>specific behavior is not handled well by CMA. In both case I think we
 >>need to identify what that driver/app is.
 >
 >What I know is going on, is that there is heavy fs I/O at the same time - 
 >there is
 >a thumbnailer process running in background which tries to extract thumbnails 
 >of all video
 >files in the system. Also, there are other processes doing various jobs 
 >(e-mail fetching, IM
 >accounts login, whatnot). And in addition Xorg mlocks parts of its address 
 >space. Of course
 >all this happens with lots of memory being swapped in and out. I guess all 
 >this is related.
 >
 >However, even after the system has settled, the CMA failures continue to 
 >happen. It looks like
 >some pages are allocated from CMA which should not be.
 >
 >>I wonder how I could try to reproduce this with a generic omap3 board...
 >
 >I can always reproduce it here (well, not on generic board, but I guess it is 
 >even better to
 >test in real-life conditions), so if you need some specific tests or traces 
 >or whatever, I
 >can do them for you.
 >
 >Regards,
 >Ivo
 >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 Enabling ARM errata 430973 
 >> workaround.n);
 >> +   /* 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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 *) 
+   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   = omap3-rom-rng,
 >> > + .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(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 %s: initializingn,
 >> > omap3_rom_rng_name); +
 >> > + omap3_rom_rng_call = pdev->dev.platform_data;
 >> > + if (!omap3_rom_rng_call) {
 >> > + printk(KERN_ERR %s: omap3_rom_rng_call is 
 >> > NULLn,
 >> > +omap3_rom_rng_name);
 >> > + return -EINVAL;
 >> > + }
 >> > +
 >> > + setup_timer(idle_timer, omap3_rom_idle_rng, 0);
 >> > + rng_clk = clk_get_sys(omap_rng, ick);
 >> > + if (IS_ERR(rng_clk)) {
 >> > + printk(KERN_ERR %s: unable to get RNG clockn,
 >> > +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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 01/16] wl1251: fix scan behaviour while not associated

[Ивайло Димитров]

  > Оригинално писмо 
 >От:  Pali Rohár 
 >Относно: Re: [PATCH v2 01/16] wl1251: fix scan behaviour while not associated
 >До: Kalle Valo ,
 Pavel Machek 
 >Изпратено на: Вторник, 2013, Декември 10 19:08:44 EET
 >
 >
 >On Tuesday 10 December 2013 16:41:04 Kalle Valo wrote:
 >> Pavel Machek  writes:
 >> > ssids can have 0s in them... and what is worse, they may
 >> > not be 0 terminated AFAICT.
 >> > 
 >> > Potential solution is at
 >> > http://www.spinics.net/lists/linux-wireless/msg98640.html .
 >> 
 >> I just use print_hex_dump_bytes() to print SSIDs.
 >
 >Ok and has kernel printf modifier for size_t?
 >
 >-- 
 >Pali Rohár
 >pali.ro...@gmail.com
 >

If I read lib/vsprintf.c correctly, you can use 'z'

Regards,
Ivo

PS: Please use my gmail address when cc-ing me, LKML really hates my abv dot bg 
account :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nokia N900 - audio TPA6130A2 problems

[Ивайло Димитров]

Hi

On Fri Mar 18 12:33:14 2016 Peter Ujfalusi  wrote:
> 
> But enabling the pull via DT for the i2c2 works?
> 

No :(. I even migrated the driver to regmap - no gain. Maybe i2c bus is blocked 
by another device held in reset. The next thing I am going to try is to 
deassert reset/power gpios on all the devices on i2c-2 bus, to see if it will 
make any difference. Or if you have any other ideas, please share.

Ivo

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/