* [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
* [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 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
* [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
* 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 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
* [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 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 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 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 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 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 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 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 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] 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 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
* PM regression with LED changes in next-20161109
From: Tony Lindgren @ 2016-11-10 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621758ce-dd3f-41ad-d9b8-b8e34538700e@redhat.com>
* Hans de Goede <hdegoede@redhat.com> [161110 01:35]:
> Hi,
>
> On 09-11-16 20:23, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
> > the sysfs brightness attr for changes.") breaks runtime PM for me.
> >
> > On my omap dm3730 based test system, idle power consumption is over 70
> > times higher now with this patch! It goes from about 6mW for the core
> > system to over 440mW during idle meaning there's some busy timer now
> > active.
>
> Do you have any blinking LEDs or LED triggers defined on the system ?
There are some configured in the dts file:
$ grep -i led arch/arm/boot/dts/*torpedo*.dts*
And the gpio controlled led1 is configured to blink with
linux,default-trigger = "cpu0".
> > Reverting this patch fixes the issue. Any ideas?
>
> All I can think of is something calling led_set_brightness quite often,
> the patch in question makes led_set_brightness somewhat more expensive,
> but it should not cause such a big difference unless something is
> really calling led_set_brightness quite often maybe something is calling
> it with the same value all the time ?
I don't think this one has any brightness control.
Regards,
Tony
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-10 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110110323.GG1575@localhost.localdomain>
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.
> I do still need to revert these two patches to get the I2S to
> work properly:
>
> commit d70e861a3154833467023123e218e9b1ba558809
> ASoC: samsung: Remove SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag
>
> commit acde50a7bf1fd6ae0baa4402f0a02c4b1bd4c990
> ASoC: dmaengine_pcm: Make FLAG_NO_RESIDUE internal
>
> But that is clearly an unrelated issue, which I haven't found
> time to look into yet as we don't use this platform that often
> these days.
Thanks for reporting this, I will see if I can find time to look
into this issue as well.
--
Thanks,
Sylwester
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Jesper Nilsson @ 2016-11-10 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
Please pull the below signed tag for a trio of minor changes
adding PCIe for the ARM ARTPEC SoC.
Thanks!
/Jesper
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git tags/artpec-for-4.10
for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
----------------------------------------------------------------
ARTPEC changes for 4.10
----------------------------------------------------------------
Niklas Cassel (3):
ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
ARM: ARTPEC-6: add pcie related options
ARM: dts: artpec: add pcie support
arch/arm/boot/dts/artpec6-devboard.dts | 4 ++++
arch/arm/boot/dts/artpec6.dtsi | 29 ++++++++++++++++++++++++++++-
arch/arm/mach-artpec/Kconfig | 3 +++
3 files changed, 35 insertions(+), 1 deletion(-)
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: agustinv at codeaurora.org @ 2016-11-10 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42ff0a81-7836-11f6-58e0-979bd1d0be20@linaro.org>
Hey Hanjun,
On 2016-11-09 21:36, Hanjun Guo wrote:
> Hi Marc, Rafael, Lorenzo,
>
> Since we agreed to add a probe deferral if we failed to get irq
> resources which mirroring the DT does (patch 1 in this patch set),
> I think the last blocker to make things work both for Agustin and
> me [1] is this patch, which makes the interrupt producer and consumer
> work in ACPI, we have two different solution for one thing, we'd happy
> to work together for one solution, could you give some suggestions
> please?
>
> [1]:
> https://mail-archive.com/linux-kernel at vger.kernel.org/msg1257419.html
>
> Agustin, I have some comments below.
>
> On 2016/10/29 4:48, Agustin Vega-Frias wrote:
>> This allows irqchip drivers to associate an ACPI DSDT device to
>> an IRQ domain and provides support for using the ResourceSource
>> in Extended IRQ Resources to find the domain and map the IRQs
>> specified on that domain.
>>
>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>> ---
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/irqdomain.c | 119
>> +++++++++++++++++++++++++++++++++++++++++++++++
>
> Could we just reuse the gsi.c and not introduce a new
> file, probably we can change the gsi.c to irqdomain.c
> or something similar, then reuse the code in gsi.c.
I was thinking just that after we chatted off-list.
I might revisit and see what I come up with given that we already have
a device argument and we could pass the IRQ source there.
Thanks
>
> Thanks
> Hanjun
>
>> drivers/acpi/resource.c | 21 +++++----
>> include/linux/acpi.h | 25 ++++++++++
>> 4 files changed, 157 insertions(+), 9 deletions(-)
>> create mode 100644 drivers/acpi/irqdomain.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 9ed0878..880401b 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>> acpi-y += acpi_lpat.o
>> acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
>> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
>> +acpi-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
>>
>> # These are (potentially) separate modules
>>
>> diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
>> new file mode 100644
>> index 0000000..11d3658
>> --- /dev/null
>> +++ b/drivers/acpi/irqdomain.c
>> @@ -0,0 +1,119 @@
>> +/*
>> + * ACPI ResourceSource/IRQ domain mapping support
>> + *
>> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include <linux/acpi.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +
>> +/**
>> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ
>> produced
>> + * by the given acpi_resource_source
>> to a
>> + * Linux IRQ number
>> + * @source: IRQ source
>> + * @hwirq: Hardware IRQ number
>> + * @trigger: trigger type of the IRQ number to be mapped
>> + * @polarity: polarity of the IRQ to be mapped
>> + *
>> + * Returns: a valid linux IRQ number on success
>> + * -ENODEV if the given acpi_resource_source cannot be found
>> + * -EPROBE_DEFER if the IRQ domain has not been registered
>> + * -EINVAL for all other errors
>> + */
>> +int acpi_irq_domain_register_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq, int trigger, int polarity)
>> +{
>> + struct irq_fwspec fwspec;
>> + struct acpi_device *device;
>> + acpi_handle handle;
>> + acpi_status status;
>> + int ret;
>> +
>> + /* An empty acpi_resource_source means it is a GSI */
>> + if (!source->string_length)
>> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
>> +
>> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
>> + if (ACPI_FAILURE(status))
>> + return -ENODEV;
>> +
>> + device = acpi_bus_get_acpi_device(handle);
>> + if (!device)
>> + return -ENODEV;
>> +
>> + if (irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY) ==
>> NULL) {
>> + ret = -EPROBE_DEFER;
>> + goto out_put_device;
>> + }
>> +
>> + fwspec.fwnode = &device->fwnode;
>> + fwspec.param[0] = hwirq;
>> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
>> + fwspec.param_count = 2;
>> +
>> + ret = irq_create_fwspec_mapping(&fwspec);
>> +
>> +out_put_device:
>> + acpi_bus_put_acpi_device(device);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
>> +
>> +/**
>> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ
>> produced
>> + * by the given
>> acpi_resource_source to a
>> + * Linux IRQ number
>> + * @source: IRQ source
>> + * @hwirq: Hardware IRQ number
>> + *
>> + * Returns: 0 on success
>> + * -ENODEV if the given acpi_resource_source cannot be found
>> + * -EINVAL for all other errors
>> + */
>> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq)
>> +{
>> + struct irq_domain *domain;
>> + struct acpi_device *device;
>> + acpi_handle handle;
>> + acpi_status status;
>> + int ret = 0;
>> +
>> + if (!source->string_length) {
>> + acpi_unregister_gsi(hwirq);
>> + return 0;
>> + }
>> +
>> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
>> + if (ACPI_FAILURE(status))
>> + return -ENODEV;
>> +
>> + device = acpi_bus_get_acpi_device(handle);
>> + if (!device)
>> + return -ENODEV;
>> +
>> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
>> + if (!domain) {
>> + ret = -EINVAL;
>> + goto out_put_device;
>> + }
>> +
>> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
>> +
>> +out_put_device:
>> + acpi_bus_put_acpi_device(device);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 4beda15..ccb6f4f 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -381,14 +381,15 @@ static void acpi_dev_irqresource_disabled(struct
>> resource *res, u32 gsi)
>> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED |
>> IORESOURCE_UNSET;
>> }
>>
>> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
>> +static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
>> + const struct acpi_resource_source *source,
>> u8 triggering, u8 polarity, u8 shareable,
>> bool legacy)
>> {
>> int irq, p, t;
>>
>> - if (!valid_IRQ(gsi)) {
>> - acpi_dev_irqresource_disabled(res, gsi);
>> + if ((source->string_length == 0) && !valid_IRQ(hwirq)) {
>> + acpi_dev_irqresource_disabled(res, hwirq);
>> return;
>> }
>>
>> @@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> * using extended IRQ descriptors we take the IRQ configuration
>> * from _CRS directly.
>> */
>> - if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
>> + if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
>> u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
>> u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>>
>> if (triggering != trig || polarity != pol) {
>> - pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
>> - t ? "level" : "edge", p ? "low" : "high");
>> + pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
>> + t ? "level" : "edge", p ? "low" : "high");
>> triggering = trig;
>> polarity = pol;
>> }
>> }
>>
>> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
>> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>> + irq = acpi_irq_domain_register_irq(source, hwirq, triggering,
>> polarity);
>> if (irq >= 0) {
>> res->start = irq;
>> res->end = irq;
>> } else {
>> - acpi_dev_irqresource_disabled(res, gsi);
>> + acpi_dev_irqresource_disabled(res, hwirq);
>> }
>> }
>>
>> @@ -446,6 +447,7 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int
>> index,
>> struct resource *res)
>> {
>> + const struct acpi_resource_source dummy = { 0, 0, NULL };
>> struct acpi_resource_irq *irq;
>> struct acpi_resource_extended_irq *ext_irq;
>>
>> @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, irq->interrupts[index],
>> + acpi_dev_get_irqresource(res, irq->interrupts[index], &dummy,
>> irq->triggering, irq->polarity,
>> irq->sharable, true);
>> break;
>> @@ -471,6 +473,7 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> return false;
>> }
>> acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> + &ext_irq->resource_source,
>> ext_irq->triggering, ext_irq->polarity,
>> ext_irq->sharable, false);
>> break;
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 40213c4..ce30a12 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -321,6 +321,31 @@ void acpi_set_irq_model(enum acpi_irq_model_id
>> model,
>> */
>> void acpi_unregister_gsi (u32 gsi);
>>
>> +#ifdef CONFIG_IRQ_DOMAIN
>> +
>> +int acpi_irq_domain_register_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq, int trigger, int polarity);
>> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq);
>> +
>> +#else
>> +
>> +static inline int acpi_irq_domain_register_irq(
>> + const struct acpi_resource_source *source, u32 hwirq, int trigger,
>> + int polarity)
>> +{
>> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
>> +}
>> +
>> +static inline int acpi_irq_domain_unregister_irq(
>> + const struct acpi_resource_source *source, u32 hwirq)
>> +{
>> + acpi_unregister_gsi(hwirq);
>> + return 0;
>> +}
>> +
>> +#endif /* CONFIG_IRQ_DOMAIN */
>> +
>> struct pci_dev;
>>
>> int acpi_pci_irq_enable (struct pci_dev *dev);
>>
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 5/5] drm/sun4i: Add support for the overscan profiles
From: Maxime Ripard @ 2016-11-10 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108085927.ibyett46cjgyfwu2@phenom.ffwll.local>
Hi Daniel,
On Tue, Nov 08, 2016 at 09:59:27AM +0100, Daniel Vetter wrote:
> On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote:
> > Create overscan profiles reducing the displayed zone.
> >
> > For each TV standard (PAL and NTSC so far), we create 4 more reduced modes
> > by steps of 5% that the user will be able to select.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> tbh I think if we agree to do this (and that still seems an open question)
> I think there should be a generic helper to add these overscan modes with
> increased porches. Anything that only depends upon the sink (and
> overscanning is something the sink does) should imo be put into a suitable
> helper library for everyone to share.
>
> Or maybe even stash it into the probe helpers and call it for all TV
> connectors. Definitely not a driver-private thing.
Last time we discussed it, my recollection was that you didn't want to
have generic code for it, but I'd be happy to implement it.
I'll come up with something like that.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/40bb0b9b/attachment.sig>
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Joerg Roedel @ 2016-11-10 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83b6440a-31eb-c1b4-642c-a4c311f37ef2@redhat.com>
On Thu, Nov 10, 2016 at 01:14:42AM +0100, Auger Eric wrote:
> Besides above problematic, I started to prototype the sysfs API. A first
> issue I face is the reserved regions become global to the iommu instead
> of characterizing the iommu_domain, ie. the "reserved_regions" attribute
> file sits below an iommu instance (~
> /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
> /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
>
> MSI reserved window can be considered global to the IOMMU. However PCIe
> host bridge P2P regions rather are per iommu-domain.
>
> Do you confirm the attribute file should contain both global reserved
> regions and all per iommu_domain reserved regions?
>
> Thoughts?
This information is best attached to the sysfs-representation of
iommu-groups. The file should then contain the superset of all reserved
regions of the devices the group contains. This makes it usable later to
also describe RMRR/Unity-mapped regions on x86 there and make them
assignable to guests as well.
Joerg
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Joerg Roedel @ 2016-11-10 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109130114.3e17bba9@t450s.home>
On Wed, Nov 09, 2016 at 01:01:14PM -0700, Alex Williamson wrote:
> Well, it's not like QEMU or libvirt stumbling through sysfs to figure
> out where holes could be in order to instantiate a VM with matching
> holes, just in case someone might decide to hot-add a device into the
> VM, at some point, and hopefully they don't migrate the VM to another
> host with a different layout first, is all that much less disgusting or
> foolproof. It's just that in order to dynamically remove a page as a
> possible DMA target we require a paravirt channel, such as a balloon
> driver that's able to pluck a specific page. In some ways it's
> actually less disgusting, but it puts some prerequisites on
> enlightening the guest OS. Thanks,
I think it is much simpler if libvirt/qemu just go through all
potentially assignable devices on a system and pre-exclude any addresses
from guest RAM beforehand, rather than doing something like this with
paravirt/ballooning when a device is hot-added. There is no guarantee
that you can take a page away from a linux-guest.
Joerg
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-10 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLW4JZHb0ncVUEefnKySA231EDgvCkY3xPdaJGf=uMJYg@mail.gmail.com>
On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>> Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>
OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.
E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.
Is that not acceptable ?
--
Regards,
Sudeep
^ 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