--- Log opened Mon Apr 25 09:56:14 2016 09:56 -!- wsa_ [~wsa@p4FE25E13.dip0.t-ipconnect.de] has joined #periperi-io 09:56 -!- Irssi: #periperi-io: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal] 09:56 -!- Irssi: Join to #periperi-io was synced in 1 secs 09:58 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io 09:58 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io 09:59 < shimoda> hi 10:00 -!- horms [~horms@124-171-1-229.dyn.iinet.net.au] has joined #periperi-io 10:00 -!- geertu [~geert@d54C36DF3.access.telenet.be] has joined #periperi-io 10:01 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] 10:02 < wsa_> hi guys again 10:03 < shimoda> hi 10:03 <@uli___> hi 10:03 < wsa_> i'd like to recap tasks today to see if all is settled after the "additional tasks" change 10:04 < wsa_> and i'd like to do that in alphabetical order 10:04 < wsa_> geert is first 10:04 -!- horms [~horms@124-171-1-229.dyn.iinet.net.au] has left #periperi-io ["Leaving"] 10:04 -!- horms [~horms@124-171-1-229.dyn.iinet.net.au] has joined #periperi-io 10:05 < geertu> I've got SCIF RTS/CTS hardware assisted flow control working. 10:05 < wsa_> so, no io base contract for you but additional task SCIF FIFO flushing for May 10:05 < wsa_> cool 10:06 < wsa_> wasn't that scheduled for June? :) 10:06 < geertu> So far tested on Koelsch with HSCIF and SCIFB. Have to test SCIF on Salvator-X etc. 10:06 < geertu> No, for v4.7 10:07 < geertu> Yes, June if I wasn't lucky ;-) 10:07 < geertu> Soon after I talked to you last week, I managed to make it work. 10:07 < wsa_> Ah, okay 10:07 < wsa_> so it is this task? 10:07 < wsa_> SCIF,v4.7,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control 10:07 < geertu> Yes 10:08 < geertu> More testing, cleaning up the code, and then it can go out. 10:08 < wsa_> Awesome! 10:08 < wsa_> Then I can remove this: 10:08 < wsa_> SCIF,?,noplan,?,Add support for hardware assisted modem-control 10:08 < geertu> Ah, you did add that one. I've just pulled peripelist, and it wasn't there 10:09 < wsa_> I wanted to wait after this chat before updating 10:09 < geertu> Perhaps keep it as a separate task, it will be the last half of my patch series 10:10 < geertu> In case the serial people have too many comments, the first half (GPIO) can go in separately. 10:10 < wsa_> I see 10:12 < wsa_> but seems we are clear with the tasks assigned? 10:12 -!- Irssi: #periperi-io: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal] 10:13 < geertu> Yes 10:13 < wsa_> good 10:13 < wsa_> next one would be morimoto-san, but he is not here yet 10:14 < wsa_> his main work for IO currently is being one of the Renesas contact guys and supplying documentation :) 10:14 < shimoda> i call morimoto-san now :) 10:14 < wsa_> thanks! 10:14 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io 10:14 < wsa_> hi morimoto-san! 10:15 < morimoto> Hi 10:15 < morimoto> sorry for my late 10:15 < wsa_> we are talking about assignments for IO group currently 10:15 < wsa_> and I just said about you: 10:15 < wsa_> his main work for IO currently is being one of the Renesas contact guys and supplying documentation :) 10:15 < wsa_> no worries 10:15 < morimoto> hehe :) 10:16 < wsa_> no seperate tasks assigned currently, right? 10:16 < wsa_> but simon needs SDHI documentation 10:16 < wsa_> I once got a nice ZIP with all Gen2 SDHI docs collected 10:16 < wsa_> it would be great if he could have that, too 10:17 < morimoto> OK, will check 10:17 < morimoto> for Simon 10:17 < wsa_> thanks! 10:18 < wsa_> any news from you? 10:18 < horms> thanks. in particular SCC documentation for gen2 10:18 < morimoto> Hmm. it seems I already sent SDHI zip file to Simon ? 10:18 < morimoto> 2016/02/25 10:18 < horms> yes, i have that file 10:19 < morimoto> gr8 10:19 < horms> but I don't seem to have any SCC documentation in there 10:19 < horms> I can tell you what files are in there if it helps, perhaps via email 10:19 < morimoto> OK, thanks 10:19 < horms> thanks, I'll send you an email 10:20 < wsa_> good 10:20 < wsa_> morimoto: khiem-san is aware of the thermal driver until end of june? 10:21 < morimoto> it seems, but maybe we didn't decided dead-line 10:21 < morimoto> And we will have meeting July timing (= LinuxConJapan) 10:22 < horms> morimoto: email sent 10:22 < morimoto> Thanks 10:22 < wsa_> morimoto: the deadline came from Renesas, if it was changed, please let me know, so i can update my todo 10:25 < wsa_> okay, next one is neg 10:25 < wsa_> you have base contract with 5 days per quarter and will do I2C DMA for this quarter there, right? 10:25 < neg> yes 10:26 < wsa_> and currently no additional tasks for IO but working a lot for multimedia 10:26 < neg> got your mail describing the issue, thanks. Will start to look into it 10:26 < wsa_> good 10:27 < neg> and yes, only additional contracts for multimedia are planed 10:27 < wsa_> so we are clear here, too? 10:28 < wsa_> i guess so 10:29 < wsa_> shimoda-san is next 10:29 < wsa_> Still being our USB hero and also one of the Renesas contact guys, right? :) 10:30 < shimoda> yes :) 10:30 < wsa_> any news with the USB tasks? 10:30 < shimoda> fixing xhci probing issue now 10:31 < shimoda> and I'm working for new OTG framework that made by Roger 10:31 < wsa_> is that planned for 4.8? 10:32 < shimoda> about xhci kconfig, i could make a patch that Geert-san suggested 10:32 < shimoda> wsa_: about OTG, yes, it is for 4.8 10:33 < wsa_> i'll add this to the todo 10:33 < shimoda> OTG SUBSYS maintainer sent Acked-by in last week. 10:34 < wsa_> ah, so it is already "public"? 10:34 < wsa_> i missed that 10:35 < shimoda> wsa_: not yet, i didn't sent OTG patch for rcar yet 10:35 < wsa_> i see 10:35 < wsa_> prototypeß 10:35 < wsa_> ? 10:35 < shimoda> yes 10:35 < wsa_> good 10:36 < wsa_> thanks 10:37 < wsa_> any more news? 10:37 < wsa_> otherwise simon would be next 10:38 < horms> sounds like its my turn 10:38 < wsa_> yes, so, no base contract for simon, but working on SDR104 for SDHI in May as additional task 10:38 < wsa_> (SDHI task priorities have been quite reshuffled due to the additional tasks) 10:39 < horms> yes, thats right. I hope to make an early start on that one. So far I'm planning to prototype on Gen2 assuming I can get documentation for a Gen2 Soc. 10:39 < horms> There is support for this feature in the BSP, including enabling the SCC which seems to be the core of the task. 10:39 < wsa_> Yes, Gen2 should be prototyped, we still don't have Gen3 DMA support yet 10:39 < wsa_> upstream that is 10:39 < horms> My basic plan is to rework the BSP code and see how far that gets us. 10:40 < horms> I have not looked in enough detail to have any problems yet :) 10:40 < wsa_> i saw some custom DT bindings in there IIRC 10:41 < wsa_> i would wonder if they are really needed or if the mmc core doesn't have a solution for them already somewhere 10:41 < horms> I would also like to mention that Kaneko-san has been working on isolating which BSP v3.2.0 patches look good for upstream. I am encouraging him to discuss individial patches on the periperi ML. Presumably some will relate to IO. 10:41 < horms> thanks. obviously custom bindings are a red flashing light. 10:41 < wsa_> :) 10:42 < horms> possibly the base addr for the SCC needs to be specified in DT 10:42 < wsa_> OK, awaiting Kaneko-sans patches then 10:42 < horms> again, I haven't looked very far yet 10:43 < horms> If there are any priorities for upporting let me know. But more likely we'll be feeding features into your todo list 10:43 < wsa_> yes, i think so, too 10:43 < horms> ok, that was all i had in mind to say 10:43 < horms> perhaps we can move on? 10:44 < wsa_> when is the next BSP release planned BTW? 10:44 < wsa_> would be nice to know 10:44 < horms> there was a release, 3.2.1 very recently 10:44 < horms> like a last week 10:44 < horms> morimoto-san or shimoda-san likely have more insight into the timing of the next release than I 10:44 < neg> there where new code ind the bsp from ~friday I think 10:45 < wsa_> thanks, will check 10:45 < horms> The 3.2.1 release, at a glance, seems to have a lot of M3 related changes 10:45 < geertu> Yeah, CPG and PFC 10:45 < wsa_> uli___ is next 10:45 < geertu> (noticed that earlier this week) 10:47 <@uli___> no additional i/o tasks for me so far 10:47 < wsa_> he has a 5 days/quarter base contract for IO and does CANFD driver review and r8a7740 clock driver refactoring to fix an SDHI regression. The latter one most probably in June. 10:47 < wsa_> and no IO additional tasks in May 10:47 < wsa_> correct? 10:47 <@uli___> yes 10:48 < wsa_> but most likely additional tasks in June (like with geertu and simon, too; not sure about niklas, we will see then) 10:49 < wsa_> uli___: did you have time to check the CANFD driver yet? 10:49 < horms> fwiw i have no insight into my bonus plans in June :) 10:49 <@uli___> on screen now, but haven't looked closely yet 10:49 < wsa_> horms: from what I know, 1 week for IO is planned 10:50 < horms> thanks, good to know :) 10:51 < wsa_> the CANFD driver seems stuck; I hope that additional comments or simply "reviewed-by" tags will get it rolling again 10:51 < wsa_> i don't think it is that bad, it has a few iterations done already 10:52 <@uli___> ramesh asked whether to send a new version 2 weeks ago, to no response 10:52 < horms> possibly the person responsible got re-tasked 10:53 < wsa_> "I can send a next version of patch if we have a closure on current set of comments. 10:53 < horms> ok then perhaps he just needs some feedback 10:53 < wsa_> " 10:53 < wsa_> he said 10:53 < horms> Is there closure? 10:53 < wsa_> uli___: maybe you can agree/disagree to his comments to re-start the procedure 10:54 <@uli___> i can say "please send it, i'd like to have a look"... 10:54 < wsa_> that might work, too 10:54 < wsa_> :) 10:55 < wsa_> unless you see something worth fixing already 10:56 < wsa_> ok, but you are at it 10:56 <@uli___> i am 10:56 < wsa_> so, it is my turn now 10:57 < wsa_> i have a base contract of 5 days/month for IO currently 10:57 < wsa_> this month was nearly completely eaten up by the new task/contract procedures 10:57 < wsa_> i hope this will become better once things settled down 10:58 < geertu> :-) 10:58 < wsa_> my plan is to keep this time for a) group leading and b) spontaneous, important, emergency tasks in the IO sector 10:59 < wsa_> my additional tasks for May are "pre-timeout support for watchdog" and "SDIO support on Gen3 for SDHI" 11:00 < horms> wsa_: do you have any SDIO cards? 11:00 < wsa_> yes 11:00 < horms> great! 11:01 < wsa_> Bluetooth, and serial (GPS) and a wireless one 11:01 < wsa_> sadly the latter is not supported by Linux :( 11:01 < horms> I have one SDIO wifi card that is known to work (in the past at least) with renesas hw. I can lend it to you / let you know the model if that would help. 11:01 < wsa_> i ordered a 802.11ac card to test UHS throughput with SDIO 11:02 < wsa_> but this card is still in prototype stage and I dunno when I'll get it :/ 11:02 < wsa_> horms: that would in deed help 11:03 < horms> ok, great. I probably can't get my hands on the card for about 10 days (because I am not in Japan). Would waiting that long + postage be a problem? 11:03 < wsa_> nope 11:03 < horms> great 11:03 < horms> can you ping me on about the 4th? 11:03 < wsa_> will do 11:03 < horms> great 11:04 < wsa_> so, SDHI tasks about DMA for Gen3 and eMMC support got moved to the back because of the new tasks coming in 11:04 < wsa_> i hope the DMA task for Gen3 can be done in June 11:04 < wsa_> it might become a bottleneck otherwise 11:05 < wsa_> so, that was that 11:06 < wsa_> there seem to be no surprises, so we did well last week, I think :) 11:07 < wsa_> anything else which needs to be shared? 11:08 < neg> I have a question about firmware upgrade, have you all updated your Salvator-X boards? 11:08 < geertu> Not yet 11:08 < geertu> I should 11:08 < wsa_> I haven't 11:09 < horms> I have 11:09 <@uli___> not me 11:09 < wsa_> haha 11:09 < horms> to test cpuhotplug 11:09 < neg> ok, then I hold out a bit longer then untill there is a happy repport that the board won't catch fire :-) 11:09 < horms> it did not catch fire 11:09 < horms> but i am not pushing anyone to upgrade 11:10 < wsa_> so, let's call it a meeting then 11:11 < wsa_> thank you! 11:11 < horms> thanks, have a nice day 11:11 < wsa_> and have a good week 11:11 < neg> also morimoto-san said something about meeting time arund LinuxConJapan is that set? I'm thinking about tickets and other summer planing 11:11 < wsa_> I'll be at LCJ most likely 11:11 < wsa_> I dunno about a meeting 11:11 < wsa_> but would be very interested :) 11:11 < morimoto> Yes, now we are thinking LinuxConJapan + Renesas Meeting + mini-PeriPeriCon 11:12 < morimoto> not yet decidec 11:12 < morimoto> decided 11:12 < geertu> Which parts? I think LinuxConJapan will definitely happen ;-) 11:13 < morimoto> I will send invite email soon. Renesas Meeting is gray 11:13 < morimoto> Maybe 1day mini-PeriPeriCon, 1day Renesas Meeting (if we have) 11:13 < morimoto> And Magnus plan is we will have full PeriPeriCon on Sep (?) 11:14 < neg> morimoto: ok thanks then I hold of buying tickets and other summer planing around LCJ timing 11:14 < morimoto> gr8 11:14 < wsa_> I'll be in Japan before LCJ 11:14 < wsa_> and fly back directly after LCJ 11:15 < morimoto> Oops, do you already have ticket ? 11:15 < wsa_> yes 11:15 < morimoto> OK 11:15 < wsa_> I need to go to LCJ anyhow because of giving a talk there 11:16 < geertu> Brussels Airport is open again, and the direct flight to/from Narita is no longer diverted to Düsseldorf 11:16 < geertu> wsa_: That's a good reason 11:16 < wsa_> Yes, I need to present the results of a LinuxFoundation contract 11:17 < geertu> IC, as the CFP is still open 11:17 < wsa_> so, no travel costs for Renesas this time, sorry ;) 11:17 < morimoto> wsa_: OK :) 11:18 < geertu> More budget for sake and kobe-beef ;-) 11:18 < wsa_> \o/ 11:18 < wsa_> ok, gotta leave now 11:19 < morimoto> very important budget :) 11:19 < wsa_> i'll update redmine soon 11:19 < morimoto> thanks 11:19 < geertu> bye, thx 11:19 < neg> thanks all 11:19 < shimoda> thanks 11:20 <@uli___> bye 11:20 < morimoto> wsa_: please Redmine log + Redmine IO schedule + PeriPelist git 11:20 <@uli___> morimoto: hardass! :) 11:20 < morimoto> ;P 11:20 < morimoto> Thanks 11:20 < morimoto> bye 11:20 -!- morimoto [~user@relprex1.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] 11:20 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 --- Log closed Mon Apr 25 11:22:32 2016 >352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 
Geert Uytterhoeven ­ 11:01 AM
Good morning/afternoon!
Magnus Damm ­ 11:01 AM
Hey Geert!
Simon Horman ­ 11:01 AM
Hi
Yoshihiro Shimoda ­ 11:01 AM
Good afternoon! Geert­san!
Kuninori Morimoto ­ 11:01 AM
Hi
Ulrich Hecht ­ 11:01 AM
hello
Laurent Pinchart ­ 11:02 AM
hello
Geert Uytterhoeven ­ 11:02 AM
Cool, looks like it's working
Some people need pictures
Laurent Pinchart ­ 11:03 AM
Are we having an audio conference ?
or just text ?
Geert Uytterhoeven ­ 11:03 AM
Just text
Laurent Pinchart ­ 11:03 AM
then why not irc ???
Geert Uytterhoeven ­ 11:04 AM
Good question...
Ulrich Hecht ­ 11:04 AM
i was, in fact, even prepared for video
Geert Uytterhoeven ­ 11:04 AM
Google Hangout is good for chat archival
Laurent Pinchart ­ 11:04 AM
so is IRC, logs are easy
and there's more screen real estate
Geert Uytterhoeven ­ 11:04 AM
Maybe next time on irc
Laurent Pinchart ­ 11:04 AM
GH is a toy for text chat
Geert Uytterhoeven ­ 11:05 AM
Well, this is a first try.
Agenda for first session:
1. IPMMU,
2. SMP DT,
3. Legacy board phase out.
A. Magnus' todo list format?
Magnus Damm ­ 11:05 AM
Oh right
Geert Uytterhoeven ­ 11:06 AM
I'd like to limit this to 1h30, so 20' per item?
Let's start with IPMMU.
Laurent Pinchart ­ 11:06 AM
speaking of IRC, I believe it would be interesting to create a channel for our team. can we add that to the
agenda ?
it won't take long
Simon Horman ­ 11:07 AM
Perhaps we can tackle that last if we have time
I agree it shouldn't take long
Geert Uytterhoeven ­ 11:08 AM
I think IPMMU is (mostly) Laurent's kettle of fish?
Laurent Pinchart ­ 11:08 AM
yes
what would you like to know about it ?
Magnus Damm ­ 11:09 AM
we want to define tasks
Geert Uytterhoeven ­ 11:09 AM
Apparently there's an issue with using IPMMU with (some) devices, cfr. Shimoda­san's email
Magnus Damm ­ 11:09 AM
and some back ground would be nice too
Geert Uytterhoeven ­ 11:09 AM
What devices do we know IPMMU works with?
Laurent Pinchart ­ 11:10 AM
it's not an IPMMU issue
it's a DMAC issue
we know about one IPMMU issue
Geert Uytterhoeven ­ 11:10 AM
What devices do we know IPMMU doesn't work with?
Laurent Pinchart ­ 11:10 AM
or rather one DMAC + IPMMU issue
Geert Uytterhoeven ­ 11:10 AM
So I should have written IPMMU/DMAC
Laurent Pinchart ­ 11:10 AM
in that DMAC channel 0 doesn't work properly with the IPMMU
I've raised that a long time ago
and got no feedback
Geert Uytterhoeven ­ 11:11 AM
But we have a workaround for that, right?
Laurent Pinchart ­ 11:11 AM
we don't know whether it has been fixed on Gen3
the workaround is to not use channel 0
so we're losing hardware
the second issue that Shimoda­san raised is not caused by the IPMMU itself
Geert Uytterhoeven ­ 11:12 AM
It's integration DMAC/IPMMU?
Laurent Pinchart ­ 11:12 AM
but by the DMAC driver configuring the DMAC to issue bus master requests to a physical address even when
the accesses are translated by the IPMMU
it's a DMAC driver issue
or possibly a DMA slave driver issue
Geert Uytterhoeven ­ 11:13 AM
Do you know how other DMAC drivers handle this? I'd assume IPMMU or not should be transparent.
Apparently all DMA slave drivers use the physical address when accessing device registers.
Laurent Pinchart ­ 11:14 AM
as far as I can see, they don't, they're all broken
Magnus Damm ­ 11:14 AM
From my side it looks like none of our DMA Engine slave drivers can work with IPMMU as­is today, right?
But it may "only" be an issue of fixing the DMAC driver
Laurent Pinchart ­ 11:14 AM
correct
Magnus Damm ­ 11:15 AM
thanks for confirming my suspicion
Laurent Pinchart ­ 11:15 AM
the DMA engine API passes the slave address as a dma_addr_t
but our drivers pass a physical address
so either we map the physical address to a DMA address in the slave drivers
or we modify the DMA engine API to pass a phys_addr_t and map the address in the DMAC driver
Geert Uytterhoeven ­ 11:16 AM
yes, dma_slave_config uses dma_addr_t. but the docs say it's a physical address. And it's been like that since
its introduction
Magnus Damm ­ 11:17 AM
it looks to me like the DMA Engine slave drivers are supposed to perform something similar to ioremap() to get
a virtual bus address
I think PCI device drivers tend to do something like that
but not for DMA Engine purpose
Laurent Pinchart ­ 11:18 AM
the API documentation is incoherent
we first need to define what API we need
and then to fix the side that is broken
Magnus Damm ­ 11:19 AM
sounds like a good plan
Geert Uytterhoeven ­ 11:19 AM
I'm wondering why nobody else has that problem.
Magnus Damm ­ 11:19 AM
we may want to cook up a prototype too so we can check if we can get it working at all
Geert Uytterhoeven ­ 11:20 AM
At least on PowerPC/Cell, the IOMMU is mandatory.
Magnus Damm ­ 11:20 AM
No one is using DMA Engine with IOMMU?
Geert Uytterhoeven ­ 11:20 AM
On PS3, that was hidden by the hypervisor.
But on other Cell platorms, it should apply.
Magnus Damm ­ 11:20 AM
On­chip devices with bus mastering capability is kind of common, right?
Geert Uytterhoeven ­ 11:21 AM
spidernet doesn't use dma engine config (only dma to ring buffers)
Laurent Pinchart ­ 11:21 AM
it could be that on some systems the DMA engine can bypass the IOMMU when it accesses slave devices, I
don't know
Geert Uytterhoeven ­ 11:21 AM
Looking for other cell drivers...
Yoshihiro Shimoda ­ 11:21 AM
I'm not sure but IOMMU ML is discussing PCI enviromnet
http://lists.linuxfoundation.org/pipermail/iommu/2015­May/013052.html
Magnus Damm ­ 11:22 AM
dma_map_resource()
Geert Uytterhoeven ­ 11:22 AM
yep
Magnus Damm ­ 11:22 AM
maybe similar to ioremap() but for devices?
Laurent Pinchart ­ 11:22 AM
we don't need to map the whole resource, just part of it in our case
Magnus Damm ­ 11:22 AM
right
Laurent Pinchart ­ 11:23 AM
but in practice we can't map areas smaller than a page anyway
Geert Uytterhoeven ­ 11:23 AM
indeed
Laurent Pinchart ­ 11:23 AM
which, from an isolation point of view, is an issue
if we want to isolate devices, especially in virtual environment, we need to use PIO
Magnus Damm ­ 11:23 AM
we will get a whole ton of these issues with security and virtualization
but lets save those for later
Geert Uytterhoeven ­ 11:24 AM
I don't see any devices where we need a granularity smaller than 4 KiB?
Laurent Pinchart ­ 11:24 AM
all of them ?
we're talking about DMA access to a hardware register
Magnus Damm ­ 11:25 AM
i thought we sort of assigned one side at a time for the DMA API
so the CPU and the IOMMU should not be able to map at the same time
Geert Uytterhoeven ­ 11:26 AM
Yes. What's the problem with accessing the other registers in the register block? It's the same device.
Magnus Damm ­ 11:26 AM
write­combining?
Laurent Pinchart ­ 11:26 AM
can you guarantee that the 4kB around the hardware register will always belong to the same device ?
Magnus Damm ­ 11:26 AM
perhaps depends on the topology?
i think we can assume that
Geert Uytterhoeven ­ 11:26 AM
I had a quick look at r8a7791.dtsi
(before I said "I don't see any devices where we need a granularity smaller than 4 KiB?")
CPU uses the plain MMU
DMA uses the IOMMU
Magnus Damm ­ 11:27 AM
I think we can assume they are page­aligned
Geert Uytterhoeven ­ 11:27 AM
Both can map the same register block ("4 KiB") at the same time
If a VM can use e.g. QSPI, it can map the registers using both MMU and IOMMU.
That's the idea, right?
Laurent Pinchart ­ 11:28 AM
anyway, that's not an API issue, it's a hardware design issue
if multiple devices share the same 4kB page there's nothing we can do
Magnus Damm ­ 11:28 AM
right
Laurent Pinchart ­ 11:28 AM
and we don't need to take that into account in the API
Geert Uytterhoeven ­ 11:28 AM
If the OS implementer is too stupid to DMA to other QSPI registers, that's his problem. He can write to these
registers using PIO too
Laurent Pinchart ­ 11:29 AM
any other question regarding the IPMMU isssue ?
Magnus Damm ­ 11:29 AM
i have one about the API
not about stupid users in virtualized environments
but the DMA API where I believe the "user" of a certain device is passed around and can either be the CPU or
the device
not both at the same time
so if we have a device using IOMMU with DMAC to access the hardware then is it OK to access other control
registers from the CPU?
Laurent Pinchart ­ 11:31 AM
all the mappings will be non­cacheable, so that's fine
Magnus Damm ­ 11:32 AM
but the API described by Documentation/DMA­API.txt allows more detailed control than that
but yes, we can treat it in a simple way for now, and more advanced usage may require different 4K pages for
different I/O areas within the save device
and in such case our hardware design may not be good enough
but shall we leave that for later?
Laurent Pinchart ­ 11:34 AM
I'm not sure to see where the problem is
so let's leave it for later
Magnus Damm ­ 11:34 AM
good
Laurent Pinchart ­ 11:35 AM
no other question ?
Magnus Damm ­ 11:35 AM
what needs to be done?
Laurent Pinchart ­ 11:36 AM
I was going to mention that
action points for this item ?
Magnus Damm ­ 11:36 AM
I think we need to cook up some prototype code
Laurent Pinchart ­ 11:36 AM
1. finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue
Magnus Damm ­ 11:36 AM
to see if we can get _anything_ working at all
(haha, good luck)
Laurent Pinchart ­ 11:37 AM
2. discuss API changes on the dma­engine mailing list
3. fix the code
1. is for Magnus
Magnus Damm ­ 11:37 AM
I don't think so
if for anyone it would be the "Renesas interface person"
Geert Uytterhoeven ­ 11:37 AM
Morimoto­san?
Simon Horman ­ 11:37 AM
I thought we agreed not to assign people to taks
Laurent Pinchart ­ 11:38 AM
congratulations, you've just been appointed as the Renesas interface person !
Yoshihiro Shimoda ­ 11:38 AM
I will do the 1.
Geert Uytterhoeven ­ 11:38 AM
Right
Laurent Pinchart ­ 11:38 AM
Simon: did we ? ok
so, 3 actions points
Magnus Damm ­ 11:38 AM
I expect both Shimoda­san and Morimoto­san to help out as Renesas interface for the core group
Simon Horman ­ 11:38 AM
I may be mistaken
Laurent Pinchart ­ 11:38 AM
1 is standalone, 3 depends on 2
Magnus Damm ­ 11:38 AM
thanks for stepping up, shimoda­san
prototype is standalone too
Geert, can you collect these please?
Geert Uytterhoeven ­ 11:39 AM
Sure, 3 is prototype?
Magnus Damm ­ 11:40 AM
i thought 3 was proper implementation?
after determining the proper API
without knowing if the hardware works we can't do anything IMO
Geert Uytterhoeven ­ 11:40 AM
Ah, so 0 is prototype
1.5 is prototype?
Magnus Damm ­ 11:41 AM
that's better! (for me at least)
Geert Uytterhoeven ­ 11:41 AM
BTW http://lists.infradead.org/pipermail/linux­arm­kernel/2013­April/165411.html
Laurent Pinchart ­ 11:41 AM
I don't see a need for a prototype
Geert Uytterhoeven ­ 11:41 AM
Arnd: The dma engine driver must know the address in its dma space, while the
slave driver has it available in physical space. These two are often the
same, but there is no generic way to convert between the two, especially
if the dma engine resides behind an IOMMU.
The best assumption we can make is that the dma engine driver knows
how to convert between the two. Interestingly the documentation for
dma_slave_config talks about "physical address", while the structure
itself uses a dma_addr_t. Linus Walleij introduced the structure in
c156d0a5b0 "DMAENGINE: generic slave channel control v3", so I assume
he can shed some light on what he was thinking. I assume the documentation
is right but the structure is not and should be converted to use
phys_add_t or resource_size_t.
Simon Horman ­ 11:41 AM
I think it is likely some kind of loop between discuss and implement may emerge
Magnus Damm ­ 11:42 AM
Laurent: have you tried DMA Slave API with IOMMU?
Laurent Pinchart ­ 11:42 AM
Simon: agreed
Geert Uytterhoeven ­ 11:42 AM
(Arnd should know, as he did PowerPC/Cell before, where the IOMMU is mandatory. Some scanning in the
sources makes me think it was al handled by the (real) Open Firmware on Cell)
Laurent Pinchart ­ 11:42 AM
Magnus: no, and I'm not worried about it. it's an API issue
Magnus Damm ­ 11:43 AM
I'm worried that we found it out at this timing.
I thought it was tested and ready to integrate
Geert Uytterhoeven ­ 11:43 AM
Yes
Magnus Damm ­ 11:44 AM
I agree that a proper API is needed
Geert Uytterhoeven ­ 11:44 AM
Hence my question "
What devices do we know IPMMU works with?" in the beginning
But we're running out of time for this topic?
Laurent Pinchart ­ 11:44 AM
ok, there's a discussion of the issue in that e­mail thread
Magnus Damm ­ 11:44 AM
I've tested the IPMMU with the DU
Geert Uytterhoeven ­ 11:44 AM
s/we're running/we ran/
Laurent Pinchart ­ 11:44 AM
we need to study it and revive it
Yoshihiro Shimoda ­ 11:45 AM
I have tested the IPMMU with xhci
Laurent Pinchart ­ 11:45 AM
DU, VSP1 and DMAC (in mem to mem mode) have been tested
Magnus Damm ­ 11:45 AM
I also tested USBHS
with some prototype patches
Simon Horman ­ 11:45 AM
by tested, is the implication that they work?
Magnus Damm ­ 11:45 AM
at least it may work
I believe USBHS needs more work
Yoshihiro Shimoda ­ 11:46 AM
xhci works, I think
Magnus Damm ­ 11:46 AM
but it is separate from the DMAC issue that sort of holds back a whole range of devices
But with USBHS I've seen that the hardware seems to work
I never seen anything like that for DMAC and IPMMU combo with DMA Engine slave
so may I add a prototype task just to test the hardware?
Laurent Pinchart ­ 11:48 AM
Magnus: I think that's overkill
the DMA engine API needs to be fixed anyway
Magnus Damm ­ 11:49 AM
Well, I don't want to flame, but I expected you to do this for your MMCIF work last summer ­ after the IOMMU
and DMAC work
sure
Im not arguing against fixing the API
Laurent Pinchart ­ 11:49 AM
that's interesting, because I'm pretty sure I've tested MMCIF
Magnus Damm ­ 11:50 AM
So i thought it was tested
but it seems to not work at all
I should have tested on my side
so no blame on you
Laurent Pinchart ­ 11:50 AM
I clearly remember running into issues with channel 0 + IOMMU with MMCIF
and not with channel 1
Magnus Damm ­ 11:50 AM
But looking at it now it seems that it couldn't ever work
Geert Uytterhoeven ­ 11:50 AM
cfg.src_addr = res­>start + MMCIF_CE_DATA;
Magnus Damm ­ 11:51 AM
laurent: i'm not trying to get you to write a prototype
just saying that we need to do it
actual assignment is a different matter
Geert Uytterhoeven ­ 11:51 AM
We just ran out of time for topic 2
Magnus Damm ­ 11:52 AM
haha
Geert Uytterhoeven ­ 11:52 AM
Topic 2. SMP DT,
Magnus Damm ­ 11:52 AM
So what does the Core Group leader say about prototyping?
Geert Uytterhoeven ­ 11:52 AM
I wrote down:
Magnus Damm ­ 11:52 AM
I will follow our leader penguin
Geert Uytterhoeven ­ 11:52 AM
1. finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue
2. implement prototype
3. discuss API changes on the dma­engine mailing list
4. implement proper solution
Kuninori Morimoto ­ 11:52 AM
About quetion to HW team,
I can ask to HW team any quetion, but then I need "original question mail" from you guys.
It is difficult to create it by myself, since I don't know detail of this issue/background/problem.
Then, please send question email to my or shimoda­san.
We can convert it English ­> Japanese, and ask to HW team. then feedback to you guys.
Is that OK ?
Magnus Damm ­ 11:53 AM
Morimoto­san, I think you can get history from Shimoda­san
or me
Geert Uytterhoeven ­ 11:53 AM
If the original answer is VHDL, please don't translate VHDL ­> Japanese ­> English
Topic 2. SMP DT
Magnus Damm ­ 11:53 AM
ok
Geert Uytterhoeven ­ 11:55 AM
This is about properly handling this with DT support, which is not backwards compatible with old DT
And it hinders topic 3. Legacy board phase out.
Magnus, you had patches to move forward?
Magnus Damm ­ 11:55 AM
(Only if we want to)
Yeah, I think it is fine to disconnect the DT SMP enablement from the board phase­out
Simon Horman ­ 11:56 AM
From my point of view the key is to undersand how we can move forward with the new DT SMP properties.
Magnus Damm ­ 11:56 AM
This because DT SMP is likely to take quite a bit of time
Simon Horman ­ 11:56 AM
While handling backwards compatibility in some controlled fashion
Magnus Damm ­ 11:56 AM
Especially if we are going to open the can of worms with challenging the current API
Geert Uytterhoeven ­ 11:57 AM
Yes
Magnus Damm ­ 11:57 AM
s/API/DT style/g
Simon Horman ­ 11:57 AM
And from my point of view r8a7779/marzen is a particularly interesting/difficult case
Magnus Damm ­ 11:58 AM
I think it is a silly case, because we have nothing to share code with for r8a7779
at least for R­Car Gen2 we can use a new DT format to enable SMP on remaining SoCs
r8a7779 is breakage only without upside. complete wank
Geert Uytterhoeven ­ 11:59 AM
And we don't care about DT backward compatibility for R­Car Gen1
Magnus Damm ­ 11:59 AM
Well..
We have some freedom
Simon Horman ­ 12:00 PM
[to summarise the interesting/difficult big] we have an SoC (r8a7779) compat string which does not support
SMP while we have board (marzen, marzen­reference) compat strings which do support SMP. And the default
configuration gives the latter.
s/big/bit/
Magnus Damm ­ 12:01 PM
What's the upside of doing SMP DT first?
(or doing it at all)
I mean compared to phasing out board support first
Geert Uytterhoeven ­ 12:02 PM
For Gen1 or Gen2?
Magnus Damm ­ 12:02 PM
r8a7779
Geert Uytterhoeven ­ 12:02 PM
We don't break SMP
Magnus Damm ­ 12:02 PM
We do require DTB update for the existing boards, no?
which equals breakage
Geert Uytterhoeven ­ 12:03 PM
Yes. So we have to update the DTB to keep SMP.
Magnus Damm ­ 12:03 PM
if we do SMP DT first
Simon Horman ­ 12:03 PM
taking a step back
Geert Uytterhoeven ­ 12:04 PM
I understand there will be only one mandatory DT upgrade instead of two?
Simon Horman ­ 12:04 PM
I believe we already support SMP for marzen using multiplatform
Magnus Damm ­ 12:04 PM
simon: correct ­ SMP is already supported by board­marzen­reference.c
Geert: I don't see the number of required updates?
Geert Uytterhoeven ­ 12:06 PM
Forget about it, I think I'm mixing up with something else
Magnus Damm ­ 12:06 PM
So adding a DT SMP dependency just delays things from my point of view
and by "things" i mean board cleanup
Laurent: Can you explain your concern?
Laurent Pinchart ­ 12:07 PM
if we add SMP support through the machine description first
Simon Horman ­ 12:07 PM
and by cleanup, your mean removal, right?
Geert Uytterhoeven ­ 12:07 PM
For r8a7779 we may do without SMP DT. What prevents us from adding .smp =
smp_ops(r8a7779_smp_ops), to setup­r88a7770.c?
Laurent Pinchart ­ 12:07 PM
and then later move to DT­based SMP support
we'll have a regression
Magnus Damm ­ 12:08 PM
laurent: we only have a regression when we decide to remove backward­support
Geert Uytterhoeven ­ 12:08 PM
(setup­r8a7779.c, of course)
Laurent Pinchart ­ 12:08 PM
Magnus: of course
and I'd like to remove that
or, rather, not introduce it in the first place
Magnus Damm ­ 12:08 PM
simon: cleanup = removal, yes
but we already have that for the board case, no?
so it is a matter of when to remove it?
Laurent Pinchart ­ 12:09 PM
it's bad enough when we only have to deal with backward compat for unforeseen issues
if we already know that bindings will become deprecated before using them, it's even worse
Magnus Damm ­ 12:10 PM
i thought we already were using them?
Laurent Pinchart ­ 12:10 PM
on some platforms yes
my point is about new platforms
Magnus Damm ­ 12:10 PM
on all r8a7779 systems
new platforms of course
but r8a7779 is not new
Geert Uytterhoeven ­ 12:11 PM
I think ignoring DT SMP for r8a7779 makes sense. We already have enough to do for Gen2
(and Gen3)
Magnus Damm ­ 12:11 PM
We can perhaps keep an incremental DT SMP for r8a7779 task around?
But not let that block board phase out
Geert Uytterhoeven ­ 12:11 PM
yes
task added
What about Gen2?
Magnus Damm ­ 12:12 PM
We should add SMP DT before adding SMP support for new SoCs
Simon Horman ­ 12:12 PM
magnus: would that retain the current beaviour where multiplatform supports SMP for marzen?
Magnus Damm ­ 12:12 PM
but before adding SMP DT I want to discuss the DT format with ARM SoC maintainers
Geert Uytterhoeven ­ 12:12 PM
Yes, else we're "too late", and stuck with more backward compatibility
Magnus Damm ­ 12:13 PM
simon and geert: i'm confused with mix of marzen and Gen2, please rephrase
Simon Horman ­ 12:13 PM
perhaps I am confused. Geert, did you have a proposal?
Geert Uytterhoeven ­ 12:14 PM
If we add SMP support for new SoCs before adding SMP DT, we're "too late", and stuck with more backward
compatibility
Magnus Damm ­ 12:14 PM
Geert: we will not
we have the "old way" for r8a7790 and r8a7791
Geert Uytterhoeven ­ 12:14 PM
not add support? Not be late?
Laurent Pinchart ­ 12:14 PM
if we go strought for SMP DT for new SoCs I'll be happy, I don't need more
s/strought/straight/
Magnus Damm ­ 12:15 PM
Laurent: of course, i thought that's what we're doing
perhaps I'm wrong, but I thought newer SoCs don't include SMP support at this point
Simon Horman ­ 12:15 PM
I think that is the nub of the issue
Magnus Damm ­ 12:15 PM
Ulrich: do you know hte current state?
Geert Uytterhoeven ­ 12:15 PM
Does that include the option to use new SMP DT (with a new DT of course) on '90/'91?
Simon Horman ­ 12:15 PM
We should use the latest way to handle new SoCs.
Magnus Damm ­ 12:15 PM
yes of course
Ulrich Hecht ­ 12:16 PM
of what?
Magnus Damm ­ 12:16 PM
if newer kernel suport for SoCs include SMP support or not? I don't remember latest state, but i believe you
hacked on it
My series "[PATCH 00/04] ARM: shmobile: APMU DT support via SMP Enable method" is intended to upgrade
SMP DT on r8a7790 and r8a7791, and be the only format for newer SoCs
Laurent Pinchart ­ 12:17 PM
Geert: for 90 and 91, I'd like to add support for SMP DT and deprecate smp_ops. we'll have to keep them for
backward compatibility of course, and hopefully phase them out at some point
Ulrich Hecht ­ 12:17 PM
no, i'm not aware
Geert Uytterhoeven ­ 12:17 PM
OK
Magnus Damm ­ 12:18 PM
ulrich: ok
Laurent Pinchart ­ 12:18 PM
it looks like we all agree, don't we ?
Magnus Damm ­ 12:18 PM
i think so
good
Simon Horman ­ 12:18 PM
can we clafiry what we agreed on
?
Magnus Damm ­ 12:18 PM
but i still want to discuss with ARM SoC maintainers about the existing format
Laurent Pinchart ­ 12:18 PM
action points ? discuss SMP DT bindings with ARM SoC maintainers ?
Magnus Damm ­ 12:18 PM
yeah
Geert Uytterhoeven ­ 12:18 PM
Running out of time
Magnus Damm ­ 12:18 PM
that is one task for sure
another task is APMU DT support
Simon Horman ­ 12:19 PM
ok, geert, perhaps you could summarise things in an email
Geert Uytterhoeven ­ 12:19 PM
My task list is
1. discuss SMP DT bindings with ARM SoC maintainers
2. Add DT SMP support for new SoCs (r8a7793/r8a7794)
A. Plan phase­out of old smp_ops for r8a7790/r8a7791
B. DT SMP for r8a7779
Magnus Damm ­ 12:19 PM
sweet, thanks!!
Geert Uytterhoeven ­ 12:19 PM
Isn't APMU DT included?
Magnus Damm ­ 12:19 PM
it is part of 2
Geert Uytterhoeven ­ 12:20 PM
I mean, needed for seconary bringup?
Magnus Damm ­ 12:20 PM
currently C structures encode the base address of the APMU
DT is on the way
Geert Uytterhoeven ­ 12:20 PM
yes, that needs to move to DT
Magnus Damm ­ 12:20 PM
but I rather handle it together with the silly "enable­method" or whatnot
Geert Uytterhoeven ­ 12:21 PM
yep
Topic 3. Legacy board phase out.
r8a7740 and sh73a0 are gone
r8a7778 and r8a7779 are next
Simon Horman ­ 12:22 PM
is anything blocking the Gen1 boards?
Geert Uytterhoeven ­ 12:22 PM
(esp. r8a7779 would make SYSC PM domains less work)
Kuninori Morimoto ­ 12:22 PM
Can we remove r8a7778/r8a7779 support from driver then ? if so it is very good for me
Simon Horman ­ 12:22 PM
I know we just talked about SMP for the 79. But anying else?
Magnus Damm ­ 12:22 PM
Now when r8a7779 SMP DT has been agreed then we can fix that
I will resubmit patches
Geert Uytterhoeven ­ 12:23 PM
we still need '78/'79 support in drivers, but only DT based
bockw mostly needs vin etc?
Simon Horman ­ 12:23 PM
morimoto­san: we are talking about removing legacy (non­multiplatform) support. Not all support.
Kuninori Morimoto ­ 12:24 PM
sorry
Simon Horman ­ 12:24 PM
Ok, so some vin bindings are a dependency for removing bockw legacy?
Magnus Damm ­ 12:24 PM
can anyone volunteer to get rid of r8a7778 legacy?
and finalize the conversion?
Geert Uytterhoeven ­ 12:25 PM
The pins are in the dts, but not the vin enablement
Magnus Damm ­ 12:25 PM
in reverse order?
How many Bock­W boards do we have?
Laurent Pinchart ­ 12:25 PM
what are the missing pieces beyond vin ?
Magnus Damm ­ 12:25 PM
I have one
Simon Horman ­ 12:25 PM
I could look into that
Geert Uytterhoeven ­ 12:25 PM
usb is missing
Simon Horman ­ 12:26 PM
ok, so its enabled in board code but not in DT?
Geert Uytterhoeven ­ 12:26 PM
yep
Simon Horman ­ 12:26 PM
ok
Geert Uytterhoeven ­ 12:26 PM
(was the same on armadillo, there it was known borken)
Laurent Pinchart ­ 12:26 PM
are we missing USB DT support completely, or is it just a matter of enabling it ?
Simon Horman ­ 12:26 PM
how about I start by looking at exactly what is missing: so far the list is vin and usb DT enablement
Laurent Pinchart ­ 12:26 PM
how about the FPGA IRQ controller ?
Geert Uytterhoeven ­ 12:27 PM
task added
Simon Horman ­ 12:27 PM
i have (remote) access to the hw. so that is a start
Magnus Damm ­ 12:27 PM
simon: ok, but pretty useless for USB and VIN
Simon Horman ­ 12:27 PM
i also suspect ethernet is broken all over the place for gen1. that could be another task.
Magnus Damm ­ 12:27 PM
and real physical hardware seems like a waste of time
in general r8a7778 seems like a waste of time to me
but that's just me
Simon Horman ­ 12:28 PM
ok
shold we jsut remove it from mainline entirely?
Magnus Damm ­ 12:28 PM
add a task: give magnus coffee to make him less grumpy
Simon Horman ­ 12:28 PM
or leave it there without usb and vin enabled?
Magnus Damm ­ 12:28 PM
Simon, you are interested in fixing it up?
is it possible to do so remotely?
Geert Uytterhoeven ­ 12:29 PM
fpga is in both board­bockw.c and board­bockw­reference.c
Magnus Damm ­ 12:29 PM
and is that our only board?
Geert Uytterhoeven ­ 12:29 PM
needed for sound and ethernet?
Simon Horman ­ 12:29 PM
usb sounds possible to me
vin, perhaps not
Magnus Damm ­ 12:30 PM
so perhaps USB and VIN shall be moved to I/O and Multimedia discussions?
and we can decide to either wait for those or just remove regardless
Simon Horman ­ 12:30 PM
good idea
I'm interested in getting bockw fixd to whatever level we agree is sane.
Magnus Damm ­ 12:30 PM
Maybe we can vote on what level is sane?
Simon Horman ­ 12:31 PM
I would not object
Geert Uytterhoeven ­ 12:31 PM
Before we can vote, we need
Simon Horman ­ 12:31 PM
anyway, i will look at what is missing
Geert Uytterhoeven ­ 12:31 PM
1. Identify missing support in multi­platform r8a7778
(VIN, USB, FPGA IRQ?)
2. Identify missing support in multi­platform r8a7779
Then
3. Add support for valuable devices to multi­platform r8a7778
4. Add support for valuable devices to multi­platform r8a7779
sorry, 2b vote
Simon Horman ­ 12:32 PM
sounds good
Magnus Damm ­ 12:32 PM
Geert: Sure, that is true, but there are cleanups needed before 1 too
Geert Uytterhoeven ­ 12:32 PM
6. Drop legacy r8a7778/bockw
7. Drop legacy r8a7779/marzen
Simon Horman ­ 12:32 PM
shall I take 1 and 2(a) ?
Magnus Damm ­ 12:32 PM
for instance, for r8a7779 we can remove the board­marzen­reference.c
and for r8a7778 I think we have split DTSI still?
Simon Horman ­ 12:32 PM
cleanups required to identify what is incomplete?
Magnus Damm ­ 12:33 PM
no my 0 cleaups are independent
i'll fix r8a7779
Geert Uytterhoeven ­ 12:33 PM
Yes r8a7778­bockw.dts and r8a7778­bockw­reference.dts
Magnus Damm ­ 12:33 PM
but someone needs to fix r8a7778
who had r8a7779 multiplatform as task?
Simon Horman ­ 12:33 PM
it should not be as difficule at 79
Magnus Damm ­ 12:33 PM
i mean r8a7778 multiplat
Simon Horman ­ 12:33 PM
as its UP, right?
Laurent Pinchart ­ 12:34 PM
Magnus: don't we also miss r8a7779_init_irq_extpin ?
Magnus Damm ­ 12:34 PM
laurent: it has been fixed already
Laurent Pinchart ­ 12:34 PM
it's called from board­marzn­reference.c
ah ok
Magnus Damm ­ 12:34 PM
quite recently
so the board­mz­ref.c is ready to go after some minor SMP bit
but r8a7778 is more messy
Laurent Pinchart ­ 12:35 PM
where's the fix ?
Magnus Damm ­ 12:35 PM
it should have been picked up by simon
it was in the same series as where you questioned the SMP DT order for r8a7779.
let me find it
Laurent Pinchart ­ 12:36 PM
"[PATCH v2 01/06] ARM: shmobile: r8a7779: Configure IRLM mode via DT" ?
Magnus Damm ­ 12:36 PM
yes
Geert Uytterhoeven ­ 12:36 PM
We ran out of time
Laurent Pinchart ­ 12:36 PM
ok, I didn't realize it was about that
Magnus Damm ­ 12:36 PM
once all contents of "[PATCH v2 00/06] ARM: shmobile: r8a7779 IRQ update and Marzen cleanup V2" are in i
intend to remove legacy code too
Laurent Pinchart ­ 12:37 PM
by the way the commit message says "Adjust the r8a7779 SoC DTS and the Marzen Reference
C board code to use DTS only for INTC­IRQPIN IRLM setup."
Magnus Damm ­ 12:37 PM
but step by step
Laurent Pinchart ­ 12:37 PM
but the patch doesn't touch C board code
Magnus Damm ­ 12:37 PM
the board removal patch takes care of that i think
Laurent Pinchart ­ 12:37 PM
yes it does
Magnus Damm ­ 12:38 PM
so who can do r8a7778?
who did it initially?
Ulrich Hecht ­ 12:38 PM
r8a7778 MP was me
but i don't have a board, making usb and vin difficult
Geert Uytterhoeven ­ 12:38 PM
We found a winner
Magnus Damm ­ 12:38 PM
you have a core developer task, right?
Ulrich Hecht ­ 12:39 PM
me? yes, i do
Magnus Damm ­ 12:39 PM
if so, can you move the multiplatform support forward?
like getting rid of that duplicated DTS setup
and things that do not depend on vin and usb
Geert Uytterhoeven ­ 12:40 PM
Guys, we're running late. And my daughters want me to join lunch
Ulrich Hecht ­ 12:40 PM
i just checked, and i think the list of missing stuff is conclusive. so apart from usb and vin, there's the fpga
Magnus Damm ­ 12:40 PM
ok ok
Geert Uytterhoeven ­ 12:40 PM
I will send the task list to periperi for final review
Magnus Damm ­ 12:40 PM
thanks a lot everyone
Geert Uytterhoeven ­ 12:40 PM
yes, thanks a lot.
Magnus Damm ­ 12:40 PM
and thanks for preparing the task list geert!!
and arranging this meeting
Simon Horman ­ 12:40 PM
Likewise, thanks everyine
Geert Uytterhoeven ­ 12:41 PM
Will send out an invitation and RFC for topics for next chat
Magnus Damm ­ 12:41 PM
wonderful
Laurent Pinchart ­ 12:41 PM
what about the todo list format ? next time ?
Ulrich Hecht ­ 12:41 PM
thanks, too. and if someone can give me a hint as to how to handle the fpga, i'd appreciate it
Magnus Damm ­ 12:41 PM
ulrich: you can probably merge DTS independently of FPGA
Geert Uytterhoeven ­ 12:41 PM
the fpga seems to be needed for Ethernet
Laurent Pinchart ­ 12:41 PM
Ulrich: you might need to write a driver for the FPGA I'm afraid
Ulrich Hecht ­ 12:41 PM
yes, of course
Laurent Pinchart ­ 12:41 PM
I can assist with that
Ulrich Hecht ­ 12:42 PM
that would be helpful. i couldn't find anything similar on other platforms
Laurent Pinchart ­ 12:42 PM
we can discuss it later. on IRC maybe ?
Geert Uytterhoeven ­ 12:42 PM
bye! (I'll keep the chat window open, though)
Magnus Damm ­ 12:42 PM
bye bye!
Ulrich Hecht ­ 12:43 PM
i'd prefer something more asynchronous, like e­mail
Simon Horman ­ 12:43 PM
I also need to attend to family matters, but will leave this window open. I expect to be back in 20min or so
Laurent Pinchart ­ 12:43 PM
Ulrich: that works too
Ulrich Hecht ­ 12:43 PM
ok, thanks a lot
Kuninori Morimoto ­ 12:47 PM
Bye, I go back to my home
Yoshihiro Shimoda ­ 12:50 PM
Bye! I also go back to my home