<mmind00_>
naobsd: try adding "fcs,suspend-voltage-selector = <1>;" in vdd_cpu and vdd_gpu ... firefly is scaling quite sucessfully to 1.6GHz with this
<naobsd>
mmind00_: good news!
<naobsd>
mmind00_: happy new year! :)
<mmind00_>
naobsd: to you and everybody else too :-)
<naobsd>
mmind00_: btw how can I know that value? it's possible to read from schematic? or just trial & error thing?
<mmind00_>
naobsd: the fan53555 (and thus the syr82x) have two sets of voltage setting-registers ... the system switches between the two by using the pmic_sleep pin (which gets triggered automatically on suspend)
<mmind00_>
naobsd: that option declares which one is to be used on suspend (and the other at runtime) ... without this option it's the other way around
FreezingCold has quit [Ping timeout: 240 seconds]
<naobsd>
I can see PMIC_SLEEP line is conneted to VSEL on syr82x
<jmcneill>
hi naobsd
<jmcneill>
having cpu freq setting + smp issues
<jmcneill>
anything > 1GHz is unstable
<mmind00_>
naobsd: correct ... this tells the syr82x which register to get the voltage setting from
<jmcneill>
1.2 boots but random panics, beyond that im lucky to get pll lock at all
<jmcneill>
or it hangs while doing the change
<naobsd>
I have no idea about polarity... adding "fcs,suspend-voltage-selector = <1>;" means syr82x driver change it to high?
<mmind00_>
no ... the syr82x does not touch any gpio ... it just tells the driver, that register1 is meant for the suspend setting (and register0 for runtime) ... without this option the driver uses the registers swapped (register0 for suspend, register1 for runtime)
<jmcneill>
we can fix that #if 1 in gpio setup
<naobsd>
jmcneill: it's exactly same as RK3066
<jmcneill>
ok
<mmind00_>
naobsd: btw. vccio_sd is not the supply of the sdio0 controller ... instead it is the vqmmc-supply of the sdmmc ... te firefly schematics are correct on page9 (and hopefully match the hardware), but the schematic on page3 is wrong
<naobsd>
mmind00_: ah I remembered, surely that has 2 set of regulator
<naobsd>
jmcneill: there are some local updates for gpio setup
<naobsd>
mmind00_: I found some errors in firefly schematics... I'll check it again
<mmind00_>
naobsd: anyway, time for bed now :-)
<jmcneill>
if you have any ideas for i2c let me know, i have tried a few things
<naobsd>
mmind00_: I see, thank you, good night!
<jmcneill>
been trying to read vendor reg of hdmi tx so far no luck
<naobsd>
jmcneill: can you access act8846 via i2c?
<naobsd>
jmcneill: pmic must be running
<jmcneill>
havent tried yet
<naobsd>
mmind00_: sorry, I cannot find vqmmc pin in TF_SD_SOCKET, pin4 VDD is connected to VCC_SD...
<naobsd>
pmic_sleep must be high
nighty^ has quit [Quit: Disappears in a puff of smoke]
<naobsd>
mmind00_: in RK 3.10 kernel, there are SYR82X_BUCK1_SET_VOL_BASE 0x00 and SYR82X_BUCK1_SLP_VOL_BASE 0x01
<naobsd>
it assumes PMIC_SLEEP/VSEL is high on normal, low on sleep
<naobsd>
ah, no
<naobsd>
in RK3.10, VSEL0 is used for normal, VSEL1 is used for sleep
<naobsd>
so it assumes PMIC_SLEEP/VSEL is low
<naobsd>
so it assumes PMIC_SLEEP/VSEL is low on normal
<naobsd>
and probably no one touch PMIC_SLEEP/VSEL, it should be low (pulled down by default)
<naobsd>
fcs,suspend-voltage-selector = 1 seems to be normal
<naobsd>
(in RK context)
nighty^ has joined #linux-rockchip
<naobsd>
jmcneill: rk3188plus_p path works fine on your rk3188+?
<naobsd>
rk3188plus_p path should be able to use for rk3066/px2 too...
<naobsd>
jmcneill: I'll move grf init lines into each drivers, mmc lines into rockchip_dwcmmc.c etc
nighty^ has quit [Ping timeout: 245 seconds]
<naobsd>
jmcneill: I think some grf handling need to be centralized in future
field^Mop has quit [Ping timeout: 240 seconds]
<naobsd>
aaaaaaaaaaaaaaaaaahhh
<naobsd>
I erased emmc on my firefly production ver... it has (at least) serialno...
<naobsd>
I can restore serialno from my log
<naobsd>
but I'm not sure other info is also flashed to emmc or not...
field^Mop has joined #linux-rockchip
<naobsd>
hm, regulator-always-on; may be needed for vdd_gpu: syr828@41
field^Mop has quit [Ping timeout: 244 seconds]
zombu2 has quit [Ping timeout: 252 seconds]
zombu2 has joined #linux-rockchip
Avagetto has joined #linux-rockchip
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 250 seconds]
Danukeru has quit [Ping timeout: 250 seconds]
Danukeru has joined #linux-rockchip
mrcan__ has joined #linux-rockchip
akaizen_ has joined #linux-rockchip
mrcan_ has quit [Ping timeout: 264 seconds]
akaizen has quit [Ping timeout: 264 seconds]
hipboi_ has joined #linux-rockchip
hipboi has quit [Ping timeout: 255 seconds]
FreezingCold has joined #linux-rockchip
zombu2 has quit [Ping timeout: 255 seconds]
<naobsd>
I'll change u-boot for rk3288 that dtb can be missed (no resource.img in resource partition and 2nd image of boot.img)
<naobsd>
then memory size, command line, and initrd info will be passed as ATAG
<naobsd>
current device tree handling in u-boot rk3288 is very specific to RK 3.10 dts
<naobsd>
atag shouldn't be used anymore, but dt support in u-boot rk3288 is not so useful
<naobsd>
better implementation will be done in upstream u-boot
<naobsd>
then, ugly hack is ok for current u-boot ;)
<naobsd>
if you clear resource partition and you don't use boot.img with resource.img, you can get mem size and initrd (and cmdline if it's not overwrite by kernel config) from atag
<naobsd>
if you flash resource.img into resource partition, or make boot.img with resource.img, dtb will be read from there, and passed to kernel as usual
<naobsd>
using ramdisk in boot partition is handly for me
<naobsd>
and I can ignore memory size info in dts ;)
<naobsd>
mmind00_: any idea? thermal thermal_zone1: failed to read out thermal zone 1
<naobsd>
mmind00_: (same for zone 2)
<naobsd>
let's try bootdelay issue...
<naobsd>
ganbold_: boot delay just work. you need to erase misc partition
<naobsd>
ganbold_: e.g. rkrlashtool w misc < /dev/zero
Danukeru has quit [Remote host closed the connection]
Danukeru has joined #linux-rockchip
<ganbold_>
naobsd: what does misc have?
<naobsd>
your misc should have a info to boot recovery
<naobsd>
erase it
<ganbold_>
I see
jas-hacks has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 265 seconds]
FreezingCold has joined #linux-rockchip
<naobsd>
jmcneill: I cannot get any result from i2cscan
<naobsd>
jmcneill: ah, I didn't check grf setting. trying...
<mmind00_>
naobsd: please don't try to add constants for RK_GPIO[7/8] ... they don't really serve a function as everything maps RK_GPIOx -> x, so there is no additional value provided ... that is also the reason why the core rk3288.dtsi does not use them anymore
hramrach_ has joined #linux-rockchip
bengal has quit [Quit: Leaving]
hramrach_ has quit [Quit: WeeChat 0.4.3]
<jmcneill>
yay i can talk to the pmic
<jmcneill>
or at least, something at iic1 addr 0x5a is responding
jas-hacks has joined #linux-rockchip
hramrach has joined #linux-rockchip
<jas-hacks>
mmind00_: do you know if vopb needs to be specifically configured for hdmi in the dts?
<mmind00_>
jas-hacks: if you mean if vopl and vopb nodes are necessary, yes of course, along with some other stuff
<jas-hacks>
mmind00_: if only want to test hdmi I guess I need only to enable vopb, assuming its the primary display
<mmind00_>
jas-hacks: you'll also need the display-subsystem root node ... see the chromeos kernel repo for reference
<jas-hacks>
mmind00_: that's what I'm trying to follow. I've added the nodes for hdmi & vopb but I'm not getting screen output
<mmind00_>
jas-hacks: does it detect the connected hdmi plug at all? I haven't tried this at all yet, so I'm not sure what to expect
<jas-hacks>
mmind00_: Looks like the hdmi controller is detected but not the attached device. http://pastebin.com/pX1vAp8J
<rperier>
I will probably work on adding phy-usb on rk3188 (using the generic driver wrote by rockchip for rk3288, I will adapt it to old SoCs) if nobody else planned to work on it, of course...
nighty^ has quit [Quit: Disappears in a puff of smoke]
nighty^ has joined #linux-rockchip
nighty^_ has joined #linux-rockchip
rocky has joined #linux-rockchip
rocky has left #linux-rockchip [#linux-rockchip]
BorgCuba has joined #linux-rockchip
<BorgCuba>
rperier, I am using the rk3288 phy driver on the rk3066 which seems to work out of the box
<BorgCuba>
you only need to add the correct reg address to your dts
<rperier>
in this case I will test it on rk3188 (and add the corresponding changes to the dts)
<BorgCuba>
okay, I can give you my settings for reference
<jmcneill>
yay i can talk to the it66121 hdmi tx chip now
<BorgCuba>
and 269 ... eof
<rperier>
BorgCuba: did you test it on the marsboard or you just use this dts on your rk3066 board ?
<rperier>
If you get something working, feel free to send a patch on the ML
<BorgCuba>
rperier, I used it on this rk3066 hdmi stick I own
<rperier>
these changes should not be in the dts of the board but in the dtsi, imho
<BorgCuba>
line 90-110 add the phys and the you have to assign them to the usb_otg/host nodes
<rperier>
I mean, it's not specific to the board but to the soc...
<BorgCuba>
yes, its only for personal testing
<rperier>
:)
<rperier>
but that's good to know anyway
<BorgCuba>
Have you looked into the phy driver? Its pretty simple, only sets/clears 1 bit
<rperier>
that's not the first time I work with a devicetree binding and with the devicetree, so It should be okay I think. It does not look very complicated ;)
<rperier>
mhhh... perhaps these changes can be shared between rk3066/rk3188 directly... in this case we might factorize them into rk3xx.dtsi... I will look at it
<BorgCuba>
I think so
<rperier>
thanks for your feedbacks
<BorgCuba>
to be precise: bit 13 (usbphy_siddq) of GRF_UOCn_CON0 (n=0(0x17c),1(0x188)) (p. 234 of the RK30xx TRM)
<Astralix1>
hey guys
<Astralix1>
did anyone recently download the latest ziped source code of firefly?
<BorgCuba>
rperier, rk3xxx.dtsi is not shared with rk3288, right?
<BorgCuba>
because for the rk3288 the register offsets are different
nighty^ has quit [Quit: leaving]
<BorgCuba>
ohh, and GRF_UOC0_CON0 is at offset 0x10c for rk3188!
<rperier>
BorgCuba: not that's only for rk3066/rk3188 afaik
<jas-hacks>
Astralix1: if you already downloaded have their repo then you can pull from your local repo
<rperier>
last time I checked rk3288.dtsi did not include rk3xxx.dtsi
<Astralix1>
I downloaded the older version and fetched / pulled from the repo. But the result does not compile
<BorgCuba>
rk3066: 0x17c,0x188 vs. rk3188: 0x10c/0x11c
nighty^ has joined #linux-rockchip
<Astralix1>
So I try tor follow the advise that you should download the new ziped code and then sync again...
<Astralix1>
but the download always fails due to network error
<BorgCuba>
rperier, so since the reg values differ this probably has to go into rk3066.dtsi and rk3066.dtsi
<Astralix1>
I will ask the team about to mirror the images
<BorgCuba>
rk3188.dtsi
<jas-hacks>
Astralix1: old version compiled ok for me, but it fails to boot completey
<jas-hacks>
Astralix1: new version just has a couple of patches
<Astralix1>
For me it looks a bit incomplete in the descriptions
<Astralix1>
But any way I try, just calling "make -j6" or even "source build/envsetup.sh; lunch 10; make -j6" it just
<Astralix1>
shows the initial overview output about setup and compilers and then stays in that without compiling a single line of code
<jas-hacks>
Can you pastebin the output
<Astralix1>
But there is still a chance that I messed up something as I modified my accounts on my system
<akaizen_>
@Astralix1 @jas-hacks Is that the Firefly Android SDK? It includes its own toolchain in the source so as long as you have clone the repo and synced it to their bitbucket it should compile according to their wiki
akaizen_ is now known as akaizen
<Astralix1>
Yes, I thought so...
c0d3z3r0 has quit [Ping timeout: 240 seconds]
c0d3z3r0 has joined #linux-rockchip
bengal has joined #linux-rockchip
Danukeru has quit [Ping timeout: 250 seconds]
Danukeru has joined #linux-rockchip
<BorgCuba>
rperier, have you tested dwc2_otg with gadget/device?
GriefNorth has quit [Ping timeout: 245 seconds]
<BorgCuba>
I could need some help on this issue, I already applied the patches from the mailing list but it still does not complete the enumeration process successfully
Danukeru has quit [Ping timeout: 250 seconds]
Danukeru has joined #linux-rockchip
jas-hacks has left #linux-rockchip [#linux-rockchip]
bengal has quit [Remote host closed the connection]
mcan has joined #linux-rockchip
Danukeru has quit [Ping timeout: 250 seconds]
mrcan__ has quit [Quit: pai]
bengal has joined #linux-rockchip
Danukeru has joined #linux-rockchip
akaizen_ has joined #linux-rockchip
bengal has quit [Ping timeout: 256 seconds]
akaizen has quit [Ping timeout: 256 seconds]
bengal has joined #linux-rockchip
Danukeru has quit [Ping timeout: 250 seconds]
Danukeru has joined #linux-rockchip
<naobsd>
jmcneill: ping
<naobsd>
jmcneill: what's the problem with "set value, then set direction" for gpio?
<naobsd>
jmcneill: I think if you have a pin (e.g. power hold) which is default pull-up, and you do "set direction then set value", you'll get low(default value is 0) on "set direction"
<naobsd>
jmcneill: for correct regulator outputs, please check android source or dmesg, some outputs are board specific
<jmcneill>
i wouldnt expect set value to have effect if direction input
field^Mop has quit [Ping timeout: 250 seconds]
<jmcneill>
linux gpio driver agrees with me
<jmcneill>
btw
<jmcneill>
> ithdmi0 at iic2 addr 0x4c: id 54 49 12 16
<jmcneill>
> ithdmi_hpd: sysstat 0xcc
<jmcneill>
> ithdmi0: display connected
<jmcneill>
but i can only talk to the chip if i boot android first then press reset sw, i am missing something
bengal has quit [Ping timeout: 265 seconds]
<naobsd>
jmcneill: value doesn't have effect when direction is input
<jmcneill>
:)
<naobsd>
what I talked is time gap between set direction and set value
<jmcneill>
can you check my hdmi setup?
<jmcneill>
still not familiar with iomux
<naobsd>
"in / pulled-up" -> "out / hight" and "in / pulled-up" -> "out / low" -> "out / high" are clearly different
<naobsd>
please do "set value, then set direction"
Avagetto has joined #linux-rockchip
<naobsd>
"set value" (before "set direction") doesn't have effect, then value is applied on "set direction"
<naobsd>
"set value" doesn't have effect == we can do it safely
<naobsd>
I'm not sure I can do something today
<naobsd>
I have to go out soon
<jmcneill>
ok
<jmcneill>
i just checked with the trm, you are right
<jmcneill>
gpio api needs better abstraction anyway
<jmcneill>
iomux too
<naobsd>
jmcneill: btw how about higher cpu freq with higher core voltage?
<jmcneill>
need to figure how how to do that
<jmcneill>
iic attaches after a9tmr, which will cause freq change, no way to tell it about the change yet
<naobsd>
let add rktmr for tick and timecounter ;)
<jmcneill>
a9tmr is per cpu, matt@ says that is required
<naobsd>
jmcneill: any critical code uses it? how that code know "current _timer_ frequency"?
<naobsd>
jmcneill: if it needs to be running, it's ok
<jmcneill>
ill figure it out just want to sort out hdmi first
<naobsd>
I see
<jmcneill>
waiting for someone to volunteer a vmac driver too
<naobsd>
you may need to change voltage for hdmi output
<naobsd>
ah, after lcdc thing is done...
<jmcneill>
i should compare before/after
<jmcneill>
didnt think to check that
<naobsd>
which output is used for hdmi will be board specific
<naobsd>
I hope most board just follow reference...
<naobsd>
btw usually I don't connect any video/audio