* Re: OF PCI howto?
From: Grant Likely @ 2009-04-16 19:21 UTC (permalink / raw)
To: Roderick Colenbrander; +Cc: linuxppc-dev, Joakim Tjernlund
In-Reply-To: <c8485d470904160203y66d456f7xd73692b177587822@mail.gmail.com>
On Thu, Apr 16, 2009 at 3:03 AM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund
> <Joakim.Tjernlund@transmode.se> wrote:
>> Kumar Gala <galak@kernel.crashing.org> wrote on 15/04/2009 17:20:21:
>>> On Apr 15, 2009, at 8:08 AM, Wolfram Sang wrote:
>>>
>>> > On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
>>> >
>>> >> dts fragment correct for my setup? If not, is there a better
>>> >> example I can
>>> >> look at?
>>> >
>>> > Maybe this message/thread can help you:
>>> >
>>> > http://ozlabs.org/pipermail/devicetree-discuss/2009-March/000597.html
>>>
>>> You may also want to take a look at ePAPR on the power.org site
>>
>> Thanks guys
>>
>> Looking in ePAPR I see I should read the IDSEL like this:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* IDSEL 0x11 AD17 */
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x1 &ipic 20 0x8 /* INTA *=
/
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x2 &ipic 21 0x8 /* INTB *=
/
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x3 &ipic 22 0x8 /* INTC *=
/
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x8800 0x0 0x0 0x4 &ipic 23 0x8 /* INTD *=
/
>>
>> grouping the first line into:
>> "0x8800 0x0 0x0" "0x1" "&ipic" "20 0x8" /* INTA */
>>
>> "0x8800 0x0 0x0" =3D child unit address
>> "0x1" =3D child interrupt specifier =3D INTA
>> "&ipic" =3D interrupt parent
>> "20 0x8" =3D parent interrupt specifier
>>
>> Questions:
>> =A0MPC832x appears to only have INTA so why are the INTB,INTC
>> =A0and INTD lines there?
>>
>> =A0I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18
>> randomly
>> =A0selected or are they fixed for MPC832x?
>
> The idsel values depend on how the pci slots are wired on your board.
> The 0x8800 value is
> in general a function of bus, device and function number. ( bus << 16
> | devfn << 8)
>
> Further I would also watch out with the parent interrupt specifier
> e.g. '20 0x8'. The openfirmware spec
> normally suggests to use a value of '2' for interrupts which are
> active low. During parsing of the interrupt-map
> this value is normally translated using 'xlate' to linux kernel values
> (active low is defined as IRQ_TYPE_LEVEL_LOW =A0 =A0 =A00x00000008 in the
> kernel).
> The ipic driver code and various dts files are evil and store the
> linux kernel value inside the DTS file, so they don't do any
> conversion whis is EVIL
> in my opinion. Watch out for that.
They're just numbers and they are intended to by interrupt controller
specific values. Some IRQ controllers don't even have a 'flags' field
for instance. The binding author is free to choose values he or she
deems suitable for the purpose as long as it is documented and
reviewed.
> (The corresponding DTS files and
> drivers should be updated).
No. The binding is set. We've made a commitment to not change
bindings after they are defined and deployed. In some cases it is not
easy to update the device tree blob in deployed systems.
>
> Regards,
> Roderick Colenbrander
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: issues w/init
From: Scott Wood @ 2009-04-16 19:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <88F07543-B7F6-4F27-B5FB-4780AD069D7E@kernel.crashing.org>
Kumar Gala wrote:
> [root:~] cat /proc/1/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0feab000-0ffbe000 r-xp 00000000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffbe000-0ffcb000 ---p 00113000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffcb000-0ffeb000 rw-p 00110000 00:0d 7127086 /lib/libc-2.2.5.so
IIRC, this libc is old enough to execute out of non-exec memory in some
cases.
-Scott
^ permalink raw reply
* [patch 2/4] powerpc/ps3: Fix no flash build warning
From: Geoff Levand @ 2009-04-16 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20090416190536.540992667@am.sony.com>
Fix build warnings like these when CONFIG_PS3_FLASH=n:
arch/powerpc/platforms/ps3/os-area.c: warning: 'update_flash_db' defined but not used
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/os-area.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -578,7 +578,7 @@ static void os_area_db_init(struct os_ar
*
*/
-static void update_flash_db(void)
+static void __maybe_unused update_flash_db(void)
{
int result;
int file;
--
^ permalink raw reply
* [patch 0/4] PS3 2.6.30 patches
From: Geoff Levand @ 2009-04-16 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Hi Paul,
This is a small set of patches for 2.6.30.
(1) and (2) are simple build fixes.
(3) is a patch by Milton submitted back in October that seems to
have beed missed. Could you consider it for 2.6.30?
(4) is an update to the MAINTAINERS file. Can you take it?
[patch 1/4] powerpc/ps3: Fix no SMP build error
[patch 2/4] powerpc/ps3: Fix no flash build warning
[patch 3/4] powerpc ps3: use smp_request_message_ipi
[patch 4/4] maintainers: Fix PS3 patterns
-Geoff
--
^ permalink raw reply
* [patch 1/4] powerpc/ps3: Fix no SMP build error
From: Geoff Levand @ 2009-04-16 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Subrata Modak, linuxppc-dev
In-Reply-To: <20090416190536.540992667@am.sony.com>
A non-SMP version of smp_send_stop() is now included in smp.h.
Remove the unneeded def in the PS3 smp.c.
Fixes build errors like these when CONFIG_SMP=n:
arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of 'smp_send_stop'
include/linux/smp.h:125: error: previous definition of 'smp_send_stop' was here
Reported-by: Subrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/setup.c | 4 ----
1 file changed, 4 deletions(-)
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -45,10 +45,6 @@
DEFINE_MUTEX(ps3_gpu_mutex);
EXPORT_SYMBOL_GPL(ps3_gpu_mutex);
-#if !defined(CONFIG_SMP)
-static void smp_send_stop(void) {}
-#endif
-
static union ps3_firmware_version ps3_firmware_version;
void ps3_get_firmware_version(union ps3_firmware_version *v)
--
^ permalink raw reply
* [patch 4/4] maintainers: Fix PS3 patterns
From: Geoff Levand @ 2009-04-16 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev
In-Reply-To: <20090416190536.540992667@am.sony.com>
Correct the MAINTAINERS file patterns for PS3. Removes some PS3
patterns that were under 'CELL BROADBAND ENGINE ARCHITECTURE', and
adds missing PS3 sound and RTC driver patterns.
CC: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
MAINTAINERS | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1280,12 +1280,9 @@ L: cbe-oss-dev@ozlabs.org
W: http://www.ibm.com/developerworks/power/cell/
S: Supported
F: arch/powerpc/include/asm/cell*.h
-F: arch/powerpc/include/asm/lv1call.h
-F: arch/powerpc/include/asm/ps3*.h
F: arch/powerpc/include/asm/spu*.h
F: arch/powerpc/oprofile/*cell*
F: arch/powerpc/platforms/cell/
-F: arch/powerpc/platforms/ps3/
CERTIFIED WIRELESS USB (WUSB) SUBSYSTEM:
P: David Vrabel
@@ -4434,7 +4431,9 @@ F: arch/powerpc/include/asm/ps3*.h
F: arch/powerpc/platforms/ps3/
F: drivers/*/ps3*
F: drivers/ps3/
+F: drivers/rtc/rtc-ps3.c
F: drivers/usb/host/*ps3.c
+F: sound/ppc/snd_ps3*
PS3VRAM DRIVER
P: Jim Paris
--
^ permalink raw reply
* [patch 3/4] powerpc ps3: use smp_request_message_ipi
From: Geoff Levand @ 2009-04-16 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Milton Miller, linuxppc-dev
In-Reply-To: <20090416190536.540992667@am.sony.com>
ps3 has 4 ipis per cpu and can use the new smp_request_message_ipi to
reduce path length when receiving an ipi.
This has the side effect of setting IRQF_PERCPU.
Signed-off-by: Milton Miller <miltonm@bga.com>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Index: next.git/arch/powerpc/platforms/ps3/smp.c
===================================================================
--- next.git.orig/arch/powerpc/platforms/ps3/smp.c 2008-10-05 00:20:41.000000000 -0500
+++ next.git/arch/powerpc/platforms/ps3/smp.c 2008-10-05 00:22:50.000000000 -0500
@@ -32,12 +32,6 @@
#define DBG pr_debug
#endif
-static irqreturn_t ipi_function_handler(int irq, void *msg)
-{
- smp_message_recv((int)(long)msg);
- return IRQ_HANDLED;
-}
-
/**
* ps3_ipi_virqs - a per cpu array of virqs for ipi use
*/
@@ -45,13 +39,6 @@ static irqreturn_t ipi_function_handler(
#define MSG_COUNT 4
static DEFINE_PER_CPU(unsigned int, ps3_ipi_virqs[MSG_COUNT]);
-static const char *names[MSG_COUNT] = {
- "ipi call",
- "ipi reschedule",
- "ipi migrate",
- "ipi debug brk"
-};
-
static void do_message_pass(int target, int msg)
{
int result;
@@ -119,8 +106,7 @@ static void __init ps3_smp_setup_cpu(int
DBG("%s:%d: (%d, %d) => virq %u\n",
__func__, __LINE__, cpu, i, virqs[i]);
- result = request_irq(virqs[i], ipi_function_handler,
- IRQF_DISABLED, names[i], (void*)(long)i);
+ result = smp_request_message_ipi(virqs[i], i);
if (result)
virqs[i] = NO_IRQ;
--
^ permalink raw reply
* Re: issues w/init
From: Kumar Gala @ 2009-04-16 19:27 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development
In-Reply-To: <49E78620.7070303@freescale.com>
On Apr 16, 2009, at 2:25 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> [root:~] cat /proc/1/maps
>> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
>> 0feab000-0ffbe000 r-xp 00000000 00:0d 7127086 /lib/libc-2.2.5.so
>> 0ffbe000-0ffcb000 ---p 00113000 00:0d 7127086 /lib/libc-2.2.5.so
>> 0ffcb000-0ffeb000 rw-p 00110000 00:0d 7127086 /lib/libc-2.2.5.so
>
> IIRC, this libc is old enough to execute out of non-exec memory in
> some cases.
Yeah, I'm going to that realization. The question is are we ok with
breaking older versions of libc like this.
- k
^ permalink raw reply
* Re: [BUILD FAILURE 03/12] Next April 14 : PPC64 randconfig [arch/powerpc/platforms/ps3/setup.c]
From: Geoff Levand @ 2009-04-16 19:32 UTC (permalink / raw)
To: subrata
Cc: sachinp, Stephen Rothwell, linux-kernel, Rafael J. Wysocki,
Linuxppc-dev, linux-next, Paul Mackerras, Geert Uytterhoeven,
Alexander Beregalov
In-Reply-To: <1239733704.5344.75.camel@subratamodak.linux.ibm.com>
On 04/14/2009 11:28 AM, Subrata Modak wrote:
> Observed the following build error:
> ---
> arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of
> =E2=80=98smp_send_stop=E2=80=99
> include/linux/smp.h:125: error: previous definition of =E2=80=98smp_sen=
d_stop=E2=80=99
> was here
Hi Subrata,
Thanks for the report. I submitted a fix to the powerpc ML:
http://patchwork.ozlabs.org/patch/26084/
-Geoff
^ permalink raw reply
* RE: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support and cleanup DCR
From: John Linn @ 2009-04-16 19:51 UTC (permalink / raw)
To: Grant Likely
Cc: linux-fbdev-devel, adaplas, Stephen Neuendorffer, Suneel Garapati,
linuxppc-dev, akonovalov
In-Reply-To: <fa686aa40904161201i4c4a59alc68ca0fc75a6b316@mail.gmail.com>
Sounds good, I'll spin it again with those changes.
-- John
> -----Original Message-----
> From: Grant Likely [mailto:grant.likely@secretlab.ca]
> Sent: Thursday, April 16, 2009 1:02 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org; linux-fbdev-devel@lists.sourceforge.net; ako=
novalov@ru.mvista.com;
> adaplas@gmail.com; jwboyer@linux.vnet.ibm.com; Suneel Garapati; Stephen N=
euendorffer
> Subject: Re: [PATCH] [V4] Xilinx : Framebuffer Driver: Add PLB support an=
d cleanup DCR
> =
> On Thu, Apr 16, 2009 at 10:26 AM, John Linn <john.linn@xilinx.com> wrote:=
> > Added support for the new xps tft controller. The new core
> > has PLB interface support in addition to existing DCR interface.
> >
> > Removed platform device support as both MicroBlaze and PowerPC
> > use device tree.
> >
> > Previously, the dcr interface was assumed to be used in mmio mode,
> > and the register space of the dcr interface was precomputed and stuffed=
> > into the device tree. This driver now makes use of the new dcr
> > infrastructure to represent the dcr interface. This enables the dcr
> > interface to be connected directly to a native dcr interface in a clean=
> > way.
> >
> > Added compatibility for ml507 dvi core.
> >
> > Signed-off-by: Suneel <suneelg@xilinx.com>
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> >
> > V2 - cleanup based on review
> > V3 - update to be based on top of tree rather than Xilinx tree, sorry f=
or the
> > =A0confusion with this, update the name of the patch slightly to be mor=
e accurate
> > V4 - update based on Grant's comments to simplify it, the binding wasn'=
t changed
> > =A0as the conversation seemed to verify it's acceptable
> =
> Actually Stephen and I agreed that the driver should *not* go looking
> for the xlnx,dcr-splb-slave-if property. reg and dcr-reg are
> sufficient. If a driver has both properties, then either method of
> access will work.
> =
> =
> > @@ -107,12 +112,21 @@ static struct fb_var_screeninfo xilinx_fb_var =3D=
{
> > =A0 =A0 =A0 =A0.activate =3D =A0 =A0 FB_ACTIVATE_NOW
> > =A0};
> >
> > +
> > +#define PLB_ACCESS_FLAG =A0 =A0 =A0 =A00x1 =A0 =A0 =A0 =A0 =A0 =A0 /* =
1 =3D PLB, 0 =3D DCR */
> > +
> =
> Also, this define is no longer required.
> =
> g.
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Bartlomiej Zolnierkiewicz @ 2009-04-16 19:30 UTC (permalink / raw)
To: Roderick Colenbrander; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <c8485d470904150734s47ce0f27y3ae984355e823d9f@mail.gmail.com>
Hi,
On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
> Hi,
>
> I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
> Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
> for IDE, USB and Audio. I did a lot of work to get the pci bus working
> on this board and it works correctly but the default init code
> of the alim15x3 driver doesn't work for me. The driver explicitly
> disabled some initialization code for powerpc after uncommenting this
> code it works properly. Benjamin Herrenschmidt and I think this
> !CONFIG_PPC check should be removed because the system behaves
> like a real 'x86' system (also the i8259 interrupt controller is used).
Ben, I guess you are OK with the change and there are no longer other
platforms requiring CONFIG_PPC check below? [I don't see your ACK here]
> Regards,
> Roderick Colenbrander
>
>
> From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001
> From: Roderick Colenbrander <thunderbird2k@gmail.com>
> Date: Wed, 15 Apr 2009 10:45:17 +0200
> Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for
> x86-like PowerPC boards like Xilinx ML310/410/510.
Roderick, please add your "Signed-off-by:" line
(per Documentation/SubmittingPatches).
Thanks.
> ---
> drivers/ide/alim15x3.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
> index 537da1c..9176c0f 100644
> --- a/drivers/ide/alim15x3.c
> +++ b/drivers/ide/alim15x3.c
> @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
> return cbl;
> }
>
> -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
> +#if !defined(CONFIG_SPARC64)
> /**
> * init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
> * @hwif: interface to configure
> *
> * Obtain the IRQ tables for an ALi based IDE solution on the PC
> - * class platforms. This part of the code isn't applicable to the
> - * Sparc and PowerPC systems.
> + * class platforms. This part of the code isn't applicable to
> + * Sparc systems. It is usable on 'x86-like' PowerPC systems
> + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510.
> */
>
> static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> }
> #else
> #define init_hwif_ali15x3 NULL
> -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
> +#endif /* !defined(CONFIG_SPARC64) */
>
> /**
> * init_dma_ali15x3 - set up DMA on ALi15x3
> --
> 1.5.6.3
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Grant Likely @ 2009-04-16 20:16 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Roderick Colenbrander; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <200904162130.01237.bzolnier@gmail.com>
Hi Roderick,
Since this patch is Xilinx virtex related, it is a good idea to cc:
both the linuxppc-dev mailing list and me when posting. That way I'd
have the opportunity to reply with an 'acked-by' or 'reviewed-by'
line.
g.
On Thu, Apr 16, 2009 at 1:30 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>
> Hi,
>
> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
>> Hi,
>>
>> I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
>> Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
>> for IDE, USB and Audio. I did a lot of work to get the pci bus working
>> on this board and it works correctly but the default init code
>> of the alim15x3 driver doesn't work for me. The driver explicitly
>> disabled some initialization code for powerpc after uncommenting this
>> code it works properly. Benjamin Herrenschmidt and I think this
>> !CONFIG_PPC check should be removed because the system behaves
>> like a real 'x86' system (also the i8259 interrupt controller is used).
>
> Ben, I guess you are OK with the change and there are no longer other
> platforms requiring CONFIG_PPC check below? =A0[I don't see your ACK here=
]
>
>> Regards,
>> Roderick Colenbrander
>>
>>
>> From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001
>> From: Roderick Colenbrander <thunderbird2k@gmail.com>
>> Date: Wed, 15 Apr 2009 10:45:17 +0200
>> Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for
>> x86-like PowerPC boards like Xilinx ML310/410/510.
>
> Roderick, please add your "Signed-off-by:" line
> (per Documentation/SubmittingPatches).
>
> Thanks.
>
>> ---
>> =A0drivers/ide/alim15x3.c | =A0 =A09 +++++----
>> =A01 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
>> index 537da1c..9176c0f 100644
>> --- a/drivers/ide/alim15x3.c
>> +++ b/drivers/ide/alim15x3.c
>> @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
>> =A0 =A0 =A0return cbl;
>> =A0}
>>
>> -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
>> +#if !defined(CONFIG_SPARC64)
>> =A0/**
>> =A0 * =A0 =A0init_hwif_ali15x3 =A0 =A0- =A0 =A0Initialize the ALI IDE x8=
6 stuff
>> =A0 * =A0 =A0@hwif: interface to configure
>> =A0 *
>> =A0 * =A0 =A0Obtain the IRQ tables for an ALi based IDE solution on the =
PC
>> - * =A0 =A0class platforms. This part of the code isn't applicable to th=
e
>> - * =A0 =A0Sparc and PowerPC systems.
>> + * =A0 =A0class platforms. This part of the code isn't applicable to
>> + * =A0 =A0Sparc systems. It is usable on 'x86-like' PowerPC systems
>> + * =A0 =A0 =A0which use a Ali M15x3 south bridge like e.g. Xilinx ML310=
/410/510.
>> =A0 */
>>
>> =A0static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
>> @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t =
*hwif)
>> =A0}
>> =A0#else
>> =A0#define init_hwif_ali15x3 NULL
>> -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
>> +#endif /* !defined(CONFIG_SPARC64) */
>>
>> =A0/**
>> =A0 * =A0 =A0init_dma_ali15x3 =A0 =A0- =A0 =A0set up DMA on ALi15x3
>> --
>> 1.5.6.3
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* powerpc-linux-gcc vs ppx_8xx-gcc and ppc_6xx-gcc
From: Lixin Yao @ 2009-04-16 20:23 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
Hello, All,
I use ELDK 4.2 to work on platforms, one with MPC860 and the other with
MPC8248.
In installation, I see links:
ppc_8xx-gcc -> ppc-linux-gcc
ppc_6xx-gcc -> ppc-linux-gcc
ppc-linux-gcc -> powerpc-linux-gcc
I understand ppc_8xx-gcc needs to be used for MPC860 and ppc_6xx-gcc
needs to be used for MPC8248. But both point to the same
"powerpc-linux-gcc".
What are the differences between powerpc-linux-gcc, ppx_8xx-gcc and
ppc_6xx-gcc? What's the default target processorr of powerpc-linux-gcc?
Thanks.
Lixin Yao
Harris Strate Networks Inc.
RTP, North Carolina
[-- Attachment #2: Type: text/html, Size: 1454 bytes --]
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Anton Vorontsov @ 2009-04-16 20:57 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, Roderick Colenbrander, linuxppc-dev
In-Reply-To: <200904162130.01237.bzolnier@gmail.com>
On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
> > Hi,
> >
> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
> > for IDE, USB and Audio. I did a lot of work to get the pci bus working
> > on this board and it works correctly but the default init code
> > of the alim15x3 driver doesn't work for me. The driver explicitly
> > disabled some initialization code for powerpc after uncommenting this
> > code it works properly. Benjamin Herrenschmidt and I think this
> > !CONFIG_PPC check should be removed because the system behaves
> > like a real 'x86' system (also the i8259 interrupt controller is used).
>
> Ben, I guess you are OK with the change and there are no longer other
> platforms requiring CONFIG_PPC check below? [I don't see your ACK here]
I'd like to nak this patch. It'll break MPC8610HPCD boards.
See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
I'm not sure how should we handle this for Xilinx PPC, MPC8610
PPC and Sparc all at the same time, but it's obvious that #ifdef
isn't enough any longer...
> > Regards,
> > Roderick Colenbrander
> >
> >
> > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001
> > From: Roderick Colenbrander <thunderbird2k@gmail.com>
> > Date: Wed, 15 Apr 2009 10:45:17 +0200
> > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for
> > x86-like PowerPC boards like Xilinx ML310/410/510.
>
> Roderick, please add your "Signed-off-by:" line
> (per Documentation/SubmittingPatches).
>
> Thanks.
>
> > ---
> > drivers/ide/alim15x3.c | 9 +++++----
> > 1 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
> > index 537da1c..9176c0f 100644
> > --- a/drivers/ide/alim15x3.c
> > +++ b/drivers/ide/alim15x3.c
> > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
> > return cbl;
> > }
> >
> > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
> > +#if !defined(CONFIG_SPARC64)
> > /**
> > * init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
> > * @hwif: interface to configure
> > *
> > * Obtain the IRQ tables for an ALi based IDE solution on the PC
> > - * class platforms. This part of the code isn't applicable to the
> > - * Sparc and PowerPC systems.
> > + * class platforms. This part of the code isn't applicable to
> > + * Sparc systems. It is usable on 'x86-like' PowerPC systems
> > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510.
> > */
> >
> > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > }
> > #else
> > #define init_hwif_ali15x3 NULL
> > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
> > +#endif /* !defined(CONFIG_SPARC64) */
> >
> > /**
> > * init_dma_ali15x3 - set up DMA on ALi15x3
> > --
> > 1.5.6.3
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] therm_adt746x: Convert to a new-style i2c driver
From: Jean Delvare @ 2009-04-16 20:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
The legacy i2c binding model is going away soon, so convert the ppc
therm_adt746x driver to the new model or it will break.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
---
Can someone please test this patch for me? I could only build-test it.
Remember that you need this patch applied:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=935298696f469c0e07c73be687bd055878074ce0
Thanks.
drivers/macintosh/therm_adt746x.c | 84 ++++++++++++++++++-------------------
1 file changed, 42 insertions(+), 42 deletions(-)
--- linux-2.6.30-rc2.orig/drivers/macintosh/therm_adt746x.c 2009-04-16 21:06:31.000000000 +0200
+++ linux-2.6.30-rc2/drivers/macintosh/therm_adt746x.c 2009-04-16 21:37:05.000000000 +0200
@@ -71,7 +71,7 @@ MODULE_PARM_DESC(verbose,"Verbose log op
"(default 0)");
struct thermostat {
- struct i2c_client clt;
+ struct i2c_client *clt;
u8 temps[3];
u8 cached_temp[3];
u8 initial_limits[3];
@@ -86,9 +86,6 @@ static struct of_device * of_dev;
static struct thermostat* thermostat;
static struct task_struct *thread_therm = NULL;
-static int attach_one_thermostat(struct i2c_adapter *adapter, int addr,
- int busno);
-
static void write_both_fan_speed(struct thermostat *th, int speed);
static void write_fan_speed(struct thermostat *th, int speed, int fan);
@@ -100,7 +97,7 @@ write_reg(struct thermostat* th, int reg
tmp[0] = reg;
tmp[1] = data;
- rc = i2c_master_send(&th->clt, (const char *)tmp, 2);
+ rc = i2c_master_send(th->clt, (const char *)tmp, 2);
if (rc < 0)
return rc;
if (rc != 2)
@@ -115,12 +112,12 @@ read_reg(struct thermostat* th, int reg)
int rc;
reg_addr = (u8)reg;
- rc = i2c_master_send(&th->clt, ®_addr, 1);
+ rc = i2c_master_send(th->clt, ®_addr, 1);
if (rc < 0)
return rc;
if (rc != 1)
return -ENODEV;
- rc = i2c_master_recv(&th->clt, (char *)&data, 1);
+ rc = i2c_master_recv(th->clt, (char *)&data, 1);
if (rc < 0)
return rc;
return data;
@@ -130,26 +127,36 @@ static int
attach_thermostat(struct i2c_adapter *adapter)
{
unsigned long bus_no;
+ struct i2c_board_info info;
+ struct i2c_client *client;
if (strncmp(adapter->name, "uni-n", 5))
return -ENODEV;
bus_no = simple_strtoul(adapter->name + 6, NULL, 10);
if (bus_no != therm_bus)
return -ENODEV;
- return attach_one_thermostat(adapter, therm_address, bus_no);
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "therm_adt746x", I2C_NAME_SIZE);
+ info.addr = therm_address;
+ client = i2c_new_device(adapter, &info);
+ if (!client)
+ return -ENODEV;
+
+ /*
+ * Let i2c-core delete that device on driver removal.
+ * This is safe because i2c-core holds the core_lock mutex for us.
+ */
+ list_add_tail(&client->detected, &client->driver->clients);
+ return 0;
}
static int
-detach_thermostat(struct i2c_adapter *adapter)
+remove_thermostat(struct i2c_client *client)
{
- struct thermostat* th;
+ struct thermostat *th = i2c_get_clientdata(client);
int i;
- if (thermostat == NULL)
- return 0;
-
- th = thermostat;
-
if (thread_therm != NULL) {
kthread_stop(thread_therm);
}
@@ -165,8 +172,6 @@ detach_thermostat(struct i2c_adapter *ad
write_both_fan_speed(th, -1);
- i2c_detach_client(&th->clt);
-
thermostat = NULL;
kfree(th);
@@ -174,14 +179,6 @@ detach_thermostat(struct i2c_adapter *ad
return 0;
}
-static struct i2c_driver thermostat_driver = {
- .driver = {
- .name = "therm_adt746x",
- },
- .attach_adapter = attach_thermostat,
- .detach_adapter = detach_thermostat,
-};
-
static int read_fan_speed(struct thermostat *th, u8 addr)
{
u8 tmp[2];
@@ -369,8 +366,8 @@ static void set_limit(struct thermostat
th->limits[i] = default_limits_local[i] + limit_adjust;
}
-static int attach_one_thermostat(struct i2c_adapter *adapter, int addr,
- int busno)
+static int probe_thermostat(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
struct thermostat* th;
int rc;
@@ -383,16 +380,12 @@ static int attach_one_thermostat(struct
if (!th)
return -ENOMEM;
- th->clt.addr = addr;
- th->clt.adapter = adapter;
- th->clt.driver = &thermostat_driver;
- strcpy(th->clt.name, "thermostat");
+ i2c_set_clientdata(client, th);
+ th->clt = client;
rc = read_reg(th, 0);
if (rc < 0) {
- printk(KERN_ERR "adt746x: Thermostat failed to read config "
- "from bus %d !\n",
- busno);
+ dev_err(&client->dev, "Thermostat failed to read config!\n");
kfree(th);
return -ENODEV;
}
@@ -421,14 +414,6 @@ static int attach_one_thermostat(struct
thermostat = th;
- if (i2c_attach_client(&th->clt)) {
- printk(KERN_INFO "adt746x: Thermostat failed to attach "
- "client !\n");
- thermostat = NULL;
- kfree(th);
- return -ENODEV;
- }
-
/* be sure to really write fan speed the first time */
th->last_speed[0] = -2;
th->last_speed[1] = -2;
@@ -454,6 +439,21 @@ static int attach_one_thermostat(struct
return 0;
}
+static const struct i2c_device_id therm_adt746x_id[] = {
+ { "therm_adt746x", 0 },
+ { }
+};
+
+static struct i2c_driver thermostat_driver = {
+ .driver = {
+ .name = "therm_adt746x",
+ },
+ .attach_adapter = attach_thermostat,
+ .probe = probe_thermostat,
+ .remove = remove_thermostat,
+ .id_table = therm_adt746x_id,
+};
+
/*
* Now, unfortunately, sysfs doesn't give us a nice void * we could
* pass around to the attribute functions, so we don't really have
--
Jean Delvare
^ permalink raw reply
* [PATCH] therm_windtunnel: Convert to a new-style i2c driver
From: Jean Delvare @ 2009-04-16 21:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
The legacy i2c binding model is going away soon, so convert the ppc
therm_windtunnel driver to the new model or it will break.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
---
Can someone please test this patch for me? I could only build-test it.
Remember that you need this patch applied:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=935298696f469c0e07c73be687bd055878074ce0
Thanks.
drivers/macintosh/therm_windtunnel.c | 126 ++++++++++++++++------------------
1 file changed, 60 insertions(+), 66 deletions(-)
--- linux-2.6.30-rc2.orig/drivers/macintosh/therm_windtunnel.c 2009-03-24 13:40:47.000000000 +0100
+++ linux-2.6.30-rc2/drivers/macintosh/therm_windtunnel.c 2009-04-16 22:56:39.000000000 +0200
@@ -48,16 +48,6 @@
#define LOG_TEMP 0 /* continously log temperature */
-static int do_probe( struct i2c_adapter *adapter, int addr, int kind);
-
-/* scan 0x48-0x4f (DS1775) and 0x2c-2x2f (ADM1030) */
-static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
- 0x4c, 0x4d, 0x4e, 0x4f,
- 0x2c, 0x2d, 0x2e, 0x2f,
- I2C_CLIENT_END };
-
-I2C_CLIENT_INSMOD;
-
static struct {
volatile int running;
struct task_struct *poll_task;
@@ -315,53 +305,54 @@ static int control_loop(void *dummy)
static int
do_attach( struct i2c_adapter *adapter )
{
- int ret = 0;
+ /* scan 0x48-0x4f (DS1775) and 0x2c-2x2f (ADM1030) */
+ static const unsigned short scan_ds1775[] = {
+ 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
+ I2C_CLIENT_END
+ };
+ static const unsigned short scan_adm1030[] = {
+ 0x2c, 0x2d, 0x2e, 0x2f,
+ I2C_CLIENT_END
+ };
if( strncmp(adapter->name, "uni-n", 5) )
return 0;
if( !x.running ) {
- ret = i2c_probe( adapter, &addr_data, &do_probe );
+ struct i2c_board_info info;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "therm_ds1775", I2C_NAME_SIZE);
+ i2c_new_probed_device(adapter, &info, scan_ds1775);
+
+ strlcpy(info.type, "therm_adm1030", I2C_NAME_SIZE);
+ i2c_new_probed_device(adapter, &info, scan_adm1030);
+
if( x.thermostat && x.fan ) {
x.running = 1;
x.poll_task = kthread_run(control_loop, NULL, "g4fand");
}
}
- return ret;
+ return 0;
}
static int
-do_detach( struct i2c_client *client )
+do_remove(struct i2c_client *client)
{
- int err;
-
- if( (err=i2c_detach_client(client)) )
- printk(KERN_ERR "failed to detach thermostat client\n");
- else {
- if( x.running ) {
- x.running = 0;
- kthread_stop(x.poll_task);
- x.poll_task = NULL;
- }
- if( client == x.thermostat )
- x.thermostat = NULL;
- else if( client == x.fan )
- x.fan = NULL;
- else {
- printk(KERN_ERR "g4fan: bad client\n");
- }
- kfree( client );
+ if (x.running) {
+ x.running = 0;
+ kthread_stop(x.poll_task);
+ x.poll_task = NULL;
}
- return err;
-}
+ if (client == x.thermostat)
+ x.thermostat = NULL;
+ else if (client == x.fan)
+ x.fan = NULL;
+ else
+ printk(KERN_ERR "g4fan: bad client\n");
-static struct i2c_driver g4fan_driver = {
- .driver = {
- .name = "therm_windtunnel",
- },
- .attach_adapter = do_attach,
- .detach_client = do_detach,
-};
+ return 0;
+}
static int
attach_fan( struct i2c_client *cl )
@@ -374,13 +365,8 @@ attach_fan( struct i2c_client *cl )
goto out;
printk("ADM1030 fan controller [@%02x]\n", cl->addr );
- strlcpy( cl->name, "ADM1030 fan controller", sizeof(cl->name) );
-
- if( !i2c_attach_client(cl) )
- x.fan = cl;
+ x.fan = cl;
out:
- if( cl != x.fan )
- kfree( cl );
return 0;
}
@@ -412,39 +398,47 @@ attach_thermostat( struct i2c_client *cl
x.temp = temp;
x.overheat_temp = os_temp;
x.overheat_hyst = hyst_temp;
-
- strlcpy( cl->name, "DS1775 thermostat", sizeof(cl->name) );
-
- if( !i2c_attach_client(cl) )
- x.thermostat = cl;
+ x.thermostat = cl;
out:
- if( cl != x.thermostat )
- kfree( cl );
return 0;
}
+enum chip { ds1775, adm1030 };
+
+static const struct i2c_device_id therm_windtunnel_id[] = {
+ { "therm_ds1775", ds1775 },
+ { "therm_adm1030", adm1030 },
+ { }
+};
+
static int
-do_probe( struct i2c_adapter *adapter, int addr, int kind )
+do_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
- struct i2c_client *cl;
+ struct i2c_adapter *adapter = cl->adapter;
if( !i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA
| I2C_FUNC_SMBUS_WRITE_BYTE) )
return 0;
- if( !(cl=kzalloc(sizeof(*cl), GFP_KERNEL)) )
- return -ENOMEM;
-
- cl->addr = addr;
- cl->adapter = adapter;
- cl->driver = &g4fan_driver;
- cl->flags = 0;
-
- if( addr < 0x48 )
+ switch (id->driver_data) {
+ case adm1030:
return attach_fan( cl );
- return attach_thermostat( cl );
+ case ds1775:
+ return attach_thermostat(cl);
+ }
+ return 0;
}
+static struct i2c_driver g4fan_driver = {
+ .driver = {
+ .name = "therm_windtunnel",
+ },
+ .attach_adapter = do_attach,
+ .probe = do_probe,
+ .remove = do_remove,
+ .id_table = therm_windtunnel_id,
+};
+
/************************************************************************/
/* initialization / cleanup */
--
Jean Delvare
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Roderick Colenbrander @ 2009-04-16 21:27 UTC (permalink / raw)
To: avorontsov; +Cc: linux-ide, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20090416205735.GA26519@oksana.dev.rtsoft.ru>
On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote=
:
>>
>> Hi,
>>
>> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
>> > Hi,
>> >
>> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
>> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
>> > for IDE, USB and Audio. I did a lot of work to get the pci bus working
>> > on this board and it works correctly but the default init code
>> > of the alim15x3 driver doesn't work for me. The driver explicitly
>> > disabled some initialization code for powerpc after uncommenting this
>> > code it works properly. Benjamin Herrenschmidt and I think this
>> > !CONFIG_PPC check should be removed because the system behaves
>> > like a real 'x86' system (also the i8259 interrupt controller is used)=
.
>>
>> Ben, I guess you are OK with the change and there are no longer other
>> platforms requiring CONFIG_PPC check below? =A0[I don't see your ACK her=
e]
>
> I'd like to nak this patch. It'll break MPC8610HPCD boards.
>
> See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
>
> I'm not sure how should we handle this for Xilinx PPC, MPC8610
> PPC and Sparc all at the same time, but it's obvious that #ifdef
> isn't enough any longer...
>
>
>
If it is really a board specific issue (in case of powerpc it appears
to be one) we could also use the default_irq override in ppc_md. What
do you think?
Roderick
^ permalink raw reply
* Re: "ahci: drop intx manipulation on msi enable" breaks ULI M1575
From: Timur Tabi @ 2009-04-16 21:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Tejun Heo, Linux PPC Development, linux-ide
In-Reply-To: <49DD8871.2030404@garzik.org>
On Thu, Apr 9, 2009 at 12:32 AM, Jeff Garzik <jeff@garzik.org> wrote:
> 3) As a result, Timur's 'ahci' is no longer receiving interrupts. Presuma=
bly
> this means that BOTH of the following conditions are true
>
> =A0 =A0 =A0 =A0a) INTX is disabled
> =A0 =A0 =A0 =A0b) MSI is not available
>
> Today I am thinking we should either revert the libata commit
> (a5bfc4714b3f01365aef89a92673f2ceb1ccf246), or poke PCI to twiddle INTX f=
or
> us at pci_enable_device() time, perhaps.
We (Freescale) have discussed and debugged this issue, and I'm 99%
certain that we have a board-specific fix, so there's no need to
revert the patch.
According to the original developer, he had to disable the INTX on the
board if SATA were disabled, otherwise some other problem occurred.
He noticed that the interrupt was re-enabled (presumably by the
pre-patch code in ahci.c), so he thought it would be okay to disable
it.
I've run some tests, and so far it appears that the problem does not
occur with the latest kernel (or the latest revision of the hardware).
I need to run some more tests to be absolutely certain. If those
tests pass, then I will post a patch that modifies
hpcd_quirk_uli5288().
So please, don't revert any patches. And thanks to everyone for
helping me resolve this issue.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Anton Vorontsov @ 2009-04-16 22:04 UTC (permalink / raw)
To: Roderick Colenbrander; +Cc: linux-ide, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <c8485d470904161427w31ff313dsb651aa1f53bbacea@mail.gmail.com>
On Thu, Apr 16, 2009 at 11:27:34PM +0200, Roderick Colenbrander wrote:
> On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> > On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> Hi,
> >>
> >> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
> >> > Hi,
> >> >
> >> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
> >> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
> >> > for IDE, USB and Audio. I did a lot of work to get the pci bus working
> >> > on this board and it works correctly but the default init code
> >> > of the alim15x3 driver doesn't work for me. The driver explicitly
> >> > disabled some initialization code for powerpc after uncommenting this
> >> > code it works properly. Benjamin Herrenschmidt and I think this
> >> > !CONFIG_PPC check should be removed because the system behaves
> >> > like a real 'x86' system (also the i8259 interrupt controller is used).
> >>
> >> Ben, I guess you are OK with the change and there are no longer other
> >> platforms requiring CONFIG_PPC check below? [I don't see your ACK here]
> >
> > I'd like to nak this patch. It'll break MPC8610HPCD boards.
> >
> > See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
> >
> > I'm not sure how should we handle this for Xilinx PPC, MPC8610
> > PPC and Sparc all at the same time, but it's obvious that #ifdef
> > isn't enough any longer...
> >
> >
> >
>
> If it is really a board specific issue (in case of powerpc it appears
> to be one) we could also use the default_irq override in ppc_md. What
> do you think?
Um, I don't see "default_irq" in the ppc_md. Do you want to add one?
I wonder if DECLARE_PCI_FIXUP_*() mechanism will work... see
arch/powerpc/platforms/fsl_uli1575.c as an example for board-specific
PCI fixups.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: ppc32: Don't clobber personality flags on exec
From: David Miller @ 2009-04-16 23:17 UTC (permalink / raw)
To: schwab; +Cc: linuxppc-dev
In-Reply-To: <m27i1k8t7a.fsf@igel.home>
From: Andreas Schwab <schwab@linux-m68k.org>
Date: Thu, 16 Apr 2009 18:22:01 +0200
> Now that ppc32 implements address randomization it also wants to inherit
> personality flags like ADDR_NO_RANDOMIZE across exec, for things like
> `setarch ppc -R' to work. But the ppc32 version of SET_PERSONALITY
> forcefully sets PER_LINUX, clearing all personality flags. So be
> careful about preserving the flags.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Grumble, sparc has the same bugs... thanks for finding this.
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards
From: Peter Korsgaard @ 2009-04-17 5:13 UTC (permalink / raw)
To: Anton Vorontsov
Cc: spi-devel-general, Andrew Morton, David Brownell, linux-kernel,
linuxppc-dev
In-Reply-To: <87bpr71p1o.fsf_-_@macbook.be.48ers.dk>
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Anyone? I've locally reverted the commit, but most likely I'm not the
only one using the spi_mpc83xx driver without direct gpio controlled
chip select handling.
Anton> The advantages of this:
Anton> - Don't encourage legacy support;
Anton> - Less external symbols, less code to compile-in for !MPC832x_RDB
Anton> platforms.
Peter> It's nice with your cleanups, but I wonder how to handle more
Peter> complicated chip select handling than simply toggling a single gpio.
Peter> I have a board (or 2 actually, but they are similar in this regard)
Peter> with a mpc8347 using SPI to a number of addon boards. For signal
Peter> integrity reasons the SPI signals are routed to a MUX, so the chip
Peter> select logic has to set the MUX in addition to controlling the CS line
Peter> of the device.
Peter> I've been using code like this since late 2007, but this patch
Peter> ofcourse breaks it:
Peter> static void thinx_spi_activate_cs(u8 cs, u8 polarity)
Peter> {
Peter> static u8 old_cs = 255;
Peter> if (cs != old_cs) {
Peter> /* mux setup (cs 2:1)*/
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 1);
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL0, cs&2);
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL1, cs&4);
Peter> gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 0);
Peter> old_cs = cs;
Peter> }
Peter> switch (cs) {
Peter> case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, polarity); break;
Peter> case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, polarity); break;
Peter> case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, polarity); break;
Peter> case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, polarity); break;
Peter> }
Peter> }
Peter> static void thinx_spi_deactivate_cs(u8 cs, u8 polarity)
Peter> {
Peter> switch (cs) {
Peter> case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, !polarity); break;
Peter> case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, !polarity); break;
Peter> case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, !polarity); break;
Peter> case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, !polarity); break;
Peter> }
Peter> }
Peter> static __init int thinx_spi_init(void)
Peter> {
Peter> struct device_node *np;
Peter> struct of_gpio_chip *gc;
Peter> static const int gpios[] = {
Peter> GPIO_SPI_CS_BKL1,
Peter> GPIO_SPI_CS_BKL2,
Peter> GPIO_SPI_CS_OPT1,
Peter> GPIO_SPI_CS_OPT2,
Peter> GPIO_SPI_MUX_NOE,
Peter> GPIO_SPI_MUX_SEL0,
Peter> GPIO_SPI_MUX_SEL1
Peter> };
Peter> int i;
Peter> np = of_find_node_by_name(NULL, "gpio-controller");
Peter> if (!np || !np->data) {
Peter> printk(KERN_ERR
Peter> "gpio1 node not found or controller not registerred\n");
Peter> return -ENODEV;
Peter> }
Peter> gc = np->data;
Peter> gpio1 = gc->gc.base;
Peter> for (i=0; i<ARRAY_SIZE(gpios); i++) {
Peter> gpio_request(gpio1 + gpios[i], "spi");
Peter> gpio_direction_output(gpio1 + gpios[i], 1);
Peter> }
Peter> fsl_spi_init(thinx_spi_boardinfo, ARRAY_SIZE(thinx_spi_boardinfo),
Peter> thinx_spi_activate_cs, thinx_spi_deactivate_cs);
Peter> return 0;
Peter> }
Peter> Now, I don't quite see how to handle this with the new OF bindings -
Peter> Any ideas?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [BUILD FAILURE 03/12] Next April 14 : PPC64 randconfig [arch/powerpc/platforms/ps3/setup.c]
From: Subrata Modak @ 2009-04-17 5:47 UTC (permalink / raw)
To: Geoff Levand
Cc: sachinp, Stephen Rothwell, linux-kernel, Rafael J. Wysocki,
Linuxppc-dev, linux-next, Paul Mackerras, Geert Uytterhoeven,
Alexander Beregalov
In-Reply-To: <49E787DC.2050800@am.sony.com>
On Thu, 2009-04-16 at 12:32 -0700, Geoff Levand wrote:
> On 04/14/2009 11:28 AM, Subrata Modak wrote:
> > Observed the following build error:
> > ---
> > arch/powerpc/platforms/ps3/setup.c:49: error: redefinition of
> > ‘smp_send_stop’
> > include/linux/smp.h:125: error: previous definition of ‘smp_send_stop’
> > was here
>
> Hi Subrata,
>
> Thanks for the report. I submitted a fix to the powerpc ML:
>
> http://patchwork.ozlabs.org/patch/26084/
Thanks Geoff.
Regards--
Subrata
>
> -Geoff
>
^ permalink raw reply
* Please pull merge branch from git.secretlab.ca
From: Grant Likely @ 2009-04-17 5:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Stefan Roese, linuxppc-dev, Subrata Modak
Hi Ben/Paul,
Here are some fixups and documentation updates for 2.6.30
The following changes since commit 0882e8dd3aad33eca41696d463bb896e6c8817eb:
Linus Torvalds (1):
Linux 2.6.30-rc2
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 merge
Anton Vorontsov (1):
powerpc/5200: Bring the legacy fsl_spi_platform_data hooks back
Grant Likely (1):
powerpc/5200: Add FLASH nodes to lite5200 device tree
Stefan Roese (2):
powerpc/of-device-tree: Factor MTD physmap bindings out of
booting-without-of
powerpc/device-tree: Document MTD nodes with multiple "reg" tuples
Documentation/powerpc/booting-without-of.txt | 89 +++-----------------
Documentation/powerpc/dts-bindings/mtd-physmap.txt | 80 ++++++++++++++++++
arch/powerpc/boot/dts/lite5200b.dts | 39 +++++++++
include/linux/fsl_devices.h | 4 +
4 files changed, 135 insertions(+), 77 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Proposed prom parse fix + moving.
From: Michal Simek @ 2009-04-17 6:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ilpo.jarvinen, Arnd Bergmann
Hi All,
I have got email from Ilpo about prom_parse file.
I take this file from powerpc. Who did write prom_parse file and take care about?
BTW: What about to move prom_parse file to any generic location as we discussed in past?
Any volunteer?
Thanks,
Michal
-------- Original Message --------
Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
To: monstr@monstr.eu
CC: microblaze-uclinux@itee.uq.edu.au
While some version of the patches were on the lkml I read
some part of the code briefly through but my feedback got
stuck into postponed emails, so here's one correctness
related issue I might have found (the rest were just
cosmetic things).
I'm not sure if the latter return needs the of_node_put or not
but it seems more likely than not.
Not even compile tested.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
arch/microblaze/kernel/prom_parse.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel/prom_parse.c
index ae0352e..d1174bc 100644
--- a/arch/microblaze/kernel/prom_parse.c
+++ b/arch/microblaze/kernel/prom_parse.c
@@ -927,20 +927,23 @@ int of_irq_map_one(struct device_node *device,
/* Get size of interrupt specifier */
tmp = of_get_property(p, "#interrupt-cells", NULL);
if (tmp == NULL) {
- of_node_put(p);
- return -EINVAL;
+ res = -EINVAL;
+ goto out;
}
intsize = *tmp;
pr_debug(" intsize=%d intlen=%d\n", intsize, intlen);
/* Check index */
- if ((index + 1) * intsize > intlen)
- return -EINVAL;
+ if ((index + 1) * intsize > intlen) {
+ res = -EINVAL;
+ goto out;
+ }
/* Get new specifier and map it */
res = of_irq_map_raw(p, intspec + index * intsize, intsize,
addr, out_irq);
+out:
of_node_put(p);
return res;
}
--
1.5.6.5
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
^ permalink raw reply related
* Re: Proposed prom parse fix + moving.
From: Grant Likely @ 2009-04-17 6:44 UTC (permalink / raw)
To: monstr; +Cc: ilpo.jarvinen, linuxppc-dev, Arnd Bergmann
In-Reply-To: <49E81CED.1000704@monstr.eu>
On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wrote:
> Hi All,
>
> I have got email from Ilpo about prom_parse file.
> I take this file from powerpc. Who did write prom_parse file and take car=
e about?
Posting to the linuxppc-dev list is sufficient to start. There are
several people who may be interested.
> BTW: What about to move prom_parse file to any generic location as we dis=
cussed in past?
> Any volunteer?
I'm kind of working on it. More specifically, I'm looking at
factoring out fdt stuff into common code (drivers/of/of_fdt.c). But I
haven't made a whole lot of progress yet.
> -------- Original Message --------
> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
> From: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
> To: monstr@monstr.eu
> CC: microblaze-uclinux@itee.uq.edu.au
>
> While some version of the patches were on the lkml I read
> some part of the code briefly through but my feedback got
> stuck into postponed emails, so here's one correctness
> related issue I might have found (the rest were just
> cosmetic things).
>
> I'm not sure if the latter return needs the of_node_put or not
> but it seems more likely than not.
Yes, it does. This change is applicable to
arch/powerpc/kernel/prom_parse.c too.
>
> Not even compile tested.
>
> Signed-off-by: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
> ---
> =A0arch/microblaze/kernel/prom_parse.c | =A0 11 +++++++----
> =A01 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel=
/prom_parse.c
> index ae0352e..d1174bc 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -927,20 +927,23 @@ int of_irq_map_one(struct device_node *device,
> =A0 =A0 =A0 =A0/* Get size of interrupt specifier */
> =A0 =A0 =A0 =A0tmp =3D of_get_property(p, "#interrupt-cells", NULL);
> =A0 =A0 =A0 =A0if (tmp =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(p);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 res =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0intsize =3D *tmp;
>
> =A0 =A0 =A0 =A0pr_debug(" intsize=3D%d intlen=3D%d\n", intsize, intlen);
>
> =A0 =A0 =A0 =A0/* Check index */
> - =A0 =A0 =A0 if ((index + 1) * intsize > intlen)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 if ((index + 1) * intsize > intlen) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 res =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0/* Get new specifier and map it */
> =A0 =A0 =A0 =A0res =3D of_irq_map_raw(p, intspec + index * intsize, intsi=
ze,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addr, out_=
irq);
> +out:
> =A0 =A0 =A0 =A0of_node_put(p);
> =A0 =A0 =A0 =A0return res;
> =A0}
> --
> 1.5.6.5
>
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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