[linux-sunxi] Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

于 2018年2月3日 GMT+08:00 上午6:13:01, Maxime Ripard  写到:
>On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote:
>> The V3s is just a differently packaged version of the V3 chip, which
>has
>> a MAC with the same capability with H3. The V3s just doesn't wire out
>> the external MII/RMII/RGMII bus. (V3 wired out it).
>> 
>> Drop the compatible string of V3s in the dwmac-sun8i driver, and add
>a
>> V3 compatible string, which has all capabilities.
>> 
>> Signed-off-by: Icenowy Zheng 
>
>This breaks the DT ABI, so NAK.

I have asked this at IRC.

The V3s compatible string is never used in any mainline
kernel, even not in any RC version.

>
>Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

于 2018年2月3日 GMT+08:00 下午2:00:33, Julian Calaby  写到:
>Hi Icenowy,
>
>On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng  wrote:
>> The V3s is just a differently packaged version of the V3 chip, which
>has
>> a MAC with the same capability with H3. The V3s just doesn't wire out
>> the external MII/RMII/RGMII bus. (V3 wired out it).
>>
>> Drop the compatible string of V3s in the dwmac-sun8i driver, and add
>a
>> V3 compatible string, which has all capabilities.
>
>Aren't compatible strings technically API, so don't we need to support
>those that are out in the wild "forever"?
>
>Therefore shouldn't we leave the v3s variant around for compatibility
>with existing device trees?

You can run grep at arch/arm/boot/dts, this compatible
string is not used at all.

>
>Thanks,

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH v3] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board

[Julian Calaby]

Hi all,

On Sun, Dec 24, 2017 at 4:40 PM, Icenowy Zheng  wrote:
> Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a form
> factor and GPIO holes similar to Raspberry Pi Zero.
>
> It features:
> - Allwinner H2+ SoC
> - Single-chip (16-bit) 512MiB DDR3 DRAM
> - Ampak AP6212 Wi-Fi/Bluetooth module
> - MicroSD slot
> - Two MicroUSB Type-B ports (one can only be used to power the board and
>   the other features OTG functionality)
> - Two keys, a reset and a GPIO-connected key.
> - HDMI Type-C (miniHDMI) connector connected to the HDMI part of H2+.
> - CSI connector to connect the camera sensor provided by Sinovoip.
>
> Signed-off-by: Icenowy Zheng 

[Trimmed lots of non-sunxi-specific mailing lists]

Did support for this board ever get merged?

(I have two of them now, so if it didn't, I'll try to shepherd this
and it's corresponding u-boot patch upstream.)

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Julian Calaby]

Hi Icenowy,

On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng  wrote:
> The V3s is just a differently packaged version of the V3 chip, which has
> a MAC with the same capability with H3. The V3s just doesn't wire out
> the external MII/RMII/RGMII bus. (V3 wired out it).
>
> Drop the compatible string of V3s in the dwmac-sun8i driver, and add a
> V3 compatible string, which has all capabilities.

Aren't compatible strings technically API, so don't we need to support
those that are out in the wild "forever"?

Therefore shouldn't we leave the v3s variant around for compatibility
with existing device trees?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 3/3] ARM: sun8i: v3s: enable Ethernet port on the Lichee Pi Zero Dock

[Icenowy Zheng]

The Lichee Pi Zero Dock has an Ethernet port connected to the internal
PHY of the V3s SoC.

Enable it in the device tree.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts 
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
index d1311098ea45..9b3465cc0dcd 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
@@ -49,12 +49,20 @@
compatible = "licheepi,licheepi-zero-dock", "licheepi,licheepi-zero",
 "allwinner,sun8i-v3s";
 
+   aliases {
+   ethernet0 = 
+   };
+
leds {
/* The LEDs use PG0~2 pins, which conflict with MMC1 */
status = "disbaled";
};
 };
 
+ {
+   status = "okay";
+};
+
  {
broken-cd;
bus-width = <4>;
-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 2/3] ARM: sun8i: v3s: add V3s EMAC device tree node

[Icenowy Zheng]

The V3/V3s EMAC is just similar to the one in H3 SoC, but as the package
of V3s is pin-limited, the external MII/MDIO bus is not wired out.

