from:"Ivaylo Dimitrov"

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

2016-01-06 Thread Ivaylo Dimitrov




On  6.01.2016 00:49, Tony Lindgren wrote:


Suggested fix below, please test and reply with your Tested-by's if
it solves the problem so we may still be able to get this into v4.4.

Regards,

Tony

8< ---
From: Tony Lindgren <t...@atomide.com>
Date: Tue, 5 Jan 2016 12:04:20 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
  corruption

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device
tree provided timings. It works enough to get detected but the clock
rate supported by the onenand chip gets misdetected. This in turn causes
the GPMC timings to be miscalculated and this leads into file system
corruption on n900.

Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
write. This is needed also for async timings when we write to onenand
with omap2_onenand_set_async_mode(). Without sync write bit set, the
async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.

Let's exit with an error if onenand rate is not detected. And let's
remove the extra call to omap2_onenand_set_async_mode() as we only
need to do this once at the end of omap2_onenand_setup_async().

Reported-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>

--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c


Bellow is gpmc dmesg output with that fix. I also disabled 
CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no 
obvious problems.


So, seems that fixes the problem, feel free to  add:

Tested-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>


Jan  6 10:34:15 Nokia-N900 kernel: [1.373229] omap-gpmc 
6e00.gpmc: GPMC revision 5.0
Jan  6 10:34:15 Nokia-N900 kernel: [1.379425] GPMC CS0: cs_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.387481] GPMC CS0: cs_rd_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.395507] GPMC CS0: cs_wr_off 
 :  19 ticks, 114 ns (was  16 ticks) 114 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.403472] GPMC CS0: adv_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.411407] GPMC CS0: adv_rd_off 
 :   3 ticks,  18 ns (was   2 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.419342] GPMC CS0: adv_wr_off 
 :   3 ticks,  18 ns (was   2 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.427276] GPMC CS0: oe_on 
 :   5 ticks,  30 ns (was   2 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.435211] GPMC CS0: oe_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.443115] GPMC CS0: we_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.451110] GPMC CS0: we_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.459045] GPMC CS0: rd_cycle 
 :  18 ticks, 108 ns (was  19 ticks) 108 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.467041] GPMC CS0: wr_cycle 
 :  17 ticks, 102 ns (was  19 ticks) 102 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.474975] GPMC CS0: access 
 :  13 ticks,  78 ns (was  15 ticks)  78 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.482879] GPMC CS0: 
page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.490814] GPMC CS0: 
bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.498748] GPMC CS0: 
cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.506683] GPMC CS0: 
wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.514617] GPMC CS0: wr_access 
 :  13 ticks,  78 ns (was  15 ticks)  78 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.522583] GPMC CS0: 
wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.530548] GPMC CS0: 
clk_activation   :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.538543] GPMC CS0 CLK period is 
6 ns (div 1)
Jan  6 10:34:15 Nokia-N900 kernel: [1.543334] gpmc cs0 after 
gpmc_cs_set_timings:
Jan  6 10:34:15 Nokia-N900 kernel: [1.548126] cs0 GPMC_CS_CONFIG1: 
0xd9001200
Jan  6 10:34:15 Nokia-N900 kernel: [1.552581] cs0 GPMC_CS_CONFIG2: 
0x00130e00
Jan  6 10:34:15 Nokia-N900 kernel: [1.558837] cs0 GPMC_CS_CONFIG3: 
0x00030300
Jan  6 10:34:15 Nokia-N900 kernel: [1.563323] cs0 GPMC_CS_CONFIG4: 
0x0e000e05
Jan  6 10:34:15 Nokia-N900 kernel: [1.567901] cs0 GPMC_CS_CONFIG5: 
0x000d1112
Jan  6 10:34:15

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

2016-01-06 Thread Ivaylo Dimitrov




On  6.01.2016 19:47, Tony Lindgren wrote:

* Sebastian Reichel  [160106 09:41]:

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device


You may want to change 900 to n900 (maybe even Nokia N900) before
actually committing this.


Thanks will do.

Tony




Unfortunately, it seems there is more to be fixed. It booted several 
times to the userspace, but after a couple of shutdowns, rootfs became 
corrupted again. I flashed, installed linux 4.4, but the same happened 
after the first shutdown with 4.4:


<5>[8.159179] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
<3>[8.184631] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node 
type (255 but expected 9)
<3>[8.197937] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node 
at LEB 1934:6936, LEB mapping status 0

<3:[8.216522] Not a node, first 24 bytes:
<3>[8.220520] : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff  

<4>[8.247772] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0-rc7+ #4
<4>[8.258911] Hardware name: Nokia RX-51 board
<4>[8.268096] [] (unwind_backtrace) from Y] 
(show_stack+0x10/0x14)
<4>[8.281097] [] (show_stack) from [] 
(ubifs_read_node+0x29c/0x2d4)
<4>[8.294097] [] (ubifs_read_node) from [] 
(dbg_old_index_check_init+0x60/0x9c)
<4>[8.308258] [] (dbg_old_index_check_init) from 
[] (ubifs_mount+0xd90/0x15f0)
<4>[8.322357] [] (ubifs_mount) from [] 
(mount_fs+0x70/0x148)
<4>[8.334747] [] (mount_fs) from [] 
(vfs_kern_mount+0x4c/0x110)
<4>[8.347412] [] (vfs_kern_mount) from [] 
(do_mount+0xadc/0xc34)
<4>[8.360168] [] (do_mount) from [] 
(SyS_mount+0x70/0x9c)
<4>[8.372253] [] (SyS_mount) from [] 
(mount_block_root+0xf0/0x28c)
<4>[8.385162] [] (mount_block_root) from [] 
(prepare_namespace+0x88/0x1bc)
<4>[8.398834] [] (prepare_namespace) from [] 
(kernel_init_freeable+0x178/0x1c4)
<4>[8.412963] [] (kernel_init_freeabme) from [] 
(kernel_init+0x8/0xe4)
<4>[8.426300] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x3c)


P.S.
(Pali, sorry for not having time to read the kernel docs re e-mail 
clients :) )

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

2016-01-06 Thread Ivaylo Dimitrov


Hi,

On  6.01.2016 20:26, Tony Lindgren wrote:



Hmm. Care to verify that your onenand really gets detected at 83 MHz like
your earlier logs show? Below is a patch that should show it.


before the corruption appeared, I looked a couple of times in syslog and 
the freq there was 83MHz. Including after I disabled CONFIG_OMAP_GPMC_DEBUG.




Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG
enabled? Or does that also produce corruption after few reboots?


CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it?


--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}

+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
  }



Where am I supposed to get the output from ^^^ if rootfs become 
corrupted? The problem appears after poweroff/restart when it is already 
too late to get the syslog.


BTW, did you compare all the GPMC registers with and without 
HWMOD_INIT_NO_RESET?


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

2016-01-04 Thread Ivaylo Dimitrov


Hi,

On  4.01.2016 19:40, Tony Lindgren wrote:

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

> >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >dmesg output?


