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
apritzel has quit [Ping timeout: 272 seconds]
Pali has quit [Ping timeout: 272 seconds]
jlinton has quit [Ping timeout: 250 seconds]
amitk has joined #armlinux
<tmlind> arnd: yeah please pick it up directly to arm-soc if no other comments
kos_tom has quit [Ping timeout: 250 seconds]
scosu has quit [Quit: No Ping reply in 180 seconds.]
scosu has joined #armlinux
kos_tom has joined #armlinux
wens has quit [Quit: Reconnecting]
wens has joined #armlinux
wens has quit [Quit: Reconnecting]
wens has joined #armlinux
Lucanis0 has joined #armlinux
Lucanis has quit [Ping timeout: 260 seconds]
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has joined #armlinux
Lucanis0 has quit [Ping timeout: 260 seconds]
iivanov__ has joined #armlinux
iivanov has quit [Ping timeout: 272 seconds]
Misotauros has quit [Ping timeout: 256 seconds]
archetech has joined #armlinux
iivanov__ has quit [Remote host closed the connection]
iivanov has joined #armlinux
monstr has joined #armlinux
apritzel has joined #armlinux
djrscally has joined #armlinux
guillaume_g has joined #armlinux
luispm has joined #armlinux
sszy has joined #armlinux
apritzel has quit [Ping timeout: 260 seconds]
Pali has joined #armlinux
headless has joined #armlinux
apritzel has joined #armlinux
Grimler has quit [Ping timeout: 240 seconds]
luispm has quit [Read error: Connection reset by peer]
luispm has joined #armlinux
<ardb> arnd: thanks for pulling those Seattle changes
headless has quit [Quit: Konversation terminated!]
<ajb-linaro> what is page_link in an scatterlist? A page aligned address or an indirection to a page entry?
* ajb-linaro is trying to track the conversion of kernel vaddr to guest physical address in a virtio transaction
<arnd> ajb-linaro: see the comments in include/linux/scatterlist.h, "We use the unsigned long page_link field in the scatterlist struct to place the page pointer AND encode information about the sg table as well. The two ower bits are reserved for this information..."
<arnd> in driver code, you are supposed to not care if you use the interfaces correctly, such as traversing with for_each_sg()
<ajb-linaro> arnd: yeah and confusingly all the other transactions work but the last one in my driver ends up with the backend parsing an invalid gpa
<ajb-linaro> arnd: at some point there is a gpa calculated right?
<arnd> ajb-linaro: the two adresses in the scatterlist are the page pointer (which can be turned into a guest physical address or a pointer in the linear map using page_to_*()), and the dma_addr, which is usually either a gpa or the DMA address as assigned by the iommu
<ajb-linaro> arnd: so it looks like when vring_map_one_sg is called on my outgoing frame we get a invalid gpa... I wonder if having the request frame sit on the kernel stack is the problem?
<ajb-linaro> (gdb) p/x pa
<ajb-linaro> $4 = 0x4049d7bb40
<ajb-linaro> (gdb) p/x dev->regions[0]
<ajb-linaro> $5 = {gpa = 0x40000000, size = 0x100000000, qva = 0x7fc7dbfff000, mmap_offset = 0x0, mmap_addr = 0x7ffef0000000}
<ajb-linaro> (gdb) p/x pa - dev->regions[0].gpa
<ajb-linaro> $6 = 0x4009d7bb40
<ajb-linaro> very outside the region of the one block of ram we have
<ardb> ajb-linaro: yes that is a problem
<ardb> you cannot DMA from the stack
<ajb-linaro> ardb: because of a specific protection - it is after all just another area of RAM
<ardb> ajb-linaro: it does not use the same VA to PA translation
<ajb-linaro> (not that there is any real DMA going on here)
<ardb> DMA from the stack is a bad idea for other reasons as well
<ardb> non-coherent DMA, most notably
<ajb-linaro> oh well I guess I'll just kmalloc my frame in the driver
<ardb> yes that should do the trick
headless has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
torez has joined #armlinux
headless has quit [Quit: Konversation terminated!]
SallyAhaj has joined #armlinux
archetech has quit [Quit: Konversation terminated!]
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
amitk has quit [Ping timeout: 256 seconds]
Lucanis has quit [Ping timeout: 260 seconds]
amitk has joined #armlinux
Lucanis has joined #armlinux
SallyAhaj has quit [Read error: Connection reset by peer]
SallyAhaj has joined #armlinux
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has joined #armlinux
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #armlinux
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has joined #armlinux
Lucanis has quit [Client Quit]
Lucanis has joined #armlinux
Lucanis has quit [Client Quit]
Lucanis has joined #armlinux
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #armlinux
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has joined #armlinux
monstr has quit [Remote host closed the connection]
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
SallyAhaj has quit [Ping timeout: 260 seconds]
Misotauros has joined #armlinux
SallyAhaj has joined #armlinux
luispm has quit [Quit: Leaving]
headless has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
<broonie> tmlind: Did that clk_put() regression get handled? The kernelci bisect bot just hit an issue on that commit.
ukleinek has quit [Quit: back in a moment]
ukleinek has joined #armlinux
apritzel has quit [Ping timeout: 260 seconds]
dok has joined #armlinux
<ajb-linaro> \o/ passes all tests. Shall rebase and clean-up for posting on Monday
barebox has joined #armlinux
<barebox> hello o/
barebox has left #armlinux [surfing away, stay cool]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<palmer> robher: sorry if I screwed this one up, looks like Linus is merging stuff. I don't mind re-spinning my PR
<robher> palmer: Please.
barebox has joined #armlinux
<barebox> hello o/
apritzel has joined #armlinux
<barebox> What's the most used bootloader on arm ?
<palmer> robher: hopefully Linus sees it
<palmer> sorry
barebox has left #armlinux [byebye]
<robher> palmer: I would suggest you do a patch on top. Rebasing will only further annoy him if only just landing in linux-next didn't. It's not the first set of binding warnings he's been aware of this merge window either.
<palmer> so I thought you were suggesteding I drop the PMU patches?
<palmer> I can fix the warnings, that's an easy one, but it might not make rc1
<palmer> (I guess, almost certainly won't)
<palmer> if it's OK to keep these and have a fix, then I'll reply and say the PR is OK for now
<robher> I mean apply a fix on top and send a new PR today.
<palmer> OK
amitk has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #armlinux
<marex> broonie: hi, are you aware of any MIPI DSI regmap attempts ?
<broonie> marex: Not that I can recall.
<marex> broonie: maybe next year I'll get to it and submit a patch then
<broonie> It should be pretty quick to do if the bus has register I/O operations.
<marex> broonie: like mipi_dsi_generic_read/mipi_dsi_generic_write ? :)
<marex> broonie: there is many pretty quick things to do on that todo list
<palmer> robher: I just sent something, I must not have the checkers running (as I didn't see anything) -- I'll try and figure that out...
<broonie> marex: Think of all the time the logging and cache code will save you :P
<marex> broonie: yeah, very little, of the two drivers which use these DSI accessors, one has its own wrappers around them
<marex> broonie: but I plan to write the regmap part, if only for the debugfs register list
<marex> that part of regmap is great
SallyAhaj has quit [Remote host closed the connection]
<palmer> robher: LMK if that v2 is OK, I'm still trying to get the dt check to run locally but I've always had issues
headless has quit [Quit: Konversation terminated!]
<palmer> robher: with the v2 on top of my for-next and Linus' master merged, I don't get any more idle DT check issues -- there's a handful of others, I'll look into fixing them but it might take a bit
torez has quit [Remote host closed the connection]
<robher> palmer: you need to add this hunk:
<palmer> thanks, let me go re-run the tests
<palmer> I think they're working now, it's still a manual thing though because there's some failures
<palmer> I'll try and get them in the automation so this doesn't break again
<robher> palmer: You can always check Linus' tree and next here: https://gitlab.com/robherring/linux-dt/-/jobs
<palmer> oh, thanks
<palmer> I kind of like to be able to run them locally, though -- if I catch stuff before it's in next or reviewed then it makes life a bit easier on my end, as I don't have to juggle patches like this
<palmer> looks like I broke my toolchain trying to sort out the sparse issue, so it might take a minute or two to sort this out...
cbeznea1 has quit [Ping timeout: 260 seconds]
SallyAhaj has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
<palmer> robher: I don't see any differenece with/without that hunk, I think probably because we don't have CPUs with idle-states? It's just the generic examples right now
<palmer> (I get the failures you were seeing before the fix)
SallyAhaj has quit [Remote host closed the connection]
<palmer> robher: ah, crap, Linus merged it -- do you want me to send a part 3 still, or do you want to take my fix via your tree? either way is OK for me
<robher> palmer: please send to Linus.
<palmer> OK
<marex> broonie: dang ... that ChipOne ICN6211 is truly ....... not nice hardware
<marex> broonie: it needs 1 empty cycle between read register address and data, while write does not need this cycle
<marex> so like read byte is W:0xaddress W:0x00 R:<data byte from chip>
<marex> and write is like W:0xaddress W:0xdatabyte
<broonie> Ah, someone had a part like that recently (the same one possibly?). Check what went in this merge window, can’t remember the details offhand
<marex> broonie: I am on next all the time :)
<marex> broonie: I think I would need an upshift instead of downshift ... and only for read
<broonie> Yes. The asymmetry for read isn’t that surprising at high speeds, writes can be buffered but reads need to get the data ready for shifting out.
SallyAhaj has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
<marex> broonie: I might just implement driver specific regmap for this part in the end
<broonie> Sure, it can always be generalised later.