[linux-sunxi] Re: [PATCH v5 0/6] IR support for A83T

[Philipp Rossak]

On 30.01.2018 18:46, 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(-)



Hey,

RC1 is now out, thus I would like to ask you to have a look at this 
patch series again. Some patches still miss an acked-by. It would be 
nice if we could schedule this for v4.17.


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] [PATCH 1/1] ARM: dts: sun8i: h2-plus: remove unnecessary mmc1_pins node

[Joonas Kylmälä]

The mmc1_pins node with bias-pull-up attribute is already defined in
the sunxi-h3-h5.dtsi file. Thus, we can remove it from here.

Signed-off-by: Joonas Kylmälä 
---
 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts 
b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
index f868cf197c8e..0bc031fe4c56 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
@@ -134,10 +134,6 @@
};
 };
 
-_pins {
-   bias-pull-up;
-};
-
  {
status = "okay";
 };
-- 
2.11.0

-- 
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/1] ARM: dts: sun8i: h2-plus: remove unnecessary mmc1_pins node

[Joonas Kylmälä]

Hi Maxime,

I made now the patch removing the unnecessary mmc1_pins node as discussed in
the email thread "ARM: dts: sunxi: h3-h5: rename mmc0_pins_a and mmc1_pins_a".

Joonas

Joonas Kylmälä (1):
  ARM: dts: sun8i: h2-plus: remove unnecessary mmc1_pins node

 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 4 
 1 file changed, 4 deletions(-)

-- 
2.11.0

-- 
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] BUG: A31s Not booting anymore

[Philipp Rossak]

Hey,

When I try to boot my A31s (Bananapi M2) u-boot is showing only Starting 
kernel ... . After enabling the earlyprintk I could capture this log: [1].


After reverting those 5 commits from Chen-Yu I was able to boot again:


clk: sunxi-ng: Support fixed post-dividers on NM style clocks
7d333ef1cc1b8c8951f3a2c41f6406e2295d8be9

clk: sunxi-ng: sun8i: a83t: Add /2 fixed post divider to audio PLL
10e6eb4f2c5b35ae71c9bc0db83d74238719b453

clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL
e952ca3c6b2ffdfbf9618e4bd3e9aad1ff3f5eb4

clk: sunxi-ng: Support fixed post-dividers on MP style clocks
946797aa3f08e2f6f5992f3ec2be44791e9b9260

clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
83fe3be4d1974f5f50c5e2039a1609f4960e8579


I allready tried to fix it with making them save against zero:

if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV && \
cmp->fixed_post_div with)
   rate *= cmp->fixed_post_div;

But that didn't help.

Any ideas?

Regards,
Philipp

[1]: https://pastebin.com/64Fzzqvg

--
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] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

[Mr . Fülöp]

Hi Icenowy,

Thank you for your reply!
I worked much and got this close, so I really want to make this thing work 
:) 
Do you have any suggestions/patches/directions? This "ugly hack" is there 
somewhere? :)

I think the issue resides on the "switching" to the next cpu...

Thank you in advance!

Alex


On Wednesday, February 7, 2018 at 8:04:41 PM UTC+2, Icenowy Zheng wrote:
>
>
>
> 于 2018年2月8日 GMT+08:00 上午2:02:39, "Mr. Fülöp"  > 写到: 
> >Hi Guys, 
> > 
> >I think I reached a dead end... 
> >Can you please tell me why does it hang on "(XEN) Bringing up CPU1"? 
> >I compiled many xen version, but my feeling is that in the u-boot is 
> >sth. that makes Xen hang... 
> > 
> >Any suggestions? 
> > 
> >Thank you in advance! 
> > 
> >= 
> > 
> > Xen 4.11-unstable 
> >(XEN) Xen version 4.11-unstable (@) (arm-linux-gnueabi-gcc (Debian 
> >6.1.1-9) 6.1.1 20160705) debug=y  Fri Feb  2 16:48:36 UTC 2018 
> >(XEN) Latest ChangeSet: Fri Nov 3 16:43:02 2017 + git:4c7e478 
> >(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 
> >0x5 
> >(XEN) 32-bit Execution: 
> >(XEN)   Processor Features: 1131:00011011 
> >(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle 
> >(XEN) Extensions: GenericTimer Security 
> >(XEN)   Debug Features: 02010555 
> >(XEN)   Auxiliary Features:  
> >(XEN)   Memory Model Features: 10101105 4000 0124 02102211 
> >(XEN)  ISA Features: 02101110 13112111 21232041 2131 10011142 
> > 
> >(XEN) Using PSCI-0.1 for SMP bringup 
> >(XEN) SMP: Allowing 8 CPUs 
> >(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz 
> >(XEN) GICv2 initialization: 
> >(XEN) gic_dist_addr=01c81000 
> >(XEN) gic_cpu_addr=01c82000 
> >(XEN) gic_hyp_addr=01c84000 
> >(XEN) gic_vcpu_addr=01c86000 
> >(XEN) gic_maintenance_irq=25 
> >(XEN) GICv2: 224 lines, 8 cpus, secure (IID 0200143b). 
> >(XEN) Using scheduler: SMP Credit Scheduler (credit) 
> >(XEN) Allocated console ring of 64 KiB. 
> >(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5 
> >(XEN) Bringing up CPU1- HERE IT HANGS - 
>
> I think you just met the bug we mentioned in this thread. 
> With this patchset applied a Linux kernel will also hang 
> here without ugly hack. 
>
>

-- 
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: [BUG]: A83T - AC100 gets the wrong number of parents

[Chen-Yu Tsai]

On Sun, Feb 11, 2018 at 10:43 AM, Philipp Rossak  wrote:
> Hey,
>
> When I boot my A83T I get the following bootlog [1].
>
> After some debugging, I found out that the function call:
> clk_hw_get_num_parents() returns 2. After a look in the devicetree I
> found out that this value should be 1, since we only have one parent
> clock [3].

Not really. The first parent is registered within the rtc-ac100 driver,
which also handles the clocks on the RTC side of the chip.

The clock in the device tree is meant to tie the two parts of the chip
together: the codec side provides a high speed clock to the RTC side.

> Setting the variable num_parents to 1 fixes the problem, but this is no
> soultion.

A good fix would be to check the return value of clk_hw_get_parent_by_index()
here: http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/rtc/rtc-ac100.c#L186
and skip it if it's NULL.

The driver is setup this way because the codec side is not implemented,
but the device tree binding is partially defined to include the clock.

ChenYu

> Regards,
> Philipp
>
>
>
> [1]: https://pastebin.com/5c7hxjsS
> [2]: http://lxr.bootlin.com/linux/v4.15/source/drivers/rtc/rtc-ac100.c#
> L180
> [3]: http://lxr.bootlin.com/linux/v4.15/source/arch/arm/boot/dts/sun8i-
> a83t-bananapi-m3.dts#L159
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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 v2 2/6] pinctrl: sunxi: add support for the Allwinner H6 main pin controller

[André Przywara]

Hi,

On 03/02/18 15:49, Icenowy Zheng wrote:
> The Allwinner H6 SoC has two pin controllers, one main controller
> (called CPUX-PORT in user manual) and one controller in CPUs power
> domain (called CPUS-PORT in user manual).

Leaving aside that I don't like this approach of stashing yet another
pile of data in the kernel ...

> This commit introduces support for the main pin controller on H6.

So I went through *every* single pin of port C, D, F, G and H and
compared your entries with the manual. Quite impressively, I couldn't
find any issues. Well done!

> The pin bank A and B are not wired out and hidden from the SoC's
> documents, however it's shown that the "ATE" (an AC200 chip
> co-packaged with the H6 die) is connected to the main SoC die via these
> pin banks. The information about these banks is just copied from the BSP
> pinctrl driver, but re-formatted to fit the mainline pinctrl driver
> format.

See below ...

> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Dropped without_bus_gate description.
> - Switched to SPDX license identifier.
> 
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>  drivers/pinctrl/sunxi/Kconfig  |   4 +
>  drivers/pinctrl/sunxi/Makefile |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c  | 676 
> +
>  4 files changed, 682 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 09789fdfa749..ed5eb547afc8 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -27,6 +27,7 @@ Required properties:
>"allwinner,sun50i-a64-pinctrl"
>"allwinner,sun50i-a64-r-pinctrl"
>"allwinner,sun50i-h5-pinctrl"
> +  "allwinner,sun50i-h6-pinctrl"
>"nextthing,gr8-pinctrl"
>  
>  - reg: Should contain the register physical address and length for the
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index bfce99d86dfc..5de1f63b07bb 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -77,4 +77,8 @@ config PINCTRL_SUN50I_H5
>   def_bool ARM64 && ARCH_SUNXI
>   select PINCTRL_SUNXI
>  
> +config PINCTRL_SUN50I_H6
> + def_bool ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
>  endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 12a752e836ef..3c4aec6611e9 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -18,5 +18,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_H3)  += 
> pinctrl-sun8i-h3.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o
>  obj-$(CONFIG_PINCTRL_SUN8I_V3S)  += pinctrl-sun8i-v3s.o
>  obj-$(CONFIG_PINCTRL_SUN50I_H5)  += pinctrl-sun50i-h5.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H6)  += pinctrl-sun50i-h6.o
>  obj-$(CONFIG_PINCTRL_SUN9I_A80)  += pinctrl-sun9i-a80.o
>  obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> new file mode 100644
> index ..f1f728e2f6d3
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> @@ -0,0 +1,676 @@
> +/*
> + * Allwinner H6 SoC pinctrl driver.
> + *
> + * Copyright (C) 2017 Icenowy Zheng 
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin h6_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),

So why is this? If those pins are hardwired to the ATE's EMAC port, why
do we have GPIOs here? Is that actually possible to configure these as
an input/output, then bitbanging those pins?
And even if that would be possible, what would be the reason for doing
so? Doesn't naming gpio_in and gpio_out here make them appear as
exportable GPIOs in sysfs (and other GPIO interfaces)? I don't think
this is desirable?
>From dumping the MMIO registers in U-Boot I see that those pins reset to
0x7 (disabled), so we need to expose function 0x2 here to wire them
through to the ATE. But I don't believe that having function 0x0 and 0x1
here is useful.

Cheers,
Andre.

> +   SUNXI_FUNCTION(0x2, "emac")), /* ERXD1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "emac")), /* ERXD0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> + 

[linux-sunxi] Re: BUG: A31s Not booting anymore

[Philipp Rossak]

On 12.02.2018 19:21, Philipp Rossak wrote:

Hey,

When I try to boot my A31s (Bananapi M2) u-boot is showing only Starting 
kernel ... . After enabling the earlyprintk I could capture this log: [1].


After reverting those 5 commits from Chen-Yu I was able to boot again:


clk: sunxi-ng: Support fixed post-dividers on NM style clocks
7d333ef1cc1b8c8951f3a2c41f6406e2295d8be9

clk: sunxi-ng: sun8i: a83t: Add /2 fixed post divider to audio PLL
10e6eb4f2c5b35ae71c9bc0db83d74238719b453

clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL
e952ca3c6b2ffdfbf9618e4bd3e9aad1ff3f5eb4

clk: sunxi-ng: Support fixed post-dividers on MP style clocks
946797aa3f08e2f6f5992f3ec2be44791e9b9260

clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
83fe3be4d1974f5f50c5e2039a1609f4960e8579


I allready tried to fix it with making them save against zero:

if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV && \
     cmp->fixed_post_div with)
    rate *= cmp->fixed_post_div;

But that didn't help.

Any ideas?

Regards,
Philipp

[1]: https://pastebin.com/64Fzzqvg


It took me some time, but I have now a few more infos:

Right now the code breaks at this point here [1], with this clock [2].
If we have a look now at the clock config [3], we see here a table which 
is an u8 array and also a fixed_predivs struct.


If we have a look at the function call where it breaks [4], shouldn't 
the table be a clk_div_table struct instead of an u8?


The a31s is the only board where we have this combination of a 
fixed_predivs and a table.


Philipp


Related Clock source register A31s:

: OSC24MHz/750=32KHz
0001: LOSC
0010: OSC24MHz
0011: /
0100: /
0101: /
0110: /
0111: /
1000: /
1001: /
1010: /
1011: AXICLK/4
1100: /
1101: AHB1CLK/4
1110: /
: /


[1]: 
http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/clk-divider.c#L89


[2]: 
http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/sunxi-ng/ccu-sun6i-a31.c#L1137


[3]: 
http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/sunxi-ng/ccu-sun6i-a31.c#L749


[4]: 
http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/clk-divider.c#L93


--
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] rtc: ac100: Fix ac100 determine rate bug

[Chen-Yu Tsai]

On Tue, Feb 13, 2018 at 5:07 AM, Philipp Rossak  wrote:
> This patch fixes a bug, that prevents the Allwinner A83T and the A80
> from a successful boot. You can find the shortend trace below:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 
> pgd = (ptrval)
> [] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2
> Hardware name: Allwinner sun8i Family
> Workqueue: events deferred_probe_work_func
> PC is at clk_hw_get_rate+0x0/0x34
> LR is at ac100_clkout_determine_rate+0x48/0x19c
>
> [ ... ]
>
> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
> (ac100_clkout_determine_rate) from  (clk_core_set_rate_nolock+0x3c/0x1a0)
> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
>
> To fix that bug, we first check if the return of the
> clk_hw_get_parent_by_index is non zero. If it is zero we skip that
> clock parent.
>
> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
>

Please add the tag:

Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")

> Signed-off-by: Philipp Rossak 
> ---
>  drivers/rtc/rtc-ac100.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
> index 8ff9dc3fe5bf..820ce6fb9d34 100644
> --- a/drivers/rtc/rtc-ac100.c
> +++ b/drivers/rtc/rtc-ac100.c
> @@ -183,7 +183,12 @@ static int ac100_clkout_determine_rate(struct clk_hw *hw,
>
> for (i = 0; i < num_parents; i++) {
> struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
> -   unsigned long tmp, prate = clk_hw_get_rate(parent);
> +   unsigned long tmp, prate;
> +
> +   if (!parent)
> +   continue;

There should be a comment on why this is happening, i.e. we purposefully
left open the possibility of the clock from the codec side missing.
Otherwise I think the clk subsystem doesn't expect this to happen,
which is why there are no checks like this anywhere.

ChenYu

> +
> +   prate = clk_hw_get_rate(parent);
>
> tmp = ac100_clkout_round_rate(hw, req->rate, prate);
>
> --
> 2.11.0
>

-- 
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: BUG: A31s Not booting anymore

[Chen-Yu Tsai]

On Tue, Feb 13, 2018 at 9:25 AM, Philipp Rossak  wrote:
>
>
> On 12.02.2018 19:21, Philipp Rossak wrote:
>>
>> Hey,
>>
>> When I try to boot my A31s (Bananapi M2) u-boot is showing only Starting
>> kernel ... . After enabling the earlyprintk I could capture this log: [1].
>>
>> After reverting those 5 commits from Chen-Yu I was able to boot again:
>>
>>
>> clk: sunxi-ng: Support fixed post-dividers on NM style clocks
>> 7d333ef1cc1b8c8951f3a2c41f6406e2295d8be9
>>
>> clk: sunxi-ng: sun8i: a83t: Add /2 fixed post divider to audio PLL
>> 10e6eb4f2c5b35ae71c9bc0db83d74238719b453
>>
>> clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL
>> e952ca3c6b2ffdfbf9618e4bd3e9aad1ff3f5eb4
>>
>> clk: sunxi-ng: Support fixed post-dividers on MP style clocks
>> 946797aa3f08e2f6f5992f3ec2be44791e9b9260
>>
>> clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
>> 83fe3be4d1974f5f50c5e2039a1609f4960e8579
>>
>>
>> I allready tried to fix it with making them save against zero:
>>
>> if (cmp->common.features & CCU_FEATURE_FIXED_POSTDIV && \
>>  cmp->fixed_post_div with)
>> rate *= cmp->fixed_post_div;
>>
>> But that didn't help.
>>
>> Any ideas?
>>
>> Regards,
>> Philipp
>>
>> [1]: https://pastebin.com/64Fzzqvg
>
>
> It took me some time, but I have now a few more infos:
>
> Right now the code breaks at this point here [1], with this clock [2].
> If we have a look now at the clock config [3], we see here a table which is
> an u8 array and also a fixed_predivs struct.

The u8 array is for mapping the parents from the index in the parents
array to the actual register value you listed below.

How are you figuring out which clock is triggering this? Because that
is not even the right type of clock. The backtrace you posted shows
the error occurring in a DIV or M type clock, not the MP type you
are pointing to.

Could you add some noisy printk calls to the sunxi_ccu_probe()
function in drivers/clk/sunxi-ng/ccu_common.c so it's much clearer
which clock is failing?


>
> If we have a look at the function call where it breaks [4], shouldn't the
> table be a clk_div_table struct instead of an u8?

The table argument is an option. Did you go through how the sunxi-ng driver
calls this function? As mentioned above, you are looking at the wrong thing.

Thanks
ChenYu

>
> The a31s is the only board where we have this combination of a fixed_predivs
> and a table.
>
> Philipp
>
>
> Related Clock source register A31s:
>
> : OSC24MHz/750=32KHz
> 0001: LOSC
> 0010: OSC24MHz
> 0011: /
> 0100: /
> 0101: /
> 0110: /
> 0111: /
> 1000: /
> 1001: /
> 1010: /
> 1011: AXICLK/4
> 1100: /
> 1101: AHB1CLK/4
> 1110: /
> : /
>
>
> [1]:
> http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/clk-divider.c#L89
>
> [2]:
> http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/sunxi-ng/ccu-sun6i-a31.c#L1137
>
> [3]:
> http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/sunxi-ng/ccu-sun6i-a31.c#L749
>
> [4]:
> http://lxr.bootlin.com/linux/v4.16-rc1/source/drivers/clk/clk-divider.c#L93
>

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