Add V3s EMAC device tree node. As V3s is only capable of using the
internal PHY, it's hardcoded in the V3s DTSI file.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 55 
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 443b083c6adc..4d49a8b22a1c 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -141,6 +141,12 @@
};
};
 
+   syscon: syscon@1c0 {
+   compatible = "allwinner,sun8i-v3-system-controller",
+   "syscon";
+   reg = <0x01c0 0x1000>;
+   };
+
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun8i-v3s-tcon";
reg = <0x01c0c000 0x1000>;
@@ -402,6 +408,55 @@
#size-cells = <0>;
};
 
+   emac: ethernet@1c3 {
+   compatible = "allwinner,sun8i-v3-emac";
+   syscon = <>;
+   reg = <0x01c3 0x1>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   resets = < RST_BUS_EMAC>;
+   reset-names = "stmmaceth";
+   clocks = < CLK_BUS_EMAC>;
+   clock-names = "stmmaceth";
+   phy-handle = <_mii_phy>;
+   phy-mode = "mii";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   mdio: mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "snps,dwmac-mdio";
+   };
+
+   mdio-mux {
+   compatible = "allwinner,sun8i-v3-mdio-mux",
+"allwinner,sun8i-h3-mdio-mux";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio-parent-bus = <>;
+
+   internal_mdio: mdio@1 {
+   compatible = 
"allwinner,sun8i-v3-mdio-internal",
+
"allwinner,sun8i-h3-mdio-internal";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   int_mii_phy: ethernet-phy@1 {
+   compatible = 
"ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   clocks = < CLK_BUS_EPHY>;
+   resets = < RST_BUS_EPHY>;
+   };
+   };
+
+   /* V3s has no external MDIO bus, but V3 has it 
*/
+   };
+   };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 0/3] Allwinner V3s EMAC support

[Icenowy Zheng]

The Allwinner V3/V3s SoCs have EMAC similar to the one in H3, but on V3s
the external MII is not exported due to packaging. (V3s is eLQFP128;
the BGA-packaged V3 exported the external MII bus.)

Add support for the EMAC on V3s. The external bus is not added yet, and
will be added when adding support for V3.

Icenowy Zheng (3):
  net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one
  ARM: sun8i: v3s: add V3s EMAC device tree node
  ARM: sun8i: v3s: enable Ethernet port on the Lichee Pi Zero Dock

 .../devicetree/bindings/net/dwmac-sun8i.txt| 10 ++--
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts |  8 
 arch/arm/boot/dts/sun8i-v3s.dtsi   | 55 ++
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  | 10 ++--
 4 files changed, 74 insertions(+), 9 deletions(-)

-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

[Icenowy Zheng]

The V3s is just a differently packaged version of the V3 chip, which has
a MAC with the same capability with H3. The V3s just doesn't wire out
the external MII/RMII/RGMII bus. (V3 wired out it).

Drop the compatible string of V3s in the dwmac-sun8i driver, and add a
V3 compatible string, which has all capabilities.

Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/net/dwmac-sun8i.txt | 10 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 10 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt 
b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
index 3d6d5fa0c4d5..158124e8ee71 100644
--- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
+++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
@@ -7,7 +7,7 @@ Required properties:
 - compatible: must be one of the following string:
"allwinner,sun8i-a83t-emac"
"allwinner,sun8i-h3-emac"
-   "allwinner,sun8i-v3s-emac"
+   "allwinner,sun8i-v3-emac"
"allwinner,sun50i-a64-emac"
 - reg: address and length of the register for the device.
 - interrupts: interrupt for the device
@@ -23,7 +23,7 @@ Required properties:
 - syscon: A phandle to the syscon of the SoC with one of the following
  compatible string:
   - allwinner,sun8i-h3-system-controller
-  - allwinner,sun8i-v3s-system-controller
+  - allwinner,sun8i-v3-system-controller
   - allwinner,sun50i-a64-system-controller
   - allwinner,sun8i-a83t-system-controller
 
@@ -35,7 +35,7 @@ external PHY.
 
 Optional properties for the following compatibles:
   - "allwinner,sun8i-h3-emac",
