* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Wei Huang @ 2016-11-10 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa5b2275-374f-4d74-d9d9-0959d90454ca@arm.com>
On 11/10/2016 03:10 AM, Marc Zyngier wrote:
> Hi Wei,
>
> On 09/11/16 19:57, Wei Huang wrote:
>> This patch moves ARMv8-related perf event definitions from perf_event.c
>> to asm/perf_event.h; so KVM code can use them directly. This also help
>> remove a duplicated definition of SW_INCR in perf_event.h.
>>
>> Signed-off-by: Wei Huang <wei@redhat.com>
>> ---
>> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
>> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
>> 2 files changed, 160 insertions(+), 162 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
>> index 2065f46..6c7b18b 100644
>> --- a/arch/arm64/include/asm/perf_event.h
>> +++ b/arch/arm64/include/asm/perf_event.h
>> @@ -46,7 +46,166 @@
>> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
>> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>>
>> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
>> +/*
>> + * ARMv8 PMUv3 Performance Events handling code.
>> + * Common event types.
>> + */
>> +
>> +/* Required events. */
>> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
>> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
>> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
>> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
>
> In my initial review, I asked for the "required" events to be moved to a
> shared location. What's the rational for moving absolutely everything?
I did notice the phrase "required" in the original email. However I
think it is weird to have two places for a same set of PMU definitions.
Other developers might think these two are missing if they don't search
kernel files carefully.
If Will Deacon and you insist, I can move only two defs to perf_event.h,
consolidated with the 2nd patch into a single one.
> KVM only needs to know about ARMV8_PMUV3_PERFCTR_SW_INCR and
> ARMV8_PMUV3_PERFCTR_CPU_CYCLES, so I thought that moving the above six
> events (and maybe the following two) would be enough.
>
> Also, you've now broken the build by dropping
> ARMV8_PMU_EVTYPE_EVENT_SW_INCR without amending it use in the KVM PMU
> code (see the kbuild report).
>
My bad. I tested compilation only after two patches applied. Will fix it.
<snip>
>> +
>> /* PMUv3 HW events mapping. */
>>
>> /*
>>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Corentin Labbe @ 2016-11-10 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025132648.txeo3rw6yz5wutrg@lukather>
On Tue, Oct 25, 2016 at 03:26:48PM +0200, Maxime Ripard wrote:
> On Tue, Oct 25, 2016 at 07:38:55AM +0200, LABBE Corentin wrote:
> > On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> > > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > > Since SID's content is constant over reboot,
> > >
> > > That's not true, at least not across all the Allwinner SoCs, and
> > > especially not on the A10 and A20 that this driver supports.
> > >
> >
> > On my cubieboard2 (A20)
> > hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> > cubiedev ~ # reboot
> > cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> >
> > So clearly for me its constant.
>
> It's constant across reboots, but not across devices. Each device have
> a different SID content, therefore it's a relevant source of entropy
> in the system.
>
Not the 3 leading digit and not the tailing zeros which are the same accross device.
So only 50% of data are really different accross devices.
Perhaps a "random-range" property could be used ?
Herbert, does it is safe to add that 50% duplicate content via add_device_randomness() ?
Reading add_device_randomness doc, it seems finally it is safe, but if you could confirm it.
Regards
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch series aims to convert the s3c64xx platform to use
the new DMA channel request API, i.e. this is only meaningful
for non-dt systems using s3c64xx SoCs.
Presumably the first 2 or 4 patches in this series could be queued
for v4.10-rc1 and the remaining patches could be left for subsequent
release, to avoid non-trivial conflict with patches already applied
in the ASoC tree.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx-v2
Thanks.
Sylwester Nawrocki (8):
dma: pl08x: Add support for the DMA slave map
ARM: s3c64xx: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ARM: s3c64xx: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: s3c64xx: Drop initialization of unused struct s3c_audio_pdata
fields
ARM: s3c24xx: Drop unused struct s3c_audio_pdata entries
arch/arm/mach-s3c64xx/dev-audio.c | 19 --------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 43 -------------------------------
drivers/dma/amba-pl08x.c | 11 ++++++++
drivers/spi/spi-s3c64xx.c | 21 +++------------
include/linux/amba/pl08x.h | 4 +++
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++--------
sound/soc/samsung/pcm.c | 14 ++++------
9 files changed, 58 insertions(+), 103 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/8] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
This patch adds support for the new channel request API introduced
in commit a8135d0d79e9d0ad3a4ff494fceeaae83
"dmaengine: core: Introduce new, universal API to request a channel".
param field of struct dma_slave_map type entries in the platform
data structure should be pointing to struct pl08x_channel_data
of related DMA channel.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/dma/amba-pl08x.c | 11 +++++++++++
include/linux/amba/pl08x.h | 4 ++++
2 files changed, 15 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..0b7c6ce 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1793,6 +1793,13 @@ bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
}
EXPORT_SYMBOL_GPL(pl08x_filter_id);
+static bool pl08x_filter_fn(struct dma_chan *chan, void *chan_id)
+{
+ struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
+
+ return plchan->cd == chan_id;
+}
+
/*
* Just check that the device is there and active
* TODO: turn this bit on/off depending on the number of physical channels
@@ -2307,6 +2314,10 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
+ pl08x->slave.filter.fn = pl08x_filter_fn;
}
/* By default, AHB1 only. If dualmaster, from platform */
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 27e9ec8..5308eae 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -84,6 +84,8 @@ struct pl08x_channel_data {
* running any DMA transfer and multiplexing can be recycled
* @lli_buses: buses which LLIs can be fetched from: PL08X_AHB1 | PL08X_AHB2
* @mem_buses: buses which memory can be accessed from: PL08X_AHB1 | PL08X_AHB2
+ * @slave_map: DMA slave matching table
+ * @slave_map_len: number of elements in @slave_map
*/
struct pl08x_platform_data {
struct pl08x_channel_data *slave_channels;
@@ -93,6 +95,8 @@ struct pl08x_platform_data {
void (*put_xfer_signal)(const struct pl08x_channel_data *, int);
u8 lli_buses;
u8 mem_buses;
+ const struct dma_slave_map *slave_map;
+ int slave_map_len;
};
#ifdef CONFIG_AMBA_PL08X
--
1.9.1
^ permalink raw reply related
* [PATCH 2/8] ARM: s3c64xx: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
This patch adds DMA slave map tables to the pl080 devices's
platform_data in order to support the new channel request API.
A few devices for which there was no DMA support with current
code are omitted in the tables.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
index 89c5a62..261820a 100644
--- a/arch/arm/mach-s3c64xx/pl080.c
+++ b/arch/arm/mach-s3c64xx/pl080.c
@@ -117,6 +117,25 @@ static void pl08x_put_xfer_signal(const struct pl08x_channel_data *cd, int ch)
}
};
+static const struct dma_slave_map s3c64xx_dma0_slave_map[] = {
+ { "s3c6400-uart.0", "tx", &s3c64xx_dma0_info[0] },
+ { "s3c6400-uart.0", "rx", &s3c64xx_dma0_info[1] },
+ { "s3c6400-uart.1", "tx", &s3c64xx_dma0_info[2] },
+ { "s3c6400-uart.1", "rx", &s3c64xx_dma0_info[3] },
+ { "s3c6400-uart.2", "tx", &s3c64xx_dma0_info[4] },
+ { "s3c6400-uart.2", "rx", &s3c64xx_dma0_info[5] },
+ { "s3c6400-uart.3", "tx", &s3c64xx_dma0_info[6] },
+ { "s3c6400-uart.3", "rx", &s3c64xx_dma0_info[7] },
+ { "samsung-pcm.0", "tx", &s3c64xx_dma0_info[8] },
+ { "samsung-pcm.0", "rx", &s3c64xx_dma0_info[9] },
+ { "samsung-i2s.0", "tx", &s3c64xx_dma0_info[10] },
+ { "samsung-i2s.0", "rx", &s3c64xx_dma0_info[11] },
+ { "s3c6410-spi.0", "tx", &s3c64xx_dma0_info[12] },
+ { "s3c6410-spi.0", "rx", &s3c64xx_dma0_info[13] },
+ { "samsung-i2s.2", "tx", &s3c64xx_dma0_info[14] },
+ { "samsung-i2s.2", "rx", &s3c64xx_dma0_info[15] },
+};
+
struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma0_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
+ .slave_map = s3c64xx_dma0_slave_map,
+ .slave_map_len = ARRAY_SIZE(s3c64xx_dma0_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
@@ -207,6 +228,15 @@ static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
},
};
+static const struct dma_slave_map s3c64xx_dma1_slave_map[] = {
+ { "samsung-pcm.1", "tx", &s3c64xx_dma1_info[0] },
+ { "samsung-pcm.1", "rx", &s3c64xx_dma1_info[1] },
+ { "samsung-i2s.1", "tx", &s3c64xx_dma1_info[2] },
+ { "samsung-i2s.1", "rx", &s3c64xx_dma1_info[3] },
+ { "s3c6410-spi.1", "tx", &s3c64xx_dma1_info[4] },
+ { "s3c6410-spi.1", "rx", &s3c64xx_dma1_info[5] },
+};
+
struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -224,6 +254,8 @@ struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma1_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma1_info),
+ .slave_map = s3c64xx_dma1_slave_map,
+ .slave_map_len = ARRAY_SIZE(s3c64xx_dma1_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma1, "dma-pl080s.1", 0,
--
1.9.1
^ permalink raw reply related
* [PATCH 3/8] spi: s3c64xx: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to DMA slaves so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Andi Shyti <andi.shyti@samsung.com>
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-s3c64xx.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 3c09e94..28dfdce 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -341,27 +341,20 @@ static void s3c64xx_spi_set_cs(struct spi_device *spi, bool enable)
static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
{
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
- dma_filter_fn filter = sdd->cntrlr_info->filter;
struct device *dev = &sdd->pdev->dev;
- dma_cap_mask_t mask;
if (is_polling(sdd))
return 0;
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
/* Acquire DMA channels */
- sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_rx, dev, "rx");
+ sdd->rx_dma.ch = dma_request_slave_channel(dev, "rx");
if (!sdd->rx_dma.ch) {
dev_err(dev, "Failed to get RX DMA channel\n");
return -EBUSY;
}
spi->dma_rx = sdd->rx_dma.ch;
- sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_tx, dev, "tx");
+ sdd->tx_dma.ch = dma_request_slave_channel(dev, "tx");
if (!sdd->tx_dma.ch) {
dev_err(dev, "Failed to get TX DMA channel\n");
dma_release_channel(sdd->rx_dma.ch);
@@ -1091,11 +1084,6 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
sdd->cur_bpw = 8;
- if (!sdd->pdev->dev.of_node && (!sci->dma_tx || !sci->dma_rx)) {
- dev_warn(&pdev->dev, "Unable to get SPI tx/rx DMA data. Switching to poll mode\n");
- sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
- }
-
sdd->tx_dma.direction = DMA_MEM_TO_DEV;
sdd->rx_dma.direction = DMA_DEV_TO_MEM;
@@ -1205,9 +1193,8 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d with %d Slaves attached\n",
sdd->port_id, master->num_chipselect);
- dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\tDMA=[Rx-%p, Tx-%p]\n",
- mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1,
- sci->dma_rx, sci->dma_tx);
+ dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\n",
+ mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1);
pm_runtime_mark_last_busy(&pdev->dev);
pm_runtime_put_autosuspend(&pdev->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH 4/8] ARM: s3c64xx: Drop unused DMA fields from struct s3c64xx_spi_csinfo
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
There is no drivers using those fields so remove them and
the remaining initializations.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
arch/arm/plat-samsung/devs.c | 24 ------------------------
include/linux/platform_data/spi-s3c64xx.h | 3 ---
2 files changed, 27 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e93aa67..cf7b95f 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1124,15 +1124,6 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI0_TX;
- pd.dma_rx = (void *)DMACH_SPI0_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#elif defined(CONFIG_S3C24XX_DMAC)
- pd.filter = s3c24xx_dma_filter;
-#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
}
@@ -1169,14 +1160,6 @@ void __init s3c64xx_spi1_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI1_TX;
- pd.dma_rx = (void *)DMACH_SPI1_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#endif
-
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
}
@@ -1213,13 +1196,6 @@ void __init s3c64xx_spi2_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI2_TX;
- pd.dma_rx = (void *)DMACH_SPI2_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
}
diff --git a/include/linux/platform_data/spi-s3c64xx.h b/include/linux/platform_data/spi-s3c64xx.h
index 5c1e21c..da79774 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -40,9 +40,6 @@ struct s3c64xx_spi_info {
int num_cs;
bool no_cs;
int (*cfg_gpio)(void);
- dma_filter_fn filter;
- void *dma_tx;
- void *dma_rx;
};
/**
--
1.9.1
^ permalink raw reply related
* [PATCH 5/8] ASoC: samsung: i2s: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/i2s.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 7e32cf4..95a9a3f 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -90,7 +90,6 @@ struct i2s_dai {
struct snd_dmaengine_dai_dma_data dma_playback;
struct snd_dmaengine_dai_dma_data dma_capture;
struct snd_dmaengine_dai_dma_data idma_playback;
- dma_filter_fn filter;
u32 quirks;
u32 suspend_i2smod;
u32 suspend_i2scon;
@@ -1244,7 +1243,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return ret;
return samsung_asoc_dma_platform_register(&pdev->dev,
- sec_dai->filter, "tx-sec", NULL);
+ NULL, "tx-sec", NULL);
}
pri_dai = i2s_alloc_dai(pdev, false);
@@ -1262,10 +1261,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return -EINVAL;
}
- pri_dai->dma_playback.filter_data = i2s_pdata->dma_playback;
- pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
- pri_dai->filter = i2s_pdata->dma_filter;
-
if (&i2s_pdata->type)
i2s_cfg = &i2s_pdata->type.i2s;
@@ -1327,11 +1322,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai->dma_playback.addr = regs_base + I2STXDS;
sec_dai->dma_playback.chan_name = "tx-sec";
- if (!np) {
- sec_dai->dma_playback.filter_data = i2s_pdata->dma_play_sec;
- sec_dai->filter = i2s_pdata->dma_filter;
- }
-
sec_dai->dma_playback.addr_width = 4;
sec_dai->addr = pri_dai->addr;
sec_dai->clk = pri_dai->clk;
@@ -1353,7 +1343,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
if (ret < 0)
goto err_free_dai;
- ret = samsung_asoc_dma_platform_register(&pdev->dev, pri_dai->filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret < 0)
goto err_free_dai;
--
1.9.1
^ permalink raw reply related
* [PATCH 6/8] ASoC: samsung: pcm: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/pcm.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c
index 43e367a..ccedab2 100644
--- a/sound/soc/samsung/pcm.c
+++ b/sound/soc/samsung/pcm.c
@@ -134,18 +134,22 @@ struct s3c_pcm_info {
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_out[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "tx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "tx",
},
};
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_in[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "rx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "rx",
},
};
@@ -488,7 +492,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
struct s3c_pcm_info *pcm;
struct resource *mem_res;
struct s3c_audio_pdata *pcm_pdata;
- dma_filter_fn filter;
int ret;
/* Check for valid device index */
@@ -555,13 +558,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
s3c_pcm_stereo_in[pdev->id].addr = mem_res->start + S3C_PCM_RXFIFO;
s3c_pcm_stereo_out[pdev->id].addr = mem_res->start + S3C_PCM_TXFIFO;
- filter = NULL;
- if (pcm_pdata) {
- s3c_pcm_stereo_in[pdev->id].filter_data = pcm_pdata->dma_capture;
- s3c_pcm_stereo_out[pdev->id].filter_data = pcm_pdata->dma_playback;
- filter = pcm_pdata->dma_filter;
- }
-
pcm->dma_capture = &s3c_pcm_stereo_in[pdev->id];
pcm->dma_playback = &s3c_pcm_stereo_out[pdev->id];
@@ -574,7 +570,7 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
goto err5;
}
- ret = samsung_asoc_dma_platform_register(&pdev->dev, filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret) {
dev_err(&pdev->dev, "failed to get register DMA: %d\n", ret);
--
1.9.1
^ permalink raw reply related
* [PATCH 7/8] ARM: s3c64xx: Drop initialization of unused struct s3c_audio_pdata fields
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
Remove initialization of dma_{filter, playback, capture, capture_mic}
fields where it is not used any more.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/dev-audio.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b577833..a3f39dd 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -58,9 +58,6 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S0_OUT,
- .dma_capture = DMACH_I2S0_IN,
};
struct platform_device s3c64xx_device_iis0 = {
@@ -80,9 +77,6 @@ struct platform_device s3c64xx_device_iis0 = {
static struct s3c_audio_pdata i2s1_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S1_OUT,
- .dma_capture = DMACH_I2S1_IN,
};
struct platform_device s3c64xx_device_iis1 = {
@@ -102,9 +96,6 @@ struct platform_device s3c64xx_device_iis1 = {
static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_HSI_I2SV40_TX,
- .dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
.i2s = {
.quirks = QUIRK_PRI_6CHAN,
@@ -153,9 +144,6 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_PCM0_RX,
- .dma_playback = DMACH_PCM0_TX,
};
struct platform_device s3c64xx_device_pcm0 = {
@@ -175,9 +163,6 @@ struct platform_device s3c64xx_device_pcm0 = {
static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_PCM1_TX,
- .dma_capture = DMACH_PCM1_RX,
};
struct platform_device s3c64xx_device_pcm1 = {
@@ -209,10 +194,6 @@ static int s3c64xx_ac97_cfg_gpe(struct platform_device *pdev)
};
static struct s3c_audio_pdata s3c_ac97_pdata = {
- .dma_playback = DMACH_AC97_PCMOUT,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_AC97_PCMIN,
- .dma_capture_mic = DMACH_AC97_MICIN,
};
static u64 s3c64xx_ac97_dmamask = DMA_BIT_MASK(32);
--
1.9.1
^ permalink raw reply related
* [PATCH 8/8] ARM: s3c24xx: Drop unused struct s3c_audio_pdata entries
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
The s3c24xx-iis driver is now converted to use the dma_slave_map API
and the samsung-ac97 driver got removed from the tree so remove
the unused platform data structure instances.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/plat-samsung/devs.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index cf7b95f..03fac12 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -77,15 +77,6 @@
[1] = DEFINE_RES_IRQ(IRQ_S3C244X_AC97),
};
-static struct s3c_audio_pdata s3c_ac97_pdata = {
-#ifdef CONFIG_S3C24XX_DMAC
- .dma_filter = s3c24xx_dma_filter,
-#endif
- .dma_playback = (void *)DMACH_PCM_OUT,
- .dma_capture = (void *)DMACH_PCM_IN,
- .dma_capture_mic = (void *)DMACH_MIC_IN,
-};
-
struct platform_device s3c_device_ac97 = {
.name = "samsung-ac97",
.id = -1,
@@ -94,7 +85,6 @@ struct platform_device s3c_device_ac97 = {
.dev = {
.dma_mask = &samsung_device_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &s3c_ac97_pdata,
}
};
#endif /* CONFIG_CPU_S3C2440 */
@@ -574,14 +564,6 @@ void __init s3c_i2c7_set_platdata(struct s3c2410_platform_i2c *pd)
[0] = DEFINE_RES_MEM(S3C24XX_PA_IIS, S3C24XX_SZ_IIS),
};
-static struct s3c_audio_pdata s3c_iis_platdata = {
-#ifdef CONFIG_S3C24XX_DMAC
- .dma_filter = s3c24xx_dma_filter,
-#endif
- .dma_playback = (void *)DMACH_I2S_OUT,
- .dma_capture = (void *)DMACH_I2S_IN,
-};
-
struct platform_device s3c_device_iis = {
.name = "s3c24xx-iis",
.id = -1,
@@ -590,7 +572,6 @@ struct platform_device s3c_device_iis = {
.dev = {
.dma_mask = &samsung_device_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &s3c_iis_platdata,
}
};
#endif /* CONFIG_PLAT_S3C24XX */
--
1.9.1
^ permalink raw reply related
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Charles Keepax @ 2016-11-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b654d5f7-7b67-7216-760f-d29e49a29296@samsung.com>
On Thu, Nov 10, 2016 at 04:10:56PM +0100, Sylwester Nawrocki wrote:
> On 11/10/2016 12:03 PM, Charles Keepax wrote:
> >> On Tue, Nov 08, 2016 at 04:53:40PM +0100, Sylwester Nawrocki wrote:
> [...]
> >> I pushed now to branch for-v4.10/dma/pl080-s3c64xx-v2 with this
> >> issue fixed and added initialization of the filer function.
> >
> > Apologies for the delay got somewhat swamped with internal stuff
> > yesterday. Yeah using that branch it looks good to me, the SPI and
> > I2S are both working fine. I can download code to the wm0010
> > which should be a good work out of the SPI and play audio
> > correctly so the I2S should be fine. So for the series:
> >
> > Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>
> Great, thanks a lot! I'm going to post the next iteration with
> modified pl080 DMAC patches, addressing comments from Arnd.
> I would be grateful if you could confirm it also works on your
> platform.
>
Yeah, no problem, I should be able to find time to test those as
well.
Thanks,
Charles
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Joerg Roedel @ 2016-11-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e59e9a17-e943-a227-5ea4-d028232155a8@arm.com>
On Wed, Nov 09, 2016 at 08:11:16PM +0000, Robin Murphy wrote:
> When we *are* in full control of the IOVA space, we just carve out what
> we can find as best we can - see iova_reserve_pci_windows() in
> dma-iommu.c, which isn't really all that different to what x86 does
> (e.g. init_reserved_iova_ranges() in amd-iommu.c).
Yeah, that code was actually written with a look at what the Intel
driver does. I don't really like that it goes over all resources and
reserves them individually (not only because it is not hotplug-safe).
I have to check whether there is a nice and generic way to find out the
root-bridge windows and just reserve them in the iova-space. That would
be easier and more reliable.
Joerg
^ permalink raw reply
* [PATCH -next] cpufreq: brcmstb-avs-cpufreq: make symbol brcm_avs_cpufreq_attr static
From: Wei Yongjun @ 2016-11-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/cpufreq/brcmstb-avs-cpufreq.c:982:18: warning:
symbol 'brcm_avs_cpufreq_attr' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/cpufreq/brcmstb-avs-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index b761d54..4fda623 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -979,7 +979,7 @@ cpufreq_freq_attr_ro(brcm_avs_pmap);
cpufreq_freq_attr_ro(brcm_avs_voltage);
cpufreq_freq_attr_ro(brcm_avs_frequency);
-struct freq_attr *brcm_avs_cpufreq_attr[] = {
+static struct freq_attr *brcm_avs_cpufreq_attr[] = {
&cpufreq_freq_attr_scaling_available_freqs,
&brcm_avs_pstate,
&brcm_avs_mode,
^ permalink raw reply related
* [PATCH fpga 9/9] fpga: Remove support for non-sg drivers
From: Joshua Clayton @ 2016-11-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478732303-13718-10-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
On 11/09/2016 02:58 PM, Jason Gunthorpe wrote:
> All drivers now use the sg interface so there is no reason to keep
> the contiguous interface any more.
>
> Now that all drivers support this interface we can also export it.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/fpga-mgr.c | 62 +++++++------------------------------------
> include/linux/fpga/fpga-mgr.h | 7 ++---
> 2 files changed, 11 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index c2491ffeabd3..4ba22925d9d5 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -47,8 +47,8 @@ static struct class *fpga_mgr_class;
> *
> * Return: 0 on success, negative error code otherwise.
> */
> -static int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> - struct sg_table *sgt)
> +int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> + struct sg_table *sgt)
> {
> struct device *dev = &mgr->dev;
> int ret;
> @@ -92,52 +92,7 @@ static int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
>
> return 0;
> }
> -
> -static int fpga_mgr_buf_load_mapped(struct fpga_manager *mgr, u32 flags,
> - const char *buf, size_t count)
> -{
> - struct device *dev = &mgr->dev;
> - int ret;
> -
> - /*
> - * Call the low level driver's write_init function. This will do the
> - * device-specific things to get the FPGA into the state where it is
> - * ready to receive an FPGA image.
> - */
> - mgr->state = FPGA_MGR_STATE_WRITE_INIT;
> - ret = mgr->mops->write_init(mgr, flags, buf, count);
> - if (ret) {
> - dev_err(dev, "Error preparing FPGA for writing\n");
> - mgr->state = FPGA_MGR_STATE_WRITE_INIT_ERR;
> - return ret;
> - }
> -
> - /*
> - * Write the FPGA image to the FPGA.
> - */
> - mgr->state = FPGA_MGR_STATE_WRITE;
> - ret = mgr->mops->write(mgr, buf, count);
> - if (ret) {
> - dev_err(dev, "Error while writing image data to FPGA\n");
> - mgr->state = FPGA_MGR_STATE_WRITE_ERR;
> - return ret;
> - }
> -
> - /*
> - * After all the FPGA image has been written, do the device specific
> - * steps to finish and set the FPGA into operating mode.
> - */
> - mgr->state = FPGA_MGR_STATE_WRITE_COMPLETE;
> - ret = mgr->mops->write_complete(mgr, flags);
> - if (ret) {
> - dev_err(dev, "Error after writing image data to FPGA\n");
> - mgr->state = FPGA_MGR_STATE_WRITE_COMPLETE_ERR;
> - return ret;
> - }
> - mgr->state = FPGA_MGR_STATE_OPERATING;
> -
> - return 0;
> -}
> +EXPORT_SYMBOL_GPL(fpga_mgr_buf_load_sg);
>
> /**
> * fpga_mgr_buf_load - load fpga from image in buffer
> @@ -163,9 +118,6 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> int index;
> int rc;
>
> - if (!mgr->mops->write_init_sg || !mgr->mops->write_sg)
> - return fpga_mgr_buf_load_mapped(mgr, flags, buf, count);
> -
> /*
> * Convert the linear kernel pointer into a sg_table of pages for use
> * by the driver.
> @@ -226,6 +178,11 @@ int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
>
> mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ;
>
> + /*
> + * FIXME: We do not need a vmap, just a page list, but
> + * request_firmware has no way to give us that, so this needlessly
> + * consumes vmalloc space.
> + */
> ret = request_firmware(&fw, image_name, dev);
> if (ret) {
> mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ_ERR;
> @@ -369,8 +326,7 @@ int fpga_mgr_register(struct device *dev, const char *name,
> int id, ret;
>
> if (!mops || !mops->write_complete || !mops->state ||
> - ((!mops->write_init || !mops->write) &&
> - (!mops->write_init_sg || !mops->write_sg))) {
> + !mops->write_init_sg || !mops->write_sg) {
> dev_err(dev, "Attempt to register without fpga_manager_ops\n");
> return -EINVAL;
> }
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index 371b30ea60eb..5c698c8fe71b 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -72,8 +72,6 @@ enum fpga_mgr_states {
> /**
> * struct fpga_manager_ops - ops for low level fpga manager drivers
> * @state: returns an enum value of the FPGA's state
> - * @write_init: prepare the FPGA to receive confuration data (linear memory)
> - * @write: write count bytes of configuration data to the FPGA
> * @write_init_sg: prepare the FPGA to receive confuration data (scatter list
> * table)
> * @write_sg: write count bytes of configuration data to the FPGA
> @@ -86,9 +84,6 @@ enum fpga_mgr_states {
> */
> struct fpga_manager_ops {
> enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
> - int (*write_init)(struct fpga_manager *mgr, u32 flags,
> - const char *buf, size_t count);
> - int (*write)(struct fpga_manager *mgr, const char *buf, size_t count);
> int (*write_init_sg)(struct fpga_manager *mgr, u32 flags,
> struct sg_table *sgt);
> int (*write_sg)(struct fpga_manager *mgr, struct sg_table *sgt);
> @@ -118,6 +113,8 @@ struct fpga_manager {
>
> int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags,
> const char *buf, size_t count);
> +int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> + struct sg_table *sgt);
>
> int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
> const char *image_name);
I don't have any feeling either way about switching to scatter-gather.
(Not zynq or socfpga user)
But I do object to renaming the API.
write_init() and write() do not imply a particular implementation, nor even that
the buffer is coherent.
I am working to merge an fpga manager which uses SPI to load the bitstream
(see https://www.spinics.net/lists/arm-kernel/msg539328.html)
Any dma in use there would come from the spi driver. write_init_sg, and write_sg
don't make any sense in my case.
Would it not make sense to keep the top level API the same?
Thanks, Joshua.
^ permalink raw reply
* [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range
From: Joerg Roedel @ 2016-11-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-3-git-send-email-eric.auger@redhat.com>
On Fri, Nov 04, 2016 at 11:24:00AM +0000, Eric Auger wrote:
> Fix the size check within start_pfn and limit_pfn.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> the issue was observed when playing with 1 page iova domain with
> higher iova reserved.
> ---
> drivers/iommu/iova.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index e23001b..ee29dbf 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -147,7 +147,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> if (!curr) {
> if (size_aligned)
> pad_size = iova_get_pad_size(size, limit_pfn);
> - if ((iovad->start_pfn + size + pad_size) > limit_pfn) {
> + if ((iovad->start_pfn + size + pad_size - 1) > limit_pfn) {
A >= check is more readable here.
Joerg
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Mark Rutland @ 2016-11-10 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9ef10b9-44f2-b02e-9d90-02cf348aa49c@redhat.com>
On Thu, Nov 10, 2016 at 09:12:35AM -0600, Wei Huang wrote:
> On 11/10/2016 03:10 AM, Marc Zyngier wrote:
> > On 09/11/16 19:57, Wei Huang wrote:
> >> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> >> +/*
> >> + * ARMv8 PMUv3 Performance Events handling code.
> >> + * Common event types.
> >> + */
> >> +
> >> +/* Required events. */
> >> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> >> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> >> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> >> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> >> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> >> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
> >
> > In my initial review, I asked for the "required" events to be moved to a
> > shared location. What's the rational for moving absolutely everything?
>
> I did notice the phrase "required" in the original email. However I
> think it is weird to have two places for a same set of PMU definitions.
> Other developers might think these two are missing if they don't search
> kernel files carefully.
>
> If Will Deacon and you insist, I can move only two defs to perf_event.h,
> consolidated with the 2nd patch into a single one.
FWIW, my personal preference would be for all the definitions (or at
least all of the ARMV8_PMUV3_* ones) to be in one place.
That said, I don't feel particularly strongly either way, and I'll defer
to Will.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Marc Zyngier @ 2016-11-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9ef10b9-44f2-b02e-9d90-02cf348aa49c@redhat.com>
On 10/11/16 15:12, Wei Huang wrote:
>
>
> On 11/10/2016 03:10 AM, Marc Zyngier wrote:
>> Hi Wei,
>>
>> On 09/11/16 19:57, Wei Huang wrote:
>>> This patch moves ARMv8-related perf event definitions from perf_event.c
>>> to asm/perf_event.h; so KVM code can use them directly. This also help
>>> remove a duplicated definition of SW_INCR in perf_event.h.
>>>
>>> Signed-off-by: Wei Huang <wei@redhat.com>
>>> ---
>>> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
>>> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
>>> 2 files changed, 160 insertions(+), 162 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
>>> index 2065f46..6c7b18b 100644
>>> --- a/arch/arm64/include/asm/perf_event.h
>>> +++ b/arch/arm64/include/asm/perf_event.h
>>> @@ -46,7 +46,166 @@
>>> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
>>> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>>>
>>> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
>>> +/*
>>> + * ARMv8 PMUv3 Performance Events handling code.
>>> + * Common event types.
>>> + */
>>> +
>>> +/* Required events. */
>>> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
>>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
>>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
>>> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
>>> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
>>> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
>>
>> In my initial review, I asked for the "required" events to be moved to a
>> shared location. What's the rational for moving absolutely everything?
>
> I did notice the phrase "required" in the original email. However I
> think it is weird to have two places for a same set of PMU definitions.
> Other developers might think these two are missing if they don't search
> kernel files carefully.
>
> If Will Deacon and you insist, I can move only two defs to perf_event.h,
> consolidated with the 2nd patch into a single one.
My personal feeling is that only architected events should be in a
public header. The CPU-specific ones are probably better kept private,
as it is doubtful that other users would appear).
I'll leave it up to Will to decide, as all I want to avoid is the
duplication of constants between the PMU and KVM code bases.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] spi: atmel: Fix scheduling while atomic
From: ben.whitten at gmail.com @ 2016-11-10 15:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Ben Whitten <ben.whitten@lairdtech.com>
A call to clk_get_rate appears to be called in the context of an interrupt,
cache the bus clock for the frequency calculations in transmission.
This fixes a 'BUG: scheduling while atomic' and
'WARNING: CPU: 0 PID: 777 at kernel/sched/core.c:2960 atmel_spi_unlock'
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
Signed-off-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/spi/spi-atmel.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8feac59..c281d1a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -295,6 +295,7 @@ struct atmel_spi {
int irq;
struct clk *clk;
struct platform_device *pdev;
+ unsigned long spi_clk;
struct spi_transfer *current_transfer;
int current_remaining_bytes;
@@ -864,7 +865,7 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
unsigned long bus_hz;
/* v1 chips start out at half the peripheral bus speed. */
- bus_hz = clk_get_rate(as->clk);
+ bus_hz = as->spi_clk;
if (!atmel_spi_is_v2(as))
bus_hz /= 2;
@@ -1606,6 +1607,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
ret = clk_prepare_enable(clk);
if (ret)
goto out_free_irq;
+
+ as->spi_clk = clk_get_rate(clk);
+
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
if (as->caps.has_wdrbt) {
--
2.7.4
^ permalink raw reply related
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-10 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17821285.aIcTyCGn5n@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 10 November 2016 09:12
> To: linux-arm-kernel at lists.infradead.org
> Cc: Yuanzhichang; mark.rutland at arm.com; devicetree at vger.kernel.org;
> lorenzo.pieralisi at arm.com; Gabriele Paoloni; minyard at acm.org; linux-
> pci at vger.kernel.org; benh at kernel.crashing.org; John Garry;
> will.deacon at arm.com; linux-kernel at vger.kernel.org; xuwei (O); Linuxarm;
> zourongrong at gmail.com; robh+dt at kernel.org; kantyzc at 163.com; linux-
> serial at vger.kernel.org; catalin.marinas at arm.com; olof at lixom.net;
> liviu.dudau at arm.com; bhelgaas at google.com; zhichang.yuan02 at gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
> > On 2016/11/10 5:34, Arnd Bergmann wrote:
> > > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni
> wrote:
> > >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > >>>> + /*
> > >>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
> > >>> indirectIO.
> > >>>> + * It will separate indirectIO range from pci host
> bridge to
> > >>>> + * avoid the possible PIO conflict.
> > >>>> + * Set the indirectIO range directly here.
> > >>>> + */
> > >>>> + lpcdev->io_ops.start = 0;
> > >>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > >>>> + lpcdev->io_ops.devpara = lpcdev;
> > >>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > >>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > >>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > >>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >>>
> > >>> I have to look at patch 2 in more detail again, after missing a
> few
> > >>> review
> > >>> rounds. I'm still a bit skeptical about hardcoding a logical I/O
> port
> > >>> range here, and would hope that we can just go through the same
> > >>> assignment of logical port ranges that we have for PCI buses,
> > >>> decoupling
> > >>> the bus addresses from the linux-internal ones.
> > >>
> > >> The point here is that we want to avoid any conflict/overlap
> between
> > >> the LPC I/O space and the PCI I/O space. With the assignment above
> > >> we make sure that LPC never interfere with PCI I/O space.
> > >
> > > But we already abstract the PCI I/O space using dynamic
> registration.
> > > There is no need to hardcode the logical address for ISA, though
> > > I think we can hardcode the bus address to start at zero here.
> >
> > Do you means that we can pick up the maximal I/O address from all
> children's
> > device resources??
>
> The driver should not look at the resources of its children, just
> register a range of addresses dynamically, as I suggested in an
> earlier review.
Where should we get the range from? For LPC we know that it is going
Work on anything that is not used by PCI I/O space, and this is
why we use [0, PCIBIOS_MIN_IO]
>
>
> Your current version has
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr, value, sizeof(type)); \
>
> Instead, just subtract the start of the range from the logical
> port number to transform it back into a bus-local port number:
These accessors do not operate on IO tokens:
If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
addr is not going to be an I/O token; in fact patch 2/3 imposes that
the I/O tokens will start@PCIBIOS_MIN_IO. So from 0 to PCIBIOS_MIN_IO
we have free physical addresses that the accessors can operate on.
Thanks
Gab
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr - arm64_extio_ops->start, value,
> sizeof(type)); \
>
> We know that the ISA/LPC bus can only have up to 65536 ports,
> so you can register all of those, or possibly limit it further to
> 1024 or 4096 ports, whichever matches the bus implementation.
>
> Arnd
^ permalink raw reply
* [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain
From: Joerg Roedel @ 2016-11-10 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-5-git-send-email-eric.auger@redhat.com>
On Fri, Nov 04, 2016 at 11:24:02AM +0000, Eric Auger wrote:
> Introduce a new iommu_reserved_region struct. This embodies
> an IOVA reserved region that cannot be used along with the IOMMU
> API. The list is protected by a dedicated mutex.
>
> An iommu domain now owns a list of those.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
> ---
> drivers/iommu/iommu.c | 2 ++
> include/linux/iommu.h | 17 +++++++++++++++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..0af07492 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1061,6 +1061,8 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>
> domain->ops = bus->iommu_ops;
> domain->type = type;
> + INIT_LIST_HEAD(&domain->reserved_regions);
> + mutex_init(&domain->resv_mutex);
These regions are a property of the iommu-group, they are specific to a
device or a group of devices, not to a particular domain where devics
(iommu-groups) can come and go.
Further I agree with Robin that this is similar to the
get_dm_regions/set_dm_regions approach, which should be changed/extended
for this instead of adding something new.
Joerg
^ permalink raw reply
* [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range
From: Auger Eric @ 2016-11-10 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110152241.GF2078@8bytes.org>
Hi Joerg,
On 10/11/2016 16:22, Joerg Roedel wrote:
> On Fri, Nov 04, 2016 at 11:24:00AM +0000, Eric Auger wrote:
>> Fix the size check within start_pfn and limit_pfn.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> the issue was observed when playing with 1 page iova domain with
>> higher iova reserved.
>> ---
>> drivers/iommu/iova.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index e23001b..ee29dbf 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -147,7 +147,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
>> if (!curr) {
>> if (size_aligned)
>> pad_size = iova_get_pad_size(size, limit_pfn);
>> - if ((iovad->start_pfn + size + pad_size) > limit_pfn) {
>> + if ((iovad->start_pfn + size + pad_size - 1) > limit_pfn) {
>
> A >= check is more readable here.
Sure
Thanks
Eric
>
>
> Joerg
>
>
> _______________________________________________
> 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 v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain
From: Auger Eric @ 2016-11-10 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110153724.GG2078@8bytes.org>
Hi Joerg, Robin,
On 10/11/2016 16:37, Joerg Roedel wrote:
> On Fri, Nov 04, 2016 at 11:24:02AM +0000, Eric Auger wrote:
>> Introduce a new iommu_reserved_region struct. This embodies
>> an IOVA reserved region that cannot be used along with the IOMMU
>> API. The list is protected by a dedicated mutex.
>>
>> An iommu domain now owns a list of those.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> ---
>> drivers/iommu/iommu.c | 2 ++
>> include/linux/iommu.h | 17 +++++++++++++++++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 9a2f196..0af07492 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1061,6 +1061,8 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>>
>> domain->ops = bus->iommu_ops;
>> domain->type = type;
>> + INIT_LIST_HEAD(&domain->reserved_regions);
>> + mutex_init(&domain->resv_mutex);
>
> These regions are a property of the iommu-group, they are specific to a
> device or a group of devices, not to a particular domain where devics
> (iommu-groups) can come and go.
>
> Further I agree with Robin that this is similar to the
> get_dm_regions/set_dm_regions approach, which should be changed/extended
> for this instead of adding something new.
OK I am currently respinning, taking this into account. I will put the
reserved region file attribute in the iommu-group sysfs dir.
Thanks
Eric
>
>
> Joerg
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger@redhat.com>
On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
> drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>
> #define FSYNR0_WNR (1 << 4)
>
> +#define MSI_IOVA_BASE 0x8000000
> +#define MSI_IOVA_LENGTH 0x100000
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
>
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> + struct pci_dev *dev)
> +{
> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> + struct iommu_reserved_region *region;
> + struct resource_entry *window;
> + phys_addr_t start;
> + size_t length;
> +
> + resource_list_for_each_entry(window, &bridge->windows) {
> + if (resource_type(window->res) != IORESOURCE_MEM &&
> + resource_type(window->res) != IORESOURCE_IO)
> + continue;
Why do you care about IO resources?
> +
> + start = window->res->start - window->offset;
> + length = window->res->end - window->res->start + 1;
> +
> + iommu_reserved_region_for_each(region, domain) {
> + if (region->start == start && region->length == length)
> + continue;
> + }
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = start;
> + region->length = length;
> +
> + list_add_tail(®ion->list, &domain->reserved_regions);
> + }
> + return 0;
> +}
> +
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> + struct device *device)
> +{
> + struct iommu_reserved_region *region;
> + int ret = 0;
> +
> + /* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> + if (!domain->iova_cookie) {
> +
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = MSI_IOVA_BASE;
> + region->length = MSI_IOVA_LENGTH;
> + list_add_tail(®ion->list, &domain->reserved_regions);
> +
> + ret = iommu_get_dma_msi_region_cookie(domain,
> + region->start, region->length);
> + if (ret)
> + return ret;
Gah, I hate this. Is there no other and simpler way to get the MSI
region than allocating an iova-domain? In that regard, I also _hate_ the
patch before introducing this weird iommu_get_dma_msi_region_cookie()
function.
Allocation an iova-domain is pretty expensive, as it also includes
per-cpu data-structures and all, so please don't do this just for the
purpose of compiling a list of reserved regions.
Joerg
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-10 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110154606.GH2078@8bytes.org>
Hi Joerg,
On 10/11/2016 16:46, Joerg Roedel wrote:
> On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
>> The function populates the list of reserved regions with the
>> PCI host bridge windows and the MSI IOVA range.
>>
>> At the moment an arbitray MSI IOVA window is set at 0x8000000
>> of size 1MB.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> RFC v1 -> v2: use defines for MSI IOVA base and length
>> ---
>> drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 66 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index c841eb7..c07ea41 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>>
>> #define FSYNR0_WNR (1 << 4)
>>
>> +#define MSI_IOVA_BASE 0x8000000
>> +#define MSI_IOVA_LENGTH 0x100000
>> +
>> static int force_stage;
>> module_param(force_stage, int, S_IRUGO);
>> MODULE_PARM_DESC(force_stage,
>> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>> return iommu_fwspec_add_ids(dev, &fwid, 1);
>> }
>>
>> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
>> + struct pci_dev *dev)
>> +{
>> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
>> + struct iommu_reserved_region *region;
>> + struct resource_entry *window;
>> + phys_addr_t start;
>> + size_t length;
>> +
>> + resource_list_for_each_entry(window, &bridge->windows) {
>> + if (resource_type(window->res) != IORESOURCE_MEM &&
>> + resource_type(window->res) != IORESOURCE_IO)
>> + continue;
>
> Why do you care about IO resources?
Effectively that's a draft implementation inspired from "iommu/dma:
Avoid PCI host bridge windows". Also not all PCI host bridge windows
induce issues; my understanding is only those not supporting ACS are a
problem.
>
>> +
>> + start = window->res->start - window->offset;
>> + length = window->res->end - window->res->start + 1;
>> +
>> + iommu_reserved_region_for_each(region, domain) {
>> + if (region->start == start && region->length == length)
>> + continue;
>> + }
>> + region = kzalloc(sizeof(*region), GFP_KERNEL);
>> + if (!region)
>> + return -ENOMEM;
>> +
>> + region->start = start;
>> + region->length = length;
>> +
>> + list_add_tail(®ion->list, &domain->reserved_regions);
>> + }
>> + return 0;
>> +}
>> +
>> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
>> + struct device *device)
>> +{
>> + struct iommu_reserved_region *region;
>> + int ret = 0;
>> +
>> + /* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
>> + if (!domain->iova_cookie) {
>> +
>> + region = kzalloc(sizeof(*region), GFP_KERNEL);
>> + if (!region)
>> + return -ENOMEM;
>> +
>> + region->start = MSI_IOVA_BASE;
>> + region->length = MSI_IOVA_LENGTH;
>> + list_add_tail(®ion->list, &domain->reserved_regions);
>> +
>> + ret = iommu_get_dma_msi_region_cookie(domain,
>> + region->start, region->length);
>> + if (ret)
>> + return ret;
>
> Gah, I hate this. Is there no other and simpler way to get the MSI
> region than allocating an iova-domain? In that regard, I also _hate_ the
> patch before introducing this weird iommu_get_dma_msi_region_cookie()
> function.
>
> Allocation an iova-domain is pretty expensive, as it also includes
> per-cpu data-structures and all, so please don't do this just for the
> purpose of compiling a list of reserved regions.
It does not only serve the purpose to register the MSI IOVA region. We
also need to allocate an iova_domain where MSI IOVAs will be allocated
upon the request of the relevant MSI controllers. Do you mean you don't
like to use the iova allocator for this purpose?
Thanks
Eric
>
>
>
> Joerg
>
^ 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