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
XV8 has joined #armlinux
<palmer>
ndesaulniers: the cooperation with userspace is interesting, IIUC Linux generally unconditionally fences (not quite sure what the switch kernel is doing for everything else)
Pali has quit [Ping timeout: 268 seconds]
apritzel_ has quit [Ping timeout: 240 seconds]
mripard has quit [Ping timeout: 272 seconds]
mripard has joined #armlinux
amitk has joined #armlinux
prabhakarlad has quit [Ping timeout: 256 seconds]
jlinton has quit [Ping timeout: 256 seconds]
Misotauros has quit [Ping timeout: 252 seconds]
iivanov has joined #armlinux
apritzel_ has joined #armlinux
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #armlinux
SallyAhaj has quit [Quit: Leaving]
apritzel_ has quit [Ping timeout: 240 seconds]
frieder has joined #armlinux
djrscally has joined #armlinux
tre has joined #armlinux
sszy has joined #armlinux
headless has joined #armlinux
Lucanis has quit [Ping timeout: 256 seconds]
Lucanis has joined #armlinux
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
nsaenz has joined #armlinux
kos_tom_ has quit [Ping timeout: 240 seconds]
luispm has joined #armlinux
XV8 has quit [Ping timeout: 240 seconds]
XV8 has joined #armlinux
XV8 has quit [Ping timeout: 240 seconds]
XV8 has joined #armlinux
Pali has joined #armlinux
nsaenz has quit [Quit: Leaving]
nsaenz has joined #armlinux
TheCoffeMaker has quit [Ping timeout: 240 seconds]
headless has quit [Quit: Konversation terminated!]
<maz>
the DSY SY in the Nintendo code is interesting. I wonder why they need something that strong (for Linux, ish is all we need)
apritzel_ has joined #armlinux
TheCoffeMaker has joined #armlinux
matthias_bgg has quit [Ping timeout: 252 seconds]
SallyAhaj has quit [Remote host closed the connection]
TheCoffeMaker has quit [Ping timeout: 256 seconds]
TheCoffeMaker has joined #armlinux
ravan_ has quit [Remote host closed the connection]
ravan_ has joined #armlinux
frieder has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #armlinux
prabhakarlad has joined #armlinux
<arnd>
geertu: I just came across drivers/staging/board again, which I had completely forgotten still exists . It looks like you last worked on this in 2015. Are the two board files still useful or have they been completely replaced by the dts files by now?
<geertu>
arnd: I'm still using the one for Armadillo, as there are no DT bindings for sh_mobile_lcdcfb. I tried to make it work with DT, but never succeeded.
<arnd>
ok, Isee
<geertu>
Note that there's also a shmob_drm driver that's supposed to drive the same hardware, but it also has no DT bindings :-(
<geertu>
And thus no users! Perhaps I should try to get that working, one day...
frieder has joined #armlinux
<geertu>
arnd: The kzm9d part can probably be removed (together with drivers/staging/emxx_udc). AFAIK it hsd no users, but its an old pet peeve of Magnus.
<geertu>
s/hsd/has/
<arnd>
this is the Pre-Renesas NEC SoC, right?
<geertu>
arnd: Yep. EMMA Mobile. I'm not so sure it's really pre-Renesas, but it's a continuation of the NEC EMMA line, which is BTW still powering my Sony Living-room TV ;)
<geertu>
(with MIPS inside, though)
<arnd>
it looks like the announcement of EV2 was a few weeks before the merger, but it only made it to the market afterwards
<arnd>
geertu: what I was actually looking at today was what platforms are left using HAVE_LEGACY_CLK after omap1 is convered, and whether there is a way out for them. Unfortunately I still don't see a way for arch/sh/
<arnd>
I was hoping that it only shares a small number of drivers with arm platforms, but I found at least 10 of them that are used on both sh and arm
<arnd>
so no easy way to make the sh clk code coexist with the generic version
<geertu>
arnd: I'm not aware of any legacy clock drivers shared by arm and sh?
<arnd>
geertu: not the clk drivers, just the consumers
<geertu>
arnd: OK, but these are all new-style consumers? or what am I missing?
<arnd>
I was hoping that we could s/clk_get/sh_clk_get/ etc in the sh specific consumer drivers
<geertu>
IC
Nact has joined #armlinux
<arnd>
if there were only a couple of drivers used on both, we could duplicate them, or have an ugly wrapper inside the driver, but for a dozen of them that is just too ugly
<geertu>
arnd: We can still do that in an #ifdef SUPERH section at the top of the driver?
TheCoffeMaker has quit [Ping timeout: 240 seconds]
<arnd>
geertu: possible, but still ugly. I think these are the ones that would need to be wrapped, but I may have missed some more: https://www.irccloud.com/pastebin/aJZHpZpX/
TheCoffeMaker has joined #armlinux
TheCoffeMaker has quit [Read error: Connection timed out]
TheCoffeMaker has joined #armlinux
<ajb-linaro>
what would be a good userspace visible test of using LPA2 addressing? Would looking at the address of /proc/self/map be reliable enough?
<arnd>
geertu: after some more inspection, I think it could be done if we just put trivial wrappers into include/linux/sh_clk.h and have the ten drivers include that
<geertu>
arnd: I think you missed the timers (tmu etc)
<geertu>
and sh_eth
<geertu>
spi-sh-sci, pwm-renesas-tpu
<arnd>
geertu: right, I only looked at CLKDEV_DEV_ID() definitions, not CLKDEV_ICK_ID, which are used for cmt/tmu/mtu2 timers
<arnd>
sh_eth doesn't seem to reference any clocks though
<arnd>
geertu: ok, it is referenced by the clk list, but I still don't see a device being created
<arnd>
and similarly for the spi_sh_sci, the hardware may be there, but no DT nodes
<arnd>
(and "depends on SUPERH")
<geertu>
arnd: sh-sci is basically using the SCI serial port in synchronous mode, so it can be used for SPI.
<geertu>
spi-sh-sci
haritz has quit [Ping timeout: 252 seconds]
<ajb-linaro>
milkylainen: is page size available from the fs?
* ajb-linaro
is trying to avoid writing custom test tools for his buildroot fs
TheCoffeMaker has joined #armlinux
<arnd>
ajb-linaro: getpagesize() is a glibc function, I don't know how you'd tell the physical addressing though
<arnd>
LPA2 should not have a visible effect on user space, in particular I don't think there is any correlation with the size of the virtual address space
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
<ajb-linaro>
arnd: ^ I see differences in the vaddr in the maps - but not sure if that is just a fluke...
TheCoffeMaker has joined #armlinux
<arnd>
ajb-linaro: it looks like you changed the virtual address space size between those runs, the top one looks like 42 bits (two level 64KB pages), while the bottom one looks like 39 bits (three level 4KB pages)
<arnd>
ajb-linaro: If you use 48 bits physical and 42 bits virtual addressing, it should look the same as 52/42
<ajb-linaro>
arnd: two different kernels (both run with -cpu max in TCG)
<ajb-linaro>
arnd: and I want to exercise LPA, LPA2 and LVA features
<ajb-linaro>
which were just merged to QEMU pstream
<arnd>
ajb-linaro: I think the LVA bits is easy to test from user space by using mmap(MAP_FIXED...) on an address above the 48 bit VA limit, but for testing the large physical addresses you need to actually have something in the hardware
<arnd>
e.g. by instantiating a virtio-mmio device at a high address from qemu and checking if the kernel can use it
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
<arnd>
It may have to be RAM rather than a device, not sure if there are any restrictions on what the high physical addresses are used for. Probably both work
<arnd>
ajb-linaro: actually you may want to test both high MMIO addresses and high RAM addresses
TheCoffeMaker has quit [Read error: Connection timed out]
TheCoffeMaker has joined #armlinux
haritz has joined #armlinux
haritz has quit [Changing host]
haritz has joined #armlinux
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
TheCoffeMaker has joined #armlinux
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
TheCoffeMaker has joined #armlinux
torez has joined #armlinux
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
TheCoffeMaker has joined #armlinux
TheCoffeMaker has quit [Read error: Connection timed out]
TheCoffeMaker has joined #armlinux
<gpiccoli>
I'm not sure if this is the proper place to ask...but any pointers of the right place would be already quite helpful!! So, I have questions about panel/LVDS and device-tree. Seems we have a single display 1920x1080, but it requires 2 lvds channels to accomodate the bandwidth and I'm having some trouble making that work heh
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
SallyAhaj has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
SallyAhaj has quit [Remote host closed the connection]
Nact has quit [Quit: Konversation terminated!]
TheCoffeMaker has joined #armlinux
monstr has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
<palmer>
maz: I saw that in Will's twitter, but I guess I forgot to send the reply. IIUC there's no full-system DMBs in the context switch path? I was wondering if these special calls were just for the full-system ones, as presumably there's a bunch of stuff that would blow up with no fence at all
Misotauros has joined #armlinux
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
Tokamak_ has quit [Ping timeout: 240 seconds]
Tokamak has joined #armlinux
SallyAhaj has quit [Read error: Connection reset by peer]
<maz>
palmer: it could well be that this HW requires system-wide synchronisation, and that userspace needs to be able to sync with it.
<palmer>
I was thinking it's that normal stuff (so maybe cpu-cpu stuff like locks) didn't need it, but more complicated stuff (like maybe memcpy-to-gpu) did
<palmer>
we've got a sort of similar spot where we're sticking IO orderings in a bunch of our fences, but they're not really necessary (because userspace isn't usuallly talking to a device)
<palmer>
if we could do some trick where we say "write to an IO device from userspace is a VDSO call", then we could detect scheduling inside the VDSO and only insert the big fences there
<palmer>
(sorry, that's all RISC-V stuff)
headless has joined #armlinux
TheCoffeMaker has joined #armlinux
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #armlinux
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
SallyAhaj has joined #armlinux
matthias_bgg has quit [Quit: Leaving]
mag has quit [Remote host closed the connection]
matthias_bgg has joined #armlinux
torez has quit [Remote host closed the connection]
mag has joined #armlinux
<ajb-linaro>
arnd: thanks for the ptrs
TheCoffeMaker has joined #armlinux
darkapex is now known as jai
jai is now known as darkapex
tre has quit [Remote host closed the connection]
<broonie>
arnd: Can't be very good emulation of an Arm platform if the PCI works! :P
<arnd>
broonie: interestingly, realview-eb actually has PCI support in qemu, but not in the kernel. I assume it works with /something/, but would at least need an updated dtb to use the PCI support with Linux
<arnd>
it would be nice to use that for armv5 testing because it also has 512MB of RAM
TheCoffeMaker has quit [Ping timeout: 250 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
TheCoffeMaker has joined #armlinux
<broonie>
arnd: Is there any great advantage over just the virt machine?
<arnd>
broonie: virt only works with cortex-a15 or newer
<arnd>
so you can't test multi_v5_defconfig or similar kernels
<broonie>
Ah, that's a good reason.
<broonie>
I didn't realise it affected the guests as well as the hosts.
Lucanis has quit [Quit: Leaving]
Lucanis has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has joined #armlinux
<arnd>
I tried to hack qemu to make it work recently, but make the timer work: the virt machine relies on the architected timer with cp15 instructions that don't work on older CPUs, and is tightly coupled to the CPU model itself