System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
naoki has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
fleg has quit [Ping timeout: 260 seconds]
qschulz has quit [Remote host closed the connection]
fleg has joined #linux-rockchip
System_Error has quit [Ping timeout: 260 seconds]
qschulz has joined #linux-rockchip
System_Error has joined #linux-rockchip
hipboi has joined #linux-rockchip
amazingfate has joined #linux-rockchip
hipboi_ has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 248 seconds]
hipboi has quit [Read error: Connection reset by peer]
hipboi_ is now known as hipboi
ungeskriptet has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
hexdump0815 has quit [Ping timeout: 248 seconds]
hexdump0815 has joined #linux-rockchip
hipboi has quit [Quit: hipboi]
hipboi has joined #linux-rockchip
hipboi has quit [Client Quit]
<naoki>
mmind00: is "CONFIG_ROCKCHIP_SPI=y" required for u-boot for ROCK 5 ITX?
hipboi has joined #linux-rockchip
hipboi has quit [Client Quit]
hipboi has joined #linux-rockchip
franoosh has joined #linux-rockchip
franoosh has quit [Changing host]
franoosh has joined #linux-rockchip
franoosh has quit [Ping timeout: 252 seconds]
franoosh has joined #linux-rockchip
franoosh has quit [Changing host]
franoosh has joined #linux-rockchip
hipboi has quit [Quit: hipboi]
hipboi has joined #linux-rockchip
<naoki>
hmm, emmc(sdhci) related driver should be removed, but sdmmc related driver should not be removed...
<naoki>
I'll make v4 tomorrow
franoosh has quit [Remote host closed the connection]
franoosh has joined #linux-rockchip
ldevulder has joined #linux-rockchip
mps has quit [Ping timeout: 252 seconds]
<qschulz>
naoki: re: spi on rock 5 itx. The PMIC is on SPI, so if you want to be able to control stuff on the PMIC, we probably should have it, yes
<qschulz>
is there an issue with enabling SPI controller on that board?
<naoki>
qschulz: CONFIG_ROCKCHIP_SPI is for SPI NOR flash for older RK SoC
<qschulz>
naoki: pretty sure that isn't true as I had to fix that driver for RK806 PMIC support ;)
<naoki>
oh
<naoki>
sorry, I was confused
hipboi has quit [Quit: hipboi]
<qschulz>
naoki: there are actually different IPs now in Rockchip's SoCs
<qschulz>
the "typical" SPI controllers are using the old IP back from RK3066 according to the compatible string
<qschulz>
but there is also another kind of SPI controller called SFC which is a different IP and is used typically for SPI flashes as it can go much faster than that old IP (limited to 50MHz)
<naoki>
my question may be "why is CONFIG_ROCKCHIP_SPI=y not specified for (some RK3588 based board with SPI PMIC)"
<naoki>
I need to check my working branch first ;)
<diederik>
because that kernel module doesn't exist?
mps has joined #linux-rockchip
<diederik>
(at least in the upstream kernel)
<qschulz>
naoki: could be a simple oversight, maybe we should imply that one on CONFIG_ROCKCHIP_RK3588 level
<naoki>
I cannot remember but there is a board which uses I2C PMIC
tlwoerner has quit [Remote host closed the connection]
sL1pKn07 has quit [Ping timeout: 276 seconds]
sL1pKn07 has joined #linux-rockchip
lucaceresoli has joined #linux-rockchip
helene has joined #linux-rockchip
s1b1 has joined #linux-rockchip
warpme has joined #linux-rockchip
<sre>
qschulz: Support for the I2C version of RK806 got added in 6fc9bb82a3ef (6.12)
kilobyte_ch has joined #linux-rockchip
<qschulz>
sre: ah, so RK3576 boards use I2C :)
<qschulz>
wondering what made them have SPI on RK3588 and I2C on RK3576 :
<qschulz>
:)
<sre>
well usually all the board vendors copy the evaluation board design :)
<qschulz>
I know, why did Rockchip made a different design for RK3588, and then RK3576 is back to the old days
<qschulz>
in U-boot, it's possible that RK806 on I2C will just magically work without patches
<sre>
One difference is, that RK3588 needs more regulators than RK3576. The RK3588 boards either use two RK806 or one RK806 and a few extra I2C regulators.
indy_ is now known as indy
<sre>
But it might just have been an experiment from Rockchip.
<qschulz>
yeah but how does that make it better to use SPI over I2C :)
<qschulz>
(not a question for you :) )
<sre>
Usually with SPI you can use higher bus speed. Could be that they wanted to experiment with this for faster frequency scaling?
<sre>
Personally I was more amused by them having a rk8602 and an rk8603 with the only known difference being their I2C address.
<qschulz>
that's not that uncommon though?
<qschulz>
allows to have them both on the same i2c bus
<qschulz>
I guess they could have had a bootstrap pin instead?
<qschulz>
sre: seeing a lot of work on RK3576 in mainline Linux from you folks, not much sent for RK3576 by anyone in the community yet though
<qschulz>
quite surprised (well, priorities :) )
<sre>
For RK3588 they actually need three I2C regulators when only a single RK806 is used. Apparently they did not want to create an rk8604 and do use a second bus for the third I2C regulator.
<qschulz>
sre: interesting!
<sre>
I would have expected a bootstrap pin, which means they only need to produce one silicon version and can easily support 3 chip addresses (tied to ground, tied to vcc, and open)
<qschulz>
sre: I guess you could have some chicken and the egg problem though
<qschulz>
and "difficult" timings
<qschulz>
as you need power to pull the line high before you actually power the regulator
<qschulz>
on our designs we actually have 2x RK8602 and 1x RK8603, so necessarily two I2C busses... is there an RK8601 we missed maybe
<sre>
2x RK8602 and 1x RK8603 is the reference design when using a single RK806. I don't think there is an RK8601.
<qschulz>
oh they do exist, but different from rk8602/rk8603 according to Cristian
<qschulz>
RK8600/RK8601 are fully compatible with the FAN53555 regulators.
<qschulz>
naming stuff consistenly really is difficult for engineers, not only SW ones but HW ones as well it seem
<qschulz>
s
<sre>
regarding the timings for a bootstrap pin - the regulator needs power anyways to be functional. There should be some kind of brownout detection for the I2C side, which can be reused for sampling the bootstrap pin.
dsimic has quit [Ping timeout: 265 seconds]
dsimic has joined #linux-rockchip
erg__ has joined #linux-rockchip
erg_ has quit [Ping timeout: 272 seconds]
alpernebbi has quit [Ping timeout: 245 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dliviu has quit [Quit: Going away]
alpernebbi has joined #linux-rockchip
dliviu has joined #linux-rockchip
<Kwiboo>
qschulz: re rk3576 from anyone in the community, I do not think TRM for rk3576 is shared/leaked in "public" yet ?
<qschulz>
Kwiboo: which part of the TRM?
<qschulz>
Kwiboo: true, I was certain I had my hands on the part1 of the TRM
<Kwiboo>
qschulz: any part of TRM, I have only seen a datasheet for rk3576 and nothing else :-)
<tlwoerner>
if a board has more than 1 PWM, is it possible to sync the PWMs so their operation is linked?
<tlwoerner>
i'm looking at the rock-pi-s (rk3308) specifically
<tlwoerner>
(if that matters)
<qschulz>
tlwoerner: what are you trying to achieve here?
<qschulz>
Kwiboo: well, yes. Let's see how long it takes before stuff gets leaked ;)
<tlwoerner>
qschulz: i'm using 2 PWMs to drive the separate inputs of an H-bridge and would like to have the two PWMs sync'ed
<tlwoerner>
i.e. when one is 1 the other is 0 and vica versa
<sre>
FWIW we could start a little bit earlier with the RK3576, since we got one Sige5 board early. Upstreaming goes quickly because most IP is very similar to RK3588 :)
<qschulz>
sre: that's what I've been told yes :)
<qschulz>
hopefully that is true :)
<tlwoerner>
the hardware i'm using, thankfully, is smart enough to guard against destroying itself if both are 1 at the same time (by turning off) which causes occasional glitches that would be nice to avoid