08:59 < wsa_> hi guys!
08:59 -!- uli__ [~uli___@static.206.203.46.78.clients.your-server.de] has joined #periperi
08:59 < geertu> Mornin'
08:59 < jmondi> 'morning!
09:00 < uli__> good morning
09:01 < morimoto> Marex: I will bring your sound board in next ELCE ;P
09:02 < Marex> morimoto: nice, thank you :-)
09:02 < wsa_> morimoto: do you know if Shimoda-san will attend the meeting?
09:02 < Marex> morimoto: at least we know where the problem is now
09:02 < morimoto> wsa_: Now shimoda-san is talking to our Boss.
09:02 < wsa_> I see
09:03 < wsa_> So, I guess we'll start then
09:03 < morimoto> Marex: the most biggest problem is that I have it ;P
09:03 < Marex> morimoto: why so ?
09:03 < morimoto> It means, I have your sound board. You can't fix it, right
09:04 < Marex> btw minor announcement regarding prague taxis and their price, I was just reading an article today about that in local news
09:04 < Marex> they did a test with local people and some foreigners and apparently there was some difference, so please be a bit careful
09:04 < wsa_> so, welcome to the io meeting! I collected all the status updates from you guys and will paste them now. After that, there is room for questions
09:04 < wsa_> A)
09:04 < wsa_> Geert:
09:04 < wsa_>         - Sent patch to consolidate RAVB clock handling.
09:04 < wsa_> Simon:
09:04 < wsa_>         - Began backporting HS400 from BSP
09:04 < wsa_>         - Posted fallback bindings for SDHI and SH-Eth
09:04 < wsa_>         - Posted and merged patches to use R-Car GPIO fallback bindings
09:04 < wsa_> Niklas:
09:04 < wsa_>         - [RFC] mmc: tmio: fix tuning for stubborn cards
09:04 < wsa_>           Not sure if I should repost this as a PATCH, got positive
09:04 < wsa_>           feedback from Simon.
09:04 < wsa_>         - Familiarised my self with SDIO and the basics of tuning
09:04 < wsa_>           SDR50/SDR104.
09:04 < wsa_> Shimoda-san:
09:04 < wsa_>         - Investigate MMC driver issues in v4.14-rc3.
09:04 < wsa_>         - Submitted the following patch(es):
09:04 < wsa_>          - Modify phy-rcar-gen3-usb2 driver for R-Car D3 support.
09:04 < wsa_>          - Fix the SDHI driver for v4.14, but needs update the patch.
09:04 < wsa_>         - Merged the following patch(es) into the subsystem:
09:04 < wsa_>          - Add support suspend/resume and generic phy for USB3.0 peripheral.
09:04 < wsa_>          - Add R-Car D3 support for phy-rcar-gen3-usb2 driver.
09:04 < wsa_> Wolfram:
09:04 < wsa_>         * sent out PFC patches for HSCIF on XS
09:04 < wsa_>         * discuss use of mmc_regulator_get_supply() and fix drivers
09:04 < wsa_>         * resent eMMC driver strength patches addressing comments from Ulf
09:04 < wsa_>         * implemented the missing bits for the I2C DMA series
09:04 < wsa_>         * various SDHI discussions
09:04 < wsa_>         * various I2C/IIC/RIIC discussions
09:04 < wsa_>         * reviewed a few patches
09:04 < wsa_>         * last Q4 add tasks on the way now
09:04 < wsa_>         * started working on my talk for ELCE
09:04 < wsa_> B)
09:04 < wsa_> Geert:
09:04 < wsa_>         - Rework EtherAVB PHY reset according to review comments
09:04 < wsa_>           (Sergei's old patches look promising),
09:04 < wsa_>         - MSIOF (add. task + issues reported by Dirk Behme).
09:04 < wsa_> Simon:
09:04 < wsa_>         - Continue HS400 work
09:04 < wsa_> Niklas:
09:04 < wsa_>         - Help Wolfram with more SDIO tests if he needs it.
09:04 < wsa_> Shimoda-san:
09:04 < wsa_>         - Fix USBHS driver more if I got feedback from HW team.
09:04 < wsa_>         - Continue to investigate how to implement bugfix code for MMC world.
09:04 < wsa_>         - Continue to watch if Sergei submits updated patch for phylib gpio-reset.
09:04 < wsa_>           Or, do I misunderstand somethings?
09:04 < wsa_>           https://marc.info/?l=linux-netdev&m=150755343716727&w=2
09:04 < wsa_> Wolfram:
09:04 < wsa_>         * finish talk for ELCE
09:04 < wsa_>         * add arbitration_lost_test to i2c_fault_injector and resend
09:04 < wsa_>         * test I2C DMA patches and resend
09:04 < wsa_>         * start working on no_busy_looping in MMC core
09:04 < wsa_>         * verify Niklas' SDR findings
09:04 < wsa_> C)
09:04 < wsa_> Shimoda-san:
09:04 < wsa_>         - HW team of USB area always blocks my works...
09:04 < wsa_>         - Maintainer(s) doesn't review the following patch(es) yet...:
09:04 < wsa_>          - Add PWM dt-binding for r8a77995.
09:04 < wsa_> Wolfram:
09:04 < wsa_>         * private life issues usually have bad timing
09:05 < Marex> the distance from the airport to the city center is about 16 km and price per km is ~28 CZK, so that should give you the idea of how much and how long it takes
09:06 < wsa_> neg: please wait with resending the SDR tuning patch until I had the chance to test it
09:07 < neg> wsa_: OK, will do
09:07 < wsa_> geertu: i assume your "Rework EtherAVB PHY reset" is the same as what shimoda-san mentioned with "Continue to watch if Sergei submits updated patch for phylib gpio-reset"?
09:08 < horms> shimoda-san: in general i advise against waiting for sergei, i would take over anything you need done quckly. i would tell him if you think he would mind - probably he will not
09:08 < geertu> wsa_: Yes it is
09:08 < wsa_> good
09:08 < geertu> horms: I'll take over the series, It already works as-is.
09:08 < horms> good plan
09:09 < wsa_> so, then there is this swiotlb thing
09:10 < geertu> Commit 7453c549f5f6485c ("swiotlb: Export swiotlb_max_segment to users") appears to be the solution?
09:10 < wsa_> this has turned into a core issue IIUC?
09:10 < geertu> It's in v4.10 and later
09:10 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi
09:10 < shimoda> sorry for the delayed
09:10 < geertu> Let's repeat
09:10 < geertu> Commit 7453c549f5f6485c ("swiotlb: Export swiotlb_max_segment to users") appears to be the solution?
09:11 < wsa_> hello shimoda-san
09:11 < geertu> It's in v4.10 and later
09:11 < shimoda> geertu: I don't think so, because
09:12 < shimoda> a mmc device cannot recognise which ops (swiotlb or iommu) is used
09:12 < shimoda> on local code of mine, some api seems to detect it
09:12 < geertu> Indeed, the check is not a real runtime check
09:13 < geertu> On arm64, it will always limit the size, as swiotlb is always compiled in.
09:13  * pinchartl has to leave for a bit, I'll be back in 45 minutes at the latest
09:13 < shimoda> the api is of_iommu_configure().
09:15 < shimoda> if the return value is not null, we can assume the device is on iommu.
09:15 < geertu> Thatg's called by core device code?
09:16 < shimoda> on my local code, it's called by sdhi code, not core device code. but i guess core device code can use it
09:17 < geertu> It's called from drivers/of/device.c:of_dma_configure
09:18 < geertu> which is called from drivers/base/dma-mapping.c:dma_configure()
09:18 < shimoda> in my opinion, we should fix this issue in v4.14. so, i'd like to apply a workaround code (adjust max_req_size) into v4.14. is it reasonable?
09:18 < wsa_> uli__: about the receive margin thing: any idea how to set it up without sysfs?
09:18 < geertu> whcih is called from drivers/base/dd.c:really_probe(), i.e. for all devices
09:19 < uli__> no, none yet
09:19 < geertu> uli__: Have you noticed any improvements by fiddling with the sampling point?
09:19 < uli__> it behaves as you would expect; shifting the sampling point down adds margin at the lower and and removes it at the higher end
09:19 < uli__> and vice versa
09:20 < geertu> uli__: So you can derive a formula to calculate optimal sampling point for sepcific requested bps?
09:20 < geertu> s/sepcific/specific/
09:21 < uli__> yes, but i am not sure about how this should behave when you change the baud rate
09:21 < geertu> shimoda: Can you look at the dma_ops configured for the device?
09:21 < geertu> uli__: What do you mean? Can't you just recalculate?
09:22 < uli__> yes, but that makes little sense; if you have a device connected that deviates, it will not deviate the same way at different baud rates
09:22 < uli__> so scaling is not helpful
09:22 < uli__> resetting is even worse, it's a biting-the-carpet bug generator for userspace
09:23 < geertu> uli__: Ah, so the goal is to accomodate an off device at the other side.
09:23 < uli__> yes
09:23 < horms> shimoda: assuming the problem was introduced in v4.14 then fixing it there seems to be a good idea. and providing a simple fix/work around sounds appropriate if a full fix is too invasive.
09:23 < geertu> Then you need a way to communicate the other side's rate to the driver => sysfs?
09:23 < uli__> exactly
09:23 < geertu> Or ioctl. Ugh
09:24 < uli__> and that gregkh doesn't like new sysfs attributes doesn't help either
09:24 < geertu> But it can also be used if the local scif cannot support the exact requested rate, right?
09:25 < shimoda> geertu: you're request means what of_dma_configure() output the message? dev_dbg(dev, "device is%sbehind an iommu\n", iommu ? " " : " not ");
09:25 < geertu> shimoda: I mean if the MMC driver can figure out if the IOMMU is used by looking at its dma_ops
09:26 < geertu> I believe of_dma_configure() is already called anyway.
09:26 < shimoda> horms: thank you for your comment! I will add such document and submit v2 patch
09:26 < uli__> geertu: that is also possible, but it's not the use case i have looked into
09:26 < geertu> uli__: OK. But it's something that doesn't rely on sysfs ;-)
09:27 < geertu> So for now you could calculate sampling point based on requested rate vs. scif-supported rate.
09:28 < geertu> Later it can be extended to remote-supported rate vs. scif-supported rate
09:28 < uli__> that would probably work
09:28 < geertu> The latter of course depends on discussing with Greg and friends about a good way to configue remote-supported rate
09:28 < geertu> Does that make sense?
09:29 < uli__> i think it does
09:30 < wsa_> shimoda: was my mail about your IIC requests helpful to you?
09:31 < shimoda> geertu: i don't think dma_ops is useful to figure out if the iommu ise used or not because dma_ops only has function pointers. So, it is diffcult to use on multiple arch.
09:32 < shimoda> wsa_: I'm sorry, i need to read your comment more about stop condition.
09:32 < geertu> shimoda: OK. Then we have to bring up to Konrad that we can use his suggestion as a temporary workaround, but that it doesn't solve the full problem (i.e. it limits mapping size if the device uses the IOMMU)
09:33 < wsa_> shimoda: i see, no worries. Please ask if there are still questions or if it is more urgent
09:33 < horms> can you use dma_ops like this? if (dma_ops == renesas_sdhi_sys_dmac_dma_ops) ...
09:34 < shimoda> geertu: ok. you means we should use his suggested api on the sdhi driver instead of hardcoded value of max_blk_size?
09:35 < geertu> shimoda: Yes. If swiotlb_set_max_segment() returns non-zero, we should use the returned value.
09:35 < shimoda> wsa_: i got it. thanks!
09:35 < shimoda> geertu: i got it!
09:35 < geertu> shimoda: Optimization for IOMMU can be done later
09:35 < geertu> Correctness first ;-)
09:35 < wsa_> swiotlb_max_segment()
09:36 < wsa_> not swiotlb_set_max_segment
09:36 < geertu> wsa_: Thanks, copy-and-pasted the wrong fucntion
09:36 < geertu> s/fucntion/function/
09:36 < wsa_> :)
09:36 < wsa_> ok, i think that was it for io?
09:37 < neg> One question is thermeal driver support IO or Core ? :-)
09:37 < geertu> neg: If you want to control e.g. CPUFreq, it's core
09:37 < geertu> neg: If it's just about measuring temperatures, it's I/O
09:38 < geertu> wsa_: Do you agree? ;-)
09:38 < wsa_> I was about to write the same thing, yes
09:38 < wsa_> :)
09:38 < neg> OK I'm thinking about thermal readig of temps for V3M, so then I guess it's IO :-) Do we have a request/plan for V3M support as it looks like this will be different from rcar_gen3_thermal
09:39 < wsa_> neg: I didn't get anything like that yet
09:40 < wsa_> I didn't get any request for V3M yet
09:40 < neg> wsa_: OK I just wanted you (or Geert if it where Core ;-) to be aware of the hardware difference that is all :-)
09:40 < wsa_> ok, thanks!
09:41 < wsa_> so, it's core time now...
09:41 < wsa_> thanks guys! happy hacking...
09:41 < geertu> wsa_: Thank you!