Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 3/3] pinctrl: mvebu: add additional variant for standalone CP115
From: Linus Walleij @ 2019-08-27  7:49 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Mark Rutland,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Yan Markman, Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
	Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
	Rob Herring, Thomas Petazzoni, Stefan Chulski, Marcin Wojtas,
	Linux ARM
In-Reply-To: <20190805101607.29811-4-miquel.raynal@bootlin.com>

On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> From: Grzegorz Jaszczyk <jaz@semihalf.com>
>
> With CP115 standalone modules, all MPP configuration are
> possible. Handle this new possibility thanks to the new
> "marvell,cp115-standalone-pinctrl" compatible property.
>
> Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
> [<miquel.raynal@bootlin.com>: mention the new compatible in the
> commit log]
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Patch applied.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 1/3] pinctrl: mvebu: Add CP110 missing pin functionality
From: Linus Walleij @ 2019-08-27  7:48 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Mark Rutland,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Yan Markman, Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
	Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
	Rob Herring, Thomas Petazzoni, Konstantin Porotchkin,
	Stefan Chulski, Marcin Wojtas, Linux ARM
In-Reply-To: <20190805101607.29811-2-miquel.raynal@bootlin.com>

On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> From: Konstantin Porotchkin <kostap@marvell.com>
>
> Add missing definition for function 0xe on CP-110 MPP-62.
> The pin function is Data Strobe for SDIO interface.
>
> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Patch applied.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 2/3] dt-bindings: cp110: document the new CP115 pinctrl compatible
From: Linus Walleij @ 2019-08-27  7:46 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Mark Rutland,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Yan Markman, Antoine Tenart, Grzegorz Jaszczyk, Gregory Clement,
	Maxime Chevallier, Nadav Haklai, open list:GPIO SUBSYSTEM,
	Rob Herring, Thomas Petazzoni, Stefan Chulski, Marcin Wojtas,
	Linux ARM
In-Reply-To: <20190805101607.29811-3-miquel.raynal@bootlin.com>

On Mon, Aug 5, 2019 at 12:16 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> From: Grzegorz Jaszczyk <jaz@semihalf.com>
>
> A new compatible is going to be used for Armada CP115 pinctrl block,
> document it.
>
> Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
> [<miquel.raynal@bootlin.com>: split the documentation out of the
> driver commit]
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Patch applied with Rob's ACK.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-27  7:45 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
	Linux Kernel Mailing List, Max Filippov, Marek Szyprowski,
	Stephen Rothwell, Joerg Roedel, Russell King, Thierry Reding,
	linux-xtensa, Kees Cook, Nicolin Chen, Andrew Morton,
	linux-arm-kernel, Chris Zankel, Wolfram Sang, David Woodhouse,
	linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim, Robin Murphy
In-Reply-To: <20190826073320.GA11712@lst.de>

On Mon, Aug 26, 2019 at 4:33 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Aug 26, 2019 at 11:05:00AM +0900, Masahiro Yamada wrote:
> > This is included in v5.3-rc6
> > so I tested it.
>
> So there is no allocation failure, but you get I/O errors later?

Right.

>
> Does the device use a device-private CMA area?

Not sure.
My driver is drivers/mmc/host/sdhci-cadence.c
It reuses routines in drivers/mmc/host/sdhci.c



>  Does it work with Linux
> 5.2 if CONFIG_DMA_CMA is disabled?

No.
5.2 + disable CONFIG_DMA_CMA
failed in the same way.




-- 
Best Regards
Masahiro Yamada

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] ASoC: imx-audmix: register the card on a proper dev
From: Daniel Baluta @ 2019-08-27  7:44 UTC (permalink / raw)
  To: timur@kernel.org, Xiubo.Lee@gmail.com, nicoleotsuka@gmail.com,
	festevam@gmail.com, broonie@kernel.org, tiwai@suse.com,
	lgirdwood@gmail.com, shawnguo@kernel.org, S.j. Wang, Viorel Suman,
	perex@perex.cz, kernel@pengutronix.de,
	alsa-devel@alsa-project.org, s.hauer@pengutronix.de
  Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1566921315-23402-1-git-send-email-shengjiu.wang@nxp.com>

On Tue, 2019-08-27 at 11:55 -0400, Shengjiu Wang wrote:
> This platform device is registered from "fsl_audmix", which is
> its parent device. If use pdev->dev.parent for the priv->card.dev,
> the value set by dev_set_drvdata in parent device will be covered
> by the value in child device.
> 
> Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
> Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>

Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>

Thanks Shengjiu for the fix!

> ---
>  sound/soc/fsl/imx-audmix.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
> index 9e1cb18859ce..71590ca6394b 100644
> --- a/sound/soc/fsl/imx-audmix.c
> +++ b/sound/soc/fsl/imx-audmix.c
> @@ -325,14 +325,14 @@ static int imx_audmix_probe(struct
> platform_device *pdev)
>  	priv->card.num_configs = priv->num_dai_conf;
>  	priv->card.dapm_routes = priv->dapm_routes;
>  	priv->card.num_dapm_routes = priv->num_dapm_routes;
> -	priv->card.dev = pdev->dev.parent;
> +	priv->card.dev = &pdev->dev;
>  	priv->card.owner = THIS_MODULE;
>  	priv->card.name = "imx-audmix";
>  
>  	platform_set_drvdata(pdev, &priv->card);
>  	snd_soc_card_set_drvdata(&priv->card, priv);
>  
> -	ret = devm_snd_soc_register_card(pdev->dev.parent, &priv-
> >card);
> +	ret = devm_snd_soc_register_card(&pdev->dev, &priv->card);
>  	if (ret) {
>  		dev_err(&pdev->dev, "snd_soc_register_card failed\n");
>  		return ret;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH -next] media: sun6i: Make sun4i_csi_formats static
From: Yuehaibing @ 2019-08-27  7:23 UTC (permalink / raw)
  To: Sakari Ailus
  Cc: maxime.ripard, linux-kernel, mripard, wens, mchehab,
	linux-arm-kernel, linux-media
In-Reply-To: <20190827072043.GA7657@paasikivi.fi.intel.com>

On 2019/8/27 15:20, Sakari Ailus wrote:
> Hi Yue,
> 
> On Tue, Aug 27, 2019 at 03:06:23PM +0800, YueHaibing wrote:
>> Fix sparse warning:
>>
>> drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c:21:31:
>>  warning: symbol 'sun4i_csi_formats' was not declared. Should it be static?
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> 
> Thanks for the patch.
> 
> This has been already addressed by another patch:
> 
> <URL:https://patchwork.linuxtv.org/patch/58395/>

OK, thank you!

> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH -next] media: sun6i: Make sun4i_csi_formats static
From: Sakari Ailus @ 2019-08-27  7:20 UTC (permalink / raw)
  To: YueHaibing
  Cc: maxime.ripard, linux-kernel, mripard, wens, mchehab,
	linux-arm-kernel, linux-media
In-Reply-To: <20190827070623.15776-1-yuehaibing@huawei.com>

Hi Yue,

On Tue, Aug 27, 2019 at 03:06:23PM +0800, YueHaibing wrote:
> Fix sparse warning:
> 
> drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c:21:31:
>  warning: symbol 'sun4i_csi_formats' was not declared. Should it be static?
> 
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Thanks for the patch.

This has been already addressed by another patch:

<URL:https://patchwork.linuxtv.org/patch/58395/>

-- 
Sakari Ailus
sakari.ailus@linux.intel.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v1 1/1] ARM: dts: rockchip: set crypto default disabled on rk3288
From: Elon Zhang @ 2019-08-27  7:14 UTC (permalink / raw)
  To: heiko, mark.rutland, robh+dt
  Cc: Elon Zhang, devicetree, linux-kernel, linux-arm-kernel,
	linux-rockchip

Not every board needs to enable crypto node, so the node should
be set default disabled in rk3288.dtsi and enabled in specific
board dts file.

Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cc893e154fe5..d509aa24177c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -984,7 +984,7 @@
 		clock-names = "aclk", "hclk", "sclk", "apb_pclk";
 		resets = <&cru SRST_CRYPTO>;
 		reset-names = "crypto-rst";
-		status = "okay";
+		status = "disabled";
 	};
 
 	iep_mmu: iommu@ff900800 {
-- 
2.17.1




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH] drm/meson: vclk: use the correct G12A frac max value
From: Neil Armstrong @ 2019-08-27  7:11 UTC (permalink / raw)
  To: Martin Blumenstingl
  Cc: linux-arm-kernel, linux-amlogic, linux-kernel, dri-devel
In-Reply-To: <CAFBinCBdxLnHsqvLT863cUkZ3Cf_2FhzOMQVTvLbxNCsQBi1WQ@mail.gmail.com>

On 27/08/2019 07:40, Martin Blumenstingl wrote:
> On Mon, Aug 26, 2019 at 4:47 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
>> use the correct max fractional PLL value for G12A VPU.
>>
>> With this fix, we can finally setup the 1024x76-60 mode.
> nit-pick: is this really 1024x76 or 1024x768?
> 

It is 1024x768, bad copy paste :-p

Neil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH -next] media: sun6i: Make sun4i_csi_formats static
From: YueHaibing @ 2019-08-27  7:06 UTC (permalink / raw)
  To: mripard, mchehab, wens, maxime.ripard, sakari.ailus
  Cc: YueHaibing, linux-kernel, linux-arm-kernel, linux-media

Fix sparse warning:

drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c:21:31:
 warning: symbol 'sun4i_csi_formats' was not declared. Should it be static?

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
 drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
index 772b0fc..83a3a02 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
@@ -18,7 +18,7 @@
 #define CSI_DEFAULT_WIDTH	640
 #define CSI_DEFAULT_HEIGHT	480
 
-const struct sun4i_csi_format sun4i_csi_formats[] = {
+static const struct sun4i_csi_format sun4i_csi_formats[] = {
 	/* YUV422 inputs */
 	{
 		.mbus		= MEDIA_BUS_FMT_YUYV8_2X8,
-- 
2.7.4



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v2 10/11] arm64: edit zone_dma_bits to fine tune dma-direct min mask
From: Petr Tesarik @ 2019-08-27  7:03 UTC (permalink / raw)
  To: Nicolas Saenz Julienne
  Cc: catalin.marinas, linux-mm, linux-riscv, frowand.list,
	Christoph Hellwig, m.szyprowski, linux-arch, f.fainelli, will,
	devicetree, marc.zyngier, robh+dt, linux-rpi-kernel,
	linux-arm-kernel, phill, mbrugger, eric, linux-kernel, iommu,
	wahrenst, akpm, Robin Murphy
In-Reply-To: <4d8d18af22d6dcd122bc9b4d9c2bd49e8443c746.camel@suse.de>


[-- Attachment #1.1: Type: text/plain, Size: 820 bytes --]

On Mon, 26 Aug 2019 13:08:50 +0200
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote:

> On Mon, 2019-08-26 at 09:06 +0200, Christoph Hellwig wrote:
> > On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote:  
> > > -	if (IS_ENABLED(CONFIG_ZONE_DMA))
> > > +	if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> > >  		arm64_dma_phys_limit = max_zone_dma_phys();
> > > +		zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) &
> > > GENMASK_ULL(31, 0)) + 1;  
> >  
> Hi Christoph,
> thanks for the rewiews.
> 
> > This adds a way too long line.  
> 
> I know, I couldn't find a way to split the operation without making it even
> harder to read. I'll find a solution.

If all else fails, move the code to an inline function and call it e.g.
phys_limit_to_dma_bits().

Just my two cents,
Petr T

[-- Attachment #1.2: Digitální podpis OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 3/3] ASoC: sun4i-i2s: Adjust LRCLK width
From: Maxime Ripard @ 2019-08-27  7:01 UTC (permalink / raw)
  To: codekipper
  Cc: alsa-devel, linux-sunxi, linux-kernel, lgirdwood, be17068, wens,
	broonie, linux-arm-kernel
In-Reply-To: <20190826180734.15801-4-codekipper@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

On Mon, Aug 26, 2019 at 08:07:34PM +0200, codekipper@gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> Some codecs such as i2s based HDMI audio and the Pine64 DAC require
> a different amount of bit clocks per frame than what is calculated
> by the sample width. Use the values obtained by the tdm slot bindings
> to adjust the LRCLK width accordingly.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
>  sound/soc/sunxi/sun4i-i2s.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 056a299c03fb..0965a97c96e5 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -455,7 +455,10 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
>  		break;
>
>  	case SND_SOC_DAIFMT_I2S:
> -		lrck_period = params_physical_width(params);
> +		if (i2s->slot_width)
> +			lrck_period = i2s->slot_width;
> +		else
> +			lrck_period = params_physical_width(params);
>  		break;

That would be the case with the DSP formats too, right?

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 03/11] xen/arm: simplify dma_cache_maint
From: Christoph Hellwig @ 2019-08-27  6:37 UTC (permalink / raw)
  To: Stefano Stabellini, Konrad Rzeszutek Wilk
  Cc: xen-devel, iommu, x86, linux-kernel, linux-arm-kernel
In-Reply-To: <20190826121944.515-4-hch@lst.de>

And this was still buggy I think, it really needs some real Xen/Arm
testing which I can't do.  Hopefully better version below:

--
From 5ad4b6e291dbb49f65480c9b769414931cbd485a Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 24 Jul 2019 15:26:08 +0200
Subject: xen/arm: simplify dma_cache_maint

Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arm/xen/mm.c | 61 ++++++++++++++++-------------------------------
 1 file changed, 21 insertions(+), 40 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 90574d89d0d4..2fde161733b0 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -35,64 +35,45 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
 	return __get_free_pages(flags, order);
 }
 
