00:04 <Jookia> jernej: tokyovigilante has hit this issue various times i think

03:36 <tokyovigilante> jernej: would be interested too, my current DRAM patches for the H616/700 are here, I'd say 1 in 10 cold boots I get an incorrect detection (2GB instead of 1GB)

03:36 <tokyovigilante> https://git.sr.ht/~tokyovigilante/u-boot/commit/7092bdc777f785ba9fde2fb680be9198aba8d1d5

03:59 <jernej> apritzel: Not sure how to describe in more details other than provide a patch. I didn't check what exactly happens if this is wrong.

03:59 <jernej> I don't experience any issue on H6, once I applied patch from ML with dsb() calls

04:00 <jernej> but I'll check if there is any similar issue

04:49 <tokyovigilante> thanks, I'm keen to get the LPDDR4 patches into u-boot as I have DT support for my H700 devices in-kernel now, and closing in on HDMI, GPU, sound etc

09:15 <apritzel> jernej: so can you send a H616 DRAM update series for U-Boot? Ideally containing your T507/H700 bits as well?

09:41 <tokyovigilante> jernej: could I also bother you on something else, I'm trying to enable LCD support on top of your HDMI/DE patches, do I need anything else for an LCD (connected by an RGB/SPI interface) than the DE/TCON patches there? And do you have any insight into what remote endpoint I should be using in my DT? Sorry if that's a lot

09:43 <tokyovigilante> Am getting [ 12.011383] sun8i-mixer 1100000.mixer: iommu configuration for device failed with -ETIMEDOUT

09:44 <tokyovigilante> when pointing it at remote-endpoint = <&tcon_top_mixer0_out_tcon_tv>;

09:52 <tokyovigilante> hmm, looking at the T507 datasheet that was never going to work, I need TCON_LCD0 in the middle

09:54 <gamiee> https://github.com/YuzukiHD/xfel-ng

10:51 <karlp> seems to be missing the spl and uboot ops though, also the multi write ops, which seem pretty useful

10:51 <karlp> has better spi flash support?

10:55 <tokyovigilante> hmmm, seems I'm going to have to add another TCON node for the LCD controller, and a buch of stuff from the D1, T507 etc... At what point should I be creating a new set of DT bindings for the H700? Or is it sufficient to add them to the H616 because they're actually there just not with exposed pins?

12:03 <apritzel> gamiee: we already have A523 support in sunxi-fel

12:03 <apritzel> (and not sure yet *another* FEL tool is helpful)

12:06 <gamiee> apritzel : ah yeah, just sent it here as interesting thing to take look on.

12:06 <gamiee> still fan of our sunxi-tools

15:13 <kikuchan> I've update my PWM driver for H700: https://gist.github.com/kikuchan/f21be9dc5947fbb88d7c51dff2f6bdd6

15:14 <kikuchan> Now it supports selecting PWM clock source for paired-channel individually and applying prescale (DIV_M) for each channel. Also I think it would be fixed some issue regarding period edge-case.

15:15 <apritzel> kikuchan: that's a nice driver, but putting it somewhere is not how the process works, unfortunately.

15:15 <kikuchan> oh thanks. how should I do next?

15:16 <apritzel> as you know, there is already a driver proposed on the list, and Aleksandr put quite some effort into it, going through different revisions and addressing comments

15:16 <apritzel> so the unwritten rule is: "the first one to post a driver wins"

15:17 <apritzel> if you have comments and improvements, they should be reported on the list, as a reply

15:18 <apritzel> you mentioned "copyright issues" earlier, what was that about, particularly?

15:23 <kikuchan> oh I see. thanks. I didn't understand the rule.

15:23 <kikuchan> I'd worked on the driver separately before, so I made the driver from scratch again. I thought if he didn't respond actively, I could post the driver that is not related to his effort.

15:26 <kikuchan> but now I think I understood the rule. thanks again.

15:27 <apritzel> well, you can take over. I haven't seen him replying since January, so he might have given up. You should just send him an email asking about that

15:29 <apritzel> in general the expectation is that drivers are developing on the list, so they improve gradually. If Aleksandr doesn't have interest in that anymore, you can fix his driver, and send a new version

15:30 <apritzel> but normally that would keep his authorship

15:31 <apritzel> unless the code is considered completely broken, and the new version does not contain significant parts of the old driver anymore

15:31 <apritzel> as you see, this: "here is a completely new driver" doesn't fit in that model very well

15:32 <apritzel> so I haven't looked at this in detail, but how close or how far is your driver from the v8 on the list?

15:35 <kikuchan> Hmm... I think it's very far...

15:39 <kikuchan> Honestly, I also wanted take the code over to someone, because I have no experiences on the list, and I'm non-English speaker.

15:42 <apritzel> you are honestly doing very well with English, and in fact the majority of contributors are not native speakers

15:42 <apritzel> and email makes it easier to cope with the language barrier, as you can take your time in understanding comments and crafting responses

