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!