* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-24 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124150918.GF2213@rric.localdomain>
Ard,
> > >> On 24 November 2016 at 13:51, Robert Richter <robert.richter@cavium.com> wrote:
> > >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote:
> > >> Regions containing firmware tables are owned by the firmware, and it
> > >> is the firmware that tells us which memory attributes we are allowed
> > >> to use. If those attributes include WB, it is perfectly legal to use a
> > >> cacheable mapping. That does *not* mean they should be covered by the
> > >> linear mapping. The linear mapping is read-write-non-exec, for
> > >> instance, and we may prefer to use a read-only mapping and/or
> > >> executable mapping.
> > >
> > > Ok, I am going to fix try_ram_remap().
I revisited the code and it is working well already since:
e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
Now, try_ram_remap() is only called if the region to be mapped is
entirely in IORESOURCE_SYSTEM_RAM. This is only true for normal mem
ranges and not NOMAP mem. region_intersects() then returns
REGION_INTERSECTS and calls try_ram_remap(). For the NOMAP memory case
REGION_DISJOINT would be returned and thus arch_memremap_wb() being
called directly. Before the e7cd190385d1 change try_ram_remap() was
called also for nomap regions.
So we can leave memremap() as it is and just apply this patch
unmodified. What do you think? Please ack.
I am going to prepare the pfn_is_ram() change in addition to this
patch, but that should not be required for this fix to work correcly.
Thanks,
-Robert
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: James Bottomley @ 2016-11-24 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147990565051.7576.9673287945782426886.stgit@warthog.procyon.org.uk>
On Wed, 2016-11-23 at 12:54 +0000, David Howells wrote:
> Get the firmware's secure-boot status in the kernel boot wrapper and
> stash it somewhere that the main kernel image can find.
>
> The efi_get_secureboot() function is extracted from the arm stub and
> (a) generalised so that it can be called from x86 and (b) made to use
> efi_call_runtime() so that it can be run in mixed-mode.
>
> Suggested-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: David Howells <dhowells@redhat.com>
Since you seem to be using this to mean "is the platform locked down?",
this looks to be no longer complete in the UEFI 2.6 world. If
DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can
remove the platform key by writing 1 to AuditMode and gain control of
the secure variables. The lock down state becomes DeployedMode == 1,
SecureBoot == 1 and SetupMode == 0
See the diagram on page 1817
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
James
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-24 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124192659.GH2213@rric.localdomain>
On 24 November 2016 at 19:26, Robert Richter <robert.richter@cavium.com> wrote:
> Ard,
>
>> > >> On 24 November 2016 at 13:51, Robert Richter <robert.richter@cavium.com> wrote:
>> > >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote:
>
>> > >> Regions containing firmware tables are owned by the firmware, and it
>> > >> is the firmware that tells us which memory attributes we are allowed
>> > >> to use. If those attributes include WB, it is perfectly legal to use a
>> > >> cacheable mapping. That does *not* mean they should be covered by the
>> > >> linear mapping. The linear mapping is read-write-non-exec, for
>> > >> instance, and we may prefer to use a read-only mapping and/or
>> > >> executable mapping.
>> > >
>> > > Ok, I am going to fix try_ram_remap().
>
> I revisited the code and it is working well already since:
>
> e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
>
> Now, try_ram_remap() is only called if the region to be mapped is
> entirely in IORESOURCE_SYSTEM_RAM. This is only true for normal mem
> ranges and not NOMAP mem. region_intersects() then returns
> REGION_INTERSECTS and calls try_ram_remap(). For the NOMAP memory case
> REGION_DISJOINT would be returned and thus arch_memremap_wb() being
> called directly. Before the e7cd190385d1 change try_ram_remap() was
> called also for nomap regions.
>
> So we can leave memremap() as it is and just apply this patch
> unmodified. What do you think?
I agree. The pfn_valid() check in try_ram_remap() is still appropriate
simply because the PageHighmem check requires a valid struct page. But
if we don't enter that code path anymore for NOMAP regions, I think
we're ok.
> Please ack.
>
I still don't fully understand how it is guaranteed that *all* memory
(i.e., all regions for which memblock_is_memory() returns true) is
covered by a struct page, but marked as reserved. Are we relying on
the fact that NOMAP memory is also memblock_reserve()'d?
> I am going to prepare the pfn_is_ram() change in addition to this
> patch, but that should not be required for this fix to work correcly.
>
I don't think you need to bother with page_is_ram() then. The only
place we use it is in devmem_is_allowed(), and there it makes sense to
allow NOMAP regions to be accessed (provided that you think /dev/mem
is a good idea in the first place).
^ permalink raw reply
* [RFC PATCH 2/2] arm64: dts: enable the MUSB controller of Pine64 in host-only mode
From: Maxime Ripard @ 2016-11-24 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122165902.62543-2-icenowy@aosc.xyz>
On Wed, Nov 23, 2016 at 12:59:02AM +0800, Icenowy Zheng wrote:
> A64 has a MUSB controller wired to the USB PHY 0, which is connected
> to the upper USB Type-A port of Pine64.
>
> As the port is a Type-A female port, enable it in host-only mode in the
> device tree, which makes devices with USB Type-A male port can work on
> this port (which is originally designed by Pine64 team).
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/7504c3f1/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Maxime Ripard @ 2016-11-24 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122170616.29557-1-manu@bidouilliste.com>
On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> others three only have 1.
> Add the num-cs property to each node.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
I don't think we have any code that uses it at the moment. What is the
rationale behind this patch?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/e1729b42/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] ARM: dts: sun6i: Disable display pipeline by default
From: Maxime Ripard @ 2016-11-24 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124064339.12615-1-wens@csie.org>
On Thu, Nov 24, 2016 at 02:43:37PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> While we now support the internal display pipeline found on sun6i, it
> is possible that we are unable to enable the display for some boards,
> due to a lack of drivers for the panels or bridges found on them. If
> the display pipeline is enabled, the driver will try to enable, and
> possibly screw up the simple framebuffer U-boot had configured.
>
> This series disables the display pipeline by default, and re-enables
> it for the A31 Hummingbird, which already had its display pipeline
> enabled.
>
> The series can go in after 4.10-rc1, as a fix, but should not be delayed
> till the next release.
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/fc6a71f2/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun6i: hummingbird: Enable USB OTG
From: Maxime Ripard @ 2016-11-24 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124112908.4796-1-wens@csie.org>
On Thu, Nov 24, 2016 at 07:29:08PM +0800, Chen-Yu Tsai wrote:
> The A31 Hummingbird has a mini USB OTG port, and uses GPIO pins from the
> SoC for ID pin and VBUS detection and VBUS control. The PMIC can also do
> VBUS detection and control.
>
> Here we prefer to use the PMIC's DRIVEVBUS function to control VBUS for
> USB OTG, as that is the hardware default.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/fb996ac4/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-24 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124195517.qrq7briu3pwjnp4n@lukather>
On Thu, 24 Nov 2016 20:55:17 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > others three only have 1.
> > Add the num-cs property to each node.
> >
> > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
>
> I don't think we have any code that uses it at the moment. What is the
> rationale behind this patch?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Hi Maxime,
If num-cs isn't present nothing prevent to start a transfer with a
non-valid CS pin, resulting in an error.
num-cs are default property especially made for this and a SPI driver
should try to get the property at probe/attach time.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-24 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123181610.cae67ad53f5f69246d341b30@bidouilliste.com>
On Wed, 23 Nov 2016 18:16:10 +0100
Emmanuel Vadot <manu@bidouilliste.com> wrote:
> On Wed, 23 Nov 2016 09:03:50 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > > and uart pins along power in one connector and are found on most,
> > > if not all, Olimex boards.
> > > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > > those two connectors.
> > >
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> >
> > Fixed the indentation of the spi pinctrl cells, and applied.
> >
> > Please note that I'm note planning to send any new pull request, so
> > this will likely end up in 4.11.
> >
> > Thanks!
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> Sorry about the indentation, I'll be more carefull next time.
>
> Thank you.
>
> --
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>
Hi Maxime,
Re-reading the patch I've seen that I've not enabled the SPI nodes, I
guess it's easier if you revert my patch and that I send a new one ?
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH renesas-next 0/3] ARM: dts: shmobile: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes add of SoC-specific compat strings to the DT of
the r8a73a4, r8a7778 and sh73a0 SoCs. This is in keeping with the
rest of the Renesas ARM based SoCs with mmcif enabled in mainline.
Based on renesas-devel-20161123v2-v4.9-rc6
Documentation of these compat strings for the mmcif driver has been posted
separately as:
"[PATCH] mmc: sh_mmcif: Document r8a73a4, r8a7779 and sh73a0 DT bindings".
Simon Horman (3):
ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif
ARM: dts: r8a7778: Use SoC-specific compat string for mmcif
ARM: dts: sh73a0: Use SoC-specific compat string for mmcif
arch/arm/boot/dts/r8a73a4.dtsi | 4 ++--
arch/arm/boot/dts/r8a7778.dtsi | 2 +-
arch/arm/boot/dts/sh73a0.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH renesas-next 1/3] ARM: dts: r8a73a4: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480018514-31718-1-git-send-email-horms+renesas@verge.net.au>
Use the SoC-specific compat string for mmcif in DT for the r8a73a4 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a73a4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 53183ffe04c1..b138584b8800 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -440,7 +440,7 @@
};
mmcif0: mmc at ee200000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-r8a73a4", "renesas,sh-mmcif";
reg = <0 0xee200000 0 0x80>;
interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A73A4_CLK_MMCIF0>;
@@ -450,7 +450,7 @@
};
mmcif1: mmc at ee220000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-r8a73a4", "renesas,sh-mmcif";
reg = <0 0xee220000 0 0x80>;
interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A73A4_CLK_MMCIF1>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas-next 2/3] ARM: dts: r8a7778: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480018514-31718-1-git-send-email-horms+renesas@verge.net.au>
Use the SoC-specific compat string for mmcif in DT for the r8a7778 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7778.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index f3ffe1d31544..1e59eda8e66e 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -369,7 +369,7 @@
};
mmcif: mmc at ffe4e000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-r8a7778", "renesas,sh-mmcif";
reg = <0xffe4e000 0x100>;
interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7778_CLK_MMC>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH renesas-next 3/3] ARM: dts: sh73a0: Use SoC-specific compat string for mmcif
From: Simon Horman @ 2016-11-24 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480018514-31718-1-git-send-email-horms+renesas@verge.net.au>
Use the SoC-specific compat string for mmcif in DT for the sh73a0 SoC.
This is in keeping with the use of compat strings for mmcif for other
Renesas ARM based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/sh73a0.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index e1267590b575..6b01ab354e88 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -263,7 +263,7 @@
};
mmcif: mmc at e6bd0000 {
- compatible = "renesas,sh-mmcif";
+ compatible = "renesas,mmcif-sh73a0", "renesas,sh-mmcif";
reg = <0xe6bd0000 0x100>;
interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v3 2/6] iio: adc: Add support for STM32 ADC core
From: Jonathan Cameron @ 2016-11-24 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3775e118-ec41-8b09-6be3-6bde579f046d@st.com>
On 21/11/16 08:54, Fabrice Gasnier wrote:
> On 11/19/2016 01:17 PM, Jonathan Cameron wrote:
>> On 15/11/16 15:30, Fabrice Gasnier wrote:
>>> Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
>>> Converter). STM32 ADC can be composed of up to 3 ADCs with shared
>>> resources like clock prescaler, common interrupt line and analog
>>> reference voltage.
>>> This core driver basically manages shared resources.
>>>
>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
>> There is nothing in here that demands selecting a fixed regulator.
>> I've also switched the select regulator over to depends on inline with
>> other drivers in IIO that have a hard dependency on regulators.
>> Other than that which showed up during build tests, looks good to me.
>> Shout if I've broken anything with this change.
>
> Hi Jonathan, All,
>
> First many thanks.
> This is not a big deal. Only thing is: I think patch 4 of this series (on stm32_defconfig) need to be updated
> to accommodate this change. E.g. :
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
>
> Shall I send a new version of this series (all patches), including your changes, with updated defconfig as well ?
> Or only updated patch on defconfig is enough ?
Just update those that haven't already been applied.
Thanks,
Jonathan
>
> Please advise,
> Fabrice
>>
>> Applied to the togreg branch of iio.git and pushed out as testing for
>> the autobuilders to play with it.
>>
>> Thanks,
>>
>> Jonathan
>>> ---
>>> drivers/iio/adc/Kconfig | 13 ++
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/stm32-adc-core.c | 303 +++++++++++++++++++++++++++++++++++++++
>>> drivers/iio/adc/stm32-adc-core.h | 52 +++++++
>>> 4 files changed, 369 insertions(+)
>>> create mode 100644 drivers/iio/adc/stm32-adc-core.c
>>> create mode 100644 drivers/iio/adc/stm32-adc-core.h
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 7edcf32..ff30239 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -419,6 +419,19 @@ config ROCKCHIP_SARADC
>>> To compile this driver as a module, choose M here: the
>>> module will be called rockchip_saradc.
>>> +config STM32_ADC_CORE
>>> + tristate "STMicroelectronics STM32 adc core"
>>> + depends on ARCH_STM32 || COMPILE_TEST
>>> + depends on OF
>>> + select REGULATOR
>>> + select REGULATOR_FIXED_VOLTAGE
>>> + help
>>> + Select this option to enable the core driver for STMicroelectronics
>>> + STM32 analog-to-digital converter (ADC).
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called stm32-adc-core.
>>> +
>>> config STX104
>>> tristate "Apex Embedded Systems STX104 driver"
>>> depends on X86 && ISA_BUS_API
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 7a40c04..a1e8f44 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>>> obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>> obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>> obj-$(CONFIG_STX104) += stx104.o
>>> +obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
>>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>> obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>>> obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>>> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
>>> new file mode 100644
>>> index 0000000..4214b0c
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/stm32-adc-core.c
>>> @@ -0,0 +1,303 @@
>>> +/*
>>> + * This file is part of STM32 ADC driver
>>> + *
>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>> + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
>>> + *
>>> + * Inspired from: fsl-imx25-tsadc
>>> + *
>>> + * License type: GPLv2
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>>> + * See the GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License along with
>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/irqchip/chained_irq.h>
>>> +#include <linux/irqdesc.h>
>>> +#include <linux/irqdomain.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/regulator/consumer.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include "stm32-adc-core.h"
>>> +
>>> +/* STM32F4 - common registers for all ADC instances: 1, 2 & 3 */
>>> +#define STM32F4_ADC_CSR (STM32_ADCX_COMN_OFFSET + 0x00)
>>> +#define STM32F4_ADC_CCR (STM32_ADCX_COMN_OFFSET + 0x04)
>>> +
>>> +/* STM32F4_ADC_CSR - bit fields */
>>> +#define STM32F4_EOC3 BIT(17)
>>> +#define STM32F4_EOC2 BIT(9)
>>> +#define STM32F4_EOC1 BIT(1)
>>> +
>>> +/* STM32F4_ADC_CCR - bit fields */
>>> +#define STM32F4_ADC_ADCPRE_SHIFT 16
>>> +#define STM32F4_ADC_ADCPRE_MASK GENMASK(17, 16)
>>> +
>>> +/* STM32 F4 maximum analog clock rate (from datasheet) */
>>> +#define STM32F4_ADC_MAX_CLK_RATE 36000000
>>> +
>>> +/**
>>> + * struct stm32_adc_priv - stm32 ADC core private data
>>> + * @irq: irq for ADC block
>>> + * @domain: irq domain reference
>>> + * @aclk: clock reference for the analog circuitry
>>> + * @vref: regulator reference
>>> + * @common: common data for all ADC instances
>>> + */
>>> +struct stm32_adc_priv {
>>> + int irq;
>>> + struct irq_domain *domain;
>>> + struct clk *aclk;
>>> + struct regulator *vref;
>>> + struct stm32_adc_common common;
>>> +};
>>> +
>>> +static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
>>> +{
>>> + return container_of(com, struct stm32_adc_priv, common);
>>> +}
>>> +
>>> +/* STM32F4 ADC internal common clock prescaler division ratios */
>>> +static int stm32f4_pclk_div[] = {2, 4, 6, 8};
>>> +
>>> +/**
>>> + * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
>>> + * @priv: stm32 ADC core private data
>>> + * Select clock prescaler used for analog conversions, before using ADC.
>>> + */
>>> +static int stm32f4_adc_clk_sel(struct platform_device *pdev,
>>> + struct stm32_adc_priv *priv)
>>> +{
>>> + unsigned long rate;
>>> + u32 val;
>>> + int i;
>>> +
>>> + rate = clk_get_rate(priv->aclk);
>>> + for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
>>> + if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
>>> + break;
>>> + }
>>> + if (i >= ARRAY_SIZE(stm32f4_pclk_div))
>>> + return -EINVAL;
>>> +
>>> + val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
>>> + val &= ~STM32F4_ADC_ADCPRE_MASK;
>>> + val |= i << STM32F4_ADC_ADCPRE_SHIFT;
>>> + writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
>>> +
>>> + dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
>>> + rate / (stm32f4_pclk_div[i] * 1000));
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/* ADC common interrupt for all instances */
>>> +static void stm32_adc_irq_handler(struct irq_desc *desc)
>>> +{
>>> + struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc);
>>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>>> + u32 status;
>>> +
>>> + chained_irq_enter(chip, desc);
>>> + status = readl_relaxed(priv->common.base + STM32F4_ADC_CSR);
>>> +
>>> + if (status & STM32F4_EOC1)
>>> + generic_handle_irq(irq_find_mapping(priv->domain, 0));
>>> +
>>> + if (status & STM32F4_EOC2)
>>> + generic_handle_irq(irq_find_mapping(priv->domain, 1));
>>> +
>>> + if (status & STM32F4_EOC3)
>>> + generic_handle_irq(irq_find_mapping(priv->domain, 2));
>>> +
>>> + chained_irq_exit(chip, desc);
>>> +};
>>> +
>>> +static int stm32_adc_domain_map(struct irq_domain *d, unsigned int irq,
>>> + irq_hw_number_t hwirq)
>>> +{
>>> + irq_set_chip_data(irq, d->host_data);
>>> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_level_irq);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void stm32_adc_domain_unmap(struct irq_domain *d, unsigned int irq)
>>> +{
>>> + irq_set_chip_and_handler(irq, NULL, NULL);
>>> + irq_set_chip_data(irq, NULL);
>>> +}
>>> +
>>> +static const struct irq_domain_ops stm32_adc_domain_ops = {
>>> + .map = stm32_adc_domain_map,
>>> + .unmap = stm32_adc_domain_unmap,
>>> + .xlate = irq_domain_xlate_onecell,
>>> +};
>>> +
>>> +static int stm32_adc_irq_probe(struct platform_device *pdev,
>>> + struct stm32_adc_priv *priv)
>>> +{
>>> + struct device_node *np = pdev->dev.of_node;
>>> +
>>> + priv->irq = platform_get_irq(pdev, 0);
>>> + if (priv->irq < 0) {
>>> + dev_err(&pdev->dev, "failed to get irq\n");
>>> + return priv->irq;
>>> + }
>>> +
>>> + priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
>>> + &stm32_adc_domain_ops,
>>> + priv);
>>> + if (!priv->domain) {
>>> + dev_err(&pdev->dev, "Failed to add irq domain\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + irq_set_chained_handler(priv->irq, stm32_adc_irq_handler);
>>> + irq_set_handler_data(priv->irq, priv);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void stm32_adc_irq_remove(struct platform_device *pdev,
>>> + struct stm32_adc_priv *priv)
>>> +{
>>> + int hwirq;
>>> +
>>> + for (hwirq = 0; hwirq < STM32_ADC_MAX_ADCS; hwirq++)
>>> + irq_dispose_mapping(irq_find_mapping(priv->domain, hwirq));
>>> + irq_domain_remove(priv->domain);
>>> + irq_set_chained_handler(priv->irq, NULL);
>>> +}
>>> +
>>> +static int stm32_adc_probe(struct platform_device *pdev)
>>> +{
>>> + struct stm32_adc_priv *priv;
>>> + struct device_node *np = pdev->dev.of_node;
>>> + struct resource *res;
>>> + int ret;
>>> +
>>> + if (!pdev->dev.of_node)
>>> + return -ENODEV;
>>> +
>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + priv->common.base = devm_ioremap_resource(&pdev->dev, res);
>>> + if (IS_ERR(priv->common.base))
>>> + return PTR_ERR(priv->common.base);
>>> +
>>> + priv->vref = devm_regulator_get(&pdev->dev, "vref");
>>> + if (IS_ERR(priv->vref)) {
>>> + ret = PTR_ERR(priv->vref);
>>> + dev_err(&pdev->dev, "vref get failed, %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + ret = regulator_enable(priv->vref);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "vref enable failed\n");
>>> + return ret;
>>> + }
>>> +
>>> + ret = regulator_get_voltage(priv->vref);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "vref get voltage failed, %d\n", ret);
>>> + goto err_regulator_disable;
>>> + }
>>> + priv->common.vref_mv = ret / 1000;
>>> + dev_dbg(&pdev->dev, "vref+=%dmV\n", priv->common.vref_mv);
>>> +
>>> + priv->aclk = devm_clk_get(&pdev->dev, "adc");
>>> + if (IS_ERR(priv->aclk)) {
>>> + ret = PTR_ERR(priv->aclk);
>>> + dev_err(&pdev->dev, "Can't get 'adc' clock\n");
>>> + goto err_regulator_disable;
>>> + }
>>> +
>>> + ret = clk_prepare_enable(priv->aclk);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "adc clk enable failed\n");
>>> + goto err_regulator_disable;
>>> + }
>>> +
>>> + ret = stm32f4_adc_clk_sel(pdev, priv);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "adc clk selection failed\n");
>>> + goto err_clk_disable;
>>> + }
>>> +
>>> + ret = stm32_adc_irq_probe(pdev, priv);
>>> + if (ret < 0)
>>> + goto err_clk_disable;
>>> +
>>> + platform_set_drvdata(pdev, &priv->common);
>>> +
>>> + ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "failed to populate DT children\n");
>>> + goto err_irq_remove;
>>> + }
>>> +
>>> + return 0;
>>> +
>>> +err_irq_remove:
>>> + stm32_adc_irq_remove(pdev, priv);
>>> +
>>> +err_clk_disable:
>>> + clk_disable_unprepare(priv->aclk);
>>> +
>>> +err_regulator_disable:
>>> + regulator_disable(priv->vref);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int stm32_adc_remove(struct platform_device *pdev)
>>> +{
>>> + struct stm32_adc_common *common = platform_get_drvdata(pdev);
>>> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
>>> +
>>> + of_platform_depopulate(&pdev->dev);
>>> + stm32_adc_irq_remove(pdev, priv);
>>> + clk_disable_unprepare(priv->aclk);
>>> + regulator_disable(priv->vref);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static const struct of_device_id stm32_adc_of_match[] = {
>>> + { .compatible = "st,stm32f4-adc-core" },
>>> + {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, stm32_adc_of_match);
>>> +
>>> +static struct platform_driver stm32_adc_driver = {
>>> + .probe = stm32_adc_probe,
>>> + .remove = stm32_adc_remove,
>>> + .driver = {
>>> + .name = "stm32-adc-core",
>>> + .of_match_table = stm32_adc_of_match,
>>> + },
>>> +};
>>> +module_platform_driver(stm32_adc_driver);
>>> +
>>> +MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier@st.com>");
>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 ADC core driver");
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_ALIAS("platform:stm32-adc-core");
>>> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
>>> new file mode 100644
>>> index 0000000..081fa5f
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/stm32-adc-core.h
>>> @@ -0,0 +1,52 @@
>>> +/*
>>> + * This file is part of STM32 ADC driver
>>> + *
>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>> + * Author: Fabrice Gasnier <fabrice.gasnier@st.com>.
>>> + *
>>> + * License type: GPLv2
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>>> + * See the GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License along with
>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#ifndef __STM32_ADC_H
>>> +#define __STM32_ADC_H
>>> +
>>> +/*
>>> + * STM32 - ADC global register map
>>> + * ________________________________________________________
>>> + * | Offset | Register |
>>> + * --------------------------------------------------------
>>> + * | 0x000 | Master ADC1 |
>>> + * --------------------------------------------------------
>>> + * | 0x100 | Slave ADC2 |
>>> + * --------------------------------------------------------
>>> + * | 0x200 | Slave ADC3 |
>>> + * --------------------------------------------------------
>>> + * | 0x300 | Master & Slave common regs |
>>> + * --------------------------------------------------------
>>> + */
>>> +#define STM32_ADC_MAX_ADCS 3
>>> +#define STM32_ADCX_COMN_OFFSET 0x300
>>> +
>>> +/**
>>> + * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
>>> + * @base: control registers base cpu addr
>>> + * @vref_mv: vref voltage (mv)
>>> + */
>>> +struct stm32_adc_common {
>>> + void __iomem *base;
>>> + int vref_mv;
>>> +};
>>> +
>>> +#endif
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs
From: Maxime Ripard @ 2016-11-24 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <606230fd-37f6-e1ed-adc3-72f606fa944c@arm.com>
On Thu, Nov 24, 2016 at 11:15:42AM +0000, Andre Przywara wrote:
> On 24/11/16 10:55, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> >>> Hi,
> >>>
> >>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara <andre.przywara@arm.com> wrote:
> >>>>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> >>>>> have arm64 capable cores. Add the generic sunxi config symbol to allow
> >>>>> the driver to be selected by arm64 Kconfigs, which don't feature
> >>>>> SoC specific MACH_xxxx configs.
> >>>>>
> >>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>>>> ---
> >>>>> drivers/dma/Kconfig | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> >>>>> index af63a6b..003c284 100644
> >>>>> --- a/drivers/dma/Kconfig
> >>>>> +++ b/drivers/dma/Kconfig
> >>>>> @@ -157,7 +157,7 @@ config DMA_SUN4I
> >>>>>
> >>>>> config DMA_SUN6I
> >>>>> tristate "Allwinner A31 SoCs DMA support"
> >>>>> - depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> >>>>> + depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
> >>>>
> >>>> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
> >>>> (And I don't have to add MACH_SUN9I later :) )
> >>>
> >>> Sure, admittedly it was just a quick hack to get things going.
> >>> Actually I don't know why we had a *depend* on those MACH_s before. I
> >>> think technically it does not depend on a certain SoC (having the
> >>> COMPILE_TEST in there hints on that). So what about:
> >>
> >> It was really because this DMA engine only comes with the later
> >> SoCs. We have dma-sun4i for the older one.
> >
> > Indeed.
> >
> >> But yes, there's no reason why you can't build it for the earlier
> >> SoC. It just doesn't get used.
> >
> > I'm still in favor of keeping the depends on. There's no point of
> > compiling something we know have zero chance of running.
> >
> > (But that would be (ARCH_SUNXI && ARM64))
>
> I am OK with that, just wondering if there is a definition of what
> "depends" really means. My impression what that it's a about code
> dependencies (requires a certain subsystem, for instance), not really if
> it's useful in a particular configuration.
My understanding is that it's a hard dependency that prevents
configuration that make no sense, ie being able to compile a driver
that has no chance of being useful in the system, or a driver missing
its framework of choice.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/1a161529/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-24 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4393a37-5008-ec76-9886-05f8686dadd5@arm.com>
On Wed, Nov 23, 2016 at 09:23:49AM +0000, Andre Przywara wrote:
> Hi Maxime,
>
> On 23/11/16 07:57, Maxime Ripard wrote:
> > On Tue, Nov 22, 2016 at 12:24:20AM +0800, Icenowy Zheng wrote:
> >> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
> >>
> >> Add a device tree file for it.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >> ---
> >> Changes since v2:
> >> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
> >> - removed uart3, which is not accessible on Orange Pi Zero.
> >> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
> >> sun8i-h3.dtsi.
> >> - Removed allwinner,sun8i-h3 compatible.
> >>
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
> >
> > Ditto, h2-plus-orangepi-zero.
> >
> >> 2 files changed, 138 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 802a10d..51a1dd7 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >> sun8i-a33-sinlinx-sina33.dtb \
> >> sun8i-a83t-allwinner-h8homlet-v2.dtb \
> >> sun8i-a83t-cubietruck-plus.dtb \
> >> + sun8i-h2plus-orangepi-zero.dtb \
> >> sun8i-h3-bananapi-m2-plus.dtb \
> >> sun8i-h3-nanopi-neo.dtb \
> >> sun8i-h3-orangepi-2.dtb \
> >> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> new file mode 100644
> >> index 0000000..b428e47
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> @@ -0,0 +1,137 @@
> >> +/*
> >> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> >> + *
> >> + * Based on sun8i-h3-orangepi-one.dts, which is:
> >> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
> >> + *
> >> + * This file is dual-licensed: you can use it either under the terms
> >> + * of the GPL or the X11 license, at your option. Note that this dual
> >> + * licensing only applies to this file, and not this project as a
> >> + * whole.
> >> + *
> >> + * a) This file is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License as
> >> + * published by the Free Software Foundation; either version 2 of the
> >> + * License, or (at your option) any later version.
> >> + *
> >> + * This file is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * Or, alternatively,
> >> + *
> >> + * b) Permission is hereby granted, free of charge, to any person
> >> + * obtaining a copy of this software and associated documentation
> >> + * files (the "Software"), to deal in the Software without
> >> + * restriction, including without limitation the rights to use,
> >> + * copy, modify, merge, publish, distribute, sublicense, and/or
> >> + * sell copies of the Software, and to permit persons to whom the
> >> + * Software is furnished to do so, subject to the following
> >> + * conditions:
> >> + *
> >> + * The above copyright notice and this permission notice shall be
> >> + * included in all copies or substantial portions of the Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> >> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> >> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> >> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> >> + * OTHER DEALINGS IN THE SOFTWARE.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +#include "sun8i-h3.dtsi"
> >> +#include "sunxi-common-regulators.dtsi"
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/input/input.h>
> >> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> >> +
> >> +/ {
> >> + model = "Xunlong Orange Pi Zero";
> >> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
> >> +
> >> + aliases {
> >> + serial0 = &uart0;
> >> + };
> >> +
> >> + chosen {
> >> + stdout-path = "serial0:115200n8";
> >> + };
> >> +
> >> + leds {
> >> + compatible = "gpio-leds";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
> >> +
> >> + pwr_led {
> >> + label = "orangepi:green:pwr";
> >> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> >> + default-state = "on";
> >> + };
> >> +
> >> + status_led {
> >> + label = "orangepi:red:status";
> >> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
> >> + };
> >> + };
> >> +};
> >> +
> >> +&ehci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&mmc0 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
> >> + vmmc-supply = <®_vcc3v3>;
> >> + bus-width = <4>;
> >> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> >> + cd-inverted;
> >> + status = "okay";
> >> +};
> >> +
> >> +&ohci1 {
> >> + status = "okay";
> >> +};
> >> +
> >> +&pio {
> >> + leds_opi0: led_pins at 0 {
> >> + pins = "PA17";
> >> + function = "gpio_out";
> >> + };
> >> +};
> >> +
> >> +&r_pio {
> >> + leds_r_opi0: led_pins at 0 {
> >> + pins = "PL10";
> >> + function = "gpio_out";
> >> + };
> >> +};
> >> +
> >> +&uart0 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart0_pins_a>;
> >> + status = "okay";
> >> +};
> >> +
> >> +&uart1 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart1_pins>;
> >> + status = "disabled";
> >> +};
> >> +
> >> +&uart2 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&uart2_pins>;
> >> + status = "disabled";
> >> +};
> >
> > I'm not sure you answered me on this one. Are those exposed on the
> > headers? why did you put them as disabled here?
>
> So they are on headers, though you have to solder the actual header pins
> yourself [1]. But also these are the normal pins multiplexed with GPIOs
> and other peripherals, so keeping them disabled is in line with the
> existing policy, if I got this correctly.
>
> I agree that the status="disabled" is redundant, since we have that
> exact line already in the .dtsi. But I saw it in other DTs as well, most
> prominently in the sun8i-h3-orangepi-one.dts.
>
> So I think we should remove the "status=" lines here, dtc will generate
> an identical dtb out of it. But we should keep the uart descriptions in
> to make it easier for users to see which SoC pins are used for these
> pins labeled UART[012] in the board description and schematic. Also all
> it takes to enable those is to overwrite the status property, which can
> easily be done inline (without resizing the dtb).
I'd rather have the status still in the DTS. It's true that it's
redundant, but it's also explicit. A node without any status would
give the impression that it is actually enabled, especially since a
node without a status is going to be probed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/39a986ab/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
From: Maxime Ripard @ 2016-11-24 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>
On Wed, Nov 23, 2016 at 10:25:57PM +0800, Chen-Yu Tsai wrote:
> >> &r_pio {
> >> @@ -111,6 +148,11 @@
> >> pins = "PL10";
> >> function = "gpio_out";
> >> };
> >> +
> >> + wifi_pwrseq_pin_opi0: wifi_pwrseq_pin at 0 {
> >> + allwinner,pins = "PL7";
> >> + allwinner,function = "gpio_out";
> >
> > And same thing here.
>
> Might we do away with the pinmux for gpio pins tradition?
> Recent patches I've sent all omit them.
Oh, yes, that's true.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/836dbe90/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Stefan Schmidt @ 2016-11-24 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124162955.3887066-1-arnd@arndb.de>
Hello.
On 24.11.2016 17:29, Arnd Bergmann wrote:
> The camera_supply_dummy_device definition is shared between a780 and a910,
> but only provided when the first is enabled and fails to build for a
> configuration with only a910:
>
> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>
> This moves the definition into its own section.
>
> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
I wonder what we should do with ezx.c.
As far as I know neither Daniel nor Harald or myself are doing anything
with this devices anymore. Besides a basic compile test having an ack or
reviewed by from our side is a bit worthless. :/
I should still have some of these phones around in a box somewhere. If
there is someone with a good motivation and time to take over on this
platform we will find a way to get the person this devices.
Any takers? Robert? I guess you are already overloaded but you might
also have an interest. Worth asking :)
In the case nobody wants to pick up here what would you consider the
bets way forward? I could send a patch removing ezx platform support
from the kernel (basically ezx.c plus build support) or I can send a
patch marking it at least orphan in MAINTAINERS. Let me know what you think.
Daniel, Harald, if one of you is still interested in these and what to
pick up the work again, please speak up now. :)
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Alexander Kochetkov @ 2016-11-24 22:10 UTC (permalink / raw)
To: linux-arm-kernel
rk3036 dtsi file already use compatible field as
"rockchip,rk3036-timer", "rockchip,rk3288-timer".
The patch clearly shows how that filed should be used on other chips.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
.../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index a41b184..7bc9691 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -1,9 +1,15 @@
Rockchip rk timer
Required properties:
-- compatible: shall be one of:
- "rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
- "rockchip,rk3399-timer" - for rk3399
+- compatible: should be:
+ "rockchip,rk3036-timer", "rockchip,rk3288-timer": for Rockchip RK3036
+ "rockchip,rk3066-timer", "rockchip,rk3288-timer": for Rockchip RK3066
+ "rockchip,rk3188-timer", "rockchip,rk3288-timer": for Rockchip RK3188
+ "rockchip,rk322x-timer", "rockchip,rk3288-timer": for Rockchip RK322X
+ (please replace rk322x with exact device name and update this file)
+ "rockchip,rk3288-timer": for Rockchip RK3288
+ "rockchip,rk3368-timer", "rockchip,rk3288-timer": for Rockchip RK3368
+ "rockchip,rk3399-timer": for Rockchip RK3399
- reg: base address of the timer register starting with TIMERS CONTROL register
- interrupts: should contain the interrupts for Timer0
- clocks : must contain an entry for each entry in clock-names
--
1.7.9.5
^ permalink raw reply related
* [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Alexander Kochetkov @ 2016-11-24 22:12 UTC (permalink / raw)
To: linux-arm-kernel
The patch describes how to setup rockchip timers in device tree
so they can be used as clocksource.
I'm going to implement this feature.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
.../bindings/timer/rockchip,rk-timer.txt | 35 +++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index 7bc9691..15f8fed 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -16,7 +16,18 @@ Required properties:
- clock-names : must include the following entries:
"timer", "pclk"
-Example:
+Note:
+If device tree contain only one timer, than the timer will be intialized
+as clockevent provider. If device tree contain two timers, than first timer
+will be initialized as clockevent provider and second one as clocksource.
+
+If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
+and specific timer as clocksource, you can number the timers in "aliases" node.
+
+If device tree contain only one timer and the timer is named as timer1 in
+"aliases" node, then the timer will be initialized as clocksource.
+
+Example (clockevent only):
timer: timer at ff810000 {
compatible = "rockchip,rk3288-timer";
reg = <0xff810000 0x20>;
@@ -24,3 +35,25 @@ Example:
clocks = <&xin24m>, <&cru PCLK_TIMER>;
clock-names = "timer", "pclk";
};
+
+Example (clockevent and clocksource with explicit numbering):
+ aliases {
+ timer0 = &timer6;
+ timer1 = &timer5;
+ };
+
+ timer5: timer at 20038080 {
+ compatible = "rockchip,rk3188-timer", "rockchip,rk3288-timer";
+ reg = <0x20038080 0x20>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER5>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ };
+
+ timer6: timer at 200380A0 {
+ compatible = ""rockchip,rk3188-timer", rockchip,rk3288-timer";
+ reg = <0x200380A0 0x20>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER6>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: dts: imx6qdl-ntirogen6x: remove duplicate iomux entry
From: Gary Bisson @ 2016-11-24 23:16 UTC (permalink / raw)
To: linux-arm-kernel
The NANDF_CS2 pad is also part of the wlan-vmmcgrp iomux group.
Removing is from the usdhc2grp group avoids the following error:
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_NANDF_CS2 already requested
by regulators:regulator at 4; cannot claim for 2194000.usdhc
imx6q-pinctrl 20e0000.iomuxc: pin-187 (2194000.usdhc) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 187
(MX6Q_PAD_NANDF_CS2) from group usdhc2grp on device 20e0000.iomuxc
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..26d0604 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -533,7 +533,6 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071
- MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x000b0
>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2] ARM: dts: imx6qdl-nitrogen6x: remove duplicate iomux entry
From: Gary Bisson @ 2016-11-24 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124231638.12840-1-gary.bisson@boundarydevices.com>
The NANDF_CS2 pad is also part of the wlan-vmmcgrp iomux group.
Removing is from the usdhc2grp group avoids the following error:
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_NANDF_CS2 already requested
by regulators:regulator at 4; cannot claim for 2194000.usdhc
imx6q-pinctrl 20e0000.iomuxc: pin-187 (2194000.usdhc) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 187
(MX6Q_PAD_NANDF_CS2) from group usdhc2grp on device 20e0000.iomuxc
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
Hi all,
Changelog v1->v2:
- fix typo in patch title
Regards,
Gary
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..26d0604 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -533,7 +533,6 @@
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071
- MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x000b0
>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3
From: megous at megous.com @ 2016-11-25 0:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a known stable 24 MHz oscillator.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Tested-by: Lutz Sammer <johns98@gmx.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 614d47c..cf266c9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -809,6 +809,13 @@ static const struct sunxi_ccu_desc sun8i_h3_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
};
+static struct ccu_mux_nb sun8i_h3_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_h3_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -827,6 +834,9 @@ static void __init sun8i_h3_ccu_setup(struct device_node *node)
writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
sunxi_ccu_probe(node, reg, &sun8i_h3_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_h3_cpu_nb);
}
CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
sun8i_h3_ccu_setup);
--
2.10.2
^ permalink raw reply related
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-11-25 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e6ca0941-e2e3-dd93-d4d3-8fbd76b60e17@gmail.com>
On Thu, Nov 24, 2016 at 7:55 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 24/11/2016 ? 09:05, Martin Blumenstingl a ?crit :
>> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>>> cycle TX clock delay. This seems to work fine for many boards (for
>>>> example Odroid-C2 or Amlogic's reference boards) but there are some
>>>> others where TX traffic is simply broken.
>>>> There are probably multiple reasons why it's working on some boards
>>>> while it's broken on others:
>>>> - some of Amlogic's reference boards are using a Micrel PHY
>>>> - hardware circuit design
>>>> - maybe more...
>>>>
>>>> This raises a question though:
>>>> Which device is supposed to enable the TX delay when both MAC and PHY
>>>> support it? And should we implement it for each PHY / MAC separately
>>>> or should we think about a more generic solution (currently it's not
>>>> possible to disable the TX delay generated by the RTL8211F PHY via
>>>> devicetree when using phy-mode "rgmii")?
>>>
>>> Actually you can skip the part which activate the Tx-delay on the phy
>>> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>>>
>>> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
>>> but PHY_INTERFACE_MODE_RGMII_ID.
>> unfortunately this is not true for RTL8211F (I did my previous tests
>> with the same expectation in mind)!
>> the code seems to suggest that TX-delay is disabled whenever mode !=
>> PHY_INTERFACE_MODE_RGMII.
>> BUT: on my device RTL8211F_TX_DELAY is set even before
>> "phy_write(phydev, 0x11, reg);"!
>
> (Adding Sebastian (and Mans, and Andrew) since he raised the same
> question a while ago. I think I now understand a bit better what
> Sebastian was after a couple of weeks ago)
>
>>
>> Based on what I found it seems that rgmii-id, rgmii-txid and
>> rgmii-rxid are supposed to be handled by the PHY.
>
> Correct, the meaning of PHY_INTERFACE_MODE should be from the
> perspective of the PHY device:
>
> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
and PHY_INTERFACE_MODE_RGMII_ID is basically _TXID and _RXID combined
(meaning that the PHY is responsible for the TX and RX delays)
>> That would mean that we have two problems here:
>> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
>> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
>> enable the TX-delay in that case - otherwise explicitly disable it
>
> Agreed.
(on a side-not: it seems that the RTL8211F's TX-delay setting is
either untouched by a hardware reset via GPIO or enabled automatically
during hardware reset via GPIO)
>> 2) dwmac-meson8b.c should only use the configured TX-delay for
>> PHY_INTERFACE_MODE_RGMII
>> @Florian: could you please share your thoughts on this (who handles
>> the TX delay in which case)?
>
> This also seems reasonable to do, provided that the PHY is also properly
> configured not to add delays in both directions, and therefore assumes
> that the MAC does it.
on Amlogic Meson systems (at least on the ARM64 ones) all customer
devices with Gbit ethernet are using the RTL8211F PHY. The only
exception are some development/reference boards from Amlogic
themselves, which seem to be using a Micrel RGMII PHY.
> We have a fairly large problem with how RGMII delays are done in PHYLIB
> and Ethernet MAC drivers (or just in general), where we can't really
> intersect properly what a PHY is supporting (in terms of internal
> delays), and what the MAC supports either. One possible approach could
> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
> support (ideally, even with normalized nanosecond delay values), and
> then intersect that with the requested phy_interface_t during
> phy_{attach,connect} time, and feed this back to the MAC with a special
> error code/callback, so we could gracefully try to choose another
> PHY_INTERFACE_MODE_* value that the MAC supports....
>
> A larger problem is that a number of drivers have been deployed, and
> Device Trees, possibly with the meaning of "phy-mode" and
> "phy-connection-type" being from the MAC perspective, and not the PHY
> perspective *sigh*, good luck auditing those.
>
> So from there, here is possibly what we could do
>
> - submit a series of patches that update the PHYLIB documentation (there
> are other things missing here) and make it clear from which entity (PHY
> or MAC) does the delay apply to, document the "intersection" problem here
sounds like a good idea, maybe we should move this to a separate thread (I guess
this is the part which is especially interesting for Sebastian, Mans
and Andrew)?
> - have you document the configured behavior for dwmac-meson8b that we
> just discussed here in v2 of this patch series
I would add something like "...using the phy-modes rgmii-id or
rgmii-txid means that the TX-delay will be added by the PHY, thus no
TX-delay should be configured for the MAC/dwmac-meson8b glue" (I'll
improve this, I just want a quick confirmation that I get your idea
right)
Thanks for the quick and helpful answer Florian!
Regards,
Martin
^ permalink raw reply
* [PATCH v2 0/2] SCPI (pre-v1.0): fix reading sensor value
From: Martin Blumenstingl @ 2016-11-25 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124001845.20830-1-martin.blumenstingl@googlemail.com>
I observed the following "strange" value when trying to read the SCPI
temperature sensor on my Amlogic GXM S912 device:
$ cat /sys/class/hwmon/hwmon0/temp1_input
6875990994467160116
The value reported by the original kernel (Amlogic vendor kernel, after
a reboot obviously) was 53C.
The Amlogic SCPI driver only uses a single 32bit value to read the
sensor value, instead of two. After stripping the upper 32bits from
above value gives "52" as result, which is basically identical to
what the vendor kernel reports.
I also compared this with the value shown by u-boot (since there's
less delay between "reboot to u-boot" compared to "reboot from mainline
kernel to vendor kernel") and the temperature reported by u-boot always
matches the lower 32bits of the value from scpi-hwmon temp1_input.
Version 1 of this series introduced a separate function for reading the
sensor value on pre-v1.0 SCPI firmwares. I also tried initializing the
"buf" variable in scpi_sensor_get_value() but this didn't work (because
we request a 64bit payload from the SCPI firmware, but the firmware only
replies with a 32bit payload).
Version 2 is different as it does not require a "legacy implementation"
for scpi_sensor_get_value(). Instead the rx_buf is zeroed out before
reading the buffer from the mailbox. This works fine as well, since the
sensor_value.hi_val field was added after sensor_value.lo_val (meaning
it is backwards compatible, as long as hi_val is all zeroes on
pre-v1.0 SCPI firmwares).
A small benefit we get from this: we are now able to handle all
commands where new fields are introduced at the end of receive buffer
(which might be relevant also for future SCPI implementations - but
this is pure speculation).
I did not remove the memset(buf, 0, len) in scpi_process_cmd() because
I am not sure if there are v1.0 SCPI firmwares out there which respond
that X bytes are available in the rx_buf while it actually writes more
data (X + n where n > 0 bytes) than indicated.
Changes since v1:
- zero out the rx_buf before reading the mbox buffer (see long
description above) instead of introducing a separate legacy command
for reading the sensor value
- added patch 2/2 which validates the payload lengths (so nobody can
read or write data beyond rx_buf or tx_buf). This optional and patch
1/2 can be applied without it
Martin Blumenstingl (2):
firmware: arm_scpi: zero RX buffer before requesting data from the
mbox
firmware: arm_scpi: check the payload length in scpi_send_message
drivers/firmware/arm_scpi.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
--
2.10.2
^ 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