path: root/wiki/Chat_log/20170817-io-chatlog

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