Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 05/10] ASoC: Add sun8i digital audio codec
From: Mylene Josserand @ 2017-01-17 16:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-6-mylene.josserand@free-electrons.com>

Hello everyone,

On 17/01/2017 15:02, Myl?ne Josserand wrote:
> Add the sun8i audio codec which handles the digital register of
> A33 codec.
> The driver handles only the basic playback from the DAC to headphones.
> All other features (microphone, capture, etc) will be added later.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>

[...]

> +static int sun8i_codec_get_hw_rate(struct snd_pcm_hw_params *params)
> +{
> +	unsigned int rate = params_rate(params);
> +
> +	switch (rate) {
> +	case 8000:
> +	case 7350:
> +		return 0x0;
> +	case 11025:
> +		return 0x1;
> +	case 12000:
> +		return 0x2;
> +	case 16000:
> +		return 0x3;
> +	case 22050:
> +		return 0x4;
> +	case 24000:
> +		return 0x5;
> +	case 32000:
> +		return 0x6;
> +	case 44100:
> +		return 0x7;
> +	case 48000:
> +		return 0x8;
> +	case 96000:
> +		return 0x9;
> +	case 192000:
> +		return 0xa;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static u32 sun8i_codec_get_mod_freq(struct snd_pcm_hw_params *params)
> +{
> +	unsigned int rate = params_rate(params);
> +
> +	switch (rate) {
> +	case 176400:
> +	case 88200:
> +	case 44100:
> +	case 22050:
> +	case 11025:
> +		return 22579200;
> +
> +	case 192000:
> +	case 128000:
> +	case 96000:
> +	case 64000:
> +	case 48000:
> +	case 32000:
> +	case 24000:
> +	case 16000:
> +	case 12000:
> +	case 8000:
> +		return 24576000;
> +
> +	default:
> +		return 0;
> +	}
> +}

This function is not used anymore, I will remove it in v3 (once I will 
get some reviews).

> +
> +static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> +{
> +	struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
> +	u32 value;
> +
> +	/* clock masters */
> +	switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> +	case SND_SOC_DAIFMT_CBS_CFS: /* DAI Slave */
> +		value = 0x0; /* Codec Master */
> +		break;
> +	case SND_SOC_DAIFMT_CBM_CFM: /* DAI Master */
> +		value = 0x1; /* Codec Slave */
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
> +			   BIT(SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD),
> +			   value << SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD);
> +
> +	/* clock inversion */
> +	switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
> +	case SND_SOC_DAIFMT_NB_NF: /* Normal */
> +		value = 0x0;
> +		break;
> +	case SND_SOC_DAIFMT_IB_IF: /* Inversion */
> +		value = 0x1;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
> +			   BIT(SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV),
> +			   value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV);
> +	regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
> +			   BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV),
> +			   value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
> +
> +	/* DAI format */
> +	switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> +	case SND_SOC_DAIFMT_I2S:
> +		value = 0x0;
> +		break;
> +	case SND_SOC_DAIFMT_LEFT_J:
> +		value = 0x1;
> +		break;
> +	case SND_SOC_DAIFMT_RIGHT_J:
> +		value = 0x2;
> +		break;
> +	case SND_SOC_DAIFMT_DSP_A:
> +	case SND_SOC_DAIFMT_DSP_B:
> +		value = 0x3;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
> +			   BIT(SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT),
> +			   value << SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT);
> +
> +	return 0;
> +}
> +
> +static int sun8i_codec_hw_params(struct snd_pcm_substream *substream,
> +				 struct snd_pcm_hw_params *params,
> +				 struct snd_soc_dai *dai)
> +{
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct snd_soc_dai *cpu_dai = rtd->cpu_dai;

Same things for these variables.

> +	struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
> +	u32 clk_freq;
> +	int sample_rate, err;

ditto for "clk_freq" and "err" ones.

Sorry about that.

Best regards,

-- 
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
From: Kim Phillips @ 2017-01-17 16:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170116105904.GB1510@arm.com>

On Mon, 16 Jan 2017 10:59:04 +0000
Will Deacon <will.deacon@arm.com> wrote:

> On Fri, Jan 13, 2017 at 06:43:52PM +0000, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> > > +- compatible : should be one of:
> > > +	       "arm,arm-spe-pmu-v1"
> > 
> > The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> > instead?
> 
> I don't think armv8.2 is particularly helpful, because that effectively ties
> together the SPE version and the architecture version, which I don't think
> is strictly required. The reason I added it was so that you could describe
> a partner implementation as something like:
> 
>   acme,arm-spe-pmu-v1
> 
> and know that it was acme's implementation of an ARM architectural feature.

Wouldn't such an implementation be compatible with an
"arm,arm-spe-pmu-v1" (or one with less "arm"s)?

> If I drop the second "arm", I was worried that it might conflict with other
> namespaces (e.g. acme's signal-processing-element's power-management-unit).

I'd personally let them worry about that, esp. because this problem
would come up first and hopefully be fixed in the marketing domain
before it reaches its device tree specification stage.

Kim

^ permalink raw reply

* [PATCH 1/2] power/reset: at91-reset: add samx7 support
From: Sebastian Reichel @ 2017-01-17 16:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117125910.icdsl2x7lpnukymy@piout.net>

Hi Alexandre,

On Tue, Jan 17, 2017 at 01:59:10PM +0100, Alexandre Belloni wrote:
> Did you have any comment on those two patches ?

They look fine, but I can't apply them. Can you resend a rebased
version?

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/86f32aa0/attachment.sig>

^ permalink raw reply

* Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop
From: Russell King - ARM Linux @ 2017-01-17 16:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AM5PR0701MB187319ED63BCB767DA438C0CA07C0@AM5PR0701MB1873.eurprd07.prod.outlook.com>

On Tue, Jan 17, 2017 at 04:20:00PM +0000, Elad Nachman wrote:
> Hi,
> 
> I am experiencing sporadic work queue lockups on kernel 4.6.7-rt14 (mach-socfpga).
> 
> Using a HW debugger I got the following information:
> 
> A process containing a network namespace is terminating itself (SIGKILL),
> which causes cleanup_net() to be scheduled to kworker/u4:2 to clean up
> the network namespace running on the process.
> 
> Kworker/u4:2 got preempted (plus there are a lot of other work queue
> items, like vmstat_shepherd, wakeup_dirtytime_writeback, phy_state_machine,
> neigh_periodic_work, check_lifetime plus another one by a LKM) while
> holding the rtnl lock.
> 
> A processing running waitpid() on the terminated process starts a new
> process, which forks busybox to run sysctl -w net.ipv6.conf.all.forwarding
> = 1 .
> This in turn starts making a write syscall, calling in turn vfs_write,
> proc_sys_call_handler, addrconf_sysctl_forward, and finally
> addrconf_fixup_forwarding().
> 
> addrconf_fixup_forwarding() runs the following code:
> 
> if (!rtnl_trylock())
>                  return restart_syscall();
> 
> This fails and restart_syscall() does the following:
> 
> set_tsk_thread_flag(current, TIF_SIGPENDING);
>          return -ERESTARTNOINTR;
> 
> Now the system call goes back to ret_fast_syscall (arch/arm/kernel/entry-common.S)
> Testing the flags in the task_struct (which contain TIF_SIGPENDING) the code branches to fast_work_pending, then falls through to slow_work_pending, which
> Calls do_work_pending(), and in turn calls do_signal(), get_signal(), dequeuer_signal(), which find no signals, and clears the TIF_SIGPENDING bit when recalc_sigpending() is called, then returns zero.
> 
> This causes do_signal() to examine r0 and return 1 (-ERESTARTNOINTR), which is propogated to the assembly code by do_work_pending().
> Having r0 equal zero causes a branch to local_restart, which restarts the very same write system call in an endless loop.
> No scheduling is possible, so the cleanup_net() cannot finish and release rtnl, which in turn causes the endless restarting of the write system call.
> 
> Going over the x86 assembly code and does not look like system calls are restarted within the assembly syscall handler without returning to user-space.
> 
> There could be several remedies:
> 
> 1.Adopt the X86 handling (avoid restarting system calls within the handler, but rather return to user-space).

We used to do that, but it became infeasible.

commit 81783786d5cf4aa0d3e15bb0fac856aa8ebf1a76
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Jul 19 17:48:21 2012 +0100

    ARM: 7473/1: deal with handlerless restarts without leaving the kernel

However, I think your analysis is slightly off.  Yes, we call into
do_work_pending().  As long as _TIF_NEED_RESCHED is not set, then
you are correct.

However, _TIF_NEED_RESCHED will be set at the end of the thread's
quantum, or when a higher priority thread needs to run on the current
CPU.

Now, that's the exact same path which gets used when a thread needs to
be preempted, so returning back to userspace and re-entering to the
restart syscall doesn't achieve anything as long as _TIF_NEED_RESCHED
is clear.  We just end up executing more instructions uselessly.

I think the problem is that:

        if (!rtnl_trylock())
                return restart_syscall();

which, if it didn't do a trylock, it would put this thread to sleep
and allow other threads to run (potentially allowing the holder of
the lock to release it.)

What's more odd about this is that it's very unusual and strange for
a kernel function to invoke the restart mechanism because a lock is
being held - the point of the restart mechanism is to allow userspace
signal handlers to run, so it should only be used when there's a
signal pending.  I think this is a hack in the IPv6 code to work
around some other issue.

This isn't really -rt kernel specific, I'd expect exactly the same
behaviour from a non-rt kernel.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* [PATCH v2 01/10] ASoC: sun4i-i2s: Increase DMA max burst to 8
From: Maxime Ripard @ 2017-01-17 16:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-2-mylene.josserand@free-electrons.com>

On Tue, Jan 17, 2017 at 03:02:21PM +0100, Myl?ne Josserand wrote:
> As done previously for sun4i-codec, the DMA maxburst of 4
> is not supported by every SoCs so the DMA controller engine
> returns "unsupported value".
> 
> As a maxburst of 8 is supported by all variants, this patch
> increases it to 8.
> 
> For more details, see commit from Chen-Yu Tsai:
> commit 730e2dd0cbc7 ("ASoC: sun4i-codec: Increase DMA max burst to 8")

Those details could have been included directly in the commit log.

Otherwise,
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/04d60086/attachment.sig>

^ permalink raw reply

* [PATCH v2 02/10] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig
From: Maxime Ripard @ 2017-01-17 16:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-3-mylene.josserand@free-electrons.com>

Hi,

On Tue, Jan 17, 2017 at 03:02:22PM +0100, Myl?ne Josserand wrote:
> The audio DAI needs to set the clock rates of the ac-dig clock.
> To make it possible, the parent PLL audio clock rates should
> also be changed. This is possible via "CLK_SET_RATE_PARENT" flag.
> 
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>

Please make sure to look at the prefixes usually used in the commit
titles of the area you're working on. In this case that would have
been "clk: sunxi-ng:". I fixed it, and applied.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/601fc082/attachment.sig>

^ permalink raw reply

* [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
From: Mark Rutland @ 2017-01-17 16:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170116105904.GB1510@arm.com>

On Mon, Jan 16, 2017 at 10:59:04AM +0000, Will Deacon wrote:
> On Fri, Jan 13, 2017 at 06:43:52PM +0000, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> > > This patch documents the devicetree binding in use for ARM SPE.
> > > 
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > >  Documentation/devicetree/bindings/arm/spe-pmu.txt | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/arm/spe-pmu.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/spe-pmu.txt b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> > > new file mode 100644
> > > index 000000000000..d6540b491af4
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> > > @@ -0,0 +1,20 @@
> > > +* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU)
> > > +
> > > +ARMv8.2 introduces the optional Statistical Profiling Extension for collecting
> > > +performance sample data using an in-memory trace buffer.
> > > +
> > > +** SPE Required properties:
> > > +
> > > +- compatible : should be one of:
> > > +	       "arm,arm-spe-pmu-v1"
> > 
> > The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> > instead?
> 
> I don't think armv8.2 is particularly helpful, because that effectively ties
> together the SPE version and the architecture version, which I don't think
> is strictly required.

Sure; I was mostly going by the example of the generic timer (which
changed somewhat between ARMv7 and ARMv8), but if SPE is somewhat
decoupled from ARMv8.2 that's not a big concern.

> The reason I added it was so that you could describe
> a partner implementation as something like:
> 
>   acme,arm-spe-pmu-v1
> 
> and know that it was acme's implementation of an ARM architectural feature.

We don't seem to do this for the SMMU, or elsewhere that I am aware of.

> If I drop the second "arm", I was worried that it might conflict with other
> namespaces (e.g. acme's signal-processing-element's power-management-unit).

That does sound possible.

Another way of avoiding this would be to expand "spe" (and we can drop
"pmu", since that's not actually part of the SPE name, and implied
anyhow).

How would you feel about:

"arm,statisitical-profiling-extension-v1"

Thanks,
Mark.

^ permalink raw reply

* [PATCH v2 03/10] dt-bindings: sound: Add new reset compatible for sun4i-i2s
From: Maxime Ripard @ 2017-01-17 16:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-4-mylene.josserand@free-electrons.com>

On Tue, Jan 17, 2017 at 03:02:23PM +0100, Myl?ne Josserand wrote:
> Add a new compatible for sun4i-i2s driver to handle some
> SoCs that have a reset line that must be asserted/deasserted.
> 
> This new compatible, "allwinner,sun6i-a31-i2s", requires two
> properties:
> 	- resets: phandle to the reset line
> 	- reset-names: the name of the reset line ("rst").
> Except these differences, the compatible is identical to previous one
> which will not handle a reset line.
> 
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
> ---
>  .../devicetree/bindings/sound/sun4i-i2s.txt        | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> index 7a2c0945fd22..f673206e309b 100644
> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> @@ -7,6 +7,7 @@ Required properties:
>  
>  - compatible: should be one of the following:
>     - "allwinner,sun4i-a10-i2s"
> +   - "allwinner,sun6i-a31-i2s" for controller with reset lines

That's not only for controllers with reset lines, but for the
controllers found in the A31 (and later). I'd simply drop the last
part of that line.

>  - reg: physical base address of the controller and length of memory mapped
>    region.
>  - interrupts: should contain the I2S interrupt.
> @@ -19,7 +20,13 @@ Required properties:
>     - "mod" : module clock for the I2S controller
>  - #sound-dai-cells : Must be equal to 0
>  
> +Required properties for the following compatibles:
> +		- "allwinner,sun6i-a31-i2s"
> +- resets: phandle to the reset line for this codec
> +- reset-names: Contains the reset signal name "rst"

You don't need reset-names if there's a single reset line.

> +
>  Example:
> +For "allwinner,sun4i-a10-i2s":
>  
>  i2s0: i2s at 01c22400 {
>  	#sound-dai-cells = <0>;
> @@ -32,3 +39,19 @@ i2s0: i2s at 01c22400 {
>  	       <&dma SUN4I_DMA_NORMAL 3>;
>  	dma-names = "rx", "tx";
>  };
> +
> +For "allwinner,sun6i-a31-i2s":
> +
> +dai: dai at 01c22c00 {
> +	#sound-dai-cells = <0>;
> +	compatible = "allwinner,sun6i-a31-i2s";
> +	reg = <0x01c22c00 0x200>;
> +	interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> +	clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> +	clock-names = "apb", "mod";
> +	resets = <&ccu RST_BUS_CODEC>;
> +	reset-names = "rst";
> +	dmas = <&dma 15>, /* AUDIO_CODEC port */
> +		<&dma 15>; /* AUDIO_CODEC port */
> +	dma-names = "rx", "tx";
> +};

And we already have an example, so there's no need to add a new one
either.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/798afa34/attachment.sig>

^ permalink raw reply

* [PATCH] ARM: DT: STiH407: Add RTS / CTS pinctrl definition for UARTs.
From: Peter Griffin @ 2017-01-17 16:46 UTC (permalink / raw)
  To: linux-arm-kernel

The uart IP is capable of doing hardware flow control. Define
the RTS and CTS pins for STiH407 family Socs so we can use this
feature in the future if we wish to.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 50 ++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
index daab16b..3bbb0c0 100644
--- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -149,6 +149,16 @@
 						rx = <&pio3 5 ALT1 IN>;
 					};
 				};
+				pinctrl_sbc_serial0_rts: sbc_serial0-0_rts {
+					st,pins {
+						rts = <&pio3 7 ALT1 OUT>;
+					};
+				};
+				pinctrl_sbc_serial0_cts: sbc_serial0-0_cts {
+					st,pins {
+						cts = <&pio3 6 ALT1 IN>;
+					};
+				};
 			};
 			/* SBC_ASC1 - UART11 */
 			sbc_serial1 {
@@ -158,6 +168,16 @@
 						rx = <&pio2 7 ALT3 IN>;
 					};
 				};
+				pinctrl_sbc_serial1_rts: sbc_serial1-0_rts {
+					st,pins {
+						rts = <&pio3 1 ALT3 OUT>;
+					};
+				};
+				pinctrl_sbc_serial1_cts: sbc_serial1-0_cts {
+					st,pins {
+						cts = <&pio3 0 ALT3 IN>;
+					};
+				};
 			};
 
 			i2c10 {
@@ -469,6 +489,16 @@
 						rx = <&pio17 1 ALT1 IN>;
 					};
 				};
+				pinctrl_serial0_rts: serial0-0_rts {
+					st,pins {
+						rts = <&pio17 3	ALT1 OUT>;
+					};
+				};
+				pinctrl_serial0_cts: serial0-0_cts {
+					st,pins {
+						cts = <&pio17 2	ALT1 IN>;
+					};
+				};
 			};
 
 			serial1 {
@@ -478,6 +508,16 @@
 						rx = <&pio16 1 ALT1 IN>;
 					};
 				};
+				pinctrl_serial1_rts: serial1-0_rts {
+					st,pins {
+						rts = <&pio16 3	ALT1 OUT>;
+					};
+				};
+				pinctrl_serial1_cts: serial1-0_cts {
+					st,pins {
+						cts = <&pio16 2 ALT1 IN>;
+					};
+				};
 			};
 
 			serial2 {
@@ -487,6 +527,16 @@
 						rx = <&pio15 1 ALT1 IN>;
 					};
 				};
+				pinctrl_serial2_rts: serial2-0_rts {
+					st,pins {
+						rts = <&pio15 3	ALT1 OUT>;
+					};
+				};
+				pinctrl_serial2_cts: serial2-0_cts {
+					st,pins {
+						cts = <&pio15 2	ALT1 IN>;
+					};
+				};
 			};
 
 			mmc1 {
-- 
2.7.4

^ permalink raw reply related

* [PATCH v2 04/10] ASoC: sun4i-i2s: Add quirks to handle new compatible for reset
From: Maxime Ripard @ 2017-01-17 16:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-5-mylene.josserand@free-electrons.com>

On Tue, Jan 17, 2017 at 03:02:24PM +0100, Myl?ne Josserand wrote:
> Some SoCs have a reset line that must be asserted/deasserted.
> This patch adds a quirk to handle the new compatible
> "allwinner,sun6i-a31-i2s" which will deassert the reset
> line on probe function and assert it on remove's one.
> 
> This new compatible is useful in case of A33 codec driver, for example.
> 
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/ba3a4f3a/attachment.sig>

^ permalink raw reply

* [PATCH v2 06/10] ASoC: sun8i-codec-analog: Add amplifier event to fix first delay
From: Maxime Ripard @ 2017-01-17 16:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-7-mylene.josserand@free-electrons.com>

On Tue, Jan 17, 2017 at 03:02:26PM +0100, Myl?ne Josserand wrote:
> When playing a sound for the first time, a short delay, where the audio
> file is not played, can be noticed.
> On a second play (right after), the sound is played correctly.
> If we wait a short time (~5 sec which corresponds to the aplay
> timeout), the delay is back.
> 
> This patch fixes it by using an event on headphone amplifier.
> It allows to keep the amplifier enable while playing a sound.
> A delay of 700ms allows to wait that the amplifier is powered-up
> before playing the sound.
> 
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/b6afa6d0/attachment.sig>

^ permalink raw reply

* [PATCH 0/3] KVM/ARM updates for 4.10-rc4
From: Radim Krčmář @ 2017-01-17 16:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484307093-29153-1-git-send-email-marc.zyngier@arm.com>

2017-01-13 11:31+0000, Marc Zyngier:
> Radim, Paolo,
> 
> Here's the KVM/ARM updates for 4.10-rc4. Two timer fixes, and one vgic
> fix for a deadlock that's been reported this week (which should land
> into stable).

