* 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
* [PATCH V7 3/3] MAINTAINERS: add imx8 ddr perf admin-guide maintainer information
From: Joakim Zhang @ 2019-08-27 2:39 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190827023557.7071-1-qiangqing.zhang@nxp.com>
Add imx8 ddr perf admin-guide maintainer information.
ChangeLog:
V1 -> V5:
* new add in V5.
V5 -> V6:
* no change.
V6 -> V7:
* no change.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e60f5c361969..2ba378e806c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6462,6 +6462,7 @@ M: Frank Li <Frank.li@nxp.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
F: drivers/perf/fsl_imx8_ddr_perf.c
+F: Documentation/admin-guide/perf/imx-ddr.rst
F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
FREESCALE IMX LPI2C DRIVER
--
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
* [PATCH V7 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Joakim Zhang @ 2019-08-27 2:39 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190827023557.7071-1-qiangqing.zhang@nxp.com>
Add i.MX8 ddr pmu user doc.
ChangeLog:
V1 -> V4:
* new add in V4.
V4 -> V5:
* no change.
V5 -> V6:
* change the event name
V6 -> V7:
* no change.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
Documentation/admin-guide/perf/imx-ddr.rst | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
new file mode 100644
index 000000000000..2540a4d1417b
--- /dev/null
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -0,0 +1,30 @@
+====================================================
+Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
+====================================================
+
+There are no performance counters inside the DRAM controller, so performance
+signals are brought out to the edge of the controller where a set of 4 x 32 bit
+counters is implemented. This is controlled by the Performance log on parameter
+which causes a large number of PERF signals to be generated.
+
+Selection of the value for each counter is done via the config registiers. There
+is one register for each counter. Counter 0 is special in that it always counts
+“time” and when expired causes a lock on itself and the other counters and an
+interrupt ie enable of counter 0 is a global function.
+
+The "format" directory describes format of the config (event ID) and config1
+(AXI ID filter) fields of the perf_event_attr structure, see /sys/bus/event_source/
+devices/imx8_ddr0/format/. The "events" directory describes the events types
+hardware supported that can be used with perf tool, see /sys/bus/event_source/
+devices/imx8_ddr0/events/.
+
+AXI ID filter is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write)
+to count reading or writing matches filter setting. User should specify this two
+events with the same AXI ID filter value if want to count at the same time, as
+this filter register is shared between counters.
+
+Example for perf tool use::
+
+ perf stat -a -e imx8_ddr0/cycles/ cmd
+ perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd
+ perf stat -a -e imx8_ddr0/axid-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axid-write,axi_id=0xMMMMDDDD/ cmd
--
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
* [PATCH V7 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-27 2:39 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
writes with an ARID or AWID matching filter setting. Granularity is at
subsystem level. Implementation does not allow filtring between masters
within a subsystem. Filter is defined with 2 configuration parameters.
--AXI_ID defines AxID matching value
--AXI_MASKING defines which bits of AxID are meaningful for the matching
0：corresponding bit is masked
1: corresponding bit is not masked, i.e. used to do the matching
When non-masked bits are matching corresponding AXI_ID bits then counter
is incremented. This filter allows counting read or write access from a
subsystem or multiple subsystems.
Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
Read and write AXI ID filter should write same value to DPCR1 if want to
specify at the same time as this filter is shared between counters.
e.g.
perf stat -a -e imx8_ddr0/axid-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axid-write,axi_id=0xMMMMDDDD/ cmd
MMMM: AXI_MASKING DDDD: AXI_ID
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
NOTE: AXI_MASKING is inverted at driver(i.e. set bits are bits to mask), so
that the user can just specify axi_id to monitor a specific id, rather than
having to specify axi_id=0xffff<id>.
ChangeLog:
V1 -> V2:
* add error log if user specifies read/write AXI ID filter at
the same time.
* of_device_get_match_data() instead of of_match_device(), and
remove the check of return value.
V2 -> V3:
* move the AXI ID check to event_add().
* add support for same value of axi_id.
V3 -> V4:
* move the AXI ID check to event_init().
V4 -> V5:
* reject event group if AXI ID not consistent in event_init().
V5 -> V6:
* change the event name: axi-id-read->axid-read;
axi-id-write->axid-write
* add another helper: ddr_perf_filters_compatible()
* drop the dev_dbg()
V6 -> V7:
* revert AXI_MASKING at driver.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
drivers/perf/fsl_imx8_ddr_perf.c | 70 +++++++++++++++++++++++++++++++-
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 0e3310dbb145..ec2120fc3207 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -35,6 +35,8 @@
#define EVENT_CYCLES_COUNTER 0
#define NUM_COUNTERS 4
+#define AXI_MASKING_REVERT 0xffff0000 /* AXI_MASKING(MSB 16bits) + AXI_ID(LSB 16bits) */
+
#define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu)
#define DDR_PERF_DEV_NAME "imx8_ddr"
@@ -42,9 +44,22 @@
static DEFINE_IDA(ddr_ida);
+/* DDR Perf hardware feature */
+#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
+
+struct fsl_ddr_devtype_data {
+ unsigned int quirks; /* quirks needed for different DDR Perf core */
+};
+
+static const struct fsl_ddr_devtype_data imx8_devtype_data;
+
+static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
+ .quirks = DDR_CAP_AXI_ID_FILTER,
+};
+
static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
- { .compatible = "fsl,imx8-ddr-pmu",},
- { .compatible = "fsl,imx8m-ddr-pmu",},
+ { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
+ { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
@@ -58,6 +73,7 @@ struct ddr_pmu {
struct perf_event *events[NUM_COUNTERS];
int active_events;
enum cpuhp_state cpuhp_state;
+ const struct fsl_ddr_devtype_data *devtype_data;
int irq;
int id;
};
@@ -129,6 +145,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-read, 0x41),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-write, 0x42),
NULL,
};
@@ -138,9 +156,11 @@ static struct attribute_group ddr_perf_events_attr_group = {
};
PMU_FORMAT_ATTR(event, "config:0-7");
+PMU_FORMAT_ATTR(axi_id, "config1:0-31");
static struct attribute *ddr_perf_format_attrs[] = {
&format_attr_event.attr,
+ &format_attr_axi_id.attr,
NULL,
};
@@ -190,6 +210,26 @@ static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter)
return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
}
+static bool ddr_perf_is_filtered(struct perf_event *event)
+{
+ return event->attr.config == 0x41 || event->attr.config == 0x42;
+}
+
+static u32 ddr_perf_filter_val(struct perf_event *event)
+{
+ return event->attr.config1;
+}
+
+static bool ddr_perf_filters_compatible(struct perf_event *a,
+ struct perf_event *b)
+{
+ if (!ddr_perf_is_filtered(a))
+ return true;
+ if (!ddr_perf_is_filtered(b))
+ return true;
+ return ddr_perf_filter_val(a) == ddr_perf_filter_val(b);
+}
+
static int ddr_perf_event_init(struct perf_event *event)
{
struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
@@ -216,6 +256,15 @@ static int ddr_perf_event_init(struct perf_event *event)
!is_software_event(event->group_leader))
return -EINVAL;
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ if (!ddr_perf_filters_compatible(event, event->group_leader))
+ return -EINVAL;
+ for_each_sibling_event(sibling, event->group_leader) {
+ if (!ddr_perf_filters_compatible(event, sibling))
+ return -EINVAL;
+ }
+ }
+
for_each_sibling_event(sibling, event->group_leader) {
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
@@ -288,6 +337,21 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
struct hw_perf_event *hwc = &event->hw;
int counter;
int cfg = event->attr.config;
+ int cfg1 = event->attr.config1;
+
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ int i;
+
+ for (i = 1; i < NUM_COUNTERS; i++) {
+ if (pmu->events[i] &&
+ !ddr_perf_filters_compatible(event, pmu->events[i]))
+ return -EINVAL;
+ }
+
+ /* revert axi_id masking value */
+ cfg1 ^= AXI_MASKING_REVERT;
+ writel(cfg1, pmu->base + COUNTER_DPCR1);
+ }
counter = ddr_perf_alloc_counter(pmu, cfg);
if (counter < 0) {
@@ -473,6 +537,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
if (!name)
return -ENOMEM;
+ pmu->devtype_data = of_device_get_match_data(&pdev->dev);
+
pmu->cpu = raw_smp_processor_id();
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
DDR_CPUHP_CB_NAME,
--
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 V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-27 2:15 UTC (permalink / raw)
To: Frank Li, Mark Rutland
Cc: will@kernel.org, robin.murphy@arm.com, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM6PR04MB49032FA7159DC8B2B96488DC88A10@AM6PR04MB4903.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Frank Li
> Sent: 2019年8月26日 23:37
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; Mark Rutland
> <mark.rutland@arm.com>
> Cc: robin.murphy@arm.com; will@kernel.org;
> linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
>
>
>
> > -----Original Message-----
> > From: Joakim Zhang
> > Sent: Monday, August 26, 2019 2:12 AM
> > To: Mark Rutland <mark.rutland@arm.com>
> > Cc: robin.murphy@arm.com; will@kernel.org; Frank Li
> > <frank.li@nxp.com>; linux-arm-kernel@lists.infradead.org; dl-linux-imx
> > <linux-imx@nxp.com>
> > Subject: RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter
> > support
> >
> >
> > > -----Original Message-----
> > > From: Mark Rutland <mark.rutland@arm.com>
> > > Sent: 2019年8月23日 20:57
> > > To: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > Cc: robin.murphy@arm.com; will@kernel.org; Frank Li
> > > <frank.li@nxp.com>; linux-arm-kernel@lists.infradead.org;
> > > dl-linux-imx <linux-imx@nxp.com>
> > > Subject: Re: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter
> > > support
> > >
> > > On Thu, Aug 08, 2019 at 06:45:29AM +0000, Joakim Zhang wrote:
> > > > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > > > writes with an ARID or AXID matching filter setting. Granularity
> > > > is at subsystem level. Implementation does not allow filtring
> > > > between masters within a subsystem. Filter is defined with 2
> configuration registers.
> > > >
> > > > --AXI_ID defines AxID matching value --AXI_MASKING defines which
> > > > bits of AxID are meaningful for the matching
> > > >
> > > > When non-masked bits are matching corresponding AXI_ID bits then
> > > > counter is incremented. This filter allows counting read or write
> > > > access from a subsystem or multiple subsystems.
> > > >
> > > > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > > > AXI_MASKING
> > >
> > > Just to check, the filter does not affect other events, right?
> >
> > [Joakim] Yes, this filter is only for events 0x41 and 0x42.
> >
> > > >
> > > > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> > > counter.
> > > >
> > > > Read and write AXI ID filter should write same value to DPCR1 if
> > > > want to specify at the same time as this filter is shared between
> counters.
> > > >
> > > > e.g.
> > > > perf stat -a -e
> > > >
> > >
> imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_
> > > id
> > > > =0xMMMMDDDD/ cmd
> > > > MMMM: AXI_MASKING
> > > > DDDD: AXI_ID
> > >
> > > You might want to expose this to userspace as two fields:
> > >
> > > axi_id=DDDD
> > > axi_mask=MMMM
> > >
> > > ... where axi_mask is inverted (i.e. set bits are bits to ignore),
> > > so that the user can just specify axi_id to monitor a specific id,
> > > rather than having to specifiy axi_id=0xffff<id>.
> >
> > [Joakim] No, axi_mask is not inverted, should specify axi_id =
> > 0xffff<id> for the particular AXI ID. I will improve the commit message.
> > 0: corresponding bit is masked
> > 1: corresponding bit is not masked, i.e. used to do the matching
> >
>
> [Frank Li] Joakim, mark's means is that revert it at your driver.
> Most case user just want to filter a AXID. For example 0x12
>
> If you revert mask at driver, user just need input axi_id = 0x12 instead of
> axi_id=0xffff0012.
[Joakim] Sorry for my misunderstanding, I will improve it in V7. Thanks.
>
> > > >
> > > > ChangeLog:
> > > > V1 -> V2:
> > > > * add error log if user specifies read/write AXI ID filter at
> > > > the same time.
> > > > * of_device_get_match_data() instead of of_match_device(), and
> > > > remove the check of return value.
> > > > V2 -> V3:
> > > > * move the AXI ID check to event_add().
> > > > * add support for same value of axi_id.
> > > > V3 -> V4:
> > > > * move the AXI ID check to event_init().
> > > > V4 -> V5:
> > > > * reject event group if AXI ID not consistent in event_init().
> > > >
> > > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > > ---
> > > > drivers/perf/fsl_imx8_ddr_perf.c | 63
> > > > +++++++++++++++++++++++++++++++-
> > > > 1 file changed, 61 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
> > > > b/drivers/perf/fsl_imx8_ddr_perf.c
> > > > index 63fe21600072..f25cf5cbe156 100644
> > > > --- a/drivers/perf/fsl_imx8_ddr_perf.c
> > > > +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> > > > @@ -42,9 +42,22 @@
> > > >
> > > > static DEFINE_IDA(ddr_ida);
> > > >
> > > > +/* DDR Perf hardware feature */
> > > > +#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter
> > */
> > > > +
> > > > +struct fsl_ddr_devtype_data {
> > > > + unsigned int quirks; /* quirks needed for different DDR Perf core */
> > > > +};
> > > > +
> > > > +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> > > > +
> > > > +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> > > > + .quirks = DDR_CAP_AXI_ID_FILTER, };
> > > > +
> > > > static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> > > > - { .compatible = "fsl,imx8-ddr-pmu",},
> > > > - { .compatible = "fsl,imx8m-ddr-pmu",},
> > > > + { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> > > > + { .compatible = "fsl,imx8m-ddr-pmu", .data =
> > > > +&imx8m_devtype_data},
> > > > { /* sentinel */ }
> > > > };
> > >
> > > Are new DDR PMUs going to lack this feature?
> > >
> > > If all PMUs the driver supports have it, then we don't need this
> > > quirk/feature list.
> > >
> > > That would make the subsequent code a bit nicer, as all the
> > > filtering code would lose a level of indentation.
> >
> > [Joakim] This feature may drop, some coming SOCs will improve this AXI
> > ID filtering, let it can filter from different ID separately, and ang other
> extensions.
> >
> > > >
> > > > @@ -57,6 +70,7 @@ struct ddr_pmu {
> > > > struct perf_event *events[NUM_COUNTERS];
> > > > int active_events;
> > > > enum cpuhp_state cpuhp_state;
> > > > + const struct fsl_ddr_devtype_data *devtype_data;
> > > > int irq;
> > > > int id;
> > > > };
> > > > @@ -128,6 +142,8 @@ static struct attribute *ddr_perf_events_attrs[] =
> {
> > > > IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> > > > IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> > > > IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> > > > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
> > > > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
> > > > NULL,
> > > > };
> > > >
> > > > @@ -137,9 +153,11 @@ static struct attribute_group
> > > > ddr_perf_events_attr_group = { };
> > > >
> > > > PMU_FORMAT_ATTR(event, "config:0-7");
> > > > +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
> > > >
> > > > static struct attribute *ddr_perf_format_attrs[] = {
> > > > &format_attr_event.attr,
> > > > + &format_attr_axi_id.attr,
> > > > NULL,
> > > > };
> > > >
> > > > @@ -189,6 +207,16 @@ static u32 ddr_perf_read_counter(struct
> > > > ddr_pmu
> > > *pmu, int counter)
> > > > return readl_relaxed(pmu->base + COUNTER_READ + counter *
> 4); }
> > > >
> > > > +static bool ddr_perf_is_filtered(struct perf_event *event) {
> > > > + return event->attr.config == 0x41 || event->attr.config == 0x42;
> > > > +}
> > > > +
> > > > +static u32 ddr_perf_filter_val(struct perf_event *event) {
> > > > + return event->attr.config1;
> > > > +}
> > > > +
> > >
> > > Let's add another helper:
> > >
> > > static bool ddr_perf_filters_compatible(struct perf_event *a,
> > > struct perf_event *b)
> > > {
> > > if (!ddr_perf_is_filtered(a))
> > > return true;
> > > if (!ddr_perf_is_filtered(b))
> > > return true;
> > > return ddr_perf_filter_val(a) == ddr_perf_filter_val(b); }
> > >
> > > > static int ddr_perf_event_init(struct perf_event *event) {
> > > > struct ddr_pmu *pmu = to_ddr_pmu(event->pmu); @@ -215,6
> +243,18
> > > @@
> > > > static int ddr_perf_event_init(struct perf_event *event)
> > > > !is_software_event(event->group_leader))
> > > > return -EINVAL;
> > > >
> > > > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > > + bool is_filtered = ddr_perf_is_filtered(event);
> > > > + u32 filter_val = ddr_perf_filter_val(event);
> > > > +
> > > > + for_each_sibling_event(sibling, event->group_leader) {
> > > > + if (is_filtered && ddr_perf_is_filtered(sibling) &&
> > > > + ddr_perf_filter_val(sibling) != filter_val) {
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > > > + }
> > >
> > > ... so this can be:
> > >
> > > if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > if (!ddr_perf_filters_compatible(event, event->group_leader))
> > > return -EINVAL;
> > > for_each_sibling_event(sibling, event->group_leader) {
> > > if (!ddr_perf_filters_compatible(event, sibling))
> > > return -EINVAL;
> > > }
> > > }
> >
> > [Joakim] Got it.
> >
> > > Note: that checks group_leader, which you mised above. When the
> > > event is the group leader, it's trivially compatible with itself, so
> > > we don't need a special case there.
> > >
> > > > +
> > > > for_each_sibling_event(sibling, event->group_leader) {
> > > > if (sibling->pmu != event->pmu &&
> > > > !is_software_event(sibling))
> > > > @@ -288,6 +328,23 @@ static int ddr_perf_event_add(struct
> > > > perf_event
> > > *event, int flags)
> > > > int counter;
> > > > int cfg = event->attr.config;
> > > >
> > > > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > > + int i;
> > > > + bool is_filtered = ddr_perf_is_filtered(event);
> > > > + u32 filter_val = ddr_perf_filter_val(event);
> > > > +
> > > > + for (i = 1; i < NUM_COUNTERS; i++) {
> > > > + if (is_filtered && pmu->events[i] &&
> > > > + ddr_perf_is_filtered(pmu->events[i]) &&
> > > > + ddr_perf_filter_val(pmu->events[i]) != filter_val) {
> > > > + dev_dbg(pmu->dev, "Contradictory axi id filter
> > value\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > >
> > > ... and likewise:
> > >
> > > if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > int i;
> > >
> > > for (i = 1; i < NUM_COUNTERS; i++) {
> > > if (!ddr_perf_filters_compatible(event, pmu->events[i]))
> > > return -EINVAL;
> > > }
> > > }
> > >
> > > Please drop the dev_dbg() here, since when perf rotates events this
> > > can happen many times per second, and it's entirely legitimate.
> >
> > [Joakim] Got it.
> >
> > > Otherwise, this looks good to me.
> >
> > [Joakim] Thanks Mark, I will sent out a V6, please help review.
> >
> > Best Regards,
> > Joakim Zhang
> > > Thanks,
> > > Mark.
> > >
> > > > +
> > > > + writel(filter_val, pmu->base + COUNTER_DPCR1);
> > > > + }
> > > > +
> > > > counter = ddr_perf_alloc_counter(pmu, cfg);
> > > > if (counter < 0) {
> > > > dev_dbg(pmu->dev, "There are not enough counters\n"); @@ -
> > 472,6
> > > > +529,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
> > > > if (!name)
> > > > return -ENOMEM;
> > > >
> > > > + pmu->devtype_data = of_device_get_match_data(&pdev->dev);
> > > > +
> > > > pmu->cpu = raw_smp_processor_id();
> > > > ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> > > > DDR_CPUHP_CB_NAME,
> > > > --
> > > > 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
* Re: CPUfreq fail on rk3399-firefly
From: Heiko Stuebner @ 2019-08-27 2:14 UTC (permalink / raw)
To: Kever Yang
Cc: kernel-build-reports, Kevin Hilman, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <852dd7d4-520b-7eb0-f307-c3fa9c0ebf2a@rock-chips.com>
Hi Kever,
Am Dienstag, 27. August 2019, 03:54:26 CEST schrieb Kever Yang:
> On 2019/8/27 上午1:09, Kevin Hilman wrote:
> > Kever Yang <kever.yang@rock-chips.com> writes:
> >> I want to have a test with my board, I can get the Image and dtb
> >> from the link for the job,
> >>
> >> but how can I get the randisk which is named initrd-SDbyy2.cpio.gz?
> > The ramdisk images are here:
> >
> > https://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02/arm64/base/
> >
> > in the kernelCI logs the ramdisk is slightly modified because the kernel
> > modules have been inserted into the cpio archive.
> >
> > However, for the purposes of this test, you can just test with the
> > unmodified rootfs.cpio.gz above.
>
>
> I try with this ramdisk, and it hangs at fan53555 init, but not get into
> cpufreq.
>
> Any suggestion?
My guess would be the fcs,suspend-voltage-selector maybe?
I.e. old uboots somehow set the voltage gpio strangely, so you'd need
fcs,suspend-voltage-selector = <0>
while newer uboots I think do configure the gpio, needing a value of <1>;
So try to swap that number in the dts perhaps for a start?
Heiko
> My boot log:
>
> https://paste.ubuntu.com/p/WYZKPWp7sk/
>
> Thanks,
>
> - Kever
>
> >
> > Kevin
> >
> >
> >> Thanks,
> >>
> >> - Kever
> >>
> >> On 2019/8/24 上午1:03, Kevin Hilman wrote:
> >>> Kevin Hilman <khilman@baylibre.com> writes:
> >>>
> >>>> Kever Yang <kever.yang@rock-chips.com> writes:
> >>>>
> >>>>> Hi Kevin, Heiko,
> >>>>>
> >>>>> On 2019/8/22 上午2:59, Kevin Hilman wrote:
> >>>>>> Hi Heiko,
> >>>>>>
> >>>>>> Heiko Stuebner <heiko@sntech.de> writes:
> >>>>>>
> >>>>>>> Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
> >>>>>>>> [ resent with correct addr for linux-rockchip list ]
> >>>>>>>>
> >>>>>>>> Mark Brown <broonie@kernel.org> writes:
> >>>>>>>>
> >>>>>>>>> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
> >>>>>>>>>
> >>>>>>>>> Today's -next started failing to boot defconfig on rk3399-firefly:
> >>>>>>>>>
> >>>>>>>>>> arm64:
> >>>>>>>>>> defconfig:
> >>>>>>>>>> gcc-8:
> >>>>>>>>>> rk3399-firefly: 1 failed lab
> >>>>>>>>> It hits a BUG() trying to set up cpufreq:
> >>>>>>>>>
> >>>>>>>>> [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
> >>>>>>>>> [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
> >>>>>>>>> [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
> >>>>>>>>> [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
> >>>>>>>>> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
> >>>>>>>>> [ 87.495335] ------------[ cut here ]------------
> >>>>>>>>> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
> >>>>>>>>> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> >>>>>>>>>
> >>>>>>>>> I'm struggling to see anything relevant in the diff from yesterday, the
> >>>>>>>>> unlisted frequency warnings were there in the logs yesterday but no oops
> >>>>>>>>> and I'm not seeing any changes in cpufreq, clk or anything relevant
> >>>>>>>>> looking.
> >>>>>>>>>
> >>>>>>>>> Full bootlog and other info can be found here:
> >>>>>>>>>
> >>>>>>>>> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
> >>>>>>>> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
> >>>>>>>> makes the firefly board start working again.
> >>>>>>>>
> >>>>>>>> Note that the default defconfig enables the "performance" CPUfreq
> >>>>>>>> governor as the default governor, so during kernel boot, it will always
> >>>>>>>> switch to the max frequency.
> >>>>>>>>
> >>>>>>>> For fun, I set the default governor to "userspace" so the kernel
> >>>>>>>> wouldn't make any OPP changes, and that leads to a slightly more
> >>>>>>>> informative splat[1]
> >>>>>>>>
> >>>>>>>> There is still an OPP change happening because the detected OPP is not
> >>>>>>>> one that's listed in the table, so it tries to change to a listed OPP
> >>>>>>>> and fails in the bowels of clk_set_rate()
> >>>>>>> Though I think that might only be a symptom as well.
> >>>>>>> Both the PLL setting code as well as the actual cpu-clock implementation
> >>>>>>> is unchanged since 2017 (and runs just fine on all boards in my farm).
> >>>>>>>
> >>>>>>> One source for these issues is often the regulator supplying the cpu
> >>>>>>> going haywire - aka the voltage not matching the opp.
> >>>>>>>
> >>>>>>> As in this error-case it's CPU4 being set, this would mean it might
> >>>>>>> be the big cluster supplied by the external syr825 (fan5355 clone)
> >>>>>>> that might act up. In the Firefly-rk3399 case this is even stranger.
> >>>>>>>
> >>>>>>> There is a discrepancy between the "fcs,suspend-voltage-selector"
> >>>>>>> between different bootloader versions (how the selection-pin is set up),
> >>>>>>> so the kernel might actually write his requested voltage to the wrong
> >>>>>>> register (not the one for actual voltage, but the second set used for
> >>>>>>> the suspend voltage).
> >>>>>>>
> >>>>>>> Did you by chance swap bootloaders at some point in recent past?
> >>>>>> No, haven't touched bootloader since I initially setup the board.
> >>>>> The CPU voltage does not affect by bootloader for kernel should have its
> >>>>> own opp-table,
> >>>>>
> >>>>> the bootloader may only affect the center/logic power supply.
> >>>>>
> >>>>>>> I'd assume [2] might actually be the same issue last year, though
> >>>>>>> the CI-logs are not available anymore it seems.
> >>>>>>>
> >>>>>>> Could you try to set the vdd_cpu_b regulator to disabled, so that
> >>>>>>> cpufreq for this cluster defers and see what happens?
> >>>>>> Yes, this change[1] definitely makes things boot reliably again, so
> >>>>>> there's defintiely something a bit unstable with this regulator, at
> >>>>>> least on this firefly.
> >>>>> Is it possible to target which patch introduce this bug? This board
> >>>>> should have work correctly for a long time with upstream source code.
> >>>> Unfortunately, it seems to be a regular, but intermittent failure, so
> >>>> bisection is not producing anything reliable.
> >>>>
> >>>> You can see that both in mainline[1] and in linux-next[2] there are
> >>>> periodic failures, but it's hard to see any patterns.
> >>> Even worse, I (re)tested mainline for versions that were previously
> >>> passing (v5.2, v5.3-rc5) and they are also failing now.
> >>>
> >>> They work again if I disable that regulator as suggested by Heiko.
> >>>
> >>> So this is increasingly pointing to failing hardware.
> >>>
> >>> Kevin
> >>>
> >>>
> >>>
> >
> >
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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