-  - "allwinner,sun8i-v3s-emac":
+  - "allwinner,sun8i-v3-emac":
 - allwinner,leds-active-low: EPHY LEDs are active low
 
 Required child node of emac:
@@ -51,7 +51,7 @@ of the mdio node. See phy.txt for the generic PHY bindings.
 The following compatibles require that the emac node have a mdio-mux child
 node called "mdio-mux":
   - "allwinner,sun8i-h3-emac"
-  - "allwinner,sun8i-v3s-emac":
+  - "allwinner,sun8i-v3-emac":
 Required properties for the mdio-mux node:
   - compatible = "allwinner,sun8i-h3-mdio-mux"
   - mdio-parent-bus: a phandle to EMAC mdio
@@ -64,7 +64,7 @@ Required properties for the mdio-mux children node:
 The following compatibles require a PHY node representing the integrated
 PHY, under the integrated MDIO bus node if an mdio-mux node is used:
   - "allwinner,sun8i-h3-emac",
-  - "allwinner,sun8i-v3s-emac":
+  - "allwinner,sun8i-v3-emac":
 
 Additional information regarding generic multiplexer properties can be found
 at Documentation/devicetree/bindings/net/mdio-mux.txt
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3fa65b1ca8e..fd0519cf27b9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -84,10 +84,12 @@ static const struct emac_variant emac_variant_h3 = {
.support_rgmii = true
 };
 
-static const struct emac_variant emac_variant_v3s = {
+static const struct emac_variant emac_variant_v3 = {
.default_syscon_value = 0x38000,
.soc_has_internal_phy = true,
-   .support_mii = true
+   .support_mii = true,
+   .support_rmii = true,
+   .support_rgmii = true
 };
 
 static const struct emac_variant emac_variant_a83t = {
@@ -1074,8 +1076,8 @@ return ret;
 static const struct of_device_id sun8i_dwmac_match[] = {
{ .compatible = "allwinner,sun8i-h3-emac",
.data = _variant_h3 },
-   { .compatible = "allwinner,sun8i-v3s-emac",
-   .data = _variant_v3s },
+   { .compatible = "allwinner,sun8i-v3-emac",
+   .data = _variant_v3 },
{ .compatible = "allwinner,sun8i-a83t-emac",
.data = _variant_a83t },
{ .compatible = "allwinner,sun50i-a64-emac",
-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 07/16] iio: adc: sun4i-gpadc-iio: rework: support nvmem calibration data

[Philipp Rossak]

/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
struct thermal_zone_device  *tzd;
@@ -561,6 +569,9 @@ static int sun4i_gpadc_probe_dt(struct platform_device 
*pdev,
struct resource *mem;
void __iomem *base;
int ret;
+   struct nvmem_cell *cell;
+   ssize_t cell_size;
+   u64 *cell_data;
info->data = of_device_get_match_data(>dev);
if (!info->data)
@@ -575,6 +586,39 @@ static int sun4i_gpadc_probe_dt(struct platform_device 
*pdev,
if (IS_ERR(base))
return PTR_ERR(base);
+   info->has_calibration_data[0] = false;
+   info->has_calibration_data[1] = false;
+
+   if (!info->data->supports_nvmem)
+   goto no_nvmem;
+
+   cell = nvmem_cell_get(>dev, "calibration");
+   if (IS_ERR(cell)) {
+   if (PTR_ERR(cell) == -EPROBE_DEFER)
+   return PTR_ERR(cell);
+   goto no_nvmem;


goto considered evil ? :)


this was a suggestion from Jonatan in version one, to make the code better
readable.


Isn't

if (info->data->supports_nvmem && IS_ERR(cell = nvmem_cell_get()))

pretty much the same thing?

Maxime


I would say :

if (info->data->supports_nvmem && !IS_ERR(cell = nvmem_cell_get())) is

the same.
This would require an else if statement like this:

else if (info->data->supports_nvmem && PTR_ERR(cell) == -EPROBE_DEFER)
return PTR_ERR(cell);

to avoid errors if the thermal sensor is probed before the sid driver.

Philipp

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 09/16] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

[Philipp Rossak]

On 31.01.2018 20:23, Quentin Schulz wrote:

Hi Philipp,

On Mon, Jan 29, 2018 at 12:29:12AM +0100, Philipp Rossak wrote:

This patch adds support for the H3 ths sensor.

The H3 supports interrupts. The interrupt is configured to update the
the sensor values every second. The calibration data is writen at the
begin of the init process.

Signed-off-by: Philipp Rossak 
---
  drivers/iio/adc/sun4i-gpadc-iio.c | 86 +++
  include/linux/mfd/sun4i-gpadc.h   | 22 ++
  2 files changed, 108 insertions(+)

diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c 
b/drivers/iio/adc/sun4i-gpadc-iio.c
index b7b5451226b0..8196203d65fe 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -61,6 +61,9 @@ struct sun4i_gpadc_iio;
  static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
  static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
  
+static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info);

+static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info);
+


We try to avoid using the generic sunxi prefix.


  struct gpadc_data {
int temp_offset;
int temp_scale;
@@ -71,6 +74,10 @@ struct gpadc_data {
unsigned inttemp_data[MAX_SENSOR_COUNT];
int (*sample_start)(struct sun4i_gpadc_iio *info);
int (*sample_end)(struct sun4i_gpadc_iio *info);
+   u32 ctrl0_map;
+   u32 ctrl2_map;
+   u32 sensor_en_map;
+   u32 filter_map;
u32 irq_clear_map;
u32 irq_control_map;
boolhas_bus_clk;
@@ -138,6 +145,31 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
.support_irq = false,
  };
  
+static const struct gpadc_data sun8i_h3_ths_data = {

+   .temp_offset = -1791,
+   .temp_scale = -121,
+   .temp_data = {SUN8I_H3_THS_TDATA0, 0, 0, 0},
+   .sample_start = sunxi_ths_sample_start,
+   .sample_end = sunxi_ths_sample_end,
+   .has_bus_clk = true,
+   .has_bus_rst = true,
+   .has_mod_clk = true,
+   .sensor_count = 1,
+   .supports_nvmem = true,
+   .support_irq = true,
+   .ctrl0_map = SUN4I_GPADC_CTRL0_T_ACQ(0xff),
+   .ctrl2_map = SUN8I_H3_THS_ACQ1(0x3f),
+   .sensor_en_map = SUN8I_H3_THS_TEMP_SENSE_EN0,
+   .filter_map = SUN4I_GPADC_CTRL3_FILTER_EN |
+   SUN4I_GPADC_CTRL3_FILTER_TYPE(0x2),
+   .irq_clear_map = SUN8I_H3_THS_INTS_ALARM_INT_0 |
+   SUN8I_H3_THS_INTS_SHUT_INT_0   |
+   SUN8I_H3_THS_INTS_TDATA_IRQ_0  |
+   SUN8I_H3_THS_INTS_ALARM_OFF_0,
+   .irq_control_map = SUN8I_H3_THS_INTC_TDATA_IRQ_EN0 |
+   SUN8I_H3_THS_TEMP_PERIOD(0x7),


 From what I've understood, ACQ regs are basically clock dividers. We
should make a better job at explaining it :)



I agree, I will add this in the next version in the commit message.


+};
+
  struct sun4i_gpadc_iio {
struct iio_dev  *indio_dev;
struct completion   completion;
@@ -462,6 +494,16 @@ static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio 
*info)
return 0;
  }
  
+static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info)

+{
+   /* Disable ths interrupt */
+   regmap_write(info->regmap, SUN8I_H3_THS_INTC, 0x0);
+   /* Disable temperature sensor */
+   regmap_write(info->regmap, SUN8I_H3_THS_CTRL2, 0x0);
+
+   return 0;
+}
+
  static int sun4i_gpadc_runtime_suspend(struct device *dev)
  {
struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
@@ -473,6 +515,17 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev)
return info->data->sample_end(info);
  }
  
+static void sunxi_calibrate(struct sun4i_gpadc_iio *info)

+{
+   if (info->has_calibration_data[0])
+   regmap_write(info->regmap, SUNXI_THS_CDATA_0_1,
+   info->calibration_data[0]);
+
+   if (info->has_calibration_data[1])
+   regmap_write(info->regmap, SUNXI_THS_CDATA_2_3,
+   info->calibration_data[1]);
+}
+
  static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info)
  {
/* clkin = 6MHz */
@@ -492,6 +545,35 @@ static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio 
*info)
return 0;
  }
  
+static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info)

+{
+   u32 value;
+   sunxi_calibrate(info);
+
+   if (info->data->ctrl0_map)
+   regmap_write(info->regmap, SUN8I_H3_THS_CTRL0,
+   info->data->ctrl0_map);
+
+   regmap_write(info->regmap, SUN8I_H3_THS_CTRL2,
+   info->data->ctrl2_map);
+
+   regmap_write(info->regmap, SUN8I_H3_THS_STAT,
+   info->data->irq_clear_map);
+
+   regmap_write(info->regmap, SUN8I_H3_THS_FILTER,
+ 

[linux-sunxi] Re: [PATCH v2 08/16] iio: adc: sun4i-gpadc-iio: rework: add interrupt support

[Philipp Rossak]

On 31.01.2018 20:07, Quentin Schulz wrote:

Hi Philipp,

On Mon, Jan 29, 2018 at 12:29:11AM +0100, Philipp Rossak wrote:

This patch rewors the driver to support interrupts for the thermal part
of the sensor.

This is only available for the newer sensor (currently H3 and A83T).
The interrupt will be trigerd on data available and triggers the update
for the thermal sensors. All newer sensors have different amount of
sensors and different interrupts for each device the reset of the
interrupts need to be done different

For the newer sensors is the autosuspend disabled.

Signed-off-by: Philipp Rossak 
Acked-by: Jonathan  Cameron 
---
  drivers/iio/adc/sun4i-gpadc-iio.c | 60 +++
  include/linux/mfd/sun4i-gpadc.h   |  2 ++
  2 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c 
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 74eeb5cd5218..b7b5451226b0 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -71,11 +71,14 @@ struct gpadc_data {
unsigned inttemp_data[MAX_SENSOR_COUNT];
int (*sample_start)(struct sun4i_gpadc_iio *info);
int (*sample_end)(struct sun4i_gpadc_iio *info);
+   u32 irq_clear_map;
+   u32 irq_control_map;


I would say to use a regmap_irq_chip for controlling IRQs.


Sounds good for me! I will rework that in the next version.

boolhas_bus_clk;
boolhas_bus_rst;
boolhas_mod_clk;
int sensor_count;
boolsupports_nvmem;
+   boolsupport_irq;
  };
  
  static const struct gpadc_data sun4i_gpadc_data = {

@@ -90,6 +93,7 @@ static const struct gpadc_data sun4i_gpadc_data = {
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
.supports_nvmem = false,
+   .support_irq = false,


False is the default, no need to set support_irq.

[...]


  struct sun4i_gpadc_iio {
@@ -332,6 +339,11 @@ static int sun4i_gpadc_temp_read(struct iio_dev 
*indio_dev, int *val,
return 0;
}
  
+	if (info->data->support_irq) {

+   regmap_read(info->regmap, info->data->temp_data[sensor], val);
+   return 0;
+   }
+


Maybe you could define a new thermal_zone_of_device_ops for these new
thermal sensors? That way, you don't even need the boolean support_irq.


Sounds good for me! I will rework that in the next version.


return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
  }
  
@@ -429,6 +441,17 @@ static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int irq, void *dev_id)

return IRQ_HANDLED;
  }
  
+static irqreturn_t sunxi_irq_thread(int irq, void *data)


I think we're trying to avoid sunxi mentions but rather using the name
of the first IP (in term of product release, not support) using this
function.


+{
+   struct sun4i_gpadc_iio *info = data;
+
+   regmap_write(info->regmap, SUN8I_H3_THS_STAT, 
info->data->irq_clear_map);
+


Will be handled by regmap_irq_chip.
[...]

-   info->no_irq = true;
+   if (info->data->support_irq) {
+   /* only the new versions of ths support right now irqs */
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   dev_err(>dev, "failed to get IRQ: %d\n", irq);
+   return irq;
+   }
+
+   ret = devm_request_threaded_irq(>dev, irq, NULL,
+   sunxi_irq_thread, IRQF_ONESHOT,
+   dev_name(>dev), info);
+   if (ret)
+   return ret;
+
+   } else
+   info->no_irq = true;
+


That's a bit funny to have two booleans named no_irq and support_irq :)

I know this looks very funny. I thought this would be better to keep, to 
_not_ break anything. Since I will rework the whole driver and integrate 
the mfd part I hope I can remove both.



indio_dev->num_channels = ARRAY_SIZE(sun8i_a33_gpadc_channels);
indio_dev->channels = sun8i_a33_gpadc_channels;
  
@@ -789,11 +829,13 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)

if (ret)
return ret;
  
-	pm_runtime_set_autosuspend_delay(>dev,

-SUN4I_GPADC_AUTOSUSPEND_DELAY);
-   pm_runtime_use_autosuspend(>dev);
-   pm_runtime_set_suspended(>dev);
-   pm_runtime_enable(>dev);
+   if (!info->data->support_irq) {
+   pm_runtime_set_autosuspend_delay(>dev,
+SUN4I_GPADC_AUTOSUSPEND_DELAY);
+   pm_runtime_use_autosuspend(>dev);
+   pm_runtime_set_suspended(>dev);
+   pm_runtime_enable(>dev);
+   }


Why would you not want your IP to do runtime PM?


I will enable this again, 

[linux-sunxi] Re: [PATCH v2 06/16] iio: adc: sun4i-gpadc-iio: rework: support multiple sensors

[Philipp Rossak]

On 31.01.2018 19:42, Quentin Schulz wrote:

Hi Philipp,

On Mon, Jan 29, 2018 at 12:29:09AM +0100, Philipp Rossak wrote:

For adding newer sensor some basic rework of the code is necessary.

This patch reworks the driver to be able to handle more than one
thermal sensor. Newer SoC like the A80 have 4 thermal sensors.
Because of this the maximal sensor count value was set to 4.

The sensor_id value is set during sensor registration and is for each
registered sensor indiviual. This makes it able to differntiate the
sensors when the value is read from the register.

In function sun4i_gpadc_read_raw(), the sensor number of the ths sensor
was directly set to 0 (sun4i_gpadc_temp_read(x,x,0)). This selects
in the temp_read function automatically sensor 0. A check for the
sensor_id is here not required since the old sensors only have one
thermal sensor. In addition to that is the sun4i_gpadc_read_raw()
function only used by the "older" sensors (before A33) where the
thermal sensor was a cobination of an adc and a thermal sensor.

Signed-off-by: Philipp Rossak 
---
  drivers/iio/adc/sun4i-gpadc-iio.c | 36 +++-
  include/linux/mfd/sun4i-gpadc.h   |  3 +++
  2 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c 
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 51ec0104d678..ac9ad2f8232f 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -67,12 +67,13 @@ struct gpadc_data {
unsigned inttp_adc_select;
unsigned int(*adc_chan_select)(unsigned int chan);
unsigned intadc_chan_mask;
-   unsigned inttemp_data;
+   unsigned inttemp_data[MAX_SENSOR_COUNT];
int (*sample_start)(struct sun4i_gpadc_iio *info);
int (*sample_end)(struct sun4i_gpadc_iio *info);
boolhas_bus_clk;
boolhas_bus_rst;
boolhas_mod_clk;
+   int sensor_count;
  };
  


I've noticed that for H3, A83T, A64 (at least), if DATA reg of sensor 0
is e.g. 0x80, DATA reg of sensor N is at 0x80 + 0x04 * N.

Is that verified for other SoCs? Does anyone have some input on this?

We could then just use temp_data as the DATA reg "base" and increment by
0x4 depending on the sensor id instead of using a fixed-size array.



This sounds like a good idea! I will add this to the next version.

I can verify this with a table, I created during development. I will 
upload it during the weekend here: [1]




  static const struct gpadc_data sun4i_gpadc_data = {
@@ -82,9 +83,10 @@ static const struct gpadc_data sun4i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = _gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
-   .temp_data = SUN4I_GPADC_TEMP_DATA,
+   .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
+   .sensor_count = 1,


If the solution above is not desirable/possible, could we use something
like:

unsigned int sun4i_temp_data[] = {SUN4I_GPADC_TEMP_DATA,};

static const struct gpadc_data sun4i_gpadc_data = {
.temp_data = _temp_data,
.sensor_count = ARRAY_SIZE(sun4i_temp_data),
};

That avoids 1) inconsistencies between the array size and the array
itself, 2) does not require to pad the array with zeroes.

[...]


@@ -745,9 +752,12 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
pm_runtime_enable(>dev);
  
  	if (IS_ENABLED(CONFIG_THERMAL_OF)) {

-   info->tzd = thermal_zone_of_sensor_register(info->sensor_device,
-   0, info,
-   _ts_tz_ops);
+   for (i = 0; i < info->data->sensor_count; i++) {
+   info->sensor_id = i;
+   info->tzd = thermal_zone_of_sensor_register(
+   info->sensor_device,
+   i, info, _ts_tz_ops);
+   }


As Maxime said, this does not work.

One way would be to have a new structure being:
struct sun4i_sensor_info {
struct sun4i_gpadc_iio  *info;
unsigned intsensor_id;
};

Or since we only use the iio_dev within the sun4i_gpadc_iio in the
.get_temp function, we may replace info by struct iio_dev *indio_dev
above.

Quentin

I will have a closer look on this next week, when I start to work on the 
next version..


Thanks,
Philipp

[1]: http://linux-sunxi.org/Thermal_Sensor

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: add audio codec support into V3s DTSI

[Icenowy Zheng]

Allwinner V3s SoC features an internal audio codec like the one in H3,
and a analog codec like the one in H3/A23 (but much simpler).

Add them in the DTSI file.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 20edebd983f0..f6c534efaef9 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -354,6 +354,25 @@
status = "disabled";
};
 
