Hi,
Long story short: we shouldn't send buffers that are not page-aligned for MMU
fault recovery.
For more information, see:
http://thread.gmane.org/gmane.linux.ports.arm.omap/33926/focus=34207
v2: Incuding comments from Fernando Lugo to keep stack dump functionality
Felipe Contreras (1):
The DSP might misbehave and write to the dummy memory. So let's make
sure that nobody else is using the pages related to it by grabbing a
full page.
Based on the analysis of Deepak Chitriki.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/ue_deh.c | 11
Hi,
A few trivial patches. The important one is the fix to build when MCBSP is
disabled.
Felipe Contreras (4):
dspbridge: fix build when OMAP_MCBSP=n
dspbridge: dev: fix dev_create_device()
dspbridge: remove _tiomap_mmu.h
dspbridge: remove _tiomap_util.h
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/dsp-clock.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/core/dsp-clock.c
b/drivers/dsp/bridge/core/dsp-clock.c
index 3683dc3..7df100a 100644
---
... when resources are not available.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/pmgr/dev.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/dev.c b/drivers/dsp/bridge/pmgr/dev.c
index
Not used, only in bridge_brd_start(), so refactor that code.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/_tiomap_mmu.h | 41
drivers/dsp/bridge/core/mmu_fault.c |1 -
drivers/dsp/bridge/core/tiomap3430.c | 84
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/_tiomap_util.h | 43 --
drivers/dsp/bridge/core/tiomap3430.c |5 +++-
drivers/dsp/bridge/core/tiomap3430_pwr.c |3 +-
3 files changed, 6 insertions(+), 45
Hi,
Investigating the MMU fault corruption issue I found a lot of areas of
improvements of the exception handling code.
Moreover, even though the obvious memory corruption is fixed on kernel side,
there are still some rare cases where corruption in user-space might be
possible if some buffers
Self-documenting code is better.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/ue_deh.c | 65 +++--
1 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/dsp/bridge/core/ue_deh.c
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/ue_deh.c | 112 ++
1 files changed, 41 insertions(+), 71 deletions(-)
diff --git a/drivers/dsp/bridge/core/ue_deh.c
There's no need to keep it around. DSP should stop trying to access
system memory.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/ue_deh.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/core/ue_deh.c
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dspdeh.h |1 -
drivers/dsp/bridge/core/_tiomap.h |6 +-
drivers/dsp/bridge/core/tiomap3430.c |2 --
drivers/dsp/bridge/core/ue_deh.c | 17
So that it can be used in more than one place.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/tiomap3430.c |9 +
drivers/dsp/bridge/hw/hw_mmu.c |6 ++
drivers/dsp/bridge/hw/hw_mmu.h |2 ++
3 files changed, 9
We don't want the DSP to continue writing into other mapped pages, no
matter how unlikely.
Based on extensive discussion with Fernando Guzman Lugo.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/ue_deh.c |8
1 files changed, 8 insertions(+),
All this code is just to print the stack, so make it clearer.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/core/ue_deh.c | 58 +-
1 files changed, 32 insertions(+), 26 deletions(-)
diff --git
Nobody is using it.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dspdefs.h | 19 ---
arch/arm/plat-omap/include/dspbridge/dspdeh.h |3 ---
drivers/dsp/bridge/core/tiomap3430.c |1 -
We only use it to pass the MMU fault address.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dbdefs.h |1 -
drivers/dsp/bridge/core/_deh.h|2 +-
drivers/dsp/bridge/core/mmu_fault.c | 11 +--
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dspdefs.h | 56
drivers/dsp/bridge/core/tiomap3430.c |5 --
drivers/dsp/bridge/pmgr/dev.c | 15 +-
drivers/dsp/bridge/rmgr/node.c
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/Makefile |2 +-
drivers/dsp/bridge/core/mmu_fault.c | 100 ---
drivers/dsp/bridge/core/mmu_fault.h | 34
drivers/dsp/bridge/core/ue_deh.c| 50
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dspdeh.h | 15 +--
drivers/dsp/bridge/core/_deh.h|1 -
drivers/dsp/bridge/core/ue_deh.c | 163 +++--
3 files changed, 77 insertions(+), 102
Add myself... git blame seems to agree :)
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dspdeh.h |1 +
drivers/dsp/bridge/core/_deh.h|1 +
drivers/dsp/bridge/core/ue_deh.c |1 +
3 files changed, 3
Hi,
The current Kconfig really needed some attention. I have tried to standarize
everything to CONFIG_OMAP_DSP, unfortunately, it seems the dspgateway was using
that. Since that was never mainlined, I removed the dead code that was relying
on it (should move to the dspgateway branch). Besides
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/devices.c | 62 --
1 files changed, 0 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/dspbridge.c |6 ++--
arch/arm/mach-omap2/omap3-iommu.c |2 +-
arch/arm/plat-omap/devices.c|4
Obviously nobody was using DSP_TRACEBUF_DISABLED, since it wasn't even
standarized between TRACEBUF and TRACE_BUF.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/io_sm.h |2 +-
drivers/dsp/bridge/core/io_sm.c | 16
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/Kconfig | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/dsp/bridge/Kconfig b/drivers/dsp/bridge/Kconfig
index 75c1a1c..b2af858 100644
---
We only want this code when testing.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/dbll.h |2 ++
arch/arm/plat-omap/include/dspbridge/gh.h|2 ++
arch/arm/plat-omap/include/dspbridge/io_sm.h |4 +++-
On Sat, May 15, 2010 at 12:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, May 15, 2010 at 11:26 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, May 14, 2010 at 10:49 PM, Omar Ramirez Luna omar.rami...@ti.com
wrote:
On 5/14/2010 2:27 PM, Felipe Contreras
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I spent some time looking deeper into this patch series, and I have some
doubts.
On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Basically you're right, but the patches currently
Here's some of the healthcare lists we have:
Veterinarians - 78,986 total records with 1,438 emails and 1,050 fax numbers
National Health Service Corp Clinics - 1,300 total records with emails for
government run free clinics
Medical Equipment Suppliers - 167,425 total records with 6,940 emails
Hi,
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 10:46 AM
To: linux-omap
Cc: Ramirez Luna, Omar; Guzman Lugo, Fernando; Felipe Contreras
Subject: [PATCH 02/14] dspbridge: deh: trivial cleanups
No functional changes.
On Mon, May 17, 2010 at 1:02 AM, Guzman Lugo, Fernando
fernando.l...@ti.com wrote:
+ for (c = 0; c GPTIMER_IRQ_WAIT_MAX_CNT; c++)
+ if ((omap_dm_timer_read_status(timer) GPTIMER_IRQ_OVERFLOW))
+ return;
+
+ pr_err(%s: GPTimer interrupt failed\n,
Hi Felipe,
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
I spent some time looking deeper into this patch series, and I have some
doubts.
On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Sun, May 2, 2010 at 4:17 PM, Felipe
Hi Felipe,
On Sun, May 16, 2010 at 8:35 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I spent some time looking deeper into this patch series, and I have some
doubts.
On Sun, May 2, 2010 at 8:47
Hi Felipe,
On Sat, May 15, 2010 at 11:34 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Every time the MM application calls proc_map to map
a memory area, remember the details of that mapping,
together with the
Hi Felipe,
On Sat, May 15, 2010 at 11:38 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Clean up all mapping information resources whenever
a buffer is unmapped.
If I understand correctly the previous patch
Hi Ohad,
On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c)
and I don't understand what dma_unmap_sg is supposed to
On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi Ohad,
On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I looked into the dma code (I guess it's in
On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi Ohad,
On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I looked into the dma code (I guess it's in
Hello,
On Mon, May 17, 2010 at 1:57 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Sun, May 16, 2010 at 8:35 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Now I understand better; arch/arm/mm/dma-mapping.c will not be used
unless CONFIG_DMABOUNCE=y, which is not the case for OMAP3.
On Mon, May 17, 2010 at 2:25 AM, Ohad Ben-Cohen o...@wizery.com wrote:
Out of curiosity, what board/environment do you use to play with
the code ? I'd like to run the same use cases you do, so I can
reproduce any issue you may bump into.
I use a beagleboard, use the DSP firmware in
I was observing the following error messages on my OMAP1 based Amstrad Delta
board when first changing from text to graphics mode or vice versa after the
LCD display had been blanked:
omapfb omapfb: timeout waiting for FRAME DONE
with a followup error message while unblanking it back:
Hi,
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Sunday, May 16, 2010 5:13 PM
To: Guzman Lugo, Fernando
Cc: linux-omap; Ramirez Luna, Omar
Subject: Re: [PATCH 02/14] dspbridge: deh: trivial cleanups
On Mon, May 17, 2010 at 1:02 AM, Guzman
On Sat, 2010-05-15 at 22:14 +0200, Rafael J. Wysocki wrote:
On Saturday 15 May 2010, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Friday 14 May 2010, Kevin Hilman wrote:
If it truly is the lack of a suspend blocker API that is preventing
the merge of these out of tree
Vimal,
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: 2010-05-14 23:33
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; artem.bityuts...@nokia.com;
t...@atomide.com; sako...@gmail.com; linux-...@lists.infradead.org
Subject: Re: [PATCH v2 1/2] omap3
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: 2010-05-15 05:29
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
sako...@gmail.com; m...@compulab.co.il; artem.bityuts...@nokia.com
Subject: Re: [PATCH v2 1/2] omap3
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Friday, May 14, 2010 6:32 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; linux-fb...@vger.kernel.org;
t...@atomide.com; Hiremath, Vaibhav
Subject: RE: [PATCH v2 0/2] DSS2:Allow FB
47 matches
Mail list logo
