* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 14:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Alexandre.Bounine, Yang Xin-Xin-r48390
In-Reply-To: <17516.20191.490360.852876@cargo.ozlabs.ibm.com>
On May 18, 2006, at 5:39 AM, Paul Mackerras wrote:
> Zang Roy-r61911 writes:
>
>> I can migrate my code to embedded6xx technically. In fact,
>> I can move it into anywhere in the arch/powerpc/platforms.
>> While for mpc7448hpc2(taiga) board, it is not a embedded
>> application board. It is a high performance server! It seems
>> odd to put code there :). What's your opinion?
>
> What sort of machine(s) is this board used in? Or what machines will
> it be in?
Its a reference board from Freescale with a MPC7448 + TSI108.
Similar in concept to sandpoint.
- kumar
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 0/10] powerpc: add mpc7448hpc2 (Taiga) board support
From: Kumar Gala @ 2006-05-18 14:08 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626D618@zch01exm40.ap.freescale.net>
On May 17, 2006, at 5:13 AM, Zang Roy-r61911 wrote:
> Hi, Paul
>
> This series of patch adds mpc7448hpc2 (taiga) board support in
> arch/powerpc.
> Tsi108 chip of Tundra Semiconductor is also supported.
>
> Roy Zang
Can you post your .dts for us to take a look at. I know Mark Greer
is looking at support for the 105/6/7 family of bridges and the 10x
family should have consistent flat device trees.
- kumar
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Laurent Pinchart @ 2006-05-18 14:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Gosiuua
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
[...]
You should tell the BDI to initialize the SYPCR register, otherwise the
internal watchdog timer will keep resetting the CPU.
[INIT]
; *** Initialize the core internal registers
; Program the SYPCR - Disable the watchdog timer
WM32 0xf0010004 0xffff2081
You will need to initiliaze other internal registers as well (BCR, SIUMCR,
BRx, ORx, ...).
I'm not sure if this will be enough to solve your problem, but it should at
least be a start.
Laurent Pinchart
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Mark Chambers @ 2006-05-18 14:22 UTC (permalink / raw)
To: Gosiuua, linuxppc-embedded
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> Hello List..
>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
>
<snip>
> - Waiting for target stop failed
> - TARGET: Break at boot vector failed, freeze forced
> /*****/
>
>
> BDI can't bread the CPU and i don't know what can i do!
> Any one can help me?
> _______________________________________________
I have had the same issue. You need lines similar to the following
in your bdi config file to stop the watchdog timer. Then you will
need other lines to set various registers to match your hardware
bus widths, etc.
[INIT]
; init core register
WREG MSR 0x00001042 ;MSR : ME,RI, exceptions high
WM32 0x000101a8 0xf0000000 ;move internal space
WM32 0xf0010004 0xFFFFFFC1 ;SYPCR: disable watchdog
Mark C.
^ permalink raw reply
* MPC8xx USB SOF microcode patch
From: Josef Angermeier @ 2006-05-18 14:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using linux 2.6.15 and try to get the MPC875 USB controller
working. I just checked if the microcode patch in
arch/ppc/8xx_io/micropatch.c for CONFIG_USB_SOF_UCODE_PATCH set
corresponds with the newest microcode patch for mpc8xx, downloadable
from freescale: They differ slighly, is it an older (working) version or
where is it from ?
ciao
josef
^ permalink raw reply
* [RFD] Hugetlb: Allowing hugetlb regions to be closed
From: Adam Litke @ 2006-05-18 15:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libhugetlbfs-devel
Please correct me if I am wrong in any of the following...
On powerpc, once a region of the address space has been 'opened' for use
with hugetlb pages this region can never again contain normal pages for
the remaining life of the process -- even if all hugetlb mappings have
been unmapped from this region.
The above approach is nice and simple, but a bit restrictive too. Would
people be opposed to a patch which provides methods for closing low/high
hugetlb areas and logic in arch_get_unmapped_area() to perform the
closing? My thought would be to try closing only in the full_search:
case (so the fast path is left untouched.
As for why I want this... I have an application (libhugetlbfs), which
provides hugetlb pages to applications in an abstracted manner. There
are situations where the library creates a hugetlb area and needs to
later replace it with normal pages. The main case this will happen is
for a hugetlb-backed malloc area.
Thoughts?
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* MPC8xx: resolution of gettimeofday() ?
From: Steven Scholz @ 2006-05-18 15:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
what is the resolution of gettimeofday() for an MPC8xx?
IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
But is this decrementer used to update xtime?
Will gettimeofday() have a resolution of 200ns?
How about linux 2.4 where xtime is a "struct timeval" rather then "struct
timespec"?
This trivial test programm
struct timeval first, next;
double diff;
gettimeofday(&first, NULL);
do {
gettimeofday(&next, NULL);
} while (first.tv_usec == next.tv_usec &&
first.tv_sec == next.tv_sec);
diff = ((double) next.tv_sec - (double) first.tv_sec) * 1e6;
diff += (double) (next.tv_usec - first.tv_usec);
printf ("Resolution gettimeofday() = %g µs\n", diff);
says it's between 13 - 16 µs on a linux-2.4.20. Could that be? how does this
relate to the decrementer frequency?
Thanks a million!
--
Steven
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Michael Ellerman @ 2006-05-18 15:56 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <34FAC3E5-F717-4640-B094-312C8773852E@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Thu, 2006-05-18 at 08:22 -0400, Jimi Xenidis wrote:
> On May 17, 2006, at 7:36 PM, Michael Ellerman wrote:
>
> > On Wed, 2006-05-17 at 12:00 -0400, jimix@watson.ibm.com wrote:
> >> - pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
> >> + pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
> >> __FUNCTION__, current_entitled, current_weight);
> >>
> >> - pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
> >> + pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
> >> __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
> >
> > But pr_debug() calls printk, not udbg_printf() ?
>
> Now _thats_ funny!
> Then I'm so happy to have found and fixed this compiler warning :)
Haha, nice one Jimi :D
> >> -extern void udbg_printf(const char *fmt, ...);
> >> +extern void udbg_printf(const char *fmt, ...)
> >> + __attribute__ ((format (printf, 1, 2)));
>
> I believe this chunk is still goodness as it will catch format issues
> for developers.
I'm actually hoping to get rid of udbg_printf(), but if I can't we
should stick this in I guess. The real problem IMHO is that debug
printks rot because they're rarely compiled, not sure what to do about
that.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Jeff Garzik @ 2006-05-18 15:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexandre.Bounine, linuxppc-dev list, linux-kernel, linux-ide,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <1147935734.17679.93.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: 2006年5月17日 21:28
>> To: Zang Roy-r61911
>> Cc: Paul Mackerras; linuxppc-dev list; Alexandre.Bounine@tundra.com; Yang Xin-Xin-r48390
>> Subject: Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerpc pl atform
>
> Copying here the comments I already made so Jeff gets them...
>
>> @@ -1032,6 +1032,9 @@ static inline void mv_crqb_pack_cmd(u16
>> {
>> *cmdw = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
>> (last ? CRQB_CMD_LAST : 0);
>> +#ifdef CONFIG_PPC
>> + *cmdw = cpu_to_le16(*cmdw);
>> +#endif
>> }
>
> Why an ifdef here ? The cpu_to_le16 should probably be unconditional.
> And even if for some weird reason you wanted to ifdef it, why PPC ? and
> what about other BE architectures ?
>
>> /**
>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
> *mmio)
>> {
>> u32 tmp;
>> -
>> +#ifndef CONFIG_PPC
>> writel(0, mmio + MV_GPIO_PORT_CTL);
>> +#endif
>
> You'll have to do better here too... I don't wee why when compiled on
> PPC, this driver should "magically" not clear those bits... At the very
> least, you should test the machine type if you want to do something
> specific to your platform, but first, you'll have to convince Jeff why
> this change has to be done in the first place and if there is a better
> way to handle it.
Correct... it does seem some bugs were found, but #ifdef powerpc is
certainly out of the question. We want the driver to work without
ifdefs on all platforms.
Jeff
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:35 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
On May 18, 2006, at 5:21 AM, Zang Roy-r61911 wrote:
>
>> On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
>>>> I'm not repeating Kumar's comments about that CONFIG_7xxx
>>>> thing and that
>>>> 7xxx/ directory, it should all go.
>>>>
>>>
>>> Should I move my code to embedded6xx?
>>
>> Probably for now yes.
>
> I can migrate my code to embedded6xx technically. In fact,
> I can move it into anywhere in the arch/powerpc/platforms.
> While for mpc7448hpc2(taiga) board, it is not a embedded
> application board. It is a high performance server! It seems
> odd to put code there :). What's your opinion?
We should rename the files so they are 7448 specific. I dont see any
reason if FSL comes up with a 7449 that it wouldn't run on the same
board.
- k
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:36 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C07EC@zch01exm40.ap.freescale.net>
On May 18, 2006, at 3:05 AM, Zang Roy-r61911 wrote:
>>
>>> The tsi108 serial port is not a sub node of "soc". well, any way,
>>> I can try soc!
>>
>> What is it ? Where is it ? "soc" is a bit of a generic name for
>> something in the device-tree in fact... we might want to
>> define a way to
>> expose any bus via some kind of soc mecanism even if it's not a root
>> bus.
>>
>>
> Should I just use add_legacy_soc_port() instead of a new function
> add_legacy_tsi_port()?
I think seeing your dts will help here. We need to have a concept of
a "bridge" that may be similar to an "soc".
> --- arch/powerpc/kernel/legacy_serial.c.orig Thu May 18 15:35:19 2006
> +++ arch/powerpc/kernel/legacy_serial.c Thu May 18 15:50:38 2006
> @@ -302,6 +302,17 @@ void __init find_legacy_serial_ports(voi
> of_node_put(isa);
> }
>
> + /* First fill our array with tsi-bridge ports */
> + for (np = NULL; (np = of_find_compatible_node(np, "serial",
> "ns16550")) != NULL;) {
> + struct device_node *tsi = of_get_parent(np);
> + if (tsi && !strcmp(tsi->type, "tsi-bridge")) {
> + index = add_legacy_soc_port(np, np);
> + if (index >= 0 && np == stdout)
> + legacy_serial_console = index;
> + }
> + of_node_put(tsi);
> + }
> +
> #ifdef CONFIG_PCI
> /* Next, try to locate PCI ports */
> for (np = NULL; (np = of_find_all_nodes(np));)
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexandre.Bounine, linuxppc-dev list, Paul Mackerras,
Yang Xin-Xin-r48390
In-Reply-To: <1147936929.17679.106.camel@localhost.localdomain>
>> I will get rid of those tables. I can see that in file
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c (2.6.17-rc4), there is
>> a similar table. Should it be removed in future :)?
>
> Yes. And somebody beaten up for letting that stuff leak into
> arch/powerpc :)
>
>>> Yes, please do so, we will not accept a board that does the above :)
>>
>> I just do the same thing as 85xx :).
>
> Yes and I intend to LART Kumar seriously for that next time I meet
> him :)
Get in line ;) [lets be fair, I didn't actually do the 85xx/ads.c
port, but it was based on the 83xx which I did do]
The problem with the irq mapping is we dont have any code yet that
handles the "static" tables.
>>> We need a generic add_bridge that goes through PCI bridges and
>>> instanciate based on their type as provided by the device-tree. You
>>> should try to work in that direction...
>
> I suggest you also read my comments to Mark A. Greer as most of that
> stuff overlaps... I wish I had more times to work myself on that
> but I'm
> fairly overflowed at the moment...
>
> Ben
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 16:43 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C05CC@zch01exm40.ap.freescale.net>
On May 18, 2006, at 1:57 AM, Zang Roy-r61911 wrote:
>
>> On Wed, 2006-05-17 at 08:45 -0500, Kumar Gala wrote:
>>
>>>> +#ifdef TSI108_ETH
>>>> +hw_info hw_info_table[TSI108_ETH_MAX_PORTS + 1] = {
>>>> + {TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET,
>>>> + TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET,
>>>> + TSI108_PHY0_ADDR, IRQ_TSI108_GIGE0},
>>>> +
>>>> + {TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET + 0x400,
>>>> + TSI108_CSR_ADDR_PHYS + TSI108_ETH_OFFSET,
>>>> + TSI108_PHY1_ADDR, IRQ_TSI108_GIGE1},
>>>> +
>>>> + {TBL_END, TBL_END, TBL_END, TBL_END}
>>>> +};
>>>> +#endif
>>>
>>> This table looks problematic. Look at using something like a
>>> platform device.
>>
>> Bzzzt ... wrong answer :) That's a textbook example of stuff
>> that should
>> be provided via the device-tree.
>>
>>
>
> Well , should I register this data to a platform device or the
> Ethernet
> driver get the information from device-tree directly?
I'd say the later. Ben mentioned use of of_device which will allow
you to do that more directly. I used platform_device to maintain the
fact that we had existing drivers to support that were using it already.
- k
^ permalink raw reply
* Re: MPC8xx: resolution of gettimeofday() ?
From: Eugene Surovegin @ 2006-05-18 16:48 UTC (permalink / raw)
To: Steven Scholz; +Cc: linuxppc-embedded
In-Reply-To: <446C8E70.3040601@imc-berlin.de>
On Thu, May 18, 2006 at 05:10:40PM +0200, Steven Scholz wrote:
> Hi all,
>
> what is the resolution of gettimeofday() for an MPC8xx?
>
> IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
>
> This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
> resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
>
> But is this decrementer used to update xtime?
> Will gettimeofday() have a resolution of 200ns?
>
> How about linux 2.4 where xtime is a "struct timeval" rather then "struct
> timespec"?
>
> This trivial test programm
>
> struct timeval first, next;
> double diff;
>
> gettimeofday(&first, NULL);
> do {
> gettimeofday(&next, NULL);
> } while (first.tv_usec == next.tv_usec &&
> first.tv_sec == next.tv_sec);
>
> diff = ((double) next.tv_sec - (double) first.tv_sec) * 1e6;
> diff += (double) (next.tv_usec - first.tv_usec);
>
> printf ("Resolution gettimeofday() = %g ?s\n", diff);
>
> says it's between 13 - 16 ?s on a linux-2.4.20. Could that be? how does this
> relate to the decrementer frequency?
Usually on PPC we use timebase to interpolate time between Decrementer
interrupts. In this case gettimeofday resolution is determined by
timebase resolution which is quite high (megahertz range).
--
Eugene
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Jimi Xenidis @ 2006-05-18 16:52 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1147967806.8469.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]
On May 18, 2006, at 11:56 AM, Michael Ellerman wrote:
>
> I'm actually hoping to get rid of udbg_printf(), but if I can't we
> should stick this in I guess. The real problem IMHO is that debug
> printks rot because they're rarely compiled, not sure what to do about
> that.
Yeah, debug code always has that problem. But I must say, whenever I
work with the x86 guys and I see how long they are _blind_ when they
boot it blows my mind. Lets hope we don't go there.
-JX
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] dtc: add setting of physical boot cpu
From: Michael Neuling @ 2006-05-18 16:59 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <7AC7793A-74F3-4596-BF28-19BCA9E388CF@watson.ibm.com>
> How does this interact with "linux,boot-cpu"?
Currently, the -b option only changes the value in blob header.
linux,boot-cpu is still taken from whatever the input dts/dtb/fs
specifies.
> If -b is defined then the absence of "linux,boot-cpu" should no
> longer cause a warning.
For version 2 of the blob, this property should be in the header.
Perhaps we should warn if linux,boot-cpu is _missing_ when using <
version 2 and warn if it's _there_ for >= version 2.
I should add an error if someone specifies -b with version < 2.
> Perhaps if -b is missing the header value is set from "linux,boot-
> cpu" property?
I believe they're suppose to be mutually exclusive, so probably not a
good idea.
> Should we extend the "linux,boot-cpu" to actually contain a thread-id
> or are we deprecating this prop?
Yeah, the linux,boot-cpu is deprecated in version >= 2.
The dtc docs say that the boot_cpuid_phys field should match the "reg"
property in the CPU node. Their should be a "reg" property for each
thread, which I think solves your problem.
On a different note, dtc reading blobs on little endian machines is
broken. Just look at reserve mem entries in the output. I think the
main issue is with flat_read_chunk using memcpy.
Mikey
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Olof Johansson @ 2006-05-18 17:11 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933251.463191.267166640873.qpush@pokey>
On Thu, May 18, 2006 at 04:20:51PM +1000, Jeremy Kerr wrote:
> Add a function for generic parsing of dma-window properties (ie,
> ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
>
> This function will also be used by cell.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Olof Johansson <olof@lixom.net>
(I'm assuming you've booted it on POWER4 LPAR and JS20, I don't
have access to either to make sure it doesn't break there. Main worry
would be if it lacked ibm,#dma*-properties for some reason.)
>
> arch/powerpc/kernel/prom_parse.c | 23 +++++++++++++++++++++++
> include/asm-powerpc/prom.h | 6 ++++++
> 2 files changed, 29 insertions(+)
>
> Index: linux-2.6/arch/powerpc/kernel/prom_parse.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/prom_parse.c
> +++ linux-2.6/arch/powerpc/kernel/prom_parse.c
> @@ -548,3 +548,26 @@ int of_pci_address_to_resource(struct de
> return __of_address_to_resource(dev, addrp, size, flags, r);
> }
> EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
> +
> +void of_parse_dma_window(struct device_node *dn, unsigned char *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size)
> +{
> + u32 *dma_window, cells;
> + unsigned char *prop;
> +
> + dma_window = (u32 *)dma_window_prop;
> +
> + /* busno is always one cell */
> + *busno = *(dma_window++);
> +
> + prop = get_property(dn, "ibm,#dma-address-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_addr_cells(dn);
> + *phys = of_read_addr(dma_window, cells);
> +
> + dma_window += cells;
> +
> + prop = get_property(dn, "ibm,#dma-size-cells", NULL);
> + cells = prop ? *(u32 *)prop : prom_n_size_cells(dn);
> + *size = of_read_addr(dma_window, cells);
> +}
> +EXPORT_SYMBOL_GPL(of_parse_dma_window);
> Index: linux-2.6/include/asm-powerpc/prom.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/prom.h
> +++ linux-2.6/include/asm-powerpc/prom.h
> @@ -230,6 +230,12 @@ extern int of_address_to_resource(struct
> extern int of_pci_address_to_resource(struct device_node *dev, int bar,
> struct resource *r);
>
> +/* Parse the ibm,dma-window property of an OF node into the busno, phys and
> + * size parameters.
> + */
> +void of_parse_dma_window(struct device_node *dn, unsigned char *dma_window_prop,
> + unsigned long *busno, unsigned long *phys, unsigned long *size);
> +
> extern void kdump_move_device_tree(void);
>
> #endif /* __KERNEL__ */
>
> To: linuxppc-dev@ozlabs.org
> From: Jeremy Kerr <jk@ozlabs.org>
> Date: Thu, 18 May 2006 16:20:51 +1000
> Subject: [PATCH 2/2] powerpc: pseries: Use generic dma-window parsing function
> Message-Id: <1147933251.472945.297063284077.qpush@pokey>
>
> Change the pseries iommu init code to use the new of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
> arch/powerpc/platforms/pseries/iommu.c | 29 ++++++++++-------------------
> arch/powerpc/platforms/pseries/vio.c | 32 ++++++++++++++------------------
> 2 files changed, 24 insertions(+), 37 deletions(-)
>
> Index: linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/iommu.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/iommu.c
> @@ -299,30 +299,22 @@ static void iommu_table_setparms(struct
> * iommu_table_setparms_lpar
> *
> * Function: On pSeries LPAR systems, return TCE table info, given a pci bus.
> - *
> - * ToDo: properly interpret the ibm,dma-window property. The definition is:
> - * logical-bus-number (1 word)
> - * phys-address (#address-cells words)
> - * size (#cell-size words)
> - *
> - * Currently we hard code these sizes (more or less).
> */
> static void iommu_table_setparms_lpar(struct pci_controller *phb,
> struct device_node *dn,
> struct iommu_table *tbl,
> - unsigned int *dma_window)
> + unsigned char *dma_window)
> {
> + unsigned long offset, size;
> +
> tbl->it_busno = PCI_DN(dn)->bussubno;
> + of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset, &size);
>
> - /* TODO: Parse field size properties properly. */
> - tbl->it_size = (((unsigned long)dma_window[4] << 32) |
> - (unsigned long)dma_window[5]) >> PAGE_SHIFT;
> - tbl->it_offset = (((unsigned long)dma_window[2] << 32) |
> - (unsigned long)dma_window[3]) >> PAGE_SHIFT;
> tbl->it_base = 0;
> - tbl->it_index = dma_window[0];
> tbl->it_blocksize = 16;
> tbl->it_type = TCE_PCI;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> }
>
> static void iommu_bus_setup_pSeries(struct pci_bus *bus)
> @@ -414,7 +406,7 @@ static void iommu_bus_setup_pSeriesLP(st
> struct iommu_table *tbl;
> struct device_node *dn, *pdn;
> struct pci_dn *ppci;
> - unsigned int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
>
> DBG("iommu_bus_setup_pSeriesLP, bus %p, bus->self %p\n", bus, bus->self);
>
> @@ -422,7 +414,7 @@ static void iommu_bus_setup_pSeriesLP(st
>
> /* Find nearest ibm,dma-window, walking up the device tree */
> for (pdn = dn; pdn != NULL; pdn = pdn->parent) {
> - dma_window = (unsigned int *)get_property(pdn, "ibm,dma-window", NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window != NULL)
> break;
> }
> @@ -516,7 +508,7 @@ static void iommu_dev_setup_pSeriesLP(st
> {
> struct device_node *pdn, *dn;
> struct iommu_table *tbl;
> - int *dma_window = NULL;
> + unsigned char *dma_window = NULL;
> struct pci_dn *pci;
>
> DBG("iommu_dev_setup_pSeriesLP, dev %p (%s)\n", dev, pci_name(dev));
> @@ -531,8 +523,7 @@ static void iommu_dev_setup_pSeriesLP(st
>
> for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->iommu_table;
> pdn = pdn->parent) {
> - dma_window = (unsigned int *)
> - get_property(pdn, "ibm,dma-window", NULL);
> + dma_window = get_property(pdn, "ibm,dma-window", NULL);
> if (dma_window)
> break;
> }
> Index: linux-2.6/arch/powerpc/platforms/pseries/vio.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/pseries/vio.c
> +++ linux-2.6/arch/powerpc/platforms/pseries/vio.c
> @@ -108,32 +108,28 @@ __initcall(vio_bus_init_pseries);
> */
> static struct iommu_table *vio_build_iommu_table(struct vio_dev *dev)
> {
> - unsigned int *dma_window;
> - struct iommu_table *newTceTable;
> - unsigned long offset;
> - int dma_window_property_size;
> + unsigned char *dma_window;
> + struct iommu_table *tbl;
> + unsigned long offset, size;
>
> - dma_window = (unsigned int *) get_property(dev->dev.platform_data, "ibm,my-dma-window", &dma_window_property_size);
> - if(!dma_window) {
> + dma_window = get_property(dev->dev.platform_data,
> + "ibm,my-dma-window", NULL);
> + if (!dma_window)
> return NULL;
> - }
>
> - newTceTable = (struct iommu_table *) kmalloc(sizeof(struct iommu_table), GFP_KERNEL);
> + tbl = (struct iommu_table *)kmalloc(sizeof(*tbl), GFP_KERNEL);
>
> - /* There should be some code to extract the phys-encoded offset
> - using prom_n_addr_cells(). However, according to a comment
> - on earlier versions, it's always zero, so we don't bother */
> - offset = dma_window[1] >> PAGE_SHIFT;
> + of_parse_dma_window(dev->dev.platform_data, dma_window,
> + &tbl->it_index, &offset, &size);
>
> /* TCE table size - measured in tce entries */
> - newTceTable->it_size = dma_window[4] >> PAGE_SHIFT;
> + tbl->it_size = size >> PAGE_SHIFT;
> /* offset for VIO should always be 0 */
> - newTceTable->it_offset = offset;
> - newTceTable->it_busno = 0;
> - newTceTable->it_index = (unsigned long)dma_window[0];
> - newTceTable->it_type = TCE_VB;
> + tbl->it_offset = offset >> PAGE_SHIFT;
> + tbl->it_busno = 0;
> + tbl->it_type = TCE_VB;
>
> - return iommu_init_table(newTceTable);
> + return iommu_init_table(tbl);
> }
>
> /**
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add of_parse_dma_window()
From: Olof Johansson @ 2006-05-18 17:12 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933975.484840.681634501201.qpush@pokey>
On Thu, May 18, 2006 at 04:32:55PM +1000, Jeremy Kerr wrote:
> Add a function for generic parsing of dma-window properties (ie,
> ibm,dma-window and ibm,my-dma-window) of pci and virtual device nodes.
>
> This function will also be used by cell.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>
Acked-by: Olof Johansson <olof@lixom.net>
(replied to the wrong email last time)
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: pseries: Use generic dma-window parsing function
From: Olof Johansson @ 2006-05-18 17:13 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, paulus
In-Reply-To: <1147933975.516311.850847048300.qpush@pokey>
On Thu, May 18, 2006 at 04:32:55PM +1000, Jeremy Kerr wrote:
> Change the pseries iommu init code to use the new of_parse_dma_window()
> to parse the ibm,dma-window and ibm,my-dma-window properties of pci and
> virtual device nodes.
>
> Also, clean up vio_build_iommu_table() a little.
>
> Tested on pseries, with both vio and pci devices.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH 01/16] ehca: module infrastructure
From: Jörn Engel @ 2006-05-18 17:41 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4468BD39.3010008@de.ibm.com>
On Mon, 15 May 2006 19:41:13 +0200, Heiko J Schick wrote:
> + * This source code is distributed under a dual license of GPL v2.0 and
> OpenIB
Your mailer is still mangling long lines, it seems. If you need a
quick solution, I could offer you a gmail invite.
> +
> + EDEB_EX(7, "ret=%x", ret);
> +
> + return ret;
> +
> +create_aqp1:
> + ib_destroy_cq(sport->ibcq_aqp1);
> +
> + EDEB_EX(7, "ret=%x", ret);
> +
> + return ret;
> +}
Those two cases could be combined with a goto. Saves a tiny amount of
rodata.
> +#define EHCA_RESOURCE_ATTR(name)
> \
> +static ssize_t ehca_show_##name(struct device *dev,
> \
You have spaces instead of tabs in the lines the mailer mangled.
> +
> \
> + data = rblock->name; \
> + kfree(rblock); \
> + \
> + if ((strcmp(#name, "num_ports") == 0) && (ehca_nr_ports == 1)) \
> + return snprintf(buf, 256, "1\n"); \
> + else \
> + return snprintf(buf, 256, "%d\n", data); \
> + \
Is rblock->num_ports uninitialized when (ehca_nr_ports == 1)? Looks
rather odd.
> + shca = (struct ehca_shca *)ib_alloc_device(sizeof(*shca));
A quick grep showed that every single return value of
ib_alloc_device() has a cast.
Roland, can't you just change ib_alloc_device() to return void*?
> +static struct of_device_id ehca_device_table[] =
> +{
> + {
> + .name = "lhca",
> + .compatible = "IBM,lhca",
> + },
> + {},
> +};
Is the extra element needed?
> + if ((ret = ehca_create_slab_caches(&ehca_module))) {
> + EDEB_ERR(4, "Cannot create SLAB caches");
> + ret = -ENOMEM;
> + goto module_init1;
> + }
ret = try_something()
if (ret) {
...
}
> + ehca_module.timer.data = (unsigned long)(void*)&ehca_module;
Why the double cast?
Jörn
--
Fancy algorithms are slow when n is small, and n is usually small.
Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy.
-- Rob Pike
^ permalink raw reply
* remap_page_range vs. map_user_kiobuf
From: Stephen Williams @ 2006-05-18 17:43 UTC (permalink / raw)
To: linuxppc-embedded
My setup is Linux 2.4.33 w/ bigphysarea patch. My application is
using a virtual device driver to mmap a bigphysarea chunk, which
uses the remap_page_range function. This works well, and for my
devices that are aware of this and take advantage, the contiguous
physical memory is a real boon.
However, I also have a device driver that is not made specifically
aware of this heap. In its "read" method, it uses a map_user_kiobuf
to map user memory into the kernel. I do this as part of preparing
to DMA the read. This driver gets a -EFAULT back from map_user_kiobuf
when it is passed a user buffer that is mapped from the bigphysarea
heap.
It appears that get_user_pages (in mm/memory.c) does not like the
VM_RESERVED flag and returns -EFAULT if it tries to get reserved
pages in this manner. Am I reading this right?
Is there a way I can map the bigphysarea heap into user space such
that map_user_kiobuf works on these heaps, or am I stuck with
making all drivers aware of this bigphysarea heap?
(This is an embedded system, so this is possible to do, if painful.)
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Wolfgang Pfeiffer @ 2006-05-18 18:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147947192.15507.40.camel@johannes>
On Thu, May 18, 2006 at 12:13:12PM +0200, Johannes Berg wrote:
> On Thu, 2006-05-18 at 00:19 +0200, Wolfgang Pfeiffer wrote:
>
> > changed /etc/modules to explicitly load only i2sbus:
>
> Even that should not be necessary.
True. Just tested it (i.e. booted the machine) with this /etc/modules file:
----------------
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
apm_emu
ide-cd
#ide-disk
#ide-generic
sbp2
i2c-powermac
#snd-powermac
#snd-aoa:
#soundbus
#i2sbus
#snd-aoa
#snd-aoa-fabric-layout
#snd-aoa-codec-onyx
# End snd-aoa
cpufreq_performance
cpufreq_powersave
sr_mod
therm_adt746x
-----------------
And this is lsmod, after booting with he file above (op. slightly
edited for better readability):
# lsmod | grep snd
snd_aoa_codec_onyx 12736 2
snd_aoa_fabric_layout 7716 1
snd_aoa 8076 2 snd_aoa_codec_onyx,snd_aoa_fabric_layout
snd_pcm_oss 45824 0
snd_mixer_oss 19392 1 snd_pcm_oss
snd_pcm 89060 2 i2sbus,snd_pcm_oss
snd_timer 22468 1 snd_pcm
snd_page_alloc 8744 1 snd_pcm
soundbus 6436 2 snd_aoa_fabric_layout,i2sbus
snd 60148 10 snd_aoa_codec_onyx,
snd_aoa_fabric_layout,snd_aoa,i2sbus,
snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 8612 1 snd
BTW: Is there a way to let 'alsaconf' detect the soundcard on this
PB5,8 ?
So far that's impossible, as it seems. But this could also be
related to mistakes I made in my modules files, or wherever.
That's why I changed a few files today below /etc/modprobe.d/ and
/etc/modutils/ that still had a few instances calling snd-powermac:
I simply replaced 'snd-powermac' with i2sbus resp. (IIRC)
snd-aoa. To no avail so far: alsaconf still does not detect any
soundcard ..
Status quo:
$ grep -irs i2sbus /etc/
/etc/modprobe.d/alsa-base:install i2sbus /sbin/modprobe --ignore-install i2sbus $CMDLINE_OPTS && /lib/alsa/modprobe-post-install i2sbus
/etc/modprobe.d/sound:alias snd-card-0 i2sbus
/etc/modutils/alsa-base:post-install i2sbus /lib/alsa/modprobe-post-install i2sbus
Anything wrong up there?
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Jeff Garzik @ 2006-05-18 21:07 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <446CDE26.8090504@rtr.ca>
Mark Lord wrote:
> Jeff Garzik wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
> ..
>>>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>>>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
>>> *mmio)
>>>> {
>>>> u32 tmp;
>>>> -
>>>> +#ifndef CONFIG_PPC
>>>> writel(0, mmio + MV_GPIO_PORT_CTL);
>>>> +#endif
>>>
>>> You'll have to do better here too... I don't wee why when compiled on
>>> PPC, this driver should "magically" not clear those bits... At the very
>>> least, you should test the machine type if you want to do something
>>> specific to your platform, but first, you'll have to convince Jeff why
>>> this change has to be done in the first place and if there is a better
>>> way to handle it.
>>
>> Correct... it does seem some bugs were found, but #ifdef powerpc is
>> certainly out of the question. We want the driver to work without
>> ifdefs on all platforms.
>
> Yup. I have a powerpc platform here with PCI-X, and a PCI-X Marvell card
> to try in it. So I'll pick up these changes and try to integrate them a
> little more nicely in my internal updated driver, and then pass it on to
When will this happen? I'm getting worried that useful stuff is
disappearing into the Mark Lord ether, with no changes appearing on the
other side. Haven't seen patches from you in weeks.
I'm happy that you have an updated internal driver, but that helps no
one else.
Jeff
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-18 20:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <446C9219.4080300@pobox.com>
Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
>> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
..
>>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
>> *mmio)
>>> {
>>> u32 tmp;
>>> -
>>> +#ifndef CONFIG_PPC
>>> writel(0, mmio + MV_GPIO_PORT_CTL);
>>> +#endif
>>
>> You'll have to do better here too... I don't wee why when compiled on
>> PPC, this driver should "magically" not clear those bits... At the very
>> least, you should test the machine type if you want to do something
>> specific to your platform, but first, you'll have to convince Jeff why
>> this change has to be done in the first place and if there is a better
>> way to handle it.
>
> Correct... it does seem some bugs were found, but #ifdef powerpc is
> certainly out of the question. We want the driver to work without
> ifdefs on all platforms.
Yup. I have a powerpc platform here with PCI-X, and a PCI-X Marvell card
to try in it. So I'll pick up these changes and try to integrate them a
little more nicely in my internal updated driver, and then pass it on to Jeff.
Cheers
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-18 21:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <446CE217.2070703@pobox.com>
Jeff Garzik wrote:
>
> I'm happy that you have an updated internal driver, but that helps no
> one else.
Yikes! Mine own words, echoed back at me!
I'll organize some patches for you Friday.
Cheers
^ 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