Here it is, including the pre-gpmc log, keep in mind this is with 
restored HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get 
dmesg output from the syslog. Don't know if it is helpful :). Also, this 
device has Numonyx onenand (HW rev. 2204), unlike most of the others 
which have Samsung onenand (HW rev. 2101 etc), no idea if it is relevant.


Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Booting Linux on 
physical CPU 0x0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Initializing cgroup 
subsys cpu
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Linux version 
4.4.0-rc7+ (ivo@ivo-H81M-S2PV) (gcc version 4.7.2 20120701 (prerelease) 
(Linaro GCC 4.7-2012.07) ) #4 PREEMPT Mon Jan 4 20:30:31 EET 2016
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: ARMv7 Processor 
[411fc083] revision 3 (ARMv7), cr=10c5387d
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: PIPT / VIPT 
nonaliasing data cache, VIPT nonaliasing instruction cache

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Machine model: Nokia N900
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory policy: Data 
cache writeback
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] On node 0 totalpages: 
65280
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] free_area_init_node: 
node 0, pgdat c06776f8, node_mem_map cfcf9000
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 512 
pages used for memmap
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 0 pages 
reserved
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 65280 
pages, LIFO batch:15
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: All CPU(s) 
started in SVC mode.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] OMAP3430/3530 ES3.1 
(l2cache iva sgx neon isp )
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: s0 r0 
d32768 u32768 alloc=1*32768

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: [0] 0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Built 1 zonelists in 
Zone order, mobility grouping on.  Total pages: 64768
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Kernel command line: 
init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs 
rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log console=tty0 
console=ttyO2 omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] PID hash table 
entries: 1024 (order: 0, 4096 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Dentry cache hash 
table entries: 32768 (order: 5, 131072 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Inode-cache hash table 
entries: 16384 (order: 4, 65536 bytes)
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: com.nokia.phone.SIM: 
csd-libsimpb::configure: args=<(null)>
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: Succesfully loaded 
plugin 
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory: 
251588K/261120K available (4487K kernel code, 232K rwdata, 1624K rodata, 
244K init, 256K bss, 9532K reserved, 0K cma-reserved, 0K highmem)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Virtual kernel memory 
layout:
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vector  : 
0x - 0x1000   (   4 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] fixmap  : 
0xffc0 - 0xfff0   (3072 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vmalloc : 
0xd080 - 0xff80   ( 752 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] lowmem  : 
0xc000 - 0xd000   ( 256 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pkmap   : 
0xbfe0 - 0xc000   (   2 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] modules : 
0xbf00 - 0xbfe0   (  14 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .text : 
0xc0008000 - 0xc0600044   (6113 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .init : 
0xc0601000 - 0xc063e000   ( 244 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .data : 
0xc063e000 - 0xc0678240   ( 233 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00].bss : 
0xc0678240 - 0xc06b8628   ( 257 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] SLUB: HWalign=64, 
Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Preemptible 
hierarchical RCU implementation.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] ^IBuild-time 
adjustment of leaf fanout to 32.

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] NR_IRQS:16 nr_irqs:16 16
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] IRQ: Found an INTC at 
0xfa20 (revision 4.0) with 96 interrupts
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Clocking rate 
(Crystal/Core/MPU): 19.2/332/500 MHz
Jan  4 20:42:50 Nokia-N900

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

2016-01-04 Thread Ivaylo Dimitrov


Hi Tomi,

On  4.01.2016 13:37, Tomi Valkeinen wrote:


We probably need exactly the same for omapdrm, as omapfb is on the way
to being deprecated. And sounds to me that we probably need similar for
other devices which try to do large allocations (camera? video decoders?).



Re omapdrm - I guess it wouldn't be hard for omapdrm to use the same 
preallocated memory, when/if it is needed. Though I know nothing about 
omapdrm, so can't really tell.


If not mistaken, camera driver uses sg lists. DSP needs such a memory, 
but anyway it(driver) was removed from mainline, with no signs/hope to 
be returned anytime soon.



So I really think this should be somehow be a general option for any device.



Then maybe add the relevant people in CC, so we to start some kind of 
discussion. But until such a general option exists, I think it makes 
sense to apply the $subject patch, we can easily fix it to use whatever 
general purpose API might the discussion come up with. As it is now, 
omapfb simply cannot be used to play any video with sane resolution 
(without preallocated memory that is), unless this is the only thing the 
device does. And even then it is not assured.



I also wonder if CMA can be improved to not need anything like this? If
you just increase the CMA area, won't that increase the chances CMA will
work?



The short answer is no, at least not with the CMA code currently 
upstream. A kind of a long answer could be found on 
http://marc.info/?l=linux-mm=141571797202006=2


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

2016-01-01 Thread Ivaylo Dimitrov


Hi Tony,

On 21.05.2015 00:21, Tony Lindgren wrote:

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson 
Cc: Paul Walmsley 
Cc: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
  drivers/memory/Kconfig  |  8 
  drivers/memory/omap-gpmc.c  |  6 +++---
  9 files changed, 29 insertions(+), 35 deletions(-)



1. Happy new year :)

2. It was a while I tested upstream on N900 but I had some spare time 
during the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To 
my surprise, after that try, Maemo 5 rootfs, which is located on onenand 
became irreversibly corrupted. I bisected the tree to the $subject 
commit and after restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod 
flags, the problem was solved. It seems that GPMC is either incorrectly 
or incompletely setup by the kernel, leading to failed onenand 
reads/writes and whatnot. Unfortunately, what I have here is a release 
device, so I am unable to capture any logs through the serial port. BTW 
keep in mind that rootfs corruption happens as soon as a boot is 
attempted, even after a freshly flashed rootfs.


Please advice on how to proceed.

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

Re: [PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage

2016-01-01 Thread Ivaylo Dimitrov


Hi,

On 24.12.2015 20:56, Tony Lindgren wrote:


Maybe update the description to say "This fixes a regression with
device tree based booting compared to legacy booting for n900 to
make the n900 legacy user space to also work with device tree based
booting".



OK, will do.


It would be nice to get these two in as fixes after -rc1 assuming
people have no objections to it. So please upload this one also
into Russell's patch system after no more comments:



Seems there are no more comments (and objections) so I will *try* to 
upload the patches in Russell's patch system. Will pester you to do it 
for me if I fail to do so :)



Acked-by: Tony Lindgren 



Thanks,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2016-01-01 Thread Ivaylo Dimitrov




On 29.12.2015 09:46, Tomi Valkeinen wrote:


Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.

  Tomi



Actually it is me to be sorry for making noise, I've missed 
0eb0dafb674cd6bfac2e3204b2f8b907e26b1138 with all those patches moving 
files around.


Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

2015-12-25 Thread Ivaylo Dimitrov


On 26.12.2013 01:12, Ivaylo Dimitrov wrote:

From: Ivaylo Dimitrov <freemangor...@abv.bg>

On memory limited devices, CMA fails easily when asked to allocate big
chunks of memory like framebuffer memory needed for video playback.

Add boot parameter "omapfb_memsize" which allocates memory to be used
as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when
trying to allocate memory for the framebuffers

Signed-off-by: Ivaylo Dimitrov <freemangor...@abv.bg>
---
  arch/arm/mach-omap2/common.c |1 +
  arch/arm/mach-omap2/common.h |2 +
  arch/arm/mach-omap2/fb.c |   46 +-
  3 files changed, 48 insertions(+), 1 deletions(-)



ping
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2015-12-25 Thread Ivaylo Dimitrov



Hi Tomi,

On 13.01.2014 12:20, Tomi Valkeinen wrote:

On 2014-01-11 11:39, Ivaylo Dimitrov wrote:


The patch does not apply cleanly on top of rc7, however I applied it by
hand. So far it seems it fixes the issue brought by
c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
mutex_lock/mutex_unlock are complementary in every code path (at least
not explicitly, I guess maemo is doing it for us anyway :) ).


Ok, thanks.


So, shall I send a patch incorporating your code changes, or you will do
it?


I can handle it.

  Tomi




I still don't see those fixes in mainline, shall I send a patch?

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: ATAGS: move save_atags() to include/asm arch/arm/include/asm/setup.h

2015-12-24 Thread Ivaylo Dimitrov




On 24.12.2015 20:53, Tony Lindgren wrote:

* Pali Rohár <pali.ro...@gmail.com> [151224 09:48]:

On Thursday 24 December 2015 17:37:55 Ivaylo Dimitrov wrote:

So it can be used by code outside arch/arm/kernel/. Fix save_atags()
declaration to match its definition while at it.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>


Tested-by: Pali Rohár <pali.ro...@gmail.com>


Nice, please upload both to Russell's patch system after no
more comments:

Acked-by: Tony Lindgren <t...@atomide.com>



Hi Tony,

Could you elaborate on that patch system? Where it is and do I need some 
special account/access?


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

[PATCH 0/2] OMAP: RX51: save atags data to be exported on /proc/atags

2015-12-24 Thread Ivaylo Dimitrov

Nokia N900 legacy userspace needs ATAGS passed by the bootloder to be
available in /proc/atags. With DT booted kernel this information is
no longer availabe. Fix that by saving ATAGS data early in the boot 
stage so it can be exported in /proc/atags later

Ivaylo Dimitrov (2):
  ARM: ATAGS: move save_atags() to include/asm
arch/arm/include/asm/setup.h
  OMAP: RX51: save ATAGS data in the early boot stage

 arch/arm/include/asm/setup.h|  6 ++
 arch/arm/kernel/atags.h |  6 --
 arch/arm/mach-omap2/board-generic.c | 12 +++-
 3 files changed, 17 insertions(+), 7 deletions(-)

-- 
1.9.1

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

[PATCH 1/2] ARM: ATAGS: move save_atags() to include/asm arch/arm/include/asm/setup.h

2015-12-24 Thread Ivaylo Dimitrov

So it can be used by code outside arch/arm/kernel/. Fix save_atags()
declaration to match its definition while at it.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
---
 arch/arm/include/asm/setup.h | 6 ++
 arch/arm/kernel/atags.h  | 6 --
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index e0adb9f..3613d7e 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -25,4 +25,10 @@ extern int arm_add_memory(u64 start, u64 size);
 extern void early_print(const char *str, ...);
 extern void dump_machine_table(void);
 
+#ifdef CONFIG_ATAGS_PROC
+extern void save_atags(const struct tag *tags);
+#else
+static inline void save_atags(const struct tag *tags) { }
+#endif
+
 #endif
diff --git a/arch/arm/kernel/atags.h b/arch/arm/kernel/atags.h
index ec4164d..edfa226 100644
--- a/arch/arm/kernel/atags.h
+++ b/arch/arm/kernel/atags.h
@@ -1,9 +1,3 @@
-#ifdef CONFIG_ATAGS_PROC
-extern void save_atags(struct tag *tags);
-#else
-static inline void save_atags(struct tag *tags) { }
-#endif
-
 void convert_to_tag_list(struct tag *tags);
 
 #ifdef CONFIG_ATAGS
-- 
1.9.1

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

[PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage

2015-12-24 Thread Ivaylo Dimitrov

Nokia N900 (RX51) legacy userspace needs various ATAGS passed by the
bootloader (boot reason, device serial, boot mode, various GPIO swithes,
etc). Save that data early enough in the boot process, so it can be
exported later in /proc/atags

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
---
 arch/arm/mach-omap2/board-generic.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 04a56cc..8098272 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "common.h"
@@ -76,8 +77,17 @@ static const char *const n900_boards_compat[] __initconst = {
NULL,
 };
 
+/* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
+ * save them while the data is still not overwritten
+ */
+static void __init rx51_reserve(void)
+{
+   save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
+   omap_reserve();
+}
+
 DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
-   .reserve= omap_reserve,
+   .reserve= rx51_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
-- 
1.9.1

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

[PATCH 1/3] ARM: ATAGS: move atags.h to include/asm so it can be included by files outside kernel/

2015-12-24 Thread Ivaylo Dimitrov

This is needed by a follow-up patch that saves atags on RX51 device

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
---
 arch/arm/include/asm/atags.h  | 20 
 arch/arm/kernel/atags.h   | 20 
 arch/arm/kernel/atags_parse.c |  3 +--
 arch/arm/kernel/setup.c   |  3 +--
 4 files changed, 22 insertions(+), 24 deletions(-)
 create mode 100644 arch/arm/include/asm/atags.h
 delete mode 100644 arch/arm/kernel/atags.h

diff --git a/arch/arm/include/asm/atags.h b/arch/arm/include/asm/atags.h
new file mode 100644
index 000..ec4164d
--- /dev/null
+++ b/arch/arm/include/asm/atags.h
@@ -0,0 +1,20 @@
+#ifdef CONFIG_ATAGS_PROC
+extern void save_atags(struct tag *tags);
+#else
+static inline void save_atags(struct tag *tags) { }
+#endif
+
+void convert_to_tag_list(struct tag *tags);
+
+#ifdef CONFIG_ATAGS
+const struct machine_desc *setup_machine_tags(phys_addr_t __atags_pointer,
+   unsigned int machine_nr);
+#else
+static inline const struct machine_desc *
+setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
+{
+   early_print("no ATAGS support: can't continue\n");
+   while (true);
+   unreachable();
+}
+#endif
diff --git a/arch/arm/kernel/atags.h b/arch/arm/kernel/atags.h
deleted file mode 100644
index ec4164d..000
--- a/arch/arm/kernel/atags.h
+++ /dev/null
@@ -1,20 +0,0 @@
-#ifdef CONFIG_ATAGS_PROC
-extern void save_atags(struct tag *tags);
-#else
-static inline void save_atags(struct tag *tags) { }
-#endif
-
-void convert_to_tag_list(struct tag *tags);
-
-#ifdef CONFIG_ATAGS
-const struct machine_desc *setup_machine_tags(phys_addr_t __atags_pointer,
-   unsigned int machine_nr);
-#else
-static inline const struct machine_desc *
-setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
-{
-   early_print("no ATAGS support: can't continue\n");
-   while (true);
-   unreachable();
-}
-#endif
diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 68c6ae0..faac2d1 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -28,8 +28,7 @@
 #include 
 #include 
 #include 
-
-#include "atags.h"
+#include 
 
 static char default_command_line[COMMAND_LINE_SIZE] __initdata = 
CONFIG_CMDLINE;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..aa0193a 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -60,8 +60,7 @@
 #include 
 #include 
 #include 
-
-#include "atags.h"
+#include 
 
 
 #if defined(CONFIG_FPE_NWFPE) || defined(CONFIG_FPE_FASTFPE)
-- 
1.9.1

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

[PATCH 0/3] OMAP: RX51: save atags data to be exported on /proc/atags

2015-12-24 Thread Ivaylo Dimitrov

Nokia N900 legacy userspace needs ATAGS passed by the bootloder to be
available in /proc/atags. With DT booted kernel this information is
no longer availabe. Fix that by saving ATAGS data early in the boot 
stage so it can be exported in /proc/atags later

Ivaylo Dimitrov (3):
  ARM: ATAGS: move atags.h to include/asm so it can be included by files
outside kernel/
  ARM: ATAGS: Fix declaration of function save_atags
  OMAP: RX51: save ATAGS data in the early boot stage

 arch/arm/include/asm/atags.h| 20 
 arch/arm/kernel/atags.h | 20 
 arch/arm/kernel/atags_parse.c   |  3 +--
 arch/arm/kernel/setup.c |  3 +--
 arch/arm/mach-omap2/board-generic.c | 12 +++-
 5 files changed, 33 insertions(+), 25 deletions(-)
 create mode 100644 arch/arm/include/asm/atags.h
 delete mode 100644 arch/arm/kernel/atags.h

-- 
1.9.1

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

[PATCH 3/3] OMAP: RX51: save ATAGS data in the early boot stage

2015-12-24 Thread Ivaylo Dimitrov

Nokia N900 (RX51) legacy userspace needs various ATAGS passed by the
bootloader (boot reason, device serial, boot mode, various GPIO swithes,
etc). Save that data early enough in the boot process, so it can be
exported later in /proc/atags

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
---
 arch/arm/mach-omap2/board-generic.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 04a56cc..594eefe 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 
 #include "common.h"
 
@@ -76,8 +77,17 @@ static const char *const n900_boards_compat[] __initconst = {
NULL,
 };
 
+/* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
+ * save them while the data is still there
+ */
+static void __init rx51_reserve(void)
+{
+   save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
+   omap_reserve();
+}
+
 DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
-   .reserve= omap_reserve,
+   .reserve= rx51_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
-- 
1.9.1

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

[PATCH 2/3] ARM: ATAGS: Fix declaration of function save_atags

2015-12-24 Thread Ivaylo Dimitrov

In file atags_proc.c function save_atags() expect const argument, but in
atags.h file is declarated as non const. Fix declaration in atags.h file to
match what is expected.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com>
---
 arch/arm/include/asm/atags.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/atags.h b/arch/arm/include/asm/atags.h
index ec4164d..2dfc30f 100644
--- a/arch/arm/include/asm/atags.h
+++ b/arch/arm/include/asm/atags.h
@@ -1,7 +1,7 @@
 #ifdef CONFIG_ATAGS_PROC
-extern void save_atags(struct tag *tags);
+extern void save_atags(const struct tag *tags);
 #else
-static inline void save_atags(struct tag *tags) { }
+static inline void save_atags(const struct tag *tags) { }
 #endif
 
 void convert_to_tag_list(struct tag *tags);
-- 
1.9.1

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

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

2015-12-23 Thread Ivaylo Dimitrov


Hi,

On 15.12.2015 14:20, Russell King - ARM Linux wrote:


You could also just save_atags() in there, with a comment saying that
this is a work-around for N900 which needs the ATAGs saved, and this
is allowed in ->reserve as a special exception.



What about this (just to confirm I got the idea correctly, proper patch 
will follow if that's the case):


diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c

index 34ff14b..8916856 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -83,8 +83,25 @@ static const char *const n900_boards_compat[] 
__initconst = {

NULL,
 };

+#ifdef CONFIG_ATAGS_PROC
+extern void save_atags(const struct tag *tags);
+
+/* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
+ * save them while the data is still not overwritten
+ */
+static void __init rx51_reserve(void)
+{
+   const phys_addr_t __atags_pointer = 0x100;
+
+   save_atags(phys_to_virt(__atags_pointer));
+   omap_reserve();
+}
+#else
+#define rx51_reserve omap_reserve
+#endif
+
 DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
-   .reserve= omap_reserve,
+   .reserve= rx51_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

2015-11-26 Thread Ivaylo Dimitrov




On 26.11.2015 22:39, Tony Lindgren wrote:


Just to explore options.. How about make a minimal device driver that
just loads the atags blob from /lib/firmware and then shows it in
/proc/atags? Of course some checking on the atags should be done by
the driver..



What is the chance for such a driver to be accepted upstream? As IIRC 
the current situation is because similar driver was rejected. Might be 
wrong as well, it was about 2-3 years ago.


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

Re: linux 4.2-rc1 broken Nokia N900

2015-07-24 Thread Ivaylo Dimitrov




On 24.07.2015 11:18, Dave Young wrote:


Pali, could you tell how do you test mainline kernel on n900?

I used to use n900 as a usb dbgp gadget with a backport patch to
2.6.28 so that I can get early debug kernel message from my laptop.

I tried mainline previously with Fedora arm, text mode works but
no graphics. Is there a way to use maemo UI with mainline kernel?

Thanks
Dave



http://talk.maemo.org/showpost.php?p=1459970postcount=142

This is the last (almost) upstream kernel I tried, unfortunately 
recently I am very short on spare time, so cannot confirm for 4.x 
kernels, but in theory those should work as well.


The kernel tree was on gitorious, but it is down now(I have a local 
copy). However, all of the needed patches should be on 
https://github.com/pali/linux-n900.


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM errata 430973 on multi platform kernels

2015-04-06 Thread Ivaylo Dimitrov




On  6.04.2015 18:40, Tony Lindgren wrote:

* Tony Lindgren t...@atomide.com [150406 08:24]:

* Matthijs van Duin matthijsvand...@gmail.com [150405 16:53]:

Cortex-A8 errata doc states in its workaround for erratum 430973:


By default, the BTB Invalidate instruction is treated as a NOP on Cortex-A8.
However, it is possible to enable the BTB Invalidate instruction such that it
actually does a full invalidate of the BTB by setting the IBE bit (bit 6) in
the CP15 Auxiliary Control Register. As a consequence of erratum 687067, the
L1 System Array Debug Register should be cleared to 0 before the IBE bit is
set using the following code sequence:
MOV r1, #0
MCR p15, 0, r1, c15, c1, 0; write instruction data 0 register
MRC p15, 0, R1, c1, c0, 1 ; read Aux Ctl Register
ORR R1, R1 #(1  6)  ; set IBE to 1
MCR p15, 0, R1, c1, c0, 1 ; write Aux Ctl Register
The above code needs to be executed in Secure state. ARM Limited recommends
that this code is added to the boot monitor.


The 430973 workaround code in proc-v7.S will do absolutely nothing if
executed in non-secure state. Ditto for the 458693 workaround, and the
460075 workaround should trigger an undefined instruction exception.
Maybe linux is started in secure mode on some targets and this code
was written for one of those?


That's only for HS omaps, for those we currently only do it in the
nokia_n900_legacy_init that calls rx51_secure_update_aux_cr.


I scanned DM814x secure ROM for any (ARM or Thumb) write to
Instruction L1 System Array Debug Register 0, but I found none, hence
my warning to watch out for erratum 687067.


OK


Adding the full set of BTB invalidates while making sure IBE is
disabled on sufficiently recent Cortex-A8 revisions would be optimal
for the Cortex-A8. But, apparently (based on the description of the
ARMv7 CPUID registers) there are also processors which only require
BTB invalidates when code is modified, but not when context-switching,
so there may be performance considerations there...


Attempting to summarize all that's been discussed.. It sounds like we
need the following implemented:

1. For cortex-a8 revisions affected by 458693, we can do a custom
cpu_v7_switch_mm function that always does flush BTAC/BTB.

2. For HS cortex-a8 processors other than n900 affected by 458693,
we need to implement functions similar to rx51_secure_update_aux_cr,
the bootrom on n900 is different from TI HS omaps so the SMC call
numbering may be different.

3. For later cortex-a8 processors not affected by 458693, we need
to clear IBE bit to avoid erratum 687067.


Oops sorry, wrong numbers for errata above.. s/458693/430973/, here's
a better version:

1. For cortex-a8 revisions affected by 430973, we can do a custom
cpu_v7_switch_mm function that always does flush BTAC/BTB.



Why custom function, if IBE bit is zero, BTB invalidate instruction is a 
NOP. Do you think that mcr p15, 0, r2, c7, c5, 6 executed as a NOP 
will put so much overhead, that it deserves a custom function?



2. For HS cortex-a8 processors other than n900 affected by 430973,
we need to implement functions similar to rx51_secure_update_aux_cr,
the bootrom on n900 is different from TI HS omaps so the SMC call
numbering may be different.

3. For later cortex-a8 processors not affected by 430973, we need
to clear IBE bit to avoid erratum 687067.



Maybe it should be implemented something like:

1. if Cortex-A8, always execute invalidate BTB instruction in
   cpu_v7_switch_mm

2. For Cortex-A8 revisions affected by 430973, set IBE bit to 1, set it
   to 0 for all others. That should happen as soon as possible,
   otherwise kernel may crash on affected revisions if thumb-
   compiled.


Regards,

Tony



Regards,

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM errata 430973 on multi platform kernels

2015-04-05 Thread Ivaylo Dimitrov




On  5.04.2015 19:50, Matthijs van Duin wrote:

On 5 April 2015 at 09:23, Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com wrote:

Though I wonder why SMC is needed to write ACR on non-HS devices. A simple
MRC should suffice, unless I miss something.


Public-world access to ACR varies per bit:
bit 1 (L2EN) is documented as banked, but at least on r3p2 turns out
to be common r/w.
bits 30-31 are secure read-only and public RAZ.
remaining bits are secure read/write and public read-only.

The net effect is that doing an MRC from public world will only modify
the L2EN bit.

There's no bit in the non-secure access control register to affect all
of this, so GP vs HS doesn't matter here (from a CPU point of view; it
may matter for the availability of SM calls obviously).

Matthijs



But then the first part(setting the IBE bit in ACR to 1) of the errata 
workaround is wrong, as it uses a plain MCR to set the IBE bit, see 
http://lxr.free-electrons.com/source/arch/arm/mm/proc-v7.S#L340. Which 
is weird, given that the workaround was posted by ARM iirc.


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM errata 430973 on multi platform kernels

2015-04-05 Thread Ivaylo Dimitrov




On  5.04.2015 07:13, Matthijs van Duin wrote:

I would actually suggest clearing IBE if it set on Cortex-A8 r2 or
later processors and a secure monitor call is available to do so
(there is on the DM814x and AM335x, dunno about the 37xx), also for
performance reasons: BTB invalidates are quite expensive instructions
(when enabled).


There is (or should be) SM call, it is explained in 36xx TRM(SWPU177AA) 
as well, 26.4.1, Booting Overview. Though I wonder why SMC is needed 
to write ACR on non-HS devices. A simple MRC should suffice, unless I 
miss something.


Clearing the IBE bit on devices that don't need erratum 430973 
workaround, along with enabling that workaround in kernel is the best 
approach IMO. That way we will gain both stability on cores that need 
the workaround (like on N900 and the other devices with p1) and won't 
lose performance on cores that are not affected.




Matthijs



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

Re: ARM errata 430973 on multi platform kernels

2015-04-03 Thread Ivaylo Dimitrov


Hi

On  3.04.2015 19:35, Sebastian Reichel wrote:


Maybe an option would be to provide two cpu_v7_switch_mm
implementations (one with the errata and one without). Then
the system can start with the simple implementation. Once
the boot as progressed far enough to know, that the hardware
is affected by the errata, it could switch to the implementation
with the flushing.


Or rather the opposite, as if the kernel itself is thumb-compiled, it 
most probably will have no chance to progress enough to switch to the 
correct implementation before hanging.


-- Sebastian



Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ARM errata 430973 on multi platform kernels

2015-04-03 Thread Ivaylo Dimitrov



Hi,


We should first verify the same bug happens with armel also.
I just verified the CPU load in the background makes armhf
apps segfault without $subject workaround enabled.

If the segfaulting does not happen with armel, then chances
it's some kind of neon related issue and the fix can be more
targeted.

Regards,

Tony



I can assure you that at least SoC in N900 is affected by ARM errata 
430973, no matter armel or armhf. Though the crash is usually with 
SIGILL(because of the wrong T bit in CPSR the code is executed with), I 
don't remember seeing SIGSEGV, but that could be my ageing memory. I am 
the maintainer of the so-called cssu-thumb Fremantle upgrade [1], which 
is armel, thumb2 compiled, so I have some experience with the matter  :) 
. Without that errata workaround enabled in kernel, it is impossible to 
boot Fremantle with cssu-thumb on top. BTW it was the same back in the 
days when there was Ubuntu 12.04 for N900 - it was hardfp, thumb2 
compiled. Again, without that errata workaround enabled, there was no 
way to boot it.


Regards,
Ivo

[1] http://talk.maemo.org/showthread.php?t=84829
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: omap3-n900.dts: fix i2c bus numbering

2015-02-09 Thread Ivaylo Dimitrov




On  9.02.2015 17:02, Nishanth Menon wrote:

On 17:48-20150208, Ivaylo Dimitrov wrote:

With legacy boot i2c buses on Nokia N900 are numbered i2c1, i2c2 and i2c3.
Commit 20b80942ef4e (ARM: dts: OMAP3+: Add i2c aliases) fixed the
numbering with DT boot, but introduced a regression on N900 - aliases
become i2c0, i2c1 and i2c2. Fix that by providing the correct aliases in
the board dts.

Signed-off-by: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---

I suppose this is due to some legacy userspace breakage?
if yes, we do not intend to break userspace :), So:


Yes, legacy userspace breakage :)

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

