* [PATCH V4 13/26] bnx2x: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Introduce bnx2x_vf_domain() function to extract the domain information
and save it to VF specific data structure.
Use the saved domain value while calling pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 10 +++++++++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 3591077..ffa7959 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -812,7 +812,7 @@ static u8 bnx2x_vf_is_pcie_pending(struct bnx2x *bp, u8 abs_vfid)
if (!vf)
return false;
- dev = pci_get_bus_and_slot(vf->bus, vf->devfn);
+ dev = pci_get_domain_bus_and_slot(vf->domain, vf->bus, vf->devfn);
if (dev)
return bnx2x_is_pcie_pending(dev);
return false;
@@ -1041,6 +1041,13 @@ void bnx2x_iov_init_dmae(struct bnx2x *bp)
REG_WR(bp, DMAE_REG_BACKWARD_COMP_EN, 0);
}
+static int bnx2x_vf_domain(struct bnx2x *bp, int vfid)
+{
+ struct pci_dev *dev = bp->pdev;
+
+ return pci_domain_nr(dev->bus);
+}
+
static int bnx2x_vf_bus(struct bnx2x *bp, int vfid)
{
struct pci_dev *dev = bp->pdev;
@@ -1606,6 +1613,7 @@ int bnx2x_iov_nic_init(struct bnx2x *bp)
struct bnx2x_virtf *vf = BP_VF(bp, vfid);
/* fill in the BDF and bars */
+ vf->domain = bnx2x_vf_domain(bp, vfid);
vf->bus = bnx2x_vf_bus(bp, vfid);
vf->devfn = bnx2x_vf_devfn(bp, vfid);
bnx2x_vf_set_bars(bp, vf);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
index 53466f6..eb814c6 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h
@@ -182,6 +182,7 @@ struct bnx2x_virtf {
u32 error; /* 0 means all's-well */
/* BDF */
+ unsigned int domain;
unsigned int bus;
unsigned int devfn;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Use the domain information from pdev while calling into
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 40e52ff..7cd4946 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -2594,8 +2594,10 @@ static int pch_gbe_probe(struct pci_dev *pdev,
if (adapter->pdata && adapter->pdata->platform_init)
adapter->pdata->platform_init(pdev);
- adapter->ptp_pdev = pci_get_bus_and_slot(adapter->pdev->bus->number,
- PCI_DEVFN(12, 4));
+ adapter->ptp_pdev =
+ pci_get_domain_bus_and_slot(pci_domain_nr(adapter->pdev->bus),
+ adapter->pdev->bus->number,
+ PCI_DEVFN(12, 4));
netdev->netdev_ops = &pch_gbe_netdev_ops;
netdev->watchdog_timeo = PCH_GBE_WATCHDOG_PERIOD;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 15/26] PCI: cpqhp: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain number as 0. The code doesn't seem to be ready
for multiple domains.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/hotplug/cpqphp_pci.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/hotplug/cpqphp_pci.c b/drivers/pci/hotplug/cpqphp_pci.c
index e220d49..8897a77 100644
--- a/drivers/pci/hotplug/cpqphp_pci.c
+++ b/drivers/pci/hotplug/cpqphp_pci.c
@@ -89,7 +89,9 @@ int cpqhp_configure_device(struct controller *ctrl, struct pci_func *func)
pci_lock_rescan_remove();
if (func->pci_dev == NULL)
- func->pci_dev = pci_get_bus_and_slot(func->bus, PCI_DEVFN(func->device, func->function));
+ func->pci_dev = pci_get_domain_bus_and_slot(0, func->bus,
+ PCI_DEVFN(func->device,
+ func->function));
/* No pci device, we need to create it then */
if (func->pci_dev == NULL) {
@@ -99,7 +101,9 @@ int cpqhp_configure_device(struct controller *ctrl, struct pci_func *func)
if (num)
pci_bus_add_devices(ctrl->pci_dev->bus);
- func->pci_dev = pci_get_bus_and_slot(func->bus, PCI_DEVFN(func->device, func->function));
+ func->pci_dev = pci_get_domain_bus_and_slot(0, func->bus,
+ PCI_DEVFN(func->device,
+ func->function));
if (func->pci_dev == NULL) {
dbg("ERROR: pci_dev still null\n");
goto out;
@@ -129,7 +133,10 @@ int cpqhp_unconfigure_device(struct pci_func *func)
pci_lock_rescan_remove();
for (j = 0; j < 8 ; j++) {
- struct pci_dev *temp = pci_get_bus_and_slot(func->bus, PCI_DEVFN(func->device, j));
+ struct pci_dev *temp = pci_get_domain_bus_and_slot(0,
+ func->bus,
+ PCI_DEVFN(func->device,
+ j));
if (temp) {
pci_dev_put(temp);
pci_stop_and_remove_bus_device(temp);
@@ -319,6 +326,7 @@ int cpqhp_save_config(struct controller *ctrl, int busnumber, int is_hot_plug)
int cloop = 0;
int stop_it;
int index;
+ u16 devfn;
/* Decide which slots are supported */
@@ -416,7 +424,9 @@ int cpqhp_save_config(struct controller *ctrl, int busnumber, int is_hot_plug)
new_slot->switch_save = 0x10;
/* In case of unsupported board */
new_slot->status = DevError;
- new_slot->pci_dev = pci_get_bus_and_slot(new_slot->bus, (new_slot->device << 3) | new_slot->function);
+ devfn = (new_slot->device << 3) | new_slot->function;
+ new_slot->pci_dev = pci_get_domain_bus_and_slot(0,
+ new_slot->bus, devfn);
for (cloop = 0; cloop < 0x20; cloop++) {
rc = pci_bus_read_config_dword(ctrl->pci_bus, PCI_DEVFN(device, function), cloop << 2, (u32 *) &(new_slot->config_space[cloop]));
--
1.9.1
^ permalink raw reply related
* [PATCH V4 16/26] PCI: ibmphp: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain parameter as 0 since the code doesn't seem to be
ready for multiple domains.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/hotplug/ibmphp_core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug/ibmphp_core.c b/drivers/pci/hotplug/ibmphp_core.c
index 73cf846..92dd882 100644
--- a/drivers/pci/hotplug/ibmphp_core.c
+++ b/drivers/pci/hotplug/ibmphp_core.c
@@ -707,7 +707,8 @@ static void ibm_unconfigure_device(struct pci_func *func)
pci_lock_rescan_remove();
for (j = 0; j < 0x08; j++) {
- temp = pci_get_bus_and_slot(func->busno, (func->device << 3) | j);
+ temp = pci_get_domain_bus_and_slot(0, func->busno,
+ (func->device << 3) | j);
if (temp) {
pci_stop_and_remove_bus_device(temp);
pci_dev_put(temp);
@@ -780,7 +781,7 @@ static int ibm_configure_device(struct pci_func *func)
if (!(bus_structure_fixup(func->busno)))
flag = 1;
if (func->dev == NULL)
- func->dev = pci_get_bus_and_slot(func->busno,
+ func->dev = pci_get_domain_bus_and_slot(0, func->busno,
PCI_DEVFN(func->device, func->function));
if (func->dev == NULL) {
@@ -793,7 +794,7 @@ static int ibm_configure_device(struct pci_func *func)
if (num)
pci_bus_add_devices(bus);
- func->dev = pci_get_bus_and_slot(func->busno,
+ func->dev = pci_get_domain_bus_and_slot(0, func->busno,
PCI_DEVFN(func->device, func->function));
if (func->dev == NULL) {
err("ERROR... : pci_dev still NULL\n");
--
1.9.1
^ permalink raw reply related
* [PATCH V4 17/26] PCI/quirks: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Extract the domain number from pdev while calling into
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/quirks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index fd49b97..d7aa31f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2698,7 +2698,8 @@ static void __nv_msi_ht_cap_quirk(struct pci_dev *dev, int all)
* HT MSI mapping should be disabled on devices that are below
* a non-Hypertransport host bridge. Locate the host bridge...
*/
- host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+ host_bridge = pci_get_domain_bus_and_slot(pci_domain_nr(dev->bus), 0,
+ PCI_DEVFN(0, 0));
if (host_bridge == NULL) {
dev_warn(&dev->dev, "nv_msi_ht_cap_quirk didn't locate host bridge\n");
return;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 18/26] PCI/syscall: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain value as 0 because the domain information is not
coming from the userspace.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/syscall.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index 83efa00..e725f99 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -28,7 +28,7 @@
return -EPERM;
err = -ENODEV;
- dev = pci_get_bus_and_slot(bus, dfn);
+ dev = pci_get_domain_bus_and_slot(0, bus, dfn);
if (!dev)
goto error;
@@ -96,7 +96,7 @@
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- dev = pci_get_bus_and_slot(bus, dfn);
+ dev = pci_get_domain_bus_and_slot(0, bus, dfn);
if (!dev)
return -ENODEV;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 19/26] xen: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
drivers/pci/xen-pcifront.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 8fc2e95..94b25b5 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -595,6 +595,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
struct pci_driver *pdrv;
int bus = pdev->sh_info->aer_op.bus;
int devfn = pdev->sh_info->aer_op.devfn;
+ int domain = pdev->sh_info->aer_op.domain;
struct pci_dev *pcidev;
int flag = 0;
@@ -603,7 +604,7 @@ static pci_ers_result_t pcifront_common_process(int cmd,
cmd, bus, devfn);
result = PCI_ERS_RESULT_NONE;
- pcidev = pci_get_bus_and_slot(bus, devfn);
+ pcidev = pci_get_domain_bus_and_slot(domain, bus, devfn);
if (!pcidev || !pcidev->driver) {
dev_err(&pdev->xdev->dev, "device or AER driver is NULL\n");
pci_dev_put(pcidev);
--
1.9.1
^ permalink raw reply related
* [PATCH V4 20/26] openprom: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain as 0 since domain information is not available.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/sbus/char/openprom.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/sbus/char/openprom.c b/drivers/sbus/char/openprom.c
index 2c2e6a3..7b31f19 100644
--- a/drivers/sbus/char/openprom.c
+++ b/drivers/sbus/char/openprom.c
@@ -251,8 +251,9 @@ static int oprompci2node(void __user *argp, struct device_node *dp, struct openp
struct pci_dev *pdev;
struct device_node *dp;
- pdev = pci_get_bus_and_slot (((int *) op->oprom_array)[0],
- ((int *) op->oprom_array)[1]);
+ pdev = pci_get_domain_bus_and_slot(0,
+ ((int *) op->oprom_array)[0],
+ ((int *) op->oprom_array)[1]);
dp = pci_device_to_OF_node(pdev);
data->current_node = dp;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 21/26] backlight: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain as 0.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
---
drivers/video/backlight/apple_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/apple_bl.c b/drivers/video/backlight/apple_bl.c
index d843296..6a34ab9 100644
--- a/drivers/video/backlight/apple_bl.c
+++ b/drivers/video/backlight/apple_bl.c
@@ -143,7 +143,7 @@ static int apple_bl_add(struct acpi_device *dev)
struct pci_dev *host;
int intensity;
- host = pci_get_bus_and_slot(0, 0);
+ host = pci_get_domain_bus_and_slot(0, 0, 0);
if (!host) {
pr_err("unable to find PCI host\n");
--
1.9.1
^ permalink raw reply related
* [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Find the domain number from pdev.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/intelfb/intelfbhw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/intelfb/intelfbhw.c b/drivers/video/fbdev/intelfb/intelfbhw.c
index 83fec57..57aff74 100644
--- a/drivers/video/fbdev/intelfb/intelfbhw.c
+++ b/drivers/video/fbdev/intelfb/intelfbhw.c
@@ -181,7 +181,9 @@ int intelfbhw_get_memory(struct pci_dev *pdev, int *aperture_size,
return 1;
/* Find the bridge device. It is always 0:0.0 */
- if (!(bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)))) {
+ bridge_dev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus), 0,
+ PCI_DEVFN(0, 0));
+ if (!bridge_dev) {
ERR_MSG("cannot find bridge device\n");
return 1;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev
member to extract the domain information and pass it to
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/nvidia/nv_hw.c | 11 ++++++-----
drivers/video/fbdev/nvidia/nv_setup.c | 3 ++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_hw.c b/drivers/video/fbdev/nvidia/nv_hw.c
index 81c80ac..8335da4 100644
--- a/drivers/video/fbdev/nvidia/nv_hw.c
+++ b/drivers/video/fbdev/nvidia/nv_hw.c
@@ -683,10 +683,11 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
nv10_sim_state sim_data;
unsigned int M, N, P, pll, MClk, NVClk, memctrl;
struct pci_dev *dev;
+ int domain = pci_domain_nr(par->pci_dev->bus);
if ((par->Chipset & 0x0FF0) == 0x01A0) {
unsigned int uMClkPostDiv;
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0x6C, &uMClkPostDiv);
uMClkPostDiv = (uMClkPostDiv >> 8) & 0xf;
@@ -694,7 +695,7 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
uMClkPostDiv = 4;
MClk = 400000 / uMClkPostDiv;
} else {
- dev = pci_get_bus_and_slot(0, 5);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 5);
pci_read_config_dword(dev, 0x4c, &MClk);
MClk /= 1000;
}
@@ -707,13 +708,13 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
sim_data.pix_bpp = (char)pixelDepth;
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &sim_data.memory_type);
pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type >> 12) & 1;
sim_data.memory_width = 64;
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0, &memctrl);
pci_dev_put(dev);
memctrl >>= 16;
@@ -721,7 +722,7 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
if ((memctrl == 0x1A9) || (memctrl == 0x1AB) || (memctrl == 0x1ED)) {
u32 dimm[3];
- dev = pci_get_bus_and_slot(0, 2);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 2);
pci_read_config_dword(dev, 0x40, &dimm[0]);
dimm[0] = (dimm[0] >> 8) & 0x4f;
pci_read_config_dword(dev, 0x44, &dimm[1]);
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c b/drivers/video/fbdev/nvidia/nv_setup.c
index 2f2e162..b17acd2 100644
--- a/drivers/video/fbdev/nvidia/nv_setup.c
+++ b/drivers/video/fbdev/nvidia/nv_setup.c
@@ -264,7 +264,8 @@ static void nv10GetConfig(struct nvidia_par *par)
}
#endif
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(pci_domain_nr(par->pci_dev->bus),
+ 0, 1);
if ((par->Chipset & 0xffff) == 0x01a0) {
u32 amt;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
struct riva_par has a pointer to struct pci_dev. Use the pci_dev member
to extract the domain information.
Change the function signature for CalcStateExt and RivaGetConfig to pass
in struct pci_dev in addition to RIVA_HW_INST so that code inside the
riva_hw.c can also calculate domain number and pass it to
pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/riva/fbdev.c | 2 +-
drivers/video/fbdev/riva/nv_driver.c | 7 ++++---
drivers/video/fbdev/riva/riva_hw.c | 20 +++++++++++++-------
drivers/video/fbdev/riva/riva_hw.h | 3 ++-
4 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index 1ea78bb..ff82823 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -780,7 +780,7 @@ static int riva_load_video_mode(struct fb_info *info)
else
newmode.misc_output |= 0x80;
- rc = CalcStateExt(&par->riva, &newmode.ext, bpp, width,
+ rc = CalcStateExt(&par->riva, &newmode.ext, par->pdev, bpp, width,
hDisplaySize, height, dotClock);
if (rc)
goto out;
diff --git a/drivers/video/fbdev/riva/nv_driver.c b/drivers/video/fbdev/riva/nv_driver.c
index f3694cf..a3d9c66 100644
--- a/drivers/video/fbdev/riva/nv_driver.c
+++ b/drivers/video/fbdev/riva/nv_driver.c
@@ -159,6 +159,7 @@ unsigned long riva_get_memlen(struct riva_par *par)
unsigned int chipset = par->Chipset;
struct pci_dev* dev;
u32 amt;
+ int domain = pci_domain_nr(par->pdev->bus);
switch (chip->Architecture) {
case NV_ARCH_03:
@@ -226,12 +227,12 @@ unsigned long riva_get_memlen(struct riva_par *par)
case NV_ARCH_30:
if(chipset == NV_CHIP_IGEFORCE2) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &amt);
pci_dev_put(dev);
memlen = (((amt >> 6) & 31) + 1) * 1024;
} else if (chipset == NV_CHIP_0x01F0) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x84, &amt);
pci_dev_put(dev);
memlen = (((amt >> 4) & 127) + 1) * 1024;
@@ -417,6 +418,6 @@ unsigned long riva_get_maxdclk(struct riva_par *par)
}
par->riva.flatPanel = (par->FlatPanel > 0) ? TRUE : FALSE;
- RivaGetConfig(&par->riva, par->Chipset);
+ RivaGetConfig(&par->riva, par->pdev, par->Chipset);
}
diff --git a/drivers/video/fbdev/riva/riva_hw.c b/drivers/video/fbdev/riva/riva_hw.c
index 8bdf37f..0601c13 100644
--- a/drivers/video/fbdev/riva/riva_hw.c
+++ b/drivers/video/fbdev/riva/riva_hw.c
@@ -1108,7 +1108,8 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
unsigned pixelDepth,
unsigned *burst,
unsigned *lwm,
- RIVA_HW_INST *chip
+ RIVA_HW_INST *chip,
+ struct pci_dev *pdev
)
{
nv10_fifo_info fifo_data;
@@ -1116,8 +1117,9 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
unsigned int M, N, P, pll, MClk, NVClk;
unsigned int uMClkPostDiv;
struct pci_dev *dev;
+ int domain = pci_domain_nr(pdev->bus);
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0x6C, &uMClkPostDiv);
pci_dev_put(dev);
uMClkPostDiv = (uMClkPostDiv >> 8) & 0xf;
@@ -1132,7 +1134,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &sim_data.memory_type);
pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type >> 12) & 1;
@@ -1234,6 +1236,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
(
RIVA_HW_INST *chip,
RIVA_HW_STATE *state,
+ struct pci_dev *pdev,
int bpp,
int width,
int hDisplaySize,
@@ -1300,7 +1303,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
pixelDepth * 8,
&(state->arbitration0),
&(state->arbitration1),
- chip);
+ chip, pdev);
} else {
nv10UpdateArbitrationSettings(VClk,
pixelDepth * 8,
@@ -2102,10 +2105,12 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
static void nv10GetConfig
(
RIVA_HW_INST *chip,
+ struct pci_dev *pdev,
unsigned int chipset
)
{
struct pci_dev* dev;
+ int domain = pci_domain_nr(pdev->bus);
u32 amt;
#ifdef __BIG_ENDIAN
@@ -2118,12 +2123,12 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
* Fill in chip configuration.
*/
if(chipset == NV_CHIP_IGEFORCE2) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &amt);
pci_dev_put(dev);
chip->RamAmountKBytes = (((amt >> 6) & 31) + 1) * 1024;
} else if(chipset == NV_CHIP_0x01F0) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x84, &amt);
pci_dev_put(dev);
chip->RamAmountKBytes = (((amt >> 4) & 127) + 1) * 1024;
@@ -2224,6 +2229,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
int RivaGetConfig
(
RIVA_HW_INST *chip,
+ struct pci_dev *pdev,
unsigned int chipset
)
{
@@ -2245,7 +2251,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
case NV_ARCH_10:
case NV_ARCH_20:
case NV_ARCH_30:
- nv10GetConfig(chip, chipset);
+ nv10GetConfig(chip, pdev, chipset);
break;
default:
return (-1);
diff --git a/drivers/video/fbdev/riva/riva_hw.h b/drivers/video/fbdev/riva/riva_hw.h
index c2769f7..5e7b354 100644
--- a/drivers/video/fbdev/riva/riva_hw.h
+++ b/drivers/video/fbdev/riva/riva_hw.h
@@ -536,6 +536,7 @@
(
RIVA_HW_INST *chip,
RIVA_HW_STATE *state,
+ struct pci_dev *pdev,
int bpp,
int width,
int hDisplaySize,
@@ -546,7 +547,7 @@
/*
* External routines.
*/
-int RivaGetConfig(RIVA_HW_INST *, unsigned int);
+int RivaGetConfig(RIVA_HW_INST *chip, struct pci_dev *pdev, unsigned int c);
/*
* FIFO Free Count. Should attempt to yield processor if RIVA is busy.
*/
--
1.9.1
^ permalink raw reply related
* [PATCH V4 25/26] i7300_idle: remove unused file
From: Sinan Kaya @ 2017-12-19 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
i7300_idle.h is not being called by any source file and contains calls to
pci_get_bus_and_slot() that we are trying to deprecate. Remove unused file.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
include/linux/i7300_idle.h | 84 ----------------------------------------------
1 file changed, 84 deletions(-)
delete mode 100644 include/linux/i7300_idle.h
diff --git a/include/linux/i7300_idle.h b/include/linux/i7300_idle.h
deleted file mode 100644
index 4dbe651..0000000
--- a/include/linux/i7300_idle.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#ifndef I7300_IDLE_H
-#define I7300_IDLE_H
-
-#include <linux/pci.h>
-
-/*
- * I/O AT controls (PCI bus 0 device 8 function 0)
- * DIMM controls (PCI bus 0 device 16 function 1)
- */
-#define IOAT_BUS 0
-#define IOAT_DEVFN PCI_DEVFN(8, 0)
-#define MEMCTL_BUS 0
-#define MEMCTL_DEVFN PCI_DEVFN(16, 1)
-
-struct fbd_ioat {
- unsigned int vendor;
- unsigned int ioat_dev;
- unsigned int enabled;
-};
-
-/*
- * The i5000 chip-set has the same hooks as the i7300
- * but it is not enabled by default and must be manually
- * manually enabled with "forceload=1" because it is
- * only lightly validated.
- */
-
-static const struct fbd_ioat fbd_ioat_list[] = {
- {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_CNB, 1},
- {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT, 0},
- {0, 0}
-};
-
-/* table of devices that work with this driver */
-static const struct pci_device_id pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_FBD_CNB) },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_5000_ERR) },
- { } /* Terminating entry */
-};
-
-/* Check for known platforms with I/O-AT */
-static inline int i7300_idle_platform_probe(struct pci_dev **fbd_dev,
- struct pci_dev **ioat_dev,
- int enable_all)
-{
- int i;
- struct pci_dev *memdev, *dmadev;
-
- memdev = pci_get_bus_and_slot(MEMCTL_BUS, MEMCTL_DEVFN);
- if (!memdev)
- return -ENODEV;
-
- for (i = 0; pci_tbl[i].vendor != 0; i++) {
- if (memdev->vendor == pci_tbl[i].vendor &&
- memdev->device == pci_tbl[i].device) {
- break;
- }
- }
- if (pci_tbl[i].vendor == 0)
- return -ENODEV;
-
- dmadev = pci_get_bus_and_slot(IOAT_BUS, IOAT_DEVFN);
- if (!dmadev)
- return -ENODEV;
-
- for (i = 0; fbd_ioat_list[i].vendor != 0; i++) {
- if (dmadev->vendor == fbd_ioat_list[i].vendor &&
- dmadev->device == fbd_ioat_list[i].ioat_dev) {
- if (!(fbd_ioat_list[i].enabled || enable_all))
- continue;
- if (fbd_dev)
- *fbd_dev = memdev;
- if (ioat_dev)
- *ioat_dev = dmadev;
-
- return 0;
- }
- }
- return -ENODEV;
-}
-
-#endif
--
1.9.1
^ permalink raw reply related
* [PATCH V4 26/26] PCI: Remove pci_get_bus_and_slot() function
From: Sinan Kaya @ 2017-12-19 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Now that all users of pci_get_bus_and_slot() switched to
pci_get_domain_bus_and_slot(), it is now safe to remove this function.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
include/linux/pci.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 66cca1c..04cecbe 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -948,11 +948,6 @@ struct pci_dev *pci_get_subsys(unsigned int vendor, unsigned int device,
struct pci_dev *pci_get_slot(struct pci_bus *bus, unsigned int devfn);
struct pci_dev *pci_get_domain_bus_and_slot(int domain, unsigned int bus,
unsigned int devfn);
-static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
- unsigned int devfn)
-{
- return pci_get_domain_bus_and_slot(0, bus, devfn);
-}
struct pci_dev *pci_get_class(unsigned int class, struct pci_dev *from);
int pci_dev_present(const struct pci_device_id *ids);
@@ -1660,9 +1655,6 @@ static inline struct pci_bus *pci_find_next_bus(const struct pci_bus *from)
static inline struct pci_dev *pci_get_slot(struct pci_bus *bus,
unsigned int devfn)
{ return NULL; }
-static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
- unsigned int devfn)
-{ return NULL; }
static inline struct pci_dev *pci_get_domain_bus_and_slot(int domain,
unsigned int bus, unsigned int devfn)
{ return NULL; }
--
1.9.1
^ permalink raw reply related
* [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Baruch Siach @ 2017-12-19 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219013233.319365c4@xps13>
Hi Miqu?l,
On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> On Mon, 18 Dec 2017 22:35:42 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > > Bindings were incomplete for a long time by only exposing one of
> > > the two available control registers. To ease the migration to the
> > > full bindings (already in use for the Armada 375 SoC), rename the
> > > pointers for clarification. This way, it will only be needed to add
> > > another pointer to access the other control register when the time
> > > comes.
> > >
> > > This avoids dangerous situations where the offset 0 of the control
> > > area can be either one register or the other depending on the
> > > bindings used. After this change, device trees of other SoCs could
> > > be migrated to the "full" bindings if they may benefit from
> > > features from the unaccessible register, without any change in the
> > > driver.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > > ---
> >
> > [...]
> >
> > > + /*
> > > + * Legacy DT bindings only described "control1" register
> > > (also referred
> > > + * as "control MSB" on old documentation). New bindings
> > > cover
> > > + * "control0/control LSB" and "control1/control MSB"
> > > registers within
> > > + * the same resource, which is then of size 8 instead of 4.
> > > + */
> > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > + /* ->control0 unavailable in this configuration */
> > > + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > > + } else {
> > > + priv->control0 = control + CONTROL0_OFFSET;
> > > + priv->control1 = control + CONTROL1_OFFSET;
> > > + }
> >
> > The needs_control0 field that you mentioned in the cover page is
> > missing here.
>
> Yes, at this point nobody actually *needs* control0 so the limitation
> is added with the patch that introduce ap806 support as it is the first
> compatible that needs both control0 and control1 to work correctly.
> Does this bother you?
No. It is just that we agreed to have a verification here that the size of the
control registers resource matches the binding. I thought that the
needs_control0 field that you mention in the cover page is meant to implement
that. But I'm not sure all that is strictly necessary. It would just make sure
that no one introduces a DT with the wrong resource size.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-19 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219014320.182d2522@xps13>
Hi Miqu?l,
On Tue, Dec 19, 2017 at 01:43:20AM +0100, Miquel RAYNAL wrote:
> On Mon, 18 Dec 2017 22:33:24 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > > From: Baruch Siach <baruch@tkos.co.il>
> > >
> > > Add compatible strings for AP806 and CP110 that are part of the
> > > Armada 8k/7k line of SoCs.
> > >
> > > Add a note on the differences in the size of the control area in
> > > different bindings. This is an existing difference between the
> > > Armada 375 binding and the other boards already supported. The new
> > > AP806 and CP110 bindings are similar to the existing Armada 375 in
> > > this regard.
> > >
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > [<miquel.raynal@free-electrons.com>: reword, additional details]
> > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > ---
> > > .../devicetree/bindings/thermal/armada-thermal.txt | 24
> > > +++++++++++++++++----- 1 file changed, 19 insertions(+), 5
> > > deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > index 24aacf8948c5..9b7b2c03cc6f 100644 ---
> > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++
> > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@
> > > -7,17 +7,31 @@ Required properties: marvell,armada375-thermal
> > > marvell,armada380-thermal marvell,armadaxp-thermal
> > > + marvell,armada-ap806-thermal
> > > + marvell,armada-cp110-thermal
> > >
> > > - reg: Device's register space.
> > > Two entries are expected, see the examples below.
> > > - The first one is required for the sensor register;
> > > - the second one is required for the control register
> > > - to be used for sensor initialization (a.k.a.
> > > calibration).
> > > + The first one points to the status register (4B).
> > > + The second one points to the control registers
> > > (8B).
> > > + Note: with legacy bindings, the second entry
> > > pointed
> > > + only to the so called "control MSB" ("control 1"),
> > > was
> > > + 4B wide and did not let the possibility to reach
> > > the
> > > + "control LSB" ("control 0") register. This is only
> > > + allowed for compatibility reasons in Armada
> > > + 370/375/38x/XP DT nodes.
> >
> > "allowed" is not the right term, IMO. Legacy compatibles MUST point
> > to the MSB control register to preserve compatibility with existing
> > DTs.
> >
> > The original patch had a list of legacy and non-legacy compatibles. I
> > think we need to keep them.
>
> Maybe I should reword this paragraph because we both agree on the
> meaning:
>
> "
> Note: Legacy bindings are only supported with Armada 370/375/38x/XP
> compatibles. The second memory resource entry only points to
> "control MSB/control 1", is 4 bytes wide and is preventing any access
> to "control LSB/control 0".
> "
>
> Does this sounds better to you?
I think we need to explicitly list the affected compatible strings. Something
like:
For backwards compatibility reasons, the compatibles
marvell,armada370-thermal, marvell,armada380-thermal, and
marvell,armadaxp-thermal must point to "control MSB/control 1", with size of
4. All other compatibles must point to "control LSB/control 0" with size of
8.
But I think you are right that we can use the size of the control registers to
tell whether e.g. marvell,armada380-thermal is of the old binding of the new
one. So maybe the "allow" language is more correct. But let's make it explicit
to avoid any doubt. How about:
The compatibles marvell,armada370-thermal, marvell,armada380-thermal, and
marvell,armadaxp-thermal must point to "control MSB/control 1", with size of
4 (deprecated binding), or point to "control LSB/control 0" with size of 8
(current binding). All other compatibles must point to "control LSB/control
0" with size of 8.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-19 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218054009.GA6392@dhcp-128-65.nay.redhat.com>
On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> > > On 13 December 2017 at 12:16, AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> > > >> <takahiro.akashi@linaro.org> wrote:
> > > >> > Bhupesh, Ard,
> > > >> >
> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> > > >> >> Hi Ard, Akashi
> > > >> >>
> > > >> > (snip)
> > > >> >
> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> > > >> >> identify its own usable memory and exclude, at its boot time, any
> > > >> >> other memory areas that are part of the panicked kernel's memory.
> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> > > >> >> , for details)
> > > >> >
> > > >> > Right.
> > > >> >
> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> > > >> >> with the crashkernel memory range:
> > > >> >>
> > > >> >> /* add linux,usable-memory-range */
> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> > > >> >> address_cells, size_cells);
> > > >> >>
> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> > > >> >> , for details)
> > > >> >>
> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> > > >> >> they are marked as System RAM or as RESERVED. As,
> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> > > >> >>
> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> > > >> >> ACPI memory and crashes while trying to access the same:
> > > >> >>
> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > >> >> -r`.img --reuse-cmdline -d
> > > >> >>
> > > >> >> [snip..]
> > > >> >>
> > > >> >> Reserved memory range
> > > >> >> 000000000e800000-000000002e7fffff (0)
> > > >> >>
> > > >> >> Coredump memory ranges
> > > >> >> 0000000000000000-000000000e7fffff (0)
> > > >> >> 000000002e800000-000000003961ffff (0)
> > > >> >> 0000000039d40000-000000003ed2ffff (0)
> > > >> >> 000000003ed60000-000000003fbfffff (0)
> > > >> >> 0000001040000000-0000001ffbffffff (0)
> > > >> >> 0000002000000000-0000002ffbffffff (0)
> > > >> >> 0000009000000000-0000009ffbffffff (0)
> > > >> >> 000000a000000000-000000affbffffff (0)
> > > >> >>
> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> > > >> >> memory cap'ing passed to the crash kernel inside
> > > >> >> 'arch/arm64/mm/init.c' (see below):
> > > >> >>
> > > >> >> static void __init fdt_enforce_memory_region(void)
> > > >> >> {
> > > >> >> struct memblock_region reg = {
> > > >> >> .size = 0,
> > > >> >> };
> > > >> >>
> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> > > >> >>
> > > >> >> if (reg.size)
> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> > > >> >> comment this out */
> > > >> >> }
> > > >> >
> > > >> > Please just don't do that. It can cause a fatal damage on
> > > >> > memory contents of the *crashed* kernel.
> > > >> >
> > > >> >> 5). Both the above temporary solutions fix the problem.
> > > >> >>
> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> > > >> >> fail.
> > > >> >>
> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> > > >> >> dt node 'linux,usable-memory-range'
> > > >> >
> > > >> > I still don't understand why we need to carry over the information
> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> > > >> > such regions are free to be reused by the kernel after some point of
> > > >> > initialization. Why does crash dump kernel need to know about them?
> > > >> >
> > > >>
> > > >> Not really. According to the UEFI spec, they can be reclaimed after
> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> > > >> no longer needs them. Of course, in order to be able to boot a kexec
> > > >> kernel, those regions needs to be preserved, which is why they are
> > > >> memblock_reserve()'d now.
> > > >
> > > > For my better understandings, who is actually accessing such regions
> > > > during boot time, uefi itself or efistub?
> > > >
> > >
> > > No, only the kernel. This is where the ACPI tables are stored. For
> > > instance, on QEMU we have
> > >
> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> > > 01000013)
> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> > > BXPC 00000001)
> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> > > BXPC 00000001)
> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> > > BXPC 00000001)
> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> > > BXPC 00000001)
> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> > > BXPC 00000001)
> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> > > BXPC 00000001)
> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> > > BXPC 00000001)
> > >
> > > covered by
> > >
> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> > > ...
> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >
> > OK. I mistakenly understood those regions could be freed after exiting
> > UEFI boot services.
> >
> > >
> > > >> So it seems that kexec does not honour the memblock_reserve() table
> > > >> when booting the next kernel.
> > > >
> > > > not really.
> > > >
> > > >> > (In other words, can or should we skip some part of ACPI-related init code
> > > >> > on crash dump kernel?)
> > > >> >
> > > >>
> > > >> I don't think so. And the change to the handling of ACPI reclaim
> > > >> regions only revealed the bug, not created it (given that other
> > > >> memblock_reserve regions may be affected as well)
> > > >
> > > > As whether we should honor such reserved regions over kexec'ing
> > > > depends on each one's specific nature, we will have to take care one-by-one.
> > > > As a matter of fact, no information about "reserved" memblocks is
> > > > exposed to user space (via proc/iomem).
> > > >
> > >
> > > That is why I suggested (somewhere in this thread?) to not expose them
> > > as 'System RAM'. Do you think that could solve this?
> >
> > Memblock-reserv'ing them is necessary to prevent their corruption and
> > marking them under another name in /proc/iomem would also be good in order
> > not to allocate them as part of crash kernel's memory.
> >
> > But I'm not still convinced that we should export them in useable-
> > memory-range to crash dump kernel. They will be accessed through
> > acpi_os_map_memory() and so won't be required to be part of system ram
> > (or memblocks), I guess.
> > -> Bhupesh?
>
> I forgot how arm64 kernel retrieve the memory ranges and initialize
> them. If no "e820" like interfaces shouldn't kernel reinitialize all
> the memory according to the efi memmap? For kdump kernel anything other
> than usable memory (which is from the dt node instead) should be
> reinitialized according to efi passed info, no?
All the regions exported in efi memmap will be added to memblock.memory
in (u)efi_init() and then trimmed down to the exact range specified as
usable-memory-range by fdt_enforce_memory_region().
Now I noticed that the current fdt_enforce_memory_region() may not work well
with multiple entries in usable-memory-range.
> >
> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> > via a kernel command line parameter, "memmap=".
>
> memmap= is only used in old kexec-tools, now we are passing them via
> e820 table.
Thanks. I remember that you have explained it before.
-Takahiro AKASHI
> [snip]
>
> Thanks
> Dave
^ permalink raw reply
* [RFC PATCH 5/5] ARM: NOMMU: Support PMSAv8 MPU
From: afzal mohammed @ 2017-12-19 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c64f605-462b-728c-36d7-e8380c3f16db@arm.com>
Hi,
On Mon, Dec 18, 2017 at 11:47:04AM +0000, Vladimir Murzin wrote:
> > Is there a public ARMv8-R architecture reference manual available ?,
> you might get PMSA-v8 related information from Cortex-R52 TRM [1].
>
> [1] https://developer.arm.com/docs/100026/latest/preface
Thanks Vladimir.
Got a ARMv8-R ARM supplement to ARMv8-A ARM,
https://static.docs.arm.com/ddi0568/a/DDI0568A_b_armv8_r_supplement.pdf
> Not sure why it is not there yet
Cortex-R mafia again ;)
afzal
^ permalink raw reply
* [GIT PULL] TI DaVinci fixes for v4.15
From: Sekhar Nori @ 2017-12-19 6:15 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.15
for you to fetch changes up to 451df7d110b82998c04a80d0de0f1e79aaa7792a:
ARM: davinci: fix mmc entries in dm365's dma_slave_map (2017-12-08 16:12:21 +0530)
----------------------------------------------------------------
DaVinci fixes for v4.15 consiting of fixes to make EDMA and MMC/SD
work on DM365 and a fix for battery voltage monitoring on Lego EV3.
----------------------------------------------------------------
Alejandro Mery (3):
ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA
ARM: davinci: Add dma_mask to dm365's eDMA device
ARM: davinci: fix mmc entries in dm365's dma_slave_map
David Lechner (1):
ARM: dts: da850-lego-ev3: Fix battery voltage gpio
arch/arm/boot/dts/da850-lego-ev3.dts | 4 ++--
arch/arm/mach-davinci/dm365.c | 29 ++++++++++++++++++-----------
2 files changed, 20 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Linu Cherian @ 2017-12-19 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <999b7132-2de8-2872-1067-fc7e02cbc57a@arm.com>
Hi Robin,
On Mon Dec 18, 2017 at 02:48:14PM +0000, Robin Murphy wrote:
> On 10/12/17 02:35, Linu Cherian wrote:
> >Hi,
> >
> >
> >On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
> >>This adds a driver for the SMMUv3 PMU into the perf framework.
> >>It includes an IORT update to support PM Counter Groups.
> >>
> >
> >In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
> >that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
> >This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
> >are managed by two independent drivers.
> >
> >The problem arises when we want to alloc/free MSIs for these devices
> >using the APIs, platform_msi_domain_alloc/free_irqs.
> >Platform bus id being same for these two hardware blocks, they end up sharing the same
> >ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
> >of this shared ITT becomes a problem when they are managed by two independent
> >drivers.
>
> What is the problem exactly? IIRC resizing a possibly-live ITT is a
> right pain in the bum to do - is it just that?
Yes exactly. Resizing ITT was the problem in sharing.
> >We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
> >SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
> >required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
> >function call for all devices that share the platform bus id.
>
> I'm not sure how scalable that approach would be, since it's not
> entirely obvious how to handle PMCGs associated with named
> components or root complexes (rather than directly with SMMU
> instances). We certainly don't want to end up spraying similar PMCG
> DevID logic around all manner of GPU/accelerator/etc. drivers in
> future (whilst PMCGs for device TLBs will be expected to have
> distinct IDs from their host devices, they could reasonably still
> overlap with other PMCGs/SMMUs).
>
OK.
While trying the above approach, we also felt that the code will become
lot messier than actually thought.
> >Would like to know your expert opinion on what would be the right approach
> >to handle this case ?
>
> My gut feeling says the way to deal with this properly is in the ITS
> code, but I appreciate that that's a lot easier said than done :/
>
Yes Correct.
> Robin.
--
Linu cherian
^ permalink raw reply
* [PATCH 0/3] Add i2c dt-binding and compatible for Mediatek MT2712
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch series based on v4.15-rc1, include MT2712 i2c dt-binding, compatible
and i2c module clock enable.
Jun Gao (3):
dt-bindings: i2c: Add MediaTek MT2712 i2c binding
i2c: mediatek: Add i2c compatible for MediaTek MT2712
i2c: mediatek: Enable i2c module clock before i2c registers access.
Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
drivers/i2c/busses/i2c-mt65xx.c | 40 ++++++++++++++++++++---
2 files changed, 37 insertions(+), 4 deletions(-)
--
1.8.1.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: i2c: Add MediaTek MT2712 i2c binding
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add MT2712 i2c binding to binding file. Compare to MT8173 i2c
controller, MT2712 has timing adjust registers which can adjust
the internal divider of i2c source clock, SCL duty cycle, SCL
compare point, start(repeated start) and stop time, SDA change
time.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index ff7bf37..e199695 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -5,6 +5,7 @@ The MediaTek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
"mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
+ "mediatek,mt2712-i2c": for MediaTek MT2712
"mediatek,mt6577-i2c": for MediaTek MT6577
"mediatek,mt6589-i2c": for MediaTek MT6589
"mediatek,mt7622-i2c": for MediaTek MT7622
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/3] i2c: mediatek: Add i2c compatible for MediaTek MT2712
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add i2c compatible for MT2712. Compare to MT8173 i2c controller,
internal divider of i2c source clock need to be configured for
MT2712 i2c speed calculation.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 09d288c..58d6401 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -61,6 +61,7 @@
#define I2C_DMA_HARD_RST 0x0002
#define I2C_DMA_4G_MODE 0x0001
+#define I2C_DEFAULT_CLK_DIV 5
#define I2C_DEFAULT_SPEED 100000 /* hz */
#define MAX_FS_MODE_SPEED 400000
#define MAX_HS_MODE_SPEED 3400000
@@ -127,6 +128,7 @@ enum I2C_REGS_OFFSET {
OFFSET_DEBUGSTAT = 0x64,
OFFSET_DEBUGCTRL = 0x68,
OFFSET_TRANSFER_LEN_AUX = 0x6c,
+ OFFSET_CLOCK_DIV = 0x70,
};
struct mtk_i2c_compatible {
@@ -136,6 +138,7 @@ struct mtk_i2c_compatible {
unsigned char auto_restart: 1;
unsigned char aux_len_reg: 1;
unsigned char support_33bits: 1;
+ unsigned char timing_adjust: 1;
};
struct mtk_i2c {
@@ -176,6 +179,15 @@ struct mtk_i2c {
.max_num_msgs = 255,
};
+static const struct mtk_i2c_compatible mt2712_compat = {
+ .pmic_i2c = 0,
+ .dcm = 1,
+ .auto_restart = 1,
+ .aux_len_reg = 1,
+ .support_33bits = 1,
+ .timing_adjust = 1,
+};
+
static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = &mt6577_i2c_quirks,
.pmic_i2c = 0,
@@ -183,6 +195,7 @@ struct mtk_i2c {
.auto_restart = 0,
.aux_len_reg = 0,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt6589_compat = {
@@ -192,6 +205,7 @@ struct mtk_i2c {
.auto_restart = 0,
.aux_len_reg = 0,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt7622_compat = {
@@ -201,6 +215,7 @@ struct mtk_i2c {
.auto_restart = 1,
.aux_len_reg = 1,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt8173_compat = {
@@ -209,9 +224,11 @@ struct mtk_i2c {
.auto_restart = 1,
.aux_len_reg = 1,
.support_33bits = 1,
+ .timing_adjust = 0,
};
static const struct of_device_id mtk_i2c_of_match[] = {
+ { .compatible = "mediatek,mt2712-i2c", .data = &mt2712_compat },
{ .compatible = "mediatek,mt6577-i2c", .data = &mt6577_compat },
{ .compatible = "mediatek,mt6589-i2c", .data = &mt6589_compat },
{ .compatible = "mediatek,mt7622-i2c", .data = &mt7622_compat },
@@ -271,6 +288,9 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
if (i2c->dev_comp->dcm)
writew(I2C_DCM_DISABLE, i2c->base + OFFSET_DCM_EN);
+ if (i2c->dev_comp->timing_adjust)
+ writew(I2C_DEFAULT_CLK_DIV - 1, i2c->base + OFFSET_CLOCK_DIV);
+
writew(i2c->timing_reg, i2c->base + OFFSET_TIMING);
writew(i2c->high_speed_reg, i2c->base + OFFSET_HS);
@@ -725,10 +745,6 @@ static int mtk_i2c_probe(struct platform_device *pdev)
if (!i2c)
return -ENOMEM;
- ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
- if (ret)
- return -EINVAL;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
i2c->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(i2c->base))
@@ -759,6 +775,13 @@ static int mtk_i2c_probe(struct platform_device *pdev)
i2c->adap.timeout = 2 * HZ;
i2c->adap.retries = 1;
+ ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
+ if (ret)
+ return -EINVAL;
+
+ if (i2c->dev_comp->timing_adjust)
+ i2c->clk_src_div *= I2C_DEFAULT_CLK_DIV;
+
if (i2c->have_pmic && !i2c->dev_comp->pmic_i2c)
return -EINVAL;
--
1.8.1.1
^ permalink raw reply related
* [PATCH 3/3] i2c: mediatek: Enable i2c module clock before i2c registers access.
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Make sure i2c module clock has been enabled before i2c registers
access.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 58d6401..cf23a74 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -861,10 +861,19 @@ static int mtk_i2c_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int mtk_i2c_resume(struct device *dev)
{
+ int ret;
struct mtk_i2c *i2c = dev_get_drvdata(dev);
+ ret = mtk_i2c_clock_enable(i2c);
+ if (ret) {
+ dev_err(dev, "clock enable failed!\n");
+ return ret;
+ }
+
mtk_i2c_init_hw(i2c);
+ mtk_i2c_clock_disable(i2c);
+
return 0;
}
#endif
--
1.8.1.1
^ permalink raw reply related
* [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Linu Cherian @ 2017-12-19 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7312293d-8897-95d8-9045-9e97a6c150eb@arm.com>
Hi Marc,
On Mon Dec 18, 2017 at 03:39:22PM +0000, Marc Zyngier wrote:
> Thanks for putting me in the loop Robin.
>
> On 18/12/17 14:48, Robin Murphy wrote:
> > On 10/12/17 02:35, Linu Cherian wrote:
> >> Hi,
> >>
> >>
> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
> >>> This adds a driver for the SMMUv3 PMU into the perf framework.
> >>> It includes an IORT update to support PM Counter Groups.
> >>>
> >>
> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
> >> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
> >> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
> >> are managed by two independent drivers.
> >>
> >> The problem arises when we want to alloc/free MSIs for these devices
> >> using the APIs, platform_msi_domain_alloc/free_irqs.
> >> Platform bus id being same for these two hardware blocks, they end up sharing the same
> >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
> >> of this shared ITT becomes a problem when they are managed by two independent
> >> drivers.
> >
> > What is the problem exactly? IIRC resizing a possibly-live ITT is a
> > right pain in the bum to do - is it just that?
>
> Understatement of the day! ;-) Yes, it is a massive headache, and will
> either result in a temporary loss of interrupts (at some point you have
> to unmap the ITT), or with spurious interrupts (you generate interrupts
> for all the MSIs you've blackholed when unmapping the ITT).
Just sharing a thought.
If the firmware, through device tree/ACPI
can provide the following input to the ITS driver,
(For example, as part of msi-parent property in device tree)
1. flag indicating the ITT (Device ID) is being shared
2. the maximum number of vectors that are required to be allocated for this ITT
resizing of ITT and the associated complexities could be avoided.
>
> >
> >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
> >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
> >> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
> >> function call for all devices that share the platform bus id.
> >
> > I'm not sure how scalable that approach would be, since it's not
> > entirely obvious how to handle PMCGs associated with named components or
> > root complexes (rather than directly with SMMU instances). We certainly
> > don't want to end up spraying similar PMCG DevID logic around all manner
> > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs
> > will be expected to have distinct IDs from their host devices, they
> > could reasonably still overlap with other PMCGs/SMMUs).
> >
> >> Would like to know your expert opinion on what would be the right approach
> >> to handle this case ?
> >
> > My gut feeling says the way to deal with this properly is in the ITS
> > code, but I appreciate that that's a lot easier said than done :/
>
> I can revive the hack I once wrote for that (and that was hoping to
> forever forget), but that's pretty disgusting, and subject to the above
> caveat.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Linu cherian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox