Age | Commit message (Collapse) | Author | Files | Lines |
|
x86_of_pci_init() does two things:
- it provides a generic irq enable and disable function. enable queries
the device tree for the interrupt information, calls ->xlate on the
irq host and updates the pci->irq information for the device.
- it walks through PCI bus(es) in the device tree and adds its children
(device) nodes to appropriate pci_dev nodes in kernel. So the dtb
node information is available at probe time of the PCI device.
Adding a PCI bus based on the information in the device tree is
currently not supported. Right now direct access via ioports is used.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Tested-by: Dirk Brandewie <[email protected]>
Acked-by: Grant Likely <[email protected]>
Cc: [email protected]
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Set hpet_address based on information provied form DTB
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Grant Likely <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Dirk Brandewie <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
APIC and IO_APIC have to be added to the system early because
native_init_IRQ() requires it.
In order to obtain the address of the ioapic the device tree has to be
unflattened so of_address_to_resource() works.
The device tree is relocated to ensure it is always covered by the
kernel mapping. That way the boot loader does not have to make
any assumptions about kernel's memory layout.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Grant Likely <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Dirk Brandewie <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
The here introduced irq_domain abstraction represents a generic irq
controller. It is a subset of powerpc's irq_host which is going to be
renamed to irq_domain and then become generic. This implementation will
be removed once it is generic.
The xlate callback is resposible to parse irq informations like irq type
and number and returns the hardware irq number which is reported by the
hardware as active.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Tested-by: Dirk Brandewie <[email protected]>
Acked-by: Grant Likely <[email protected]>
Cc: [email protected]
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
History:
v1..v2:
- dropped device_type except for cpu & pci. I have the compatible string
for pci so I can drop the device_type once it is possible
- I lowercased all compatible types. I will need to resend some patches
which have upper case intel
- The cpu had the same compatible string as the soc node. So I added to
the soc node -immr for internel memory mapped registers.
- I added generic names for all parts.
- I reworked the i2c bars matching the way you suggested. I added a
compatible node for the PCI device which only the PCI ids in its
compatible string. The bars (each represents a complete i2c
controller) have a "intel,ce4100-i2c-controller" compatible node. It
is not used by the driver.
The driver is probed via PCI ids (by the pci subsystem not OF) and
matches the bar address against the ressource in the child node. Once
there is a hit the node is attached.
- The SPI driver is also probed via pci. However I also attached a
compatible property based on PCI ids
v2..v3:
- intel,ce4100-immr become intel,ce4100-cp. cp stands for core
peripherals. The Atom data sheet talks here about ACPI devices. Since
we don't have ACPI this does not apply here.
- The interrupt map is gone. There are now plenty of device nodes.
- The "unit address string" got fixed, it uses not DD,V format.
v3..v4:
- added descriptions for compatible nodes introduced here:
- intel,ce4100-ioapic
- intel,ce4100-lapic
- intel,ce4100-hpet
- intel,ce4100
- intel,ce4100-cp
- intel,ce4100-pci
- added a description about I2C controller magic.
- Added gpio-controller and gpio-cells property to gpio devices. Those
properties are not (yet) used.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Dirk Brandewie <[email protected]>
Acked-by: Grant Likely <[email protected]>
Cc: [email protected]
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
This patch adds minimal support for device tree on x86. The device
tree blob is passed to the kernel via setup_data which requires at
least boot protocol 2.09.
Memory size, restricted memory regions, boot arguments are gathered
the traditional way so things like cmd_line are just here to let the
code compile.
The current plan is use the device tree as an extension and to gather
information which can not be enumerated and would have to be hardcoded
otherwise. This includes things like
- which devices are on this I2C/SPI bus?
- how are the interrupts wired to IO APIC?
- where could my hpet be?
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Dirk Brandewie <[email protected]>
Acked-by: Grant Likely <[email protected]>
Cc: [email protected]
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
This patch ensures that the memory passed from parse_setup_data() is
large enough to cover the complete data structure. That means that the
conditional mapping in parse_e820_ext() can go.
While here, I also attempt not to map two pages if the address is not
aligned to a page boundary.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Dirk Brandewie <[email protected]>
Cc: [email protected]
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Reason: Devicetree based ioapic setup depends on the apic changes.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Required for devicetree based io_apic configuration.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
io_apic_set_pci_routing() and mp_save_irq() check the pin_programmed
bit before calling io_apic_setup_irq_pin() and set the bit when the
pin was setup.
Move that duplicated code into a separate function and use it.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
There is no point to have irq_trigger() and irq_polarity() as wrappers
around the MPBIOS_* camel case functions. Get rid of both the inlines
and the ugly camel case.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
No users outside of io_apic.c. Mark bad_ioapic() __init while at it.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Another version of the same thing. Only set the pin programmed, when
the setup function succeeds.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Replace the duplicated code.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
The only difference here is that we did not call
__add_pin_to_irq_node() for the legacy irqs, but that's not worth 30
lines of extra code.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Remove the duplicated code and call the function. It does not matter
whether we allocated the cfg before calling setup_local_APIC() and we
can set the irq chip and handler after that as well.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
There are about four places in the ioapic code which do exactly the
same setup sequence. Also the OF based ioapic setup needs that
function to avoid putting the OF specific code into ioapic.c
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Two consecutive
for(...)
for(...)
lines to avoid an extra indentation are just horrible to read. I had
to look more than once to figure out what the code is doing.
Split out the inner loop into a separate function.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
This is debug code and it does not matter at all whether we print each
not connected pin in an extra line or try to be extra clever.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Stupid me missed the functions called from setup.c. Add the stubs back
for OLPC=n
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
Since commit 7cd92366a593246650cc7d6198e2c7d3af8c1d8a
lAPIC enabled accidently the IOAPIC, which now gets fixed.
Signed-off-by: Henrik Kretzschmar <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
This patch adds IOAPIC dummy functions for compilation
with local APIC, but without IOAPIC.
The local variable ioapic_entries in enable_IR_x2apic()
does not need initialization anymore, since the dummy
returns NULL.
Signed-off-by: Henrik Kretzschmar <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Currently arch_disable_smp_support() on x86 disables only the
support for the IOAPIC and is also compiled in if SMP-support is
not.
Therefore this function is renamed to disable_ioapic_support(),
which meets its purpose and is only compiled in the kernel
when IOAPIC support is also.
A new arch_disable_smp_support() is created in smpboot.c,
which calls disable_ioapic_support() and gets only compiled
in the kernel when SMP support is also.
Signed-off-by: Henrik Kretzschmar <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
This is a dummy function, used when no IOAPIC is compiled in.
Signed-off-by: Henrik Kretzschmar <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
This enum is used by non IOAPIC code, so apicdef.h is
the best place for it.
Signed-off-by: Henrik Kretzschmar <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
OLPC_OPENFIRMWARE_DT is just there to be selected by OLPC and selects
OF_PROMTREE. So let OLPC select OF_PROMTREE and remove that extra
config indirection. Fixup code and Makefile and use CONFIG_OF_PROMTREE
instead.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Andres Salomon <[email protected]>
|
|
Neither CONFIG_OLPC_OPENFIRMWARE nor CONFIG_OLPC_OPENFIRMWARE_DT are
really necessary.
OLPC selects OLPC_OPENFIRMWARE unconditionally, so move the "select
OF" part under OLPC config option and fixup the dependencies in
Makefiles and code.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Andres Salomon <[email protected]>
|
|
OLPC selects OLPC_OPENFIRMWARE unconditionally. If OLPC=n then
the OLPC_OPENFIRMWARE functionality is pointless.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Andres Salomon <[email protected]>
|
|
OLPC is under if X86_32 already.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Andres Salomon <[email protected]>
|
|
Reason: Import mainline device tree changes on which further patches
depend on or conflict.
Trivial conflict in: drivers/spi/pxa2xx_spi_pci.c
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
With the hypervisor argument of dom0_mem=X we iterate over the physical
(only for the initial domain) E820 and subtract the the size from each
E820_RAM region the delta so that the cumulative size of all E820_RAM regions
is equal to 'X'. This sometimes ends up with E820_RAM regions with zero size
(which are removed by e820_sanitize) and E820_RAM that are smaller
than physically.
Later on the PCI API looks at the E820 and attempts to set up an
resource region for the "PCI mem". The E820 (assume dom0_mem=1GB is
set) compared to the physical looks as so:
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 0000000000097c00 (usable)
[ 0.000000] Xen: 0000000000097c00 - 0000000000100000 (reserved)
-[ 0.000000] Xen: 0000000000100000 - 00000000defafe00 (usable)
+[ 0.000000] Xen: 0000000000100000 - 0000000040000000 (usable)
[ 0.000000] Xen: 00000000defafe00 - 00000000defb1ea0 (ACPI NVS)
[ 0.000000] Xen: 00000000defb1ea0 - 00000000e0000000 (reserved)
[ 0.000000] Xen: 00000000f4000000 - 00000000f8000000 (reserved)
..
And we get
[ 0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:9efafe00)
while it should have started at e0000000 (a nice big gap up to
f4000000 exists). The "Allocating PCI" is part of the resource API.
The users that end up using those PCI I/O regions usually supply their
own BARs when calling the resource API (request_resource, or allocate_resource),
but there are exceptions which provide an empty 'struct resource' and
expect the API to provide the 'struct resource' to be populated with valid values.
The one that triggered this bug was the intel AGP driver that requested
a region for the flush page (intel_i9xx_setup_flush).
Before this patch, when running under Xen hypervisor, the 'struct resource'
returned could have (depending on the dom0_mem size) physical ranges of a 'System RAM'
instead of 'I/O' regions. This ended up with the Hypervisor failing a request
to populate PTE's with those PFNs as the domain did not have access to those
'System RAM' regions (rightly so).
After this patch, the left-over E820_RAM region from the truncation, will be
labeled as E820_UNUSABLE. The E820 will look as so:
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 0000000000097c00 (usable)
[ 0.000000] Xen: 0000000000097c00 - 0000000000100000 (reserved)
-[ 0.000000] Xen: 0000000000100000 - 00000000defafe00 (usable)
+[ 0.000000] Xen: 0000000000100000 - 0000000040000000 (usable)
+[ 0.000000] Xen: 0000000040000000 - 00000000defafe00 (unusable)
[ 0.000000] Xen: 00000000defafe00 - 00000000defb1ea0 (ACPI NVS)
[ 0.000000] Xen: 00000000defb1ea0 - 00000000e0000000 (reserved)
[ 0.000000] Xen: 00000000f4000000 - 00000000f8000000 (reserved)
For more information:
http://mid.gmane.org/1A42CE6F5F474C41B63392A5F80372B2335E978C@shsmsx501.ccr.corp.intel.com
BugLink: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726
Signed-off-by: Fengzhe Zhang <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
|
|
into x86/platform
Reason: x86 devicetree support for ce4100 depends on those device tree
changes scheduled for .39.
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
In the dr_intercept function a new cpu-feature called
decode-assists is implemented and used when available. This
code-path does not advance the guest-rip causing the guest
to dead-loop over mov-dr instructions. This is fixed by this
patch.
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
|
|
Alloc code is much bigger the distance setting. Separate it out into
numa_alloc_distance() for readability.
-v2: Let alloc_numa_distance to return -ENOMEM on failing path,
requested by tj.
-tj: Description update. Minor tweaks including function name,
location and return value check.
Signed-off-by: Yinghai Lu <[email protected]>
Acked-by: David Rientjes <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
|
|
Signed-off-by: Tejun Heo <[email protected]>
Cc: Yinghai Lu <[email protected]>
Cc: Ingo Molnar <[email protected]>
|
|
Create numa_emulation.c and move all NUMA emulation code there. The
definitions of struct numa_memblk and numa_meminfo are moved to
numa_64.h. Also, numa_remove_memblk_from(), numa_cleanup_meminfo(),
numa_reset_distance() along with numa_emulation() are made global.
- v2: Internal declarations moved to numa_internal.h as suggested by
Yinghai.
Signed-off-by: Tejun Heo <[email protected]>
Acked-by: Yinghai Lu <[email protected]>
Cc: Ingo Molnar <[email protected]>
|
|
separate file
Update numa_emulation() such that, it
- takes @numa_meminfo and @numa_dist_cnt instead of directly
referencing the global variables.
- copies the distance table by iterating each distance with
node_distance() instead of memcpy'ing the distance table.
- tests emu_cmdline to determine whether emulation is requested and
fills emu_nid_to_phys[] with identity mapping if emulation is not
used. This allows the caller to call numa_emulation()
unconditionally and makes return value unncessary.
- defines dummy version if CONFIG_NUMA_EMU is disabled.
This patch doesn't introduce any behavior change.
Signed-off-by: Tejun Heo <[email protected]>
Cc: Yinghai Lu <[email protected]>
Cc: Ingo Molnar <[email protected]>
|
|
By the time setup_node_bootmem() is called, all the memblocks are
already registered. As node_data is allocated from these memblocks,
calling it more than once doesn't make any difference. Drop the loop.
tj: Dropped comment referencing to the old behavior as suggested by
David and rephrased the description.
Signed-off-by: Yinghai Lu <[email protected]>
Acked-by: David Rientjes <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
|
|
VersaLogic Menlow based boards hang on reboot unless reboot=bios
is used. Add quirk to reboot through the BIOS.
Tested on at least four boards.
Signed-off-by: Kushal Koolwal <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
install_equiv_cpu_table() returns type int. It uses negative
error codes so using an unsigned type breaks the error handling.
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Cc: open list:AMD MICROCODE UPD... <[email protected]>
Cc: Andreas Herrmann <[email protected]>
LKML-Reference: <20110218091716.GA4384@bicker>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Those are unused since at least the beginning of git history.
Signed-off-by: Borislav Petkov <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Removed unused variable left over from development.
Reported-by: Brian Gerst <[email protected]>
LKML-Reference: <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Matthieu Castet <[email protected]>
|
|
The initial version of this patch had %eax being a segment and %ecx
being the mode. I had changed the interfaces, but not the actual
implementation!
Reported-by: Brian Gerst <[email protected]>
LKML-Reference: <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Matthieu Castet <[email protected]>
|
|
APB timer current count was unreliable in the earlier silicon, which
could result in time going backwards. This problem has been fixed in
the current silicon stepping. This patch removes the workaround which
was used to check and prevent timer rolling back when APB timer is
used as clocksource device.
The workaround code was also flawed by potential race condition
around the cached read value last_read. Though a fix can be done
by assigning last_read to a local variable at the beginning of
apbt_read_clocksource(), but this is not necessary anymore.
[ tglx: A sane timer on an Intel chip - I can't believe it ]
Signed-off-by: Jacob Pan <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: Alan Cox <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
This code path is only run when an MSI/MSI-X PCI device is passed
in to PV DomU.
In 2.6.37 time-frame we over-wrote the default cleanup handler for
MSI/MSI-X irq->desc to be "xen_teardown_msi_irqs". That function
calls the the xen-pcifront driver which can tell the backend to
cleanup/take back the MSI/MSI-X device.
However, we forgot to continue the process of free-ing the MSI/MSI-X
device resources (irq->desc) in the PV domU side. Which is what
the default cleanup handler: default_teardown_msi_irqs did.
Hence we would leak IRQ descriptors.
Without this patch, doing "rmmod igbvf;modprobe igbvf" multiple
times ends with abandoned IRQ descriptors:
28: 5 xen-pirq-pcifront-msi-x
29: 8 xen-pirq-pcifront-msi-x
...
130: 10 xen-pirq-pcifront-msi-x
with the end result of running out of IRQ descriptors.
Reviewed-by: Ian Campbell <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
|
|
Cleanup code. Cosmetic change to make the code look easier
to read.
Reviewed-by: Ian Campbell <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
|
|
|arch/x86/pci/ce4100.c: In function `ce4100_conf_read':
|arch/x86/pci/ce4100.c:257:9: warning: unused variable `retval'
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
xen_allocate_pirq -> xen_map_pirq_gsi -> PHYSDEVOP_alloc_irq_vector IFF
xen_initial_domain() in addition to the kernel side book-keeping side of
things (set chip and handler, update irq_info etc) whereas
xen_allocate_pirq_msi just does the kernel book keeping.
Also xen_allocate_pirq allocates an IRQ in the 1-1 GSI space whereas
xen_allocate_pirq_msi allocates a dynamic one in the >GSI IRQ space.
All of this is uneccessary as this code path is only executed
when we run as a domU PV guest with an MSI/MSI-X PCI card passed in.
Hence we can jump straight to allocating an dynamic IRQ (and
binding it to the proper PIRQ) and skip the rest.
In short: this change is a cosmetic one.
Reviewed-by: Ian Campbell <[email protected]>
Reviewed-by: Stefano Stabellini <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
|
|
Not only when an IRQ's affinity equals cpu_online_mask is there
no need to actually try to adjust the affinity, but also when
it's a subset thereof. This particularly avoids adjustment
attempts during system shutdown to any IRQs bound to CPU#0.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Gary Hade <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
With no caller left, the function and the DIE_NMIWATCHDOG
enumerator can both go away.
Signed-off-by: Jan Beulich <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Don Zickus <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|