Re: [linux-sunxi] Re: [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Andre Przywara]

Hi,

On 02/03/18 16:32, Vincent Legoll wrote:
> Hi,
> 
> On Fri, Mar 2, 2018 at 5:24 PM, Andre Przywara  wrote:
>> Regarding the whole forward/backward compatibility:
>> I clearly see the difficulty in coming up with a "perfect" DT from day
>> one, especially for badly documented SoCs, where mainlining is driven by
>> hobbyists. So I was wondering if we introduce a grace period, where we
>> declare the DT "unstable" or "subject to incompatible changes" for some
>> releases (not too many). In hindsight we might declare 4.12 the stable
>> DT base for the A64, for instance.
>> This would allow us to start upstreaming early, with a small feature set
>> only (just serial + clocks + pinctrl, as for the H6). Additional
>> features (PMIC) might then add small incompatibilities (like this one
>> here), until we are reasonably confident about the DT.
>> Does that sound useful?
> 
> Kind of "staging" for DT ?

Yeah, somewhat, though I would like to see this moved out of the Linux
context ;-) Actually this would also simplify collaboration with other
stakeholders (U-Boot, *BSD, Your-toy-OS), as they can participate in the
discussion without being bound to some particular release cycle or
special upstreaming process.
And ideally the DT would not be in the Linux tree in the first place, to
not give people the idea of it being a "Linux config file".

Cheers,
Andre.

-- 
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] Re: [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Vincent Legoll]

Hi,

On Fri, Mar 2, 2018 at 5:24 PM, Andre Przywara  wrote:
> Regarding the whole forward/backward compatibility:
> I clearly see the difficulty in coming up with a "perfect" DT from day
> one, especially for badly documented SoCs, where mainlining is driven by
> hobbyists. So I was wondering if we introduce a grace period, where we
> declare the DT "unstable" or "subject to incompatible changes" for some
> releases (not too many). In hindsight we might declare 4.12 the stable
> DT base for the A64, for instance.
> This would allow us to start upstreaming early, with a small feature set
> only (just serial + clocks + pinctrl, as for the H6). Additional
> features (PMIC) might then add small incompatibilities (like this one
> here), until we are reasonably confident about the DT.
> Does that sound useful?

Kind of "staging" for DT ?

-- 
Vincent Legoll

-- 
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 v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0

[Andre Przywara]

Hi,

On 02/03/18 15:58, Maxime Ripard wrote:
> On Fri, Mar 02, 2018 at 12:56:52AM +, Andre Przywara wrote:
>> Linux kernels before 4.12-rc1 don't know about the AXP803 PMIC, so can't
>> enable the MMC driver with the current DT anymore, because that now
>> depends on this regulator.
> 
> Given that only I2C, USB and MMC were supported at the time, is it
> really worth it? There's a lot of incentive to move to a newer kernel
> given the minimal support it had at the time.

Yeah, this is somewhat true, although serial, USB and MMC are somewhat
enough if one uses a USB Ethernet or WiFi adapter. And the kernel choice
might not always a decision of the user (thinking of distributions here).
But I was actually unsure about this as well, and wanted to hear some
opinions.

One thing that comes to mind is other OSes. Does anyone know how if for
instance FreeBSD supports the AXP and its Linux bindings? The whole goal
of this series is to allow booting OSes with U-Boot's DT copy
($fdtcontroladdr), so if this patch would make their life easier, it
might be worth it.

Regarding the whole forward/backward compatibility:
I clearly see the difficulty in coming up with a "perfect" DT from day
one, especially for badly documented SoCs, where mainlining is driven by
hobbyists. So I was wondering if we introduce a grace period, where we
declare the DT "unstable" or "subject to incompatible changes" for some
releases (not too many). In hindsight we might declare 4.12 the stable
DT base for the A64, for instance.
This would allow us to start upstreaming early, with a small feature set
only (just serial + clocks + pinctrl, as for the H6). Additional
features (PMIC) might then add small incompatibilities (like this one
here), until we are reasonably confident about the DT.
Does that sound useful?

So I am not insisting on this patch, but wanted to point out the
problems that those seemingly innocent DT changes create and would be
happy if we can at least try to avoid them in the future.

Cheers,
Andre.

-- 
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 v3 09/20] sunxi: disable direct MMC environment for 64 bit boards

[Andre Przywara]

Hi,

On 02/03/18 15:56, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Mar 02, 2018 at 12:56:48AM +, Andre Przywara wrote:
>> Since the dawn of time for the Allwinner support in mainline U-Boot
>> we store the environment to the SD card and write directly at
>> 544KB from the beginning of the device. This leads to problems when
>> the U-Boot proper image grows beyond 504KB and eventually overlaps.
>> With one release of having the environment preferably in a FAT
>> partition, let's now turn off the MMC variant fallback, so we get back
>> all the space we need to implement features.
>> In case someone desperately needs to turn direct MMC environment back
>> on, let's move that to 896KB (128K below 1MB), so that we won't be
>> easily limited anymore.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  env/Kconfig| 5 +++--
>>  include/configs/sunxi-common.h | 2 +-
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/env/Kconfig b/env/Kconfig
>> index a3c6298273..b404855542 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -152,7 +152,7 @@ config ENV_IS_IN_MMC
>>  bool "Environment in an MMC device"
>>  depends on !CHAIN_OF_TRUST
>>  depends on MMC
>> -default y if ARCH_SUNXI
>> +default y if ARCH_SUNXI && !ARM64
> 
> I'd go even further and remove it for everyone.

Fine, if you say so!

> 
>>  default y if ARCH_EXYNOS4
>>  default y if MX6SX || MX7D
>>  default y if TEGRA30 || TEGRA124
>> @@ -443,7 +443,8 @@ config ENV_OFFSET
>>  hex "Environment Offset"
>>  depends on !ENV_IS_IN_UBI
>>  depends on !ENV_IS_NOWHERE
>> -default 0x88000 if ARCH_SUNXI
>> +default 0x88000 if ARCH_SUNXI && !ARM64
>> +default 0xe if ARCH_SUNXI && ARM64
> 
> However, I'm not sure why that would be needed. I would rather keep
> the old value to have an easy fallback to the old environment, given
> that you disable a few things afterwards.

Yeah, fair enough. Wasn't so sure about it anyway.

Cheers,
Andre.

-- 
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: [RESEND PATCH v5 0/6] IR support for A83T

[Philipp Rossak]

On 13.02.2018 13:29, Philipp Rossak wrote:

This patch series adds support for the sunxi A83T ir module and enhances
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.

This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface
on the a83t and the Bananapi M3.

changes since v4:
* rename cir pin from cir_pins to r_cir_pin
* drop unit-adress from r_cir_pin
* add a83t compatible to the cir node
* move muxing options to dtsi
* rename cir label and reorder it in the bananpim3.dts file

changes since v3:
* collecting all acks & reviewd by
* fixed typos

changes since v2:
* reorder cir pin (alphabetical)
* fix typo in documentation

changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5

changes since rfc:
* The property is now optinal. If the property is not available in
   the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency

Regards,
Philipp

Philipp Rossak (6):
   media: rc: update sunxi-ir driver to get base clock frequency from
 devicetree
   media: dt: bindings: Update binding documentation for sunxi IR
 controller
   arm: dts: sun8i: a83t: Add the cir pin for the A83T
   arm: dts: sun8i: a83t: Add support for the cir interface
   arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
   arm: dts: sun8i: h3-h5: ir register size should be the whole memory
 block

  Documentation/devicetree/bindings/media/sunxi-ir.txt |  3 +++
  arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts |  5 +
  arch/arm/boot/dts/sun8i-a83t.dtsi| 18 ++
  arch/arm/boot/dts/sunxi-h3-h5.dtsi   |  2 +-
  drivers/media/rc/sunxi-cir.c | 19 +++
  5 files changed, 38 insertions(+), 9 deletions(-)



I talked yesterday with Maxime about this patch series. And he told me 
if the first to patches got merged, he will apply the dts patches to the 
sunxi tree.


Sean, can you merge the first two patches through the rc-core?

Thanks,
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] pinctrl: sunxi: always look for apb block

[Andre Przywara]

Hi Maxime,

On 01/03/18 11:48, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Mar 01, 2018 at 11:37:01AM +, Andre Przywara wrote:
>> The Allwinner pinctrl device tree binding suggests that a clock named
>> "apb" would drive the pin controller IP. However (for legacy reasons) we
>> rely on this clock actually being the first clock defined.
>> Since named clocks can be in any order, let's explicitly check for a
>> clock called "apb" first, then revert to using the first (and only!)
>> clock to keep compatibility with older DTs.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  drivers/pinctrl/sunxi/pinctrl-sunxi.c | 17 ++---
>>  1 file changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
>> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> index 4b6cb25bc796..897ba13e6a03 100644
>> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> @@ -1360,10 +1360,21 @@ int sunxi_pinctrl_init_with_variant(struct 
>> platform_device *pdev,
>>  goto gpiochip_error;
>>  }
>>  
>> -clk = devm_clk_get(>dev, NULL);
>> +clk = devm_clk_get(>dev, "apb");
>>  if (IS_ERR(clk)) {
>> -ret = PTR_ERR(clk);
>> -goto gpiochip_error;
>> +/*
>> + * If no "apb" clock can be found, try the first one, which
>> + * must be the only one defined.
>> + */
>> +if (PTR_ERR(clk) == -ENOENT &&
>> +of_count_phandle_with_args(node, "clocks",
>> +   "#clock-cells") == 1)
>> +clk = devm_clk_get(>dev, NULL);
>> +
>> +if (IS_ERR(clk)) {
>> +ret = PTR_ERR(clk);
>> +goto gpiochip_error;
>> +}
> 
> I guess this can be made slightly less convoluted using something like

    that's a slight understatement

> 
> ret = of_count_phandle_with_args(node, "clocks", "#clock-cells");
> clk = devm_clk_get(>dev, ret == 1 ? NULL : "apb");

Pah, that's just embarrassing.
I guess I will need to back your Kickstarter now to buy me out of this.

Will send v2 after testing tonight.

Thanks a lot for having a look!

Cheers,
Andre.

-- 
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 v3 0/7] Initial Allwinner H6 support

[Linus Walleij]

On Fri, Feb 23, 2018 at 1:25 PM, Icenowy Zheng  wrote:

> This patchset adds initial support for the Allwinner H6 SoC.
>
> It's quite different from earlier Allwinner SoCs. For example, the
> memory map is refactored, and the CCU is rearranged. It's also the first
> Allwinner SoC with PCI Express interface, and the second one with USB
> 3.0 (the first one is A80).
>
> This patchset adds the most basical support for it, including the main pin
> controller, the main CCU and the basical device tree.

It seems the pin control part is more or less finished, I will
apply it after v4 if Maxime provides ACKs for it.

Is it fine to merge the pinctrl drivers/* portions in isolation from the
rest?

Yours,
Linus Walleij

-- 
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.