ikarso has quit [Quit: Connection closed for inactivity]
<marex>
macromorgan: language ffs !
<marex>
macromorgan: also, just reply to the mail and say this is really a V2, reasonable maintainer won't be overly grumpy
<marex>
macromorgan: or send a V3 and be done with it
prabhakarlad has quit [Quit: Client closed]
<macromorgan>
okay, I'll reply. Also sorry for the language.
mmu_man has joined #u-boot
<rfs613>
marex: I've addressed most of your comments for the RZ/N1 patches. Could post a new version. But I am struggling a bit with how to split up the DDR controller stuff between driver, arch, and board.
<sjg1>
marex: yes that fdt_blob thing should be using map_to_sysmem()
flyback has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 246 seconds]
flyback has joined #u-boot
<marex>
rfs613: thanks. About the DRAM controller, ideally as much as possible in drivers/ , as little as possible elsewhere
<rfs613>
marex: currently it is all in drivers/ram/cadence (new directory) apart from the table of magic values (which is now in the devicetree).
<rfs613>
however there are some things that are specific to rzn1, such as the calls to clk_rzn1_reset_state()
<rfs613>
(am just putting the kids to sleep, so a bit difficult to discuss right now...)
<marex>
rfs613: cant you use clock and reset framework to abstract that part out ?
<rfs613>
marex: possibly (am already using clock framework). But there are other things, such configuring for a single bank, the PHY setup, etc, which are board (or perhaps arch) specific.
<marex>
rfs613: the DRAM settings should likely go into DT or board/ files
<marex>
because yes, those are board specific
<rfs613>
marex: there is a comment near the top of drivers/ram/cadence/ddr_ctrl.h which explains that one calls init, then a bunch of optional functions (depending on the desired configuration), and then cdns_ddr_ctrl_start()
<rfs613>
so presumably that should go into board file (putting it in DT seems difficult)
<marex>
seems like $ git grep -li cadence drivers/ram/ drivers/ddr/
<marex>
already contains a cadence DDR driver
<marex>
I am worried this will end up like the Designware one -- U-Boot now has 7 drivers for the same IP, each from different SoC vendor, each in different weird state
<marex>
sigh
<marex>
rfs613: I guess __weak board_do_some_dram_init() would be OK too
<rfs613>
marex: yes there are several similar-ish versions of cadence denali driver already...
<marex>
oh, yeah, denali ... about four
<marex>
sigh
<rfs613>
unfortunately it's quite hard to find out exactly what IP is present on a given SoC... and usually by the time software team sees a new piece of hardware, the "magic" for starting DDR etc has already been done. Any changes to it are met with a lot of resistance...
<rfs613>
(by management I mean...)
<marex>
rfs613: so what would it take to convince management to stop turning upstream into dumping ground for this crud ?
<marex>
I mean, this is not maintainable in the long run
<rfs613>
i have to agree with you there... but I don't know how we solve the problem...