* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-12-01 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201123009.d2b4d9d389070200c54138ee@free.fr>
On Thursday 01 Dec 2016 12:30:09 Jean-Francois Moine wrote:
> On Thu, 01 Dec 2016 12:41:20 +0200 Laurent Pinchart wrote:
> >>> If a DVI connector instead of a HDMI connector is soldered, how
> >>> should such a device tree be written?
> >>
> >> Use a dvi-connector instead :)
> >
> > The HDMI encoder DT node doesn't (and certainly shouldn't) report what
> > type of connector is mounted on the board. Having a connector node in DT
> > makes the connector type available to the system, allowing the DRM driver
> > to expose the right connector type to userspace (it would be confusing
> > for the user to report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).
>
> The connector type, HDMI or DVI, is known by the EDID.
> The user is not interested by the software indication of the connector
> type: (s)he knows it because (s)he connected him/herself the display
> device.
That's not correct. The connector type reported by DRM to userspace can be
used as a hint to information the user about connectors. Displaying a "Please
connect a monitor to the HDMI connector" is confusing when the system has a
DVI connector.
> And the DRM driver does not do anything from the knowledge of the
> connector type in the DT. Only the EDID may tell if the display device
> may do audio streaming (direct HDMI with audio capability) or not
> (direct HDMI without audio, HDMI to DVI cable, DVI physical connector).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Marcin Wojtas @ 2016-12-01 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201192604.07ed9516@xhacker>
Hi Jisheng,
Which baseline do you use?
It took me really lot of time to catch why RX broke after rebase from
LKv4.1 to LKv4.4. Between those two, in commit:
97303480753e ("arm64: Increase the max granular size")
L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
did NET_SKB_PAD.
And 128 is more than the maximum that can fit into packet offset
[11:8]@0x1400. In such case this correction is needed. Did it answer
your doubts?
Best regards,
Marcin
2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> Hi Gregory, Marcin,
>
> On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
>
>> From: Marcin Wojtas <mw@semihalf.com>
>>
>> Prepare the mvneta driver in order to be usable on the 64 bits platform
>> such as the Armada 3700.
>>
>> [gregory.clement at free-electrons.com]: this patch was extract from a larger
>> one to ease review and maintenance.
>>
>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>> index 92b9af14c352..8ef03fb69bcd 100644
>> --- a/drivers/net/ethernet/marvell/mvneta.c
>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>> @@ -296,6 +296,12 @@
>> /* descriptor aligned size */
>> #define MVNETA_DESC_ALIGNED_SIZE 32
>>
>> +/* Number of bytes to be taken into account by HW when putting incoming data
>> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
>> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
>
> We also brought up this driver on 64bit platforms, we doesn't have this
> patch. Maybe I'm wrong, I'm trying to understand why we need this
> modification. Let's assume the NET_SKB_PAD is 64B, we call
> mvneta_rxq_offset_set(pp, rxq, 64),
>
> {
> u32 val;
>
> val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
> val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
>
> /* Offset is in */
> val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
> // then this will be "val |= 8;" it doesn't exceeds the max offset of
> MVNETA_RXQ_CONFIG_REG(q) register.
>
> Could you please kindly point out where I am wrong?
>
>> + */
>> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
>> +
>> #define MVNETA_RX_PKT_SIZE(mtu) \
>> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
>> ETH_HLEN + ETH_FCS_LEN, \
>> @@ -416,6 +422,7 @@ struct mvneta_port {
>> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
>>
>> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
>> + u16 rx_offset_correction;
>> };
>>
>> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
>> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
>> return -ENOMEM;
>> }
>>
>> + phys_addr += pp->rx_offset_correction;
>> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
>> return 0;
>> }
>> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
>> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
>>
>> /* Set Offset */
>> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
>> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
>>
>> /* Set coalescing pkts and time */
>> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
>> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
>>
>> pp->rxq_def = rxq_def;
>>
>> + /* Set RX packet offset correction for platforms, whose
>> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
>> + * platforms and 0B for 32-bit ones.
>
> Even we need this patch, I'm not sure this last comment is correct or not.
> NET_SKB_PAD is defined as:
>
> #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
>
> we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
> should be 64B as well.
>
> Thanks,
> Jisheng
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Sricharan @ 2016-12-01 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201112917.GA9680@red-moon>
Hi Robin,Lorenzo,
>On Wed, Nov 30, 2016 at 04:42:27PM +0000, Robin Murphy wrote:
>> On 30/11/16 16:17, Lorenzo Pieralisi wrote:
>> > Sricharan, Robin,
>> >
>> > I gave this series a go on ACPI and apart from an SMMU v3 fix-up
>> > it seems to work, more thorough testing required though.
>> >
>> > A key question below.
>> >
>> > On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
>> >> From: Robin Murphy <robin.murphy@arm.com>
>> >>
>> >> IOMMU configuration represents unchanging properties of the hardware,
>> >> and as such should only need happen once in a device's lifetime, but
>> >> the necessary interaction with the IOMMU device and driver complicates
>> >> exactly when that point should be.
>> >>
>> >> Since the only reasonable tool available for handling the inter-device
>> >> dependency is probe deferral, we need to prepare of_iommu_configure()
>> >> to run later than it is currently called (i.e. at driver probe rather
>> >> than device creation), to handle being retried, and to tell whether a
>> >> not-yet present IOMMU should be waited for or skipped (by virtue of
>> >> having declared a built-in driver or not).
>> >>
>> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> >> ---
>> >> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
>> >> 1 file changed, 29 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> >> index ee49081..349bd1d 100644
>> >> --- a/drivers/iommu/of_iommu.c
>> >> +++ b/drivers/iommu/of_iommu.c
>> >> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>> >> int err;
>> >>
>> >> ops = iommu_get_instance(fwnode);
>> >> - if (!ops || !ops->of_xlate)
>> >> + if ((ops && !ops->of_xlate) ||
>> >> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
>> >
>> > IIUC of_match_node() here is there to check there is a driver compiled
>> > in for this device_node (aka compatible string in OF world), correct ?
>>
>> Yes - specifically, it's checking the magic table for a matching
>> IOMMU_OF_DECLARE entry.
>>
>> > If that's the case (and I think that's what Sricharan was referring to
>> > in his ACPI query) I need to cook-up something on the ACPI side to
>> > emulate the OF linker table behaviour (or anyway to detect a driver is
>> > actually in the kernel), it is not that difficult but it is key to know,
>> > I will give it some thought to make it as clean as possible.
>>
>> I didn't think this would be a concern for ACPI, since IORT works much
>> the same way the current of_iommu_init_fn/of_platform_device_create()
>> bodges in drivers so for DT. If you can only discover SMMUs from IORT,
>> then iort_init_platform_devices() will have already created every SMMU
>> that's going to exist before discovering other devices from wherever
>> they come from, thus you could never get into the situation of probing a
>> device without its SMMU being ready (if it's ever going to be). Is that
>> not right?
>
>It is right, my point and question is: we are probing a device and we
>have to know whether it is worth deferring its IOMMU DMA setup. On DT,
>through of_match_node(&__iommu_of_table, iommu_device_node) we check at
>once that:
>
>1 - A device for the IOMMU exists
>
>AND
>
>2 - A driver for the IOMMU is compiled in the kernel
>
>Is this correct ? As you said (1) is not a concern on ACPI IORT (because
>we create the IOMMU device before _any_ other device so either the IOMMU
>device is there or it will never be by the time master devices are
>probed), but for (2) I need to slightly change how the IORT linker entry
>work to make sure we can detect a driver is actually compiled in the
>kernel, it is easy, I was just asking if my understanding was correct
>and I think that was what Sricharan was referring to in his query.
>
Yes right, this was what i was looking for in the ACPI case and putting this
in the iort_iommu_xlate was needed to return EPROBE_DEFER when the
driver is not yet been probed.
Regards,
Sricharan
^ permalink raw reply
* [RFC PATCH] PCI: designware: add host_init() error handling
From: Srinivas Kandagatla @ 2016-12-01 11:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch add support to return value from host_init() callback from
drivers,so that the designware library can handle or pass it to proper
place. Issue with void return type is that errors or error handling
within host_init() callback are never know to designware code, which
could go ahead and access registers even in error cases.
Typical case in qcom controller driver is to turn off clks in case of
errors, if designware code continues to read/write register when clocks
are turned off the board would reboot/lockup.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Currently designware code does not have a way return errors generated
as part of host_init() callback in controller drivers. This is an issue
with controller drivers like qcom which turns off the clocks in error
handling path. As the dw core is un aware of this would continue to
access registers which faults resulting in board reboots/hangs.
There are two ways to solve this issue,
one is remove error handling in the qcom controller host_init() function
other is to handle error and pass back to dw core code which would then
pass back to controller driver as part of dw_pcie_host_init() return value.
Second option seems more sensible and correct way to fix the issue,
this patch does the same.
As part of this change to host_init() return type I had to patch other
host controller drivers which use dw core. Most of these changes are
harmless as I have not added any extra code other then returning 0
from host_init().
drivers/pci/host/pci-dra7xx.c | 4 +++-
drivers/pci/host/pci-exynos.c | 4 +++-
drivers/pci/host/pci-imx6.c | 4 +++-
drivers/pci/host/pci-keystone.c | 4 +++-
drivers/pci/host/pci-layerscape.c | 12 ++++++++----
drivers/pci/host/pcie-armada8k.c | 4 +++-
drivers/pci/host/pcie-designware-plat.c | 4 +++-
drivers/pci/host/pcie-designware.c | 4 +++-
drivers/pci/host/pcie-designware.h | 2 +-
drivers/pci/host/pcie-qcom.c | 6 ++++--
drivers/pci/host/pcie-spear13xx.c | 4 +++-
11 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 9595fad..f63491c 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -127,7 +127,7 @@ static void dra7xx_pcie_enable_interrupts(struct dra7xx_pcie *dra7xx)
LEG_EP_INTERRUPTS);
}
-static void dra7xx_pcie_host_init(struct pcie_port *pp)
+static int dra7xx_pcie_host_init(struct pcie_port *pp)
{
struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
@@ -142,6 +142,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
dra7xx_pcie_enable_interrupts(dra7xx);
+
+ return 0;
}
static struct pcie_host_ops dra7xx_pcie_host_ops = {
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index f1c544b..b5a8f11 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -458,12 +458,14 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
return 0;
}
-static void exynos_pcie_host_init(struct pcie_port *pp)
+static int exynos_pcie_host_init(struct pcie_port *pp)
{
struct exynos_pcie *exynos_pcie = to_exynos_pcie(pp);
exynos_pcie_establish_link(exynos_pcie);
exynos_pcie_enable_interrupts(exynos_pcie);
+
+ return 0;
}
static struct pcie_host_ops exynos_pcie_host_ops = {
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index c8cefb0..4844367 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -550,7 +550,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
return ret;
}
-static void imx6_pcie_host_init(struct pcie_port *pp)
+static int imx6_pcie_host_init(struct pcie_port *pp)
{
struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
@@ -562,6 +562,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
+
+ return 0;
}
static int imx6_pcie_link_up(struct pcie_port *pp)
diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
index 043c19a..fded7f9 100644
--- a/drivers/pci/host/pci-keystone.c
+++ b/drivers/pci/host/pci-keystone.c
@@ -260,7 +260,7 @@ static int keystone_pcie_fault(unsigned long addr, unsigned int fsr,
return 0;
}
-static void __init ks_pcie_host_init(struct pcie_port *pp)
+static int __init ks_pcie_host_init(struct pcie_port *pp)
{
struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
u32 val;
@@ -287,6 +287,8 @@ static void __init ks_pcie_host_init(struct pcie_port *pp)
*/
hook_fault_code(17, keystone_pcie_fault, SIGBUS, 0,
"Asynchronous external abort");
+
+ return 0;
}
static struct pcie_host_ops keystone_pcie_host_ops = {
diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
index 6537079..d3a7266 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -103,7 +103,7 @@ static int ls1021_pcie_link_up(struct pcie_port *pp)
return 1;
}
-static void ls1021_pcie_host_init(struct pcie_port *pp)
+static int ls1021_pcie_host_init(struct pcie_port *pp)
{
struct device *dev = pp->dev;
struct ls_pcie *pcie = to_ls_pcie(pp);
@@ -114,19 +114,21 @@ static void ls1021_pcie_host_init(struct pcie_port *pp)
if (IS_ERR(pcie->scfg)) {
dev_err(dev, "No syscfg phandle specified\n");
pcie->scfg = NULL;
- return;
+ return 0;
}
if (of_property_read_u32_array(dev->of_node,
"fsl,pcie-scfg", index, 2)) {
pcie->scfg = NULL;
- return;
+ return 0;
}
pcie->index = index[1];
dw_pcie_setup_rc(pp);
ls_pcie_drop_msg_tlp(pcie);
+
+ return 0;
}
static int ls_pcie_link_up(struct pcie_port *pp)
@@ -144,7 +146,7 @@ static int ls_pcie_link_up(struct pcie_port *pp)
return 1;
}
-static void ls_pcie_host_init(struct pcie_port *pp)
+static int ls_pcie_host_init(struct pcie_port *pp)
{
struct ls_pcie *pcie = to_ls_pcie(pp);
@@ -153,6 +155,8 @@ static void ls_pcie_host_init(struct pcie_port *pp)
ls_pcie_clear_multifunction(pcie);
ls_pcie_drop_msg_tlp(pcie);
iowrite32(0, pcie->pp.dbi_base + PCIE_DBI_RO_WR_EN);
+
+ return 0;
}
static int ls_pcie_msi_host_init(struct pcie_port *pp,
diff --git a/drivers/pci/host/pcie-armada8k.c b/drivers/pci/host/pcie-armada8k.c
index 0ac0f18..29bdd8b 100644
--- a/drivers/pci/host/pcie-armada8k.c
+++ b/drivers/pci/host/pcie-armada8k.c
@@ -134,12 +134,14 @@ static void armada8k_pcie_establish_link(struct armada8k_pcie *pcie)
dev_err(pp->dev, "Link not up after reconfiguration\n");
}
-static void armada8k_pcie_host_init(struct pcie_port *pp)
+static int armada8k_pcie_host_init(struct pcie_port *pp)
{
struct armada8k_pcie *pcie = to_armada8k_pcie(pp);
dw_pcie_setup_rc(pp);
armada8k_pcie_establish_link(pcie);
+
+ return 0;
}
static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
diff --git a/drivers/pci/host/pcie-designware-plat.c b/drivers/pci/host/pcie-designware-plat.c
index 8df6312..a4f146a 100644
--- a/drivers/pci/host/pcie-designware-plat.c
+++ b/drivers/pci/host/pcie-designware-plat.c
@@ -35,13 +35,15 @@ static irqreturn_t dw_plat_pcie_msi_irq_handler(int irq, void *arg)
return dw_handle_msi_irq(pp);
}
-static void dw_plat_pcie_host_init(struct pcie_port *pp)
+static int dw_plat_pcie_host_init(struct pcie_port *pp)
{
dw_pcie_setup_rc(pp);
dw_pcie_wait_for_link(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
dw_pcie_msi_init(pp);
+
+ return 0;
}
static struct pcie_host_ops dw_plat_pcie_host_ops = {
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index bed1999..4a81b72 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -638,7 +638,9 @@ int dw_pcie_host_init(struct pcie_port *pp)
}
if (pp->ops->host_init)
- pp->ops->host_init(pp);
+ ret = pp->ops->host_init(pp);
+ if (ret < 0)
+ goto error;
pp->root_bus_nr = pp->busn->start;
if (IS_ENABLED(CONFIG_PCI_MSI)) {
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index a567ea2..eacf18f 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -63,7 +63,7 @@ struct pcie_host_ops {
int (*wr_other_conf)(struct pcie_port *pp, struct pci_bus *bus,
unsigned int devfn, int where, int size, u32 val);
int (*link_up)(struct pcie_port *pp);
- void (*host_init)(struct pcie_port *pp);
+ int (*host_init)(struct pcie_port *pp);
void (*msi_set_irq)(struct pcie_port *pp, int irq);
void (*msi_clear_irq)(struct pcie_port *pp, int irq);
phys_addr_t (*get_msi_addr)(struct pcie_port *pp);
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
index f37c690..14f730a 100644
--- a/drivers/pci/host/pcie-qcom.c
+++ b/drivers/pci/host/pcie-qcom.c
@@ -582,7 +582,7 @@ static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
clk_disable_unprepare(res->pipe_clk);
}
-static void qcom_pcie_host_init(struct pcie_port *pp)
+static int qcom_pcie_host_init(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
int ret;
@@ -611,12 +611,14 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
if (ret)
goto err;
- return;
+ return ret;
err:
qcom_ep_reset_assert(pcie);
phy_power_off(pcie->phy);
err_deinit:
pcie->ops->deinit(pcie);
+
+ return ret;
}
static int qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
diff --git a/drivers/pci/host/pcie-spear13xx.c b/drivers/pci/host/pcie-spear13xx.c
index 3cf197b..5f7ae90 100644
--- a/drivers/pci/host/pcie-spear13xx.c
+++ b/drivers/pci/host/pcie-spear13xx.c
@@ -174,12 +174,14 @@ static int spear13xx_pcie_link_up(struct pcie_port *pp)
return 0;
}
-static void spear13xx_pcie_host_init(struct pcie_port *pp)
+static int spear13xx_pcie_host_init(struct pcie_port *pp)
{
struct spear13xx_pcie *spear13xx_pcie = to_spear13xx_pcie(pp);
spear13xx_pcie_establish_link(spear13xx_pcie);
spear13xx_pcie_enable_interrupts(spear13xx_pcie);
+
+ return 0;
}
static struct pcie_host_ops spear13xx_pcie_host_ops = {
--
2.10.1
^ permalink raw reply related
* [PATCH v14] acpi, apei, arm64: APEI initial support for aarch64.
From: Fu Wei @ 2016-12-01 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201114137.herpemkbg3rqxrc4@pd.tnic>
Hi Borislav,
On 1 December 2016 at 19:41, Borislav Petkov <bp@suse.de> wrote:
> On Wed, Aug 10, 2016 at 09:02:48PM +0800, fu.wei at linaro.org wrote:
>> From: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>>
>> This patch provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> (2)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
>> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>
> ...
>
>> @@ -110,8 +111,27 @@ static inline const char *acpi_get_enable_method(int cpu)
>> }
>>
>> #ifdef CONFIG_ACPI_APEI
>> +/*
>> + * acpi_disable_cmcff is used in drivers/acpi/apei/hest.c for disabling
>> + * IA-32 Architecture Corrected Machine Check (CMC) Firmware-First mode by
>> + * boot parameter(acpi=nocmcff). But we don't have this IA-32 specific
>
> Make that
>
> "... with a kernel command line parameter "acpi=nocmcoff"."
>
> Please fix that up when applying.
>
> With that:
>
> Reviewed-by: Borislav Petkov <bp@suse.de>
Great thanks for your rapidly feedback :-)
will send v15 with that fix immediately
>
> Thanks!
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
> --
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH 0/2] register atmel-ssc as sound DAI w/o platform driver
From: Peter Rosin @ 2016-12-01 11:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
The Atmel SSC is currently not usable as an audio DAI unless someone
registers it with ASoC. This is currently delegated to a platform
driver for every possible audio use, and prevents the SSC from being
used as a cpu DAI with the simple-audio-card driver.
The first patch fixes this.
The second patch simplifies one of these platform drivers, since it
can now rely on the SSC to register itself with ASoC. However, this
may not be a possible simplification for other, older, drivers since
it also requires device tree changes.
Cheers,
Peter
Peter Rosin (2):
misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by
itself
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
.../bindings/sound/axentia,tse850-pcm5142.txt | 5 +--
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
sound/soc/atmel/tse850-pcm5142.c | 23 ++--------
5 files changed, 58 insertions(+), 23 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Peter Rosin @ 2016-12-01 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593549-6464-1-git-send-email-peda@axentia.se>
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
- By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+ - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
Examples:
- PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
#include <linux/of.h>
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ struct device_node *np = ssc->pdev->dev.of_node;
+ int ret;
+ int id;
+
+ ssc->sound_dai = false;
+
+ if (!of_property_read_bool(np, "#sound-dai-cells"))
+ return 0;
+
+ id = of_alias_get_id(np, "ssc");
+ if (id < 0)
+ return id;
+
+ ret = atmel_ssc_set_audio(id);
+ ssc->sound_dai = !ret;
+
+ return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+ if (!ssc->sound_dai)
+ return;
+
+ atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
+ if (ssc_sound_dai_probe(ssc))
+ dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
+
return 0;
}
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
+ ssc_sound_dai_remove(ssc);
+
spin_lock(&user_lock);
list_del(&ssc->list);
spin_unlock(&user_lock);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 7c0f6549898b..fdb545101ede 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -20,6 +20,7 @@ struct ssc_device {
int user;
int irq;
bool clk_from_rk_pin;
+ bool sound_dai;
};
struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
From: Peter Rosin @ 2016-12-01 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593549-6464-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 5 ++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 5b9b38f578bb..fd12ecb35b5c 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
Required properties:
- compatible: "axentia,tse850-pcm5142"
- - axentia,ssc-controller: The phandle of the atmel SSC controller used as
- cpu dai.
+ - axentia,cpu-dai: The phandle of the cpu dai.
- axentia,audio-codec: The phandle of the PCM5142 codec.
- axentia,add-gpios: gpio specifier that controls the mixer.
- axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
@@ -77,7 +76,7 @@ Example:
sound {
compatible = "axentia,tse850-pcm5142";
- axentia,ssc-controller = <&ssc0>;
+ axentia,cpu-dai = <&ssc0>;
axentia,audio-codec = <&codec>;
axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
index ac6a814c8ecf..a72c7d642026 100644
--- a/sound/soc/atmel/tse850-pcm5142.c
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -51,11 +51,7 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include "atmel_ssc_dai.h"
-
struct tse850_priv {
- int ssc_id;
-
struct gpio_desc *add;
struct gpio_desc *loop1;
struct gpio_desc *loop2;
@@ -329,23 +325,20 @@ static int tse850_dt_init(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device_node *codec_np, *cpu_np;
- struct snd_soc_card *card = &tse850_card;
struct snd_soc_dai_link *dailink = &tse850_dailink;
- struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
if (!np) {
dev_err(&pdev->dev, "only device tree supported\n");
return -EINVAL;
}
- cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ cpu_np = of_parse_phandle(np, "axentia,cpu-dai", 0);
if (!cpu_np) {
- dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ dev_err(&pdev->dev, "failed to get cpu dai\n");
return -EINVAL;
}
dailink->cpu_of_node = cpu_np;
dailink->platform_of_node = cpu_np;
- tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
of_node_put(cpu_np);
codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
@@ -415,23 +408,14 @@ static int tse850_probe(struct platform_device *pdev)
return ret;
}
- ret = atmel_ssc_set_audio(tse850->ssc_id);
- if (ret != 0) {
- dev_err(dev,
- "failed to set SSC %d for audio\n", tse850->ssc_id);
- goto err_disable_ana;
- }
-
ret = snd_soc_register_card(card);
if (ret) {
dev_err(dev, "snd_soc_register_card failed\n");
- goto err_put_audio;
+ goto err_disable_ana;
}
return 0;
-err_put_audio:
- atmel_ssc_put_audio(tse850->ssc_id);
err_disable_ana:
regulator_disable(tse850->ana);
return ret;
@@ -443,7 +427,6 @@ static int tse850_remove(struct platform_device *pdev)
struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
snd_soc_unregister_card(card);
- atmel_ssc_put_audio(tse850->ssc_id);
regulator_disable(tse850->ana);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Gregory CLEMENT @ 2016-12-01 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKeJBL7_V_7QPVNDAd9H4bgeLcSF8enuD96sgEmecuRkRA@mail.gmail.com>
Hi Jisheng,
On jeu., d?c. 01 2016, Marcin Wojtas <mw@semihalf.com> wrote:
> Hi Jisheng,
>
> Which baseline do you use?
>
> It took me really lot of time to catch why RX broke after rebase from
> LKv4.1 to LKv4.4. Between those two, in commit:
> 97303480753e ("arm64: Increase the max granular size")
> L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
> did NET_SKB_PAD.
>
> And 128 is more than the maximum that can fit into packet offset
> [11:8]@0x1400. In such case this correction is needed. Did it answer
> your doubts?
I can confirm also that without this patch it just doesn't work.
Gregory
>
> Best regards,
> Marcin
>
>
>
> 2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
>> Hi Gregory, Marcin,
>>
>> On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
>>
>>> From: Marcin Wojtas <mw@semihalf.com>
>>>
>>> Prepare the mvneta driver in order to be usable on the 64 bits platform
>>> such as the Armada 3700.
>>>
>>> [gregory.clement at free-electrons.com]: this patch was extract from a larger
>>> one to ease review and maintenance.
>>>
>>> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> ---
>>> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>>> index 92b9af14c352..8ef03fb69bcd 100644
>>> --- a/drivers/net/ethernet/marvell/mvneta.c
>>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>>> @@ -296,6 +296,12 @@
>>> /* descriptor aligned size */
>>> #define MVNETA_DESC_ALIGNED_SIZE 32
>>>
>>> +/* Number of bytes to be taken into account by HW when putting incoming data
>>> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
>>> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
>>
>> We also brought up this driver on 64bit platforms, we doesn't have this
>> patch. Maybe I'm wrong, I'm trying to understand why we need this
>> modification. Let's assume the NET_SKB_PAD is 64B, we call
>> mvneta_rxq_offset_set(pp, rxq, 64),
>>
>> {
>> u32 val;
>>
>> val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
>> val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
>>
>> /* Offset is in */
>> val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
>> // then this will be "val |= 8;" it doesn't exceeds the max offset of
>> MVNETA_RXQ_CONFIG_REG(q) register.
>>
>> Could you please kindly point out where I am wrong?
>>
>>> + */
>>> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
>>> +
>>> #define MVNETA_RX_PKT_SIZE(mtu) \
>>> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
>>> ETH_HLEN + ETH_FCS_LEN, \
>>> @@ -416,6 +422,7 @@ struct mvneta_port {
>>> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
>>>
>>> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
>>> + u16 rx_offset_correction;
>>> };
>>>
>>> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
>>> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
>>> return -ENOMEM;
>>> }
>>>
>>> + phys_addr += pp->rx_offset_correction;
>>> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
>>> return 0;
>>> }
>>> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
>>> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
>>>
>>> /* Set Offset */
>>> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
>>> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
>>>
>>> /* Set coalescing pkts and time */
>>> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
>>> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
>>>
>>> pp->rxq_def = rxq_def;
>>>
>>> + /* Set RX packet offset correction for platforms, whose
>>> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
>>> + * platforms and 0B for 32-bit ones.
>>
>> Even we need this patch, I'm not sure this last comment is correct or not.
>> NET_SKB_PAD is defined as:
>>
>> #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
>>
>> we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
>> should be 64B as well.
>>
>> Thanks,
>> Jisheng
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKeJBL7_V_7QPVNDAd9H4bgeLcSF8enuD96sgEmecuRkRA@mail.gmail.com>
Hi Marcin,
On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
> Hi Jisheng,
>
> Which baseline do you use?
>
> It took me really lot of time to catch why RX broke after rebase from
> LKv4.1 to LKv4.4. Between those two, in commit:
> 97303480753e ("arm64: Increase the max granular size")
> L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
> did NET_SKB_PAD.
>
> And 128 is more than the maximum that can fit into packet offset
> [11:8]@0x1400. In such case this correction is needed. Did it answer
> your doubts?
That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
("arm64: Increase the max granular size")
I think it would be great if this information can be added into the commit
msg.
IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
cache line sizes of arm64. If that's implemented and merged, then we can
revert this patch later.
Thanks,
Jisheng
>
> Best regards,
> Marcin
>
>
>
> 2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> > Hi Gregory, Marcin,
> >
> > On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> >
> >> From: Marcin Wojtas <mw@semihalf.com>
> >>
> >> Prepare the mvneta driver in order to be usable on the 64 bits platform
> >> such as the Armada 3700.
> >>
> >> [gregory.clement at free-electrons.com]: this patch was extract from a larger
> >> one to ease review and maintenance.
> >>
> >> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> >> 1 file changed, 16 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> >> index 92b9af14c352..8ef03fb69bcd 100644
> >> --- a/drivers/net/ethernet/marvell/mvneta.c
> >> +++ b/drivers/net/ethernet/marvell/mvneta.c
> >> @@ -296,6 +296,12 @@
> >> /* descriptor aligned size */
> >> #define MVNETA_DESC_ALIGNED_SIZE 32
> >>
> >> +/* Number of bytes to be taken into account by HW when putting incoming data
> >> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> >> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
> >
> > We also brought up this driver on 64bit platforms, we doesn't have this
> > patch. Maybe I'm wrong, I'm trying to understand why we need this
> > modification. Let's assume the NET_SKB_PAD is 64B, we call
> > mvneta_rxq_offset_set(pp, rxq, 64),
> >
> > {
> > u32 val;
> >
> > val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
> > val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
> >
> > /* Offset is in */
> > val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
> > // then this will be "val |= 8;" it doesn't exceeds the max offset of
> > MVNETA_RXQ_CONFIG_REG(q) register.
> >
> > Could you please kindly point out where I am wrong?
> >
> >> + */
> >> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> >> +
> >> #define MVNETA_RX_PKT_SIZE(mtu) \
> >> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> >> ETH_HLEN + ETH_FCS_LEN, \
> >> @@ -416,6 +422,7 @@ struct mvneta_port {
> >> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
> >>
> >> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> >> + u16 rx_offset_correction;
> >> };
> >>
> >> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> >> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> >> return -ENOMEM;
> >> }
> >>
> >> + phys_addr += pp->rx_offset_correction;
> >> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> >> return 0;
> >> }
> >> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> >> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
> >>
> >> /* Set Offset */
> >> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> >> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
> >>
> >> /* Set coalescing pkts and time */
> >> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> >> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
> >>
> >> pp->rxq_def = rxq_def;
> >>
> >> + /* Set RX packet offset correction for platforms, whose
> >> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> >> + * platforms and 0B for 32-bit ones.
> >
> > Even we need this patch, I'm not sure this last comment is correct or not.
> > NET_SKB_PAD is defined as:
> >
> > #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
> >
> > we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
> > should be 64B as well.
> >
> > Thanks,
> > Jisheng
^ permalink raw reply
* [PATCH 1/3] arm64: dts: zx: support cpu-freq for zx296718
From: Baoyou Xie @ 2016-12-01 12:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 37 +++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 7a1aed7..16f7d5e 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/zx296718-clock.h>
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu at 3 {
@@ -102,6 +107,38 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1188000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <500000>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: James Morse @ 2016-12-01 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-6-git-send-email-labbott@redhat.com>
Hi Laura,
On 29/11/16 18:55, Laura Abbott wrote:
> __pa_symbol is technically the marco that should be used for kernel
macro
> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> will do bounds checking. As part of this, introduce lm_alias, a
> macro which wraps the __va(__pa(...)) idiom used a few places to
> get the alias.
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index d55a7b0..4f0c77d 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -484,7 +481,7 @@ int swsusp_arch_resume(void)
> * Since we only copied the linear map, we need to find restore_pblist's
> * linear map address.
> */
> - lm_restore_pblist = LMADDR(restore_pblist);
> + lm_restore_pblist = lm_alias(restore_pblist);
>
> /*
> * We need a zero page that is zero before & after resume in order to
This change causes resume from hibernate to panic in:
> VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START ||
> x > (unsigned long) KERNEL_END);
It looks like kaslr's relocation code has already fixed restore_pblist, so your
debug virtual check catches this doing the wrong thing. My bug.
readelf -s vmlinux | grep ...
> 103495: ffff000008080000 0 NOTYPE GLOBAL DEFAULT 1 _text
> 92104: ffff000008e43860 8 OBJECT GLOBAL DEFAULT 24 restore_pblist
> 105442: ffff000008e85000 0 NOTYPE GLOBAL DEFAULT 24 _end
But restore_pblist == 0xffff800971b7f998 when passed to __phys_addr_symbol().
This fixes the problem:
----------------%<----------------
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 4f0c77d2ff7a..8bed26a2d558 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -457,7 +457,6 @@ int swsusp_arch_resume(void)
void *zero_page;
size_t exit_size;
pgd_t *tmp_pg_dir;
- void *lm_restore_pblist;
phys_addr_t phys_hibernate_exit;
void __noreturn (*hibernate_exit)(phys_addr_t, phys_addr_t, void *,
void *, phys_addr_t, phys_addr_t);
@@ -478,12 +477,6 @@ int swsusp_arch_resume(void)
goto out;
/*
- * Since we only copied the linear map, we need to find restore_pblist's
- * linear map address.
- */
- lm_restore_pblist = lm_alias(restore_pblist);
-
- /*
* We need a zero page that is zero before & after resume in order to
* to break before make on the ttbr1 page tables.
*/
@@ -534,7 +527,7 @@ int swsusp_arch_resume(void)
}
hibernate_exit(virt_to_phys(tmp_pg_dir), resume_hdr.ttbr1_el1,
- resume_hdr.reenter_kernel, lm_restore_pblist,
+ resume_hdr.reenter_kernel, restore_pblist,
resume_hdr.__hyp_stub_vectors, virt_to_phys(zero_page));
out:
----------------%<----------------
I can post it as a separate fixes patch if you prefer.
I also tested kexec. FWIW:
Tested-by: James Morse <james.morse@arm.com>
Thanks,
James
[0] Trace
[ 4.191607] Freezing user space processes ... (elapsed 0.000 seconds) done.
[ 4.224251] random: fast init done
[ 4.243825] PM: Using 3 thread(s) for decompression.
[ 4.243825] PM: Loading and decompressing image data (90831 pages)...
[ 4.255257] hibernate: Hibernated on CPU 0 [mpidr:0x100]
[ 5.213469] PM: Image loading progress: 0%
[ 5.579886] PM: Image loading progress: 10%
[ 5.740234] ata2: SATA link down (SStatus 0 SControl 0)
[ 5.760435] PM: Image loading progress: 20%
[ 5.970647] PM: Image loading progress: 30%
[ 6.563108] PM: Image loading progress: 40%
[ 6.848389] PM: Image loading progress: 50%
[ 7.526272] PM: Image loading progress: 60%
[ 7.702727] PM: Image loading progress: 70%
[ 7.899754] PM: Image loading progress: 80%
[ 8.100703] PM: Image loading progress: 90%
[ 8.300978] PM: Image loading progress: 100%
[ 8.305441] PM: Image loading done.
[ 8.308975] PM: Read 363324 kbytes in 4.05 seconds (89.70 MB/s)
[ 8.344299] PM: quiesce of devices complete after 22.706 msecs
[ 8.350762] PM: late quiesce of devices complete after 0.596 msecs
[ 8.381334] PM: noirq quiesce of devices complete after 24.365 msecs
[ 8.387729] Disabling non-boot CPUs ...
[ 8.412500] CPU1: shutdown
[ 8.415211] psci: CPU1 killed.
[ 8.460465] CPU2: shutdown
[ 8.463175] psci: CPU2 killed.
[ 8.504447] CPU3: shutdown
[ 8.507156] psci: CPU3 killed.
[ 8.540375] CPU4: shutdown
[ 8.543084] psci: CPU4 killed.
[ 8.580333] CPU5: shutdown
[ 8.583043] psci: CPU5 killed.
[ 8.601206] ------------[ cut here ]------------
[ 8.601206] kernel BUG at ../arch/arm64/mm/physaddr.c:25!
[ 8.601206] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 8.601206] Modules linked in:
[ 8.601206] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7-00010-g27c672
[ 8.601206] Hardware name: ARM Juno development board (r1) (DT)
[ 8.601206] task: ffff800976ca8000 task.stack: ffff800976c3c000
[ 8.601206] PC is at __phys_addr_symbol+0x30/0x34
[ 8.601206] LR is at swsusp_arch_resume+0x304/0x588
[ 8.601206] pc : [<ffff0000080992d8>] lr : [<ffff0000080938b4>] pstate: 20005
[ 8.601206] sp : ffff800976c3fca0
[ 8.601206] x29: ffff800976c3fca0 x28: ffff000008bee000
[ 8.601206] x27: 000000000e5ea000 x26: ffff000008e83000
[ 8.601206] x25: 0000000000000801 x24: 0000000040000000
[ 8.601206] x23: 0000000000000000 x22: 000000000e00d000
[ 8.601206] x21: ffff808000000000 x20: ffff800080000000
[ 8.601206] x19: 0000000000000000 x18: 4000000000000000
[ 8.601206] x17: 0000000000000000 x16: 0000000000000694
[ 8.601206] x15: ffff000008bee000 x14: 0000000000000008
[ 8.601206] x13: 0000000000000000 x12: 003d090000000000
[ 8.601206] x11: 0000000000000001 x10: fffffffff1a0f000
[ 8.601206] x9 : 0000000000000001 x8 : ffff800971a0aff8
[ 8.601206] x7 : 0000000000000001 x6 : 000000000000003f
[ 8.601206] x5 : 0000000000000040 x4 : 0000000000000000
[ 8.601206] x3 : ffff807fffffffff x2 : 0000000000000000
[ 8.601206] x1 : ffff000008e85000 x0 : ffff80097152b578
[ 8.601206]
[ 8.601206] Process swapper/0 (pid: 1, stack limit = 0xffff800976c3c020)
[ 8.601206] Stack: (0xffff800976c3fca0 to 0xffff800976c40000)
[ 8.601206] Call trace:
[ 8.601206] Exception stack(0xffff800976c3fad0 to 0xffff800976c3fc00)
[ 8.601206] [<ffff0000080992d8>] __phys_addr_symbol+0x30/0x34
[ 8.601206] [<ffff0000080fe340>] hibernation_restore+0xf8/0x130
[ 8.601206] [<ffff0000080fe3e4>] load_image_and_restore+0x6c/0x70
[ 8.601206] [<ffff0000080fe640>] software_resume+0x258/0x288
[ 8.601206] [<ffff0000080830b8>] do_one_initcall+0x38/0x128
[ 8.601206] [<ffff000008c60cf4>] kernel_init_freeable+0x1ac/0x250
[ 8.601206] [<ffff0000088acd10>] kernel_init+0x10/0x100
[ 8.601206] [<ffff000008082e80>] ret_from_fork+0x10/0x50
[ 8.601206] Code: b0005aa1 f9475c21 cb010000 d65f03c0 (d4210000)
[ 8.601206] ---[ end trace e15be9f4f989f0b5 ]---
[ 8.601206] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0b
[ 8.601206]
[ 8.601206] Kernel Offset: disabled
[ 8.601206] Memory Limit: none
[ 8.601206] ---[ end Kernel panic - not syncing: Attempted to kill init! exib
[ 8.601206]
^ permalink raw reply related
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Arnd Bergmann @ 2016-12-01 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480553321-17400-2-git-send-email-zhangfei.gao@linaro.org>
On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> + 0x20 0x10 /* 1: i2c1 */
> + 0x20 0x20 /* 2: i2c2 */
> + 0x20 0x8000000>; /* 3: i2c6 */
> + };
> +
> +Specifying reset lines connected to IP modules
> +==============================================
> +example:
> +
> + i2c0: i2c at ..... {
> + ...
> + resets = <&iomcu_rst 0>;
> + ...
> + };
I don't really like this approach, since now the information is
in two places. Why not put the data into the reset specifier
directly when it is used?
Also the format seems a little too close to the actual register
layout and could be a little more abstract, using bit numbers instead
of a bitmask and register numbers instead of offsets.
Arnd
^ permalink raw reply
* arm64: dts: zx: support cpu-freq for zx296718
From: Baoyou Xie @ 2016-12-01 12:08 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 37 +++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 7a1aed7..16f7d5e 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/zx296718-clock.h>
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu at 3 {
@@ -102,6 +107,38 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 648000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1188000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <500000>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Shameerali Kolothum Thodi @ 2016-12-01 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be0586f4-57b7-b732-f97e-34798f57e066@arm.com>
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Thursday, December 01, 2016 10:58 AM
> To: Shameerali Kolothum Thodi; Paolo Bonzini; Radim Kr?m??
> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
> kernel at lists.infradead.org; kvm at vger.kernel.org
> Subject: Re: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-
> SPIs
>
> On 01/12/16 10:28, Shameerali Kolothum Thodi wrote:
> > Hi Marc,
> >
> >> -----Original Message-----
> >> From: kvmarm-bounces at lists.cs.columbia.edu [mailto:kvmarm-
> >> bounces at lists.cs.columbia.edu] On Behalf Of Marc Zyngier
> >> Sent: Thursday, December 01, 2016 9:26 AM
> >> To: Paolo Bonzini; Radim Kr?m??
> >> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
> >> kernel at lists.infradead.org; kvm at vger.kernel.org
> >> Subject: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
> >>
> >> When we inject a level triggerered interrupt (and unless it is
> backed
> >> by the physical distributor - timer style), we request a maintenance
> >> interrupt. Part of the processing for that interrupt is to feed to
> the
> >> rest of KVM (and to the eventfd subsystem) the information that the
> >> interrupt has been EOIed.
> >>
> >> But that notification only makes sense for SPIs, and not PPIs (such
> as
> >> the PMU interrupt). Skip over the notification if the interrupt is
> not
> >> an SPI.
> >
> > Just to clarify my understanding, the maintenance interrupt is
> generated
> > for cases where there is no mapping of virt to phys interrupts
> > (ie, ICH_LR HW bit is not set). And I was under the impression that
> > kvm_notify_acked_irq will eventually deactivate the interrupt on
> distributor
> > for such cases. Its not clear to me how the deactivation is done
> > otherwise.
> >
> > Could you please help me to understand this better.
>
> kvm_notify_acked_irq() doesn't do *anything* at the distributor level,
> ever (it has no idea of anything GIC-specific anyway). It's sole job is
> to signal the rest of the stack that an interrupt has been EOIed in the
> guest.
Thanks Marc. Understood. I got confused by the kvm_set_irq in the
kvm_notify_acked_irq path.
> For these interrupts, which are purely virtual, there is absolutely
> nothing to do at the physical distributor level anyway. Furthermore,
> kvm_notify_acked_irq doesn't know about per-cpu interrupt, which is why
> we cannot notify them.
Just to confirm, that means for any phys interrupt(PPI/SPI) to be injected
to the Guest, the mapping bit has(HW bit set) to be used.
Thanks,
Shameer
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201200205.46dec339@xhacker>
On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
> Hi Marcin,
>
> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>
> > Hi Jisheng,
> >
> > Which baseline do you use?
> >
> > It took me really lot of time to catch why RX broke after rebase from
> > LKv4.1 to LKv4.4. Between those two, in commit:
> > 97303480753e ("arm64: Increase the max granular size")
> > L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
> > did NET_SKB_PAD.
> >
> > And 128 is more than the maximum that can fit into packet offset
> > [11:8]@0x1400. In such case this correction is needed. Did it answer
> > your doubts?
>
> That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
> ("arm64: Increase the max granular size")
>
> I think it would be great if this information can be added into the commit
> msg.
>
> IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
> cache line sizes of arm64. If that's implemented and merged, then we can
I just searched and found the email.
"We may have to revisit this logic and consider L1_CACHE_BYTES the
_minimum_ of cache line sizes in arm64 systems supported by the kernel.
Do you have any benchmarks on Cavium boards that would show significant
degradation with 64-byte L1_CACHE_BYTES vs 128?"
https://patchwork.kernel.org/patch/8634481/
> revert this patch later.
>
> Thanks,
> Jisheng
>
> >
> > Best regards,
> > Marcin
> >
> >
> >
> > 2016-12-01 12:26 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> > > Hi Gregory, Marcin,
> > >
> > > On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> > >
> > >> From: Marcin Wojtas <mw@semihalf.com>
> > >>
> > >> Prepare the mvneta driver in order to be usable on the 64 bits platform
> > >> such as the Armada 3700.
> > >>
> > >> [gregory.clement at free-electrons.com]: this patch was extract from a larger
> > >> one to ease review and maintenance.
> > >>
> > >> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> > >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > >> ---
> > >> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> > >> 1 file changed, 16 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > >> index 92b9af14c352..8ef03fb69bcd 100644
> > >> --- a/drivers/net/ethernet/marvell/mvneta.c
> > >> +++ b/drivers/net/ethernet/marvell/mvneta.c
> > >> @@ -296,6 +296,12 @@
> > >> /* descriptor aligned size */
> > >> #define MVNETA_DESC_ALIGNED_SIZE 32
> > >>
> > >> +/* Number of bytes to be taken into account by HW when putting incoming data
> > >> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> > >> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
> > >
> > > We also brought up this driver on 64bit platforms, we doesn't have this
> > > patch. Maybe I'm wrong, I'm trying to understand why we need this
> > > modification. Let's assume the NET_SKB_PAD is 64B, we call
> > > mvneta_rxq_offset_set(pp, rxq, 64),
> > >
> > > {
> > > u32 val;
> > >
> > > val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
> > > val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
> > >
> > > /* Offset is in */
> > > val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
> > > // then this will be "val |= 8;" it doesn't exceeds the max offset of
> > > MVNETA_RXQ_CONFIG_REG(q) register.
> > >
> > > Could you please kindly point out where I am wrong?
> > >
> > >> + */
> > >> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> > >> +
> > >> #define MVNETA_RX_PKT_SIZE(mtu) \
> > >> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> > >> ETH_HLEN + ETH_FCS_LEN, \
> > >> @@ -416,6 +422,7 @@ struct mvneta_port {
> > >> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
> > >>
> > >> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> > >> + u16 rx_offset_correction;
> > >> };
> > >>
> > >> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > >> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> > >> return -ENOMEM;
> > >> }
> > >>
> > >> + phys_addr += pp->rx_offset_correction;
> > >> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> > >> return 0;
> > >> }
> > >> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> > >> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
> > >>
> > >> /* Set Offset */
> > >> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> > >> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
> > >>
> > >> /* Set coalescing pkts and time */
> > >> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> > >> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
> > >>
> > >> pp->rxq_def = rxq_def;
> > >>
> > >> + /* Set RX packet offset correction for platforms, whose
> > >> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> > >> + * platforms and 0B for 32-bit ones.
> > >
> > > Even we need this patch, I'm not sure this last comment is correct or not.
> > > NET_SKB_PAD is defined as:
> > >
> > > #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
> > >
> > > we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
> > > should be 64B as well.
> > >
> > > Thanks,
> > > Jisheng
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-01 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201103048.GO1574@e103592.cambridge.arm.com>
On Thu, Dec 01, 2016 at 10:30:51AM +0000, Dave Martin wrote:
[...]
> Basically, all the *new* state is caller-save.
>
> The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view
> Zn[bits 127:0] is callee-save for all n = 8..15.
Ramana is right -- the current procedure call standard (ARM IHI 0055B)
only requires the bottom _64_ bits of V8-V15 to be preserved (not all
128 bits as I stated).
[...]
Cheers
---Dave
^ permalink raw reply
* arasan,sdhci.txt "compatibility" DT binding
From: Mason @ 2016-12-01 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f64ea0f8-31be-c5b5-3a43-a30abd8aec30@rock-chips.com>
On 01/12/2016 05:09, Shawn Lin wrote:
> On 2016/11/28 23:44, Mason wrote:
>
>> Shawn Lin, could you take a look below and tell me exactly
>> which IP core(s) Rockchip is using in its SoCs?
>
> From the Host Controller version register (0xfe)
> bit[7:0]: 0x2 : specification version number is 3.00
> bit[15:8]: 0x10: Vendor version number is 1.0
>
> Command Queueing version register (0x200)
> bit[11:8]: 0x5 eMMC Major version number
> bit[7:4]: 0x1 eMMC manor version number
> bit[3:0]: 0x0 eMMC version suffix
>
> User guide "eMMC 5.1/SD3.0/SDIO3.0 Host Controller"
> Revision number: 1.14
> Released on Dec. 2014
Wow! Yet another HW revision I wasn't aware of :-)
For the record, I think the 0x200 register was introduced fairly
recently, as it's not documented in any of the user guides I have
access to.
To summarize the situation, Arasan has made (at least) the
following versions of the HW block:
SD_2.0_SDIO_2.0__MMC_3.31_Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.4__Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.41_Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller
SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller
SD_3.0_SDIO_3.0_eMMC_5.1__Host Controller
SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller
SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller
Xilinx = "arasan,sdhci-8.9a" compat string
SD2.0 / SDIO2.0 / MMC3.31 (in Zynq)
SD3.0 / SDIO3.0 / eMMC4.51 (in ZynqMP)
Vendor version 0x89 (Zynq, from 8.9a) and 0x10 (ZynqMP)
Sigma = no compat string yet
SD3.0 / SDIO3.0 / eMMC4.4 (in SMP87xx)
Vendor version 0x99 (not related to document revision)
APM = "arasan,sdhci-4.9a"
SD3.0 / SDIO3.0 / eMMC4.41
Vendor version unknown
Rockchip = "arasan,sdhci-5.1"
SD3.0 / SDIO3.0 / eMMC 5.1
Vendor version 0x10
Conclusion, it doesn't look like the "Vendor version" field
contains dependable information, considering the duplicate
0x10 in different HW revisions.
Regards.
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Marcin Wojtas @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201201648.6a50b442@xhacker>
Hi Jisheng,
2016-12-01 13:16 GMT+01:00 Jisheng Zhang <jszhang@marvell.com>:
> On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
>
>> Hi Marcin,
>>
>> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>>
>> > Hi Jisheng,
>> >
>> > Which baseline do you use?
>> >
>> > It took me really lot of time to catch why RX broke after rebase from
>> > LKv4.1 to LKv4.4. Between those two, in commit:
>> > 97303480753e ("arm64: Increase the max granular size")
>> > L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
>> > did NET_SKB_PAD.
>> >
>> > And 128 is more than the maximum that can fit into packet offset
>> > [11:8]@0x1400. In such case this correction is needed. Did it answer
>> > your doubts?
>>
>> That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
>> ("arm64: Increase the max granular size")
>>
>> I think it would be great if this information can be added into the commit
>> msg.
>>
>> IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
>> cache line sizes of arm64. If that's implemented and merged, then we can
>
> I just searched and found the email.
>
> "We may have to revisit this logic and consider L1_CACHE_BYTES the
> _minimum_ of cache line sizes in arm64 systems supported by the kernel.
> Do you have any benchmarks on Cavium boards that would show significant
> degradation with 64-byte L1_CACHE_BYTES vs 128?"
>
> https://patchwork.kernel.org/patch/8634481/
>
>
Thank you for the information. I debugged it before the discussion. In
future we would be able to revert it, however afair packet offset may
be needed by A3700 Buffer Management.
Best regards,
Marcin
^ permalink raw reply
* [PATCH v2] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Russell King - ARM Linux @ 2016-12-01 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480589913-8839-1-git-send-email-maninder1.s@samsung.com>
On Thu, Dec 01, 2016 at 04:28:33PM +0530, Maninder Singh wrote:
> variable name can have Non NULL terminated string after cropping
> which may result strcat to fail, and cropping is not
> required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
>
> Issue caught with static analysis tool:
> "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> ---
> v1 -> v2: changed strncpy to strlcpy
> arch/arm/mach-omap2/omap_hwmod.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 759e1d4..582b95a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -742,12 +742,14 @@ static int _init_main_clk(struct omap_hwmod *oh)
> char name[MOD_CLK_MAX_NAME_LEN];
> struct clk *clk;
>
> - /* +7 magic comes from '_mod_ck' suffix */
> - if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
> + /* +8 magic comes from strlen("_mod_ck") added as suffix */
> + if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
> pr_warn("%s: warning: cropping name for %s\n", __func__,
> oh->name);
> + strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> + } else
> + strcpy(name, oh->name);
>
> - strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> strcat(name, "_mod_ck");
>
> clk = clk_get(NULL, name);
> --
> 1.9.1
>
Simpler, clearer, and less error-prone:
static const char modck[] = "_mod_ck";
if (strlen(oh->name) >= MOD_CLK_MAX_NAME_LEN - strlen(modck))
pr_warn("%s: warning: cropping name for %s\n", __func__,
oh->name);
strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - strlen(modck));
strlcat(name, modck, MOD_CLK_MAX_NAME_LEN);
Note that the length argument to strlcpy _includes_ the NUL terminator.
Also note the use of strlcat() which ensures that it won't overflow the
buffer.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH net-next v2] net: thunderx: Fix transmit queue timeout issue
From: sunil.kovvuri at gmail.com @ 2016-12-01 12:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Sunil Goutham <sgoutham@cavium.com>
Transmit queue timeout issue is seen in two cases
- Due to a race condition btw setting stop_queue at xmit()
and checking for stopped_queue in NAPI poll routine, at times
transmission from a SQ comes to a halt. This is fixed
by using barriers and also added a check for SQ free descriptors,
incase SQ is stopped and there are only CQE_RX i.e no CQE_TX.
- Contrary to an assumption, a HW errata where HW doesn't stop transmission
even though there are not enough CQEs available for a CQE_TX is
not fixed in T88 pass 2.x. This results in a Qset error with
'CQ_WR_FULL' stalling transmission. This is fixed by adjusting
RXQ's RED levels for CQ level such that there is always enough
space left for CQE_TXs.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
v2: As suggested by David, replaced netif_tx_start_queue with
netif_tx_wake_queue.
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 52 ++++++++++++++++++----
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 24 ++--------
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 15 ++++---
3 files changed, 54 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 1eacec8..2006f58 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -644,6 +644,7 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
struct cmp_queue *cq = &qs->cq[cq_idx];
struct cqe_rx_t *cq_desc;
struct netdev_queue *txq;
+ struct snd_queue *sq;
unsigned int tx_pkts = 0, tx_bytes = 0;
spin_lock_bh(&cq->lock);
@@ -709,16 +710,20 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
done:
/* Wakeup TXQ if its stopped earlier due to SQ full */
- if (tx_done) {
+ sq = &nic->qs->sq[cq_idx];
+ if (tx_done ||
+ (atomic_read(&sq->free_cnt) >= MIN_SQ_DESC_PER_PKT_XMIT)) {
netdev = nic->pnicvf->netdev;
txq = netdev_get_tx_queue(netdev,
nicvf_netdev_qidx(nic, cq_idx));
if (tx_pkts)
netdev_tx_completed_queue(txq, tx_pkts, tx_bytes);
- nic = nic->pnicvf;
+ /* To read updated queue and carrier status */
+ smp_mb();
if (netif_tx_queue_stopped(txq) && netif_carrier_ok(netdev)) {
- netif_tx_start_queue(txq);
+ netif_tx_wake_queue(txq);
+ nic = nic->pnicvf;
this_cpu_inc(nic->drv_stats->txq_wake);
if (netif_msg_tx_err(nic))
netdev_warn(netdev,
@@ -1054,6 +1059,9 @@ static netdev_tx_t nicvf_xmit(struct sk_buff *skb, struct net_device *netdev)
struct nicvf *nic = netdev_priv(netdev);
int qid = skb_get_queue_mapping(skb);
struct netdev_queue *txq = netdev_get_tx_queue(netdev, qid);
+ struct nicvf *snic;
+ struct snd_queue *sq;
+ int tmp;
/* Check for minimum packet length */
if (skb->len <= ETH_HLEN) {
@@ -1061,13 +1069,39 @@ static netdev_tx_t nicvf_xmit(struct sk_buff *skb, struct net_device *netdev)
return NETDEV_TX_OK;
}
- if (!netif_tx_queue_stopped(txq) && !nicvf_sq_append_skb(nic, skb)) {
+ snic = nic;
+ /* Get secondary Qset's SQ structure */
+ if (qid >= MAX_SND_QUEUES_PER_QS) {
+ tmp = qid / MAX_SND_QUEUES_PER_QS;
+ snic = (struct nicvf *)nic->snicvf[tmp - 1];
+ if (!snic) {
+ netdev_warn(nic->netdev,
+ "Secondary Qset#%d's ptr not initialized\n",
+ tmp - 1);
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+ qid = qid % MAX_SND_QUEUES_PER_QS;
+ }
+
+ sq = &snic->qs->sq[qid];
+ if (!netif_tx_queue_stopped(txq) &&
+ !nicvf_sq_append_skb(snic, sq, skb, qid)) {
netif_tx_stop_queue(txq);
- this_cpu_inc(nic->drv_stats->txq_stop);
- if (netif_msg_tx_err(nic))
- netdev_warn(netdev,
- "%s: Transmit ring full, stopping SQ%d\n",
- netdev->name, qid);
+
+ /* Barrier, so that stop_queue visible to other cpus */
+ smp_mb();
+
+ /* Check again, incase another cpu freed descriptors */
+ if (atomic_read(&sq->free_cnt) > MIN_SQ_DESC_PER_PKT_XMIT) {
+ netif_tx_wake_queue(txq);
+ } else {
+ this_cpu_inc(nic->drv_stats->txq_stop);
+ if (netif_msg_tx_err(nic))
+ netdev_warn(netdev,
+ "%s: Transmit ring full, stopping SQ%d\n",
+ netdev->name, qid);
+ }
return NETDEV_TX_BUSY;
}
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 7b336cd..d2ac133 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -1190,30 +1190,12 @@ static int nicvf_sq_append_tso(struct nicvf *nic, struct snd_queue *sq,
}
/* Append an skb to a SQ for packet transfer. */
-int nicvf_sq_append_skb(struct nicvf *nic, struct sk_buff *skb)
+int nicvf_sq_append_skb(struct nicvf *nic, struct snd_queue *sq,
+ struct sk_buff *skb, u8 sq_num)
{
int i, size;
int subdesc_cnt, tso_sqe = 0;
- int sq_num, qentry;
- struct queue_set *qs;
- struct snd_queue *sq;
-
- sq_num = skb_get_queue_mapping(skb);
- if (sq_num >= MAX_SND_QUEUES_PER_QS) {
- /* Get secondary Qset's SQ structure */
- i = sq_num / MAX_SND_QUEUES_PER_QS;
- if (!nic->snicvf[i - 1]) {
- netdev_warn(nic->netdev,
- "Secondary Qset#%d's ptr not initialized\n",
- i - 1);
- return 1;
- }
- nic = (struct nicvf *)nic->snicvf[i - 1];
- sq_num = sq_num % MAX_SND_QUEUES_PER_QS;
- }
-
- qs = nic->qs;
- sq = &qs->sq[sq_num];
+ int qentry;
subdesc_cnt = nicvf_sq_subdesc_required(nic, skb);
if (subdesc_cnt > atomic_read(&sq->free_cnt))
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index 20511f2..9e21046 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -88,13 +88,13 @@
/* RED and Backpressure levels of CQ for pkt reception
* For CQ, level is a measure of emptiness i.e 0x0 means full
- * eg: For CQ of size 4K, and for pass/drop levels of 128/96
- * HW accepts pkt if unused CQE >= 2048
- * RED accepts pkt if unused CQE < 2048 & >= 1536
- * DROPs pkts if unused CQE < 1536
+ * eg: For CQ of size 4K, and for pass/drop levels of 160/144
+ * HW accepts pkt if unused CQE >= 2560
+ * RED accepts pkt if unused CQE < 2304 & >= 2560
+ * DROPs pkts if unused CQE < 2304
*/
-#define RQ_PASS_CQ_LVL 128ULL
-#define RQ_DROP_CQ_LVL 96ULL
+#define RQ_PASS_CQ_LVL 160ULL
+#define RQ_DROP_CQ_LVL 144ULL
/* RED and Backpressure levels of RBDR for pkt reception
* For RBDR, level is a measure of fullness i.e 0x0 means empty
@@ -306,7 +306,8 @@ void nicvf_sq_disable(struct nicvf *nic, int qidx);
void nicvf_put_sq_desc(struct snd_queue *sq, int desc_cnt);
void nicvf_sq_free_used_descs(struct net_device *netdev,
struct snd_queue *sq, int qidx);
-int nicvf_sq_append_skb(struct nicvf *nic, struct sk_buff *skb);
+int nicvf_sq_append_skb(struct nicvf *nic, struct snd_queue *sq,
+ struct sk_buff *skb, u8 sq_num);
struct sk_buff *nicvf_get_rcv_skb(struct nicvf *nic, struct cqe_rx_t *cqe_rx);
void nicvf_rbdr_task(unsigned long data);
--
2.7.4
^ permalink raw reply related
* [PATCH] crypto: arm/aesbs - Select SIMD in Kconfig
From: Herbert Xu @ 2016-12-01 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130234826.854879-1-arnd@arndb.de>
On Thu, Dec 01, 2016 at 12:47:59AM +0100, Arnd Bergmann wrote:
> Commit 585b5fa63da9 ("crypto: arm/aes - Select SIMD in Kconfig") added
> the dependency for CRYPTO_AES_ARM_CE, but missed the same change
> for CRYPTO_AES_ARM_BS:
>
> arch/arm/crypto/aes-arm-bs.o: In function `aesbs_mod_init':
> aesbs-glue.c:(.init.text+0x38): undefined reference to `simd_skcipher_create_compat'
>
> Fixes: 211f41af534a ("crypto: aesbs - Convert to skcipher")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks Arnd. This should already be fixed by 6fdf436fd854.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] dmaengine: at_xdmac: don't restore unsaved status
From: Ludovic Desroches @ 2016-12-01 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104903.30019-1-alexandre.belloni@free-electrons.com>
On Thu, Dec 01, 2016 at 11:49:03AM +0100, Alexandre Belloni wrote:
> save_gs is supposed to save the channel status in order to be restored at
> resume time but it is never updated and is always 0. Anyway, the channel
> status is updated in the per channel loop later in the resume function.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Thanks
> ---
> drivers/dma/at_xdmac.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index b7d7f2d443a1..8c1abb794340 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -221,7 +221,6 @@ struct at_xdmac {
> int irq;
> struct clk *clk;
> u32 save_gim;
> - u32 save_gs;
> struct dma_pool *at_xdmac_desc_pool;
> struct at_xdmac_chan chan[0];
> };
> @@ -1896,7 +1895,6 @@ static int atmel_xdmac_resume(struct device *dev)
> }
>
> at_xdmac_write(atxdmac, AT_XDMAC_GIE, atxdmac->save_gim);
> - at_xdmac_write(atxdmac, AT_XDMAC_GE, atxdmac->save_gs);
> list_for_each_entry_safe(chan, _chan, &atxdmac->dma.channels, device_node) {
> atchan = to_at_xdmac_chan(chan);
> at_xdmac_chan_write(atchan, AT_XDMAC_CC, atchan->save_cc);
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Marc Zyngier @ 2016-12-01 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA81747812F@lhreml504-mbs>
On 01/12/16 12:15, Shameerali Kolothum Thodi wrote:
>> For these interrupts, which are purely virtual, there is absolutely
>> nothing to do at the physical distributor level anyway. Furthermore,
>> kvm_notify_acked_irq doesn't know about per-cpu interrupt, which is why
>> we cannot notify them.
>
> Just to confirm, that means for any phys interrupt(PPI/SPI) to be injected
> to the Guest, the mapping bit has(HW bit set) to be used.
Yup.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Marc Zyngier @ 2016-12-01 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480592310-26079-1-git-send-email-jintack@cs.columbia.edu>
Hi Jintack,
On 01/12/16 11:38, Jintack Lim wrote:
> Current KVM world switch code is unintentionally setting wrong bits to
> CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
> timer. Bit positions of CNTHCTL_EL2 are changing depending on
> HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
> not set, but they are 11th and 10th bits respectively when E2H is set.
>
> In fact, on VHE we only need to set those bits once, not for every world
> switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
> 1, which makes those bits have no effect for the host kernel execution.
> So we just set those bits once for guests, and that's it.
>
> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
> ---
> v2: Skip configuring cnthctl_el2 in world switch path on VHE system.
> This patch is based on linux-next.
>
> ---
> arch/arm/kvm/arm.c | 1 +
> include/kvm/arm_arch_timer.h | 1 +
> virt/kvm/arm/arch_timer.c | 23 ++++++++++++++++++++++
> virt/kvm/arm/hyp/timer-sr.c | 45 ++++++++++++++++++++++++++++++++------------
> 4 files changed, 58 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 8f92efa..38c0645 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -1286,6 +1286,7 @@ static void teardown_hyp_mode(void)
>
> static int init_vhe_mode(void)
> {
> + on_each_cpu(kvm_timer_init_vhe, NULL, 1);
I'm pretty sure this is not going to work with CPU hotplug, as you only
perform this once and for all at boot time.
I think it would be better if you called this init function as part of
cpu_init_hyp_mode().
> kvm_info("VHE mode initialized successfully\n");
> return 0;
> }
> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> index dda39d8..5853399 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -76,4 +76,5 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>
> void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>
> +void kvm_timer_init_vhe(void *dummy);
> #endif
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 17b8fa5..7a0d85d7 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -24,6 +24,7 @@
>
> #include <clocksource/arm_arch_timer.h>
> #include <asm/arch_timer.h>
> +#include <asm/kvm_hyp.h>
>
> #include <kvm/arm_vgic.h>
> #include <kvm/arm_arch_timer.h>
> @@ -507,3 +508,25 @@ void kvm_timer_init(struct kvm *kvm)
> {
> kvm->arch.timer.cntvoff = kvm_phys_timer_read();
> }
> +
> +/*
> + * On VHE system, we only need to configure trap on physical timer and counter
> + * accesses in EL0 and EL1 once, not for every world switch.
> + * The host kernel runs at EL2 with HCR_EL2.TGE == 1,
> + * and this makes those bits have no effect for the host kernel execution.
> + */
> +void kvm_timer_init_vhe(void *dummy)
> +{
> + /* When HCR_EL2.E2H ==1, EL1PCEN and EL1PCTEN are shifted by 10 */
> + u32 cnthctl_shift = 10;
> + u64 val;
> +
> + /*
> + * Disallow physical timer access for the guest.
> + * Physical counter access is allowed.
> + */
> + val = read_sysreg(cnthctl_el2);
> + val &= ~(CNTHCTL_EL1PCEN << cnthctl_shift);
> + val |= (CNTHCTL_EL1PCTEN << cnthctl_shift);
> + write_sysreg(val, cnthctl_el2);
> +}
If you make this called from cpu_init_hyp_mode(), it will have to be
guarded with is_kernel_in_hyp_mode().
> diff --git a/virt/kvm/arm/hyp/timer-sr.c b/virt/kvm/arm/hyp/timer-sr.c
> index 798866a..f7fc957 100644
> --- a/virt/kvm/arm/hyp/timer-sr.c
> +++ b/virt/kvm/arm/hyp/timer-sr.c
> @@ -21,6 +21,18 @@
>
> #include <asm/kvm_hyp.h>
>
> +#ifdef CONFIG_ARM64
> +static inline bool has_vhe(void)
> +{
> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
> + return true;
> +
> + return false;
> +}
> +#else
> +#define has_vhe() false
Could this now be moved to asm/virt.h, and maybe replace the current
implementation of is_kernel_in_hyp_mode? The latter may require some
more hacking around, so I'm not sure this is worth it.
> +#endif
> +
> /* vcpu is already in the HYP VA space */
> void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
> {
> @@ -35,10 +47,16 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
>
> - /* Allow physical timer/counter access for the host */
> - val = read_sysreg(cnthctl_el2);
> - val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
> - write_sysreg(val, cnthctl_el2);
> + /*
> + * We don't need to do this for VHE since the host kernel runs in EL2
> + * with HCR_EL2.TGE ==1, which makes those bits have no impact.
> + */
> + if (!has_vhe()) {
> + /* Allow physical timer/counter access for the host */
> + val = read_sysreg(cnthctl_el2);
> + val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
> + write_sysreg(val, cnthctl_el2);
> + }
>
> /* Clear cntvoff for the host */
> write_sysreg(0, cntvoff_el2);
> @@ -50,14 +68,17 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> u64 val;
>
> - /*
> - * Disallow physical timer access for the guest
> - * Physical counter access is allowed
> - */
> - val = read_sysreg(cnthctl_el2);
> - val &= ~CNTHCTL_EL1PCEN;
> - val |= CNTHCTL_EL1PCTEN;
> - write_sysreg(val, cnthctl_el2);
> + /* Those bits are already configured at boot on VHE-system */
> + if (!has_vhe()) {
> + /*
> + * Disallow physical timer access for the guest
> + * Physical counter access is allowed
> + */
> + val = read_sysreg(cnthctl_el2);
> + val &= ~CNTHCTL_EL1PCEN;
> + val |= CNTHCTL_EL1PCTEN;
> + write_sysreg(val, cnthctl_el2);
> + }
>
> if (timer->enabled) {
> write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
>
Otherwise, this looks good, and the generated code is quite nice.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ 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