Date
1 - 6 of 6
[PROPOSAL] Fix platform device irq domain support and gpio irq DT
Jean-Christophe PLAGNIOL-VILLARD
Hi,
Summary ======= Fix IRQ Domain DT support issues and gpio IRQ Proposer ======== Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...> Description =========== Today the kernel have multiple issues arround the IRQ * IRQ Domain platfrom driver support Today if you register an irq domain via a platform driver and then use the irq in DT such as this eth0: ethernet@30000000 { compatible = "micrel,ks8851-mll"; reg = <0x30000000 0x1 0x30000002 0xff>; interrupt-parent = <&pioD>; interrupts = <21 IRQ_TYPE_EDGE_BOTH>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_board_eth0>; status = "okay"; }; the irq in the platform resource will not be fill as the resolve is done at of_platform_populate To fix this we need to resolve the irq at driver probe time. * Multiple interrupt-parent support Today if you need the irq from 2 interrupt controler it's impossible. Such as a hw irq and a GPIO irq both provided via dt To fix this implement a new property "interrupt-lines" that will work in a same way as gpios by providing firt the phandle of the controller and then the cell data interrupt-lines = <&aic 0 4 0 & pioD 21 IRQ_TYPE_EDGE_BOTH>; * gpio irq DT Today you need to use a gpio as IRQ you need to configure it and then use it As a in the kernel we make the disctinction between standard IRQ and gpio IRQ. This should have never been the case and need to be fix up widely. By droping all the gpio_to_irq in the drivers and ONLY provide interrupts Scope ===== I think the main ideas can be discussed and implemented in 240 hours effort. If the duration is 3 or 5 months depends on how discussions with upstream go. Contractor candidates ===================== Given that I already started digging into the topic, have some designs sketched and already submitted initial patches, I recommend myself. I also think I have enough upstream experience to deal with such a major task. Best Regards, J. _______________________________________________ Celinux-dev mailing list Celinux-dev@... https://lists.celinuxforum.org/mailman/listinfo/celinux-dev |
|
Wolfram Sang
ScopeEeks, these are my text-blocks. This is weak. Tim, I think we should remove the "share-alike" from proposals? I mean, if the topic is of real importance, one can easily invest a bit of time for those two paragraphs. And as a sidenote, it doesn't fit well. Since Jean dropped the "Related work" section, there is no proof about digging into the topic and sketching some designs. Wolfram |
|
Wolfram Sang
Tim, I think we should remove the "share-alike" from proposals?I mean "remove the remix". I'd suggest CC BY-ND for proposals. |
|
Jean-Christophe PLAGNIOL-VILLARD
On 11:55 Wed 02 Oct , Wolfram Sang wrote:
yeah I like the english so I re-use it if you do not mindScopeEeks, these are my text-blocks. This is weak. Tim, I think we should sorry patch on the device-tree ML http://permalink.gmane.org/gmane.linux.drivers.devicetree/36679 Those topic was discussed with Grant and LinusW in Cc Best Regards, J.
|
|
Wolfram Sang
I do mind. I would have not if you had a) asked beforehand or b) gaveEeks, these are my text-blocks. This is weak. Tim, I think we shouldyeah I like the english so I re-use it if you do not mind correct attribution according to the license. |
|
Bird, Tim <Tim.Bird@...>
On Wednesday, October 02, 2013 2:13 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
Summary... Jean-Christophe, Given objections raised on the list, and my preference for easy submission to the elinux wiki, can you re-submit this proposal with the following changes: 1) please use the format specified in the template at: http://elinux.org/CEWG_Open_Project_Proposal_template 2) please fill in the Scope and Contractor Candidates sections with your own wording. This should not take too long. Thanks, -- Tim |
|