* Re: virtex_devices.c
From: Grant Likely @ 2007-05-07 0:46 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <463E4B13.2030600@dlasys.net>
On 5/6/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> >> At some point if I get inspired I may take a wack at crafting
> >> generic approach using an early serial mini driver.
> >>
> >> But for the moment my choices are:
> >> add a few more 8250 specific #ifdefs to kill off most of
> >> the
> >> conflicting code in virtex_devices.c
> >> and adapt my own code that is already in my BSP. This is the
> >> simplest and does the least damage to your code.
>
> > Considering the fact that the whole purpose of virtex_devices.c is to
> > massage the mess of #defines that is xparameters.h in to something
> > more parsable, then extra #if defined() test may not be a big deal.
> This is not just about virtex_devices. Supporting early Output on
> something other than an 8250
> requires #ifdef's all over creation.
> This is just screaming for a more generic solution. But that needs
> to happen without
> much increase in complexity
Okay if I understand you correctly, you're talking about two areas:
1. setting up output in the zImage wrapper (which is easy), and
2. Stuff turned on by CONFIG_SERIAL_TEXT_DEBUG which does seem to be a
mess of #ifdefs.
Uartlite s already supported in the zImage wrapper, and keyhole
support should be easy to add. As far as CONFIG_SERIAL_TEXT_DEBUG
support; it's probably a case of do whatever you need to make it work;
but don't get too worked up about getting it into mainline. It's all
pretty arch/ppc specific at the moment, and if you want to work on a
generic solution then you should probably wait until arch/powerpc is
working.
> > However, I need clarification. Are you talking about early serial
> > port support, console support or regular serial devices?
> While I am specifically dealing with one area. More broadly I am
> talking about
> all Output prior to the real serial driver coming up.
> This seems to be the pre-linux stuff in
> arch/ppc/boot/simple. You just added a uartlite_tty.c there. I have
> had one for a long time.
> but that is pretty trivial.
> and the slightly more complex
> arch/ppc/syslib/uartlite_dbg that is used by the progress stuff and
> for a bit prior to the early serial
> driver code.
> I do not think you have code for this - but I do.
No, I've not tackled this, and I haven't looked at your code.
> These bits are only critical when something early goes completely to
> crap.
> But then they are important.
>
> > For example;
> > on one of my boards here I've got both 16550 and uartlite devices on
> > the same board and it works fine for serial port access. I've also
> > got another design with only uartlite and another with only 16550.
> > Each of these scenarios should work with the code that is now in
> > mainline (but there are some issues still).
> This is also relevant to me because I have another pseudo serial
> device that I support in exactly the same way as UartLite. It is unique
> enough to our hardware that it is likely of little interest to anyone else.
> But it means everytime I look at a UartLite
Bullshit. :-) The pico is a commercially available board; support
for it should be in mainline. Besides, support in mainline should
make it easier for Pico to sell boards. :-)
> issue, I am looking at a "keyhole" issue too. It means that everywhere
> there is an 8250 specific solution to a problem, I end up with a 3 way fork.
> While support for early non-8250's is lite - there are others besides the
> uartlite and my keyhole.
Right; I agree this should be fixed. However keep in mind that if you
work on it in arch/ppc; you'll probably just end up redoing all your
work again in arch/powerpc.
> > plat_serial8250_port is used because it is the structure used by the
> > platform bus to connect the 8250 driver to 8250 devices. This is of
> > course specific to the 8250 driver. The Uartlite ports are simple
> > enough that they don't need a *_platform_data structure; instead the
> > resources table in a virtex_platform_devices[] entry is sufficient to
> > describe the device to the platform bus. You should be able to do the
> > same thing with your keyhole device registration.
> By substituting uart_port for plat_serial8250 I end up with something generic.
> I do not understand the rational behind the plat_serialxxxx structs.
> It is not like u-boot or something else passes them, they seem to be
> entirely a kernel
> creation, they contain no information that is not in uart_port which
> is generic for
> anything that pretends to be a serial device, and using the
> plat_serial8250 means
> individually copying values from that struct to a uart_port.
> By just substitution uart_port for plat_serial8250 I end up with
> code that is
> exactly the same for anything that looks like a serial device.
plat_serial8250 isn't supposed to be generic. You shouldn't use it as
such. It is supposed to be the driver specific data for the driver's
platform device binding. I may not like the approach of
plat_serial8250, but it at the correct level, and therefore isolated.
The 8250 platform bus binding is the only user of that data.
The generic bit is the platform_device structure. the
virtex_platform_devices[] table is supposed to contain one entry per
device. (8250 is an abomination in this regard; it uses 1
platform_device entry to represent all 8250 serial ports). The
generic early serial code should *not* be looking to the
virtex_serial_platform_data[] table to find ports. It should be
parsing the virtex_platform_devices[] table.
It is done this way because the platform bus infrastructure takes care
of binding platform_device records to platform bus device drivers. No
extra code required.
> > Now, early serial is still a problem. When using zImages, you must
> > To add early serial support, I think virtex_early_serial_map() should
> > be reworked to scan the whole virtex_platform_devices table looking
> > for either "uartlite", "serial8250" or "keyhole" devices.
>
> That is basically what I am doing.
> The UART macro(s) in xparameters, are changed to use uart_port
> element names.
> All serial/pseudo serial devices are setup uniformly the same.
> Serial devices are distinguishable in the uart_port struct by
> their .type field,
> In the rare instances I need to distinguish there are if's or
> switches on the .type field.
Yes, but then you need to write new code to pass each port off to the
correct driver; completely ignoring the platform bus code which *does
the exact same thing*.
> > It doesn't smell right; but I'm not sure I fully understand what
> > you're suggesting. Show me patches.
>
> The basic fundimental question is why is there an 8250 specific
> structure,
> when there is a perfectly good generic structure that already exists ?
> Actually it seems to be even more complex than that because I think
> there is actually an
> old_serial structure that is also used in places.
I ask the opposite question; why try to make the 8250 structure
generic when there is already a generic structure that does exactly
what you want one level up?
I *do* think that 8250 should be changed; but not in the way you're describing.
>
> This is not really a virtex or ppc question and probably belongs on
> linux-serial,
> but the gist is uart_port is what the majority if not all serial
> devices end up using.
Right; but we're not talking about the internal use of uart_port by
the drivers. We're talking about the
> instead of starting with something else and then having incongruent
> field names
> lots fo device specific code and/or #ifdef's,
> if we just use uart_port instead of plat_serialxxx's for every device,
> then all code gets simpler as does adding additional devices.
> Shortly I hope. I have code, it is just not working at this minute.
> Actually I suspect it is working, but my overall migration from my
> implimentation of your earlier code to my implimentation of your newer
> code is not yet working.
I look forward to seeing it.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 4/6] Device tree aware EMAC driver
From: David Gibson @ 2007-05-07 0:30 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070504055455.GA25922@localhost.localdomain>
This is BenH's rewritten, device tree aware driver for the IBM/AMCC
EMAC, ethernet MAC controller ASIC found on various 4xx CPUs and also
the Axon bridge. Tweaked to build on current kernels.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Patch is too too big for the list, get it from
http://ozlabs.org/~dgibson/home/tmp/powerpc-emac-new
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Matt Sealey @ 2007-05-06 22:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Olof Johansson, linuxppc-dev@ozlabs.org
In-Reply-To: <1178209046.17201.55.camel@ld0161-tx32>
Jon Loeliger wrote:
> On Thu, 2007-05-03 at 11:10, Olof Johansson wrote:
>
>> This sounds like something that firmware should take care of, not
>> hardcoded in the board code. Seems like the device is just a PCI device
>> that doesn't have a device tree entry.
>
> Well, it's not a PCI device at all.
A PCI Express southbridge - not much difference really is there?
>> Why not do this in u-boot instead?
>
> Why do it there? We'd have to do it _again_ in Linux
> if we didn't come in from U-Boot anyway.
Because the firmware should configure the board specifics if possible,
Linux should only be tweaking Northbridge/Southbridge settings if it
is truly configurable at runtime or boot. If the difference is between
whether an AC97 or Azalia codec is installed and soldered to the board,
and it is not possible to have both, really the firmware should be
setting up the chip so that only one is obviously usable.
Ostensibly Linux and any drivers should be able to check which is
enabled on the board - one revision may have AC97 and one may have
Azalia HD audio. If this can be swapped by simply having each driver
check the enabled codec mode on init, and dropping out if not correct,
then it's starting to get to be Plug And Play.
The alternative is that every revision of the board has it Hardcoded
Into A Board Support Package, with different device trees and strange
quirks which may or may not be easily determined, cluttering Kconfigs
and so on.
In theory; the firmware should do it, and if not, it should be done
as early in Linux boot (platform init, device tree fixup) as possible.
That's how we agreed to do it on the Efika after much, much discussion
and argument :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Writing an AC97 device driver for MPC52xx
From: Matt Sealey @ 2007-05-06 22:25 UTC (permalink / raw)
To: spitzauer_77; +Cc: linuxppc-dev
In-Reply-To: <20070503142259.222640@gmx.net>
There's a driver available for the Efika and Lite5200B boards.
It needs a lot of improvement but it's there. I can send you a copy of the
patch for the AC97 if you like, seperate to the list. No point duplicating
work. I'm sure others can do the same if they have anything else (although
the driver will no doubt be Sylvain's :)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
spitzauer_77@gmx.de wrote:
> Hi all,
>
> i try to write device driver for an AC97 external codec on MPC5200 controller. The PSC1 and 2 on MPC5200 can be configured as AC97.
>
> I'm a little bit new in this topic of writing linux drivers and read a lot in the internet about this. (e.g. http://www.alsa-project.org/~iwai/writing-an-alsa-driver/x1052.htm )
>
> But i have some questions:
>
> - Is there a simple driver maybe on other platforms available, which have the same problem solved?? Most of the sound drivers are coupled with pci.
>
> - I only have to write the pure hardware (PSC) stuff, or?? I'm little confused on how i should handle this with AC97 (ac97_codec.c) and ALSA.
>
> - Is this for my driver the correct layer:
> User App -> ALSA -> AC97 -> "My driver" -> Hardware MPC52xx
>
>
> I'm glad for any hint!
>
> Spitzauer
^ permalink raw reply
* Re: virtex_devices.c
From: David H. Lynch Jr. @ 2007-05-06 21:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0705051516h2b0259cfgbe3be784acf4086a@mail.gmail.com>
Grant Likely wrote:
>
> I think I understand what you're describing, but I'd need to see your
> code snippits to be sure. Can you send me the relevant patches?
>
As soon as I have something working I will post it.
>> At some point if I get inspired I may take a wack at crafting
>> generic approach using an early serial mini driver.
>>
>> But for the moment my choices are:
>> add a few more 8250 specific #ifdefs to kill off most of
>> the
>> conflicting code in virtex_devices.c
>> and adapt my own code that is already in my BSP. This is the
>> simplest and does the least damage to your code.
> Considering the fact that the whole purpose of virtex_devices.c is to
> massage the mess of #defines that is xparameters.h in to something
> more parsable, then extra #if defined() test may not be a big deal.
This is not just about virtex_devices. Supporting early Output on
something other than an 8250
requires #ifdef's all over creation.
This is just screaming for a more generic solution. But that needs
to happen without
much increase in complexity
>
> However, I need clarification. Are you talking about early serial
> port support, console support or regular serial devices?
While I am specifically dealing with one area. More broadly I am
talking about
all Output prior to the real serial driver coming up.
This seems to be the pre-linux stuff in
arch/ppc/boot/simple. You just added a uartlite_tty.c there. I have
had one for a long time.
but that is pretty trivial.
and the slightly more complex
arch/ppc/syslib/uartlite_dbg that is used by the progress stuff and
for a bit prior to the early serial
driver code.
I do not think you have code for this - but I do.
These bits are only critical when something early goes completely to
crap.
But then they are important.
> For example;
> on one of my boards here I've got both 16550 and uartlite devices on
> the same board and it works fine for serial port access. I've also
> got another design with only uartlite and another with only 16550.
> Each of these scenarios should work with the code that is now in
> mainline (but there are some issues still).
This is also relevant to me because I have another pseudo serial
device that I support
in exactly the same way as UartLite. It is unique enough to our
hardware that
it is likely of little interest to anyone else. But it means
everytime I look at a UartLite
issue, I am looking at a "keyhole" issue too.
It means that everywhere there is an 8250 specific solution to a
problem,
I end up with a 3 way fork.
While support for early non-8250's is lite - there are others
besides the uartlite and my keyhole.
I rarely use JTAG and other hardware debugging tools. It is critical
for me to be able to
output information at most every part of the kernel load process.
>
> plat_serial8250_port is used because it is the structure used by the
> platform bus to connect the 8250 driver to 8250 devices. This is of
> course specific to the 8250 driver. The Uartlite ports are simple
> enough that they don't need a *_platform_data structure; instead the
> resources table in a virtex_platform_devices[] entry is sufficient to
> describe the device to the platform bus. You should be able to do the
> same thing with your keyhole device registration.
By substituting uart_port for plat_serial8250 I end up with
something generic.
I do not understand the rational behind the plat_serialxxxx structs.
It is not like u-boot or something else passes them, they seem to be
entirely a kernel
creation, they contain no information that is not in uart_port which
is generic for
anything that pretends to be a serial device, and using the
plat_serial8250 means
individually copying values from that struct to a uart_port.
By just substitution uart_port for plat_serial8250 I end up with
code that is
exactly the same for anything that looks like a serial device.
>
> Now, early serial is still a problem. When using zImages, you must
> make sure that only one of CONFIG_SERIAL_UARTLITE_CONSOLE and
> CONFIG_SERIAL_8250_CONSOLE is set. If they are both set, then it will
> not compile. (But this is just a zImage boot wrapper issue. The
> kernel proper should work fine). Also, early serial in the kernel
> proper is not implemented in driver which is in mainline, but console
> and regular serial access is supported.
>
> To add early serial support, I think virtex_early_serial_map() should
> be reworked to scan the whole virtex_platform_devices table looking
> for either "uartlite", "serial8250" or "keyhole" devices.
That is basically what I am doing.
The UART macro(s) in xparameters, are changed to use uart_port
element names.
All serial/pseudo serial devices are setup uniformly the same.
Serial devices are distinguishable in the uart_port struct by
their .type field,
In the rare instances I need to distinguish there are if's or
switches on the .type field.
>
> Go ahead, stomp away. Worst that can happen is that I disagree. :)
> I certainly won't be offended.
>
>>
>> Is there some compelling reason to use plat_serial8250 as
>> the structure in which the port data is stored as opposed to
>> something more generic ?
>
> plat_serial8250 isn't supposed to be generic. The generic bit is
> supposed to be the virtex_platform_devices table. BTW, my personal
> opinion is that plat_serial8250 is poorly implemented because it maps
> multiple 8250 devices to a single platform_device. Instead, it should
> be a 1-1 mapping (like all the other devices in the
> virtex_platform_devices table). ie. Don't try to describe all serial
> devices, regardless of type, in a single platform_device record.
>
>> Do you have an objection to my making the changes needed to
>> switch to the uart_port struct as the initialization data ?
>
> It doesn't smell right; but I'm not sure I fully understand what
> you're suggesting. Show me patches.
The basic fundimental question is why is there an 8250 specific
structure,
when there is a perfectly good generic structure that already exists ?
Actually it seems to be even more complex than that because I think
there is actually an
old_serial structure that is also used in places.
This is not really a virtex or ppc question and probably belongs on
linux-serial,
but the gist is uart_port is what the majority if not all serial
devices end up using.
instead of starting with something else and then having incongruent
field names
lots fo device specific code and/or #ifdef's,
if we just use uart_port instead of plat_serialxxx's for every device,
then all code gets simpler as does adding additional devices.
Shortly I hope. I have code, it is just not working at this minute.
Actually I suspect it is working, but my overall migration from my
implimentation of your earlier code to my implimentation of your newer
code is not yet working.
>
>>
>> Do you have any objection to my adding additional choices
>> such as UartLite to the virtex_devices serial initialization ?
>
> Absolutely not. This is a good thing.
>
>> Do you have a different direction you would prefer to see things go
>> - aside from moving to device trees and/or implimenting
>> a more generic early serial driver, both of which I don't think I
>> want to try at this instant ?
>
> As I described above.
>
> Now, all this being said; we do need to migrate to arch/powerpc
> relatively soon. If the changes are not too complex or if they ease
> our migration to arch/powerpc, then I'm all for it. If you're
> undertaking a major development effort of stuff that's arch/ppc only;
> then I recommend against it. :-)
>
> Oh, and I'd *really* like to see pico support hit mainline. Easiest
> way to do this is to break of chunks and tackle them one at a time
> which is easier than trying to get the whole patchset in at once.
> Keyhole driver sounds like a good place to start.
>
> Cheers,
> g.
>
>
--
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: Correct location for ADC/DAC drivers
From: Guennadi Liakhovetski @ 2007-05-06 20:20 UTC (permalink / raw)
To: Bodo Eggert; +Cc: linuxppc-dev, Robin Getz, linux-kernel
In-Reply-To: <E1Hkfia-0000cJ-18@be1.lrz>
On Sun, 6 May 2007, Bodo Eggert wrote:
> Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> > On Fri 4 May 2007 16:52, Robert Schwebel pondered:
> >> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>
> >> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
> >> > that would be nice to put in the "right" place - I don't think that
> >> > drivers/char is the right place, nor drivers/misc - I also don't think
> >> > that /adc is a descriptive place for DAC or mixed signal front ends
> >> > (MxFE).
> >>
> >> What userspace interface do your drivers have?
> >
> > Right now, it is a little rudimentary char interface, it needs a little care
> > to be a bit more general purpose, but it suited needs of what the people who
> > were using it.
If I were thinking about a DAC / ADC API I would have a look at Comedi -
somehow I think it should be pretty well designed...
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Robin Getz @ 2007-05-06 19:33 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linuxppc-dev, Bodo Eggert, linux-kernel
In-Reply-To: <20070506160104.GV22585@pengutronix.de>
On Sun 6 May 2007 12:01, Robert Schwebel pondered:
> On Sun, May 06, 2007 at 02:19:59PM +0200, Bodo Eggert wrote:
> > Since you ask for random thoughts:
> >
> > IO of data streams from or to a DAC/ADC is essentially what soundcards
> > do. I'm wondering if these cards are similar enough to use alsa, and if
> > using that interface would ease or hinder programming the driver.
>
> I had a short look at ALSA and it looks like it is a little bit too
> focussed towards "normal" audio. For example, if follows an asynchronous
> model in the sense that an application can read/write to a buffer at any
> time, taken that the ringbuffer doesn't overflow. That's not enough for
> example for control applications; you need the option for real
> synchronous operation there.
Yes - there are too many applications which require tight/sync connection with
the data - control loops, software radios, machine control, etc - all have
much different needs than audio, hwmon, or touchscreen.
> IMHO we need an API which offers
>
> - kernel ring buffers (to make it sure no data gets lost)
> - generic data types (streaming plain ADC values is just the simplest
> case; we also have for example streaming FPGA data containing
> preprocessed data sets)
> - optional timestamping for each sample
> - zero-copy from hardware into userspace memory, with DMA support
I am assuming that the driver takes care of all DMA/coherency issues that
might pop up? (and handles all interrupts)?
> - application notification every N samples (N >= 1)
>
> v4l2 may also be worth a look; but in the end I suppose they are all
> specialized sub-cases of what we'd need for fast DAQ.
I would guess that something like v4l might be the best bet - the driver
provides a few mmapped buffers that you can read/write into, and some
mechanism to sync in/out of the buffers.
I was actually looking at UIO, but thought that since we really desire the
kernel ring buffers, that a think model might be better.?
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-documentation.patch
-Robin
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Robert Schwebel @ 2007-05-06 16:01 UTC (permalink / raw)
To: Bodo Eggert; +Cc: linuxppc-dev, linux-kernel, Robin Getz
In-Reply-To: <E1Hkfia-0000cJ-18@be1.lrz>
On Sun, May 06, 2007 at 02:19:59PM +0200, Bodo Eggert wrote:
> Since you ask for random thoughts:
>
> IO of data streams from or to a DAC/ADC is essentially what soundcards do.
> I'm wondering if these cards are similar enough to use alsa, and if using
> that interface would ease or hinder programming the driver.
I had a short look at ALSA and it looks like it is a little bit too
focussed towards "normal" audio. For example, if follows an asynchronous
model in the sense that an application can read/write to a buffer at any
time, taken that the ringbuffer doesn't overflow. That's not enough for
example for control applications; you need the option for real
synchronous operation there.
IMHO we need an API which offers
- kernel ring buffers (to make it sure no data gets lost)
- generic data types (streaming plain ADC values is just the simplest
case; we also have for example streaming FPGA data containing
preprocessed data sets)
- optional timestamping for each sample
- zero-copy from hardware into userspace memory, with DMA support
- application notification every N samples (N >= 1)
v4l2 may also be worth a look; but in the end I suppose they are all
specialized sub-cases of what we'd need for fast DAQ.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* [PATCH 8/8] powerpc: mpc52xx suspend to deep-sleep
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut, Domen Puncer
In-Reply-To: <11784659381238-git-send-email-tnt@246tNt.com>
From: Domen Puncer <domen.puncer@telargo.com>
Implement deep-sleep on MPC52xx.
SDRAM is put into self-refresh with help of SRAM code
(alternatives would be code in FLASH, I-cache).
Interrupt code must also not be in SDRAM, so put it
in I-cache.
MPC52xx core is static, so contents will remain intact even
with clocks turned off.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
arch/powerpc/platforms/52xx/Makefile | 2 +
arch/powerpc/platforms/52xx/efika.c | 15 ++
arch/powerpc/platforms/52xx/lite5200.c | 28 ++++
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 191 +++++++++++++++++++++++++++
arch/powerpc/platforms/52xx/mpc52xx_sleep.S | 154 +++++++++++++++++++++
include/asm-powerpc/mpc52xx.h | 11 ++
6 files changed, 401 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_pm.c
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_sleep.S
diff --git a/arch/powerpc/platforms/52xx/Makefile b/arch/powerpc/platforms/52xx/Makefile
index 07cdbca..b91e39c 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -8,3 +8,5 @@ endif
obj-$(CONFIG_PPC_EFIKA) += efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
+
+obj-$(CONFIG_PM) += mpc52xx_sleep.o mpc52xx_pm.o
diff --git a/arch/powerpc/platforms/52xx/efika.c b/arch/powerpc/platforms/52xx/efika.c
index a6bba97..f591a9f 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -184,6 +184,16 @@ static void efika_show_cpuinfo(struct seq_file *m)
of_node_put(root);
}
+#ifdef CONFIG_PM
+static void efika_suspend_prepare(void __iomem *mbar)
+{
+ u8 pin = 4; /* GPIO_WKUP_4 (GPIO_PSC6_0 - IRDA_RX) */
+ u8 level = 1; /* wakeup on high level */
+ /* IOW. to wake it up, short pins 1 and 3 on IRDA connector */
+ mpc52xx_set_wakeup_gpio(pin, level);
+}
+#endif
+
static void __init efika_setup_arch(void)
{
rtas_initialize();
@@ -199,6 +209,11 @@ static void __init efika_setup_arch(void)
efika_pcisetup();
+#ifdef CONFIG_PM
+ mpc52xx_suspend.board_suspend_prepare = efika_suspend_prepare;
+ mpc52xx_pm_init();
+#endif
+
if (ppc_md.progress)
ppc_md.progress("Linux/PPC " UTS_RELEASE " running on Efika ;-)\n", 0x0);
}
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 8e2646a..1cfc00d 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -85,6 +85,28 @@ error:
iounmap(gpio);
}
+#ifdef CONFIG_PM
+static u32 descr_a;
+static void lite5200_suspend_prepare(void __iomem *mbar)
+{
+ u8 pin = 1; /* GPIO_WKUP_1 (GPIO_PSC2_4) */
+ u8 level = 0; /* wakeup on low level */
+ mpc52xx_set_wakeup_gpio(pin, level);
+
+ /*
+ * power down usb port
+ * this needs to be called before of-ohci suspend code
+ */
+ descr_a = in_be32(mbar + 0x1048);
+ out_be32(mbar + 0x1048, (descr_a & ~0x200) | 0x100);
+}
+
+static void lite5200_resume_finish(void __iomem *mbar)
+{
+ out_be32(mbar + 0x1048, descr_a);
+}
+#endif
+
static void __init lite5200_setup_arch(void)
{
struct device_node *np;
@@ -107,6 +129,12 @@ static void __init lite5200_setup_arch(void)
mpc52xx_setup_cpu(); /* Generic */
lite5200_setup_cpu(); /* Platorm specific */
+#ifdef CONFIG_PM
+ mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
+ mpc52xx_suspend.board_resume_finish = lite5200_resume_finish;
+ mpc52xx_pm_init();
+#endif
+
#ifdef CONFIG_PCI
np = of_find_node_by_type(NULL, "pci");
if (np) {
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pm.c b/arch/powerpc/platforms/52xx/mpc52xx_pm.c
new file mode 100644
index 0000000..fd40044
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pm.c
@@ -0,0 +1,191 @@
+#include <linux/init.h>
+#include <linux/pm.h>
+#include <linux/io.h>
+#include <asm/time.h>
+#include <asm/cacheflush.h>
+#include <asm/mpc52xx.h>
+
+#include "mpc52xx_pic.h"
+
+
+/* these are defined in mpc52xx_sleep.S, and only used here */
+extern void mpc52xx_deep_sleep(void *sram, void *sdram_regs,
+ struct mpc52xx_cdm *, struct mpc52xx_intr *);
+extern void mpc52xx_ds_sram(void);
+extern const long mpc52xx_ds_sram_size;
+extern void mpc52xx_ds_cached(void);
+extern const long mpc52xx_ds_cached_size;
+
+static void __iomem *mbar;
+static void __iomem *sdram;
+static struct mpc52xx_cdm __iomem *cdm;
+static struct mpc52xx_intr __iomem *intr;
+static struct mpc52xx_gpio_wkup __iomem *gpiow;
+static void *sram;
+static int sram_size;
+
+struct mpc52xx_suspend mpc52xx_suspend;
+
+static int mpc52xx_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+int mpc52xx_set_wakeup_gpio(u8 pin, u8 level)
+{
+ u16 tmp;
+
+ /* enable gpio */
+ out_8(&gpiow->wkup_gpioe, in_8(&gpiow->wkup_gpioe) | (1 << pin));
+ /* set as input */
+ out_8(&gpiow->wkup_ddr, in_8(&gpiow->wkup_ddr) & ~(1 << pin));
+ /* enable deep sleep interrupt */
+ out_8(&gpiow->wkup_inten, in_8(&gpiow->wkup_inten) | (1 << pin));
+ /* low/high level creates wakeup interrupt */
+ tmp = in_be16(&gpiow->wkup_itype);
+ tmp &= ~(0x3 << (pin * 2));
+ tmp |= (!level + 1) << (pin * 2);
+ out_be16(&gpiow->wkup_itype, tmp);
+ /* master enable */
+ out_8(&gpiow->wkup_maste, 1);
+
+ return 0;
+}
+
+int mpc52xx_pm_prepare(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_STANDBY)
+ return -EINVAL;
+
+ /* map the whole register space */
+ mbar = mpc52xx_find_and_map("mpc5200");
+ if (!mbar) {
+ printk(KERN_ERR "%s:%i Error mapping registers\n", __func__, __LINE__);
+ return -ENOSYS;
+ }
+ /* these offsets are from mpc5200 users manual */
+ sdram = mbar + 0x100;
+ cdm = mbar + 0x200;
+ intr = mbar + 0x500;
+ gpiow = mbar + 0xc00;
+ sram = mbar + 0x8000; /* Those will be handled by the */
+ sram_size = 0x4000; /* bestcomm driver soon */
+
+ /* call board suspend code, if applicable */
+ if (mpc52xx_suspend.board_suspend_prepare)
+ mpc52xx_suspend.board_suspend_prepare(mbar);
+ else {
+ printk(KERN_ALERT "%s: %i don't know how to wake up the board\n",
+ __func__, __LINE__);
+ goto out_unmap;
+ }
+
+ return 0;
+
+ out_unmap:
+ iounmap(mbar);
+ return -ENOSYS;
+}
+
+
+char saved_sram[0x4000];
+
+int mpc52xx_pm_enter(suspend_state_t state)
+{
+ u32 clk_enables;
+ u32 msr, hid0;
+ u32 intr_main_mask;
+ void __iomem * irq_0x500 = (void *)CONFIG_KERNEL_START + 0x500;
+ unsigned long irq_0x500_stop = (unsigned long)irq_0x500 + mpc52xx_ds_cached_size;
+ char saved_0x500[mpc52xx_ds_cached_size];
+
+ /* disable all interrupts in PIC */
+ intr_main_mask = in_be32(&intr->main_mask);
+ out_be32(&intr->main_mask, intr_main_mask | 0x1ffff);
+
+ /* don't let DEC expire any time soon */
+ mtspr(SPRN_DEC, 0x7fffffff);
+
+ /* save SRAM */
+ memcpy(saved_sram, sram, sram_size);
+
+ /* copy low level suspend code to sram */
+ memcpy(sram, mpc52xx_ds_sram, mpc52xx_ds_sram_size);
+
+ out_8(&cdm->ccs_sleep_enable, 1);
+ out_8(&cdm->osc_sleep_enable, 1);
+ out_8(&cdm->ccs_qreq_test, 1);
+
+ /* disable all but SDRAM and bestcomm (SRAM) clocks */
+ clk_enables = in_be32(&cdm->clk_enables);
+ out_be32(&cdm->clk_enables, clk_enables & 0x00088000);
+
+ /* disable power management */
+ msr = mfmsr();
+ mtmsr(msr & ~MSR_POW);
+
+ /* enable sleep mode, disable others */
+ hid0 = mfspr(SPRN_HID0);
+ mtspr(SPRN_HID0, (hid0 & ~(HID0_DOZE | HID0_NAP | HID0_DPM)) | HID0_SLEEP);
+
+ /* save original, copy our irq handler, flush from dcache and invalidate icache */
+ memcpy(saved_0x500, irq_0x500, mpc52xx_ds_cached_size);
+ memcpy(irq_0x500, mpc52xx_ds_cached, mpc52xx_ds_cached_size);
+ flush_icache_range((unsigned long)irq_0x500, irq_0x500_stop);
+
+ /* call low-level sleep code */
+ mpc52xx_deep_sleep(sram, sdram, cdm, intr);
+
+ /* restore original irq handler */
+ memcpy(irq_0x500, saved_0x500, mpc52xx_ds_cached_size);
+ flush_icache_range((unsigned long)irq_0x500, irq_0x500_stop);
+
+ /* restore old power mode */
+ mtmsr(msr & ~MSR_POW);
+ mtspr(SPRN_HID0, hid0);
+ mtmsr(msr);
+
+ out_be32(&cdm->clk_enables, clk_enables);
+ out_8(&cdm->ccs_sleep_enable, 0);
+ out_8(&cdm->osc_sleep_enable, 0);
+
+ /* restore SRAM */
+ memcpy(sram, saved_sram, sram_size);
+
+ /* restart jiffies */
+ wakeup_decrementer();
+
+ /* reenable interrupts in PIC */
+ out_be32(&intr->main_mask, intr_main_mask);
+
+ return 0;
+}
+
+int mpc52xx_pm_finish(suspend_state_t state)
+{
+ /* call board resume code */
+ if (mpc52xx_suspend.board_resume_finish)
+ mpc52xx_suspend.board_resume_finish(mbar);
+
+ iounmap(mbar);
+
+ return 0;
+}
+
+static struct pm_ops mpc52xx_pm_ops = {
+ .valid = mpc52xx_pm_valid,
+ .prepare = mpc52xx_pm_prepare,
+ .enter = mpc52xx_pm_enter,
+ .finish = mpc52xx_pm_finish,
+};
+
+int __init mpc52xx_pm_init(void)
+{
+ pm_set_ops(&mpc52xx_pm_ops);
+ return 0;
+}
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_sleep.S b/arch/powerpc/platforms/52xx/mpc52xx_sleep.S
new file mode 100644
index 0000000..4dc170b
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_sleep.S
@@ -0,0 +1,154 @@
+#include <asm/reg.h>
+#include <asm/ppc_asm.h>
+#include <asm/processor.h>
+
+
+.text
+
+_GLOBAL(mpc52xx_deep_sleep)
+mpc52xx_deep_sleep: /* args r3-r6: SRAM, SDRAM regs, CDM regs, INTR regs */
+
+ /* enable interrupts */
+ mfmsr r7
+ ori r7, r7, 0x8000 /* EE */
+ mtmsr r7
+ sync; isync;
+
+ li r10, 0 /* flag that irq handler sets */
+
+ /* enable tmr7 (or any other) interrupt */
+ lwz r8, 0x14(r6) /* intr->main_mask */
+ ori r8, r8, 0x1
+ xori r8, r8, 0x1
+ stw r8, 0x14(r6)
+ sync
+
+ /* emulate tmr7 interrupt */
+ li r8, 0x1
+ stw r8, 0x40(r6) /* intr->main_emulate */
+ sync
+
+ /* wait for it to happen */
+1:
+ cmpi cr0, r10, 1
+ bne cr0, 1b
+
+ /* lock icache */
+ mfspr r10, SPRN_HID0
+ ori r10, r10, 0x2000
+ sync; isync;
+ mtspr SPRN_HID0, r10
+ sync; isync;
+
+
+ mflr r9 /* save LR */
+
+ /* jump to sram */
+ mtlr r3
+ blrl
+
+ mtlr r9 /* restore LR */
+
+ /* unlock icache */
+ mfspr r10, SPRN_HID0
+ ori r10, r10, 0x2000
+ xori r10, r10, 0x2000
+ sync; isync;
+ mtspr SPRN_HID0, r10
+ sync; isync;
+
+
+ /* return to C code */
+ blr
+
+
+_GLOBAL(mpc52xx_ds_sram)
+mpc52xx_ds_sram:
+ /* put SDRAM into self-refresh */
+ lwz r8, 0x4(r4) /* sdram->ctrl */
+
+ oris r8, r8, 0x8000 /* mode_en */
+ stw r8, 0x4(r4)
+ sync
+
+ ori r8, r8, 0x0002 /* soft_pre */
+ stw r8, 0x4(r4)
+ sync
+ xori r8, r8, 0x0002
+
+ xoris r8, r8, 0x8000 /* !mode_en */
+ stw r8, 0x4(r4)
+ sync
+
+ oris r8, r8, 0x5000
+ xoris r8, r8, 0x4000 /* ref_en !cke */
+ stw r8, 0x4(r4)
+ sync
+
+ /* disable SDRAM clock */
+ lwz r8, 0x14(r5) /* cdm->clkenable */
+ ori r8, r8, 0x0008
+ xori r8, r8, 0x0008
+ stw r8, 0x14(r5)
+ sync
+
+
+ /* put mpc5200 to sleep */
+ mfmsr r10
+ oris r10, r10, 0x0004 /* POW = 1 */
+ sync; isync;
+ mtmsr r10
+ sync; isync;
+
+
+ /* enable clock */
+ lwz r8, 0x14(r5)
+ ori r8, r8, 0x0008
+ stw r8, 0x14(r5)
+ sync
+
+ /* get ram out of self-refresh */
+ lwz r8, 0x4(r4)
+ oris r8, r8, 0x5000 /* cke ref_en */
+ stw r8, 0x4(r4)
+ sync
+
+ blr
+_GLOBAL(mpc52xx_ds_sram_size)
+mpc52xx_ds_sram_size:
+ .long $-mpc52xx_ds_sram
+
+
+/* ### interrupt handler for wakeup from deep-sleep ### */
+_GLOBAL(mpc52xx_ds_cached)
+mpc52xx_ds_cached:
+ mtspr SPRN_SPRG0, r7
+ mtspr SPRN_SPRG1, r8
+
+ /* disable emulated interrupt */
+ mfspr r7, 311 /* MBAR */
+ addi r7, r7, 0x540 /* intr->main_emul */
+ li r8, 0
+ stw r8, 0(r7)
+ sync
+ dcbf 0, r7
+
+ /* acknowledge wakeup, so CCS releases power pown */
+ mfspr r7, 311 /* MBAR */
+ addi r7, r7, 0x524 /* intr->enc_status */
+ lwz r8, 0(r7)
+ ori r8, r8, 0x0400
+ stw r8, 0(r7)
+ sync
+ dcbf 0, r7
+
+ /* flag - we handled the interrupt */
+ li r10, 1
+
+ mfspr r8, SPRN_SPRG1
+ mfspr r7, SPRN_SPRG0
+
+ rfi
+_GLOBAL(mpc52xx_ds_cached_size)
+mpc52xx_ds_cached_size:
+ .long $-mpc52xx_ds_cached
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 7afd5bf..c4631f6 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -253,5 +253,16 @@ extern int __init mpc52xx_add_bridge(struct device_node *node);
#endif /* __ASSEMBLY__ */
+#ifdef CONFIG_PM
+struct mpc52xx_suspend {
+ void (*board_suspend_prepare)(void __iomem *mbar);
+ void (*board_resume_finish)(void __iomem *mbar);
+};
+
+extern struct mpc52xx_suspend mpc52xx_suspend;
+extern int __init mpc52xx_pm_init(void);
+extern int mpc52xx_set_wakeup_gpio(u8 pin, u8 level);
+#endif /* CONFIG_PM */
+
#endif /* __ASM_POWERPC_MPC52xx_H__ */
--
1.5.1.2
^ permalink raw reply related
* [PATCH 6/8] powerpc: Set efika's device_type to "soc"
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut, Domen Puncer
In-Reply-To: <11784659371139-git-send-email-tnt@246tNt.com>
From: Domen Puncer <domen.puncer@telargo.com>
Device type should be "soc" (as in lite5200.dts), compatible is
already set to "mpc5200".
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index e27d9d1..87efb42 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2153,7 +2153,7 @@ static void __init fixup_device_tree_efika(void)
3,12,0, 3,13,0, 3,14,0, 3,15,0 };
struct subst_entry efika_subst_table[] = {
{ "/", "device_type", prop_cstr("efika") },
- { "/builtin", "compatible", prop_cstr("soc") },
+ { "/builtin", "device_type", prop_cstr("soc") },
{ "/builtin/ata", "compatible", prop_cstr("mpc5200b-ata\0mpc5200-ata"), },
{ "/builtin/bestcomm", "compatible", prop_cstr("mpc5200b-bestcomm\0mpc5200-bestcomm") },
{ "/builtin/bestcomm", "interrupts", prop_bcomm_irq, sizeof(prop_bcomm_irq) },
--
1.5.1.2
^ permalink raw reply related
* [PATCH 7/8] serial/powerpc: Don't shutdown TX on mpc5200 serial port if it is a console
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut
In-Reply-To: <11784659372712-git-send-email-tnt@246tNt.com>
From: Grant Likely <grant.likely@secretlab.ca>
If the serial port gets shut down, then console output stalls. 9 out
of 10 kernel hackers agree, this is a bad thing.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
drivers/serial/mpc52xx_uart.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index f8c1761..35f8b86 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -257,9 +257,10 @@ mpc52xx_uart_shutdown(struct uart_port *port)
{
struct mpc52xx_psc __iomem *psc = PSC(port);
- /* Shut down the port, interrupt and all */
+ /* Shut down the port. Leave TX active if on a console port */
out_8(&psc->command,MPC52xx_PSC_RST_RX);
- out_8(&psc->command,MPC52xx_PSC_RST_TX);
+ if (!uart_console(port))
+ out_8(&psc->command,MPC52xx_PSC_RST_TX);
port->read_status_mask = 0;
out_be16(&psc->mpc52xx_psc_imr,port->read_status_mask);
--
1.5.1.2
^ permalink raw reply related
* [PATCH 5/8] powerpc: lite5200(b) support for i2c
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut, Domen Puncer
In-Reply-To: <1178465936695-git-send-email-tnt@246tNt.com>
From: Domen Puncer <domen.puncer@telargo.com>
Add fsl-i2c to mpc5200 i2c node in device tree, and enable FSL_SOC.
Tested to work with built-in eeprom on lite5200b.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
arch/powerpc/boot/dts/lite5200.dts | 6 ++++--
arch/powerpc/boot/dts/lite5200b.dts | 6 ++++--
arch/powerpc/platforms/52xx/Kconfig | 1 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index 6e2650d..e13ac6e 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -318,20 +318,22 @@
i2c@3d00 {
device_type = "i2c";
- compatible = "mpc5200-i2c";
+ compatible = "mpc5200-i2c\0fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
interrupt-parent = <500>;
+ fsl5200-clocking;
};
i2c@3d40 {
device_type = "i2c";
- compatible = "mpc5200-i2c";
+ compatible = "mpc5200-i2c\0fsl-i2c";
cell-index = <1>;
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <500>;
+ fsl5200-clocking;
};
sram@8000 {
device_type = "sram";
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 5ba8100..00211b3 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -323,20 +323,22 @@
i2c@3d00 {
device_type = "i2c";
- compatible = "mpc5200b-i2c\0mpc5200-i2c";
+ compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
cell-index = <0>;
reg = <3d00 40>;
interrupts = <2 f 0>;
interrupt-parent = <500>;
+ fsl5200-clocking;
};
i2c@3d40 {
device_type = "i2c";
- compatible = "mpc5200b-i2c\0mpc5200-i2c";
+ compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
cell-index = <1>;
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <500>;
+ fsl5200-clocking;
};
sram@8000 {
device_type = "sram";
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index bc4aa4a..3ffaa06 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -1,5 +1,6 @@
config PPC_MPC52xx
bool
+ select FSL_SOC
default n
config PPC_MPC5200
--
1.5.1.2
^ permalink raw reply related
* macio modalias & mpc52xx related patches for 2.6.22
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML
Hello Paul,
Here's the patch I'd like to see merged for 2.6.22
The first one fixs the remaining autoload problems that appeared with
the uevent stuff. It has been tested by me, Johannes & benh.
The second & third are just a clean up to avoid discrepency in the
modalias generation (the same string was generated differently at
several place). They work fine on my G5.
The rest of the series are patch I received on the -embedded list,
they've been reviewed/tested by at least either Grant or me.
Sylvain
^ permalink raw reply
* [PATCH 4/8] powerpc: lite5200(b) dts fixes
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut, Domen Puncer
In-Reply-To: <11784659368-git-send-email-tnt@246tNt.com>
From: Domen Puncer <domen.puncer@telargo.com>
Three trivial DTS fixes:
-Mark Lite5200(b) boards as "mpc5200" compatible. On efika the
firmware already does that.
-Fix mscan interrupt.
-Fix wakeup GPIO address.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
arch/powerpc/boot/dts/lite5200.dts | 5 +++--
arch/powerpc/boot/dts/lite5200b.dts | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lite5200.dts
index ba54c6b..6e2650d 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -48,6 +48,7 @@
soc5200@f0000000 {
model = "fsl,mpc5200";
+ compatible = "mpc5200";
revision = "" // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
@@ -166,7 +167,7 @@
device_type = "mscan";
compatible = "mpc5200-mscan";
cell-index = <1>;
- interrupts = <1 12 0>;
+ interrupts = <2 12 0>;
interrupt-parent = <500>;
reg = <980 80>;
};
@@ -178,7 +179,7 @@
interrupt-parent = <500>;
};
- gpio-wkup@b00 {
+ gpio-wkup@c00 {
compatible = "mpc5200-gpio-wkup";
reg = <c00 40>;
interrupts = <1 8 0 0 3 0>;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 2e00308..5ba8100 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -48,6 +48,7 @@
soc5200@f0000000 {
model = "fsl,mpc5200b";
+ compatible = "mpc5200";
revision = ""; // from bootloader
#interrupt-cells = <3>;
device_type = "soc";
@@ -166,7 +167,7 @@
device_type = "mscan";
compatible = "mpc5200b-mscan\0mpc5200-mscan";
cell-index = <1>;
- interrupts = <1 12 0>;
+ interrupts = <2 12 0>;
interrupt-parent = <500>;
reg = <980 80>;
};
@@ -178,7 +179,7 @@
interrupt-parent = <500>;
};
- gpio-wkup@b00 {
+ gpio-wkup@c00 {
compatible = "mpc5200b-gpio-wkup\0mpc5200-gpio-wkup";
reg = <c00 40>;
interrupts = <1 8 0 0 3 0>;
--
1.5.1.2
^ permalink raw reply related
* [PATCH 3/8] macintosh: Use common modalias generation for macio_sysfs
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut
In-Reply-To: <1178465935138-git-send-email-tnt@246tNt.com>
There is now a common function to generate the modalias string,
so use it. We just need to add the \n at the end.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
drivers/macintosh/macio_sysfs.c | 29 ++++++++---------------------
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/macintosh/macio_sysfs.c b/drivers/macintosh/macio_sysfs.c
index cc82679..d8fadc4 100644
--- a/drivers/macintosh/macio_sysfs.c
+++ b/drivers/macintosh/macio_sysfs.c
@@ -40,29 +40,16 @@ compatible_show (struct device *dev, struct device_attribute *attr, char *buf)
static ssize_t modalias_show (struct device *dev, struct device_attribute *attr,
char *buf)
-{
- struct of_device *of;
- const char *compat;
- int cplen;
- int length;
+{
+ struct of_device *ofdev = to_of_device(dev);
+ int len;
- of = &to_macio_device (dev)->ofdev;
- compat = of_get_property(of->node, "compatible", &cplen);
- if (!compat) compat = "", cplen = 1;
- length = sprintf (buf, "of:N%sT%s", of->node->name, of->node->type);
- buf += length;
- while (cplen > 0) {
- int l;
- l = sprintf (buf, "C%s", compat);
- length += l;
- buf += l;
- l = strlen (compat) + 1;
- compat += l;
- cplen -= l;
- }
- length += sprintf(buf, "\n");
+ len = of_device_get_modalias(ofdev, buf, PAGE_SIZE);
- return length;
+ buf[len] = '\n';
+ buf[len+1] = 0;
+
+ return len+1;
}
macio_config_of_attr (name, "%s\n");
--
1.5.1.2
^ permalink raw reply related
* [PATCH 1/8] powerpc: Fix the MODALIAS generation in modpost for of devices
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut
In-Reply-To: <11784659324066-git-send-email-tnt@246tNt.com>
Since the devices may have multiple (or none) compatible properties,
the uevent generated internally by the kernel may have multiple
"C..." entries. So the MODALIAS stored in the module must have
wilcard before and after the compatible entry.
Also, if the 'compatible' field is not used for matching, there
will be no 'C' and that must handled as well.
The previous code handled all those case incorrectly and it
"mostly" worked ... but not always.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
scripts/mod/file2alias.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index b2f73ff..4903292 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -354,11 +354,16 @@ static int do_pcmcia_entry(const char *filename,
static int do_of_entry (const char *filename, struct of_device_id *of, char *alias)
{
+ int len;
char *tmp;
- sprintf (alias, "of:N%sT%sC%s",
+ len = sprintf (alias, "of:N%sT%s",
of->name[0] ? of->name : "*",
- of->type[0] ? of->type : "*",
- of->compatible[0] ? of->compatible : "*");
+ of->type[0] ? of->type : "*");
+
+ if (of->compatible[0])
+ sprintf (&alias[len], "%sC%s",
+ of->type[0] ? "*" : "",
+ of->compatible);
/* Replace all whitespace with underscores */
for (tmp = alias; tmp && *tmp; tmp++)
--
1.5.1.2
^ permalink raw reply related
* [PATCH 2/8] powerpc: export of_device_get_modalias
From: Sylvain Munaut @ 2007-05-06 15:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PPC dev ML, Sylvain Munaut
In-Reply-To: <11784659351487-git-send-email-tnt@246tNt.com>
Apparently other parts of the kernel need to know the
modalias internally (like the sysfs code in macintosh driver).
To avoid consistency issues, we export this code and use it
everywhere it's needed rather than repeat it ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
arch/powerpc/kernel/of_device.c | 5 +++--
include/asm-powerpc/of_device.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/of_device.c b/arch/powerpc/kernel/of_device.c
index 0c8ea76..38a0ef2 100644
--- a/arch/powerpc/kernel/of_device.c
+++ b/arch/powerpc/kernel/of_device.c
@@ -120,8 +120,8 @@ void of_device_unregister(struct of_device *ofdev)
}
-static ssize_t of_device_get_modalias(struct of_device *ofdev,
- char *str, ssize_t len)
+ssize_t of_device_get_modalias(struct of_device *ofdev,
+ char *str, ssize_t len)
{
const char *compat;
int cplen, i;
@@ -239,3 +239,4 @@ EXPORT_SYMBOL(of_dev_get);
EXPORT_SYMBOL(of_dev_put);
EXPORT_SYMBOL(of_release_dev);
EXPORT_SYMBOL(of_device_uevent);
+EXPORT_SYMBOL(of_device_get_modalias);
diff --git a/include/asm-powerpc/of_device.h b/include/asm-powerpc/of_device.h
index 4f1aabe..e9af49e 100644
--- a/include/asm-powerpc/of_device.h
+++ b/include/asm-powerpc/of_device.h
@@ -32,6 +32,8 @@ extern int of_device_register(struct of_device *ofdev);
extern void of_device_unregister(struct of_device *ofdev);
extern void of_release_dev(struct device *dev);
+extern ssize_t of_device_get_modalias(struct of_device *ofdev,
+ char *str, ssize_t len);
extern int of_device_uevent(struct device *dev,
char **envp, int num_envp, char *buffer, int buffer_size);
--
1.5.1.2
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Segher Boessenkool @ 2007-05-06 13:26 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <20070506114429.5c631864@localhost.localdomain>
>> Since this node's children's interrupt representation
>> is different from the node's parent's, you need an
>> interrupt-map in here. You also forgot "#address-cells"
>> and I think you need "ranges" too?
>>
> Well, in fact it does not introduce SoC device different from any
> others
> represented inside soc885 node. mk_int_int_mask() is just special
> way of enabling irq for PCMCIA stuff, in addition to normal pic stuff.
I have no idea what you mean here. Care to try again?
> Emm. Why would I need #address-cells and ranges here? it uses parent
> bus address space...
"#address-cells" is 3 for pcmcia, so not the default
value (which is 2), so you need to put it in. The
value of this property is not inherited from the
parent node.
Absence of a "ranges" property means the child bus is
*not* direct mapped into the parent bus space. If the
mapping you need is 1-1, put in an empty "ranges"
property; if not, you have to put the correct mapping
in.
Segher
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Paul Sokolovsky @ 2007-05-06 13:20 UTC (permalink / raw)
To: Bodo Eggert, Anton Vorontsov; +Cc: linuxppc-dev, Robin Getz, linux-kernel
In-Reply-To: <E1Hkfia-0000cJ-18@be1.lrz>
Hello Bodo,
Sunday, May 6, 2007, 3:19:59 PM, you wrote:
> Robin Getz <rgetz@blackfin.uclinux.org> wrote:
>> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
>>> > that would be nice to put in the "right" place - I don't think that
>>> > drivers/char is the right place, nor drivers/misc - I also don't think
>>> > that /adc is a descriptive place for DAC or mixed signal front ends
>>> > (MxFE).
>>>
>>> What userspace interface do your drivers have?
>>
>> Right now, it is a little rudimentary char interface, it needs a little care
>> to be a bit more general purpose, but it suited needs of what the people who
>> were using it.
> [...]
>> I would be interested in having a detailed discussion/random thoughts on
>> this - what is the best way to expose these types of devices?
> Since you ask for random thoughts:
> IO of data streams from or to a DAC/ADC is essentially what soundcards do.
> I'm wondering if these cards are similar enough to use alsa, and if using
> that interface would ease or hinder programming the driver.
FYI, within handhelds.org kernel project, we also saw the need
for consistent ADC infrastructure, and developed such, based on
classdev concept, on todo to be submitted for review. Our
API/userspace interface however optimized for individual (or
fixed-batch) readings over stream operations, our target usage
are touchscreen, battery, hwmon drivers.
--
Best regards,
Paul mailto:pmiscml@gmail.com
^ permalink raw reply
* [PATCH] TurboStation support
From: Øyvind Repvik @ 2007-05-06 12:46 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
This patch adds support for the QNAP TurboStation TS-101 and TS-201 device=
s.=20
Signed-off-by: =D8yvind Repvik <nail@nslu2-linux.org>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
=2D-- linux-2.6.21.1/arch/powerpc/boot/dts/qnap-ts101.dts 1970-01-01=20
01:00:00.000000000 +0100
+++ linux-2.6.21.1.ts/arch/powerpc/boot/dts/qnap-ts101.dts 2007-05-03=20
22:44:59.000000000 +0200
@@ -0,0 +1,166 @@
+/*
+ * Device Tree Souce for QNAP Turbostation 101/201
+ *
+ * Choose CONFIG_TURBOSTATION to build a kernel for turbostation
+ *=20
+ *
+ * Based on sandpoint.dts
+ *
+ * 2006 (c) G. Liakhovetski <g.liakhovetski@gmx.de>
+ *
+ * This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * build with: "dtc -f -I dts -O dtb -o qnap-ts101.dtb -V 16 qnap-ts101.dt=
s"
+ *
+ *
+ */
+
+/ {
+ linux,phandle =3D <1000>;
+ model =3D "TurboStation TSx01";
+ compatible =3D "turbostation";
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+
+ cpus {
+ linux,phandle =3D <2000>;
+ #cpus =3D <1>;
+ #address-cells =3D <1>;
+ #size-cells =3D <0>;
+
+ PowerPC,603e { /* Really 8241 */
+ linux,phandle =3D <2100>;
+ device_type =3D "cpu";
+ reg =3D <0>;
+ clock-frequency =3D <fdad680>; /* 266 MHz */
+ timebase-frequency =3D <1fca055>; /* 33.3333333 MHz */
+ bus-frequency =3D <0>;
+ /* Following required by dtc but not used */
+ i-cache-line-size =3D <0>;
+ d-cache-line-size =3D <0>;
+ i-cache-size =3D <4000>;
+ d-cache-size =3D <4000>;
+ };
+ };
+
+ /* 64MB @ 0x0 */
+ memory {
+ linux,phandle =3D <3000>;
+ device_type =3D "memory";
+ reg =3D <00000000 04000000>;
+ };
+
+ flash@ff000000 {
+ linux,phandle =3D <3100>;
+ device_type =3D "rom";
+ compatible =3D "direct-mapped";
+ probe-type =3D "CFI";
+ reg =3D <ff000000 01000000>;
+ bank-width =3D <1>;
+ partitions =3D <
+ 00000000 00200000
+ 00200000 00d00000
+ 00f00000 00040001
+ 00f40000 00020000
+ 00f60000 00040000
+ 00fa0000 00020000
+ 00fc0000 00040000
+ >;
+ partition-names=20
=3D "kernel\0rootfs\0uboot1\0uboot1-env\0uboot2\0uboot2-env\0SysConf";
+ };
+
+
+ soc10x { /* AFAICT need to make soc for 8245's uarts to be defined */
+ linux,phandle =3D <4000>;
+ #address-cells =3D <1>;
+ #size-cells =3D <1>;
+ #interrupt-cells =3D <2>;
+ device_type =3D "soc";
+ compatible =3D "mpc10x";
+ store-gathering =3D <0>; /* 0 =3D=3D off, !0 =3D=3D on */
+ reg =3D <80000000 00100000>;
+ ranges =3D <80000000 80000000 70000000 /* pci mem space */
+ fc000000 fc000000 00100000 /* EUMB */
+ fe000000 fe000000 00c00000 /* pci i/o space */
+ fec00000 fec00000 00300000 /* pci cfg regs */
+ fef00000 fef00000 00100000>; /* pci iack */
+
+ i2c@fc003000 {
+ linux,phandle =3D <4300>;
+ device_type =3D "i2c";
+ compatible =3D "fsl-i2c";
+ reg =3D <fc003000 1000>;
+ interrupts =3D <5 2>;
+ interrupt-parent =3D <4400>;
+ };
+
+ serial@fc004500 {
+ linux,phandle =3D <4511>;
+ device_type =3D "serial";
+ compatible =3D "ns16550";
+ reg =3D <fc004500 8>;
+ clock-frequency =3D <7ed6b40>; /* 133 MHz */
+ current-speed =3D <1c200>; /* 115200 */
+ interrupts =3D <9 2>;
+ interrupt-parent =3D <4400>;
+ };
+
+ serial@fc004600 {
+ linux,phandle =3D <4512>;
+ device_type =3D "serial";
+ compatible =3D "ns16550";
+ reg =3D <fc004600 8>;
+ clock-frequency =3D <7ed6b40>;
+ current-speed =3D <4b00>; /* 19200 */
+ interrupts =3D <a 2>;
+ interrupt-parent =3D <4400>;
+ };
+
+ pic@fc040000 {
+ linux,phandle =3D <4400>;
+ #interrupt-cells =3D <2>;
+ #address-cells =3D <0>;
+ device_type =3D "open-pic";
+ compatible =3D "chrp,open-pic";
+ interrupt-controller;
+ reg =3D <fc040000 40000>;
+ built-in;
+ };
+
+ pci@fe800000 {
+ linux,phandle =3D <4500>;
+ #address-cells =3D <3>;
+ #size-cells =3D <2>;
+ #interrupt-cells =3D <1>;
+ device_type =3D "pci";
+ compatible =3D "mpc10x-pci";
+ reg =3D <fc000000 400000>;
+ ranges =3D <01000000 0 0 fe000000 0 00c00000
+ 02000000 0 80000000 80000000 0 70000000>;
+ bus-range =3D <0 ff>;
+ clock-frequency =3D <7ed6b40>; /* 133 MHz */
+ interrupt-parent =3D <4400>;
+ interrupt-map-mask =3D <f800 0 0 7>;
+ interrupt-map =3D <
+ /* IDSEL 0x13 - SATA*/
+ 6800 0 0 1 4400 0 1
+ 6800 0 0 2 4400 0 1
+ 6800 0 0 3 4400 0 1
+ 6800 0 0 4 4400 0 1
+ /* IDSEL 0x14 - USB */
+ 7000 0 0 1 4400 1 1
+ 7000 0 0 2 4400 1 1
+ 7000 0 0 3 4400 1 1
+ 7000 0 0 4 4400 1 1
+ /* IDSEL 0x15 - ETH */
+ 7800 0 0 1 4400 2 1
+ 7800 0 0 2 4400 2 1
+ 7800 0 0 3 4400 2 1
+ 7800 0 0 4 4400 2 1
+ >;
+ };
+ };
+};
Binary files linux-2.6.21.1/arch/powerpc/boot/dts/storcenter.dtb and=20
linux-2.6.21.1.ts/arch/powerpc/boot/dts/storcenter.dtb differ
=2D-- linux-2.6.21.1/arch/powerpc/platforms/embedded6xx/Kconfig 2007-04-27=
=20
23:49:26.000000000 +0200
+++ linux-2.6.21.1.ts/arch/powerpc/platforms/embedded6xx/Kconfig 2007-05-06=
=20
14:31:55.000000000 +0200
@@ -87,6 +87,13 @@
Linkstation-I HD-HLAN and HD-HGLAN versions, and PPC-based
Terastation systems should be supported too.
=20
+config TURBOSTATION
+ bool "QNap TS-101/TS-102 TurboStation"
+ select MPIC
+ select FSL_SOC
+ select PPC_UDBG_16550 if SERIAL_8250
+ select DEFAULT_UIMAGE
+
config MPC7448HPC2
bool "Freescale MPC7448HPC2(Taiga)"
select TSI108_BRIDGE
@@ -200,7 +207,7 @@
depends on SANDPOINT || SPRUCE || PPLUS || \
PRPMC750 || PRPMC800 || LOPEC || \
(EV64260 && !SERIAL_MPSC) || CHESTNUT || RADSTONE_PPC7D || \
=2D 83xx || LINKSTATION
+ 83xx || LINKSTATION || TURBOSTATION=20
default y
=20
config FORCE
@@ -274,13 +281,15 @@
=20
config MPC10X_BRIDGE
bool
=2D depends on POWERPMC250 || LOPEC || SANDPOINT || LINKSTATION
+ depends on POWERPMC250 || LOPEC || SANDPOINT || LINKSTATION || \
+ TURBOSTATION=20
select PPC_INDIRECT_PCI
default y
=20
config MPC10X_OPENPIC
bool
=2D depends on POWERPMC250 || LOPEC || SANDPOINT || LINKSTATION
+ depends on POWERPMC250 || LOPEC || SANDPOINT || LINKSTATION || \
+ TURBOSTATION=20
default y
=20
config MPC10X_STORE_GATHERING
=2D-- linux-2.6.21.1/arch/powerpc/platforms/embedded6xx/Makefile 2007-04-27=
=20
23:49:26.000000000 +0200
+++ linux-2.6.21.1.ts/arch/powerpc/platforms/embedded6xx/Makefile 2007-05-0=
6=20
14:30:58.000000000 +0200
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_MPC7448HPC2) +=3D mpc7448_hpc2.o
obj-$(CONFIG_LINKSTATION) +=3D linkstation.o ls_uart.o
+obj-$(CONFIG_TURBOSTATION) +=3D turbostation.o
=2D-- linux-2.6.21.1/arch/powerpc/platforms/embedded6xx/turbostation.c=09
1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.21.1.ts/arch/powerpc/platforms/embedded6xx/turbostation.c=09
2007-05-03 22:45:03.000000000 +0200
@@ -0,0 +1,141 @@
+/*
+ * Board setup routines for the QNAP Turbostation platform (TS-101/TS-201)
+ *
+ * Copyright (C) 2007 Oyvind Repvik (nail@nslu2-linux.org)
+ *
+ * Based on linkstation.c by G. Liakhovetski
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/initrd.h>
+#include <linux/mtd/physmap.h>
+
+#include <asm/time.h>
+#include <asm/prom.h>
+#include <asm/mpic.h>
+#include <asm/mpc10x.h>
+#include <asm/pci-bridge.h>
+
+static int __init add_bridge(struct device_node *dev)
+{
+ int len;
+ struct pci_controller *hose;
+ int *bus_range;
+
+ printk("Adding PCI host bridge %s\n", dev->full_name);
+
+ bus_range =3D (int *) get_property(dev, "bus-range", &len);
+ if (bus_range =3D=3D NULL || len < 2 * sizeof(int))
+ printk(KERN_WARNING "Can't get bus-range for %s, assume"
+ " bus 0\n", dev->full_name);
+
+ hose =3D pcibios_alloc_controller();
+ if (hose =3D=3D NULL)
+ return -ENOMEM;
+ hose->first_busno =3D bus_range ? bus_range[0] : 0;
+ hose->last_busno =3D bus_range ? bus_range[1] : 0xff;
+ hose->arch_data =3D dev;
+ setup_indirect_pci(hose, 0xfec00000, 0xfee00000);
+
+ /* Interpret the "ranges" property */
+ /* This also maps the I/O region and sets isa_io/mem_base */
+ pci_process_bridge_OF_ranges(hose, dev, 1);
+
+ return 0;
+}
+
+static void __init turbostation_setup_arch(void)
+{
+ struct device_node *np;
+
+ /* Lookup PCI host bridges */
+ for (np =3D NULL; (np =3D of_find_node_by_type(np, "pci")) !=3D NULL;)
+ add_bridge(np);
+
+ printk(KERN_INFO "QNAP Turbostation series\n");
+}
+
+/*
+ * Interrupt setup and service. Interrrupts on the turbostation come
+ * from the four PCI slots plus onboard 8241 devices: I2C, DUART.
+ */
+static void __init turbostation_init_IRQ(void)
+{
+ struct mpic *mpic;
+ struct device_node *dnp;
+ void *prop;
+ int size;
+ phys_addr_t paddr;
+
+ dnp =3D of_find_node_by_type(NULL, "open-pic");
+ if (dnp =3D=3D NULL)
+ return;
+
+ prop =3D (struct device_node *)get_property(dnp, "reg", &size);
+ paddr =3D (phys_addr_t)of_translate_address(dnp, prop);
+
+ mpic =3D mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC_WANTS_RESET,
+ 4, 32, " EPIC ");
+ BUG_ON(mpic =3D=3D NULL);
+
+ /* PCI IRQs */
+ mpic_assign_isu(mpic, 0, paddr + 0x10200);
+
+ /* I2C */
+ mpic_assign_isu(mpic, 1, paddr + 0x11000);
+
+ /* ttyS0, ttyS1 */
+ mpic_assign_isu(mpic, 2, paddr + 0x11100);
+
+ mpic_init(mpic);
+}
+
+static void turbostation_restart(char *cmd)
+{
+ /* Insert restart-stuff */
+}
+
+static void turbostation_power_off(void)
+{
+ /* Insert powerdown-stuff */
+}
+
+static void turbostation_halt(void)
+{
+ turbostation_power_off();
+}
+
+static void turbostation_show_cpuinfo(struct seq_file *m)
+{
+ seq_printf(m, "vendor\t\t: QNAP Systems Inc.\n");
+ seq_printf(m, "machine\t\t: Turbostation TS-101/TS-201\n");
+}
+
+static int __init turbostation_probe(void)
+{
+ unsigned long root;
+
+ root =3D of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "turbostation"))
+ return 0;
+ return 1;
+}
+
+define_machine(turbostation){
+ .name =3D "QNAP Turbostation",
+ .probe =3D turbostation_probe,
+ .setup_arch =3D turbostation_setup_arch,
+ .init_IRQ =3D turbostation_init_IRQ,
+ .show_cpuinfo =3D turbostation_show_cpuinfo,
+ .get_irq =3D mpic_get_irq,
+ .restart =3D turbostation_restart,
+ .power_off =3D turbostation_power_off,
+ .halt =3D turbostation_halt,
+ .calibrate_decr =3D generic_calibrate_decr,
+};
^ permalink raw reply
* Re: Correct location for ADC/DAC drivers
From: Bodo Eggert @ 2007-05-06 12:19 UTC (permalink / raw)
To: Robin Getz, Robert Schwebel, Stefan Roese, linuxppc-dev,
linux-kernel
In-Reply-To: <8heii-3GM-37@gated-at.bofh.it>
Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
>> > that would be nice to put in the "right" place - I don't think that
>> > drivers/char is the right place, nor drivers/misc - I also don't think
>> > that /adc is a descriptive place for DAC or mixed signal front ends
>> > (MxFE).
>>
>> What userspace interface do your drivers have?
>
> Right now, it is a little rudimentary char interface, it needs a little care
> to be a bit more general purpose, but it suited needs of what the people who
> were using it.
[...]
> I would be interested in having a detailed discussion/random thoughts on
> this - what is the best way to expose these types of devices?
Since you ask for random thoughts:
IO of data streams from or to a DAC/ADC is essentially what soundcards do.
I'm wondering if these cards are similar enough to use alsa, and if using
that interface would ease or hinder programming the driver.
--
Top 100 things you don't want the sysadmin to say:
76. I have never seen it do *that* before...
Friß, Spammer: BZmk0Kx63V@ld7M4m.7eggert.dyndns.org
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Vitaly Bordug @ 2007-05-06 9:48 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <20070506020427.GA22162@localhost.localdomain>
On Sun, 6 May 2007 12:04:27 +1000
David Gibson wrote:
> On Sun, May 06, 2007 at 03:04:14AM +0200, Segher Boessenkool wrote:
> > > + pcmcia@0080 {
> >
> > > + #interrupt-cells = <1>;
> >
> > > + interrupt-parent = <ff000000>;
> > > + interrupts = <d 1>;
> > > + };
> >
> > Since this node's children's interrupt representation
> > is different from the node's parent's, you need an
> > interrupt-map in here. You also forgot "#address-cells"
> > and I think you need "ranges" too?
>
> And we should use a reference, instead of an implicit phandle for the
> interrupt-parent.
>
I have one more patch for this - I think it makes sense to append it to the series...
Thinking it would be better to do the phandles->labels transition in one step for all the relevant
stuff in dts as well.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH v2 6/7] Holly DTS
From: David Gibson @ 2007-05-06 0:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <e1d22829fe3f12509018791541073706@kernel.crashing.org>
On Sat, May 05, 2007 at 07:21:33PM +0200, Segher Boessenkool wrote:
[snip]
> > + compatible = "ppc750-tsi";
>
> The needs to be more specific as well; "ibm,holly"
> or something.
Or perhaps just include something more specific, compatible can have
the general version as well.
[snip]
> > + chosen {
> > + linux,platform = <0>;
> > + linux,initrd-start = <0>;
> > + linux,initrd-end = <0>;
>
> Do you need to set those zero properties?
linux,platform is obsolete and should definitely go. With the recent
bootloader updates the initrd properties can also go (the bootloader
will add them correctly). I had them in the Ebony device tree until
very recently because until some of the recent flatdevtree.c fixes,
the bootloader could replace the value of the properties, but it
couldn't add new properties (or at least not properties with new
names).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Vitaly Bordug @ 2007-05-06 7:44 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <67c6bf6b7d37f5e133398ea83edeac78@kernel.crashing.org>
On Sun, 6 May 2007 03:04:14 +0200
Segher Boessenkool wrote:
> > + pcmcia@0080 {
>
> > + #interrupt-cells = <1>;
>
> > + interrupt-parent = <ff000000>;
> > + interrupts = <d 1>;
> > + };
>
> Since this node's children's interrupt representation
> is different from the node's parent's, you need an
> interrupt-map in here. You also forgot "#address-cells"
> and I think you need "ranges" too?
>
Well, in fact it does not introduce SoC device different from any others
represented inside soc885 node. mk_int_int_mask() is just special
way of enabling irq for PCMCIA stuff, in addition to normal pic stuff.
Emm. Why would I need #address-cells and ranges here? it uses parent bus address space...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Fix interrupt distribution in ppc970
From: Milton Miller @ 2007-05-06 6:52 UTC (permalink / raw)
To: mohan; +Cc: kexec, fastboot, ppcdev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20070503144721.GA28460@in.ibm.com>
On May 3, 2007, at 9:47 AM, Mohan Kumar M wrote:
> On Thu, Apr 26, 2007 at 09:42:50AM -0500, Milton Miller wrote:
>> Yes. The whole point of
>>> -static int get_irq_server(unsigned int virq)
>>> +static int get_irq_server(unsigned int virq, unsigned int
>>> strict_check)
>> was to factor out the common code in this function.
>
> Milton,
>
> How about this patch?
Getting closer, still not right.
>
> Index: linux-2.6.21.1/arch/powerpc/platforms/pseries/xics.c
> ===================================================================
> --- linux-2.6.21.1.orig/arch/powerpc/platforms/pseries/xics.c
> +++ linux-2.6.21.1/arch/powerpc/platforms/pseries/xics.c
> @@ -156,9 +156,9 @@ static inline void lpar_qirr_info(int n_
>
>
> #ifdef CONFIG_SMP
> -static int get_irq_server(unsigned int virq)
> +static int get_irq_server(unsigned int virq, unsigned int
> strict_check)
> {
> - unsigned int server;
> + int server;
> /* For the moment only implement delivery to all cpus or one cpu */
> cpumask_t cpumask = irq_desc[virq].affinity;
> cpumask_t tmp = CPU_MASK_NONE;
> @@ -166,22 +166,28 @@ static int get_irq_server(unsigned int v
> if (!distribute_irqs)
> return default_server;
>
> - if (cpus_equal(cpumask, CPU_MASK_ALL)) {
> - server = default_distrib_server;
> - } else {
> + if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
> cpus_and(tmp, cpu_online_map, cpumask);
>
> - if (cpus_empty(tmp))
> - server = default_distrib_server;
> + server = first_cpu(tmp);
> +
> + if (server < NR_CPUS)
> + return get_hard_smp_processor_id(server);
> + else {
> + if (strict_check)
> + return -1;
> + else
> + return default_distrib_server;
> + }
> + } else {
Take out the above 4 lines, so that the return always has cpu_online
vs cpu_present factored in, by falling through from specific mask to
default server selection.
> + if (cpus_equal(cpu_online_map, cpu_present_map))
> + return default_distrib_server;
> else
> - server = get_hard_smp_processor_id(first_cpu(tmp));
> + return default_server;
> }
[This matching brace will go and indent will change.]
> -
> - return server;
> -
> }
...
> @@ -398,8 +404,7 @@ static void xics_set_affinity(unsigned i
> unsigned int irq;
> int status;
> int xics_status[2];
> - unsigned long newmask;
> - cpumask_t tmp = CPU_MASK_NONE;
> + int irq_server;
>
> irq = (unsigned int)irq_map[virq].hwirq;
> if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
> @@ -413,18 +418,28 @@ static void xics_set_affinity(unsigned i
> return;
> }
>
> - /* For the moment only implement delivery to all cpus or one cpu */
> - if (cpus_equal(cpumask, CPU_MASK_ALL)) {
> - newmask = default_distrib_server;
> - } else {
> - cpus_and(tmp, cpu_online_map, cpumask);
> - if (cpus_empty(tmp))
> + /* Get current irq_server for the given irq */
> + irq_server = get_irq_server(irq, 1);
> + if (irq_server == -1) {
> + printk(KERN_ERR "xics_set_affinity: Invalid cpumask\n");
WARNING or NOTICE would be fine. The interrupt number should be
printed.
and maybe "No online cpus in <cpumask> for irq %d" would be better (I
think there is a print cpumask helper).
> + return;
> + }
> +
> + /* For the moment only implement delivery to all cpus or one cpu.
> + * Compare the irq_server with the new cpumask. If the irq_server
> + * is specified in cpumask, do the required rtas_call, otherwise
> + * return by printing an error message
> + */
> + if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
> + if (!cpu_isset(irq_server, cpumask)) {
> + printk(KERN_ERR "xics_set_affinity: Invalid "
> + "cpumask\n");
> return;
I don't understand what you are trying to do here. We already
chose the mask, and printed an error if we got -1 due to strict.
I think this can just be dropped?
> - newmask = get_hard_smp_processor_id(first_cpu(tmp));
> + }
> }
>
> status = rtas_call(ibm_set_xive, 3, 1, NULL,
> - irq, newmask, xics_status[1]);
> + irq, irq_server, xics_status[1]);
>
> if (status) {
> printk(KERN_ERR "xics_set_affinity: irq=%u ibm,set-xive "
milton
^ 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;
as well as URLs for NNTP newsgroup(s).