* [PATCH v2 3/3] arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
From: Andrew Lunn @ 2016-12-20 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c27998fd-3807-5c99-382b-b8d0d0f06526@free-electrons.com>
> >>+ mdio {
> >>+ #address-cells = <1>;
> >>+ #size-cells = <0>;
> >>+ reg = <1>;
> >
> >what is this reg value for?
> >
> > Andrew
> >
>
> It was required to avoid a warning thrown by the mdio subsystem
Do you remember what the warning was?
This seems odd to me. I don't see why a reg is needed here.
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
From: Romain Perier @ 2016-12-20 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220154234.GC30952@lunn.ch>
Hi,
Le 20/12/2016 ? 16:42, Andrew Lunn a ?crit :
>> +&mdio {
>> + switch0: switch0 at 0 {
>> + compatible = "marvell,mv88e6085";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>
> Ah, sorry, missed this last time. reg = <1>, that means switch0 at 1.
> That is a general rule for all device tree bindings.
Ahhh, I did not pay attention either :/
I will fix this.
>
>> + mdio {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>
> what is this reg value for?
>
> Andrew
>
It was required to avoid a warning thrown by the mdio subsystem
Romain
^ permalink raw reply
* [PATCH 2/2] arm64: defconfig: enable CONFIG_MTD_NAND and CONFIG_MTD_NAND_DENALI_DT
From: Masahiro Yamada @ 2016-12-20 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482249893-14988-1-git-send-email-yamada.masahiro@socionext.com>
Enable the NAND framework and the Denali NAND controller driver.
This NAND controller is used on UniPhier SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 32d73ab..0888cab 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -145,6 +145,8 @@ CONFIG_DMA_CMA=y
CONFIG_MTD=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_DENALI_DT=y
CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: defconfig: enable CONFIG_MTD_BLOCK
From: Masahiro Yamada @ 2016-12-20 16:04 UTC (permalink / raw)
To: linux-arm-kernel
Enable the block layer support for MTD devices.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 869dded..32d73ab 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -143,6 +143,7 @@ CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_DMA_CMA=y
CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
--
2.7.4
^ permalink raw reply related
* [linux-sunxi][PATCH] ARM: dts: sun4i: A1000: add axp209 regulator nodes
From: Code Kipper @ 2016-12-20 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220141613.czhs54laqpovidej@lukather>
On 20 December 2016 at 15:16, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Dec 20, 2016 at 11:22:42AM +0100, codekipper at gmail.com wrote:
>> From: Marcus Cooper <codekipper@gmail.com>
>>
>> This patch adds the regulator nodes for the axp209 by including
>> the axp209 dtsi.
>>
>> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
>> ---
>> arch/arm/boot/dts/sun4i-a10-a1000.dts | 34 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> index 68c6bdb2cf7c..e7394d701856 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> @@ -196,6 +196,40 @@
>> };
>> };
>>
>> +#include "axp209.dtsi"
>> +
>> +®_dcdc2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-name = "vdd-cpu";
>> +};
>> +
>> +®_dcdc3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1250000>;
>> + regulator-name = "vdd-int-dll";
>> +};
>> +
>> +®_ldo1 {
>> + regulator-name = "vdd-rtc";
>> +};
>> +
>> +®_ldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-name = "avcc";
>> +};
>> +
>> +®_ldo3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <2800000>;
>> + regulator-max-microvolt = <2800000>;
>> + regulator-name = "vcc-wifi";
>
> If this is used only for the wifi, there's no point in keeping it
> enabled.
>
> Also, taking the chance to enable cpufreq by setting the cpu-suplly
> property would be a good idea.
Ack....fortunately my A1000 was out of it's box as I've been looking
at the channel reversal issue. I'll respin now.
CK
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v2] ARM: dts: sun4i: A1000: add axp209 regulator nodes
From: codekipper at gmail.com @ 2016-12-20 15:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
This patch adds the regulator nodes for the axp209 by including
the axp209 dtsi.
DCDC2 is used as the cpu power supply. This patch also references
it from the cpu node.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
arch/arm/boot/dts/sun4i-a10-a1000.dts | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
index 68c6bdb2cf7c..f3fc27412a67 100644
--- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
+++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
@@ -117,6 +117,10 @@
status = "okay";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&ehci0 {
status = "okay";
};
@@ -196,6 +200,33 @@
};
};
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
®_usb1_vbus {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/7] Documentation: DT: bindings: iio: adc: add documentation for Allwinner SoCs' GPADC driver
From: Quentin Schulz @ 2016-12-20 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220142554.rcocnculfehiwhpn@lukather>
Hi,
On 20/12/2016 15:25, Maxime Ripard wrote:
> Hi,
>
> On Tue, Dec 20, 2016 at 11:27:03AM +0100, Quentin Schulz wrote:
[...]
>> +Currently, the touchscreen controller does not have a driver using this ADC
>> +driver. The touchscreen controller is currently driven only by
>> +input/touchscreen/sun4i-ts.c which is absolutely incompatible with this driver.
>> +
>> +The Allwinner A10, A13 and A31 SoCs already have a DT binding for the
>> +aforementioned input driver, thus an MFD driver matches the existing DT binding
>> +(mfd/sun4i-gpadc.c) and replaces the input driver. No DT binding is required for
>> +these SoCs' ADC, everything is handled by the MFD which is matching the existing
>> +DT binding for input/touchscreen/sun4i-ts.c.
>> +
>> +The Allwinner A33 GPADC only have a thermal sensor and have a proper DT binding
>> +for this driver unlike the previously mentioned SoCs.
>
> The DT bindings should be agnostic from the OS. You can remove all
> mention of the implementations details in Linux.
>
> (and you should wrap at 72 characters).
>
> But we already have a binding document for that controller, so you
> shouldn't create a new one, reuse the old one that is already there.
>
ACK.
>> +Required properties:
>> + - compatible: "allwinner,sun8i-a33-gpadc-iio"
>
> IIO is an implementation detail. The IP is called GPADC.
> You're also missing reg.
>
ACK.
>> +
>> +Optional properties:
>> +(for use with thermal framework for CPU thermal throttling for example, and/or
>> + IIO consumers)
>> + - #thermal-sensor-cells = <0>; (see
>> +Documentation/devicetree/bindings/thermal/thermal.txt)
>> + - #io-channel-cells = <0>; (see
>> +Documentation/devicetree/bindings/iio/iio-bindings.txt)
>
> I wouldn't list that as optional.
>
In what sense? Do you mean you wouldn't put them here at all or you
would require them?
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
From: Andrew Lunn @ 2016-12-20 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220085138.3998-4-romain.perier@free-electrons.com>
> +&mdio {
> + switch0: switch0 at 0 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
Ah, sorry, missed this last time. reg = <1>, that means switch0 at 1.
That is a general rule for all device tree bindings.
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
what is this reg value for?
Andrew
^ permalink raw reply
* [PATCH v2 2/3] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Andrew Lunn @ 2016-12-20 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220085138.3998-3-romain.perier@free-electrons.com>
On Tue, Dec 20, 2016 at 09:51:37AM +0100, Romain Perier wrote:
> The Marvell 88E6341 device is single-chip, 6-port ethernet switch with
> four integrated 10/100/1000Mbps ethernet transceivers and one high speed
> SerDes interfaces. It is compatible with switches of family 88E6352.
>
> This commit adds basic support for this switch by describing its
> capabilities to the driver.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: imx28: Add simple-card support
From: Jörg Krause @ 2016-12-20 15:35 UTC (permalink / raw)
To: linux-arm-kernel
Add simple-card support to SAIF0 and SAIF1.
Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
arch/arm/boot/dts/imx28.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index afcf687..5783e26 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1087,6 +1087,7 @@
};
saif0: saif at 80042000 {
+ #sound-dai-cells = <0>;
compatible = "fsl,imx28-saif";
reg = <0x80042000 0x2000>;
interrupts = <59>;
@@ -1104,6 +1105,7 @@
};
saif1: saif at 80046000 {
+ #sound-dai-cells = <0>;
compatible = "fsl,imx28-saif";
reg = <0x80046000 0x2000>;
interrupts = <58>;
--
2.10.2
^ permalink raw reply related
* [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8
From: James Morse @ 2016-12-20 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481147303-7979-6-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
On 07/12/16 21:48, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchrounous External
> Abort) notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into the SEA exception handler. That way GHES will parse and report
> SEA exceptions when they occur.
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 2acbc60..66ab3fd 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -767,6 +771,62 @@ static struct notifier_block ghes_notifier_sci = {
> .notifier_call = ghes_notify_sci,
> };
>
> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
> +static LIST_HEAD(ghes_sea);
> +
> +static int ghes_notify_sea(struct notifier_block *this,
> + unsigned long event, void *data)
> +{
> + struct ghes *ghes;
> + int ret = NOTIFY_DONE;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(ghes, &ghes_sea, list) {
> + if (!ghes_proc(ghes))
> + ret = NOTIFY_OK;
> + }
> + rcu_read_unlock();
> +
> + return ret;
> +}
What stops this from being re-entrant?
ghes_copy_tofrom_phs() takes the ghes_ioremap_lock_irq spinlock, but there is
nothing to stop a subsequent instruction fetch or memory access causing another
(maybe different) Synchronous External Abort which deadlocks trying to take the
same lock.
ghes_notify_sea() looks to be based on ghes_notify_sci(), which (if I've found
the right part of the ACPI spec) is a level-low interrupt. spin_lock_irqsave()
would mask interrupts so there is no risk of a different notification firing on
the same CPU, (it looks like they are almost all ultimately an irq).
NMI is the odd one out because its not maskable like this, but ghes_notify_nmi()
has:
> if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
> return ret;
To ensure there is only ever one thread poking around in this code.
What happens if a system describes two GHES sources, one using an irq the other
SEA? The SEA error can interrupt the irq error while its holding the above lock.
I guess this is also why all the NMI code in that file is separate.
Thanks,
James
^ permalink raw reply
* [PATCH 3/7] iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
From: Quentin Schulz @ 2016-12-20 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220144434.2u6ivige6kdto6an@lukather>
Hi,
On 20/12/2016 15:44, Maxime Ripard wrote:
> On Tue, Dec 20, 2016 at 11:27:05AM +0100, Quentin Schulz wrote:
>> This adds support for the Allwinner A33 thermal sensor.
>>
>> Unlike the A10, A13 and A31, the Allwinner A33 only has one channel
>> which is dedicated to the thermal sensor. Moreover, its thermal sensor
>> does not generate interruptions, thus we only need to directly read the
>> register storing the temperature value.
>>
>> The MFD used by the A10, A13 and A31, was created to avoid breaking the
>> DT binding, but since the nodes for the ADC weren't there for the A33,
>> it is not needed.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> ---
>> drivers/iio/adc/Kconfig | 21 ++--
>> drivers/iio/adc/sun4i-gpadc-iio.c | 204 ++++++++++++++++++++++++++++----------
>> include/linux/mfd/sun4i-gpadc.h | 4 +
>> 3 files changed, 172 insertions(+), 57 deletions(-)
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 6a6d369..06041ff 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -437,17 +437,24 @@ config STX104
>> config SUN4I_GPADC
>> tristate "Support for the Allwinner SoCs GPADC"
>> depends on IIO
>> - depends on MFD_SUN4I_GPADC
>> - help
>> - Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
>> - GPADC. This ADC provides 4 channels which can be used as an ADC or as
>> - a touchscreen input and one channel for thermal sensor.
>> -
>> - The thermal sensor slows down ADC readings and can be disabled by
>> +# MFD_SUN4I_GPADC is needed for sun4i, sun5i and sun6i but not for sun8i
>
> The indentation is wrong here, and I wouldn't list all the families
> there, this is just going to be always amended, for no particular
> reason.
>
ACK.
>> + select MFD_SUN4I_GPADC if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I
>
> Why did you change the depends on to a select?
>
The "depends on" does not have an if condition but "select" has. See:
https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
> And isn't that redundant with the comment just above?
>
>> +# THERMAL_OF can be disabled on sun4i, sun5i and sun6i to quicken ADC readings
>
> I'm not sure this is worth adding either. Any option can be added with
> any number of side effects, I'm not sure we want to list all of them.
>
ACK.
>> + depends on THERMAL_OF || MACH_SUN4I || MACH_SUN5I || MACH_SUN6I
>
> So you can't disable THERMAL_OF on MACH_SUN8I?
>
Not in the current state. devm_thermal_zone_of_sensor_register from
sun4i_gpadc_probe_dt returns an error if THERMAL_OF is disabled and
thus, the probe fails. Maybe it should rather fail silently and let the
user choose whether (s)he wants the thermal framework to be able to read
data from this driver?
>> + depends on !TOUCHSCREEN_SUN4I
>
> This should be a different patch.
>
>> + help
>> + Say yes here to build support for Allwinner (A10, A13, A31 and A33)
>> + SoCs GPADC.
>> +
>> + The ADC on A10, A13 and A31 provides 4 channels which can be used as
>> + an ADC or as a touchscreen input and one channel for thermal sensor.
>> + Their thermal sensor slows down ADC readings and can be disabled by
>
> Again, I'm not sure putting all those details in the Kconfig help
> really helps. This is only going to grow with more and more cases, and
> this isn't something really helpful anyway.
>
Are you suggesting to remove completely the paragraph on why it is
possible to disable CONFIG_THERMAL_OF for the A10, A13 and A31 or only
to remove the mention to SoCs?
>> disabling CONFIG_THERMAL_OF. However, the thermal sensor should be
>> enabled by default since the SoC temperature is usually more critical
>> than ADC readings.
>>
>> + The ADC on A33 provides one channel for thermal sensor.
>> +
>> To compile this driver as a module, choose M here: the module will be
>> called sun4i-gpadc-iio.
>>
>> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
>> index a8e134f..8be694e 100644
>> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
>> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
>> @@ -1,4 +1,4 @@
>> -/* ADC driver for sunxi platforms' (A10, A13 and A31) GPADC
>> +/* ADC driver for sunxi platforms' (A10, A13, A31 and A33) GPADC
>> *
>> * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.com>
>> *
>> @@ -85,6 +85,12 @@ static const struct gpadc_data sun6i_gpadc_data = {
>> .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
>> };
>>
>> +static const struct gpadc_data sun8i_gpadc_data = {
>> + .temp_offset = -1662,
>> + .temp_scale = 162,
>> + .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
>> +};
>> +
>> struct sun4i_gpadc_iio {
>> struct iio_dev *indio_dev;
>> struct completion completion;
>> @@ -96,6 +102,7 @@ struct sun4i_gpadc_iio {
>> unsigned int temp_data_irq;
>> atomic_t ignore_temp_data_irq;
>> const struct gpadc_data *data;
>> + bool use_dt;
>> /* prevents concurrent reads of temperature and ADC */
>> struct mutex mutex;
>> };
>> @@ -138,6 +145,23 @@ static const struct iio_chan_spec sun4i_gpadc_channels_no_temp[] = {
>> SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
>> };
>>
>> +static const struct iio_chan_spec sun8i_gpadc_channels[] = {
>
> sun8i_a33. Other SoCs from that same family might have different
> channels.
>
ACK.
>> + {
>> + .type = IIO_TEMP,
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
>> + BIT(IIO_CHAN_INFO_SCALE) |
>> + BIT(IIO_CHAN_INFO_OFFSET),
>> + .datasheet_name = "temp_adc",
>> + },
>> +};
>> +
>> +static const struct regmap_config sun4i_gpadc_regmap_config = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = 4,
>> + .fast_io = true,
>> +};
>> +
>> static int sun4i_prepare_for_irq(struct iio_dev *indio_dev, int channel,
>> unsigned int irq)
>> {
>> @@ -231,7 +255,6 @@ static int sun4i_gpadc_read(struct iio_dev *indio_dev, int channel, int *val,
>> err:
>> pm_runtime_put_autosuspend(indio_dev->dev.parent);
>> mutex_unlock(&info->mutex);
>> -
>> return ret;
>> }
>>
>> @@ -246,6 +269,19 @@ static int sun4i_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
>> static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
>> {
>> struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> + int ret;
>> +
>> + if (info->use_dt) {
>> + pm_runtime_get_sync(indio_dev->dev.parent);
>> +
>> + ret = regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
>> + if (!ret)
>> + pm_runtime_mark_last_busy(indio_dev->dev.parent);
>> +
>> + pm_runtime_put_autosuspend(indio_dev->dev.parent);
>> +
>> + return 0;
>> + }
>
> Why is runtime_pm linked to the DT support or not?
>
>>
>> return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
>> }
The same runtime_pm functions are called when the driver is not probed
from DT.
sun4i_gpadc_read will call sun4i_prepare_for_irq which does a
pm_runtime_get_sync and then at the end of sun4i_gpadc_read,
pm_runtime_mark_last_busy and pm_runtime_put_autosuspend are called.
I just noticed I forgot to add a comment on this one. The A33
documentation tells us there is an interrupt for the thermal sensor but
after struggling with it, it is just false. I validated my guess with
Allwinner Linux kernel which does not wait an interrupt to read the data
register of the thermal sensor.
sun4i_gpadc_read always wait for an interrupt before reading data regs,
so I'm just not calling it and doing the "logic" (reading the data reg
and interfacing with runtime_pm) directly here in sun4i_gpadc_temp.
I'll add a comment on this one. Maybe I should create a function just
for the "logic" of the A33 thermal sensor, so it is less weird than
currently.
>> @@ -410,7 +446,7 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
>> unsigned int *irq, atomic_t *atomic)
>> {
>> int ret;
>> - struct sun4i_gpadc_dev *mfd_dev = dev_get_drvdata(pdev->dev.parent);
>> + struct sun4i_gpadc_dev *mfd_dev;
>> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(&pdev->dev));
>>
>> /*
>> @@ -427,6 +463,8 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
>> */
>> atomic_set(atomic, 1);
>>
>> + mfd_dev = dev_get_drvdata(pdev->dev.parent);
>> +
>
> Why is that change necessary?
>
>> ret = platform_get_irq_byname(pdev, name);
>> if (ret < 0) {
>> dev_err(&pdev->dev, "no %s interrupt registered\n", name);
>> @@ -454,31 +492,68 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
>> return 0;
>> }
>>
>> -static int sun4i_gpadc_probe(struct platform_device *pdev)
>> +static const struct of_device_id sun4i_gpadc_of_id[] = {
>> + {
>> + .compatible = "allwinner,sun8i-a33-gpadc-iio",
>> + .data = &sun8i_gpadc_data,
>> + },
>> + { /* sentinel */ }
>> +};
>> +
>> +static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
>> + struct iio_dev *indio_dev)
>> {
>> - struct sun4i_gpadc_iio *info;
>> - struct iio_dev *indio_dev;
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> + const struct of_device_id *of_dev;
>> + struct thermal_zone_device *tzd;
>> + struct resource *mem;
>> + void __iomem *base;
>> int ret;
>> - struct sun4i_gpadc_dev *sun4i_gpadc_dev;
>>
>> - sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
>> + of_dev = of_match_device(sun4i_gpadc_of_id, &pdev->dev);
>> + if (!of_dev)
>> + return -ENODEV;
>> +
>> + info->use_dt = true;
>> + info->data = (struct gpadc_data *)of_dev->data;
>> + indio_dev->num_channels = ARRAY_SIZE(sun8i_gpadc_channels);
>> + indio_dev->channels = sun8i_gpadc_channels;
>> +
>> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + base = devm_ioremap_resource(&pdev->dev, mem);
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>> +
>> + info->regmap = devm_regmap_init_mmio(&pdev->dev, base,
>> + &sun4i_gpadc_regmap_config);
>> + if (IS_ERR(info->regmap)) {
>> + ret = PTR_ERR(info->regmap);
>> + dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
>> + return ret;
>> + }
>>
>> - indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> - if (!indio_dev)
>> - return -ENOMEM;
>> + tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, info,
>> + &sun4i_ts_tz_ops);
>> + if (IS_ERR(tzd)) {
>> + dev_err(&pdev->dev, "could not register thermal sensor: %ld\n",
>> + PTR_ERR(tzd));
>> + return PTR_ERR(tzd);
>> + }
>>
>> - info = iio_priv(indio_dev);
>> - platform_set_drvdata(pdev, indio_dev);
>> + return 0;
>> +}
>>
>> - mutex_init(&info->mutex);
>> +static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
>> + struct iio_dev *indio_dev)
>> +{
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>> + struct sun4i_gpadc_dev *sun4i_gpadc_dev;
>> + int ret;
>> +
>> + info->use_dt = false;
>> + sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
>> info->regmap = sun4i_gpadc_dev->regmap;
>> - info->indio_dev = indio_dev;
>> - init_completion(&info->completion);
>> - indio_dev->name = dev_name(&pdev->dev);
>> - indio_dev->dev.parent = &pdev->dev;
>> - indio_dev->dev.of_node = pdev->dev.of_node;
>> - indio_dev->info = &sun4i_gpadc_iio_info;
>> - indio_dev->modes = INDIO_DIRECT_MODE;
>> +
>
> You should have two patches. One to split the MFD part from the probe,
> and a second one to add the DT probing.
>
ACK.
>> indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
>> indio_dev->channels = sun4i_gpadc_channels;
>>
>> @@ -494,7 +569,6 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
>> * register the sensor if that option is enabled, eventually leaving
>> * that choice to the user.
>> */
>> -
>
> Spurious change?
>
Yes, lots of. Sorry, I will be more careful on that.
>> if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> /*
>> * This driver is a child of an MFD which has a node in the DT
>> @@ -519,8 +593,7 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
>> dev_err(&pdev->dev,
>> "could not register thermal sensor: %ld\n",
>> PTR_ERR(tzd));
>> - ret = PTR_ERR(tzd);
>> - goto err;
>> + return PTR_ERR(tzd);
>> }
>> } else {
>> indio_dev->num_channels =
>> @@ -528,49 +601,78 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
>> indio_dev->channels = sun4i_gpadc_channels_no_temp;
>> }
>>
>> - pm_runtime_set_autosuspend_delay(&pdev->dev,
>> - SUN4I_GPADC_AUTOSUSPEND_DELAY);
>> - pm_runtime_use_autosuspend(&pdev->dev);
>> - pm_runtime_set_suspended(&pdev->dev);
>> - pm_runtime_enable(&pdev->dev);
>> -
>> if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
>> sun4i_gpadc_temp_data_irq_handler,
>> "temp_data", &info->temp_data_irq,
>> &info->ignore_temp_data_irq);
>> if (ret < 0)
>> - goto err;
>> - }
>> + return ret;
>>
>> - ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
>> - sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
>> - &info->fifo_data_irq, &info->ignore_fifo_data_irq);
>> - if (ret < 0)
>> - goto err;
>> + ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
>> + sun4i_gpadc_fifo_data_irq_handler,
>> + "fifo_data", &info->fifo_data_irq,
>> + &info->ignore_fifo_data_irq);
>> + if (ret < 0)
>> + return ret;
>> + }
>>
>> - if (IS_ENABLED(CONFIG_THERMAL_OF)) {
>> - ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
>> - if (ret < 0) {
>> - dev_err(&pdev->dev,
>> - "failed to register iio map array\n");
>> - goto err;
>> - }
>> + ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "failed to register iio map array\n");
>> + return ret;
>> }
>>
>> + return 0;
>> +}
>> +
>> +static int sun4i_gpadc_probe(struct platform_device *pdev)
>> +{
>> + struct sun4i_gpadc_iio *info;
>> + struct iio_dev *indio_dev;
>> + int ret;
>> +
>> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + info = iio_priv(indio_dev);
>> + platform_set_drvdata(pdev, indio_dev);
>> +
>> + mutex_init(&info->mutex);
>> + info->indio_dev = indio_dev;
>> + init_completion(&info->completion);
>> + indio_dev->name = dev_name(&pdev->dev);
>> + indio_dev->dev.parent = &pdev->dev;
>> + indio_dev->dev.of_node = pdev->dev.of_node;
>> + indio_dev->info = &sun4i_gpadc_iio_info;
>> + indio_dev->modes = INDIO_DIRECT_MODE;
>> +
>> + if (pdev->dev.of_node)
>> + ret = sun4i_gpadc_probe_dt(pdev, indio_dev);
>> + else
>> + ret = sun4i_gpadc_probe_mfd(pdev, indio_dev);
>> +
>> + if (ret)
>> + return ret;
>> +
>> + pm_runtime_set_autosuspend_delay(&pdev->dev,
>> + SUN4I_GPADC_AUTOSUSPEND_DELAY);
>> + pm_runtime_use_autosuspend(&pdev->dev);
>> + pm_runtime_set_suspended(&pdev->dev);
>> + pm_runtime_enable(&pdev->dev);
>> +
>> ret = devm_iio_device_register(&pdev->dev, indio_dev);
>> if (ret < 0) {
>> dev_err(&pdev->dev, "could not register the device\n");
>> - goto err_map;
>> + goto err;
>> }
>>
>> return 0;
>>
>> -err_map:
>> - if (IS_ENABLED(CONFIG_THERMAL_OF))
>> - iio_map_array_unregister(indio_dev);
>> -
>> err:
>> + if (!info->use_dt && IS_ENABLED(CONFIG_THERMAL_OF))
>> + iio_map_array_unregister(indio_dev);
>> pm_runtime_put(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>>
>> @@ -580,10 +682,11 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
>> static int sun4i_gpadc_remove(struct platform_device *pdev)
>> {
>> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>>
>> pm_runtime_put(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>> - if (IS_ENABLED(CONFIG_THERMAL_OF))
>> + if (!info->use_dt && IS_ENABLED(CONFIG_THERMAL_OF))
>> iio_map_array_unregister(indio_dev);
>>
>> return 0;
>> @@ -599,6 +702,7 @@ static const struct platform_device_id sun4i_gpadc_id[] = {
>> static struct platform_driver sun4i_gpadc_driver = {
>> .driver = {
>> .name = "sun4i-gpadc-iio",
>> + .of_match_table = sun4i_gpadc_of_id,
>> .pm = &sun4i_gpadc_pm_ops,
>> },
>> .id_table = sun4i_gpadc_id,
>> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
>> index 509e736..139872c 100644
>> --- a/include/linux/mfd/sun4i-gpadc.h
>> +++ b/include/linux/mfd/sun4i-gpadc.h
>> @@ -38,6 +38,10 @@
>> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
>> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>>
>> +/* TP_CTRL1 bits for sun8i SoCs */
>> +#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
>> +#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
>> +
>> #define SUN4I_GPADC_CTRL2 0x08
>>
>> #define SUN4I_GPADC_CTRL2_TP_SENSITIVE_ADJUST(x) ((GENMASK(3, 0) & (x)) << 28)
>> --
>> 2.9.3
>>
>
> Thanks,
> Maxime
>
Thanks,
Quentin
--
Quentin Schulz, 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: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161220/6300bcb0/attachment.sig>
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2016-12-20 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Booting Linux on an ARM fastmodel containing an SMMU emulation results
in an unexpected I/O page fault from the legacy virtio-blk PCI device:
[ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
[ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
[ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
[ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
[ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
[ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
[ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
[ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
[ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
[ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
<system hangs failing to read partition table>
This is because the virtio-blk is behind an SMMU, so we have consequently
swizzled its DMA ops and configured the SMMU to translate accesses. This
then requires the vring code to use the DMA API to establish translations,
otherwise all transactions will result in fatal faults and termination.
Given that ARM-based systems only see an SMMU if one is really present
(the topology is all described by firmware tables such as device-tree or
IORT), then we can safely use the DMA API for all virtio devices.
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
drivers/virtio/virtio_ring.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index ed9c9eeedfe5..06b91e29d1b7 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -159,6 +159,10 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
if (xen_domain())
return true;
+ /* On ARM-based machines, the DMA ops will do the right thing */
+ if (IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64))
+ return true;
+
return false;
}
--
2.1.4
^ permalink raw reply related
* [PATCH] ASoC: sun4i-i2s: Add quirks for newer SoCs
From: codekipper at gmail.com @ 2016-12-20 14:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
Newer SoCs have additional functionality so a quirks structure
has been added to handle them. So far we've seen the use of a
reset controller, a different address for the TXFIFO and varying
register changes.
This patch prepares the driver for these changes and adds the
reset specifier.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
.../devicetree/bindings/sound/sun4i-i2s.txt | 2 +
sound/soc/sunxi/sun4i-i2s.c | 47 ++++++++++++++++++++--
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7a2c0945fd22..494a881ccd21 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -18,6 +18,8 @@ Required properties:
- "apb" : clock for the I2S bus interface
- "mod" : module clock for the I2S controller
- #sound-dai-cells : Must be equal to 0
+- resets: reset specifier for the ahb reset (A31 and newer only)
+
Example:
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index f24d19526603..80fe4f1d6e3b 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -14,9 +14,11 @@
#include <linux/clk.h>
#include <linux/dmaengine.h>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
+#include <linux/reset.h>
#include <sound/dmaengine_pcm.h>
#include <sound/pcm_params.h>
@@ -92,6 +94,7 @@ struct sun4i_i2s {
struct clk *bus_clk;
struct clk *mod_clk;
struct regmap *regmap;
+ struct reset_control *rst;
unsigned int mclk_freq;
@@ -104,6 +107,13 @@ struct sun4i_i2s_clk_div {
u8 val;
};
+struct sun4i_i2s_quirks {
+ unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
+ bool has_reset;
+ const struct regmap_config *sun4i_i2s_regmap;
+ const struct snd_soc_dai_ops *ops;
+};
+
static const struct sun4i_i2s_clk_div sun4i_i2s_bclk_div[] = {
{ .div = 2, .val = 0 },
{ .div = 4, .val = 1 },
@@ -541,7 +551,6 @@ static struct snd_soc_dai_driver sun4i_i2s_dai = {
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
- .ops = &sun4i_i2s_dai_ops,
.symmetric_rates = 1,
};
@@ -655,6 +664,7 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
{
struct sun4i_i2s *i2s;
struct resource *res;
+ const struct sun4i_i2s_quirks *quirks;
void __iomem *regs;
int irq, ret;
@@ -680,8 +690,14 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
return PTR_ERR(i2s->bus_clk);
}
+ quirks = of_device_get_match_data(&pdev->dev);
+ if (quirks == NULL) {
+ dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
+ return -ENODEV;
+ }
+
i2s->regmap = devm_regmap_init_mmio(&pdev->dev, regs,
- &sun4i_i2s_regmap_config);
+ quirks->sun4i_i2s_regmap);
if (IS_ERR(i2s->regmap)) {
dev_err(&pdev->dev, "Regmap initialisation failed\n");
return PTR_ERR(i2s->regmap);
@@ -692,13 +708,25 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Can't get our mod clock\n");
return PTR_ERR(i2s->mod_clk);
}
+
- i2s->playback_dma_data.addr = res->start + SUN4I_I2S_FIFO_TX_REG;
+ i2s->playback_dma_data.addr = res->start + quirks->reg_dac_txdata;
i2s->playback_dma_data.maxburst = 4;
i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG;
i2s->capture_dma_data.maxburst = 4;
+ if (quirks->has_reset) {
+ i2s->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
+ if (IS_ERR(i2s->rst) && PTR_ERR(i2s->rst) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ dev_err(&pdev->dev, "Failed to get reset: %d\n", ret);
+ goto err_pm_disable;
+ }
+ if (!IS_ERR(i2s->rst))
+ reset_control_deassert(i2s->rst);
+ }
+
pm_runtime_enable(&pdev->dev);
if (!pm_runtime_enabled(&pdev->dev)) {
ret = sun4i_i2s_runtime_resume(&pdev->dev);
@@ -706,6 +734,8 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
goto err_pm_disable;
}
+ /* Register ops with dai */
+ sun4i_i2s_dai.ops = quirks->ops;
ret = devm_snd_soc_register_component(&pdev->dev,
&sun4i_i2s_component,
&sun4i_i2s_dai, 1);
@@ -742,8 +772,17 @@ static int sun4i_i2s_remove(struct platform_device *pdev)
return 0;
}
+static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = {
+ .reg_dac_txdata = SUN4I_I2S_FIFO_TX_REG,
+ .sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
+ .ops = &sun4i_i2s_dai_ops,
+};
+
static const struct of_device_id sun4i_i2s_match[] = {
- { .compatible = "allwinner,sun4i-a10-i2s", },
+ {
+ .compatible = "allwinner,sun4i-a10-i2s",
+ .data = &sun4i_a10_i2s_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_i2s_match);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ASoC: sun4i-spdif: Add quirks to the spdif driver
From: codekipper at gmail.com @ 2016-12-20 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220144914.30945-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
It has been seen that some newer SoCs have a different TX FIFO
address and we already have the difference with the A31 requiring
a reset. Add a quirks structure so that these can be managed
easily.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-spdif.c | 36 +++++++++++++++++++++++++++++++-----
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index 048de15d6937..fec62ee1fc72 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -403,9 +403,29 @@ static struct snd_soc_dai_driver sun4i_spdif_dai = {
.name = "spdif",
};
+struct sun4i_spdif_quirks {
+ unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
+ bool has_reset;
+};
+
+static const struct sun4i_spdif_quirks sun4i_a10_spdif_quirks = {
+ .reg_dac_txdata = SUN4I_SPDIF_TXFIFO,
+};
+
+static const struct sun4i_spdif_quirks sun6i_a31_spdif_quirks = {
+ .reg_dac_txdata = SUN4I_SPDIF_TXFIFO,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_spdif_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-spdif", },
- { .compatible = "allwinner,sun6i-a31-spdif", },
+ {
+ .compatible = "allwinner,sun4i-a10-spdif",
+ .data = &sun4i_a10_spdif_quirks,
+ },
+ {
+ .compatible = "allwinner,sun6i-a31-spdif",
+ .data = &sun6i_a31_spdif_quirks,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
@@ -438,6 +458,7 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
{
struct sun4i_spdif_dev *host;
struct resource *res;
+ const struct sun4i_spdif_quirks *quirks;
int ret;
void __iomem *base;
@@ -459,6 +480,12 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
if (IS_ERR(base))
return PTR_ERR(base);
+ quirks = of_device_get_match_data(&pdev->dev);
+ if (quirks == NULL) {
+ dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
+ return -ENODEV;
+ }
+
host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
&sun4i_spdif_regmap_config);
@@ -476,14 +503,13 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
goto err_disable_apb_clk;
}
- host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
+ host->dma_params_tx.addr = res->start + quirks->reg_dac_txdata;
host->dma_params_tx.maxburst = 8;
host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
platform_set_drvdata(pdev, host);
- if (of_device_is_compatible(pdev->dev.of_node,
- "allwinner,sun6i-a31-spdif")) {
+ if (quirks->has_reset) {
host->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
if (IS_ERR(host->rst) && PTR_ERR(host->rst) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] ASoC: sun4i-spdif: remove legacy dapm components
From: codekipper at gmail.com @ 2016-12-20 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220144914.30945-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
The dapm components are now handled by the ALSA SoC SPDIF DIT driver
so can be removed.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-spdif.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index 88fbb3a1e660..048de15d6937 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -403,14 +403,6 @@ static struct snd_soc_dai_driver sun4i_spdif_dai = {
.name = "spdif",
};
-static const struct snd_soc_dapm_widget dit_widgets[] = {
- SND_SOC_DAPM_OUTPUT("spdif-out"),
-};
-
-static const struct snd_soc_dapm_route dit_routes[] = {
- { "spdif-out", NULL, "Playback" },
-};
-
static const struct of_device_id sun4i_spdif_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-spdif", },
{ .compatible = "allwinner,sun6i-a31-spdif", },
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] ASoC: sun4i-spdif: Changes in preparation of supporting new SoCs
From: codekipper at gmail.com @ 2016-12-20 14:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
Hi All,
please find attached two patches. First being a cleanup of something that
shouldn't be in the code and the second adds the mechanism for supporting
newer Allwiner SoCs. There was a third patch in the series and that was
bringing in support of SPDIF on the Allwinner H3 but I've not been able to
test it so that I hear audio. As soon as I get some hardware with a SPDIF
connection I will confirm and push.
BR,
CK
Marcus Cooper (2):
ASoC: sun4i-spdif: remove legacy dapm components
ASoC: sun4i-spdif: Add quirks to the spdif driver
sound/soc/sunxi/sun4i-spdif.c | 36 +++++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 3/7] iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
From: Maxime Ripard @ 2016-12-20 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220102709.9504-4-quentin.schulz@free-electrons.com>
On Tue, Dec 20, 2016 at 11:27:05AM +0100, Quentin Schulz wrote:
> This adds support for the Allwinner A33 thermal sensor.
>
> Unlike the A10, A13 and A31, the Allwinner A33 only has one channel
> which is dedicated to the thermal sensor. Moreover, its thermal sensor
> does not generate interruptions, thus we only need to directly read the
> register storing the temperature value.
>
> The MFD used by the A10, A13 and A31, was created to avoid breaking the
> DT binding, but since the nodes for the ADC weren't there for the A33,
> it is not needed.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/iio/adc/Kconfig | 21 ++--
> drivers/iio/adc/sun4i-gpadc-iio.c | 204 ++++++++++++++++++++++++++++----------
> include/linux/mfd/sun4i-gpadc.h | 4 +
> 3 files changed, 172 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 6a6d369..06041ff 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -437,17 +437,24 @@ config STX104
> config SUN4I_GPADC
> tristate "Support for the Allwinner SoCs GPADC"
> depends on IIO
> - depends on MFD_SUN4I_GPADC
> - help
> - Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
> - GPADC. This ADC provides 4 channels which can be used as an ADC or as
> - a touchscreen input and one channel for thermal sensor.
> -
> - The thermal sensor slows down ADC readings and can be disabled by
> +# MFD_SUN4I_GPADC is needed for sun4i, sun5i and sun6i but not for sun8i
The indentation is wrong here, and I wouldn't list all the families
there, this is just going to be always amended, for no particular
reason.
> + select MFD_SUN4I_GPADC if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I
Why did you change the depends on to a select?
And isn't that redundant with the comment just above?
> +# THERMAL_OF can be disabled on sun4i, sun5i and sun6i to quicken ADC readings
I'm not sure this is worth adding either. Any option can be added with
any number of side effects, I'm not sure we want to list all of them.
> + depends on THERMAL_OF || MACH_SUN4I || MACH_SUN5I || MACH_SUN6I
So you can't disable THERMAL_OF on MACH_SUN8I?
> + depends on !TOUCHSCREEN_SUN4I
This should be a different patch.
> + help
> + Say yes here to build support for Allwinner (A10, A13, A31 and A33)
> + SoCs GPADC.
> +
> + The ADC on A10, A13 and A31 provides 4 channels which can be used as
> + an ADC or as a touchscreen input and one channel for thermal sensor.
> + Their thermal sensor slows down ADC readings and can be disabled by
Again, I'm not sure putting all those details in the Kconfig help
really helps. This is only going to grow with more and more cases, and
this isn't something really helpful anyway.
> disabling CONFIG_THERMAL_OF. However, the thermal sensor should be
> enabled by default since the SoC temperature is usually more critical
> than ADC readings.
>
> + The ADC on A33 provides one channel for thermal sensor.
> +
> To compile this driver as a module, choose M here: the module will be
> called sun4i-gpadc-iio.
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> index a8e134f..8be694e 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -1,4 +1,4 @@
> -/* ADC driver for sunxi platforms' (A10, A13 and A31) GPADC
> +/* ADC driver for sunxi platforms' (A10, A13, A31 and A33) GPADC
> *
> * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.com>
> *
> @@ -85,6 +85,12 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
> };
>
> +static const struct gpadc_data sun8i_gpadc_data = {
> + .temp_offset = -1662,
> + .temp_scale = 162,
> + .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> +};
> +
> struct sun4i_gpadc_iio {
> struct iio_dev *indio_dev;
> struct completion completion;
> @@ -96,6 +102,7 @@ struct sun4i_gpadc_iio {
> unsigned int temp_data_irq;
> atomic_t ignore_temp_data_irq;
> const struct gpadc_data *data;
> + bool use_dt;
> /* prevents concurrent reads of temperature and ADC */
> struct mutex mutex;
> };
> @@ -138,6 +145,23 @@ static const struct iio_chan_spec sun4i_gpadc_channels_no_temp[] = {
> SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
> };
>
> +static const struct iio_chan_spec sun8i_gpadc_channels[] = {
sun8i_a33. Other SoCs from that same family might have different
channels.
> + {
> + .type = IIO_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .datasheet_name = "temp_adc",
> + },
> +};
> +
> +static const struct regmap_config sun4i_gpadc_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .fast_io = true,
> +};
> +
> static int sun4i_prepare_for_irq(struct iio_dev *indio_dev, int channel,
> unsigned int irq)
> {
> @@ -231,7 +255,6 @@ static int sun4i_gpadc_read(struct iio_dev *indio_dev, int channel, int *val,
> err:
> pm_runtime_put_autosuspend(indio_dev->dev.parent);
> mutex_unlock(&info->mutex);
> -
> return ret;
> }
>
> @@ -246,6 +269,19 @@ static int sun4i_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
> static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> {
> struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> + int ret;
> +
> + if (info->use_dt) {
> + pm_runtime_get_sync(indio_dev->dev.parent);
> +
> + ret = regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> + if (!ret)
> + pm_runtime_mark_last_busy(indio_dev->dev.parent);
> +
> + pm_runtime_put_autosuspend(indio_dev->dev.parent);
> +
> + return 0;
> + }
Why is runtime_pm linked to the DT support or not?
>
> return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
> }
> @@ -410,7 +446,7 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
> unsigned int *irq, atomic_t *atomic)
> {
> int ret;
> - struct sun4i_gpadc_dev *mfd_dev = dev_get_drvdata(pdev->dev.parent);
> + struct sun4i_gpadc_dev *mfd_dev;
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(&pdev->dev));
>
> /*
> @@ -427,6 +463,8 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
> */
> atomic_set(atomic, 1);
>
> + mfd_dev = dev_get_drvdata(pdev->dev.parent);
> +
Why is that change necessary?
> ret = platform_get_irq_byname(pdev, name);
> if (ret < 0) {
> dev_err(&pdev->dev, "no %s interrupt registered\n", name);
> @@ -454,31 +492,68 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
> return 0;
> }
>
> -static int sun4i_gpadc_probe(struct platform_device *pdev)
> +static const struct of_device_id sun4i_gpadc_of_id[] = {
> + {
> + .compatible = "allwinner,sun8i-a33-gpadc-iio",
> + .data = &sun8i_gpadc_data,
> + },
> + { /* sentinel */ }
> +};
> +
> +static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
> + struct iio_dev *indio_dev)
> {
> - struct sun4i_gpadc_iio *info;
> - struct iio_dev *indio_dev;
> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> + const struct of_device_id *of_dev;
> + struct thermal_zone_device *tzd;
> + struct resource *mem;
> + void __iomem *base;
> int ret;
> - struct sun4i_gpadc_dev *sun4i_gpadc_dev;
>
> - sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
> + of_dev = of_match_device(sun4i_gpadc_of_id, &pdev->dev);
> + if (!of_dev)
> + return -ENODEV;
> +
> + info->use_dt = true;
> + info->data = (struct gpadc_data *)of_dev->data;
> + indio_dev->num_channels = ARRAY_SIZE(sun8i_gpadc_channels);
> + indio_dev->channels = sun8i_gpadc_channels;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, mem);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + info->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> + &sun4i_gpadc_regmap_config);
> + if (IS_ERR(info->regmap)) {
> + ret = PTR_ERR(info->regmap);
> + dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
> + return ret;
> + }
>
> - indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> - if (!indio_dev)
> - return -ENOMEM;
> + tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, info,
> + &sun4i_ts_tz_ops);
> + if (IS_ERR(tzd)) {
> + dev_err(&pdev->dev, "could not register thermal sensor: %ld\n",
> + PTR_ERR(tzd));
> + return PTR_ERR(tzd);
> + }
>
> - info = iio_priv(indio_dev);
> - platform_set_drvdata(pdev, indio_dev);
> + return 0;
> +}
>
> - mutex_init(&info->mutex);
> +static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
> + struct iio_dev *indio_dev)
> +{
> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> + struct sun4i_gpadc_dev *sun4i_gpadc_dev;
> + int ret;
> +
> + info->use_dt = false;
> + sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
> info->regmap = sun4i_gpadc_dev->regmap;
> - info->indio_dev = indio_dev;
> - init_completion(&info->completion);
> - indio_dev->name = dev_name(&pdev->dev);
> - indio_dev->dev.parent = &pdev->dev;
> - indio_dev->dev.of_node = pdev->dev.of_node;
> - indio_dev->info = &sun4i_gpadc_iio_info;
> - indio_dev->modes = INDIO_DIRECT_MODE;
> +
You should have two patches. One to split the MFD part from the probe,
and a second one to add the DT probing.
> indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
> indio_dev->channels = sun4i_gpadc_channels;
>
> @@ -494,7 +569,6 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> * register the sensor if that option is enabled, eventually leaving
> * that choice to the user.
> */
> -
Spurious change?
> if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> /*
> * This driver is a child of an MFD which has a node in the DT
> @@ -519,8 +593,7 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> dev_err(&pdev->dev,
> "could not register thermal sensor: %ld\n",
> PTR_ERR(tzd));
> - ret = PTR_ERR(tzd);
> - goto err;
> + return PTR_ERR(tzd);
> }
> } else {
> indio_dev->num_channels =
> @@ -528,49 +601,78 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> indio_dev->channels = sun4i_gpadc_channels_no_temp;
> }
>
> - pm_runtime_set_autosuspend_delay(&pdev->dev,
> - SUN4I_GPADC_AUTOSUSPEND_DELAY);
> - pm_runtime_use_autosuspend(&pdev->dev);
> - pm_runtime_set_suspended(&pdev->dev);
> - pm_runtime_enable(&pdev->dev);
> -
> if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
> sun4i_gpadc_temp_data_irq_handler,
> "temp_data", &info->temp_data_irq,
> &info->ignore_temp_data_irq);
> if (ret < 0)
> - goto err;
> - }
> + return ret;
>
> - ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
> - sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
> - &info->fifo_data_irq, &info->ignore_fifo_data_irq);
> - if (ret < 0)
> - goto err;
> + ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
> + sun4i_gpadc_fifo_data_irq_handler,
> + "fifo_data", &info->fifo_data_irq,
> + &info->ignore_fifo_data_irq);
> + if (ret < 0)
> + return ret;
> + }
>
> - if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> - ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
> - if (ret < 0) {
> - dev_err(&pdev->dev,
> - "failed to register iio map array\n");
> - goto err;
> - }
> + ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to register iio map array\n");
> + return ret;
> }
>
> + return 0;
> +}
> +
> +static int sun4i_gpadc_probe(struct platform_device *pdev)
> +{
> + struct sun4i_gpadc_iio *info;
> + struct iio_dev *indio_dev;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + info = iio_priv(indio_dev);
> + platform_set_drvdata(pdev, indio_dev);
> +
> + mutex_init(&info->mutex);
> + info->indio_dev = indio_dev;
> + init_completion(&info->completion);
> + indio_dev->name = dev_name(&pdev->dev);
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->dev.of_node = pdev->dev.of_node;
> + indio_dev->info = &sun4i_gpadc_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + if (pdev->dev.of_node)
> + ret = sun4i_gpadc_probe_dt(pdev, indio_dev);
> + else
> + ret = sun4i_gpadc_probe_mfd(pdev, indio_dev);
> +
> + if (ret)
> + return ret;
> +
> + pm_runtime_set_autosuspend_delay(&pdev->dev,
> + SUN4I_GPADC_AUTOSUSPEND_DELAY);
> + pm_runtime_use_autosuspend(&pdev->dev);
> + pm_runtime_set_suspended(&pdev->dev);
> + pm_runtime_enable(&pdev->dev);
> +
> ret = devm_iio_device_register(&pdev->dev, indio_dev);
> if (ret < 0) {
> dev_err(&pdev->dev, "could not register the device\n");
> - goto err_map;
> + goto err;
> }
>
> return 0;
>
> -err_map:
> - if (IS_ENABLED(CONFIG_THERMAL_OF))
> - iio_map_array_unregister(indio_dev);
> -
> err:
> + if (!info->use_dt && IS_ENABLED(CONFIG_THERMAL_OF))
> + iio_map_array_unregister(indio_dev);
> pm_runtime_put(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -580,10 +682,11 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> static int sun4i_gpadc_remove(struct platform_device *pdev)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>
> pm_runtime_put(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> - if (IS_ENABLED(CONFIG_THERMAL_OF))
> + if (!info->use_dt && IS_ENABLED(CONFIG_THERMAL_OF))
> iio_map_array_unregister(indio_dev);
>
> return 0;
> @@ -599,6 +702,7 @@ static const struct platform_device_id sun4i_gpadc_id[] = {
> static struct platform_driver sun4i_gpadc_driver = {
> .driver = {
> .name = "sun4i-gpadc-iio",
> + .of_match_table = sun4i_gpadc_of_id,
> .pm = &sun4i_gpadc_pm_ops,
> },
> .id_table = sun4i_gpadc_id,
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 509e736..139872c 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -38,6 +38,10 @@
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>
> +/* TP_CTRL1 bits for sun8i SoCs */
> +#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> +#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +
> #define SUN4I_GPADC_CTRL2 0x08
>
> #define SUN4I_GPADC_CTRL2_TP_SENSITIVE_ADJUST(x) ((GENMASK(3, 0) & (x)) << 28)
> --
> 2.9.3
>
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/20161220/c8014a12/attachment-0001.sig>
^ permalink raw reply
* [linux-sunxi][PATCH 2/3] ARM: dts: sun6i: Add the SPDIF block to the A31
From: Code Kipper @ 2016-12-20 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220140709.pxvzcm3osmbromfh@lukather>
On 20 December 2016 at 15:07, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Dec 20, 2016 at 11:40:37AM +0100, codekipper at gmail.com wrote:
>> From: Marcus Cooper <codekipper@gmail.com>
>>
>> Add the SPDIF transceiver controller block to the A31 dtsi.
>>
>> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
>> ---
>> arch/arm/boot/dts/sun6i-a31.dtsi | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
>> index 7370ba6c9993..559c53efa7e6 100644
>> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
>> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
>> @@ -613,6 +613,20 @@
>> reg = <0x01c20ca0 0x20>;
>> };
>>
>> + spdif: spdif at 01c21000 {
>> + #sound-dai-cells = <0>;
>> + compatible = "allwinner,sun6i-a31-spdif";
>> + reg = <0x01c21000 0x400>;
>> + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&ccu CLK_APB1_SPDIF>, <&ccu CLK_SPDIF>;
>> + resets = <&ccu RST_APB1_SPDIF>;
>> + clock-names = "apb", "spdif";
>> + dmas = <&dma 2>, <&dma 2>;
>> + dma-names = "rx", "tx";
>> + spdif-out = "disabled";
>
> That property isn't documented anywhere, and doesn't seem to be used
> in your driver either.
Ooops....do you want me to respin a new patch or will you do your
magic with 'dd'? It fell through the cracks as it was cherry picked
from my dev branch where I was at one time playing with spdif-in. This
has pretty much been relegated to the bottom of my todo/finish list.
>
> On a separate topic, is the channel inversion bug also found on the
> A31?
I have seen this and I'm sure that was also on my A31 hardware but
I've just fired her up and the speaker test worked as expected. I also
repeated the test on my A10 device and didn't hear the issue.
CK
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 2/7] Documentation: DT: bindings: mfd: add documentation for Allwinner SoCs' GPADC MFD driver
From: Maxime Ripard @ 2016-12-20 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220102709.9504-3-quentin.schulz@free-electrons.com>
On Tue, Dec 20, 2016 at 11:27:04AM +0100, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> and sometimes as a touchscreen controller. If there is a touchscreen
> controller, the first four channels can be used either for the ADC or
> the touchscreen and the fifth channel is used for the thermal sensor.
> If there is not a touchscreen controller, the one and only channel is
> used for the thermal sensor.
>
> The Allwinner SoCs already have an existing DT binding for the
> touchscreen controller and thermal sensor for the sun4i-ts input driver
> which does let the user use the ADC. To keep backward compatibility,
> this MFD driver re-uses the same bindings as the sun4i-ts input driver
> and will probe the required drivers to make the ADC and thermal sensor
> work.
>
> This patch adds the binding documentation for the MFD driver of the
> Allwinner SoCs' GPADC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 47 ++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> new file mode 100644
> index 0000000..bc4b4f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -0,0 +1,47 @@
> +Allwinner SoCs' GPADC Device Tree bindings
> +------------------------------------------
> +
> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor and
> +sometimes as a touchscreen controller. If there is a touchscreen controller, the
> +first four channels can be used either for the ADC or the touchscreen and the
> +fifth channel is used for the thermal sensor.
> +If there is not a touchscreen controller, the one and only channel is used for
> +the thermal sensor.
> +
> +Currently, the touchscreen controller does not have a driver using this ADC
> +driver. The touchscreen controller is currently driven only by
> +input/touchscreen/sun4i-ts.c which is absolutely incompatible with this driver.
> +
> +The Allwinner A10, A13 and A31 SoCs already have a DT binding for the
> +aforementioned input driver, thus this MFD driver matches the existing DT
> +binding (mfd/sun4i-gpadc.c).
> +To keep DT binding compatibility, the MFD replaces the sun4i-ts input driver and
> +probes required drivers (IIO GPADC driver (iio/adc/sun4i-gpadc-iio.c),
> +iio-hwmon and soon the touchscreen driver) without the need for a DT binding for
> +each driver.
> +
> +Required properties:
> + - compatible: one of:
> + - "allwinner,sun4i-a10-ts",
> + - "allwinner,sun5i-a13-ts",
> + - "allwinner,sun6i-a31-ts"
> + - #thermal-sensor-cells = <0>;
Same thing here, we already have such a document, please amend it if
needed.
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/20161220/e00bb9e3/attachment.sig>
^ permalink raw reply
* [PATCH 1/7] Documentation: DT: bindings: iio: adc: add documentation for Allwinner SoCs' GPADC driver
From: Maxime Ripard @ 2016-12-20 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220102709.9504-2-quentin.schulz@free-electrons.com>
Hi,
On Tue, Dec 20, 2016 at 11:27:03AM +0100, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> and sometimes as a touchscreen controller. If there is a touchscreen
> controller, the first four channels can be used either for the ADC or
> the touchscreen and the fifth channel is used for the thermal sensor.
> If there is not a touchscreen controller, the one and only channel is
> used for the thermal sensor.
>
> This patch adds the documentation for the driver of the Allwinner SoCs'
> GPADC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> .../bindings/iio/adc/sun4i-gpadc-iio.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/sun4i-gpadc-iio.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/sun4i-gpadc-iio.txt b/Documentation/devicetree/bindings/iio/adc/sun4i-gpadc-iio.txt
> new file mode 100644
> index 0000000..aab768d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/sun4i-gpadc-iio.txt
> @@ -0,0 +1,57 @@
> +Allwinner SoCs' GPADC Device Tree bindings
> +------------------------------------------
> +
> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor and
> +sometimes as a touchscreen controller. If there is a touchscreen controller, the
> +first four channels can be used either for the ADC or the touchscreen and the
> +fifth channel is used for the thermal sensor.
> +If there is not a touchscreen controller, the one and only channel is used for
> +the thermal sensor.
> +
> +Currently, the touchscreen controller does not have a driver using this ADC
> +driver. The touchscreen controller is currently driven only by
> +input/touchscreen/sun4i-ts.c which is absolutely incompatible with this driver.
> +
> +The Allwinner A10, A13 and A31 SoCs already have a DT binding for the
> +aforementioned input driver, thus an MFD driver matches the existing DT binding
> +(mfd/sun4i-gpadc.c) and replaces the input driver. No DT binding is required for
> +these SoCs' ADC, everything is handled by the MFD which is matching the existing
> +DT binding for input/touchscreen/sun4i-ts.c.
> +
> +The Allwinner A33 GPADC only have a thermal sensor and have a proper DT binding
> +for this driver unlike the previously mentioned SoCs.
The DT bindings should be agnostic from the OS. You can remove all
mention of the implementations details in Linux.
(and you should wrap at 72 characters).
But we already have a binding document for that controller, so you
shouldn't create a new one, reuse the old one that is already there.
> +Required properties:
> + - compatible: "allwinner,sun8i-a33-gpadc-iio"
IIO is an implementation detail. The IP is called GPADC.
You're also missing reg.
> +
> +Optional properties:
> +(for use with thermal framework for CPU thermal throttling for example, and/or
> + IIO consumers)
> + - #thermal-sensor-cells = <0>; (see
> +Documentation/devicetree/bindings/thermal/thermal.txt)
> + - #io-channel-cells = <0>; (see
> +Documentation/devicetree/bindings/iio/iio-bindings.txt)
I wouldn't list that as optional.
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/20161220/34694221/attachment.sig>
^ permalink raw reply
* [linux-sunxi][PATCH] ARM: dts: sun4i: A1000: add axp209 regulator nodes
From: Maxime Ripard @ 2016-12-20 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220102242.2423-1-codekipper@gmail.com>
On Tue, Dec 20, 2016 at 11:22:42AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> This patch adds the regulator nodes for the axp209 by including
> the axp209 dtsi.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> arch/arm/boot/dts/sun4i-a10-a1000.dts | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> index 68c6bdb2cf7c..e7394d701856 100644
> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> @@ -196,6 +196,40 @@
> };
> };
>
> +#include "axp209.dtsi"
> +
> +®_dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-name = "vdd-cpu";
> +};
> +
> +®_dcdc3 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-name = "vdd-int-dll";
> +};
> +
> +®_ldo1 {
> + regulator-name = "vdd-rtc";
> +};
> +
> +®_ldo2 {
> + regulator-always-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-name = "avcc";
> +};
> +
> +®_ldo3 {
> + regulator-always-on;
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-name = "vcc-wifi";
If this is used only for the wifi, there's no point in keeping it
enabled.
Also, taking the chance to enable cpufreq by setting the cpu-suplly
property would be a good idea.
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/20161220/6f56d8f4/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] Mailbox changes for v4.10
From: Jassi Brar @ 2016-12-20 14:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 16ae16c6e5616c084168740990fc508bda6655d4:
Merge tag 'mmc-v4.9-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc (2016-11-24
10:51:18 -0800)
are available in the git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next
for you to fetch changes up to db4d22c07e3e652eeec82abcc1399e6305edd838:
mailbox: mailbox-test: allow reserved areas in SRAM (2016-12-19
20:10:23 +0530)
----------------------------------------------------------------
- New features (poll and SRAM usage) added to the mailbox-test driver
- Major update of Broadcom's PDC controller driver
- Minor fix for auto-loading test and STI driver modules
----------------------------------------------------------------
Javier Martinez Canillas (2):
mailbox: mailbox-test: Fix module autoload
mailbox: sti: Fix module autoload for OF registration
Rob Rice (9):
mailbox: bcm-pdc: Use octal permissions rather than symbolic
mailbox: bcm-pdc: Convert from interrupts to poll for tx done
mailbox: bcm-pdc: streamline rx code
mailbox: bcm-pdc: Try to improve branch prediction
mailbox: bcm-pdc: Convert from threaded IRQ to tasklet
mailbox: bcm-pdc: Don't use iowrite32 to write DMA descriptors
mailbox: bcm-pdc: Performance improvements
mailbox: bcm-pdc: Simplify interrupt handler logic
mailbox: bcm-pdc: Remove unnecessary void* casts
Steve Lin (2):
mailbox: bcm-pdc: Changes so mbox client can be removed / re-inserted
mailbox: bcm-pdc: PDC driver leaves debugfs files after removal
Sudeep Holla (2):
mailbox: mailbox-test: add support for fasync/poll
mailbox: mailbox-test: allow reserved areas in SRAM
drivers/mailbox/bcm-pdc-mailbox.c | 548 ++++++++++++++++++++++----------------
drivers/mailbox/mailbox-sti.c | 1 +
drivers/mailbox/mailbox-test.c | 92 ++++++-
3 files changed, 407 insertions(+), 234 deletions(-)
^ permalink raw reply
* [linux-sunxi][PATCH 2/3] ARM: dts: sun6i: Add the SPDIF block to the A31
From: Maxime Ripard @ 2016-12-20 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220104038.22532-3-codekipper@gmail.com>
Hi,
On Tue, Dec 20, 2016 at 11:40:37AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper@gmail.com>
>
> Add the SPDIF transceiver controller block to the A31 dtsi.
>
> Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> ---
> arch/arm/boot/dts/sun6i-a31.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index 7370ba6c9993..559c53efa7e6 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -613,6 +613,20 @@
> reg = <0x01c20ca0 0x20>;
> };
>
> + spdif: spdif at 01c21000 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun6i-a31-spdif";
> + reg = <0x01c21000 0x400>;
> + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_APB1_SPDIF>, <&ccu CLK_SPDIF>;
> + resets = <&ccu RST_APB1_SPDIF>;
> + clock-names = "apb", "spdif";
> + dmas = <&dma 2>, <&dma 2>;
> + dma-names = "rx", "tx";
> + spdif-out = "disabled";
That property isn't documented anywhere, and doesn't seem to be used
in your driver either.
On a separate topic, is the channel inversion bug also found on the
A31?
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/20161220/b0c1450a/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-20 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67wU+Hw-6oa9FxzB33sZY8Up-59HZ_mneFBdcRhXbU1pA@mail.gmail.com>
On Mon, Dec 19, 2016 at 10:24:44PM +0800, Chen-Yu Tsai wrote:
> On Mon, Dec 19, 2016 at 10:08 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> >
> >
> > 19.12.2016, 18:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> >> On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
> >>> >> > > &r_pio {
> >>> >> > > wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 {
> >>> >> > > - pins = "PL6", "PL7", "PL11";
> >>> >> > > + pins = "PL6", "PL7", "PL8", "PL11";
> >>> >> > > function = "gpio_in";
> >>> >> > > bias-pull-up;
> >>> >> > > };
> >>> >> >
> >>> >> > There's several things wrong here. The first one is that you rely
> >>> >> > solely on the pinctrl state to maintain a reset line. This is very
> >>> >> > fragile (especially since the GPIO pinctrl state are likely to go away
> >>> >> > at some point), but it also means that if your driver wants to recover
> >>> >> > from that situation at some point, it won't work.
> >>> >> >
> >>> >> > The other one is that the bluetooth and wifi chips are two devices in
> >>> >> > linux, and you assign that pin to the wrong device (wifi).
> >>> >> >
> >>> >> > rfkill-gpio is made just for that, so please use it.
> >>> >>
> >>> >> The GPIO is not for the radio, but for the full Bluetooth part.
> >>> >
> >>> > I know.
> >>> >
> >>> >> If it's set to 0, then the bluetooth part will reset, and the
> >>> >> hciattach will fail.
> >>> >
> >>> > Both rfkill-gpio and rfkill-regulator will shutdown when called
> >>> > (either by poking the reset pin or shutting down the regulator), so
> >>> > that definitely seems like an expected behavior to put the device in
> >>> > reset.
> >>> >
> >>> >> The BSP uses this as a rfkill, and the result is that the bluetooth
> >>> >> on/off switch do not work properly.
> >>> >
> >>> > Then rfkill needs fixing, but working around it by hoping that the
> >>> > core will probe an entirely different device, and enforcing a default
> >>> > that the rest of the kernel might or might not change is both fragile
> >>> > and wrong.
> >>>
> >>> I think a rfkill-gpio here works just like the BSP rfkill...
> >>>
> >>> The real problem is that the Realtek UART bluetooth driver is a userspace
> >>> program (a modified hciattach), which is not capable of the GPIO reset...
> >>
> >> Can't you run rfkill before attaching? What is the problem exactly?
> >> It's not in reset for long enough?
> >>
> >> This seems more and more like an issue in the BT stack you're
> >> using. We might consider workarounds in the kernel, but they have to
> >> be correct.
> >
> > One more rfkill interface will be generated for hci0 after hciattach, which can
> > be safely toggled block and unblock.
> >
> > However, if the GPIO is toggled down, the hciattach program will die.
> >
> > The bluetooth stack I used is fd.o's BlueZ.
>
> I think the bigger issue is that the tty/serial subsystem does not have
> power sequencing support. Here we're trying to use rfkill to do that,
> but that doesn't seem to be what it was intended for. It might work with
> standalone USB bluetooth controllers that don't need any special setup,
> since the device will just appear and get registered. But it might not
> work so well with UART based adapters that need userspace fiddling with
> firmware and hciattach.
Then you can also have a look at the generic power sequence patches
that are floating around.
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/20161220/4ffe5077/attachment.sig>
^ 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