Hello, Às 6:00 PM de 5/10/2017, Marc Zyngier escreveu: > On 09/05/17 13:33, Joao Pinto wrote: >> This is a proposal for the update of the interrupt API in pcie-designware. >> >> *SoC specific drivers* >> All SoC specific drivers that use the common infrastructure (pci-qcom, >> pci-artpec6, pci-exynos, pci-imx6) were updated to be compatible. >> Other SoC specific drivers like pci-dra7, pci-armada8k, pci-hisi, pci-spear13xx >> and pci-layerscape will also work fine. >> >> *Work still to be done - need some inputs* >> The pci-keystone driver is the one that I would appreciate some opinions, since >> it uses the "old" dw_pcie_msi_chip. I think we have 3 options: >> >> a) Keep the old API + new API in pcie-designware just for pci-keystone to use >> the dw_pcie_msi_chip structure >> b) Move the old API from pcie-designware to pci-keystone for it to use the >> dw_pcie_msi_chip structure >> c) Adapt pci-keystone to use the new API also > > What is the issue with moving Keystone over to this infrastructure? I don't hardware to test if the Keystone infrastructure porting is right or not and thats my main concern. Also the Keystone SoC driver maintainer can also have the option of keeping the current structure and that's why I sent the e-mail asking for opinions about the subject. >> >> *Tests* >> I made tests with a PCI 4.80 Core IP, using pcie-designware-plat driver. >> I used an MSI-only Endpoint and a MSI/MSIX Endpoint and the APi adapted very >> well to the situation. >> >> Signed-off-by: Joao Pinto <jpinto@xxxxxxxxxxxx> >> --- >> drivers/pci/dwc/pci-exynos.c | 18 -- >> drivers/pci/dwc/pci-imx6.c | 18 -- >> drivers/pci/dwc/pcie-artpec6.c | 18 -- >> drivers/pci/dwc/pcie-designware-host.c | 342 +++++++++++++++++---------------- >> drivers/pci/dwc/pcie-designware-plat.c | 15 -- >> drivers/pci/dwc/pcie-designware.h | 6 +- >> drivers/pci/dwc/pcie-qcom.c | 15 -- >> 7 files changed, 179 insertions(+), 253 deletions(-) > > May I suggest something for your next posting? This patch is extremely > difficult to read (not your fault at all), as it deletes a lot of code > and replaces it by code that is mostly unrelated. It would be a lot > better if you had a series that: > > 1: adds the new infrastructure in parallel with the old one, with an > opt-in mechanism. > 2: convert each individual platform (one patch per SoC) > 3: remove the old code entirely. > > This will result in a much more readable series, and will give us a good > way to bisect, should a given platform break. Yep indeed! I will do the 3 patch way as you are suggesting. Thanks!
