hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
linux-sg2042/arch/mips/pci/fixup-sb1250.c

44 lines
1.2 KiB
C
Raw Normal View History

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-17 06:20:36 +08:00
/*
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
* Copyright (C) 2004, 2006 MIPS Technologies, Inc. All rights reserved.
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-17 06:20:36 +08:00
* Author: Maciej W. Rozycki <macro@mips.com>
*
* 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 of the License, or (at your option) any later version.
*/
#include <linux/init.h>
#include <linux/pci.h>
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
/*
Fix occurrences of "the the " Signed-off-by: Michael Opdenacker <michael@free-electrons.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-05-09 14:57:56 +08:00
* Set the BCM1250, etc. PCI host bridge's TRDY timeout
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
* to the finite max.
*/
MIPS: PCI: Move fixups from __init to __devinit. Fixups are executed once the pci-device is found which is during boot process so __init seems fine as long as the platform does not support hotplug. However it is possible to remove the PCI bus at run time and have it rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call the fixups again. [ralf@linux-mips.org: Made piixirqmap[] in malta_piix_func0_fixup() __initdata.] Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Cc: linux-mips@linux-mips.org Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2012-07-19 13:13:54 +08:00
static void __devinit quirk_sb1250_pci(struct pci_dev *dev)
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
{
pci_write_config_byte(dev, 0x40, 0xff);
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_PCI,
quirk_sb1250_pci);
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-17 06:20:36 +08:00
/*
* The BCM1250, etc. PCI/HT bridge reports as a host bridge.
*/
MIPS: PCI: Move fixups from __init to __devinit. Fixups are executed once the pci-device is found which is during boot process so __init seems fine as long as the platform does not support hotplug. However it is possible to remove the PCI bus at run time and have it rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call the fixups again. [ralf@linux-mips.org: Made piixirqmap[] in malta_piix_func0_fixup() __initdata.] Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Cc: linux-mips@linux-mips.org Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2012-07-19 13:13:54 +08:00
static void __devinit quirk_sb1250_ht(struct pci_dev *dev)
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-17 06:20:36 +08:00
{
dev->class = PCI_CLASS_BRIDGE_PCI << 8;
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIBYTE, PCI_DEVICE_ID_BCM1250_HT,
quirk_sb1250_ht);
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
/*
Fix occurrences of "the the " Signed-off-by: Michael Opdenacker <michael@free-electrons.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-05-09 14:57:56 +08:00
* Set the SP1011 HT/PCI bridge's TRDY timeout to the finite max.
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
*/
MIPS: PCI: Move fixups from __init to __devinit. Fixups are executed once the pci-device is found which is during boot process so __init seems fine as long as the platform does not support hotplug. However it is possible to remove the PCI bus at run time and have it rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call the fixups again. [ralf@linux-mips.org: Made piixirqmap[] in malta_piix_func0_fixup() __initdata.] Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Cc: linux-mips@linux-mips.org Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2012-07-19 13:13:54 +08:00
static void __devinit quirk_sp1011(struct pci_dev *dev)
[MIPS] BCM1250: TRDY timeout tweaks for Broadcom SiByte systems It was obesrved that at least one older PCI card predating the requirement for the TRDY signal to respond within 16 clock ticks actually does not meet this rule nor even the power-on defaults of the PCI bridges found in development systems built around the Broadcom SiByte SOCs. Here is a patch that bumps up the timeout to the highest finite value supported by these chips, which is 255 clock ticks. The bridges affected are the SiByte SOC itself and the SP1011. This change does not effectively affect systems only having PCI option cards installed that meet the TRDY requirement of the current PCI spec. The rule was introduced with PCI 2.1, so any older card may make the system affected. If this is the case, performance of the system will suffer in return for the card working at all. If this is a concern, then the solution is not to use such cards. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> ---
2006-10-02 19:55:09 +08:00
{
pci_write_config_byte(dev, 0x64, 0xff);
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SIPACKETS, PCI_DEVICE_ID_SP1011,
quirk_sp1011);