1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
09:02 < wsa> welcome to today's IO meeting
09:02 < wsa> let's start with the status updates
09:02 < wsa> I don't have one from Shimoda-san in my inbox, though
09:03 < wsa> was it sent to Geert only, maybe?
09:03 < shimoday> wsa: sorry, i sent an email now
09:03 < wsa> anyway I can add it later
09:03 -!- morimoto [~user@2001:268:c141:3b12:85ab:e1cb:3723:afda] has joined #periperi
09:03 < wsa> the rest is like this:
09:03 < wsa> A - what have I done since last time
09:03 < wsa> ------------------------------------
09:03 < wsa> Marek
09:03 < wsa> : sent next version of PCIe L1 recovery patch
09:03 < wsa> Shimoda-san
09:03 < wsa> :
09:03 < wsa> Ulrich
09:03 < wsa> : investigated and fixed code relics in SCIF driver about minimum DMA timeout, investigated SDHI clock being left on after card is suspended/removed
09:03 < wsa> Wolfram
09:03 < wsa> : documented and sent "logic analyzer via isolated CPU" work, made more SDHI fixes like better irq mask handling and avoiding unneeded polling by the MMC core, checked I2C core and Renesas I2C drivers for RPM reference leaks, upstreamed CMT and TMU support for V3U, periject updates, especially for BSP41x commits, reviewed a few patches, mostly I2C
09:03 < wsa> B - what I want to do until next time
09:03 < wsa> -------------------------------------
09:03 < wsa> Niklas
09:03 < wsa> : wants to check and enable Thermal interrupt mode
09:03 < wsa> Shimoda-san
09:03 < wsa> : wants to
09:03 < wsa> Ulrich
09:03 < wsa> : wants to find out why default_suspend_ok() says that suspend is not ok with SDHI, look at the gpio logic analyzer
09:03 < wsa> Wolfram
09:03 < wsa> : wants to send next version of the logic analyzer based on feedback, continue with extended RECV_LEN and its R-Car support for I2C, refactor SDHn to be a seperate clock
09:03 < wsa> C - problems I currently have
09:03 < wsa> -----------------------------
09:03 < wsa> Wolfram
09:03 < wsa> : wants to do Condor board eMMC fixes but it seems we don't have HW to test
09:04 < wsa> so, let's see what comes out of the next version of the PCIe patch
09:04 < wsa> marex: thanks for sending it out
09:05 < wsa> uli__: nice that you already found the culprit of the SDHI RPM issue
09:05 < wsa> about the "Condor" problem...
09:05 < wsa> damm: according to my information, there is none in your lab. But maybe my information is outdated?
09:07 < wsa> about add. tasks in Q2:
09:07 < wsa> shimoda-san told me there is no budget for add. IO tasks in Q2
09:08 < wsa> so, the CAN task is moved to Q3 (HW is still missing, too)
09:08 < wsa> ad the PCIe task as well. But we also don't have a workaround for the HW problem yet in the BSP
09:09 < wsa> I dunno if one exists as a prototype
09:09 < wsa> marex: are you running out of tasks? maybe RPC-IF enablement for V3U might be a task then...
09:09 < wsa> marex: you have a V3U already, no?
09:10 < marex> wsa: V3U U-Boot port in general seems like a lot of work, and also ATF/U-Boot CI
09:10 < wsa> marex: i read this as "no free time"
09:11 < wsa> ?
09:11 < marex> wsa: the board is here, I plan to unpack it soon, so far I was busy with preparing for the later (hence the abloader)
09:11 < wsa> ok
09:11 < marex> wsa: at least not in the next few cycles
09:11 < wsa> noted
09:11 < marex> wsa: where do you want to enable the RPCHF, in Linux ?
09:12 < wsa> yes, V3U has it enabled like all other V3x
09:13 < marex> wsa: and all other boards with ATF built with RCAR_RPC_HYPERFLASH_LOCKED=0 , heh
09:14 < wsa> yes
09:14 < wsa> we will probably need that to work on the RPC driver fixes first
09:15 < wsa> whoever does it will likely not have V3U
09:15 < wsa> but given the possibility to brick the flash, it might be a good case for good old ES1.0 boards ;)
09:16 < marex> wsa: what is it about this "brick the flash" again ?
09:16 < damm> guys, there is a condor board in my remote access lab if you need it
09:16 < wsa> for the V3U case, too much data was written which ended up in the fuse section IIUC
09:16 < marex> wsa: of the flash ?
09:16 < wsa> marex: yes
09:17 < wsa> damm: which port?
09:17 < marex> wsa: I have to look into that, that sounds odd
09:17 < marex> wsa: anyway, I'll look up the email when I get to it
09:17 < damm> please email me and i will provide details
09:18 < wsa> damm: is there a always current list of available boards?
09:18 < wsa> damm: I'll happily mail you again :)
09:20 < damm> sorry information is sparse but just contact me and i'll help
09:21 < wsa> ok
09:22 < wsa> no further questions from my side
09:22 < marex> wsa: btw I find that breakage hard to believe, either there is HF attached to the RPC on the V3U and HF is basically CFI NOR with AMD standard command set, or there is QSPI NOR with JEDEC command set, neither has any way to blow fuses during page program easily ... I think I need to read the flash emails
09:22 < wsa> marex: or the BSP commits
09:22 < wsa> 0d37f69cacb3343514380ff4a9c271b746959190 # memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode
09:23 < marex> wsa: thanks
09:23 < wsa> marex: but that one likely needs to be refactored. mixing regmap and register access looks wrong
09:24 < wsa> ok, time to move to core?
09:24 < geertu> almost ;-)
09:25 < marex> wsa: that commit only talks about some additional modes where RPC causes data corruption in various data lengths, that's normal property of that IP though
09:26 < wsa> marex: and from the mails, this somehow set up some fuses, if I recall correctly
09:26 < wsa> but that needs a closer look
09:26 < marex> wsa: yep
09:26 < wsa> okay, geert, have fun!
|