-enum dma_cache_op {
-       DMA_UNMAP,
-       DMA_MAP,
-};
 static bool hypercall_cflush = false;
 
-/* functions called by SWIOTLB */
-
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-	size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+/* buffers in highmem or foreign pages cannot cross page boundaries */
+static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op)
 {
 	struct gnttab_cache_flush cflush;
-	unsigned long xen_pfn;
-	size_t left = size;
 
-	xen_pfn = (handle >> XEN_PAGE_SHIFT) + offset / XEN_PAGE_SIZE;
-	offset %= XEN_PAGE_SIZE;
+	cflush.a.dev_bus_addr = handle & XEN_PAGE_MASK;
+	cflush.offset = xen_offset_in_page(handle);
+	cflush.op = op;
 
 	do {
-		size_t len = left;
-	
-		/* buffers in highmem or foreign pages cannot cross page
-		 * boundaries */
-		if (len + offset > XEN_PAGE_SIZE)
-			len = XEN_PAGE_SIZE - offset;
-
-		cflush.op = 0;
-		cflush.a.dev_bus_addr = xen_pfn << XEN_PAGE_SHIFT;
-		cflush.offset = offset;
-		cflush.length = len;
-
-		if (op == DMA_UNMAP && dir != DMA_TO_DEVICE)
-			cflush.op = GNTTAB_CACHE_INVAL;
-		if (op == DMA_MAP) {
-			if (dir == DMA_FROM_DEVICE)
-				cflush.op = GNTTAB_CACHE_INVAL;
-			else
-				cflush.op = GNTTAB_CACHE_CLEAN;
-		}
-		if (cflush.op)
-			HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
+		if (size + cflush.offset > XEN_PAGE_SIZE)
+			cflush.length = XEN_PAGE_SIZE - cflush.offset;
+		else
+			cflush.length = size;
+
+		HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
 
-		offset = 0;
-		xen_pfn++;
-		left -= len;
-	} while (left);
+		cflush.offset = 0;
+		cflush.a.dev_bus_addr += cflush.length;
+		size -= cflush.length;
+	} while (size);
 }
 
 static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_UNMAP);
