* Re: Power Management issues in MPC8313 processor
From: Srivatsan Canchivaram @ 2012-10-28 0:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <1351297672.23094.13@snotra>
[-- Attachment #1: Type: text/plain, Size: 3596 bytes --]
Hello Scott,
I am using 2.6.27 - I am trying to add Power Management support to an older
product.
Thanks,
Srivatsan
On Fri, Oct 26, 2012 at 8:27 PM, Scott Wood <scottwood@freescale.com> wrote:
> On 10/25/2012 05:07:01 PM, Srivatsan Canchivaram wrote:
>
>> Hi,
>>
>>
>> I have a modem with a Freescale MPC8313E processor. I am trying to enable
>> power savings in the processor by placing it in Standby mode and resume
>> normal operation with a Wake-On-LAN magic packet.
>>
>>
>> Following the directions in the Freescale Power Management app note, I
>> enabled Power Management Support in the Linux kernel and device tree
>> configurations.
>>
>>
>> I ran the following command on the board:
>>
>> echo standby > /sys/power/state
>>
>>
>> This caused the console to hang and there was no further response to
>> keyboard inputs. I enabled ‘no_console_suspend’ in the kernel and when I
>> loaded the new build and enabled standby mode, I observed an Oops trace:
>>
>>
>>
>> RASCOM_QCU.7.0.0013 $ echo standby > /sys/power/state
>>
>> <6>PM: Syncing fFreezing user space processes ... ilesystems ... <7>PM:
>> Entering standby sleep
>>
>> Unable to handle kernel paging request for instruction fetch
>>
>> Faulting instruction address: 0x616d6570
>>
>> Oops: Kernel access of bad area, sig: 11 [#1]
>>
>> MPC831x RDB
>>
>> Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last
>> unloaded: modem]
>>
>> NIP: 616d6570 LR: c0165224 CTR: 616d6573
>>
>> REGS: cd087d30 TRAP: 0400 Not tainted (2.6.27)
>>
>> MSR: 20001032 <ME,IR,DR> CR: 28002024 XER: 20000000
>>
>> TASK = cc312400[1196] 'echo' THREAD: cd086000
>>
>> GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
>> c06da4a0
>>
>> GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
>> 100050b8
>>
>> GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
>> c0246180
>>
>> GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
>> cf821808
>>
>> NIP [616d6570] 0x616d6570
>>
>> LR [c0165224] platform_pm_suspend_noirq+**0x84/0x88
>>
>
> What kernel are you using? platform_pm_suspend_noirq was removed by this
> commit:
>
> commit 9b39e73d0c2b265a7f8748b0e9a9f0**9be84079a8
> Author: Rafael J. Wysocki <rjw@sisk.pl>
> Date: Sun Dec 18 00:34:24 2011 +0100
>
> PM / Sleep: Remove forward-only callbacks from platform bus type
>
> The forward-only PM callbacks provided by the platform bus type are
> not necessary any more, because the PM core executes driver callbacks
> when the corresponding subsystem callbacks are not present, so drop
> them.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
>
> It seems that a driver's pm ops are getting corrupted -- maybe used after
> freeing? Have you tried enabling slab/slub debug?
>
> Can you instrument the code to see if there are any fields in the device
> struct that aren't corrupt, that could point out which device this is?
>
>
> I found another thread that dealt with Power Management issues on the
>> Freescale MPC8313 processor:
>>
>> https://lists.ozlabs.org/**pipermail/linuxppc-dev/2012-**
>> January/095240.html<https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-January/095240.html>
>>
>> The resolution of this issue seems to be related to the JTAG TRST pin
>> being
>> disabled. This is not relevant in my case as the TRST on my board is
>> already inactive.
>>
>
> If you were seeing that, you'd see a hang rather than an oops.
>
> -Scott
>
[-- Attachment #2: Type: text/html, Size: 4590 bytes --]
^ permalink raw reply
* [PATCH] PPC: ePAPR: Convert header to uapi
From: Alexander Graf @ 2012-10-27 17:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Timur Tabi, linux-kernel@vger.kernel.org List, kvm-ppc,
David Howells
The new uapi framework splits kernel internal and user space exported
bits of header files more cleanly. Adjust the ePAPR header accordingly.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/Kbuild | 1 -
arch/powerpc/include/asm/epapr_hcalls.h | 56 +--------------
arch/powerpc/include/uapi/asm/Kbuild | 1 +
arch/powerpc/include/uapi/asm/epapr_hcalls.h | 98 ++++++++++++++++++++++++++
4 files changed, 100 insertions(+), 56 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/epapr_hcalls.h
diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
index 13d6b7b..7e313f1 100644
--- a/arch/powerpc/include/asm/Kbuild
+++ b/arch/powerpc/include/asm/Kbuild
@@ -34,6 +34,5 @@ header-y += termios.h
header-y += types.h
header-y += ucontext.h
header-y += unistd.h
-header-y += epapr_hcalls.h
generic-y += rwsem.h
diff --git a/arch/powerpc/include/asm/epapr_hcalls.h b/arch/powerpc/include/asm/epapr_hcalls.h
index b8d9445..22defe7 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -50,65 +50,11 @@
#ifndef _EPAPR_HCALLS_H
#define _EPAPR_HCALLS_H
-#define EV_BYTE_CHANNEL_SEND 1
-#define EV_BYTE_CHANNEL_RECEIVE 2
-#define EV_BYTE_CHANNEL_POLL 3
-#define EV_INT_SET_CONFIG 4
-#define EV_INT_GET_CONFIG 5
-#define EV_INT_SET_MASK 6
-#define EV_INT_GET_MASK 7
-#define EV_INT_IACK 9
-#define EV_INT_EOI 10
-#define EV_INT_SEND_IPI 11
-#define EV_INT_SET_TASK_PRIORITY 12
-#define EV_INT_GET_TASK_PRIORITY 13
-#define EV_DOORBELL_SEND 14
-#define EV_MSGSND 15
-#define EV_IDLE 16
-
-/* vendor ID: epapr */
-#define EV_LOCAL_VENDOR_ID 0 /* for private use */
-#define EV_EPAPR_VENDOR_ID 1
-#define EV_FSL_VENDOR_ID 2 /* Freescale Semiconductor */
-#define EV_IBM_VENDOR_ID 3 /* IBM */
-#define EV_GHS_VENDOR_ID 4 /* Green Hills Software */
-#define EV_ENEA_VENDOR_ID 5 /* Enea */
-#define EV_WR_VENDOR_ID 6 /* Wind River Systems */
-#define EV_AMCC_VENDOR_ID 7 /* Applied Micro Circuits */
-#define EV_KVM_VENDOR_ID 42 /* KVM */
-
-/* The max number of bytes that a byte channel can send or receive per call */
-#define EV_BYTE_CHANNEL_MAX_BYTES 16
-
-
-#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
-#define EV_HCALL_TOKEN(hcall_num) _EV_HCALL_TOKEN(EV_EPAPR_VENDOR_ID, hcall_num)
-
-/* epapr return codes */
-#define EV_SUCCESS 0
-#define EV_EPERM 1 /* Operation not permitted */
-#define EV_ENOENT 2 /* Entry Not Found */
-#define EV_EIO 3 /* I/O error occured */
-#define EV_EAGAIN 4 /* The operation had insufficient
- * resources to complete and should be
- * retried
- */
-#define EV_ENOMEM 5 /* There was insufficient memory to
- * complete the operation */
-#define EV_EFAULT 6 /* Bad guest address */
-#define EV_ENODEV 7 /* No such device */
-#define EV_EINVAL 8 /* An argument supplied to the hcall
- was out of range or invalid */
-#define EV_INTERNAL 9 /* An internal error occured */
-#define EV_CONFIG 10 /* A configuration error was detected */
-#define EV_INVALID_STATE 11 /* The object is in an invalid state */
-#define EV_UNIMPLEMENTED 12 /* Unimplemented hypercall */
-#define EV_BUFFER_OVERFLOW 13 /* Caller-supplied buffer too small */
-
#ifndef __ASSEMBLY__
#include <linux/types.h>
#include <linux/errno.h>
#include <asm/byteorder.h>
+#include <uapi/asm/epapr_hcalls.h>
/*
* Hypercall register clobber list
diff --git a/arch/powerpc/include/uapi/asm/Kbuild b/arch/powerpc/include/uapi/asm/Kbuild
index baebb3d..e6b5be8 100644
--- a/arch/powerpc/include/uapi/asm/Kbuild
+++ b/arch/powerpc/include/uapi/asm/Kbuild
@@ -1,3 +1,4 @@
# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm
+header-y += epapr_hcalls.h
diff --git a/arch/powerpc/include/uapi/asm/epapr_hcalls.h b/arch/powerpc/include/uapi/asm/epapr_hcalls.h
new file mode 100644
index 0000000..046c793
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/epapr_hcalls.h
@@ -0,0 +1,98 @@
+/*
+ * ePAPR hcall interface
+ *
+ * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ *
+ * Author: Timur Tabi <timur@freescale.com>
+ *
+ * This file is provided under a dual BSD/GPL license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _UAPI__EPAPR_HCALLS_H
+#define _UAPI__EPAPR_HCALLS_H
+
+#define EV_BYTE_CHANNEL_SEND 1
+#define EV_BYTE_CHANNEL_RECEIVE 2
+#define EV_BYTE_CHANNEL_POLL 3
+#define EV_INT_SET_CONFIG 4
+#define EV_INT_GET_CONFIG 5
+#define EV_INT_SET_MASK 6
+#define EV_INT_GET_MASK 7
+#define EV_INT_IACK 9
+#define EV_INT_EOI 10
+#define EV_INT_SEND_IPI 11
+#define EV_INT_SET_TASK_PRIORITY 12
+#define EV_INT_GET_TASK_PRIORITY 13
+#define EV_DOORBELL_SEND 14
+#define EV_MSGSND 15
+#define EV_IDLE 16
+
+/* vendor ID: epapr */
+#define EV_LOCAL_VENDOR_ID 0 /* for private use */
+#define EV_EPAPR_VENDOR_ID 1
+#define EV_FSL_VENDOR_ID 2 /* Freescale Semiconductor */
+#define EV_IBM_VENDOR_ID 3 /* IBM */
+#define EV_GHS_VENDOR_ID 4 /* Green Hills Software */
+#define EV_ENEA_VENDOR_ID 5 /* Enea */
+#define EV_WR_VENDOR_ID 6 /* Wind River Systems */
+#define EV_AMCC_VENDOR_ID 7 /* Applied Micro Circuits */
+#define EV_KVM_VENDOR_ID 42 /* KVM */
+
+/* The max number of bytes that a byte channel can send or receive per call */
+#define EV_BYTE_CHANNEL_MAX_BYTES 16
+
+
+#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
+#define EV_HCALL_TOKEN(hcall_num) _EV_HCALL_TOKEN(EV_EPAPR_VENDOR_ID, hcall_num)
+
+/* epapr return codes */
+#define EV_SUCCESS 0
+#define EV_EPERM 1 /* Operation not permitted */
+#define EV_ENOENT 2 /* Entry Not Found */
+#define EV_EIO 3 /* I/O error occured */
+#define EV_EAGAIN 4 /* The operation had insufficient
+ * resources to complete and should be
+ * retried
+ */
+#define EV_ENOMEM 5 /* There was insufficient memory to
+ * complete the operation */
+#define EV_EFAULT 6 /* Bad guest address */
+#define EV_ENODEV 7 /* No such device */
+#define EV_EINVAL 8 /* An argument supplied to the hcall
+ was out of range or invalid */
+#define EV_INTERNAL 9 /* An internal error occured */
+#define EV_CONFIG 10 /* A configuration error was detected */
+#define EV_INVALID_STATE 11 /* The object is in an invalid state */
+#define EV_UNIMPLEMENTED 12 /* Unimplemented hypercall */
+#define EV_BUFFER_OVERFLOW 13 /* Caller-supplied buffer too small */
+
+#endif /* _UAPI__EPAPR_HCALLS_H */
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/1] powerpc/book3e: store critical/machine/debug exception thread info
From: Tiejun Chen @ 2012-10-27 4:22 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
We need to store thread info to these exception thread info like something
we already did for PPC32.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
This patch is followed on my three patches I send recently:
[PATCH 1/3] powerpc/book3e: load critical/machine/debug exception stack
[PATCH 2/3] powerpc/book3e: support kgdb for kernel space
[PATCH 3/3] kgdb/kgdbts: support ppc64
Tiejun
arch/powerpc/kernel/exceptions-64e.S | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index c5564d4..4e7083e 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -91,10 +91,28 @@
#define SPRN_GDBELL_SRR0 SPRN_GSRR0
#define SPRN_GDBELL_SRR1 SPRN_GSRR1
+/* Store something to exception thread info */
+#define BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(type) \
+ std r14,PACA_EX##type+EX_R14(r13); \
+ std r15,PACA_EX##type+EX_R15(r13); \
+ ld r14,PACA_EX##type+EX_R1(r13); \
+ clrrdi r14,r14,THREAD_SHIFT; \
+ clrrdi r15,r1,THREAD_SHIFT; \
+ ld r10,TI_FLAGS(r14); \
+ std r10,TI_FLAGS(r15); \
+ ld r10,TI_PREEMPT(r14); \
+ std r10,TI_PREEMPT(r1); \
+ ld r10,TI_TASK(r14); \
+ std r10,TI_TASK(r1); \
+ ld r14,PACA_EX##type+EX_R14(r13); \
+ ld r15,PACA_EX##type+EX_R15(r13); \
+1:
+
#define CRIT_SET_KSTACK \
BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT); \
ld r1,PACA_CRIT_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
+ BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(CRIT);
#define SPRN_CRIT_SRR0 SPRN_CSRR0
#define SPRN_CRIT_SRR1 SPRN_CSRR1
@@ -102,6 +120,7 @@
BOOK3E_LOAD_EXC_LEVEL_STACK(DBG); \
ld r1,PACA_DBG_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
+ BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(DBG);
#define SPRN_DBG_SRR0 SPRN_DSRR0
#define SPRN_DBG_SRR1 SPRN_DSRR1
@@ -109,6 +128,7 @@
BOOK3E_LOAD_EXC_LEVEL_STACK(MC); \
ld r1,PACA_MC_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
+ BOOK3E_STORE_EXC_LEVEL_THEAD_INFO(MC);
#define SPRN_MC_SRR0 SPRN_MCSRR0
#define SPRN_MC_SRR1 SPRN_MCSRR1
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] powerpc/esdhc: enable the card insert/remove interrupt
From: Anton Vorontsov @ 2012-10-27 1:12 UTC (permalink / raw)
To: Huang Changming-R66093
Cc: linuxppc-dev@lists.ozlabs.org, Chris Ball,
linux-mmc@vger.kernel.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C1DFBFB@039-SN1MPN1-004.039d.mgd.msft.net>
Hello Huang,
On Fri, Oct 26, 2012 at 02:42:36AM +0000, Huang Changming-R66093 wrote:
> For the current polling mode, driver will send CMD13 to poll the card status periodically , which will cause too many interrupts.
> Once I sent patches to detect the card when using polling mode last year: read the state register, instead of send CMD13. But, these patches were not accepted. Now I attach them for you.
Was there any specific reason why the patches didn't get accepted?
I very briefly looked at them, and they seem to be OK (there are a few
cosmetic details I'd comment on, tho -- but please send them in a normal
way (i.e. not as attachments).
Thanks,
Anton.
^ permalink raw reply
* Re: Power Management issues in MPC8313 processor
From: Scott Wood @ 2012-10-27 0:27 UTC (permalink / raw)
To: Srivatsan Canchivaram; +Cc: linuxppc-dev
In-Reply-To: <CAO_L5k-D2jMZaoxpxk_tu_=nT5T0PSSp_PUesh9gm-rNq0Qhcg@mail.gmail.com>
On 10/25/2012 05:07:01 PM, Srivatsan Canchivaram wrote:
> Hi,
>=20
>=20
> I have a modem with a Freescale MPC8313E processor. I am trying to =20
> enable
> power savings in the processor by placing it in Standby mode and =20
> resume
> normal operation with a Wake-On-LAN magic packet.
>=20
>=20
> Following the directions in the Freescale Power Management app note, I
> enabled Power Management Support in the Linux kernel and device tree
> configurations.
>=20
>=20
> I ran the following command on the board:
>=20
> echo standby > /sys/power/state
>=20
>=20
> This caused the console to hang and there was no further response to
> keyboard inputs. I enabled =E2=80=98no_console_suspend=E2=80=99 in the ke=
rnel and =20
> when I
> loaded the new build and enabled standby mode, I observed an Oops =20
> trace:
>=20
>=20
>=20
> RASCOM_QCU.7.0.0013 $ echo standby > /sys/power/state
>=20
> <6>PM: Syncing fFreezing user space processes ... ilesystems ... =20
> <7>PM:
> Entering standby sleep
>=20
> Unable to handle kernel paging request for instruction fetch
>=20
> Faulting instruction address: 0x616d6570
>=20
> Oops: Kernel access of bad area, sig: 11 [#1]
>=20
> MPC831x RDB
>=20
> Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon =20
> [last
> unloaded: modem]
>=20
> NIP: 616d6570 LR: c0165224 CTR: 616d6573
>=20
> REGS: cd087d30 TRAP: 0400 Not tainted (2.6.27)
>=20
> MSR: 20001032 <ME,IR,DR> CR: 28002024 XER: 20000000
>=20
> TASK =3D cc312400[1196] 'echo' THREAD: cd086000
>=20
> GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
> c06da4a0
>=20
> GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
> 100050b8
>=20
> GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
> c0246180
>=20
> GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
> cf821808
>=20
> NIP [616d6570] 0x616d6570
>=20
> LR [c0165224] platform_pm_suspend_noirq+0x84/0x88
What kernel are you using? platform_pm_suspend_noirq was removed by =20
this commit:
commit 9b39e73d0c2b265a7f8748b0e9a9f09be84079a8
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date: Sun Dec 18 00:34:24 2011 +0100
PM / Sleep: Remove forward-only callbacks from platform bus type
The forward-only PM callbacks provided by the platform bus type are
not necessary any more, because the PM core executes driver =20
callbacks
when the corresponding subsystem callbacks are not present, so drop
them.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
It seems that a driver's pm ops are getting corrupted -- maybe used =20
after freeing? Have you tried enabling slab/slub debug?
Can you instrument the code to see if there are any fields in the =20
device struct that aren't corrupt, that could point out which device =20
this is?
> I found another thread that dealt with Power Management issues on the
> Freescale MPC8313 processor:
>=20
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-January/095240.html
>=20
> The resolution of this issue seems to be related to the JTAG TRST pin =20
> being
> disabled. This is not relevant in my case as the TRST on my board is
> already inactive.
If you were seeing that, you'd see a hang rather than an oops.
-Scott=
^ permalink raw reply
* Re: [PATCH v2] powerpc: book3e: WSP: Add Chroma as a new WSP/PowerEN platform.
From: Scott Wood @ 2012-10-26 17:26 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <DD04A5E8-2850-4DDC-9E7A-B899B0EEEF11@pobox.com>
On Tue, Oct 11, 2011 at 09:47:36AM -0500, Jimi Xenidis wrote:
> On Tue Oct 4 05:02:41 EST 2011, Scott Wood wrote:
>
> Looking at your comments below, will the following be acceptable
>
> > On 09/29/2011 09:27 PM, Jimi Xenidis wrote:
> > > diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
> > > index ea2811c..a3eef8e 100644
> > > --- a/arch/powerpc/platforms/wsp/Kconfig
> > > +++ b/arch/powerpc/platforms/wsp/Kconfig
> > > @@ -1,6 +1,7 @@
> > > config PPC_WSP
> > > bool
> > > select PPC_A2
> > > + select GENERIC_TBSYNC
> > > select PPC_ICSWX
> > > select PPC_SCOM
> > > select PPC_XICS
> > > @@ -8,14 +9,20 @@ config PPC_WSP
> > > select PCI
> > > select PPC_IO_WORKAROUNDS if PCI
> > > select PPC_INDIRECT_PIO if PCI
> > > + select PPC_WSP_COPRO
> > > default n
> > >
> > > menu "WSP platform selection"
> > > depends on PPC_BOOK3E_64
>
> add "&& SMP"
>
> > >
> > > config PPC_PSR2
> > > - bool "PSR-2 platform"
> > > - select GENERIC_TBSYNC
> > > + bool "PowerEN System Reference Platform 2"
> > > + select EPAPR_BOOT
> > > + select PPC_WSP
> > > + default y
>
> Make these "default n"
>
> Will that address everything?
> -jx
Did a patch ever get submitted for this?
-Scott
^ permalink raw reply
* [PATCH RFT RESEND linux-next] powerpc: dma-mapping: support debug_dma_mapping_error
From: Shuah Khan @ 2012-10-26 16:08 UTC (permalink / raw)
To: benh, kyungmin.park, paulus, m.szyprowski, david, arnd, andrzej.p
Cc: linuxppc-dev, LKML, shuahkhan
In-Reply-To: <1351210584.6851.21.camel@lorien2>
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
---
arch/powerpc/include/asm/dma-mapping.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 7816087..e27e9ad 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -172,6 +172,7 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
+ debug_dma_mapping_error(dev, dma_addr);
if (dma_ops->mapping_error)
return dma_ops->mapping_error(dev, dma_addr);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc: mpc5200: Add a3m071 board support
From: Stefan Roese @ 2012-10-26 15:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin
This patch adds the MPC5200B based a3m071 board.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/boot/dts/a3m071.dts | 153 +++++++++++++++++++++++++++
arch/powerpc/platforms/52xx/mpc5200_simple.c | 1 +
2 files changed, 154 insertions(+)
create mode 100644 arch/powerpc/boot/dts/a3m071.dts
diff --git a/arch/powerpc/boot/dts/a3m071.dts b/arch/powerpc/boot/dts/a3m071.dts
new file mode 100644
index 0000000..46b30f2
--- /dev/null
+++ b/arch/powerpc/boot/dts/a3m071.dts
@@ -0,0 +1,153 @@
+/*
+ * a3m071 board Device Tree Source
+ *
+ * Copyright 2012 Stefan Roese <sr@denx.de>
+ *
+ * Copyright (C) 2011 DENX Software Engineering GmbH
+ * Heiko Schocher <hs@denx.de>
+ *
+ * Copyright (C) 2007 Semihalf
+ * Marian Balakowicz <m8@semihalf.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/include/ "mpc5200b.dtsi"
+
+/ {
+ model = "anonymous,a3m071";
+ compatible = "anonymous,a3m071";
+
+ soc5200@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc5200b-immr";
+ ranges = <0 0xf0000000 0x0000c000>;
+ reg = <0xf0000000 0x00000100>;
+ bus-frequency = <0>; /* From boot loader */
+ system-frequency = <0>; /* From boot loader */
+
+ cdm@200 {
+ fsl,init-ext-48mhz-en = <0x0>;
+ fsl,init-fd-enable = <0x01>;
+ fsl,init-fd-counters = <0x3333>;
+ };
+
+ timer@600 {
+ fsl,has-wdt;
+ };
+
+ spi@f00 {
+ status = "disabled";
+ };
+
+ usb: usb@1000 {
+ status = "disabled";
+ };
+
+ psc@2000 {
+ compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+ reg = <0x2000 0x100>;
+ interrupts = <2 1 0>;
+ };
+
+ psc@2200 {
+ status = "disabled";
+ };
+
+ psc@2400 {
+ status = "disabled";
+ };
+
+ psc@2600 {
+ status = "disabled";
+ };
+
+ psc@2800 {
+ status = "disabled";
+ };
+
+ psc@2c00 { // PSC6
+ compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+ reg = <0x2c00 0x100>;
+ interrupts = <2 4 0>;
+ };
+
+ ethernet@3000 {
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ phy0: ethernet-phy@3 {
+ reg = <0x03>;
+ };
+ };
+
+ ata@3a00 {
+ status = "disabled";
+ };
+
+ i2c@3d00 {
+ status = "disabled";
+ };
+
+ i2c@3d40 {
+ rtc@51 {
+ compatible = "epson,pcf8563";
+ reg = <0x51>;
+ };
+ };
+ };
+
+ localbus {
+ compatible = "fsl,mpc5200b-lpb","simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0xfc000000 0x02000000
+ 3 0 0xe9000000 0x00080000
+ 5 0 0xe8000000 0x00010000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0x0 0x02000000>;
+ compatible = "cfi-flash";
+ bank-width = <2>;
+ partition@0x0 {
+ label = "u-boot";
+ reg = <0x00000000 0x00040000>;
+ read-only;
+ };
+ partition@0x00040000 {
+ label = "env";
+ reg = <0x00040000 0x00020000>;
+ };
+ partition@0x00060000 {
+ label = "dtb";
+ reg = <0x00060000 0x00020000>;
+ };
+ partition@0x00080000 {
+ label = "kernel";
+ reg = <0x00080000 0x00500000>;
+ };
+ partition@0x00580000 {
+ label = "root";
+ reg = <0x00580000 0x00A80000>;
+ };
+ };
+
+ fpga@3,0 {
+ compatible = "anonymous,a3m071-fpga";
+ reg = <3 0x0 0x00080000
+ 5 0x0 0x00010000>;
+ interrupts = <0 0 3>; /* level low */
+ };
+ };
+
+ pci@f0000d00 {
+ status = "disabled";
+ };
+};
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index 9cf3602..792a301 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -50,6 +50,7 @@ static void __init mpc5200_simple_setup_arch(void)
/* list of the supported boards */
static const char *board[] __initdata = {
+ "anonymous,a3m071",
"anonymous,a4m072",
"anon,charon",
"ifm,o2d",
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
From: Felipe Balbi @ 2012-10-26 8:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Simon Haggett, Li Yang-R58472, Greg Kroah-Hartman,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, balbi,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3862785.b8vaFMSbLQ@avalon>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
Hi,
On Thu, Oct 25, 2012 at 02:36:24AM +0200, Laurent Pinchart wrote:
> Hi Felipe,
>
> On Monday 22 October 2012 13:56:01 Felipe Balbi wrote:
> > On Mon, Oct 22, 2012 at 12:47:21PM +0200, Laurent Pinchart wrote:
> > > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote:
> > > > On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote:
> > > > > On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote:
> > > > > > Some gadget drivers may attempt to dequeue requests for an endpoint
> > > > > > that has already been disabled. For example, in the UVC gadget
> > > > > > driver, uvc_function_set_alt() will call usb_ep_disable() when alt
> > > > > > setting 0 is selected. When the userspace application subsequently
> > > > > > issues the VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes
> > > > > > usb_ep_dequeue() to ensure that all requests have been cancelled.
> > > > >
> > > > > bug is on uvc gadget, then. Laurent ?
> > >
> > > We've discussed this topic a couple of months before. I believe that's not
> > > a bug.
> > >
> > > http://68.183.106.108/lists/linux-usb/msg68869.html
> >
> > fair enough :-)
> >
> > That's a different case, however. At the link above we're discussing
> > dequeueing a request which is already being dequeued. $SUBJECT is trying
> > to fix dequeueing of a request for an endpoint which isn't even enabled.
>
> You've got a point there :-) That's a different case indeed, I'm open to (at
> least evaluating) a fix in the UVC gadget driver if you think that's better.
I _do_ think that's better. If the endpoint isn't even enabled, why are
you trying to dequeue a request ? :-)
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 30/10/2012)
From: Michael Barry @ 2012-10-26 3:01 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 30/10/2012.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 98, Issue 83" sent on 26/10/2012 1:32:27.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* RE: [PATCH] powerpc/esdhc: enable the card insert/remove interrupt
From: Huang Changming-R66093 @ 2012-10-26 2:42 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev@lists.ozlabs.org, Chris Ball,
linux-mmc@vger.kernel.org
In-Reply-To: <20121025103038.GA5107@lizard>
[-- Attachment #1: Type: text/plain, Size: 4836 bytes --]
Hi, Anton,
For the current polling mode, driver will send CMD13 to poll the card status periodically , which will cause too many interrupts.
Once I sent patches to detect the card when using polling mode last year: read the state register, instead of send CMD13. But, these patches were not accepted. Now I attach them for you.
Because these patches are not accepted, I think about the interrupt mode to detect card.
Of course, you are right, the p4080ds and mpc837xmds are still using polling mode, which just fix some boards.
The best way is for all.
Then, I will back to my previous patches, for FSL eSDHC, don't send CMD13, and just read state register to check it.
For all FSL silicones, the state bit is updated when card inserting or removing.
Now I have two ways to resolve this issue, I prefer to the polling mode (unfortunately, they are not accepted).
I will be greatly appreciated if you review these attachment patches again and give your comment.
If you think the attachment patches are OK, I will resend them to mail list.
If you don't, I will continue to work on the interrupt mode for FSL eSDHC.
Thanks.
> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> owner@vger.kernel.org] On Behalf Of Anton Vorontsov
> Sent: Thursday, October 25, 2012 6:31 PM
> To: Huang Changming-R66093
> Cc: linux-mmc@vger.kernel.org; Chris Ball; Kumar Gala; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/esdhc: enable the card insert/remove
> interrupt
>
> On Thu, Oct 25, 2012 at 10:05:44AM +0000, Huang Changming-R66093 wrote:
> > Hi, Anton.
> > Could you have any comment about it?
> > If not, I will resend this patch with v2.
>
> Technically, the patch looks fine.
>
> But again, as far as I recall, the card detection logic was broken on the
> SOC level (it's actually very hard to break it on the board level -- it
> would either work or not, but in the eSDHC case it was just unreliable,
> again, if I recall everything correctly -- I might be wrong).
>
> Of course you know the hardware much better, so your words weight more,
> so you don't need my ack on the patch. :)
>
> Although there's a second issue: for P4080DS and mpc837x boards you still
> have the same problem with polling method, right? It is causing
> performance drops/freezes every like 100 ms, and that's why you want to
> avoid the polling.
>
> So, you've "fixed" some boards, but left others to suffer. Ideally, the
> best fix would be to also make the card polling cheap.
>
> Anyways, using (d) clause of the "Reviewer's statement of oversight", I
> can easily give this:
>
> Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
>
> :)
>
> Thanks!
>
> [...]
> > > > IIRC, the card detection is broken SOC-revision-wise, not board-
> wise.
> > > > So the change seems wrong.
> > > >
> > > > Also, take a look at this:
> > > >
> > > > http://lkml.org/lkml/2010/7/14/127
> > > >
> > > > I started the work but never finished, unfortunately it caused
> > > > some regressions for non-FSL hardware...
> > > >
> > > > > drivers/mmc/host/sdhci-of-esdhc.c | 7 ++++++-
> > > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > > b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > > index ffc1226..5dc362f 100644
> > > > > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > > @@ -196,6 +196,11 @@ static void
> > > > > esdhc_of_detect_limitation(struct
> > > > platform_device *pdev,
> > > > > if (vvn == VENDOR_V_22)
> > > > > pdata->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> > > > >
> > > > > + /* P4080DS and MPC837XMDS board don't support interrupt mode
> */
> > > > > + if (of_machine_is_compatible("fsl,mpc837xmds") ||
> > > > > + of_machine_is_compatible("fsl,P4080DS"))
> > > > > + pdata->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
> > > > > +
> > > > > iounmap(ioaddr);
> > > > > end:
> > > > > return;
> > > > > @@ -223,7 +228,7 @@ static struct sdhci_pltfm_data
> > > > > sdhci_esdhc_pdata =
> > > > {
> > > > > * card detection could be handled via GPIO
> > > > > * eSDHC cannot support End Attribute in NOP ADMA descriptor
> > > > > */
> > > > > - .quirks = ESDHC_DEFAULT_QUIRKS |
> SDHCI_QUIRK_BROKEN_CARD_DETECTION
> > > > > + .quirks = ESDHC_DEFAULT_QUIRKS
> > > > > | SDHCI_QUIRK_NO_CARD_NO_RESET
> > > > > | SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
> > > > > .ops = &sdhci_esdhc_ops,
> > > > > --
> > > > > 1.7.9.5
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: 0002-MMC-SD-Add-callback-function-to-detect-card.patch --]
[-- Type: application/octet-stream, Size: 2094 bytes --]
From bd9be632c2ebf77ba067dbb52a8c4bd73be1697b Mon Sep 17 00:00:00 2001
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
Date: Tue, 6 Dec 2011 17:22:27 +0800
Subject: [PATCH 2/4 v4] MMC/SD: Add callback function to detect card
In order to check whether the card has been removed, the function
mmc_send_status() will send command CMD13 to card and ask the card
to send its status register to sdhc driver, which will generate
many interrupts repeatedly and make the system performance bad.
Therefore, add callback function get_cd() to check whether
the card has been removed when the driver has this callback function.
If the card is present, 1 will return, if the card is absent, 0 will return.
If the controller will not support this feature, -ENOSYS will return.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
CC: Chris Ball <cjb@laptop.org>
---
changes for v2:
- when controller don't support get_cd, return -ENOSYS
- add the CC
changes for v3:
- enalbe the controller clock in platform, instead of core
changes for v4:
- move the detect code to core.c according to the new structure
drivers/mmc/core/core.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6db6621..d570c72 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2060,7 +2060,7 @@ static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
int _mmc_detect_card_removed(struct mmc_host *host)
{
- int ret;
+ int ret = -ENOSYS;
if ((host->caps & MMC_CAP_NONREMOVABLE) || !host->bus_ops->alive)
return 0;
@@ -2068,7 +2068,13 @@ int _mmc_detect_card_removed(struct mmc_host *host)
if (!host->card || mmc_card_removed(host->card))
return 1;
- ret = host->bus_ops->alive(host);
+ if (host->ops->get_cd) {
+ ret = host->ops->get_cd(host);
+ if (ret >= 0)
+ ret = !ret;
+ }
+ if (ret < 0)
+ ret = host->bus_ops->alive(host);
if (ret) {
mmc_card_set_removed(host->card);
pr_debug("%s: card remove detected\n", mmc_hostname(host));
--
1.7.5.4
[-- Attachment #3: 0003-SDHCI-add-sdhci_get_cd-callback-to-detect-the-card.patch --]
[-- Type: application/octet-stream, Size: 3102 bytes --]
From c029b98325733ea0225389612eb7b9f0f0b722cd Mon Sep 17 00:00:00 2001
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
Date: Wed, 7 Dec 2011 10:41:49 +0800
Subject: [PATCH 3/4 v5] SDHCI: add sdhci_get_cd callback to detect the card
Add callback function sdhci_get_cd to detect the card.
And one new callback added to implement the card detect in sdhci struncture.
If special platform has the card detect callback, it will return the card
state, the value zero is for absent cardi and one is for present card.
If the controller don't support card detect, sdhci_get_cd will return -ENOSYS.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
CC: Chris Ball <cjb@laptop.org>
---
changes for v2:
- when controller don't support get_cd, return -ENOSYS
- add new callback for sdhci to detect the card
- add the CC
changes for v3:
- use pin_lock only when get_cd defined
changes for v4:
- enalbe the controller clock in platform, instead of core
changes for v5:
- remove the copyright
drivers/mmc/host/sdhci.c | 21 ++++++++++++++++++++++
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 6d8eea3..fbe2f46 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1518,6 +1519,26 @@ static int sdhci_get_ro(struct mmc_host *mmc)
return ret;
}
+/* Return values for the sdjco_get_cd callback:
+ * 0 for a absent card
+ * 1 for a present card
+ * -ENOSYS when not supported (equal to NULL callback)
+ */
+static int sdhci_get_cd(struct mmc_host *mmc)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ unsigned long flags;
+ int present = -ENOSYS;
+
+ if (host->ops->get_cd) {
+ spin_lock_irqsave(&host->lock, flags);
+ present = host->ops->get_cd(host);
+ spin_unlock_irqrestore(&host->lock, flags);
+ }
+
+ return present;
+}
+
static void sdhci_enable_sdio_irq_nolock(struct sdhci_host *host, int enable)
{
if (host->flags & SDHCI_DEVICE_DEAD)
@@ -1884,6 +1905,7 @@ static const struct mmc_host_ops sdhci_ops = {
.request = sdhci_request,
.set_ios = sdhci_set_ios,
.get_ro = sdhci_get_ro,
+ .get_cd = sdhci_get_cd,
.hw_reset = sdhci_hw_reset,
.enable_sdio_irq = sdhci_enable_sdio_irq,
.start_signal_voltage_switch = sdhci_start_signal_voltage_switch,
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 0a5b654..82f4d27 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -69,6 +69,7 @@
#define SDHCI_SPACE_AVAILABLE 0x00000400
#define SDHCI_DATA_AVAILABLE 0x00000800
#define SDHCI_CARD_PRESENT 0x00010000
+#define SDHCI_CARD_CDPL 0x00040000
#define SDHCI_WRITE_PROTECT 0x00080000
#define SDHCI_DATA_LVL_MASK 0x00F00000
#define SDHCI_DATA_LVL_SHIFT 20
@@ -261,6 +262,7 @@ struct sdhci_ops {
void (*set_clock)(struct sdhci_host *host, unsigned int clock);
+ int (*get_cd)(struct sdhci_host *host);
int (*enable_dma)(struct sdhci_host *host);
unsigned int (*get_max_clock)(struct sdhci_host *host);
unsigned int (*get_min_clock)(struct sdhci_host *host);
--
1.7.5.4
[-- Attachment #4: 0004-ESDHC-add-callback-esdhc_of_get_cd-to-detect-card.patch --]
[-- Type: application/octet-stream, Size: 2480 bytes --]
From 99e41c1bacbad5e9a3418bcac2b5f778516efe6d Mon Sep 17 00:00:00 2001
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
Date: Fri, 9 Dec 2011 11:06:58 +0800
Subject: [PATCH 4/4 v3] ESDHC: add callback esdhc_of_get_cd to detect card
In order to check if the card is present, we will read the PRESENT STATE
register and check the bit13(Card detect pin level) and bit15(CINS).
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
CC: Chris Ball <cjb@laptop.org>
---
changes for v2:
- add new callback for esdhc to detect the card state
- add the CC
changes for v3:
- enable the controller clock when detect the card state, not core
drivers/mmc/host/sdhci-of-esdhc.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 59e9d00..40da8f4 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1,7 +1,7 @@
/*
* Freescale eSDHC controller driver.
*
- * Copyright (c) 2007, 2010 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2010-2011 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
*
* Authors: Xiaobo Xie <X.Xie@freescale.com>
@@ -82,6 +82,28 @@ static unsigned int esdhc_of_get_min_clock(struct sdhci_host *host)
return pltfm_host->clock / 256 / 16;
}
+/* Return: none zero - the card is presetn; 0 - card is absent */
+static int esdhc_of_get_cd(struct sdhci_host *host)
+{
+ int present;
+
+ if (host->flags & SDHCI_DEVICE_DEAD)
+ present = 0;
+ else {
+ int sysctl = sdhci_be32bs_readl(host, SDHCI_CLOCK_CONTROL);
+ /* Enable the controller clock to update the present state */
+ sdhci_be32bs_writel(host, sysctl | SDHCI_CLOCK_INT_EN,
+ SDHCI_CLOCK_CONTROL);
+ /* Detect the card present or absent */
+ present = sdhci_be32bs_readl(host, SDHCI_PRESENT_STATE);
+ present &= (SDHCI_CARD_PRESENT | SDHCI_CARD_CDPL);
+ /* Resve the previous to System control register */
+ sdhci_be32bs_writel(host, sysctl, SDHCI_CLOCK_CONTROL);
+ }
+
+ return present;
+}
+
static struct sdhci_ops sdhci_esdhc_ops = {
.read_l = sdhci_be32bs_readl,
.read_w = esdhc_readw,
@@ -93,6 +115,7 @@ static struct sdhci_ops sdhci_esdhc_ops = {
.enable_dma = esdhc_of_enable_dma,
.get_max_clock = esdhc_of_get_max_clock,
.get_min_clock = esdhc_of_get_min_clock,
+ .get_cd = esdhc_of_get_cd,
};
static struct sdhci_pltfm_data sdhci_esdhc_pdata = {
--
1.7.5.4
[-- Attachment #5: 0001-MMC-core-Add-f_min-to-mmc_power_on.patch --]
[-- Type: application/octet-stream, Size: 1072 bytes --]
From 5abfc594fd26198df957a5710c026d8be6de4f5e Mon Sep 17 00:00:00 2001
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
Date: Mon, 5 Dec 2011 14:28:31 +0800
Subject: [PATCH 1/4 v3] MMC/core: Add f_min to mmc_power_on()
When f_init is zero, the SDHC can't work correctly. So f_min will replace
f_init, when f_init is zero.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
CC: Chris Ball <cjb@laptop.org>
---
changes for v2:
- add the CC
changes for v3:
- enalbe the controller clock in platform, instead of core
drivers/mmc/core/core.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index a08e6b1..2d40c04 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1253,7 +1253,10 @@ static void mmc_power_up(struct mmc_host *host)
*/
mmc_delay(10);
- host->ios.clock = host->f_init;
+ if (host->f_init)
+ host->ios.clock = host->f_init;
+ else
+ host->ios.clock = host->f_min;
host->ios.power_mode = MMC_POWER_ON;
mmc_set_ios(host);
--
1.7.5.4
^ permalink raw reply related
* [PATCH RFT] powerpc: dma-mapping: support debug_dma_mapping_error
From: Shuah Khan @ 2012-10-26 0:16 UTC (permalink / raw)
To: benh, paulus, kyungmin.park, m.szyprowski, david, arnd, andrzej.p
Cc: linuxppc-dev, LKML, shuahkhan
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
---
arch/powerpc/include/asm/dma-mapping.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 7816087..e27e9ad 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -172,6 +172,7 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
+ debug_dma_mapping_error(dev, dma_addr);
if (dma_ops->mapping_error)
return dma_ops->mapping_error(dev, dma_addr);
--
1.7.9.5
^ permalink raw reply related
* Power Management issues in MPC8313 processor
From: Srivatsan Canchivaram @ 2012-10-25 22:07 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 7359 bytes --]
Hi,
I have a modem with a Freescale MPC8313E processor. I am trying to enable
power savings in the processor by placing it in Standby mode and resume
normal operation with a Wake-On-LAN magic packet.
Following the directions in the Freescale Power Management app note, I
enabled Power Management Support in the Linux kernel and device tree
configurations.
I ran the following command on the board:
echo standby > /sys/power/state
This caused the console to hang and there was no further response to
keyboard inputs. I enabled ‘no_console_suspend’ in the kernel and when I
loaded the new build and enabled standby mode, I observed an Oops trace:
RASCOM_QCU.7.0.0013 $ echo standby > /sys/power/state
<6>PM: Syncing fFreezing user space processes ... ilesystems ... <7>PM:
Entering standby sleep
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x616d6570
Oops: Kernel access of bad area, sig: 11 [#1]
MPC831x RDB
Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last
unloaded: modem]
NIP: 616d6570 LR: c0165224 CTR: 616d6573
REGS: cd087d30 TRAP: 0400 Not tainted (2.6.27)
MSR: 20001032 <ME,IR,DR> CR: 28002024 XER: 20000000
TASK = cc312400[1196] 'echo' THREAD: cd086000
GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
c06da4a0
GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
100050b8
GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
c0246180
GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
cf821808
NIP [616d6570] 0x616d6570
LR [c0165224] platform_pm_suspend_noirq+0x84/0x88
Call Trace:
[cd087de0] [c0167e6c] pm_dev_dbg+0x70/0x18c (unreliable)
[cd087df0] [c0167cb4] pm_noirq_op+0x58/0xc8
[cd087e00] [c0168e08] device_power_down+0x78/0x1c4
[cd087e40] [c00471bc] suspend_devices_and_enter+0x1ec/0x258
[cd087e70] [c00473ac] enter_state+0x13c/0x198
[cd087e90] [c00474bc] state_store+0xb4/0xf8
[cd087eb0] [c013af68] kobj_attr_store+0x24/0x3c
[cd087ec0] [c00bf734] sysfs_write_file+0xe8/0x1e8
[cd087ef0] [c0078bbc] vfs_write+0xb4/0x16c
[cd087f10] [c0078d7c] sys_write+0x4c/0xa4
[cd087f40] [c000fa88] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x4802679c
LR = 0x4803f0e8
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace b6a2457eea68b760 ]---
done.
<7>PM: Preparing system for standby sleep
<1>Freezing user space processes ... <7>PM: Entering standby sleep
<7>platform mpc83xx_wdt.0: preparing suspend
<7>fsl-gianfar fsl-gianfar.0: preparing suspend
<7>fsl-gianfar fsl-gianfar.1: preparing suspend
<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: preparing suspend
<7>serial8250 serial8250.0: preparing suspend
<7>serial8250 serial8250: preparing suspend
<7>platform Fixed MDIO bus.0: preparing suspend
<7>lm92 0-0049: legacy suspend
<7>lm92 0-0048: legacy suspend
<7>platform Fixed MDIO bus.0: suspend
<7>mdio_bus 24520:1f: legacy suspend
<7>Generic PHY 24520:01: legacy suspend
<7>Generic PHY 24520:00: legacy suspend
<7>serial8250 serial8250: suspend
<7>of_platform ee000600.timer: legacy suspend
<7>of_platform ee000500.timer: legacy suspend
<7>mpc83xx-pmc ee000b00.power: legacy suspend
<7>of_platform ee000700.pic: legacy suspend
<7>of_platform ee030000.crypto: legacy suspend
<7>of_platform ee004600.serial: legacy suspend
<7>of_platform ee004500.serial: legacy suspend
<7>of_platform ee025000.ethernet: legacy suspend
<7>of_platform ee024000.ethernet: legacy suspend
<7>of_platform ee024520.mdio: legacy suspend
<7>of_platform ee024e00.ptimer: legacy suspend
<7>of_platform ee0082a8.dma: legacy suspend
<7>mpc-i2c ee003100.i2c: legacy suspend
<7>mpc-i2c ee003000.i2c: legacy suspend
<7>of_platform ee000200.wdt: legacy suspend
<7>of_platform ee000000.soc8313: legacy suspend
<7>of-flash fc000000.flash: legacy suspend
<7>of_platform ee005000.localbus: legacy suspend
<7>serial8250 serial8250.0: suspend
<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: suspend
<7>fsl-gianfar fsl-gianfar.1: suspend
<7>fsl-gianfar fsl-gianfar.0: suspend
<7>platform mpc83xx_wdt.0: suspend
<6>PM: suspend devices took 0.000 seconds
<7>platform Fixed MDIO bus.0: LATE suspend
<7>serial8250 serial8250: LATE suspend
<7>serial8250 serial8250.0: LATE suspend
<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: LATE suspend
<1>Unable to handle kernel paging request for instruction fetch
<1>Faulting instruction address: 0x616d6570
<1>Oops: Kernel access of bad area, sig: 11 [#1]
<1>MPC831x RDB
<1>Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last
unloaded: modem]
<1>NIP: 616d6570 LR: c0165224 CTR: 616d6573
<1>REGS: cd087d30 TRAP: 0400 Not tainted (2.6.27)
<1>MSR: 20001032 <ME,IR,DR> CR: 28002024 XER: 20000000
<1>TASK = cc312400[1196] 'echo' THREAD: cd086000
<6>GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
c06da4a0
<6>GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
100050b8
<6>GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
c0246180
<6>GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
cf821808
<1>NIP [616d6570] 0x616d6570
<1>LR [c0165224] platform_pm_suspend_noirq+0x84/0x88
<1>Call Trace:
<1>[cd087de0] [c0167e6c] pm_dev_dbg+0x70/0x18c (unreliable)
<1>[cd087df0] [c0167cb4] pm_noirq_op+0x58/0xc8
<1>[cd087e00] [c0168e08] device_power_down+0x78/0x1c4
<1>[cd087e40] [c00471bc] suspend_devices_and_enter+0x1ec/0x258
<1>[cd087e70] [c00473ac] enter_state+0x13c/0x198
<1>[cd087e90] [c00474bc] state_store+0xb4/0xf8
<1>[cd087eb0] [c013af68] kobj_attr_store+0x24/0x3c
<1>[cd087ec0] [c00bf734] sysfs_write_file+0xe8/0x1e8
<1>[cd087ef0] [c0078bbc] vfs_write+0xb4/0x16c
<1>[cd087f10] [c0078d7c] sys_write+0x4c/0xa4
<1>[cd087f40] [c000fa88] ret_from_syscall+0x0/0x38
<1>--- Exception: c01 at 0x4802679c
<1> LR = 0x4803f0e8
<1>Instruction dump:
<1>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
<1>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
<4>---[ end trace b6a2457eea68b760 ]---
Segmentation fault
I tried commenting out the kernel code in drivers/base/platform.c ->
platform_legacy_suspend_late() function:
/* if (dev->driver && drv->suspend_late)
{ } */
This prevents the segmentation fault but it causes the resume functions for
all the peripherals to be called as soon as the suspend operations are
complete i.e. the processor goes into standby and then immediately goes
back to normal operation.
I found another thread that dealt with Power Management issues on the
Freescale MPC8313 processor:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-January/095240.html
The resolution of this issue seems to be related to the JTAG TRST pin being
disabled. This is not relevant in my case as the TRST on my board is
already inactive.
Any advice or suggestions are most welcome.
Thanks,
Srivatsan
[-- Attachment #2: Type: text/html, Size: 11569 bytes --]
^ permalink raw reply
* Please pull 'merge' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-10-25 20:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben,
please pull three mpc5200 fixes for 3.7:
Patch for pcm030 device tree fixing the probe() in pcm030-audio-fabric
driver. Changes to this driver have been merged in 3.7-rc1 via ASoC
tree, but this required device tree patch was submitted separately to
the linux-ppc list and is still missing in mainline. Without this patch
the probe() in pcm030-audio-fabric driver wrongly returns -ENODEV.
A patch from Wolfram fixing wrong invalid critical irq warnings for
all mpc5200 boards.
Another patch for all mpc5200 device trees fixing wrong L1 cell in
the LPB FIFO interrupt property and moving the LPB FIFO node to the
common mpc5200b.dtsi file so that this common node will be present
in all mpc5200 device trees.
All these patches have been in linux-next for a while.
Thanks,
Anatolij
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git merge
Anatolij Gustschin (1):
powerpc/mpc5200: move lpbfifo node and fix its interrupt property
Eric Millbrandt (1):
powerpc/pcm030: add pcm030-audio-fabric to dts
Wolfram Sang (1):
powerpc: 52xx: nop out unsupported critical IRQs
arch/powerpc/boot/dts/mpc5200b.dtsi | 6 ++++++
arch/powerpc/boot/dts/o2d.dtsi | 6 ------
arch/powerpc/boot/dts/pcm030.dts | 7 ++++++-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 9 +++++----
4 files changed, 17 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: PROBLEM: Linux 3.6.2 fails to boot on IBM Cell
From: Dennis Schridde @ 2012-10-25 19:33 UTC (permalink / raw)
To: Grant Likely; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <6566742.NTPeeo2QHT@ernie>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Hello everyone!
Am Freitag, 19. Oktober 2012, 09:04:08 schrieb Dennis Schridde:
> Am Freitag, 19. Oktober 2012, 00:17:55 schrieb Grant Likely:
> > What does the boot log look like with the attached patch? (compiled
> > only, I haven't booted with it)
>
> Please find the log attached.
Have you found the cause or a fix for the problem?
Best regards,
Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/esdhc: enable the card insert/remove interrupt
From: Anton Vorontsov @ 2012-10-25 10:30 UTC (permalink / raw)
To: Huang Changming-R66093
Cc: linuxppc-dev@lists.ozlabs.org, Chris Ball,
linux-mmc@vger.kernel.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C1D7A42@039-SN1MPN1-003.039d.mgd.msft.net>
On Thu, Oct 25, 2012 at 10:05:44AM +0000, Huang Changming-R66093 wrote:
> Hi, Anton.
> Could you have any comment about it?
> If not, I will resend this patch with v2.
Technically, the patch looks fine.
But again, as far as I recall, the card detection logic was broken on the
SOC level (it's actually very hard to break it on the board level -- it
would either work or not, but in the eSDHC case it was just unreliable,
again, if I recall everything correctly -- I might be wrong).
Of course you know the hardware much better, so your words weight more, so
you don't need my ack on the patch. :)
Although there's a second issue: for P4080DS and mpc837x boards you still
have the same problem with polling method, right? It is causing
performance drops/freezes every like 100 ms, and that's why you want to
avoid the polling.
So, you've "fixed" some boards, but left others to suffer. Ideally, the
best fix would be to also make the card polling cheap.
Anyways, using (d) clause of the "Reviewer's statement of oversight", I
can easily give this:
Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
:)
Thanks!
[...]
> > > IIRC, the card detection is broken SOC-revision-wise, not board-wise.
> > > So the change seems wrong.
> > >
> > > Also, take a look at this:
> > >
> > > http://lkml.org/lkml/2010/7/14/127
> > >
> > > I started the work but never finished, unfortunately it caused some
> > > regressions for non-FSL hardware...
> > >
> > > > drivers/mmc/host/sdhci-of-esdhc.c | 7 ++++++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > index ffc1226..5dc362f 100644
> > > > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > @@ -196,6 +196,11 @@ static void esdhc_of_detect_limitation(struct
> > > platform_device *pdev,
> > > > if (vvn == VENDOR_V_22)
> > > > pdata->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> > > >
> > > > + /* P4080DS and MPC837XMDS board don't support interrupt mode */
> > > > + if (of_machine_is_compatible("fsl,mpc837xmds") ||
> > > > + of_machine_is_compatible("fsl,P4080DS"))
> > > > + pdata->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
> > > > +
> > > > iounmap(ioaddr);
> > > > end:
> > > > return;
> > > > @@ -223,7 +228,7 @@ static struct sdhci_pltfm_data sdhci_esdhc_pdata
> > > > =
> > > {
> > > > * card detection could be handled via GPIO
> > > > * eSDHC cannot support End Attribute in NOP ADMA descriptor
> > > > */
> > > > - .quirks = ESDHC_DEFAULT_QUIRKS | SDHCI_QUIRK_BROKEN_CARD_DETECTION
> > > > + .quirks = ESDHC_DEFAULT_QUIRKS
> > > > | SDHCI_QUIRK_NO_CARD_NO_RESET
> > > > | SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
> > > > .ops = &sdhci_esdhc_ops,
> > > > --
> > > > 1.7.9.5
^ permalink raw reply
* RE: [PATCH] powerpc/esdhc: enable the card insert/remove interrupt
From: Huang Changming-R66093 @ 2012-10-25 10:05 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev@lists.ozlabs.org, Chris Ball,
linux-mmc@vger.kernel.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C1C68D9@039-SN1MPN1-003.039d.mgd.msft.net>
SGksIEFudG9uLg0KQ291bGQgeW91IGhhdmUgYW55IGNvbW1lbnQgYWJvdXQgaXQ/DQpJZiBub3Qs
IEkgd2lsbCByZXNlbmQgdGhpcyBwYXRjaCB3aXRoIHYyLg0KDQpCZXN0IFJlZ2FyZHMNCkplcnJ5
IEh1YW5nDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1t
bWMtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtbW1jLQ0KPiBvd25lckB2Z2Vy
Lmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBIdWFuZyBDaGFuZ21pbmctUjY2MDkzDQo+IFNlbnQ6
IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTIgNDo0MCBQTQ0KPiBUbzogQW50b24gVm9yb250c292
DQo+IENjOiBsaW51eC1tbWNAdmdlci5rZXJuZWwub3JnOyBDaHJpcyBCYWxsOyBLdW1hciBHYWxh
OyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRD
SF0gcG93ZXJwYy9lc2RoYzogZW5hYmxlIHRoZSBjYXJkIGluc2VydC9yZW1vdmUNCj4gaW50ZXJy
dXB0DQo+IA0KPiBIaSwgQW50b24NCj4gRm9yIEZTTCBTT0NzLCB0aGUgaW50ZXJydXB0IG1vZGUg
aXMgc3VwcG9ydCBmb3IgY2FyZCBkZXRlY3QuDQo+IEZvciBzb21lIHJlYXNvbnMsIHNvbWUgYm9h
cmQgY2FuJ3Qgc3VwcG9ydCB0aGlzIGZlYXR1cmUsIHN1Y2ggYXMNCj4gbXBjODM3eG1kcyBib2Fy
ZCwgYnV0IG1wYzgzN3hyZGIgYm9hcmQgc3VwcG9ydCBpdC4NCj4gDQo+IEkgc2VlIHlvdXIgbGlu
a3MsIGl0IGlzIGFib3V0IHRoZSBETUEgKHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHAyMDIwIGRvbid0
DQo+IHN1cHBvcnQgRE1BLCBuZWVkIHRvIGVuYWJsZSB0aGUgUElPIG1vZGUsIGJ1dCB0aGUgbGF0
ZXIgdmVyc2lvbiBoYXMgZml4ZWQNCj4gdGhpcyBpc3N1ZSkuDQo+IA0KPiBCZXN0IFJlZ2FyZHMN
Cj4gSmVycnkgSHVhbmcNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4gRnJvbTogbGludXgtbW1jLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LW1t
Yy0NCj4gPiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBBbnRvbiBWb3JvbnRz
b3YNCj4gPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIzLCAyMDEyIDQ6MjcgUE0NCj4gPiBUbzog
SHVhbmcgQ2hhbmdtaW5nLVI2NjA5Mw0KPiA+IENjOiBsaW51eC1tbWNAdmdlci5rZXJuZWwub3Jn
OyBIdWFuZyBDaGFuZ21pbmctUjY2MDkzOyBDaHJpcyBCYWxsOw0KPiA+IEt1bWFyIEdhbGE7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSF0gcG93
ZXJwYy9lc2RoYzogZW5hYmxlIHRoZSBjYXJkIGluc2VydC9yZW1vdmUNCj4gPiBpbnRlcnJ1cHQN
Cj4gPg0KPiA+IE9uIFR1ZSwgT2N0IDIzLCAyMDEyIGF0IDAzOjAxOjE3UE0gKzA4MDAsIHI2NjA5
M0BmcmVlc2NhbGUuY29tIHdyb3RlOg0KPiA+ID4gRnJvbTogSmVycnkgSHVhbmcgPENoYW5nLU1p
bmcuSHVhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiA+DQo+ID4gPiBUaGUgY3VycmVudCBlU0RIQyBk
cml2ZXIgdXNlIHRoZSBwb2xsIG1vZGUgdG8gZGV0ZWN0IGlmIHRoZSBTRC9NTUMNCj4gPiA+IGNh
cmQgaXMgaW5zZXJ0ZWQgb3IgcmVtb3ZlZCwgd2hpY2ggd2lsbCBnZW5lcmF0ZSBtYW55IGludGVy
cnVwdHMgYW5kDQo+ID4gPiBpbXBhY3QgdGhlIHBlcmZvcm1hbmNlLg0KPiA+ID4gVGhlcmVmb3Jl
LCBjaGFuZ2UgdGhlIGRlZmF1bHQgY2FyZCBkZXRlY3QgdG8gaW50ZXJydXB0IG1vZGUsIGlmIHRo
ZQ0KPiA+ID4gYm9hcmQgY2FuJ3Qgc3VwcG9ydCB0aGlzIG1vZGUsIHdlIHN0aWxsIHVzZSB0aGUg
cG9sbCBtb2RlLg0KPiA+ID4NCj4gPiA+IFNpZ25lZC1vZmYtYnk6IEplcnJ5IEh1YW5nIDxDaGFu
Zy1NaW5nLkh1YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4gPiBDQzogQW50b24gVm9yb250c292IDxj
Ym91YXRtYWlscnVAZ21haWwuY29tPg0KPiA+ID4gQ0M6IENocmlzIEJhbGwgPGNqYkBsYXB0b3Au
b3JnPg0KPiA+ID4gLS0tDQo+ID4NCj4gPiBJSVJDLCB0aGUgY2FyZCBkZXRlY3Rpb24gaXMgYnJv
a2VuIFNPQy1yZXZpc2lvbi13aXNlLCBub3QgYm9hcmQtd2lzZS4NCj4gPiBTbyB0aGUgY2hhbmdl
IHNlZW1zIHdyb25nLg0KPiA+DQo+ID4gQWxzbywgdGFrZSBhIGxvb2sgYXQgdGhpczoNCj4gPg0K
PiA+IAlodHRwOi8vbGttbC5vcmcvbGttbC8yMDEwLzcvMTQvMTI3DQo+ID4NCj4gPiBJIHN0YXJ0
ZWQgdGhlIHdvcmsgYnV0IG5ldmVyIGZpbmlzaGVkLCB1bmZvcnR1bmF0ZWx5IGl0IGNhdXNlZCBz
b21lDQo+ID4gcmVncmVzc2lvbnMgZm9yIG5vbi1GU0wgaGFyZHdhcmUuLi4NCj4gPg0KPiA+ID4g
IGRyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYyB8ICAgIDcgKysrKysrLQ0KPiA+ID4g
IDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPiA+DQo+
ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5jDQo+ID4g
PiBiL2RyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYw0KPiA+ID4gaW5kZXggZmZjMTIy
Ni4uNWRjMzYyZiAxMDA2NDQNCj4gPiA+IC0tLSBhL2RyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2Yt
ZXNkaGMuYw0KPiA+ID4gKysrIGIvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5jDQo+
ID4gPiBAQCAtMTk2LDYgKzE5NiwxMSBAQCBzdGF0aWMgdm9pZCBlc2RoY19vZl9kZXRlY3RfbGlt
aXRhdGlvbihzdHJ1Y3QNCj4gPiBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYsDQo+ID4gPiAgCWlmICh2
dm4gPT0gVkVORE9SX1ZfMjIpDQo+ID4gPiAgCQlwZGF0YS0+cXVpcmtzMiB8PSBTREhDSV9RVUlS
SzJfSE9TVF9OT19DTUQyMzsNCj4gPiA+DQo+ID4gPiArCS8qIFA0MDgwRFMgYW5kIE1QQzgzN1hN
RFMgYm9hcmQgZG9uJ3Qgc3VwcG9ydCBpbnRlcnJ1cHQgbW9kZSAqLw0KPiA+ID4gKwlpZiAob2Zf
bWFjaGluZV9pc19jb21wYXRpYmxlKCJmc2wsbXBjODM3eG1kcyIpIHx8DQo+ID4gPiArCSAgICBv
Zl9tYWNoaW5lX2lzX2NvbXBhdGlibGUoImZzbCxQNDA4MERTIikpDQo+ID4gPiArCQlwZGF0YS0+
cXVpcmtzIHw9IFNESENJX1FVSVJLX0JST0tFTl9DQVJEX0RFVEVDVElPTjsNCj4gPiA+ICsNCj4g
PiA+ICAJaW91bm1hcChpb2FkZHIpOw0KPiA+ID4gIGVuZDoNCj4gPiA+ICAJcmV0dXJuOw0KPiA+
ID4gQEAgLTIyMyw3ICsyMjgsNyBAQCBzdGF0aWMgc3RydWN0IHNkaGNpX3BsdGZtX2RhdGEgc2Ro
Y2lfZXNkaGNfcGRhdGENCj4gPiA+ID0NCj4gPiB7DQo+ID4gPiAgCSAqIGNhcmQgZGV0ZWN0aW9u
IGNvdWxkIGJlIGhhbmRsZWQgdmlhIEdQSU8NCj4gPiA+ICAJICogZVNESEMgY2Fubm90IHN1cHBv
cnQgRW5kIEF0dHJpYnV0ZSBpbiBOT1AgQURNQSBkZXNjcmlwdG9yDQo+ID4gPiAgCSAqLw0KPiA+
ID4gLQkucXVpcmtzID0gRVNESENfREVGQVVMVF9RVUlSS1MgfCBTREhDSV9RVUlSS19CUk9LRU5f
Q0FSRF9ERVRFQ1RJT04NCj4gPiA+ICsJLnF1aXJrcyA9IEVTREhDX0RFRkFVTFRfUVVJUktTDQo+
ID4gPiAgCQl8IFNESENJX1FVSVJLX05PX0NBUkRfTk9fUkVTRVQNCj4gPiA+ICAJCXwgU0RIQ0lf
UVVJUktfTk9fRU5EQVRUUl9JTl9OT1BERVNDLA0KPiA+ID4gIAkub3BzID0gJnNkaGNpX2VzZGhj
X29wcywNCj4gPiA+IC0tDQo+ID4gPiAxLjcuOS41DQo+ID4gLS0NCj4gPiBUbyB1bnN1YnNjcmli
ZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtbW1jIg0K
PiA+IGluIHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3Jn
IE1vcmUgbWFqb3Jkb21vDQo+ID4gaW5mbyBhdCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9y
ZG9tby1pbmZvLmh0bWwNCj4gDQo+IE4gICAgIHIgIHkgICBiIFggIMendiBeICneunsubiArICAg
IHsgIGciICBebiByICAgeiAaICBoICAgICYgIB4gRyAgIGgNCj4gAygg6ZqOIN2iaiIgIBogG20g
ICAgIHog3pYgICBmICAgaCAgIH4gbQ0K
^ permalink raw reply
* Re: iMac (PM61) quieter fan?
From: Benjamin Herrenschmidt @ 2012-10-25 8:46 UTC (permalink / raw)
To: Jeremy Elgin; +Cc: linuxppc-dev
In-Reply-To: <26F74A8F-8BCD-4E97-99F4-8DF14C2568D6@jeremyelgin.me>
On Thu, 2012-10-25 at 16:13 +1300, Jeremy Elgin wrote:
> I'm running Ubuntu 12.04 on my iMac G4 1GHz (PowerMac6,1) and I've
> been looking for any installable option to quiet the fan, nothing I've
> found mentions PowerMac6,1 and the modules installed don't even
> mention different PM models, just therm_windtunnel.ko &
> windfarm_core.ko - this first module won't load (No such device) and
> the second isn't used by anything (yet), do I need to install a .deb
> package that'll talk to this module?
>
> I know this is not really about development but it's specific to PPC,
> ok? :-)
I don't know much about the fan control on the iMac G4. You can try
sending me a dump of /proc/device-tree (a tarball), it might tell us
more about what's in there.
> Oh, I also have a Dual 2.0 GHz G5 (PowerMac7,3) that I'm keen to get
> Ubuntu running on as a headless server and it'll need fan controls
> too. What I mean to say is, I'm keen to help out with these two pieces
> of hardware should you need testers for them specifically.
This should be fully supported already.
Cheers,
Ben.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PCI device not working
From: Davide @ 2012-10-25 8:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <750F6602-132E-449A-A852-43E739EA6D3E@kernel.crashing.org>
Hi Kumar,
On Fri, Oct 05, 2012 at 07:47:24AM -0500, Kumar Gala wrote:
>
> On Oct 5, 2012, at 3:54 AM, Davide Viti wrote:
>
> >> On Oct 4, 2012, at 7:24 AM, Davide Viti wrote:
> >>
> >>> Hi,
> >>> it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the
> >>> device behind the second controller is detected by the Linux kernel.
> >>>
> >>> Would
> >>> you suggest any particular patch I should apply to fix this (I'm using kernel
> >>> 2.6.34)
> >>>
> >>> thanx alot in advance
> >>> Davide
> >>>
> >>> [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/20140
> >>
> >> My suggestion would be to try and dump all the controller registers between the case that works and doesn't and compare. There's some minor setting difference that I'm guessing is causing issues.
> >>
> >> - k
>
> When I said controller registers, I meant the FSL PCI controller and the CCSR registers not the PCI cfg register space
>
I've collected a complete dump of the registers in the working and not working cases
0x9000: 0x80000048 (not working) -> 0x8003007c (ok)
0x9004: 0x00000000 (not working) -> 0x08000000 (ok)
According to the p1020 manual, the register fall in the PCI Express controller 2 area,
in particular:
0x9000 PEX_CONFIG_ADDR—PCI Express configuration address register
0x9004 PEX_CONFIG_DATA—PCI Express configuration data register
does that ring any bell?
thank you in advance
Davide
^ permalink raw reply
* [PATCH 3/3] kgdb/kgdbts: support ppc64
From: Tiejun Chen @ 2012-10-25 6:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1351147410-17452-1-git-send-email-tiejun.chen@windriver.com>
We can't look up the address of the entry point of the function simply
via that function symbol for all architectures.
For PPC64 ABI, actually there is a function descriptors structure.
A function descriptor is a three doubleword data structure that contains
the following values:
* The first doubleword contains the address of the entry point of
the function.
* The second doubleword contains the TOC base address for
the function.
* The third doubleword contains the environment pointer for
languages such as Pascal and PL/1.
So we should call a wapperred dereference_function_descriptor() to get
the address of the entry point of the function.
Note this is also safe for other architecture after refer to
"include/asm-generic/sections.h" since:
dereference_function_descriptor(p) always is (p) if without arched definition.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
drivers/misc/kgdbts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 3aa9a96..4799e1f 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -103,6 +103,7 @@
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/module.h>
+#include <asm/sections.h>
#define v1printk(a...) do { \
if (verbose) \
@@ -222,6 +223,7 @@ static unsigned long lookup_addr(char *arg)
addr = (unsigned long)do_fork;
else if (!strcmp(arg, "hw_break_val"))
addr = (unsigned long)&hw_break_val;
+ addr = (unsigned long )dereference_function_descriptor((void *)addr);
return addr;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] powerpc/book3e: load critical/machine/debug exception stack
From: Tiejun Chen @ 2012-10-25 6:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
We always alloc critical/machine/debug check exceptions. This is
different from the normal exception. So we should load these exception
stack properly like we did for booke.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 4684e33..43b654a 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -36,6 +36,30 @@
*/
#define SPECIAL_EXC_FRAME_SIZE INT_FRAME_SIZE
+/* only on book3e */
+#define DBG_STACK_BASE dbgirq_ctx
+#define MC_STACK_BASE mcheckirq_ctx
+#define CRIT_STACK_BASE critirq_ctx
+
+#ifdef CONFIG_SMP
+#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
+ std r14,PACA_EX##level+EX_R14(r13); \
+ mfspr r14,SPRN_PIR; \
+ slwi r14,r14,3; \
+ LOAD_REG_ADDR(r10, level##_STACK_BASE); \
+ add r10,r10,r14; \
+ ld r10,0(r10); \
+ addi r10,r10,THREAD_SIZE; \
+ std r10,PACA_DBG_STACK(r13); \
+ ld r14,PACA_EX##level+EX_R14(r13);
+#else
+#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
+ LOAD_REG_ADDR(r10, level##_STACK_BASE); \
+ ld r10,0(r10); \
+ addi r10,r10,THREAD_SIZE; \
+ std r10,PACA_DBG_STACK(r13);
+#endif
+
/* Exception prolog code for all exceptions */
#define EXCEPTION_PROLOG(n, intnum, type, addition) \
mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \
@@ -68,18 +92,21 @@
#define SPRN_GDBELL_SRR1 SPRN_GSRR1
#define CRIT_SET_KSTACK \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT); \
ld r1,PACA_CRIT_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
#define SPRN_CRIT_SRR0 SPRN_CSRR0
#define SPRN_CRIT_SRR1 SPRN_CSRR1
#define DBG_SET_KSTACK \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(DBG); \
ld r1,PACA_DBG_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
#define SPRN_DBG_SRR0 SPRN_DSRR0
#define SPRN_DBG_SRR1 SPRN_DSRR1
#define MC_SET_KSTACK \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(MC); \
ld r1,PACA_MC_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
#define SPRN_MC_SRR0 SPRN_MCSRR0
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] powerpc/book3e: support kgdb for kernel space
From: Tiejun Chen @ 2012-10-25 6:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1351147410-17452-1-git-send-email-tiejun.chen@windriver.com>
Currently we need to skip this for supporting KGDB.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 43b654a..c5564d4 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -566,11 +566,14 @@ kernel_dbg_exc:
rfdi
/* Normal debug exception */
+1:
+#ifndef CONFIG_KGDB
/* XXX We only handle coming from userspace for now since we can't
* quite save properly an interrupted kernel state yet
*/
-1: andi. r14,r11,MSR_PR; /* check for userspace again */
+ andi. r14,r11,MSR_PR; /* check for userspace again */
beq kernel_dbg_exc; /* if from kernel mode */
+#endif
/* Now we mash up things to make it look like we are coming on a
* normal exception
--
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc: Remove no longer used ppc_md.idle_loop()
From: Michael Ellerman @ 2012-10-25 3:21 UTC (permalink / raw)
To: linuxppc-dev
The last user of ppc_md.idle_loop() was removed when we dropped the
legacy iSeries code, in commit 8ee3e0d.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/machdep.h | 3 ---
arch/powerpc/kernel/idle.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index c423197..a338bc7 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -166,9 +166,6 @@ struct machdep_calls {
unsigned long size,
pgprot_t vma_prot);
- /* Idle loop for this platform, leave empty for default idle loop */
- void (*idle_loop)(void);
-
/*
* Function for waiting for work with reduced power in idle loop;
* called with interrupts disabled.
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 2099d9a..ea78761 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -55,9 +55,6 @@ __setup("powersave=off", powersave_off);
*/
void cpu_idle(void)
{
- if (ppc_md.idle_loop)
- ppc_md.idle_loop(); /* doesn't return */
-
set_thread_flag(TIF_POLLING_NRFLAG);
while (1) {
tick_nohz_idle_enter();
--
1.7.9.5
^ permalink raw reply related
* iMac (PM61) quieter fan?
From: Jeremy Elgin @ 2012-10-25 3:13 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
I'm running Ubuntu 12.04 on my iMac G4 1GHz (PowerMac6,1) and I've been looking for any installable option to quiet the fan, nothing I've found mentions PowerMac6,1 and the modules installed don't even mention different PM models, just therm_windtunnel.ko & windfarm_core.ko - this first module won't load (No such device) and the second isn't used by anything (yet), do I need to install a .deb package that'll talk to this module?
I know this is not really about development but it's specific to PPC, ok? :-)
Oh, I also have a Dual 2.0 GHz G5 (PowerMac7,3) that I'm keen to get Ubuntu running on as a headless server and it'll need fan controls too. What I mean to say is, I'm keen to help out with these two pieces of hardware should you need testers for them specifically.
[-- Attachment #2: Type: text/html, Size: 1232 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
From: Laurent Pinchart @ 2012-10-25 0:36 UTC (permalink / raw)
To: balbi
Cc: Simon Haggett, Li Yang-R58472, Greg Kroah-Hartman,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20121022105601.GS14033@arwen.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
Hi Felipe,
On Monday 22 October 2012 13:56:01 Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 12:47:21PM +0200, Laurent Pinchart wrote:
> > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote:
> > > On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote:
> > > > On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote:
> > > > > Some gadget drivers may attempt to dequeue requests for an endpoint
> > > > > that has already been disabled. For example, in the UVC gadget
> > > > > driver, uvc_function_set_alt() will call usb_ep_disable() when alt
> > > > > setting 0 is selected. When the userspace application subsequently
> > > > > issues the VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes
> > > > > usb_ep_dequeue() to ensure that all requests have been cancelled.
> > > >
> > > > bug is on uvc gadget, then. Laurent ?
> >
> > We've discussed this topic a couple of months before. I believe that's not
> > a bug.
> >
> > http://68.183.106.108/lists/linux-usb/msg68869.html
>
> fair enough :-)
>
> That's a different case, however. At the link above we're discussing
> dequeueing a request which is already being dequeued. $SUBJECT is trying
> to fix dequeueing of a request for an endpoint which isn't even enabled.
You've got a point there :-) That's a different case indeed, I'm open to (at
least evaluating) a fix in the UVC gadget driver if you think that's better.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox