rvalue has quit [Read error: Connection reset by peer]
mckoan|away is now known as mckoan
rvalue has joined #u-boot
GNUtoo has quit [Ping timeout: 268 seconds]
GNUtoo has joined #u-boot
Xeroine has joined #u-boot
ldevulder has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
guillaume_g has joined #u-boot
mmu_man has joined #u-boot
sszy has joined #u-boot
<sjg1>
Tartarus: There is a new setup file in upstream: git://git.kernel.org/pub/scm/utils/dtc/dtc.git
<sjg1>
Tartarus: I have seen the warning too but have not got to it yet
monstr has joined #u-boot
persmule has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
agraf has quit [Ping timeout: 256 seconds]
agraf has joined #u-boot
mrnuke_ has joined #u-boot
Sout_ has quit [Ping timeout: 256 seconds]
alan_o has quit [Ping timeout: 256 seconds]
mrnuke has quit [Ping timeout: 256 seconds]
alan_o has joined #u-boot
Sout_ has joined #u-boot
macromorgan has joined #u-boot
macromorgan has quit [Killed (erbium.libera.chat (Nickname regained by services))]
mrnuke_ has quit [Ping timeout: 244 seconds]
mrnuke has joined #u-boot
mmu_man has joined #u-boot
matthias_bgg has joined #u-boot
davlefou has joined #u-boot
<Tartarus>
sjg1: OK, I guess we'll need to deal with the fun of re-syncing then before we can move to ubuntu 22.04 for CI
<Tartarus>
Which in turn means dealing with whatever the fall out was from ensuring our own internal case where the dtb is 4 but not 8 byte aligned is resolved
Xeroine has quit [Ping timeout: 268 seconds]
torez has joined #u-boot
tsraoien has joined #u-boot
thopiekar has quit [Ping timeout: 255 seconds]
mmu_man has quit [Ping timeout: 260 seconds]
thopiekar has joined #u-boot
hurricos has quit [Ping timeout: 244 seconds]
marc1 has quit [Quit: WeeChat 3.5]
camus has quit [Quit: camus]
<sjg1>
Tartarus: Yes I can take a look once I get the VBE series out. Some strange LTO problem is taking an age to figure out
<Tartarus>
Not update them to run, they already run them.
<Tartarus>
But moving to u22.04 from u20.04 adds that error
<Tartarus>
But, looks like there's a reasonable fix, thanks.
Xeroine has joined #u-boot
<sjg1>
Tartarus: OK good. I could not figure out what was making them run!
persmule has quit [Remote host closed the connection]
vagrantc has joined #u-boot
matthias_bgg has quit [Ping timeout: 255 seconds]
tlwoerner__ has quit [Quit: Leaving]
tlwoerner has joined #u-boot
mmu_man has joined #u-boot
persmule has joined #u-boot
matthias_bgg has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
mckoan is now known as mckoan|away
persmule has quit [Ping timeout: 268 seconds]
persmule has joined #u-boot
matthias_bgg has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 268 seconds]
* sjg1
rfs613: This is a design decision made with driver model. Drivers should read the DT data in, then use that 'platform data' to operate. It avoid mixing the DT logic in with the driver, which would complicate every driver quite a bit.
<rfs613>
sjg1: how to deal with limited malloc space pre-relocation (and presumably also in SPL/TPL/VPL/xPL)?
rvalue has quit [Read error: Connection reset by peer]
<rfs613>
my issue is the amount of malloc within a single driver instance - particular a clock driver on a SoC where there are hundreds of clocks/latches/muxes.
<rfs613>
and I'm seeing similar challenge with pinctrl, again due to large number of pins on the device.
<marex>
rfs613: I do understand the problem, yes
<marex>
rfs613: I wonder, can't we allocate one driver for the whole CCM module and not instantiate udevice for each clock, but rather have the top level udevice resolve to its internal per-clock data ?
<marex>
(I didn't look into the CCM recently, but that might make sense)
<marex>
it's essentially what you propose
akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #u-boot
<rfs613>
marex: that sounds about like what I am doing right now.. My clock driver has a large table listing all the clocks and their relationships, but the driver does not allocate a 'struct clk' for each of these.
<rfs613>
Instead, I have my own variant of clk_get_parent(), which uses the table, and constructs a 'struct clk' on-the-fly.
prabhakarlad has joined #u-boot
<marex>
rfs613: I think thats what rcar3 clock driver does too
<rfs613>
yup, that's where I got the idea...
<rfs613>
however the implementation is different enough that I was not able to adapt the rcar3 code
<marex>
rfs613: thats for some imx soc ?
<rfs613>
marex: it's for the RZ/N1 which I am (once again) resuming working on...
<marex>
oh
Xeroine has quit [Ping timeout: 272 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
matthias_bgg has quit [Ping timeout: 268 seconds]
tsraoien has quit [Ping timeout: 268 seconds]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
rburkholder has quit [Read error: Connection reset by peer]