* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 11:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071125111535.GB14557@curie-int.orbis-terrarum.net>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Sun, Nov 25, 2007 at 03:15:35AM -0800, Robin H. Johnson wrote:
> I started in there from that, and ended up in pci-sysfs.c...
> The ROM memcpy in drivers/pci/pci-sysfs.c:pci_read_rom() is never running.
...
> [ 306.396743] drivers/pci/pci-sysfs.c:577:pci_read_rom: size=0x0 rom=0xd000080082580000 off=0x0
> [ 306.396764] drivers/pci/pci-sysfs.c:579:pci_read_rom: off >= size!
...
> So next, why is it failing to decode the ROM size correctly?
> pci_get_rom_size(), here I come.
Instead of the expected value of 0x55, 0xAA at the start of the ROM
size decode in pci_get_rom_size(), the first two readb() calls both
return either 0xFF or 0x00 so the size check fails right away.
The two cards with x86 firmware return 0xFF for those two readb()
instructions, while the X1900 with OF returns 0x00 for the readb().
Could one of the more knowledgeable folk for PPC intricacies suggest why
those readb calls are returning the wrong data?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Jörg Sommer @ 2007-11-25 10:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1195850245.4149.170.camel@johannes.berg>
Hi,
Johannes Berg <johannes@sipsolutions.net> wrote:
>> % diff /proc/interrupts <(sleep 2; cat /proc/interrupts)
>> --- /proc/interrupts 2007-11-23 15:04:06.004846901 +0100
>> +++ /proc/self/fd/11 2007-11-23 15:04:05.952841422 +0100
>> @@ -1,15 +1,15 @@
>> CPU0
>> - 25: 18063968 MPIC 1 Level VIA-PMU
>> + 25: 18064241 MPIC 1 Level VIA-PMU
>> - 42: 1415066 MPIC 1 Level keywest i2c
>> - 47: 2075159 MPIC 1 Level GPIO1 ADB
>> - 48: 6686659 MPIC 1 Level radeon@pci:0000:00:10.0
>> + 42: 1415084 MPIC 1 Level keywest i2c
>> + 47: 2075193 MPIC 1 Level GPIO1 ADB
>> + 48: 6686778 MPIC 1 Level radeon@pci:0000:00:10.0
>>
>> I don't know where they come from, but that's the cause of the high IRQ
>> time.
>
> Are you sure about that?
No, I saw the high hardware interrupt value in top and looked at
/proc/interrupts and concluded that those are the evil source of the
high load.
> I'm fairly sure that I always had rather high numbers of interrupt
> here. And the system isn't sluggish or unresponsive as you'd expect if
> the IRQs actually did take 90% of the CPU time!
Okay, so what might be the source?
Doesn't really nobody else see this values? At least, Elimar
Riesebieter has the same problem. He reported on debian-powerpc.
Bye, Jörg.
--
Treffen sich zwei Funktionen.
Sagt die eine: „Verschwinde oder ich differenzier' dich!“
Erwidert die andere: „Ätsch, ich bin exponentiell!“
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 13:30 UTC (permalink / raw)
To: Robin H. Johnson, Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071125114919.GC14557@curie-int.orbis-terrarum.net>
On 11/25/07, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Sun, Nov 25, 2007 at 03:15:35AM -0800, Robin H. Johnson wrote:
> > I started in there from that, and ended up in pci-sysfs.c...
> > The ROM memcpy in drivers/pci/pci-sysfs.c:pci_read_rom() is never running.
> ...
> > [ 306.396743] drivers/pci/pci-sysfs.c:577:pci_read_rom: size=0x0 rom=0xd000080082580000 off=0x0
> > [ 306.396764] drivers/pci/pci-sysfs.c:579:pci_read_rom: off >= size!
> ...
> > So next, why is it failing to decode the ROM size correctly?
> > pci_get_rom_size(), here I come.
> Instead of the expected value of 0x55, 0xAA at the start of the ROM
> size decode in pci_get_rom_size(), the first two readb() calls both
> return either 0xFF or 0x00 so the size check fails right away.
>
> The two cards with x86 firmware return 0xFF for those two readb()
> instructions, while the X1900 with OF returns 0x00 for the readb().
>
> Could one of the more knowledgeable folk for PPC intricacies suggest why
> those readb calls are returning the wrong data?
I don't know PPC at this low of level but it may be a problem with non
word-aligned access to memory. I thought readb() was supposed to work
on all archs and alignment issues are handled inside readb(). Also,
the readw() may have an endian bug.
It might be prudent to add this check at the end of the rom size routine.
if (image == rom)
return size;
That would ensure a non-zero size is returned for non-standard ROMs.
If you add that at the end, can you read the ROM from user space?
BenH, has source code for an x86 emulator that will run on PPC. That
will let you run the ROMs. The original plan was for the kernel to
generate a uevent that would have triggered the x86 emulator to run.
Progress along that path was blocked by the X developers. The X server
contains code for enabling the PCI ROM and reading it from user space.
I wanted to move this code out of X and into the kernel.
Because the path was blocked things like the PCI ROM API were never
throughly tested. It works most of the time but the occasional problem
is still turning up. Once we identify the PPC problem we can fix it in
the kernel.
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer & Infra Guy
> E-Mail : robbat2@gentoo.org
> GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Timur Tabi @ 2007-11-25 15:38 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745BDC9.3080602@scram.de>
Jochen Friedrich wrote:
> fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and cpm2_immr,
> so the drivers can be compiled as modules.
Maybe this is a stupid question, but why did you choose EXPORT_SYMBOL_GPL and
not EXPORT_SYMBOL?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Jon Smirl @ 2007-11-25 15:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47499711.2020409@freescale.com>
On 11/25/07, Timur Tabi <timur@freescale.com> wrote:
> Jochen Friedrich wrote:
> > fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> > cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and cpm2_immr,
> > so the drivers can be compiled as modules.
>
> Maybe this is a stupid question, but why did you choose EXPORT_SYMBOL_GPL and
> not EXPORT_SYMBOL?
By marking all new exports EXPORT_SYMBOL_GPL it stops new closed
source device drivers from being built. We have to live the the
existing ones, but we certainly don't want to encourage any more to be
built.
Over on lkml there is a thread about moving all symbols of this type
into private name spaces and removing the exports in the final kernel
binary.
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Vitaly Bordug @ 2007-11-25 16:18 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <47499711.2020409@freescale.com>
On Sun, 25 Nov 2007 09:38:57 -0600
Timur Tabi wrote:
> Jochen Friedrich wrote:
> > fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> > cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and
> > cpm2_immr, so the drivers can be compiled as modules.
As I told replying to prev mail, this needs to be addressed in respective driver(s), since
there is a way to retrieve such pointers without making them global.
This patch will exist in maillist as a workaround, but meanwhile I'll take a look at this problem.
>
> Maybe this is a stupid question, but why did you choose
> EXPORT_SYMBOL_GPL and not EXPORT_SYMBOL?
>
To prevent using those pointers from within non-GPL modules. kind of policy now...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: PCI to Parallel for PowerPC
From: Clemens Koller @ 2007-11-25 17:00 UTC (permalink / raw)
To: Bai Shuwei; +Cc: linuxppc-dev, shekr06, puyq, zhang_wei, linuxppc-embedded
In-Reply-To: <f3566d60711242106x4d56efe1w325e70c522ddd62c@mail.gmail.com>
Bai Shuwei schrieb:
Please don't cross-post.
> hi, all
> I bought a SMC1500 stepper motor card. And it can connect with host
> through parallel port. My target board is PowerPC 440, which hasn't
> parrallel port. So I bought a PCI to Parallel line for SMC1500. But when
> I run the stepper motor, I find it's not stable. I doubt there are
> somthing wrong with my PCI to Parallel line. So I beg somebody can tell
> me where I can bought the appropriate conversion line from PCI to
> parallel, and does somebody give me some idea about how to control my
> stepper motor through PowerPC 440? thx all
Put that PCI Card to your host where your stepper was working
properly to see if it's a hardware issue with that card.
Then it depends on how you control your stepper motor. If you use
some bit-banging (which I wouldn't recommend) to drive each winding
and want to have smooth movement, you need a very precise timing
when it comes to some "more than low-speed" stepper motors,
otherwise your motors will start to coggle.
To be precise: you will first have to figure out what leads to
the effect of "it's not stable". Do you have an Oscilloscope?
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-25 17:45 UTC (permalink / raw)
To: Jörg Sommer; +Cc: linuxppc-dev
In-Reply-To: <slrnfkijob.j2k.joerg@alea.gnuu.de>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
Hi,
[can you CC me? I can sometimes only skim the lists]
> No, I saw the high hardware interrupt value in top and looked at
> /proc/interrupts and concluded that those are the evil source of the
> high load.
>
> > I'm fairly sure that I always had rather high numbers of interrupt
> > here. And the system isn't sluggish or unresponsive as you'd expect if
> > the IRQs actually did take 90% of the CPU time!
>
> Okay, so what might be the source?
I'd guess NOHZ is the problem because we're letting the CPU not do
anything rather than doing idle ticks or something.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-25 18:15 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <4749425C.5060207@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]
-----Original Message-----
From: David H. Lynch Jr. [mailto:dhlii@dlasys.net]
Sent: Sun 11/25/2007 1:37 AM
To: Stephen Neuendorffer
Cc: Grant Likely; linuxppc-embedded
Subject: Re: Xilinx devicetrees
Stephen Neuendorffer wrote:
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Grant Likely
> Sent: Sat 11/24/2007 9:12 AM
> To: David H. Lynch Jr.
> Cc: linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>
> Regardless, I think I saw a post of yours on the microblaze list
> about exporting a devicetree list with the firmware.
> that is probably a better solution that what exists now.
I agree.. that's why I'm working on it. :) But just to clarify: I don't work directly on Xilinx products, but more in advanced development.
> I am curious - with the firmware is not the same as in the firmware.
> But since you brought up deciphering firmware - to me and to Pico,
> and I gather to alot of others, providing indentity information within
> the firmware is a really really important issue - one which xilinx seems
> to be unable to make up its mind about.
> There are frequent posts addressing issues like this driver only
> works with this version of some IP - but there is no way to query the IP
> to enough detail to determine whether the driver will work. It is one
> thing to make version registers an option. It is entirely different to
> just omit them entirely or change the IP without changing the version.
> Our clients beat us up for things like that. DevieTrees do nto solve
> that problem.
I know these issues are high priorities within the EDK development group. One advantage of device trees is that this information can be included without using any additional FPGA resources.
> Anyway, my .02 would be to put the device tree into the firmware. In
> a perfect world - litterally in the firmware so that when the firmware
> loads the device tree data is already in the FPGA somewhere that it can
> be easily ready - oh and do that without consuming many FPGA resources.
> But in a more likely realworld scenario - append the information to
> the .bit file in some fashion so that if can easily be found and passed on.
I've experimented with putting this information into BRAM. Typically compressed device trees should easily fit within a single BRAM. However, I think in most scenarios this is actually overkill. Storing the device tree with the bitstream is probably good enough, and likely cheaper since the bitstream is likely in bulk storage. This might be configuration flash (which is accessible after booting), SystemAce (in which case, the systemace image could load the device tree into a known location in memory). In other systems the bitstream and the device tree might be combined into an executable file along with processor code for configuring the FPGA. This might be used with an external processor or a partially reconfigured system.
> Binding it to a kernel, is a non-starter for us.
I agree that this is not the best way of leveraging the power of device trees. The point is that by using a device tree, you haven't lost anything you can do currently. In the future we might have one kernel which supports all versions of all our IP, along with all flavors of microblaze and powerpc... You would only ever need to recompile this kernel as a final optimization, if at all.
> I am tasked with getting one binary for each
> OS to work with nearly every device(hardware) we make including
> addressing options that change with firmware AND the whim of the user.
> But life might not be to unpleasant - it might even actually be
> better, if our kernel loader just extracted the devicetree from the end
> of the currently executing firmware.
Device trees are a data driven way of doing exactly this.
Steve
[-- Attachment #2: Type: text/html, Size: 4931 bytes --]
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 19:41 UTC (permalink / raw)
To: Jon Smirl, linuxppc-dev
In-Reply-To: <9e4733910711250530r454c01ecoe8867a7f492b8704@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On Sun, Nov 25, 2007 at 08:30:58AM -0500, Jon Smirl wrote:
> I don't know PPC at this low of level but it may be a problem with non
> word-aligned access to memory. I thought readb() was supposed to work
> on all archs and alignment issues are handled inside readb(). Also,
> the readw() may have an endian bug.
I was looking around for a description of the ROM layout, and instead I
found this: http://developer.apple.com/technotes/tn/tn2000.html
It was relevant because it explicitly mentioned enabling the
PCI_COMMAND_MEMORY bit in the PCI_COMMAND register, which is NOT present
in any path of the sizing code.
By doing:
# dev="/sys/devices/pci0001:00/0001:00:03.0/0001:06:00.0/"
# echo 1 >${dev}/enable
# echo 1 >${dev}/rom
# cat ${dev}/rom >rom
The ROM is successfully returned for two of my 3 cards.
Namely, both of the ones containing x86 BIOS (sata_sil24, ATI X700).
The X1900 does still not return any ROM.
So the pci-sysfs.c/rom.c code path needs to change to enable the device
somewhere if it was not enabled before (and presumably disable
afterwards for suspend/resume?).
I broke my testing kernel temporarily, so I need a bit more testing to
see why the X1900 did not return a ROM. More on that in a couple of
hours.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* List of Device Bandwidths
From: narendra sisodiya @ 2007-11-25 20:15 UTC (permalink / raw)
To: computertechnology, osscampdelhi, linuxppc-embedded, fosska
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Here is a link to one of the most useful page page which tell compare almost
all device and standards in context to their bandwidth and data rate.
Hope it will be useful for somebody.
http://en.wikipedia.org/wiki/List_of_device_bandwidths
--
Narendra Sisodiya
MTech (Computer Technology), IIT Delhi
+91-9999232792
http://www.techfandu.org/index.html
[-- Attachment #2: Type: text/html, Size: 505 bytes --]
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 20:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711250530r454c01ecoe8867a7f492b8704@mail.gmail.com>
On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
>
> > The two cards with x86 firmware return 0xFF for those two readb()
> > instructions, while the X1900 with OF returns 0x00 for the readb().
> >
> > Could one of the more knowledgeable folk for PPC intricacies suggest
> why
> > those readb calls are returning the wrong data?
>
> I don't know PPC at this low of level but it may be a problem with non
> word-aligned access to memory. I thought readb() was supposed to work
> on all archs and alignment issues are handled inside readb(). Also,
> the readw() may have an endian bug.
Ugh ? Read be reads -bytes- ! Can you tell me how the hell can a byte
access be non-aligned ?
> BenH, has source code for an x86 emulator that will run on PPC. That
> will let you run the ROMs. The original plan was for the kernel to
> generate a uevent that would have triggered the x86 emulator to run.
>
> Progress along that path was blocked by the X developers. The X server
> contains code for enabling the PCI ROM and reading it from user space.
> I wanted to move this code out of X and into the kernel.
>
> Because the path was blocked things like the PCI ROM API were never
> throughly tested. It works most of the time but the occasional problem
> is still turning up. Once we identify the PPC problem we can fix it in
> the kernel.
Nobody blocked anything, you are free to develop an emulator triggered
by a uevent, nobody prevented you from doing so.
Now, regarding that user problem, this it totally unrelated as it's a
"mac" card.
It's possible that it's one of these radeons that disable ROM access via
a register in which case a quirk is needed to re-enable it.
Ben.
^ permalink raw reply
* Re: [PATCH resend 1/4] powerpc: fix typo #ifdef -> #ifndef
From: Vitaly Bordug @ 2007-11-25 20:34 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745B41B.3040904@scram.de>
On Thu, 22 Nov 2007 17:53:47 +0100
Jochen Friedrich wrote:
> fpi->cp_command should be overwritten only if
> CONFIG_PPC_CPM_NEW_BINDING is NOT set. Otherwise it is already set
> from the device tree.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied to linux-2.6-8xx.git, for-paulus branch.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH resend 2/4] powerpc: kill non-existent symbols from ksyms and commproc.h
From: Vitaly Bordug @ 2007-11-25 20:37 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745B422.5080103@scram.de>
On Thu, 22 Nov 2007 17:53:54 +0100
Jochen Friedrich wrote:
> Remove exports of __res and cpm_install_handler/cpm_free_handler.
> Remove cpm_install_handler/cpm_free_handler from the commproc.h as
> well. Both were used for ARCH=ppc and aren't defined for
> ARCH=powerpc.
>
> CC arch/powerpc/kernel/ppc_ksyms.o
> arch/powerpc/kernel/ppc_ksyms.c:180: error: '__res' undeclared here
> (not in a function) arch/powerpc/kernel/ppc_ksyms.c:180: warning:
> type defaults to 'int' in declaration of '__res' make[1]: ***
> [arch/powerpc/kernel/ppc_ksyms.o] Error 1 make: ***
> [arch/powerpc/kernel] Error 2
>
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x198): undefined reference
> to `cpm_free_handler'
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x1a0): undefined reference
> to `cpm_install_handler' make: *** [.tmp_vmlinux1] Error 1
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied to linux-2.6-8xx.git, for-paulus branch.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH resend 4/4] powerpc: Add support for PORTA and PORTB odr registers
From: Vitaly Bordug @ 2007-11-25 20:37 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745B435.3080002@scram.de>
On Thu, 22 Nov 2007 17:54:13 +0100
Jochen Friedrich wrote:
> PORTA and PORTB have odr registers, as well. However, the PORTB odr
> register is only 16bit.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Acked-by: Scott Wood <scottwood@freescale.com>
Applied to linux-2.6-8xx.git, for-paulus branch
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 20:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196022000.7195.70.camel@pasglop>
On 11/25/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
> >
> > > The two cards with x86 firmware return 0xFF for those two readb()
> > > instructions, while the X1900 with OF returns 0x00 for the readb().
> > >
> > > Could one of the more knowledgeable folk for PPC intricacies suggest
> > why
> > > those readb calls are returning the wrong data?
> >
> > I don't know PPC at this low of level but it may be a problem with non
> > word-aligned access to memory. I thought readb() was supposed to work
> > on all archs and alignment issues are handled inside readb(). Also,
> > the readw() may have an endian bug.
>
> Ugh ? Read be reads -bytes- ! Can you tell me how the hell can a byte
> access be non-aligned ?
readb() doesn't work on the dev board I'm currently working with
because the flash is wired in such a way that it only works for 16b
reads. Maybe calling that an alignment issue is the wrong term.
> > BenH, has source code for an x86 emulator that will run on PPC. That
> > will let you run the ROMs. The original plan was for the kernel to
> > generate a uevent that would have triggered the x86 emulator to run.
> >
> > Progress along that path was blocked by the X developers. The X server
> > contains code for enabling the PCI ROM and reading it from user space.
> > I wanted to move this code out of X and into the kernel.
> >
> > Because the path was blocked things like the PCI ROM API were never
> > throughly tested. It works most of the time but the occasional problem
> > is still turning up. Once we identify the PPC problem we can fix it in
> > the kernel.
>
> Nobody blocked anything, you are free to develop an emulator triggered
> by a uevent, nobody prevented you from doing so.
They blocked the X server changes, which rendered the kernel support
pointless. But that's all old news.
> Now, regarding that user problem, this it totally unrelated as it's a
> "mac" card.
>
> It's possible that it's one of these radeons that disable ROM access via
> a register in which case a quirk is needed to re-enable it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 20:54 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711251251v6c24b5dek2fe09f2d2964e769@mail.gmail.com>
On Sun, 2007-11-25 at 15:51 -0500, Jon Smirl wrote:
>
> They blocked the X server changes, which rendered the kernel support
> pointless. But that's all old news.
No, you are wrong, nothing was ever "blocked".
Ben.
^ permalink raw reply
* Re: PCI to Parallel for PowerPC
From: Benjamin Herrenschmidt @ 2007-11-25 21:09 UTC (permalink / raw)
To: Clemens Koller; +Cc: puyq, linuxppc-embedded, linuxppc-dev, zhang_wei, shekr06
In-Reply-To: <4749AA1B.3050805@anagramm.de>
On Sun, 2007-11-25 at 18:00 +0100, Clemens Koller wrote:
> Put that PCI Card to your host where your stepper was working
> properly to see if it's a hardware issue with that card.
>
> Then it depends on how you control your stepper motor. If you use
> some bit-banging (which I wouldn't recommend) to drive each winding
> and want to have smooth movement, you need a very precise timing
> when it comes to some "more than low-speed" stepper motors,
> otherwise your motors will start to coggle.
> To be precise: you will first have to figure out what leads to
> the effect of "it's not stable". Do you have an Oscilloscope?
Also, we might need to see the code you are using to control the
parallel port, it may be ignoring issues such as PCI write posting or
lacking appropriate memory barriers...
Ben.
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Dan Malek @ 2007-11-25 21:02 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071125191833.1e76f335@kernel.crashing.org>
On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
> To prevent using those pointers from within non-GPL modules. kind
> of policy now...
As the original copyright holder of nearly all of this of
this code, I do not wish this be done.
Thanks.
-- Dan
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 21:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196022000.7195.70.camel@pasglop>
On 11/25/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Now, regarding that user problem, this it totally unrelated as it's a
> "mac" card.
>
> It's possible that it's one of these radeons that disable ROM access via
> a register in which case a quirk is needed to re-enable it.
He says in the first email that when he puts the boards into an x86
box he can read them. The quick turns the ROM back on if the firmware
is turning them off.
In the PPC box the ROMs aren't being run so they would still be in
power on state. I'd expect them to be readable in power-on state.
You can dump the PCI config block in /sys with hexdump and see if the
PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
by the BIOS at boot on the x86 and not on the ppc.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 21:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711251324y5116d90pab54a1a033d024e3@mail.gmail.com>
> You can dump the PCI config block in /sys with hexdump and see if the
> PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
> the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
> by the BIOS at boot on the x86 and not on the ppc.
The kernel doesn't until somebody calls pci_enable_device(). So yes,
that's likely to be your problem.
Ben.
^ permalink raw reply
* [PATCH 13/27] powerpc: arch_has_single_step
From: Roland McGrath @ 2007-11-25 22:03 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071125215507.4B89226F8C5@magilla.localdomain>
This defines the new standard arch_has_single_step macro. It makes the
existing set_single_step and clear_single_step entry points global, and
renames them to the new standard names user_enable_single_step and
user_disable_single_step, respectively.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 12 ++++++------
include/asm-powerpc/ptrace.h | 7 +++++++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 3e17d15..b970d79 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -256,7 +256,7 @@ static int set_evrregs(struct task_struct *task, unsigned long *data)
#endif /* CONFIG_SPE */
-static void set_single_step(struct task_struct *task)
+void user_enable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
@@ -271,7 +271,7 @@ static void set_single_step(struct task_struct *task)
set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-static void clear_single_step(struct task_struct *task)
+void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
@@ -313,7 +313,7 @@ static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
void ptrace_disable(struct task_struct *child)
{
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
}
/*
@@ -456,7 +456,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
child->exit_code = data;
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
wake_up_process(child);
ret = 0;
break;
@@ -473,7 +473,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
child->exit_code = SIGKILL;
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
wake_up_process(child);
break;
}
@@ -483,7 +483,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
if (!valid_signal(data))
break;
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- set_single_step(child);
+ user_enable_single_step(child);
child->exit_code = data;
/* give it a chance to run. */
wake_up_process(child);
diff --git a/include/asm-powerpc/ptrace.h b/include/asm-powerpc/ptrace.h
index 13fccc5..3063363 100644
--- a/include/asm-powerpc/ptrace.h
+++ b/include/asm-powerpc/ptrace.h
@@ -119,6 +119,13 @@ do { \
} while (0)
#endif /* __powerpc64__ */
+/*
+ * These are defined as per linux/ptrace.h, which see.
+ */
+#define arch_has_single_step() (1)
+extern void user_enable_single_step(struct task_struct *);
+extern void user_disable_single_step(struct task_struct *);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply related
* [PATCH 14/27] powerpc: ptrace generic resume
From: Roland McGrath @ 2007-11-25 22:04 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071125215507.4B89226F8C5@magilla.localdomain>
This removes the handling for PTRACE_CONT et al from the powerpc
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 46 ------------------------------------------
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index b970d79..8b056d2 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -445,52 +445,6 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
}
- case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
- case PTRACE_CONT: { /* restart after signal. */
- ret = -EIO;
- if (!valid_signal(data))
- break;
- if (request == PTRACE_SYSCALL)
- set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- else
- clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- child->exit_code = data;
- /* make sure the single step bit is not set. */
- user_disable_single_step(child);
- wake_up_process(child);
- ret = 0;
- break;
- }
-
-/*
- * make the child exit. Best I can do is send it a sigkill.
- * perhaps it should be put in the status that it wants to
- * exit.
- */
- case PTRACE_KILL: {
- ret = 0;
- if (child->exit_state == EXIT_ZOMBIE) /* already dead */
- break;
- child->exit_code = SIGKILL;
- /* make sure the single step bit is not set. */
- user_disable_single_step(child);
- wake_up_process(child);
- break;
- }
-
- case PTRACE_SINGLESTEP: { /* set the trap flag. */
- ret = -EIO;
- if (!valid_signal(data))
- break;
- clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- user_enable_single_step(child);
- child->exit_code = data;
- /* give it a chance to run. */
- wake_up_process(child);
- ret = 0;
- break;
- }
-
case PTRACE_GET_DEBUGREG: {
ret = -EINVAL;
/* We only support one DABR and no IABRS at the moment */
^ permalink raw reply related
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-25 22:21 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <47493D4F.4070605@dlasys.net>
On 11/25/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > One more point; it is also possible to bind the device tree up with
> > the kernel so you've got a single image just like old times. :-)
> >
> But that is not actually the same is dynamically detecting
> configuration.
nope, not at all the same as dynamic detection; just backwards
compatibility with the way we do it now for arch/ppc.
> On an ordinary PC where the critical core configuration is somewhat
> fixed and the rest can be determined by firmware (code), this makes a
> great deal of sense.
> In a system where the hardware itself is actually firmware and there
> is little or no startup software to query the device and build a device
> tree dynamically for you, it is of more questionable value.
> Maybe if there is some mechanism existed to have the devicetree
> stored into the FPGA firmware where there is a natural link between the
> implimented hardware and its description. But I am not gathering things
> going in that direction and storing the device tree in the FPGA consumes
> valuable FPGA resources.
No, it doesn't make sense to store is in the FPGA fabric; but if the
design already contains BRAM then it could be placed there and
reclaimed for other purposes after booting. Or anywhere in RAM for
that matter. I don't know how feasible is to load a device tree into
SDRAM at FPGA config time.
If the FPGA bitstream is stored in processor accessable flash, then
the best place would be tacked onto the end of the bitstream file. I
believe Xilinx is planning for EDK to be responsible to generate the
.dts file for the design.
>
> >
> > The board description has to live *somewhere*.
> I have done alot of code for many purposes where the code went to a
> great deal of effort to figure out its own environment dynamically.
> Some (relatively minimal) assumptions have to be made. And some
> balance has to be struck between code complexity and dynamic flexibility.
> though sometimes dynamic detection can be simpler.
> Part of what bothers me about devicetrees, is that the entire design
> seems to presume either standard hardware with minimal permutations, or
> fairly complex firmware - like boot roms to dynamically build atleast
> parts of the device tree.
Ah; I think I see the disconnect we're having. Device trees are not
about, *and never have been about*, device detection. The device tree
is simply the communication medium used to describe the hardware. It
doesn't matter if you choose to use a 100% dynamically generated
device tree from intelligent firmware or a 100% static device tree
blob. All that matters is that the kernel is able to trust the
information handed to it by firmware.
Device detection is not a problem that the device tree is designed to solve.
It is designed to solve the problem of telling the kernel what the
platform looks like (which occurs after the detection stage).
> > That being said, using the device tree does not preclude using
> > platform code to setup devices *where it makes sense to do so*. Many
> > things are one-off board specific things that are not well described
> > with the device tree. For example, we've been debating how to handle
> > on board sound which use common codec chips, but have custom wireup.
> > The codec chip can use a common driver, but the wireup is handled with
> > an ALSA 'fabric' driver that is pretty much a one-off for the board.
> > It probably makes more sense for the fabric driver to be instantiated
> > by the platform code rather than trying to do a full device tree
> > representation.
> >
> So I can hard code some relatively simple stripped devicetree
> that may do little more than specify the CPU, major elements of the
> memory map (maybe), and say the PIC, and then let the BSP, detect things
> like the UART(s), NIC, ...
If devices *are* detectable, then they don't need to be in the device
tree. That's why we don't describe PCI devices in the FDT for
embedded boards. (We *could* but we *don't*) :-)
> > In arch/powerpc
> > we're *still* data driven; it's just that the data is no longer
> > compiled into a static structure. Plus, in the transition we've moved
> > from needed per-device platform data structures to a more expressive
> > format. Also, per-board platform support code has become much simpler
> > (compare ml300.c in arch/ppc with platforms/40x/virtex.c)
> >
>
> I have not pulled your tree in a while - are devicetree's in your
> current git tree ?
arch/powerpc support for Virtex is now in Linus' mainline tree which
will become 2.6.24
>
> Thanks for the remarks.
>
> Again, I am just trying to figure out how to keep my Pico code in
> sync and hopefully make my life better rather than worse at the same time.
> Unfortunately, I am coming to the conclusion that DeviceTrees are
> probably not going to make it that much better,
> but they are probably not going to make it that much worse either.
No, unfortunately they don't deal with the problem you're facing
(which I'm facing also). But it will be solved if we figure out a
sane way to bind the device tree up with the FPGA bitstream without
consuming FPGA resources.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Arnd Bergmann @ 2007-11-25 22:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202312130.24220@blarg.am.freescale.net>
On Wednesday 21 November 2007, Kumar Gala wrote:
> + =A0 =A0* Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> + =A0 =A0SATA nodes are defined to describe on-chip Serial ATA controller=
s.
> + =A0 =A0Each SATA port should have its own node.
> +
> + =A0 =A0Required properties:
> + =A0 =A0- compatible =A0 =A0 =A0 =A0: compatible list, contains 2 entrie=
s, first is
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "f=
sl,sata-CHIP", where CHIP is the processor
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (m=
pc8315, mpc8379, etc.) and the second is
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "f=
sl,sata-pq2pro"
> + =A0 =A0- interrupts =A0 =A0 =A0 =A0: <interrupt mapping for SATA IRQ>
> + =A0 =A0- interrupt-parent =A0: optional, if needed for interrupt mapping
> + =A0 =A0- reg =A0 =A0 =A0 =A0 =A0 =A0 =A0 : <registers mapping>
> +
Should this maybe also mandate a compatible property that is defined
in a way to match the generic (p)ata_of_platform driver?
Arnd <><
^ 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