* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Valentine Barshak @ 2007-09-18 12:03 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070911224952.9838.46644.stgit@localhost.localdomain>
Vitaly Bordug wrote:
> +
> + hose->io_base_phys = cpu_phys_addr - pci_addr;
This is not gonna work on 32-bit platform (unless pci_addr == 0).
Should be
hose->io_base_phys = cpu_phys_addr;
The other way we should adjust io size like we do on 64-bit and rewrite
resource fixup functions.
> + /* handle from 0 to top of I/O window */
> +#ifdef CONFIG_PPC64
> + hose->pci_io_size = pci_addr + size;
> +#endif
> + hose->io_base_virt = ioremap(hose->io_base_phys, size);
Do we need to ioremap on 64-bit? I think 64-bit uses different approach
in handling io space.
> +#ifdef CONFIG_PPC32
> + if (prim)
> + isa_io_base = (unsigned long)hose->io_base_virt;
> +#endif
What's exactly the point of merging this single function?
If this was intended to add 64-bit physical address support to 32-bit
platforms (like ppc440), then it does not seem sufficient to make pci
stuff work right.
What about the 32-bit pcibios_fixup_resources(),
pcibios_resource_to_bus(), pcibios_bus_to_resource() stuff?
There's still no 64-bit support. You'll get
"PCI Cannot allocate resource region" attempting to initialize resources
at PCI start-up.
Thanks,
Valentine.
^ permalink raw reply
* [PATCH] [POWERPC][RFC] mpc8xx: fix build with CONFIG_MODULES=y
From: Anton Vorontsov @ 2007-09-18 12:07 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
It seems there is no __res in the arch/powerpc. How it was used in
the new tree, can we now safely remove it? At least kernel builds
with that patch.
Thanks,
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/ppc_ksyms.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 430c502..b4163c3 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -180,9 +180,6 @@ EXPORT_SYMBOL(cacheable_memcpy);
EXPORT_SYMBOL(cpm_install_handler);
EXPORT_SYMBOL(cpm_free_handler);
#endif /* CONFIG_8xx */
-#if defined(CONFIG_8xx)
-EXPORT_SYMBOL(__res);
-#endif
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(next_mmu_context);
--
1.5.0.6
^ permalink raw reply related
* multicasting in MPC8272ADS
From: Nethra @ 2007-09-18 12:08 UTC (permalink / raw)
To: linuxppc-dev
hi,
I have written a multicast test application in which there is a multicast
sender and receiver.
The multicast sender sends multicast packets on a specified interface and
the multicast
receiver receives multicast packets. I have tested this application on my
network with
x86 machines. But when I run a multicast receiver (which has been cross
compiled for
MPC8272ADS) on my MPC board, it is unable to receive multicast packets (the
recvfrom
call is waiting for ever for packets to arrive). The MPC board is able to
send multicast
packets to without any problems. The /proc/net/dev_mcast shows the
appropriate
entries for the multicast address being enabled for the interface of
interest(esentially
group joining appear to work).
My configuration is a MPC8272ADS board rp_filter =0 for all interfaces (ie
no source
filtering).I am wondering where the problem could be, configurations or the
ethernet
driver itself? Are there some known issues ?
By the way with loopback enabled the reception of packets works
in case the sender and receiver are on the same machine
waiting for ur comments..
thnks
--
View this message in context: http://www.nabble.com/multicasting-in-MPC8272ADS-tf4473829.html#a12755615
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] [POWERPC][RFC] sysdev/commproc.c: fix build caused by undefined symbols
From: Anton Vorontsov @ 2007-09-18 12:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070918120752.GA4859@localhost.localdomain>
cpm_install_handler and cpm_free_handler neither used nor defined
for arch/powerpc.
This causes MPC8xx build failure, patch used to fix that.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/kernel/ppc_ksyms.c | 5 -----
include/asm-powerpc/commproc.h | 3 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index b4163c3..4d28774 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -176,11 +176,6 @@ EXPORT_SYMBOL(console_drivers);
EXPORT_SYMBOL(cacheable_memcpy);
#endif
-#ifdef CONFIG_8xx
-EXPORT_SYMBOL(cpm_install_handler);
-EXPORT_SYMBOL(cpm_free_handler);
-#endif /* CONFIG_8xx */
-
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(next_mmu_context);
EXPORT_SYMBOL(set_context);
diff --git a/include/asm-powerpc/commproc.h b/include/asm-powerpc/commproc.h
index 3972487..0d92012 100644
--- a/include/asm-powerpc/commproc.h
+++ b/include/asm-powerpc/commproc.h
@@ -686,7 +686,4 @@ typedef struct risc_timer_pram {
#define CICR_IEN ((uint)0x00000080) /* Int. enable */
#define CICR_SPS ((uint)0x00000001) /* SCC Spread */
-extern void cpm_install_handler(int vec, void (*handler)(void *), void *dev_id);
-extern void cpm_free_handler(int vec);
-
#endif /* __CPM_8XX__ */
--
1.5.0.6
^ permalink raw reply related
* [PATCH] [POWERPC] sysdev/commproc.c: fix copy-n-paste problem
From: Anton Vorontsov @ 2007-09-18 12:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070918120752.GA4859@localhost.localdomain>
Second export should be for cpm_dpram_phys not cpm_dpram_addr.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/commproc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index b562afc..160a8b4 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -387,4 +387,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
--
1.5.0.6
^ permalink raw reply related
* Re: 2.6.23-rc6-mm1
From: Kamalesh Babulal @ 2007-09-18 12:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1190109772.6403.79.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Tue, 2007-09-18 at 10:34 +0100, Andy Whitcroft wrote:
>
>> On Tue, Sep 18, 2007 at 02:43:48PM +0530, Kamalesh Babulal wrote:
>>
>>> Andrew Morton wrote:
>>>
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
>>>>
>>>> 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
>>>>
>>>>
>>>>
>>> <snip>
>>>
>>> Hi Andrew,
>>>
>>> The 2.6.23-rc6-mm1build fails at
>>>
>>> CC drivers/pci/hotplug/rpadlpar_core.o
>>> CC drivers/pci/hotplug/rpadlpar_sysfs.o
>>> drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
>>> specified in initializer
>>> drivers/pci/hotplug/rpadlpar_sysfs.c: In function `dlpar_sysfs_init':
>>> drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member
>>> named `name'
>>> make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
>>> make[2]: *** [drivers/pci/hotplug] Error 2
>>> make[1]: *** [drivers/pci] Error 2
>>> make: *** [drivers] Error 2
>>>
>> This seems to be occuring across a number of the powerpc systems we test
>> with. That driver is a power dynamic lpar IO partitioning driver.
>>
>> Relevant Cc: added.
>>
>
> That's because somebody is breaking sysfs/kobject interfaces without
> fixing all users :-) (Fair enough... it's just that we need to make sure
> whoever takes care of that driver nowadays is aware of the breakage).
>
> Ben.
>
Hi Andrew,
Using the kobject_set_name function to set the kobject k_name.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
---
--- linux-2.6.23-rc6/drivers/pci/hotplug/rpadlpar_sysfs.c
2007-09-18 14:56:05.000000000 +0530
+++ linux-2.6.23-rc6/drivers/pci/hotplug/~rpadlpar_sysfs.c
2007-09-18 16:51:55.000000000 +0530
@@ -129,17 +129,17 @@ struct kobj_type ktype_dlpar_io = {
};
struct kset dlpar_io_kset = {
- .kobj = {.name = DLPAR_KOBJ_NAME,
- .ktype = &ktype_dlpar_io,
- .parent = &pci_hotplug_slots_subsys.kobj},
+ .kobj = {.ktype = &ktype_dlpar_io,
+ .parent = &pci_hotplug_slots_subsys.kobj},
.ktype = &ktype_dlpar_io,
};
int dlpar_sysfs_init(void)
{
+ kobject_set_name(&dlpar_io_kset.kobj, DLPAR_KOBJ_NAME);
if (kset_register(&dlpar_io_kset)) {
printk(KERN_ERR "rpadlpar_io: cannot register kset for
%s\n",
- dlpar_io_kset.kobj.name);
+ dlpar_io_kset.kobj.k_name);
return -EINVAL;
}
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* cross compiling a library with ELDK
From: Murat Artun @ 2007-09-18 13:02 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I want to cross compile a free software library with ELDK 3.1.1 for
powerpc. I have ELDK installed under directory /opt and my system and
PATH is set properly. I have a few points to be clarified:
- GCC toolchain components for cross compiling have "ppc_8xx-" prefix
in their names. In addition, I learned from trial and error that by
setting --host=CROSS_ENV results generation of a Makefile with
compilation tools to be prefixed with CROSS_ENV. So I set
--host=ppc_8xx but I received below error from configure script:
checking host system type... Invalid configuration `ppc_8xx': machine
`ppc_8xx' not recognized
configure: error: /bin/sh scripts/config.sub ppc_8xx failed
I have checked config.sub file and could not find ppc_8xx as a machine
type. I have added it myself properly and executed configure script
and generated a Makefile with all ppc_8xx prefixed GCC toolchain
components (g++, ar, ranlib etc.). Considering that I have edited
config.sub file, is this the true way of cross compilation? Or, if
not, what is the way of specifying machine type for ELDK cross
compilation and making the configure script to generate a Makefile
with ppc_8xx prefixed GCC toolchain components.
- For a cross compilation with ELDK how can we be sure that config.h
file for a software packet is generated properly? I mean, how can we
be sure that ELDK components is checked instead of our host linux
system for generating a config.h file by the configure script?
Thanks in advice...
--
M u r at A r t u n, MSc.
Design Engineer
"be conservative in what you do, be liberal in what you accept from others"
^ permalink raw reply
* Re: [PATCH 18/28] 8xx: mpc885ads cleanup
From: Stephen Rothwell @ 2007-09-18 13:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070917165805.GR6563@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Mon, 17 Sep 2007 11:58:05 -0500 Scott Wood <scottwood@freescale.com> wrote:
>
> +++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
> #include <asm/fs_pd.h>
> -#include <asm/prom.h>
> +#include <asm/of_platform.h>
linux/of_platform.h
Sorry if I am getting boring.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem booting linux with device tree table
From: Andrew Liu @ 2007-09-18 9:01 UTC (permalink / raw)
To: Mustafa Cayir; +Cc: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F070B9298@itri.bte.mam.gov.tr>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
Latest U-boot need a chosen node in your DTS file, So u need to add a
chosen node in your DTS file.
Take mpc8272ads for example: in its DTS, has the following:
chosen {
name = "chosen";
linux,platform = <0>;
interrupt-controller = <&Cpm_pic>;
};
BRs,
Andrew
Mustafa Cayir wrote:
>
> Hi all,
>
> I am trying to boot TQM5200 with linux 2.6 kernel. i am using latest
> version of linux and u-boot from denx. And compiled with ELDK4.1
>
> i use dtc compiler with following command:
> dtc -O dtb -o tqm5200.dtb -b 0 tqm5200.dts
>
> Booting process gives following error and reset the board.
>
> WARNING: could not create /chosen FDT_ERR_NOSPACE.
> ERROR: /chosen node create failed - must RESET the board to recover.
>
> Regards.
>
>
>
> Using FEC ETHERNET device
> TFTP from server 10.18.2.83; our IP address is 10.18.5.44
> Filename 'uImage'.
> Load address: 0x200000
> Loading: #################################################################
> ####################################
> done
> Bytes transferred = 1473038 (167a0e hex)
> Using FEC ETHERNET device
> TFTP from server 10.18.2.83; our IP address is 10.18.5.44
> Filename 'tqm5200.dtb'.
> Load address: 0x400000
> Loading: #
> done
> Bytes transferred = 3816 (ee8 hex)
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.23-rc6-gf695e369
> Created: 2007-09-19 1:31:43 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1472974 Bytes = 1.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x400000
> WARNING: could not create /chosen FDT_ERR_NOSPACE.
> ERROR: /chosen node create failed - must RESET the board to recover.
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: shengping.liu.vcf --]
[-- Type: text/x-vcard, Size: 385 bytes --]
begin:vcard
fn:Andrew Liu
n:;Andrew Liu
org:China Development Center;Engineering
adr:;;Wangjing Zhonghuan Nanlu No.9 Wangjing Plaza Tower B 15F Chaoyang District Beijing China;Beijing;;100102;China
email;internet:shengping.liu@windriver.com
tel;work:86-10-8477-8639
tel;fax:86-10-6479-0367
tel;cell:86-13717751687
url:http://twiki.wrs.com/do/view/Main/AndrewLiu
version:2.1
end:vcard
^ permalink raw reply
* Re: PSC in UART mode on TQM5200S
From: Grant Likely @ 2007-09-18 14:01 UTC (permalink / raw)
To: Leopold Stotch; +Cc: linuxppc-embedded
In-Reply-To: <53b5d6e90709180313n7ef053ddqfb771f44d9bd44ef@mail.gmail.com>
On 9/18/07, Leopold Stotch <l.butterz@gmail.com> wrote:
> Hello, everyone !
>
> I have TQM5200S module and development board.
> It runs factory UBoot and latest DENX's linuxppc_2_4_devel kernel.
> I want to configure all TQM5200S's onboard PSC's as UART's.
> TQM5200S's onboard PSC's are connected to custom board
> that makes all electrical things as my hardware engineer says...
> So changed
> $HOME/linuxppc_2_4_devel/arch/ppc/platforms/tqm5200.h
> the following way:
>
> #ifdef CONFIG_PS2MULT
> #define RS_TABLE_SIZE 4
> #else
> #if defined(CONFIG_SPI_EVAL) || defined(CONFIG_TB5200)
> #define RS_TABLE_SIZE 2
> #elif defined(CONFIG_CAM5200)
> #define RS_TABLE_SIZE 6
> #else
> #define RS_TABLE_SIZE 3
> #endif
> #endif
>
> changed to
>
> #ifdef CONFIG_PS2MULT
> #define RS_TABLE_SIZE 4
> #else
> #if defined(CONFIG_SPI_EVAL) || defined(CONFIG_TB5200)
> #define RS_TABLE_SIZE 2
> #elif defined(CONFIG_CAM5200)
> #define RS_TABLE_SIZE 6
> #else
> #define RS_TABLE_SIZE 6
> #endif
> #endif
>
> and
>
> #else /* default */
> #define SERIAL_PORT_DFNS \
> STD_PSC_OP(1) \
> STD_PSC_OP(2) \
> STD_PSC_OP(3)
> #endif
>
> changed to
>
> #else /* default */
> #define SERIAL_PORT_DFNS \
> STD_PSC_OP(1) \
> STD_PSC_OP(2) \
> STD_PSC_OP(3) \
> STD_PSC_OP(4) \
> STD_PSC_OP(5) \
> STD_PSC_OP(6)
> #endif
>
> After rebuilding the kernel, dmesg says:
>
> ...
> ttyS0 on PSC1
> ttyS1 on PSC2
> ttyS2 on PSC3
> ttyS3 on PSC4
> ttyS4 on PSC5
> ttyS5 on PSC6
> ...
>
> But when i do "echo 1 > /dev/ttyS4" i receive nothing at the other end.
Have you made the appropriate changes to the port_config register?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ucc_geth: fix compilation
From: Kumar Gala @ 2007-09-18 14:04 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Jeff Garzik, netdev
In-Reply-To: <989B956029373F45A0B8AF029708189001763D1E@zch01exm26.fsl.freescale.net>
On Sep 18, 2007, at 3:56 AM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org]
>> On Behalf Of Kumar Gala
>> Sent: Friday, September 14, 2007 10:08 PM
>> To: Jeff Garzik
>> Cc: linuxppc-dev@ozlabs.org list; netdev
>> Subject: Re: [PATCH] ucc_geth: fix compilation
>>
>>
>> On Sep 13, 2007, at 10:23 AM, Anton Vorontsov wrote:
>>
>>> Currently qe_bd_t is used in the macro call --
>> dma_unmap_single, which
>>> is a no-op on PPC32, thus error is hidden today. Starting
>> with 2.6.24,
>>> macro will be replaced by the empty static function, and
>> erroneous use
>>> of qe_bd_t will trigger compilation error.
>>>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> ---
>>
>> Jeff, I'm going to pick this up via the powerpc.git tree
>> since its currently only broken in our for-2.6.24 branch
>> (because of other changes in there). Any issues?
>
> Kumar,
>
> Kim Phillips has posted the same patch to netdev list before Anton.
> Therefore, I do prefer to use his. Thanks
No problem. Jeff seems to have picked up some version of the fix.
- k
^ permalink raw reply
* Re: [PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
From: Kumar Gala @ 2007-09-18 14:11 UTC (permalink / raw)
To: tnt, Sylvain Munaut; +Cc: PowerPC dev list
In-Reply-To: <58950.87.65.18.190.1190089793.squirrel@www.opensources.be>
On Sep 17, 2007, at 11:29 PM, tnt@blacksnow.net wrote:
>> On 9/16/07, Sylvain Munaut <tnt@246tnt.com> wrote:
>>> Hello Paul, Hi everyone,
>>>
>>> This series of patch is mainly the bestcomm support for
>>> the mpc5200. It was posted a while ago and received some
>>> comments. Theses are all addressed here (afaik).
>>
>> Does this series supersede these pacthes out of your older series?
>
> Yes.
> Those are the patches I wrote to fix the comments received last time.
> They are now merged inside the main patches.
>
> Apparently I forgot to fix some other comments so I'll have to do
> that and repost again.
>
One of the big things I'd like to see for the core bestcomm lib is
proper kernel doc support for the APIs. I think we should be going
more of this for things like QE and will push on the guys doing
working there to better document the 'library' APIs.
Also, I remember you wrote up some documentation/email about what the
APIs did. Is that in a clean enough state to add do Documentation/
powerpc/?
- k
^ permalink raw reply
* RE: Ethernet adapter not found in Xilinx ppc, with linux 2.6.22
From: Junqiang Hu @ 2007-09-18 14:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY138-F271854679106F05A7C7117B2B80@phx.gbl>
Hi, Ming,
I do have the Xilinx generated Ethernet driver in hand, but could you
suggest how to add that driver into my 2.6.22 version?
Thanks!
mliu wrote:
>=20
> Hi,
>>
>>After several days of struggling I'm now able to boot the linux 2.6.22 an=
d
>>run the busybox-1.7.1 root system. Yet I could not find the Ethernet
>>adapter using Xilinx GMAC core. Pretty sure that I've chosen the 10/100
>>Ethernet drivers. Should I use the Xilinx driver xemac, or other drivers=
,
>>or any other way to apply a patch?
>=20
> If you are using gigabit ethernet, you must have the corresponding driver=
=20
> (gigabit or tri-state) instead of 10/100 one included.=20
>=20
> BR
> Ming
>=20
> _________________________________________________________________
> =E5=85=8D=E8=B4=B9=E4=B8=8B=E8=BD=BD MSN Explorer: http://explorer.msn.=
com/lccn/ =20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
--=20
View this message in context: http://www.nabble.com/Ethernet-adapter-not-fo=
und-in-Xilinx-ppc%2C-with-linux-2.6.22-tf4470255.html#a12758059
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 01/28] CPM: Change from fsl, brg-frequency to brg/clock-frequency
From: Scott Wood @ 2007-09-18 14:21 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070918061141.GE30766@localhost.localdomain>
On Tue, Sep 18, 2007 at 04:11:41PM +1000, David Gibson wrote:
> > + /* Legacy device binding -- will go away when no users are left. */
> > + node = of_find_node_by_type(NULL, "cpm");
> > + if (node) {
> > + prop = of_get_property(node, "brg-frequency", &size);
>
> Shouldn't you check for "fsl,brg-frequency" here, in case of old
> device trees?
What old device trees? fsl,brg-frequency has never hit mainline; it's
only been in Kumar's tree for a week or so.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC][RFC] sysdev/commproc.c: fix build caused by undefined symbols
From: Kumar Gala @ 2007-09-18 14:26 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070918122925.GA17481@localhost.localdomain>
On Sep 18, 2007, at 7:29 AM, Anton Vorontsov wrote:
> cpm_install_handler and cpm_free_handler neither used nor defined
> for arch/powerpc.
>
> This causes MPC8xx build failure, patch used to fix that.
can you add the __res fix, and EXPORT() and do these three as one
patch and improve the commit message. I'm guessing this all shows up
when we try to build with CONFIG_MODULES=y. Put the actual compile
failures in the commit message.
- k
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Vitaly Bordug @ 2007-09-18 14:27 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EFBEA6.4050406@ru.mvista.com>
Hello Valentine,
On Tue, 18 Sep 2007 16:03:50 +0400
Valentine Barshak wrote:
> Vitaly Bordug wrote:
> > +
> > + hose->io_base_phys = cpu_phys_addr - pci_addr;
>
> This is not gonna work on 32-bit platform (unless pci_addr == 0).
> Should be
> hose->io_base_phys = cpu_phys_addr;
> The other way we should adjust io size like we do on 64-bit and rewrite
> resource fixup functions.
>
I think the second sounds like a plan then. We should not "assume" where we can make things to behave properly.
> > + /* handle from 0 to top of I/O window */
> > +#ifdef CONFIG_PPC64
> > + hose->pci_io_size = pci_addr + size;
> > +#endif
> > + hose->io_base_virt = ioremap(hose->io_base_phys, size);
>
> Do we need to ioremap on 64-bit? I think 64-bit uses different approach
> in handling io space.
>
Correct - 64 bit code does __get_vm_area() so the upper line is ppc32-specific.
> > +#ifdef CONFIG_PPC32
> > + if (prim)
> > + isa_io_base = (unsigned long)hose->io_base_virt;
> > +#endif
>
> What's exactly the point of merging this single function?
> If this was intended to add 64-bit physical address support to 32-bit
> platforms (like ppc440), then it does not seem sufficient to make pci
> stuff work right.
> What about the 32-bit pcibios_fixup_resources(),
> pcibios_resource_to_bus(), pcibios_bus_to_resource() stuff?
> There's still no 64-bit support. You'll get
> "PCI Cannot allocate resource region" attempting to initialize resources
> at PCI start-up.
Because this function is critical to get the stuff going. You can have some devices working even without PCI resources initted
(what in fact I had with mpc8272). I am in process of moving the mentioned to the common_... domain but I suspect there are other 32-bit-stick stuff still. So if you want to assist in cleaning this up, feel free to join the club...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Valentine Barshak @ 2007-09-18 14:38 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070918182704.640c677f@localhost.localdomain>
Vitaly Bordug wrote:
> Hello Valentine,
>
> On Tue, 18 Sep 2007 16:03:50 +0400
> Valentine Barshak wrote:
>
>> Vitaly Bordug wrote:
>>> +
>>> + hose->io_base_phys = cpu_phys_addr - pci_addr;
>> This is not gonna work on 32-bit platform (unless pci_addr == 0).
>> Should be
>> hose->io_base_phys = cpu_phys_addr;
>> The other way we should adjust io size like we do on 64-bit and rewrite
>> resource fixup functions.
>>
> I think the second sounds like a plan then. We should not "assume" where we can make things to behave properly.
>
>>> + /* handle from 0 to top of I/O window */
>>> +#ifdef CONFIG_PPC64
>>> + hose->pci_io_size = pci_addr + size;
>>> +#endif
>>> + hose->io_base_virt = ioremap(hose->io_base_phys, size);
>> Do we need to ioremap on 64-bit? I think 64-bit uses different approach
>> in handling io space.
>>
> Correct - 64 bit code does __get_vm_area() so the upper line is ppc32-specific.
>>> +#ifdef CONFIG_PPC32
>>> + if (prim)
>>> + isa_io_base = (unsigned long)hose->io_base_virt;
>>> +#endif
>> What's exactly the point of merging this single function?
>> If this was intended to add 64-bit physical address support to 32-bit
>> platforms (like ppc440), then it does not seem sufficient to make pci
>> stuff work right.
>> What about the 32-bit pcibios_fixup_resources(),
>> pcibios_resource_to_bus(), pcibios_bus_to_resource() stuff?
>> There's still no 64-bit support. You'll get
>> "PCI Cannot allocate resource region" attempting to initialize resources
>> at PCI start-up.
> Because this function is critical to get the stuff going. You can have some devices working even without PCI resources initted
> (what in fact I had with mpc8272). I am in process of moving the mentioned to the common_... domain but I suspect there are other 32-bit-stick stuff still. So if you want to assist in cleaning this up, feel free to join the club...
Well, thanks for the invitation :)
I've been trying to work on the pci support here too. But I've used a
bit different approach. I tried to add 64-bit phys addr support to
pci_32.c. The patch seems to work on Sequoia. Actually, I thought
merging was too risky at this point and might cause more problems
breaking both 64 and 32-bit pci support.
Thanks,
Valentine.
^ permalink raw reply
* [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Valentine Barshak @ 2007-09-18 14:44 UTC (permalink / raw)
To: linuxppc-dev
Add 64-bit physical address support to PCI.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/iomap.c | 4 +--
arch/powerpc/kernel/pci_32.c | 56 +++++++++++++++++++++++++++++--------------
2 files changed, 41 insertions(+), 19 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/iomap.c linux-2.6/arch/powerpc/kernel/iomap.c
--- linux-2.6.orig/arch/powerpc/kernel/iomap.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/iomap.c 2007-09-18 17:26:35.000000000 +0400
@@ -119,8 +119,8 @@
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
{
- unsigned long start = pci_resource_start(dev, bar);
- unsigned long len = pci_resource_len(dev, bar);
+ resource_size_t start = pci_resource_start(dev, bar);
+ resource_size_t len = pci_resource_len(dev, bar);
unsigned long flags = pci_resource_flags(dev, bar);
if (!len)
diff -ruN linux-2.6.orig/arch/powerpc/kernel/pci_32.c linux-2.6/arch/powerpc/kernel/pci_32.c
--- linux-2.6.orig/arch/powerpc/kernel/pci_32.c 2007-09-18 15:32:19.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/pci_32.c 2007-09-18 18:17:00.000000000 +0400
@@ -105,7 +105,7 @@
{
struct pci_controller* hose = (struct pci_controller *)dev->sysdata;
int i;
- unsigned long offset;
+ resource_size_t offset;
if (!hose) {
printk(KERN_ERR "No hose for PCI dev %s!\n", pci_name(dev));
@@ -115,7 +115,7 @@
struct resource *res = dev->resource + i;
if (!res->flags)
continue;
- if (res->end == 0xffffffff) {
+ if (res->end == (resource_size_t) -1) {
DBG("PCI:%s Resource %d [%016llx-%016llx] is unassigned\n",
pci_name(dev), i, (u64)res->start, (u64)res->end);
res->end -= res->start;
@@ -148,7 +148,7 @@
void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
struct resource *res)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -163,7 +163,7 @@
void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
struct pci_bus_region *region)
{
- unsigned long offset = 0;
+ resource_size_t offset = 0;
struct pci_controller *hose = dev->sysdata;
if (hose && res->flags & IORESOURCE_IO)
@@ -439,7 +439,7 @@
u8 io_base_lo, io_limit_lo;
u16 mem_base, mem_limit;
u16 cmd;
- unsigned long start, end, off;
+ resource_size_t start, end, off;
struct pci_controller *hose = dev->sysdata;
if (!hose) {
@@ -843,16 +843,28 @@
}
EXPORT_SYMBOL(pci_device_from_OF_node);
+
+static inline u64 pci_get_range64(u32 *r)
+{
+ return (((u64)r[0] << 32) | r[1]);
+}
+
+
void __init
pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
static unsigned int static_lc_ranges[256] __initdata;
const unsigned int *dt_ranges;
- unsigned int *lc_ranges, *ranges, *prev, size;
+ unsigned int *lc_ranges, *ranges, *prev;
int rlen = 0, orig_rlen;
int memno = 0;
struct resource *res;
+ u32 prev_pci_space, pci_space;
+ u64 prev_pci_addr, pci_addr;
+ u64 prev_size, size;
+ phys_addr_t cpu_phys_addr;
+
int np, na = of_n_addr_cells(dev);
np = na + 5;
@@ -879,11 +891,18 @@
prev = NULL;
while ((rlen -= np * sizeof(unsigned int)) >= 0) {
if (prev) {
- if (prev[0] == ranges[0] && prev[1] == ranges[1] &&
- (prev[2] + prev[na+4]) == ranges[2] &&
- (prev[na+2] + prev[na+4]) == ranges[na+2]) {
- prev[na+4] += ranges[na+4];
+ prev_pci_space = prev[0];
+ prev_pci_addr = pci_get_range64(&prev[1]);
+ prev_size = pci_get_range64(&prev[na+3]);
+ pci_space = ranges[0];
+ pci_addr = pci_get_range64(&ranges[1]);
+ if ((prev_pci_space == pci_space) &&
+ ((prev_pci_addr + prev_size) == pci_addr)) {
+ size = pci_get_range64(&ranges[na+3]);
+ prev_size += size;
ranges[0] = 0;
+ prev[na+3] = (u32)((prev_size >> 32) & 0xffffffff);
+ prev[na+4] = (u32)(prev_size & 0xffffffff);
ranges += np;
continue;
}
@@ -904,21 +923,22 @@
rlen = orig_rlen;
while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
res = NULL;
- size = ranges[na+4];
- switch ((ranges[0] >> 24) & 0x3) {
+ size = pci_get_range64(&ranges[na+3]);
+ pci_space = ranges[0] >> 24;
+ switch (pci_space & 0x3) {
case 1: /* I/O space */
if (ranges[2] != 0)
break;
- hose->io_base_phys = ranges[na+2];
+ hose->io_base_phys = of_translate_address(dev, &ranges[3]);
/* limit I/O space to 16MB */
if (size > 0x01000000)
size = 0x01000000;
- hose->io_base_virt = ioremap(ranges[na+2], size);
+ hose->io_base_virt = ioremap(hose->io_base_phys, size);
if (primary)
isa_io_base = (unsigned long) hose->io_base_virt;
res = &hose->io_resource;
res->flags = IORESOURCE_IO;
- res->start = ranges[2];
+ res->start = pci_get_range64(&ranges[1]);
DBG("PCI: IO 0x%llx -> 0x%llx\n",
(u64)res->start, (u64)res->start + size - 1);
break;
@@ -933,14 +953,16 @@
}
while (memno < 3 && hose->mem_resources[memno].flags)
++memno;
+ pci_addr = pci_get_range64(&ranges[1]);
+ cpu_phys_addr = of_translate_address(dev, &ranges[3]);
if (memno == 0)
- hose->pci_mem_offset = ranges[na+2] - ranges[2];
+ hose->pci_mem_offset = (u64)cpu_phys_addr - pci_addr;
if (memno < 3) {
res = &hose->mem_resources[memno];
res->flags = IORESOURCE_MEM;
if(ranges[0] & 0x40000000)
res->flags |= IORESOURCE_PREFETCH;
- res->start = ranges[na+2];
+ res->start = cpu_phys_addr;
DBG("PCI: MEM[%d] 0x%llx -> 0x%llx\n", memno,
(u64)res->start, (u64)res->start + size - 1);
}
^ permalink raw reply
* RE: [PATCH 23/28] mpc82xx: Define CPU_FTR_NEED_COHERENT
From: Rune Torgersen @ 2007-09-18 14:34 UTC (permalink / raw)
To: Scott Wood, galak; +Cc: linuxppc-dev
In-Reply-To: <20070917165815.GW6563@loki.buserror.net>
> -----Original Message-----
> From: Scott Wood
> Sent: Monday, September 17, 2007 11:58 AM
>=20
> The 8272 (and presumably other PCI PQ2 chips) appear to have the
> same issue as the 83xx regarding PCI streaming DMA.
>=20
Can you explain what this isssue is? We're using a 8280 and have had
some PCI busmaster DMA problems, and wonder if it is related.
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Kumar Gala @ 2007-09-18 14:52 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070918144426.GA22102@ru.mvista.com>
On Sep 18, 2007, at 9:44 AM, Valentine Barshak wrote:
> Add 64-bit physical address support to PCI.
Can you expand on your commit message. for example why do this? is
it address a bug fix, etc..
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/kernel/iomap.c | 4 +--
> arch/powerpc/kernel/pci_32.c | 56 ++++++++++++++++++++++++++++
> +--------------
> 2 files changed, 41 insertions(+), 19 deletions(-)
- k
^ permalink raw reply
* Re: [PATCH 03/28] Document local bus nodes in the device tree.
From: Kumar Gala @ 2007-09-18 15:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070917165731.GC6563@loki.buserror.net>
On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
> cuboot-pq2 is updated to match the binding, and get rid of phandle
> linkage.
A slight more descriptive commit message is desired.
- k
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 38 +++++++++++++++
> +++++++++++
> arch/powerpc/boot/cuboot-pq2.c | 29 ++++
> +--------------
> 2 files changed, 46 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Valentine Barshak @ 2007-09-18 15:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2E339F78-F42B-4FCE-A97E-FFE9AE4C44F1@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 18, 2007, at 9:44 AM, Valentine Barshak wrote:
>
>> Add 64-bit physical address support to PCI.
>
> Can you expand on your commit message. for example why do this? is it
> address a bug fix, etc..
>
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> arch/powerpc/kernel/iomap.c | 4 +--
>> arch/powerpc/kernel/pci_32.c | 56
>> +++++++++++++++++++++++++++++--------------
>> 2 files changed, 41 insertions(+), 19 deletions(-)
>
> - k
>
Currently 32-bit pci code doesn't support 64-bit physical addresses.
We have to add 64-bit addr support in order to bring-up pci on PowerPC
440. Actually, this refers to the conversation started here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042267.html
Thanks,
Valentine.
^ permalink raw reply
* Re: dtc: Add basic testcases for dtc
From: Jon Loeliger @ 2007-09-18 15:02 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070918003340.GA30766@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch adds a handful of simple testcases for dtc. It adds a dts
> file which should generate the same sample tree as is used for the
> libfdt testcases, and tests invoking dtc on this dts, plus the
> standard batch of libfdt cases on the resulting dtb, which effectively
> checks that the dtb is correct.
>
> Because the test framework assumes each testcase is an executable with
> the right output conventions, we use a little shell script, dtc.sh, as
> a wrapper around dtc itself. It simply invokes dtc and returns a PASS
> or FAIL depending on whether dtc returned an error.
>
> It's not much, but it's a start.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
> NB: Jon, you won't be able to simply git-applymbox this and have it
> work. You'll need to manually add execute permission to tests/dtc.sh
> before git commiting it, since I can't encode the permissions in a
> patch. Sorry for the inconvenience, but it didn't really seem worth
> setting up my own git to pull from just for that.
No problem. Too bad you can't just use git, though... :-)
jdl
^ permalink raw reply
* Re: dtc: Whitespace cleanup
From: Jon Loeliger @ 2007-09-18 15:03 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070918014404.GB30766@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This large patch removes all trailing whitespace from dtc (including
> libfdt, the testsuite and documentation). It also removes a handful
> of redundant blank lines (at the end of functions, or when there are
> two blank lines together for no particular reason).
>
> As well as anything else, this means that quilt won't whinge when I go
> to convert the whole of libfdt into a patch to apply to the kernel.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-09-18 15:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070917165746.GP6563@loki.buserror.net>
On Sep 17, 2007, at 11:57 AM, Scott Wood wrote:
> On arch/ppc, Soft_emulate_8xx was used when full math emulation was
> turned off to emulate a minimal subset of floating point load/store
> instructions, to avoid needing a soft-float toolchain. This function
> is called, but not present, on arch/powerpc, causing a build error
> if floating point emulation is turned off.
>
> As:
> 1. soft-float toolchains are now common,
> 2. partial emulation could mislead someone into thinking they have
> a soft-float userspace because things usually work, only to have it
> fail when actual FP gets executed under unusual circumstances, and
> 3. full emulation is still available for those who need to run
> non-soft-float userspace,
>
> I'm deleting the call rather than moving Soft_emulate_8xx over to
> arch/powerpc.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I'm still not in favor of this and think we should move the
Soft_emulate_8xx code over.
- k
^ 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