00:05
<
fALSO >
seems that something broke "reboot" on latest linus kernel
00:05
<
fALSO >
will need to confirm, seems so
00:06
<
fALSO >
rebooting again
00:06
popolon has quit [Quit: WeeChat 2.4]
00:08
<
fALSO >
ignore.... it was something on my side
00:08
<
fALSO >
Linux orangepipc 5.2.0-rc3-00024-g788a024921c4 #40 SMP Tue Jun 4 00:48:58 WEST 2019 armv7l GNU/Linux
00:21
vagrantc has quit [Quit: leaving]
00:38
bong has joined #linux-sunxi
00:40
bong has quit [Client Quit]
00:47
techcap has joined #linux-sunxi
00:47
techcap has quit [Client Quit]
00:48
techcap has joined #linux-sunxi
00:52
<
megi >
jernej: let me know, so that I can update the posted patches
01:06
techcap has quit [Quit: Page closed]
01:23
suprothunderbolt has joined #linux-sunxi
02:03
sunshavi has quit [Remote host closed the connection]
02:05
cnxsoft has joined #linux-sunxi
02:09
Andy-D has quit [Ping timeout: 258 seconds]
02:13
arc_phasor has joined #linux-sunxi
02:13
arc_phasor has left #linux-sunxi [#linux-sunxi]
02:13
Andy-D has joined #linux-sunxi
02:31
Andy-D has quit [Ping timeout: 272 seconds]
02:47
sunshavi has joined #linux-sunxi
03:57
megi has quit [Ping timeout: 245 seconds]
03:58
<
MoeIcenowy >
paulk-leonov: what's your V3's DDR frequency?
03:59
<
MoeIcenowy >
S3 BSP claims 696MHz, but I think this number is quite crazy
04:04
lurchi_ has joined #linux-sunxi
04:06
ganbold has quit [Quit: Leaving]
04:06
ganbold has joined #linux-sunxi
04:07
lurchi__ has quit [Ping timeout: 248 seconds]
04:19
OutBackDingo has quit [Ping timeout: 272 seconds]
04:46
dddddd has quit [Remote host closed the connection]
05:04
selfbg has joined #linux-sunxi
05:09
JohnDoe_71Rus has joined #linux-sunxi
05:19
Putti has joined #linux-sunxi
05:24
kaspter has quit [Remote host closed the connection]
05:24
kaspter has joined #linux-sunxi
05:24
BenG83_ has joined #linux-sunxi
05:27
BenG83 has quit [Ping timeout: 258 seconds]
05:30
OutBackDingo has joined #linux-sunxi
05:57
Putti has quit [Ping timeout: 268 seconds]
06:06
lurchi_ has quit [Read error: Connection reset by peer]
06:07
lurchi__ has joined #linux-sunxi
06:10
reinforce has joined #linux-sunxi
06:11
<
DuClare >
MoeIcenowy: Why do you think it's crazy?
06:12
lurchi__ has quit [Read error: Connection reset by peer]
06:12
lurchi_ has joined #linux-sunxi
06:12
lurchi_ is now known as lurchi__
06:13
BenG83_ has quit [Ping timeout: 272 seconds]
06:18
lurchi__ has quit [Read error: Connection reset by peer]
06:18
lurchi__ has joined #linux-sunxi
06:20
<
paulk-leonov >
MoeIcenowy: yeah IIRC it's pretty high
06:21
<
paulk-leonov >
I set 360 for mine
06:21
<
paulk-leonov >
not sure what to make of it
06:23
<
paulk-leonov >
so looks like 696 is legit, but I don't think I've tried it sofar
06:23
<
paulk-leonov >
more like 648 MHz
06:31
tllim has quit [Read error: Connection reset by peer]
06:36
ldevulder_ is now known as ldevulder
06:40
tllim has joined #linux-sunxi
06:46
AneoX has joined #linux-sunxi
06:49
psydroid1 has quit [Changing host]
06:49
psydroid1 has joined #linux-sunxi
06:49
psydroid1 has joined #linux-sunxi
06:54
MoeIcenowy_PB11 has joined #linux-sunxi
07:00
<
MoeIcenowy >
paulk-leonov: 648MHz seems reasonable, but 696MHz is too high -- Allwinner claims DDR3-1333 for their 40nm SoCs
07:02
MoeIcenowy_PB11 has quit [Changing host]
07:02
MoeIcenowy_PB11 has joined #linux-sunxi
07:03
MoeIcenowy_PB11 has quit [Quit: Leaving.]
07:05
MoeIcenowy_PB11 has joined #linux-sunxi
07:05
MoeIcenowy_PB11 has quit [Client Quit]
07:05
MoeIcenowy_PB11 has joined #linux-sunxi
07:06
<
MoeIcenowy_PB11 >
paulk-leonov: thanks, I think I will choose 648 as default value when introducing V3/S3 support to U-Boot
07:08
<
DuClare >
Hmm you got a wip repo with s3 support somewhere?
07:08
<
DuClare >
I'm running s3 off of mainline but I guess it doesn't make best use of the hardware
07:12
<
paulk-leonov >
MoeIcenowy_PB11: feel free to CC me for the U-Boot patches
07:12
<
paulk-leonov >
I also have to add V3 support eventually
07:15
yann has quit [Remote host closed the connection]
07:17
<
MoeIcenowy_PB11 >
DuClare: I just received the board yesterday.
07:20
diego_r has joined #linux-sunxi
07:31
msimpson has quit [Read error: Connection reset by peer]
07:31
msimpson has joined #linux-sunxi
07:36
lurchi__ is now known as lurchi_
07:46
msimpson has quit [Remote host closed the connection]
07:46
msimpson has joined #linux-sunxi
07:58
MoeIcenowy_PB11 has quit [Remote host closed the connection]
08:05
tnovotny has joined #linux-sunxi
08:44
jaganteki has joined #linux-sunxi
08:50
msimpson has quit [Remote host closed the connection]
08:50
msimpson has joined #linux-sunxi
08:51
<
libv >
wens: " where Samsung SLSI will license graphics IP from AMD for use in mobile GPUs."
08:52
<
libv >
amd has been sueing everyone these past few years
08:53
<
libv >
they were the ones claiming that because of patent reasons documents had to spend years with lawyers
08:54
<
wens >
libv: really? didn't hit the news # sueing everyone
08:54
<
libv >
but that was all just excuses for mr bridgman not doing his actual job and instead trying to build up two separate teams
08:54
<
libv >
yeah, i was amazed too
08:54
<
libv >
i have been contacted by a lawyer once in my whole 16y graphics carreer
08:54
<
libv >
somewhere 2015, with the promise of many hours of work
08:55
<
libv >
and it ended up being a phonecall with a lawyer where i was asked what other techniques apart from the public ones, and hard work/clue, i used for REing mali
08:56
<
libv >
and that was the end of that conversation, that was all they wanted to know
08:56
<
libv >
somewhere last year, i googled the lawfirm, and found that amd had successfully sued some users of mali hw
08:56
<
MoeIcenowy >
paulk-leonov: have you tested gadget mode after you modifying the USB code?
08:57
<
MoeIcenowy >
for V3 series
08:57
<
libv >
for a patent that superficially read like tile rendering
08:57
<
libv >
so this line early on is just that
08:58
<
libv >
my feeling is (note, feeling), that amd has only just shied away from sueing imagination, as imagination was likely doing tile based rendering before the patent was filed, and that there is some tiny distinction in the seemingly broad patent
08:58
<
EmilKarlson >
those silly patents
08:59
<
libv >
now, all these companies are always claiming that they do not want details to be visible to the public
08:59
<
libv >
but this was not about details
08:59
<
libv >
this was about the basic rendering segmentation strategy
09:00
<
libv >
and once you read the info about mali and other engines, and you have this patent and are intent on sueing, you can find out the details in what tv-series call discovery
09:06
<
KotCzarny >
kicking the lying?
09:06
a|3x has quit [Read error: Connection reset by peer]
09:07
a|3x has joined #linux-sunxi
09:10
<
paulk-leonov >
MoeIcenowy: yes, it was broken before my changes and the changes made it worj
09:10
<
paulk-leonov >
work
09:10
<
paulk-leonov >
also on H3
09:10
<
paulk-leonov >
I think I still have pending patches in U-Boot for that
09:14
Mangy_Dog has joined #linux-sunxi
09:19
<
libv >
unified shaders
09:20
<
libv >
that was the base of the patent claim
09:20
<
libv >
my poor old synapses
09:20
<
libv >
arm mali based hw users got sued for unified shaders
09:20
<
libv >
and it's soo fundamental to modern day rendering that everyone can get sued
09:21
<
libv >
the details are not the big issue
09:25
<
MoeIcenowy >
paulk-leonov: I built linux-next
09:25
<
MoeIcenowy >
and gadget seems to be not working
09:25
<
MoeIcenowy >
(I use FEL to load the kernel
09:34
suprothunderbolt has quit [Ping timeout: 245 seconds]
10:30
afaerber has quit [Quit: Leaving]
10:43
gaston_ has joined #linux-sunxi
10:44
afaerber has joined #linux-sunxi
10:57
dddddd has joined #linux-sunxi
11:15
Andy-D has joined #linux-sunxi
11:17
Asara has quit [Ping timeout: 246 seconds]
11:22
Asara has joined #linux-sunxi
11:35
kaspter has quit [Ping timeout: 252 seconds]
11:36
kaspter has joined #linux-sunxi
11:37
megi has joined #linux-sunxi
12:11
ldevulder has quit [Remote host closed the connection]
12:15
sunshavi has quit [Ping timeout: 245 seconds]
12:19
ldevulder has joined #linux-sunxi
12:19
camus has joined #linux-sunxi
12:19
kaspter has quit [Read error: Connection reset by peer]
12:19
camus is now known as kaspter
12:32
lurchi_ is now known as lurchi__
12:37
lurchi__ is now known as lurchi_
12:49
Asara has quit [Ping timeout: 248 seconds]
12:53
kaspter has quit [Quit: kaspter]
12:55
kaspter has joined #linux-sunxi
12:57
afaerber has quit [Quit: Leaving]
12:58
cnxsoft1 has joined #linux-sunxi
13:00
cnxsoft has quit [Ping timeout: 248 seconds]
13:03
airwind has quit [Quit: airwind]
13:19
afaerber has joined #linux-sunxi
13:20
kaspter has quit [Ping timeout: 258 seconds]
13:23
jaganteki has quit [Ping timeout: 256 seconds]
13:42
Andy-D has quit [Ping timeout: 272 seconds]
13:46
Asara has joined #linux-sunxi
13:49
tllim has quit [Read error: Connection reset by peer]
13:52
BenG83_ has joined #linux-sunxi
13:53
tllim has joined #linux-sunxi
14:00
selfbg has quit [Remote host closed the connection]
14:01
jbrown has quit [Remote host closed the connection]
14:04
afaerber has quit [Quit: Leaving]
14:04
jbrown has joined #linux-sunxi
14:06
ynezz has quit [Ping timeout: 246 seconds]
14:07
afaerber has joined #linux-sunxi
14:12
popolon has joined #linux-sunxi
14:28
ynezz has joined #linux-sunxi
14:39
JohnDoe_71Rus has joined #linux-sunxi
14:41
reinforce has quit [Quit: Leaving.]
15:00
jernej has joined #linux-sunxi
15:01
diego_ has joined #linux-sunxi
15:01
diego_r has quit [Ping timeout: 252 seconds]
15:01
<
jernej >
martinayotte: Thanks, I'll test this soon. Anyway, that would suggest timing/initialozation issue.
15:02
<
megi >
jernej: most probably
15:04
Putti has joined #linux-sunxi
15:07
<
megi >
btw, during reboot I see phy leds blink, so phy is powered during reboot, and u-boot stages
15:07
<
megi >
then kernel maybe shuts it down and starts it again
15:08
<
megi >
maybe this is where the issue arrises (the time between regulator off/on)
15:09
<
megi >
maybe the phy doesn't power down completely if the off time is short
15:09
<
megi >
and during powerup is in undefined state
15:10
cnxsoft has joined #linux-sunxi
15:10
<
jernej >
building it as a module delays probing, so yeah, that may be it
15:10
cnxsoft has quit [Client Quit]
15:11
<
MoeIcenowy >
paulk-leonov: the board might have bug -- when I plug the microUSB port to the PC, the ID pin status is low
15:11
<
MoeIcenowy >
I remember low means host mode
15:11
cnxsoft1 has quit [Ping timeout: 245 seconds]
15:12
<
jernej >
megi: other solution would be to shut down non-essential power regulators on AXP805 before reboot
15:12
<
megi >
anyway, I use a builtin module and it works for me despite this, but I may just be lucky by having the right timing due to kernel config
15:13
<
megi >
yeah, but how?
15:14
<
jernej >
if drivers behave correctly, they would need to do that anyway at unload time
15:15
<
jernej >
or maybe for built-in drivers this never happens
15:16
<
MoeIcenowy >
megi: I don't think the kernel doesn't shut down the phy
15:16
<
MoeIcenowy >
the regulator shut down process is only done before entering userspace
15:16
<
MoeIcenowy >
and I think dwmac-sun8i probes before entering userspace
15:17
<
MoeIcenowy >
s/only done before/only done just before/
15:18
<
megi >
the problem then may be in the reset timing of the phy, as the dts has the reset signal configured
15:18
<
megi >
an this doesn't matter in case of module use, because of the poweroff of the phy
15:19
<
megi >
between userspace enter and module load
15:19
diego_r has joined #linux-sunxi
15:19
diego_ has quit [Ping timeout: 258 seconds]
15:20
jernej has quit [Ping timeout: 246 seconds]
15:20
<
MoeIcenowy >
megi: what board?
15:20
jernej__ has joined #linux-sunxi
15:20
<
MoeIcenowy >
I don't find a board with PHY reset signal defined in linux-next
15:20
<
megi >
it's a proposed patch
15:20
<
MoeIcenowy >
so does it fail on Pine H64?
15:20
<
MoeIcenowy >
(I didn
15:21
<
MoeIcenowy >
't met it
15:21
<
megi >
no idea, I don't have H64
15:21
<
megi >
jernej: you can also try just removing the reset signal configuration
15:27
reinforce has joined #linux-sunxi
15:45
jbrown has quit [Ping timeout: 258 seconds]
15:46
BenG83_ has quit [Quit: Leaving]
15:51
tnovotny has quit [Quit: Leaving]
15:57
jbrown has joined #linux-sunxi
16:00
Andy-D has joined #linux-sunxi
16:10
<
jernej__ >
I confirm that building as a module solves the issue
16:11
random_yanek has quit [Ping timeout: 272 seconds]
16:11
<
jernej__ >
or better said, workaround works
16:12
<
jernej__ >
megi: if I remove reset config from DT, then it won't work at all
16:13
<
megi >
so what's in the dmesg with my original tree?
16:14
<
jernej__ >
I didn't try it yet
16:15
<
jernej__ >
I will shortly
16:16
xade has joined #linux-sunxi
16:17
random_yanek has joined #linux-sunxi
16:18
jernej__ has quit [Quit: Konversation terminated!]
16:20
jernej__ has joined #linux-sunxi
16:21
jernej__ is now known as jernej
16:29
diego_r has quit [Ping timeout: 245 seconds]
16:32
<
jernej >
megi: nothing suspicious:
http://ix.io/1KVz (please ignore CEC messages, out of tree experiment)
16:33
<
megi >
Cannot attach to PHY (error: -19)
16:33
<
megi >
MDIO device at address 1 is missing.
16:33
<
megi >
seems suspicious
16:33
<
jernej >
oh, I missed that :)
16:34
<
jernej >
that's why I post dmesg anyway :)
16:35
<
megi >
hmm, that MDIO device missing seems quite weird, and early
16:38
<
megi >
looks like some silent phy initialization error
16:43
<
megi >
you may try marking the regulators always on, to see if it's that
16:49
xade has quit [Quit: Page closed]
16:53
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
17:03
jernej__ has joined #linux-sunxi
17:05
<
jernej__ >
megi: where did you get bluetooth firmware?
17:05
jernej has quit [Ping timeout: 248 seconds]
17:05
<
megi >
check the commit message for the dts patch
17:10
vagrantc has joined #linux-sunxi
17:10
<
anarsoul >
maybe phy regulator is missing?
17:12
<
megi >
anarsoul: why would it?
17:12
<
megi >
trouble only starts after reboot
17:12
<
anarsoul >
megi: I haven't checked dts, so no idea
17:14
jernej__ is now known as jernej
17:14
ganbold has quit [Remote host closed the connection]
17:15
f0xx has joined #linux-sunxi
17:17
ganbold has joined #linux-sunxi
17:21
jernej has quit [Quit: Konversation terminated!]
17:22
jernej has joined #linux-sunxi
17:25
ganbold has quit [Quit: Leaving]
17:27
jernej__ has joined #linux-sunxi
17:27
jernej has quit [Ping timeout: 248 seconds]
17:27
jernej__ is now known as jernej
17:33
megi has quit [Ping timeout: 268 seconds]
17:46
megi has joined #linux-sunxi
17:48
sunshavi has joined #linux-sunxi
17:56
jernej has quit [Quit: Konversation terminated!]
17:57
jernej has joined #linux-sunxi
18:15
<
jernej >
megi: I have correct bluetooth firmware which apparently gets loaded but hcitool reports "no such device"
18:17
\\Mr_C\\ has joined #linux-sunxi
18:27
<
megi >
what does btmgmt public-addr 00:03:19:9e:8b:00 do
18:28
<
megi >
after running it you should be able to see the device in bluetoothctl
18:31
<
mru >
is it one of those evil devices without a valid public mac address?
18:31
lurchi_ is now known as lurchi__
18:31
<
mru >
how are you supposed to use those sanely?
18:32
<
mru >
buy your own address block and somehow manage them for all devices?
18:32
<
megi >
dunno, create a random one?
18:32
<
mru >
bt doesn't allow that
18:32
<
mru >
ethernet has the "locally administered" bit
18:32
<
megi >
policy vs. technical reason?
18:33
<
mru >
of course you
_can_ just make something up and hope it doesn't collide with some other device
18:33
<
mru >
but then you're in violation of the spec
18:33
<
mru >
at least if I've understood it correctly
18:35
<
mru >
with BLE there's something called a "static random" address
18:36
<
mru >
but BR/EDR doesn't have that
18:36
<
mru >
and it seems to be mysteriously broken in the kernel or bluez
18:42
<
jernej >
megi: btmgmt not found
18:42
<
jernej >
please note that I'm running this on constrained distro (LibreELEC), without package manager
18:42
<
jernej >
s/constrained/minimal/
18:43
<
megi >
I dunno if hcitool can be used to set the address
18:44
<
jernej >
maybe I'm missing some patches? I'm using your 5.1 branch
18:44
<
mru >
I couldn't find a way to do it with hcitool
18:44
<
megi >
I don't think so, it works fine, you just need the right tool to set the address
18:45
<
KotCzarny >
hciconfig ?
18:45
<
jernej >
ah yes, hciconfig shows device
18:46
<
KotCzarny >
but i think you still need some daemons to manage connections
18:47
<
jernej >
yeah, I have those
18:47
<
jernej >
"hciconfig hci0 up" produced "Can't init device hci0: Operation not supported (95)"
18:48
<
megi >
you need to set the address first
18:48
<
mru >
and you need btmgmt to do that
18:49
<
KotCzarny >
bccmd ?
18:50
<
mru >
don't follow those instructions
18:50
<
mru >
they are old and specific to one vendor
18:50
<
KotCzarny >
yeah, bluez 3x
18:50
<
mru >
just use btmgmt
18:51
<
mru >
for bluetooth values of work
18:51
<
mru >
i.e. pretty low
18:54
<
jernej >
ok, this works
18:54
<
jernej >
I found that btmgmt is build as part of bluez, just not included in final image
18:54
<
jernej >
so I just copied it over
18:55
<
mru >
yeah, it builds hundreds of little tools that don't get installed
18:55
<
mru >
most of them with slightly overlapping functionality and none of them quite right
18:55
<
jernej >
given that LibreELEC is sometimes picky what gets into final image and what not, I'm not surprised it's not included
18:55
<
jernej >
to keep image size down
18:56
<
jernej >
anyway, should kernel detect that default address is set and generate one random?
18:56
<
mru >
as I said, random isn't permitted
18:57
<
jernej >
even if it doesn't conform to any oui, why should other devices bother with that?
18:57
<
KotCzarny >
starting address with E1:EC:... might be funny
18:57
<
mru >
I didn't write the spec
18:58
<
jernej >
I worked with BLE LE at my previous job and I'm pretty sure Android phones randomize MAC addresses at some points to improve privacy
18:59
<
mru >
yes, BLE supports that
18:59
<
mru >
BLE is basically a whole new spec
18:59
<
mru >
bluetooth is insane
18:59
<
jernej >
I know, I have to studied it
18:59
<
jernej >
this is similar as newer USB standards
19:00
<
mru >
usb is quite sane by comparison
19:00
<
jernej >
thunderbolt 3 is new USB 4
19:00
<
mru >
usb 3.2 is 548 pages
19:00
<
mru >
BT5 "core" is 2822 pages
19:01
<
KotCzarny >
how much of it is copy paste with tiny changes?
19:01
<
mru >
tiny but
_very important_ changes
19:02
<
mru >
and every vendor missed one or more in unique combinations
19:03
<
mru >
hmm, the usb type-c plug spec is 241 pages
19:04
<
mru >
pcie 3.0 is 860 pages
19:04
msimpson has quit [Remote host closed the connection]
19:06
msimpson has joined #linux-sunxi
19:08
msimpson_ has joined #linux-sunxi
19:08
msimpson has quit [Remote host closed the connection]
19:08
<
jernej >
it was fun to find bug in Nordic BLE stack in combination with Samsung phones
19:08
<
jernej >
as you said, everyone miss something
19:09
msimpson_ has quit [Remote host closed the connection]
19:10
msimpson has joined #linux-sunxi
19:12
msimpson has quit [Remote host closed the connection]
19:12
msimpson has joined #linux-sunxi
19:13
msimpson has quit [Remote host closed the connection]
19:23
sunshavi has quit [Ping timeout: 248 seconds]
19:23
jstein_ has joined #linux-sunxi
19:23
jstein_ is now known as jstein
19:23
dev1990 has quit [Ping timeout: 246 seconds]
19:40
afaerber has quit [Quit: Leaving]
19:57
<
fALSO >
sirs, just flashed the latest uboot , everything boots
19:57
<
fALSO >
but noticed a weird error
19:58
<
fALSO >
ERROR: USB-error: DATAOVERRUN: The amount of data returned by the endpoint exceeded
19:58
<
fALSO >
bla bla bla
19:58
<
fALSO >
i only have a usb keyboard connected to it
19:59
<
vagrantc >
going to have to type a lot slower!
19:59
<
mru >
maybe you're typing too fast :)
19:59
<
fALSO >
let me try again witht the keyboard disconnected
20:02
<
fALSO >
yap, without the keyboard: no errors
20:03
<
fALSO >
Linux version 5.2.0-rc3-00024-g788a024921c4 (root@fishy) (gcc version 9.1.0 (Gentoo 9.1.0-r1 p1.1)) #40 SMP Tue Jun 4 00:48:58 WEST 2019
20:09
jernej has quit [Quit: Konversation terminated!]
20:10
jernej has joined #linux-sunxi
20:29
iamfrankenstein has joined #linux-sunxi
20:46
iamfrankenstein has quit [Quit: iamfrankenstein]
20:47
nashpa has quit [Ping timeout: 258 seconds]
20:49
nashpa has joined #linux-sunxi
20:56
nashpa has quit [Ping timeout: 245 seconds]
20:56
nashpa has joined #linux-sunxi
21:01
f0xx has quit [Ping timeout: 244 seconds]
21:05
jbrown has quit [Ping timeout: 252 seconds]
21:13
MangyDog has joined #linux-sunxi
21:14
nashpa has quit [Ping timeout: 248 seconds]
21:16
jbrown has joined #linux-sunxi
21:17
nashpa has joined #linux-sunxi
21:17
Mangy_Dog has quit [Ping timeout: 248 seconds]
21:21
nashpa has quit [Ping timeout: 258 seconds]
21:23
nashpa has joined #linux-sunxi
21:24
msimpson has joined #linux-sunxi
21:26
msimpson_ has joined #linux-sunxi
21:27
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
21:28
msimpson_ has quit [Max SendQ exceeded]
21:28
msimpson has quit [Ping timeout: 248 seconds]
21:30
msimpson has joined #linux-sunxi
21:32
nashpa has quit [Ping timeout: 245 seconds]
21:33
msimpson has quit [Max SendQ exceeded]
21:35
nashpa has joined #linux-sunxi
21:37
dev1990 has joined #linux-sunxi
22:07
reinforce has quit [Quit: Leaving.]
22:17
rellla has quit [Ping timeout: 246 seconds]
22:18
a|3x has quit [Ping timeout: 248 seconds]
22:18
ldevulder_ has joined #linux-sunxi
22:18
a|3x has joined #linux-sunxi
22:21
ldevulder has quit [Ping timeout: 252 seconds]
22:27
jstein has quit [Quit: quit]
22:31
arc_phasor has joined #linux-sunxi
22:36
<
arc_phasor >
hi, is there anything special i need to do to support multi-master i2c on allwinner r16?
22:39
MangyDog has quit [Ping timeout: 248 seconds]
22:43
lurchi__ is now known as lurchi_
22:47
jernej__ has joined #linux-sunxi
22:49
<
arc_phasor >
i'm seeing " i2c i2c-1: mv64xxx: I2C bus locked, block: 1,", only when my stm32 is on and acting as a master
22:49
jernej has quit [Ping timeout: 248 seconds]
22:57
aalm has joined #linux-sunxi
22:58
rellla has joined #linux-sunxi
23:00
<
karlp >
well, for starters, are you
_realllly_ sure your stm32 i2c multi master is working well?
23:00
<
karlp >
there's a lot of gotchas there.
23:02
<
arc_phasor >
karlp: i'm not sure, i'm using the HAL layer
23:02
<
arc_phasor >
well whatever is the highest layer of the stm32 drivers
23:12
<
karlp >
I'v eno idea about how linux i2c multi mster works, I'm just saying there's a pile of gotchas on the stm32 side too :)
23:17
lurchi_ is now known as lurchi__
23:31
default__ has joined #linux-sunxi
23:32
popolon has quit [Quit: WeeChat 2.4]
23:34
ldevulder_ has quit [Ping timeout: 248 seconds]
23:35
jernej__ has quit [Ping timeout: 248 seconds]