* Re: [PATCH] PCI / ACPI: Make acpiphp ignore root bridges using PCIe native hotplug
From: Yinghai Lu @ 2011-10-22 21:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PCI, Jesse Barnes, LKML, Linux PM list,
ACPI Devel Mailing List, Matthew Garrett
In-Reply-To: <201110220043.38635.rjw@sisk.pl>
On Fri, Oct 21, 2011 at 3:43 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> If the kernel has requested control of the PCIe native hotplug
> feature for a given root complex, the acpiphp driver should not try
> to handle that root complex and it should leave it to pciehp.
> Failing to do so causes problems to happen if acpiphp is loaded
> before pciehp on such systems.
Should pciehp be built-in kernel instead of as a module?
Yinghai
^ permalink raw reply
* [U-Boot] A bit about board.c, board.c
From: Graeme Russ @ 2011-10-22 21:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA3388D.2080906@gmail.com>
Hi Simon,
On 23/10/11 08:41, Graeme Russ wrote:
> Hi Simon,
>
>
> On 23/10/11 03:36, Simon Glass wrote:
>> Hi Graeme,
[snip]
>>> I vote to pick an arch, convert it to a unified style and move it to
>>> lib/board.c and then merge each arch over. This should be done in a single
>>> series rather than the ol' 'migrate over time' which never happens.
>>
>> I thing you mean merge each arch over in its own series?
I mean merge all arches in one series
>>> x86 is a good arch to start with because the number of boards is so small
>>> (1)
>>>
>>> Also, I'd personally like the init sequence patches I posted earlier to be
>>> re-examined
>>
>> I already examined and thought it was good. Let's be careful to keep
>> it simple in the sense that we only need a very small number of init
>> functions. Most of the board_init_r() code should not be there as I
>> understand it (e.g. on ARM MMC, USB, NAND should be inited if/when
>> used and not before). Need to be careful not to confuse this bit with
>> driver init or any refactor of the driver model. So we have things
>> like
My biggest gripe with the init code is the lack of consistency. There are
two prime examples of this:
1) The pre-relocation sequence and post-relocation sequences can be
implemented using identical code (a sequence loop) - x86 almost gets there,
other arches only loop for one, and have sequential logic for the other
2) Even with the init loop, there is a lot of sequential code after the
loop that could be merged into the loop
>> - init memory and make it so we can relocate code, etc. (this is
>> called from start.S at present)
>> - init the CPU core
>> - arch init like turn off caches, MMU, flush TLBs, etc.
>> - early board init (hopefully just requires an initcall in board code if needed)
>> - the current init sequence like banner, serial, etc.
>> - relocate
>> - console init
>> - board_init (initcall in board code if needed)
>> - (hopefully all other post-relocation init can be punted)
>>
>> So board.c becomes a few functions and about a dozen initcalls. Albert
>> will want to use weak symbols instead of #ifdef, and we will be done.
The INIT_CALL approach eliminated this need - If the .c file does not get
compiled in, the INIT_CALL does not get included. And adding a new
INIT_CALL was as simple as including the macro in the .c file without
needing to mess with board.c at all - simple :)
INIT_CALL is a completely separate issue to what you are looking at and
would be easier to implement after board.c was merged into lib
Regard,
Graeme
^ permalink raw reply
* Congratulation!!! Money Is Awarded To You
From: Western Union© @ 2011-10-22 19:46 UTC (permalink / raw)
--
Dear Beneficiary,
The sum of $900,000.00USD has been deposited in your name here in the
western union office by Ecowas Organisation, you are to contact Mr. Tom
Carlson to collect your money transfer control number (M.T.C.N).
Contact email: customer.service.western.un@hotmail.com
Western Union©
Customer Service
^ permalink raw reply
* Re: Kernel driver r8169 not working for Realtek 8111E onboard network card
From: Francois Romieu @ 2011-10-22 21:44 UTC (permalink / raw)
To: Adrian George Sav; +Cc: netdev@vger.kernel.org
In-Reply-To: <1319296941.68390.YahooMailNeo@web161905.mail.bf1.yahoo.com>
Adrian George Sav <adi_sav@yahoo.com> :
[...]
> I am having trouble with the r8169 kernel driver for Realtek 8111E network
> card. The NIC works intermittently and horribly with this driver. Unusable.
>
> Below is my config. I am happy to provide any and every other necessary
> information to help in solving this.
Up to 2.6.39 ?
Your r8169 driver is too old. Please try current -rc and send your dmesg
including the XID line from the r8169 driver.
--
Ueimor
^ permalink raw reply
* [Bug 40507] NV50 multi GPU only one GPU is used by X
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-22 21:45 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-40507-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=40507
--- Comment #16 from Thomas van Gulick <thomas-OAIPNaC2qqLgjWiVKyS68A@public.gmane.org> 2011-10-22 14:45:26 PDT ---
Another intereseting note. Displaying an image to the device which X does not
recognize is no problem, using fbi on /dev/fb0, using nouveaufb.
Could be that it has nothing with the nouveau driver, but the way X initializes
nouveau, in which case this ticket should probably be moved to another section?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 06/14] ARM : SAMSUNG : S3C2416 Added io mapping for Static memory controller.
From: Heiko Stübner @ 2011-10-22 21:43 UTC (permalink / raw)
To: Paul Schilling
Cc: Kukjin Kim, Russell King, Yauhen Kharuzhy, Rafael J. Wysocki,
Greg Kroah-Hartman, linux-arm-kernel, linux-kernel
In-Reply-To: <1319257301-5040-1-git-send-email-paul.s.schilling@gmail.com>
Am Samstag 22 Oktober 2011, 06:21:41 schrieb Paul Schilling:
> Added MMU access to the Static Memory Controller.
>
> Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
> ---
> arch/arm/mach-s3c2416/s3c2416.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s3c2416/s3c2416.c
> b/arch/arm/mach-s3c2416/s3c2416.c index 494ce91..823a034 100644
> --- a/arch/arm/mach-s3c2416/s3c2416.c
> +++ b/arch/arm/mach-s3c2416/s3c2416.c
> @@ -65,6 +65,18 @@ static struct map_desc s3c2416_iodesc[] __initdata = {
> IODESC_ENT(WATCHDOG),
> IODESC_ENT(CLKPWR),
> IODESC_ENT(TIMER),
> + {
> + .virtual = (u32)S3C2412_VA_SSMC,
> + .pfn = __phys_to_pfn(S3C2412_PA_SSMC),
> + .length = SZ_1M,
> + .type = MT_DEVICE,
> + },
> + /*{
> + .virtual = (u32)S3C2412_VA_EBI,
> + .pfn = __phys_to_pfn(S3C2412_PA_EBI),
> + .length = SZ_1M,
> + .type = MT_DEVICE,
> + },*/
> };
why are you adding disabled code?
Btw. it seems your posts got mangled somehow... only your patches 2,5 and 6 of
14 made it to linux-kernel and linux-arm-kernel.
Heiko
^ permalink raw reply
* [PATCH 06/14] ARM : SAMSUNG : S3C2416 Added io mapping for Static memory controller.
From: Heiko Stübner @ 2011-10-22 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319257301-5040-1-git-send-email-paul.s.schilling@gmail.com>
Am Samstag 22 Oktober 2011, 06:21:41 schrieb Paul Schilling:
> Added MMU access to the Static Memory Controller.
>
> Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
> ---
> arch/arm/mach-s3c2416/s3c2416.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s3c2416/s3c2416.c
> b/arch/arm/mach-s3c2416/s3c2416.c index 494ce91..823a034 100644
> --- a/arch/arm/mach-s3c2416/s3c2416.c
> +++ b/arch/arm/mach-s3c2416/s3c2416.c
> @@ -65,6 +65,18 @@ static struct map_desc s3c2416_iodesc[] __initdata = {
> IODESC_ENT(WATCHDOG),
> IODESC_ENT(CLKPWR),
> IODESC_ENT(TIMER),
> + {
> + .virtual = (u32)S3C2412_VA_SSMC,
> + .pfn = __phys_to_pfn(S3C2412_PA_SSMC),
> + .length = SZ_1M,
> + .type = MT_DEVICE,
> + },
> + /*{
> + .virtual = (u32)S3C2412_VA_EBI,
> + .pfn = __phys_to_pfn(S3C2412_PA_EBI),
> + .length = SZ_1M,
> + .type = MT_DEVICE,
> + },*/
> };
why are you adding disabled code?
Btw. it seems your posts got mangled somehow... only your patches 2,5 and 6 of
14 made it to linux-kernel and linux-arm-kernel.
Heiko
^ permalink raw reply
* [U-Boot] A bit about board.c, board.c
From: Graeme Russ @ 2011-10-22 21:41 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ2AeXwhR+hAN9UGL1USuvCTtNHjJrXd-cyYRwm_zum6uw@mail.gmail.com>
Hi Simon,
On 23/10/11 03:36, Simon Glass wrote:
> Hi Graeme,
>
> Did you mean to send to list?
Oops, yes I did - Done now
> On Fri, Oct 21, 2011 at 10:49 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
>> Hi Simon
>>
>> On Oct 22, 2011 4:11 PM, "Simon Glass" <sjg@chromium.org> wrote:
>>>
>>> Hi,
>>>
>>> Each architecture has its own board.c but they are mostly quite similar.
>>>
>>> New features such as fdt, boot timing, trace, profiling, etc. must be
>>> done separately for each arch, even if there are no
>>> architecture-specific bits.
>>
>> Yes, it is a mess - something my unit sequence patches tried to clean up
>>
>>> What would you say to adding something like lib/board.c which is a
>>> simplified cleaned-up copy of one of the existing board.c files, and a
>>
>> 100% agree
>>
>>> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the
>>> architecture-specific one. Then perhaps people could try it out and we
>>> could slowly move to it over time...
>>
>> I vote to pick an arch, convert it to a unified style and move it to
>> lib/board.c and then merge each arch over. This should be done in a single
>> series rather than the ol' 'migrate over time' which never happens.
>
> I thing you mean merge each arch over in its own series?
>
>>
>> x86 is a good arch to start with because the number of boards is so small
>> (1)
>>
>> Also, I'd personally like the init sequence patches I posted earlier to be
>> re-examined
>
> I already examined and thought it was good. Let's be careful to keep
> it simple in the sense that we only need a very small number of init
> functions. Most of the board_init_r() code should not be there as I
> understand it (e.g. on ARM MMC, USB, NAND should be inited if/when
> used and not before). Need to be careful not to confuse this bit with
> driver init or any refactor of the driver model. So we have things
> like
>
> - init memory and make it so we can relocate code, etc. (this is
> called from start.S at present)
> - init the CPU core
> - arch init like turn off caches, MMU, flush TLBs, etc.
> - early board init (hopefully just requires an initcall in board code if needed)
> - the current init sequence like banner, serial, etc.
> - relocate
> - console init
> - board_init (initcall in board code if needed)
> - (hopefully all other post-relocation init can be punted)
>
> So board.c becomes a few functions and about a dozen initcalls. Albert
> will want to use weak symbols instead of #ifdef, and we will be done.
>
> Regards,
> Simon
>
>>
>> Regards,
>>
>> Graeme
>>
>
^ permalink raw reply
* Re: [PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)
From: Rafael J. Wysocki @ 2011-10-22 21:35 UTC (permalink / raw)
To: Christoph, Takashi Iwai
Cc: Theodore Ts'o, Linux PM list, LKML, xfs, Christoph Hellwig,
Nigel Cunningham, Pavel Machek, linux-fsdevel, linux-ext4
In-Reply-To: <4EA2DDD3.8080306@u-club.de>
On Saturday, October 22, 2011, Christoph wrote:
> > PM / Freezer: Freeze filesystems while freezing processes (v2)
> >
> > On Sunday, August 07, 2011, Dave Chinner wrote:
> >> On Sat, Aug 06, 2011 at 11:17:18PM +0200, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki <rjw@sisk.pl>
> >>>
> >>> Freeze all filesystems during the freezing of tasks by calling
> >>> freeze_bdev() for each of them and thaw them during the thawing of
> >>> tasks with the help of thaw_bdev().
> >>>
> >>> This is needed by hibernation, because some filesystems (e.g. XFS)
> >>> deadlock with the preallocation of memory used by it if the memory
> >>> pressure caused by it is too heavy.
> >>>
> ...
> >
> > Below is an alternative fix, the changelog pretty much explains the
> > idea.
> >
> > I've tested it on Toshiba Portege R500, but I don't have an XFS
> > partition to verify that it really helps, so I'd appreciate it if
> > someone able to reproduce the original issue could test it and report
> > back.
>
> Hi Rafael!
>
> Well, the kernel bugtracker is still down and I just like to post my
> experience with kernel (x64) v3.1-rc8/9 + patches. My machine is a
> MacBookPro, doomed with 4GB RAM running debian.
>
> Bug #1
>
> on the way to hibernate, machine hangs on
>
> "PM: Preallocating image memory..."
>
> this patch worked for me now for weeks:
> "[PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)"
> https://lkml.org/lkml/2011/9/24/77
This patch is going to be merged into 3.2.
> I was able to reproduce this bug with virtualbox and tested the patch ~40
> cycles.
>
> Bug#2
>
> on resume from hibernate, hard reset (x64 only):
> http://marc.info/?l=linux-kernel&m=131653513414314&w=2
>
> With this patch I haven't got this issue again the last weeks.
Hmm. This issue appears to be still under investigation to me, but perhaps
that's taken too much already.
Takashi, perhaps you can repost the patch as a proper submission? It would
be good to have this regression fixed even if we don't know the real source of
it.
> I wasn't able to reproduce this bug with virtualbox.
>
>
>
>
>
> I only got one pm-hibernate issue. Last line:
>
> Disabling non-boot CPUs ...
>
> This time I've enabled debug hung task :)
>
> schedule_timeout
> ...
> workqueue_cpu_callback
> notifier_call_chain
> ...
> __cpu_notify
> _cpu_down
> printk
> disable_nonboot_cpus
> hibernation_snapshot
> hibernate
> ...
>
> Any other idea besides the possibility it's caused by evil earth
> radiation, isn't it?
I'm not exactly sure what happened from your description, care to explain?
Rafael
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)
From: Rafael J. Wysocki @ 2011-10-22 21:35 UTC (permalink / raw)
To: Christoph, Takashi Iwai
Cc: Theodore Ts'o, LKML, xfs, Christoph Hellwig, Nigel Cunningham,
Pavel Machek, linux-fsdevel, linux-ext4, Linux PM list
In-Reply-To: <4EA2DDD3.8080306@u-club.de>
On Saturday, October 22, 2011, Christoph wrote:
> > PM / Freezer: Freeze filesystems while freezing processes (v2)
> >
> > On Sunday, August 07, 2011, Dave Chinner wrote:
> >> On Sat, Aug 06, 2011 at 11:17:18PM +0200, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki <rjw@sisk.pl>
> >>>
> >>> Freeze all filesystems during the freezing of tasks by calling
> >>> freeze_bdev() for each of them and thaw them during the thawing of
> >>> tasks with the help of thaw_bdev().
> >>>
> >>> This is needed by hibernation, because some filesystems (e.g. XFS)
> >>> deadlock with the preallocation of memory used by it if the memory
> >>> pressure caused by it is too heavy.
> >>>
> ...
> >
> > Below is an alternative fix, the changelog pretty much explains the
> > idea.
> >
> > I've tested it on Toshiba Portege R500, but I don't have an XFS
> > partition to verify that it really helps, so I'd appreciate it if
> > someone able to reproduce the original issue could test it and report
> > back.
>
> Hi Rafael!
>
> Well, the kernel bugtracker is still down and I just like to post my
> experience with kernel (x64) v3.1-rc8/9 + patches. My machine is a
> MacBookPro, doomed with 4GB RAM running debian.
>
> Bug #1
>
> on the way to hibernate, machine hangs on
>
> "PM: Preallocating image memory..."
>
> this patch worked for me now for weeks:
> "[PATCH] PM / Freezer: Freeze filesystems while freezing processes (v2)"
> https://lkml.org/lkml/2011/9/24/77
This patch is going to be merged into 3.2.
> I was able to reproduce this bug with virtualbox and tested the patch ~40
> cycles.
>
> Bug#2
>
> on resume from hibernate, hard reset (x64 only):
> http://marc.info/?l=linux-kernel&m=131653513414314&w=2
>
> With this patch I haven't got this issue again the last weeks.
Hmm. This issue appears to be still under investigation to me, but perhaps
that's taken too much already.
Takashi, perhaps you can repost the patch as a proper submission? It would
be good to have this regression fixed even if we don't know the real source of
it.
> I wasn't able to reproduce this bug with virtualbox.
>
>
>
>
>
> I only got one pm-hibernate issue. Last line:
>
> Disabling non-boot CPUs ...
>
> This time I've enabled debug hung task :)
>
> schedule_timeout
> ...
> workqueue_cpu_callback
> notifier_call_chain
> ...
> __cpu_notify
> _cpu_down
> printk
> disable_nonboot_cpus
> hibernation_snapshot
> hibernate
> ...
>
> Any other idea besides the possibility it's caused by evil earth
> radiation, isn't it?
I'm not exactly sure what happened from your description, care to explain?
Rafael
^ permalink raw reply
* [Bug 40507] NV50 multi GPU only one GPU is used by X
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-22 21:32 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-40507-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=40507
--- Comment #15 from Thomas van Gulick <thomas-OAIPNaC2qqLgjWiVKyS68A@public.gmane.org> 2011-10-22 14:32:29 PDT ---
Created attachment 52638
--> https://bugs.freedesktop.org/attachment.cgi?id=52638
ls of /sys/card/drm
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [Bug 40507] NV50 multi GPU only one GPU is used by X
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-22 21:31 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-40507-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=40507
--- Comment #14 from Thomas van Gulick <thomas-OAIPNaC2qqLgjWiVKyS68A@public.gmane.org> 2011-10-22 14:31:06 PDT ---
Created attachment 52637
--> https://bugs.freedesktop.org/attachment.cgi?id=52637
Xorg log for test case of non working card
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH 05/14] ARM : SAMSUNG : Add GPIO_EXTRA for S3C2416.
From: Heiko Stübner @ 2011-10-22 21:30 UTC (permalink / raw)
To: Paul Schilling; +Cc: Kukjin Kim, Russell King, linux-arm-kernel, linux-kernel
In-Reply-To: <1319256492-4975-1-git-send-email-paul.s.schilling@gmail.com>
Am Samstag 22 Oktober 2011, 06:08:12 schrieb Paul Schilling:
> The S3C2416 has more GPIO than other S3C24XX processors.
>
> Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
> ---
> arch/arm/mach-s3c2410/include/mach/gpio.h | 15 ++++++++++-----
> arch/arm/plat-s3c24xx/gpiolib.c | 10 ++++++++--
> 2 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-s3c2410/include/mach/gpio.h
> b/arch/arm/mach-s3c2410/include/mach/gpio.h index f7f6b07..65a0bce 100644
> --- a/arch/arm/mach-s3c2410/include/mach/gpio.h
> +++ b/arch/arm/mach-s3c2410/include/mach/gpio.h
> @@ -20,22 +20,27 @@
> * devices that need GPIO.
> */
>
> +#if defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> +#define ARCH_NR_GPIOS (32 * 12 + CONFIG_S3C24XX_GPIO_EXTRA)
> +#else
> #ifdef CONFIG_CPU_S3C244X
> #define ARCH_NR_GPIOS (32 * 9 + CONFIG_S3C24XX_GPIO_EXTRA)
> -#elif defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> -#define ARCH_NR_GPIOS (32 * 12 + CONFIG_S3C24XX_GPIO_EXTRA)
> #else
> #define ARCH_NR_GPIOS (256 + CONFIG_S3C24XX_GPIO_EXTRA)
> #endif
> +#endif
why are you moving these around? I don't see a functional change.
> #include <asm-generic/gpio.h>
> #include <mach/gpio-nrs.h>
> #include <mach/gpio-fns.h>
>
> -#ifdef CONFIG_CPU_S3C244X
> -#define S3C_GPIO_END (S3C2410_GPJ(0) + 32)
> -#elif defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> +
> +#if defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> #define S3C_GPIO_END (S3C2410_GPM(0) + 32)
> #else
> +#ifdef CONFIG_CPU_S3C244X
> +#define S3C_GPIO_END (S3C2410_GPJ(0) + 32)
> +else
> #define S3C_GPIO_END (S3C2410_GPH(0) + 32)
> #endif
> +#endif
same as above
> diff --git a/arch/arm/plat-s3c24xx/gpiolib.c
> b/arch/arm/plat-s3c24xx/gpiolib.c index 243b641..93d4734 100644
> --- a/arch/arm/plat-s3c24xx/gpiolib.c
> +++ b/arch/arm/plat-s3c24xx/gpiolib.c
> @@ -34,6 +34,11 @@ static int s3c24xx_gpiolib_banka_input(struct gpio_chip
> *chip, unsigned offset) return -EINVAL;
> }
>
> +static int s3c24xx_gpiolib_bankm_output(struct gpio_chip *chip, unsigned
> offset, int value) +{
> + return -EINVAL;
> +}
> +
> static int s3c24xx_gpiolib_banka_output(struct gpio_chip *chip,
> unsigned offset, int value)
> {
> @@ -93,7 +98,7 @@ struct s3c_gpio_chip s3c24xx_gpios[] = {
> .base = S3C2410_GPA(0),
> .owner = THIS_MODULE,
> .label = "GPIOA",
> - .ngpio = 24,
> + .ngpio = 27,
> .direction_input = s3c24xx_gpiolib_banka_input,
> .direction_output = s3c24xx_gpiolib_banka_output,
> },
> @@ -167,7 +172,7 @@ struct s3c_gpio_chip s3c24xx_gpios[] = {
> .base = S3C2410_GPH(0),
> .owner = THIS_MODULE,
> .label = "GPIOH",
> - .ngpio = 11,
> + .ngpio = 15,
> },
> },
> /* GPIOS for the S3C2443 and later devices. */
> @@ -206,6 +211,7 @@ struct s3c_gpio_chip s3c24xx_gpios[] = {
> .owner = THIS_MODULE,
> .label = "GPIOM",
> .ngpio = 2,
> + .direction_output = s3c24xx_gpiolib_bankm_output,
> },
> },
> };
looks ok, but you will probably have to coordinate with Kgene as the Samsung
gpio support gets consolidated for 3.2 (i.e. in linux-next it currently sits
in drivers/gpio/gpio-samsung.c)
Heiko
^ permalink raw reply
* [Bug 40507] NV50 multi GPU only one GPU is used by X
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-22 21:30 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-40507-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=40507
--- Comment #13 from Thomas van Gulick <thomas-OAIPNaC2qqLgjWiVKyS68A@public.gmane.org> 2011-10-22 14:30:13 PDT ---
I've took the time to try and test the GPU on PCI:0:4:0:0, and that seems to
not work at all.
I notice there is an asterisk in front of the PCI:0:5:0:0 line in the
Xorg.0.log, might that mean something like only that device is enabled?
I'll include all the configs and logs for the very simple test case trying to
use the non working device.
Also, here's someone with seemingly the same problem. The solution there was to
use the proprietary driver. Of course I will too after this post, but nouveau
seems to perform much much better and is of course open source and I would like
to use it and would like other with multiple cards and this same problem to be
able to use it too!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 05/14] ARM : SAMSUNG : Add GPIO_EXTRA for S3C2416.
From: Heiko Stübner @ 2011-10-22 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319256492-4975-1-git-send-email-paul.s.schilling@gmail.com>
Am Samstag 22 Oktober 2011, 06:08:12 schrieb Paul Schilling:
> The S3C2416 has more GPIO than other S3C24XX processors.
>
> Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
> ---
> arch/arm/mach-s3c2410/include/mach/gpio.h | 15 ++++++++++-----
> arch/arm/plat-s3c24xx/gpiolib.c | 10 ++++++++--
> 2 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-s3c2410/include/mach/gpio.h
> b/arch/arm/mach-s3c2410/include/mach/gpio.h index f7f6b07..65a0bce 100644
> --- a/arch/arm/mach-s3c2410/include/mach/gpio.h
> +++ b/arch/arm/mach-s3c2410/include/mach/gpio.h
> @@ -20,22 +20,27 @@
> * devices that need GPIO.
> */
>
> +#if defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> +#define ARCH_NR_GPIOS (32 * 12 + CONFIG_S3C24XX_GPIO_EXTRA)
> +#else
> #ifdef CONFIG_CPU_S3C244X
> #define ARCH_NR_GPIOS (32 * 9 + CONFIG_S3C24XX_GPIO_EXTRA)
> -#elif defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> -#define ARCH_NR_GPIOS (32 * 12 + CONFIG_S3C24XX_GPIO_EXTRA)
> #else
> #define ARCH_NR_GPIOS (256 + CONFIG_S3C24XX_GPIO_EXTRA)
> #endif
> +#endif
why are you moving these around? I don't see a functional change.
> #include <asm-generic/gpio.h>
> #include <mach/gpio-nrs.h>
> #include <mach/gpio-fns.h>
>
> -#ifdef CONFIG_CPU_S3C244X
> -#define S3C_GPIO_END (S3C2410_GPJ(0) + 32)
> -#elif defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> +
> +#if defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> #define S3C_GPIO_END (S3C2410_GPM(0) + 32)
> #else
> +#ifdef CONFIG_CPU_S3C244X
> +#define S3C_GPIO_END (S3C2410_GPJ(0) + 32)
> +else
> #define S3C_GPIO_END (S3C2410_GPH(0) + 32)
> #endif
> +#endif
same as above
> diff --git a/arch/arm/plat-s3c24xx/gpiolib.c
> b/arch/arm/plat-s3c24xx/gpiolib.c index 243b641..93d4734 100644
> --- a/arch/arm/plat-s3c24xx/gpiolib.c
> +++ b/arch/arm/plat-s3c24xx/gpiolib.c
> @@ -34,6 +34,11 @@ static int s3c24xx_gpiolib_banka_input(struct gpio_chip
> *chip, unsigned offset) return -EINVAL;
> }
>
> +static int s3c24xx_gpiolib_bankm_output(struct gpio_chip *chip, unsigned
> offset, int value) +{
> + return -EINVAL;
> +}
> +
> static int s3c24xx_gpiolib_banka_output(struct gpio_chip *chip,
> unsigned offset, int value)
> {
> @@ -93,7 +98,7 @@ struct s3c_gpio_chip s3c24xx_gpios[] = {
> .base = S3C2410_GPA(0),
> .owner = THIS_MODULE,
> .label = "GPIOA",
> - .ngpio = 24,
> + .ngpio = 27,
> .direction_input = s3c24xx_gpiolib_banka_input,
> .direction_output = s3c24xx_gpiolib_banka_output,
> },
> @@ -167,7 +172,7 @@ struct s3c_gpio_chip s3c24xx_gpios[] = {
> .base = S3C2410_GPH(0),
> .owner = THIS_MODULE,
> .label = "GPIOH",
> - .ngpio = 11,
> + .ngpio = 15,
> },
> },
> /* GPIOS for the S3C2443 and later devices. */
> @@ -206,6 +211,7 @@ struct s3c_gpio_chip s3c24xx_gpios[] = {
> .owner = THIS_MODULE,
> .label = "GPIOM",
> .ngpio = 2,
> + .direction_output = s3c24xx_gpiolib_bankm_output,
> },
> },
> };
looks ok, but you will probably have to coordinate with Kgene as the Samsung
gpio support gets consolidated for 3.2 (i.e. in linux-next it currently sits
in drivers/gpio/gpio-samsung.c)
Heiko
^ permalink raw reply
* Re: [linux-lvm] unable to create mirror in LVM using lvconvert
From: Stuart D. Gathman @ 2011-10-22 21:26 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <CANp7ydPHg_Otp+XMrhn6TJ5c+-kn3Bc+mPaGtuN8exRtokYk-g@mail.gmail.com>
On Sat, 22 Oct 2011, sabari G wrote:
> when i try to
> lvconvert -m 1 vgnew/lvol4
>
> "not enough free pv for creating parallel allocation.."
By default, and for best performance, the bitmap must be on a 3rd PV.
There are options to place the bitmap on the same PV as a leg, or to
keep it in memory (requiring a resync at boot).
Also, I hope your setup is for testing only. Putting mirror legs on
the same device doesn't protect you much.
--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
^ permalink raw reply
* [PATCH 11/11] powerpc/85xx: Add P1020RDB 36-bit address map device tree
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-10-git-send-email-galak@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p1020rdb_36b.dts | 66 ++++++++++++++++++++++++++++++++
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1020rdb_36b.dts
diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts b/arch/powerpc/boot/dts/p1020rdb_36b.dts
new file mode 100644
index 0000000..bdbdb60
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
@@ -0,0 +1,66 @@
+/*
+ * P1020 RDB Device Tree Source (36-bit address map)
+ *
+ * Copyright 2009-2011 Freescale Semiconductor Inc.
+ *
+ * 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/ "fsl/p1020si-pre.dtsi"
+/ {
+ model = "fsl,P1020RDB";
+ compatible = "fsl,P1020RDB";
+
+ memory {
+ device_type = "memory";
+ };
+
+ board_lbc: lbc: localbus@fffe05000 {
+ reg = <0xf 0xffe05000 0 0x1000>;
+
+ /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
+ ranges = <0x0 0x0 0xf 0xef000000 0x01000000
+ 0x1 0x0 0xf 0xffa00000 0x00040000
+ 0x2 0x0 0xf 0xffb00000 0x00020000>;
+ };
+
+ board_soc: soc: soc@fffe00000 {
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe09000 {
+ reg = <0xf 0xffe09000 0 0x1000>;
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xc0000000
+ 0x2000000 0x0 0xc0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@fffe0a000 {
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+/include/ "p1020rdb.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
--
1.7.3.4
^ permalink raw reply related
* [PATCH 09/11] powerpc/85xx: Rework P1020 SoC device tree
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-8-git-send-email-galak@kernel.crashing.org>
Split the P1020 SoC device tree into what we can include as a 'prefix'
to the board device tree and what needs to be included as a 'postfix'.
This allows use more re-use and less duplication between various board
device tree configurations (32-bit address map vs 36-bit address map).
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 229 +++++++++++++++
arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi | 68 +++++
arch/powerpc/boot/dts/p1020si.dtsi | 407 ---------------------------
3 files changed, 297 insertions(+), 407 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
delete mode 100644 arch/powerpc/boot/dts/p1020si.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
new file mode 100644
index 0000000..74538a4
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -0,0 +1,229 @@
+/*
+ * P1020/P1011 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+&lbc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
+ interrupts = <19 2 0 0>;
+};
+
+&pci0 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 255>;
+ clock-frequency = <33333333>;
+ interrupts = <16 2 0 0>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x4 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x5 0x1
+ 0000 0x0 0x0 0x3 &mpic 0x6 0x1
+ 0000 0x0 0x0 0x4 &mpic 0x7 0x1
+ >;
+ };
+};
+
+&pci1 {
+ compatible = "fsl,mpc8548-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 255>;
+ clock-frequency = <33333333>;
+ interrupts = <16 2 0 0>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x0 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x1 0x1
+ 0000 0x0 0x0 0x3 &mpic 0x2 0x1
+ 0000 0x0 0x0 0x4 &mpic 0x3 0x1
+ >;
+ };
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,p1020-immr", "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,p1020-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,p1020-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+ i2c0: i2c@3000 {
+ };
+
+ i2c1: i2c@3100 {
+ };
+
+ serial0: serial@4500 {
+ };
+
+ serial1: serial@4600 {
+ };
+
+ spi0: spi@7000 {
+ };
+
+ gpio0: gpio-controller@f000 {
+ };
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,p1020-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x40000>; // L2,256K
+ interrupts = <16 2 0 0>;
+ };
+
+ dma0: dma@21300 {
+ };
+
+ mdio0: mdio@24000 {
+ };
+
+ mdio1: mdio@25000 {
+ };
+
+ mdio2: mdio@26000 {
+ };
+
+ enet0: ethernet@b0000 {
+ };
+
+ enet1: ethernet@b1000 {
+ };
+
+ enet2: ethernet@b2000 {
+ };
+
+ usb@22000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-usb2-dr";
+ reg = <0x22000 0x1000>;
+ interrupts = <28 0x2 0 0>;
+ };
+
+ /* USB2 is shared with localbus, so it must be disabled
+ by default. We can't put 'status = "disabled";' here
+ since U-Boot doesn't clear the status property when
+ it enables USB2. OTOH, U-Boot does create a new node
+ when there isn't any. So, just comment it out.
+ usb@23000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl-usb2-dr";
+ reg = <0x23000 0x1000>;
+ interrupts = <46 0x2 0 0>;
+ phy_type = "ulpi";
+ };
+ */
+
+ sdhc0: sdhc@2e000 {
+ };
+
+ crypto: crypto@30000 {
+ };
+
+ mpic: pic@40000 {
+ };
+
+ timerA: timer@41100 {
+ };
+
+ timerB: timer@42100 {
+ };
+
+ msiA: msi@41600 {
+ };
+
+ global-utilities@e0000 {
+ compatible = "fsl,p1020-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
+
+/include/ "pq3-dma-0.dtsi"
+/include/ "pq3-duart-0.dtsi"
+/include/ "pq3-esdhc-0.dtsi"
+/include/ "pq3-espi-0.dtsi"
+/include/ "pq3-etsec2-0.dtsi"
+/include/ "pq3-etsec2-1.dtsi"
+/include/ "pq3-etsec2-2.dtsi"
+/include/ "pq3-gpio-0.dtsi"
+/include/ "pq3-i2c-0.dtsi"
+/include/ "pq3-i2c-1.dtsi"
+/include/ "pq3-mpic.dtsi"
+/include/ "pq3-mpic-timer-B.dtsi"
+/include/ "pq3-sec3.3-0.dtsi"
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
new file mode 100644
index 0000000..6f0376e
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
@@ -0,0 +1,68 @@
+/*
+ * P1020/P1011 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/ {
+ compatible = "fsl,P1020";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,P1020@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+
+ PowerPC,P1020@1 {
+ device_type = "cpu";
+ reg = <0x1>;
+ next-level-cache = <&L2>;
+ };
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi b/arch/powerpc/boot/dts/p1020si.dtsi
deleted file mode 100644
index b08c848..0000000
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ /dev/null
@@ -1,407 +0,0 @@
-/*
- * P1020si Device Tree Source
- *
- * Copyright 2011 Freescale Semiconductor Inc.
- *
- * 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.
- */
-
-/dts-v1/;
-/ {
- compatible = "fsl,P1020";
- #address-cells = <2>;
- #size-cells = <2>;
- interrupt-parent = <&mpic>;
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- PowerPC,P1020@0 {
- device_type = "cpu";
- reg = <0x0>;
- next-level-cache = <&L2>;
- };
-
- PowerPC,P1020@1 {
- device_type = "cpu";
- reg = <0x1>;
- next-level-cache = <&L2>;
- };
- };
-
- localbus@ffe05000 {
- #address-cells = <2>;
- #size-cells = <1>;
- compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
- reg = <0 0xffe05000 0 0x1000>;
- interrupts = <19 2 0 0>;
- };
-
- soc@ffe00000 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "soc";
- compatible = "fsl,p1020-immr", "simple-bus";
- ranges = <0x0 0x0 0xffe00000 0x100000>;
- bus-frequency = <0>; // Filled out by uboot.
-
- ecm-law@0 {
- compatible = "fsl,ecm-law";
- reg = <0x0 0x1000>;
- fsl,num-laws = <12>;
- };
-
- ecm@1000 {
- compatible = "fsl,p1020-ecm", "fsl,ecm";
- reg = <0x1000 0x1000>;
- interrupts = <16 2 0 0>;
- };
-
- memory-controller@2000 {
- compatible = "fsl,p1020-memory-controller";
- reg = <0x2000 0x1000>;
- interrupts = <16 2 0 0>;
- };
-
- i2c@3000 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <0>;
- compatible = "fsl-i2c";
- reg = <0x3000 0x100>;
- interrupts = <43 2 0 0>;
- dfsrr;
- };
-
- i2c@3100 {
- #address-cells = <1>;
- #size-cells = <0>;
- cell-index = <1>;
- compatible = "fsl-i2c";
- reg = <0x3100 0x100>;
- interrupts = <43 2 0 0>;
- dfsrr;
- };
-
- serial0: serial@4500 {
- cell-index = <0>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x4500 0x100>;
- clock-frequency = <0>;
- interrupts = <42 2 0 0>;
- };
-
- serial1: serial@4600 {
- cell-index = <1>;
- device_type = "serial";
- compatible = "ns16550";
- reg = <0x4600 0x100>;
- clock-frequency = <0>;
- interrupts = <42 2 0 0>;
- };
-
- spi@7000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,p1020-espi", "fsl,mpc8536-espi";
- reg = <0x7000 0x1000>;
- interrupts = <59 0x2 0 0>;
- fsl,espi-num-chipselects = <4>;
- };
-
- gpio: gpio-controller@f000 {
- #gpio-cells = <2>;
- compatible = "fsl,mpc8572-gpio";
- reg = <0xf000 0x100>;
- interrupts = <47 0x2 0 0>;
- gpio-controller;
- };
-
- L2: l2-cache-controller@20000 {
- compatible = "fsl,p1020-l2-cache-controller";
- reg = <0x20000 0x1000>;
- cache-line-size = <32>; // 32 bytes
- cache-size = <0x40000>; // L2,256K
- interrupts = <16 2 0 0>;
- };
-
- dma@21300 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,eloplus-dma";
- reg = <0x21300 0x4>;
- ranges = <0x0 0x21100 0x200>;
- cell-index = <0>;
- dma-channel@0 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x0 0x80>;
- cell-index = <0>;
- interrupts = <20 2 0 0>;
- };
- dma-channel@80 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x80 0x80>;
- cell-index = <1>;
- interrupts = <21 2 0 0>;
- };
- dma-channel@100 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x100 0x80>;
- cell-index = <2>;
- interrupts = <22 2 0 0>;
- };
- dma-channel@180 {
- compatible = "fsl,eloplus-dma-channel";
- reg = <0x180 0x80>;
- cell-index = <3>;
- interrupts = <23 2 0 0>;
- };
- };
-
- mdio@24000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,etsec2-mdio";
- reg = <0x24000 0x1000 0xb0030 0x4>;
-
- };
-
- mdio@25000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,etsec2-tbi";
- reg = <0x25000 0x1000 0xb1030 0x4>;
-
- };
-
- enet0: ethernet@b0000 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "network";
- model = "eTSEC";
- compatible = "fsl,etsec2";
- fsl,num_rx_queues = <0x8>;
- fsl,num_tx_queues = <0x8>;
- fsl,magic-packet;
- local-mac-address = [ 00 00 00 00 00 00 ];
-
- queue-group@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xb0000 0x1000>;
- interrupts = <29 2 0 0 30 2 0 0 34 2 0 0>;
- };
-
- queue-group@1 {
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xb4000 0x1000>;
- interrupts = <17 2 0 0 18 2 0 0 24 2 0 0>;
- };
- };
-
- enet1: ethernet@b1000 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "network";
- model = "eTSEC";
- compatible = "fsl,etsec2";
- fsl,num_rx_queues = <0x8>;
- fsl,num_tx_queues = <0x8>;
- fsl,magic-packet;
- local-mac-address = [ 00 00 00 00 00 00 ];
-
- queue-group@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xb1000 0x1000>;
- interrupts = <35 2 0 0 36 2 0 0 40 2 0 0>;
- };
-
- queue-group@1 {
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xb5000 0x1000>;
- interrupts = <51 2 0 0 52 2 0 0 67 2 0 0>;
- };
- };
-
- enet2: ethernet@b2000 {
- #address-cells = <1>;
- #size-cells = <1>;
- device_type = "network";
- model = "eTSEC";
- compatible = "fsl,etsec2";
- fsl,num_rx_queues = <0x8>;
- fsl,num_tx_queues = <0x8>;
- fsl,magic-packet;
- local-mac-address = [ 00 00 00 00 00 00 ];
-
- queue-group@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xb2000 0x1000>;
- interrupts = <31 2 0 0 32 2 0 0 33 2 0 0>;
- };
-
- queue-group@1 {
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0xb6000 0x1000>;
- interrupts = <25 2 0 0 26 2 0 0 27 2 0 0>;
- };
- };
-
- usb@22000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl-usb2-dr";
- reg = <0x22000 0x1000>;
- interrupts = <28 0x2 0 0>;
- };
-
- /* USB2 is shared with localbus, so it must be disabled
- by default. We can't put 'status = "disabled";' here
- since U-Boot doesn't clear the status property when
- it enables USB2. OTOH, U-Boot does create a new node
- when there isn't any. So, just comment it out.
- usb@23000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl-usb2-dr";
- reg = <0x23000 0x1000>;
- interrupts = <46 0x2 0 0>;
- phy_type = "ulpi";
- };
- */
-
- sdhci@2e000 {
- compatible = "fsl,p1020-esdhc", "fsl,esdhc";
- reg = <0x2e000 0x1000>;
- interrupts = <72 0x2 0 0>;
- /* Filled in by U-Boot */
- clock-frequency = <0>;
- };
-
- crypto@30000 {
- compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
- "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
- "fsl,sec2.0";
- reg = <0x30000 0x10000>;
- interrupts = <45 2 0 0 58 2 0 0>;
- fsl,num-channels = <4>;
- fsl,channel-fifo-len = <24>;
- fsl,exec-units-mask = <0x97c>;
- fsl,descriptor-types-mask = <0x3a30abf>;
- };
-
- mpic: pic@40000 {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <4>;
- reg = <0x40000 0x40000>;
- compatible = "chrp,open-pic";
- device_type = "open-pic";
- };
-
- timer@41100 {
- compatible = "fsl,mpic-global-timer";
- reg = <0x41100 0x100 0x41300 4>;
- interrupts = <0 0 3 0
- 1 0 3 0
- 2 0 3 0
- 3 0 3 0>;
- };
-
- timer@42100 {
- compatible = "fsl,mpic-global-timer";
- reg = <0x42100 0x100 0x42300 4>;
- interrupts = <4 0 3 0
- 5 0 3 0
- 6 0 3 0
- 7 0 3 0>;
- };
-
- msi@41600 {
- compatible = "fsl,p1020-msi", "fsl,mpic-msi";
- reg = <0x41600 0x80>;
- msi-available-ranges = <0 0x100>;
- interrupts = <
- 0xe0 0 0 0
- 0xe1 0 0 0
- 0xe2 0 0 0
- 0xe3 0 0 0
- 0xe4 0 0 0
- 0xe5 0 0 0
- 0xe6 0 0 0
- 0xe7 0 0 0>;
- };
-
- global-utilities@e0000 { //global utilities block
- compatible = "fsl,p1020-guts","fsl,p2020-guts";
- reg = <0xe0000 0x1000>;
- fsl,has-rstcr;
- };
- };
-
- pci0: pcie@ffe09000 {
- compatible = "fsl,mpc8548-pcie";
- device_type = "pci";
- #size-cells = <2>;
- #address-cells = <3>;
- bus-range = <0 255>;
- clock-frequency = <33333333>;
- interrupts = <16 2 0 0>;
-
- pcie@0 {
- reg = <0 0 0 0 0>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- interrupts = <16 2 0 0>;
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0x0 0x0 0x1 &mpic 0x4 0x1
- 0000 0x0 0x0 0x2 &mpic 0x5 0x1
- 0000 0x0 0x0 0x3 &mpic 0x6 0x1
- 0000 0x0 0x0 0x4 &mpic 0x7 0x1
- >;
- };
-
- };
-
- pci1: pcie@ffe0a000 {
- compatible = "fsl,mpc8548-pcie";
- device_type = "pci";
- #size-cells = <2>;
- #address-cells = <3>;
- bus-range = <0 255>;
- clock-frequency = <33333333>;
- interrupts = <16 2 0 0>;
-
- pcie@0 {
- reg = <0 0 0 0 0>;
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- interrupts = <16 2 0 0>;
- interrupt-map-mask = <0xf800 0 0 7>;
-
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0x0 0x0 0x1 &mpic 0x0 0x1
- 0000 0x0 0x0 0x2 &mpic 0x1 0x1
- 0000 0x0 0x0 0x3 &mpic 0x2 0x1
- 0000 0x0 0x0 0x4 &mpic 0x3 0x1
- >;
- };
- };
-};
--
1.7.3.4
^ permalink raw reply related
* [PATCH 06/11] powerpc/85xx: Add ethernet magic packet property to P1020 device tree
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-5-git-send-email-galak@kernel.crashing.org>
All eTSEC2 controllers support waking on magic packet so fixup device
tree to report that.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p1020si.dtsi | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi b/arch/powerpc/boot/dts/p1020si.dtsi
index 5514e1d..14dff69 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -200,6 +200,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
@@ -226,6 +227,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
@@ -252,6 +254,7 @@
compatible = "fsl,etsec2";
fsl,num_rx_queues = <0x8>;
fsl,num_tx_queues = <0x8>;
+ fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupt-parent = <&mpic>;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 05/11] powerpc/85xx: Update P1020 SEC3.3 node to match actual SoC HW
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-4-git-send-email-galak@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p1020si.dtsi | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi b/arch/powerpc/boot/dts/p1020si.dtsi
index 25e10cf..5514e1d 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -305,15 +305,16 @@
};
crypto@30000 {
- compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
- "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
+ compatible = "fsl,sec3.3", "fsl,sec3.1", "fsl,sec3.0",
+ "fsl,sec2.4", "fsl,sec2.2", "fsl,sec2.1",
+ "fsl,sec2.0";
reg = <0x30000 0x10000>;
interrupts = <45 2 58 2>;
interrupt-parent = <&mpic>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
- fsl,exec-units-mask = <0xbfe>;
- fsl,descriptor-types-mask = <0x3ab0ebf>;
+ fsl,exec-units-mask = <0x97c>;
+ fsl,descriptor-types-mask = <0x3a30abf>;
};
mpic: pic@40000 {
--
1.7.3.4
^ permalink raw reply related
* [PATCH 04/11] powerpc/85xx: Update SPI binding to match binding spec for P1020RDB
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-3-git-send-email-galak@kernel.crashing.org>
The SPI node is out of date with regards to the binding for fsl-espi and
driver support.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p1020rdb.dts | 30 +++++++++++++-----------------
arch/powerpc/boot/dts/p1020si.dtsi | 5 ++---
2 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
index 8b1a7ee..b31e7ec 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -149,49 +149,45 @@
};
spi@7000 {
-
- fsl_m25p80@0 {
+ flash@0 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "fsl,espi-flash";
+ compatible = "spansion,s25sl12801";
reg = <0>;
- linux,modalias = "fsl_m25p80";
- modal = "s25sl128b";
- spi-max-frequency = <50000000>;
- mode = <0>;
+ spi-max-frequency = <40000000>; /* input clock */
- partition@0 {
+ partition@u-boot {
/* 512KB for u-boot Bootloader Image */
reg = <0x0 0x00080000>;
- label = "SPI (RO) U-Boot Image";
+ label = "u-boot";
read-only;
};
- partition@80000 {
+ partition@dtb {
/* 512KB for DTB Image */
reg = <0x00080000 0x00080000>;
- label = "SPI (RO) DTB Image";
+ label = "dtb";
read-only;
};
- partition@100000 {
+ partition@kernel {
/* 4MB for Linux Kernel Image */
reg = <0x00100000 0x00400000>;
- label = "SPI (RO) Linux Kernel Image";
+ label = "kernel";
read-only;
};
- partition@500000 {
+ partition@fs {
/* 4MB for Compressed RFS Image */
reg = <0x00500000 0x00400000>;
- label = "SPI (RO) Compressed RFS Image";
+ label = "file system";
read-only;
};
- partition@900000 {
+ partition@jffs-fs {
/* 7MB for JFFS2 based RFS */
reg = <0x00900000 0x00700000>;
- label = "SPI (RW) JFFS2 RFS";
+ label = "file system jffs2";
};
};
};
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi b/arch/powerpc/boot/dts/p1020si.dtsi
index 58f6b30..25e10cf 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -112,14 +112,13 @@
};
spi@7000 {
- cell-index = <0>;
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,espi";
+ compatible = "fsl,p1020-espi", "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2>;
interrupt-parent = <&mpic>;
- mode = "cpu";
+ fsl,espi-num-chipselects = <4>;
};
gpio: gpio-controller@f000 {
--
1.7.3.4
^ permalink raw reply related
* [PATCH 03/11] powerpc/85xx: Rework PCI nodes on P1020RDB
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-2-git-send-email-galak@kernel.crashing.org>
* Move SoC specific details like irq mapping to SoC dtsi
* Update interrupt property to cover both error interrupt and PCIe
runtime interrupts
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p1020rdb.dts | 26 +---------------------
arch/powerpc/boot/dts/p1020si.dtsi | 40 ++++++++++++++++++++++++++++++++---
2 files changed, 38 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
index d6a8ae4..8b1a7ee 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -257,19 +257,8 @@
pci0: pcie@ffe09000 {
ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0x0 0x0 0x1 &mpic 0x4 0x1
- 0000 0x0 0x0 0x2 &mpic 0x5 0x1
- 0000 0x0 0x0 0x3 &mpic 0x6 0x1
- 0000 0x0 0x0 0x4 &mpic 0x7 0x1
- >;
+ reg = <0 0xffe09000 0 0x1000>;
pcie@0 {
- reg = <0x0 0x0 0x0 0x0 0x0>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
ranges = <0x2000000 0x0 0xa0000000
0x2000000 0x0 0xa0000000
0x0 0x20000000
@@ -281,21 +270,10 @@
};
pci1: pcie@ffe0a000 {
+ reg = <0 0xffe0a000 0 0x1000>;
ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0x0 0x0 0x1 &mpic 0x0 0x1
- 0000 0x0 0x0 0x2 &mpic 0x1 0x1
- 0000 0x0 0x0 0x3 &mpic 0x2 0x1
- 0000 0x0 0x0 0x4 &mpic 0x3 0x1
- >;
pcie@0 {
- reg = <0x0 0x0 0x0 0x0 0x0>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
ranges = <0x2000000 0x0 0x80000000
0x2000000 0x0 0x80000000
0x0 0x20000000
diff --git a/arch/powerpc/boot/dts/p1020si.dtsi b/arch/powerpc/boot/dts/p1020si.dtsi
index 5c5acb6..58f6b30 100644
--- a/arch/powerpc/boot/dts/p1020si.dtsi
+++ b/arch/powerpc/boot/dts/p1020si.dtsi
@@ -352,26 +352,58 @@
pci0: pcie@ffe09000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
- #interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 255>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x4 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x5 0x1
+ 0000 0x0 0x0 0x3 &mpic 0x6 0x1
+ 0000 0x0 0x0 0x4 &mpic 0x7 0x1
+ >;
+ };
+
};
pci1: pcie@ffe0a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
- #interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x0 0x1
+ 0000 0x0 0x0 0x2 &mpic 0x1 0x1
+ 0000 0x0 0x0 0x3 &mpic 0x2 0x1
+ 0000 0x0 0x0 0x4 &mpic 0x3 0x1
+ >;
+ };
};
};
--
1.7.3.4
^ permalink raw reply related
* [PATCH 02/11] powerpc/85xx: Simplify P1020RDB CAMP dts using includes
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1319318452-27036-1-git-send-email-galak@kernel.crashing.org>
If we include the p1020rdb.dts instead of p1020si.dts we greatly reduce
duplication and maintenance. We can just list which devices are
disabled for the given core and mpic protected sources.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/p1020rdb_camp_core0.dts | 154 +------------------------
arch/powerpc/boot/dts/p1020rdb_camp_core1.dts | 11 +--
2 files changed, 4 insertions(+), 161 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
index f0bf7f4..41b4585 100644
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_camp_core0.dts
@@ -16,7 +16,7 @@
* option) any later version.
*/
-/include/ "p1020si.dtsi"
+/include/ "p1020rdb.dts"
/ {
model = "fsl,P1020RDB";
@@ -32,7 +32,7 @@
cpus {
PowerPC,P1020@1 {
- status = "disabled";
+ status = "disabled";
};
};
@@ -45,169 +45,19 @@
};
soc@ffe00000 {
- i2c@3000 {
- rtc@68 {
- compatible = "dallas,ds1339";
- reg = <0x68>;
- };
- };
-
serial1: serial@4600 {
status = "disabled";
};
- spi@7000 {
- fsl_m25p80@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,espi-flash";
- reg = <0>;
- linux,modalias = "fsl_m25p80";
- spi-max-frequency = <40000000>;
-
- partition@0 {
- /* 512KB for u-boot Bootloader Image */
- reg = <0x0 0x00080000>;
- label = "SPI (RO) U-Boot Image";
- read-only;
- };
-
- partition@80000 {
- /* 512KB for DTB Image */
- reg = <0x00080000 0x00080000>;
- label = "SPI (RO) DTB Image";
- read-only;
- };
-
- partition@100000 {
- /* 4MB for Linux Kernel Image */
- reg = <0x00100000 0x00400000>;
- label = "SPI (RO) Linux Kernel Image";
- read-only;
- };
-
- partition@500000 {
- /* 4MB for Compressed RFS Image */
- reg = <0x00500000 0x00400000>;
- label = "SPI (RO) Compressed RFS Image";
- read-only;
- };
-
- partition@900000 {
- /* 7MB for JFFS2 based RFS */
- reg = <0x00900000 0x00700000>;
- label = "SPI (RW) JFFS2 RFS";
- };
- };
- };
-
- mdio@24000 {
- phy0: ethernet-phy@0 {
- interrupt-parent = <&mpic>;
- interrupts = <3 1>;
- reg = <0x0>;
- };
- phy1: ethernet-phy@1 {
- interrupt-parent = <&mpic>;
- interrupts = <2 1>;
- reg = <0x1>;
- };
- };
-
- mdio@25000 {
- tbi0: tbi-phy@11 {
- reg = <0x11>;
- device_type = "tbi-phy";
- };
- };
-
enet0: ethernet@b0000 {
status = "disabled";
};
- enet1: ethernet@b1000 {
- phy-handle = <&phy0>;
- tbi-handle = <&tbi0>;
- phy-connection-type = "sgmii";
- };
-
- enet2: ethernet@b2000 {
- phy-handle = <&phy1>;
- phy-connection-type = "rgmii-id";
- };
-
- usb@22000 {
- phy_type = "ulpi";
- };
-
- /* USB2 is shared with localbus, so it must be disabled
- by default. We can't put 'status = "disabled";' here
- since U-Boot doesn't clear the status property when
- it enables USB2. OTOH, U-Boot does create a new node
- when there isn't any. So, just comment it out.
- usb@23000 {
- phy_type = "ulpi";
- };
- */
-
mpic: pic@40000 {
protected-sources = <
42 29 30 34 /* serial1, enet0-queue-group0 */
17 18 24 45 /* enet0-queue-group1, crypto */
>;
};
-
- };
-
- pci0: pcie@ffe09000 {
- ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0x0 0x0 0x1 &mpic 0x4 0x1
- 0000 0x0 0x0 0x2 &mpic 0x5 0x1
- 0000 0x0 0x0 0x3 &mpic 0x6 0x1
- 0000 0x0 0x0 0x4 &mpic 0x7 0x1
- >;
- pcie@0 {
- reg = <0x0 0x0 0x0 0x0 0x0>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- ranges = <0x2000000 0x0 0xa0000000
- 0x2000000 0x0 0xa0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci1: pcie@ffe0a000 {
- ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0x0 0x0 0x1 &mpic 0x0 0x1
- 0000 0x0 0x0 0x2 &mpic 0x1 0x1
- 0000 0x0 0x0 0x3 &mpic 0x2 0x1
- 0000 0x0 0x0 0x4 &mpic 0x3 0x1
- >;
- pcie@0 {
- reg = <0x0 0x0 0x0 0x0 0x0>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- ranges = <0x2000000 0x0 0x80000000
- 0x2000000 0x0 0x80000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
};
};
diff --git a/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts b/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
index 6ec0220..5174538 100644
--- a/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_camp_core1.dts
@@ -15,7 +15,7 @@
* option) any later version.
*/
-/include/ "p1020si.dtsi"
+/include/ "p1020rdb.dts"
/ {
model = "fsl,P1020RDB";
@@ -28,7 +28,7 @@
cpus {
PowerPC,P1020@0 {
- status = "disabled";
+ status = "disabled";
};
};
@@ -85,12 +85,6 @@
status = "disabled";
};
- enet0: ethernet@b0000 {
- fixed-link = <1 1 1000 0 0>;
- phy-connection-type = "rgmii-id";
-
- };
-
enet1: ethernet@b1000 {
status = "disabled";
};
@@ -135,7 +129,6 @@
global-utilities@e0000 { //global utilities block
status = "disabled";
};
-
};
pci0: pcie@ffe09000 {
--
1.7.3.4
^ permalink raw reply related
* [PATCH 01/11] powerpc/85xx: Add 'fsl, pq3-gpio' compatiable for GPIO driver
From: Kumar Gala @ 2011-10-22 21:20 UTC (permalink / raw)
To: linuxppc-dev
Support MPC85xx platforms outside of MPC8572/MPC8536. The
MPC8572/MPC8536 have an erratum that is worked around based on having
"fsl,mpc8572-gpio" in the compatiable list. All other MPC85xx SoCs
don't require this workaround and thus utilize the 'fsl,pq3-gpio'
compatiable.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/gpio/gpio-mpc8xxx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index fb4963a..d74d19b 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -310,6 +310,7 @@ static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
{ .compatible = "fsl,mpc8572-gpio", },
{ .compatible = "fsl,mpc8610-gpio", },
{ .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
+ { .compatible = "fsl,pq3-gpio", },
{ .compatible = "fsl,qoriq-gpio", },
{}
};
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl_msi: add support for "msi-address-64" property
From: Kumar Gala @ 2011-10-22 21:19 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780
In-Reply-To: <CAOZdJXVJXhiSsjm9cBruGgJ946fr6xwpOZzTLcN2GQGq6eamVw@mail.gmail.com>
On Oct 21, 2011, at 2:16 PM, Tabi Timur-B04825 wrote:
> On Fri, Oct 14, 2011 at 9:15 AM, Kumar Gala <kumar.gala@freescale.com> =
wrote:
>=20
>>> .../devicetree/bindings/powerpc/fsl/msi-pic.txt | 42 =
++++++++++++++++++++
>>> arch/powerpc/sysdev/fsl_msi.c | 20 +++++++---
>>> arch/powerpc/sysdev/fsl_msi.h | 3 +-
>>> 3 files changed, 57 insertions(+), 8 deletions(-)
>>=20
>> applied
>=20
> Applied where, exactly? You don't have a repo on kernel.org, and your
> repo on github.org is over a month old.
I've updated github as still trying to figure out when I'll get my =
kernel.org account back.
- k=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.