ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
jlinton has joined #armlinux
bps has quit [Remote host closed the connection]
Pali has quit [Ping timeout: 260 seconds]
rbutler1728 has quit [Read error: Connection reset by peer]
matthias_bgg has quit [Ping timeout: 260 seconds]
TheCoffeMaker has quit [Ping timeout: 252 seconds]
TheCoffeMaker has joined #armlinux
TheCoffeMaker has quit [Ping timeout: 260 seconds]
TheCoffeMaker has joined #armlinux
matthias_bgg has joined #armlinux
jlinton21 has joined #armlinux
jlinton has quit [Ping timeout: 256 seconds]
Nact has joined #armlinux
russ has joined #armlinux
rfs613 has quit [Ping timeout: 258 seconds]
rfs613 has joined #armlinux
iivanov has joined #armlinux
iivanov__ has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 260 seconds]
iivanov__ has quit [Ping timeout: 260 seconds]
iivanov_ has quit [Remote host closed the connection]
<mwalle>
maz: which is uboot only and not really blessed by rob. anyway
<mwalle>
maz: I don't know almost nothing about the GIC. apparently there is some memory region for the LPIs. Is this something the bootloader has to set up? I.e. who chooses the offset 0x80000000 (which is the start of the system RAM)
<mwalle>
maz: but it doesn't mention the motivation behind it. So I'm currently trying to figure out who should do what. Or where to get that information, eg. there is also that max-gic-redistributors property.. but isn't that something which can also be read from hardware?
<mwalle>
maz: from the GIC i mean
<maz>
this information is already in the original binding, in the form of the GICR regions. each RD is either 128kB or 256kB, and it is a simple division to know how many you get.
<maz>
what I expect is that they have allocated memory for that many RDs, but we can only find out when looking at the state of the RDs themselves.
<maz>
this is obviously written by people who don't have a clue of how the HW works, and of what an OS expectations are.
<maz>
Linux will work without that crap as long as you mark the memory as reserved.
<mwalle>
maz: which memory?
<mwalle>
that which is allocated for the RDs?
<maz>
that memory: reg = <0x0 0x80000000 0x0 0x100000>;
<maz>
which I expect has been programmed into the RDs somehow.
<mwalle>
maz: but it can be anywhere in system ram, I guess?
<maz>
as long as it has the right alignment, yes. but once it is programmed in the RD and that the RD is enabled, you can't change it anymore. it is set once and for all.
<maz>
(until you reset the system, that is).
<maz>
but frankly, I question why they push that crap into u-boot.
<mwalle>
maz: thanks, if I'll come up with something, can I put you on CC?
<maz>
please do. I'm happy to publicly state that this crap shouldn't be there at all.
<mwalle>
maz: one last question though. "The workaround of LPI one-way reset issue is broken by the series". can you make sense of what a LPI one-way reset should be?
<maz>
I guess that's what I was explaining: once you have programmed the RD for LPIs to be enable, you can't turn it off nor reclaim the memory programmed there.
<maz>
I'm not sure where you are reading this from though.
<mwalle>
maz: and CONFIG_GIC_V3_ITS=y crept into the layerscape configs. funny enough my board, which is also a ls1028a, doesn't have it set. and i have no clue why I'd need it
Amit_T has joined #armlinux
<maz>
mwalle: I tried to explain it, but obviously failed: once you enable LPIs, you can't disable them. full stop. which means that if you have enabled them in u-boot because you rely on MSIs, you need to tell the kernel about your allocations.
<maz>
mwalle: this is what is crap is trying to achieve, not even realising that this is an already solved problem.
<mwalle>
maz: i understood that you cannot change it, but my question was, does u-boot need it at all
<maz>
mwalle: again: if u-boot relies on MSIs for $reason, it has no option but to enable LPIs.
<mwalle>
maz: ok. MSIs.. (sorry if i'm not that familiar with that whole GIC stuff)
monstr has quit [Ping timeout: 264 seconds]
monstr has joined #armlinux
Turingtoast has joined #armlinux
matthias_bgg has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #armlinux
jlinton21 has quit [Quit: Client closed]
jlinton has joined #armlinux
monstr has quit [Remote host closed the connection]
sudeepholla has joined #armlinux
prabhakarlad has quit [Ping timeout: 256 seconds]
wwilly has joined #armlinux
torez has joined #armlinux
matthias_bgg has quit [Ping timeout: 245 seconds]
matthias_bgg has joined #armlinux
torez has quit [Ping timeout: 264 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #armlinux
tudorel has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]