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
Lucanis0 has joined #armlinux
Lucanis0 has quit [Changing host]
Lucanis0 has joined #armlinux
Lucanis has quit [Ping timeout: 240 seconds]
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak has joined #armlinux
Tokamak_ has joined #armlinux
Tokamak has quit [Ping timeout: 246 seconds]
Tokamak has joined #armlinux
Tokamak_ has quit [Ping timeout: 244 seconds]
Tokamak has quit [Ping timeout: 246 seconds]
Tokamak has joined #armlinux
Tokamak has quit [Ping timeout: 244 seconds]
Tokamak_ has joined #armlinux
Tokamak_ has quit [Read error: Connection reset by peer]
Tokamak has joined #armlinux
amitk has quit [Ping timeout: 240 seconds]
wens has quit [Ping timeout: 256 seconds]
wens has joined #armlinux
amitk has joined #armlinux
jn has quit [Remote host closed the connection]
jn has joined #armlinux
jn has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 240 seconds]
<Xogium> what could enable a heartbeat led in linux despite the default state being set to off in the device tree ? Any way to disable it ?
rvalue has quit [Ping timeout: 244 seconds]
djrscally has joined #armlinux
cleger has joined #armlinux
<sicelo> udev rule maybe?
rvalue has joined #armlinux
<Xogium> hmmm maybe. I really don't know. It's also very fun to try and disable it when you're blind :D
<jn> it might also be due to any userspace that writes into /sys/class/leds/XX/trigger
<Xogium> erk.. I see
<Xogium> well.. maybe I misinterpret the dt node
<Xogium> linux,default-trigger = "heartbeat";
<Xogium> default-state = "off";
<jn> ah, you got a default trigger there, i suspect that makes the default state irrelevant
* Xogium blinks
<Xogium> mmmh weird
<Xogium> damn that's.. confusing
<jn> for other trigger it might still be relevant
<Xogium> so huh I should set it to none instead ?
<jn> but the heartbeat trigger immediately starts beating
luispm has joined #armlinux
<Xogium> the only way I found was to manually set to none in a service file when the system boot with systemd
<Xogium> but I was kinda hoping for a better way
<jn> yes, if you don't want the heartbeat trigger active at boot, don't set it in the DT
<Xogium> so... just remove the trigger line and set default to off ?
<jn> (set to "none", or remove the property)
<Xogium> ah
<Xogium> good
<Xogium> was st doing it
<jn> that sould do it
<Xogium> not me
monstr has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
<Xogium> now need to make a button behave to set brightness of the touchscreen's backlight between 0 and 150... there's any way to do that in a device tree ?
<Xogium> or do I need to do that in userspace ?
<Xogium> I don't user any desktop, just typical drm/framebuffer with one program launched on it
Pali has joined #armlinux
<jn> i don't think this is implemented in the kernel
<jn> you can of course describe a button in DT (via gpio-keys), but then (i think) you'll need a userspace program that takes botton inputs and sets the backlight brightness in response
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #armlinux
<Xogium> hmm
<Xogium> so just make a button but with no keycode or however it is called on the dt side ?
sszy has joined #armlinux
<jn> make a button with a keycode
<jn> respond to the keycode in userspace
<geertu> Xogium: include/dt-bindings/input/linux-event-codes.h has several KEY_BRIGHTNESS* key types
<geertu> Depending on your userspace, it may already work out-of-the-box
<Xogium> hmm
<Xogium> thanks :) I'll check them
<geertu> E.g. after marking one of the keys on my board with "linux,code = <KEY_POWER>", the Debian nfsroot userspace I'm using started treating that key as a soft power-down button.
<geertu> (I noticed because I pressed it accidentally, and the system shut down ;-)
<Xogium> oh what fun
<Xogium> I have this with a pmic over here
<Xogium> but linux watches over that button
<Xogium> Watching system buttons on /dev/input/event0 (pmic_onkey)
<Xogium> I think udev is the one handling that
headless has joined #armlinux
<Xogium> this is kinda confusing the buttons on the board can be both buttons and leds
matthias_bgg has joined #armlinux
tre has joined #armlinux
marex has joined #armlinux
scosu[m] has quit [Quit: You have been kicked for being idle]
apritzel has joined #armlinux
<javierm> geertu: that's also how I implemented the gamepad for the retro console I made with my kids, retroarch was able to pick the buttons without any changes
<javierm> the gpio-keys driver is quite useful
sudeepholla_ has quit [Remote host closed the connection]
sudeepholla_ has joined #armlinux
prabhakarlad has joined #armlinux
sicelo has quit [Quit: Bye!]
sicelo has joined #armlinux
sicelo has joined #armlinux
sicelo has quit [Changing host]
Amit_T has joined #armlinux
headless has quit [Quit: Konversation terminated!]
<hanetzer> I may do the infra-red on this next :P
<hanetzer> neat
<j`ey> javierm: why blacklist simpledrm?
sicelo has quit [Quit: Bye!]
<javierm> j`ey: on the rpi4 for some reasons the firmware was providing a simple-framebuffer DTB node even when no HDMI monitor was plugged
<javierm> maybe was a bug in the uboot version shipped in Fedora 36, didn't investigate that much
<j`ey> javierm: but what was the problem with that?
sicelo has joined #armlinux
sicelo has joined #armlinux
sicelo has quit [Changing host]
<javierm> j`ey: that retroarch tried to run against the /dev/fb0 emulated by the simpledrm driver rather than the one for the st7735r drm driver for the spi TFT panel
<j`ey> javierm: ah
sicelo has quit [Client Quit]
sicelo has joined #armlinux
sicelo has quit [Changing host]
sicelo has joined #armlinux
roxell_ has quit []
roxell_ has joined #armlinux
roxell_ is now known as roxell
sicelo has quit [Quit: Bye!]
sicelo has joined #armlinux
sicelo has joined #armlinux
<Xogium> jn: do you happen to know if there's a way I could send a keycode to linux over ssh or something, so I can test if sending that keycode via a button would work ?
<Xogium> I was mostly considering the 0x1af keycode which should toggle the lcd on and off... This should work seeing its a dsi lcd
<hanetzer> Xogium: uinput mayhaps.
<Xogium> uinput... Huh, y'know that's a splandid idea
<jn> Xogium: evtest
<Xogium> hmmm but evtest would only work with a configured button, wouldn't it ?
<jn> ah, i misread
<jn> yes, evtest prints incoming input events, it doesn't generate new input events
<Xogium> I would like to know if that would work before I mess about in the dt
* hanetzer has picked up a decent amount of odds and ends knowledge over time
<Xogium> ;)
<hanetzer> maybe if I'm lucky I can con hisi into giving me a devkit if I put in a lotta code for this :P
<Xogium> hehe
<Xogium> which dev kit ?
<hanetzer> well, they had a *.brd file in the sdk, which has the soc (hi3521a). Right now I'm developing against consumer hw
<Xogium> oh riiight
<Xogium> I forgot you were the one dealing with that SoC
<Xogium> :D
<hanetzer> yee. I'm also gonna be fiddling with hi3531a and hi3535
<hanetzer> (very similar)
<Xogium> is it fun, at least ?
<hanetzer> the former one, the board I have has two of the socs on it in a master/slave relationship
<hanetzer> for certain definitions of fun,, sure :P
<hanetzer> the grind kinda sucks, but when you have a 'breakthru' of sorts its a nice feeling.
<Xogium> ;)
<Xogium> yep I know that feeling
<hanetzer> now that I have persistent storage via sata I think some parts will work better. needa get ethernet up and running too
<hanetzer> sata was the phi-hix5hd2-sata.c driver, needed some parameter tweaking for my soc. I'm pretty sure the hix5hd2_gmac.c driver can be coerced into working as well, its pretty similar.
<hanetzer> as in, most of the register definitions appear to be 'the same'
<Xogium> fancy
<Xogium> this is the SoC you're trying to mainline right ?
<hanetzer> yee. booting some 5.19-rc on it atm
<Xogium> cool :O
<hanetzer> yee. for some reason the flash controller can't read the high bits of each half-byte
<hanetzer> I'll have to prolly wire in some tracepoints and see what its doing tbh
<hanetzer> but yeah. I'm hoping to do something akin to openwrt for this class of devices. too many insecure security devices out there lol
<jn> hanetzer: what kind of flash and how are the data bits connected?
<jn> my first guess would be that the pinmux for the high data lines isn't correct
<Xogium> too many insecure security devices -- indeed
<jn> i don't even call these things "security" devices
<jn> it is surveillance in function
<hanetzer> the S in IoT stands for security.
<jn> security in purpose perhaps, but bah
<hanetzer> jn: I thought that too, but it seems to be correct. I'll double check it against the vendor kernel tho
<Xogium> mhm I agree
<hanetzer> I wish there was a half-decent mechanism for printk'ing register bit definitions and values lol
ywnkmn has joined #armlinux
<broonie> hanetzer: regmap has a field abstraction which some people use.
<hanetzer> orly.
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
sicelo has quit [Quit: Bye!]
sicelo has joined #armlinux
sicelo has joined #armlinux
sicelo has quit [Changing host]
<hanetzer> broonie: yo, thanks for pointing out regmaps to me. I think it can actually solve one issue I had with the hypothetical use of the hix5hd2_gmac driver
<broonie> np
<hanetzer> basically, in the upstream one, they use two reg fields in the dtsi. one is 'all the io space', and the second is a specific 0x4 chunka it. the latter has various control and status regs used by it; problem is, in mine, that reg is broke into two regs
<broonie> That's pretty much exactly the case people made regmap_field for.
<hanetzer> yerp
<hanetzer> jn: oh, and its a plain spi flash, some macronix chip
<jn> any multi-pin or DDR mode going on?
<jn> like QSPI
<hanetzer> yeh, iirc its qspi
<jn> so, if the bitmask 0xcc is dead, that sort of does seem like the upper half of the quad-SPI data lines is dead, so only dual-SPI is working. if it's 0xee, it's even more plausible, only IO0 (aka. DI) works
<hanetzer> nah, its 0x88 that's dead
<jn> hm, strange
<jn> may i see your devicetree?
<hanetzer> Xogium: tho, I'd like to have a hix5hd2 dev board, since I'm bodging a lot of its drivers :P
<hanetzer> jn: sure, sec.
krzk_ is now known as krzk
krzk is now known as Guest6582
<jn> ah, that's only the dtsi, i think
Guest6582 is now known as krzk
<hanetzer> ah. sec.
<jn> hmm, no pinctrl settings on hi_sfc. and apparently SPI mode selection works as follows: the flash chip and the SPI controller driver announce all supported modes, and the spi-nor driver core selects the highest mode supported by both sides
<jn> so, as far as i understand it, there's no way to disable QSPI in DT
<hanetzer> ah, I have pinctrl'd that before, didn't seem to work out at the time.
<jn> AFAIUI, SFC_HOLD_IO3 should be the misconfigured pin
* hanetzer notes for later
bps has quit [Read error: Connection reset by peer]
<hanetzer> broonie: https://lore.kernel.org/all/37ac958a-2196-349d-6af9-995067f1bdb8@gmail.com/T/#re65a9f7c6d33758f74867cda6cd87838b34f4d33 if you see the reg layout here, basically phy_link_{status,speed,mode} are in a separate 32bit block :P
<broonie> smells a bit like a syscon, though it may not actually be shared.
<jn> hanetzer: hm, based on the hi3520 datasheet, i'm not so sure about my hypothesis anymore. SFC_HOLD_IO3 doesn't appear to be multiplexed, only the drive strength can be configured
<hanetzer> well, to be fair mine differs from yours a bit. I'll gander at it.
<hanetzer> yeah, not muxed on mine as well.
<hanetzer> but yeh. now that i have persistent storage it won't be too hard to run tests with the vendor kernel and store the results for use with the mainline one, and so on.
<hanetzer> broonie: see, I'm not sure. in the hisi-hix5hd2.dtsi, the second reg lies within the first reg. on mine, its in an entirely different IP block
<hanetzer> but as mentioned, almost the same bit definitions,, and the differnent bits are just one more register down the list
<broonie> The distinguishing thing with a syscon is that it's top level SoC glue shared with a bunch of devices rather than something on the side/part of a device that isn't shared.
<hanetzer> like synopsis stuff?
<jn> synopsis doesn't have any significant relation to syscons
<hanetzer> I mean, they tend to have 'core' driver parts and soc glue
<hanetzer> the latter being syscons?
<jn> yea
<jn> well, ok, i might be misunderstanding you
<broonie> No, like I say the important part with a system controller is that it's shared between multiple blocks - things like top level power and clock managemnt for a soC.
prabhakarlad has quit [Quit: Client closed]
<hanetzer> ahhh. well, for *their* gmac, its only in the gmac. but mine is more syscon-y
<jn> e.g.: you have a bunch of peripherals, each with their own register block of standard layout. but then there are some SoC-specific configuration bits. to leave the register interfaces of the peripherals unchanges, you put these bits *somewhere* else, e.g. a central register window with all the miscellaneous bits of the SoC. that register window is a good example of a syscon
<hanetzer> gotcha.
<hanetzer> yeah, that's what I figured, but sometimes getting across what ya mean is trcky
djrscally has quit [Ping timeout: 240 seconds]
tre has quit [Remote host closed the connection]
prabhakarlad has joined #armlinux
cleger has quit [Quit: Leaving]
<hanetzer> ugh. I just wish vendors weren't such dicks about it.
<hanetzer> like bruh, just give us the code, give us the datasheets. the nerds will put together something far better than your guys, for free even.
<bencoh> :)
<hanetzer> re: regmaps and such. does that add any particular overhead, to compose a driver entirely of that, as opposed to defines and readl/writel?
<broonie> There's a lot more framework code and locking with regmap, though that can get relatively low - it's definitely not a single instruction like readl/writel would be.
<hanetzer> fair enough.
<broonie> It's generally fine for things that aren't in the data path though, but the core use case is more things like I2C and SPI where the bus is sufficiently slow that CPU time is approximately free.
<bencoh> I don't think I'd use regmaps for internal registers
<broonie> eg, the MMIO stuff was originally added for Tegra audio controllers which DMA all the actual data since being able to reuse the cache code greatly simplified the driver.
<bencoh> (to me it sounds more like a one-way ticket to regcache debugging hell, for no added value)
<broonie> Well, the tracepoints and whatnot can be super helpful in debugging... The cache code is widely enough used that I'd not be super worried about it.
matthias_bgg has quit [Quit: Leaving]
<hanetzer> does regmap come with free tracepoints?
* hanetzer wired in tracepoints into phy-hix5hd2-sata.c while debugging it for my soc
<broonie> Yes, it's got tracepoints in the core.
<broonie> and a debugfs interface.
headless has joined #armlinux
apritzel has quit [Ping timeout: 246 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
djrscally has joined #armlinux
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #armlinux
nsaenz has quit [Quit: Leaving]
iivanov has quit [Quit: Leaving...]
apritzel has joined #armlinux
Amit_T has quit [Quit: Leaving]
headless has quit [Ping timeout: 246 seconds]
headless has joined #armlinux
cbeznea has quit [Quit: Leaving.]
headless has quit [Quit: Konversation terminated!]
djrscally has quit [Ping timeout: 258 seconds]
amitk has quit [Ping timeout: 276 seconds]
Pali has quit [Ping timeout: 272 seconds]