From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20151119-io-chatlog | 203 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 wiki/Chat_log/20151119-io-chatlog (limited to 'wiki/Chat_log/20151119-io-chatlog') diff --git a/wiki/Chat_log/20151119-io-chatlog b/wiki/Chat_log/20151119-io-chatlog new file mode 100644 index 0000000..0d06431 --- /dev/null +++ b/wiki/Chat_log/20151119-io-chatlog @@ -0,0 +1,203 @@ +--- Log opened Thu Nov 19 09:52:39 2015 +09:52 -!- wsa_ [~wsa@p4FE2557F.dip0.t-ipconnect.de] has joined #periperi-io +09:52 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] +09:52 -!- Irssi: Join to #periperi-io was synced in 0 secs +10:11 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi-io +10:11 < morimoto> Hi +10:11 <@geertu> hi +10:11 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +10:12 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io +10:12 < wsa_> great +10:12 < wsa_> everyone's here... +10:13 < wsa_> so, let's get started +10:13 < wsa_> i assume people in Japan want to go home soon ;) +10:14 < shimoda> :) +10:14 < wsa_> my topics as mentioned: +10:14 < wsa_> 1) gen3 updates +10:14 < wsa_> 2) clocks-off as default? +10:14 < wsa_> are there topics from your side? +10:15 < shimoda> none from me +10:15 < morimoto> Did you get email from shimoda-san about I2C macro issue ? +10:16 < wsa_> morimoto-san: yes, i even replied +10:16 < wsa_> morimoto: laurent and i found the same issue yesterday +10:16 < shimoda> wsa_: thank you for the information. this is useful to me +10:17 < morimoto> Oops I got email from you just during Renesas network issue time :) +10:17 < shimoda> so, i will forward this information to the customer +10:17 < wsa_> yes, and it was useful confirmation for me, too +10:17 < wsa_> as we are talking I2C already +10:18 < wsa_> any estimation when the HW team answers the "what is low drive only LVTTL" question? +10:19 < shimoda> wsa_: i am asking this and they returned something, but I don't get useful information yet for now +10:20 <@geertu> I think it's just the lower half of a regular push-pull output +10:20 < wsa_> i was thinking the same +10:20 <@geertu> I.e. similar like open drain, but with smaller transistors supporting only LVTLL voltage levels +10:20 < wsa_> but that would mean those busses are not multi-master capable +10:20 <@geertu> Typically open drain supports much higher voltage levels +10:21 <@geertu> Why not multi-master? +10:21 <@geertu> (higher voltage levels = much higher than vdd) +10:21 <@geertu> s/LVTLL/LVTTL/ +10:23 < wsa_> to be precise, they might not be multi-master compatible +10:23 < wsa_> it depends how it is done +10:23 <@geertu> lower half of a regular push-pull output == open drain +10:24 < wsa_> then why is not everyone doing it when it is so much faster? +10:25 < wsa_> that i wonder and why i'd like some details +10:25 <@geertu> Isn't it faster because of LVTTL levels? The lower voltage the pull-up, the faster it is (regular i2c is 5v, right) +10:25 < wsa_> yes, but rcar does only 3v3 at max +10:26 < wsa_> hmmm +10:26 < wsa_> makes sense +10:26 < wsa_> need to think about it +10:26 < wsa_> not now ;) +10:26 < wsa_> i saw the watchdog driver made it to the bsp +10:26 < wsa_> so bsp team was happy with it? +10:26 < wsa_> and we can continue upstreaming i guess +10:27 < shimoda> wsa_: i think so because bsp team doesn't ask me about it for now :) +10:28 < wsa_> :) +10:28 < wsa_> the PCIE driver works here for me +10:29 < wsa_> the interrupt issue found attention by Marc Zygnier, so I guess he and Phil will work it out +10:29 < shimoda> nice! +10:30 < wsa_> i can also scan the new bsp for sata patches. should be low-hanging fruit to upstream +10:31 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection +10:31 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io +10:32 < wsa_> then we wanted to find an upstream path for SDHI DMA +10:32 < wsa_> shimoda-san: is this still valid? +10:32 < wsa_> or did something other urgent show up? +10:32 < shimoda> i think so about sata. about porting from bsp to upstream, kaneko san of horms can do it, i guess +10:33 < wsa_> ok +10:33 < dammsan> guys +10:33 < shimoda> wsa_: yes, it is still valid, i think noone care about SDHI DMA for upstreamining +10:33 < dammsan> may i simply ask you to prioritize the I2C stuff over other leaf node devices? +10:33 < dammsan> that will be my only request =) +10:34 < wsa_> dammsan: i will send out v3 of my refactoring series today +10:34 < wsa_> this has all known issues addressed; needs thorough testing, of course +10:35 < dammsan> good - thanks a lot +10:35 < wsa_> and people do test currently which is great! +10:36 < dammsan> wsa_: you can use my remote access system anytime +10:36 < wsa_> dammsan: i will +10:36 < dammsan> ideally to test stuff on a wide range of boards before you queue it up +10:36 < wsa_> and i will run the continous edid read test +10:36 < dammsan> thanks +10:36 < dammsan> i cannot guarantee that the TV will be there forever +10:37 < dammsan> but looping HDMI back to the VIN may be good +10:37 < dammsan> but anyway, i will try not to steal your time with this anymore +10:37 < dammsan> =) +10:38 < wsa_> dammsan: sure thing. i always tested your koelsch. yet, all kernels were build with a toolchain that "worked" :/ +10:38 < wsa_> but this time laurent tested even before v3 is released ;) +10:40 < wsa_> but i understand this long standing issue is worrying +10:40 < dammsan> great, thanks! +10:41 < wsa_> shimoda: so kaneko-san will do SATA, nice. I noted it +10:41 < shimoda> i will ask simon-san about this later though :) +10:42 < wsa_> ok +10:43 < wsa_> there is a thermal driver now in the bsp \o/ +10:44 < wsa_> not in an upstreamable condition, though +10:44 < wsa_> i guess this needs to be done somewhen but it is not urgent? +10:45 < shimoda> I think so (it is not urgent) because they have a code +10:46 < shimoda> however, i will ask bsp team when it needs to upstream +10:47 < wsa_> so what is USB status? I see USB3 support will be pulled in soon? +10:47 < shimoda> yes, xhci maintainer mentioned about it +10:48 < shimoda> about USB2.0 host (usb2.0 phy), I should ping to kishon later +10:50 < wsa_> nice +10:50 < shimoda> about USB3.0 peri, I am developing it now +10:50 < shimoda> about USB2.0 peri, it should work after usb2.0 phy patch is merged +10:50 < wsa_> great +10:51 < wsa_> shimoda-san == USB hero +10:51 < wsa_> :) +10:51 < shimoda> :) +10:51 < wsa_> geertu: did you have any time left for SCIF or SPI development? +10:52 <@geertu> Expect SCK and full BRG support for (H)SCIF later today +10:53 < dammsan> how to handle the fifo drain issue? +10:53 < dammsan> i guess we need to fix that eventually +10:53 < wsa_> geertu: nice +10:54 <@geertu> I don't know enough about the tty/serial layer innards to answer that question +10:54 < dammsan> sure, no worries +10:54 < dammsan> it would be good to keep track of the task though, to show this to high level people +10:55 < dammsan> or maybe it will cause fire =) +10:56 < wsa_> noted +10:56 < dammsan> thanks! +10:58 < wsa_> so, can we go over to the clocks-off discussion? +10:58 < shimoda> yes +11:00 < wsa_> proposal: I'd like to make them mandatory for io-group upstream development +11:01 < wsa_> that would mean that 7791 has to be added +11:01 < wsa_> but their usefulness justify that IMO +11:01 < wsa_> comments? +11:02 <@geertu> 7791? +11:02 < wsa_> 7790 +11:02 < wsa_> sorry +11:03 < wsa_> ideally they would be in some branch, so that we developers can merge it into our codebase when we start hacking +11:04 < dammsan> [1;5Dwhy not including it in upstream by default? +11:06 < dammsan> perhaps you already have a good answer to that from a different thread? +11:06 <@geertu> It's ugly +11:06 < dammsan> ok but so is life +11:07 < dammsan> if you prefer not to then if it of course fine +11:07 < dammsan> just seems like a handy feature +11:07 <@geertu> with the new cpg-mssr driver, we could disable all clocks early in that driver +11:07 <@geertu> but then we have to list all of them +11:07 < dammsan> ok, self-contained ugliness =) +11:07 <@geertu> and I really mean all of them +11:08 <@geertu> thus including the non-documented ones ;-) +11:08 < dammsan> sure +11:08 <@geertu> or live with the hex numbers, alternatively +11:08 < dammsan> but it is easy to start doing that early compared to later in the process, no? +11:08 <@geertu> actually the hex numbers is probably the best way +11:08 < wsa_> the debug interface is also nice but also doesn't seem upstreamable to me +11:09 <@geertu> indeed +11:09 < wsa_> /proc \o/ +11:10 < wsa_> geertu: can you provide a branch? +11:10 < wsa_> or keep them integrated in renesas-drivers? +11:10 < wsa_> or is the latter too much work? +11:11 <@geertu> I can provide a branch +11:12 <@geertu> There's no classified information in there? E.g. clocks marked "secure" +11:12 < wsa_> that i don't know +11:12 < dammsan> you may find bugs =) +11:13 < dammsan> if so we shall really report them +11:13 < dammsan> not sure how secret it is +11:13 < dammsan> but should be fine unless you violate copyright +11:15 < wsa_> shimoda: morimoto: if geert provides a "clocks-off" branch, would you be OK using it? +11:15 < morimoto> sure of course +11:15 < dammsan> wsa_: including it in renesas-drivers may be a bit difficult for bsp people +11:15 < shimoda> wsa_: yes +11:16 < dammsan> i think that needs to be coordinated +11:16 < dammsan> if so +11:16 < dammsan> just a topic branch is something else +11:16 < wsa_> dammsan: i agree +11:17 < wsa_> the first thought was to reduce merge conflict resolutions, but on second thought it is too invasive +11:18 <@geertu> Do you need the full thing with debug interface, or just writing the hardcoded hex numbers to the mstpcr registers? +11:19 < wsa_> is it much work to keep the debug interface? +11:20 < wsa_> or maybe we start small +11:20 < wsa_> and port the debug interface when needed +11:24 < wsa_> ok? +11:25 <@geertu> ok +11:26 <@geertu> wsa_: can you extend the current "full" version to r8a7790? +11:27 < wsa_> i'll try +11:27 < wsa_> i'll come back to you if i have questions +11:27 <@geertu> ok, thx +11:28 < wsa_> anything more? +11:28 < wsa_> i think we are done +11:29 < shimoda> i think so +11:29 <@geertu> I have a small note +11:29 <@geertu> I added gpio-leds and gpio-keys to Salvator-X dts +11:30 <@geertu> Either of them work on their own, but not combined, as the LEDs and keys share GPIOs +11:30 < dammsan> GPIOF_SHARED? +11:30 < dammsan> like for IRQs? =) +11:30 <@geertu> This is an "interesting" DT issue, as both hardware descriptions are correct :-) +11:31 < dammsan> similar to our pinmux policy setting +11:31 < dammsan> with a single uart described but in reality the pinmux is what is limiting +11:31 <@geertu> I have some ideas for a proof-of-convept driver combining gpio-leds and gpio-keys-polled +11:31 < dammsan> gool +11:31 < dammsan> i mean cool =) +11:32 <@geertu> A while ago I had asked LinusW if something like that already existed, and he was interested in it. +11:32 <@geertu> Sharing a GPIO for both key and LED is a classic microcontroller trick +11:33 <@geertu> If I find some time, I'll implement it. Probably it will trigger an interesting DT discussion, so stay tuned :-) +11:34 * wsa_ orders some popcorn +11:34 <@geertu> Nothing else from my side for now +11:34 < wsa_> first time i hear someone starts a DT discussion for fun... ;) +11:35 < wsa_> ok +11:36 < wsa_> we are done +11:36 < wsa_> thank you! +11:36 < morimoto> gool, thx +11:36 < wsa_> and have a great rest of the day +11:37 <@geertu> cu, bye! +11:37 < wsa_> very gool! +11:37 < shimoda> bye! :) +11:37 < dammsan> cya +11:37 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 +11:38 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +--- Log closed Thu Nov 19 11:41:26 2015 -- cgit v1.2.3