+	if (dir != DMA_TO_DEVICE)
+		dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
 }
 
 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
 		size_t size, enum dma_data_direction dir)
 {
-	dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, DMA_MAP);
+	if (dir == DMA_FROM_DEVICE)
+		dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+	else
+		dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
 }
 
 void __xen_dma_map_page(struct device *hwdev, struct page *page,
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: swiotlb-xen cleanups
From: Christoph Hellwig @ 2019-08-27  6:21 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: Konrad Rzeszutek Wilk, x86, linux-kernel, iommu, xen-devel,
	Christoph Hellwig, linux-arm-kernel
In-Reply-To: <alpine.DEB.2.21.1908261859490.3428@sstabellini-ThinkPad-T480s>

On Mon, Aug 26, 2019 at 07:00:44PM -0700, Stefano Stabellini wrote:
> On Fri, 16 Aug 2019, Christoph Hellwig wrote:
> > Hi Xen maintainers and friends,
> > 
> > please take a look at this series that cleans up the parts of swiotlb-xen
> > that deal with non-coherent caches.
> 
> Hi Christoph,
> 
> I just wanted to let you know that your series is on my radar, but I
> have been swamped the last few days. I hope to get to it by the end of
> the week.

Thanks, and no rush.  Note that I posted a v2 with a few significant
changes yesterday.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* RE: [PATCH] input: keyboard: snvs_pwrkey: Send press and release event for i.MX6 S,DL and Q
From: Robin Gong @ 2019-08-27  6:17 UTC (permalink / raw)
  To: Robin van der Gracht
  Cc: Mark Rutland, devicetree@vger.kernel.org, Shawn Guo, Sascha Hauer,
	Dmitry Torokhov, linux-kernel@vger.kernel.org, Rob Herring,
	dl-linux-imx, Pengutronix Kernel Team,
	linux-input@vger.kernel.org, Adam Ford, Fabio Estevam,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823123002.10448-1-robin@protonic.nl>

On Fri, Aug 23, 2019 at 02:30:02PM +0200, Robin van der Gracht wrote:> 
> The older generation i.MX6 processors send a powerdown request interrupt
> if the powerkey is released before a hard shutdown (5 second press). This
> should allow software to bring down the SoC safely.
> 
> For this driver to work as a regular powerkey with the older SoCs, we need to
> send a keypress AND release when we get the powerdown request interrupt.
Please clarify here more clearly that because there is NO press interrupt triggered
but only release interrupt on elder i.mx6 processors and that HW issue fixed from
i.mx6sx.
> 
> Signed-off-by: Robin van der Gracht <robin@protonic.nl>
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi       |  2 +-
>  arch/arm/boot/dts/imx6sll.dtsi       |  2 +-
>  arch/arm/boot/dts/imx6sx.dtsi        |  2 +-
>  arch/arm/boot/dts/imx6ul.dtsi        |  2 +-
>  arch/arm/boot/dts/imx7s.dtsi         |  2 +-
As Shawn talked, please keep the original "fsl,sec-v4.0-pwrkey", just add
'imx6qdl-snvs-pwrkey' for elder i.mx6 processor i.mx6q/dl/sl, thus no need
to touch other newer processor's dts.

> 
>  static void imx_imx_snvs_check_for_events(struct timer_list *t) @@ -67,13
> +85,23 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void
> *dev_id)  {
>  	struct platform_device *pdev = dev_id;
>  	struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> +	struct input_dev *input = pdata->input;
>  	u32 lp_status;
> 
> -	pm_wakeup_event(pdata->input->dev.parent, 0);
> +	pm_wakeup_event(input->dev.parent, 0);
> 
>  	regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> -	if (lp_status & SNVS_LPSR_SPO)
> -		mod_timer(&pdata->check_timer, jiffies +
> msecs_to_jiffies(DEBOUNCE_TIME));
> +	if (lp_status & SNVS_LPSR_SPO) {
> +		if (pdata->hwtype == IMX6QDL_SNVS) {
> +			input_report_key(input, pdata->keycode, 1);
> +			input_report_key(input, pdata->keycode, 0);
> +			input_sync(input);
> +			pm_relax(input->dev.parent);
Could you move the above input event report steps into imx_imx_snvs_check_for_events()
as before? That make code better to understand and less operation in ISR.
> +		} else {
> +			mod_timer(&pdata->check_timer,
> +				jiffies + msecs_to_jiffies(DEBOUNCE_TIME));
> +		}
> +	}
> 
>  	/* clear SPO status */
>  	regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO); @@
> -88,11 +116,24 @@ static void imx_snvs_pwrkey_act(void *pdata)
>  	del_timer_sync(&pd->check_timer);
>  }
> 
> +static const struct of_device_id imx_snvs_pwrkey_ids[] = {
> +	{
> +		.compatible = "fsl,imx6sx-sec-v4.0-pwrkey",
> +		.data = &imx_snvs_devtype[IMX6SX_SNVS],
> +	}, {
> +		.compatible = "fsl,imx6qdl-sec-v4.0-pwrkey",
> +		.data = &imx_snvs_devtype[IMX6QDL_SNVS],
No ' IMX6QDL_SNVS ' defined in your patch or am I missing?
> +	},
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
> --
> 2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: Code Kipper @ 2019-08-27  5:54 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Linux-ALSA, linux-kernel, Maxime Ripard, Liam Girdwood,
	Andrea Venturi (pers), linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <CAGb2v651jVp+J2eyWh7vw-yHmFTVy4eaMjHV0FvOF17C5_Hswg@mail.gmail.com>

On Tue, 27 Aug 2019 at 06:13, Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Tue, Aug 27, 2019 at 2:07 AM <codekipper@gmail.com> wrote:
> >
> > From: Marcus Cooper <codekipper@gmail.com>
> >
> > The regmap configuration is set up for the legacy block on the
> > A83T whereas it uses the new block with a larger register map.
>
> Looking at the code Allwinner previously released [1], that doesn't seem to be
> the case. Keep in mind that the register map shown in the user manual is for
> the TDM interface, which we don't actually support right now.

Should it matter what we support right now?, the block according to the user
manual shows the bigger range. I don't have a A83T device and from what I
gather not many users do. But the compatible for the H3 has been removed
and replaced with the settings for the A83T which also has default settings in
registers further up than SUNXI_RXCHMAP.

>
> The file shows the base address as 0x01c22800, and the last defined register
> is SUNXI_RXCHMAP at 0x3c.
>
> The I2S driver [2] also shows that it is the old register map size, but with
> TX_FIFO and INT_STA swapped around. This might mean that it would need a
> separate regmap_config, as the read/write callbacks need to be changed to
> fit the swapped registers.
>
> Finally, the TDM driver [3], which matches the TDM section in the manual, shows
> a larger register map.
>
> A83T is SUN8IW6, while SUN8IW7 refers to the H3.

Since when have we trusted Allwinner code?, the TDM labelled block
clearly supports
I2S. The biggest use case for this block is getting HDMI audio working
on the newer
devices(LibreELEC nightlies has a user base of over 300) and I've tested this on
numerous set ups over the last couple of years.

Failing that reverting (3e9acd7ac693: "ASoC: sun4i-i2s: Remove
duplicated quirks structure")
would help.

BR,
CK
>
> ChenYu
>
> [1] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.h
> [2] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/i2s0/sunxi-i2s0.h
> [3] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/daudio0/sunxi-daudio0.h
>
> > Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
> > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> > ---
> >  sound/soc/sunxi/sun4i-i2s.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> > index 57bf2a33753e..34575a8aa9f6 100644
> > --- a/sound/soc/sunxi/sun4i-i2s.c
> > +++ b/sound/soc/sunxi/sun4i-i2s.c
> > @@ -1100,7 +1100,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
> >  static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
> >         .has_reset              = true,
> >         .reg_offset_txdata      = SUN8I_I2S_FIFO_TX_REG,
> > -       .sun4i_i2s_regmap       = &sun4i_i2s_regmap_config,
> > +       .sun4i_i2s_regmap       = &sun8i_i2s_regmap_config,
> >         .field_clkdiv_mclk_en   = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
> >         .field_fmt_wss          = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
> >         .field_fmt_sr           = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
> > --
> > 2.23.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190826180734.15801-2-codekipper%40gmail.com.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] drm/meson: vclk: use the correct G12A frac max value
From: Martin Blumenstingl @ 2019-08-27  5:40 UTC (permalink / raw)
  To: Neil Armstrong; +Cc: linux-arm-kernel, linux-amlogic, linux-kernel, dri-devel
In-Reply-To: <20190826144647.17302-1-narmstrong@baylibre.com>

On Mon, Aug 26, 2019 at 4:47 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
> use the correct max fractional PLL value for G12A VPU.
>
> With this fix, we can finally setup the 1024x76-60 mode.
nit-pick: is this really 1024x76 or 1024x768?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Bjorn Andersson @ 2019-08-27  5:10 UTC (permalink / raw)
  To: Suman Anna
  Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <40831f80-1e36-66ca-b8e5-684d46ba167e@ti.com>

On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:

> Hi Bjorn,
> 

Hi Suman

> On 10/23/18 8:19 PM, Suman Anna wrote:
> > The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> > printing the vring buffer address. This prints only a hashed
> > pointer even for previliged users. Use "%pK" instead so that
> > the address can be printed during debug using kptr_restrict
> > sysctl.
> 
> Seems to have been lost among the patches, can you pick up this trivial
> patch for 5.4? Should apply cleanly on the latest HEAD as well.
> 

I share Andrew's question regarding what benefit you have from knowing
this value. Should we not just remove the va from the print? Or do you
actually have a use case for it?

Regards,
Bjorn

> regards
> Suman
> 
> > 
> > Signed-off-by: Suman Anna <s-anna@ti.com>
> > ---
> >  drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
> > index f29dee731026..1345f373a1a0 100644
> > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
> >  		goto vqs_del;
> >  	}
> >  
> > -	dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
> > +	dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
> >  		bufs_va, &vrp->bufs_dma);
> >  
> >  	/* half of the buffers is dedicated for RX */
> > 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 2/2] arm: Add DRM_MSM to defconfigs with ARCH_QCOM
From: Bjorn Andersson @ 2019-08-27  4:49 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Geert Uytterhoeven, Tony Lindgren, Catalin Marinas, Miquel Raynal,
	Leonard Crestez, Will Deacon, Marek Szyprowski, Anson Huang,
	Russell King, Krzysztof Kozlowski, Marcin Juszkiewicz, Andy Gross,
	Jagan Teki, Brian Masney, Alexandre Torgue, Arnd Bergmann, MSM,
	Maxime Ripard, Enric Balletbo i Serra, Jordan Crouse,
	Simon Horman, Fabrice Gasnier, Linux ARM, freedreno,
	linux-kernel@vger.kernel.org, Yannick Fertr?, Dinh Nguyen,
	Olof Johansson, Shawn Guo, Frank Rowand
