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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
DarkShadow44 has quit [Read error: Connection reset by peer]
niv has joined #asahi
niv has quit [Client Quit]
niv has joined #asahi
niv has quit [Client Quit]
niv has joined #asahi
niv has quit [Client Quit]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
jeffmiw has joined #asahi
niv has joined #asahi
niv has quit [Read error: Connection reset by peer]
jeffmiw has quit [Ping timeout: 265 seconds]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
VinDuv has quit [Quit: Leaving.]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
DarkShadow44 has joined #asahi
DarkShadow44 has quit [Client Quit]
DarkShadow44 has joined #asahi
niv has joined #asahi
Necrosporus has quit [Killed (card.freenode.net (Nickname regained by services))]
Necrosporus has joined #asahi
Necrosporus has quit [Ping timeout: 240 seconds]
Necrosporus has joined #asahi
Empus has joined #asahi
Empus has quit [Changing host]
Necrosporus has quit [Ping timeout: 265 seconds]
maor26 has joined #asahi
vimal has joined #asahi
Bublik has quit [Ping timeout: 268 seconds]
Bublik has joined #asahi
Necrosporus has joined #asahi
<sven>
okay, so there are gated clocks and clocks with a configurable frequency probably.
<sven>
the gated clocks seems to have some dependencies as well (e.g. UART0 seems to depend on UART_P and SIO)
<sven>
and i think uart can be switched to UART_N possibly but testing that is a little bit tricky
<sven>
the frequency clocks are defined in the "arm-io" ADT node but i can't figure out the clock-ids -> clock register mapping and i'm also too scared to flip bits in those registers
Necrosporus has quit [Killed (verne.freenode.net (Nickname regained by services))]
Necrosporus has joined #asahi
<sven>
oh, and there some PLLs. so i guess the PLLs generate some base frequencies and the freq clocks can select (or are hardwired) to one of those and allow that base freq to be divided down.
maor26 has quit [Ping timeout: 265 seconds]
<marcan>
I think the UART has at least two clocks (the current driver patch does not attempt to support that; we can start to experiment now that we have non-UART channels)
<sven>
yeah, there are two clock-ids in the ADT. i think they are gated with UART_P and UART_N
<sven>
and additionally it probably needs UART0 enabled
bngs[m] has quit [Quit: Idle for 30+ days]
AONeiLL[m] has quit [Quit: Idle for 30+ days]
bisko_ has joined #asahi
bisko has quit [Ping timeout: 240 seconds]
<marcan>
yes, AIUI nominally the UART peripheral has one core clock and N baud clocks
<marcan>
though presumably one of the baud clock options could be shared with the core clock
<sven>
so if the ADT is to be trusted there is one gating clock (UART0) and two clock-ids that i can't map to anything yet. but i believe these are UART_N and UART_P which could be two baud clocks
<sven>
i'll have to some experiments
<sven>
(and all this only started anyway because i was trying to figure out the i2c clock...)
<kettenis1>
correllium only has gating clocks for i2c
<sven>
i'm not sure they have added all clocks fwiw
<sven>
i have i2c working with the pasemi driver. i'd just like to see if i can find the clock that determines the frequency as well
<kettenis1>
sure, but it indicates the other clocks aren't important
<sven>
yeah, agreed
<sven>
this is more me being curious than doing something that's directly useful ;)
<kettenis1>
correllium has some pinmuxing for the i2c pins
<sven>
that's not required
<sven>
or, well, at least iboot leaves those pins in the correct state
<kettenis1>
yeah, that makes sense
<sven>
i'll need some gpio controller for the interrupt though
<sven>
but i got distracted by the clocks :-)
<sven>
https://github.com/svenpeter42/linux/commits/i2c-wip that's the current i2c stuff i have. still needs a lot of work though, like e.g. the device tree bindings for which i'd like to figure out the clocks
maor26 has joined #asahi
maor has joined #asahi
<kettenis1>
presumably you'd want to set the divisor based on a clock-frequency property
maor26 has quit [Ping timeout: 246 seconds]
<sven>
yeah
<sven>
ideally get the frequency of some parent clock and then calculate the divisor based on that
<kettenis1>
that suggests it is possible to bring the i2x signals out
<kettenis1>
i2c even
<kettenis1>
so with the right tools you might be able to actually measure the clock
<sven>
Device addresses seen (unshifted): 0x38, 0x3f
<kettenis1>
the bus clock that is
<sven>
those are the addresses of the ti usbc chips on that bus
<kettenis1>
that suggests it is the same bus then
<sven>
sounds like that, yes
<kettenis1>
it will be hard to figure out though what the real input clock is to the block
<kettenis1>
and in the end it won't really matter of course
<sven>
i suspect the clock-ids in the ADT refers to it. i just don't what *exactly* that ids maps to. but maybe that's not even required. we could just have a dummy fixed-frequency clock for each of these ids
<kettenis1>
an "effective" model of the hardware is good enough
<sven>
yeah
<sven>
i don't want to touch clock registers except for the gating ones anyway because i might actually be able to break the hardware that way
<marcan>
I'd be surprised if you could bork something permanently by touching clocks
<marcan>
but I'd be happy to do the riskier bits :)
<marcan>
and yes, I was planning on looking at those i2c pins to measure the clock and other i2c behavior
<marcan>
since i need to port over that pasemi driver
<marcan>
anyway, enough distractions, let me do one final change to AIC and push v4 out already now
<marcan>
ffs it's been one thing after the other the past few weeks, personal things, then stallman...
<sven>
i already have that pasemi one kinda working fwiw
<marcan>
just mostly as-is?
<sven>
pretty much
<marcan>
figured
<marcan>
I have the pasemi doc so I should be able to add IRQ support based on that
<sven>
just had to add a platform_device frontend on top of the current pci frontend
<sven>
and the one in the m1 needs a mystery bit set in the CTL register for transactions to work
<sven>
but otherwise it's just the same thing
<marcan>
what bit?
<arnd>
sven, marcan: if we can get consensus on the binding for the i2c port, this might be something to include in the initial dt
<sven>
0x800 in REG_CTL
<marcan>
arnd: if the existing driver works as-is, and we just need bog standard stuff, then we can definitely get this in after the initial series
<marcan>
(in the same merge window)
<arnd>
right, that's what I meant
<sven>
it did need a little bit of refactoring to split the PCI parts out fwiw
<marcan>
yeah, as expected
<sven>
if we trust the ADT we can also just use two dummy clocks like the UART for now
<arnd>
doesn't have to be in the v4 series, but we may have enough time to get it into the pull request that I will send to torvalds for v5.13
<marcan>
sven: 26:16 in CTL is a counter
<marcan>
maximum slave size write
<marcan>
"MSW"
<marcan>
that would need to be 1 to receive single bytes from the target
<arnd>
sven: IIRC ojn said he intentionally left out irq support when he wrote that driver originally. You could ask him about that when he shows up on #armlinux the next time
<marcan>
larger for larger reads
<sven>
huh, interesting. i just stole the value that was pre-configured by iboot
<marcan>
(assuming this is the same as the pasemi one)
<marcan>
arnd: I already emailed him about this
<arnd>
ok
<marcan>
he can test once we have the improvements
<sven>
i'm not sure we need irq support for the i2c. it would just be nice to have
<marcan>
so we should be good
<marcan>
well, we definitely want that
<sven>
but that typec ti chip needs and irq and it gets that one from the gpio controller
<marcan>
otherwise it turns into a crappy blocking game
<sven>
fair enough
<marcan>
but it's not required to *work* of course
<marcan>
just to not suck :-)
<sven>
yeah, pretty much :)
<sven>
but at least the ti chip doesn't have much traffic
<marcan>
yeah
<marcan>
so the original PCI so there's no DT binding, right?
<sven>
nope
<marcan>
but the DT bindings should be 100% bog standard i2c stuff anyway
<marcan>
and PCI means the IRQ stuff is standard
<marcan>
so this should all be extremely simple
<sven>
yeah, pretty much
<kettenis1>
i'd say you only need to ducument "reg" and "compatible"
<sven>
so the i2c needs one clock gate and probably one clock for the base frequency
<marcan>
kettenis1: exactly
<marcan>
and interrupts
<marcan>
well, and clock and maybe power
<marcan>
but again, these are all standards things every i2c controller on every soc pretty much has
<sven>
yeah
<sven>
i'll look into cleaning up what i have for the pasemi one so far and c&p some simple i2c dt binding then
<sven>
i guess it's fine to already have the interrupt in the binding but just not use it in the driver for now, isn't it?
<kettenis1>
I'd say so
<arnd>
ah, the driver is so old we didn't document the bindings back then
<arnd>
nevermind, I missed that this is a pci_driver in the original version
<arnd>
agreed on documenting the interrupt
<marcan>
I bet the binding can be reduced to picking an existing simple i2c one and s//ing the name
<marcan>
there have to be a good dozen or so ~identical ones along these lines
<arnd>
Not sure what the current method is for having multiple i2c drivers with the same i2c_algorithm. I'd probably start out having one module that exports it as i2c_pasemi_algorithm, and then duplicate the probe() function into one module for pci and platform each.
<arnd>
Traditionally, the algorithm would be in drivers/i2c/algos/, with an abstract probe function, but this is probably more work than necessary
<arnd>
the other way would be to have everything in one file, with some #ifdefs to deal with the possible combinations of platform and pci support, but that seems ugly
<marcan>
yeah, splitting it into separate modules seems saner
<arnd>
out of the three remaining i2c algorithms that remain in drivers/i2c/algos, only the bitbang version is actually used by more than two drivers, the other two each have an ISA (!) frontend and a platform front-end
<sven>
right now i just have it one file but i can easily split that
Calchan has quit [Ping timeout: 240 seconds]
Calchan has joined #asahi
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
TheLink has quit [Quit: Blubb]
choozy has joined #asahi
TheLink has joined #asahi
choozy has quit [Ping timeout: 245 seconds]
choozy has joined #asahi
frode_0xa has joined #asahi
frode_0xa has quit [Client Quit]
frode_0xa has joined #asahi
frode_0xa has quit [Client Quit]
frode_0xa has joined #asahi
frode_0xa has quit [Client Quit]
frode_0xa has joined #asahi
frode_0xa has quit [Client Quit]
frode_0xa has joined #asahi
odmir has joined #asahi
odmir has quit [Ping timeout: 250 seconds]
Behemoth has quit [Quit: Quit]
Behemoth has joined #asahi
Behemoth has quit [Client Quit]
Behemoth has joined #asahi
choozy has quit [Ping timeout: 245 seconds]
bisko has joined #asahi
bisko_ has quit [Ping timeout: 268 seconds]
scooby2_ is now known as scooby2
scooby2 has quit [Changing host]
scooby2 has joined #asahi
arcsor5 has joined #asahi
choozy has joined #asahi
ephe_meral has quit [Ping timeout: 240 seconds]
ephe_meral has joined #asahi
odmir has joined #asahi
arcsor5 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]