* SPI driver for spi_mpc83xx
From: fabio777 @ 2007-11-25 8:23 UTC (permalink / raw)
To: linuxppc-embedded
Has anyone been using this driver ?
For legacy reasons I need to keep the ppc=arch however I haven't found
out how to get this driver probed at start-up even basing my init on
Lublock.
Any help would be very appreciated - Thanks
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-25 9:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40711240912r192aba72o2cbdb798370e7b7c@mail.gmail.com>
First;
I am not deliberately trying to be obstructive. It is apparent
that the ppc kernel is moving towards devicetrees and initially I
thought that sounded like a good idea.
Now I am trying to reconcile the positive benefits with my
perception of the negative side effects.
> Yes, you are correct in all of the above.
>
> 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.
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.
>
> 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.
>
> 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, ...
> 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 ?
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.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-25 9:37 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20071125052459.DA8B1EE805F@mail70-blu.bigfish.com>
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
>
> On 11/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>
>>> I am having some difficulty grasping the significant advantages to
>>> this.
>>> If the firmware for a given target is not fairly static - and I load
>>> different firmware depending on what I am doing all the time, then I
>>> know have to manage both a bit file for the firmware, and a devicetree
>>> file describing it to the kernel.
>>>
>
> The device tree file is meta-information about your bitfile. Think of it as 'part of the firmware'. In the (hopefully short) future, it won't even have to be managed, it will just be one of the things that is generated by the EDK flow.
>
Part of the bad news is that I have been kept so busy on the
software side of things, I have had very very little time to play with
xilinx tools and firmware. But overall at Pico we have a love hate
relationship with them. Our products are primarily wrapped arround
FPGA's particularly Xilinx.
We love what we can do. But there are days that I here loud muttering
about completely rewriting all the xilinx software tools - there is a
surprisingly large amount that many of the Pico firmware people do not
use already.
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.
> You won't have to write a bunch of code that deciphers which fpga firmware you are running on.. That information will be found with the firmware and can be dealt with in a generic way. If you already HAVE that code, you can keep using it, but maintaining that kind of code is probably not where you want to spend your time.
>
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.
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.
Binding it to a kernel, is a non-starter for us. That means a
permuation of multiple different OS kernels for each bit file we might
have. That is huge number. 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.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Andreas Schwab @ 2007-11-25 9:42 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20071125015707.GO3174@curie-int.orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> /sys/device/pci*, and dumped it as follows:
> # echo 1>$ROM
Did you run it exactly like this? Because this will echo exactly one
newline to $ROM. If you want to echo "1\n" you need to put a space
between "1" and ">".
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* SPI, I2C
From: David H. Lynch Jr. @ 2007-11-25 9:44 UTC (permalink / raw)
To: linuxppc-embedded
I have been asked to do SPI and I2C drivers for Pico cards.
I am trying to grasp what the practical use of either could be in an
environment where neither SPI nor I2C are going to be able to
communicate outside the FPGA.
I am guessing that SPI and I2C implementations already exist for
Xilinx FPGA's - any chance that drivers might already exist ?
I would prefer not to charge a client to reinvent something that
exists, or that can not serve a useful purpose.
I am not trying to imply that SPI or I2C are not useful, just that
they are communications channels, and unless they have outside I2C or
SPI hardware to talk to what purpose might they serve ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 9:58 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jey7cmfyp9.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
On Sun, Nov 25, 2007 at 10:42:42AM +0100, Andreas Schwab wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> writes:
>
> > I put the card into an amd64 box, found the relevant 'rom' node ($ROM) under
> > /sys/device/pci*, and dumped it as follows:
> > # echo 1>$ROM
> Did you run it exactly like this? Because this will echo exactly one
> newline to $ROM. If you want to echo "1\n" you need to put a space
> between "1" and ">".
I did run the correct version, "echo 1 >$ROM", so that a "1\n" was
actually sent, and not a newline without a digit.
--
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: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-25 11:15 UTC (permalink / raw)
To: Jon Smirl, linuxppc-dev
In-Reply-To: <9e4733910711241813r3412d459l95fb3b84cbee1d8a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
On Sat, Nov 24, 2007 at 09:13:40PM -0500, Jon Smirl wrote:
> The ROM is mapped in drivers/pci/rom.c
>
> You could add some printks and see if there is an error and if the ROM
> is accessible
>
> rom = ioremap(start, *size);
> if (!rom) {
> /* restore enable if ioremap fails */
> if (!(res->flags & (IORESOURCE_ROM_ENABLE |
> IORESOURCE_ROM_SHADOW |
> IORESOURCE_ROM_COPY)))
> pci_disable_rom(pdev);
> return NULL;
> }
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.
Relevant section of my debug output:
[ 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!
[ 306.396768] drivers/pci/pci-sysfs.c:588pci_read_rom: unmapping
Relevant snippet of my debug patching:
- if (off >= size)
+ printk(KERN_INFO "%s:%d:%s: size=0x%lx rom=0x%lx off=0x%lx\n", __FILE__,__LINE__,__FUNCTION__,size,rom,off);
+ if (off >= size) {
+ printk(KERN_INFO "%s:%d:%s: off >= size!\n", __FILE__,__LINE__,__FUNCTION__);
count = 0;
- else {
+ } else {
So next, why is it failing to decode the ROM size correctly?
pci_get_rom_size(), here I come.
--
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: 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
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