Commit Graph

7 Commits

Author SHA1 Message Date
Vitaly Bordug
2ca2d5e84c [PATCH] ppc32: board-specific part of fs_enet update
This contains board-specific portion to respect driver changes (for 8272ads ,
885ads and 866ads).  Altered platform_data structures as well as initial setup
routines relevant to fs_enet.

Changes to the mpc8560ads ppc/ code are also introduced, but mainly as
reference, since the entire board support is going to appear in arch/powerpc.

Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-08-19 17:44:31 -04:00
David Woodhouse
62c4f0a2d5 Don't include linux/config.h from anywhere else in include/
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-26 12:56:16 +01:00
Vitaly Bordug
75288c78c6 [PATCH] ppc32: Make platform devices being able to assign functions
Implemented by  modification of the .name field of the platform device,
when PDs with the
same names are to be used within different drivers, as
<device_name> -> <device_name>:<function>
Corresponding drivers should change the .name in struct device_driver to
reflect upper of course.

Added ppc_sys_device_disable/enable function set, making it easier to
disable all the inexistent/not utilized platform device way pdevs. By the
check of the "disabled" bit in the config field of ppc_sys_specs, disabled
platform devices will be either added/removed from the bus, or simply not
registered on it, depending on the time when disable/enable call asserted.

The default behaviour when nothing is disabled/enabled will be "all devices
are enabled", which is the same as before.

Also helper platform_notify_map function added, making assignment of
board-specific platform_info more consistent and generic.

Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-10 16:52:46 +11:00
Vitaly Bordug
1461b4ea2b [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
This patch fixes a numbers of issues regarding to that both 8xx and 82xx
began to use ppc_sys model:
	- Platform is now identified by default deviceless SOC, if no
BOARD_CHIP_NAME is specified in the bard-specific header. For the list
of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and
mpc82xx_sys.c for 8xx and 82xx respectively.
	- Fixed a bug in identification by name - if the name was not found,
it returned -1 instead of default deviceless ppc_spec.
	- fixed devices amount in the 8xx platform system descriptions

Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-29 14:49:29 +10:00
Kumar Gala
8e8fff0975 [PATCH] ppc32: Add ppc_sys descriptions for PowerQUICC II devices
Added ppc_sys device and system definitions for PowerQUICC II devices.
This will allow drivers for PQ2 to be proper platform device drivers.
Which can be shared on PQ3 processors with the same peripherals.

Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:05:56 -07:00
Vitaly Bordug
a6dbba77a9 [PATCH] ppc32: Support for 82xx PQII on-chip PCI bridge
This patch adds on-chip PCI bridge support for the PQ2 family.  The
incomplete existent code is updated with interrupt handling stuff and
board-specific bits for 8272ADS and PQ2FADS; the related files were renamed
(from m8260_pci to m82xx_pci) to be of more generic fashion.  This is
tested with 8266ADS and 8272ADS, should work on PQ2FADS as well.

Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-28 16:46:15 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00