diff options
Diffstat (limited to 'wiki/Chat_log/20171019-io-chatlog')
| -rw-r--r-- | wiki/Chat_log/20171019-io-chatlog | 175 |
1 files changed, 175 insertions, 0 deletions
diff --git a/wiki/Chat_log/20171019-io-chatlog b/wiki/Chat_log/20171019-io-chatlog new file mode 100644 index 0000000..289c990 --- /dev/null +++ b/wiki/Chat_log/20171019-io-chatlog @@ -0,0 +1,175 @@ +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! |