In-Reply-To: <CACRpkdbtPo9dr7E2hZ4=fEWTXappWTaypKJyd9M2jz0tYu7HXw@mail.gmail.com>

On Thu 22 Aug 23:52 PDT 2019, Linus Walleij wrote:

> On Tue, Aug 13, 2019 at 4:46 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> 
> > Now that CONFIG_DRM_MSM is no longer default 'y' add it as a module to all
> > ARCH_QCOM enabled defconfigs to restore the previous expected build
> > behavior.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> I suppose Andy will pick this up?
> 

Not sure why, but this patch isn't in any of my mailboxes. So thanks for
the reminder, I've picked it from patchworks for 5.4.

Regards,
Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: Chen-Yu Tsai @ 2019-08-27  4:13 UTC (permalink / raw)
  To: Code Kipper
  Cc: Linux-ALSA, linux-kernel, Maxime Ripard, Liam Girdwood,
	Andrea Venturi (pers), linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <20190826180734.15801-2-codekipper@gmail.com>

On Tue, Aug 27, 2019 at 2:07 AM <codekipper@gmail.com> wrote:
>
> From: Marcus Cooper <codekipper@gmail.com>
>
> The regmap configuration is set up for the legacy block on the
> A83T whereas it uses the new block with a larger register map.

Looking at the code Allwinner previously released [1], that doesn't seem to be
the case. Keep in mind that the register map shown in the user manual is for
the TDM interface, which we don't actually support right now.

The file shows the base address as 0x01c22800, and the last defined register
is SUNXI_RXCHMAP at 0x3c.

The I2S driver [2] also shows that it is the old register map size, but with
TX_FIFO and INT_STA swapped around. This might mean that it would need a
separate regmap_config, as the read/write callbacks need to be changed to
fit the swapped registers.

Finally, the TDM driver [3], which matches the TDM section in the manual, shows
a larger register map.

A83T is SUN8IW6, while SUN8IW7 refers to the H3.

ChenYu

[1] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.h
[2] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/i2s0/sunxi-i2s0.h
[3] https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/daudio0/sunxi-daudio0.h

> Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
>  sound/soc/sunxi/sun4i-i2s.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 57bf2a33753e..34575a8aa9f6 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -1100,7 +1100,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
>  static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
>         .has_reset              = true,
>         .reg_offset_txdata      = SUN8I_I2S_FIFO_TX_REG,
> -       .sun4i_i2s_regmap       = &sun4i_i2s_regmap_config,
> +       .sun4i_i2s_regmap       = &sun8i_i2s_regmap_config,
>         .field_clkdiv_mclk_en   = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
>         .field_fmt_wss          = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
>         .field_fmt_sr           = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
> --
> 2.23.0
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190826180734.15801-2-codekipper%40gmail.com.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RESEND, PATCH v13 09/12] soc: mediatek: cmdq: define the instruction struct
From: Bibby Hsieh @ 2019-08-27  4:12 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
	Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
	Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
	linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
	linux-arm-kernel, ginny.chen
In-Reply-To: <486deaa3-d139-d4af-e0cf-e324b3270f3b@gmail.com>

