mripard has quit [Read error: Connection reset by peer]
mripard has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
diveben has quit [Server closed connection]
diveben has joined #linux-sunxi
<macromorgan>
yeah, though I'm also (about to be) booting Linux from SPI as well, so I'll need that stuff I think.
NekoMay has quit [Server closed connection]
NekoMay has joined #linux-sunxi
cyrozap has quit [Server closed connection]
cyrozap has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit []
Ultrasauce has quit [Server closed connection]
sauce has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
diveben has quit [Remote host closed the connection]
NekoMay has quit [Remote host closed the connection]
diveben has joined #linux-sunxi
NekoMay has joined #linux-sunxi
samueldr has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
smaeul has joined #linux-sunxi
apritzel has joined #linux-sunxi
jakllsch has joined #linux-sunxi
uis has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
hlauer has joined #linux-sunxi
evgeny_boger has quit [Read error: Connection reset by peer]
evgeny_boger has joined #linux-sunxi
apritzel has joined #linux-sunxi
uis_ has joined #linux-sunxi
uis has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
<evgeny_boger>
Hi guys! How do you set pinctrl for userspace gpios in allwinner dts?
<evgeny_boger>
I mean a have a bunch of gpios which I use from userspace only. So the pins don't belong to any node in DTS, so I can't set pinctrl-0 = <&my_userspace_pins> to any meaningful node. What should I do? I can't find any standard way
<jernej>
use libgpiod
<evgeny_boger>
I mean I know how to control gpios from userspace. The question is about pinctrl. For instance, I need to set bias-pull-up for some of the pins
juri_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
<jernej>
sure, that can be done with libgpiod also
<jernej>
using GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP flag
<apritzel>
evgeny_boger: as jernej said: if you request GPIO access from userspace, for instance through libgpiod, then the kernel manages the pinmuxing part for you
<apritzel>
evgeny_boger: you can request any pin that has not been already claimed by a driver
<evgeny_boger>
thank you, I didn't know that. On i.mx target we just declare everything in &pinctrl_hog or something in dts
<evgeny_boger>
I'm also seeing rather interesting behaviour:
<evgeny_boger>
it looks like LInux kernel driver (pinctrl-a10?) has assumptions about Px_CFG state. Is it a kernel bug?
cnxsoft has quit [Remote host closed the connection]
<apritzel>
evgeny_boger: how so? with the export you just claim that GPIO for the sysfs/userspace interface, you don't configure it as an input
<apritzel>
evgeny_boger: so it naturally won't report anything until you ask it explicitly
<apritzel>
the "in" is probably just some generic mapping from sunxi'x 0b111 to the generic debugfs output
<gamiee>
hello, is possible to reach UART baudrate 1500000 on V3s SoC (or any other allwinner SoC)? Thanks
<evgeny_boger>
apritzel: well, it is extremely confusing. On other SoCs where GPIOs handled by dedicated hardware and driver, they are always in a valid state: either input or output. I would expect that export (i.e. gpiod_request) would reset the GPIO to some state that makes sense for GPIO.
<evgeny_boger>
For driver API, they indeed mention in kernel documentation that "using a GPIO without setting its direction first is illegal and will result in undefined behavior", even though I personally would understand "underfined behavour" as GPIO being either input or output.
<evgeny_boger>
and it's getting more weird. looks like sunxi driver doesn't implement get_direction at all! So it's not some default mapping from unexpected mux value, it's just an uninitialized state being reported
<evgeny_boger>
so I think better behaviour would implement proper get_direction() which will throw a warning if mux is not gpio_in or gpio_out. What do you think?
<apritzel>
evgeny_boger: do you see this behaviour with the gpiolibd as well? This sysfs interface is deprecated for quite some time now
<apritzel>
also /sys/kernel/debug/gpio is the *debugfs*, which is really just informational, and doesn't guarantee much
<jernej>
I think libgpiod offers more choices than sysfs interface
<jernej>
gamiee: yes, 1.5 Mbaud is often set for bluetooth across different boards
<gamiee>
jernej: great, thank you very much!
<jernej>
actually it's highest reachable speed without driver changes
<gamiee>
I read somewhere that maximum is 3 Mbaud but clock changes required
<aggi>
Mbaud or Mbps?
<jernej>
I'm not familiar with V3s particularly, but I would imagine it has same limitations as other SoCs
<gamiee>
yes, + it's SoC from 2015? so I don't think it will be different
<jernej>
aggi: uart speed is usually expressed as baud rate
<aggi>
then this is very fast, 1.5Mbaud=12Mbps (although baud/symbol rate, and the bits/symbol vary depending on modulation, often announced as 1Baud=8bps)
<jernej>
I'm reading now about that
<aggi>
was surprised to see uart reached 1.5Mbps with some aarch64 i got here
<jernej>
but here it's actually 1.5 Mbps
<jernej>
nomenclature is from early days when 1 bit = 1 baud
<aggi>
then it's probably 1.5Mbps, identical to the aarch64 SBC i got here, which is 1.5/8 Mbaud (if 1Baud=8Bps, depends on modulation)
<aggi>
this had never been nomenclature, 1baud=1bps, Baud has always been the symbol rate, and the bits/symbol always varied depending on modulation
<evgeny_boger>
apritzel: gpio chardev interface report cached gpio direction regardless of whether get_direction() is implemented by the GPIO driver. So I can't reproduce it using chardev userspace interface.
<apritzel>
evgeny_boger: which is probably expected behaviour? I mean get_direction() seems somewhat redundant, since the driver should know at any point in time how it set this pin up?
<evgeny_boger>
but gpiod_get_direction() is nevertheless there, it's called by legacy sysfs interface, debugfs and some legitimate drivers too
<evgeny_boger>
apritzel: well, we for certain didn't expect that. In my opinion, whether the interface is legacy (as old sysfs userspace one) or redundant (as in-kernel gpiod_get_direction) it should work in a consistent way
<evgeny_boger>
as for get_direction, kernel sources (gpio/driver.h) even recommend to implement It "it is recommended to always implement this function, even on input-only or output-only gpio chips"
<jernej>
but yes, bps and bauds is often used interchargably even if it isn't
<apritzel>
jernej: aggi: but that doesn't apply to serial cables, does it? Here we have one bit = one symbol, so bps = baud
<apritzel>
I feel this is some pointless trivia topic, serial line speed is always counted in bits per second
<aggi>
depends on the layer, at layer2 Bps is suitable, at layer1(physical) Baud (symbol rate) is highly relevant, because depending on the modulation (QAM, Trellis whatever), a symbol can encode any amount of Bits
<apritzel>
aggi, sure, but this is about a serial cable using the EIA-232 standard, right?
<aggi>
typical OS-related discussions refer to layer2 (link), Bps is suitable; and most WiFi drivers (which cope with modulation schemes) are proprietary blobbed anyway
<apritzel>
but as I said: trivia territory ...
<apritzel>
the V3s (and many other SoCs) driver the UART clocks from ABP2, which can be muxed the PLL-periph
<apritzel>
the V3s manual doesn't mention a maximum speed, but the A64 for instance speaks of up to 3Mbps
<apritzel>
normally APB2 is muxed to the 24 MHz oscillator, which gives you the 24/16=1.5Mbps speed
<aggi>
maybe, there is another confusion? because a rough estimate is maximum data rate is half the available bandwith
<aggi>
meaning with 3MHz 1.5Mbps is max (sampling theorem)
<apritzel>
no
<jernej>
UART peripheral in AW SoCs need 16x oversampling
<jernej>
so just take source clock and divide by 16 to get max speed
<aggi>
sorry then (had again the analog part in mind, if you got 3MHz analog signal bandwith, digital data rate is appr. 1.5MBps max)
<apritzel>
jernej: but on top of that there is surely some limit in the UART IP
<apritzel>
aggi: with perfect filters, but again this is irrelevant here. And it's an Allwinner datasheet number, so take with a grain of salt
<apritzel>
I remember people experimenting with max UART speed before, and they ran into quality issues pretty quickly
<jernej>
apritzel: I guess, many bluetooth modules I've seen support 3 M max.
<apritzel>
I think 1.5MBps is fine, especially if used on the PCB only (SoC <=> Bluetooth)
<jernej>
yeah, 1.5 M is enough for bluetooth audio
<apritzel>
as usual for Allwinner: if you really want to know the truth, you have to do your own experiments
JohnDoe_71Rus has quit []
hlauer has joined #linux-sunxi
vagrantc has joined #linux-sunxi
Asara has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
rm_ has joined #linux-sunxi
<rm_>
hello
<rm_>
installed Debian on a Mele M5 (A20) just now, some random things come to mind to ask
<rm_>
e.g. why the A20 is clocked at only up to 960 MHz in mainline kernel DTBs