* 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: [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] 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: 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 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: [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 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
* [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] 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 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 -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
* 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] 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 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 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 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 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 v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Christoph Hellwig @ 2019-08-27 7:50 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Max Filippov, Christoph Hellwig,
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,
Robin Murphy, linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim,
David Woodhouse
In-Reply-To: <CAK7LNATYOLEboUTO4qPx2z7cqwDrHBO1HFHG8VzZEJ15STv+nw@mail.gmail.com>
On Tue, Aug 27, 2019 at 04:45:20PM +0900, Masahiro Yamada wrote:
> 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.
So it seems like the device wants CMA memory. I guess the patch
below will fix it, but that isn't the solution. Can you try it
to confirm? In the end it probably assumes a dma mask it doesn't
set that the CMA memory satisfies or something similar.
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 69cfb4345388..bd2f24aa7f19 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -236,7 +236,7 @@ struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
if (dev && dev->cma_area)
cma = dev->cma_area;
- else if (count > 1)
+ else
cma = dma_contiguous_default_area;
/* CMA can be used only in the context which permits sleeping */
_______________________________________________
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 0/3] CP115 pinctrl support
From: Linus Walleij @ 2019-08-27 7:50 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: <20190824133317.371dec4f@xps13>
On Sat, Aug 24, 2019 at 1:33 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Linus Walleij <linus.walleij@linaro.org> wrote on Thu, 15 Aug 2019
> > OK then maybe I am a bit impatient.
>
> Actually Gregory is on vacation until September, so if we still are in
> time for this merge window I suppose you can take it.
OK I applied the patches.
If someone is upset we can always revert them in the -rc phase.
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] input: keyboard: snvs_pwrkey: Send press and release event for i.MX6 S,DL and Q
From: robin @ 2019-08-27 7:55 UTC (permalink / raw)
To: Robin Gong
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer,
Dmitry Torokhov, linux-kernel, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input, Adam Ford, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <VE1PR04MB6638754916357F551502102589A00@VE1PR04MB6638.eurprd04.prod.outlook.com>
On 2019-08-27 08:17, Robin Gong wrote:
> 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.
ACK
>>
>> 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.
ACK
>
>>
>> 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.
I placed it here to avoid the unnessesairy debounce delay (since thats
already
implemented in hardware).
I do agree with your arguments so I'll move emitting the events to
imx_imx_snvs_check_for_events().
Is it ok if I keep the conditional, but instead of emitting the events,
schedule imx_imx_snvs_check_for_events() immidiatly to avoid the
debounce,
or should I choose clarity over the 30 ms delay?
>> + } 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?
I added an enum 'imx_snvs_hwtype' that defines both IMX6SX_SNVS and
IMX6QDL_SNVS.
>> + },
>> + { /* 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: Chen-Yu Tsai @ 2019-08-27 8:01 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: <CAEKpxBmCg4AkqKM-O3C76gto+mPWyEdDbviAmRJ8PxLOOMTJ7w@mail.gmail.com>
On Tue, Aug 27, 2019 at 1:55 PM Code Kipper <codekipper@gmail.com> wrote:
>
> 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
There are a total of four I2S controllers on the A83T. Currently three of them
are listed in the dtsi file, which are _not_ the one shown in the user manual.
The one shown is the fourth one, which is the TDM controller.
It's not like we haven't seen this before. IIRC the A64 also had two variants
of the I2S interface. The one coupled with the audio codec was different from
the others.
> 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.
I'll sync up with Maxime on this.
> >
> > 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
Since they haven't listed the I2S block in the user manual, so that is what we
have to go by.
The TDM section in the user manual only lists the block at 0x1c23000. The memory
map says DAUDIO-[012] for addresses 0x1c22000, 0x1c22400, 0x1c22800, and TDM for
address 0x1c23000. One would assume this meant these are somewhat different.
> I2S. The biggest use case for this block is getting HDMI audio working
> on the newer
I understand that.
> 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.
Tested on the H3, correct?
> Failing that reverting (3e9acd7ac693: "ASoC: sun4i-i2s: Remove
> duplicated quirks structure")
> would help.
I'll take a look. IIRC it worked with the old layout, with the two registers
swapped, playing standard 48 KHz / 16 bit audio when I added supported for
the A83T. Then again maybe the stars were perfectly aligned. At the very least
we could separate A83T and H3 as you suggested.
ChenYu
> 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.
>
> --
> 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/CAEKpxBmCg4AkqKM-O3C76gto%2BmPWyEdDbviAmRJ8PxLOOMTJ7w%40mail.gmail.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 v1 0/6] Allow kexec reboot for GICv3 and device tree
From: Marc Zyngier @ 2019-08-27 8:15 UTC (permalink / raw)
To: Pavel Tatashin
Cc: Sasha Levin, Mark Rutland, Vladimir Murzin, kexec mailing list,
James Morris, LKML, James Morse, Linux ARM
In-Reply-To: <CA+CK2bAS-jDwY-qKfZQD8TbvyAhS1+rBvcxGqkR4BHd5NR5BGQ@mail.gmail.com>
On 26/08/2019 22:25, Pavel Tatashin wrote:
> On Mon, Aug 26, 2019 at 3:13 PM Marc Zyngier <maz@kernel.org> wrote:
>>
>> On Mon, 26 Aug 2019 15:00:50 -0400
>> Pavel Tatashin <pasha.tatashin@soleen.com> wrote:
>>
>>> Marc Zyngier added the support for kexec and GICv3 for EFI based systems.
>>> However, it is still not possible todo on systems with device trees.
>>>
>>> Here is EFI fixes from Marc:
>>> https://lore.kernel.org/lkml/20180921195954.21574-1-marc.zyngier@arm.com
>>>
>>> For Device Tree variant: lets allow reserve a memory region in interrupt
>>> controller node, and use this property to allocate interrupt tables.
>>
>> There is no such thing as a "device tree variant". As long as your
>> bootloader implements EFI, everything will work correctly, whether
>> you're using DT, ACPI, or the anything else.
>>
>> This already works today, without any need to add anything to the
>> kernel (I have systems using EDK II and u-boot, both implementing EFI,
>> and I'm able to kexec without any issue). If your bootloader doesn't
>> support EFI, here's a good opportunity to implement it!
>
> Hi Marc,
>
> Thank you very much for looking at this work.
>
> Running Linux without EFI is common, and there are scenarios which
> make it appropriate. As I understand most of embedded linux do not
> have EFI enabled, and thus I do not see a reason why we would not
> support a first class feature of Linux (kexec) on non-EFI bootloaders.
Define "most". All the arm64 systems I have around (and trust me, that's
quite a number of them) can either use u-boot, which has more than
enough EFI support to use this functionality, or use EDK-II natively.
> We (Microsoft) have a small highly secure device with a high uptime
> requirement. The device also has PCIe and thus GICv3. The update for
PCIe doesn't imply GICv3 at all.
> this device relies on kexec. For a number of reasons, it was decided
> to use U-Boot and Linux without EFI enabled. One of those reasons is
> to improve boot performance, enabling EFI in U-Boot alone reduces the
> boot performance by half a second. Our total reboot budget is under a
> second which makes that half a second unacceptable. Also, adding EFI
> support to kernel increases its size and there are security
> implications from enabling more code both in U-Boot and Linux.
You're are missing the point. kexec with EFI has 0 overhead (no
non-kernel EFI code gets executed), doesn't impact your time budget, and
only relies on a single in-memory table. This can be pretty trivially
provided by the dumbest EFI shim.
All you are describing above is a set of self imposed limitations in
your bootloader, which you are fully in control of. So instead of
reinventing a square wheel, I suggest you adopt the existing implementation.
Another reason not to do this is interoperability: I want to be able to
kexec whatever Linux kernel I want, without having to cope with all
flavours of the same functionality. Effectively, the EFI table is a
private ABI between two Linux kernels. We're not changing it.
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: imx: lpcg: write twice when writing lpcg regs
From: Peng Fan @ 2019-08-27 8:17 UTC (permalink / raw)
To: mturquette@baylibre.com, sboyd@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, festevam@gmail.com, Aisheng Dong
Cc: Peng Fan, Abel Vesa, Anson Huang, linux-kernel@vger.kernel.org,
dl-linux-imx, kernel@pengutronix.de, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jacky Bai
From: Peng Fan <peng.fan@nxp.com>
There is hardware issue that:
The output clock the LPCG cell will not turn back on as expected,
even though a read of the IPG registers in the LPCG indicates that
the clock should be enabled.
The software workaround is to write twice to enable the LPCG clock
output.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/clk/imx/clk-lpcg-scu.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/imx/clk-lpcg-scu.c b/drivers/clk/imx/clk-lpcg-scu.c
index a73a799fb777..7391d0668ec4 100644
--- a/drivers/clk/imx/clk-lpcg-scu.c
+++ b/drivers/clk/imx/clk-lpcg-scu.c
@@ -54,6 +54,11 @@ static int clk_lpcg_scu_enable(struct clk_hw *hw)
reg |= val << clk->bit_idx;
writel(reg, clk->reg);
+ /*
+ * There is hardware bug. When enabling the LPCG clock
+ * output, SW can write the enabling value twice
+ */
+ writel(reg, clk->reg);
spin_unlock_irqrestore(&imx_lpcg_scu_lock, flags);
@@ -71,6 +76,11 @@ static void clk_lpcg_scu_disable(struct clk_hw *hw)
reg = readl_relaxed(clk->reg);
reg &= ~(CLK_GATE_SCU_LPCG_MASK << clk->bit_idx);
writel(reg, clk->reg);
+ /*
+ * There is hardware bug. When enabling the LPCG clock
+ * output, SW can write the enabling value twice
+ */
+ writel(reg, clk->reg);
spin_unlock_irqrestore(&imx_lpcg_scu_lock, flags);
}
--
2.16.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 00/21] ASoC: sun4i-i2s: Number of fixes and TDM Support
From: Chen-Yu Tsai @ 2019-08-27 8:20 UTC (permalink / raw)
To: Maxime Ripard, Mark Brown
Cc: Code Kipper, Linux-ALSA, Liam Girdwood, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.e08aa7e33afe117e1fa8f017119d465d47c98016.1566242458.git-series.maxime.ripard@bootlin.com>
Hi everyone,
On Tue, Aug 20, 2019 at 3:25 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Hi,
>
> This series aims at fixing a number of issues in the current i2s driver,
> mostly related to the i2s master support and the A83t support. It also uses
> that occasion to cleanup a few things and simplify the driver. Finally, it
> builds on those fixes and cleanups to introduce TDM and DSP formats support.
>
> Let me know what you think,
> Maxime
>
> Marcus Cooper (1):
> ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs
>
> Maxime Ripard (20):
> ASoC: sun4i-i2s: Register regmap and PCM before our component
> ASoC: sun4i-i2s: Switch to devm for PCM register
> ASoC: sun4i-i2s: Replace call to params_channels by local variable
> ASoC: sun4i-i2s: Move the channel configuration to a callback
> ASoC: sun4i-i2s: Move the format configuration to a callback
> ASoC: sun4i-i2s: Rework MCLK divider calculation
> ASoC: sun4i-i2s: Don't use the oversample to calculate BCLK
> ASoC: sun4i-i2s: Use module clock as BCLK parent on newer SoCs
> ASoC: sun4i-i2s: RX and TX counter registers are swapped
> ASoC: sun4i-i2s: Use the actual format width instead of an hardcoded one
> ASoC: sun4i-i2s: Fix LRCK and BCLK polarity offsets on newer SoCs
> ASoC: sun4i-i2s: Fix the LRCK polarity
> ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t
> ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t
> ASoC: sun4i-i2s: Fix the LRCK period on A83t
> ASoC: sun4i-i2s: Remove duplicated quirks structure
Unfortunately the patches that "fix" support on the A83T actually break it.
The confusion stems from the user manual not actually documenting the I2S
controller. Instead it documents the TDM controller, which is very similar
or the same as the I2S controller in the H3. The I2S controller that we
actually support in this driver is not the TDM controller, but three other
I2S controllers that are only mentioned in the memory map. Support for this
was done by referencing the BSP kernel, which has separate driver instances
for each controller instance, both I2S and TDM.
Now to remedy this I could send reverts for all the "A83t" patches, and
fixes for all the others that affect the A83t quirks. However the fixes
tags existing in the tree would be wrong and confusing. That might be a
pain for the stable kernel maintainers.
Any suggestions on how to proceed?
Regards
ChenYu
> ASoC: sun4i-i2s: Pass the channels number as an argument
> ASoC: sun4i-i2s: Support more channels
> ASoC: sun4i-i2s: Add support for TDM slots
> ASoC: sun4i-i2s: Add support for DSP formats
>
> sound/soc/sunxi/sun4i-i2s.c | 660 ++++++++++++++++++++-----------------
> 1 file changed, 372 insertions(+), 288 deletions(-)
>
> base-commit: d45331b00ddb179e291766617259261c112db872
> --
> git-series 0.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
* Re: [PATCH 5/9] block: support diskcipher
From: boojin.kim @ 2019-08-27 8:33 UTC (permalink / raw)
To: 'Satya Tangirala'
Cc: 'Ulf Hansson', 'Mike Snitzer', dm-devel,
'Andreas Dilger', 'Alasdair Kergon',
'Eric Biggers', linux-samsung-soc, 'Herbert Xu',
'Krzysztof Kozlowski', 'Jaehoon Chung',
'Kukjin Kim', linux-ext4, 'Chao Yu', linux-block,
linux-fscrypt, 'Jaegeuk Kim', linux-arm-kernel,
'Jens Axboe', 'Theodore Ts'o', linux-mmc,
linux-kernel, linux-f2fs-devel, linux-crypto, linux-fsdevel,
'David S. Miller'
In-Reply-To: <CGME20190827083334epcas2p115d479190b9a72c886f66569add78203@epcas2p1.samsung.com>
On Wed, Aug 21, 2019 at 5:10 AM Satya Tangirala <satyat@kernel.dk> wrote:
>
> Hi Boojin,
>
> We're very keen to make sure that our approach to inline encryption can
> work with diverse hardware, including Samsung's FMP hardware; if you
> can see any issues with using our approach with your hardware please
> let us know.
>
> We understand that a possible concern for getting FMP working with our
> patch series for Inline Encryption Support at
>
>
https://lore.kernel.org/linux-block/20190821075714.65140-1-satyat@google.com
/
>
> is that unlike some inline encryption hardware (and also unlike the JEDEC
> UFS v2.1 spec), FMP doesn't have the concept of a limited number of
> keyslots - to address that difference we have a "passthrough keyslot
> manager", which we put up on top of our patch series for inline encryption
> support at
>
> https://android-review.googlesource.com/c/kernel/common/+/980137/2
>
> Setting up a passthrough keyslot manager in the request queue of a
> device allows the device to receive a bio's encryption context as-is with
> the bio, which is what FMP would prefer. Are there any issues with
> using the passthrough keyslot manager for FMP?
>
> Thanks!
> Satya
Dear Satya.
Keyslot manager is a good solution for ICE. And probably no issue for FMP.
But, I think it's complicated for FMP because FMP doesn't need
any keyslot control.
Crypto API that FMP's using is simply, stable, and supports test.
FMP has been mass producing and certificating using crypto APIs
for several years.
So I wants to keep our current crypto API solution.
But, I'm looking at your patch. And I will keep examining at your patch
because our goal is to run the FMP on the mainline kernel.
Thanks for your reply.
Boojin Kim.
_______________________________________________
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