[PATCH] ARM: DTS: omap3-n900.dts: fix i2c bus numbering

2015-02-08 Thread Ivaylo Dimitrov

With legacy boot i2c buses on Nokia N900 are numbered i2c1, i2c2 and i2c3.
Commit 20b80942ef4e (ARM: dts: OMAP3+: Add i2c aliases) fixed the
numbering with DT boot, but introduced a regression on N900 - aliases
become i2c0, i2c1 and i2c2. Fix that by providing the correct aliases in
the board dts.

Signed-off-by: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 arch/arm/boot/dts/omap3-n900.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index b550c41..68bf3cd 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -16,6 +16,13 @@
model = Nokia N900;
compatible = nokia,omap3-n900, ti,omap3430, ti,omap3;
 
+   aliases {
+   i2c0;
+   i2c1 = i2c1;
+   i2c2 = i2c2;
+   i2c3 = i2c3;
+   };
+
cpus {
cpu@0 {
cpu0-supply = vcc;
-- 
1.9.1

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

Re: OMAP3 DSP

2015-01-26 Thread Ivaylo Dimitrov


Hi,

On 26.01.2015 21:56, Sven Brandau wrote:

Hello,

is there any driver support for the DSP on OMAP3 SOCs available in the
current kernel?

This means DSP image loading, starting and communication mechanisms
between ARM CPU and DSP.

The original TI driver only running on kernels with versions 2.6.x.

Best regards,
Sven


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


we still try to support out-of-the-tree tidspbridge, last version I 
tried and it was working was 3.16 (iirc), check it if it does the job 
for you:


https://gitorious.org/linux-n900/linux-n900/source/4af08adb31709cb3e057af10675f354553848653:drivers/staging/tidspbridge

It is tailored to be compatible with Maemo 5, but should work (in 
theory) with any distro as long as you have gst-dsp.


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

Re: [RFC] adp1653: Add device tree bindings for LED controller

2014-11-22 Thread Ivaylo Dimitrov



Hi,


Can you capture raw bayer images correctly? I assume green
means YUV buffers that are all zero.

Do you know more specifically which patch breaks it?


CCing freemangordon (Ivaylo Dimitrov). He tried to debug it
months ago but without success. Should know more info about this
problem.

I think that commit which broke it was not bisected...



According to my vague memories, the green captured image was a result 
from the ISP IRQ never got triggered. I tried to find why, but never 
succeeded.


Sakari, we discussed that on #maemo-ssu when I was playing with cameras, 
and there is nothing new in that regard:
http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2013-09-18.log.html#t2013-09-18T18:46:38 


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

Re: N900 modem support in 3.18-rc1

2014-11-14 Thread Ivaylo Dimitrov

On 14.11.2014 19:20, Sebastian Reichel wrote:

The patch looks ok. It does not cleanup the cmt-speech driver for
mainline usage, but it should work. Before adding this driver to the
mainline kernel there should be open source userspace support anyway.

I am aware of that(patch not ready), it's one of the reasons this patch
still sits on gitorious IMO.

libcmtspeechdata was opened by Nokia long ago, so I don't understand
what userspace support (for inclusion of the driver in the mainline
kernel that is) is needed. see
https://gitorious.org/meego-cellular/libcmtspeechdata/source/7f8f3ce357513e4849e1bf6d657980a514529c1a:

REed pulseaudio modules that use cmtspeech will be ready sooner than
later (I believe in 2-3 monts from now), see on gitorious how fast we
progressed with -record and -music modules. Sure, -voice module is way
more complicated, but lots of it is already opensourced, we just need to
figure out a couple of DSP algorithms(drc, agc, aec, etc) related to
call quality. But I don't think the driver should wait for those modules
to be REed, they can be used as is even now, in their closed form for
testing. Unfortunately all my spare time is dedicated to that PA stuff,
so I simply can't cleanup cmtspeech driver and send a patch for
upstreaming. (Pavel, what about you?)

Btw. I am aware that this would break existing pulse audio stuff,
but wouldn't it make sense to export a V4L2 device instead of the
custom /dev/cmt_speech ABI?

Nokia PA guys did a great job integrating lots of things related to
audio and honestly, I don't see a reason why should we reinvent the
wheel. There is lot more behind the scenes than simple PCM streaming
(like audio policies and routing, sideband audio, speakers protection,
etc) and reiplementing all this using different API wouldn't worth it IMO.

Not to say that I agree with Pali's reply that working userspace should
not be broken just for the sake of it.

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: N900 modem support in 3.18-rc1

2014-11-13 Thread Ivaylo Dimitrov




On 13.11.2014 18:24, Pavel Machek wrote:

On Fri 2014-11-07 09:04:52, Ivaylo Dimitrov wrote:

Sebastian is quiet, can we have the patch? :-).


Sure, why not :)