On Fri, 2019-08-23 at 15:50 +0200, Matthias Brugger wrote:
> 
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > Define an instruction structure for gce driver to append command.
> > This structure can make the client's code more readability.
> > 
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> >  drivers/soc/mediatek/mtk-cmdq-helper.c   | 106 +++++++++++++++--------
> >  include/linux/mailbox/mtk-cmdq-mailbox.h |   2 +
> >  2 files changed, 74 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index 7aa0517ff2f3..e3d5b0be8e79 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -9,12 +9,24 @@
> >  #include <linux/mailbox_controller.h>
> >  #include <linux/soc/mediatek/mtk-cmdq.h>
> >  
> > -#define CMDQ_ARG_A_WRITE_MASK	0xffff
> >  #define CMDQ_WRITE_ENABLE_MASK	BIT(0)
> >  #define CMDQ_EOC_IRQ_EN		BIT(0)
> >  #define CMDQ_EOC_CMD		((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
> >  				<< 32 | CMDQ_EOC_IRQ_EN)
> >  
> > +struct cmdq_instruction {
> > +	union {
> > +		u32 value;
> > +		u32 mask;
> > +	};
> > +	union {
> > +		u16 offset;
> > +		u16 event;
> > +	};
> > +	u8 subsys;
> > +	u8 op;
> > +};
> > +
> >  static void cmdq_client_timeout(struct timer_list *t)
> >  {
> >  	struct cmdq_client *client = from_timer(client, t, timer);
> > @@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> >  }
> >  EXPORT_SYMBOL(cmdq_pkt_destroy);
> >  
> > -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> > -				   u32 arg_a, u32 arg_b)
> > +static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
> >  {
> > -	u64 *cmd_ptr;
> >  
> >  	if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> >  		/*
> > @@ -127,81 +137,109 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> >  		pkt->cmd_buf_size += CMDQ_INST_SIZE;
> >  		WARN_ONCE(1, "%s: buffer size %u is too small !\n",
> >  			__func__, (u32)pkt->buf_size);
> > -		return -ENOMEM;
> > +		return NULL;
> >  	}
> > -	cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> > -	(*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> > +
> > +	*(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;>  	pkt->cmd_buf_size += CMDQ_INST_SIZE;
> >  
> > -	return 0;
> > +	return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
> >  }
> >  
> >  int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> >  {
> > -	u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> > -		    (subsys << CMDQ_SUBSYS_SHIFT);
> > +	struct cmdq_instruction *inst;
> > +
> > +	inst = cmdq_pkt_append_command(pkt);
> > +	if (!inst)
> > +		return -ENOMEM;
> > +
> > +	inst->op = CMDQ_CODE_WRITE;
> > +	inst->value = value;
> > +	inst->offset = offset;
> > +	inst->subsys = subsys;
> >  
> 
> I can see that using cmdq_instruction will make the code more readable, but I
> dislike the approach that cmdq_pkt_append_command returns a pointer where we
> write the instruction to. Better we pass inst to cmdq_pkt_append_command() and
> write it there to cmd_ptr.
> 
> I think this way we can get rid of explicitly setting the memory to zero:
> *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;
> 
> And if we pass the inst to the append_command we don't have to change the return
> value handling of cmdq_pkt_append_command(), which makes the patch easier to
> understand.

Ok, I will change and resend it.

> 
> > -	return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> > +	return 0;
> >  }
> >  EXPORT_SYMBOL(cmdq_pkt_write);
> >  
> >  int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> >  			u16 offset, u32 value, u32 mask)
> >  {
> > -	u32 offset_mask = offset;
> > -	int err = 0;
> > +	struct cmdq_instruction *inst;
> > +	u16 offset_mask = offset;
> >  
> >  	if (mask != 0xffffffff) {
> > -		err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> > +		inst = cmdq_pkt_append_command(pkt);
> > +		if (!inst)
> > +			return -ENOMEM;
> > +
> > +		inst->op = CMDQ_CODE_MASK;
> > +		inst->mask = ~mask;
> >  		offset_mask |= CMDQ_WRITE_ENABLE_MASK;
> >  	}
> > -	err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
> >  
> > -	return err;
> > +	return cmdq_pkt_write(pkt, subsys, offset_mask, value);
> >  }
> >  EXPORT_SYMBOL(cmdq_pkt_write_mask);
> >  
> >  int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> >  {
> > -	u32 arg_b;
> > +	struct cmdq_instruction *inst;
> >  
> >  	if (event >= CMDQ_MAX_EVENT)
> >  		return -EINVAL;
> >  
> > -	/*
> > -	 * WFE arg_b
> > -	 * bit 0-11: wait value
> > -	 * bit 15: 1 - wait, 0 - no wait
> > -	 * bit 16-27: update value
> > -	 * bit 31: 1 - update, 0 - no update
> > -	 */
> 
> I have no strong opinion of CMDQ_WFE_OPTION but if you want to introduce it,
> then please copy the comment over to include/linux/mailbox/mtk-cmdq-mailbox.h

Ok. let's move the descriptions to header.
> 
> Just one question, why did you call it _OPTION? It's not really expressive for me.

Actually, _OPTION is come from our hardware design name...

> 
> > -	arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> > +	inst = cmdq_pkt_append_command(pkt);
> > +	if (!inst)
> > +		return -ENOMEM;
> > +
> > +	inst->op = CMDQ_CODE_WFE;
> > +	inst->value = CMDQ_WFE_OPTION;
> > +	inst->event = event;
> >  
> > -	return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
> > +	return 0;
> >  }
> >  EXPORT_SYMBOL(cmdq_pkt_wfe);
> >  
> >  int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> >  {
> > +	struct cmdq_instruction *inst;
> > +
> >  	if (event >= CMDQ_MAX_EVENT)
> >  		return -EINVAL;
> >  
> > -	return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
> > -				       CMDQ_WFE_UPDATE);
> > +	inst = cmdq_pkt_append_command(pkt);
> > +	if (!inst)
> > +		return -ENOMEM;
> > +
> > +	inst->op = CMDQ_CODE_WFE;
> > +	inst->value = CMDQ_WFE_UPDATE;
> > +	inst->event = event;
> > +
> > +	return 0;
> >  }
> >  EXPORT_SYMBOL(cmdq_pkt_clear_event);
> >  
> >  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >  {
> > -	int err;
> > +	struct cmdq_instruction *inst;
> > +
> > +	inst = cmdq_pkt_append_command(pkt);
> > +	if (!inst)
> > +		return -ENOMEM;
> >  
> > -	/* insert EOC and generate IRQ for each command iteration */
> 
> Please don't delete the comment.
> 
> > -	err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> > +	inst->op = CMDQ_CODE_EOC;
> > +	inst->value = CMDQ_EOC_IRQ_EN;
> >  
> > -	/* JUMP to end */
> 
> Same here.
> 
> Regards,
> Matthias
> 
> > -	err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> > +	inst = cmdq_pkt_append_command(pkt);
> > +	if (!inst)
> > +		return -ENOMEM;
> > +
> > +	inst->op = CMDQ_CODE_JUMP;
> > +	inst->value = CMDQ_JUMP_PASS;
> >  
> > -	return err;
> > +	return 0;
> >  }
> >  
> >  static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> > diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > index 911475da7a53..c8adedefaf42 100644
> > --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> > +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > @@ -19,6 +19,8 @@
> >  #define CMDQ_WFE_UPDATE			BIT(31)
> >  #define CMDQ_WFE_WAIT			BIT(15)
> >  #define CMDQ_WFE_WAIT_VALUE		0x1
> > +#define CMDQ_WFE_OPTION			(CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
> > +					CMDQ_WFE_WAIT_VALUE)
> >  /** cmdq event maximum */
> >  #define CMDQ_MAX_EVENT			0x3ff
> >  
> > 

