Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Tue, Sep 08, 2020 at 11:42:26AM +0100, Lorenzo Pieralisi wrote: > > Maybe we can parallelize the PCIe driver review while the DMA changes > > are being worked on in Christoph's branch. Lorenzo, are you fine with > > the PCIe changes proper? > > I will have a look - the main contentious point was about the DMA > changes - if Christoph is happy with them I am OK with them > too - I hope there is not anything controversial in the host > bridge driver itself but I will look into it. I'm pretty happy with the overall shape. Now we just need to squeeze out the regressions.. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Mon, Sep 07, 2020 at 11:29:06AM -0700, Florian Fainelli wrote: > > > On 9/7/2020 10:43 AM, Jim Quinlan wrote: > > On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi > > wrote: > > > > > > On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: > > > > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > > > > > > > > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > > > > > Hi, > > > > > > > > > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > > > > > > > > > > > > > > Patchset Summary: > > > > > > > Enhance a PCIe host controller driver. Because of its > > > > > > > unusual design > > > > > > > we are foced to change dev->dma_pfn_offset into a more > > > > > > > general role > > > > > > > allowing multiple offsets. See the 'v1' notes below for more > > > > > > > info. > > > > > > > > > > > > We are version 11 and counting, and it is not clear to me whether > > > > > > there is > > > > > > any chance of getting these patches reviewed and hopefully merged > > > > > > for the > > > > > > 5.10 merge window. > > > > > > > > > > > > There are a lot of different files being touched, so what would be > > > > > > the > > > > > > ideal way of routing those changes towards inclusion? > > > > > > > > > > FYI, I offered to take the dma-mapping bits through the dma-mapping > > > > > tree. > > > > > I have a bit of a backlog, but plan to review and if Jim is ok with > > > > > that > > > > > apply the current version. > > > > Sounds good to me. > > > > > > Hi Jim, > > > > > > is the dependency now solved ? Should we review/take this series as > > > is for v5.10 through the PCI tree ? > > Hello Lorenzo, > > > > We are still working out a regression with the DMA offset commit on > > the RaspberryPi. Nicolas has found the root cause and we are now > > devising a solution. > > Maybe we can parallelize the PCIe driver review while the DMA changes > are being worked on in Christoph's branch. Lorenzo, are you fine with > the PCIe changes proper? I will have a look - the main contentious point was about the DMA changes - if Christoph is happy with them I am OK with them too - I hope there is not anything controversial in the host bridge driver itself but I will look into it. Lorenzo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On 9/7/2020 10:43 AM, Jim Quinlan wrote: On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi wrote: On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: Hi, On 8/24/2020 12:30 PM, Jim Quinlan wrote: Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. We are version 11 and counting, and it is not clear to me whether there is any chance of getting these patches reviewed and hopefully merged for the 5.10 merge window. There are a lot of different files being touched, so what would be the ideal way of routing those changes towards inclusion? FYI, I offered to take the dma-mapping bits through the dma-mapping tree. I have a bit of a backlog, but plan to review and if Jim is ok with that apply the current version. Sounds good to me. Hi Jim, is the dependency now solved ? Should we review/take this series as is for v5.10 through the PCI tree ? Hello Lorenzo, We are still working out a regression with the DMA offset commit on the RaspberryPi. Nicolas has found the root cause and we are now devising a solution. Maybe we can parallelize the PCIe driver review while the DMA changes are being worked on in Christoph's branch. Lorenzo, are you fine with the PCIe changes proper? -- Florian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi wrote: > > On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: > > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > > > > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > > > Hi, > > > > > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > > > >> > > > >> Patchset Summary: > > > >>Enhance a PCIe host controller driver. Because of its unusual > > > >> design > > > >>we are foced to change dev->dma_pfn_offset into a more general role > > > >>allowing multiple offsets. See the 'v1' notes below for more info. > > > > > > > > We are version 11 and counting, and it is not clear to me whether there > > > > is > > > > any chance of getting these patches reviewed and hopefully merged for > > > > the > > > > 5.10 merge window. > > > > > > > > There are a lot of different files being touched, so what would be the > > > > ideal way of routing those changes towards inclusion? > > > > > > FYI, I offered to take the dma-mapping bits through the dma-mapping tree. > > > I have a bit of a backlog, but plan to review and if Jim is ok with that > > > apply the current version. > > Sounds good to me. > > Hi Jim, > > is the dependency now solved ? Should we review/take this series as > is for v5.10 through the PCI tree ? Hello Lorenzo, We are still working out a regression with the DMA offset commit on the RaspberryPi. Nicolas has found the root cause and we are now devising a solution. Thanks, Jim Quinlan Broadcom STB > > Thanks, > Lorenzo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote: > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > > Hi, > > > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > > >> > > >> Patchset Summary: > > >>Enhance a PCIe host controller driver. Because of its unusual design > > >>we are foced to change dev->dma_pfn_offset into a more general role > > >>allowing multiple offsets. See the 'v1' notes below for more info. > > > > > > We are version 11 and counting, and it is not clear to me whether there is > > > any chance of getting these patches reviewed and hopefully merged for the > > > 5.10 merge window. > > > > > > There are a lot of different files being touched, so what would be the > > > ideal way of routing those changes towards inclusion? > > > > FYI, I offered to take the dma-mapping bits through the dma-mapping tree. > > I have a bit of a backlog, but plan to review and if Jim is ok with that > > apply the current version. > Sounds good to me. Hi Jim, is the dependency now solved ? Should we review/take this series as is for v5.10 through the PCI tree ? Thanks, Lorenzo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > Hi, > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > >> > >> Patchset Summary: > >>Enhance a PCIe host controller driver. Because of its unusual design > >>we are foced to change dev->dma_pfn_offset into a more general role > >>allowing multiple offsets. See the 'v1' notes below for more info. > > > > We are version 11 and counting, and it is not clear to me whether there is > > any chance of getting these patches reviewed and hopefully merged for the > > 5.10 merge window. > > > > There are a lot of different files being touched, so what would be the > > ideal way of routing those changes towards inclusion? > > FYI, I offered to take the dma-mapping bits through the dma-mapping tree. > I have a bit of a backlog, but plan to review and if Jim is ok with that > apply the current version. Sounds good to me. Thanks, Jim ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > Hi, > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: >> >> Patchset Summary: >>Enhance a PCIe host controller driver. Because of its unusual design >>we are foced to change dev->dma_pfn_offset into a more general role >>allowing multiple offsets. See the 'v1' notes below for more info. > > We are version 11 and counting, and it is not clear to me whether there is > any chance of getting these patches reviewed and hopefully merged for the > 5.10 merge window. > > There are a lot of different files being touched, so what would be the > ideal way of routing those changes towards inclusion? FYI, I offered to take the dma-mapping bits through the dma-mapping tree. I have a bit of a backlog, but plan to review and if Jim is ok with that apply the current version. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
Hi, On 8/24/2020 12:30 PM, Jim Quinlan wrote: Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. We are version 11 and counting, and it is not clear to me whether there is any chance of getting these patches reviewed and hopefully merged for the 5.10 merge window. There are a lot of different files being touched, so what would be the ideal way of routing those changes towards inclusion? Thanks! -- Florian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. v11: Commit: "device-mapping: Introduce DMA range map, supplanting ..." -- Rebased to latest torvalds, Aug 20, 2020. -- Minor change in of_dma_get_range() to satisfy the kernel's robot tester. -- Use of PFN_DOWN(), PFN_PHYS() instead of explicit shifts (Andy) -- Eliminate extra return in dma_offset_from_xxx_addr() (Andy) -- Change dma_set_offset_range() to correctly handle the case of pre-existing DMA map and zero offset. v10: Commit: "device-mapping: Introduce DMA range map, supplanting ..." -- change title of commit; "bus core:" => "device-mapping:" -- instead of allocating the DMA map with devm, use kcalloc and call kfree() during device_release(). (RobH) Also, for three cases that want to use the same DMA map, copy the dma_range_map using a helper function. -- added a missing 'return = 0;' to of_dma_get_range(). (Nicolas) -- removed dma_range_overlaps(); instead return error if there is an existing DMA map. (Christoph). Commit: "PCI: brcmstb: Set additional internal memory DMA ..." -- Changed constant 1 to 1ULL. (Nicolas) Commit: "ata: ahci_brcm: Fix use of BCM7216 reset controller" This commit has been removed from this patchset and will be submitted on its own. v9: Commit: "device core: Introduce DMA range map, supplanting ..." -- A number of code improvements were implemented as suggested by ChristophH. Unfortunately, some of these changes reversed the implemented suggestions of other reviewers; for example, the new macros PFN_DMA_ADDR(), DMA_ADDR_PFN() have been pulled. v8: Commit: "device core: Introduce DMA range map, supplanting ..." -- To satisfy a specific m68 compile configuration, I moved the 'struct bus_dma_region; definition out of #ifdef CONFIG_HAS_DMA and also defined three inline functions for !CONFIG_HAS_DMA (kernel test robot). -- The sunXi drivers -- suc4i_csi, sun6i_csi, cedrus_hw -- set a pfn_offset outside of_dma_configure() but the code offers no insight on the size of the translation window. V7 had me using SIZE_MAX as the size. I have since contacted the sunXi maintainer and he said that using a size of SZ_4G would cover sunXi configurations. v7: Commit: "device core: Introduce DMA range map, supplanting ..." -- remove second kcalloc/copy in device.c (AndyS) -- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS) -- indentation, sizeof(struct ...) => sizeof(*r) (AndyS) -- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS) -- Fixed compile error in "sun6i_csi.c" (kernel test robot) Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller" -- correct name of function in the commit msg (SergeiS) v6: Commit "device core: Introduce DMA range map": -- of_dma_get_range() now takes a single argument and returns either NULL, a valid map, or an ERR_PTR. (Robin) -- offsets are no longer a PFN value but an actual address. (Robin) -- the bus_dma_region struct stores the range size instead of the cpu_end and pci_end values. (Robin) -- devices that were setting a single offset with no boundaries have been modified to have boundaries; in a few places where this information was unavilable a /* FIXME: ... */ comment was added. (Robin) -- dma_attach_offset_range() can be called when an offset map already exists; if it's range is already present nothing is done and success is returned. (Robin) All commits: -- Man name/style/corrections/etc changed (Bjorn) -- rebase to Torvalds master v5: Commit "device core: Introduce multiple dma pfn offsets" -- in of/address.c: "map_size = 0" => "*map_size = 0" -- use kcalloc instead of kzalloc (AndyS) -- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0" Commit "PCI: brcmstb: Set internal memory viewport sizes" -- now gives error on missing dma-ranges property. Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips" -- removed "Allof:" from brcm,scb-sizes definition (RobH) All Commits: -- indentation style, use max chars 100 (AndyS) -- rebased to torvalds master v4: Commit "device core: Introduce multiple dma pfn offsets" -- of_dma_get_range() does not take a dev param but instead takes two "out" params: map and map_size. We do this so that the code that parses dma-ranges is separate from the code that modifies 'dev'. (Nicolas) -- the separate case of having a single pfn offset has been removed and is now processed by going through the map array. (Nicolas) -- move attach_uniform_dma_pfn_offset() from of/address.c to dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas) -- devm_kcalloc => devm_kzalloc (DanC) -- add/fix assignment to