+   codec: codec@01c22c00 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun8i-v3s-codec";
+   reg = <0x01c22c00 0x400>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+   clock-names = "apb", "codec";
+   resets = < RST_BUS_CODEC>;
+   dmas = < 15>, < 15>;
+   dma-names = "rx", "tx";
+   allwinner,codec-analog-controls = <_analog>;
+   status = "disabled";
+   };
+
+   codec_analog: codec-analog@01c23000 {
+   compatible = "allwinner,sun8i-v3s-codec-analog";
+   reg = <0x01c23000 0x4>;
+   };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 3/3] ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board

[Icenowy Zheng]

The Lichee Pi Zero Dock board has an audio jack and an onboard MIC.

Enable them.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts 
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
index d1311098ea45..80f477738668 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
@@ -55,6 +55,15 @@
};
 };
 
+ {
+   allwinner,audio-routing =
+   "Headphone", "HP",
+   "Headphone", "HPCOM",
+   "MIC1", "Mic",
+   "Mic",  "HBIAS";
+   status = "okay";
+};
+
  {
broken-cd;
bus-width = <4>;
-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 1/3] ARM: dts: sun8i: add DMA engine in V3s DTSI

[Icenowy Zheng]

Allwinner V3s SoC features a DMA engine.

Add it in the DTSI file.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 443b083c6adc..20edebd983f0 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -178,6 +178,15 @@
};
 
 
+   dma: dma-controller@01c02000 {
+   compatible = "allwinner,sun8i-v3s-dma";
+   reg = <0x01c02000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_DMA>;
+   resets = < RST_BUS_DMA>;
+   #dma-cells = <1>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 0/3] Allwinner V3s audio codec device tree changes

[Icenowy Zheng]

Here's the Allwinner V3s audio codec device tree changes, which used to
be blocked by the DMA engine code.

The first patch adds the DMA engine device tree node, and the second
adds the codec nodes (digital and analog).

The thrid patch is for Lichee Pi Zero with Dock board to enable the
audio jack and on-board mic.

Icenowy Zheng (3):
  ARM: dts: sun8i: add DMA engine in V3s DTSI
  ARM: dts: sun8i: add audio codec support into V3s DTSI
  ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board

 arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts |  9 +++
 arch/arm/boot/dts/sun8i-v3s.dtsi   | 28 ++
 2 files changed, 37 insertions(+)

-- 
2.15.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.