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

ead 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 Dimit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Sign

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

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

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

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 inse

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

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.dimit

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

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 +-- ar

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

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

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

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.dimit

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

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 chan

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

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

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

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

Re: linux 4.2-rc1 broken Nokia N900

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

Re: ARM errata 430973 on multi platform kernels

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

Re: ARM errata 430973 on multi platform kernels

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

Re: ARM errata 430973 on multi platform kernels

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

Re: ARM errata 430973 on multi platform kernels

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

Re: ARM errata 430973 on multi platform kernels

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

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

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

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

. 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

Re: OMAP3 DSP

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

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

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

Re: N900 modem support in 3.18-rc1

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),

Re: N900 modem support in 3.18-rc1

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

Re: N900 modem support in 3.18-rc1

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

Re: Anybody working on tidspbridge?

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

Re: [RFC] OMAP DT i2c aliases

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

Re: [RFC] OMAP DT i2c aliases

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

[RFC] OMAP DT i2c aliases

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

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

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

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

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

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

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

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

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

[BISECTED] OMAP: DSS: clk rate mismatch

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, 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

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

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

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

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

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

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