* [PATCH v3 2/2] powerpc, video: add SM501 support for charon board.
From: Heiko Schocher @ 2010-12-11 6:31 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, Heiko Schocher
In-Reply-To: <1291451028-22532-2-git-send-email-hs@denx.de>
Signed-off-by: Heiko Schocher <hs@denx.de>
cc: linux-fbdev@vger.kernel.org
cc: devicetree-discuss@ozlabs.org
cc: Ben Dooks <ben@simtec.co.uk>
cc: Vincent Sanders <vince@simtec.co.uk>
cc: Samuel Ortiz <sameo@linux.intel.com>
cc: linux-kernel@vger.kernel.org
---
- based against 2.6.37-rc4
./scripts/checkpatch.pl 0003-powerpc-video-add-SM501-support-for-charon-board.patch
total: 0 errors, 0 warnings, 21 lines checked
0003-powerpc-video-add-SM501-support-for-charon-board.patch has no obvious style problems and is ready for submission.
- changes since v1:
- no board specific defconfig file for mpc52xx based boards as suggested
from Wolfram Sang
- changes since v2:
add Ben Dooks, Vincent Sanders and Samuel Ortiz and lkml to cc, as
suggested from Paul Mundt.
arch/powerpc/boot/dts/charon.dts | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts
index 9776889..d9af022 100644
--- a/arch/powerpc/boot/dts/charon.dts
+++ b/arch/powerpc/boot/dts/charon.dts
@@ -186,6 +186,7 @@
#address-cells = <2>;
#size-cells = <1>;
ranges = < 0 0 0xfc000000 0x02000000
+ 1 0 0xe0000000 0x04000000 // CS1 range, SM501
3 0 0xe8000000 0x00080000>;
flash@0,0 {
@@ -197,6 +198,14 @@
#address-cells = <1>;
};
+ display@1,0 {
+ compatible = "smi,sm501";
+ reg = <1 0x00000000 0x00800000
+ 1 0x03e00000 0x00200000>;
+ mode = "640x480-32@60";
+ interrupts = <1 1 3>;
+ };
+
mram0@3,0 {
compatible = "mtd-ram";
reg = <3 0x00000 0x80000>;
--
1.7.2.3
^ permalink raw reply related
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-11 9:14 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101210115639.08d37db9@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/10 18:56:39:
>
> On Fri, 10 Dec 2010 13:39:01 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 23:25:59:
> > >
> > > On Wed, 8 Dec 2010 17:02:45 -0500
> > > Mark Mason <mason@postdiluvian.org> wrote:
> > >
> > > > I don't think that using a software NAND controller instead of the LBC
> > > > FCM mode is all that bad. Again, I haven't actually done it, so check
> > > > the MTD docs, but I'm pretty sure the software is meant to do that, so
> > > > it doesn't even really constitute a "fix". Assuming that it is
> > > > supported then I doubt that configuring the NAND layer to use your
> > > > setup would be any harder than configuring the FCM.
> > >
> > > The MTD layer supports some really simple NAND controllers, but what do
> > > you mean by not having a controller at all? Hooking everything up to
> > > GPIO? Using UPM?
> > >
> > > There is already a UPM NAND driver, BTW.
> > >
> > > You would lose hardware ECC and the ability to be interrupt-driven (the
> > > latter should be possible with SW changes, using GPIO interrupts).
> >
> > hmm, you think it would be possible to use one of the IRQ pins instead?
>
> GPIO should be fine, software just needs to be changed to use the
> interrupt functionality.
>
> An external IRQ line would let you limit interrupts to rising edges
> rather than all edges, though you'd lose the ability to directly read
> the line status.
oh, one cannot read the IRQ line? didn't know that. Also I not sure
all Freescale CPUs can do rising edge.
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2010-12-11 17:53 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <20101210224402.GA8943@kroah.com>
On Fri, Dec 10, 2010 at 2:44 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Dec 08, 2010 at 04:28:59PM -0800, tmarri@apm.com wrote:
>> From: Tirumala Marri <tmarri@apm.com>
>>
>> v6:
>> =A01. Replaced register definitions and bit fields with macros.
>> =A02. Replace printks with dev_dbg or dev_err functions.
>> =A03. Cleanup some assignments.
>> =A04. Remove chip specific selections in Kconfig file.
>
> There are still a lot of checkpatch errors and warnings in these
> patches. =A0Patch 1-8 has:
> =A0 =A0 =A0 =A0total: 64 errors, 126 warnings, 13905 lines checked
>
> Care to fix all of these up in your next submission? =A0I can't take thes=
e
> as-is, sorry.
>
> And, if you haven't run checkpatch.pl before, odds are you haven't run
> 'sparse'. =A0Please run that as well and resolve the issues it finds.
>
> thanks,
>
> greg k-h
>
I will fix the all these errors. Also will run use the sparse tool .
Regards,
Marri
^ permalink raw reply
* Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
From: Randy Dunlap @ 2010-12-11 18:28 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, linuxppc-dev
In-Reply-To: <1292049075-1809-1-git-send-email-hs@denx.de>
On Sat, 11 Dec 2010 07:31:15 +0100 Heiko Schocher wrote:
> - add commandline options:
> sm501.fb_mode:
sm501.mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> ---
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index cdd2a6e..6341541 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2301,6 +2301,13 @@ and is between 256 and 4096 characters. It is defined in the file
> merging on their own.
> For more information see Documentation/vm/slub.txt.
>
> + sm501.bpp= SM501 Display driver:
> + Specify bit-per-pixel if not specified mode
Specifiy bits-per-pixel if not specified by 'mode'
> +
> + sm501fb.mode= SM501 Display driver:
> + Specify resolution as
> + "<xres>x<yres>[-<bpp>][@<refresh>]"
> +
> smart2= [HW]
> Format: <io1>[,<io2>[,...,<io8>]]
However, I think that these shouldn't be added to Documentation/kernel-parameters.txt
but should be added to the Documentation/fb/ sub-directory either by adding to
Documentation/fb/modedb.txt or by adding a new file Documentation/fb/sm501.txt.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* RE: [PATCH -mm 4/4] RapidIO: Add new sysfs attributes
From: Bounine, Alexandre @ 2010-12-11 18:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20101210152233.3786b432.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
>=20
> One would like to see documentation updates along with sysfs API
> updates. But one fears that this entire interface wasn't documented
> anyway :(
I think I have to find a time for that. I am adding it into my TODO
list.
=20
> Please at least fully describe the proposed interface in the changelog
> so others can review the proposal.
Will do.
=20
> The proposed new sysfs files appear to break the
> one-value-per-sysfs-file rule.
This is true for two of them. I was trying to find a better format for
them and at the end decided to break a rule and use port-device format
for this first version.
I may use just device name but "lnext" has to show multiple devices
anyway.
I decided the one-value-per-sysfs-file rule because it was broken once
already by the "routes" attribute (lprev and lnext have a similar
format).
^ permalink raw reply
* RE: [PATCH -mm 0/4] RapidIO: Misc updates
From: Bounine, Alexandre @ 2010-12-11 19:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20101210151924.333afed7.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> I held
> rapidio-use-common-destid-storage-for-endpoints-and-switches.patch and
> rapidio-integrate-rio_switch-into-rio_dev.patch back from 2.6.37 due
to
> ongoing discussion. What is the situation now?
Sorry, it took me too long to do this follow-up.
Patches in this set are direct product of that discussion and address
the issue of unified switch identification brought by Micha Nelissen.
The implementation is different from what he would like to see but I
prefer to have minimal changes to the code combined with enough
flexibility to enable proprietary implementations if such are required.
Besides that discussion, I did not receive any complaints about the
changes that you are referencing above.
=20
^ permalink raw reply
* Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
From: Randy Dunlap @ 2010-12-11 22:34 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, linuxppc-dev
In-Reply-To: <1292049075-1809-1-git-send-email-hs@denx.de>
On Sat, 11 Dec 2010 07:31:15 +0100 Heiko Schocher wrote:
> - add commandline options:
> sm501.fb_mode:
sm501.mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> ---
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index cdd2a6e..6341541 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2301,6 +2301,13 @@ and is between 256 and 4096 characters. It is defined in the file
> merging on their own.
> For more information see Documentation/vm/slub.txt.
>
> + sm501.bpp= SM501 Display driver:
> + Specify bit-per-pixel if not specified mode
Specifiy bits-per-pixel if not specified by 'mode'
> +
> + sm501fb.mode= SM501 Display driver:
Shouldn't that be sm501.mode ?
> + Specify resolution as
> + "<xres>x<yres>[-<bpp>][@<refresh>]"
> +
> smart2= [HW]
> Format: <io1>[,<io2>[,...,<io8>]]
However, I think that these shouldn't be added to Documentation/kernel-parameters.txt
but should be added to the Documentation/fb/ sub-directory either by adding to
Documentation/fb/modedb.txt or by adding a new file Documentation/fb/sm501.txt.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, mpc5200: update defconfig to fit with 2.6.37-rc4
From: Wolfram Sang @ 2010-12-12 8:47 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <1292047981-1435-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]
On Sat, Dec 11, 2010 at 07:13:00AM +0100, Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
I'd say the two patches can be merged. Dunno what Grant prefers whom you should
CC as he is the maintainer.
> cc: Wolfram Sang <w.sang@pengutronix.de>
> cc: linuxppc-dev@lists.ozlabs.org
> ---
> - based against 2.6.37-rc4
> - I did the following steps to generate this patch:
>
> make mpc5200_defconfig
> make savedefconfig
> cp ./defconfig arch/powerpc/configs/mpc5200_defconfig
>
> arch/powerpc/configs/mpc5200_defconfig | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/configs/mpc5200_defconfig b/arch/powerpc/configs/mpc5200_defconfig
> index 7376e27..6f75623 100644
> --- a/arch/powerpc/configs/mpc5200_defconfig
> +++ b/arch/powerpc/configs/mpc5200_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_EXPERIMENTAL=y
> CONFIG_SYSVIPC=y
> +CONFIG_SPARSE_IRQ=y
> CONFIG_LOG_BUF_SHIFT=14
> CONFIG_BLK_DEV_INITRD=y
> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> @@ -20,7 +21,6 @@ CONFIG_PPC_BESTCOMM=y
> CONFIG_SIMPLE_GPIO=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> -CONFIG_SPARSE_IRQ=y
> CONFIG_PM=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> @@ -52,7 +52,6 @@ CONFIG_PROC_DEVICETREE=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=32768
> -CONFIG_EEPROM_AT24=y
NACK.
> CONFIG_SCSI_TGT=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_CHR_DEV_SG=y
> @@ -114,7 +113,6 @@ CONFIG_RTC_DRV_DS1307=y
> CONFIG_EXT2_FS=y
> CONFIG_EXT3_FS=y
> # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
> -CONFIG_INOTIFY=y
Are you sure?
> CONFIG_MSDOS_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_PROC_KCORE=y
> @@ -132,5 +130,4 @@ CONFIG_PRINTK_TIME=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DETECT_HUNG_TASK=y
> CONFIG_DEBUG_INFO=y
> -# CONFIG_RCU_CPU_STALL_DETECTOR is not set
> # CONFIG_CRYPTO_ANSI_CPRNG is not set
> --
> 1.7.2.3
>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH -mm 4/4] RapidIO: Add new sysfs attributes
From: Greg KH @ 2010-12-12 18:48 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linux-kernel, Thomas Moll, akpm, linuxppc-dev
In-Reply-To: <1292013498-31406-5-git-send-email-alexandre.bounine@idt.com>
On Fri, Dec 10, 2010 at 03:38:18PM -0500, Alexandre Bounine wrote:
> Add new sysfs attributes.
Like Andrew pointed out, all sysfs files are required to have entries in
Documentation/ABI. If the existing rapidio sysfs files are not
documented, please document them in there _before_ adding new ones.
thanks,
greg k-h
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-12 21:46 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012101721.03689.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Fri, 2010-12-10 at 17:21 +0100, Guillaume Dargaud wrote:
> Hello all,
>
> > Also turn on CONFIG_DEBUG_DRIVER and see if that gives you anything
> > interesting.
>
> I see an unset CONFIG_DEBUG_KERNEL but no CONFIG_DEBUG_DRIVER in the .config of
> my current kernel.
Right you'd need to turn on CONFIG_DEBUG_KERNEL first, and then
CONFIG_DEBUG_DRIVER will appear.
> Does it need to be changed in the .config with a full kernel recompilation, or
> can I still benefit from it in my module only by doing a #define at the begining
> of my code ? Some #defines like DEBUG seem to work locally on things like
> dev_dbg but I doubt the CONFIG_* work the same...
No you'd need to rebuild your kernel. DEBUG is the only #define I can
think of that has an effect locally. Using different values for a
CONFIG_ in the kernel vs modules will not work.
> > Er. Not sure sorry. I can't see anything obviously wrong. Maybe post
> > your driver code again.
>
> Err... I ran it again this morning and it worked farther. I now get into the
> probe function and can now register my interrupt, yeah!, but I don't see the
> ISR being called. I'm currently checking if it can be a hardware problem
> before coming back here for more questions !
Great!
> BTW, is errno/strerror used within the kernel ?
Nope.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] powerpc/pseries: Fix VPHN build errors on non-SMP systems
From: Jesse Larrew @ 2010-12-12 23:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: markn, tbreeds, lkessler, Jesse Larrew, mjwolf
From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
The VPHN feature is only meaningful on NUMA systems that implement
the SPLPAR option, so exclude the VPHN code on systems without
SPLPAR enabled.
This patch fixes a build problem on non-SMP systems introduced by the
following commits:
3b7a27db3b6b5501e3d1c1628e6d5a547ffe76c6
9eff1a38407c051273fe1a20f03f8155bd32de35
Signed-off-by: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/topology.h | 20 +++++++++++---------
arch/powerpc/mm/numa.c | 3 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index aed188b..a2832b8 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -93,9 +93,20 @@ extern void __init dump_numa_cpu_topology(void);
extern int sysfs_add_device_to_node(struct sys_device *dev, int nid);
extern void sysfs_remove_device_from_node(struct sys_device *dev, int nid);
+#ifdef CONFIG_SPLPAR
extern int start_topology_update(void);
extern int stop_topology_update(void);
#else
+static inline int start_topology_update(void)
+{
+ return 0;
+}
+static inline int stop_topology_update(void)
+{
+ return 0;
+}
+#endif /* CONFIG_SPLPAR */
+#else
static inline void dump_numa_cpu_topology(void) {}
@@ -108,15 +119,6 @@ static inline void sysfs_remove_device_from_node(struct sys_device *dev,
int nid)
{
}
-
-static inline int start_topology_update(void)
-{
- return 0;
-}
-static inline int stop_topology_update(void)
-{
- return 0;
-}
#endif /* CONFIG_NUMA */
#include <asm-generic/topology.h>
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 42aa7d1..0f50941 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -28,6 +28,7 @@
#include <asm/smp.h>
#include <asm/firmware.h>
#include <asm/paca.h>
+#include <asm/hvcall.h>
static int numa_enabled = 1;
@@ -1263,6 +1264,7 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
#endif /* CONFIG_MEMORY_HOTPLUG */
/* Vrtual Processor Home Node (VPHN) support */
+#ifdef CONFIG_SPLPAR
#define VPHN_NR_CHANGE_CTRS (8)
static u8 vphn_cpu_change_counts[NR_CPUS][VPHN_NR_CHANGE_CTRS];
static cpumask_t cpu_associativity_changes_mask;
@@ -1505,3 +1507,4 @@ int stop_topology_update(void)
vphn_enabled = 0;
return del_timer_sync(&topology_timer);
}
+#endif /* CONFIG_SPLPAR */
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
From: Heiko Schocher @ 2010-12-13 7:01 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, linuxppc-dev
In-Reply-To: <20101211143454.ccc5e296.rdunlap@xenotime.net>
Hello Randy,
Randy Dunlap wrote:
> On Sat, 11 Dec 2010 07:31:15 +0100 Heiko Schocher wrote:
>
>> - add commandline options:
>> sm501.fb_mode:
>
> sm501.mode:
Sorry, type, should be "sm501fb.mode", thanks!
>> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
>> sm501.bpp:
Here too, "sm501fb.bpp"
>> Specify bit-per-pixel if not specified mode
>>
>> ---
>>
>> Documentation/kernel-parameters.txt | 7 +
>> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
>> drivers/mfd/sm501.c | 141 ++++++++------
>> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
>> include/linux/sm501.h | 8 +
>> 5 files changed, 299 insertions(+), 151 deletions(-)
>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index cdd2a6e..6341541 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2301,6 +2301,13 @@ and is between 256 and 4096 characters. It is defined in the file
>> merging on their own.
>> For more information see Documentation/vm/slub.txt.
>>
>> + sm501.bpp= SM501 Display driver:
>> + Specify bit-per-pixel if not specified mode
>
> Specifiy bits-per-pixel if not specified by 'mode'
>
>> +
>> + sm501fb.mode= SM501 Display driver:
>
> Shouldn't that be sm501.mode ?
No, the name of the source file is sm501fb.c -> sm501fb is right here.
As the sm501 is a multifunction device, the "fb" is more precise here.
>> + Specify resolution as
>> + "<xres>x<yres>[-<bpp>][@<refresh>]"
>> +
>> smart2= [HW]
>> Format: <io1>[,<io2>[,...,<io8>]]
>
>
> However, I think that these shouldn't be added to Documentation/kernel-parameters.txt
> but should be added to the Documentation/fb/ sub-directory either by adding to
> Documentation/fb/modedb.txt or by adding a new file Documentation/fb/sm501.txt.
Ok, do this. Thanks for the review!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, mpc5200: update defconfig to fit with 2.6.37-rc4
From: Heiko Schocher @ 2010-12-13 7:09 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101212084707.GA14580@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Sat, Dec 11, 2010 at 07:13:00AM +0100, Heiko Schocher wrote:
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>
> I'd say the two patches can be merged. Dunno what Grant prefers whom you should
> CC as he is the maintainer.
I prefer the split in two patches, so we can see, what is added
by the charon board, and what by "make mpc5200_defconfig" ...
>> cc: Wolfram Sang <w.sang@pengutronix.de>
>> cc: linuxppc-dev@lists.ozlabs.org
>> ---
>> - based against 2.6.37-rc4
>> - I did the following steps to generate this patch:
>>
>> make mpc5200_defconfig
>> make savedefconfig
>> cp ./defconfig arch/powerpc/configs/mpc5200_defconfig
>>
>> arch/powerpc/configs/mpc5200_defconfig | 5 +----
>> 1 files changed, 1 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/powerpc/configs/mpc5200_defconfig b/arch/powerpc/configs/mpc5200_defconfig
>> index 7376e27..6f75623 100644
>> --- a/arch/powerpc/configs/mpc5200_defconfig
>> +++ b/arch/powerpc/configs/mpc5200_defconfig
>> @@ -1,5 +1,6 @@
>> CONFIG_EXPERIMENTAL=y
>> CONFIG_SYSVIPC=y
>> +CONFIG_SPARSE_IRQ=y
>> CONFIG_LOG_BUF_SHIFT=14
>> CONFIG_BLK_DEV_INITRD=y
>> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
>> @@ -20,7 +21,6 @@ CONFIG_PPC_BESTCOMM=y
>> CONFIG_SIMPLE_GPIO=y
>> CONFIG_NO_HZ=y
>> CONFIG_HIGH_RES_TIMERS=y
>> -CONFIG_SPARSE_IRQ=y
>> CONFIG_PM=y
>> CONFIG_NET=y
>> CONFIG_PACKET=y
>> @@ -52,7 +52,6 @@ CONFIG_PROC_DEVICETREE=y
>> CONFIG_BLK_DEV_LOOP=y
>> CONFIG_BLK_DEV_RAM=y
>> CONFIG_BLK_DEV_RAM_SIZE=32768
>> -CONFIG_EEPROM_AT24=y
>
> NACK.
... I did just the steps above mentioned, so this is
automagically done by "make mpc5200_defconfig" !
>> CONFIG_SCSI_TGT=y
>> CONFIG_BLK_DEV_SD=y
>> CONFIG_CHR_DEV_SG=y
>> @@ -114,7 +113,6 @@ CONFIG_RTC_DRV_DS1307=y
>> CONFIG_EXT2_FS=y
>> CONFIG_EXT3_FS=y
>> # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
>> -CONFIG_INOTIFY=y
>
> Are you sure?
See comment above, did just the "make mpc5200_defconfig"
step ...
>> CONFIG_MSDOS_FS=y
>> CONFIG_VFAT_FS=y
>> CONFIG_PROC_KCORE=y
>> @@ -132,5 +130,4 @@ CONFIG_PRINTK_TIME=y
>> CONFIG_DEBUG_KERNEL=y
>> CONFIG_DETECT_HUNG_TASK=y
>> CONFIG_DEBUG_INFO=y
>> -# CONFIG_RCU_CPU_STALL_DETECTOR is not set
>> # CONFIG_CRYPTO_ANSI_CPRNG is not set
>> --
>> 1.7.2.3
Thanks for the review!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* RE: [PATCH v5] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-12-13 7:17 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101210133905.GE1903@zod.rchland.ibm.com>
>This can fail if you boot a new kernel on a board with an old FDT that
lacks the gpio node. Calling of_iomap with a NULL np seems like it would
work without crashing anything, so maybe that's not a huge issue.
>>+ vaddr = of_iomap(np, 0);
>>+ if (!vaddr) {
>>+ printk(KERN_CRIT "Could not get gpio node address\n");
>>+ ret = -ENODEV;
>>+ goto err_bcsr;
>>+ }
>A reference count is leaked for the node in this error case because
of_node_put isn't called for the gpio node. Also, iounmap is never called
on vaddr.
>>+ /* Disable USB, through the BCSR7 bits */
Thanks for your inputs. I will fix and resubmit.
Regards,
Rup
^ permalink raw reply
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: K.Prasad @ 2010-12-13 8:26 UTC (permalink / raw)
To: Andreas Schwab
Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <20101201043758.GA2219@in.ibm.com>
On Wed, Dec 01, 2010 at 10:07:58AM +0530, K.Prasad wrote:
> On Mon, Nov 29, 2010 at 11:15:51AM +0100, Andreas Schwab wrote:
> > "K.Prasad" <prasad@linux.vnet.ibm.com> writes:
> >
> > > Although ppc_set_hwdebug() can set DABR through set_dabr() in
> > > arch/powerpc/kernel/process.c, it is good to have it converted to use
> > > register_user_hw_breakpoint().
> >
> > What do you mean with "good to have"? It doesn't work without it unless
> > I disable PERF_EVENTS (which is the only way to disable
> > HAVE_HW_BREAKPOINT).
> >
> > Andreas.
> >
>
> Let me see if I can cook up a patch for this i.e. make set_dabr() invoke
> register_user_hw_breakpoint() when CONFIG_PPC_BOOK3S is defined; before I
> head out on my vacation (starting second week of this month).
>
> Thanks,
> K.Prasad
>
Hi,
Can you check if the following patch (compile tested only) works
for you?
Thanks,
K.Prasad
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
Index: linux-2.6.set_hwdebug/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6.set_hwdebug.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6.set_hwdebug/arch/powerpc/kernel/ptrace.c
@@ -1316,6 +1316,11 @@ static int set_dac_range(struct task_str
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
if (bp_info->version != 1)
return -ENOTSUPP;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
@@ -1362,10 +1367,29 @@ static long ppc_set_hwdebug(struct task_
if (child->thread.dabr)
return -ENOSPC;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (child->thread->ptrace_bps[0])
+ return -ENOSPC;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(bp_info->addr &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ bp = register_user_hw_breakpoint(&attr, ptrace_triggered, task);
+ if (IS_ERR(bp))
+ return PTR_ERR(bp);
+
+ child->thread.ptrace_bps[0] = bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
child->thread.dabr = (unsigned long)bp_info->addr;
return 1;
@@ -1395,6 +1419,16 @@ static long ppc_del_hwdebug(struct task_
return -EINVAL;
if (child->thread.dabr == 0)
return -ENOENT;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /*
+ * There is no way by which address in ptrace_bps[0] and thread.dabr
+ * can be different. So we don't explicitly check if they're the same
+ */
+ if (child->thread.ptrace_bps[0]) {
+ unregister_hw_breakpoint(child->thread.ptrace_bps[0]);
+ child->thread.ptrace_bps[0] = NULL;
+ }
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
child->thread.dabr = 0;
^ permalink raw reply
* RE: MPC831x (and others?) NAND erase performance improvements
From: David Laight @ 2010-12-13 8:33 UTC (permalink / raw)
To: Joakim Tjernlund, Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OF51D61C57.96435CC9-ONC12577F6.00326299-C12577F6.0032BA93@transmode.se>
=20
> > An external IRQ line would let you limit interrupts to rising edges
> > rather than all edges, though you'd lose the ability to=20
> > directly read the line status.
>=20
> oh, one cannot read the IRQ line? didn't know that. Also I not sure
> all Freescale CPUs can do rising edge.
I suspect that you may be able to leave the interupt masked, but still
read the 'interrupt pending' register. Which would have the same effect.
Our HW engineers tend to feed everything into an FPGA since it
gives than a lot more flexibility over pin connections.
In which case the invertor is trivial.
(and the fpga interface can read the status!)
David
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, mpc5200: update defconfig to fit with 2.6.37-rc4
From: Wolfram Sang @ 2010-12-13 10:06 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <4D05C68F.4030600@denx.de>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi Heiko,
> >> -CONFIG_EEPROM_AT24=y
> >
> > NACK.
>
> ... I did just the steps above mentioned, so this is
> automagically done by "make mpc5200_defconfig" !
Yes, I understood that, but I can't help it: it is still wrong. I need
it.
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc, mpc5200: update defconfig to fit with 2.6.37-rc4
From: Heiko Schocher @ 2010-12-13 10:12 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20101213100647.GA5911@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> Hi Heiko,
>
>>>> -CONFIG_EEPROM_AT24=y
>>> NACK.
>> ... I did just the steps above mentioned, so this is
>> automagically done by "make mpc5200_defconfig" !
>
> Yes, I understood that, but I can't help it: it is still wrong. I need
> it.
Ok, than we need to look why "make mpc5200_defconfig" did this ...
I try to look at this point.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* RE: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-13 10:32 UTC (permalink / raw)
To: David Laight; +Cc: Mark Mason, Scott Wood, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8ABFB@saturn3.aculab.com>
"David Laight" <David.Laight@ACULAB.COM> wrote on 2010/12/13 09:33:37:
>
>
> > > An external IRQ line would let you limit interrupts to rising edges
> > > rather than all edges, though you'd lose the ability to
> > > directly read the line status.
> >
> > oh, one cannot read the IRQ line? didn't know that. Also I not sure
> > all Freescale CPUs can do rising edge.
>
> I suspect that you may be able to leave the interupt masked, but still
> read the 'interrupt pending' register. Which would have the same effect.
Ah, that should work too. I should be able to read the 'interrupt pending'
register at all times, even when it isn't masked.
What if one has several NAND chips to build a big FS? Is the NAND
controller equipped to handle that?
>
> Our HW engineers tend to feed everything into an FPGA since it
> gives than a lot more flexibility over pin connections.
> In which case the invertor is trivial.
> (and the fpga interface can read the status!)
Yes, but not all of our boards have FPGA and we load the FPGA
from the SW so it is a chicken and egg problem for us.
Jocke
^ permalink raw reply
* RE: [PATCH -mm 4/4] RapidIO: Add new sysfs attributes
From: Bounine, Alexandre @ 2010-12-13 13:55 UTC (permalink / raw)
To: Greg KH; +Cc: akpm, linuxppc-dev, linux-kernel, Thomas Moll
In-Reply-To: <20101212184834.GA17052@kroah.com>
Greg KH wrote:
>=20
> Like Andrew pointed out, all sysfs files are required to have entries
in
> Documentation/ABI. If the existing rapidio sysfs files are not
> documented, please document them in there _before_ adding new ones.
>=20
I included RapidIO documentation update into my plan for next set of
RapidIO patches. Until than this patch may be safely dropped without
affecting other patches in this set.
Alex. =20
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Neil Jones @ 2010-12-13 15:48 UTC (permalink / raw)
To: Greg KH; +Cc: tmarri, linux-usb, linuxppc-dev
In-Reply-To: <20101210224402.GA8943@kroah.com>
Hi,
We are currently using the latest version of this Synopsis IP in some
of our customers SoC's.
The latest hardware adds a new DMA mode which is less Interrupt
intensive as well as a few other features.
I have spent (and im still spending) a long time fixing up this driver
to be linux standards compliant with the intention of pushing it
upstream once complete, its still not ready yet.
One of the major issues we had is the driver isn't SMP safe, I've not
had chance to review your patches yet but have your run the driver
with lock checking turned on ?
Would it be possible to get the changes for the latest version of the
IP merged into this driver, I can supply my current version as a
reference.
In my driver :
Currently host support is working well and i've tested it with
multiple devices and done the test outlined on
http://www.linux-usb.org/usbtest/, the driver passed checkpatches and
runs with lockdeps on and on a SMP system, Im still working on the
device mode (PCD) part of the driver generally it works, but im still
getting the odd lock dep warning and a panic on un-loading of certain
gadget kernel modules. The only issue with our driver is I have not
converted all the bitfield usage to macros so it might make diffing a
pain.
Cheers
Neil
On Fri, Dec 10, 2010 at 10:44 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Dec 08, 2010 at 04:28:59PM -0800, tmarri@apm.com wrote:
>> From: Tirumala Marri <tmarri@apm.com>
>>
>> v6:
>> =C2=A01. Replaced register definitions and bit fields with macros.
>> =C2=A02. Replace printks with dev_dbg or dev_err functions.
>> =C2=A03. Cleanup some assignments.
>> =C2=A04. Remove chip specific selections in Kconfig file.
>
> There are still a lot of checkpatch errors and warnings in these
> patches. =C2=A0Patch 1-8 has:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0total: 64 errors, 126 warnings, 13905 lines ch=
ecked
>
> Care to fix all of these up in your next submission? =C2=A0I can't take t=
hese
> as-is, sorry.
>
> And, if you haven't run checkpatch.pl before, odds are you haven't run
> 'sparse'. =C2=A0Please run that as well and resolve the issues it finds.
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-13 17:33 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, David Laight, linuxppc-dev
In-Reply-To: <OF4BAAB822.8E759F4C-ONC12577F8.00393E37-C12577F8.0039DC9E@transmode.se>
On Mon, 13 Dec 2010 11:32:00 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> "David Laight" <David.Laight@ACULAB.COM> wrote on 2010/12/13 09:33:37:
> >
> >
> > > > An external IRQ line would let you limit interrupts to rising edges
> > > > rather than all edges, though you'd lose the ability to
> > > > directly read the line status.
> > >
> > > oh, one cannot read the IRQ line? didn't know that.
> > > Also I not sure all Freescale CPUs can do rising edge.
Ah right, 83xx has IPIC rather than MPIC.
> > I suspect that you may be able to leave the interupt masked, but still
> > read the 'interrupt pending' register. Which would have the same effect.
>
> Ah, that should work too. I should be able to read the 'interrupt pending'
> register at all times, even when it isn't masked.
This could work OK if you have board logic to invert the signal.
> What if one has several NAND chips to build a big FS? Is the NAND
> controller equipped to handle that?
FCM can drive one NAND chip per eLBC chipselect, though possibly you
could go beyond that with a board-logic chipselect mechanism.
-Scott
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-13 17:41 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, David Laight, linuxppc-dev
In-Reply-To: <20101213113356.1596c6a6@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:33:56:
>
> On Mon, 13 Dec 2010 11:32:00 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > "David Laight" <David.Laight@ACULAB.COM> wrote on 2010/12/13 09:33:37:
> > >
> > >
> > > > > An external IRQ line would let you limit interrupts to rising edges
> > > > > rather than all edges, though you'd lose the ability to
> > > > > directly read the line status.
> > > >
> > > > oh, one cannot read the IRQ line? didn't know that.
> > > > Also I not sure all Freescale CPUs can do rising edge.
>
> Ah right, 83xx has IPIC rather than MPIC.
>
> > > I suspect that you may be able to leave the interupt masked, but still
> > > read the 'interrupt pending' register. Which would have the same effect.
> >
> > Ah, that should work too. I should be able to read the 'interrupt pending'
> > register at all times, even when it isn't masked.
>
> This could work OK if you have board logic to invert the signal.
yeah, just a NAND gate :)
>
> > What if one has several NAND chips to build a big FS? Is the NAND
> > controller equipped to handle that?
>
> FCM can drive one NAND chip per eLBC chipselect, though possibly you
> could go beyond that with a board-logic chipselect mechanism.
hmm, then I guess one would have to use one GPIO/IRQ per NAND chip?
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-13 17:51 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, David Laight, linuxppc-dev
In-Reply-To: <OF45E5CF67.CA505B87-ONC12577F8.00610A85-C12577F8.00612FDB@transmode.se>
On Mon, 13 Dec 2010 18:41:32 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:33:56:
> >
> > On Mon, 13 Dec 2010 11:32:00 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > What if one has several NAND chips to build a big FS? Is the NAND
> > > controller equipped to handle that?
> >
> > FCM can drive one NAND chip per eLBC chipselect, though possibly you
> > could go beyond that with a board-logic chipselect mechanism.
>
> hmm, then I guess one would have to use one GPIO/IRQ per NAND chip?
Couldn't you just tie together all the open-drain busy lines before you
invert it? You'll only be driving one NAND chip at a time anyway; the
others should not be asserting busy.
-Scott
^ permalink raw reply
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: Andreas Schwab @ 2010-12-13 19:05 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <20101213082619.GA6582@in.ibm.com>
"K.Prasad" <prasad@linux.vnet.ibm.com> writes:
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + /* Create a new breakpoint request if one doesn't exist already */
> + hw_breakpoint_init(&attr);
> + attr.bp_addr = bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> + arch_bp_generic_fields(bp_info->addr &
> + (DABR_DATA_WRITE | DABR_DATA_READ),
> + &attr.bp_type);
> +
> + bp = register_user_hw_breakpoint(&attr, ptrace_triggered, task);
> + if (IS_ERR(bp))
> + return PTR_ERR(bp);
> +
> + child->thread.ptrace_bps[0] = bp;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> +
> child->thread.dabr = (unsigned long)bp_info->addr;
That cannot work, see
<http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/71418>.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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