stikonas has quit [Quit: Konversation terminated!]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 276 seconds]
kevery1 is now known as kevery
Daanct12 has joined #linux-rockchip
hipboi has joined #linux-rockchip
naoki has joined #linux-rockchip
hipboi has quit [Quit: hipboi]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
hipboi has joined #linux-rockchip
hipboi has quit [Client Quit]
hexdump0815 has quit [Ping timeout: 244 seconds]
hexdump0815 has joined #linux-rockchip
naoki has quit [Quit: naoki]
hipboi has joined #linux-rockchip
hipboi has quit [Client Quit]
ungeskriptet has quit [Ping timeout: 246 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Client Quit]
indy has quit [Ping timeout: 244 seconds]
hipboi has joined #linux-rockchip
eballetbo has joined #linux-rockchip
xha has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
xha has joined #linux-rockchip
System_Error has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
System_Error has joined #linux-rockchip
stikonas has joined #linux-rockchip
raster has joined #linux-rockchip
stikonas has quit [Quit: Konversation terminated!]
<wens>
qschulz: returning to the "remove pinctrl properties" subject, if the pin config options used on the GPIO lines are only pull up / pull down / disable bias, those can be replaced with the GPIO flags "GPIO_PULL_*"
<qschulz>
wens: we have to set drive strength also for some pins
<qschulz>
so not enough :/
kevery1 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery1 has quit [Read error: Connection reset by peer]
kevery has joined #linux-rockchip
warpme has joined #linux-rockchip
crabbedhaloablut has quit []
crabbedhaloablut has joined #linux-rockchip
crabbedhaloablut has quit []
crabbedhaloablut has joined #linux-rockchip
hipboi has quit [Quit: hipboi]
hipboi has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
Stat_headcrabbed has joined #linux-rockchip
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<wens>
I guess we can at least minimize them?
<qschulz>
wdym by minimizing?
psydroid has joined #linux-rockchip
<qschulz>
doesn't it also mean that we postpone the setting of the bias/pull?
Daanct12 has quit [Quit: WeeChat 4.4.2]
<qschulz>
the pinconf happens well before the driver manually requests the GPIO IIRDC
<qschulz>
IIRC*
Stat_headcrabbed has joined #linux-rockchip
Stat_headcrabbed has quit [Client Quit]
Stat_headcrabbed has joined #linux-rockchip
<wens>
that true
<wens>
qschulz: minimizing the number of pinctrl settings used for GPIOs
<wens>
well, it happens when the device is bound
<qschulz>
wens: I am not sure it makes a lot of sense to have several ways of configuring GPIO pinconfs but that would be a decision on the maintainership level, so for mmind00
<qschulz>
wens: I mean, having both in DTs
<qschulz>
both in the same DT
<qschulz>
especially if requesting the GPIO doesn't reserve the pin in the pinctrl subsystem (I have yet to test what's the state on Rockchip)
dsimic has quit [Ping timeout: 255 seconds]
dsimic has joined #linux-rockchip
hipboi has quit [Quit: hipboi]
urja has quit [Read error: Connection reset by peer]
<mmind00>
qschulz: as far as I remember (from waaaaay back then) the pinctrl driver did not request the gpio if it was only done via gpio-request ... it does set the mux though in that case
<mmind00>
qschulz: wens: I guess the whole thing is a bit of a chicken-egg problem? Reducing pinctrl entries for gpios opens things up for funny mismatches, where a pinctrl entry requests a pin as something ... and somewhere else by some mistake, another driver requests the same pin as gpio
<mmind00>
But having those separate entries then prevents us from ever moving to that strict thingy
<mmind00>
and as qschulz said, as long as we can't fully replace pinctrl settings (drive-strength, bias, whatever), I don't think it makes a lot of sense to have something in the middle that conforms to neither paradigm?
urja has joined #linux-rockchip
<wens>
yeah, strict mode needs to be implemented in a way that is compatible with existing GPIO muxing
<wens>
as you said, probably doesn't make sense if we can't completely eliminate the GPIO related pinctrl settings
<qschulz>
and I don't think we'll be able to extend the GPIO_* flags for DT with vendor-specific (heck, even SoC-specific IIRC) values for drive strength for example
<wens>
that's true
<wens>
what are the drive strengths used for? LED brightness?
<qschulz>
What the actual meaning in hardware is? no clue, but we need it for at least RK3399 Puma
<qschulz>
because we have diodes on some input pins
<qschulz>
and those only let the signal pass with a high driving strength
<qschulz>
mmmm wait, I may be mistaken
<qschulz>
I needed a pull-up on the input pins protected by diodes
<qschulz>
from the internal commit messages, it's used to make signals more square (rise/fall faster) or get rid of undershoot/overshoot
<wens>
AFAICT those are for I2C functions, not GPIO functions?
<wens>
which makes sense
<wens>
I'm saying that we can probably get rid of the four sets defined on line 321
<wens>
the ones with RK_FUNC_GPIO
<qschulz>
Ah, I see what you mean now... I don't know tbh, we could check if there's any Rockchip DTS(I) that has a drive strength set for a GPIO function
<qschulz>
and a big if for "if nobody will ever have a GPIO function with a non-default drive strength"
<wens>
Only thing I found it useful for so far is to lower the brightness on GPIO driven LEDs :p
<qschulz>
that could be enough justification already :/
<qschulz>
(could go the other way around, increasing the LED brightness)
<wens>
"driving" LEDS directly with GPIOs seems a bit ill advised though. Would probably be better the other way around, having the GPIO on the negative side
<qschulz>
wens: we cannot tell contributors to modify HW that isn't following best practices though :)
<wens>
hehe
<qschulz>
though sometimes that would make things much easier :)
ldevulder has quit [Quit: Leaving]
kevery1 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery1 is now known as kevery
naoki has joined #linux-rockchip
naoki has quit [Quit: naoki]
dlezcano has joined #linux-rockchip
<dlezcano>
Hi all,
<dlezcano>
@mmind00, is there some documentation to compile a mainline kernel for the rk3358 (rock-5B) ?
qschulz has quit [Remote host closed the connection]
qschulz has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beeble>
dlezcano: the same as any other mainline kernel? or maybe better to ask, what issue do you have?
<dlezcano>
My goal is to tftpboot the kernel from u-boot
<mmind00>
yep ... and does not contain any wiggling with images or such
<mmind00>
pxelinux then
<dlezcano>
mmh, may be I too used with the rock960 setup
<mmind00>
my tftpserver has "pxelinux.cfg/01-be-d1-06-6f-37-47" file ... mac address for the board, that then has the same layout for describing kernel+fdt+commandline+initrd
<beeble>
and just for completeness next-server for the tftp server if you use at least isc-dhcp and want to use use it with dhcp/pxe autoboot
<dlezcano>
mmind00, rock5b.fit is an option when generating u-boot ?
<dlezcano>
@beeble, ok thanks
<mmind00>
dlezcano: my setup is, I build u-boot with the generic distroboot ... which then tries a number of boot methods and then lands at the pxelinux one, doing dhcp, then trying to load the pxelinux config for the mac-adress
<mmind00>
dlezcano: from that file it then retrieves the rock5b.fit filename and gets this from the tftp server as well
<dlezcano>
mmind00, where do you get the rock5b.fit file ? It is a file I have to install on my tftp server
<mmind00>
dlezcano: correct .... that's just mkimage running on the .its from above
<dlezcano>
mmind00, But actually I can just generate the kernel image from the its, tftp load it and then boot
<dlezcano>
mmind00, no ?
<dlezcano>
I skip the intermediate boots with the rock5b.fit
<mmind00>
dlezcano: not sure I understand ... the rock5b.fit is that image build from the .its
<mmind00>
dlezcano: if you mean without the pxelinux then yes, that is also possible, but then you need to tell u-boot what to do
<mmind00>
dlezcano: the nice part about pxelinux / extlinux is that u-boot will just find this stuff by itself
<beeble>
(as long as its at some of the predefined locations)
<mmind00>
yep :-)
<dlezcano>
mmind00, beeble thanks for your help. I'll try the different methods
<beeble>
dlezcano: but if your goal is to only do this once via network, yes you can do it manually. via the fit image or the kernel/devicetree separately
<dlezcano>
beeble, right I'll be compiling often and test. Currently with the rk3399, I cross-compile on a server and then reboot the boards. In turns, it will tftp load the image and boot it directly.
<beeble>
in that case pxe might be the nicest option as it works out of the box and can be configured per board or per architecture or even catch-all
<dlezcano>
beeble, yes I think you are right, I'll experiment that
<beeble>
and if you want to force it to always do network boot set boot_targets in your u-boot env to pxe only
<dlezcano>
beeble, right thanks
raster has joined #linux-rockchip
stikonas has joined #linux-rockchip
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
raster has quit [Ping timeout: 252 seconds]
raster has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]