* 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
* Re: [linux-sunxi] [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: Code Kipper @ 2019-08-27 8:35 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: <CAGb2v64VNZ0oyD_760uNccwJb7MKngSooWB72M+d1DfT4-djog@mail.gmail.com>
On Tue, 27 Aug 2019 at 10:01, Chen-Yu Tsai <wens@csie.org> wrote:
>
> 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.
The configuration for the A83T suggests that it's a mixture of old and
new which I don't
think is the case considering it was released around the same time as
the H3. There
is enough similarity between the blocks for it to still work. For
example on the H6
we referenced by mistake the H3 block and we still got audio (with
only slight distortion).
I would suggest to validate all of the i2s blocks we need to test
using the internal loopback
as that will also cover capture.
>
> 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.
Yes...but the i2s of the audio codec was documented in the audio codec
section. I've used
this device to ensure that I've not broken anything in the old block
with these new changes.
>
> > 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?
Yes....but only with the additional changes for multi-channel with my
LibreELEC build.
These changes I tested on my pine64 before pushing upstream.
>
> > 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.
Thanks,
CK
>
> 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 v6 3/3] ASoC: sun4i-i2s: Adjust LRCLK width
From: Code Kipper @ 2019-08-27 8:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: Linux-ALSA, linux-sunxi, linux-kernel, Liam Girdwood,
Andrea Venturi (pers), Chen-Yu Tsai, Mark Brown, linux-arm-kernel
In-Reply-To: <20190827070101.tastgcqvzrgv3kc5@flea>
On Tue, 27 Aug 2019 at 09:01, Maxime Ripard <mripard@kernel.org> wrote:
>
> 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?
Maybe....but I need a TDM test volunteer!,
CK
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.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 v3 01/10] KVM: arm64: Document PV-time interface
From: Christoffer Dall @ 2019-08-27 8:44 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190821153656.33429-2-steven.price@arm.com>
On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time" have not been fully agreed.
>
> User space can specify a reserved area of memory for the guest and
> inform KVM to populate the memory with information on time that the host
> kernel has stolen from the guest.
>
> A hypercall interface is provided for the guest to interrogate the
> hypervisor's support for this interface and the location of the shared
> memory structures.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>
> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
> new file mode 100644
> index 000000000000..1ceb118694e7
> --- /dev/null
> +++ b/Documentation/virt/kvm/arm/pvtime.txt
> @@ -0,0 +1,100 @@
> +Paravirtualized time support for arm64
> +======================================
> +
> +Arm specification DEN0057/A defined a standard for paravirtualised time
> +support for AArch64 guests:
> +
> +https://developer.arm.com/docs/den0057/a
> +
> +KVM/arm64 implements the stolen time part of this specification by providing
> +some hypervisor service calls to support a paravirtualized guest obtaining a
> +view of the amount of time stolen from its execution.
> +
> +Two new SMCCC compatible hypercalls are defined:
> +
> +PV_FEATURES 0xC5000020
> +PV_TIME_ST 0xC5000022
> +
> +These are only available in the SMC64/HVC64 calling convention as
> +paravirtualized time is not available to 32 bit Arm guests. The existence of
> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
> +mechanism before calling it.
> +
> +PV_FEATURES
> + Function ID: (uint32) : 0xC5000020
> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> + PV-time feature is supported by the hypervisor.
> +
> +PV_TIME_ST
> + Function ID: (uint32) : 0xC5000022
> + Return value: (int64) : IPA of the stolen time data structure for this
> + (V)CPU. On failure:
> + NOT_SUPPORTED (-1)
> +
> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> +with inner and outer write back caching attributes, in the inner shareable
> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> +meaningfully filled by the hypervisor (see structure below).
> +
> +PV_TIME_ST returns the structure for the calling VCPU.
> +
> +Stolen Time
> +-----------
> +
> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> +
> + Field | Byte Length | Byte Offset | Description
> + ----------- | ----------- | ----------- | --------------------------
> + Revision | 4 | 0 | Must be 0 for version 0.1
> + Attributes | 4 | 4 | Must be 0
> + Stolen time | 8 | 8 | Stolen time in unsigned
> + | | | nanoseconds indicating how
> + | | | much time this VCPU thread
> + | | | was involuntarily not
> + | | | running on a physical CPU.
> +
> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> +will be present within a reserved region of the normal memory given to the
> +guest. The guest should not attempt to write into this memory. There is a
> +structure per VCPU of the guest.
> +
> +User space interface
> +====================
> +
> +User space can request that KVM provide the paravirtualized time interface to
> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
> +
I feel it would be more consistent to have the details of this in
Documentation/virt/kvm/devices/arm-pv-time.txt and refer to this
document from here.
> + struct kvm_create_device pvtime_device = {
> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> + .attr = 0,
> + .flags = 0,
> + };
> +
> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> +
> +Creation of the device should be done after creating the vCPUs of the virtual
> +machine.
> +
> +The IPA of the structures must be given to KVM. This is the base address
> +of an array of stolen time structures (one for each VCPU). The base address
> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
> +multiple of PAGE_SIZE.
> +
> +The memory for these structures should be added to the guest in the usual
> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
> +
> +For example:
> +
> + struct kvm_dev_arm_st_region region = {
> + .gpa = <IPA of guest base address>,
> + .size = <size in bytes>
> + };
> +
> + struct kvm_device_attr st_base = {
> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
> + .attr = KVM_DEV_ARM_PV_TIME_ST,
> + .addr = (u64)®ion
> + };
> +
> + ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
> --
> 2.20.1
>
Thanks,
Christoffer
_______________________________________________
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: Pavel Tatashin @ 2019-08-27 8:53 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sasha Levin, Mark Rutland, Vladimir Murzin, kexec mailing list,
James Morris, LKML, James Morse, Linux ARM
In-Reply-To: <d7461fb3-0f6d-8abf-084d-ce0be1f1a18d@kernel.org>
> > 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.
OK. Is this the most common configuration in the embedded ARM64
devices currently deployed: phones, cameras, consoles, players, etc?
> > 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.
My impression was that without PCIe GICv3 is rarely used, and this
could be the reason why this problem is not seen outside of larger
machines which normally have EFI enabled.
>
> > 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.
Thanks, this makes sense that the Linux boot time won't be affected. I
have not tested how u-boot was affected, but was told 0.5 second
longer to start.
> 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.
I am not sure this analogy is correct, I do not think that non-EFI
enabled kernels became legacy.
> 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.
This is exactly the problem: by having this region defined in signed
DTB file we reduce the amount of communication between the kernels.
Passing modified EFI Table causes us to pass more information from the
first kernel indefinitely through updates. Thus, increases a chance
for a security compromise. We are not changing EFI ABI between
kernels, it will stay as is. All this code does is enables kernels
that do not have EFI table communication between them a way to do
kexec updates with reduced amount of data exchange.
Thank you,
Pasha
_______________________________________________
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 v3 01/10] KVM: arm64: Document PV-time interface
From: Christoffer Dall @ 2019-08-27 8:57 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190821153656.33429-2-steven.price@arm.com>
On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time" have not been fully agreed.
>
> User space can specify a reserved area of memory for the guest and
> inform KVM to populate the memory with information on time that the host
> kernel has stolen from the guest.
>
> A hypercall interface is provided for the guest to interrogate the
> hypervisor's support for this interface and the location of the shared
> memory structures.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>
> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
> new file mode 100644
> index 000000000000..1ceb118694e7
> --- /dev/null
> +++ b/Documentation/virt/kvm/arm/pvtime.txt
> @@ -0,0 +1,100 @@
> +Paravirtualized time support for arm64
> +======================================
> +
> +Arm specification DEN0057/A defined a standard for paravirtualised time
> +support for AArch64 guests:
> +
> +https://developer.arm.com/docs/den0057/a
> +
> +KVM/arm64 implements the stolen time part of this specification by providing
> +some hypervisor service calls to support a paravirtualized guest obtaining a
> +view of the amount of time stolen from its execution.
> +
> +Two new SMCCC compatible hypercalls are defined:
> +
> +PV_FEATURES 0xC5000020
> +PV_TIME_ST 0xC5000022
> +
> +These are only available in the SMC64/HVC64 calling convention as
> +paravirtualized time is not available to 32 bit Arm guests. The existence of
> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
> +mechanism before calling it.
> +
> +PV_FEATURES
> + Function ID: (uint32) : 0xC5000020
> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> + PV-time feature is supported by the hypervisor.
> +
> +PV_TIME_ST
> + Function ID: (uint32) : 0xC5000022
> + Return value: (int64) : IPA of the stolen time data structure for this
> + (V)CPU. On failure:
> + NOT_SUPPORTED (-1)
> +
> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> +with inner and outer write back caching attributes, in the inner shareable
> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> +meaningfully filled by the hypervisor (see structure below).
> +
> +PV_TIME_ST returns the structure for the calling VCPU.
> +
> +Stolen Time
> +-----------
> +
> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> +
> + Field | Byte Length | Byte Offset | Description
> + ----------- | ----------- | ----------- | --------------------------
> + Revision | 4 | 0 | Must be 0 for version 0.1
> + Attributes | 4 | 4 | Must be 0
> + Stolen time | 8 | 8 | Stolen time in unsigned
> + | | | nanoseconds indicating how
> + | | | much time this VCPU thread
> + | | | was involuntarily not
> + | | | running on a physical CPU.
> +
> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> +will be present within a reserved region of the normal memory given to the
> +guest. The guest should not attempt to write into this memory. There is a
> +structure per VCPU of the guest.
> +
> +User space interface
> +====================
> +
> +User space can request that KVM provide the paravirtualized time interface to
> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
> +
> + struct kvm_create_device pvtime_device = {
> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> + .attr = 0,
> + .flags = 0,
> + };
> +
> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> +
> +Creation of the device should be done after creating the vCPUs of the virtual
> +machine.
> +
> +The IPA of the structures must be given to KVM. This is the base address
> +of an array of stolen time structures (one for each VCPU). The base address
> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
> +multiple of PAGE_SIZE.
> +
> +The memory for these structures should be added to the guest in the usual
> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
> +
> +For example:
> +
> + struct kvm_dev_arm_st_region region = {
> + .gpa = <IPA of guest base address>,
> + .size = <size in bytes>
> + };
This feel fragile; how are you handling userspace creating VCPUs after
setting this up, the GPA overlapping guest memory, etc. Is the
philosophy here that the VMM can mess up the VM if it wants, but that
this should never lead attacks on the host (we better hope not) and so
we don't care?
It seems to me setting the IPA per vcpu throught the VCPU device would
avoid a lot of these issues. See
Documentation/virt/kvm/devices/vcpu.txt.
Thanks,
Christoffer
> +
> + struct kvm_device_attr st_base = {
> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
> + .attr = KVM_DEV_ARM_PV_TIME_ST,
> + .addr = (u64)®ion
> + };
> +
> + ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
> --
> 2.20.1
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
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 9:03 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: <20190827075021.GA953@lst.de>
On Tue, Aug 27, 2019 at 4:50 PM Christoph Hellwig <hch@lst.de> wrote:
>
> 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.
Thanks for the pointer.
> 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 */
Yes, this makes my driver working again
when CONFIG_DMA_CMA=y.
If I apply the following, my driver gets back working
irrespective of CONFIG_DMA_CMA.
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 163d1cf4367e..504459395c39 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -237,6 +237,7 @@ static const struct sdhci_ops sdhci_cdns_ops = {
static const struct sdhci_pltfm_data sdhci_cdns_pltfm_data = {
.ops = &sdhci_cdns_ops,
+ .quirks2 = SDHCI_QUIRK2_BROKEN_64_BIT_DMA,
};
static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
--
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 related
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Russell King - ARM Linux admin @ 2019-08-27 9:13 UTC (permalink / raw)
To: Chris Packham
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, james.morse@arm.com, patches@armlinux.org.uk,
gregory.clement@free-electrons.com, bp@alien8.de,
mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-edac@vger.kernel.org
In-Reply-To: <836653f04f526333e8dbd45361329731f8dfe2ea.camel@alliedtelesis.co.nz>
On Mon, Aug 26, 2019 at 12:46:44AM +0000, Chris Packham wrote:
> Hi Russell,
>
> On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> > admin wrote:
> > > I can't apply this series - this file does not exist in my tree,
> > > and
> > > from what git tells me, it never has existed. Maybe it's in
> > > someone
> > > elses tree?
> >
> > I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
> > which is where it has been since it was originally submitted in 2012.
>
> Sorry there is a missing patch that moves it next to the
> hardware/cache-*.h. I can send the missing patch or I can re-send the
> whole series. If I do send the whole series do you want me to rebase it
> against a particular tag/tree?
Just send the single patch to the patch tracker - having it against
5.3-rc is fine (I don't think anything has changed for a long time
with that file.)
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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 v10 2/3] fdt: add support for rng-seed
From: Geert Uytterhoeven @ 2019-08-27 9:17 UTC (permalink / raw)
To: Will Deacon, Hsin-Yi Wang
Cc: Kate Stewart, Peter Zijlstra, Catalin Marinas, Mukesh Ojha,
Grzegorz Halat, H . Peter Anvin, Guenter Roeck, Marek Szyprowski,
Rob Herring, Daniel Thompson, Anders Roxell, Yury Norov,
Marc Zyngier, Russell King, Aaro Koskinen, Ingo Molnar,
Viresh Kumar, Waiman Long, Paul E . McKenney, Wei Li,
Alexey Dobriyan, Julien Thierry, Len Brown, Kees Cook,
Arnd Bergmann, Rik van Riel, Stephen Boyd, Shaokun Zhang,
Mike Rapoport, Borislav Petkov, Josh Poimboeuf, Thomas Gleixner,
Linux ARM, Theodore Tso, Greg Kroah-Hartman, Marcelo Tosatti,
Linux Kernel Mailing List, Linux-Renesas, Armijn Hemel,
Jiri Kosina, Mathieu Desnoyers, Andrew Morton, Tim Chen,
David S . Miller
In-Reply-To: <20190823154158.wgcnxfzpcttpnhga@willie-the-truck>
Hi Will, Hsin-Yi,
On Fri, Aug 23, 2019 at 5:42 PM Will Deacon <will@kernel.org> wrote:
> On Fri, Aug 23, 2019 at 02:24:51PM +0800, Hsin-Yi Wang wrote:
> > Introducing a chosen node, rng-seed, which is an entropy that can be
> > passed to kernel called very early to increase initial device
> > randomness. Bootloader should provide this entropy and the value is
> > read from /chosen/rng-seed in DT.
> >
> > Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(),
> > since early_init_dt_scan_chosen() would modify fdt to erase rng-seed.
> >
> > Add a new interface add_bootloader_randomness() for rng-seed use case.
> > Depends on whether the seed is trustworthy, rng seed would be passed to
> > add_hwgenerator_randomness(). Otherwise it would be passed to
> > add_device_randomness(). Decision is controlled by kernel config
> > RANDOM_TRUST_BOOTLOADER.
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > Change from v9:
> > * reword kconfig
> > * use IS_ENABLED for config
>
> Given that these aren't functional changes, I've kept Ted's ack from v9
> and I'll queue these via arm64 assuming they pass testing.
This is now commit 428826f5358c922d ("fdt: add support for rng-seed")
in arm64/for-next/core, and causes the following regression on arm32
(e.g. r8a7791/koelsch, and sh73a0/kzm9g):
OF: fdt: not creating '/sys/firmware/fdt': CRC check failed
Seems to work fine on arm64 (r8a7795/h3-salvator-xs), though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 9:24 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+CK2bAk4Xb_hxh2KLxWKa8ogM-jO1MpREmc02TmUMpdJ2ZbSA@mail.gmail.com>
On 27/08/2019 09:53, Pavel Tatashin wrote:
>>> 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.
>
> OK. Is this the most common configuration in the embedded ARM64
> devices currently deployed: phones, cameras, consoles, players, etc?
Which one of these has kexec as a requirement?
>>> 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.
>
> My impression was that without PCIe GICv3 is rarely used, and this
> could be the reason why this problem is not seen outside of larger
> machines which normally have EFI enabled.
Wong impression. All the combinations exist and are wildly deployed.
>>> 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.
>
> Thanks, this makes sense that the Linux boot time won't be affected. I
> have not tested how u-boot was affected, but was told 0.5 second
> longer to start.
So you haven't even tried? :-(
>
>> 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.
>
> I am not sure this analogy is correct, I do not think that non-EFI
> enabled kernels became legacy.
non-EFI systems always had reduced functionality, such as not being able
to use runtime services.
>
>> 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.
>
> This is exactly the problem: by having this region defined in signed
> DTB file we reduce the amount of communication between the kernels.
> Passing modified EFI Table causes us to pass more information from the
> first kernel indefinitely through updates. Thus, increases a chance
> for a security compromise.
Nothing says that it has to be modified. For what it's worth, you could
perform the allocation in your bootloader once and for all, configure
the GIC redistributors and enable LPIs there, and pass the EFI
reservation to the first kernel. The security argument is a fallacy.
> We are not changing EFI ABI between
> kernels, it will stay as is. All this code does is enables kernels
> that do not have EFI table communication between them a way to do
> kexec updates with reduced amount of data exchange.
And to do that, you're adding yet another ABI we have to support, and
creating havoc in the kexec chain (kernel 1 knows about the DT hack,
kernel 2 doesn't, panic follows). My answer to this is *no*. We already
have a flexible interface that allows you to do what you want, and I'm
not adding another one.
Thanks,
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
* Re: [PATCH v2 3/4] watchdog/aspeed: add support for dual boot
From: Ivan Mikhaylov @ 2019-08-27 9:24 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, linux-arm-kernel
In-Reply-To: <0df27d36-b45f-2059-6ead-a09ceb4b7605@roeck-us.net>
On Mon, 2019-08-26 at 17:14 -0700, Guenter Roeck wrote:
> > +/*
> > + * At alternate side the 'access_cs0' sysfs node provides:
> > + * ast2400: a way to get access to the primary SPI flash chip at CS0
> > + * after booting from the alternate chip at CS1.
> > + * ast2500: a way to restore the normal address mapping from
> > + * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
> > + *
> > + * Clearing the boot code selection and timeout counter also resets to the
> > + * initial state the chip select line mapping. When the SoC is in normal
> > + * mapping state (i.e. booted from CS0), clearing those bits does nothing
> > for
> > + * both versions of the SoC. For alternate boot mode (booted from CS1 due
> > to
> > + * wdt2 expiration) the behavior differs as described above.
> > + *
> The above needs to be in the sysfs attribute documentation as well.
My apologies but I didn't find any suitable, only watchdog parameters with
dtbindings file, where should I put it? Documentation/watchdog/aspeed-wdt-
sysfs.rst?
> > + * This option can be used with wdt2 (watchdog1) only.
>
> This implies a specific watchdog numbering which is not guaranteed.
> Someone might implement a system with some external watchdog.
>
> > + */
> > +static DEVICE_ATTR_RW(access_cs0);
> > +
> > +static struct attribute *bswitch_attrs[] = {
> > + &dev_attr_access_cs0.attr,
> > + NULL
> > +};
> > +ATTRIBUTE_GROUPS(bswitch);
> > +
> > static const struct watchdog_ops aspeed_wdt_ops = {
> > .start = aspeed_wdt_start,
> > .stop = aspeed_wdt_stop,
> > @@ -306,9 +359,16 @@ static int aspeed_wdt_probe(struct platform_device
> > *pdev)
> > }
> >
> > status = readl(wdt->base + WDT_TIMEOUT_STATUS);
> > - if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
> > + if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
> > wdt->wdd.bootstatus = WDIOF_CARDRESET;
> >
> > + if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
> > + of_device_is_compatible(np, "aspeed,ast2500-wdt"))
> > + wdt->wdd.groups = bswitch_groups;
> Kind of odd that the attribute only exists if the system booted from the
> second flash, but if that is what you want I won't object. Just make sure
> that this is explained properly.
Perhaps dts configuration option would be better solution for it then? "force-
cs0-switch" as example? Also, if it would be an option, dtbindings/wdt file for
documentation will be the right place for it. Usage of this at side 0 will not
get any good/bad results, it just makes user confused, so I decided to put it
only at side 1. It works only for ast2400/2500 board unfortunately, for 2600
there is big difference in switching mechanism. Any other thoughts how to make
it better?
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Applied "ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs" to the asoc tree
From: Chen-Yu Tsai @ 2019-08-27 9:25 UTC (permalink / raw)
To: Mark Brown, Maxime Ripard, Maxime Ripard
Cc: Marcus Cooper, Linux-ALSA, Liam Girdwood, linux-arm-kernel,
linux-kernel
In-Reply-To: <20190820174105.96899274314F@ypsilon.sirena.org.uk>
Hi,
On Wed, Aug 21, 2019 at 1:41 AM Mark Brown <broonie@kernel.org> wrote:
>
> The patch
>
> ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs
>
> has been applied to the asoc tree at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From c1d3a921d72bd21f266ca28c15213fbe78160a4b Mon Sep 17 00:00:00 2001
> From: Maxime Ripard <maxime.ripard@bootlin.com>
> Date: Mon, 19 Aug 2019 21:25:16 +0200
> Subject: [PATCH] ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs
>
> From: Marcus Cooper <codekipper@gmail.com>
The authorship of this patch looks to be wrong. Maybe it's a tooling issue.
I imagine it might have happened if Maxime created the patches using
`git format-patch` with his @bootlin.com address, then sent them with his
@kernel.org address, and `git send-email` swapped out the "From:" header
and prepended it to the body.
Either way the "From:" line looks odd in the commit log.
ChenYu
> The clock division dividers have changed between the older (A10/A31) and
> newer (H3, A64, etc) SoCs.
>
> While this was addressed through an offset on some SoCs, it was missing
> some dividers as well, so the support wasn't perfect. Let's introduce a
> pointer in the quirk structure for the divider calculation functions to use
> so we can have the proper range now.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> [Maxime: Fix the commit log, use a field in the quirk structure]
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> Link: https://lore.kernel.org/r/0e5b4abf06cd3202354315201c6af44caeb20236.1566242458.git-series.maxime.ripard@bootlin.com
> Signed-off-by: Mark Brown <broonie@kernel.org>
_______________________________________________
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] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-08-27 9:27 UTC (permalink / raw)
To: sstabellini@kernel.org, linux@armlinux.org.uk,
julien.grall@arm.com
Cc: van.freenix@gmail.com, xen-devel@lists.xenproject.org,
dl-linux-imx, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR04MB448135E1B2C85F0B6029F7B788C70@AM0PR04MB4481.eurprd04.prod.outlook.com>
Ping again..
+Julien
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> Hi Russell, Stefano
>
> > Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> Any comments?
>
> >
> > arm64 shares some code under arch/arm/xen, including mm.c.
> > However ZONE_DMA is removed by commit
> > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > So to ARM64, need use __GFP_DMA32.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > arch/arm/xen/mm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > e1d44b903dfc..a95e76d18bf9 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> int
> > order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0xffffffff) {
> > - flags |= __GFP_DMA;
> > + flags |= __GFP_DMA | __GFP_DMA32;
> > break;
> > }
> > }
>
> Thanks,
> Peng.
Thanks,
Peng.
>
> > --
> > 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
* [PATCH 1/2] Revert "ASoC: sun4i-i2s: Remove duplicated quirks structure"
From: Maxime Ripard @ 2019-08-27 9:32 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
This reverts commit 3e9acd7ac6933cdc20c441bbf9a38ed9e42e1490.
It turns out that while one I2S controller is described in the A83t
datasheet, the driver supports another, undocumented, one that has been
inherited from the older SoCs, while the documented one uses the new
design.
Fixes: 3e9acd7ac693 ("ASoC: sun4i-i2s: Remove duplicated quirks structure")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 57bf2a33753e..a6a3f772fdf0 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1097,6 +1097,11 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.set_fmt = sun4i_i2s_set_soc_fmt,
};
+/*
+ * This doesn't describe the TDM controller documented in the A83t
+ * datasheet, but the three undocumented I2S controller that use the
+ * older design.
+ */
static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1115,6 +1120,24 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.set_fmt = sun8i_i2s_set_soc_fmt,
};
+static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
+ .has_reset = true,
+ .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
+ .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),
+ .bclk_dividers = sun8i_i2s_clk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
+ .mclk_dividers = sun8i_i2s_clk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
+ .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
+ .get_sr = sun8i_i2s_get_sr_wss,
+ .get_wss = sun8i_i2s_get_sr_wss,
+ .set_chan_cfg = sun8i_i2s_set_chan_cfg,
+ .set_fmt = sun8i_i2s_set_soc_fmt,
+};
+
static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1296,7 +1319,7 @@ static const struct of_device_id sun4i_i2s_match[] = {
},
{
.compatible = "allwinner,sun8i-h3-i2s",
- .data = &sun8i_a83t_i2s_quirks,
+ .data = &sun8i_h3_i2s_quirks,
},
{
.compatible = "allwinner,sun50i-a64-codec-i2s",
--
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
* [PATCH 2/2] ASoC: sun4i: Revert A83t description
From: Maxime Ripard @ 2019-08-27 9:32 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20190827093206.17919-1-mripard@kernel.org>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The last set of reworks included some fixes to change the A83t behaviour
and "fix" it.
It turns out that the controller described in the datasheet and the one
supported here are not the same, yet the A83t has the two of them, and the
one supported in the driver wasn't the one described in the datasheet.
Fix this by reintroducing the proper quirks.
Fixes: 69e450e50ca6 ("ASoC: sun4i-i2s: Fix the LRCK period on A83t")
Fixes: bf943d527987 ("ASoC: sun4i-i2s: Fix MCLK Enable bit offset on A83t")
Fixes: 2e04fc4dbf50 ("ASoC: sun4i-i2s: Fix WSS and SR fields for the A83t")
Fixes: 515fcfbc7736 ("ASoC: sun4i-i2s: Fix LRCK and BCLK polarity offsets on newer SoCs")
Fixes: c1d3a921d72b ("ASoC: sun4i-i2s: Fix the MCLK and BCLK dividers on newer SoCs")
Fixes: fb19739d7f68 ("ASoC: sun4i-i2s: Use module clock as BCLK parent on newer SoCs")
Fixes: 71137bcd0a9a ("ASoC: sun4i-i2s: Move the format configuration to a callback")
Fixes: d70be625f25a ("ASoC: sun4i-i2s: Move the channel configuration to a callback")
Reported-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index a6a3f772fdf0..498ceebd9135 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1106,18 +1106,18 @@ 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,
- .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),
- .bclk_dividers = sun8i_i2s_clk_div,
- .num_bclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .mclk_dividers = sun8i_i2s_clk_div,
- .num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
- .get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
- .get_sr = sun8i_i2s_get_sr_wss,
- .get_wss = sun8i_i2s_get_sr_wss,
- .set_chan_cfg = sun8i_i2s_set_chan_cfg,
- .set_fmt = sun8i_i2s_set_soc_fmt,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 2, 3),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 5),
+ .bclk_dividers = sun4i_i2s_bclk_div,
+ .num_bclk_dividers = ARRAY_SIZE(sun4i_i2s_bclk_div),
+ .mclk_dividers = sun4i_i2s_mclk_div,
+ .num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
+ .get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .get_sr = sun4i_i2s_get_sr_wss,
+ .get_wss = sun4i_i2s_get_sr_wss,
+ .set_chan_cfg = sun4i_i2s_set_chan_cfg,
+ .set_fmt = sun4i_i2s_set_soc_fmt,
};
static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
--
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
* Re: [PATCH v6 2/3] ASoC: sun4i-i2s: Add regmap field to sign extend sample
From: Maxime Ripard @ 2019-08-27 9:34 UTC (permalink / raw)
To: codekipper
Cc: alsa-devel, linux-sunxi, linux-kernel, lgirdwood, be17068, wens,
broonie, linux-arm-kernel
In-Reply-To: <20190826180734.15801-3-codekipper@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 976 bytes --]
On Mon, Aug 26, 2019 at 08:07:33PM +0200, codekipper@gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> On the newer SoCs such as the H3 and A64 this is set by default
> to transfer a 0 after each sample in each slot. However the A10
> and A20 SoCs that this driver was developed on had a default
> setting where it padded the audio gain with zeros.
>
> This isn't a problem whilst we have only support for 16bit audio
> but with larger sample resolution rates in the pipeline then SEXT
> bits should be cleared so that they also pad at the LSB. Without
> this the audio gets distorted.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
If anything, I'd like to have less regmap_fields rather than more of
them. This is pretty easy to add to one of the callbacks, especially
since the field itself has been completely reworked from one
generation to the other.
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 00/21] ASoC: sun4i-i2s: Number of fixes and TDM Support
From: Maxime Ripard @ 2019-08-27 9:35 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Linux-ALSA, Liam Girdwood, linux-kernel, Code Kipper, Mark Brown,
linux-arm-kernel
In-Reply-To: <CAGb2v64xOcs3Vi5k3yUwMiUrzZMuJ5vZ3kxp9w1=CQDrkn3cgA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2884 bytes --]
Hi,
On Tue, Aug 27, 2019 at 04:20:24PM +0800, Chen-Yu Tsai wrote:
> 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?
I've just sent two patches to address that (adding a comment in the
process so that hopefully it doesn't happen again).
Let me know if it works, and sorry for the mess :/
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 v10 2/3] fdt: add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-27 9:42 UTC (permalink / raw)
To: Geert Uytterhoeven, Will Deacon
Cc: Kate Stewart, Peter Zijlstra, Catalin Marinas, Mukesh Ojha,
Grzegorz Halat, H . Peter Anvin, Guenter Roeck, Marek Szyprowski,
Rob Herring, Daniel Thompson, Anders Roxell, Yury Norov,
Marc Zyngier, Russell King, Aaro Koskinen, Ingo Molnar,
Viresh Kumar, Waiman Long, Paul E . McKenney, Wei Li,
Alexey Dobriyan, Julien Thierry, Len Brown, Kees Cook,
Arnd Bergmann, Rik van Riel, Stephen Boyd, Shaokun Zhang,
Mike Rapoport, Borislav Petkov, Josh Poimboeuf, Thomas Gleixner,
Linux ARM, Theodore Tso, Greg Kroah-Hartman, Marcelo Tosatti,
Linux Kernel Mailing List, Linux-Renesas, Armijn Hemel,
Jiri Kosina, Mathieu Desnoyers, Andrew Morton, Tim Chen,
David S . Miller
In-Reply-To: <CAMuHMdXkKomZm_5dhmYd3ryy7PCygA1JBRnpJVvaCXm8nXvTxw@mail.gmail.com>
I probably shouldn't move of_fdt_crc32 from early_init_dt_verify() to
early_init_dt_scan() after early_init_dt_scan_nodes().
Since arm doesn't call early_init_dt_scan(). It calls
early_init_dt_verify() and early_init_dt_scan_nodes(). While arm64
calls early_init_dt_scan().
Sorry for not checking on arm.
Since it's early_init_dt_scan_nodes() that would modify DT, I'll still
leave of_fdt_crc32 be in early_init_dt_verify() and update it in
early_init_dt_scan_chosen() if rng-seed is wiped from dt.
On Tue, Aug 27, 2019 at 5:18 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Will, Hsin-Yi,
>
> On Fri, Aug 23, 2019 at 5:42 PM Will Deacon <will@kernel.org> wrote:
> > On Fri, Aug 23, 2019 at 02:24:51PM +0800, Hsin-Yi Wang wrote:
> > > Introducing a chosen node, rng-seed, which is an entropy that can be
> > > passed to kernel called very early to increase initial device
> > > randomness. Bootloader should provide this entropy and the value is
> > > read from /chosen/rng-seed in DT.
> > >
> > > Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(),
> > > since early_init_dt_scan_chosen() would modify fdt to erase rng-seed.
> > >
> > > Add a new interface add_bootloader_randomness() for rng-seed use case.
> > > Depends on whether the seed is trustworthy, rng seed would be passed to
> > > add_hwgenerator_randomness(). Otherwise it would be passed to
> > > add_device_randomness(). Decision is controlled by kernel config
> > > RANDOM_TRUST_BOOTLOADER.
> > >
> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > > Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Change from v9:
> > > * reword kconfig
> > > * use IS_ENABLED for config
> >
> > Given that these aren't functional changes, I've kept Ted's ack from v9
> > and I'll queue these via arm64 assuming they pass testing.
>
> This is now commit 428826f5358c922d ("fdt: add support for rng-seed")
> in arm64/for-next/core, and causes the following regression on arm32
> (e.g. r8a7791/koelsch, and sh73a0/kzm9g):
>
> OF: fdt: not creating '/sys/firmware/fdt': CRC check failed
>
> Seems to work fine on arm64 (r8a7795/h3-salvator-xs), though.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
_______________________________________________
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] arm: xen: mm: use __GPF_DMA32 for arm64
From: Russell King - ARM Linux admin @ 2019-08-27 9:45 UTC (permalink / raw)
To: Peng Fan
Cc: sstabellini@kernel.org, linux-kernel@vger.kernel.org,
julien.grall@arm.com, dl-linux-imx, van.freenix@gmail.com,
xen-devel@lists.xenproject.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB44818BB69CAD35DC989A416988A00@AM0PR04MB4481.eurprd04.prod.outlook.com>
You need to find someone who is interested in Xen on 32-bit ARM, and
who knows this code - and therefore what impact your change causes.
That isn't me, sorry.
On Tue, Aug 27, 2019 at 09:27:53AM +0000, Peng Fan wrote:
> Ping again..
>
> +Julien
>
> > Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> >
> > Hi Russell, Stefano
> >
> > > Subject: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> >
> > Any comments?
> >
> > >
> > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > However ZONE_DMA is removed by commit
> > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > So to ARM64, need use __GFP_DMA32.
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > arch/arm/xen/mm.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > e1d44b903dfc..a95e76d18bf9 100644
> > > --- a/arch/arm/xen/mm.c
> > > +++ b/arch/arm/xen/mm.c
> > > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int
> > > order)
> > >
> > > for_each_memblock(memory, reg) {
> > > if (reg->base < (phys_addr_t)0xffffffff) {
> > > - flags |= __GFP_DMA;
> > > + flags |= __GFP_DMA | __GFP_DMA32;
> > > break;
> > > }
> > > }
> >
> > Thanks,
> > Peng.
>
> Thanks,
> Peng.
>
> >
> > > --
> > > 2.16.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan @ 2019-08-27 9:51 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
From: Peng Fan <peng.fan@nxp.com>
V4:
yaml fix for num-chans in patch 1/2.
V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.
[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.
The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.
The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.
This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.
This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.
Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.
Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.
[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi
Peng Fan (2):
dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
mailbox: introduce ARM SMC based mailbox
.../devicetree/bindings/mailbox/arm-smc.yaml | 126 ++++++++++++
drivers/mailbox/Kconfig | 7 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 215 +++++++++++++++++++++
4 files changed, 350 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
--
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
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