zephyr/drivers/pci/pci.c

462 lines
12 KiB
C
Raw Normal View History

/* pci.c - PCI probe and information routines */
/*
* Copyright (c) 2013-2014 Wind River Systems, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
/*
DESCRIPTION
Module implements routines for PCI bus initialization and query.
USAGE
To use the driver, the platform must define:
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
- Numbers of BUSes:
- PCI_BUS_NUMBERS;
- Register addresses:
- PCI_CTRL_ADDR_REG;
- PCI_CTRL_DATA_REG;
- pci_pin2irq() - the routine that converts the PCI interrupt pin
number to IRQ number.
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
About scanning the PCI buses:
At every new usage of this API, the code should call pci_bus_scan_init().
It should own a struct pci_dev_info, filled in with the parameters it is
interested to look for: class and/or vendor_id/device_id.
Then it can loop on pci_bus_scan() providing a pointer on that structure.
Such function can be called as long as it returns 1. At every successful
return of pci_bus_scan() it means the provided structure pointer will have
been updated with the current scan result which the code might be interested
in. On pci_bus_scan() returning 0, the code should discard the result and
stop calling pci_bus_scan(). If it wants to retrieve the result, it will
have to restart the procedure all over again.
EXAMPLE
struct pci_dev_info info = {
.class = PCI_CLASS_COMM_CTLR
};
pci_bus_scan_init();
while (pci_bus_scan(&info) {
// do something with "info" which holds a valid result, i.e. some
// device information matching the PCI class PCI_CLASS_COMM_CTLR
}
INTERNALS
The whole logic runs around a structure: struct lookup_data, which exists
on one instanciation called 'lookup'.
Such structure is used for 2 distinct roles:
- to match devices the caller is looking for
- to loop on PCI bus, devices, function and BARs
The search criterias are the class and/or the vendor_id/device_id of a PCI
device. The caller first initializes the lookup structure by calling
pci_bus_scan_init(), which will reset the search criterias as well as the
loop paramaters to 0. At the very first subsequent call of pci_bus_scan()
the lookup structure will store the search criterias. Then the loop starts.
For each bus it will run through each device on which it will loop on each
function and BARs, as long as the criterias does not match or until it hit
the limit of bus/dev/functions to scan.
On a successful match, it will stop the loop, fill in the caller's
pci_dev_info structure with the found device information, and return 1.
Hopefully, the lookup structure still remembers where it stopped and the
original search criterias. Thus, when the caller asks to scan again for
a possible result next, the loop will restart where it stopped.
That will work as long as there are relevant results found.
*/
#include <nanokernel.h>
#include <arch/cpu.h>
#include <misc/printk.h>
#include <toolchain.h>
#include <sections.h>
#include <board.h>
#include <pci/pci_mgr.h>
#include <pci/pci.h>
#ifdef CONFIG_PCI_ENUMERATION
/* NOTE. These parameters may need to be configurable */
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
#define LSPCI_MAX_BUS PCI_BUS_NUMBERS /* maximum number of buses to scan */
#define LSPCI_MAX_DEV 32 /* maximum number of devices to scan */
#define LSPCI_MAX_FUNC PCI_MAX_FUNCTIONS /* maximum functions to scan */
#define LSPCI_MAX_REG 64 /* maximum device registers to read */
/* Base Address Register configuration fields */
#define BAR_SPACE(x) ((x) & 0x00000001)
#define BAR_TYPE(x) ((x) & 0x00000006)
#define BAR_TYPE_32BIT 0
#define BAR_TYPE_64BIT 4
#define BAR_PREFETCH(x) (((x) >> 3) & 0x00000001)
#define BAR_ADDR(x) (((x) >> 4) & 0x0fffffff)
#define BAR_IO_MASK(x) ((x) & ~0x3)
#define BAR_MEM_MASK(x) ((x) & ~0xf)
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
struct lookup_data {
struct pci_dev_info info;
uint32_t bus:9;
uint32_t dev:6;
uint32_t func:4;
uint32_t bar:4;
uint32_t unused:9;
};
static struct lookup_data __noinit lookup;
/**
*
* @brief Return the configuration for the specified BAR
*
* @return 0 if BAR is implemented, -1 if not.
*/
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
static inline int pci_bar_config_get(union pci_addr_reg pci_ctrl_addr,
uint32_t *config)
{
uint32_t old_value;
/* save the current setting */
pci_read(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(old_value),
&old_value);
/* write to the BAR to see how large it is */
pci_write(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(uint32_t),
0xffffffff);
pci_read(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(*config),
config);
/* put back the old configuration */
pci_write(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(old_value),
old_value);
/* check if this BAR is implemented */
if (*config != 0xffffffff && *config != 0) {
return 0;
}
/* BAR not supported */
return -1;
}
/**
*
* @brief Retrieve the I/O address and IRQ of the specified BAR
*
* @return -1 on error, 0 if 32 bit BAR retrieved or 1 if 64 bit BAR retrieved
*
* NOTE: Routine does not set up parameters for 64 bit BARS, they are ignored.
*
* \NOMANUAL
*/
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
static inline int pci_bar_params_get(union pci_addr_reg pci_ctrl_addr,
struct pci_dev_info *dev_info)
{
uint32_t bar_value;
uint32_t bar_config;
uint32_t addr;
uint32_t mask;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
pci_ctrl_addr.field.reg = 4 + lookup.bar;
pci_read(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(bar_value),
&bar_value);
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
if (pci_bar_config_get(pci_ctrl_addr, &bar_config) != 0) {
return -1;
}
if (BAR_SPACE(bar_config) == BAR_SPACE_MEM) {
dev_info->mem_type = BAR_SPACE_MEM;
mask = ~0xf;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
if (lookup.bar < 5 && BAR_TYPE(bar_config) == BAR_TYPE_64BIT) {
return 1; /* 64-bit MEM */
}
} else {
dev_info->mem_type = BAR_SPACE_IO;
mask = ~0x3;
}
dev_info->addr = bar_value & mask;
addr = bar_config & mask;
if (addr != 0) {
/* calculate the size of the BAR memory required */
dev_info->size = 1 << (find_lsb_set(addr) - 1);
}
return 0;
}
/**
*
* @brief Scan the specified PCI device for all sub functions
*
* @return 1 if a device has been found, 0 otherwise.
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
*
* \NOMANUAL
*/
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
static inline int pci_dev_scan(union pci_addr_reg pci_ctrl_addr,
struct pci_dev_info *dev_info)
{
static union pci_dev pci_dev_header;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
uint32_t pci_data;
int max_bars;
/* verify first if there is a valid device at this point */
pci_ctrl_addr.field.func = 0;
pci_read(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(pci_data),
&pci_data);
if (pci_data == 0xffffffff) {
return 0;
}
/* scan all the possible functions for this device */
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
for (; lookup.func < LSPCI_MAX_FUNC; lookup.bar = 0, lookup.func++) {
if (lookup.info.function != PCI_FUNCTION_ANY &&
lookup.func != lookup.info.function) {
return 0;
}
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
pci_ctrl_addr.field.func = lookup.func;
if (lookup.func != 0) {
pci_read(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(pci_data),
&pci_data);
if (pci_data == 0xffffffff) {
continue;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
}
}
/* get the PCI header from the device */
pci_header_get(DEFAULT_PCI_CONTROLLER,
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
pci_ctrl_addr,
&pci_dev_header);
/*
* Skip a device if its class is specified by the
* caller and does not match
*/
if (lookup.info.class &&
pci_dev_header.field.class != lookup.info.class) {
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
continue;
}
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
if (lookup.info.vendor_id && lookup.info.device_id &&
(lookup.info.vendor_id != pci_dev_header.field.vendor_id ||
lookup.info.device_id != pci_dev_header.field.device_id)) {
continue;
}
/* Get memory and interrupt information */
if ((pci_dev_header.field.hdr_type & 0x7f) == 1) {
max_bars = 2;
} else {
max_bars = PCI_MAX_BARS;
}
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
for (; lookup.bar < max_bars; lookup.bar++) {
/* Ignore BARs with errors and 64 bit BARs */
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
if (pci_bar_params_get(pci_ctrl_addr, dev_info) != 0) {
continue;
} else if (lookup.info.bar != PCI_BAR_ANY &&
lookup.bar != lookup.info.bar) {
continue;
} else {
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
dev_info->vendor_id =
pci_dev_header.field.vendor_id;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
dev_info->device_id =
pci_dev_header.field.device_id;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
dev_info->class =
pci_dev_header.field.class;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
dev_info->irq = pci_pin2irq(
pci_dev_header.field.interrupt_pin);
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
dev_info->function = lookup.func;
dev_info->bar = lookup.bar;
lookup.bar++;
if (lookup.bar >= max_bars)
lookup.bar = 0;
return 1;
}
}
}
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
return 0;
}
void pci_bus_scan_init(void)
{
lookup.info.class = 0;
lookup.info.vendor_id = 0;
lookup.info.device_id = 0;
lookup.info.function = PCI_FUNCTION_ANY;
lookup.info.bar = PCI_BAR_ANY;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
lookup.bus = 0;
lookup.dev = 0;
lookup.func = 0;
lookup.bar = 0;
}
/**
*
* @brief Scans PCI bus for devices
*
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
* The routine scans the PCI bus for the devices on criterias provided in the
* given dev_info at first call. Which criterias can be class and/or
* vendor_id/device_id.
*
* @return 1 on success, 0 otherwise. On success, dev_info is filled in with
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
* currently found device information
*
* \NOMANUAL
*/
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
int pci_bus_scan(struct pci_dev_info *dev_info)
{
union pci_addr_reg pci_ctrl_addr;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
if (!lookup.info.class &&
!lookup.info.vendor_id &&
!lookup.info.device_id &&
lookup.info.bar == PCI_BAR_ANY &&
lookup.info.function == PCI_FUNCTION_ANY) {
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
lookup.info.class = dev_info->class;
lookup.info.vendor_id = dev_info->vendor_id;
lookup.info.device_id = dev_info->device_id;
lookup.info.function = dev_info->function;
lookup.info.bar = dev_info->bar;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
}
/* initialise the PCI controller address register value */
pci_ctrl_addr.value = 0;
if (lookup.info.function != PCI_FUNCTION_ANY) {
lookup.func = lookup.info.function;
}
/* run through the buses and devices */
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
for (; lookup.bus < LSPCI_MAX_BUS; lookup.bus++) {
for (; (lookup.dev < LSPCI_MAX_DEV); lookup.dev++) {
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
pci_ctrl_addr.field.bus = lookup.bus;
pci_ctrl_addr.field.device = lookup.dev;
if (pci_dev_scan(pci_ctrl_addr, dev_info)) {
dev_info->bus = lookup.bus;
dev_info->dev = lookup.dev;
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
return 1;
}
if (lookup.info.function != PCI_FUNCTION_ANY) {
lookup.func = lookup.info.function;
} else {
lookup.func = 0;
}
}
}
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
return 0;
}
#endif /* CONFIG_PCI_ENUMERATION */
void pci_enable_regs(struct pci_dev_info *dev_info)
{
union pci_addr_reg pci_ctrl_addr;
uint32_t pci_data;
pci_ctrl_addr.value = 0;
pci_ctrl_addr.field.func = dev_info->function;
pci_ctrl_addr.field.bus = dev_info->bus;
pci_ctrl_addr.field.device = dev_info->dev;
pci_ctrl_addr.field.reg = 1;
#ifdef CONFIG_PCI_DEBUG
printk("pci_enable_regs 0x%x\n", pci_ctrl_addr);
#endif
pci_read(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(uint16_t),
&pci_data);
pci_data = pci_data | PCI_CMD_MEM_ENABLE;
pci_write(DEFAULT_PCI_CONTROLLER,
pci_ctrl_addr,
sizeof(uint16_t),
pci_data);
}
#ifdef CONFIG_PCI_DEBUG
/**
*
* @brief Show PCI device
*
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
* Shows the PCI device found provided as parameter.
*
* @return N/A
*/
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
void pci_show(struct pci_dev_info *dev_info)
{
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
printk("PCI device:\n");
printk("%u:%u %X:%X class: 0x%X, %u, %u, %s,"
"addrs: 0x%X-0x%X, IRQ %d\n",
dev_info->bus,
dev_info->dev,
pci: Provide a simpler yet powerful PCI enumeration API This fixes many issues around PCI enumeration from old API: - a static internal table was fed with scanning results, thus eating memory, and worse: due to the limit of its size, scanning for new classes was impossible unless growing statically the size of this table --> more memory eaten! Not to mention PCI enumeration is done once at boot time for driver initialization and that's all, so this table is hanging around for nothing afterwards. - one needs first to scan a class, then maybe he will be able to find his device via pci_dev_find. Where all could be done at once. - pci_dev_find was not trustworthy due again to the internal table. Now if the device is not found, one will know it really went through all the possbilities. - still let the possibility for hard-coded BARs value on driver side (thus no PCI scan required). However this is greatly advised not to do so as BARs might change over a firmware/BIOS update. Comparison: old pci_dev_scan: could only filter out via class mask. new pci_dev_scan: can filter out via a class, a vendor and device ID (it could easily do the same for Function and BAR index as these are usually fixed and informed through datasheet) old pci_dev_scan: was limited in its findings by the size of the internal result table. new pci_dev_scan: can proceed through all the buses and devices every time (there are optimizations to avoid useless work of course) old results did not tell about the function or BAR index. new one tells, and the structure has not bloated. old internal code: was storing a big table of results new internal code: is only storing a small lookup structure and an array of Bus:Dev pairs for each PCI class for optimizations purpose. (though, if needed, we could disable this through some #ifdef) Usage: - Have a local struct dev_info - Fill it with what you want to look for, currently: only class and vendor_id/device_id. Function and BAR index could be added if needed. - Call pci_bus_scan_init(): this will reset the internal lookup structure. - Call pci_dev_scan(<a pointer to your dev_info>): at first call, the internal lookup structure will pick up the informations from dev_info and will try to find out what has been requested. It will return 1 on success, or 0. On 1, your dev_info structure will be updated with the found informations. If more devices can be found against the same lookup informations, just call again pci_dev_scan(<a pointer to your dev_info>) as long as it returns 1. When 0 is hit, it will mean you found all. Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4 Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
2015-05-20 13:30:35 +02:00
dev_info->vendor_id,
dev_info->device_id,
dev_info->class,
dev_info->function,
dev_info->bar,
(dev_info->mem_type == BAR_SPACE_MEM) ? "MEM" : "I/O",
(uint32_t)dev_info->addr,
(uint32_t)(dev_info->addr + dev_info->size - 1),
dev_info->irq);
}
#endif /* CONFIG_PCI_DEBUG */