gnarface has quit [Remote host closed the connection]
tuxd3v has quit [Ping timeout: 480 seconds]
gnarface has joined #linux-sunxi
<smaeul>
for clock-names, are we preferring "bus" or "apb"/"ahb" now? I seem to remember it is "bus", but I want to make sure before giving bad patch suggestions
pmp-p has quit [Ping timeout: 480 seconds]
pmp-p has joined #linux-sunxi
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #linux-sunxi
Danct12 has joined #linux-sunxi
<jernej>
smaeul: it's bus/mod now
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
cmeerw has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #linux-sunxi
ftg has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
prefixcactus has joined #linux-sunxi
apritzel has joined #linux-sunxi
tnovotny has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
<apritzel>
mripard: wens: so what are the chances of some H616 support still making it into 5.14?
<apritzel>
with probably removing the RTC for now?
<mripard>
apritzel: the PR have been sent last week
<mripard>
so it won't make it for 5.14
<apritzel>
bummer!
<apritzel>
and there is no chance for a 2nd PR?
<mripard>
Linus wants every commit in a PR to be in next for two weeks, so arm-soc has the same cut-out
<mripard>
for fixes or small stuff, it can be negociated, but not for a series that large
<arnd>
mripard: I would probably still consider merging it, since the changes in the series (I just had a look after you mentioning "arm-soc" summoned me ;-)) are either trivial or new files with no regression potential
<arnd>
but it's up to you (and olofj, since he's dealing with the 5.14 merges)
<arnd>
I guess the phy driver changes aren't quite trivial, which may also be a show-stopper
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 480 seconds]
<mripard>
Lee also hasn't reviewed the MFD parts yet
<mripard>
davem didn't either for the net part (even though that's not really a huge concern)
<mripard>
I'd really prefer to target 5.15 for this
<arnd>
makes sense
<arnd>
I was only looking at the arch/arm/ changes, which should be uncontroversial in this case, but depend on the drivers also getting merged
<apritzel>
yeah, thanks to AW we need small changes in every subsystem when a new SoC appears ...
<apritzel>
I am just trying to get this off my back
hlauer has quit [Ping timeout: 480 seconds]
cmeerw has joined #linux-sunxi
<apritzel>
mripard: btw: Lee actually took the AXP patch already (in v6), and it's in -next
<apritzel>
and we don't need the net part at the moment, that's just for the second EMAC, for which we require AC200 support first anyway
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
martinayotte has joined #linux-sunxi
jernej_ has quit []
jernej has joined #linux-sunxi
<mripard>
apritzel: generally speaking, it's easier to get series like this merged if they are split
<mripard>
some parts could have been merged way earlier but didn't because you were doing everything at once
<mripard>
the DTSI with the UART, SPI and MMC have been fairly stable for a while for example
<mripard>
but we never could merged it because it also had the USB bits that were controversial
<apritzel>
I know, that's why I dropped USB once (in v5, I believe)
<apritzel>
but USB is quite useful, especially for those TV boxes
<apritzel>
but yeah, originally I anticipated much less changes, so thought we can get some more peripherals supported on the first go
<mripard>
sure, I didn't say you should abandon USB support :)
<apritzel>
and splitting has the disadvantage of making the dependencies more complicated
<apritzel>
I could make a minimal v8: no USB, no RTC, no net, and the AXP patch being merged would reduce it to the .dtsi and .dts patches, I think
<apritzel>
which has little danger of regressions, I'd say
<apritzel>
but would allow the other parts (RTC, USB, HDMI, ...) to become independent from each other
Daanct12 has joined #linux-sunxi
<jernej>
apritzel: I played with 7 segment display on T95
<jernej>
fun fact, it's weird I2C protocol
Danct12 has quit [Ping timeout: 480 seconds]
<jernej>
1. no address per se - register address is effectively I2C address
<apritzel>
yeah, I found this as well
<apritzel>
I think the BSP bitbangs this?
<jernej>
2. it never acknowledges, even if it is successfull
<jernej>
yes
<apritzel>
and I found there is some framework that supports that chip/protocol
<jernej>
but i2c-gpio works just fine, once you start ignoring ACKs
<apritzel>
can you do that without hacks?
<jernej>
where? I couldn't find any 7 segment led framework, only several RFC series which were all turned down for various reasons
<apritzel>
jernej: did you play with this OpenVFD?
<jernej>
nope and I don't plan to
<apritzel>
Google turned that up when I searched for the chip
<apritzel>
it looks like userland?
<apritzel>
I haven't time to look into this, just made a note
<jernej>
there is some history with LE but it was ripped off from build system
<jernej>
no, it's both, kernel and userspace
<jernej>
kernel side is just driver with custom interface
<jernej>
anyway, it's good for documentation
<apritzel>
I see, I thought it would be bitbanging GPIOs, or using I2C (with some tweaks, maybe)
<jernej>
driver does bitbanging
<jernej>
but that seems redundant if kernel supports that
<apritzel>
you mean with i2c-gpio?
<jernej>
for example
<jernej>
but maybe it's better to reuse just i2c-algo-bit
<jernej>
afaik, i2c-gpio would mean to treat as normal i2c bus, which is not really
<apritzel>
yeah, I was wondering about that
<apritzel>
so I guess you can't tweak that from userland, for instance to ignore ACKs?
<jernej>
not sure, I plan to check that
<jernej>
if acks depend on userspace, it could be useful just to enable i2c-gpio and let userspace deal with actual device
<jernej>
I mean, if userspace can ignore acks
<apritzel>
I agree
<apritzel>
(as I was also looking for a 7 segment kernel framework, and came to the same conclusions as you)
<jernej>
but long term, if 7 seg. display interface ever become a thing, driver could be easily made, it's extremely simple device
<apritzel>
you mean like: echo 17:43 > /dev/7seg0 ?
<jernej>
for example
prefixcactus has quit [Ping timeout: 480 seconds]
<jernej>
but I think only numbers would be covered
<jernej>
not all displays have ":" and in my case, it's driven separately
<apritzel>
that's why the driver could sort that out (and drop it, if needed)
<jernej>
oh, there is I2C_M_IGNORE_NAK flag
<jernej>
which must be supported by the HW/driver, but in i2c-gpio case it is