https://gitorious.org/linux-n900/freemangordons-linux-n900/commits/30e9a5c498a89cea4c29523f69e436bf0af3c631

commits 89ce13b, b81d80d, ec4d0dc, 91256e2 and 8022a6d - e29f558 (no 
idea why gitorious shows those mixed with SGX stuff, on my local tree it 
is contiguous patch series)


didn't test against the current upstream, but I see no reason why those 
should not apply, build and run.





About the pulseaudio stuff - we're still in process of REing it, so
far there are 2 out of 3 closed Nokia modules ready
(https://gitorious.org/pulseaudio-nokia), but the last one, which is
the one used for voice calls is still not ready and will take it a
while :).


Ok, is there a way I could help? Pretty much everything else works with
opensource drivers...



There is, though I am not sure you'll like it much - fire up IDA and 
join the party :P. Ping me on IRC for more details in case you're 
interested.


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

Re: N900 modem support in 3.18-rc1

2014-11-06 Thread Ivaylo Dimitrov




On  7.11.2014 01:01, Pali Rohár wrote:



For voice calls you need:
* kernel driver cmt-speech (or it has some new name)
* cmt-speech userspace library (communication with kernel)
* pulseaudio modules which are using that library

Freemangordon (Ivaylo Dimitrov, CCed) should know more about it,
specially about pulseaudio modules...



