wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 96 insertions, 0 deletions

diff --git a/wiki/Chat_log/20170817-io-chatlog b/wiki/Chat_log/20170817-io-chatlog
new file mode 100644
index 0000000..67df725
--- /dev/null
+++ b/wiki/Chat_log/20170817-io-chatlog
@@ -0,0 +1,96 @@
+10:53 < wsa_> hey guys, welcome to the core meeting
+10:53 < uli___> wot?
+10:53 < geertu> again?
+10:53 < wsa_> ups
+10:53 < wsa_> io
+10:53 < wsa_> sorry, geert
+10:53  * wsa_ notes: copy&pasting meetings doesn't work
+10:54 < wsa_> let me summarize the status updates:
+10:54 < wsa_> simon got the Gen3 enablement patch merged
+10:54 < wsa_> uli created the HW timeout config patch for HSCIF but it doesn't work
+10:55 < wsa_> wolfram did various things with SDHI and rewrote the I2C core DMA helpers
+10:55 < wsa_> please add something if I missed it
+10:55 < wsa_> otherwise we have the issues of the non-working HSCIF register from Uli
+10:56 < geertu> uli___: Have you checked out the R-Car E2X errata you received recently?
+10:56 < geertu> They contain more info about registers that cannot be accessed at any time.
+10:56 < wsa_> I'll try to play around today with that, but I'd think we need Morimoto-san on this?
+10:56 < uli___> geertu: i'll check it out
+10:56 -!- neg [~neg@unaffiliated/neg] has joined #periperi
+10:57 < pinchartl> geertu: doesn't sound like very useful registers if they can't be accessed at any time
+10:57 < geertu> pinchartl: From the POV of the SW engineer?
+10:57 < wsa_> Gen3 docs say "HSSCR can always be read from and written to by the CPU."
+10:57 < pinchartl> from any point of view :-)
+10:58 < pinchartl> after the read-only register, the write-only register, we have the don't-access-only register
+11:00 < wsa_> so, the other issue is SDR104 on Gen3
+11:00 < geertu> on H3 ES2.0? ;-)
+11:00 < wsa_> (if there are not more ideas on the HSSCR register)
+11:00 < wsa_> enabling ES2.0 is also somewhere on my todo-list
+11:01 < wsa_> one of the tasks I'd really like to give away, but in my book, this is a base-task, not an additional task
+11:02 < wsa_> this is why I'd like to discuss the status-quo in SanSeb
+11:02 < wsa_> so, SDR104 memory cards now work fine on H3 ES1.* and M3-W 1.0
+11:03 < wsa_> it is the SDIO card which has problems in some slots
+11:03 < wsa_> at high speeds
+11:03 < wsa_> I think the fact that the line length is ~23cm instead of 10cm might have an influence
+11:04 < wsa_> hard to test
+11:04 < wsa_> resoldering in SanSeb was also kind of shot down :)
+11:05 < wsa_> I wonder where is the line of not enabling-SDR104 because of some setup
+11:05 < wsa_> I don't want to enable it now
+11:05 < wsa_> ES2.0 testing should also happen and way more testing in SanSeb
+11:05 < wsa_> but still
+11:05 < pinchartl> wsa_: desoldering such connectors is pretty difficult. a soldering iron isn't the best tool for the job
+11:05 < geertu> Can't the driver/subsystem downgrade the feature set if errors are detected?
+11:07 < wsa_> on the mmc core layer, could be
+11:07 < wsa_> dunno if a driver can request that if e.g. loading firmware fails
+11:08 < wsa_> i'd guess if the core notices a problem it will schedule a retune
+11:08 < geertu> And if retune fails?
+11:09 < wsa_> i expect it to go down with the speed, but i haven't checked
+11:10 < wsa_> so far, our tuning only failed because of stalled HW
+11:10 < wsa_> but we fixed that
+11:12 < wsa_> well, looks like this is a question for SanSeb, too; when we also have more data
+11:13 < wsa_> i think that's it for io
+11:13 < wsa_> unless you have something to add?
+11:13 < geertu> I have one more comment
+11:13 < wsa_> sure
+11:13 < geertu> About shifting the UART sampling point: This can increase accuracy for serial
+11:13 < geertu> speeds that are too much off, cfr. 92a0574867f3329c ("serial: sh-sci: Add
+11:13 < geertu> support for SCIFA/SCIFB variable sampling rates").
+11:14 < geertu> If the actual speed differs more than a few % from the requested speed, it fails.
+11:14 < geertu> Changing the sampling point can fix that.
+11:16 < uli___> i'm looking into quantifying that effect in practice
+11:16 < uli___> my current idea is to plop a 57.6 kHz square wave into an uart
+11:16 < uli___> and then tweak the frequency until the received pattern is not repetitive any more
+11:17 < uli___> and then check if pushing the sampling point can improve the margin
+11:17 < uli___> dunno if that works, i'll see once i get my equipment
+11:18 < geertu> I had a simpler test method when doing the variable sampling rates
+11:18 < geertu> Just configure a speed that cannot be done exactly
+11:18 < geertu> and see how it receives garbage.
+11:19 < uli___> don't you need two ends for that, with differing imprecisions?
+11:19 < geertu> USB serial adapters (e.g. FTDI) can usually do all standard rates.
+11:20 < geertu> Renesas SCIF ports always can't, with the supplied clocks
+11:20 < geertu> E.g. APE6EVM couldn't do 460800 bps before the aforementioned patch
+11:22 < geertu> I think SCIFA on Gen2 still can't do 1500000 bps
+11:22 < geertu> Perhaps also not 460800
+11:23 < uli___> frankly, i'm atm more concerned if that functionality in the hscif actually works at all...
+11:24 < wsa_> i understand that
+11:24 < wsa_> same here
+11:24 < geertu> It's not that difficult to find out.
+11:25 < geertu> Try all standard rates up to 4 Mbps, and see which fails.
+11:25 < wsa_> if we get feedback from renesas next week, this is kinda late for setting up an add. task
+11:25 < geertu> Then try all possible sampling points, and see if it helps
+11:25 < wsa_> first start would be to see if you can actually change bits in the register ;)
+11:26 < uli___> i'll look into it
+11:27 < wsa_> for completeness, the planned IO tasks for Q3/2:
+11:27 < wsa_> Simon - IP csum offloading for EtherAVB
+11:27 < wsa_> Uli - (hopefully) this sampling point adaption for SCIF
+11:28 < wsa_> Wolfram - DT bindings for SD/MMC drive strength settings (and side-effect: SDHI ES2.0 enabling)
+11:28 < wsa_> note: not PFC drive strength
+11:29 < wsa_> this is a command sent to the controllers on the other side
+11:29 < wsa_> are we done?
+11:30 < geertu> 10-4
+11:31 < wsa_> i don't know what it means, but I assume "yes" :)
+11:31 < wsa_> I only know 7-1
+11:31 < uli___> https://en.wikipedia.org/wiki/Ten-code
+11:32 < uli___> only used by really old men ;)
+11:33 < wsa_> hehe
+11:33 < wsa_> okay, then, thank you very much
+11:33 < wsa_> meeting closed