* [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104
From: Simon Horman @ 2016-09-16 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-6-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:02PM +0200, Simon Horman wrote:
> Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
> And the sd-uhs-sdr104 property to SDHI0.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I have queued this up after dropping the sdr104 portion and
updating the changelog accordingly.
The result is as follows:
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 13 Sep 2016 12:57:02 +0200
Subject: [PATCH] ARM: dts: koelsch: arm64: dts: r8a7795: salvator-x: enable
UHS for SDHI 0, 1 & 3
Add the "1v8" pinctrl state and sd-uhs-sdr50 property to SDHI{0,1,2}.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f8a7d090fd01..f17bfa000f73 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -360,16 +360,37 @@
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
};
sdhi1_pins: sd1 {
groups = "sdhi1_data4", "sdhi1_ctrl";
function = "sdhi1";
+ power-source = <3300>;
+ };
+
+ sdhi1_pins_uhs: sd1_uhs {
+ groups = "sdhi1_data4", "sdhi1_ctrl";
+ function = "sdhi1";
+ power-source = <1800>;
};
sdhi2_pins: sd2 {
groups = "sdhi2_data4", "sdhi2_ctrl";
function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data4", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
};
qspi_pins: qspi {
@@ -454,33 +475,39 @@
&sdhi0 {
pinctrl-0 = <&sdhi0_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi0>;
vqmmc-supply = <&vccq_sdhi0>;
cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi1 {
pinctrl-0 = <&sdhi1_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi1_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi1>;
vqmmc-supply = <&vccq_sdhi1>;
cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio6 15 GPIO_ACTIVE_HIGH>;
+ sd-uhs-sdr50;
status = "okay";
};
&sdhi2 {
pinctrl-0 = <&sdhi2_pins>;
- pinctrl-names = "default";
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi2>;
vqmmc-supply = <&vccq_sdhi2>;
cd-gpios = <&gpio6 22 GPIO_ACTIVE_LOW>;
+ sd-uhs-sdr50;
status = "okay";
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3
From: Simon Horman @ 2016-09-16 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-3-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote:
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
As SDR50 support is present in the driver in mainline (correct me if I am
wrong!) I am queuing this up.
^ permalink raw reply
* [PATCH v7 04/11] ARM: dts: r8a7791: set maximum frequency for SDHI clocks
From: Simon Horman @ 2016-09-16 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473764228-24768-5-git-send-email-horms+renesas@verge.net.au>
On Tue, Sep 13, 2016 at 12:57:01PM +0200, Simon Horman wrote:
> Define the upper limit otherwise the driver cannot utilize max speeds.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
I have queued this up.
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.9
From: Simon Horman @ 2016-09-16 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14474684.Hhngk1emgJ@wuerfel>
On Tue, Sep 13, 2016 at 05:35:25PM +0200, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 9:49:30 AM CEST Simon Horman wrote:
> > Second Round of Renesas ARM Based SoC DT Updates for v4.9
> >
> > Fixes (for v4.9):
> > * Correct PWM clock parent on r8a7794 SoC
> >
> > Clean-up:
> > * Remove obsolete vsp1 properties from r8a779[01] SoCs
> >
> > New boards:
> > * Add r8a7792/wheat and r7s72100/rskrza1 boards
> >
> > Enablement:
> > * Enable LEDs, DU, SDHI on r8a7792/blanche board
> > * Enable MMCIF and SDHI on r8a7794/alt board
> > * Add SPI and VSP1 to r8a7792 SoC
> > * Add ethernet to r7s72100 SoC
> >
>
> Pulled into next/dt, thanks!
Great, thanks for handling this and the other pull requests I sent last week.
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Laurent Pinchart @ 2016-09-16 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3152956.IVRykDnfF6@wuerfel>
Hi Arnd,
On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> >> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> >>> Hi,
> >>>
> >>> This series tries to solve the problem with DMA with device registers
> >>> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> >>> recent patch '9575632 (dmaengine: make slave address physical)'
> >>> clarifies that DMA slave address provided by clients is the physical
> >>> address. This puts the task of mapping the DMA slave address from a
> >>> phys_addr_t to a dma_addr_t on the DMA engine.
> >>>
> >>> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> >>> the same and no special care is needed. However if you have a IOMMU
> >>> you need to map the DMA slave phys_addr_t to a dma_addr_t using
> >>> something like this.
> >>>
> >>> This series is based on top of v4.8-rc1. And I'm hoping to be able to
> >>> collect a Ack from Russell King on patch 4/6 that adds the ARM
> >>> specific part and then be able to take the whole series through the
> >>> dmaengine tree. If this is not the best route I'm more then happy to
> >>> do it another way.
> >>>
> >>> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> >>> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting
> >>> with /dev/mmcblk1, i2c and the serial console which are devices behind
> >>> the iommu.
> >>
> >> As I said in last one, the dmaengine parts look fine to me. But to go
> >> thru dmaengine tree I would need ACK on non dmaengine patches.
> >
> > I havent heard back from this one and I am inclined to merge this one now.
> > If anyone has any objects, please speak up now...
> >
> > Also ACKs welcome...
>
> I had not looked at the series earlier, but this version looks entirely
> reasonable to me, so
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
>
> One concern I have is that we might get an awkward situation if we ever
> encounter one DMA engine hardware that is used in different systems that all
> have an IOMMU, but on some of them the connection between the DMA master and
> the slave FIFO bypasses the IOMMU while on others the IOMMU is required.
Do you mean systems where some of the channels of a specific DMA engine go
through the IOMMU while others do not ? We indeed have no solution today for
such a situation.
The problem is a bit broader than that, we'll also have an issue with DMA
engines that have different channels served by different IOMMUs. I recall
discussing this in the past with you, and the solution you proposed was to add
a channel index to struct dma_attrs seems good to me. To support the case
where some channels don't go through an IOMMU we would only need support for
null entries in the IOMMUs list associated with a device (for instance in the
DT case null entries in the iommus property).
Now I see that struct dma_attrs has been replaced by unsigned long in
commit 00085f1efa387a8ce100e3734920f7639c80caa3
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Wed Aug 3 13:46:00 2016 -0700
dma-mapping: use unsigned long for dma_attrs
We still have enough bits to reserve some of them for a channel number, but
I'm not very happy with that patch as I can see how a future proposal to
handle the channel number through the DMA attributes will get rejected on the
grounds of bits starvation then :-(
> I don't have any idea for how this could be handled in a generic way, so my
> best answer here is to hope we never get there, and if we do, handle it
> using some local hack in the driver.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: Route vtimer events to user space
From: Christoffer Dall @ 2016-09-16 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474002553-30079-1-git-send-email-agraf@suse.de>
Alex,
On Fri, Sep 16, 2016 at 07:09:13AM +0200, Alexander Graf wrote:
> We have 2 modes for dealing with interrupts in the ARM world. We can either
> handle them all using hardware acceleration through the vgic or we can emulate
> a gic in user space and only drive CPU IRQ pins from there.
>
> Unfortunately, when driving IRQs from user space, we never tell user space
> about timer events that may result in interrupt line state changes, so we
> lose out on timer events if we run with user space gic emulation.
>
> This patch set fixes that by routing vtimer expiration events to user space.
> With this patch I can successfully run edk2 and Linux with user space gic
> emulation.
I have two versions of v2. Are there any differences or did it just go
out twice or got duplicated somehow on my end?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] dmaengine: mv_xor: Add support for scatter-gather DMA mode
From: Stefan Roese @ 2016-09-16 9:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds memory to memory scatter-gather support to the Marvell
mv_or DMA driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>
---
drivers/dma/mv_xor.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/dma/mv_xor.h | 1 +
2 files changed, 180 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index ff4a094..d453aa6 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -68,6 +68,36 @@ static void mv_desc_init(struct mv_xor_desc_slot *desc,
hw_desc->byte_count = byte_count;
}
+/* Populate the descriptor */
+static void mv_xor_config_sg_ll_desc(struct mv_xor_desc_slot *desc,
+ dma_addr_t dma_src, dma_addr_t dma_dst,
+ u32 len, struct mv_xor_desc_slot *prev)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ hw_desc->status = XOR_DESC_DMA_OWNED;
+ hw_desc->phy_next_desc = 0;
+ /* Configure for XOR with only one src address -> MEMCPY */
+ hw_desc->desc_command = XOR_DESC_OPERATION_XOR | (0x1 << 0);
+ hw_desc->phy_dest_addr = dma_dst;
+ hw_desc->phy_src_addr[0] = dma_src;
+ hw_desc->byte_count = len;
+
+ if (prev) {
+ struct mv_xor_desc *hw_prev = prev->hw_desc;
+
+ hw_prev->phy_next_desc = desc->async_tx.phys;
+ }
+}
+
+static void mv_xor_desc_config_eod(struct mv_xor_desc_slot *desc)
+{
+ struct mv_xor_desc *hw_desc = desc->hw_desc;
+
+ /* Enable end-of-descriptor interrupt */
+ hw_desc->desc_command |= XOR_DESC_EOD_INT_EN;
+}
+
static void mv_desc_set_mode(struct mv_xor_desc_slot *desc)
{
struct mv_xor_desc *hw_desc = desc->hw_desc;
@@ -231,8 +261,13 @@ mv_chan_clean_completed_slots(struct mv_xor_chan *mv_chan)
list_for_each_entry_safe(iter, _iter, &mv_chan->completed_slots,
node) {
- if (async_tx_test_ack(&iter->async_tx))
+ if (async_tx_test_ack(&iter->async_tx)) {
list_move_tail(&iter->node, &mv_chan->free_slots);
+ if (!list_empty(&iter->sg_tx_list)) {
+ list_splice_tail_init(&iter->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
}
return 0;
}
@@ -247,11 +282,20 @@ mv_desc_clean_slot(struct mv_xor_desc_slot *desc,
/* the client is allowed to attach dependent operations
* until 'ack' is set
*/
- if (!async_tx_test_ack(&desc->async_tx))
+ if (!async_tx_test_ack(&desc->async_tx)) {
/* move this slot to the completed_slots */
list_move_tail(&desc->node, &mv_chan->completed_slots);
- else
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->completed_slots);
+ }
+ } else {
list_move_tail(&desc->node, &mv_chan->free_slots);
+ if (!list_empty(&desc->sg_tx_list)) {
+ list_splice_tail_init(&desc->sg_tx_list,
+ &mv_chan->free_slots);
+ }
+ }
return 0;
}
@@ -453,6 +497,7 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
dma_async_tx_descriptor_init(&slot->async_tx, chan);
slot->async_tx.tx_submit = mv_xor_tx_submit;
INIT_LIST_HEAD(&slot->node);
+ INIT_LIST_HEAD(&slot->sg_tx_list);
dma_desc = mv_chan->dma_desc_pool;
slot->async_tx.phys = dma_desc + idx * MV_XOR_SLOT_SIZE;
slot->idx = idx++;
@@ -620,6 +665,132 @@ mv_xor_prep_dma_interrupt(struct dma_chan *chan, unsigned long flags)
return mv_xor_prep_dma_xor(chan, dest, &src, 1, len, flags);
}
+/**
+ * mv_xor_prep_dma_sg - prepare descriptors for a memory sg transaction
+ * @chan: DMA channel
+ * @dst_sg: Destination scatter list
+ * @dst_sg_len: Number of entries in destination scatter list
+ * @src_sg: Source scatter list
+ * @src_sg_len: Number of entries in source scatter list
+ * @flags: transfer ack flags
+ *
+ * Return: Async transaction descriptor on success and NULL on failure
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_prep_dma_sg(struct dma_chan *chan, struct scatterlist *dst_sg,
+ unsigned int dst_sg_len, struct scatterlist *src_sg,
+ unsigned int src_sg_len, unsigned long flags)
+{
+ struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
+ struct mv_xor_desc_slot *new;
+ struct mv_xor_desc_slot *first = NULL;
+ struct mv_xor_desc_slot *prev = NULL;
+ size_t len, dst_avail, src_avail;
+ dma_addr_t dma_dst, dma_src;
+ int desc_cnt = 0;
+ int ret;
+
+ dev_dbg(mv_chan_to_devp(mv_chan),
+ "%s dst_sg_len: %d src_sg_len: %d flags: %ld\n",
+ __func__, dst_sg_len, src_sg_len, flags);
+
+ dst_avail = sg_dma_len(dst_sg);
+ src_avail = sg_dma_len(src_sg);
+
+ /* Run until we are out of scatterlist entries */
+ while (true) {
+ /* Allocate and populate the descriptor */
+ desc_cnt++;
+ new = mv_chan_alloc_slot(mv_chan);
+ if (!new) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Out of descriptors (desc_cnt=%d)!\n",
+ desc_cnt);
+ goto err;
+ }
+
+ len = min_t(size_t, src_avail, dst_avail);
+ len = min_t(size_t, len, MV_XOR_MAX_BYTE_COUNT);
+ if (len == 0)
+ goto fetch;
+
+ if (len < MV_XOR_MIN_BYTE_COUNT) {
+ dev_err(mv_chan_to_devp(mv_chan),
+ "Transfer size of %d too small!\n", len);
+ goto err;
+ }
+
+ dma_dst = sg_dma_address(dst_sg) + sg_dma_len(dst_sg) -
+ dst_avail;
+ dma_src = sg_dma_address(src_sg) + sg_dma_len(src_sg) -
+ src_avail;
+
+ /* Check if a new window needs to get added for 'dst' */
+ ret = mv_xor_add_io_win(mv_chan, dma_dst);
+ if (ret)
+ goto err;
+
+ /* Check if a new window needs to get added for 'src' */
+ ret = mv_xor_add_io_win(mv_chan, dma_src);
+ if (ret)
+ goto err;
+
+ /* Populate the descriptor */
+ mv_xor_config_sg_ll_desc(new, dma_src, dma_dst, len, prev);
+ prev = new;
+ dst_avail -= len;
+ src_avail -= len;
+
+ if (!first)
+ first = new;
+ else
+ list_move_tail(&new->node, &first->sg_tx_list);
+
+fetch:
+ /* Fetch the next dst scatterlist entry */
+ if (dst_avail == 0) {
+ if (dst_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ dst_sg = sg_next(dst_sg);
+ if (dst_sg == NULL)
+ break;
+
+ dst_sg_len--;
+ dst_avail = sg_dma_len(dst_sg);
+ }
+
+ /* Fetch the next src scatterlist entry */
+ if (src_avail == 0) {
+ if (src_sg_len == 0)
+ break;
+
+ /* Fetch the next entry: if there are no more: done */
+ src_sg = sg_next(src_sg);
+ if (src_sg == NULL)
+ break;
+
+ src_sg_len--;
+ src_avail = sg_dma_len(src_sg);
+ }
+ }
+
+ /* Set the EOD flag in the last descriptor */
+ mv_xor_desc_config_eod(new);
+ first->async_tx.flags = flags;
+
+ return &first->async_tx;
+
+err:
+ /* Cleanup: Move all descriptors back into the free list */
+ spin_lock_bh(&mv_chan->lock);
+ mv_desc_clean_slot(first, mv_chan);
+ spin_unlock_bh(&mv_chan->lock);
+
+ return NULL;
+}
+
static void mv_xor_free_chan_resources(struct dma_chan *chan)
{
struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
@@ -1086,6 +1257,8 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
dma_dev->device_prep_dma_interrupt = mv_xor_prep_dma_interrupt;
if (dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask))
dma_dev->device_prep_dma_memcpy = mv_xor_prep_dma_memcpy;
+ if (dma_has_cap(DMA_SG, dma_dev->cap_mask))
+ dma_dev->device_prep_dma_sg = mv_xor_prep_dma_sg;
if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
dma_dev->max_xor = 8;
dma_dev->device_prep_dma_xor = mv_xor_prep_dma_xor;
@@ -1135,10 +1308,11 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
goto err_free_irq;
}
- dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s)\n",
+ dev_info(&pdev->dev, "Marvell XOR (%s): ( %s%s%s%s)\n",
mv_chan->op_in_desc ? "Descriptor Mode" : "Registers Mode",
dma_has_cap(DMA_XOR, dma_dev->cap_mask) ? "xor " : "",
dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
+ dma_has_cap(DMA_SG, dma_dev->cap_mask) ? "sg " : "",
dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
dma_async_device_register(dma_dev);
@@ -1381,6 +1555,7 @@ static int mv_xor_probe(struct platform_device *pdev)
dma_cap_zero(cap_mask);
dma_cap_set(DMA_MEMCPY, cap_mask);
+ dma_cap_set(DMA_SG, cap_mask);
dma_cap_set(DMA_XOR, cap_mask);
dma_cap_set(DMA_INTERRUPT, cap_mask);
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index 88eeab2..cf921dd 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -148,6 +148,7 @@ struct mv_xor_chan {
*/
struct mv_xor_desc_slot {
struct list_head node;
+ struct list_head sg_tx_list;
enum dma_transaction_type type;
void *hw_desc;
u16 idx;
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: Kconfig: select GENERIC_CLOCKEVENTS_BROADCAST also on UP
From: Lucas Stach @ 2016-09-16 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467993522-9176-1-git-send-email-l.stach@pengutronix.de>
Hi Russell,
can you please take a look at this and tell if there is something wrong
about it, or if you think it can go in?
Without this patch the kernel is unable to use the deeper CPU idle
states on i.MX6S if it isn't built with SMP support enabled.
Regards,
Lucas
Am Freitag, den 08.07.2016, 17:58 +0200 schrieb Lucas Stach:
> Quite a few systems have deeper idle states where the local timer tick
> stops to fire, that rely on the GENERIC_CLOCKEVENTS_BROADCAST
> infrastructure to switch to a global (non-stopping) clockevent device.
> This is also true on UP systems, so select GENERIC_CLOCKEVENTS_BROADCAST
> unconditionally.
>
> Instead only select ARCH_HAS_TICK_BROADCAST if SMP is present, as this
> is only implemented for SMP systems.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> arch/arm/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 90542db1220d..745843ea769c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -4,7 +4,7 @@ config ARM
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> - select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> + select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST && SMP
> select ARCH_HAVE_CUSTOM_GPIO_H
> select ARCH_HAS_GCOV_PROFILE_ALL
> select ARCH_MIGHT_HAVE_PC_PARPORT
> @@ -20,7 +20,7 @@ config ARM
> select EDAC_ATOMIC_SCRUB
> select GENERIC_ALLOCATOR
> select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> - select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> + select GENERIC_CLOCKEVENTS_BROADCAST
> select GENERIC_EARLY_IOREMAP
> select GENERIC_IDLE_POLL_SETUP
> select GENERIC_IRQ_PROBE
^ permalink raw reply
* [PATCH v3 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Alexander Graf @ 2016-09-16 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA_SGmQVg0COoVArhVtC3TFEEMB3bdT-UTPYvnuwLKANYg@mail.gmail.com>
> On 16 Sep 2016, at 11:11, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On 16 September 2016 at 07:26, Alexander Graf <agraf@suse.de> wrote:
>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>> handle them all using hardware acceleration through the vgic or we can emulate
>> a gic in user space and only drive CPU IRQ pins from there.
>>
>> Unfortunately, when driving IRQs from user space, we never tell user space
>> about timer events that may result in interrupt line state changes, so we
>> lose out on timer events if we run with user space gic emulation.
>>
>> This patch fixes that by routing vtimer expiration events to user space.
>> With this patch I can successfully run edk2 and Linux with user space gic
>> emulation.
>
> Hi Alex. I have some comments just on the userspace API docs.
> These are mostly requests for clarification or expansion, and they
> boil down to "if you gave me this API document change I wouldn't be
> able to deduce from it the necessary changes to QEMU or kvmtool to
> use this functionality?.
Yeah, most of the documentation wouldn?t be enough to deduce the changes you need in user space applications, but I agree that that doesn?t mean we can?t improve going forward :).
>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>> index 23937e0..dec1a78 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -3202,8 +3202,10 @@ struct kvm_run {
>> /* in */
>> __u8 request_interrupt_window;
>>
>> -Request that KVM_RUN return when it becomes possible to inject external
>> +[x86] Request that KVM_RUN return when it becomes possible to inject external
>> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
>> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
>> +trigger forever. Useful with KVM_CAP_ARM_TIMER.
>
> It's only a _u8 and there's more than 8 IRQ lines -- which ones
> can you mask this way?
There are defines for the individual event lines you can mask. I?ll clarify.
>
>> __u8 padding1[7];
>>
>> @@ -3519,6 +3521,16 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
>> event/message pages and to enable/disable SynIC messages/events processing
>> in userspace.
>>
>> + /* KVM_EXIT_ARM_TIMER */
>> + struct {
>> + __u8 timesource;
>> + } arm_timer;
>> +
>> +Indicates that a timer triggered that user space needs to handle and
>> +potentially mask with vcpu->run->request_interrupt_window to allow the
>> +guest to proceed. This only happens for timers that got enabled through
>> +KVM_CAP_ARM_TIMER.
>
> What values can the timesource field contain?
There are defines for that again, I?ll clarify :).
>
>> +
>> /* Fix the size of the union. */
>> char padding[256];
>> };
>> @@ -3739,6 +3751,16 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
>> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
>> the guest.
>>
>> +6.11 KVM_CAP_ARM_TIMER
>> +
>> +Architectures: arm, arm64
>> +Target: vcpu
>> +Parameters: args[0] contains a bitmap of timers to enable
>> +
>> +This capability allows to route per-core timers into user space. When it's
>> +enabled, the enabled timers trigger KVM_EXIT_ARM_TIMER guest exits when they
>> +are pending, unless masked by vcpu->run->request_interrupt_window.
>
> How are the timers enumerated within the bitmap? Which timers can
> be enabled like this?
See above ;).
> Shouldn't this be talking about "timers to route to userspace"
> rather than "timers to enable", since AIUI the timers are always
> enabled regardless of what you set here ?
The counter is enabled, but the timer isn?t, as you can never receive an event. But yes, I agree that the wording isn?t explicit enough. I?ll see if I can come up with something better.
> The KVM_CAP constant name seems rather generic given this is an
> obscure corner of the API.
It basically enables the KVM_EXIT_ARM_TIMER capability - and I didn?t want to make the name too long. Any suggestions?
> What is the mechanism for the kernel to tell userspace when the
> timer *stops* being pending, so it can update the interrupt
It can?t, because it doesn?t know :(. We can?t trap that event.
> level for it in userspace? (What you really want I think is
> for the kernel to notify "timer level goes high" and "timer
> level goes low" and handle the masking internally.)
That?s what I want, but it?s not what hardware gives me. All I can do is poll whether it?s still up - and that?s basically what this interface does.
Alex
^ permalink raw reply
* [PATCH] drm/rockchip: Respect page offset for PRIME mmap calls
From: Tomasz Figa @ 2016-09-16 9:17 UTC (permalink / raw)
To: linux-arm-kernel
From: ?rjan Eide <orjan.eide@arm.com>
When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.
This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.
Fixes: a8594f2 ("drm/rockchip: unset pgoff when mmap'ing gems")
Signed-off-by: ?rjan Eide <orjan.eide@arm.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..cab4d60 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -64,7 +64,6 @@ static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
* VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
*/
vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_pgoff = 0;
ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
obj->size, rk_obj->dma_attrs);
@@ -96,6 +95,12 @@ int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
if (ret)
return ret;
+ /*
+ * Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the
+ * whole buffer from the start.
+ */
+ vma->vm_pgoff = 0;
+
obj = vma->vm_private_data;
return rockchip_drm_gem_object_mmap(obj, vma);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/2] clk: imx6: initialize GPU clocks
From: Lucas Stach @ 2016-09-16 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474017371-28966-1-git-send-email-l.stach@pengutronix.de>
Initialize the GPU clock muxes to sane inputs. Until now they have
not been changed from their default values, which means that both
GPU3D shader and GPU2D core were fed by clock inputs whose rates
exceed the maximium allowed frequency of the cores by as much as
200MHz.
This fixes a severe GPU stability issue on i.MX6DL.
Cc: stable at vger.kernel.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/clk/imx/clk-imx6q.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 64c243173395..751c3e7d5843 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -633,6 +633,24 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
if (IS_ENABLED(CONFIG_PCI_IMX6))
clk_set_parent(clk[IMX6QDL_CLK_LVDS1_SEL], clk[IMX6QDL_CLK_SATA_REF_100M]);
+ /*
+ * Initialize the GPU clock muxes, so that the maximum specified clock
+ * rates for the respective SoC are not exceeded.
+ */
+ if (clk_on_imx6dl()) {
+ clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
+ clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+ clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
+ clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+ } else if (clk_on_imx6q()) {
+ clk_set_parent(clk[IMX6QDL_CLK_GPU3D_CORE_SEL],
+ clk[IMX6QDL_CLK_MMDC_CH0_AXI]);
+ clk_set_parent(clk[IMX6QDL_CLK_GPU3D_SHADER_SEL],
+ clk[IMX6QDL_CLK_PLL2_PFD1_594M]);
+ clk_set_parent(clk[IMX6QDL_CLK_GPU2D_CORE_SEL],
+ clk[IMX6QDL_CLK_PLL3_USB_OTG]);
+ }
+
imx_register_uart_clocks(uart_clks);
}
CLK_OF_DECLARE(imx6q, "fsl,imx6q-ccm", imx6q_clocks_init);
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] clk: imx6: fix i.MX6DL clock tree to reflect reality
From: Lucas Stach @ 2016-09-16 9:16 UTC (permalink / raw)
To: linux-arm-kernel
The current clock tree only implements the minimal set of differences
between the i.MX6Q and the i.MX6DL, but that doesn't really reflect
reality.
Apply the following fixes to match the RM:
- DL has no GPU3D_SHADER_SEL/PODF, the shader domain is clocked by
GPU3D_CORE
- GPU3D_SHADER_SEL/PODF has been repurposed as GPU2D_CORE_SEL/PODF
- GPU2D_CORE_SEL/PODF has been repurposed as MLB_SEL/PODF
Cc: stable at vger.kernel.org
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/clk/imx/clk-imx6q.c | 28 ++++++++++++++++------------
include/dt-bindings/clock/imx6qdl-clock.h | 4 +++-
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index ba1c1ae72ac2..64c243173395 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -318,11 +318,16 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[IMX6QDL_CLK_IPG_PER_SEL] = imx_clk_mux("ipg_per_sel", base + 0x1c, 6, 1, ipg_per_sels, ARRAY_SIZE(ipg_per_sels));
clk[IMX6QDL_CLK_UART_SEL] = imx_clk_mux("uart_sel", base + 0x24, 6, 1, uart_sels, ARRAY_SIZE(uart_sels));
clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 16, 2, gpu2d_core_sels_2, ARRAY_SIZE(gpu2d_core_sels_2));
+ } else if (clk_on_imx6dl()) {
+ clk[IMX6QDL_CLK_MLB_SEL] = imx_clk_mux("mlb_sel", base + 0x18, 16, 2, gpu2d_core_sels, ARRAY_SIZE(gpu2d_core_sels));
} else {
clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 16, 2, gpu2d_core_sels, ARRAY_SIZE(gpu2d_core_sels));
}
clk[IMX6QDL_CLK_GPU3D_CORE_SEL] = imx_clk_mux("gpu3d_core_sel", base + 0x18, 4, 2, gpu3d_core_sels, ARRAY_SIZE(gpu3d_core_sels));
- clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8, 2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
+ if (clk_on_imx6dl())
+ clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 8, 2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
+ else
+ clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8, 2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
clk[IMX6QDL_CLK_IPU1_SEL] = imx_clk_mux("ipu1_sel", base + 0x3c, 9, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[IMX6QDL_CLK_IPU2_SEL] = imx_clk_mux("ipu2_sel", base + 0x3c, 14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[IMX6QDL_CLK_LDB_DI0_SEL] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c, 9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
@@ -400,9 +405,15 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[IMX6QDL_CLK_LDB_DI0_DIV_3_5] = imx_clk_fixed_factor("ldb_di0_div_3_5", "ldb_di0_sel", 2, 7);
clk[IMX6QDL_CLK_LDB_DI1_DIV_3_5] = imx_clk_fixed_factor("ldb_di1_div_3_5", "ldb_di1_sel", 2, 7);
}
- clk[IMX6QDL_CLK_GPU2D_CORE_PODF] = imx_clk_divider("gpu2d_core_podf", "gpu2d_core_sel", base + 0x18, 23, 3);
+ if (clk_on_imx6dl())
+ clk[IMX6QDL_CLK_MLB_PODF] = imx_clk_divider("mlb_podf", "mlb_sel", base + 0x18, 23, 3);
+ else
+ clk[IMX6QDL_CLK_GPU2D_CORE_PODF] = imx_clk_divider("gpu2d_core_podf", "gpu2d_core_sel", base + 0x18, 23, 3);
clk[IMX6QDL_CLK_GPU3D_CORE_PODF] = imx_clk_divider("gpu3d_core_podf", "gpu3d_core_sel", base + 0x18, 26, 3);
- clk[IMX6QDL_CLK_GPU3D_SHADER] = imx_clk_divider("gpu3d_shader", "gpu3d_shader_sel", base + 0x18, 29, 3);
+ if (clk_on_imx6dl())
+ clk[IMX6QDL_CLK_GPU2D_CORE_PODF] = imx_clk_divider("gpu2d_core_podf", "gpu2d_core_sel", base + 0x18, 29, 3);
+ else
+ clk[IMX6QDL_CLK_GPU3D_SHADER] = imx_clk_divider("gpu3d_shader", "gpu3d_shader_sel", base + 0x18, 29, 3);
clk[IMX6QDL_CLK_IPU1_PODF] = imx_clk_divider("ipu1_podf", "ipu1_sel", base + 0x3c, 11, 3);
clk[IMX6QDL_CLK_IPU2_PODF] = imx_clk_divider("ipu2_podf", "ipu2_sel", base + 0x3c, 16, 3);
clk[IMX6QDL_CLK_LDB_DI0_PODF] = imx_clk_divider_flags("ldb_di0_podf", "ldb_di0_div_3_5", base + 0x20, 10, 1, 0);
@@ -473,14 +484,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[IMX6QDL_CLK_ESAI_MEM] = imx_clk_gate2_shared("esai_mem", "ahb", base + 0x6c, 16, &share_count_esai);
clk[IMX6QDL_CLK_GPT_IPG] = imx_clk_gate2("gpt_ipg", "ipg", base + 0x6c, 20);
clk[IMX6QDL_CLK_GPT_IPG_PER] = imx_clk_gate2("gpt_ipg_per", "ipg_per", base + 0x6c, 22);
- if (clk_on_imx6dl())
- /*
- * The multiplexer and divider of imx6q clock gpu3d_shader get
- * redefined/reused as gpu2d_core_sel and gpu2d_core_podf on imx6dl.
- */
- clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu3d_shader", base + 0x6c, 24);
- else
- clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24);
+ clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core", "gpu2d_core_podf", base + 0x6c, 24);
clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core", "gpu3d_core_podf", base + 0x6c, 26);
clk[IMX6QDL_CLK_HDMI_IAHB] = imx_clk_gate2("hdmi_iahb", "ahb", base + 0x70, 0);
clk[IMX6QDL_CLK_HDMI_ISFR] = imx_clk_gate2("hdmi_isfr", "video_27m", base + 0x70, 4);
@@ -511,7 +515,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
* The multiplexer and divider of the imx6q clock gpu2d get
* redefined/reused as mlb_sys_sel and mlb_sys_clk_podf on imx6dl.
*/
- clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb", "gpu2d_core_podf", base + 0x74, 18);
+ clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb", "mlb_podf", base + 0x74, 18);
else
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb", "axi", base + 0x74, 18);
clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2("mmdc_ch0_axi", "mmdc_ch0_axi_podf", base + 0x74, 20);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h b/include/dt-bindings/clock/imx6qdl-clock.h
index 29050337d9d5..da59fd9cdb5e 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -269,6 +269,8 @@
#define IMX6QDL_CLK_PRG0_APB 256
#define IMX6QDL_CLK_PRG1_APB 257
#define IMX6QDL_CLK_PRE_AXI 258
-#define IMX6QDL_CLK_END 259
+#define IMX6QDL_CLK_MLB_SEL 259
+#define IMX6QDL_CLK_MLB_PODF 260
+#define IMX6QDL_CLK_END 261
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.8.1
^ permalink raw reply related
* [PATCH v3 2/2] KVM: arm/arm64: Route vtimer events to user space
From: Peter Maydell @ 2016-09-16 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474007187-18673-3-git-send-email-agraf@suse.de>
On 16 September 2016 at 07:26, Alexander Graf <agraf@suse.de> wrote:
> We have 2 modes for dealing with interrupts in the ARM world. We can either
> handle them all using hardware acceleration through the vgic or we can emulate
> a gic in user space and only drive CPU IRQ pins from there.
>
> Unfortunately, when driving IRQs from user space, we never tell user space
> about timer events that may result in interrupt line state changes, so we
> lose out on timer events if we run with user space gic emulation.
>
> This patch fixes that by routing vtimer expiration events to user space.
> With this patch I can successfully run edk2 and Linux with user space gic
> emulation.
Hi Alex. I have some comments just on the userspace API docs.
These are mostly requests for clarification or expansion, and they
boil down to "if you gave me this API document change I wouldn't be
able to deduce from it the necessary changes to QEMU or kvmtool to
use this functionality".
> Signed-off-by: Alexander Graf <agraf@suse.de>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 23937e0..dec1a78 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3202,8 +3202,10 @@ struct kvm_run {
> /* in */
> __u8 request_interrupt_window;
>
> -Request that KVM_RUN return when it becomes possible to inject external
> +[x86] Request that KVM_RUN return when it becomes possible to inject external
> interrupts into the guest. Useful in conjunction with KVM_INTERRUPT.
> +[arm*] Bits set to 1 in here mask IRQ lines that would otherwise potentially
> +trigger forever. Useful with KVM_CAP_ARM_TIMER.
It's only a _u8 and there's more than 8 IRQ lines -- which ones
can you mask this way?
> __u8 padding1[7];
>
> @@ -3519,6 +3521,16 @@ Hyper-V SynIC state change. Notification is used to remap SynIC
> event/message pages and to enable/disable SynIC messages/events processing
> in userspace.
>
> + /* KVM_EXIT_ARM_TIMER */
> + struct {
> + __u8 timesource;
> + } arm_timer;
> +
> +Indicates that a timer triggered that user space needs to handle and
> +potentially mask with vcpu->run->request_interrupt_window to allow the
> +guest to proceed. This only happens for timers that got enabled through
> +KVM_CAP_ARM_TIMER.
What values can the timesource field contain?
> +
> /* Fix the size of the union. */
> char padding[256];
> };
> @@ -3739,6 +3751,16 @@ Once this is done the KVM_REG_MIPS_VEC_* and KVM_REG_MIPS_MSA_* registers can be
> accessed, and the Config5.MSAEn bit is accessible via the KVM API and also from
> the guest.
>
> +6.11 KVM_CAP_ARM_TIMER
> +
> +Architectures: arm, arm64
> +Target: vcpu
> +Parameters: args[0] contains a bitmap of timers to enable
> +
> +This capability allows to route per-core timers into user space. When it's
> +enabled, the enabled timers trigger KVM_EXIT_ARM_TIMER guest exits when they
> +are pending, unless masked by vcpu->run->request_interrupt_window.
How are the timers enumerated within the bitmap? Which timers can
be enabled like this?
Shouldn't this be talking about "timers to route to userspace"
rather than "timers to enable", since AIUI the timers are always
enabled regardless of what you set here ?
The KVM_CAP constant name seems rather generic given this is an
obscure corner of the API.
What is the mechanism for the kernel to tell userspace when the
timer *stops* being pending, so it can update the interrupt
level for it in userspace? (What you really want I think is
for the kernel to notify "timer level goes high" and "timer
level goes low" and handle the masking internally.)
> +
> 7. Capabilities that can be enabled on VMs
> ------------------------------------------
thanks
-- PMM
^ permalink raw reply
* v4.8-rc: GSM audio causes trouble
From: Pavel Machek @ 2016-09-16 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916055249.h7zw6hguvwwe2zwu@earth>
On Fri 2016-09-16 07:52:50, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Sep 15, 2016 at 10:51:42PM +0200, Pavel Machek wrote:
> > > I was trying to improve GSM call quality, and hit problems in
> > > v4.8-rc. Sound only worked for a while, then I tried to kill
> > > cmtspeech_ofono_test, and could not, not even with -9 and could not
> > > even reboot.
> > >
> > > I went back to v4.1 (ok, quite far, I see), and problems are gone.
> > >
> > > Does it work for you? Any ideas what to try... besides bisect?
> >
> > v4.7 is okay.
> >
> > v4.8 with
> >
> > git diff ..mini-v4.7 drivers/hsi/ | git apply
> >
> > Seems to work ok.
Hmm. I guess I made some error with the testing, because reverting
just drivers/hsi to v4.7 state results in non-compiling kernel
> hsi changes from 4.7 to 4.8 are basically runtime PM enablement.
> Does 4.8 work for you with just 9c99e5e51988 reverted?
No, according to the notes. But see above... and let me retry with
drivers/hsi _and_ include/linux/hsi reverted. No GSM audio and same
problem with shutdown. Oops. Sorry about the confusion.
Does it work for you? Any ideas what could be wrong?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Arnd Bergmann @ 2016-09-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915162650.GZ13920@localhost>
On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> > > Hi,
> > >
> > > This series tries to solve the problem with DMA with device registers
> > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > > recent patch '9575632 (dmaengine: make slave address physical)'
> > > clarifies that DMA slave address provided by clients is the physical
> > > address. This puts the task of mapping the DMA slave address from a
> > > phys_addr_t to a dma_addr_t on the DMA engine.
> > >
> > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > > the same and no special care is needed. However if you have a IOMMU you
> > > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > > like this.
> > >
> > > This series is based on top of v4.8-rc1. And I'm hoping to be able to collect a
> > > Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> > > able to take the whole series through the dmaengine tree. If this is not the
> > > best route I'm more then happy to do it another way.
> > >
> > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > > iommu.
> >
> > As I said in last one, the dmaengine parts look fine to me. But to go thru
> > dmaengine tree I would need ACK on non dmaengine patches.
>
> I havent heard back from this one and I am inclined to merge this one now.
> If anyone has any objects, please speak up now...
>
> Also ACKs welcome...
>
I had not looked at the series earlier, but this version looks entirely
reasonable to me, so
Acked-by: Arnd Bergmann <arnd@arndb.de>
One concern I have is that we might get an awkward situation if we
ever encounter one DMA engine hardware that is used in different
systems that all have an IOMMU, but on some of them the connection
between the DMA master and the slave FIFO bypasses the IOMMU
while on others the IOMMU is required. I don't have any idea for
how this could be handled in a generic way, so my best answer
here is to hope we never get there, and if we do, handle it
using some local hack in the driver.
Arnd
^ permalink raw reply
* [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks
From: Gabriele Paoloni @ 2016-09-16 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915105849.GA10345@red-moon>
Hi Lorenzo and Tomasz
Many Thanks for looking at this
> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi at arm.com]
> Sent: 15 September 2016 11:59
> To: liudongdong (C)
> Cc: Tomasz Nowicki; helgaas at kernel.org; will.deacon at arm.com;
> catalin.marinas at arm.com; rafael at kernel.org; arnd at arndb.de;
> hanjun.guo at linaro.org; okaya at codeaurora.org; jchandra at broadcom.com;
> cov at codeaurora.org; dhdang at apm.com; ard.biesheuvel at linaro.org;
> robert.richter at caviumnetworks.com; mw at semihalf.com;
> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> msalter at redhat.com; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org;
> jcm at redhat.com; andrea.gallo at linaro.org; jeremy.linton at arm.com;
> Gabriele Paoloni; jhugo at codeaurora.org; linux-acpi at vger.kernel.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM
> quirks
>
> On Tue, Sep 13, 2016 at 07:38:39PM +0800, Dongdong Liu wrote:
>
> [...]
>
> > Our host bridge is non ECAM only for the RC bus config space;
> > for any other bus underneath the root bus we support ECAM access.
> >
> > RC config resource with hardcode as DEFINE_RES_MEM(0xb0070000,
> SZ_4K),
> > EP config resource we get it from MCFG table.
> > So we need to override ops, but config resource we only need to
> hardcode with RC config resource.
> >
> > Our host controller ACPI support patch can be found:
> > https://lkml.org/lkml/2016/8/31/340
>
> Sorry I misread your code. IIUC you create an array of resources that
> represent non-ECAM config space (and incidentally contain debug
> registers to check the link status - that you need to check for every
> given config access (?)), but you still need to have an MCFG entry that
The link status check is inherited from the designware framework (see
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L678)
However I think that in this case we can just check the link status
in our init function and return an error if the link is down
> covers the bus number subject to quirk to make sure this mechanism
> works. Correct ?
Well we need the quirks for the root bus numbers but if read this v6
quirk mechanism correctly even if we do not specify an mcfg entry for
bus 0 oci_mcfg_match_quirks() is called anyway and we can set our
special configuration space addresses for the root buses (i.e. I think
we can have a clean MCFG table with entries only for those bus ranges
that are really ECAM)
>
> This also means that, with the MCFG tables you have and current
> mainline kernel you are able to probe a root bridge (because the MCFG
> table covers the bus number that is not ECAM), with enumeration
> going haywire because it is trying to carry out ECAM accesses on
> non-ECAM space.
Yes correct, we cannot access the host controller configuration space
with our current MCFG table and current Linux mainline
>
> Is my reading correct ?
>
> Anyway, that's not stricly related to this discussion, it is time we
> converge on this patchset, we can add a domain range if that
> simplifies things.
IMO it would be better to have the domain range to avoid
a very large and repetitive static quirk array
Thanks
Gab
>
> Thanks,
> Lorenzo
>
> > This patch is based on RFC V5 quirk mechanism.
> >
> > Based on V6 quirk mechanism, we have to change it as below:
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > { "HISI ", "HIP05 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> > ....
> >
> > { "HISI ", "HIP07 ", 0, 15, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> >
> > #endif
> >
> > struct pci_ecam_ops hisi_pci_hip05_ops = {
> > .bus_shift = 20,
> > .init = hisi_pci_hip05_init,
> > .pci_ops = {
> > .map_bus = pci_ecam_map_bus,
> > .read = hisi_pcie_acpi_rd_conf,
> > .write = hisi_pcie_acpi_wr_conf,
> > }
> > };
> >
> > struct pci_ecam_ops hisi_pci_hip06_ops = {
> > .bus_shift = 20,
> > .init = hisi_pci_hip06_init,
> > .pci_ops = {
> > .map_bus = pci_ecam_map_bus,
> > .read = hisi_pcie_acpi_rd_conf,
> > .write = hisi_pcie_acpi_wr_conf,
> > }
> > };
> >
> > hisi_pci_hipxx_init function is used to get RC config resource with
> hardcode.
> > .....
> >
> > So I hope we can use MCFG_DOM_RANGE, Then I can change it as below.
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > { "HISI ", "HIP05 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > &hisi_pcie_hip05_ops, MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > &hisi_pcie_hip06_ops, MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, MCFG_DOM_RANGE(0, 15), MCFG_BUS_ANY,
> > &hisi_pcie_hip07_ops, MCFG_RES_EMPTY},
> > #endif
> >
> > Thanks
> > Dongdong
> > >
> > >Thanks,
> > >Tomasz
> > >
> > >.
> > >
> >
^ permalink raw reply
* [PATCH] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Will Deacon @ 2016-09-16 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473689244-147136-1-git-send-email-labath@google.com>
Hi Pavel,
On Mon, Sep 12, 2016 at 03:07:24PM +0100, Pavel Labath wrote:
> Arm64 hardware does not always report a watchpoint hit address that
> matches one of the watchpoints set. It can also report an address
> "near" the watchpoint if a single instruction access both watched and
> unwatched addresses. There is no straight-forward way, short of
> disassembling the offending instruction, to map that address back to
> the watchpoint.
>
> Previously, when the hardware reported a watchpoint hit on an address
> that did not match our watchpoint (this happens in case of instructions
> which access large chunks of memory such as "stp") the process would
> enter a loop where we would be continually resuming it (because we did
> not recognise that watchpoint hit) and it would keep hitting the
> watchpoint again and again. The tracing process would never get
> notified of the watchpoint hit.
>
> This commit fixes the problem by looking at the watchpoints near the
> address reported by the hardware. If the address does not exactly match
> one of the watchpoints we have set, it attributes the hit to the
> nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
> think we can do much more, given the hardware limitations.
> I include a kernel selftest which triggers this code.
Thanks for the patch. Comments inline.
> Signed-off-by: Pavel Labath <labath@google.com>
> ---
> arch/arm64/kernel/hw_breakpoint.c | 104 +++++++---
> tools/testing/selftests/breakpoints/Makefile | 5 +-
> .../selftests/breakpoints/breakpoint_test-arm.c | 217 +++++++++++++++++++++
> 3 files changed, 298 insertions(+), 28 deletions(-)
> create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test-arm.c
Could you split the test out into a separate patch please?
> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> index 26a6bf7..d0ebfe6 100644
> --- a/arch/arm64/kernel/hw_breakpoint.c
> +++ b/arch/arm64/kernel/hw_breakpoint.c
> @@ -661,50 +661,80 @@ unlock:
> }
> NOKPROBE_SYMBOL(breakpoint_handler);
>
> +/*
> + * Arm64 hardware does not always report a watchpoint hit address that matches
> + * one of the watchpoints set. It can also report an address "near" the
> + * watchpoint if a single instruction access both watched and unwatched
> + * addresses. There is no straight-forward way, short of disassembling the
> + * offending instruction, to map that address back to the watchpoint. This
> + * function computes the distance of the memory access from the watchpoint as a
> + * heuristic for the likelyhood that a given access triggered the watchpoint.
> + *
> + * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
> + * exception" of ARMv8 Architecture Reference Manual for details.
> + *
> + * The function returns the distance of the address from the bytes watched by
> + * the watchpoint. In case of an exact match, it returns 0.
> + */
> +static u64 get_distance_from_watchpoint(unsigned long addr, int i,
> + struct arch_hw_breakpoint *info)
> +{
> + u64 val, alignment_mask, wp_low, wp_high;
> + u32 ctrl_reg;
> + int first_bit;
> + struct arch_hw_breakpoint_ctrl ctrl;
> +
> + /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
> + if (is_compat_task()) {
> + if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
> + alignment_mask = 0x7;
> + else
> + alignment_mask = 0x3;
> + } else {
> + alignment_mask = 0x7;
> + }
We have identical logic elsewhere in this file, so please stick this into
a get_watchpoint_alignment_mask function.
> +
> + val = read_wb_reg(AARCH64_DBG_REG_WVR, i) & ~alignment_mask;
> +
> + ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
> + decode_ctrl_reg(ctrl_reg, &ctrl);
> + first_bit = ffs(ctrl.len);
> + if (first_bit == 0)
> + return -1;
> + wp_low = val + first_bit - 1;
> + wp_high = val + fls(ctrl.len) - 1;
> + if (addr < wp_low)
> + return wp_low - addr;
> + else if (addr > wp_high)
> + return addr - wp_high;
Why do you need to read the control register? We already have the length
in the arch_hw_breakpoint, and that should be sufficient for the check, no?
> static int watchpoint_handler(unsigned long addr, unsigned int esr,
> struct pt_regs *regs)
> {
> - int i, step = 0, *kernel_step, access;
> - u32 ctrl_reg;
> - u64 val, alignment_mask;
> + int i, step = 0, *kernel_step, access, closest_match;
> + u64 min_dist = -1, dist;
> struct perf_event *wp, **slots;
> struct debug_info *debug_info;
> struct arch_hw_breakpoint *info;
> - struct arch_hw_breakpoint_ctrl ctrl;
>
> slots = this_cpu_ptr(wp_on_reg);
> debug_info = ¤t->thread.debug;
>
> + /*
> + * Find all watchpoints that match the reported address. If no exact
> + * match is found. Attribute the hit to the closest watchpoint.
> + */
> for (i = 0; i < core_num_wrps; ++i) {
> rcu_read_lock();
>
> wp = slots[i];
> -
> if (wp == NULL)
> goto unlock;
>
> - info = counter_arch_bp(wp);
> - /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
> - if (is_compat_task()) {
> - if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
> - alignment_mask = 0x7;
> - else
> - alignment_mask = 0x3;
> - } else {
> - alignment_mask = 0x7;
> - }
> -
> - /* Check if the watchpoint value matches. */
> - val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
> - if (val != (addr & ~alignment_mask))
> - goto unlock;
> -
> - /* Possible match, check the byte address select to confirm. */
> - ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
> - decode_ctrl_reg(ctrl_reg, &ctrl);
> - if (!((1 << (addr & alignment_mask)) & ctrl.len))
> - goto unlock;
> -
> /*
> * Check that the access type matches.
> * 0 => load, otherwise => store
> @@ -714,6 +744,17 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
> if (!(access & hw_breakpoint_type(wp)))
> goto unlock;
>
> + info = counter_arch_bp(wp);
> +
> + dist = get_distance_from_watchpoint(addr, i, info);
> + if (dist < min_dist) {
> + min_dist = dist;
> + closest_match = i;
> + }
> + /* Is this an exact match? */
> + if (dist != 0)
> + goto unlock;
> +
> info->trigger = addr;
> perf_bp_event(wp, regs);
>
> @@ -724,6 +765,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
> unlock:
> rcu_read_unlock();
> }
> + if (min_dist > 0 && min_dist != -1) {
> + /* No exact match found. */
> + rcu_read_lock();
> + wp = slots[closest_match];
> + info = counter_arch_bp(wp);
> + info->trigger = addr;
> + perf_bp_event(wp, regs);
> + rcu_read_unlock();
Hmm, are you sure it's safe to drop and retake the RCU lock here? If the
event is destroyed before we retake the RCU lock, won't htis go horribly
wrong? It's probably best to hold the lock outside the loop :(
Will
^ permalink raw reply
* linux-next: manual merge of the samsung-krzk tree with the arm-soc tree
From: Krzysztof Kozlowski @ 2016-09-16 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160905111948.553487be@canb.auug.org.au>
On 09/05/2016 03:19 AM, Stephen Rothwell wrote:
> Hi Krzysztof,
>
> Today's linux-next merge of the samsung-krzk tree got a conflict in:
>
> arch/arm64/boot/dts/exynos/exynos7.dtsi
>
> between commit:
>
> 585dcacac6bb ("arm64: dts: Fix broken architected timer interrupt trigger")
>
> from the arm-soc tree and commit:
>
> 36d1c9cd07cd ("arm64: dts: exynos: Use human-friendly symbols for timer interrupt flags")
>
> from the samsung-krzk tree.
>
> I fixed it up (I *think* - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
The fix is correct, for the record:
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Merge conflict was (unfortunately) expected. In general, the
multiple-platform-at-once patches are conflict prone. Especially in this
case, Marc's patch ("arm64: dts: Fix broken architected...") could be
split per architecture.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] KVM: arm/arm64: Route vtimer events to user space
From: kbuild test robot @ 2016-09-16 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473981320-25387-1-git-send-email-agraf@suse.de>
Hi Alexander,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.8-rc6 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Alexander-Graf/KVM-arm-arm64-Route-vtimer-events-to-user-space/20160916-073838
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All error/warnings (new ones prefixed by >>):
arch/arm64/kvm/../../../arch/arm/kvm/arm.c: In function 'kvm_arch_vcpu_ioctl':
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1000:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1016:12: error: invalid storage class for function 'kvm_vm_ioctl_set_device_addr'
static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1077:13: error: invalid storage class for function 'cpu_init_hyp_mode'
static void cpu_init_hyp_mode(void *dummy)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1098:13: error: invalid storage class for function 'cpu_hyp_reinit'
static void cpu_hyp_reinit(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1112:13: error: invalid storage class for function 'cpu_hyp_reset'
static void cpu_hyp_reset(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1119:13: error: invalid storage class for function '_kvm_arch_hardware_enable'
static void _kvm_arch_hardware_enable(void *discard)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1133:13: error: invalid storage class for function '_kvm_arch_hardware_disable'
static void _kvm_arch_hardware_disable(void *discard)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1147:12: error: invalid storage class for function 'hyp_init_cpu_pm_notifier'
static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1180:19: error: initializer element is not constant
.notifier_call = hyp_init_cpu_pm_notifier,
^
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1180:19: note: (near initialization for 'hyp_init_cpu_pm_nb.notifier_call')
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1183:20: error: invalid storage class for function 'hyp_cpu_pm_init'
static void __init hyp_cpu_pm_init(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1187:20: error: invalid storage class for function 'hyp_cpu_pm_exit'
static void __init hyp_cpu_pm_exit(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1200:13: error: invalid storage class for function 'teardown_common_resources'
static void teardown_common_resources(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1205:12: error: invalid storage class for function 'init_common_resources'
static int init_common_resources(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1216:12: error: invalid storage class for function 'init_subsystems'
static int init_subsystems(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1263:13: error: invalid storage class for function 'teardown_hyp_mode'
static void teardown_hyp_mode(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1276:12: error: invalid storage class for function 'init_vhe_mode'
static int init_vhe_mode(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1289:12: error: invalid storage class for function 'init_hyp_mode'
static int init_hyp_mode(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1379:13: error: invalid storage class for function 'check_kvm_target_cpu'
static void check_kvm_target_cpu(void *ret)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1448:12: error: invalid storage class for function 'arm_init'
static int arm_init(void)
^
In file included from include/linux/printk.h:5:0,
from include/linux/kernel.h:13,
from include/linux/cpu_pm.h:21,
from arch/arm64/kvm/../../../arch/arm/kvm/arm.c:19:
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1454:13: error: initializer element is not constant
module_init(arm_init);
^
include/linux/init.h:182:58: note: in definition of macro '__define_initcall'
__attribute__((__section__(".initcall" #id ".init"))) = fn; \
^
include/linux/init.h:217:24: note: in expansion of macro 'device_initcall'
#define __initcall(fn) device_initcall(fn)
^
include/linux/module.h:86:24: note: in expansion of macro '__initcall'
#define module_init(x) __initcall(x);
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1454:1: note: in expansion of macro 'module_init'
module_init(arm_init);
^
vim +/kvm_vm_ioctl_set_device_addr +1016 arch/arm64/kvm/../../../arch/arm/kvm/arm.c
53c810c36 Mario Smarduch 2015-01-15 994 *
53c810c36 Mario Smarduch 2015-01-15 995 * 1. Take a snapshot of the bit and clear it if needed.
53c810c36 Mario Smarduch 2015-01-15 996 * 2. Write protect the corresponding page.
53c810c36 Mario Smarduch 2015-01-15 997 * 3. Copy the snapshot to the userspace.
53c810c36 Mario Smarduch 2015-01-15 998 * 4. Flush TLB's if needed.
53c810c36 Mario Smarduch 2015-01-15 999 */
749cf76c5 Christoffer Dall 2013-01-20 @1000 int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
749cf76c5 Christoffer Dall 2013-01-20 1001 {
53c810c36 Mario Smarduch 2015-01-15 1002 bool is_dirty = false;
53c810c36 Mario Smarduch 2015-01-15 1003 int r;
53c810c36 Mario Smarduch 2015-01-15 1004
53c810c36 Mario Smarduch 2015-01-15 1005 mutex_lock(&kvm->slots_lock);
53c810c36 Mario Smarduch 2015-01-15 1006
53c810c36 Mario Smarduch 2015-01-15 1007 r = kvm_get_dirty_log_protect(kvm, log, &is_dirty);
53c810c36 Mario Smarduch 2015-01-15 1008
53c810c36 Mario Smarduch 2015-01-15 1009 if (is_dirty)
53c810c36 Mario Smarduch 2015-01-15 1010 kvm_flush_remote_tlbs(kvm);
53c810c36 Mario Smarduch 2015-01-15 1011
53c810c36 Mario Smarduch 2015-01-15 1012 mutex_unlock(&kvm->slots_lock);
53c810c36 Mario Smarduch 2015-01-15 1013 return r;
749cf76c5 Christoffer Dall 2013-01-20 1014 }
749cf76c5 Christoffer Dall 2013-01-20 1015
3401d5469 Christoffer Dall 2013-01-23 @1016 static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
3401d5469 Christoffer Dall 2013-01-23 1017 struct kvm_arm_device_addr *dev_addr)
3401d5469 Christoffer Dall 2013-01-23 1018 {
330690cdc Christoffer Dall 2013-01-21 1019 unsigned long dev_id, type;
330690cdc Christoffer Dall 2013-01-21 1020
330690cdc Christoffer Dall 2013-01-21 1021 dev_id = (dev_addr->id & KVM_ARM_DEVICE_ID_MASK) >>
330690cdc Christoffer Dall 2013-01-21 1022 KVM_ARM_DEVICE_ID_SHIFT;
330690cdc Christoffer Dall 2013-01-21 1023 type = (dev_addr->id & KVM_ARM_DEVICE_TYPE_MASK) >>
330690cdc Christoffer Dall 2013-01-21 1024 KVM_ARM_DEVICE_TYPE_SHIFT;
330690cdc Christoffer Dall 2013-01-21 1025
330690cdc Christoffer Dall 2013-01-21 1026 switch (dev_id) {
330690cdc Christoffer Dall 2013-01-21 1027 case KVM_ARM_DEVICE_VGIC_V2:
c7da6fa43 Pavel Fedin 2015-12-18 1028 if (!vgic_present)
c7da6fa43 Pavel Fedin 2015-12-18 1029 return -ENXIO;
ce01e4e88 Christoffer Dall 2013-09-23 1030 return kvm_vgic_addr(kvm, type, &dev_addr->addr, true);
330690cdc Christoffer Dall 2013-01-21 1031 default:
3401d5469 Christoffer Dall 2013-01-23 1032 return -ENODEV;
3401d5469 Christoffer Dall 2013-01-23 1033 }
330690cdc Christoffer Dall 2013-01-21 1034 }
3401d5469 Christoffer Dall 2013-01-23 1035
749cf76c5 Christoffer Dall 2013-01-20 1036 long kvm_arch_vm_ioctl(struct file *filp,
749cf76c5 Christoffer Dall 2013-01-20 1037 unsigned int ioctl, unsigned long arg)
749cf76c5 Christoffer Dall 2013-01-20 1038 {
3401d5469 Christoffer Dall 2013-01-23 1039 struct kvm *kvm = filp->private_data;
3401d5469 Christoffer Dall 2013-01-23 1040 void __user *argp = (void __user *)arg;
3401d5469 Christoffer Dall 2013-01-23 1041
3401d5469 Christoffer Dall 2013-01-23 1042 switch (ioctl) {
5863c2ce7 Marc Zyngier 2013-01-21 1043 case KVM_CREATE_IRQCHIP: {
a28ebea2a Christoffer Dall 2016-08-09 1044 int ret;
c7da6fa43 Pavel Fedin 2015-12-18 1045 if (!vgic_present)
c7da6fa43 Pavel Fedin 2015-12-18 1046 return -ENXIO;
a28ebea2a Christoffer Dall 2016-08-09 1047 mutex_lock(&kvm->lock);
a28ebea2a Christoffer Dall 2016-08-09 1048 ret = kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
a28ebea2a Christoffer Dall 2016-08-09 1049 mutex_unlock(&kvm->lock);
a28ebea2a Christoffer Dall 2016-08-09 1050 return ret;
5863c2ce7 Marc Zyngier 2013-01-21 1051 }
3401d5469 Christoffer Dall 2013-01-23 1052 case KVM_ARM_SET_DEVICE_ADDR: {
3401d5469 Christoffer Dall 2013-01-23 1053 struct kvm_arm_device_addr dev_addr;
3401d5469 Christoffer Dall 2013-01-23 1054
3401d5469 Christoffer Dall 2013-01-23 1055 if (copy_from_user(&dev_addr, argp, sizeof(dev_addr)))
3401d5469 Christoffer Dall 2013-01-23 1056 return -EFAULT;
3401d5469 Christoffer Dall 2013-01-23 1057 return kvm_vm_ioctl_set_device_addr(kvm, &dev_addr);
3401d5469 Christoffer Dall 2013-01-23 1058 }
42c4e0c77 Anup Patel 2013-09-30 1059 case KVM_ARM_PREFERRED_TARGET: {
42c4e0c77 Anup Patel 2013-09-30 1060 int err;
42c4e0c77 Anup Patel 2013-09-30 1061 struct kvm_vcpu_init init;
42c4e0c77 Anup Patel 2013-09-30 1062
42c4e0c77 Anup Patel 2013-09-30 1063 err = kvm_vcpu_preferred_target(&init);
42c4e0c77 Anup Patel 2013-09-30 1064 if (err)
42c4e0c77 Anup Patel 2013-09-30 1065 return err;
42c4e0c77 Anup Patel 2013-09-30 1066
42c4e0c77 Anup Patel 2013-09-30 1067 if (copy_to_user(argp, &init, sizeof(init)))
42c4e0c77 Anup Patel 2013-09-30 1068 return -EFAULT;
42c4e0c77 Anup Patel 2013-09-30 1069
42c4e0c77 Anup Patel 2013-09-30 1070 return 0;
42c4e0c77 Anup Patel 2013-09-30 1071 }
3401d5469 Christoffer Dall 2013-01-23 1072 default:
749cf76c5 Christoffer Dall 2013-01-20 1073 return -EINVAL;
749cf76c5 Christoffer Dall 2013-01-20 1074 }
3401d5469 Christoffer Dall 2013-01-23 1075 }
749cf76c5 Christoffer Dall 2013-01-20 1076
d157f4a51 Marc Zyngier 2013-04-12 @1077 static void cpu_init_hyp_mode(void *dummy)
342cd0ab0 Christoffer Dall 2013-01-20 1078 {
dac288f7b Marc Zyngier 2013-05-14 1079 phys_addr_t pgd_ptr;
342cd0ab0 Christoffer Dall 2013-01-20 1080 unsigned long hyp_stack_ptr;
342cd0ab0 Christoffer Dall 2013-01-20 1081 unsigned long stack_page;
342cd0ab0 Christoffer Dall 2013-01-20 1082 unsigned long vector_ptr;
342cd0ab0 Christoffer Dall 2013-01-20 1083
342cd0ab0 Christoffer Dall 2013-01-20 1084 /* Switch from the HYP stub to our own HYP init vector */
5a677ce04 Marc Zyngier 2013-04-12 1085 __hyp_set_vectors(kvm_get_idmap_vector());
342cd0ab0 Christoffer Dall 2013-01-20 1086
dac288f7b Marc Zyngier 2013-05-14 1087 pgd_ptr = kvm_mmu_get_httbr();
1436c1aa6 Christoph Lameter 2013-10-21 1088 stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
342cd0ab0 Christoffer Dall 2013-01-20 1089 hyp_stack_ptr = stack_page + PAGE_SIZE;
a0bf9776c Ard Biesheuvel 2016-02-16 1090 vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
342cd0ab0 Christoffer Dall 2013-01-20 1091
12fda8123 Marc Zyngier 2016-06-30 1092 __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
35a2491a6 Marc Zyngier 2016-02-01 1093 __cpu_init_stage2();
56c7f5e77 Alex Benn?e 2015-07-07 1094
56c7f5e77 Alex Benn?e 2015-07-07 1095 kvm_arm_init_debug();
342cd0ab0 Christoffer Dall 2013-01-20 1096 }
342cd0ab0 Christoffer Dall 2013-01-20 1097
5f5560b1c James Morse 2016-03-30 @1098 static void cpu_hyp_reinit(void)
5f5560b1c James Morse 2016-03-30 1099 {
5f5560b1c James Morse 2016-03-30 1100 if (is_kernel_in_hyp_mode()) {
5f5560b1c James Morse 2016-03-30 1101 /*
67f691976 AKASHI Takahiro 2016-04-27 1102 * __cpu_init_stage2() is safe to call even if the PM
5f5560b1c James Morse 2016-03-30 1103 * event was cancelled before the CPU was reset.
5f5560b1c James Morse 2016-03-30 1104 */
67f691976 AKASHI Takahiro 2016-04-27 1105 __cpu_init_stage2();
5f5560b1c James Morse 2016-03-30 1106 } else {
5f5560b1c James Morse 2016-03-30 1107 if (__hyp_get_vectors() == hyp_default_vectors)
5f5560b1c James Morse 2016-03-30 1108 cpu_init_hyp_mode(NULL);
5f5560b1c James Morse 2016-03-30 1109 }
5f5560b1c James Morse 2016-03-30 1110 }
5f5560b1c James Morse 2016-03-30 1111
67f691976 AKASHI Takahiro 2016-04-27 @1112 static void cpu_hyp_reset(void)
67f691976 AKASHI Takahiro 2016-04-27 1113 {
12fda8123 Marc Zyngier 2016-06-30 1114 if (!is_kernel_in_hyp_mode())
e537ecd7e Marc Zyngier 2016-06-30 1115 __cpu_reset_hyp_mode(hyp_default_vectors,
e537ecd7e Marc Zyngier 2016-06-30 1116 kvm_get_idmap_start());
67f691976 AKASHI Takahiro 2016-04-27 1117 }
67f691976 AKASHI Takahiro 2016-04-27 1118
67f691976 AKASHI Takahiro 2016-04-27 @1119 static void _kvm_arch_hardware_enable(void *discard)
d157f4a51 Marc Zyngier 2013-04-12 1120 {
67f691976 AKASHI Takahiro 2016-04-27 1121 if (!__this_cpu_read(kvm_arm_hardware_enabled)) {
5f5560b1c James Morse 2016-03-30 1122 cpu_hyp_reinit();
67f691976 AKASHI Takahiro 2016-04-27 1123 __this_cpu_write(kvm_arm_hardware_enabled, 1);
67f691976 AKASHI Takahiro 2016-04-27 1124 }
d157f4a51 Marc Zyngier 2013-04-12 1125 }
d157f4a51 Marc Zyngier 2013-04-12 1126
67f691976 AKASHI Takahiro 2016-04-27 1127 int kvm_arch_hardware_enable(void)
67f691976 AKASHI Takahiro 2016-04-27 1128 {
67f691976 AKASHI Takahiro 2016-04-27 1129 _kvm_arch_hardware_enable(NULL);
67f691976 AKASHI Takahiro 2016-04-27 1130 return 0;
342cd0ab0 Christoffer Dall 2013-01-20 1131 }
342cd0ab0 Christoffer Dall 2013-01-20 1132
67f691976 AKASHI Takahiro 2016-04-27 @1133 static void _kvm_arch_hardware_disable(void *discard)
67f691976 AKASHI Takahiro 2016-04-27 1134 {
67f691976 AKASHI Takahiro 2016-04-27 1135 if (__this_cpu_read(kvm_arm_hardware_enabled)) {
67f691976 AKASHI Takahiro 2016-04-27 1136 cpu_hyp_reset();
67f691976 AKASHI Takahiro 2016-04-27 1137 __this_cpu_write(kvm_arm_hardware_enabled, 0);
67f691976 AKASHI Takahiro 2016-04-27 1138 }
67f691976 AKASHI Takahiro 2016-04-27 1139 }
67f691976 AKASHI Takahiro 2016-04-27 1140
67f691976 AKASHI Takahiro 2016-04-27 1141 void kvm_arch_hardware_disable(void)
67f691976 AKASHI Takahiro 2016-04-27 1142 {
67f691976 AKASHI Takahiro 2016-04-27 1143 _kvm_arch_hardware_disable(NULL);
67f691976 AKASHI Takahiro 2016-04-27 1144 }
d157f4a51 Marc Zyngier 2013-04-12 1145
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1146 #ifdef CONFIG_CPU_PM
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 @1147 static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1148 unsigned long cmd,
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1149 void *v)
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1150 {
67f691976 AKASHI Takahiro 2016-04-27 1151 /*
67f691976 AKASHI Takahiro 2016-04-27 1152 * kvm_arm_hardware_enabled is left with its old value over
67f691976 AKASHI Takahiro 2016-04-27 1153 * PM_ENTER->PM_EXIT. It is used to indicate PM_EXIT should
67f691976 AKASHI Takahiro 2016-04-27 1154 * re-enable hyp.
67f691976 AKASHI Takahiro 2016-04-27 1155 */
67f691976 AKASHI Takahiro 2016-04-27 1156 switch (cmd) {
67f691976 AKASHI Takahiro 2016-04-27 1157 case CPU_PM_ENTER:
67f691976 AKASHI Takahiro 2016-04-27 1158 if (__this_cpu_read(kvm_arm_hardware_enabled))
67f691976 AKASHI Takahiro 2016-04-27 1159 /*
67f691976 AKASHI Takahiro 2016-04-27 1160 * don't update kvm_arm_hardware_enabled here
67f691976 AKASHI Takahiro 2016-04-27 1161 * so that the hardware will be re-enabled
67f691976 AKASHI Takahiro 2016-04-27 1162 * when we resume. See below.
67f691976 AKASHI Takahiro 2016-04-27 1163 */
67f691976 AKASHI Takahiro 2016-04-27 1164 cpu_hyp_reset();
67f691976 AKASHI Takahiro 2016-04-27 1165
67f691976 AKASHI Takahiro 2016-04-27 1166 return NOTIFY_OK;
67f691976 AKASHI Takahiro 2016-04-27 1167 case CPU_PM_EXIT:
67f691976 AKASHI Takahiro 2016-04-27 1168 if (__this_cpu_read(kvm_arm_hardware_enabled))
67f691976 AKASHI Takahiro 2016-04-27 1169 /* The hardware was enabled before suspend. */
5f5560b1c James Morse 2016-03-30 1170 cpu_hyp_reinit();
67f691976 AKASHI Takahiro 2016-04-27 1171
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1172 return NOTIFY_OK;
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1173
67f691976 AKASHI Takahiro 2016-04-27 1174 default:
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1175 return NOTIFY_DONE;
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1176 }
67f691976 AKASHI Takahiro 2016-04-27 1177 }
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1178
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1179 static struct notifier_block hyp_init_cpu_pm_nb = {
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 @1180 .notifier_call = hyp_init_cpu_pm_notifier,
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1181 };
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1182
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 @1183 static void __init hyp_cpu_pm_init(void)
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1184 {
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1185 cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1186 }
06a71a24b Sudeep Holla 2016-04-04 @1187 static void __init hyp_cpu_pm_exit(void)
06a71a24b Sudeep Holla 2016-04-04 1188 {
06a71a24b Sudeep Holla 2016-04-04 1189 cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
06a71a24b Sudeep Holla 2016-04-04 1190 }
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1191 #else
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1192 static inline void hyp_cpu_pm_init(void)
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1193 {
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1194 }
06a71a24b Sudeep Holla 2016-04-04 1195 static inline void hyp_cpu_pm_exit(void)
06a71a24b Sudeep Holla 2016-04-04 1196 {
06a71a24b Sudeep Holla 2016-04-04 1197 }
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1198 #endif
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1199
1e947bad0 Marc Zyngier 2015-01-29 @1200 static void teardown_common_resources(void)
1e947bad0 Marc Zyngier 2015-01-29 1201 {
1e947bad0 Marc Zyngier 2015-01-29 1202 free_percpu(kvm_host_cpu_state);
1e947bad0 Marc Zyngier 2015-01-29 1203 }
1e947bad0 Marc Zyngier 2015-01-29 1204
1e947bad0 Marc Zyngier 2015-01-29 @1205 static int init_common_resources(void)
1e947bad0 Marc Zyngier 2015-01-29 1206 {
1e947bad0 Marc Zyngier 2015-01-29 1207 kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
1e947bad0 Marc Zyngier 2015-01-29 1208 if (!kvm_host_cpu_state) {
:::::: The code at line 1016 was first introduced by commit
:::::: 3401d54696f992edf036f00f46c8c399d1b75c2a KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR ioctl
:::::: TO: Christoffer Dall <c.dall@virtualopensystems.com>
:::::: CC: Marc Zyngier <marc.zyngier@arm.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 51309 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/1dd442e8/attachment-0001.obj>
^ permalink raw reply
* [PATCH v2 0/5] Cavium ThunderX uncore PMU support
From: Jan Glauber @ 2016-09-16 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916075523.GJ3380@arm.com>
On Fri, Sep 16, 2016 at 08:55:24AM +0100, Will Deacon wrote:
> Hi Jan,
>
> On Mon, Jul 04, 2016 at 11:11:32AM +0100, Will Deacon wrote:
> > On Tue, Jun 28, 2016 at 04:04:59PM +0200, Jan Glauber wrote:
> > > On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote:
> > > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote:
> > > > > This patch series provides access to various counters on the ThunderX SOC.
> > > > >
> > > > > For details of the uncore implementation see patch #1.
> > > > >
> > > > > Patches #2-5 add the various ThunderX specific PMUs.
> > > > >
> > > > > As suggested I've put the files under drivers/perf/uncore. I would
> > > > > prefer this location over drivers/bus because not all of the uncore
> > > > > drivers are bus related.
> > > >
> > > > What's the status of these patches? Were you planning to send a new
> > > > version?
> > >
> > > I was half-way through with addressing Mark's review comments when
> > > got side-tracked.
> > >
> > > The principle question these patches raised remains open though in my
> > > opinion, how to determine the socket a device belongs to.
> > >
> > > There is no first-class interface to ask a device or the firmware
> > > which socket the device lives on.
> > >
> > > The options I see are:
> > > A) Using NUMA node information, depends on CONFIG_NUMA
> > > B) Decoding the socket bits of the PCI BAR address
> > > C) Using PCI topology information
> > >
> > > A is what I tried, but I agree that depending on CONFIG_NUMA is not a good
> > > solution. B would be easy but looks not very future-proof. So option C
> > > is what is left...
> >
> > Sorry to go full circle on this, but "depends on NUMA" sounds better
> > than deriving NUMA topology from PCI to me. The only worry I have is if
> > the NUMA information ends up being insufficient in the long-term, and we
> > end up with a mixture of the three options above in order to figure out
> > the PMU topology.
> >
> > As long as you're happy that the PMU:NUMA topology remains 1:1, then I
> > have no objections. The moment you need extra hacks on the side, we should
> > probably drop the NUMA dependency altogether and figure it out some other
> > way.
>
> Any news on this series, or did I miss a v3? I was hoping to have this in
> for 4.9, but it seems to have stalled :(
>
> Will
No news, I'm afraid it is stalled on my side :( I'll try to get back to
it, but not for 4.9.
Jan
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Nicolas Ferre @ 2016-09-16 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915150722.13103-1-alexandre.belloni@free-electrons.com>
Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
> atmel_usba_udc fails with:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
> ecm_do_notify+0x188/0x1a0
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
> Hardware name: Atmel SAMA5
> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
> ---[ end trace e7cf9dcebf4815a6 ]---
>
> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Felipe, Greg,
It is clearly a regression and material for 4.8-fixes. But I do know
that we are very late in the process :-(
Please do what you can to make it progress before 4.8-final but I'm
truly aware of the challenge.
Thanks to Richard for finding this and Alexandre for the quick correction.
Bye,
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index bb1f6c8f0f01..45bc997d0711 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1978,7 +1978,7 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
> dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
> goto err;
> }
> - ep->ep.name = name;
> + ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>
> ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
> ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
From: Sylwester Nawrocki @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
The "simple-bus" compatible was originally added for fimc-is only
to ensure the child devices instantiation. The child devices are
now being created by the parent device driver so remove the
"simple-bus" compatible.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index c452499..e8d0678 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -147,7 +147,7 @@
};
fimc_is: fimc-is at 12000000 {
- compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+ compatible = "samsung,exynos4212-fimc-is";
reg = <0x12000000 0x260000>;
interrupts = <0 90 0>, <0 95 0>;
power-domains = <&pd_isp>;
--
1.9.1
^ permalink raw reply related
* [PATCH 9/9] dmaengine: ti-dma-crossbar: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
When compile testing eDMA or omap-dma, select also the ti-dma-crossbar so
it is also covered by the compile testing.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 84647d6cb2f4..1c11628062ad 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -133,7 +133,7 @@ config DMA_OMAP
depends on ARCH_OMAP || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
- select TI_DMA_CROSSBAR if SOC_DRA7XX
+ select TI_DMA_CROSSBAR if (SOC_DRA7XX || COMPILE_TEST)
config DMA_SA11X0
tristate "SA-11x0 DMA support"
@@ -518,7 +518,7 @@ config TI_EDMA
depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
- select TI_DMA_CROSSBAR if ARCH_OMAP
+ select TI_DMA_CROSSBAR if (ARCH_OMAP || COMPILE_TEST)
default n
help
Enable support for the TI EDMA controller. This DMA
--
2.10.0
^ permalink raw reply related
* [PATCH 8/9] dmaengine: ti-dma-crossbar: Use enum for crossbar type
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
Fixes compiler warning on 64bit architectures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index e4f3bd1ae264..876e4ccaf033 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -16,8 +16,10 @@
#include <linux/of_device.h>
#include <linux/of_dma.h>
-#define TI_XBAR_DRA7 0
-#define TI_XBAR_AM335X 1
+enum ti_xbar_type {
+ TI_XBAR_DRA7 = 0,
+ TI_XBAR_AM335X,
+};
static const struct of_device_id ti_dma_xbar_match[] = {
{
@@ -395,7 +397,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.dev = &pdev->dev;
xbar->dmarouter.route_free = ti_dra7_xbar_free;
- xbar->dma_offset = (u32)match->data;
+ xbar->dma_offset = (enum ti_xbar_type)match->data;
mutex_init(&xbar->mutex);
platform_set_drvdata(pdev, xbar);
@@ -428,7 +430,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
if (unlikely(!match))
return -EINVAL;
- switch ((u32)match->data) {
+ switch ((enum ti_xbar_type)match->data) {
case TI_XBAR_DRA7:
ret = ti_dra7_xbar_probe(pdev);
break;
--
2.10.0
^ permalink raw reply related
* [PATCH 7/9] dmaengine: ti-dma-crossbar: Correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5ae294b256a7..e4f3bd1ae264 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -311,7 +311,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
struct property *prop;
struct resource *res;
u32 safe_val;
- size_t sz;
+ int sz;
void __iomem *iomem;
int i, ret;
--
2.10.0
^ permalink raw reply related
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