I have a patch for cmt-speech on top of nokia-modem driver living 
somewhere on my HDD, but I guess it is better Sebastian to make such a 
patch (Sebastian, no?).


About the pulseaudio stuff - we're still in process of REing it, so far 
there are 2 out of 3 closed Nokia modules ready 
(https://gitorious.org/pulseaudio-nokia), but the last one, which is the 
one used for voice calls is still not ready and will take it a while :).


Regards,
Ivo

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

Re: Anybody working on tidspbridge?

2014-07-09 Thread Ivaylo Dimitrov

On 9.07.2014 10:07, Tony Lindgren wrote:

* Suman Anna s-a...@ti.com [140708 11:40]:

Hi Peter,

On 07/08/2014 09:36 AM, Greg KH wrote:

On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote:

Hello,

Given the total lack of response here, I suggest just deleting the
driver. No one has ever done the real work that is going to be
required to get this code out of staging. It has had build errors
causing it to not even be usable for some kernel versions with no one
noticing, so I doubt anyone cares about it anymore here.

Cc'ing some more people who might be interested. If no one offers to
work on the driver in the next couple of days, I'll send a patch to
remove it.

I'm using the driver (with kernel 3.7) and it works reasonably well for
me; removing it seems a bit harsh.

Using it is different from being able to maintain the code and move it
out of the staging tree. Also, 3.7 is really old and obsolete, not much
we can do with that kernel version :)

Are you able to work on the code and do the effort needed to get it out
of the staging tree? If so, great, if not, we are going to have to
delete it, sorry.

I agree with Greg here. In fact, the current TODO does not do enough
justice to the amount of work required to make it even work on the
latest kernel. Most of the TIers who worked on this driver have moved on
as Kristina would have figured with her bounced emails. So I do suggest
that this driver be deleted from the kernel tree. If there are enough
number of folks using it (not sure how many are out there), it can be
worked on out-of-tree and brought back in a cleaner fashion rather than
keeping a broken stale driver in the kernel.

I agree, not much has improved with this driver since it got added into
staging except just compile fixes.

Regards,

Tony

Well, recently I've sent a couple of patches which implement stuff from
TODO [1]. However, with the migration to DT, my focus now is to have a
kernel/userspace that boots at all and this leaves no free cycles for
DSP. Maybe tidspbridge can be left in staging until DT migration is
finished, that way me (and maybe other people) will have the time needed
to try to implement what remains in TODO. Also, keep in mind there will
(hopefully) be another omap3 end-user device released by the end of the
year (Neo900), which most probably will gain more developers interested
in fixing the DSP driver.

Regards,
Ivo

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=559c71fe5dc3bf2ecc55afb336145db7f0abf810

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=a3b0a48bd14c9ba4ca8d051b0c92d5bc3866
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/tidspbridge?id=d30555853052bbec8497260ba888b7d696bed9b8
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC] OMAP DT i2c aliases

2014-06-02 Thread Ivaylo Dimitrov




On  2.06.2014 18:42, Nishanth Menon wrote:

On 06/01/2014 09:28 AM, Ivaylo Dimitrov wrote:

Hi,

patch https://lkml.org/lkml/2013/10/16/744 fixes DT i2c bus ids in case
of deferred probe and assigns id 0,1 and 2 for i2c buses 1,2 and 3.
Unfortunately, this breaks Maemo userspace on N900, where board code (in
case of legacy boot) assigns ids 1, 2 and 3, but with DT boot ids are


ughh.. missed that :(


0,1 and 2. I've already send a patch https://lkml.org/lkml/2014/6/1/49
that will allow me to fix that from board .dts, but I was wondering if
it is the correct way, or ids should be changed in omap3.dtsi for all
omap devices.


Should'nt we retain 0,1,2 as indexing to make this consistent for all
SoCs?




I think this is the most sane thing, esp if the alias replace patch 
gets accepted(thus allowing us to workaround the problems on N900 and 
N9/50), however I wanted to hear from you on the matter. Esp that 
indexing is different with legacy boot compared to DT boot.

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

Re: [RFC] OMAP DT i2c aliases

2014-06-02 Thread Ivaylo Dimitrov




On  2.06.2014 19:19, Nishanth Menon wrote:


I think that slipped my check list unfortunately. :( But then, if we
think that it is just n900 that is impacted, then I wonder if we can
override the alias? just wondering..



That https://lkml.org/lkml/2014/6/1/49 patch will allow such override, I 
tested it on N900 with Fremantle and it works fine. Ofc I had to add


aliases {
i2c1 = i2c1;
i2c2 = i2c2;
i2c3 = i2c3;
};

to omap3-n900.dts (while keeping omap3.dtsi intact) for it to work.

I checked in some Nemo N9/N950 adaptation kernel and it seems those will 
be broken too(and I bet it is the same in stock Nokia N9/50 kernels):


static void __init rm680_i2c_init(void)
{
omap3_pmic_get_config(rm680_twl_data, TWL_COMMON_PDATA_USB,
  TWL_COMMON_REGULATOR_VDAC |
  TWL_COMMON_REGULATOR_VPLL2);
omap_pmic_init(1, 2900, twl5031, INT_34XX_SYS_NIRQ, rm680_twl_data);
omap_register_i2c_bus(2, 400, rm696_peripherals_i2c_board_info_2,
  ARRAY_SIZE(rm696_peripherals_i2c_board_info_2));
omap_register_i2c_bus(3, 400, rm696_peripherals_i2c_board_info_3,
  ARRAY_SIZE(rm696_peripherals_i2c_board_info_3));
}

Again 1,2 and 3 for bus indexes just like on N900.

Anyway, I am fine with the alias override. If the patch makes it to the 
upstream :)


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

[RFC] OMAP DT i2c aliases

2014-06-01 Thread Ivaylo Dimitrov


Hi,

patch https://lkml.org/lkml/2013/10/16/744 fixes DT i2c bus ids in case 
of deferred probe and assigns id 0,1 and 2 for i2c buses 1,2 and 3. 
Unfortunately, this breaks Maemo userspace on N900, where board code (in 
case of legacy boot) assigns ids 1, 2 and 3, but with DT boot ids are 
0,1 and 2. I've already send a patch https://lkml.org/lkml/2014/6/1/49 
that will allow me to fix that from board .dts, but I was wondering if 
it is the correct way, or ids should be changed in omap3.dtsi for all 
omap devices.


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

Re: Re: [PATCH] ARM: OMAP2+: Add support for thumb mode on DT booted N900

2014-02-05 Thread Ivaylo Dimitrov


Hi,

On  5.02.2014 19:17, Sebastian Reichel wrote:

Hi,

On Wed, Feb 05, 2014 at 05:38:54PM +0100, Pali Rohár wrote:

I assumed, that the workaround is not needed for this device type.


That rx51 secure call must not be called on non secure devices (e.g.
qemu), because it cause kernel crash. So I thought that kernel should
write something like secure call is disabled on that device types.
Kernel code for errata 430973 will update ibe bit for non secure
devices.


Do you see any advantage in having that message?



AIUI it will appear only when booting the kernel in qemu -m rx51..., I 
am not aware of any other non-secure device manifesting itself as RX51. 
So there is little advantage of having that additional message IMO.



I just added the warning for missing CONFIG_ARM_ERRATA_430973,
because its very likely a misconfigured kernel.


Yes, it can be misconfigured kernel, but if you do not have any thumb
binary (like stock Maemo 5 system), then it is safe and OK.


I think running this kernel may also be a potential security
problem. If I understand it right the ARM core is left in an
unstable state when you run Thumb code, so this may result in
funny effects in the kernel?

-- Sebastian



In theory having that workaround disabled might be a security problem, 
but honestly, knowing its nature I don't think it is easily exploitable, 
if at all. The final result when bitten by it is a SIGILL, but in 
userspace, not in the kernel(assuming the kernel is ARM), and userspace 
runs in totally different mode (nonsecure, nonprivileged) compared to 
the kernel(nonsecure, privileged) and IIRC every mode has its own set of 
stack, registers etc. BTW I don't think the kernel itself can be 
thumb2-compiled for cores with that errata, but I might wrong. Also, as 
Pali noted, the problem appears if and only if there is an userspace 
binary containing thumb2 code. If all of the userspace is pure ARM, 
there is no problem. And as the errata workaround has its drawbacks (BTB 
is cleared on every context switch which affects performance), one might 
want to not have it enabled. Maybe that warning should be spit only if 
CONFIG_THUMB2_KERNEL (or whatever the option was) is enabled. Though if 
that option is enabled I'd rather #error during compile time if errata 
workaround is not enabled, instead of printing a warning while booting a 
system that will crash in a matter of seconds.


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Ivaylo Dimitrov




On 29.01.2014 11:10, Tero Kristo wrote:



It looks like the omap36xx version of the omap96m_alwon_fck is modelled
improperly in the dts files. I don't have access to omap36xx hardware
myself, but give a try for the following patch:




It could be that 36xx omap96m_alwon_fck clock is wrongly modeled, but I 
am testing on 1) 3430es2 (Nokia N900) and 2) legacy boot, so I guess 
that patch won't help much (unless I am missing something and DT is used 
even with legacy boot and 36xx clocks are used on 3430es2)


Thanks,
Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-29 Thread Ivaylo Dimitrov




On 29.01.2014 13:30, Tomi Valkeinen wrote:

On 2014-01-28 20:17, Ivaylo Dimitrov wrote:



On 28.01.2014 10:48, Tomi Valkeinen wrote:


I made a somewhat hacky quickfix for beagle. Applying that and the
clk-divider from the link above makes things work for me. However, as I
said, the issue with n900 might be different, but it'd be interesting to
hear if it has any effect.

   Tomi



Applying those 2 patches doesn't help, still get exactly the same warning.

Find attached my clk_summary (with my hacky patch applied, otherwise I
cannot boot the device)


Can you try this one:

 From e511789f7be00be0712910c60a57c51b2705 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Wed, 29 Jan 2014 13:28:53 +0200
Subject: [PATCH] clkoutx2 fix

---
  arch/arm/mach-omap2/cclock3xxx_data.c |  7 +++
  arch/arm/mach-omap2/dpll3xxx.c| 20 
  2 files changed, 27 insertions(+)



Yep, that one fixes the problem. Thanks!

Now I only need to find why maemo is 10 times slower with linux-next 
compared to 3.13-rc7, but that is another story :).


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BISECTED] OMAP: DSS: clk rate mismatch

2014-01-28 Thread Ivaylo Dimitrov




On 28.01.2014 10:48, Tomi Valkeinen wrote:


I made a somewhat hacky quickfix for beagle. Applying that and the
clk-divider from the link above makes things work for me. However, as I
said, the issue with n900 might be different, but it'd be interesting to
hear if it has any effect.

  Tomi



Applying those 2 patches doesn't help, still get exactly the same warning.

Find attached my clk_summary (with my hacky patch applied, otherwise I 
cannot boot the device)


Ivo
   clockenable_cnt  prepare_cnt  rateaccuracy
-
 secure_32k_fck 0   032768  0  
wdt1_fck0   032768  0  
gpt12_fck   0   032768  0  
 mcbsp_clks 0   50  0  
 sys_altclk 0   00  0  
 virt_38_4m_ck  0   03840   0  
 virt_2600_ck   0   02600   0  
 virt_1920_ck   1   11920   0  
osc_sys_ck  1   11920   0  
   sys_clkout1  0   01920   0  
   sys_ck   4   14   1920   0  
  dpll1_ck  0   16  0  
 dpll1_x2_ck0   112 0  
dpll1_x2m2_ck   0   112 0  
   mpu_ck   0   112 0  
  emu_mpu_alwon_ck 0   012 0
  
  arm_fck   0   16  0  
  traceclk_src_fck  0   01920   0  
 traceclk_fck   0   01920   0  
  emu_src_ck0   11920   0  
 atclk_fck  0   01920   0  
 pclkx2_fck 0   01920   0  
 pclk_fck   0   09600  
  gpt9_fck  0   11920   0  
  gpt4_fck  0   11920   0  
  gpt3_fck  0   11920   0  
  gpt2_fck  0   11920   0  
  dss2_alwon_fck0   21920   0  
  dpll4_ck  2   343200  0  
 dpll4_m6_ck0   014400  0  
dpll4_m6x2_ck   0   028800  0  
   emu_per_alwon_ck 0   028800  0   
   
 dpll4_m5_ck0   08640   0  
dpll4_m5x2_ck   0   017280  0  
   cam_mclk 0   017280  0  
  cam_xclkb 0   01080   0  
  cam_xclka 0   09600  
 dpll4_m4_ck1   13600   0  
dpll4_m4x2_ck   1   17200   0  
   dss1_alwon_fck_3430es2 2   47200   0 
 
 dpll4_m3_ck0   12700   0  
dpll4_m3x2_ck   0   15400   0  
   omap_54m_fck 0   15400   0  
  dss_tv_fck 0   25400   0  
  clkout2_src_ck 0   05400   0  

 sys_clkout2 0   05400   0  

 dpll4_m2_ck1   14800   0  
dpll4_m2x2_ck   1   19600   0  
   omap_96m_alwon_fck 1   29600   0 
 
  per_96m_fck 0   69600   0 
 
 mcbsp4_fck 0   19600   0   
   
 mcbsp3_fck 0   29600   0   
   
 mcbsp2_fck 0   29600   0   
   
  cm_96m_fck 2   2

[BISECTED] OMAP: DSS: clk rate mismatch

2014-01-27 Thread Ivaylo Dimitrov


Hi Tomi,

linux-next-20140124 DSS is broken on N900  - display stays black (there 
is some noise though). I booted the kernel with qemu and it gives the 
following warning:


[0.623779] DSS: set fck to 17280
[0.624237] [ cut here ]
[0.624298] WARNING: CPU: 0 PID: 1 at 
drivers/video/omap2/dss/dss.c:497 dss_set_fck_rate+0x68/0x8c()

[0.624359] clk rate mismatch: 28800 != 17280
[0.624389] Modules linked in:
[0.624481] CPU: 0 PID: 1 Comm: swapper Tainted: GW 
3.13.0-next-20140124+ #35
[0.624572] [c00126dc] (unwind_backtrace) from [c0010c30] 
(show_stack+0x10/0x14)
[0.624633] [c0010c30] (show_stack) from [c0032d8c] 
(warn_slowpath_common+0x64/0x84)
[0.624694] [c0032d8c] (warn_slowpath_common) from [c0032e2c] 
(warn_slowpath_fmt+0x2c/0x3c)
[0.624755] [c0032e2c] (warn_slowpath_fmt) from [c01edb88] 
(dss_set_fck_rate+0x68/0x8c)
[0.624816] [c01edb88] (dss_set_fck_rate) from [c056f300] 
(omap_dsshw_probe+0x1e4/0x2f8)
[0.624877] [c056f300] (omap_dsshw_probe) from [c023e5f8] 
(platform_drv_probe+0x18/0x48)
[0.624938] [c023e5f8] (platform_drv_probe) from [c023d1f0] 
(driver_probe_device+0xb0/0x200)
[0.624999] [c023d1f0] (driver_probe_device) from [c023d3a8] 
(__driver_attach+0x68/0x8c)
[0.625061] [c023d3a8] (__driver_attach) from [c023bac0] 
(bus_for_each_dev+0x50/0x88)
[0.625122] [c023bac0] (bus_for_each_dev) from [c023ca28] 
(bus_add_driver+0xcc/0x1c8)
[0.625183] [c023ca28] (bus_add_driver) from [c023da24] 
(driver_register+0x9c/0xe0)
[0.625244] [c023da24] (driver_register) from [c023e540] 
(platform_driver_probe+0x20/0xc0)
[0.625305] [c023e540] (platform_driver_probe) from [c056f088] 
(omap_dss_init+0x1c/0xb0)
[0.625366] [c056f088] (omap_dss_init) from [c0008758] 
(do_one_initcall+0x94/0x138)
[0.625427] [c0008758] (do_one_initcall) from [c054db64] 
(kernel_init_freeable+0xe4/0x1ac)
[0.625488] [c054db64] (kernel_init_freeable) from [c03a0108] 
(kernel_init+0x8/0x100)
[0.625549] [c03a0108] (kernel_init) from [c000ded8] 
(ret_from_fork+0x14/0x3c)

[0.625610] ---[ end trace 9f1065fe5ada0e27 ]---


According to git bisect, this 
http://permalink.gmane.org/gmane.linux.ports.arm.omap/107355 is the 
commit that broke it. Unfortunately that commit cannot be reverted, so I 
did a quick'n'dirty hack(just for the sake of it):


diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 9a145da..10e2fab 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -482,7 +482,8 @@ bool dss_div_calc(unsigned long pck, unsigned long 
fck_min,


 int dss_set_fck_rate(unsigned long rate)
 {
-   int r;
+   int  r, mul, div;
+   unsigned long prate;

DSSDBG(set fck to %lu\n, rate);

@@ -490,8 +491,22 @@ int dss_set_fck_rate(unsigned long rate)
if (r)
return r;

-   dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+   prate = clk_get_rate(dss.dss_clk);
+
+   for (mul = 1; mul  16; mul++)
+   for(div = 1; div 16; div++)
+   if(((prate*mul)/div) == rate)
+   goto found;
+
+found:

+   if(mul != 16)
+   r = clk_set_rate(dss.dss_clk, (rate*mul)/div);
+
+   if (r)
+   return r;
+
+   dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
WARN_ONCE(dss.dss_clk_rate != rate,
clk rate mismatch: %lu != %lu, dss.dss_clk_rate,
rate);


and it solves the problem. I hope the above will give you a better idea 
on what is really broken (and how to fix it :) ).


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

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

2014-01-22 Thread Ivaylo Dimitrov


Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues

Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation

2014-01-13 Thread Ivaylo Dimitrov

From: Ivaylo Dimitrov freemangor...@abv.bg

commit 7faa92339bbb1e6b9a80983b206642517327eb75 OMAPDSS: DISPC: Handle
synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
on OMAP3. However, it misses the logic found in Nokia kernels that is
needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
well as the logic to fallback to 3 taps if 5 taps clock results in too
tight horizontal timings. Without that patch horizontal timing too tight
errors are seen when a video with resolution above 640x350 is tried to be
played. The patch is a forward-ported logic found in Nokia N900 and N9/50
kernels.

Signed-off-by: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 drivers/video/omap2/dss/dispc.c |   31 ++-
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 67e413e..66e0849 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1999,7 +1999,8 @@ static void calc_tiler_rotation_offset(u16 screen_width, 
u16 width,
  */
 static int check_horiz_timing_omap3(unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *t, u16 pos_x,
-   u16 width, u16 height, u16 out_width, u16 out_height)
+   u16 width, u16 height, u16 out_width, u16 out_height,
+   bool five_taps)
 {
const int ds = DIV_ROUND_UP(height, out_height);
unsigned long nonactive;
@@ -2019,6 +2020,10 @@ static int check_horiz_timing_omap3(unsigned long pclk, 
unsigned long lclk,
if (blank = limits[i])
return -EINVAL;
 
+   /* FIXME add checks for 3-tap filter once the limitations are known */
+   if (!five_taps)
+   return 0;
+
/*
 * Pixel data should be prepared before visible display point starts.
 * So, atleast DS-2 lines must have already been fetched by DISPC
@@ -2194,22 +2199,30 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long 
pclk, unsigned long lclk,
do {
in_height = DIV_ROUND_UP(height, *decim_y);
in_width = DIV_ROUND_UP(width, *decim_x);
-   *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
-   in_width, in_height, out_width, out_height, color_mode);
-
-   error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
-   pos_x, in_width, in_height, out_width,
-   out_height);
+   *five_taps = in_height  out_height;
 
if (in_width  maxsinglelinewidth)
if (in_height  out_height 
in_height  out_height * 2)
*five_taps = false;
-   if (!*five_taps)
+again:
+   if (*five_taps)
+   *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
+   in_width, in_height, out_width,
+   out_height, color_mode);
+   else
*core_clk = dispc.feat-calc_core_clk(pclk, in_width,
in_height, out_width, out_height,
mem_to_mem);
 
+   error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
+   pos_x, in_width, in_height, out_width,
+   out_height, *five_taps);
+   if (error  *five_taps) {
+   *five_taps = false;
+   goto again;
+   }
+
error = (error || in_width  maxsinglelinewidth * 2 ||
(in_width  maxsinglelinewidth  *five_taps) ||
!*core_clk || *core_clk  dispc_core_clk_rate());
@@ -2226,7 +2239,7 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long 
pclk, unsigned long lclk,
} while (*decim_x = *x_predecim  *decim_y = *y_predecim  error);
 
if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, width,
-   height, out_width, out_height)){
+   height, out_width, out_height, *five_taps)) {
DSSERR(horizontal timing too tight\n);
return -EINVAL;
}
-- 
1.5.6.1

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

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2014-01-11 Thread Ivaylo Dimitrov


On 10.01.2014 12:56, Tomi Valkeinen wrote:

On 2014-01-05 15:13, Ivaylo Dimitrov wrote:

From: Ivaylo Dimitrov freemangor...@abv.bg

Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
unlock in acx565akm_enable but introduces another problem - if
acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
that by unlocking the mutex on early return. Also add mutex protection in
acx565akm_panel_power_off and remove an unused variable



I think this is just getting more messy. How about we more or less revert the 
c37dd677988ca50bc8bc60ab5ab053720583c168 and fix it like this:



I am fine with whatever patch you may come with, as long as it fixes the 
issue.




diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c 
b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index 714ee92dfb9f..8e97d06921ff 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c


The patch does not apply cleanly on top of rc7, however I applied it by 
hand. So far it seems it fixes the issue brought by 
c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if 
mutex_lock/mutex_unlock are complementary in every code path (at least 
not explicitly, I guess maemo is doing it for us anyway :) ).


So, shall I send a patch incorporating your code changes, or you will do it?

Regards,
Ivo

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

[PATCH] OMAPDSS: DISPC: Fix 34xx overlay scaling calculation

2014-01-11 Thread Ivaylo Dimitrov

From: Ivaylo Dimitrov freemangor...@abv.bg

commit 7faa92339bbb1e6b9a80983b206642517327eb75 OMAPDSS: DISPC: Handle
synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
on OMAP3. However, it misses the logic found in Nokia kernels that is
needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
well as the logic to fallback to 3 taps if 5 taps clock results in too
tight horizontal timings. Without that patch horizontal timing too tight
errors are seen when a video with resolution above 640x350 is tried to be
played. The patch is a forward-ported logic found in Nokia N900 and N9/50
kernels.

Signed-off-by: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 drivers/video/omap2/dss/dispc.c |   36 +---
 1 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 67e413e..9d1aa25 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1999,7 +1999,8 @@ static void calc_tiler_rotation_offset(u16 screen_width, 
u16 width,
  */
 static int check_horiz_timing_omap3(unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *t, u16 pos_x,
-   u16 width, u16 height, u16 out_width, u16 out_height)
+   u16 width, u16 height, u16 out_width, u16 out_height,
+   bool five_taps)
 {
const int ds = DIV_ROUND_UP(height, out_height);
unsigned long nonactive;
@@ -2019,6 +2020,10 @@ static int check_horiz_timing_omap3(unsigned long pclk, 
unsigned long lclk,
if (blank = limits[i])
return -EINVAL;
 
+   /* FIXME add checks for 3-tap filter once the limitations are known */
+   if (!five_taps)
+   return 0;
+
/*
 * Pixel data should be prepared before visible display point starts.
 * So, atleast DS-2 lines must have already been fetched by DISPC
@@ -2191,24 +2196,33 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long 
pclk, unsigned long lclk,
const int maxsinglelinewidth =
dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
 
+   *five_taps = height  out_height;
+
do {
in_height = DIV_ROUND_UP(height, *decim_y);
in_width = DIV_ROUND_UP(width, *decim_x);
-   *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
-   in_width, in_height, out_width, out_height, color_mode);
-
-   error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
-   pos_x, in_width, in_height, out_width,
-   out_height);
 
if (in_width  maxsinglelinewidth)
if (in_height  out_height 
in_height  out_height * 2)
*five_taps = false;
-   if (!*five_taps)
+again:
+   if (*five_taps)
+   *core_clk = calc_core_clk_five_taps(pclk, mgr_timings,
+   in_width, in_height, out_width,
+   out_height, color_mode);
+   else
*core_clk = dispc.feat-calc_core_clk(pclk, in_width,
-   in_height, out_width, out_height,
-   mem_to_mem);
+   in_height, out_width, out_height,
+   mem_to_mem);
+
+   error = check_horiz_timing_omap3(pclk, lclk, mgr_timings,
+   pos_x, in_width, in_height, out_width,
+   out_height, *five_taps);
+   if (error  *five_taps) {
+   *five_taps = false;
+   goto again;
+   }
 
error = (error || in_width  maxsinglelinewidth * 2 ||
(in_width  maxsinglelinewidth  *five_taps) ||
@@ -2226,7 +2240,7 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long 
pclk, unsigned long lclk,
} while (*decim_x = *x_predecim  *decim_y = *y_predecim  error);
 
if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, width,
-   height, out_width, out_height)){
+   height, out_width, out_height, *five_taps)) {
DSSERR(horizontal timing too tight\n);
return -EINVAL;
}
-- 
1.5.6.1

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

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

2014-01-11 Thread Ivaylo Dimitrov


On 09.01.2014 10:08, Hiremath, Vaibhav wrote:



No, that's what is causing issue to me. Can you try predefined address flow?

Thanks,
Vaibhav



Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.13.0-rc7+ (maemo@maemo-desktop) (gcc version 4.7.2 
20120701 (prerelease) (Linaro GCC 4.7-2012.07) ) #24 PREEMPT Sat Jan 11 
17:06:39 EET 2014

CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Nokia RX-51 board
omapfb: reserved 0x0080 bytes at 0x8f10
Memory policy: Data cache writeback
On node 0 totalpages: 61696
free_area_init_node: node 0, pgdat c05b73b4, node_mem_map c061b000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 61696 pages, LIFO batch:15
CPU: All CPU(s) started in SVC mode.
OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 61184
Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs 
rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw 
mtdoops.mtddev=log console=tty0 console=ttyO2 omapfb_vram=8M@0x8F10 
omapfb.mode=lcd:848x480-16



There are no (UNDERFLOW) errors on OMAP3 when predefined address is 
used, I am still able to play every video I try.


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

2014-01-08 Thread Ivaylo Dimitrov



On 09.01.2014 07:06, Hiremath, Vaibhav wrote:

Tomi,

I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
Did you see this on OMAP?

I am using omapfb_vram=10M@0xA000, and I believe it is correct way of 
usage.

Thanks,
Vaibhav



AFAIK underflow interrupts could come from badly calculated DSS core 
clock or bad HW resizer setup and should be unrelated to the memory 
allocation. It might be something similar to the problem I have on N900 
- see https://lkml.org/lkml/2014/1/6/173


Is it possible to upload the video you have problems with, so me to test 
it on N900? So far I didn't see any underflow issues on it (N900 is 
OMAP3, in case you're not aware), no matter the resolution of the videos 
I played(up to 720p), however I didn't test the part that allocates the 
memory on a pre-defined address. Though I don't think that should matter.


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2014-01-05 Thread Ivaylo Dimitrov


On 04.01.2014 14:51, Pavel Machek wrote:

On Mon 2013-12-30 18:17:52, Ivaylo Dimitrov wrote:

From: Ivaylo Dimitrov freemangor...@abv.bg

Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
unlock in acx565akm_enable but introduces another problem - if
acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
that by unlocking the mutex on early return. Also add mutex protection in
acx565akm_panel_power_off and remove an unused variable

Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg

Reviewed-by: Pavel Machek pa...@ucw.cz


Hmm, I introduced a bug with that patch (recursive lock), will send a 
new version that fixes it


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

[PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2014-01-05 Thread Ivaylo Dimitrov

From: Ivaylo Dimitrov freemangor...@abv.bg

Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
unlock in acx565akm_enable but introduces another problem - if
acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
that by unlocking the mutex on early return. Also add mutex protection in
acx565akm_panel_power_off and remove an unused variable

Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
---
 .../omap2/displays-new/panel-sony-acx565akm.c  |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c 
b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index d94f35d..9aef7fa 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -535,6 +535,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device 
*dssdev)
 
r = in-ops.sdi-enable(in);
if (r) {
+   mutex_unlock(ddata-mutex);
pr_err(%s sdi enable failed\n, __func__);
return r;
}
@@ -546,6 +547,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device 
*dssdev)
gpio_set_value(ddata-reset_gpio, 1);
 
if (ddata-enabled) {
+   mutex_unlock(ddata-mutex);
dev_dbg(ddata-spi-dev, panel already enabled\n);
return 0;
}
@@ -578,10 +580,14 @@ static void acx565akm_panel_power_off(struct 
omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata-in;
 
+   mutex_lock(ddata-mutex);
+
dev_dbg(dssdev-dev, %s\n, __func__);
 
-   if (!ddata-enabled)
+   if (!ddata-enabled) {
+   mutex_unlock(ddata-mutex);
return;
+   }
 
set_display_state(ddata, 0);
set_sleep_mode(ddata, 1);
@@ -601,11 +607,13 @@ static void acx565akm_panel_power_off(struct 
omap_dss_device *dssdev)
msleep(100);
 
in-ops.sdi-disable(in);
+
+   mutex_unlock(ddata-mutex);
+
 }
 
 static int acx565akm_enable(struct omap_dss_device *dssdev)
 {
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
int r;
 
dev_dbg(dssdev-dev, %s\n, __func__);
@@ -627,16 +635,12 @@ static int acx565akm_enable(struct omap_dss_device 
*dssdev)
 
 static void acx565akm_disable(struct omap_dss_device *dssdev)
 {
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
-
dev_dbg(dssdev-dev, %s\n, __func__);
 
if (!omapdss_device_is_enabled(dssdev))
return;
 
-   mutex_lock(ddata-mutex);
acx565akm_panel_power_off(dssdev);
-   mutex_unlock(ddata-mutex);
 
dssdev-state = OMAP_DSS_DISPLAY_DISABLED;
 }
-- 
1.5.6.1

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

Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support

2014-01-05 Thread Ivaylo Dimitrov



On 30.12.2013 15:19, Tomi Valkeinen wrote:

The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
However, on some use cases, even when CMA is in use, it's quite probable
that omapfb fails to allocate the fb, either due to not enough free dma
memory, fragmented dma memory, or CMA failing to make enough contiguous
space.

This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
used to give the size of a memory area reserved exclusively for omapfb,
and optionally a physical address where the memory area is reserved.

The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. The dma_alloc function will first try to
allocate the fb from the coherent memory area, and if that fails, it'll
use the normal method of allocation.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ivaylo Dimitrov freemangor...@abv.bg
---
  arch/arm/mach-omap2/common.c |  1 +
  arch/arm/mach-omap2/common.h |  2 ++
  arch/arm/mach-omap2/fb.c | 77 +++-
  3 files changed, 79 insertions(+), 1 deletion(-)



Tested on Nokia N900 with Maemo5 and linux 3.13-rc6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

2013-12-30 Thread Ivaylo Dimitrov

From: Ivaylo Dimitrov freemangor...@abv.bg

Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
unlock in acx565akm_enable but introduces another problem - if
acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
that by unlocking the mutex on early return. Also add mutex protection in
acx565akm_panel_power_off and remove an unused variable

Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
---
 .../omap2/displays-new/panel-sony-acx565akm.c  |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c 
b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index d94f35d..a093d3a 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -535,6 +535,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device 
*dssdev)
 
r = in-ops.sdi-enable(in);
if (r) {
+   mutex_unlock(ddata-mutex);
pr_err(%s sdi enable failed\n, __func__);
return r;
}
@@ -546,6 +547,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device 
*dssdev)
gpio_set_value(ddata-reset_gpio, 1);
 
if (ddata-enabled) {
+   mutex_unlock(ddata-mutex);
dev_dbg(ddata-spi-dev, panel already enabled\n);
return 0;
}
@@ -578,10 +580,14 @@ static void acx565akm_panel_power_off(struct 
omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata-in;
 
+   mutex_lock(ddata-mutex);
+
dev_dbg(dssdev-dev, %s\n, __func__);
 
-   if (!ddata-enabled)
+   if (!ddata-enabled) {
+   mutex_unlock(ddata-mutex);
return;
+   }
 
set_display_state(ddata, 0);
set_sleep_mode(ddata, 1);
@@ -601,11 +607,13 @@ static void acx565akm_panel_power_off(struct 
omap_dss_device *dssdev)
msleep(100);
 
in-ops.sdi-disable(in);
+
+   mutex_unlock(ddata-mutex);
+
 }
 
 static int acx565akm_enable(struct omap_dss_device *dssdev)
 {
-   struct panel_drv_data *ddata = to_panel_data(dssdev);
int r;
 
dev_dbg(dssdev-dev, %s\n, __func__);
-- 
1.5.6.1

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

Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

2013-12-27 Thread Ivaylo Dimitrov



On 27.12.2013 11:48, Pavel Machek wrote:

On Thu 2013-12-26 01:12:39, Ivaylo Dimitrov wrote:

From: Ivaylo Dimitrov freemangor...@abv.bg

On memory limited devices, CMA fails easily when asked to allocate big
chunks of memory like framebuffer memory needed for video playback.

Add boot parameter omapfb_memsize which allocates memory to be used
as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when
trying to allocate memory for the framebuffers

Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg

Hmm, would it make sense to add a parameter to reserve certain ammount
of memory for CMA? omapfb is probably not the only user hitting
this...?
Pavel


But that would mean that one must have CMA enabled to use that 
functionality and it is an additional memory overhead. Also, I don't 
think we will have much of a benefit of that - for video playback we'll 
still have to preallocate the same amount of RAM as now - but with the 
additional overhead of page migration when that RAM becomes needed by 
DSP and OMAPFB. However, even if such functionality is someday 
implemented in CMA, it doesn't conflict with the proposed patch - by 
simply not preallocating memory for omapfb, one will automatically use it.


BTW there is CMEM driver (not upstreamed afaik) which does exactly that 
- it manages a contiguous (stolen)memory pool. No idea how easy it 
would be to merge CMEM into CMA. Neither I am the right guy for the 
task, IMO :)


Ivo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: omapfb: Add early framebuffer memory allocator

2013-12-25 Thread Ivaylo Dimitrov

From: Ivaylo Dimitrov freemangor...@abv.bg

On memory limited devices, CMA fails easily when asked to allocate big
chunks of memory like framebuffer memory needed for video playback.

Add boot parameter omapfb_memsize which allocates memory to be used
as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when
trying to allocate memory for the framebuffers

Signed-off-by: Ivaylo Dimitrov freemangor...@abv.bg
---
 arch/arm/mach-omap2/common.c |1 +
 arch/arm/mach-omap2/common.h |2 +
 arch/arm/mach-omap2/fb.c |   46 +-
 3 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9e..9beecde 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -33,4 +33,5 @@ void __init omap_reserve(void)
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
+   omap_fb_reserve_memblock();
 }
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index e30ef67..21afdc0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -304,6 +304,8 @@ extern void omap_reserve(void);
 struct omap_hwmod;
 extern int omap_dss_reset(struct omap_hwmod *);
 
+extern void omap_fb_reserve_memblock(void);
+
 /* SoC specific clock initializer */
 extern int (*omap_clk_init)(void);
 
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 26e28e9..0eacbe9 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -30,6 +30,7 @@
 #include linux/dma-mapping.h
 
 #include asm/mach/map.h
+#include asm/memblock.h
 
 #include soc.h
 #include display.h
@@ -106,10 +107,53 @@ static struct platform_device omap_fb_device = {
.num_resources = 0,
 };
 
+static phys_addr_t omapfb_mem_base __initdata;
+static phys_addr_t omapfb_mem_size __initdata;
+
+void __init omap_fb_reserve_memblock(void)
+{
+   if (omapfb_mem_size) {
+   omapfb_mem_base = arm_memblock_steal(omapfb_mem_size, SZ_1M);
+   if (omapfb_mem_base)
+   pr_info(omapfb: reserved %u bytes at %x\n,
+   omapfb_mem_size, omapfb_mem_base);
+   else
+   pr_err(omapfb: arm_memblock_steal failed\n);
+   }
+}
+
 int __init omap_init_fb(void)
 {
-   return platform_device_register(omap_fb_device);
+   int ret;
+
+   ret = platform_device_register(omap_fb_device);
+
+   if (ret)
+   return ret;
+
+   if (!omapfb_mem_base)
+   return 0;
+
+   ret = dma_declare_coherent_memory(omap_fb_device.dev,
+ omapfb_mem_base, omapfb_mem_base,
+ omapfb_mem_size, DMA_MEMORY_MAP |
+ DMA_MEMORY_EXCLUSIVE);
+   if (!(ret  DMA_MEMORY_MAP))
+   pr_err(omapfb: dma_declare_coherent_memory failed\n);
+
+   return 0;
+}
+
+static int __init early_omapfb_memsize(char *p)
+{
+   omapfb_mem_size = ALIGN(memparse(p, p), SZ_1M);
+
+   if(!omapfb_mem_size)
+   pr_err(omapfb: bad memsize parameter\n);
+
+   return 0;
 }
+early_param(omapfb_memsize, early_omapfb_memsize);
 #else
 int __init omap_init_fb(void) { return 0; }
 #endif
-- 
1.5.6.1

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

54 matches

Mail list logo