-- 
Bibby


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RESEND, PATCH v13 10/12] soc: mediatek: cmdq: add polling function
From: Bibby Hsieh @ 2019-08-27  4:07 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
	Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
	Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
	linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
	linux-arm-kernel, ginny.chen
In-Reply-To: <2dfb6a69-c325-9caf-e11b-bf0f0fbf4bb6@gmail.com>

On Fri, 2019-08-23 at 16:05 +0200, Matthias Brugger wrote:
> 
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > add polling function in cmdq helper functions
> > 
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> >  drivers/soc/mediatek/mtk-cmdq-helper.c   | 28 ++++++++++++++++++++++++
> >  include/linux/mailbox/mtk-cmdq-mailbox.h |  1 +
> >  include/linux/soc/mediatek/mtk-cmdq.h    | 15 +++++++++++++
> >  3 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index e3d5b0be8e79..c53f8476c68d 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -221,6 +221,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> >  }
> >  EXPORT_SYMBOL(cmdq_pkt_clear_event);
> >  
> > +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> > +		  u16 offset, u32 value, u32 mask)
> > +{
> > +	struct cmdq_instruction *inst;
> > +
> > +	if (mask != 0xffffffff) {
> 
> Is this necessary? Can't we just always set the mask, even if it's 0xffffffff?
> 
> Regarding interfaces, depending on how often you expect the mask being ~0 we
> might think of adding a cmdq_pkt_poll_mask call.
> What I want to say, if in the end most of the callers will use the mask with
> 0xffffffff, then we should add a call cmdq_pkt_poll_mask which actually allows
> to set the mask and let cmdq_pkt_poll set the mask in it's function body.
> As I already said, this depends on how often you think a caller will use/not-use
> the mask.
> Does this make sense?

It's better to have two function: cmdq_pkt_poll_mask and cmdq_pkt_poll,
client can choose which they need by themselves.

Thanks for the comments.

Bibby
> > +		inst = cmdq_pkt_append_command(pkt);
> > +		if (!inst)
> > +			return -ENOMEM;
> > +
> > +		inst->op = CMDQ_CODE_MASK;
> > +		inst->value = ~mask;
> > +		offset = offset | 0x1;
> > +	}
> > +
> > +	inst = cmdq_pkt_append_command(pkt);
> > +	if (!inst)
> > +		return -ENOMEM;
> > +
> > +	inst->op = CMDQ_CODE_POLL;
> > +	inst->value = value;
> > +	inst->offset = offset;
> > +	inst->subsys = subsys;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_pkt_poll);
> > +
> >  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >  {
> >  	struct cmdq_instruction *inst;
> > diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > index c8adedefaf42..9e3502945bc1 100644
> > --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> > +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> > @@ -46,6 +46,7 @@
> >  enum cmdq_code {
> >  	CMDQ_CODE_MASK = 0x02,
> >  	CMDQ_CODE_WRITE = 0x04,
> > +	CMDQ_CODE_POLL = 0x08,
> >  	CMDQ_CODE_JUMP = 0x10,
> >  	CMDQ_CODE_WFE = 0x20,
> >  	CMDQ_CODE_EOC = 0x40,
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> > index 9618debb9ceb..a345870a6d10 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> >   */
> >  int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
> >  
> > +/**
> > + * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> > + *		     execute an instruction that wait for a specified hardware
> > + *		     register to check for the value. All GCE hardware
> > + *		     threads will be blocked by this instruction.
> > + * @pkt:	the CMDQ packet
> > + * @subsys:	the CMDQ sub system code
> > + * @offset:	register offset from CMDQ sub system
> > + * @value:	the specified target register value
> > + * @mask:	the specified target register mask
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + */
> > +int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> > +		  u16 offset, u32 value, u32 mask);
> >  /**
> >   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> >   *                          packet and call back at the end of done packet
> > 




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RESEND, PATCH v13 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-08-27  3:59 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
	Daoyuan Huang, Sascha Hauer, Jassi Brar, linux-kernel,
	Daniel Kurtz, Dennis-YC Hsieh, YT Shen, Rob Herring,
	linux-mediatek, Houlong Wei, Sascha Hauer, CK HU, Jiaguang Zhang,
	linux-arm-kernel, ginny.chen
In-Reply-To: <ccd3782e-b1bb-7887-f4a5-d7774183c7b7@gmail.com>

On Fri, 2019-08-23 at 16:21 +0200, Matthias Brugger wrote:
> 
> On 20/08/2019 10:49, Bibby Hsieh wrote:
> > GCE cannot know the register base address, this function
> > can help cmdq client to get the cmdq_client_reg structure.
> > 
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> >  drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
> >  include/linux/soc/mediatek/mtk-cmdq.h  | 21 +++++++++++++++++++
> >  2 files changed, 50 insertions(+)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index c53f8476c68d..80f75a1075b4 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -27,6 +27,35 @@ struct cmdq_instruction {
> >  	u8 op;
> >  };
> >  
> > +int cmdq_dev_get_client_reg(struct device *dev,
> > +			    struct cmdq_client_reg *client_reg, int idx)
> > +{
> 
> Can't we do/call this in cmdq_mbox_create parsing the number of gce-client-reg
> properties we have and allocating these using a pointer to cmdq_client_reg in
> cmdq_client?
> We will have to free the pointer then in cmdq_mbox_destroy.
> 
> Regards,
> Matthias

I don't think we need to keep the cmdq_client_reg in cmdq_client
structure.
Because our client will have own data structure, they will copy the
client_reg information into their own structure.

In the design now, we do not allocate the cmdq_client_reg, client pass
the cmdq_client_reg pointer into this API.
Client will destroy the pointer after they get the information they
want.

Thanks for the comments so much.

Bibby

> 
> > +	struct of_phandle_args spec;
> > +	int err;
> > +
> > +	if (!client_reg)
> > +		return -ENOENT;
> > +
> > +	err = of_parse_phandle_with_fixed_args(dev->of_node,
> > +					       "mediatek,gce-client-reg",
> > +					       3, idx, &spec);
> > +	if (err < 0) {
> > +		dev_err(dev,
> > +			"error %d can't parse gce-client-reg property (%d)",
> > +			err, idx);
> > +
> > +		return err;
> > +	}
> > +
> > +	client_reg->subsys = (u8)spec.args[0];
> > +	client_reg->offset = (u16)spec.args[1];
> > +	client_reg->size = (u16)spec.args[2];
> > +	of_node_put(spec.np);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> > +
> >  static void cmdq_client_timeout(struct timer_list *t)
> >  {
> >  	struct cmdq_client *client = from_timer(client, t, timer);
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> > index a345870a6d10..02ddd60b212f 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -15,6 +15,12 @@
> >  
> >  struct cmdq_pkt;
> >  
> > +struct cmdq_client_reg {
> > +	u8 subsys;
> > +	u16 offset;
> > +	u16 size;
> > +};
> > +
> >  struct cmdq_client {
> >  	spinlock_t lock;
> >  	u32 pkt_cnt;
> > @@ -24,6 +30,21 @@ struct cmdq_client {
> >  	u32 timeout_ms; /* in unit of microsecond */
> >  };
> >  
> > +/**
> > + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> > + *			       node of CMDQ client
> > + * @dev:	device of CMDQ mailbox client
> > + * @client_reg: CMDQ client reg pointer
> > + * @idx:	the index of desired reg
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + *
> > + * Help CMDQ client parsing the cmdq client reg
> > + * from the device node of CMDQ client.
> > + */
> > +int cmdq_dev_get_client_reg(struct device *dev,
> > +			    struct cmdq_client_reg *client_reg, int idx);
> > +
> >  /**
> >   * cmdq_mbox_create() - create CMDQ mailbox client and channel
> >   * @dev:	device of CMDQ mailbox client
> > 



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] ASoC: imx-audmix: register the card on a proper dev
From: Shengjiu Wang @ 2019-08-27 15:55 UTC (permalink / raw)
  To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, lgirdwood,
	perex, tiwai, shawnguo, s.hauer, kernel, alsa-devel, viorel.suman
  Cc: linuxppc-dev, linux-imx, linux-arm-kernel, linux-kernel

This platform device is registered from "fsl_audmix", which is
its parent device. If use pdev->dev.parent for the priv->card.dev,
the value set by dev_set_drvdata in parent device will be covered
by the value in child device.

Fixes: b86ef5367761 ("ASoC: fsl: Add Audio Mixer machine driver")
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
 sound/soc/fsl/imx-audmix.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 9e1cb18859ce..71590ca6394b 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -325,14 +325,14 @@ static int imx_audmix_probe(struct platform_device *pdev)
 	priv->card.num_configs = priv->num_dai_conf;
 	priv->card.dapm_routes = priv->dapm_routes;
 	priv->card.num_dapm_routes = priv->num_dapm_routes;
-	priv->card.dev = pdev->dev.parent;
+	priv->card.dev = &pdev->dev;
 	priv->card.owner = THIS_MODULE;
 	priv->card.name = "imx-audmix";
 
 	platform_set_drvdata(pdev, &priv->card);
 	snd_soc_card_set_drvdata(&priv->card, priv);
 
-	ret = devm_snd_soc_register_card(pdev->dev.parent, &priv->card);
+	ret = devm_snd_soc_register_card(&pdev->dev, &priv->card);
 	if (ret) {
 		dev_err(&pdev->dev, "snd_soc_register_card failed\n");
 		return ret;
-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [GIT PULL] SOC: TI soc updates for 5.4
From: Santosh Shilimkar @ 2019-08-27  3:11 UTC (permalink / raw)
  To: arm, linux-arm-kernel
  Cc: olof, santosh.shilimkar, linux-kernel, arnd, khilman

The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:

  Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.4

for you to fetch changes up to 23013399a2252e9f592c2c52a62b213d3ef09217:

  soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access (2019-08-26 20:00:41 -0700)

----------------------------------------------------------------
soc: TI soc updates for 5.4

 -  Update firmware to support PM domain shared and exclusive support
 -  Update driver and dt binding docs for the same.

----------------------------------------------------------------

Lokesh Vutla (3):
  firmware: ti_sci: Allow for device shared and exclusive requests
  dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
    access
  soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
    access

 .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 11 +++++-
 MAINTAINERS                                        |  1 +
 drivers/firmware/ti_sci.c                          | 45 +++++++++++++++++++++-
 drivers/soc/ti/ti_sci_pm_domains.c                 | 23 ++++++++++-
 include/dt-bindings/soc/ti,sci_pm_domain.h         |  9 +++++
 include/linux/soc/ti/ti_sci_protocol.h             |  3 ++
 6 files changed, 86 insertions(+), 6 deletions(-)
 create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h

-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox