- 03 Jul, 2007 9 commits
-
-
Christoph Hellwig authored
spu_deactivate should never be called for nosched contets. Put in a check so we can print a stacktrace and exit early in case it happes erroneously. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Arnd Bergmann <arnd.bergmann@de.ibm.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Christoph Hellwig authored
Add a cpus_allowed allowed filed to struct spu_context so that we always use the cpu mask of the owning thread instead of the one happening to call into the scheduler. Also use this information in grab_runnable_context to avoid spurious wakeups. Signed-off-by:
-
Christoph Hellwig authored
Update scheduling information on every spu_run to allow for setting threads to realtime priority just before running them. This requires some slightly ugly code in spufs_run_spu because we can just update the information unlocked if the spu is not runnable, but we need to acquire the active_mutex when it is runnable to protect against find_victim. This locking scheme requires opencoding spu_acquire_runnable in spufs_run_spu which actually is a nice cleanup all by itself. Signed-off-by:
-
Jeremy Kerr authored
Print out a few scheduler tuning parameters when we've compiled with DEBUG defined. Signed-off-by:
-
Jeremy Kerr authored
The current timeslice code mixes 'jiffies' up with 'spesched ticks'. This change correctly defines the number of time slices each SPE contexts is given, and clarifies the comment. This brings the default timeslice for SPE contexts into a reasonable range. Signed-off-by:
-
Christoph Hellwig authored
Enable preemptive scheduling for non-RT contexts. We use the same algorithms as the CPU scheduler to calculate the time slice length, and for now we also use the same timeslice length as the CPU scheduler. This might be not enough for good performance and can be changed after some benchmarking. Note that currently we do not boost the priority for contexts waiting on the runqueue for a long time, so contexts with a higher nice value could starve ones with less priority. This could easily be fixed once the rework of the spu lists that Luke and I discussed is done. Signed-off-by:
-
Christoph Hellwig authored
Get rid of the scheduler workqueues that complicated things a lot to a dedicated spu scheduler thread that gets woken by a traditional scheduler tick. By default this scheduler tick runs a HZ * 10, aka one spu scheduler tick for every 10 cpu ticks. Currently the tick is not disabled when we have less context than available spus, but I will implement this later. Signed-off-by:
-
Sebastian Siewior authored
Add a bit define from book, and replace one hex number with a symbol, for clarity. Signed-off-by:
Sebastian Siewior <bigeasy@linux.vnet.ibm.com> Signed-off-by:
-
Sebastian Siewior authored
Currently it fails with gcc from sdk 2.1 because of a spec change [1]. Maybe we should start using the definitions from spu_mfcio.h. [1] http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01598.htmlSigned-off-by:
-
- 29 Jun, 2007 30 commits
-
-
Kumar Gala authored
Signed-off-by:Kumar Gala <galak@kernel.crashing.org>
-
Kumar Gala authored
Use the ppc64 style list management and allocation functions for pci_controllers. This makes the pci_controller structs just a bit more common between ppc32 & ppc64. Signed-off-by: -
Kumar Gala authored
Moved the low hanging fruit that was either identical or close to it between ppc32 & ppc64 for PCI into pci-common.c Signed-off-by: -
Kumar Gala authored
In the places we can move to using pci_bus_to_host, this allows us to make pci_bus_to_host static and remove its export. Signed-off-by: -
Kumar Gala authored
Make the ppc32 pcibios_alloc_controller take a device node to match the ppc64 prototypes and have it set arch_data. Signed-off-by: -
Kumar Gala authored
Make the pci_controller struct use global_number for the PHB domain number instead of index to match what ppc64 does and reuse its pci_domain_nr code. Introduced a pci-common.c to handle shared code between ppc32 & ppc64. Signed-off-by: -
Kumar Gala authored
There are no in kernel users of any off these functions and some of them were not even EXPORT_SYMBOL: - pci_bus_io_base() - pci_bus_io_base_phys() - pci_bus_mem_base_phys() - pci_resource_to_bus() - phys_to_bus() - pci_phys_to_bus() - pci_bus_to_phys() - pci_init_resource() - resource_fixup() Signed-off-by: -
Kumar Gala authored
We never actually read local_number so lets just remove it. Signed-off-by: -
Kumar Gala authored
Moved bits need for ppc32 from asm-ppc/pci-bridge.h into asm-powerpc/pci-bridge.h. Removed ARCH=powerpc specific bits (and comments related to ARCH=ppc) from asm-ppc/pci-bridge.h as its only used on ARCH=ppc. Signed-off-by: -
Zhang Wei authored
The Freescale PCI-e RC poses as a transparent bridge, but does not implement the IO_BASE or IO_LIMIT registers in the config space. This means that the code which initializes the bridge resources ends up setting the IO resources erroneously. Add quick_fsl_pcie_transparent() to handle this. This change sets RC of mpc8641 to be a transparent bridge for legacy I/O access and initializes the RC bridge resources from the device tree. Signed-off-by:
Zhang Wei <wei.zhang@freescale.com> Signed-off-by:
Andy Fleming <afleming@freescale.com> Signed-off-by:
Jon Loeliger <jdl@freescale.com> Signed-off-by:
-
York Sun authored
In pcibios_fixup_bus(), bridges that are subordinate to transparent bridges were still relocating their IORESOURCE_IO and IO_RESOURCE_MEM start and end values. Fix this by preventing the transparent bridge from relocating the start and end values, thus allowing the subordinate non-transparent bridge full molestation rights. Signed-off-by:
York Sun <yorksun@freescale.com> Signed-off-by:
-
Zhang Wei authored
Set IDE in ULI1575 to not 100% native mode, which forces the IDE driver to probe the irq itself. Signed-off-by:
-
Kumar Gala authored
The Freescale PCI-e controllers have an issue in that they use the PCI_PRIMARY_BUS register in the virtual P2P bridge to determine which bus number to match on when generating a type 0 config cycle. The issue is if we are renumbering bus numbers to match Linux we will try setting the PCI_PRIMARY_BUS and will not know which bus number to use for generating type 0 config cycles. We surpress writing the register in the P2P bridge and always keep it at zero. In the future when proper PCI domain support is working we should be able to remove this. Signed-off-by: -
Zhang Wei authored
We check the Link Training and State Status register to make sure we are at least at the L0 state. Signed-off-by:
Roy Zang <tie-fei.zang@freescale.com> Signed-off-by:
-
Kumar Gala authored
The generic PCI config ops indirect support for ppc32 covers only two cases (implicit vs explicit) type 0/1 config cycles via set_cfg_type. Added a indirect_type bit mask to handle other variants. Added support for PCI-e extended registers and moved the cfg_type handling into the bit mask for ARCH=powerpc. We can also use this to handle indirect quirks. Signed-off-by: -
Wade Farnsworth authored
This adds device nodes for the PCI bridges as well as the ISA devices on the newer revision MPC8641HPCN. It also adds the PCI ranges to the soc node so that address translation for the ISA devices works properly. Signed-off-by:
Wade Farnsworth <wfarnsworth@mvista.com> Signed-off-by:
-
Zhang Wei authored
Remove errata for PCI-e support of Rev 1.0 of MPC8641 since its considered obselete and is not production level silicon from Freescale. Signed-off-by:
-
Kumar Gala authored
Removed the remants of bus_offset and use self_busno in the mv64x60 case and use pci_assign_all_buses on 83xx/85xx. 83xx/85xx have multiple PHBs and the firmwares on these devices tend not to handle topologies with P2P bridges well so we let Linux just reassign the bus numbers to match. Signed-off-by: -
Kumar Gala authored
Added self_busno to pci_controller and indirect PCI ops to be set by board code to indicate which bus number to use when talking to the PHB. By default we use zero since the majority of controllers that have implicit mechanisms to talk to the PHBs use a bus number of zero. Signed-off-by: -
Kumar Gala authored
The user of the fsl_pcie code doesn't set bus_offset and 82xx doesn't require it either. Remove the places in the code that reference it so we can remove it all together. Signed-off-by: -
Kumar Gala authored
Now that we have the pci_controller in the exclude function we can easy figure out if the bus number is the PHB or not. The old style of using a variable setup at init time was actually broken and would only work in specific cases. Signed-off-by: -
Kumar Gala authored
There are times that we need to know which controller we are on to decide how to exclude devices properly. We now pass the pci_controller that we are going to use down to the pci_exclude_device function. This will greatly simplify being able to exclude the PHBs in multiple controller setups. Signed-off-by: -
Kumar Gala authored
The hose->bus_offset is only used for PCI config cycles and the 52xx PCI config code doesn't actually ever set bus_offset to a non-zero value. Signed-off-by: -
Kumar Gala authored
The Freescale and Marvell PCI controllers dont require explicit setting for type 1 config cycles. They handle producing them by implicitly looking at the bus, devfn. The TSI108 and 52xx don't use the generic PCI indirect code and thus don't bother with set_cfg_type. Signed-off-by: -
Arnd Bergmann authored
The TSI108 code and the 32 bit powermac and chrp platforms have dependency on PCI that is not easy or desirable to get rid of. The easiest fix is to always select CONFIG_PCI if one of those platforms is enabled. Signed-off-by:Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Some code looks can be configured to be built without PCI support, but does not work properly. Signed-off-by: -
Arnd Bergmann authored
When CONFIG_PCI is disabled, the definitions for isa_io_base, isa_mem_base and pci_dram_offset are entirely unused, but they can result in link failure because they are defined in multiple places. The easiest fix is to just remove all these definitions. Signed-off-by: -
Arnd Bergmann authored
needed for 6xx allyesconfig Signed-off-by: -
Arnd Bergmann authored
Many platforms currently define their own add_bridge function, some of them globally. This breaks some multiplatform configurations. Prefixing each of these functions with the platform name avoids this problem. Signed-off-by: -
Arnd Bergmann authored
The cores used in the MPC82xx/83xx/86xx embedded controllers are very similar to those in the 32 bit general-purpose processors, so it makes sense to treat them as the same CPU family. Choosing between the embedded platforms and the multiplatform code is now done in the platform menu, but functionally everything stays the same. Signed-off-by:
-
- 28 Jun, 2007 1 commit
-
-
David Gibson authored
A strict reading of the flattened device tree format defined in booting-without-of.txt does in fact require that all the tags defining properties for a node go before any definitions of subnodes, however it's not particularly emphasised. Although allowing intermingled properties and subnodes would not be ambiguous in meaning, the kernel parser does currently require that properties precede subnodes. Furthermore, keeping this constraint makes life easier for various device tree scanning tools. Therefore, re-emphasise in booting-without-of.txt that this is a strict requirement of the flattened device tree format. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
