This series adds a driver to control the Aspeed XDMA engine embedded in the
AST2500 and AST2600. The XDMA engine performs automatic DMA operations
over PCI-E between the Aspeed SOC (acting as a BMC) and a host processor.
Changes since v6:
- See individual patches
Eddie James (5):
dt-bindings: soc: Add Aspeed XDMA engine
soc: aspeed: Add XDMA Engine Driver
soc: aspeed: xdma: Add user interface
soc: aspeed: xdma: Add reset ioctl
ARM: dts: Aspeed: AST2600: Add XDMA PCI-E root control reset
.../devicetree/bindings/soc/aspeed/xdma.txt | 44 +
MAINTAINERS | 8 +
arch/arm/boot/dts/aspeed-g6.dtsi | 3 +-
drivers/soc/aspeed/Kconfig | 8 +
drivers/soc/aspeed/Makefile | 1 +
drivers/soc/aspeed/aspeed-xdma.c | 1084 +++++++++++++++++
include/uapi/linux/aspeed-xdma.h | 42 +
7 files changed, 1189 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/soc/aspeed/xdma.txt
create mode 100644 drivers/soc/aspeed/aspeed-xdma.c
create mode 100644 include/uapi/linux/aspeed-xdma.h
--
2.24.0
On Fri, 3 Apr 2020, at 06:19, Eddie James wrote:
> This series adds a driver to control the Aspeed XDMA engine embedded in the
> AST2500 and AST2600. The XDMA engine performs automatic DMA operations
> over PCI-E between the Aspeed SOC (acting as a BMC) and a host processor.
>
> Changes since v6:
> - See individual patches
v7 is not an evolution on v6 - v7 contains a bunch of bugs that v6 fixed (at least
wrt locking). How did you generate this series?
Also my name is misspelled in each of the Reviewed-by: tags which makes me
think that something has gone quite wrong with the posting of v7, and I'm
concerned that this was based on e.g. v5 but with my tags against v6 applied.
Andrew
On 4/2/20 7:32 PM, Andrew Jeffery wrote:
>
> On Fri, 3 Apr 2020, at 06:19, Eddie James wrote:
>> This series adds a driver to control the Aspeed XDMA engine embedded in the
>> AST2500 and AST2600. The XDMA engine performs automatic DMA operations
>> over PCI-E between the Aspeed SOC (acting as a BMC) and a host processor.
>>
>> Changes since v6:
>> - See individual patches
> v7 is not an evolution on v6 - v7 contains a bunch of bugs that v6 fixed (at least
> wrt locking). How did you generate this series?
My goodness, I could have sworn that was v6. I took the series that was
merged in the openbmc kernel. Must have gotten mixed up. -_-
>
> Also my name is misspelled in each of the Reviewed-by: tags which makes me
> think that something has gone quite wrong with the posting of v7, and I'm
> concerned that this was based on e.g. v5 but with my tags against v6 applied.
Well thats because I added them manually since they had "disappeared" or
so I thought from v6 during the application to openbmc... guess that
should have been a warning sign
>
> Andrew
On Sat, 4 Apr 2020, at 01:22, Eddie James wrote:
>
> On 4/2/20 7:32 PM, Andrew Jeffery wrote:
> >
> > On Fri, 3 Apr 2020, at 06:19, Eddie James wrote:
> >> This series adds a driver to control the Aspeed XDMA engine embedded in the
> >> AST2500 and AST2600. The XDMA engine performs automatic DMA operations
> >> over PCI-E between the Aspeed SOC (acting as a BMC) and a host processor.
> >>
> >> Changes since v6:
> >> - See individual patches
> > v7 is not an evolution on v6 - v7 contains a bunch of bugs that v6 fixed (at least
> > wrt locking). How did you generate this series?
>
>
> My goodness, I could have sworn that was v6. I took the series that was
> merged in the openbmc kernel. Must have gotten mixed up. -_-
No worries, hopefully v8 is in the right state :)
>
>
> >
> > Also my name is misspelled in each of the Reviewed-by: tags which makes me
> > think that something has gone quite wrong with the posting of v7, and I'm
> > concerned that this was based on e.g. v5 but with my tags against v6 applied.
>
>
> Well thats because I added them manually since they had "disappeared" or
> so I thought from v6 during the application to openbmc... guess that
> should have been a warning sign
It certainly was for me!
Cheers,
Andrew