15:48 <kikuchan> oh thanks, and indeed. I'll try something then...

15:49 <apritzel> kikuchan: you should figure out what's Aleksandr's position on this driver. If he indeed is not interested anymore, you could post your driver as an RFC, if you can give rationale why this one is better

15:49 <apritzel> that would allow people to look at both versions and from their own opinion

15:50 <apritzel> s/from/form/

15:51 <apritzel> if most agree that the new driver is much better, and if Aleksandr doesn't object, we could take yours as well

15:51 <apritzel> but the process should be transparent, so happen on the mailing list

15:52 <kikuchan> ok, I see. I'm really appreciate for the advise. thanks again.

16:06 <jernej> apritzel: I plan to post improvements for H616 DRAM driver, but first I want get some feedback here first

16:07 <jernej> I'll prepare patches today so tokyovigilante can test them

16:57 <Schimsalabim> jernej: i still have an eye open for DDR4 on H616, would your patches affect this ?

16:59 <Schimsalabim> running brute force phy_init configurations trying to get somewhere with this.

17:05 <apritzel> jernej: I think it's easier to provide feedback if you would post something ;-)

17:06 <jernej> sure, but ML patches take time to prepare, here I can just dump random patch :D

17:06 <jernej> but don't worry, I'll make them in any case

17:16 <apritzel> jernej: you could also push them on your github, for early comments and tests

17:16 <jernej> sure

17:17 <jernej> if everything goes to plan, they should appear there around the weekend, but no promises

18:22 <macromorgan> dumb C question (not a programmer by trade), but is there a way to create a table of values without having to list them all out? Like here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/supply/axp20x_usb_power.c?h=v6.9#n487

18:23 <macromorgan> this table is 9 values, but I want to create one with 32 values. rather than list all 32 out I was just going to see if there was a macro to do it (assuming the values are sequential). Otherwise, I might have to refactor a bit more to change how current limit values are derived (with a function rather than a table).

18:25 <jakllsch> macromorgan: you basically have to list any ones you want non-zero

18:26 <macromorgan> okay, I guess I'll refactor to add a function, because a table of 32 sequential values seems a bit lazy

19:35 <jernej> apritzel: Annoying thing is that initial driver was done with older version of DRAM driver. Now that I have newer version, I notice some differences.

19:35 <jernej> I'm not sure if it makes sense to update everything to newer version, although there must be a reason for those changes.

21:15 <apritzel> macromorgan: do you want to initialise a struct or an array? I guess the latter?

21:21 <apritzel> ah, I see, sequential values in an array: for that you would indeed need a function. You can skip indices: {1, 3,[7] = 5, 7, 9}; or you can assign multiple indices the same value: [12 ... 15] = 7

21:22 <apritzel> not sure the latter is accepted in the kernel, though

21:30 <macromorgan> since I'm going to use a different series of routines for getting and setting the properties, I think I can safely go without a table and just use a function.

21:30 <macromorgan> I have a functional ADC driver, working on the USB charger one now

21:49 <apritzel> macromorgan: it would be good to ask in a better (or wider) forum what's the recommended way to model a battery is. May a power_supply class device?

21:50 <apritzel> either post on some mailing list or find an IRC channel

21:52 <apritzel> I think the A64 and its AXP803 power mobile devices, like PineTab/PinePhone/PineBook, or the TeresI. Maybe worth to check there, if you didn't already

21:58 <macromorgan> I'm looking at the existing axp driver. What it does basically is create a few adc channels with an ADC driver that then feed into a charger driver and a battery driver.

22:00 <macromorgan> for example on the axp813 it creates the following channels: pmic_temp, gpio0_v, batt_v, batt_chrg_i, batt_dischrg_i, ts_v: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/adc/axp20x_adc.c?h=v6.9#n213

22:00 <macromorgan> then the battery and power supply drivers consume those channels (along with doing a few additional things of their own)

22:14 <apritzel> that sounds like one solution, but from a (very quick) search I got the impression there is some power supply class to unifies all those elements, and is targeted specifically at batteries?

22:14 <apritzel> the problem with many AW related devices is that their drivers are quite old, so might not represent the current approach in the kernel

22:16 <apritzel> the AXP813 was paired with the A83T, which is 10 years old by now

22:20 <macromorgan> hmm

22:20 <macromorgan> let me pester the mfd team for advice

22:22 <macromorgan> the only other way I see it done is the way the axp288 does it... again if I'm sticking with Allwinner devices.

22:33 <macromorgan> I mean I suppose I could just use the axp20x drivers without building my own ADC driver too. End of the day it won't change very much.

22:38 <apritzel> yes, there might not be much difference functionality-wise, I just wanted to avoid disappointment on your side, when you come up with a series and the first reply on the list is to do it completely differently

23:12 <macromorgan> wouldn't be the first time (or the second time...)