marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<alyssa>
uh.
<alyssa>
oh boy. the act of calling trace_device("/arm-io/jpeg0") causes a kernel panic. uh
<alyssa>
what on earth
<alyssa>
i do hope this is a PLBKAC
<alyssa>
okay I see some writes in boot, so the kernel driver is at least alive.
<alyssa>
hilarious
<alyssa>
that said, I'm not seeing any writes now that it's actually, you know, booted.
<alyssa>
so I dunno if this thing is wired up to userspace.
<alyssa>
(opening jpegs in preview doesn't do it :-p)
<alyssa>
ioreg says a few things; it requires MCU alignment, does not support DCT scaling, and does not support RST logging
<alyssa>
the whole iOS JPEG stack is here, though
<alyssa>
...i need to switch to !hypervisor to build a test app don't I. ugh.
<alyssa>
well, not a total loss. that gave me the boot procedure.
<alyssa>
this stuff was r/e'd on iOS, I wonder if the ABI is the same
<alyssa>
...just typed printk in userspace code
<alyssa>
the linux docs say I'm a real kernel hacker now.
yuyichao has joined #asahi
artemist0 has quit [Quit: artemist0]
artemist has joined #asahi
<alyssa>
ABI seems ot have changed. can I do this blindly? well...
<alyssa>
---it won't be blind 😉
<alyssa>
the kext is loaded with asserts
DragoonAethis has quit [Quit: hej-hej!]
<alyssa>
so I can just trial and error and it'll tell me what I did wrong
<chadmed>
it would be cool if the hardware was able to be generalised for other tasks involving similar math to jpeg compression
<sven>
would be fun to benchmark and see if software running on the M1 or the HW would be faster :D
<chadmed>
yeah its possible that its not even faster than the main application cores
<chadmed>
it might exist just to offload jpeg processing such that the main cores dont need to be woken up to process a jpeg (common task on a phone) and thus can either stay asleep and save power or do other things and speed up the overall UX
<sven>
i guess it was useful on the first iphones
<j_ey>
when im browsing memes, i need them to load *as quickly as possible*
<sven>
:>
<chadmed>
probably saves a ton of processor time when generating thumbnails for Photos.app even on newer iphones
<j_ey>
you dont think theyre cached?
<chadmed>
yeah they are but theyve got to be generated in the first place
<chadmed>
caches can be cleared too
<j_ey>
fair
<sorear>
on average over the life of your phone, how many still images per second have you taken?
<sorear>
I can't see how this makes any sense except for video as VinDuv first suggested
<chadmed>
well idk why dont cameras just have an AArch64 core to do image DSP then, why bother with fixed function hardware?
<sorear>
because cameras are expected to do video?
<chadmed>
its more energy efficient per operation is the answer. and given that the M1 is at the end of the day essentially just a big A14X then it will have the DNA of Apple's mobile devices in it
<chadmed>
yeah and phones are expected to compress JPEGs on the fly from raw image data too
<chadmed>
a hw block that can do this without waking up a bigger application core is more desirable in terms of energy use, which is important for mobile devices
<sven>
fwiw, i wouldn't be surprised at all if the JPEG hardware used to be faster/more efficient years ago but is easily beat by software running on the main core these days
<sven>
possibly even software running on the efficiency core
<chadmed>
yeah it will be an interesting comparison to do regardless
<sven>
yeah
<sven>
not very useful, but interesting :D
<chadmed>
dunno why theyd keep it in the soc if it wasnt helpful though. its not like they need to maintain backwards compatibility with ancient versions of ios and their corresponding apps
<chadmed>
its just wasted xsistors if it doesnt actually do anything useful
<sorear>
by the time you've done a UI interaction to wake up the phone, open the camera, taken a few dozen preview frames, autofocused, run the neural network noise reducer, etc, etc, etc, the final JPEG encode before storing the image is lost in the noise
<sorear>
also, the latency doesn't matter because you can do this asynchronously?
<dottedmag>
chadmed: Might as well be // TODO: remove later, if it does not take much space on the chip
<sven>
https://github.com/AsahiLinux/linux/commits/i2c/v1 i'll probably submit that tomorrow after all the built bots have picked it up. happy about anyone who already wants to catch my dumb mistakes (typos, etc.) in there
<j_ey>
sven: there's no issue including i2c-pasemi-core.o twice?, if both CONFIG_I2C_PASEMI and CONFIG_I2C_APPLE are set
<sven>
do you have a CPU that is both PowerPC and ARM64?
<j_ey>
sven: maybe the wii2 will have that
<sven>
on the same cpu? :-P
<sven>
other drivers do that same thing fwiw
<sven>
e.g. i2c-octeon-core.o
<j_ey>
PowerARMPC64
<sven>
(there's also this entire algos/ subfolder which i first thought would be the right place. but that one appears to be abandoned and newer drivers which also require the pci/platform split do it similar to what i've done there)
<j_ey>
sven: youre using platform_get_resource + devm_ioremap_resource instead of devm_platform_ioremap_resource
<sven>
good point. let me fix that
<j_ey>
sven: I hope pinctrl never fails to initialise in this driver, otherwise there's probably a null pointer deref :P
<sven>
huh, where?
<j_ey>
if (IS_ERR(data->pctrl)) { goto out_clk_disable;
<j_ey>
but clkref isnt initiliased yet
<sven>
uh. are you looking at an old version?
<j_ey>
um
<j_ey>
apparently
<sven>
:)
<j_ey>
btw, do you even need that? I think it should just do that already
<sven>
oh, does the core do that automatically?
<j_ey>
I believe so
<j_ey>
through pinctrl_bind_pins
<sven>
ah, nice
<sven>
let me drop that then
<j_ey>
sven: and what about reordering the last 2 commits? it's very minor, but the 2nd to last commit wont work without it, right?
<sven>
true
<sven>
though i guess now that commit is no-op for the pci variant :D
<j_ey>
that's fine I think
<maz>
I really like that there is still a trace of PASEMI in this machine. these guys were good.
<kettenis>
btw, is patchwork supposed to pick up patches automatically? or does this involve a manual step from the relevant maintainers?
<kettenis>
(my pcie DT v5 series doesn't seem to show up yet in the devicetree patchwork)
<maz>
kettenis: depends on the maintainer's flow. some use PW, some don't, and it depends whether PW is fed from a bot or manually.
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi
Glanzmann has joined #asahi
<Glanzmann>
alyssa: Do you have a kernel tree and branch that I can use to run a Debian Desktop on a mac mini?
<Glanzmann>
marcan: I wonder what kind of Internet connection you have in Tokyo? Do they already have fibre to the flat there?
<alyssa>
("How did you actually install to NVMe?" "I installed to USB, booted the USB, and rsync'ed / to /mnt")
<alyssa>
sven: 😅
nico_32_ is now known as nico_32
<Glanzmann>
alyssa: Thank you for the detailed instructions. I'll try to repdoduce it tomorrow and let you know how it went.
<alyssa>
Good luck 😅
<Glanzmann>
Thank you.
<alyssa>
I am eager to know if the DCP driver works for you
gabuscus_ has quit [Ping timeout: 480 seconds]
<Glanzmann>
alyssa: I see. Previously I hooked up the mac mini with a usb-c cable to my eizo monitor, should that work?
gabuscus has joined #asahi
<alyssa>
not yet
<alyssa>
HDMI should work
<alyssa>
doing video over the type-c ports requires a whole bunch of non-DCP work as well because USB is a nightmare
<alyssa>
sven: I should... probably look into that now shouldn't I :v
<sven>
probably
<sven>
my best guess is that the tipd chip will be able to detect you want to switch to DP-only for the usb-c port and tell the typec_mux to set everything up correctly
<sven>
dunno yet if the typec_mux is part of ATC PHY or just calls phy_set_mode or maybe does something else completely
<alyssa>
Grumble
<kettenis>
iBoot doesn't set this up if it detects DP on the type-c port?
<sven>
alyssa: yeah, it's gonna be complicated and probably requires us to understand how the entire typec mode switching (i.e. usb3, thunderbolt, etc.) is going to work before we can add this in a sane way :(
<Glanzmann>
alyssa: i see. will try hdmi then.
<alyssa>
kettenis: oh, that's possible. still need it for hotplug.
<marcan>
Glanzmann: yes, it was already wired for symmetric gigabit FTTH, I just had to sign up for the line and ISP
<sven>
i'll have to figure out how to get those message into my mail client. i do9n't think i've subscribed to linux-kernel or linux-nvme
<j_ey>
You can download a mbox.gz
<j_ey>
if your client supports that, in mutt it's `mutt -f t.mbox.gz`
<sven>
or if anyone else wants to reply: ANS2 is a arm64 coprocessor that emulates the NVMe MMIO and is likely used on the T2 as well. It uses the tag as index to an internal data structure and that index has only 8 bits. if you talk to ANS2 directly it'll just ignore the higher bits and only return the lower ones in the completion queue
<sven>
presumably, whatever is running on T2 doesn't ignore them but panics if the tag is > 0x100
<sven>
ah. that was actually painless to import
<sven>
guess i can already reply right now then :D