* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Scott Wood @ 2007-09-18 15:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <027F3363-3154-4A16-A251-C56D8DC339A1@kernel.crashing.org>
On Tue, Sep 18, 2007 at 10:19:05AM -0500, Kumar Gala wrote:
> Mainly that 8xx has been doing this for a vast number of years and I
> see no reason to stop doing it at this point.
>
> While I can see that it might be misleading, clearly 8xx linux users
> haven't had issues with it.
Or they haven't said anything. :-P
How about a three-way choice of full emulation, minimal emulation, and no
emulation?
-Scott
^ permalink raw reply
* Re: Problem booting linux with device tree table
From: Scott Wood @ 2007-09-18 15:17 UTC (permalink / raw)
To: Andrew Liu; +Cc: linuxppc-embedded
In-Reply-To: <46EF93D8.6050201@windriver.com>
On Tue, Sep 18, 2007 at 05:01:12PM +0800, Andrew Liu wrote:
> Latest U-boot need a chosen node in your DTS file,
It does not.
> 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>;
> };
Please don't use that file as an example. :-)
-Scott
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Domen Puncer @ 2007-09-18 15:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: netdev, linuxppc-embedded
In-Reply-To: <9e4733910709171508s76c842c8hca236249617cbb44@mail.gmail.com>
(I edited Cc: -jeff, +sven, hope you don't mind)
On 17/09/07 18:08 -0400, Jon Smirl wrote:
> On 9/17/07, Domen Puncer <domen@coderock.org> wrote:
> > Export phy_mii_ioctl, so network drivers can use it when built
> > as modules too.
>
> Domen, do you want to collect all of these changes for MPC5200 FEC in
> to a single patch series? The code is getting scattered around, I'll
> check it over to make sure it is all working. I have these patches
> applied individually and they all work.
>
> It builds on this series:
> [PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
>
> If you can put this together is a clean series, I should be able to
> layer support for the Phytec pcm030 on top of it.
>
> It would be these three combined...
>
> http://coderock.org/tmp/fec-v3rc1/
http://coderock.org/tmp/fec-v3rc2/
export_phy_mii_ioctl
fec_driver-bestcomm
fec_driver-dts
fec_driver-fec
fec_driver-phy
Built (on top of 7 bestcomm patches) and ran it built-in and as module
on Efika.
Order of applying only matters for phy part, which has to be after
the fec driver.
More testing and getting it to work properly on Phytec pcm030 would
be great.
Domen
^ 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:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070918151147.GB736@ld0162-tx32.am.freescale.net>
On Sep 18, 2007, at 10:11 AM, Scott Wood wrote:
> On Tue, Sep 18, 2007 at 10:08:50AM -0500, Kumar Gala wrote:
>>
>> 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.
>
> Any particular reasons that outweigh the reasons I gave, especially
> #2?
Mainly that 8xx has been doing this for a vast number of years and I
see no reason to stop doing it at this point.
While I can see that it might be misleading, clearly 8xx linux users
haven't had issues with it.
- k
^ permalink raw reply
* Re: [PATCH 16/28] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Scott Wood @ 2007-09-18 15:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <58472170-34D3-43F4-A816-87AF0020A086@kernel.crashing.org>
On Tue, Sep 18, 2007 at 10:08:50AM -0500, Kumar Gala wrote:
>
> 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.
Any particular reasons that outweigh the reasons I gave, especially #2?
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Add 64-bit phys addr support to 32-bit pci.
From: Kumar Gala @ 2007-09-18 15:13 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46EFE849.7080508@ru.mvista.com>
On Sep 18, 2007, at 10:01 AM, Valentine Barshak wrote:
> 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:
I can guess as to why, but its useful for the commit messages to be
more descriptive so when some goes back a year from now they know why
someone added this patch.
- k
^ 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
* 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: 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: [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: [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: 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 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
* [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] [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
* 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] [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 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: 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 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: [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: 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: 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: [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
* 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
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