* [PATCH v27 0/9] arm64: add kdump support
From: James Morse @ 2016-11-10 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104030025.GC381@linaro.org>
Hi Akashi,
On 04/11/16 03:00, AKASHI Takahiro wrote:
> For easier testing, I pushed my patches to:
> https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git arm64/kdump
> https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/kdump
Aha, thanks. That saved hopping around the mail archives to find the right set
of kdump patches.
> If anybody tries my patches, please let me know the result.
I gave this a spin on Juno with all the page-size va-bits combinations it
supports and used 'crash' to fish around in the resulting image. I also tested
the 4K/39 combination on Seattle that caused us problems in the past.
If its useful:
Tested-by: James Morse <james.morse@arm.com>
So the last thing is review/acks on patch 1
"memblock: add memblock_cap_memory_range()"?
Thanks,
James
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-10 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109165044.GE10219@e106497-lin.cambridge.arm.com>
Hi Liviu
> -----Original Message-----
> From: liviu.dudau at arm.com [mailto:liviu.dudau at arm.com]
> Sent: 09 November 2016 16:51
> To: Gabriele Paoloni
> Cc: Yuanzhichang; catalin.marinas at arm.com; will.deacon at arm.com;
> robh+dt at kernel.org; bhelgaas at google.com; mark.rutland at arm.com;
> olof at lixom.net; arnd at arndb.de; linux-arm-kernel at lists.infradead.org;
> lorenzo.pieralisi at arm.com; linux-kernel at vger.kernel.org; Linuxarm;
> devicetree at vger.kernel.org; linux-pci at vger.kernel.org; linux-
> serial at vger.kernel.org; minyard at acm.org; benh at kernel.crashing.org;
> zourongrong at gmail.com; John Garry; zhichang.yuan02 at gmail.com;
> kantyzc at 163.com; xuwei (O)
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
>
> On Wed, Nov 09, 2016 at 04:16:17PM +0000, Gabriele Paoloni wrote:
> > Hi Liviu
> >
> > Thanks for reviewing
> >
>
> [removed some irrelevant part of discussion, avoid crazy formatting]
>
> > > > +/**
> > > > + * addr_is_indirect_io - check whether the input taddr is for
> > > indirectIO.
> > > > + * @taddr: the io address to be checked.
> > > > + *
> > > > + * Returns 1 when taddr is in the range; otherwise return 0.
> > > > + */
> > > > +int addr_is_indirect_io(u64 taddr)
> > > > +{
> > > > + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end
> <
> > > taddr)
> > >
> > > start >= taddr ?
> >
> > Nope... if (taddr < arm64_extio_ops->start || taddr >
> arm64_extio_ops->end)
> > then taddr is outside the range [start; end] and will return 0;
> otherwise
> > it will return 1...
>
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
>
> >
> > >
> > > > + return 0;
> > > > +
> > > > + return 1;
> > > > +}
> > > >
> > > > BUILD_EXTIO(b, u8)
> > > >
> > > > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > > > index 02b2903..cc2a05d 100644
> > > > --- a/drivers/of/address.c
> > > > +++ b/drivers/of/address.c
> > > > @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
> > > device_node *np)
> > > > return false;
> > > > }
> > > >
> > > > +
> > > > +/*
> > > > + * of_isa_indirect_io - get the IO address from some isa reg
> > > property value.
> > > > + * For some isa/lpc devices, no ranges property in ancestor
> node.
> > > > + * The device addresses are described directly in their regs
> > > property.
> > > > + * This fixup function will be called to get the IO address of
> > > isa/lpc
> > > > + * devices when the normal of_translation failed.
> > > > + *
> > > > + * @parent: points to the parent dts node;
> > > > + * @bus: points to the of_bus which can be used to parse
> > > address;
> > > > + * @addr: the address from reg property;
> > > > + * @na: the address cell counter of @addr;
> > > > + * @presult: store the address paresed from @addr;
> > > > + *
> > > > + * return 1 when successfully get the I/O address;
> > > > + * 0 will return for some failures.
> > >
> > > Bah, you are returning a signed int, why 0 for failure? Return a
> > > negative value with
> > > error codes. Otherwise change the return value into a bool.
> >
> > Yes we'll move to bool
> >
> > >
> > > > + */
> > > > +static int of_get_isa_indirect_io(struct device_node *parent,
> > > > + struct of_bus *bus, __be32 *addr,
> > > > + int na, u64 *presult)
> > > > +{
> > > > + unsigned int flags;
> > > > + unsigned int rlen;
> > > > +
> > > > + /* whether support indirectIO */
> > > > + if (!indirect_io_enabled())
> > > > + return 0;
> > > > +
> > > > + if (!of_bus_isa_match(parent))
> > > > + return 0;
> > > > +
> > > > + flags = bus->get_flags(addr);
> > > > + if (!(flags & IORESOURCE_IO))
> > > > + return 0;
> > > > +
> > > > + /* there is ranges property, apply the normal translation
> > > directly. */
> > >
> > > s/there is ranges/if we have a 'ranges'/
> >
> > Thanks for spotting this
> >
> > >
> > > > + if (of_get_property(parent, "ranges", &rlen))
> > > > + return 0;
> > > > +
> > > > + *presult = of_read_number(addr + 1, na - 1);
> > > > + /* this fixup is only valid for specific I/O range. */
> > > > + return addr_is_indirect_io(*presult);
> > > > +}
> > > > +
> > > > static int of_translate_one(struct device_node *parent, struct
> > > of_bus *bus,
> > > > struct of_bus *pbus, __be32 *addr,
> > > > int na, int ns, int pna, const char *rprop)
> > > > @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
> > > device_node *dev,
> > > > result = of_read_number(addr, na);
> > > > break;
> > > > }
> > > > + /*
> > > > + * For indirectIO device which has no ranges
> property, get
> > > > + * the address from reg directly.
> > > > + */
> > > > + if (of_get_isa_indirect_io(dev, bus, addr, na,
> &result)) {
> > > > + pr_debug("isa indirectIO matched(%s)..addr =
> > > 0x%llx\n",
> > > > + of_node_full_name(dev), result);
> > > > + break;
> > > > + }
> > > >
> > > > /* Get new parent bus and counts */
> > > > pbus = of_match_bus(parent);
> > > > @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
> > > device_node *dev,
> > > > if (taddr == OF_BAD_ADDR)
> > > > return -EINVAL;
> > > > memset(r, 0, sizeof(struct resource));
> > > > - if (flags & IORESOURCE_IO) {
> > > > + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
> > > > unsigned long port;
> > > > +
> > > > port = pci_address_to_pio(taddr);
> > > > if (port == (unsigned long)-1)
> > > > return -EINVAL;
> > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > > index ba34907..1a08511 100644
> > > > --- a/drivers/pci/pci.c
> > > > +++ b/drivers/pci/pci.c
> > > > @@ -3263,7 +3263,7 @@ int __weak
> pci_register_io_range(phys_addr_t
> > > addr, resource_size_t size)
> > > >
> > > > #ifdef PCI_IOBASE
> > > > struct io_range *range;
> > > > - resource_size_t allocated_size = 0;
> > > > + resource_size_t allocated_size = PCIBIOS_MIN_IO;
> > > >
> > > > /* check if the range hasn't been previously recorded */
> > > > spin_lock(&io_range_lock);
> > > > @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned
> long
> > > pio)
> > > >
> > > > #ifdef PCI_IOBASE
> > > > struct io_range *range;
> > > > - resource_size_t allocated_size = 0;
> > > > + resource_size_t allocated_size = PCIBIOS_MIN_IO;
> > >
> > > Have you checked that pci_pio_to_address still returns valid values
> > > after this? I know that
> > > you are trying to take into account PCIBIOS_MIN_IO limit when
> > > allocating reserving the IO ranges,
> > > but the values added in the io_range_list are still starting from
> zero,
> > > no from PCIBIOS_MIN_IO,
> >
> > I think you're wrong here as in pci_address_to_pio we have:
> > + resource_size_t offset = PCIBIOS_MIN_IO;
> >
> > This should be enough to guarantee that the PIOs start at
> > PCIBIOS_MIN_IO...right?
>
> I don't think you can guarantee that the pio value that gets passed
> into
> pci_pio_to_address() always comes from a previously returned value by
> pci_address_to_pio(). Maybe you can add a check in pci_pio_to_address()
Maybe I am missing something...could you make an exampleof a case
where an IO toke doesn?t come from pci_address_to_pio() ?
Thanks
Gab
>
> if (pio < PCIBIOS_MIN_IO)
> return address;
>
> to avoid adding more checks in the list_for_each_entry() loop.
>
> Best regards,
> Liviu
>
> >
> >
> > > so the calculation of the address in this function could return
> > > negative values casted to pci_addr_t.
> > >
> > > Maybe you want to adjust the range->start value in
> > > pci_register_io_range() as well to have it
> > > offset by PCIBIOS_MIN_IO as well.
> > >
> > > Best regards,
> > > Liviu
> > >
> > > >
> > > > if (pio > IO_SPACE_LIMIT)
> > > > return address;
> > > > @@ -3335,7 +3335,7 @@ unsigned long __weak
> > > pci_address_to_pio(phys_addr_t address)
> > > > {
> > > > #ifdef PCI_IOBASE
> > > > struct io_range *res;
> > > > - resource_size_t offset = 0;
> > > > + resource_size_t offset = PCIBIOS_MIN_IO;
> > > > unsigned long addr = -1;
> > > >
> > > > spin_lock(&io_range_lock);
> > > > diff --git a/include/linux/of_address.h
> b/include/linux/of_address.h
> > > > index 3786473..deec469 100644
> > > > --- a/include/linux/of_address.h
> > > > +++ b/include/linux/of_address.h
> > > > @@ -24,6 +24,23 @@ struct of_pci_range {
> > > > #define for_each_of_pci_range(parser, range) \
> > > > for (; of_pci_range_parser_one(parser, range);)
> > > >
> > > > +
> > > > +#ifndef indirect_io_enabled
> > > > +#define indirect_io_enabled indirect_io_enabled
> > > > +static inline bool indirect_io_enabled(void)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +#endif
> > > > +
> > > > +#ifndef addr_is_indirect_io
> > > > +#define addr_is_indirect_io addr_is_indirect_io
> > > > +static inline int addr_is_indirect_io(u64 taddr)
> > > > +{
> > > > + return 0;
> > > > +}
> > > > +#endif
> > > > +
> > > > /* Translate a DMA address from device space to CPU space */
> > > > extern u64 of_translate_dma_address(struct device_node *dev,
> > > > const __be32 *in_addr);
> > > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > > index 0e49f70..7f6bbb6 100644
> > > > --- a/include/linux/pci.h
> > > > +++ b/include/linux/pci.h
> > > > @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct
> > > pci_bus *bus)
> > > > /* provide the legacy pci_dma_* API */
> > > > #include <linux/pci-dma-compat.h>
> > > >
> > > > +/*
> > > > + * define this macro here to refrain from compilation error for
> some
> > > > + * platforms. Please keep this macro at the end of this header
> file.
> > > > + */
> > > > +#ifndef PCIBIOS_MIN_IO
> > > > +#define PCIBIOS_MIN_IO 0
> > > > +#endif
> > > > +
> > > > #endif /* LINUX_PCI_H */
> > > > --
> > > > 1.9.1
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-
> pci"
> > > in
> > > > the body of a message to majordomo at vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-
> info.html
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ?\_(?)_/?
^ permalink raw reply
* [PATCH] iommu/dma-iommu: properly respect configured address space size
From: Joerg Roedel @ 2016-11-10 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68e7a18b-739e-b73e-eacf-3cb6c1bd279a@arm.com>
On Tue, Nov 08, 2016 at 11:37:23AM +0000, Robin Murphy wrote:
> TBH I've been pondering ripping the size stuff out of dma-iommu, as it
> all stems from me originally failing to understand what dma_32bit_pfn is
> actually for.
The point of dma_32bit_pfn is to allocate dma-address below 4G by
default. This is a performance optimization so that even devices capable
of 64bit DMA are using SAC by default instead of DAC.
Since it is the goal to share a dma-iommu implemenation between
architectures, I would rather prefer not to rip this stuff out.
Joerg
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Auger Eric @ 2016-11-10 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110154606.GH2078@8bytes.org>
Hi Joerg,
On 10/11/2016 16:46, Joerg Roedel wrote:
> On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
>> The function populates the list of reserved regions with the
>> PCI host bridge windows and the MSI IOVA range.
>>
>> At the moment an arbitray MSI IOVA window is set at 0x8000000
>> of size 1MB.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> RFC v1 -> v2: use defines for MSI IOVA base and length
>> ---
>> drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 66 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index c841eb7..c07ea41 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>>
>> #define FSYNR0_WNR (1 << 4)
>>
>> +#define MSI_IOVA_BASE 0x8000000
>> +#define MSI_IOVA_LENGTH 0x100000
>> +
>> static int force_stage;
>> module_param(force_stage, int, S_IRUGO);
>> MODULE_PARM_DESC(force_stage,
>> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>> return iommu_fwspec_add_ids(dev, &fwid, 1);
>> }
>>
>> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
>> + struct pci_dev *dev)
>> +{
>> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
>> + struct iommu_reserved_region *region;
>> + struct resource_entry *window;
>> + phys_addr_t start;
>> + size_t length;
>> +
>> + resource_list_for_each_entry(window, &bridge->windows) {
>> + if (resource_type(window->res) != IORESOURCE_MEM &&
>> + resource_type(window->res) != IORESOURCE_IO)
>> + continue;
>
> Why do you care about IO resources?
Effectively that's a draft implementation inspired from "iommu/dma:
Avoid PCI host bridge windows". Also not all PCI host bridge windows
induce issues; my understanding is only those not supporting ACS are a
problem.
>
>> +
>> + start = window->res->start - window->offset;
>> + length = window->res->end - window->res->start + 1;
>> +
>> + iommu_reserved_region_for_each(region, domain) {
>> + if (region->start == start && region->length == length)
>> + continue;
>> + }
>> + region = kzalloc(sizeof(*region), GFP_KERNEL);
>> + if (!region)
>> + return -ENOMEM;
>> +
>> + region->start = start;
>> + region->length = length;
>> +
>> + list_add_tail(®ion->list, &domain->reserved_regions);
>> + }
>> + return 0;
>> +}
>> +
>> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
>> + struct device *device)
>> +{
>> + struct iommu_reserved_region *region;
>> + int ret = 0;
>> +
>> + /* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
>> + if (!domain->iova_cookie) {
>> +
>> + region = kzalloc(sizeof(*region), GFP_KERNEL);
>> + if (!region)
>> + return -ENOMEM;
>> +
>> + region->start = MSI_IOVA_BASE;
>> + region->length = MSI_IOVA_LENGTH;
>> + list_add_tail(®ion->list, &domain->reserved_regions);
>> +
>> + ret = iommu_get_dma_msi_region_cookie(domain,
>> + region->start, region->length);
>> + if (ret)
>> + return ret;
>
> Gah, I hate this. Is there no other and simpler way to get the MSI
> region than allocating an iova-domain? In that regard, I also _hate_ the
> patch before introducing this weird iommu_get_dma_msi_region_cookie()
> function.
>
> Allocation an iova-domain is pretty expensive, as it also includes
> per-cpu data-structures and all, so please don't do this just for the
> purpose of compiling a list of reserved regions.
It does not only serve the purpose to register the MSI IOVA region. We
also need to allocate an iova_domain where MSI IOVAs will be allocated
upon the request of the relevant MSI controllers. Do you mean you don't
like to use the iova allocator for this purpose?
Thanks
Eric
>
>
>
> Joerg
>
^ permalink raw reply
* [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
From: Joerg Roedel @ 2016-11-10 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-9-git-send-email-eric.auger@redhat.com>
On Fri, Nov 04, 2016 at 11:24:06AM +0000, Eric Auger wrote:
> The function populates the list of reserved regions with the
> PCI host bridge windows and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x8000000
> of size 1MB.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> RFC v1 -> v2: use defines for MSI IOVA base and length
> ---
> drivers/iommu/arm-smmu.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..c07ea41 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -278,6 +278,9 @@ enum arm_smmu_s2cr_privcfg {
>
> #define FSYNR0_WNR (1 << 4)
>
> +#define MSI_IOVA_BASE 0x8000000
> +#define MSI_IOVA_LENGTH 0x100000
> +
> static int force_stage;
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> @@ -1533,6 +1536,68 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> return iommu_fwspec_add_ids(dev, &fwid, 1);
> }
>
> +static int add_pci_window_reserved_regions(struct iommu_domain *domain,
> + struct pci_dev *dev)
> +{
> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> + struct iommu_reserved_region *region;
> + struct resource_entry *window;
> + phys_addr_t start;
> + size_t length;
> +
> + resource_list_for_each_entry(window, &bridge->windows) {
> + if (resource_type(window->res) != IORESOURCE_MEM &&
> + resource_type(window->res) != IORESOURCE_IO)
> + continue;
Why do you care about IO resources?
> +
> + start = window->res->start - window->offset;
> + length = window->res->end - window->res->start + 1;
> +
> + iommu_reserved_region_for_each(region, domain) {
> + if (region->start == start && region->length == length)
> + continue;
> + }
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = start;
> + region->length = length;
> +
> + list_add_tail(®ion->list, &domain->reserved_regions);
> + }
> + return 0;
> +}
> +
> +static int arm_smmu_add_reserved_regions(struct iommu_domain *domain,
> + struct device *device)
> +{
> + struct iommu_reserved_region *region;
> + int ret = 0;
> +
> + /* An arbitrary 1MB region starting at 0x8000000 is reserved for MSIs */
> + if (!domain->iova_cookie) {
> +
> + region = kzalloc(sizeof(*region), GFP_KERNEL);
> + if (!region)
> + return -ENOMEM;
> +
> + region->start = MSI_IOVA_BASE;
> + region->length = MSI_IOVA_LENGTH;
> + list_add_tail(®ion->list, &domain->reserved_regions);
> +
> + ret = iommu_get_dma_msi_region_cookie(domain,
> + region->start, region->length);
> + if (ret)
> + return ret;
Gah, I hate this. Is there no other and simpler way to get the MSI
region than allocating an iova-domain? In that regard, I also _hate_ the
patch before introducing this weird iommu_get_dma_msi_region_cookie()
function.
Allocation an iova-domain is pretty expensive, as it also includes
per-cpu data-structures and all, so please don't do this just for the
purpose of compiling a list of reserved regions.
Joerg
^ permalink raw reply
* [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain
From: Auger Eric @ 2016-11-10 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110153724.GG2078@8bytes.org>
Hi Joerg, Robin,
On 10/11/2016 16:37, Joerg Roedel wrote:
> On Fri, Nov 04, 2016 at 11:24:02AM +0000, Eric Auger wrote:
>> Introduce a new iommu_reserved_region struct. This embodies
>> an IOVA reserved region that cannot be used along with the IOMMU
>> API. The list is protected by a dedicated mutex.
>>
>> An iommu domain now owns a list of those.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> ---
>> drivers/iommu/iommu.c | 2 ++
>> include/linux/iommu.h | 17 +++++++++++++++++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 9a2f196..0af07492 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1061,6 +1061,8 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>>
>> domain->ops = bus->iommu_ops;
>> domain->type = type;
>> + INIT_LIST_HEAD(&domain->reserved_regions);
>> + mutex_init(&domain->resv_mutex);
>
> These regions are a property of the iommu-group, they are specific to a
> device or a group of devices, not to a particular domain where devics
> (iommu-groups) can come and go.
>
> Further I agree with Robin that this is similar to the
> get_dm_regions/set_dm_regions approach, which should be changed/extended
> for this instead of adding something new.
OK I am currently respinning, taking this into account. I will put the
reserved region file attribute in the iommu-group sysfs dir.
Thanks
Eric
>
>
> Joerg
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range
From: Auger Eric @ 2016-11-10 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110152241.GF2078@8bytes.org>
Hi Joerg,
On 10/11/2016 16:22, Joerg Roedel wrote:
> On Fri, Nov 04, 2016 at 11:24:00AM +0000, Eric Auger wrote:
>> Fix the size check within start_pfn and limit_pfn.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> the issue was observed when playing with 1 page iova domain with
>> higher iova reserved.
>> ---
>> drivers/iommu/iova.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index e23001b..ee29dbf 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -147,7 +147,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
>> if (!curr) {
>> if (size_aligned)
>> pad_size = iova_get_pad_size(size, limit_pfn);
>> - if ((iovad->start_pfn + size + pad_size) > limit_pfn) {
>> + if ((iovad->start_pfn + size + pad_size - 1) > limit_pfn) {
>
> A >= check is more readable here.
Sure
Thanks
Eric
>
>
> Joerg
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain
From: Joerg Roedel @ 2016-11-10 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-5-git-send-email-eric.auger@redhat.com>
On Fri, Nov 04, 2016 at 11:24:02AM +0000, Eric Auger wrote:
> Introduce a new iommu_reserved_region struct. This embodies
> an IOVA reserved region that cannot be used along with the IOMMU
> API. The list is protected by a dedicated mutex.
>
> An iommu domain now owns a list of those.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
> ---
> drivers/iommu/iommu.c | 2 ++
> include/linux/iommu.h | 17 +++++++++++++++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9a2f196..0af07492 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1061,6 +1061,8 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>
> domain->ops = bus->iommu_ops;
> domain->type = type;
> + INIT_LIST_HEAD(&domain->reserved_regions);
> + mutex_init(&domain->resv_mutex);
These regions are a property of the iommu-group, they are specific to a
device or a group of devices, not to a particular domain where devics
(iommu-groups) can come and go.
Further I agree with Robin that this is similar to the
get_dm_regions/set_dm_regions approach, which should be changed/extended
for this instead of adding something new.
Joerg
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-10 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <17821285.aIcTyCGn5n@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 10 November 2016 09:12
> To: linux-arm-kernel at lists.infradead.org
> Cc: Yuanzhichang; mark.rutland at arm.com; devicetree at vger.kernel.org;
> lorenzo.pieralisi at arm.com; Gabriele Paoloni; minyard at acm.org; linux-
> pci at vger.kernel.org; benh at kernel.crashing.org; John Garry;
> will.deacon at arm.com; linux-kernel at vger.kernel.org; xuwei (O); Linuxarm;
> zourongrong at gmail.com; robh+dt at kernel.org; kantyzc at 163.com; linux-
> serial at vger.kernel.org; catalin.marinas at arm.com; olof at lixom.net;
> liviu.dudau at arm.com; bhelgaas at google.com; zhichang.yuan02 at gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
> > On 2016/11/10 5:34, Arnd Bergmann wrote:
> > > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni
> wrote:
> > >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > >>>> + /*
> > >>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
> > >>> indirectIO.
> > >>>> + * It will separate indirectIO range from pci host
> bridge to
> > >>>> + * avoid the possible PIO conflict.
> > >>>> + * Set the indirectIO range directly here.
> > >>>> + */
> > >>>> + lpcdev->io_ops.start = 0;
> > >>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > >>>> + lpcdev->io_ops.devpara = lpcdev;
> > >>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > >>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > >>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > >>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >>>
> > >>> I have to look at patch 2 in more detail again, after missing a
> few
> > >>> review
> > >>> rounds. I'm still a bit skeptical about hardcoding a logical I/O
> port
> > >>> range here, and would hope that we can just go through the same
> > >>> assignment of logical port ranges that we have for PCI buses,
> > >>> decoupling
> > >>> the bus addresses from the linux-internal ones.
> > >>
> > >> The point here is that we want to avoid any conflict/overlap
> between
> > >> the LPC I/O space and the PCI I/O space. With the assignment above
> > >> we make sure that LPC never interfere with PCI I/O space.
> > >
> > > But we already abstract the PCI I/O space using dynamic
> registration.
> > > There is no need to hardcode the logical address for ISA, though
> > > I think we can hardcode the bus address to start at zero here.
> >
> > Do you means that we can pick up the maximal I/O address from all
> children's
> > device resources??
>
> The driver should not look at the resources of its children, just
> register a range of addresses dynamically, as I suggested in an
> earlier review.
Where should we get the range from? For LPC we know that it is going
Work on anything that is not used by PCI I/O space, and this is
why we use [0, PCIBIOS_MIN_IO]
>
>
> Your current version has
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr, value, sizeof(type)); \
>
> Instead, just subtract the start of the range from the logical
> port number to transform it back into a bus-local port number:
These accessors do not operate on IO tokens:
If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
addr is not going to be an I/O token; in fact patch 2/3 imposes that
the I/O tokens will start@PCIBIOS_MIN_IO. So from 0 to PCIBIOS_MIN_IO
we have free physical addresses that the accessors can operate on.
Thanks
Gab
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr - arm64_extio_ops->start, value,
> sizeof(type)); \
>
> We know that the ISA/LPC bus can only have up to 65536 ports,
> so you can register all of those, or possibly limit it further to
> 1024 or 4096 ports, whichever matches the bus implementation.
>
> Arnd
^ permalink raw reply
* [PATCH] spi: atmel: Fix scheduling while atomic
From: ben.whitten at gmail.com @ 2016-11-10 15:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Ben Whitten <ben.whitten@lairdtech.com>
A call to clk_get_rate appears to be called in the context of an interrupt,
cache the bus clock for the frequency calculations in transmission.
This fixes a 'BUG: scheduling while atomic' and
'WARNING: CPU: 0 PID: 777 at kernel/sched/core.c:2960 atmel_spi_unlock'
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
Signed-off-by: Steve deRosier <steve.derosier@lairdtech.com>
---
drivers/spi/spi-atmel.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 8feac59..c281d1a 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -295,6 +295,7 @@ struct atmel_spi {
int irq;
struct clk *clk;
struct platform_device *pdev;
+ unsigned long spi_clk;
struct spi_transfer *current_transfer;
int current_remaining_bytes;
@@ -864,7 +865,7 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
unsigned long bus_hz;
/* v1 chips start out at half the peripheral bus speed. */
- bus_hz = clk_get_rate(as->clk);
+ bus_hz = as->spi_clk;
if (!atmel_spi_is_v2(as))
bus_hz /= 2;
@@ -1606,6 +1607,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
ret = clk_prepare_enable(clk);
if (ret)
goto out_free_irq;
+
+ as->spi_clk = clk_get_rate(clk);
+
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
if (as->caps.has_wdrbt) {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Marc Zyngier @ 2016-11-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9ef10b9-44f2-b02e-9d90-02cf348aa49c@redhat.com>
On 10/11/16 15:12, Wei Huang wrote:
>
>
> On 11/10/2016 03:10 AM, Marc Zyngier wrote:
>> Hi Wei,
>>
>> On 09/11/16 19:57, Wei Huang wrote:
>>> This patch moves ARMv8-related perf event definitions from perf_event.c
>>> to asm/perf_event.h; so KVM code can use them directly. This also help
>>> remove a duplicated definition of SW_INCR in perf_event.h.
>>>
>>> Signed-off-by: Wei Huang <wei@redhat.com>
>>> ---
>>> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
>>> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
>>> 2 files changed, 160 insertions(+), 162 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
>>> index 2065f46..6c7b18b 100644
>>> --- a/arch/arm64/include/asm/perf_event.h
>>> +++ b/arch/arm64/include/asm/perf_event.h
>>> @@ -46,7 +46,166 @@
>>> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
>>> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>>>
>>> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
>>> +/*
>>> + * ARMv8 PMUv3 Performance Events handling code.
>>> + * Common event types.
>>> + */
>>> +
>>> +/* Required events. */
>>> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
>>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
>>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
>>> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
>>> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
>>> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
>>
>> In my initial review, I asked for the "required" events to be moved to a
>> shared location. What's the rational for moving absolutely everything?
>
> I did notice the phrase "required" in the original email. However I
> think it is weird to have two places for a same set of PMU definitions.
> Other developers might think these two are missing if they don't search
> kernel files carefully.
>
> If Will Deacon and you insist, I can move only two defs to perf_event.h,
> consolidated with the 2nd patch into a single one.
My personal feeling is that only architected events should be in a
public header. The CPU-specific ones are probably better kept private,
as it is doubtful that other users would appear).
I'll leave it up to Will to decide, as all I want to avoid is the
duplication of constants between the PMU and KVM code bases.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Mark Rutland @ 2016-11-10 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9ef10b9-44f2-b02e-9d90-02cf348aa49c@redhat.com>
On Thu, Nov 10, 2016 at 09:12:35AM -0600, Wei Huang wrote:
> On 11/10/2016 03:10 AM, Marc Zyngier wrote:
> > On 09/11/16 19:57, Wei Huang wrote:
> >> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> >> +/*
> >> + * ARMv8 PMUv3 Performance Events handling code.
> >> + * Common event types.
> >> + */
> >> +
> >> +/* Required events. */
> >> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> >> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> >> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> >> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> >> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> >> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
> >
> > In my initial review, I asked for the "required" events to be moved to a
> > shared location. What's the rational for moving absolutely everything?
>
> I did notice the phrase "required" in the original email. However I
> think it is weird to have two places for a same set of PMU definitions.
> Other developers might think these two are missing if they don't search
> kernel files carefully.
>
> If Will Deacon and you insist, I can move only two defs to perf_event.h,
> consolidated with the 2nd patch into a single one.
FWIW, my personal preference would be for all the definitions (or at
least all of the ARMV8_PMUV3_* ones) to be in one place.
That said, I don't feel particularly strongly either way, and I'll defer
to Will.
Thanks,
Mark.
^ permalink raw reply
* [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range
From: Joerg Roedel @ 2016-11-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-3-git-send-email-eric.auger@redhat.com>
On Fri, Nov 04, 2016 at 11:24:00AM +0000, Eric Auger wrote:
> Fix the size check within start_pfn and limit_pfn.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> the issue was observed when playing with 1 page iova domain with
> higher iova reserved.
> ---
> drivers/iommu/iova.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index e23001b..ee29dbf 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -147,7 +147,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> if (!curr) {
> if (size_aligned)
> pad_size = iova_get_pad_size(size, limit_pfn);
> - if ((iovad->start_pfn + size + pad_size) > limit_pfn) {
> + if ((iovad->start_pfn + size + pad_size - 1) > limit_pfn) {
A >= check is more readable here.
Joerg
^ permalink raw reply
* [PATCH fpga 9/9] fpga: Remove support for non-sg drivers
From: Joshua Clayton @ 2016-11-10 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478732303-13718-10-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
On 11/09/2016 02:58 PM, Jason Gunthorpe wrote:
> All drivers now use the sg interface so there is no reason to keep
> the contiguous interface any more.
>
> Now that all drivers support this interface we can also export it.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/fpga-mgr.c | 62 +++++++------------------------------------
> include/linux/fpga/fpga-mgr.h | 7 ++---
> 2 files changed, 11 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index c2491ffeabd3..4ba22925d9d5 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -47,8 +47,8 @@ static struct class *fpga_mgr_class;
> *
> * Return: 0 on success, negative error code otherwise.
> */
> -static int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> - struct sg_table *sgt)
> +int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> + struct sg_table *sgt)
> {
> struct device *dev = &mgr->dev;
> int ret;
> @@ -92,52 +92,7 @@ static int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
>
> return 0;
> }
> -
> -static int fpga_mgr_buf_load_mapped(struct fpga_manager *mgr, u32 flags,
> - const char *buf, size_t count)
> -{
> - struct device *dev = &mgr->dev;
> - int ret;
> -
> - /*
> - * Call the low level driver's write_init function. This will do the
> - * device-specific things to get the FPGA into the state where it is
> - * ready to receive an FPGA image.
> - */
> - mgr->state = FPGA_MGR_STATE_WRITE_INIT;
> - ret = mgr->mops->write_init(mgr, flags, buf, count);
> - if (ret) {
> - dev_err(dev, "Error preparing FPGA for writing\n");
> - mgr->state = FPGA_MGR_STATE_WRITE_INIT_ERR;
> - return ret;
> - }
> -
> - /*
> - * Write the FPGA image to the FPGA.
> - */
> - mgr->state = FPGA_MGR_STATE_WRITE;
> - ret = mgr->mops->write(mgr, buf, count);
> - if (ret) {
> - dev_err(dev, "Error while writing image data to FPGA\n");
> - mgr->state = FPGA_MGR_STATE_WRITE_ERR;
> - return ret;
> - }
> -
> - /*
> - * After all the FPGA image has been written, do the device specific
> - * steps to finish and set the FPGA into operating mode.
> - */
> - mgr->state = FPGA_MGR_STATE_WRITE_COMPLETE;
> - ret = mgr->mops->write_complete(mgr, flags);
> - if (ret) {
> - dev_err(dev, "Error after writing image data to FPGA\n");
> - mgr->state = FPGA_MGR_STATE_WRITE_COMPLETE_ERR;
> - return ret;
> - }
> - mgr->state = FPGA_MGR_STATE_OPERATING;
> -
> - return 0;
> -}
> +EXPORT_SYMBOL_GPL(fpga_mgr_buf_load_sg);
>
> /**
> * fpga_mgr_buf_load - load fpga from image in buffer
> @@ -163,9 +118,6 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> int index;
> int rc;
>
> - if (!mgr->mops->write_init_sg || !mgr->mops->write_sg)
> - return fpga_mgr_buf_load_mapped(mgr, flags, buf, count);
> -
> /*
> * Convert the linear kernel pointer into a sg_table of pages for use
> * by the driver.
> @@ -226,6 +178,11 @@ int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
>
> mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ;
>
> + /*
> + * FIXME: We do not need a vmap, just a page list, but
> + * request_firmware has no way to give us that, so this needlessly
> + * consumes vmalloc space.
> + */
> ret = request_firmware(&fw, image_name, dev);
> if (ret) {
> mgr->state = FPGA_MGR_STATE_FIRMWARE_REQ_ERR;
> @@ -369,8 +326,7 @@ int fpga_mgr_register(struct device *dev, const char *name,
> int id, ret;
>
> if (!mops || !mops->write_complete || !mops->state ||
> - ((!mops->write_init || !mops->write) &&
> - (!mops->write_init_sg || !mops->write_sg))) {
> + !mops->write_init_sg || !mops->write_sg) {
> dev_err(dev, "Attempt to register without fpga_manager_ops\n");
> return -EINVAL;
> }
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index 371b30ea60eb..5c698c8fe71b 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -72,8 +72,6 @@ enum fpga_mgr_states {
> /**
> * struct fpga_manager_ops - ops for low level fpga manager drivers
> * @state: returns an enum value of the FPGA's state
> - * @write_init: prepare the FPGA to receive confuration data (linear memory)
> - * @write: write count bytes of configuration data to the FPGA
> * @write_init_sg: prepare the FPGA to receive confuration data (scatter list
> * table)
> * @write_sg: write count bytes of configuration data to the FPGA
> @@ -86,9 +84,6 @@ enum fpga_mgr_states {
> */
> struct fpga_manager_ops {
> enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
> - int (*write_init)(struct fpga_manager *mgr, u32 flags,
> - const char *buf, size_t count);
> - int (*write)(struct fpga_manager *mgr, const char *buf, size_t count);
> int (*write_init_sg)(struct fpga_manager *mgr, u32 flags,
> struct sg_table *sgt);
> int (*write_sg)(struct fpga_manager *mgr, struct sg_table *sgt);
> @@ -118,6 +113,8 @@ struct fpga_manager {
>
> int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags,
> const char *buf, size_t count);
> +int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
> + struct sg_table *sgt);
>
> int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
> const char *image_name);
I don't have any feeling either way about switching to scatter-gather.
(Not zynq or socfpga user)
But I do object to renaming the API.
write_init() and write() do not imply a particular implementation, nor even that
the buffer is coherent.
I am working to merge an fpga manager which uses SPI to load the bitstream
(see https://www.spinics.net/lists/arm-kernel/msg539328.html)
Any dma in use there would come from the spi driver. write_init_sg, and write_sg
don't make any sense in my case.
Would it not make sense to keep the top level API the same?
Thanks, Joshua.
^ permalink raw reply
* [PATCH -next] cpufreq: brcmstb-avs-cpufreq: make symbol brcm_avs_cpufreq_attr static
From: Wei Yongjun @ 2016-11-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/cpufreq/brcmstb-avs-cpufreq.c:982:18: warning:
symbol 'brcm_avs_cpufreq_attr' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/cpufreq/brcmstb-avs-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index b761d54..4fda623 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -979,7 +979,7 @@ cpufreq_freq_attr_ro(brcm_avs_pmap);
cpufreq_freq_attr_ro(brcm_avs_voltage);
cpufreq_freq_attr_ro(brcm_avs_frequency);
-struct freq_attr *brcm_avs_cpufreq_attr[] = {
+static struct freq_attr *brcm_avs_cpufreq_attr[] = {
&cpufreq_freq_attr_scaling_available_freqs,
&brcm_avs_pstate,
&brcm_avs_mode,
^ permalink raw reply related
* Summary of LPC guest MSI discussion in Santa Fe
From: Joerg Roedel @ 2016-11-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e59e9a17-e943-a227-5ea4-d028232155a8@arm.com>
On Wed, Nov 09, 2016 at 08:11:16PM +0000, Robin Murphy wrote:
> When we *are* in full control of the IOVA space, we just carve out what
> we can find as best we can - see iova_reserve_pci_windows() in
> dma-iommu.c, which isn't really all that different to what x86 does
> (e.g. init_reserved_iova_ranges() in amd-iommu.c).
Yeah, that code was actually written with a look at what the Intel
driver does. I don't really like that it goes over all resources and
reserves them individually (not only because it is not hotplug-safe).
I have to check whether there is a nice and generic way to find out the
root-bridge windows and just reserve them in the iova-space. That would
be easier and more reliable.
Joerg
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Charles Keepax @ 2016-11-10 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b654d5f7-7b67-7216-760f-d29e49a29296@samsung.com>
On Thu, Nov 10, 2016 at 04:10:56PM +0100, Sylwester Nawrocki wrote:
> On 11/10/2016 12:03 PM, Charles Keepax wrote:
> >> On Tue, Nov 08, 2016 at 04:53:40PM +0100, Sylwester Nawrocki wrote:
> [...]
> >> I pushed now to branch for-v4.10/dma/pl080-s3c64xx-v2 with this
> >> issue fixed and added initialization of the filer function.
> >
> > Apologies for the delay got somewhat swamped with internal stuff
> > yesterday. Yeah using that branch it looks good to me, the SPI and
> > I2S are both working fine. I can download code to the wm0010
> > which should be a good work out of the SPI and play audio
> > correctly so the I2S should be fine. So for the series:
> >
> > Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>
> Great, thanks a lot! I'm going to post the next iteration with
> modified pl080 DMAC patches, addressing comments from Arnd.
> I would be grateful if you could confirm it also works on your
> platform.
>
Yeah, no problem, I should be able to find time to test those as
well.
Thanks,
Charles
^ permalink raw reply
* [PATCH 8/8] ARM: s3c24xx: Drop unused struct s3c_audio_pdata entries
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
The s3c24xx-iis driver is now converted to use the dma_slave_map API
and the samsung-ac97 driver got removed from the tree so remove
the unused platform data structure instances.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/plat-samsung/devs.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index cf7b95f..03fac12 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -77,15 +77,6 @@
[1] = DEFINE_RES_IRQ(IRQ_S3C244X_AC97),
};
-static struct s3c_audio_pdata s3c_ac97_pdata = {
-#ifdef CONFIG_S3C24XX_DMAC
- .dma_filter = s3c24xx_dma_filter,
-#endif
- .dma_playback = (void *)DMACH_PCM_OUT,
- .dma_capture = (void *)DMACH_PCM_IN,
- .dma_capture_mic = (void *)DMACH_MIC_IN,
-};
-
struct platform_device s3c_device_ac97 = {
.name = "samsung-ac97",
.id = -1,
@@ -94,7 +85,6 @@ struct platform_device s3c_device_ac97 = {
.dev = {
.dma_mask = &samsung_device_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &s3c_ac97_pdata,
}
};
#endif /* CONFIG_CPU_S3C2440 */
@@ -574,14 +564,6 @@ void __init s3c_i2c7_set_platdata(struct s3c2410_platform_i2c *pd)
[0] = DEFINE_RES_MEM(S3C24XX_PA_IIS, S3C24XX_SZ_IIS),
};
-static struct s3c_audio_pdata s3c_iis_platdata = {
-#ifdef CONFIG_S3C24XX_DMAC
- .dma_filter = s3c24xx_dma_filter,
-#endif
- .dma_playback = (void *)DMACH_I2S_OUT,
- .dma_capture = (void *)DMACH_I2S_IN,
-};
-
struct platform_device s3c_device_iis = {
.name = "s3c24xx-iis",
.id = -1,
@@ -590,7 +572,6 @@ struct platform_device s3c_device_iis = {
.dev = {
.dma_mask = &samsung_device_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = &s3c_iis_platdata,
}
};
#endif /* CONFIG_PLAT_S3C24XX */
--
1.9.1
^ permalink raw reply related
* [PATCH 7/8] ARM: s3c64xx: Drop initialization of unused struct s3c_audio_pdata fields
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
Remove initialization of dma_{filter, playback, capture, capture_mic}
fields where it is not used any more.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/dev-audio.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b577833..a3f39dd 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -58,9 +58,6 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata i2s0_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S0_OUT,
- .dma_capture = DMACH_I2S0_IN,
};
struct platform_device s3c64xx_device_iis0 = {
@@ -80,9 +77,6 @@ struct platform_device s3c64xx_device_iis0 = {
static struct s3c_audio_pdata i2s1_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_I2S1_OUT,
- .dma_capture = DMACH_I2S1_IN,
};
struct platform_device s3c64xx_device_iis1 = {
@@ -102,9 +96,6 @@ struct platform_device s3c64xx_device_iis1 = {
static struct s3c_audio_pdata i2sv4_pdata = {
.cfg_gpio = s3c64xx_i2s_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_HSI_I2SV40_TX,
- .dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
.i2s = {
.quirks = QUIRK_PRI_6CHAN,
@@ -153,9 +144,6 @@ static int s3c64xx_pcm_cfg_gpio(struct platform_device *pdev)
static struct s3c_audio_pdata s3c_pcm0_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_PCM0_RX,
- .dma_playback = DMACH_PCM0_TX,
};
struct platform_device s3c64xx_device_pcm0 = {
@@ -175,9 +163,6 @@ struct platform_device s3c64xx_device_pcm0 = {
static struct s3c_audio_pdata s3c_pcm1_pdata = {
.cfg_gpio = s3c64xx_pcm_cfg_gpio,
- .dma_filter = pl08x_filter_id,
- .dma_playback = DMACH_PCM1_TX,
- .dma_capture = DMACH_PCM1_RX,
};
struct platform_device s3c64xx_device_pcm1 = {
@@ -209,10 +194,6 @@ static int s3c64xx_ac97_cfg_gpe(struct platform_device *pdev)
};
static struct s3c_audio_pdata s3c_ac97_pdata = {
- .dma_playback = DMACH_AC97_PCMOUT,
- .dma_filter = pl08x_filter_id,
- .dma_capture = DMACH_AC97_PCMIN,
- .dma_capture_mic = DMACH_AC97_MICIN,
};
static u64 s3c64xx_ac97_dmamask = DMA_BIT_MASK(32);
--
1.9.1
^ permalink raw reply related
* [PATCH 6/8] ASoC: samsung: pcm: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/pcm.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c
index 43e367a..ccedab2 100644
--- a/sound/soc/samsung/pcm.c
+++ b/sound/soc/samsung/pcm.c
@@ -134,18 +134,22 @@ struct s3c_pcm_info {
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_out[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "tx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "tx",
},
};
static struct snd_dmaengine_dai_dma_data s3c_pcm_stereo_in[] = {
[0] = {
.addr_width = 4,
+ .chan_name = "rx",
},
[1] = {
.addr_width = 4,
+ .chan_name = "rx",
},
};
@@ -488,7 +492,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
struct s3c_pcm_info *pcm;
struct resource *mem_res;
struct s3c_audio_pdata *pcm_pdata;
- dma_filter_fn filter;
int ret;
/* Check for valid device index */
@@ -555,13 +558,6 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
s3c_pcm_stereo_in[pdev->id].addr = mem_res->start + S3C_PCM_RXFIFO;
s3c_pcm_stereo_out[pdev->id].addr = mem_res->start + S3C_PCM_TXFIFO;
- filter = NULL;
- if (pcm_pdata) {
- s3c_pcm_stereo_in[pdev->id].filter_data = pcm_pdata->dma_capture;
- s3c_pcm_stereo_out[pdev->id].filter_data = pcm_pdata->dma_playback;
- filter = pcm_pdata->dma_filter;
- }
-
pcm->dma_capture = &s3c_pcm_stereo_in[pdev->id];
pcm->dma_playback = &s3c_pcm_stereo_out[pdev->id];
@@ -574,7 +570,7 @@ static int s3c_pcm_dev_probe(struct platform_device *pdev)
goto err5;
}
- ret = samsung_asoc_dma_platform_register(&pdev->dev, filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret) {
dev_err(&pdev->dev, "failed to get register DMA: %d\n", ret);
--
1.9.1
^ permalink raw reply related
* [PATCH 5/8] ASoC: samsung: i2s: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to slave devices so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/i2s.c | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 7e32cf4..95a9a3f 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -90,7 +90,6 @@ struct i2s_dai {
struct snd_dmaengine_dai_dma_data dma_playback;
struct snd_dmaengine_dai_dma_data dma_capture;
struct snd_dmaengine_dai_dma_data idma_playback;
- dma_filter_fn filter;
u32 quirks;
u32 suspend_i2smod;
u32 suspend_i2scon;
@@ -1244,7 +1243,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return ret;
return samsung_asoc_dma_platform_register(&pdev->dev,
- sec_dai->filter, "tx-sec", NULL);
+ NULL, "tx-sec", NULL);
}
pri_dai = i2s_alloc_dai(pdev, false);
@@ -1262,10 +1261,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return -EINVAL;
}
- pri_dai->dma_playback.filter_data = i2s_pdata->dma_playback;
- pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
- pri_dai->filter = i2s_pdata->dma_filter;
-
if (&i2s_pdata->type)
i2s_cfg = &i2s_pdata->type.i2s;
@@ -1327,11 +1322,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai->dma_playback.addr = regs_base + I2STXDS;
sec_dai->dma_playback.chan_name = "tx-sec";
- if (!np) {
- sec_dai->dma_playback.filter_data = i2s_pdata->dma_play_sec;
- sec_dai->filter = i2s_pdata->dma_filter;
- }
-
sec_dai->dma_playback.addr_width = 4;
sec_dai->addr = pri_dai->addr;
sec_dai->clk = pri_dai->clk;
@@ -1353,7 +1343,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
if (ret < 0)
goto err_free_dai;
- ret = samsung_asoc_dma_platform_register(&pdev->dev, pri_dai->filter,
+ ret = samsung_asoc_dma_platform_register(&pdev->dev, NULL,
NULL, NULL);
if (ret < 0)
goto err_free_dai;
--
1.9.1
^ permalink raw reply related
* [PATCH 4/8] ARM: s3c64xx: Drop unused DMA fields from struct s3c64xx_spi_csinfo
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
There is no drivers using those fields so remove them and
the remaining initializations.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
arch/arm/plat-samsung/devs.c | 24 ------------------------
include/linux/platform_data/spi-s3c64xx.h | 3 ---
2 files changed, 27 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index e93aa67..cf7b95f 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1124,15 +1124,6 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI0_TX;
- pd.dma_rx = (void *)DMACH_SPI0_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#elif defined(CONFIG_S3C24XX_DMAC)
- pd.filter = s3c24xx_dma_filter;
-#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
}
@@ -1169,14 +1160,6 @@ void __init s3c64xx_spi1_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI1_TX;
- pd.dma_rx = (void *)DMACH_SPI1_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#endif
-
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
}
@@ -1213,13 +1196,6 @@ void __init s3c64xx_spi2_set_platdata(int (*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
- pd.dma_tx = (void *)DMACH_SPI2_TX;
- pd.dma_rx = (void *)DMACH_SPI2_RX;
-#if defined(CONFIG_PL330_DMA)
- pd.filter = pl330_filter;
-#elif defined(CONFIG_S3C64XX_PL080)
- pd.filter = pl08x_filter_id;
-#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
}
diff --git a/include/linux/platform_data/spi-s3c64xx.h b/include/linux/platform_data/spi-s3c64xx.h
index 5c1e21c..da79774 100644
--- a/include/linux/platform_data/spi-s3c64xx.h
+++ b/include/linux/platform_data/spi-s3c64xx.h
@@ -40,9 +40,6 @@ struct s3c64xx_spi_info {
int num_cs;
bool no_cs;
int (*cfg_gpio)(void);
- dma_filter_fn filter;
- void *dma_tx;
- void *dma_rx;
};
/**
--
1.9.1
^ permalink raw reply related
* [PATCH 3/8] spi: s3c64xx: Do not use platform_data for DMA parameters
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
All related platforms use either devicetree or the DMA slave
map API for mapping DMA channels to DMA slaves so we can now
stop using platform_data for passing DMA details.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Andi Shyti <andi.shyti@samsung.com>
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-s3c64xx.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 3c09e94..28dfdce 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -341,27 +341,20 @@ static void s3c64xx_spi_set_cs(struct spi_device *spi, bool enable)
static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
{
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
- dma_filter_fn filter = sdd->cntrlr_info->filter;
struct device *dev = &sdd->pdev->dev;
- dma_cap_mask_t mask;
if (is_polling(sdd))
return 0;
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
/* Acquire DMA channels */
- sdd->rx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_rx, dev, "rx");
+ sdd->rx_dma.ch = dma_request_slave_channel(dev, "rx");
if (!sdd->rx_dma.ch) {
dev_err(dev, "Failed to get RX DMA channel\n");
return -EBUSY;
}
spi->dma_rx = sdd->rx_dma.ch;
- sdd->tx_dma.ch = dma_request_slave_channel_compat(mask, filter,
- sdd->cntrlr_info->dma_tx, dev, "tx");
+ sdd->tx_dma.ch = dma_request_slave_channel(dev, "tx");
if (!sdd->tx_dma.ch) {
dev_err(dev, "Failed to get TX DMA channel\n");
dma_release_channel(sdd->rx_dma.ch);
@@ -1091,11 +1084,6 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
sdd->cur_bpw = 8;
- if (!sdd->pdev->dev.of_node && (!sci->dma_tx || !sci->dma_rx)) {
- dev_warn(&pdev->dev, "Unable to get SPI tx/rx DMA data. Switching to poll mode\n");
- sdd->port_conf->quirks = S3C64XX_SPI_QUIRK_POLL;
- }
-
sdd->tx_dma.direction = DMA_MEM_TO_DEV;
sdd->rx_dma.direction = DMA_DEV_TO_MEM;
@@ -1205,9 +1193,8 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d with %d Slaves attached\n",
sdd->port_id, master->num_chipselect);
- dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\tDMA=[Rx-%p, Tx-%p]\n",
- mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1,
- sci->dma_rx, sci->dma_tx);
+ dev_dbg(&pdev->dev, "\tIOmem=[%pR]\tFIFO %dbytes\n",
+ mem_res, (FIFO_LVL_MASK(sdd) >> 1) + 1);
pm_runtime_mark_last_busy(&pdev->dev);
pm_runtime_put_autosuspend(&pdev->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/8] ARM: s3c64xx: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
This patch adds DMA slave map tables to the pl080 devices's
platform_data in order to support the new channel request API.
A few devices for which there was no DMA support with current
code are omitted in the tables.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/mach-s3c64xx/pl080.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
index 89c5a62..261820a 100644
--- a/arch/arm/mach-s3c64xx/pl080.c
+++ b/arch/arm/mach-s3c64xx/pl080.c
@@ -117,6 +117,25 @@ static void pl08x_put_xfer_signal(const struct pl08x_channel_data *cd, int ch)
}
};
+static const struct dma_slave_map s3c64xx_dma0_slave_map[] = {
+ { "s3c6400-uart.0", "tx", &s3c64xx_dma0_info[0] },
+ { "s3c6400-uart.0", "rx", &s3c64xx_dma0_info[1] },
+ { "s3c6400-uart.1", "tx", &s3c64xx_dma0_info[2] },
+ { "s3c6400-uart.1", "rx", &s3c64xx_dma0_info[3] },
+ { "s3c6400-uart.2", "tx", &s3c64xx_dma0_info[4] },
+ { "s3c6400-uart.2", "rx", &s3c64xx_dma0_info[5] },
+ { "s3c6400-uart.3", "tx", &s3c64xx_dma0_info[6] },
+ { "s3c6400-uart.3", "rx", &s3c64xx_dma0_info[7] },
+ { "samsung-pcm.0", "tx", &s3c64xx_dma0_info[8] },
+ { "samsung-pcm.0", "rx", &s3c64xx_dma0_info[9] },
+ { "samsung-i2s.0", "tx", &s3c64xx_dma0_info[10] },
+ { "samsung-i2s.0", "rx", &s3c64xx_dma0_info[11] },
+ { "s3c6410-spi.0", "tx", &s3c64xx_dma0_info[12] },
+ { "s3c6410-spi.0", "rx", &s3c64xx_dma0_info[13] },
+ { "samsung-i2s.2", "tx", &s3c64xx_dma0_info[14] },
+ { "samsung-i2s.2", "rx", &s3c64xx_dma0_info[15] },
+};
+
struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma0_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
+ .slave_map = s3c64xx_dma0_slave_map,
+ .slave_map_len = ARRAY_SIZE(s3c64xx_dma0_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
@@ -207,6 +228,15 @@ static AMBA_AHB_DEVICE(s3c64xx_dma0, "dma-pl080s.0", 0,
},
};
+static const struct dma_slave_map s3c64xx_dma1_slave_map[] = {
+ { "samsung-pcm.1", "tx", &s3c64xx_dma1_info[0] },
+ { "samsung-pcm.1", "rx", &s3c64xx_dma1_info[1] },
+ { "samsung-i2s.1", "tx", &s3c64xx_dma1_info[2] },
+ { "samsung-i2s.1", "rx", &s3c64xx_dma1_info[3] },
+ { "s3c6410-spi.1", "tx", &s3c64xx_dma1_info[4] },
+ { "s3c6410-spi.1", "rx", &s3c64xx_dma1_info[5] },
+};
+
struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.memcpy_channel = {
.bus_id = "memcpy",
@@ -224,6 +254,8 @@ struct pl08x_platform_data s3c64xx_dma1_plat_data = {
.put_xfer_signal = pl08x_put_xfer_signal,
.slave_channels = s3c64xx_dma1_info,
.num_slave_channels = ARRAY_SIZE(s3c64xx_dma1_info),
+ .slave_map = s3c64xx_dma1_slave_map,
+ .slave_map_len = ARRAY_SIZE(s3c64xx_dma1_slave_map),
};
static AMBA_AHB_DEVICE(s3c64xx_dma1, "dma-pl080s.1", 0,
--
1.9.1
^ permalink raw reply related
* [PATCH 1/8] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
This patch adds support for the new channel request API introduced
in commit a8135d0d79e9d0ad3a4ff494fceeaae83
"dmaengine: core: Introduce new, universal API to request a channel".
param field of struct dma_slave_map type entries in the platform
data structure should be pointing to struct pl08x_channel_data
of related DMA channel.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/dma/amba-pl08x.c | 11 +++++++++++
include/linux/amba/pl08x.h | 4 ++++
2 files changed, 15 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..0b7c6ce 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1793,6 +1793,13 @@ bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
}
EXPORT_SYMBOL_GPL(pl08x_filter_id);
+static bool pl08x_filter_fn(struct dma_chan *chan, void *chan_id)
+{
+ struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
+
+ return plchan->cd == chan_id;
+}
+
/*
* Just check that the device is there and active
* TODO: turn this bit on/off depending on the number of physical channels
@@ -2307,6 +2314,10 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
+ pl08x->slave.filter.fn = pl08x_filter_fn;
}
/* By default, AHB1 only. If dualmaster, from platform */
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 27e9ec8..5308eae 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -84,6 +84,8 @@ struct pl08x_channel_data {
* running any DMA transfer and multiplexing can be recycled
* @lli_buses: buses which LLIs can be fetched from: PL08X_AHB1 | PL08X_AHB2
* @mem_buses: buses which memory can be accessed from: PL08X_AHB1 | PL08X_AHB2
+ * @slave_map: DMA slave matching table
+ * @slave_map_len: number of elements in @slave_map
*/
struct pl08x_platform_data {
struct pl08x_channel_data *slave_channels;
@@ -93,6 +95,8 @@ struct pl08x_platform_data {
void (*put_xfer_signal)(const struct pl08x_channel_data *, int);
u8 lli_buses;
u8 mem_buses;
+ const struct dma_slave_map *slave_map;
+ int slave_map_len;
};
#ifdef CONFIG_AMBA_PL08X
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox