04:22 <chewitt> xdarklight: not sure if that commit was supposed to fix the blue-tint or not, but I picked it and tested with a G12B box (vendor u-boot) and no difference

05:48 <xdarklight> chewitt: for me it solves the "framebuffer console is not shown" issue. the blue tint is now not as "in your face" (before the black part of the screen was also blue-ish) anymore, but it's still there

06:55 <narmstrong> xdarklight: the g12b issue is a hdr issue, afaik it’s not possible in m8, and I didn’t find what to disable... but i havent spend a lot of time on it

07:25 <xdarklight> OK

07:46 <narmstrong> xdarklight: I don't recall having such blue tint on the black

07:46 <narmstrong> maybe it'a an alpha issue

10:50 <xdarklight> narmstrong: I need to look into it tonight. please let me know if there's a register you would check first

15:29 <alpha_one_x86> Hi, I'm testing the kernel 5.6, and I have: https://pastebin.com/HdSSgzbY

15:30 <alpha_one_x86> any idea?

15:32 <la-s> alpha_one_x86: does ethernet not work then?

15:33 <la-s> also, I think people can help you more if you post the full dmesg and also what hardware you're using

15:35 <narmstrong> yep, hw model would be a minimul

15:40 <alpha_one_x86> correct, ethernet don't work

15:41 <alpha_one_x86> Odroid C2, sorry

15:41 <alpha_one_x86> dmesg is not accessible, I'm connected to the UART

15:41 <alpha_one_x86> 4.19 kernel worked fine

15:51 <la-s> I am pretty sure the nightly armbian builds work fine, you could try figuring out what's different if those work (dl.armbian.com/odroidc2/nightly/)

15:53 <alpha_one_x86> will be complicated test a whole OS

15:56 <alpha_one_x86> I had tested multiple kernel option, but without result

16:42 <alpha_one_x86> amlogic DMA is not show into menuconfig

17:50 <xdarklight> alpha_one_x86: what is your CONFIG_HZ= value (from your kernel config)?

17:57 <armoon> hello xdarklight, I see you have been working on getting HDMI to working on meson8, is their any branch for me to test on my Odroid c1

18:01 <xdarklight> armoon: generally the latest meson-mx-integration branch from https://github.com/xdarklight/linux/

18:02 <armoon> ok I will check out, thanks

18:02 <xdarklight> armoon: if you want to try it now you need to: 1. drop the assigned-clocks and assigned-clock-rates properties from the VPU node in meson8b.dtsi 2. run "video dev open 1080P" in u-boot before you boot Linux

18:02 <armoon> Ok good

18:02 <xdarklight> (I'm currently playing with CVBS *and* HDMI, so the assigned-clocks are configured for CVBS at the moment and there's no support in Linux to properly reconfigure the video clocks for HDMI yet)

18:03 <xdarklight> also expect color issues on HDMI ;)

18:04 <armoon> ok cool

18:06 <xdarklight> wens: narmstrong: I was very certain that the HDMI controller in the Meson8* SoCs is an Analogix IP block. I contacted them and had a very nice conversation with an Analogix employee. summary of this conversation: "I don’t think it uses Analogix HDMI IP". if you have any ideas from which vendor this may be then please let me know

18:08 <armoon> Another query you submitted https://patchwork.kernel.org/cover/11463341/ for SDHC MMC, will these patches support eMMC on Odroid c1

18:09 <xdarklight> yes, I have an Odroid-C1 with 8GB eMMC module and that was one of my testing targets :-)

18:12 <armoon> I have so old eMMC 5.0 modules, so I will give this a try at my end, but some DTS changes are sill missing

18:13 <xdarklight> https://github.com/xdarklight/linux/commit/3fdd89585ac557a1780a0226cc50f4a41ccb0c3d that works fine for me

18:14 <armoon> ok

18:16 <armoon> Thanks I will give this a try tmr

18:24 <xdarklight> narmstrong: RE color/alpha issue: I see the same blue-ish tint on CVBS output as well. when I start kmscube the background turns red: https://abload.de/img/vlcsnap-2020-04-21-20vtks3.png (captured from the CVBS output using some CVBS-to-USB capture adapter)

18:34 <alpha_one_x86> xdarklight: CONFIG_HZ=100

18:39 <narmstrong> xdarklight: weird

18:40 <narmstrong> xdarklight: I’ll think of a part to check, but I never had this issue

18:43 <alpha_one_x86> I try enable CONFIG_AXI_DMAC and I failed

18:45 <alpha_one_x86> oups, nothing

18:45 <alpha_one_x86> maybe missing firmware?

19:09 <xdarklight> alpha_one_x86: that's also what I have and what's working fine for me. the Armbian guys reported issues with either CONFIG_HZ=200 or =250 (I don't remember anymore), but it always worked for them with =100. However, I'm not sure anymore what their exact problem was

19:13 <alpha_one_x86> my full config: https://pastebin.com/HYQGc6ta

19:19 <xdarklight> alpha_one_x86: can you please try to revert this patch: https://github.com/torvalds/linux/commit/f29cabf240ed6e67993f17594e5e6fffc5bc07e0 ? I have an email from a user who said that this causes problems for him, but he didn't give me any details (like kernel config, dmesg, etc.)

19:34 <alpha_one_x86> https://pastebin.com/yz8br0EP -> patch reverted, led on, but remain failed

19:42 <xdarklight> OK, if you go back to the original version (meaning: that patch should be applied again), what happens if you remove the reset-assert-us, reset-deassert-us and reset-gpios from the eth_phy0 node in arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts ?

19:44 <xdarklight> alpha_one_x86: I'm just guessing by the way. I cannot reproduce this myself unfortunately, so sorry if you have to do some experiments ;-(

19:46 <alpha_one_x86> revert the patch already disable this code

19:46 <alpha_one_x86> no problem, thanks to help me

19:50 <alpha_one_x86> same with or without reset-assert-us, reset-deassert-us and reset-gpios

19:53 <xdarklight> "same" means which error message do you get?

19:55 <alpha_one_x86> correct, same error message into dmesg

19:57 <xdarklight> here you got "meson8b-dwmac c9410000.ethernet: Failed to reset the dma": https://pastebin.com/HdSSgzbY but here you got "meson8b-dwmac c9410000.ethernet eth0: no phy at addr -1": https://pastebin.com/yz8br0EP

19:57 <xdarklight> which of these two do you get without the reset-* properties? or do you now get a new error?

19:59 <alpha_one_x86> https://pastebin.com/HdSSgzbY -> vanilla kernel

20:00 <alpha_one_x86> with snps,reset-* https://pastebin.com/yz8br0EP

20:00 <alpha_one_x86> with or without reset-* no change

20:02 <xdarklight> and what happens if you remove all snps,reset-* and all reset-

20:12 <alpha_one_x86> if I remove all snps,reset-* and all reset- -> all work

20:17 <xdarklight> interesting. now can you please go back to vanilla and apply https://pastebin.com/umtzBgE4

21:03 <alpha_one_x86> last ets for today

21:03 <alpha_one_x86> last test for today

21:06 <alpha_one_x86> with your patch, all work