Pulled to kvm/master, thanks.

^ permalink raw reply

* [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
From: Mark Rutland @ 2017-01-17 16:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117103100.55e98029aac55ef7770350f3@arm.com>

On Tue, Jan 17, 2017 at 10:31:00AM -0600, Kim Phillips wrote:
> On Mon, 16 Jan 2017 10:59:04 +0000 Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Jan 13, 2017 at 06:43:52PM +0000, Mark Rutland wrote:
> > > On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> > > > +- compatible : should be one of:
> > > > +	       "arm,arm-spe-pmu-v1"
> > > 
> > > The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> > > instead?
> > 
> > I don't think armv8.2 is particularly helpful, because that effectively ties
> > together the SPE version and the architecture version, which I don't think
> > is strictly required. The reason I added it was so that you could describe
> > a partner implementation as something like:
> > 
> >   acme,arm-spe-pmu-v1
> > 
> > and know that it was acme's implementation of an ARM architectural feature.
> 
> Wouldn't such an implementation be compatible with an
> "arm,arm-spe-pmu-v1" (or one with less "arm"s)?

We'd expect that, but in the case of significant divergence (e.g.
errata), we may not expect the fallback to the ARM compatible string.

That said, I'm not keen on the duplicate "arm" here, regardless.

> > If I drop the second "arm", I was worried that it might conflict with other
> > namespaces (e.g. acme's signal-processing-element's power-management-unit).
> 
> I'd personally let them worry about that, esp. because this problem
> would come up first and hopefully be fixed in the marketing domain
> before it reaches its device tree specification stage.

