/* * IDE tuning and bus mastering support for the CS5510/CS5520 * chipsets * * The CS5510/CS5520 are slightly unusual devices. Unlike the * typical IDE controllers they do bus mastering with the drive in * PIO mode and smarter silicon. * * The practical upshot of this is that we must always tune the * drive for the right PIO mode. We must also ignore all the blacklists * and the drive bus mastering DMA information. * * *** This driver is strictly experimental *** * * (c) Copyright Red Hat Inc 2002 * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation; either version 2, or (at your option) any * later version. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * For the avoidance of doubt the "preferred form" of this code is one which * is in an open non patent encumbered format. Where cryptographic key signing * forms part of the process of creating an executable the information * including keys needed to generate an equivalently functional executable * are deemed to be part of the source code. * */ #include #include #include #include #include #include #include #define DRV_NAME "cs5520" struct pio_clocks { int address; int assert; int recovery; }; static struct pio_clocks cs5520_pio_clocks[]={ {3, 6, 11}, {2, 5, 6}, {1, 4, 3}, {1, 3, 2}, {1, 2, 1} }; static void cs5520_set_pio_mode(ide_hwif_t *hwif, ide_drive_t *drive) { struct pci_dev *pdev = to_pci_dev(hwif->dev); int controller = drive->dn > 1 ? 1 : 0; const u8 pio = drive->pio_mode - XFER_PIO_0; /* 8bit CAT/CRT - 8bit command timing for channel */ pci_write_config_byte(pdev, 0x62 + controller, (cs5520_pio_clocks[pio].recovery << 4) | (cs5520_pio_clocks[pio].assert)); /* 0x64 - 16bit Primary, 0x68 - 16bit Secondary */ /* FIXME: should these use address ? */ /* Data read timing */ pci_write_config_byte(pdev, 0x64 + 4*controller + (drive->dn&1), (cs5520_pio_clocks[pio].recovery << 4) | (cs5520_pio_clocks[pio].assert)); /* Write command timing */ pci_write_config_byte(pdev, 0x66 + 4*controller + (drive->dn&1), (cs5520_pio_clocks[pio].recovery << 4) | (cs5520_pio_clocks[pio].assert)); } static void cs5520_set_dma_mode(ide_hwif_t *hwif, ide_drive_t *drive) { printk(KERN_ERR "cs55x0: bad ide timing.\n"); drive->pio_mode = XFER_PIO_0 + 0; cs5520_set_pio_mode(hwif, drive); } static const struct ide_port_ops cs5520_port_ops = { .set_pio_mode = cs5520_set_pio_mode, .set_dma_mode = cs5520_set_dma_mode, }; static const struct ide_port_info cyrix_chipset __devinitdata = { .name = DRV_NAME, .enablebits = { { 0x60, 0x01, 0x01 }, { 0x60, 0x02, 0x02 } }, .port_ops = &cs5520_port_ops, .host_flags = IDE_HFLAG_ISA_PORTS | IDE_HFLAG_CS5520, .pio_mask = ATA_PIO4, }; /* * The 5510/5520 are a bit weird. They don't quite set up the way * the PCI helper layer expects so we must do much of the set up * work longhand. */ static int __devinit cs5520_init_one(struct pci_dev *dev, const struct pci_device_id *id) { const struct ide_port_info *d = &cyrix_chipset; struct ide_hw hw[2], *hws[] = { NULL, NULL }; ide_setup_pci_noise(dev, d); /* We must not grab the entire device, it has 'ISA' space in its * BARS too and we will freak out other bits of the kernel */ if (pci_enable_device_io(dev)) { printk(KERN_WARNING "%s: Unable to enable 55x0.\n", d->name); return -ENODEV; } pci_set_master(dev); if (pci_set_dma_mask(dev, DMA_BIT_MASK(32))) { printk(KERN_WARNING "%s: No suitable DMA available.\n", d->name); return -ENODEV; } /* * Now the chipset is configured we can let the core * do all the device setup for us */ ide_pci_setup_ports(dev, d, &hw[0], &hws[0]); hw[0].irq = 14; hw[1].irq = 15; return ide_host_add(d, hws, 2, NULL); } static const struct pci_device_id cs5520_pci_tbl[] = { { PCI_VDEVICE(CYRIX, PCI_DEVICE_ID_CYRIX_5510), 0 }, { PCI_VDEVICE(CYRIX, PCI_DEVICE_ID_CYRIX_5520), 1 }, { 0, }, }; MODULE_DEVICE_TABLE(pci, cs5520_pci_tbl); static struct pci_driver cs5520_pci_driver = { .name = "Cyrix_IDE", .id_table = cs5520_pci_tbl, .probe = cs5520_init_one, .suspend = ide_pci_suspend, .resume = ide_pci_resume, }; static int __init cs5520_ide_init(void) { return ide_pci_register_driver(&cs5520_pci_driver); } module_init(cs5520_ide_init); MODULE_AUTHOR("Alan Cox"); MODULE_DESCRIPTION("PCI driver module for Cyrix 5510/5520 IDE"); MODULE_LICENSE("GPL"); x-arm.git/commit/arch/ia64/kernel/acpi.c?h=mcbin'>commitdiff
path: root/arch/ia64/kernel/acpi.c
AgeCommit message (Collapse)Author
2010-03-14ACPI: processor: driver doesn't need to evaluate _PDCAlex Chiang
Now that the early _PDC evaluation path knows how to correctly evaluate _PDC on only physically present processors, there's no need for the processor driver to evaluate it later when it loads. To cover the hotplug case, push _PDC evaluation down into the hotplug paths. Cc: x86@kernel.org Cc: Tony Luck <tony.luck@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-03Merge branch 'x86-apic-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-apic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (25 commits) x86: Fix out of order of gsi x86: apic: Fix mismerge, add arch_probe_nr_irqs() again x86, irq: Keep chip_data in create_irq_nr and destroy_irq xen: Remove unnecessary arch specific xen irq functions. smp: Use nr_cpus= to set nr_cpu_ids early x86, irq: Remove arch_probe_nr_irqs sparseirq: Use radix_tree instead of ptrs array sparseirq: Change irq_desc_ptrs to static init: Move radix_tree_init() early irq: Remove unnecessary bootmem code x86: Add iMac9,1 to pci_reboot_dmi_table x86: Convert i8259_lock to raw_spinlock x86: Convert nmi_lock to raw_spinlock x86: Convert ioapic_lock and vector_lock to raw_spinlock x86: Avoid race condition in pci_enable_msix() x86: Fix SCI on IOAPIC != 0 x86, ia32_aout: do not kill argument mapping x86, irq: Move __setup_vector_irq() before the first irq enable in cpu online path x86, irq: Update the vector domain for legacy irqs handled by io-apic x86, irq: Don't block IRQ0_VECTOR..IRQ15_VECTOR's on all cpu's ...
2010-02-25[IA64] Only build arch/ia64/kernel/acpi.o when CONFIG_ACPIAlex Chiang
The following commit broke the ia64 sim_defconfig build: 3b2b84c0b81108a9a869a88bf2beeb5a95d81dd1 ACPI: processor: driver doesn't need to evaluate _PDC This is because it added: +#include <acpi/processor.h> To arch/ia64/kernel/acpi.c. Unfortunately, the ia64_simdefconfig does not turn on CONFIG_ACPI, and we get build errors. The fix described in $subject seems to be the most sensible way to untangle the mess. The other issue is that acpi_get_sysname() is required for all configs, most of which define CONFIG_ACPI, but are not CONFIG_IA64_GENERIC. Turn it into an inline to cover the "non generic" ia64 configs; to prevent a duplicate definition build error, we need to wrap the definition in acpi.o inside an #ifdef. Finally, move the pm_idle and pm_power_off exports into process.c (which is always built), similar to other architectures, and allow the sim defconfig to link. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2010-02-17smp: Use nr_cpus= to set nr_cpu_ids earlyYinghai Lu
On x86, before prefill_possible_map(), nr_cpu_ids will be NR_CPUS aka CONFIG_NR_CPUS. Add nr_cpus= to set nr_cpu_ids. so we can simulate cpus <=8 are installed on normal config. -v2: accordging to Christoph, acpi_numa_init should use nr_cpu_ids in stead of NR_CPUS. -v3: add doc in kernel-parameters.txt according to Andrew. Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <1265793639-15071-34-git-send-email-yinghai@kernel.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Tony Luck <tony.luck@intel.com>
2009-10-02ia64: initialize cpu maps earlyTejun Heo
All information necessary to initialize cpu possible and present maps are available once early_acpi_boot_init() is complete. Reorganize setup_arch() and acpi init functions such that, * CPU information is printed after LAPIC entries are parsed in early_acpi_boot_init(). * smp_build_cpu_map() is called by setup_arch() instead of acpi functions. * smp_build_cpu_map() is called once all CPU related information is available before memory is initialized. This is primarily to allow find_memory() to use cpu maps but is also a general cleanup. Please note that with this change, the somewhat ad-hoc early_cpu_possible_map defined and used for NUMA configurations is probably unnecessary. Something to clean up another day. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64 <linux-ia64@vger.kernel.org>
2009-04-28irq: change ACPI GSI APIs to also take a device argumentYinghai Lu
We want to use dev_to_node() later on, to be aware of the 'home node' of the GSI in question. [ Impact: cleanup, prepare the IRQ code to be more NUMA aware ] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Len Brown <lenb@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Len Brown <lenb@kernel.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-acpi@vger.kernel.org Cc: linux-ia64@vger.kernel.org LKML-Reference: <49F65560.20904@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-31Pull cpumask into release branchTony Luck
2009-03-16cpumask: Use accessors code.: ia64Rusty Russell
Impact: use new API Use the accessors rather than frobbing bits directly. Most of this is in arch code I haven't even compiled, but is straightforward. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com>
2009-03-16cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: ia64Rusty Russell
Impact: cleanup, futureproof In fact, all cpumask ops will only be valid (in general) for bit numbers < nr_cpu_ids. So use that instead of NR_CPUS in various places. This is always safe: no cpu number can be >= nr_cpu_ids, and nr_cpu_ids is initialized to NR_CPUS at boot. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Acked-by: Ingo Molnar <mingo@elte.hu>
2009-02-16[IA64] fix __apci_unmap_tableYinghai Lu
Impact: fix build error to fix: tip/arch/ia64/kernel/acpi.c:203: error: conflicting types for '__acpi_unmap_table' tip/include/linux/acpi.h:82: error: previous declaration of '__acpi_unmap_table' was here tip/arch/ia64/kernel/acpi.c:203: error: conflicting types for '__acpi_unmap_table' tip/include/linux/acpi.h:82: error: previous declaration of '__acpi_unmap_table' was here Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-02-09acpi/x86: introduce __apci_map_table, v4Yinghai Lu
to prevent wrongly overwriting fixmap that still want to use. ACPI used to rely on low mappings being all linearly mapped and grew a habit: it never really unmapped certain kinds of tables after use. This can cause problems - for example the hypothetical case when some spurious access still references it. v2: remove prev_map and prev_size in __apci_map_table v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to early_acpi_os_unmap_memory v4: fix typo in one acpi_get_table_with_size calling Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-01-09Merge branch 'linus' into releaseLen Brown
2009-01-09ACPI : Use RSDT instead of XSDT by adding boot option of "acpi=rsdt"Zhao Yakui
On some boxes there exist both RSDT and XSDT table. But unfortunately sometimes there exists the following error when XSDT table is used: a. 32/64X address mismatch b. The 32/64X FACS address mismatch In such case the boot option of "acpi=rsdt" is provided so that RSDT is tried instead of XSDT table when the system can't work well. http://bugzilla.kernel.org/show_bug.cgi?id=8246 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> cc:Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-01cpumask: Remove IA64 definition of total_cpus now it's in core codeRusty Russell
Impact: fix IA64 compile Fortunately, they have exactly the same semantics. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2008-12-26cpumask: IA64: Introduce cpumask_of_{node,pcibus} to replace ↵Rusty Russell
{node,pcibus}_to_cpumask Impact: New APIs The old node_to_cpumask/node_to_pcibus returned a cpumask_t: these return a pointer to a struct cpumask. Part of removing cpumasks from the stack. We can also use the new for_each_cpu_and() to avoid a temporary cpumask, and a gratuitous test in sn_topology_show. (Includes fix from KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Tony Luck <tony.luck@intel.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
2008-11-06[IA64] fix boot panic caused by offline CPUsDoug Chapman
This fixes a regression introduced by 2c6e6db41f01b6b4eb98809350827c9678996698 "Minimize per_cpu reservations." That patch incorrectly used information about what CPUs are possible that was not yet initialized by ACPI. The end result was that per_cpu structures for offline CPUs were not initialized causing a NULL pointer reference. Since we cannot do the full acpi_boot_init() call any earlier, the simplest fix is to just parse the MADT for SAPIC entries early to find the CPU info. This should also allow for some cleanup of the code added by the "Minimize per_cpu reservations". This patch just fixes the regressions, the cleanup will come in a later patch. Signed-off-by: Doug Chapman <doug.chapman@hp.com> Signed-off-by: Alex Chiang <achiang@hp.com> CC: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-10-17Pull vtd-iommu into release branchTony Luck
Conflicts: arch/ia64/kernel/acpi.c
2008-10-17[IA64] Add Variable Page Size and IA64 Support in Intel IOMMUFenghua Yu
The patch contains Intel IOMMU IA64 specific code. It defines new machvec dig_vtd, hooks for IOMMU, DMAR table detection, cache line flush function, etc. For a generic kernel with CONFIG_DMAR=y, if Intel IOMMU is detected, dig_vtd is used for machinve vector. Otherwise, kernel falls back to dig machine vector. Kernel parameter "machvec=dig" or "intel_iommu=off" can be used to force kernel to boot dig machine vector. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-10-17ia64/xen: define xen machine vector for domU.Isaku Yamahata
define xen machine vector for domU. Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-07-17[IA64] Avoid overflowing ia64_cpu_to_sapicid in acpi_map_lsapic()Alex Chiang
acpi_map_lsapic tries to stuff a long into ia64_cpu_to_sapicid[], which can only hold ints, so let's fix that. We need to update the signature of acpi_map_cpu2node() too. Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-06-11ACPI: handle invalid ACPI SLIT tableFenghua Yu
This is a SLIT sanity checking patch. It moves slit_valid() function to generic ACPI code and does sanity checking for both x86 and ia64. It sets up node_distance with LOCAL_DISTANCE and REMOTE_DISTANCE when hitting invalid SLIT table on ia64. It also cleans up unused variable localities in acpi_parse_slit() on x86. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2008-05-14[IA64] Properly unregister legacy interruptsPrarit Bhargava
acpi_unregister_gsi() should "undo" what acpi_register_gsi() does. On systems that have legacy interrupts, acpi_unregister_gsi erroneously calls iosapci_unregister_intr() which is wrong to do and causes a loud warning. acpi_unregister_gsi() should just return in these cases. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-05-14[IA64] machvec support for SGI UV platformJack Steiner
This patch adds the basic IA64 machvec infrastructure to support the SGI "UV" platform. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-04-30[IA64] fix section mismatch in arch/ia64/kernel/acpi.cHidetoshi Seto
This patch kills: WARNING: vmlinux.o(.text+0x1702): Section mismatch in reference from the function acpi_register_ioapic() to the function .devinit.text:iosapic_init() Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>