<apritzel>
tokyovigilante: looks good on the first glance
<tokyovigilante>
Trying bluetooth now, added a wee bit from macromorgan's work, apparently the BT component of the RTL8821 runs over serial (Which I think you know from the uart1 node in the DT
<tokyovigilante>
have added bluetooth { compatible = "realtek,rtl8821cs-bt", "realtek,rtl8723bs-bt";
<tokyovigilante>
}; but does not seem to be detected
<tokyovigilante>
ah, probably need CONFIG_BT_HCIUART_RTL
<tokyovigilante>
in the kernel
<tokyovigilante>
I know you mentioned the goal is a single defconfig for the kernel for ARM64, but there's quite a bit not enabled by default
<apritzel>
defconfig is not meant to cover *everything*, that would be insane
<apritzel>
the idea is to have drivers needed to boot (popular) devices, so essentials like pinctrl & clocks, plus some drivers for mass storage, maybe network, to have a common config for testing and reproducing bugs
<apritzel>
if you find something missing, you can send a patch, but I doubt that BT or WiFi devices would be included, it's already getting large
<apritzel>
for actual usage you are expected to go with a distro kernel, they make sure you have everything
<apritzel>
tokyovigilante: as a developer, during bringup, you do as you do: add options to defconfig as you need them
<apritzel>
I build in a separate build directory, and have a .git in there, to track and manage some configs
<tokyovigilante>
makes sense
<apritzel>
that allows to not lose options when you go to newer kernels, and allows to check out an older config easily
<apritzel>
and you can switch to experimental configs easily: it's just a branch
<tokyovigilante>
ok, rebuilt and still no BT controller
<apritzel>
do you have CONFIG_BT_HCIUART_3WIRE?
<apritzel>
also I guess there is at least one GPIO, probably enable?
vagrantc has quit [Quit: leaving]
<apritzel>
I put the GPIOs used in the comment above the uart1 node
<apritzel>
I'd guess you need enable-gpios = <&pio 6 19 GPIO_ACTIVE_HIGH>;
<tokyovigilante>
yup, just puzzling those out now
<apritzel>
also I forgot uart-has-rtscts;
<apritzel>
I added all the interrupts and the power key to the AXP717 driver, will try to post something on the weekend
<tokyovigilante>
awesome, thanks
apritzel has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
<tokyovigilante>
OUTSTANDING
<tokyovigilante>
[ 15.461757] Bluetooth: hci0: RTL: fw version 0x75b8f098
<tokyovigilante>
[ 73.917051] rtw_8821cs mmc1:0001:1: firmware failed to leave lps state
montjoie_ has quit [Ping timeout: 480 seconds]
<tokyovigilante>
got it paired with my phone though, just not sure about the log spam
<tokyovigilante>
I assume that's a power issue though
<tokyovigilante>
lsmod
colinsane has quit []
<macromorgan>
bad ass... sorry I haven't had much time to look at it (had to fix my fridge). Do you have a page with your kernel/U-boot commits, and also will you be taking lead on mainlining these? If not I'll be glad to help walk you through it.
<tokyovigilante>
the only other kernel changes currently are just config for the wifi and bt modules
<tokyovigilante>
happy to work on getting them mainlined, cant overemphasise enough how much i have no idea what i'm doing and only learnt this entire ecosystem existed last month
<macromorgan>
no, actually I think mainlining something yourself is a good learning experience if you're willing to put in the work. Devicetrees are fairly easy, so long as you run them through all the necessary checks and stuff. I'd be more than happy to walk you through it.
<macromorgan>
basically make triple sure you do "make dtbs_check" before you push anything upstream, and also "scripts/checkpatch.pl", and for good measure when writing docs for devicetree also use "yamllint"
vagrantc has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
flyback has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
junari has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
<MoeIcenowy>
well I recently heard about refurbished H616
macromorgan has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
<Jookia>
mainlining a device tree is a good way to get in to kernel development i think :)
<Jookia>
libv: i don't have access yet. i'm not sure what should be carried in this rp-t113 sdk yet
<Jookia>
i love linux, but it has really broken my heart with some of the things desktop linux has done
<Jookia>
keep a safe distance and it'll be fine :)
<libv>
desktop linux had a shot in the vista days
<Jookia>
i use linux as my desktop but i'm pretty lucky to be able to do that
<gamiee>
Same
<gamiee>
Sadly, even nowadays Linux desktop is not fully ready
<gamiee>
Having weird issues with KDE Plasma from time to time
<libv>
sadly, one big player never sold a desktop product, and has always been way too busy being the big dog, and pushing others out of the pram
<libv>
one method was always to (re)invent things for the desktop, claim it will be ready in 6 months, then deliver a 60% product as they did not have to sell it on the desktop, but create user/customer demand and force the other players to fix all the issues to actually turn it into a product
<Jookia>
embedded space is pretty cool though, having basically full stack control means you can actually fix issues
<libv>
when i joined suse, the big story was networkmanager, the amount of complaints and noise from people who actually needed to deal with the fallout was quite something
<libv>
this was before pulseaudio, or before they did the same to my code (radeonhd)
<Jookia>
it's not great sometimes
<Jookia>
i feel like with kernel hacking i can at least make a change in some places
Schimsalabim has joined #linux-sunxi
ungeskriptet is now known as Guest2269
ungeskriptet has joined #linux-sunxi
Guest2269 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
mkazantsev has joined #linux-sunxi
mkazantsev has quit [Remote host closed the connection]
<apritzel>
tokyovigilante: can you post your DT changes so far, for instance to your U-Boot git repo?
<apritzel>
I saw the regulator ranges being "wide", as in the BSP DT, which is nonsense IMHO (not your fault, but I think a misunderstanding on AW's side)
<apritzel>
because most consumers don't know or don't care about a voltage, and the system design fixes most of the rails
<apritzel>
and AW put the AXP's limits in there, which is not something that belongs into a *device* DT
<apritzel>
so DCDC1 should be 0.81V - 1.1V, DCDC2 fixed to 0.94V, DCDC3 fixed to 1.1, ALDO1&BLDO2 to 1.8V, CLDO4 to 3.3
<Jookia>
limits sound like they go in the driver
<Jookia>
if at all
<apritzel>
yes, either this, but actually those limits are the PMIC hardware limits, so you cannot go outside of these anyways
<apritzel>
and the purpose of the device part of the DT is to exactly specify the voltage needed, like: this rail is connected to the WiFi chip, which needs 3.3V
<Jookia>
oh, if they're limits you can't go outside then it really is redundant to put them anywhere i guess
<apritzel>
not restricting them is actually outright dangerous, for instance DCDC2 is connected to VDD_GPU and VDD_SYS, which have a absolute maximum rating of 1.1V in the H616 datasheet
<apritzel>
AW is doing this for years, though this would be among the first things that would be noted in a mailing list post, fixed in v2, remembered for the future
<apritzel>
macromorgan: many thanks for the offer on supporting tokyovigilante with the upstreaming efforts, much appreciated!
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
we need more people to actually get their feet wet with mainline contributions. While it can be daunting, there is no real way around it, and it gets easier over time
warpme has joined #linux-sunxi
<gamiee>
apritzel : hi, this reminds me one question which was puzzling me. On AXP start up, how the PMIC knows which rails to power up and at what voltage?
<apritzel>
gamiee: that's a good question! There are defaults for both the enable bits and the voltages, though the datasheet if somewhat fuzzy about their actual values
<apritzel>
is often says: "customized"
<gamiee>
so are there some efuse/memory where default values are stored? :o
<apritzel>
my understanding is that you can specify those values when you order (a bunch of them), I guess there are efuses
<apritzel>
of maybe you get those customized when you order them together with a certain Allwinner SoC, I hear they are often bundled
<apritzel>
there are some rails that need to be in reasonable ranges and enabled, for instance for powering the CPU cores, VDD-SYS, VCC-IO and say an SD card or SPI flash
<gamiee>
exactly...
<apritzel>
the datasheet gives some recommendations about the rail's usage (DCDC1 for CPU, DCDC3 for DRAM, and so on), and I guess there are some "default defaults"
<apritzel>
in previous AXP chips there was at least one pin to set the startup voltage for the DRAM rail, so you connect that to GND, leave it floating, or connect to +5V, for DDR3, LPDDR3, DDR4, respectively
<apritzel>
which meant we didn't need an AXP driver in U-Boot's SPL for the A64 and H6 boards (using AXP803 and AXP805)
<apritzel>
but someone messed that up in the H616 reference design, or the designated rail didn't provide enough current
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<jernej>
gamiee, apritzel: I saw one AXP datasheet mentioned efuses from where default value is loaded
<apritzel>
jernej: ah, are they accessible/programmable via the normal I2C/RSB registers?
<jernej>
there were no further mentions afaik
<jernej>
so idk
<jernej>
interestingly, AXP858 has pin for default DCDC5 (DRAM) voltage
<jernej>
so you can set it according to your DRAM type
<jernej>
but I'm not sure if CPU and VCC-SYS and other important rails are set up properly
<gamiee>
interesting, I didn't saw any other information about it either... Well, AXP datasheets were always not much ... helpful :D
<jernej>
so each H616 & co. boot0 sets those 3 rails regardless of default settings
dsimic is now known as Guest2278
dsimic has joined #linux-sunxi
Guest2278 has quit [Ping timeout: 480 seconds]
<libv>
mediawiki templates are a pain.
<gamiee>
libv: mediawiki is generally pain
<gamiee>
D
<libv>
gamiee: which is probably because anything web related is a pain :)
<libv>
i have reduced the infobox to a quarter of its original size, and can now see a path forward to making it better and even smarter (like automatically categorizing devices)
<gamiee>
libv : I don't agree with that much, web can be "nice", but current web tech situation is so horrible, that I avoid it and don't enjoy doing anything web at all.
<libv>
gamiee: do you see privmsgs at all btw?
<libv>
gamiee: anything web makes me feel dirty ;)
<gamiee_>
libv: for PMs please send it to this account. The "gamiee" account is another bouncer, which makes bridge with my Discord (so it's easier for me to watch this channel :P ).
<libv>
i have been in several projects where my insistance on wikis saved our bacon, in as far as there was any bacon left to rescue
<gamiee>
Yes, wikis for projects are amazing, although, mediawiki is sometimes pain to work with, both as admin or user.
<libv>
yeah, but it's about the extent to which i allow myself to be in contact with web stuff ;)
Syter has joined #linux-sunxi
<apritzel>
libv: thanks for taking one for the team ;-)
<gamiee>
libv: makes sense :)
<apritzel>
jernej: I think most, if not all PMICs have that pin, but on the AXP305 it's called DCBSET, while DRAM is on DCDCD, which makes me think that DCDCB is not sufficient for the DRAM needs
mripard has quit [Quit: mripard]
<MoeIcenowy>
jernej: I think many AXPs that are used as companion of Allwinner SoC has this design
<MoeIcenowy>
to adapt for multiple DRAM types
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
<libv>
:)
apritzel has quit [Ping timeout: 480 seconds]
Syter has quit [Quit: Konversation terminated!]
f_ has quit [Ping timeout: 480 seconds]
<libv>
i have reduced the infobox + infobox_board templates to something much much saner
<libv>
there should be no changes whatsoever to infoboxes on our device pages
<libv>
kick me if you find something though
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
f_ has joined #linux-sunxi
warpme has quit []
apritzel has joined #linux-sunxi
<apritzel>
libv: there is some stray "|" character on each device page now?
<libv>
urgh
<libv>
at the last minute i decided not to include logic to automatically show the default no picture image...
<libv>
and there is too much white space at the top as well
<tokyovigilante>
Added the BT enable and wake GPIOs but not working well as described above. Should I go ahead and change the power limits as you described above?
<apritzel>
yes please, the power limits should definitely be restricted! I think I had them like this in my update patch? Any particular reason why you changed them?
<apritzel>
most devices just *enable* the regulators, and don't ask for a certain voltage (they just cannot know which)
<apritzel>
In this case the regulator core code reads the current voltage, and just makes sure it's within the limits
<apritzel>
which effectively means in our case it keeps them
<tokyovigilante>
I have them matching that patch currently, just wondering if I should put tighter ones in, ie DCDC1 0.81/1.1v, DCDC2=1.1/1.1 etc