* [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-15 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87po7gmlcs.fsf@free-electrons.com>
Hello Baruch and Gregory,
On Fri, 15 Dec 2017 09:44:19 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On ven., d?c. 15 2017, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
>
> > Hello Baruch,
> >
> > On Fri, 15 Dec 2017 10:27:59 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> >
> >> Hi Miquel
> >>
> >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> >> > +- marvell,thermal-zone-name: The name to identify the thermal
> >> > zone
> >> > + within the sysfs, useful when
> >> > multiple
> >> > + thermal zones are registered (AP,
> >> > CPx...).
> >>
> >> I don't think that would be acceptable. DT is about describing the
> >> hardware. sysfs is a Linux implementation detail which is not tied
> >> to any specific hardware. If this is accepted, the property should
> >> be named 'linux,thermal-zone-name'.
> >
> > You are right the sysfs mention should not appear in the
> > description.
Actually, you are right for all of it, this property should not
exist, sorry for my too quick answer.
> >
> > Otherwise for the naming I'm not sure "linux," is a valid prefix in
> > that case.
Thank you both for your explanations, I was also wrong about the prefix.
>
> Actually the choice between linux or marvell make me realize that
> there is something wrong. Having a name associated to a device is
> something pretty usual with the device tree, however it is as the
> class device level, such as clock-names, line-name, or
> regulator-name. So in my opinion if we want to support naming from
> device tree it would be done for all the thermal device not just for
> the Marvell one.
>
> However I don't think we need it. For example for the clocks we
> created the name dynamically using of the base address of the
> register to keep them unique.
I was convinced that dev_name's would be the same but after trying it on
a 8040-DB, using dev_name(&pdev->dev) gives:
f06f808c.thermal
f2400078.thermal
f4400078.thermal
which I found meaningful enough.
I will drop the property and use dev_name instead. I still need your
help to solve one problem though: how to make the distinction between
using "armada_thermal" (the previous name) and dev_name() ? If I don't
it kind of breaks userspace, doesn't it ?
Thank you,
Miqu?l
^ permalink raw reply
* [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Maxime Ripard @ 2017-12-15 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204174511.a5be3b521e9a7c7004d32d0d@magewell.com>
Hi Yong,
On Mon, Dec 04, 2017 at 05:45:11PM +0800, Yong wrote:
> I just noticed that you are using the second iteration?
> Have you received my third iteration?
Sorry for the late reply, and for not coming back to you yet about
that test. No, this is still in your v2. I've definitely received your
v3, I just didn't have time to update to it yet.
But don't worry, my mail was mostly to know if you had tested that
setup on your side to try to nail down the issue on my end, not really
a review or comment that would prevent your patch from going in.
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/89668106/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: defconfig: Select schedutil as default cpufreq governor
From: Viresh Kumar @ 2017-12-15 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af12e002bc165844101830c0eb00e283b536a879.1510813288.git.viresh.kumar@linaro.org>
On 16-11-17, 11:51, Viresh Kumar wrote:
> Currently performance governor is getting selected by default, which is
> surely not a very good choice as its pretty much power hungry.
>
> Select schedutil instead.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 34480e9af2e7..9424a7aafdb2 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -93,6 +93,7 @@ CONFIG_HIBERNATION=y
> CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
> CONFIG_ARM_CPUIDLE=y
> CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y
> CONFIG_CPUFREQ_DT=y
> CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
> CONFIG_ARM_SCPI_CPUFREQ=y
Ping !!
--
viresh
^ permalink raw reply
* [PATCH 12/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 8K
From: Gregory CLEMENT @ 2017-12-15 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3m4l1wi.fsf@free-electrons.com>
Hi,
On ven., d?c. 15 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On jeu., d?c. 07 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
>
>> Use the new bindings of the reworked Marvell NAND controller driver.
>> Also adapt the nand controller node organization to distinguish which
>> property is relevant for the controller, and which one is NAND chip
>> specific. Expose the partitions as a subnode of the NAND chip.
>>
>> Remove the 'marvell,nand-enable-arbiter' property, not needed anymore as
>> the driver activates the arbiter by default for all boards (either
>> needed or harmless).
>>
>> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
>
> Applied on mvebu/dt64
As for the other paych, I have been said that actually thess changes are
not ready and that we should wait for the driver would me merged first
so I moved it on mvebu/dt64-nand
Gregory
>
> Thanks,
>
> Gregory
>
>> ---
>> arch/arm64/boot/dts/marvell/armada-8040-db.dts | 46 +++++++++++++---------
>> .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 10 ++---
>> 2 files changed, 32 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
>> index b1f6cccc5081..c25ac3fa9aec 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
>> +++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
>> @@ -272,27 +272,35 @@
>> * Proper NAND usage will require DPR-76 to be in position 1-2, which disables
>> * MDIO signal of CP1.
>> */
>> -&cps_nand {
>> - num-cs = <1>;
>> +&cps_nand_controller {
>> pinctrl-0 = <&nand_pins>, <&nand_rb>;
>> pinctrl-names = "default";
>> - nand-ecc-strength = <4>;
>> - nand-ecc-step-size = <512>;
>> - marvell,nand-enable-arbiter;
>> - marvell,system-controller = <&cps_syscon0>;
>> - nand-on-flash-bbt;
>> -
>> - partition at 0 {
>> - label = "U-Boot";
>> - reg = <0 0x200000>;
>> - };
>> - partition at 200000 {
>> - label = "Linux";
>> - reg = <0x200000 0xe00000>;
>> - };
>> - partition at 1000000 {
>> - label = "Filesystem";
>> - reg = <0x1000000 0x3f000000>;
>> +
>> + nand at 0 {
>> + reg = <0>;
>> + marvell,rb = <0>;
>> + nand-on-flash-bbt;
>> + nand-ecc-strength = <4>;
>> + nand-ecc-step-size = <512>;
>> +
>> + partitions {
>> + compatible = "fixed-partitions";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + partition at 0 {
>> + label = "U-Boot";
>> + reg = <0 0x200000>;
>> + };
>> + partition at 200000 {
>> + label = "Linux";
>> + reg = <0x200000 0xe00000>;
>> + };
>> + partition at 1000000 {
>> + label = "Filesystem";
>> + reg = <0x1000000 0x3f000000>;
>> + };
>> + };
>> };
>> };
>>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
>> index cb1fb49ccf81..8610163bb1a4 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
>> @@ -310,20 +310,20 @@
>> status = "disabled";
>> };
>>
>> - cps_nand: nand at 720000 {
>> + cps_nand_controller: nand at 720000 {
>> /*
>> * Due to the limiation of the pin available
>> * this controller is only usable on the CPM
>> * for A7K and on the CPS for A8K.
>> */
>> - compatible = "marvell,armada370-nand",
>> - "marvell,armada-8k-nand";
>> + compatible = "marvell,armada-8k-nand-controller",
>> + "marvell,armada370-nand-controller";
>> reg = <0x720000 0x54>;
>> #address-cells = <1>;
>> - #size-cells = <1>;
>> + #size-cells = <0>;
>> interrupts = <ICU_GRP_NSR 115 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&cps_clk 1 2>;
>> - marvell,system-controller = <&cpm_syscon0>;
>> + marvell,system-controller = <&cps_syscon0>;
>> status = "disabled";
>> };
>>
>> --
>> 2.11.0
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 11/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 7K
From: Gregory CLEMENT @ 2017-12-15 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87374cmghe.fsf@free-electrons.com>
Hi,
On ven., d?c. 15 2017, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On jeu., d?c. 07 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
>
>> Use the new bindings of the reworked Marvell NAND controller driver.
>> Also adapt the nand controller node organization to distinguish which
>> property is relevant for the controller, and which one is NAND chip
>> specific. Expose the partitions as a subnode of the NAND chip.
>>
>> Remove the 'marvell,nand-enable-arbiter' property, not needed anymore as
>> the driver activates the arbiter by default for all boards (either
>> needed or harmless).
>>
>> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
>
> Applied on mvebu/dt64
Well I have been said that actually thess changes are not ready and that
we should wait for the driver would me merged first so I moved it on
mvebu/dt64-nand
>
> Thanks,
>
> Gregory
>
>> ---
>> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 52 +++++++++++++---------
>> .../boot/dts/marvell/armada-cp110-master.dtsi | 8 ++--
>> 2 files changed, 36 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
>> index 52b5341cb270..758452c10612 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
>> +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
>> @@ -156,36 +156,48 @@
>> };
>> };
>>
>> -&cpm_nand {
>> +&cpm_nand_controller {
>> /*
>> * SPI on CPM and NAND have common pins on this board. We can
>> - * use only one at a time. To enable the NAND (whihch will
>> + * use only one at a time. To enable the NAND (which will
>> * disable the SPI), the "status = "okay";" line have to be
>> * added here.
>> */
>> - num-cs = <1>;
>> pinctrl-0 = <&nand_pins>, <&nand_rb>;
>> pinctrl-names = "default";
>> - nand-ecc-strength = <4>;
>> - nand-ecc-step-size = <512>;
>> - marvell,nand-enable-arbiter;
>> - nand-on-flash-bbt;
>> -
>> - partition at 0 {
>> - label = "U-Boot";
>> - reg = <0 0x200000>;
>> - };
>> - partition at 200000 {
>> - label = "Linux";
>> - reg = <0x200000 0xe00000>;
>> - };
>> - partition at 1000000 {
>> - label = "Filesystem";
>> - reg = <0x1000000 0x3f000000>;
>> +
>> + nand at 0 {
>> + reg = <0>;
>> + label = "pxa3xx_nand-0";
>> + marvell,rb = <0>;
>> + nand-on-flash-bbt;
>> + nand-ecc-strength = <4>;
>> + nand-ecc-step-size = <512>;
>> +
>> + partitions {
>> + compatible = "fixed-partitions";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + partition at 0 {
>> + label = "U-Boot";
>> + reg = <0 0x200000>;
>> + };
>> +
>> + partition at 200000 {
>> + label = "Linux";
>> + reg = <0x200000 0xe00000>;
>> + };
>> +
>> + partition at 1000000 {
>> + label = "Filesystem";
>> + reg = <0x1000000 0x3f000000>;
>> + };
>> +
>> + };
>> };
>> };
>>
>> -
>> &cpm_spi1 {
>> status = "okay";
>>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
>> index e3b64d03fbd8..8a3cff9a7343 100644
>> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
>> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
>> @@ -309,17 +309,17 @@
>> status = "disabled";
>> };
>>
>> - cpm_nand: nand at 720000 {
>> + cpm_nand_controller: nand at 720000 {
>> /*
>> * Due to the limiation of the pin available
>> * this controller is only usable on the CPM
>> * for A7K and on the CPS for A8K.
>> */
>> - compatible = "marvell,armada-8k-nand",
>> - "marvell,armada370-nand";
>> + compatible = "marvell,armada-8k-nand-controller",
>> + "marvell,armada370-nand-controller";
>> reg = <0x720000 0x54>;
>> #address-cells = <1>;
>> - #size-cells = <1>;
>> + #size-cells = <0>;
>> interrupts = <ICU_GRP_NSR 115 IRQ_TYPE_LEVEL_HIGH>;
>> clocks = <&cpm_clk 1 2>;
>> marvell,system-controller = <&cpm_syscon0>;
>> --
>> 2.11.0
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler
From: Marc Zyngier @ 2017-12-15 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215101053.GZ910@cbox>
On 15/12/17 10:10, Christoffer Dall wrote:
> On Fri, Dec 15, 2017 at 09:09:05AM +0000, Marc Zyngier wrote:
>> On 15/12/17 02:27, Jia He wrote:
>>>
>>>
>>
>> [...]
>>
>>>> @@ -367,6 +368,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>>>>
>>>> /* Disable the virtual timer */
>>>> write_sysreg_el0(0, cntv_ctl);
>>>> + isb();
>>> My only concern is whether this isb() is required here?
>>> Sorryif this is a stupid question.I understand little about arm arch
>>> memory barrier. But seems isb will flush all the instruction prefetch.Do
>>> you think if an timer interrupt irq arrives, arm will use the previous
>>> instruction prefetch?
>>
>>
>> This barrier has little to do with prefetch. It just guarantees that the
>> code after the isb() is now running with a disabled virtual timer.
>> Otherwise, a CPU can freely reorder the write_sysreg() until the next
>> context synchronization event.
>>
>> An interrupt coming between the write and the barrier will also act as a
>> context synchronization event. For more details, see the ARMv8 ARM (the
>> glossary has a section on the concept).
>>
>
> So since an ISB doesn't guarantee that the timer will actually be
> disabled, is it a waste of energy to have it, or should we keep it as a
> best effort kind of thing?
nit: the ISB does offer that guarantee. It is just that the guarantee
doesn't extend to an interrupt that has already been signalled.
The main issue I have with not having an ISB is that it makes it harder
to think of when the disabling actually happens. The disabling could be
delayed for a very long time, and would make things harder to debug if
they were going wrong.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 0/5] Introduce PMSAv8 memory protection unit
From: Vladimir Murzin @ 2017-12-15 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0B16DB97-D4E6-4DEE-A03F-FD215475C448@esh.hu>
Hi,
On 15/12/17 10:21, Szemz? Andr?s wrote:
> Hi,
>
>> On 2017. Dec 13., at 18:02, Vladimir Murzin <vladimir.murzin@arm.com> wrote:
>>
>> Hi,
>>
>> This series is an attempt to add support for PMSAv8 MPU defined by
>> ARMv8R/M architecture.
>>
>> I'm have a doubt about adding dedicated config option, so both v7 and
>> v8 versions of PMSA are covered with CONFIG_MPU, but I'd glad to hear
>> what people think of it.
>>
>> Thanks!
>>
>> Vladimir Murzin (5):
>> ARM: NOMMU: Move PMSAv7 MPU under it's own namespace
>> ARM: NOMMU: Reorganise __setup_mpu
>> ARM: NOMMU: Postpone MPU activation till __after_proc_init
>> ARM: NOMMU: Make _stext and _end meet PMSAv8 alignment restrictions
>> ARM: NOMMU: Support PMSAv8 MPU
>>
>
> I?ve tested this series on my Atmel armv7m board, and it doesn?t break anything on my side.
> (My test setup is running kernel from SDRAM, with rootfs on SDcard, so no XIP was tested)
>
> FWIW, you can add my Tested-by for patches 1-4.
Mach appreciated!
Cheers
Vladimir
>
> Thanks!
>
> Regards,
> Andras
>
>
>
>
^ permalink raw reply
* [PATCH 12/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 8K
From: Gregory CLEMENT @ 2017-12-15 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207201814.30411-13-miquel.raynal@free-electrons.com>
Hi Miquel,
On jeu., d?c. 07 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Use the new bindings of the reworked Marvell NAND controller driver.
> Also adapt the nand controller node organization to distinguish which
> property is relevant for the controller, and which one is NAND chip
> specific. Expose the partitions as a subnode of the NAND chip.
>
> Remove the 'marvell,nand-enable-arbiter' property, not needed anymore as
> the driver activates the arbiter by default for all boards (either
> needed or harmless).
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-8040-db.dts | 46 +++++++++++++---------
> .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 10 ++---
> 2 files changed, 32 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> index b1f6cccc5081..c25ac3fa9aec 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
> @@ -272,27 +272,35 @@
> * Proper NAND usage will require DPR-76 to be in position 1-2, which disables
> * MDIO signal of CP1.
> */
> -&cps_nand {
> - num-cs = <1>;
> +&cps_nand_controller {
> pinctrl-0 = <&nand_pins>, <&nand_rb>;
> pinctrl-names = "default";
> - nand-ecc-strength = <4>;
> - nand-ecc-step-size = <512>;
> - marvell,nand-enable-arbiter;
> - marvell,system-controller = <&cps_syscon0>;
> - nand-on-flash-bbt;
> -
> - partition at 0 {
> - label = "U-Boot";
> - reg = <0 0x200000>;
> - };
> - partition at 200000 {
> - label = "Linux";
> - reg = <0x200000 0xe00000>;
> - };
> - partition at 1000000 {
> - label = "Filesystem";
> - reg = <0x1000000 0x3f000000>;
> +
> + nand at 0 {
> + reg = <0>;
> + marvell,rb = <0>;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition at 0 {
> + label = "U-Boot";
> + reg = <0 0x200000>;
> + };
> + partition at 200000 {
> + label = "Linux";
> + reg = <0x200000 0xe00000>;
> + };
> + partition at 1000000 {
> + label = "Filesystem";
> + reg = <0x1000000 0x3f000000>;
> + };
> + };
> };
> };
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index cb1fb49ccf81..8610163bb1a4 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -310,20 +310,20 @@
> status = "disabled";
> };
>
> - cps_nand: nand at 720000 {
> + cps_nand_controller: nand at 720000 {
> /*
> * Due to the limiation of the pin available
> * this controller is only usable on the CPM
> * for A7K and on the CPS for A8K.
> */
> - compatible = "marvell,armada370-nand",
> - "marvell,armada-8k-nand";
> + compatible = "marvell,armada-8k-nand-controller",
> + "marvell,armada370-nand-controller";
> reg = <0x720000 0x54>;
> #address-cells = <1>;
> - #size-cells = <1>;
> + #size-cells = <0>;
> interrupts = <ICU_GRP_NSR 115 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cps_clk 1 2>;
> - marvell,system-controller = <&cpm_syscon0>;
> + marvell,system-controller = <&cps_syscon0>;
> status = "disabled";
> };
>
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 11/12] ARM64: dts: marvell: use reworked NAND controller driver on Armada 7K
From: Gregory CLEMENT @ 2017-12-15 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207201814.30411-12-miquel.raynal@free-electrons.com>
Hi Miquel,
On jeu., d?c. 07 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Use the new bindings of the reworked Marvell NAND controller driver.
> Also adapt the nand controller node organization to distinguish which
> property is relevant for the controller, and which one is NAND chip
> specific. Expose the partitions as a subnode of the NAND chip.
>
> Remove the 'marvell,nand-enable-arbiter' property, not needed anymore as
> the driver activates the arbiter by default for all boards (either
> needed or harmless).
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 52 +++++++++++++---------
> .../boot/dts/marvell/armada-cp110-master.dtsi | 8 ++--
> 2 files changed, 36 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> index 52b5341cb270..758452c10612 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
> @@ -156,36 +156,48 @@
> };
> };
>
> -&cpm_nand {
> +&cpm_nand_controller {
> /*
> * SPI on CPM and NAND have common pins on this board. We can
> - * use only one at a time. To enable the NAND (whihch will
> + * use only one at a time. To enable the NAND (which will
> * disable the SPI), the "status = "okay";" line have to be
> * added here.
> */
> - num-cs = <1>;
> pinctrl-0 = <&nand_pins>, <&nand_rb>;
> pinctrl-names = "default";
> - nand-ecc-strength = <4>;
> - nand-ecc-step-size = <512>;
> - marvell,nand-enable-arbiter;
> - nand-on-flash-bbt;
> -
> - partition at 0 {
> - label = "U-Boot";
> - reg = <0 0x200000>;
> - };
> - partition at 200000 {
> - label = "Linux";
> - reg = <0x200000 0xe00000>;
> - };
> - partition at 1000000 {
> - label = "Filesystem";
> - reg = <0x1000000 0x3f000000>;
> +
> + nand at 0 {
> + reg = <0>;
> + label = "pxa3xx_nand-0";
> + marvell,rb = <0>;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition at 0 {
> + label = "U-Boot";
> + reg = <0 0x200000>;
> + };
> +
> + partition at 200000 {
> + label = "Linux";
> + reg = <0x200000 0xe00000>;
> + };
> +
> + partition at 1000000 {
> + label = "Filesystem";
> + reg = <0x1000000 0x3f000000>;
> + };
> +
> + };
> };
> };
>
> -
> &cpm_spi1 {
> status = "okay";
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index e3b64d03fbd8..8a3cff9a7343 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -309,17 +309,17 @@
> status = "disabled";
> };
>
> - cpm_nand: nand at 720000 {
> + cpm_nand_controller: nand at 720000 {
> /*
> * Due to the limiation of the pin available
> * this controller is only usable on the CPM
> * for A7K and on the CPS for A8K.
> */
> - compatible = "marvell,armada-8k-nand",
> - "marvell,armada370-nand";
> + compatible = "marvell,armada-8k-nand-controller",
> + "marvell,armada370-nand-controller";
> reg = <0x720000 0x54>;
> #address-cells = <1>;
> - #size-cells = <1>;
> + #size-cells = <0>;
> interrupts = <ICU_GRP_NSR 115 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cpm_clk 1 2>;
> marvell,system-controller = <&cpm_syscon0>;
> --
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Lorenzo Pieralisi @ 2017-12-15 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214160957.13716-2-shameerali.kolothum.thodi@huawei.com>
On Thu, Dec 14, 2017 at 04:09:55PM +0000, Shameer Kolothum wrote:
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
>
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> drivers/acpi/arm64/iort.c | 111 +++++++++++++++++++++++++++++++++++++--
> drivers/irqchip/irq-gic-v3-its.c | 3 +-
> include/linux/acpi_iort.h | 7 ++-
> 3 files changed, 116 insertions(+), 5 deletions(-)
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 95255ec..e2f7bdd 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -39,6 +39,7 @@
> struct iort_its_msi_chip {
> struct list_head list;
> struct fwnode_handle *fw_node;
> + phys_addr_t base_addr;
> u32 translation_id;
> };
>
> @@ -161,14 +162,16 @@ typedef acpi_status (*iort_find_node_callback)
> static DEFINE_SPINLOCK(iort_msi_chip_lock);
>
> /**
> - * iort_register_domain_token() - register domain token and related ITS ID
> - * to the list from where we can get it back later on.
> + * iort_register_domain_token() - register domain token along with related
> + * ITS ID and base address to the list from where we can get it back later on.
> * @trans_id: ITS ID.
> + * @base: ITS base address.
> * @fw_node: Domain token.
> *
> * Returns: 0 on success, -ENOMEM if no memory when allocating list element
> */
> -int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
> +int iort_register_domain_token(int trans_id, phys_addr_t base,
> + struct fwnode_handle *fw_node)
> {
> struct iort_its_msi_chip *its_msi_chip;
>
> @@ -178,6 +181,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
>
> its_msi_chip->fw_node = fw_node;
> its_msi_chip->translation_id = trans_id;
> + its_msi_chip->base_addr = base;
>
> spin_lock(&iort_msi_chip_lock);
> list_add(&its_msi_chip->list, &iort_msi_chip_list);
> @@ -581,6 +585,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> return -ENODEV;
> }
>
> +static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
> +{
> + struct iort_its_msi_chip *its_msi_chip;
> + int ret = -ENODEV;
> +
> + spin_lock(&iort_msi_chip_lock);
> + list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
> + if (its_msi_chip->translation_id == its_id) {
> + *base = its_msi_chip->base_addr;
> + ret = 0;
> + break;
> + }
> + }
> + spin_unlock(&iort_msi_chip_lock);
> +
> + return ret;
> +}
> +
> /**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> @@ -766,6 +788,24 @@ static inline bool iort_iommu_driver_enabled(u8 type)
> }
>
> #ifdef CONFIG_IOMMU_API
> +static struct acpi_iort_node *iort_get_msi_resv_iommu(struct device *dev)
> +{
> + struct acpi_iort_node *iommu;
> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> +
> + iommu = iort_get_iort_node(fwspec->iommu_fwnode);
> +
> + if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> + struct acpi_iort_smmu_v3 *smmu;
> +
> + smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> + if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X)
> + return iommu;
> + }
> +
> + return NULL;
> +}
> +
> static inline const struct iommu_ops *iort_fwspec_iommu_ops(
> struct iommu_fwspec *fwspec)
> {
> @@ -782,6 +822,69 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
>
> return err;
> }
> +
> +/**
> + * iort_iommu_msi_get_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @head: Reserved region list from iommu_get_resv_regions()
> + *
> + * Returns: Number of msi reserved regions on success (0 if platform
> + * doesn't require the reservation or no associated msi regions),
> + * appropriate error value otherwise. The ITS interrupt translation
> + * spaces (ITS_base + SZ_64K, SZ_64K) associated with the device
> + * are the msi reserved regions.
> + */
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{
> + struct acpi_iort_its_group *its;
> + struct acpi_iort_node *iommu_node, *its_node = NULL;
> + int i, resv = 0;
> +
> + iommu_node = iort_get_msi_resv_iommu(dev);
> + if (!iommu_node)
> + return 0;
> +
> + /*
> + * Current logic to reserve ITS regions relies on HW topologies
> + * where a given PCI or named component maps its IDs to only one
> + * ITS group; if a PCI or named component can map its IDs to
> + * different ITS groups through IORT mappings this function has
> + * to be reworked to ensure we reserve regions for all ITS groups
> + * a given PCI or named component may map IDs to.
> + */
> +
> + for (i = 0; i < dev->iommu_fwspec->num_ids; i++) {
> + its_node = iort_node_map_id(iommu_node,
> + dev->iommu_fwspec->ids[i],
> + NULL, IORT_MSI_TYPE);
> + if (its_node)
> + break;
> + }
> +
> + if (!its_node)
> + return 0;
> +
> + /* Move to ITS specific data */
> + its = (struct acpi_iort_its_group *)its_node->node_data;
> +
> + for (i = 0; i < its->its_count; i++) {
> + phys_addr_t base;
> +
> + if (!iort_find_its_base(its->identifiers[i], &base)) {
> + int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> + struct iommu_resv_region *region;
> +
> + region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
> + prot, IOMMU_RESV_MSI);
> + if (region) {
> + list_add_tail(®ion->list, head);
> + resv++;
> + }
> + }
> + }
> +
> + return (resv == its->its_count) ? resv : -ENODEV;
> +}
> #else
> static inline const struct iommu_ops *iort_fwspec_iommu_ops(
> struct iommu_fwspec *fwspec)
> @@ -789,6 +892,8 @@ static inline const struct iommu_ops *iort_fwspec_iommu_ops(
> static inline int iort_add_device_replay(const struct iommu_ops *ops,
> struct device *dev)
> { return 0; }
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{ return 0; }
> #endif
>
> static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 4039e64..d4cff12 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3450,7 +3450,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
> return -ENOMEM;
> }
>
> - err = iort_register_domain_token(its_entry->translation_id, dom_handle);
> + err = iort_register_domain_token(its_entry->translation_id, res.start,
> + dom_handle);
> if (err) {
> pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
> &res.start, its_entry->translation_id);
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 2f7a292..38cd77b 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -26,7 +26,8 @@
> #define IORT_IRQ_MASK(irq) (irq & 0xffffffffULL)
> #define IORT_IRQ_TRIGGER_MASK(irq) ((irq >> 32) & 0xffffffffULL)
>
> -int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
> +int iort_register_domain_token(int trans_id, phys_addr_t base,
> + struct fwnode_handle *fw_node);
> void iort_deregister_domain_token(int trans_id);
> struct fwnode_handle *iort_find_domain_token(int trans_id);
> #ifdef CONFIG_ACPI_IORT
> @@ -38,6 +39,7 @@
> /* IOMMU interface */
> void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
> #else
> static inline void acpi_iort_init(void) { }
> static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> @@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
> static inline const struct iommu_ops *iort_iommu_configure(
> struct device *dev)
> { return NULL; }
> +static inline
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{ return 0; }
> #endif
>
> #endif /* __ACPI_IORT_H__ */
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH 1/2] soc: imx: gpc: Add i.MX6SX PCI power domain
From: Fabio Estevam @ 2017-12-15 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513329946.20023.1.camel@pengutronix.de>
Hi Lucas,
On Fri, Dec 15, 2017 at 7:25 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Seems like the GPC rework did turn out to work as expected by making it
> easy to add additional power domains. :)
Yes, thanks for doing the GPC driver rework. It really helped :-)
> I didn't validate the register offsets, so this is:
> Acked-by: Lucas Stach <l.stach@pengutronix.de>
Thanks!
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-h100: use usdhc2 VSELECT
From: Lucas Stach @ 2017-12-15 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215092624.12806-1-m.tretter@pengutronix.de>
Am Freitag, den 15.12.2017, 10:26 +0100 schrieb Michael Tretter:
> The uSDHC controller directly provides a VSELECT signal that can be
> muxed to the external voltage select. Mux the VSELECT directly to
> avoid
> using a GPIO.
>
> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?arch/arm/boot/dts/imx6q-h100.dts | 25 +++----------------------
> ?1 file changed, 3 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-h100.dts
> b/arch/arm/boot/dts/imx6q-h100.dts
> index a3269f57df2b..450ec967c257 100644
> --- a/arch/arm/boot/dts/imx6q-h100.dts
> +++ b/arch/arm/boot/dts/imx6q-h100.dts
> @@ -108,21 +108,6 @@
> ? regulator-always-on;
> ? };
> ?
> - reg_nvcc_sd2: regulator-nvcc-sd2 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_h100_reg_nvcc_sd2>;
> - compatible = "regulator-gpio";
> - regulator-name = "NVCC_SD2";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-type = "voltage";
> - regulator-boot-on;
> - regulator-always-on;
> - gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> - states = <1800000 0x1
> - ??3300000 0x0>;
> - };
> -
> ? reg_usbh1_vbus: regulator-usb-h1-vbus {
> ? compatible = "regulator-fixed";
> ? enable-active-high;
> @@ -260,12 +245,6 @@
> ? >;
> ? };
> ?
> - pinctrl_h100_reg_nvcc_sd2: h100-reg-nvcc-sd2 {
> - fsl,pins = <
> - MX6QDL_PAD_KEY_ROW1__GPIO4_IO09
> 0x1b0b0
> - >;
> - };
> -
> ? pinctrl_h100_sgtl5000: h100-sgtl5000 {
> ? fsl,pins = <
> ? MX6QDL_PAD_DISP0_DAT19__AUD5_RXD
> 0x130b0
> @@ -316,6 +295,7 @@
> ? MX6QDL_PAD_SD2_DAT1__SD2_DATA1
> 0x17059
> ? MX6QDL_PAD_SD2_DAT2__SD2_DATA2
> 0x17059
> ? MX6QDL_PAD_SD2_DAT3__SD2_DATA3
> 0x13059
> + MX6QDL_PAD_KEY_ROW1__SD2_VSELECT
> 0x1b0b0
> ? >;
> ? };
> ?
> @@ -328,6 +308,7 @@
> ? MX6QDL_PAD_SD2_DAT1__SD2_DATA1
> 0x170b9
> ? MX6QDL_PAD_SD2_DAT2__SD2_DATA2
> 0x170b9
> ? MX6QDL_PAD_SD2_DAT3__SD2_DATA3
> 0x170b9
> + MX6QDL_PAD_KEY_ROW1__SD2_VSELECT
> 0x1b0b0
> ? >;
> ? };
> ?
> @@ -340,6 +321,7 @@
> ? MX6QDL_PAD_SD2_DAT1__SD2_DATA1
> 0x170f9
> ? MX6QDL_PAD_SD2_DAT2__SD2_DATA2
> 0x170f9
> ? MX6QDL_PAD_SD2_DAT3__SD2_DATA3
> 0x170f9
> + MX6QDL_PAD_KEY_ROW1__SD2_VSELECT
> 0x1b0b0
> ? >;
> ? };
> ? };
> @@ -389,7 +371,6 @@
> ? pinctrl-1 = <&pinctrl_h100_usdhc2_100mhz>;
> ? pinctrl-2 = <&pinctrl_h100_usdhc2_200mhz>;
> ? vmmc-supply = <®_3p3v>;
> - vqmmc-supply = <®_nvcc_sd2>;
> ? cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> ? status = "okay";
> ?};
^ permalink raw reply
* [RFC PATCH 0/5] Introduce PMSAv8 memory protection unit
From: Szemző András @ 2017-12-15 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184527-44120-1-git-send-email-vladimir.murzin@arm.com>
Hi,
> On 2017. Dec 13., at 18:02, Vladimir Murzin <vladimir.murzin@arm.com> wrote:
>
> Hi,
>
> This series is an attempt to add support for PMSAv8 MPU defined by
> ARMv8R/M architecture.
>
> I'm have a doubt about adding dedicated config option, so both v7 and
> v8 versions of PMSA are covered with CONFIG_MPU, but I'd glad to hear
> what people think of it.
>
> Thanks!
>
> Vladimir Murzin (5):
> ARM: NOMMU: Move PMSAv7 MPU under it's own namespace
> ARM: NOMMU: Reorganise __setup_mpu
> ARM: NOMMU: Postpone MPU activation till __after_proc_init
> ARM: NOMMU: Make _stext and _end meet PMSAv8 alignment restrictions
> ARM: NOMMU: Support PMSAv8 MPU
>
I?ve tested this series on my Atmel armv7m board, and it doesn?t break anything on my side.
(My test setup is running kernel from SDRAM, with rootfs on SDcard, so no XIP was tested)
FWIW, you can add my Tested-by for patches 1-4.
Thanks!
Regards,
Andras
^ permalink raw reply
* [PATCH 02/10] arm64: limit PA size to supported range
From: Suzuki K Poulose @ 2017-12-15 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cdca0649-fa3d-a5ea-a7ee-fc30626ca2fc@arm.com>
On 14/12/17 18:34, Marc Zyngier wrote:
> On 13/12/17 17:07, Kristina Martsenko wrote:
>> We currently copy the physical address size from
>> ID_AA64MMFR0_EL1.PARange directly into TCR.(I)PS. This will not work for
>> 4k and 16k granule kernels on systems that support 52-bit physical
>> addresses, since 52-bit addresses are only permitted with the 64k
>> granule.
>>
>> To fix this, fall back to 48 bits when configuring the PA size when the
>> kernel does not support 52-bit PAs. When it does, fall back to 52, to
>> avoid similar problems in the future if the PA size is ever increased
>> above 52.
>>
>> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
>> ---
>> arch/arm64/include/asm/assembler.h | 13 +++++++++++++
>> arch/arm64/include/asm/sysreg.h | 8 ++++++++
>> arch/arm64/kvm/hyp-init.S | 6 ++----
>> arch/arm64/kvm/hyp/s2-setup.c | 2 ++
>> arch/arm64/mm/proc.S | 6 ++----
>> 5 files changed, 27 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
>> index aef72d886677..6cddf12a0250 100644
>> --- a/arch/arm64/include/asm/assembler.h
>> +++ b/arch/arm64/include/asm/assembler.h
>> @@ -351,6 +351,19 @@ alternative_endif
>> .endm
>>
>> /*
>> + * tcr_set_pa_size - set TCR.(I)PS to the highest supported
>> + * ID_AA64MMFR0_EL1.PARange value
>
> It'd be good to document what are the expected parameters here.
>
>> + */
>> + .macro tcr_set_pa_size, tcr, pos, tmp0, tmp1
>
> Small nit: "tcr_compute_pa_size" would better describe what this does.
>
>> + mrs \tmp0, ID_AA64MMFR0_EL1
>> + ubfx \tmp0, \tmp0, #ID_AA64MMFR0_PARANGE_SHIFT, #3
>
> It'd be good to have a comment explaining that we narrow the PARange to
> fit the PS firld in TCR. Who knows what will happen once (if ever) we
> get two other PARange extentions... ;-)
>
>> + mov \tmp1, #ID_AA64MMFR0_PARANGE_MAX
>> + cmp \tmp0, \tmp1
>> + csel \tmp0, \tmp1, \tmp0, hi
>> + bfi \tcr, \tmp0, \pos, #3> + .endm
>> +
>> +/*
>> * Macro to perform a data cache maintenance for the interval
>> * [kaddr, kaddr + size)
>> *
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index 08cc88574659..ec144f480b39 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -471,6 +471,14 @@
>> #define ID_AA64MMFR0_TGRAN64_SUPPORTED 0x0
>> #define ID_AA64MMFR0_TGRAN16_NI 0x0
>> #define ID_AA64MMFR0_TGRAN16_SUPPORTED 0x1
>> +#define ID_AA64MMFR0_PARANGE_48 0x5
>> +#define ID_AA64MMFR0_PARANGE_52 0x6
>> +
>> +#ifdef CONFIG_ARM64_PA_BITS_52
>> +#define ID_AA64MMFR0_PARANGE_MAX ID_AA64MMFR0_PARANGE_52
>> +#else
>> +#define ID_AA64MMFR0_PARANGE_MAX ID_AA64MMFR0_PARANGE_48
>> +#endif
>>
>> /* id_aa64mmfr1 */
>> #define ID_AA64MMFR1_PAN_SHIFT 20
>> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
>> index 3f9615582377..f731a48bd9f1 100644
>> --- a/arch/arm64/kvm/hyp-init.S
>> +++ b/arch/arm64/kvm/hyp-init.S
>> @@ -90,11 +90,9 @@ __do_hyp_init:
>> bfi x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
>> #endif
>> /*
>> - * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
>> - * TCR_EL2.
>> + * Set the PS bits in TCR_EL2.
>> */
>> - mrs x5, ID_AA64MMFR0_EL1
>> - bfi x4, x5, #16, #3
>> + tcr_set_pa_size x4, #16, x5, x6
>>
>> msr tcr_el2, x4
>>
>> diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
>> index a81f5e10fc8c..603e1ee83e89 100644
>> --- a/arch/arm64/kvm/hyp/s2-setup.c
>> +++ b/arch/arm64/kvm/hyp/s2-setup.c
>> @@ -32,6 +32,8 @@ u32 __hyp_text __init_stage2_translation(void)
>> * PS is only 3. Fortunately, bit 19 is RES0 in VTCR_EL2...
>> */
>> parange = read_sysreg(id_aa64mmfr0_el1) & 7;
>> + if (parange > ID_AA64MMFR0_PARANGE_MAX)
>> + parange = ID_AA64MMFR0_PARANGE_MAX;
>> val |= parange << 16;
>>
>> /* Compute the actual PARange... */
>> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
>> index 95233dfc4c39..c10c6c180961 100644
>> --- a/arch/arm64/mm/proc.S
>> +++ b/arch/arm64/mm/proc.S
>> @@ -228,11 +228,9 @@ ENTRY(__cpu_setup)
>> tcr_set_idmap_t0sz x10, x9
>>
>> /*
>> - * Read the PARange bits from ID_AA64MMFR0_EL1 and set the IPS bits in
>> - * TCR_EL1.
>> + * Set the IPS bits in TCR_EL1.
>> */
>> - mrs x9, ID_AA64MMFR0_EL1
>> - bfi x10, x9, #32, #3
>> + tcr_set_pa_size x10, #32, x5, x6
>> #ifdef CONFIG_ARM64_HW_AFDBM
>> /*
>> * Hardware update of the Access and Dirty bits.
>>
>
> Other than the nits above:
>
Kristina,
If you are spinning another version correcting those, please could you
also add the bit definitions for TCR_EL2_PS and TCR_EL1_IPS and use them
here instead of the constants above ?
Cheers
Suzuki
^ permalink raw reply
* [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler
From: Christoffer Dall @ 2017-12-15 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <519f0e33-4419-68be-32b4-11bb5e19cf17@arm.com>
On Fri, Dec 15, 2017 at 09:09:05AM +0000, Marc Zyngier wrote:
> On 15/12/17 02:27, Jia He wrote:
> >
> >
>
> [...]
>
> >> @@ -367,6 +368,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
> >>
> >> /* Disable the virtual timer */
> >> write_sysreg_el0(0, cntv_ctl);
> >> + isb();
> > My only concern is whether this isb() is required here?
> > Sorryif this is a stupid question.I understand little about arm arch
> > memory barrier. But seems isb will flush all the instruction prefetch.Do
> > you think if an timer interrupt irq arrives, arm will use the previous
> > instruction prefetch?
>
>
> This barrier has little to do with prefetch. It just guarantees that the
> code after the isb() is now running with a disabled virtual timer.
> Otherwise, a CPU can freely reorder the write_sysreg() until the next
> context synchronization event.
>
> An interrupt coming between the write and the barrier will also act as a
> context synchronization event. For more details, see the ARMv8 ARM (the
> glossary has a section on the concept).
>
So since an ISB doesn't guarantee that the timer will actually be
disabled, is it a waste of energy to have it, or should we keep it as a
best effort kind of thing?
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler
From: Christoffer Dall @ 2017-12-15 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5ccbf1c-6078-4c43-8aa3-fc226ed358f7@gmail.com>
On Fri, Dec 15, 2017 at 10:27:02AM +0800, Jia He wrote:
[...]
> >diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> >index 73d262c4712b..544ed15fbbb3 100644
> >--- a/virt/kvm/arm/arch_timer.c
> >+++ b/virt/kvm/arm/arch_timer.c
> >@@ -46,7 +46,7 @@ static const struct kvm_irq_level default_vtimer_irq = {
> > .level = 1,
> > };
> >-static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx);
> >+static bool kvm_timer_irq_can_fire(u32 cnt_ctl);
> > static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> > struct arch_timer_context *timer_ctx);
> > static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
> >@@ -94,6 +94,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> > {
> > struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
> > struct arch_timer_context *vtimer;
> >+ u32 cnt_ctl;
> > if (!vcpu) {
> > pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
> >@@ -101,8 +102,8 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> > }
> > vtimer = vcpu_vtimer(vcpu);
> >- vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> >- if (kvm_timer_irq_can_fire(vtimer))
> >+ cnt_ctl = read_sysreg_el0(cntv_ctl);
> >+ if (kvm_timer_irq_can_fire(cnt_ctl))
> > kvm_timer_update_irq(vcpu, true, vtimer);
> IIUC, your patch makes kvm_arch_timer_handler never changesvtimer->cnt_ctl
Yes, that's the idea.
Meanwhile, I think I thought of a cleaner way to do this. Could you
test the following two patches on your platform as well?
>From 3a594a3aa222bd64a86f6c6afcb209c9be20d5c5 Mon Sep 17 00:00:00 2001
From: Christoffer Dall <christoffer.dall@linaro.org>
Date: Thu, 14 Dec 2017 19:54:50 +0100
Subject: [PATCH 1/2] KVM: arm/arm64: Properly handle arch-timer IRQs after
vtimer_save_state
The recent timer rework was assuming that once the timer was disabled,
we should no longer see any interrupts from the timer. This assumption
turns out to not be true, and instead we have to handle the case when
the timer ISR runs even after the timer has been disabled.
This requires a couple of changes:
First, we should never overwrite the cached guest state of the timer
control register when the ISR runs, because KVM may have disabled its
timers when doing vcpu_put(), even though the guest still had the timer
enabled.
Second, we shouldn't assume that the timer is actually firing just
because we see an ISR, but we should check the ISTATUS field of the
timer control register to understand if the hardware timer is really
firing or not.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index aa9adfafe12b..792bcf6277b6 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -92,16 +92,21 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
{
struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
struct arch_timer_context *vtimer;
+ u32 cnt_ctl;
- if (!vcpu) {
- pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
- return IRQ_NONE;
- }
- vtimer = vcpu_vtimer(vcpu);
+ /*
+ * We may see a timer interrupt after vcpu_put() has been called which
+ * sets the CPU's vcpu pointer to NULL, because even though the timer
+ * has been disabled in vtimer_save_state(), the singal may not have
+ * been retired from the interrupt controller yet.
+ */
+ if (!vcpu)
+ return IRQ_HANDLED;
+ vtimer = vcpu_vtimer(vcpu);
if (!vtimer->irq.level) {
- vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
- if (kvm_timer_irq_can_fire(vtimer))
+ cnt_ctl = read_sysreg_el0(cntv_ctl);
+ if (cnt_ctl & ARCH_TIMER_CTRL_IT_STAT)
kvm_timer_update_irq(vcpu, true, vtimer);
}
>From ed96302b47d209024814df116994f64dc8f07c96 Mon Sep 17 00:00:00 2001
From: Christoffer Dall <christoffer.dall@linaro.org>
Date: Fri, 15 Dec 2017 00:30:12 +0100
Subject: [PATCH 2/2] KVM: arm/arm64: Fix timer enable flow
When enabling the timer on the first run, we fail to ever restore the
state and mark it as loaded. That means, that in the initial entry to
the VCPU ioctl, unless we exit to userspace for some reason such as a
pending signal, if the guest programs a timer and blocks, we will wait
forever, because we never read back the hardware state (the loaded flag
is not set), and so we think the timer is disabled, and we never
schedule a background soft timer.
The end result? The VCPU blocks forever, and the only solution is to
kill the thread.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arch_timer.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 792bcf6277b6..8869658e6983 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -843,10 +843,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
no_vgic:
preempt_disable();
timer->enabled = 1;
- if (!irqchip_in_kernel(vcpu->kvm))
- kvm_timer_vcpu_load_user(vcpu);
- else
- kvm_timer_vcpu_load_vgic(vcpu);
+ kvm_timer_vcpu_load(vcpu);
preempt_enable();
return 0;
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
From: Geert Uytterhoeven @ 2017-12-15 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <TY1PR06MB0895D343C77D0DB2E9F14680C00B0@TY1PR06MB0895.apcprd06.prod.outlook.com>
Hi Fabrizio,
On Fri, Dec 15, 2017 at 10:48 AM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
>> Subject: Re: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
>> On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
>> <fabrizio.castro@bp.renesas.com> wrote:
>> > RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
>> > by default.
>> >
>> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
>> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>>
>> Thanks for your patch!
>
> Thank you for your feedback.
>
>>
>> If I'm not mistaken, there are no current users of this PWM block in the
>> current R-Car Gen2 and RZ/G1 DTS files?
>
> PWM support will be needed very soon as we are going to use pwm3 on the iwg20d platform to control the RGB display backlight.
Good to know, thanks!
> The work to add display support is in progress, I hope it will be ready by next week, would you rather I sent this patch with the series to add display support?
That's up to Simon. But I guess it doesn't matter much, as defconfig updates
are queued in a separate branch anyway.
You may want to send a similar patch for multi_v7_defconfig.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
From: Fabrizio Castro @ 2017-12-15 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWUaQMgT4J0N+hrByAD12K-oO0+iNyDeVczS3nxr5ia9A@mail.gmail.com>
Hi Geert,
> Subject: Re: [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
>
> Hi Fabrizio,
>
> On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> > RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
> > by default.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
>
> Thanks for your patch!
Thank you for your feedback.
>
> If I'm not mistaken, there are no current users of this PWM block in the
> current R-Car Gen2 and RZ/G1 DTS files?
PWM support will be needed very soon as we are going to use pwm3 on the iwg20d platform to control the RGB display backlight.
The work to add display support is in progress, I hope it will be ready by next week, would you rather I sent this patch with the series to add display support?
Thanks,
Fab
> If that's correct, I don't think it makes much sense to enable it already.
>
> Simon: what do you think?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Ard Biesheuvel @ 2017-12-15 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085924.sqlcwm4copzba5ag@fireball>
On 15 December 2017 at 09:59, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>> On 13 December 2017 at 12:16, AKASHI Takahiro
>> <takahiro.akashi@linaro.org> wrote:
>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
>> >> <takahiro.akashi@linaro.org> wrote:
>> >> > Bhupesh, Ard,
>> >> >
>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>> >> >> Hi Ard, Akashi
>> >> >>
>> >> > (snip)
>> >> >
>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>> >> >> identify its own usable memory and exclude, at its boot time, any
>> >> >> other memory areas that are part of the panicked kernel's memory.
>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>> >> >> , for details)
>> >> >
>> >> > Right.
>> >> >
>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>> >> >> with the crashkernel memory range:
>> >> >>
>> >> >> /* add linux,usable-memory-range */
>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>> >> >> address_cells, size_cells);
>> >> >>
>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>> >> >> , for details)
>> >> >>
>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>> >> >> they are marked as System RAM or as RESERVED. As,
>> >> >> 'linux,usable-memory-range' dt node is patched up only with
>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>> >> >>
>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
>> >> >> ACPI memory and crashes while trying to access the same:
>> >> >>
>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>> >> >> -r`.img --reuse-cmdline -d
>> >> >>
>> >> >> [snip..]
>> >> >>
>> >> >> Reserved memory range
>> >> >> 000000000e800000-000000002e7fffff (0)
>> >> >>
>> >> >> Coredump memory ranges
>> >> >> 0000000000000000-000000000e7fffff (0)
>> >> >> 000000002e800000-000000003961ffff (0)
>> >> >> 0000000039d40000-000000003ed2ffff (0)
>> >> >> 000000003ed60000-000000003fbfffff (0)
>> >> >> 0000001040000000-0000001ffbffffff (0)
>> >> >> 0000002000000000-0000002ffbffffff (0)
>> >> >> 0000009000000000-0000009ffbffffff (0)
>> >> >> 000000a000000000-000000affbffffff (0)
>> >> >>
>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>> >> >> memory cap'ing passed to the crash kernel inside
>> >> >> 'arch/arm64/mm/init.c' (see below):
>> >> >>
>> >> >> static void __init fdt_enforce_memory_region(void)
>> >> >> {
>> >> >> struct memblock_region reg = {
>> >> >> .size = 0,
>> >> >> };
>> >> >>
>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>> >> >>
>> >> >> if (reg.size)
>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>> >> >> comment this out */
>> >> >> }
>> >> >
>> >> > Please just don't do that. It can cause a fatal damage on
>> >> > memory contents of the *crashed* kernel.
>> >> >
>> >> >> 5). Both the above temporary solutions fix the problem.
>> >> >>
>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>> >> >> fail.
>> >> >>
>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>> >> >> dt node 'linux,usable-memory-range'
>> >> >
>> >> > I still don't understand why we need to carry over the information
>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>> >> > such regions are free to be reused by the kernel after some point of
>> >> > initialization. Why does crash dump kernel need to know about them?
>> >> >
>> >>
>> >> Not really. According to the UEFI spec, they can be reclaimed after
>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>> >> no longer needs them. Of course, in order to be able to boot a kexec
>> >> kernel, those regions needs to be preserved, which is why they are
>> >> memblock_reserve()'d now.
>> >
>> > For my better understandings, who is actually accessing such regions
>> > during boot time, uefi itself or efistub?
>> >
>>
>> No, only the kernel. This is where the ACPI tables are stored. For
>> instance, on QEMU we have
>>
>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>> 01000013)
>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>> BXPC 00000001)
>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>> BXPC 00000001)
>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>> BXPC 00000001)
>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>> BXPC 00000001)
>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>> BXPC 00000001)
>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>> BXPC 00000001)
>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>> BXPC 00000001)
>>
>> covered by
>>
>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>> ...
>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>
> OK. I mistakenly understood those regions could be freed after exiting
> UEFI boot services.
>
>>
>> >> So it seems that kexec does not honour the memblock_reserve() table
>> >> when booting the next kernel.
>> >
>> > not really.
>> >
>> >> > (In other words, can or should we skip some part of ACPI-related init code
>> >> > on crash dump kernel?)
>> >> >
>> >>
>> >> I don't think so. And the change to the handling of ACPI reclaim
>> >> regions only revealed the bug, not created it (given that other
>> >> memblock_reserve regions may be affected as well)
>> >
>> > As whether we should honor such reserved regions over kexec'ing
>> > depends on each one's specific nature, we will have to take care one-by-one.
>> > As a matter of fact, no information about "reserved" memblocks is
>> > exposed to user space (via proc/iomem).
>> >
>>
>> That is why I suggested (somewhere in this thread?) to not expose them
>> as 'System RAM'. Do you think that could solve this?
>
> Memblock-reserv'ing them is necessary to prevent their corruption and
> marking them under another name in /proc/iomem would also be good in order
> not to allocate them as part of crash kernel's memory.
>
I agree. However, this may not be entirely trivial, since iterating
over the memblock_reserved table and creating iomem entries may result
in collisions.
> But I'm not still convinced that we should export them in useable-
> memory-range to crash dump kernel. They will be accessed through
> acpi_os_map_memory() and so won't be required to be part of system ram
> (or memblocks), I guess.
Agreed. They will be covered by the linear mapping in the boot kernel,
and be mapped explicitly via ioremap_cache() in the kexec kernel,
which is exactly what we want in this case.
> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> via a kernel command line parameter, "memmap=".
>
^ permalink raw reply
* [PATCH v4 2/4] ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
From: Claudiu Beznea @ 2017-12-15 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d5b5421-1c1a-f293-e197-7a1a673ddbaa@microchip.com>
On 14.12.2017 12:44, Claudiu Beznea wrote:
>
>
> On 13.12.2017 16:44, hao_zhang wrote:
>> This patch add allwinner sun8i R40/V40/T3 pwm support.
>>
>> Signed-off-by: hao_zhang <hao5781286@gmail.com>
>> ---
>> drivers/pwm/Kconfig | 10 +
>> drivers/pwm/Makefile | 1 +
>> drivers/pwm/pwm-sun8i-r40.c | 449 ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 460 insertions(+)
>> create mode 100644 drivers/pwm/pwm-sun8i-r40.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 763ee50..cde5a70 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -444,6 +444,16 @@ config PWM_SUN4I
>> To compile this driver as a module, choose M here: the module
>> will be called pwm-sun4i.
>>
>> +config PWM_SUN8I_R40
>> + tristate "Allwinner PWM SUN8I R40 support"
>> + depends on ARCH_SUNXI || COMPILE_TEST
>> + depends on HAS_IOMEM && COMMON_CLK
>> + help
>> + Generic PWM framework driver for Allwinner SoCs R40, V40, T3.
>> +
>> + To compile this driver as a module, choose M here: the module
>> + will be called pwm-sun8i-r40.
>> +
>> config PWM_TEGRA
>> tristate "NVIDIA Tegra PWM support"
>> depends on ARCH_TEGRA
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index 0258a74..026a55b 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -44,6 +44,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
>> obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o
>> obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
>> obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
>> +obj-$(CONFIG_PWM_SUN8I_R40) += pwm-sun8i-r40.o
>> obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
>> obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
>> obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
>> diff --git a/drivers/pwm/pwm-sun8i-r40.c b/drivers/pwm/pwm-sun8i-r40.c
>> new file mode 100644
>> index 0000000..8df538d
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-sun8i-r40.c
>> @@ -0,0 +1,449 @@
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pwm.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/time.h>
>> +
>> +#define PWM_IRQ_ENABLE_REG 0x0000
>> +#define PCIE(ch) BIT(ch)
>> +
>> +#define PWM_IRQ_STATUS_REG 0x0004
>> +#define PIS(ch) BIT(ch)
>> +
>> +#define CAPTURE_IRQ_ENABLE_REG 0x0010
>> +#define CFIE(ch) BIT(ch << 1 + 1)
>> +#define CRIE(ch) BIT(ch << 1)
>> +
>> +#define CAPTURE_IRQ_STATUS_REG 0x0014
>> +#define CFIS(ch) BIT(ch << 1 + 1)
>> +#define CRIS(ch) BIT(ch << 1)
>> +
>> +#define CLK_CFG_REG(ch) (0x0020 + (ch >> 1) * 4)
>> +#define CLK_SRC BIT(7)
>> +#define CLK_SRC_BYPASS_SEC BIT(6)
>> +#define CLK_SRC_BYPASS_FIR BIT(5)
>> +#define CLK_GATING BIT(4)
>> +#define CLK_DIV_M GENMASK(3, 0)
>> +
>> +#define PWM_DZ_CTR_REG(ch) (0x0030 + (ch >> 1) * 4)
>> +#define PWM_DZ_INTV GENMASK(15, 8)
>> +#define PWM_DZ_EN BIT(0)
>> +
>> +#define PWM_ENABLE_REG 0x0040
>> +#define PWM_EN(ch) BIT(ch)
>> +
>> +#define CAPTURE_ENABLE_REG 0x0044
>> +#define CAP_EN(ch) BIT(ch)
>> +
>> +#define PWM_CTR_REG(ch) (0x0060 + ch * 0x20)
>> +#define PWM_PERIOD_RDY BIT(11)
>> +#define PWM_PUL_START BIT(10)
>> +#define PWM_MODE BIT(9)
>> +#define PWM_ACT_STA BIT(8)
>> +#define PWM_PRESCAL_K GENMASK(7, 0)
>> +
>> +#define PWM_PERIOD_REG(ch) (0x0064 + ch * 0x20)
>> +#define PWM_ENTIRE_CYCLE GENMASK(31, 16)
>> +#define PWM_ACT_CYCLE GENMASK(15, 0)
>> +
>> +#define PWM_CNT_REG(ch) (0x0068 + ch * 0x20)
>> +#define PWM_CNT_VAL GENMASK(15, 0)
>> +
>> +#define CAPTURE_CTR_REG(ch) (0x006c + ch * 0x20)
>> +#define CAPTURE_CRLF BIT(2)
>> +#define CAPTURE_CFLF BIT(1)
>> +#define CAPINV BIT(0)
>> +
>> +#define CAPTURE_RISE_REG(ch) (0x0070 + ch * 0x20)
>> +#define CAPTURE_CRLR GENMASK(15, 0)
>> +
>> +#define CAPTURE_FALL_REG(ch) (0x0074 + ch * 0x20)
>> +#define CAPTURE_CFLR GENMASK(15, 0)
>> +
>> +struct sunxi_pwm_data {
>> + bool has_prescaler_bypass;
>> + bool has_rdy;
>> + unsigned int npwm;
>> +};
>> +
>> +struct sunxi_pwm_chip {
>> + struct pwm_chip chip;
>> + struct clk *clk;
>> + void __iomem *base;
>> + spinlock_t ctrl_lock;
>> + const struct sunxi_pwm_data *data;
>> +};
>> +
>> +static const u16 div_m_table[] = {
>> + 1,
>> + 2,
>> + 4,
>> + 8,
>> + 16,
>> + 32,
>> + 64,
>> + 128,
>> + 256
>> +};
>> +
>> +static inline struct sunxi_pwm_chip *to_sunxi_pwm_chip(struct pwm_chip *chip)
>> +{
>> + return container_of(chip, struct sunxi_pwm_chip, chip);
>> +}
>> +
>> +static inline u32 sunxi_pwm_readl(struct sunxi_pwm_chip *chip,
>> + unsigned long offset)
>> +{
>> + return readl(chip->base + offset);
>> +}
>> +
>> +static inline void sunxi_pwm_writel(struct sunxi_pwm_chip *chip,
>> + u32 val, unsigned long offset)
>> +{
>> + writel(val, chip->base + offset);
>> +}
>> +
>> +static void sunxi_pwm_set_bit(struct sunxi_pwm_chip *sunxi_pwm,
>> + unsigned long reg, u32 bit)
>> +{
>> + u32 val;
>> +
>> + val = sunxi_pwm_readl(sunxi_pwm, reg);
>> + val |= bit;
>> + sunxi_pwm_writel(sunxi_pwm, val, reg);
>> +}
>> +
>> +static void sunxi_pwm_clear_bit(struct sunxi_pwm_chip *sunxi_pwm,
>> + unsigned long reg, u32 bit)
>> +{
>> + u32 val;
>> +
>> + val = sunxi_pwm_readl(sunxi_pwm, reg);
>> + val &= ~bit;
>> + sunxi_pwm_writel(sunxi_pwm, val, reg);
>> +}
>> +
>> +static void sunxi_pwm_set_value(struct sunxi_pwm_chip *sunxi_pwm,
>> + unsigned long reg, u32 mask, u32 val)
>> +{
>> + u32 tmp;
>> +
>> + tmp = sunxi_pwm_readl(sunxi_pwm, reg);
>> + tmp &= ~mask;
>> + tmp |= mask & val;
>> + sunxi_pwm_writel(sunxi_pwm, tmp, reg);
>> +}
>> +
>> +static void sunxi_pwm_set_polarity(struct sunxi_pwm_chip *chip, u32 ch,
>> + enum pwm_polarity polarity)
>> +{
>> + if (polarity == PWM_POLARITY_NORMAL)
>> + sunxi_pwm_set_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
>> + else
>> + sunxi_pwm_clear_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
>> +}
>> +
>> +static void sunxi_dump_reg(struct sunxi_pwm_chip *sunxi_pwm, u8 ch)
>> +{
>> + dev_dbg(sunxi_pwm->chip.dev, "ch: %d\n"
>> + "\tPWM_IRQ_ENABLE_REG(%04x): \t0x%08x\n"
>> + "\tPWM_IRQ_STATUS_REG(%04x): \t0x%08x\n"
>> + "\tCAPTURE_IRQ_ENABLE_REG(%04x): \t0x%08x\n"
>> + "\tCAPTURE_IRQ_STATUS_REG(%04x): \t0x%08x\n"
>> + "\tCLK_CFG_REG(%04x)(%d): \t0x%08x\n"
>> + "\tPWM_DZ_CTR_REG(%04x)(%d): \t0x%08x\n"
>> + "\tPWM_ENABLE_REG(%04x): \t0x%08x\n"
>> + "\tCAPTURE_ENABLE_REG(%04x): \t0x%08x\n"
>> + "\tPWM_CTR_REG(%04x)(%d): \t0x%08x\n"
>> + "\tPWM_PERIOD_REG(%04x)(%d): \t0x%08x\n"
>> + "\tPWM_CNT_REG(%04x)(%d): \t0x%08x\n"
>> + "\tCAPTURE_CTR_REG(%04x)(%d): \t0x%08x\n"
>> + "\tCAPTURE_RISE_REG(%04x)(%d): \t0x%08x\n"
>> + "\tCAPTURE_FALL_REG(%04x)(%d): \t0x%08x\n",
>> + ch,
>> + PWM_IRQ_ENABLE_REG,
>> + readl(sunxi_pwm->base + PWM_IRQ_ENABLE_REG),
>> + PWM_IRQ_STATUS_REG,
>> + readl(sunxi_pwm->base + PWM_IRQ_STATUS_REG),
>> + CAPTURE_IRQ_ENABLE_REG,
>> + readl(sunxi_pwm->base + CAPTURE_IRQ_ENABLE_REG),
>> + CAPTURE_IRQ_STATUS_REG,
>> + readl(sunxi_pwm->base + CAPTURE_IRQ_STATUS_REG),
>> + CLK_CFG_REG(ch),
>> + ch, readl(sunxi_pwm->base + CLK_CFG_REG(ch)),
>> + PWM_DZ_CTR_REG(ch),
>> + ch, readl(sunxi_pwm->base + PWM_DZ_CTR_REG(ch)),
>> + PWM_ENABLE_REG,
>> + readl(sunxi_pwm->base + PWM_ENABLE_REG),
>> + CAPTURE_ENABLE_REG,
>> + readl(sunxi_pwm->base + CAPTURE_ENABLE_REG),
>> + PWM_CTR_REG(ch),
>> + ch, readl(sunxi_pwm->base + PWM_CTR_REG(ch)),
>> + PWM_PERIOD_REG(ch),
>> + ch, readl(sunxi_pwm->base + PWM_PERIOD_REG(ch)),
>> + PWM_CNT_REG(ch),
>> + ch, readl(sunxi_pwm->base + PWM_CNT_REG(ch)),
>> + CAPTURE_CTR_REG(ch),
>> + ch, readl(sunxi_pwm->base + CAPTURE_CTR_REG(ch)),
>> + CAPTURE_RISE_REG(ch),
>> + ch, readl(sunxi_pwm->base + CAPTURE_RISE_REG(ch)),
>> + CAPTURE_FALL_REG(ch),
>> + ch, readl(sunxi_pwm->base + CAPTURE_FALL_REG(ch)));
>> +}
>> +
>> +static int sunxi_pwm_config(struct sunxi_pwm_chip *sunxi_pwm, u8 ch,
>> + struct pwm_state *state)
>> +{
>> + u64 clk_rate, clk_div, val;
>> + u16 prescaler = 0;
>> + u8 id = 0;
>> +
>> + clk_rate = clk_get_rate(sunxi_pwm->clk);
>> + dev_dbg(sunxi_pwm->chip.dev, "clock rate:%lld\n", clk_rate);
>> +
>> + if (clk_rate == 24000000)
>> + sunxi_pwm_clear_bit(sunxi_pwm, CLK_CFG_REG(ch), CLK_SRC);
>> + else
>> + sunxi_pwm_set_bit(sunxi_pwm, CLK_CFG_REG(ch), CLK_SRC);
>> +
>> + if (sunxi_pwm->data->has_prescaler_bypass) {
>> + /* pwm output bypass */
>> + if (ch % 2)
>> + sunxi_pwm_set_bit(sunxi_pwm, CLK_CFG_REG(ch),
>> + CLK_SRC_BYPASS_FIR);
>> + else
>> + sunxi_pwm_set_bit(sunxi_pwm, CLK_CFG_REG(ch),
>> + CLK_SRC_BYPASS_SEC);
>> + return 0;
>> + }
>> +
>> + val = state->period * clk_rate;
>> + do_div(val, NSEC_PER_SEC);
>> + if (val < 1) {
>> + dev_err(sunxi_pwm->chip.dev,
>> + "period expects a larger value\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* calculate and set prescalar, div table, pwn entrie cycle */
>> + clk_div = val;
>> +
>> + while (clk_div > 65535) {
>> + prescaler++;
>> + clk_div = val;
>> + do_div(clk_div, prescaler + 1);
>> + do_div(clk_div, div_m_table[id]);
>> +
>> + if (prescaler == 255) {
>> + prescaler = 0;
>> + id++;
>> + if (id == 9)
>> + return -EINVAL;
>> + }
>> + }
>> +
>> + sunxi_pwm_set_value(sunxi_pwm, PWM_PERIOD_REG(ch),
>> + PWM_ENTIRE_CYCLE, clk_div << 16);
>> + sunxi_pwm_set_value(sunxi_pwm, PWM_CTR_REG(ch),
>> + PWM_PRESCAL_K, prescaler << 0);
>> + sunxi_pwm_set_value(sunxi_pwm, CLK_CFG_REG(ch),
>> + CLK_DIV_M, id << 0);
>> +
>> + /* set duty cycle */
>> + val = (prescaler + 1) * div_m_table[id] * clk_div;
>> + val = state->period;
>> + do_div(val, clk_div);
>> + clk_div = state->duty_cycle;
>> + do_div(clk_div, val);
>> +
>> + sunxi_pwm_set_value(sunxi_pwm, PWM_PERIOD_REG(ch),
>> + PWM_ACT_CYCLE, clk_div << 0);
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> + struct pwm_state *state)
>> +{
>> + int ret;
>> + struct sunxi_pwm_chip *sunxi_pwm = to_sunxi_pwm_chip(chip);
>> + struct pwm_state cstate;
>> +
>> + sunxi_dump_reg(sunxi_pwm, pwm->hwpwm);
>> + pwm_get_state(pwm, &cstate);
>> + if (!cstate.enabled) {
>> + ret = clk_prepare_enable(sunxi_pwm->clk);
>> + if (ret) {
>> + dev_err(chip->dev, "failed to enable PWM clock\n");
>> + return ret;
>> + }
>> + }
>> +
>> + spin_lock(&sunxi_pwm->ctrl_lock);
>> +
>> + if (state->polarity != cstate.polarity)
>> + sunxi_pwm_set_polarity(sunxi_pwm, pwm->hwpwm, state->polarity);
>> +
>> + if ((cstate.period != state->period) ||
>> + (cstate.duty_cycle != state->duty_cycle)) {
>> + ret = sunxi_pwm_config(sunxi_pwm, pwm->hwpwm, state);
>> + if (ret) {
>> + dev_err(chip->dev, "failed to enable PWM clock\n");
>> + return ret;
> Here you might want to undo the previous polarity and do clk_disable_unprepare(),
> if any, in order to not reach inconsistency b/w software state of PWM and hardware
> state. Also, unlock the spinlock.
>> + }
>> + }
>> +
>> + if (state->enabled) {
>> + sunxi_pwm_set_bit(sunxi_pwm,
>> + CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
>> +
>> + sunxi_pwm_set_bit(sunxi_pwm,
>> + PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
>> + } else {
>> + sunxi_pwm_clear_bit(sunxi_pwm,
>> + CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
>> +
>> + sunxi_pwm_clear_bit(sunxi_pwm,
>> + PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
>> + }
>> +
>> + spin_unlock(&sunxi_pwm->ctrl_lock);
>> + sunxi_dump_reg(sunxi_pwm, pwm->hwpwm);
>> +
>> + return 0;
>> +}
>> +
>> +static void sunxi_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
>> + struct pwm_state *state)
>> +{
>> + struct sunxi_pwm_chip *sunxi_pwm = to_sunxi_pwm_chip(chip);
>> + u64 clk_rate, tmp;
>> + u32 val;
>> + u16 clk_div, act_cycle;
>> + u8 prescal, id;
>> +
>> + clk_rate = clk_get_rate(sunxi_pwm->clk);
>> +
>> + val = sunxi_pwm_readl(sunxi_pwm, PWM_CTR_REG(pwm->hwpwm));
>> + if (PWM_ACT_STA & val)
>> + state->polarity = PWM_POLARITY_NORMAL;
>> + else
>> + state->polarity = PWM_POLARITY_INVERSED;
>> +
>> + prescal = PWM_PRESCAL_K & val;
>> +
>> + val = sunxi_pwm_readl(sunxi_pwm, PWM_ENABLE_REG);
>> + if (PWM_EN(pwm->hwpwm) & val)
>> + state->enabled = true;
>> + else
>> + state->enabled = false;
>> +
>> + val = sunxi_pwm_readl(sunxi_pwm, PWM_PERIOD_REG(pwm->hwpwm));
>> + act_cycle = PWM_ACT_CYCLE & val;
>> + clk_div = val >> 16;
>> +
>> + val = sunxi_pwm_readl(sunxi_pwm, CLK_CFG_REG(pwm->hwpwm));
>> + id = CLK_DIV_M & val;
>> +
>> + tmp = act_cycle * prescal * div_m_table[id] * NSEC_PER_SEC;
>> + state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
>> + tmp = clk_div * prescal * div_m_table[id] * NSEC_PER_SEC;
>> + state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
>> +}
>> +
>> +static const struct pwm_ops sunxi_pwm_ops = {
>> + .apply = sunxi_pwm_apply,
>> + .get_state = sunxi_pwm_get_state,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static const struct sunxi_pwm_data sunxi_pwm_data_r40 = {
>> + .has_prescaler_bypass = false,
>> + .has_rdy = true,
>> + .npwm = 8,
>> +};
>> +
>> +static const struct of_device_id sunxi_pwm_dt_ids[] = {
>> + {
>> + .compatible = "allwinner,sun8i-r40-pwm",
>> + .data = &sunxi_pwm_data_r40,
>> + },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, sunxi_pwm_dt_ids);
>> +
>> +static int sunxi_pwm_probe(struct platform_device *pdev)
>> +{
>> + struct sunxi_pwm_chip *pwm;
>> + struct resource *res;
>> + int ret;
>> + const struct of_device_id *match;
>> +
>> + match = of_match_device(sunxi_pwm_dt_ids, &pdev->dev);
>> +
>> + pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>> + if (!pwm)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> check for res == NULL
My bad here, no need to check res == NULL since devm_ioremap_resource() will take
care of this case.
Thanks,
Claudiu
>> + pwm->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(pwm->base))
>> + return PTR_ERR(pwm->base);
>> +
>> + pwm->clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(pwm->clk))
>> + return PTR_ERR(pwm->clk);
>> +
>> + pwm->data = match->data;
>> + pwm->chip.dev = &pdev->dev;
>> + pwm->chip.ops = &sunxi_pwm_ops;
>> + pwm->chip.base = -1;
>> + pwm->chip.npwm = pwm->data->npwm;
>> + pwm->chip.of_xlate = of_pwm_xlate_with_flags;
>> + pwm->chip.of_pwm_n_cells = 3;
>> +
>> + dev_dbg(pwm->chip.dev, "npwm: %d\n", pwm->chip.npwm);
>> +
>> + spin_lock_init(&pwm->ctrl_lock);
>> +
>> + ret = pwmchip_add(&pwm->chip);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + platform_set_drvdata(pdev, pwm);
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_pwm_remove(struct platform_device *pdev)
>> +{
>> + struct sunxi_pwm_chip *pwm = platform_get_drvdata(pdev);
>> +
>> + return pwmchip_remove(&pwm->chip);
>> +}
>> +
>> +static struct platform_driver sunxi_pwm_driver = {
>> + .driver = {
>> + .name = "sun8i-r40-pwm",
>> + .of_match_table = sunxi_pwm_dt_ids,
>> + },
>> + .probe = sunxi_pwm_probe,
>> + .remove = sunxi_pwm_remove,
>> +};
>> +module_platform_driver(sunxi_pwm_driver);
>> +
>> +MODULE_ALIAS("platform:sun8i-r40-pwm");
>> +MODULE_AUTHOR("Hao Zhang <hao5781286@gmail.com>");
>> +MODULE_DESCRIPTION("Allwinner sun8i-r40 PWM driver");
>> +MODULE_LICENSE("GPL v2");
>>
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Mauro Carvalho Chehab @ 2017-12-15 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOymtfJKzs=1xUeJOYqvxhb-o9r=aTUOLOM4-DMUj8xXdD2PUw@mail.gmail.com>
Em Fri, 15 Dec 2017 10:55:26 +0530
Dhaval Shah <dhaval23031987@gmail.com> escreveu:
> Hi Laurent/Mauro/Greg,
>
> On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > Hi Mauro,
> >
> > On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
> >> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
> >> > On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
> >> >> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
> >> >>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> >> >>>> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
> >> >>>>> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> >> >>>>>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> >> >>>>>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> >> >>>>>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
> >> >>>>>>>> wrote:
> >> >>>>>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> >> >>>>>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
> >> >>>>>>>>>> related drivers.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> >> >>>>>>>>>
> >> >>>>>>>>> Hi Dhaval,
> >> >>>>>>>>>
> >> >>>>>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
> >> >>>>>>>>> afraid that, without their explicit acks, sent to the ML, I
> >> >>>>>>>>> can't accept a patch touching at the driver's license tags.
> >> >>>>>>>>
> >> >>>>>>>> The patch doesn't change the license, I don't see why it would
> >> >>>>>>>> cause any issue. Greg isn't listed as the maintainer or copyright
> >> >>>>>>>> holder of any of the 10k+ files to which he added an SPDX license
> >> >>>>>>>> header in the last kernel release.
> >> >>>>>>>
> >> >>>>>>> Adding a comment line that describes an implicit or
> >> >>>>>>> explicit license is different than removing the license
> >> >>>>>>> text itself.
> >> >>>>>>
> >> >>>>>> The SPDX license header is meant to be equivalent to the license
> >> >>>>>> text.
> >> >>>>>
> >> >>>>> I understand that.
> >> >>>>> At a minimum, removing BSD license text is undesirable
> >> >>>>>
> >> >>>>> as that license states:
> >> >>>>> * * Redistributions of source code must retain the above copyright
> >> >>>>> * notice, this list of conditions and the following disclaimer.
> >> >>>>>
> >> >>>>> etc...
> >> >>>>
> >> >>>> But this patch only removes the following text:
> >> >>>>
> >> >>>> - * This program is free software; you can redistribute it and/or
> >> >>>> modify
> >> >>>> - * it under the terms of the GNU General Public License version 2 as
> >> >>>> - * published by the Free Software Foundation.
> >> >>>>
> >> >>>> and replaces it by the corresponding SPDX header.
> >> >>>>
> >> >>>>>> The only reason why the large SPDX patch didn't touch the whole
> >> >>>>>> kernel in one go was that it was easier to split in in multiple
> >> >>>>>> chunks.
> >> >>>>>
> >> >>>>> Not really, it was scripted.
> >> >>>>
> >> >>>> But still manually reviewed as far as I know.
> >> >>>>
> >> >>>>>> This is no different than not including the full GPL license in
> >> >>>>>> every header file but only pointing to it through its name and
> >> >>>>>> reference, as every kernel source file does.
> >> >>>>>
> >> >>>>> Not every kernel source file had a license text
> >> >>>>> or a reference to another license file.
> >> >>>>
> >> >>>> Correct, but the files touched by this patch do.
> >> >>>>
> >> >>>> This issue is in no way specific to linux-media and should be
> >> >>>> decided upon at the top level, not on a per-subsystem basis. Greg,
> >> >>>> could you comment on this ?
> >> >>>
> >> >>> Comment on what exactly? I don't understand the problem here, care to
> >> >>> summarize it?
> >> >>
> >> >> In a nutshell (if I understand it correctly), Dhaval Shah submitted
> >> >> https:// patchwork.kernel.org/patch/10102451/ which replaces
> >> >>
> >> >> +// SPDX-License-Identifier: GPL-2.0
> >> >> [...]
> >> >> - *
> >> >> - * This program is free software; you can redistribute it and/or modify
> >> >> - * it under the terms of the GNU General Public License version 2 as
> >> >> - * published by the Free Software Foundation.
> >> >>
> >> >> in all .c and .h files of the Xilinx V4L2 driver
> >> >> (drivers/media/platform/
> >> >> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
> >> >> stating that he can't accept a change to license text without an
> >> >> explicit ack from the official driver's maintainers. My position is
> >> >> that such a change doesn't change the license and thus doesn't need to
> >> >> track all copyright holders, and can be merged without an explicit ack
> >> >> from the respective maintainers.
> >> >
> >> > Yes, I agree with you, no license is being changed here, and no
> >> > copyright is either.
> >> >
> >> > BUT, I know that most major companies are reviewing this process right
> >> > now. We have gotten approval from almost all of the major kernel
> >> > developer companies to do this, which is great, and supports this work
> >> > as being acceptable.
> >> >
> >> > So it's nice to ask Xilinx if they object to this happening, which I
> >> > guess Mauro is trying to say here (in not so many words...) To at least
> >> > give them the heads-up that this is what is going to be going on
> >> > throughout the kernel tree soon, and if they object, it would be good to
> >> > speak up as to why (and if they do, I can put their lawyers in contact
> >> > with some lawyers to explain it all to them.)
> >>
> >> Yes, that's basically what I'm saying.
> >>
> >> I don't feel comfortable on signing a patch changing the license text
> >> without giving the copyright owners an opportunity and enough time
> >> to review it and approve, or otherwise comment about such changes.
> >
> > If I understand you and Greg correctly, you would like to get a general
> > approval from Xilinx for SPDX-related changes, but that would be a blanket
> > approval that would cover this and all subsequent similar patches. Is that
> > correct ? That is reasonable for me.
> >
> > In that case, could the fact that commit
> >
> > commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
> > Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Date: Fri Nov 3 11:28:30 2017 +0100
> >
> > USB: add SPDX identifiers to all remaining files in drivers/usb/
> >
> > add SPDX headers to several Xilinx-authored source files constitute such a
> > blanket approval ?
> >
> I have to do anything here or Once, we get approval from the Michal
> Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
> then it will go into mainline?
I would wait for their feedback.
Thanks,
Mauro
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6sx: Add support for PCI power domain
From: Lucas Stach @ 2017-12-15 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513304698-15169-2-git-send-email-festevam@gmail.com>
Am Freitag, den 15.12.2017, 00:24 -0200 schrieb Fabio Estevam:
> > From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Previously PCI support was working because the bootloader has previously
> powered up the PCI power domain.
>
> Represent the PCI power domain, so that PCI is functional without
> relying on the PCI support from the bootloader.
>
> Tested on a imx6sx-sdb board with no PCI support in the bootloader.
>
> > Reported-by: Abel Vesa <abel.vesa@nxp.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?arch/arm/boot/dts/imx6sx.dtsi | 14 ++++++++++++++
> ?1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 40c6738c..c6ea6ec 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -750,6 +750,19 @@
> > ? #interrupt-cells = <3>;
> > ? interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
> > ? interrupt-parent = <&intc>;
> > + clocks = <&clks IMX6SX_CLK_IPG>;
> > + clock-names = "ipg";
> +
> > + pgc {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> +
> > > + pd_pci: power-domain at 3 {
> > + reg = <3>;
> > + #power-domain-cells = <0>;
> > + power-supply = <®_pcie>;
> > + };
> > + };
> > ? };
> ?
> > > ? iomuxc: iomuxc at 20e0000 {
> @@ -1328,6 +1341,7 @@
> > ? ?<&clks IMX6SX_CLK_PCIE_REF_125M>,
> > ? ?<&clks IMX6SX_CLK_DISPLAY_AXI>;
> > ? clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_inbound_axi";
> > + power-domains = <&pd_pci>;
> > ? status = "disabled";
> > ? };
> > ? };
^ permalink raw reply
* [RFC PATCH 2/7] gpio: gpiolib: split the gpiod_configure_flags function
From: Julien Thierry @ 2017-12-15 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214142138.23008-3-ludovic.desroches@microchip.com>
Hi Ludovic,
On 14/12/17 14:21, Ludovic Desroches wrote:
> The gpiod_configure_flags function doesn't only configure flags, it
> also performs some processing. It implies that it should be called
> after having requested the GPIO. Split configuration and processing
> to allow flags configuration before requesting the GPIO. It is
> needed if we want to set the pin configuration.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> drivers/gpio/gpiolib.c | 49 +++++++++++++++++++++++++++++++------------------
> drivers/gpio/gpiolib.h | 7 ++++++-
> 2 files changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 0621baddfddc..c887602ca0ff 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -3564,23 +3564,9 @@ struct gpio_desc *__must_check gpiod_get_optional(struct device *dev,
> EXPORT_SYMBOL_GPL(gpiod_get_optional);
>
>
> -/**
> - * gpiod_configure_flags - helper function to configure a given GPIO
> - * @desc: gpio whose value will be assigned
> - * @con_id: function within the GPIO consumer
> - * @lflags: gpio_lookup_flags - returned from of_find_gpio() or
> - * of_get_gpio_hog()
> - * @dflags: gpiod_flags - optional GPIO initialization flags
> - *
> - * Return 0 on success, -ENOENT if no GPIO has been assigned to the
> - * requested function and/or index, or another IS_ERR() code if an error
> - * occurred while trying to acquire the GPIO.
> - */
> -int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
> +void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
> unsigned long lflags, enum gpiod_flags dflags)
> {
> - int status;
> -
> if (lflags & GPIO_ACTIVE_LOW)
> set_bit(FLAG_ACTIVE_LOW, &desc->flags);
>
> @@ -3601,6 +3587,11 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
> if (lflags & GPIO_OPEN_SOURCE)
> set_bit(FLAG_OPEN_SOURCE, &desc->flags);
>
Small issue, I believe the patch is missing a '}' here to properly split
the function.
Otherwise:
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Cheers,
--
Julien Thierry
^ permalink raw reply
* [PATCH] ARM: dts: imx6q-h100: use usdhc2 VSELECT
From: Michael Tretter @ 2017-12-15 9:26 UTC (permalink / raw)
To: linux-arm-kernel
The uSDHC controller directly provides a VSELECT signal that can be
muxed to the external voltage select. Mux the VSELECT directly to avoid
using a GPIO.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
---
arch/arm/boot/dts/imx6q-h100.dts | 25 +++----------------------
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-h100.dts b/arch/arm/boot/dts/imx6q-h100.dts
index a3269f57df2b..450ec967c257 100644
--- a/arch/arm/boot/dts/imx6q-h100.dts
+++ b/arch/arm/boot/dts/imx6q-h100.dts
@@ -108,21 +108,6 @@
regulator-always-on;
};
- reg_nvcc_sd2: regulator-nvcc-sd2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_h100_reg_nvcc_sd2>;
- compatible = "regulator-gpio";
- regulator-name = "NVCC_SD2";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-type = "voltage";
- regulator-boot-on;
- regulator-always-on;
- gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
- states = <1800000 0x1
- 3300000 0x0>;
- };
-
reg_usbh1_vbus: regulator-usb-h1-vbus {
compatible = "regulator-fixed";
enable-active-high;
@@ -260,12 +245,6 @@
>;
};
- pinctrl_h100_reg_nvcc_sd2: h100-reg-nvcc-sd2 {
- fsl,pins = <
- MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
- >;
- };
-
pinctrl_h100_sgtl5000: h100-sgtl5000 {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
@@ -316,6 +295,7 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b0b0
>;
};
@@ -328,6 +308,7 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b0b0
>;
};
@@ -340,6 +321,7 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170f9
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x1b0b0
>;
};
};
@@ -389,7 +371,6 @@
pinctrl-1 = <&pinctrl_h100_usdhc2_100mhz>;
pinctrl-2 = <&pinctrl_h100_usdhc2_200mhz>;
vmmc-supply = <®_3p3v>;
- vqmmc-supply = <®_nvcc_sd2>;
cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] soc: imx: gpc: Add i.MX6SX PCI power domain
From: Lucas Stach @ 2017-12-15 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513304698-15169-1-git-send-email-festevam@gmail.com>
Am Freitag, den 15.12.2017, 00:24 -0200 schrieb Fabio Estevam:
> > From: Fabio Estevam <fabio.estevam@nxp.com>
>
> i.MX6SX has a PCI power domain in PGC. Add support for it.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Seems like the GPC rework did turn out to work as expected by making it
easy to add additional power domains. :)
I didn't validate the register offsets, so this is:
Acked-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?Documentation/devicetree/bindings/power/fsl,imx-gpc.txt |??3 +++
> ?drivers/soc/imx/gpc.c???????????????????????????????????| 16 +++++++++++++++-
> ?2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> index e371b26..441f71e 100644
> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> @@ -9,6 +9,7 @@ Required properties:
> ???- fsl,imx6q-gpc
> ???- fsl,imx6qp-gpc
> ???- fsl,imx6sl-gpc
> +??- fsl,imx6sx-gpc
> ?- reg: should be register base and length as documented in the
> ???datasheet
> ?- interrupts: Should contain one interrupt specifier for the GPC interrupt
> @@ -29,6 +30,8 @@ Required properties:
> ???PU_DOMAIN??????1
> ???The following additional DOMAIN_INDEX value is valid for i.MX6SL:
> ???DISPLAY_DOMAIN 2
> +??The following additional DOMAIN_INDEX value is valid for i.MX6SX:
> +??PCI_DOMAIN?????3
> ?
> ?- #power-domain-cells: Should be 0
> ?
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 47e7aa9..53f7275 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -273,7 +273,15 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > ? },
> > ? .reg_offs = 0x240,
> > ? .cntr_pdn_bit = 4,
> > - }
> > + }, {
> > + .base = {
> > + .name = "PCI",
> > + .power_off = imx6_pm_domain_power_off,
> > + .power_on = imx6_pm_domain_power_on,
> > + },
> > + .reg_offs = 0x200,
> > + .cntr_pdn_bit = 6,
> > + },
> ?};
> ?
> ?struct imx_gpc_dt_data {
> @@ -296,10 +304,16 @@ static const struct imx_gpc_dt_data imx6sl_dt_data = {
> > ? .err009619_present = false,
> ?};
> ?
> +static const struct imx_gpc_dt_data imx6sx_dt_data = {
> > + .num_domains = 4,
> > + .err009619_present = false,
> +};
> +
> ?static const struct of_device_id imx_gpc_dt_ids[] = {
> > ? { .compatible = "fsl,imx6q-gpc", .data = &imx6q_dt_data },
> > ? { .compatible = "fsl,imx6qp-gpc", .data = &imx6qp_dt_data },
> > ? { .compatible = "fsl,imx6sl-gpc", .data = &imx6sl_dt_data },
> > + { .compatible = "fsl,imx6sx-gpc", .data = &imx6sx_dt_data },
> > ? { }
> ?};
> ?
^ 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