RE: [PATCH v1 0/2] mtd: nand: omap: booting from NAND using u-boot
Hello Enric, Nikita, and other OMAP3 users,
>
>As there were parallel set of patches running between u-boot and kernel.
>hence, some patch-sets caused regression for OMAP3x platforms when booting
>using u-boot specifically for ecc-schemes (like BCH4_SW).
>
>Hence this patch series fixes those regressions, and tests complete
>NAND boot sequence for multiple ecc-schemes on AM335x-EVM board.
>(following configurations are required for building u-boot driver which is
> compatible to kernel ecclayout for selected ecc-scheme)
>
>
>(BCH8_HW) (HAM1_HW) (HAM1_HW) (HAM1_HW) (UBIFS)
>ROM -> SPL -> U-Boot -> Kernel -> File-System
>
>(BCH8_HW) (BCH8_SW) (BCH8_SW) (BCH8_SW) (UBIFS)
>ROM -> SPL -> U-Boot -> Kernel -> File-System
>
>(BCH8_HW) (BCH8_HW) (BCH8_HW) (BCH8_HW) (UBIFS)
>ROM -> SPL -> U-Boot -> Kernel -> File-System
>
>*Configurations used to build u-boot and kernel for end-to-end NAND boot*
>+++--+
>| ecc-scheme | u-boot/SPL configs| kernel DTS |
>+++--+
>||| |
>| HAM1_HW| #define CONFIG_NAND_OMAP_ECCSCHEME \ |ti,nand-ecc-opts= |
>|| OMAP_ECC_HAM1_CODE_HW |"ham1"|
>| (1-bit | #define CONFIG_SYS_NAND_ECCBYTES 3 | |
>| Hamming| #define CONFIG_SYS_NAND_ECCPOS \ | |
>| using h/w) | { 1, 2, 3, 4, 5, 6, 7, 8, 9, \| |
>||10, 11, 12 }| |
>|| (for NAND page-size=2048) | |
>||| |
>+++--+
>||| |
>| BCH8_SW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
>|| OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |"bch8"|
>|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 13 |(without ELM node)|
>| using s/w | #define CONFIG_BCH | |
>|library for | #undef CONFIG_SPL_NAND_AM33XX_BCH | |
>|for ECC | #define CONFIG_SPL_NAND_SIMPLE | |
>| error | #define CONFIG_SYS_NAND_ECCPOS \ | |
>|correction) | {2, 3, 4, 5, 6, 7, 8, 9, 10, \ | |
>|| 11, 12, 13, 14, \ | |
>|| 16, 17, 18, 19, 20, 21, 22, 23, 24, \ | |
>|| 25, 26, 27, 28, \ | |
>|| 30, 31, 32, 33, 34, 35, 36, 37, 38, \ | |
>|| 39, 40, 41, 42, \ | |
>|| 44, 45, 46, 47, 48, 49, 50, 51, 52, \ | |
>|| 53, 54, 55, 56, } | |
>|| (for NAND page-size=2048) | |
>|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
>||| |
>+++--+
>||| |
>| BCH8_HW| #define CONFIG_NAND_OMAP_ECCSCHEME\|ti,nand-ecc-opts= |
>|| OMAP_ECC_BCH8_CODE_HW |"bch8"|
>|(8-bit BCH | #define CONFIG_SYS_NAND_ECCBYTES 14 | |
>| using ELM | #define CONFIG_SPL_NAND_AM33XX_BCH |(with ELM node) |
>| h/w engine | #define CONFIG_SYS_NAND_ECCPOS \ |ti,elm-id=<&elm> |
>|for ECC | {2, 3, 4, 5, 6, 7, 8, 9, \| |
>| error | 10, 11, 12, 13, 14, 15, 16, 17, \| |
>|correction) | 18, 19, 20, 21, 22, 23, 24, 25, \| |
>|| 26, 27, 28, 29, 30, 31, 32, 33, \| |
>|| 34, 35, 36, 37, 38, 39, 40, 41, \| |
>|| 42, 43, 44, 45, 46, 47, 48, 49, \| |
>|| 50, 51, 52, 53, 54, 55, 56, 57, }| |
>|| (for NAND page-size=2048) | |
>|| #define CONFIG_SYS_NAND_ECCSIZE 512 | |
>||| |
>+---
RE: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
> -Original Message- > From: bhupesh.sha...@freescale.com > [mailto:bhupesh.sha...@freescale.com] > Sent: Monday, January 06, 2014 11:02 AM > To: Hiremath, Vaibhav; 'linux-arm-ker...@lists.infradead.org' > Cc: 'Tony Lindgren'; 'linux-omap@vger.kernel.org'; 'Russell King' > Subject: RE: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure > communication use-cases > > > -Original Message- > > From: linux-arm-kernel [mailto:linux-arm-kernel- > > boun...@lists.infradead.org] On Behalf Of Hiremath, Vaibhav > > Sent: Monday, January 06, 2014 10:39 AM > > To: linux-arm-ker...@lists.infradead.org > > Cc: Tony Lindgren; linux-omap@vger.kernel.org; Russell King > > Subject: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure > > communication use-cases > > > > Hi, > > > > Currently the Software Generated Interrupts (SGI) are restricted to > > use only for SMP architecture for inter-processor communication as > > rightly documented in ARM GIC spec V1. > > > > In the system with the uniprocessor (and/or multiprocessor variants) > > architecture with TRUSTZONE enabled device (like, AM43xx device), the > > SGI can be used for communication between secure-to-nonsecure world. > > And in order to enable SGI event from secure world to non-secure > > world, GIC driver __must__ support registration of interrupt service > > routines for SGI's; which is currently restricted by GIC driver. > > I am not an expert on this, but as per my understanding the model > recommended by ARM is the use of IRQ as a Normal world interrupt source, and > FIQ as the Secure world source. > [Hiremath, Vaibhav] Absolutely and I also follow same recommendation here. > If IRQ is received by the Secure world, it should cause a hardware trap to the > monitor and the monitor mode should cause a context switch and jumps to the > normal world, where the interrupt handler should execute (see reference [1]). > I think I missed to explicitly talk about FIQ in the RFC, sorry for the confusion. Yes, IRQ received by secure world should cause HW trap to monitor mode and Further should cause context switch to public world to handle the interrupt. And this RFC wants to leverage this, where, any operations on secure world, - Functional operation (entered through monitor mode) which want to pass on the event to public world - Any FIQ (secure interrupts) wants to pass on certain events or information to Public world - It could be any secure peripheral interrupt causing FIQ Secure world can use IRQ, which is generated by software to pass on the event information to public world. Please note that, the SGI is non-secure, so if you raise and SGI from secure world it will follow the execution mentioned above. So this RFC enables asynchronous communication channel between secure world to Non-secure world using SGI. > For making a transition from the secure world to the normal world and vice- > versa, the core should transition via the monitor mode. Assuming a > Uniprocessor system running both Normal and Secure world - thus providing a > view of two virtual processors running in a time-sliced fashion, the world in > which the processor is executing should be indicated by the NS-bit in the > Secure > Configuration Register (SCR) in CP15. The IRQ, FIQ, Abort exceptions can all > be > configured to cause the processor to switch into monitor mode. > > The software that executes within monitor mode is implementation defined, but > it generally saves the state of the current world and restores the state of > the > world being switched to. > It then performs a return-from-exception to restart processing in the restored > world. (see reference [2]). > > Does this RFC implementation take into account the monitor mode switch while > switching/passing information b/w the two worlds? > Yes, as recommended by ARM, this RFC is also based on the recommendation, where, monitor mode is responsible for saving and restoring contexts. RFC doesn't handle the monitor mode implementation which lacks context save/restore. Please let me know if you still have any confusion on the usecase and on this RFC Thanks, Vaibhav -- 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] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Hiremath, Vaibhav
> Sent: Monday, January 06, 2014 10:39 AM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tony Lindgren; linux-omap@vger.kernel.org; Russell King
> Subject: [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure
> communication use-cases
>
> Hi,
>
> Currently the Software Generated Interrupts (SGI) are restricted to use
> only for SMP architecture for inter-processor communication as rightly
> documented in ARM GIC spec V1.
>
> In the system with the uniprocessor (and/or multiprocessor variants)
> architecture with TRUSTZONE enabled device (like, AM43xx device), the SGI
> can be used for communication between secure-to-nonsecure world.
> And in order to enable SGI event from secure world to non-secure world,
> GIC driver __must__ support registration of interrupt service routines
> for SGI's; which is currently restricted by GIC driver.
I am not an expert on this, but as per my understanding the model recommended
by ARM is the use of IRQ as
a Normal world interrupt source, and FIQ as the Secure world source.
If IRQ is received by the Secure world, it should cause a hardware trap to the
monitor and the monitor
mode should cause a context switch and jumps to the normal world, where the
interrupt handler should execute
(see reference [1]).
For making a transition from the secure world to the normal world and
vice-versa, the core should transition
via the monitor mode. Assuming a Uniprocessor system running both Normal and
Secure world - thus providing a
view of two virtual processors running in a time-sliced fashion, the world in
which the processor is executing
should be indicated by the NS-bit in the Secure Configuration Register (SCR) in
CP15. The IRQ, FIQ, Abort exceptions
can all be configured to cause the processor to switch into monitor mode.
The software that executes within monitor mode is implementation defined, but
it generally saves the state of the
current world and restores the state of the world being switched to.
It then performs a return-from-exception to restart processing in the restored
world. (see reference [2]).
Does this RFC implementation take into account the monitor mode switch while
switching/passing information b/w
the two worlds?
[1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/CACCDCDH.html
[2]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/ch03s03s01.html
Regards,
Bhupesh
> The usecase is something like,
>
> On any asynchronous HW or SW events, certain secure functionality gets
> triggered and SGI will be used to notify to the public world on the
> completion and/or result of operation.
>
> Non Secure | Secure (TrustZone)
> (Linux Booted | (Secure software init happed
>To prompt) | and trusted code getting executed)
> |
> (On any secure operation Where we would
> like public world communication)
> |
> | - Use SGI to trigger event to
> public Linux code
> | - And share the public
> info/data with public world for further processing
> <=
> Public code |
> handles it|
>
> In order to prototype and to make sure that it works, I did change the
> GIC driver to allow registration of SGI interrupts (interrupts 0 - 16)
> and tried it on AM43xx EVM and pasted the diff of the changes below.
> I have also validated using SGI for secure to non-secure communication.
>
> The idea behind this RFC (or rather query) is, to get feedback or
> comments on the use-case of using SGI for secure-to-nonsecure
> communication on non-SMP architecture or SMP architecture with
> uniprocessor.
> I understand that, lot of things I need to take care from SMP
> architecture perspective.
> Based on the feedback I can spend more time to make below changes more
> generic to handle both uniprocessor and multi-processor architectures
> including more validation.
>
> Also, please note that, this requires change in all the DT files using
> GIC interrupt controller.
>
> Any pointers and suggestions are welcome here.
>
> Thanks,
> Vaibhav
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index
> d0e9480..135385a 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -290,7 +290,7 @@ static asmlinkage void __exception_irq_entry
> gic_handle_irq(struct pt_regs *regs
> irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
> irqnr = irqstat & ~0x1c00;
>
> - if (likely(irqnr > 15 && irqnr < 1021)) {
> + if (likely(irqnr >= 0 && irqnr < 1021)) {
> irqnr = irq_find_mapping(gic->domain, irqnr);
>
[RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
Hi,
Currently the Software Generated Interrupts (SGI) are restricted to use only
for SMP architecture for inter-processor communication as rightly documented
in ARM GIC spec V1.
In the system with the uniprocessor (and/or multiprocessor variants)
architecture with
TRUSTZONE enabled device (like, AM43xx device), the SGI can be used for
communication between secure-to-nonsecure world.
And in order to enable SGI event from secure world to non-secure world,
GIC driver __must__ support registration of interrupt service routines for
SGI's;
which is currently restricted by GIC driver.
The usecase is something like,
On any asynchronous HW or SW events, certain secure functionality gets
triggered
and SGI will be used to notify to the public world on the completion and/or
result of operation.
Non Secure | Secure (TrustZone)
(Linux Booted | (Secure software init happed
To prompt) | and trusted code getting executed)
|
(On any secure operation Where we would
like public world communication)
|
| - Use SGI to trigger event to public
Linux code
| - And share the public info/data with
public world for further processing
<=
Public code |
handles it|
In order to prototype and to make sure that it works,
I did change the GIC driver to allow registration of SGI interrupts (interrupts
0 - 16) and
tried it on AM43xx EVM and pasted the diff of the changes below.
I have also validated using SGI for secure to non-secure communication.
The idea behind this RFC (or rather query) is, to get feedback or
comments on the use-case of using SGI for secure-to-nonsecure communication
on non-SMP architecture or SMP architecture with uniprocessor.
I understand that, lot of things I need to take care from SMP architecture
perspective.
Based on the feedback I can spend more time to make below changes more generic
to handle
both uniprocessor and multi-processor architectures including more validation.
Also, please note that, this requires change in all the DT files using GIC
interrupt controller.
Any pointers and suggestions are welcome here.
Thanks,
Vaibhav
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d0e9480..135385a 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -290,7 +290,7 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
irqnr = irqstat & ~0x1c00;
- if (likely(irqnr > 15 && irqnr < 1021)) {
+ if (likely(irqnr >= 0 && irqnr < 1021)) {
irqnr = irq_find_mapping(gic->domain, irqnr);
handle_IRQ(irqnr, regs);
continue;
@@ -324,7 +324,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct
irq_desc *desc)
goto out;
cascade_irq = irq_find_mapping(chip_data->domain, gic_irq);
- if (unlikely(gic_irq < 32 || gic_irq > 1020))
+ if (unlikely(gic_irq > 1020))
handle_bad_irq(cascade_irq, desc);
else
generic_handle_irq(cascade_irq);
@@ -395,20 +395,20 @@ static void __init gic_dist_init(struct gic_chip_data
*gic)
cpumask = gic_get_cpumask(gic);
cpumask |= cpumask << 8;
cpumask |= cpumask << 16;
- for (i = 32; i < gic_irqs; i += 4)
+ for (i = 0; i < gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
/*
* Set priority on all global interrupts.
*/
- for (i = 32; i < gic_irqs; i += 4)
+ for (i = 0; i < gic_irqs; i += 4)
writel_relaxed(0xa0a0a0a0, base + GIC_DIST_PRI + i * 4 / 4);
/*
* Disable all interrupts. Leave the PPI and SGIs alone
* as these enables are banked registers.
*/
- for (i = 32; i < gic_irqs; i += 32)
+ for (i = 0; i < gic_irqs; i += 32)
writel_relaxed(0x, base + GIC_DIST_ENABLE_CLEAR + i * 4
/ 32);
writel_relaxed(1, base + GIC_DIST_CTRL);
@@ -672,7 +672,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned
int irq)
static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- if (hw < 32) {
+ if (hw < 0) {
irq_set_percpu_devid(irq);
irq_set_chip_and_handler(irq, &gic_chip,
handle_percpu_devid_irq);
@@ -696,8 +696,11 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
if (intsize < 3)
return -EINVAL;
-/* Get the interrupt number and add 16 to skip over SGIs */
-
Problems with double, qreal and float porting an application - Help please!
System is an ODROID-X.
root@odroid:/1/cuSDR32# uname -a
Linux odroid 3.8.13.14 #1 SMP PREEMPT Sat Dec 21 22:14:31 UTC 2013
armv7l armv7l armv7l GNU/Linux
root@odroid:/1/cuSDR32# cat /etc/os-release
NAME="Ubuntu"
VERSION="13.10, Saucy Salamander"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 13.10"
VERSION_ID="13.10"
HOME_URL="http://www.ubuntu.com/";
SUPPORT_URL="http://help.ubuntu.com/";
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
The failures and the offending lines below.
---
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_MULTIMEDIA_LIB
-DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtMultimedia
-I/usr/include/qt4 -I/usr/include/QtMultimediaKit
-I/usr/include/QtMobility -I. -Isrc -Isrc/AudioEngine -Isrc/CL
-Isrc/DataEngine -Isrc/GL -Isrc/QtDSP -Isrc/Util -I/usr/X11R6/include
-Ibld/moc -o bld/o/qtdsp_wpagc.o src/QtDSP/qtdsp_wpagc.cpp
src/QtDSP/qtdsp_wpagc.cpp: In member function ‘void
QWPAGC::ProcessAGC(CPX&, CPX&, int)’:
src/QtDSP/qtdsp_wpagc.cpp:290:88: error: no matching function for call
to ‘qMin(double, float)’
mult = (m_out_target - m_slope_constant * qMin(0.0, log10
(m_inv_max_input * m_volts))) / m_volts;
^
src/QtDSP/qtdsp_wpagc.cpp:290:88: note: candidate is:
In file included from /usr/include/qt4/QtCore/qiterator.h:45:0,
from /usr/include/qt4/QtCore/qvector.h:45,
from /usr/include/qt4/QtCore/QVector:1,
from src/QtDSP/qtdsp_qComplex.h:34,
from src/QtDSP/qtdsp_wpagc.h:36,
from src/QtDSP/qtdsp_wpagc.cpp:34:
/usr/include/qt4/QtCore/qglobal.h:1213:34: note: template const
T& qMin(const T&, const T&)
Q_DECL_CONSTEXPR inline const T &qMin(const T &a, const T &b) { return
(a < b) ? a : b; }
^
/usr/include/qt4/QtCore/qglobal.h:1213:34: note: template argument
deduction/substitution failed:
src/QtDSP/qtdsp_wpagc.cpp:290:88: note: deduced conflicting types for
parameter ‘const T’ (‘double’ and ‘float’)
mult = (m_out_target - m_slope_constant * qMin(0.0, log10
(m_inv_max_input * m_volts))) / m_volts;
^
src/QtDSP/qtdsp_wpagc.cpp: In member function ‘void
QWPAGC::setHangLevelDb(qreal)’:
src/QtDSP/qtdsp_wpagc.cpp:588:78: error: no matching function for call
to ‘qMax(double, qreal)’
qreal tmp = qMax(1.0e-8, (convert - m_minVolts) / (m_maxInput -
m_minVolts));
^
src/QtDSP/qtdsp_wpagc.cpp:588:78: note: candidate is:
In file included from /usr/include/qt4/QtCore/qiterator.h:45:0,
from /usr/include/qt4/QtCore/qvector.h:45,
from /usr/include/qt4/QtCore/QVector:1,
from src/QtDSP/qtdsp_qComplex.h:34,
from src/QtDSP/qtdsp_wpagc.h:36,
from src/QtDSP/qtdsp_wpagc.cpp:34:
/usr/include/qt4/QtCore/qglobal.h:1215:34: note: template const
T& qMax(const T&, const T&)
Q_DECL_CONSTEXPR inline const T &qMax(const T &a, const T &b) { return
(a < b) ? b : a; }
^
/usr/include/qt4/QtCore/qglobal.h:1215:34: note: template argument
deduction/substitution failed:
src/QtDSP/qtdsp_wpagc.cpp:588:78: note: deduced conflicting types for
parameter ‘const T’ (‘double’ and ‘qreal {aka float}’)
qreal tmp = qMax(1.0e-8, (convert - m_minVolts) / (m_maxInput -
m_minVolts));
^
make: *** [bld/o/qtdsp_wpagc.o] Error 1
root@odroid:/1/cuSDR32#
svn co http://svn.tapr.org/repos_sdr_hpsdr/trunk/DL3HVH/cuSDR32/ for the
source.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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
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 Cc: Ivaylo Dimitrov --- 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 v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov
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
---
.../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] 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 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 Reviewed-by: Pavel Machek 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