FWIW, I think that marketing is completely unrelated.

I can imagine we might have a clash, but I suspect it's unlikely if we
have enough oversight of the bindings (i.e. so long as we keep an eye
out, and the DT maintainers get Cc'd on anything likely to clash).

Thanks,
Mark.

^ permalink raw reply

* [PATCH v2 07/10] dt-bindings: sound: Add sun8i audio documentation
From: Mark Brown @ 2017-01-17 16:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-8-mylene.josserand@free-electrons.com>

On Tue, Jan 17, 2017 at 03:02:27PM +0100, Myl?ne Josserand wrote:
> Add the documentation for dt-binding of the digital audio codec driver
> and the audio card driver for Sun8i SoCs.


Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/4c2c9932/attachment.sig>

^ permalink raw reply

* [PATCH v2 07/10] dt-bindings: sound: Add sun8i audio documentation
From: Maxime Ripard @ 2017-01-17 16:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-8-mylene.josserand@free-electrons.com>

Hi,

On Tue, Jan 17, 2017 at 03:02:27PM +0100, Myl?ne Josserand wrote:
> Add the documentation for dt-binding of the digital audio codec driver
> and the audio card driver for Sun8i SoCs.
> 
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>

One small comment below,

> ---
>  .../devicetree/bindings/sound/sun8i-codec.txt      | 76 ++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/sun8i-codec.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-codec.txt
> new file mode 100644
> index 000000000000..ce3c05219e33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/sun8i-codec.txt
> @@ -0,0 +1,76 @@
> +Allwinner SUN8I audio codec
> +------------------------------------
> +
> +On Sun8i SoCs, and particularly on A33, the audio is separated in

Technically that's not true on all the SoCs of the sun8i family, but
only a few of them (A33 and H3 iirc).

This driver is only made for the A33 at the moment, so you should only
mention it (and you should rename that file as well).

Once done,
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks,
Maxime


> +different parts:
> +	  - A DAI driver. It uses the "sun4i-i2s" driver which is
> +	  documented here:
> +	  Documentation/devicetree/bindings/sound/sun4i-i2s.txt
> +	  - An analog part of the codec which is handled as PRCM registers.
> +	  See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
> +	  - An digital part of the codec which is documented in this current
> +	  binding documentation.
> +	  - And finally, an audio card which links all the above components.
> +	  The simple-audio card will be used.
> +	  See Documentation/devicetree/bindings/sound/simple-card.txt
> +
> +This bindings documentation exposes Sun8i codec (digital part).
> +
> +Required properties:
> +- compatible: must be "allwinner,sun8i-a33-codec"
> +- reg: must contain the registers location and length
> +- interrupts: must contain the codec interrupt
> +- clocks: a list of phandle + clock-specifer pairs, one for each entry
> +  in clock-names.
> +- clock-names: should contain followings:
> +   - "bus": the parent APB clock for this controller
> +   - "mod": the parent module clock
> +
> +Example:
> +codec: codec at 01c22e00 {
> +	#sound-dai-cells = <0>;
> +	compatible = "allwinner,sun8i-a33-codec";
> +	reg = <0x01c22e00 0x400>;
> +	interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> +	clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> +	clock-names = "bus", "mod";
> +	status = "disabled";
> +};
> +
> +Here is an example to add a sound card and the codec binding on sun8i SoCs that
> +are similar to A33 using simple-card:
> +
> +	sound {
> +		compatible = "simple-audio-card";
> +		simple-audio-card,name = "Sun8i Audio Card";
> +		simple-audio-card,format = "i2s";
> +		simple-audio-card,frame-master = <&link_codec>;
> +		simple-audio-card,bitclock-master = <&link_codec>;
> +		simple-audio-card,mclk-fs = <512>;
> +		simple-audio-card,aux-devs = <&codec_analog>;
> +		simple-audio-card,routing =
> +				"Left DAC", "Digital Left DAC",
> +				"Right DAC", "Digital Right DAC";
> +
> +		simple-audio-card,cpu {
> +			sound-dai = <&dai>;
> +		};
> +
> +		link_codec: simple-audio-card,codec {
> +			sound-dai = <&codec>;
> +		};
> +
> +	soc at 01c00000 {
> +		[...]
> +
> +		codec: codec at 01c22e00 {
> +			#sound-dai-cells = <0>;
> +			compatible = "allwinner,sun8i-a33-codec";
> +			reg = <0x01c22e00 0x400>;
> +			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> +			clock-names = "bus", "mod";
> +			status = "disabled";
> +		};
> +	};
> +
> -- 
> 2.11.0
> 

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/dbd075eb/attachment-0001.sig>

^ permalink raw reply

* [PATCH v2 1/4] arm: sunxi: add support for V3s SoC
From: Icenowy Zheng @ 2017-01-17 16:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117090549.uqwsiwmclzhx7456@lukather>



17.01.2017, 17:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Jan 17, 2017 at 02:01:13AM +0800, Icenowy Zheng wrote:
>> ?Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
>> ?integrated DRAM, and several peripherals.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>> ?Changes in v2:
>> ?- Used linux-sunxi.org wiki hosted address of V3s datasheet.
>>
>> ?Note: the V3s datasheet contains its user manual.
>
> That would be great to use User Manual in the filename rather than
> datasheet then. The datasheet is something different.

Allwinner named it datasheet.

For previous SoCs, datasheet will contain info about pins, and user manual
about registers.

But for H3 and V3s, datasheet now contains both pins' info and registers' info.

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

^ permalink raw reply

* [PATCH] clk: meson-gxbb: Export HDMI clocks
From: Kevin Hilman @ 2017-01-17 16:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1484654928-5640-1-git-send-email-narmstrong@baylibre.com>

Neil Armstrong <narmstrong@baylibre.com> writes:

> Export HDMI clock from internal to dt-bindings.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

Acked-by: Kevin Hilman <khilman@baylibre.com>

> ---
>  drivers/clk/meson/gxbb.h              | 4 ++--
>  include/dt-bindings/clock/gxbb-clkc.h | 2 ++
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
> index 0252939..2139e97 100644
> --- a/drivers/clk/meson/gxbb.h
> +++ b/drivers/clk/meson/gxbb.h
> @@ -231,7 +231,7 @@
>  #define CLKID_AHB_DATA_BUS	  60
>  #define CLKID_AHB_CTRL_BUS	  61
>  #define CLKID_HDMI_INTR_SYNC	  62
> -#define CLKID_HDMI_PCLK		  63
> +/* CLKID_HDMI_PCLK */
>  /* CLKID_USB1_DDR_BRIDGE */
>  /* CLKID_USB0_DDR_BRIDGE */
>  #define CLKID_MMC_PCLK		  66
> @@ -245,7 +245,7 @@
>  #define CLKID_VCLK2_VENCI1	  74
>  #define CLKID_VCLK2_VENCP0	  75
>  #define CLKID_VCLK2_VENCP1	  76
> -#define CLKID_GCLK_VENCI_INT0	  77
> +/* CLKID_GCLK_VENCI_INT0 */
>  #define CLKID_GCLK_VENCI_INT	  78
>  #define CLKID_DAC_CLK		  79
>  #define CLKID_AOCLK_GATE	  80
> diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
> index baade6f..da1d473 100644
> --- a/include/dt-bindings/clock/gxbb-clkc.h
> +++ b/include/dt-bindings/clock/gxbb-clkc.h
> @@ -18,8 +18,10 @@
>  #define CLKID_USB0		50
>  #define CLKID_USB1		51
>  #define CLKID_USB		55
> +#define CLKID_HDMI_PCLK		63
>  #define CLKID_USB1_DDR_BRIDGE	64
>  #define CLKID_USB0_DDR_BRIDGE	65
> +#define CLKID_GCLK_VENCI_INT0	77
>  #define CLKID_AO_I2C		93
>  #define CLKID_SD_EMMC_A		94
>  #define CLKID_SD_EMMC_B		95

^ permalink raw reply

* [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
From: Icenowy Zheng @ 2017-01-17 16:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117080611.tn7s7ddj2csqr27m@lukather>



17.01.2017, 16:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote:
>> ?The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
>> ?controller.
>>
>> ?The original driver wired it to OHCI/EHCI controller; however, as the
>> ?code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
>> ?unusable.
>>
>> ?Rename the register (according to its function and the name in BSP
>> ?driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
>> ?can support both peripheral and host mode (although the host mode of
>> ?MUSB is buggy).
>
> Can you elaborate on that? What's wrong with it?

The configuration is at bit 0 of register 0x20 in PHY.

When the PHY is reseted, it defaults as MUSB mode.

However, the original author of the H3 PHY code seems to be lack of this
knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI mode.

I just removed the code that wires it to HCI mode, thus it will work in MUSB
mode, with my sun8i-h3-musb patch.

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

^ permalink raw reply

* [PATCH v2 08/10] ARM: dts: sun8i: Add audio codec, dai and card for A33
From: Maxime Ripard @ 2017-01-17 16:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117140230.23142-9-mylene.josserand@free-electrons.com>

Hi,

On Tue, Jan 17, 2017 at 03:02:28PM +0100, Myl?ne Josserand wrote:
> Add the audio codec, dai and a simple card to be able to use the
> audio stream of the builtin codec on sun8i SoC.
> 
> This commit adds also an audio-routing for the sound card node to link
> the analog DAPM widgets (Right/Left DAC) and the digital one's as they
> are created in different drivers.
> 
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
> ---
>  arch/arm/boot/dts/sun8i-a33.dtsi | 47 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 63d5181ffff8..fe8a4f4760d2 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -43,6 +43,7 @@
>   */
>  
>  #include "sun8i-a23-a33.dtsi"
> +#include <dt-bindings/dma/sun4i-a10.h>
>  
>  / {
>  	cpus {
> @@ -69,6 +70,27 @@
>  		reg = <0x40000000 0x80000000>;
>  	};
>  
> +	sound {
> +		compatible = "simple-audio-card";
> +		simple-audio-card,name = "Sun8i Audio Card";

You might have several of them if you're using an internal i2s DAI
with a codec too. What about "a33-codec" or something alike?

> +		simple-audio-card,format = "i2s";
> +		simple-audio-card,frame-master = <&link_codec>;
> +		simple-audio-card,bitclock-master = <&link_codec>;
> +		simple-audio-card,mclk-fs = <512>;
> +		simple-audio-card,aux-devs = <&codec_analog>;
> +		simple-audio-card,routing =
> +				"Left DAC", "Digital Left DAC",
> +				"Right DAC", "Digital Right DAC";

This will be enabled all the time (even if your DAI and codec are
not), which means that the driver will probe and.. do nothing. You
probably want to disable it here.

> +
> +		simple-audio-card,cpu {
> +			sound-dai = <&dai>;
> +		};
> +
> +		link_codec: simple-audio-card,codec {
> +			sound-dai = <&codec>;
> +		};
> +	};
> +
>  	soc at 01c00000 {
>  		tcon0: lcd-controller at 01c0c000 {
>  			compatible = "allwinner,sun8i-a33-tcon";
> @@ -116,6 +138,31 @@
>  			reset-names = "ahb";
>  		};
>  
> +		dai: dai at 01c22c00 {
> +			#sound-dai-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-i2s";
> +			reg = <0x01c22c00 0x200>;
> +			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
> +			clock-names = "apb", "mod";
> +			resets = <&ccu RST_BUS_CODEC>;
> +			reset-names = "rst";
> +			dmas = <&dma 15>, /* AUDIO_CODEC port */
> +				<&dma 15>; /* AUDIO_CODEC port */

There's no need for those comments.

Thanks!
Maxime 

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/7bc16a97/attachment.sig>

^ permalink raw reply

* [PATCH v2 1/8] ARM: dts: armada-370-rd: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-2-f.fainelli@gmail.com>

On Thu, Jan 05, 2017 at 11:29:50AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Tested-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* [PATCH v2 2/8] ARM: dts: armada-385-linksys: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-17 17:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-3-f.fainelli@gmail.com>

On Thu, Jan 05, 2017 at 11:29:51AM -0800, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

^ permalink raw reply

* [PATCH v2 2/4] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-17 17:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117090456.fgw6lpqgurwwcczj@lukather>



17.01.2017, 17:05, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> Hi,
>
> On Tue, Jan 17, 2017 at 02:01:14AM +0800, Icenowy Zheng wrote:
>> ?V3s has a similar but cut-down CCU to H3.
>>
>> ?Add support for it.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ?---
>
> Output from checkpatch:
> total: 5 errors, 2 warnings, 3 checks, 857 lines checked

I remembered some errors' code is directly derived from ccu-sun8i-h3.c,
so I generated a patch file for "clk: sunxi-ng: Add H3 clocks" and run
checkpatch on it:
total: 4 errors, 5 warnings, 1159 lines checked

Should I still get all errors fixed?

>
>> ?I think I should make a comparsion between V3s and H3 CCU here:
>> ?(I won't mention the missing/added clocks here, only list conflicting clocks)
>
> That should be in your commit log.
>
>> ?- "bus-ehci0" is at different bit (The bit that is "bus-ehci0" on V3s is
>> ???"bus-ehci2" on H3)
>> ?- The mux of "ce" is different. (According the view at V3s datasheet by the
>> ???author of sun4i-ss, V3s may have sun4i-ss, not sun8i-ce)
>> ?- The mux of "de" is different. (V3s do not have "pll-de", but it can mux "de"
>> ???to "pll-video")
>> ?- Clocks about CSI largely differs. (As V3s is designed as a camera SoC, and
>> ???it have an extra "pll-isp")
>
> OK.
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

^ permalink raw reply

* [RFC 0/8] Provide the EL1 physical timer to the VM
From: Marc Zyngier @ 2017-01-17 17:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482772326-29110-1-git-send-email-jintack@cs.columbia.edu>

On 26/12/16 17:11, Jintack Lim wrote:
> The ARM architecture defines the EL1 physical timer and the virtual
> timer, and it is reasonable for an OS to expect to be able to access
> both.  However, the current KVM implementation does not provide the EL1
> physical timer to VMs but terminates VMs on access to the timer.
> 
> On VHE systems, this would be as simple as allowing full access to the
> EL1 physical timer to VMs because the KVM host does not use the EL1
> physical timer.  However, on non-VHE systems, the KVM host already uses
> the EL1 physical timer which prevents us from granting full access of
> the EL1 physical timer to VMs.
> 
> This patchset enables VMs to use the EL1 physical timer through
> trap-and-emulate.  The KVM host emulates each EL1 physical timer
> register access and sets up the background timer accordingly.  When the
> background timer expires, the KVM host injects EL1 physical timer
> interrupts to the VM.  Alternatively, it's also possible to allow VMs to
> access the EL1 physical timer without trapping.  However, this requires
> somehow using the EL2 physical timer for the Linux host while running
> the VM instead of the EL1 physical timer.  Right now I just implemented
> trap-and-emulate because this was straightforward to do, and I leave it
> to future work to determine if transferring the EL1 physical timer state
> to the EL2 timer provides any performance benefit.
> 
> This feature will be useful for any OS that wishes to access the EL1
> physical timer. Nested virtualization is one of those use cases. A
> nested hypervisor running inside a VM would think it has full access to
> the hardware and naturally tries to use the EL1 physical timer as Linux
> would do. Other nested hypervisors may try to use the EL2 physical timer
> as Xen would do, but supporting the EL2 physical timer to the VM is out
> of scope of this patchset. This patchset will make it easy to add the
> EL2 timer support in the future, though.
> 
> Note, Linux VMs booting in EL1 will be unaffected by this patch set and
> will continue to use only the virtual timer and this patch set will
> therefore not introduce any performance degredation as a result of
> trap-and-emulate.

Hi Jintack,

Any chance you could address Christoffer's comments and respin this
series? This looks like a good enhancement to our emulation, and
definitely a requirement for the nested work, so I'm obviously keen on it.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

^ permalink raw reply

* [PATCH] arm64: mm: fix __page_to_voff definition
From: Oleksandr Andrushchenko @ 2017-01-17 17:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170117161546.GF11939@leverpostej>

On 01/17/2017 06:15 PM, Mark Rutland wrote:
> On Tue, Jan 17, 2017 at 05:23:53PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
>>
>> Fix parameter name for __page_to_voff, to match its definition.
>> There are other callers of page_to_virt which do not
>> declare 'page'.
>>
>> Fixes: 3fa72fe9c614 ("arm64: mm: fix __page_to_voff definition")
>> Signed-off-by: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
> I take it this is because it messes up the 'struct page' at the end of
> the macro expansion?
yes, you got it right
> It would be good to explicitly state that, since that's not immediately
> obvious.
Will do that in patch v1
>
> With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Can I put your ack into the v1?
>
> Thanks,
> Mark.
Thanks,
Oleksandr
>> ---
>>   arch/arm64/include/asm/memory.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index bfe632808d77..90c39a662379 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -222,7 +222,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>   #define _virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
>>   #else
>>   #define __virt_to_pgoff(kaddr)	(((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
>> -#define __page_to_voff(page)	(((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
>> +#define __page_to_voff(kaddr)	(((u64)(kaddr) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
>>   
>>   #define page_to_virt(page)	((void *)((__page_to_voff(page)) | PAGE_OFFSET))
>>   #define virt_to_page(vaddr)	((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
>> -- 
>> 2.7.4
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [RFC 0/8] Provide the EL1 physical timer to the VM
From: Jintack Lim @ 2017-01-17 17:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <b15297e4-1b30-27f8-dd43-fb1a85bd2cd5@arm.com>

On Tue, Jan 17, 2017 at 12:09 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 26/12/16 17:11, Jintack Lim wrote:
>> The ARM architecture defines the EL1 physical timer and the virtual
>> timer, and it is reasonable for an OS to expect to be able to access
>> both.  However, the current KVM implementation does not provide the EL1
>> physical timer to VMs but terminates VMs on access to the timer.
>>
>> On VHE systems, this would be as simple as allowing full access to the
>> EL1 physical timer to VMs because the KVM host does not use the EL1
>> physical timer.  However, on non-VHE systems, the KVM host already uses
>> the EL1 physical timer which prevents us from granting full access of
>> the EL1 physical timer to VMs.
>>
>> This patchset enables VMs to use the EL1 physical timer through
>> trap-and-emulate.  The KVM host emulates each EL1 physical timer
>> register access and sets up the background timer accordingly.  When the
>> background timer expires, the KVM host injects EL1 physical timer
>> interrupts to the VM.  Alternatively, it's also possible to allow VMs to
>> access the EL1 physical timer without trapping.  However, this requires
>> somehow using the EL2 physical timer for the Linux host while running
>> the VM instead of the EL1 physical timer.  Right now I just implemented
>> trap-and-emulate because this was straightforward to do, and I leave it
>> to future work to determine if transferring the EL1 physical timer state
>> to the EL2 timer provides any performance benefit.
>>
>> This feature will be useful for any OS that wishes to access the EL1
>> physical timer. Nested virtualization is one of those use cases. A
>> nested hypervisor running inside a VM would think it has full access to
>> the hardware and naturally tries to use the EL1 physical timer as Linux
>> would do. Other nested hypervisors may try to use the EL2 physical timer
>> as Xen would do, but supporting the EL2 physical timer to the VM is out
>> of scope of this patchset. This patchset will make it easy to add the
>> EL2 timer support in the future, though.
>>
>> Note, Linux VMs booting in EL1 will be unaffected by this patch set and
>> will continue to use only the virtual timer and this patch set will
>> therefore not introduce any performance degredation as a result of
>> trap-and-emulate.
>
> Hi Jintack,
>
> Any chance you could address Christoffer's comments and respin this
> series? This looks like a good enhancement to our emulation, and
> definitely a requirement for the nested work, so I'm obviously keen on it.

Hi Marc,

Yes, I plan to respin this patch series this week.

Thanks,
Jintack

>
> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...
>

^ permalink raw reply


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