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
kettenis has quit [Ping timeout: 260 seconds]
kettenis has joined #armlinux
bps2 has quit [Remote host closed the connection]
bps2 has joined #armlinux
bps2 has quit [Ping timeout: 256 seconds]
torez has quit [Quit: torez]
amitk has joined #armlinux
prabhakarlad has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
matthias_bgg has quit [Ping timeout: 246 seconds]
prabhakarlad has joined #armlinux
Peng_Fan has joined #armlinux
Misotauros has quit [Ping timeout: 252 seconds]
cbeznea has joined #armlinux
saip has joined #armlinux
frieder has joined #armlinux
macromorgan is now known as Guest8637
Guest8637 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
macromorgan has joined #armlinux
matthias_bgg has joined #armlinux
cleger has joined #armlinux
djrscally has joined #armlinux
monstr has joined #armlinux
luispm has joined #armlinux
sszy has joined #armlinux
nsaenz has joined #armlinux
headless has joined #armlinux
matthias_bgg has quit [Ping timeout: 246 seconds]
Pali has joined #armlinux
saip has quit [Ping timeout: 250 seconds]
matthias_bgg has joined #armlinux
Pali has quit [Ping timeout: 268 seconds]
bps2 has joined #armlinux
SallyAhaj has quit [Quit: SallyAhaj]
SallyAhaj has joined #armlinux
SallyAhaj has quit [Quit: SallyAhaj]
Turingtoast has joined #armlinux
headless has quit [Quit: Konversation terminated!]
SallyAhaj has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<broonie>
marex: If you're doing it inside the driver I'd expect reg_read()/reg_write() rather than implementing a bus.
<broonie>
(for the DSI one)
<broonie>
Though it looks like it supports block I/O which reg_read/write don't.
<broonie>
Alternatively just split the bus into a separate patch and put it in drivers/base/regmap? Doesn't look driver specific at all and people can always improve it later.
<javierm>
broonie: what if your device needs some special handling for writes, for instance I've a chip that uses a D/C (data/command) pin to indicate whether you are writing a command or data
<javierm>
broonie: I implemented as a regmap bus in the driver (to have a custom .write) but wondered too if was the correct approach
<marex>
broonie: you can pour more registers into it at one time from what I can tell
<javierm>
broonie: and the second is what marex said, could implement a custom .reg_write() but then woldn't be able to do bulk writes
<marex>
broonie: about that bus part -- see second half of the commit message -- that's why I didn't turn this into generic DSI regmap implementation
<marex>
broonie: there is that one extra byte in the DSI read implementation which specifies the amount of data to read
<broonie>
javierm: Use reg_read/reg_write - you can basically just write anything in there for them. Only does one register at a time though.
<javierm>
broonie: yeah I know but as mentioned I wanted to do bulk writes (since that way I could do a full display update with a sinle write)
* broonie
tries to remember why regmap_bus is in regmap.h....
<javierm>
broonie: it's useful for sure in case devices need special handling :)
<broonie>
It's sounding like it might be worth adding a block version of reg_read/reg_write.
<javierm>
like seems to be the case for marex and me
<marex>
broonie: isn't that what the regmap bus is for ?
<broonie>
The buses are supposed to live in drivers/base/regmap so people can share them, not be a per-client thing.
<javierm>
broonie: got it. Then probably for now will go with the .reg_write() even if it's worse perf wise and then once the driver lands figure out how to extend regmap to do bulk writes
<javierm>
or is OK to do a custom bus in this case and then cleanup later? I see that many drivers already do the same...
<broonie>
Meh, looks like we already have a bunch of custom regmap_bus implementations including some that look like they should be very generic :/
<javierm>
broonie: yeah...
<broonie>
Just go for it, let's worry about making things more generic later.
<javierm>
broonie: perfect, thanks
<broonie>
marex: ^^^
<marex>
broonie: well, what is the conclusion ? go with custom bus is OK , or , extend regmap with bulk read/write and then use that ?
<javierm>
marex: the former AFAIU
<javierm>
marex: and sorry for stealing broonie's attention but your question was quite relevant to me as well :)
<broonie>
yes
<marex>
broonie: in that case, can you please AB/RB the patch ?
<marex>
javierm: do you want to pick up the bulk read/write task ?
<javierm>
marex: sure, already looked at the regmap core and shouldn't be a lot of work
<marex>
javierm: I think it's pretty much going to copy the bus bulk read/write
<javierm>
marex: I wouldn't include in my series because patch-sets that touches many subsystems are always painful to land
<javierm>
marex: yup
<javierm>
but we can cleanup later once we have such a infrastructure in the regmap API
<broonie>
Can you bounce me a copy please?
<marex>
broonie: I CCed you on that patch when submitting it
<javierm>
broonie: sure, I was going to Cc you as well due the regmap usage but haven't posted the patches yet
<javierm>
broonie: another limitation that I noticed in the regmap API is that you can't have write only buses (this driver is for a OLED display and you just need to write, not read)
<javierm>
so I've a fake .read callback that doesn't do anything
<marex>
javierm: maybe implement a read which returns -EOPNOTSUPP ?
<broonie>
javierm: You can, there's a bunch of I2C devices with 7x9 format that we support.
<javierm>
broonie: I believe you can have only a .reg_write() but not a bus with only .write()
<javierm>
broonie: yes, easy to fix but again didn't want the series to span across different subsytems :)
<javierm>
will do with marex suggestion but add that too in my TODO for regmap enhancements
<javierm>
*will go
<broonie>
It shouldn't be too much of a hassle to get the core patch in hopefully?
<marex>
broonie: I think the whole point is to keep the regmap plumbing and driver feature separate, so the driver feature can go in, then regmap patch can go in in parallel, and then driver can be converted over to regmap patch
<marex>
broonie: thanks for the AB
<javierm>
broonie: no, but you will need to create an immutable branch for DRM folks to pull, etc. If you don't mind that hassle, then I can do properly from the start
<javierm>
another option is to hold this driver for a bit until all the regmap bits land and then wait for the next release to post
<broonie>
I don't mind that, I do that all the time for regmap/spi/regulator
<javierm>
broonie: Ok
<broonie>
Or like marex said do a conversion patch later to update the driver for the core change if the driver goes in first.
<javierm>
broonie: yes, I was already planning to do that
<javierm>
and maybe we could even cleanup the other drivers and move the bus API to drivers/base/regmap/internal.h like for example regulators do
<javierm>
if that's really meant only for drivers/base/regmap/regmap-*.c bus drivers
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<javierm>
better doing sooner rather than latter, since at least 2 more drivers will use that API soon :P
<broonie>
Yeah. Some of them do it for a bulk reg read/write which should be doable, there's some more complex ones though.
<javierm>
broonie: I see
<javierm>
broonie: but even in that case, maybe we could have a device specific bus in drivers/base/regmap/regmap-foo.c to stop the bleeding ?
<javierm>
and then figure out how the I2C/SPI/MMIO/etc could be extended to support the special cases
<broonie>
Well, it's partly just a taste thing (and keeping track of what people need) and that feels like it's too ugly.
<javierm>
right...
Jmabsd has joined #armlinux
<Jmabsd>
Hi all, just curious, does anyone have a HoneyComb/ClearFox LX2 (= NXP LX2160A SoC)? There is a particular operating system setup I wish to have validated if it works on the LX2. Also I can buy an LX2 second hand if anyone has one to sell.
<Jmabsd>
It's a mini-ITX ARM64 with 16 cores, 18MB cache, supports 64GB RAM, and has fast PCIe and ethernet. Quite high performance apparently.
<HdkR>
Has a bunch of information about installing various OSes
<Jmabsd>
Oh, re LX2, on #armbian the Discord bridge says: <IgorPec> you need some patches on top of generic arm kernel. we don't provide plug and play images but you can make image easily
<HdkR>
`Linux solidrun 5.4.3-00006-g0038ae610ef6 #9 SMP PREEMPT Thu May 21 12:08:27 IDT 2020 aarch64 aarch64 aarch64 GNU/Linux` Not sure, I'm running some dumb old thing
<broonie>
Some of that stuff is upstream now (the TRNG for example). The RMR spec got rejected upstream - the boards aren't really a good fit for ACPI. IIRC SolidRun decided to continue with ACPI and adopt a different more quirks based implementation.
pivi has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<kettenis>
broonie: yet some folks at arm and associated industry partners keep pushing ACPI in that space (SystemReady ES)
<tmlind>
argh, yet another v5.18-rc1 regression.. bisected down four so far :( this time 932d596378b0 ("serial: 8250: Return early in .start_tx() if there are no chars to send") missing rpm_put
<kettenis>
(I don't disagree that the hardware is a bad fit for ACPI)
<Xogium>
oh god, acpi on arm, yecch
<Jmabsd>
kettenis: Do you have a guess about whether OpenBSD works out of the box on the HoneyComb/ClearFog LX2=LX2160A?
<Jmabsd>
It appears patrick@ has it working, but good question if he has diff:s that did not upstream yet
<broonie>
kettenis: Right, there's a bit of tension with people trying to expand the set of hardware covered without thinking through the assumptions ACPI has :/
<broonie>
Xogium: It works great for the hardware designed for it.
<Jmabsd>
HdkR: Are you running a HoneyComb/ClearFog LX2?
<Xogium>
hmm I honestly don't know… I prefer device trees to acpi, frankly
<kettenis>
Jmabsd: As far as I know it still works out of the box
<kettenis>
but the onboard networking doesn't work for reasons related to the discussion above
<Jmabsd>
kettenis: Oh. Thanks for sharing. So PCIe works, otherwise he would not have reached AMDGPU. Should USB3 work?
<Jmabsd>
kettenis: Does OpenBSD have drivers for the networking, could a layman like me get networking going supposedly <import of question dropping, will end this question around here>
<kettenis>
really off-topic here; but yes usb3 should work and no there is no driver for the networking stuff and amdgpu is currently broken)
<kettenis>
maybe better to ask further questions on the #solidrun discord channel
<Jmabsd>
kettenis: Oh. Should AMDGPU be permanently broken or just a temporary glitch fixed soon - great will go to https://discord.gg/DU8zAPJH Discord as you suggest. Many thanks.
<kettenis>
I'm working on a fix
<Jmabsd>
Wow yey
<Jmabsd>
kettenis: last question here - without a GPU, the boot will be made to the serial console which has a dedicated USB port right, so then one can install OpenBSD from a USB memory stick onto an M.2 NVMe SSD - that works since PCIe works
<Jmabsd>
And then plug 10gbe ethernet into the PCIe. And it works. Later, get a PCIe switch card to have AMDGPU & 10gbe at the same time. Cool!
<Jmabsd>
*supported 10gbe e.g. some intel etc.
<kettenis>
correct
jlinton has joined #armlinux
darkapex has quit [Ping timeout: 268 seconds]
Jmabsd has quit [Quit: Leaving]
Tenkawa has joined #armlinux
Peng_Fan has quit [Quit: Connection closed for inactivity]
Misotauros has quit [Ping timeout: 240 seconds]
Turingtoast has joined #armlinux
guillaume_g has quit [Quit: Konversation terminated!]
frieder has quit [Remote host closed the connection]
gdd has quit [Ping timeout: 250 seconds]
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
headless has joined #armlinux
gdd has joined #armlinux
cleger has quit [Remote host closed the connection]