00:06
ninolein has quit [Ping timeout: 264 seconds]
00:06
ninolein_ has joined #linux-sunxi
00:15
warpme_ has quit [Quit: warpme_]
00:16
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
00:16
vagrantc has quit [Quit: leaving]
00:19
jstefanop has quit [Remote host closed the connection]
00:19
jstefanop has joined #linux-sunxi
00:25
leio has joined #linux-sunxi
00:34
lurchi__ has quit [Quit: Konversation terminated!]
00:34
lurchi_ has joined #linux-sunxi
00:34
lurchi_ is now known as lurchi__
00:40
lurchi_ has joined #linux-sunxi
00:41
\\Mr_C\\ has joined #linux-sunxi
00:43
lurchi__ has quit [Ping timeout: 246 seconds]
00:52
lurchi_ has quit [Quit: Konversation terminated!]
00:53
lurchi_ has joined #linux-sunxi
00:53
lurchi_ is now known as lurchi__
01:02
megi has quit [Ping timeout: 268 seconds]
01:02
ninolein_ has quit [Ping timeout: 250 seconds]
01:03
ninolein has joined #linux-sunxi
01:05
veremitz has joined #linux-sunxi
01:15
swiftgeek has quit [Ping timeout: 244 seconds]
01:22
camus has joined #linux-sunxi
01:22
kaspter has quit [Ping timeout: 245 seconds]
01:22
camus is now known as kaspter
01:30
suprothunderbolt has joined #linux-sunxi
01:31
deesix has quit [Ping timeout: 246 seconds]
01:31
deesix has joined #linux-sunxi
01:57
sunshavi has joined #linux-sunxi
02:18
<
MoeIcenowy >
jernej: I think no
02:18
<
MoeIcenowy >
do you really have a half DQ H6 board?
02:18
cnxsoft has joined #linux-sunxi
02:45
swiftgeek has joined #linux-sunxi
02:48
aalm has quit [Quit: xyz 2.3]
02:54
jbrown has quit [Ping timeout: 252 seconds]
02:54
jbrown has joined #linux-sunxi
02:58
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
03:01
libv has quit [Ping timeout: 245 seconds]
03:01
libv has joined #linux-sunxi
03:28
TheSeven has quit [Ping timeout: 264 seconds]
03:28
[7] has joined #linux-sunxi
03:31
wens has quit [Ping timeout: 258 seconds]
03:32
wens has joined #linux-sunxi
03:55
cnxsoft has quit [Ping timeout: 245 seconds]
04:01
cristian_c has joined #linux-sunxi
04:03
cristian__c has quit [Ping timeout: 246 seconds]
04:11
cnxsoft has joined #linux-sunxi
04:27
sunshavi has quit [Read error: Connection reset by peer]
04:28
sunshavi has joined #linux-sunxi
04:28
dddddd has quit [Read error: Connection reset by peer]
04:33
ganbold has quit [Read error: Connection reset by peer]
04:45
_whitelogger has joined #linux-sunxi
04:47
JohnDoe_71Rus has joined #linux-sunxi
04:47
ganbold has joined #linux-sunxi
04:51
lurchi_ has joined #linux-sunxi
04:54
lurchi__ has quit [Ping timeout: 246 seconds]
05:06
Net147 has joined #linux-sunxi
05:22
jstefanop has quit [Remote host closed the connection]
05:24
vagrantc has joined #linux-sunxi
05:28
jstefanop has joined #linux-sunxi
05:37
jstefanop has quit [Ping timeout: 245 seconds]
05:42
Nemo_bis has joined #linux-sunxi
05:43
<
jernej >
MoeIcenowy: One of LE user has Tanix TX6 mini STB, which I'm pretty sure it has half DQ
05:46
<
jernej >
that 1 in dram_para2 means half DQ, right?
05:46
jstefanop has joined #linux-sunxi
06:02
<
MoeIcenowy >
jernej: do you have PCB photo of it?
06:02
<
MoeIcenowy >
dual sided
06:04
<
jernej >
note that it also uses DDR3, but together with apritzel we added support for it
06:04
<
jernej >
Tanix TX6 (without "mini") uses same DDR3 chips, but it works fine (I have that STB)
06:05
<
jernej >
how do you know if it is half DQ from images?
06:10
jstefano_ has joined #linux-sunxi
06:12
jstefanop has quit [Ping timeout: 246 seconds]
06:15
jstefanop has joined #linux-sunxi
06:15
Net147 has quit [Read error: Connection reset by peer]
06:17
jstefano_ has quit [Ping timeout: 268 seconds]
06:17
Net147 has joined #linux-sunxi
06:29
Putti has joined #linux-sunxi
06:35
vagrantc has quit [Quit: leaving]
06:38
<
MoeIcenowy >
jernej: by the size of the DRAM chips
06:39
<
MoeIcenowy >
jernej: BTW do you remember the 0x03006100 problem?
06:39
<
MoeIcenowy >
this is an interesting device -- it uses H6 CV200-OS
06:39
[7] has quit [Ping timeout: 252 seconds]
06:40
<
MoeIcenowy >
according to Wink it's some bonding id of the subversion of the chip
06:40
<
jernej >
oh, so it may actually have bonding id 3
06:40
<
MoeIcenowy >
had you observed 0x03006100 difference w/ Pine H64?
06:40
<
MoeIcenowy >
Pine H64 uses H6 V200-AWIN
06:40
<
jernej >
I have to add this printout in next test version
06:41
<
MoeIcenowy >
there're 3 known H6 subversions
06:41
<
MoeIcenowy >
V200-AWIN (seen in Pine H64)
06:41
<
jernej >
no, all devices I have have bonding id 7
06:41
<
MoeIcenowy >
V200-AI (seen in OPi3)
06:41
<
MoeIcenowy >
CV200-OS (seen in this device)
06:41
<
jernej >
do you know what is the difference?
06:42
<
jernej >
between all this variants?
06:42
<
MoeIcenowy >
according to Wink they're selected
06:42
<
MoeIcenowy >
according to the bin
06:42
<
MoeIcenowy >
BTW this board doesn't look like half DQ
06:42
<
MoeIcenowy >
it has 4 8-bit DDR3 chips
06:43
<
MoeIcenowy >
4*8=32
06:43
TheSeven has joined #linux-sunxi
06:43
<
jernej >
half DQ would be only when 2 8-bit chips would be used?
06:43
<
MoeIcenowy >
although it's theortically possible to be dual rank 2*8
06:43
<
MoeIcenowy >
but I don't think any OTT vendor will use it
06:44
<
MoeIcenowy >
because half DQ will decrease the decoding capability of the board
06:44
<
jernej >
but why then dram_para2 suggest half DQ?
06:44
<
MoeIcenowy >
due to it halves the memory bandwidth
06:44
<
MoeIcenowy >
jernej: the dram_para is nonsense in FEX
06:44
<
MoeIcenowy >
it will gets overrided in H6 libdram
06:45
<
MoeIcenowy >
if autodetecting is enabled
06:49
jstefanop has quit [Remote host closed the connection]
06:50
jstefanop has joined #linux-sunxi
06:50
<
jernej >
yeah, I think you're right, autodetecting seems to be enabled
06:51
AneoX has joined #linux-sunxi
06:55
jstefanop has quit [Ping timeout: 272 seconds]
07:12
cristian__c has joined #linux-sunxi
07:14
cristian_c has quit [Ping timeout: 246 seconds]
07:16
cristian__c has quit [Ping timeout: 246 seconds]
07:16
cristian_c has joined #linux-sunxi
07:49
jstein has joined #linux-sunxi
08:32
Mangy_Dog has joined #linux-sunxi
09:26
freemangordon has quit [Ping timeout: 258 seconds]
09:57
Gerwin_J has joined #linux-sunxi
09:57
<
jernej >
MoeIcenowy: Do you have any description what DRAM parameters in fex represents? I mean bit by bit.
10:02
<
MoeIcenowy >
jernej: no
10:02
<
MoeIcenowy >
but if you want sth
10:02
<
MoeIcenowy >
I can ask Wink
10:03
<
jernej >
yeah, it would be nice to have it explained on wiki
10:07
<
jernej >
MoeIcenowy: How banks fits into DRAM configurations? I see H6 code supports only 8 banks for now, but controller supports also only 4 banks.
10:08
<
jernej >
what are the chances to see 4 banks configuration?
10:09
<
MoeIcenowy >
jernej: check the number of CS (chip select) pin
10:09
<
MoeIcenowy >
on sorry it's rank, not bank
10:09
<
MoeIcenowy >
bank is the case of internal DDR structure
10:09
<
MoeIcenowy >
for all DDR3/LPDDR3 it's 8 banks
10:09
<
MoeIcenowy >
4 banks is for DDR2
10:09
<
MoeIcenowy >
the V3s DDR2 is 4 banks
10:10
<
jernej >
so there is no point to look into that for now
10:10
<
MoeIcenowy >
and I don't think there would be board w/ H6+DDR2
10:10
<
MoeIcenowy >
H6 is advertised for decoding capability
10:11
<
MoeIcenowy >
use low-bandwidth memory will severely break it
10:12
<
MoeIcenowy >
in fact I had never seen Allwinner Cortex-A boards w/ dedicated DDR2
10:12
<
MoeIcenowy >
since A10
10:12
<
jernej >
I hope we would see DDR4 based H6 board
10:12
<
MoeIcenowy >
DDR4 code will be difficult
10:13
<
MoeIcenowy >
DDR4 is more complex than {,LP}DDR3
10:13
<
jernej >
if we cracked (LP)DDR3, we can DDR4 too
10:15
<
jernej >
BTW, yesterday I found definition of DX[0-4].RSR[0] bit in qemu code for Zynq US+
10:15
<
MoeIcenowy >
qemu...
10:15
<
MoeIcenowy >
interesting
10:16
<
jernej >
it just says QSGERR
10:16
<
jernej >
which is kind of expected :)
10:17
<
MoeIcenowy >
but I didn't expect QEMU to have DDR code...
10:17
<
jernej >
I think it's there so unmodified software can run
10:18
<
jernej >
but it's not really needed
10:19
<
MoeIcenowy >
jernej: yes, the current Allwinner emulation in QEMU is too bad
10:19
<
MoeIcenowy >
it even doesn't emulate CCU and the clock driver will fail due to many /0 error on boot
10:19
<
jernej >
I never really used qemu...
10:20
<
MoeIcenowy >
so do I, except for KVM
10:20
<
MoeIcenowy >
(oh I use qemu-user, but rarely qemu-system
10:21
Gerwin_J has quit [Quit: Gerwin_J]
10:21
<
MoeIcenowy >
(I used to run few times RISC-V kernel on QEMU, but after then I switched to HFU
10:30
<
jernej >
MoeIcenowy: Have "Half DQ" configuration influence on DRAM size calculation?
10:30
<
jernej >
e.g. should be size halved?
10:36
<
MoeIcenowy >
see my comment around the formula
10:37
<
MoeIcenowy >
(in H6
10:37
<
MoeIcenowy >
it says 32-bit (4 byte) data width
10:37
<
MoeIcenowy >
half DQ is 16-bit
10:37
<
MoeIcenowy >
so the *4 should be changed to *2 for half DQ
10:40
<
jernej >
btw, this board has half DQ, because it uses 4 4-bit chips (k4b4g0446q)
10:41
<
jernej >
only issue I have now is that only half of memory is detected (1 GiB instead of 2)
10:43
<
jernej >
ah, I never really know where that 4 came from :)
10:45
<
jernej >
and yes, that box is as cheap as it can be, it even has XR819
10:50
<
jernej >
MoeIcenowy: Could it be that due to half DQ one column less is detected?
11:23
lurchi_ is now known as lurchi__
11:25
<
MoeIcenowy >
jernej: no
11:25
<
MoeIcenowy >
half DQ is a really hardware thing
11:25
<
MoeIcenowy >
column is inside the chip
11:26
<
MoeIcenowy >
jernej: is there really 4-bit DDR3 chip?
11:26
<
MoeIcenowy >
oh there really is
11:26
<
jernej >
MoeIcenowy: in mctl_auto_detect_dram_size() you mentioned that half DQ is TODO. By that you mean mctl_core_init()?
11:27
<
jernej >
I'm just exploring why only half of RAM is detected
11:27
<
MoeIcenowy >
jernej: I think we need to detect DQ at first
11:27
<
jernej >
yes, that's done by first call to mctl_core_init().
11:27
<
MoeIcenowy >
at least before row/column
11:27
<
MoeIcenowy >
and see my comments
11:28
<
MoeIcenowy >
all my formulas assume 32-bit width
11:28
<
MoeIcenowy >
and for half DQ you need to change them
11:28
<
jernej >
yes, but I'm not sure how
11:28
<
MoeIcenowy >
do you see 1<< (blabla + blabla + const) ?
11:28
<
MoeIcenowy >
just let const be 1 less when half DQ
11:29
<
MoeIcenowy >
oh sorry
11:29
<
jernej >
aha, that's what I thought, but I wasn't sure if it's correct or not
11:29
<
MoeIcenowy >
I need to check whether all the consts need to be lowered
11:30
<
MoeIcenowy >
the address is divided into many parts in mctl_set_addrmap
11:30
<
MoeIcenowy >
I had some notes, but they used to be in my laptop's DRAM
11:30
<
MoeIcenowy >
not non-volatile
11:30
<
MoeIcenowy >
so I need to recalculate it
11:30
<
MoeIcenowy >
let me grab a manual for this IP
11:35
Mangy_Dog has quit [Ping timeout: 245 seconds]
11:38
suprothunderbolt has quit [Ping timeout: 272 seconds]
11:43
reinforce has joined #linux-sunxi
11:45
lurchi__ is now known as lurchi_
11:51
<
MoeIcenowy >
jernej: bad news
11:51
<
MoeIcenowy >
my poppler breaks
11:51
<
MoeIcenowy >
now I cannot read some PDF
11:51
<
MoeIcenowy >
including i.MX7 reference manual
11:51
<
jernej >
sorry to hear that
11:51
<
jernej >
i.MX7 has useful DRAM info?
11:51
<
MoeIcenowy >
i.MX7 uses the DW DDR controller
11:52
<
DuClare >
MoeIcenowy: Try mupdf
11:52
<
MoeIcenowy >
see the ADDRMAP registers
11:53
<
MoeIcenowy >
it's about mapping the address to different parts of the DRAM
11:54
<
jernej >
I know that libdram decrements number of columns by one if half DQ is detected
11:54
<
jernej >
I'm just not sure if this directly maps to our code?
11:56
<
jernej >
it's shifted by one for half DQ mode
11:59
<
MoeIcenowy >
jernej: yes so I think we should consider this in mctl_set_addrmap
11:59
<
MoeIcenowy >
and both consts in mctl_auto_detect_dram_size should be sub 1 for half DQ
12:03
cristian__c has joined #linux-sunxi
12:03
xes has quit [Ping timeout: 245 seconds]
12:04
cristian_c has quit [Ping timeout: 245 seconds]
12:07
<
jernej >
ok, thanks
12:07
<
jernej >
now we have to wait for confirmation if this helped or not
12:09
cristian_c has joined #linux-sunxi
12:09
<
MoeIcenowy >
jernej: it's not your device?
12:10
<
jernej >
no, one LE user has it
12:11
cristian__c has quit [Ping timeout: 248 seconds]
12:25
<
jernej >
Thanks for help!
12:36
gaston_ has joined #linux-sunxi
12:39
SopaXorzTaker has joined #linux-sunxi
12:48
<
MoeIcenowy >
jernej: why do you change the column switch in mctl_set_addrmap?
12:49
<
jernej >
I reverted this change back
12:49
cnxsoft has quit [Quit: cnxsoft]
12:50
<
jernej >
during intial patches it reported invalid number of columns, but now it should be fine
12:50
<
jernej >
*initial tests
12:51
<
MoeIcenowy >
BTW I think your rank/width detect code is still not proper
12:51
<
MoeIcenowy >
oh sorry reading patch is not my advantage
12:52
<
MoeIcenowy >
did you do any regression test on Pine H64?
12:52
<
MoeIcenowy >
BTW in the final version you should remove DXnRSR0 print
12:54
<
jernej >
not yet, probably tomorrow
12:54
<
jernej >
as I said, this is developer version of the patch
12:54
<
jernej >
I will clean it up
12:57
<
jernej >
MoeIcenowy: PineH64 4GiB is dual rank and 2 GiB version is single rank, right?
12:57
<
MoeIcenowy >
4/2 are all dual rank
12:57
<
MoeIcenowy >
1 is single
12:57
<
jernej >
oh, then I won't be able to do any good regression testing
12:58
<
MoeIcenowy >
jernej: LPDDR3 is a special situation
12:59
<
MoeIcenowy >
it has 2 CS pins per chip package
12:59
<
MoeIcenowy >
as Pine H64 has one footprint
12:59
<
MoeIcenowy >
it depends on the DRAM chip to be 2 ranks or 1 rank
12:59
cristian__c has joined #linux-sunxi
13:00
<
jernej >
ah, it seems that this latest, cleaned up patch doesn't work, invalid number of columns
13:01
<
MoeIcenowy >
jernej: so how many?
13:02
<
jernej >
final configuration is 11 columns and 16 rows
13:02
<
MoeIcenowy >
final what do you mean?
13:02
cristian_c has quit [Ping timeout: 245 seconds]
13:02
<
MoeIcenowy >
probed in struct dram_para?
13:02
<
jernej >
but it seems that during size detection this number is out of range
13:03
<
jernej >
when it's trying different combinations
13:03
<
jernej >
libdram has that default case instead of 12
13:04
<
MoeIcenowy >
jernej: do we really have any codepath to let cols go beyond 11?
13:04
jstein has quit [Quit: No Ping reply in 180 seconds.]
13:05
jstein has joined #linux-sunxi
13:05
<
MoeIcenowy >
when detecting rows we're assuming cols = 8
13:06
<
MoeIcenowy >
and when detecting cols we end when cols == 11
13:06
<
MoeIcenowy >
default is cols = 11
13:06
<
jernej >
not sure how this happens
13:06
<
jernej >
I'll add some debug output
13:06
<
MoeIcenowy >
try to set the default cols to 8 ?
13:06
<
MoeIcenowy >
jernej: I know
13:07
<
MoeIcenowy >
we need to add codepath for cols = 7 for full DQ
13:07
<
MoeIcenowy >
which equals = 8 for half DQ
13:07
<
jernej >
so although this is invalid, we have to write something in it, right?
13:07
<
MoeIcenowy >
it's valid
13:08
<
MoeIcenowy >
it's the cols = 8 for half DQ
13:08
<
jernej >
so how to configure when cols == 7? Currently I'm using code for case 12, which seems to work
13:10
<
jernej >
btw, how can we have case 12?
13:10
<
jernej >
maybe it should be 7 in the first place
13:11
<
MoeIcenowy >
yes should be 7 in the first place
13:12
<
MoeIcenowy >
the HW in fact supports 3 to 12
13:12
<
MoeIcenowy >
just append one more 0x1F to the 8 configuration
13:12
<
MoeIcenowy >
compare the configuration between 8 and 9
13:12
<
MoeIcenowy >
you will know
13:13
<
MoeIcenowy >
(one 0x1F means one column line is masked
13:14
<
MoeIcenowy >
`If set to 15, this column address bit is set to 0.` according to the Zynq UG1087
13:14
<
MoeIcenowy >
oh sorry HW supports 5 to 12
13:15
cristian_c has joined #linux-sunxi
13:15
<
MoeIcenowy >
the lower half of addrmap[2] is forced to 0
13:15
<
jernej >
so case for 12 is ok, I should add similar to that of case 8, with one 1F more, right?
13:15
<
MoeIcenowy >
addrmap[3] = 0x1F1F1F00; addrmap[4] = 0x1F1F;
13:15
<
MoeIcenowy >
for case 7
13:16
cristian__c has quit [Ping timeout: 246 seconds]
13:16
<
MoeIcenowy >
case for 12 is ok, but not used now
13:16
<
MoeIcenowy >
it's really deadcode
13:16
<
MoeIcenowy >
furtherly we may reach there by setting the upper limit in auto_detect_size to 12
13:17
<
MoeIcenowy >
but we haven't seen such a DRAM chip
13:18
<
MoeIcenowy >
the highest columns number proceeded in H3 code is 10 in fact
13:19
<
MoeIcenowy >
(11 when half DQ
13:21
dddddd has joined #linux-sunxi
13:22
<
MoeIcenowy >
jernej: in fact the addressing ability of the DRAM controller is far more than the internal bus of H6
13:23
<
jernej >
I imagine, 3 GiB is not much by today standards
13:23
<
MoeIcenowy >
I think the internal bus is designed to be 32-bit
13:23
<
jernej >
hopefully next SoC can use more RAM
13:24
<
MoeIcenowy >
they did it on A80
13:24
<
MoeIcenowy >
A80 uses LPAE feature of A7/A15
13:24
<
MoeIcenowy >
and can address 8GiB of DRAM
13:25
<
jernej >
yes, but with 64-bit cores you don't have to do that anymore
13:25
<
MoeIcenowy >
but I think AMBA components are also sold as IP cores
13:25
<
MoeIcenowy >
and Allwinner may only order 32-bit AMBA cores now
13:28
<
jernej >
I think DE2 and DE3 are ready for 40-bit addresses
13:28
<
jernej >
there is separate register which holds upper 8-bits
13:36
cristian__c has joined #linux-sunxi
13:36
warpme_ has joined #linux-sunxi
13:38
cristian_c has quit [Ping timeout: 258 seconds]
13:41
cristian_c has joined #linux-sunxi
13:43
cristian__c has quit [Ping timeout: 268 seconds]
13:44
cristian__c has joined #linux-sunxi
13:46
cristian_c has quit [Ping timeout: 268 seconds]
13:47
jstefanop has joined #linux-sunxi
13:48
cristian_c has joined #linux-sunxi
13:50
cristian__c has quit [Ping timeout: 245 seconds]
13:52
cristian__c has joined #linux-sunxi
13:52
<
MoeIcenowy >
jernej: interesting
13:52
cristian_c has quit [Ping timeout: 245 seconds]
13:55
cristian_c has joined #linux-sunxi
13:57
cristian__c has quit [Ping timeout: 246 seconds]
14:12
lurchi_ is now known as lurchi__
14:19
warpme_ has quit [Quit: warpme_]
14:21
montjoie has quit [Ping timeout: 272 seconds]
14:22
montjoie has joined #linux-sunxi
14:27
cnxsoft has joined #linux-sunxi
14:29
cnxsoft has quit [Remote host closed the connection]
14:47
<
jernej >
do you have PineH64 with 1 GiB of RAM to test this patch?
14:48
jaganteki has joined #linux-sunxi
14:56
jstefanop has quit [Remote host closed the connection]
14:56
jstefanop has joined #linux-sunxi
15:04
jstefanop has quit [Ping timeout: 245 seconds]
15:05
jstefanop has joined #linux-sunxi
15:15
jstefanop has quit [Ping timeout: 244 seconds]
15:17
lurchi__ is now known as lurchi_
15:45
Gerwin_J has joined #linux-sunxi
16:04
cristian_c has quit [Ping timeout: 258 seconds]
16:04
cristian_c has joined #linux-sunxi
16:16
lurchi_ is now known as lurchi__
16:32
Gerwin_J has quit [Quit: Gerwin_J]
16:35
lurchi__ is now known as lurchi_
16:41
jstefanop has joined #linux-sunxi
16:41
jstefanop has quit [Remote host closed the connection]
16:41
jstefanop has joined #linux-sunxi
17:22
cristian__c has joined #linux-sunxi
17:23
cristian_c has quit [Ping timeout: 258 seconds]
17:27
cristian_c has joined #linux-sunxi
17:29
cristian__c has quit [Ping timeout: 245 seconds]
17:32
cristian_c has quit [Ping timeout: 258 seconds]
17:33
cristian_c has joined #linux-sunxi
17:38
<
z3ntu >
Hi, does somebody know how to fix the error `dwmac-sun8i 1c30000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)` ?
17:43
indy has joined #linux-sunxi
17:53
<
MoeIcenowy >
z3ntu: what SoC and what device?
17:54
<
z3ntu >
MoeIcenowy: A64, pinephone devkit
17:54
<
MoeIcenowy >
did you power up the PHY?
17:54
<
MoeIcenowy >
is the LEDs on the Ethernet port lit up?
17:54
<
z3ntu >
Yes both leds on the port are blinking
18:01
jstefanop has quit [Remote host closed the connection]
18:27
<
MoeIcenowy >
z3ntu: are you sure your PHY address is right?
18:29
<
z3ntu >
MoeIcenowy: Funnily enough, after applying some patches for dsi and rebooting, ethernet is working now...
18:34
BenG83 has joined #linux-sunxi
18:44
shfil has joined #linux-sunxi
18:48
cristian__c has joined #linux-sunxi
18:50
cristian_c has quit [Ping timeout: 268 seconds]
18:51
xes has joined #linux-sunxi
18:58
cristian_c has joined #linux-sunxi
19:00
cristian__c has quit [Ping timeout: 258 seconds]
19:02
xes has quit [Quit: bye..]
19:03
cristian__c has joined #linux-sunxi
19:05
cristian_c has quit [Ping timeout: 268 seconds]
19:06
xes has joined #linux-sunxi
19:16
jbrown has quit [Ping timeout: 245 seconds]
19:31
Mangy_Dog has joined #linux-sunxi
19:32
jstefanop has joined #linux-sunxi
19:36
<
z3ntu >
jaganteki: I'm trying to rebase the pinephone devkit kernel (currently 5.1-rc7) onto 5.2-rc6 using your v10 dsi patch set (and 'dsi: Add has_mod_clk quirk', 'dsi: Add Allwinner A64 MIPI DSI support' & 'a64: Add MIPI DSI pipeline' from v9) but the result is that the display is blinking fast and there's "vblank wait timed out" in the dmesg
19:37
jstefanop has quit [Ping timeout: 248 seconds]
19:44
OutBackDingo has quit [Read error: Connection reset by peer]
19:45
OutBackDingo has joined #linux-sunxi
19:49
jstefanop has joined #linux-sunxi
19:50
night199uk has joined #linux-sunxi
19:50
night199uk has joined #linux-sunxi
19:50
night199uk has quit [Changing host]
19:53
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.0, revision: 5.0.0+git-7420-d8a3ee002, build type: debug, sources date: 20160102, built on: 2019-05-05 14:49:07 UTC 5.0.0+git-7420-d8a3ee002
http://www.kvirc.net/ ]
19:59
megi has joined #linux-sunxi
20:01
SopaXorzTaker has quit [Remote host closed the connection]
20:04
jstefanop has quit [Ping timeout: 245 seconds]
20:22
cristian__c has quit [Ping timeout: 248 seconds]
20:23
cristian_c has joined #linux-sunxi
20:39
cristian__c has joined #linux-sunxi
20:39
cristian_c has quit [Ping timeout: 245 seconds]
20:44
cristian_c has joined #linux-sunxi
20:45
cristian__c has quit [Ping timeout: 248 seconds]
20:49
cristian__c has joined #linux-sunxi
20:51
cristian_c has quit [Ping timeout: 272 seconds]
20:59
cristian__c has quit [Ping timeout: 272 seconds]
21:00
cristian_c has joined #linux-sunxi
21:01
jstefanop has joined #linux-sunxi
21:02
jaganteki has quit [Remote host closed the connection]
21:06
cristian__c has joined #linux-sunxi
21:06
jstefanop has quit [Ping timeout: 272 seconds]
21:07
cristian_c has quit [Ping timeout: 268 seconds]
21:14
shfil has quit [Quit: Connection closed for inactivity]
21:16
lurchi_ is now known as lurchi__
21:19
lurchi__ is now known as lurchi_
21:32
cristian_c has joined #linux-sunxi
21:33
cristian__c has quit [Ping timeout: 272 seconds]
21:36
cristian_c has quit [Ping timeout: 245 seconds]
21:37
cristian_c has joined #linux-sunxi
21:53
jstefanop has joined #linux-sunxi
22:05
willmore has joined #linux-sunxi
22:06
cristian_c has quit [Ping timeout: 248 seconds]
22:07
cristian_c has joined #linux-sunxi
22:14
BenG83 has quit [Quit: Leaving]
22:18
OutBackDingo has quit [Ping timeout: 246 seconds]
22:24
jstefanop has quit [Remote host closed the connection]
22:25
jstefanop has joined #linux-sunxi
22:27
OutBackDingo has joined #linux-sunxi
22:29
jstefanop has quit [Ping timeout: 268 seconds]
22:30
Mangy_Dog has quit [Ping timeout: 272 seconds]
22:31
jbrown has joined #linux-sunxi
22:39
OutBackDingo has quit [Quit: No Ping reply in 180 seconds.]
22:41
OutBackDingo has joined #linux-sunxi
22:43
lurchi_ is now known as lurchi__
22:47
lurchi__ is now known as lurchi_
22:49
Putti has quit [Ping timeout: 272 seconds]
23:24
tllim has joined #linux-sunxi
23:43
vagrantc has joined #linux-sunxi
23:51
jstein has quit [Ping timeout: 268 seconds]