08:06 <CounterPillow> Whose tree is the mipi-dsi stuff in? I see some patches on the mailing list from the 30th but that patchset is smaller than the one from May so I assume some stuff was merged somewhere

08:07 <CounterPillow> Did this go through the drm tree?

08:09 <CounterPillow> ok yes it was through drm, sorry for the noise :)

08:34 <narmstrong> CounterPillow: yes it's based on drm-misc-next, you'll be able to base on v6.5-rc1 on next monday

08:34 <CounterPillow> Thanks

09:12 <rockosov> narmstrong: xdarklight Hello! Do you know the purpose of using the ttyAML prefix for the meson uart device instead of the standard ttyS prefix? Because of this, it is necessary to generate additional 'if' statements in the bootloader scripts to support different kernel versions (from vendors and upstream). I am just wondering how this helps to solve which problems.

09:12 <narmstrong> rockosov: legacy reasons...

09:13 <rockosov> :-)

09:13 <rockosov> I'm trying to find any special driver to generate early name aliasing... But don't see anything

09:13 <narmstrong> uart was one of the first amlogic driver upstreamed long time ago, nowadays ttyAML would have been rejected

09:14 <narmstrong> OMAP did the migration a long time ago and had a driver who did the aliasing, but it has been removed

09:14 <narmstrong> I don't understand why ttyAML was accepted at the time

09:15 <rockosov> narmstrong: Do you think it's not good idea to change this name in the new kernel versions (with appropriate chages to all dts(i)?

09:16 <narmstrong> well it will cause breakage, but perhaps we could perhaps make it appear as ttyS for new platforms

09:16 <narmstrong> AFAIK DT doesn't need any changes

09:20 <narmstrong> rockosov: add a copy of uart_meson_driver with ttyS and use it for new compatibles via a new meson_uart_data struct

09:22 <rockosov> narmstrong: Okay, I'll prepare the such change, and send today. I suppose we can use new name for A1, S4, T7, C3 as newest Amlogic platforms. What do you think?

09:23 <narmstrong> rockosov: yep I think all of these can use the new name since they are part of no distro right now

09:24 <rockosov> narmstrong: BTW, I've made a grep over dts. You are right, no additional changes are required for dt part

09:24 <narmstrong> I'll be able to finally drop https://github.com/superna9999/meta-meson/tree/master/recipes-extended/shadow-securetty !

09:25 <narmstrong> even if with systemd it's no longer an issue

09:26 <rockosov> Yep, all well-known UART-based things are using ttyS prefix... So the change will help certainly

09:55 <rockosov> narmstrong: One small point to make - in order to support different ttyXXX names based on compatible tag, it is necessary to port the meson-uart driver from a simple init/exit module to a platform_driver module. This is necessary because the OF subsystem requires an initialized platform device. At first glance, it doesn't seem like a big deal.

10:05 <narmstrong> rockosov: yeah whatever must be done do it and we’ll see the result

10:07 <rockosov> narmstrong: Okay :-)

10:45 <f_> ttyAMLx is legacy now

10:45 <f_> if I understood correctly. Honestly it shouldn't be too hard to adapt that for postmarketOS (I maintain the kernel package used for Amlogic devices)

10:46 <f_> Each device has a deviceinfo file where we configure some stuff like the cmdline

10:47 <f_> I made the choice to *not* enable UART by default in the KII Pro, but some Amlogic devices have it enabled by default.

10:47 <f_> Still, a simple s/ttyAML0/ttyS0/ should be enough =)

10:47 <f_> The number of Amlogic devices supported by postmarketOS should be manageable.

11:31 <rockosov> f_: I agree with you that using the old approach is acceptable for legacy devices. However, we should avoid repeating the same mistakes with new boards. Why not try a different approach?

11:32 <f_> Sorry, didn't mean that. I meant that we should also use the new approach on legacy devices.

11:33 <f_> and that, in postmarketOS, it should be easy to switch to ttyS from ttyAML.

11:33 <f_> (we don't have that much Amlogic devices in postmarketOS)

11:41 <narmstrong> We can’t allow breakage for current supported device

11:43 <f_> Understandable.

11:44 <f_> "We don't break userspace!"

12:07 <f11f12> when OMAP migrated, they had some kind of alias and a warning message for quite some time.

12:12 <narmstrong> Yep exact, so I wonder why ttyAML was accepted after that… anyway it’s done but let’s avoid it for new socs if possible

12:13 <f_> We should slowly migrate older ones, too..like, have ttyS as default and ttyAML as alt

12:13 <f_> just to not break anything.

12:13 <f_> Have both, but recommend the use of ttyS

12:14 <f_> Tell that ttyAML is deprecated but left for compatibility

13:02 <rockosov> Draft patch is ready, will try to send the first version today or tomorrow

13:10 <f11f12> narmstrong: is mipi + hdmi output possible? In the past it was mipi or hdmi

13:17 <narmstrong> f11f12: dual display is still not implemented

13:59 <psi15> Hello! I'm trying to create a sound card where a DAI link has separate codecs for playback and capture. I can add two codecs in the DTS but the problem is snd_soc_dai_ops.startup callback is called when I do a capture with arecord even when snd_soc_dai_driver only fills the playback element. So both codecs for this DAI are started but I think the

13:59 <psi15> correct way would be to only start the codec that can actually handle the current substream direction. Is there a way to specify in the DTS that a codec is only responsible for playback or capture but not both?

14:01 <f_> Which SBC/set-top box?

14:03 <psi15> A113D

15:33 <f_> I ended up successfully initialising the PLL

15:33 <f_> *DDR PLL

15:36 <f_> Wanna know what the problem was?

15:36 <f_> I wrote to the wrong regs :^)

15:38 <f_> I think I needed sleep when I was writing the code :^)

15:39 <f_> Now PCTL init is where stuff goes wrong

15:39 <f_> With the watchdog it would reset again and again. Now it just hangs.

15:39 <f_> (which is good)

15:45 <f_> Here's a trick I use to debug:

15:45 <f_> #define mmio_write_32(reg, val) printf("mmio_write_32\t%lx\t%x\n", (uintptr_t)reg, (uint32_t)val); *(volatile uint32_t*)reg = val

15:46 <f_> mmio_write_32 c8839004 2

15:46 <f_> And this is where it hangs

15:47 <f_> https://git.vitali64.duckdns.org/misc/trustedfirmware-a.git/tree/drivers/amlogic/ddr_new/ddr_pctl_init.c?h=wip/gxbb&id=af1c9495d0ef11d65787ae2f9a4a0a788db26106#n202 permalink

15:47 <f_> Right to the ~end.

15:48 <f_> BTW you may also have noticed that I hardcode values

15:52 <f_> Ok it's actually hanging at the while loop just after.

16:22 <f_> Problem: 0xC8839008 is supposed to be == 3

16:22 <f_> but it isn't.

16:22 <f_> Maybe forgot to set some register