* [PATCH v6 02/18] iommu: Rename iommu_dm_regions into iommu_resv_regions
From: Eric Auger @ 2017-01-05 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-1-git-send-email-eric.auger@redhat.com>
We want to extend the callbacks used for dm regions and
use them for reserved regions. Reserved regions can be
- directly mapped regions
- regions that cannot be iommu mapped (PCI host bridge windows, ...)
- MSI regions (because they belong to another address space or because
they are not translated by the IOMMU and need special handling)
So let's rename the struct and also the callbacks.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
---
v3 -> v4:
- add Robin's A-b
---
drivers/iommu/amd_iommu.c | 20 ++++++++++----------
drivers/iommu/iommu.c | 22 +++++++++++-----------
include/linux/iommu.h | 29 +++++++++++++++--------------
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 019e027..04334eb 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3161,8 +3161,8 @@ static bool amd_iommu_capable(enum iommu_cap cap)
return false;
}
-static void amd_iommu_get_dm_regions(struct device *dev,
- struct list_head *head)
+static void amd_iommu_get_resv_regions(struct device *dev,
+ struct list_head *head)
{
struct unity_map_entry *entry;
int devid;
@@ -3172,7 +3172,7 @@ static void amd_iommu_get_dm_regions(struct device *dev,
return;
list_for_each_entry(entry, &amd_iommu_unity_map, list) {
- struct iommu_dm_region *region;
+ struct iommu_resv_region *region;
if (devid < entry->devid_start || devid > entry->devid_end)
continue;
@@ -3195,18 +3195,18 @@ static void amd_iommu_get_dm_regions(struct device *dev,
}
}
-static void amd_iommu_put_dm_regions(struct device *dev,
+static void amd_iommu_put_resv_regions(struct device *dev,
struct list_head *head)
{
- struct iommu_dm_region *entry, *next;
+ struct iommu_resv_region *entry, *next;
list_for_each_entry_safe(entry, next, head, list)
kfree(entry);
}
-static void amd_iommu_apply_dm_region(struct device *dev,
+static void amd_iommu_apply_resv_region(struct device *dev,
struct iommu_domain *domain,
- struct iommu_dm_region *region)
+ struct iommu_resv_region *region)
{
struct dma_ops_domain *dma_dom = to_dma_ops_domain(to_pdomain(domain));
unsigned long start, end;
@@ -3230,9 +3230,9 @@ static void amd_iommu_apply_dm_region(struct device *dev,
.add_device = amd_iommu_add_device,
.remove_device = amd_iommu_remove_device,
.device_group = amd_iommu_device_group,
- .get_dm_regions = amd_iommu_get_dm_regions,
- .put_dm_regions = amd_iommu_put_dm_regions,
- .apply_dm_region = amd_iommu_apply_dm_region,
+ .get_resv_regions = amd_iommu_get_resv_regions,
+ .put_resv_regions = amd_iommu_put_resv_regions,
+ .apply_resv_region = amd_iommu_apply_resv_region,
.pgsize_bitmap = AMD_IOMMU_PGSIZES,
};
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index dbe7f65..1cee5c3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -318,7 +318,7 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
struct device *dev)
{
struct iommu_domain *domain = group->default_domain;
- struct iommu_dm_region *entry;
+ struct iommu_resv_region *entry;
struct list_head mappings;
unsigned long pg_size;
int ret = 0;
@@ -331,14 +331,14 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
pg_size = 1UL << __ffs(domain->pgsize_bitmap);
INIT_LIST_HEAD(&mappings);
- iommu_get_dm_regions(dev, &mappings);
+ iommu_get_resv_regions(dev, &mappings);
/* We need to consider overlapping regions for different devices */
list_for_each_entry(entry, &mappings, list) {
dma_addr_t start, end, addr;
- if (domain->ops->apply_dm_region)
- domain->ops->apply_dm_region(dev, domain, entry);
+ if (domain->ops->apply_resv_region)
+ domain->ops->apply_resv_region(dev, domain, entry);
start = ALIGN(entry->start, pg_size);
end = ALIGN(entry->start + entry->length, pg_size);
@@ -358,7 +358,7 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group,
}
out:
- iommu_put_dm_regions(dev, &mappings);
+ iommu_put_resv_regions(dev, &mappings);
return ret;
}
@@ -1559,20 +1559,20 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
}
EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
-void iommu_get_dm_regions(struct device *dev, struct list_head *list)
+void iommu_get_resv_regions(struct device *dev, struct list_head *list)
{
const struct iommu_ops *ops = dev->bus->iommu_ops;
- if (ops && ops->get_dm_regions)
- ops->get_dm_regions(dev, list);
+ if (ops && ops->get_resv_regions)
+ ops->get_resv_regions(dev, list);
}
-void iommu_put_dm_regions(struct device *dev, struct list_head *list)
+void iommu_put_resv_regions(struct device *dev, struct list_head *list)
{
const struct iommu_ops *ops = dev->bus->iommu_ops;
- if (ops && ops->put_dm_regions)
- ops->put_dm_regions(dev, list);
+ if (ops && ops->put_resv_regions)
+ ops->put_resv_regions(dev, list);
}
/* Request that a device is direct mapped by the IOMMU */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 0ff5111..bfecb8b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,13 +118,13 @@ enum iommu_attr {
};
/**
- * struct iommu_dm_region - descriptor for a direct mapped memory region
+ * struct iommu_resv_region - descriptor for a reserved memory region
* @list: Linked list pointers
* @start: System physical start address of the region
* @length: Length of the region in bytes
* @prot: IOMMU Protection flags (READ/WRITE/...)
*/
-struct iommu_dm_region {
+struct iommu_resv_region {
struct list_head list;
phys_addr_t start;
size_t length;
@@ -150,9 +150,9 @@ struct iommu_dm_region {
* @device_group: find iommu group for a particular device
* @domain_get_attr: Query domain attributes
* @domain_set_attr: Change domain attributes
- * @get_dm_regions: Request list of direct mapping requirements for a device
- * @put_dm_regions: Free list of direct mapping requirements for a device
- * @apply_dm_region: Temporary helper call-back for iova reserved ranges
+ * @get_resv_regions: Request list of reserved regions for a device
+ * @put_resv_regions: Free list of reserved regions for a device
+ * @apply_resv_region: Temporary helper call-back for iova reserved ranges
* @domain_window_enable: Configure and enable a particular window for a domain
* @domain_window_disable: Disable a particular window for a domain
* @domain_set_windows: Set the number of windows for a domain
@@ -184,11 +184,12 @@ struct iommu_ops {
int (*domain_set_attr)(struct iommu_domain *domain,
enum iommu_attr attr, void *data);
- /* Request/Free a list of direct mapping requirements for a device */
- void (*get_dm_regions)(struct device *dev, struct list_head *list);
- void (*put_dm_regions)(struct device *dev, struct list_head *list);
- void (*apply_dm_region)(struct device *dev, struct iommu_domain *domain,
- struct iommu_dm_region *region);
+ /* Request/Free a list of reserved regions for a device */
+ void (*get_resv_regions)(struct device *dev, struct list_head *list);
+ void (*put_resv_regions)(struct device *dev, struct list_head *list);
+ void (*apply_resv_region)(struct device *dev,
+ struct iommu_domain *domain,
+ struct iommu_resv_region *region);
/* Window handling functions */
int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
@@ -233,8 +234,8 @@ extern size_t default_iommu_map_sg(struct iommu_domain *domain, unsigned long io
extern void iommu_set_fault_handler(struct iommu_domain *domain,
iommu_fault_handler_t handler, void *token);
-extern void iommu_get_dm_regions(struct device *dev, struct list_head *list);
-extern void iommu_put_dm_regions(struct device *dev, struct list_head *list);
+extern void iommu_get_resv_regions(struct device *dev, struct list_head *list);
+extern void iommu_put_resv_regions(struct device *dev, struct list_head *list);
extern int iommu_request_dm_for_dev(struct device *dev);
extern int iommu_attach_group(struct iommu_domain *domain,
@@ -443,12 +444,12 @@ static inline void iommu_set_fault_handler(struct iommu_domain *domain,
{
}
-static inline void iommu_get_dm_regions(struct device *dev,
+static inline void iommu_get_resv_regions(struct device *dev,
struct list_head *list)
{
}
-static inline void iommu_put_dm_regions(struct device *dev,
+static inline void iommu_put_resv_regions(struct device *dev,
struct list_head *list)
{
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 01/18] iommu/dma: Allow MSI-only cookies
From: Eric Auger @ 2017-01-05 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483643086-2883-1-git-send-email-eric.auger@redhat.com>
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Eric Auger <eric.auger@redhat.com>
---
[Eric] fixed 2 issues on MSI path
---
drivers/iommu/dma-iommu.c | 116 +++++++++++++++++++++++++++++++++++++---------
include/linux/dma-iommu.h | 7 +++
2 files changed, 101 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 2db0d64..f2c47ad 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_head msi_page_list;
- spinlock_t msi_lock;
+ union {
+ struct iova_domain iovad;
+ dma_addr_t msi_iova;
+ };
+ struct list_head msi_page_list;
+ spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
};
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
@@ -53,6 +62,19 @@ int iommu_dma_init(void)
return iova_cache_get();
}
+static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
+}
+
/**
* iommu_get_dma_cookie - Acquire DMA-API resources for a domain
* @domain: IOMMU domain to prepare for DMA-API usage
@@ -62,25 +84,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_dma_cookie);
+
+/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
struct iommu_dma_cookie *cookie;
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ cookie = __cookie_alloc(IOMMU_DMA_MSI_COOKIE);
if (!cookie)
return -ENOMEM;
- spin_lock_init(&cookie->msi_lock);
- INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->msi_iova = base;
domain->iova_cookie = cookie;
return 0;
}
-EXPORT_SYMBOL(iommu_get_dma_cookie);
+EXPORT_SYMBOL(iommu_get_msi_cookie);
/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
put_iova_domain(&cookie->iovad);
list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
@@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev)
{
- struct iova_domain *iovad = cookie_iovad(domain);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = &cookie->iovad;
unsigned long order, base_pfn, end_pfn;
- if (!iovad)
- return -ENODEV;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -EINVAL;
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
@@ -662,11 +713,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iommu_dma_msi_page *msi_page;
- struct iova_domain *iovad = &cookie->iovad;
+ struct iova_domain *iovad;
struct iova *iova;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ size_t size;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
+ iovad = &cookie->iovad;
+ size = iovad->granule;
+ } else {
+ iovad = NULL;
+ size = PAGE_SIZE;
+ }
+
+ msi_addr &= ~(phys_addr_t)(size - 1);
- msi_addr &= ~(phys_addr_t)iova_mask(iovad);
list_for_each_entry(msi_page, &cookie->msi_page_list, list)
if (msi_page->phys == msi_addr)
return msi_page;
@@ -675,13 +736,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
if (!msi_page)
return NULL;
- iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
- if (!iova)
- goto out_free_page;
-
msi_page->phys = msi_addr;
- msi_page->iova = iova_dma_addr(iovad, iova);
- if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
+ if (iovad) {
+ iova = __alloc_iova(domain, size, dma_get_mask(dev));
+ if (!iova)
+ goto out_free_page;
+ msi_page->iova = iova_dma_addr(iovad, iova);
+ } else {
+ msi_page->iova = cookie->msi_iova;
+ cookie->msi_iova += size;
+ }
+
+ if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
goto out_free_iova;
INIT_LIST_HEAD(&msi_page->list);
@@ -689,7 +755,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
return msi_page;
out_free_iova:
- __free_iova(iovad, iova);
+ if (iovad)
+ __free_iova(iovad, iova);
+ else
+ cookie->msi_iova -= size;
out_free_page:
kfree(msi_page);
return NULL;
@@ -730,7 +799,10 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
msg->data = ~0U;
} else {
msg->address_hi = upper_32_bits(msi_page->iova);
- msg->address_lo &= iova_mask(&cookie->iovad);
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE)
+ msg->address_lo &= iova_mask(&cookie->iovad);
+ else
+ msg->address_lo &= (PAGE_SIZE - 1);
msg->address_lo += lower_32_bits(msi_page->iova);
}
}
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 7f7e9a7..c843461 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -27,6 +27,7 @@
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
/* Setup call for arch DMA mapping code */
@@ -86,6 +87,12 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
return -ENODEV;
}
+static inline int iommu_get_msi_cookie(struct iommu_domain *domain,
+ dma_addr_t base)
+{
+ return -ENODEV;
+}
+
static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
{
}
--
1.9.1
^ permalink raw reply related
* [PATCH v6 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Eric Auger @ 2017-01-05 19:04 UTC (permalink / raw)
To: linux-arm-kernel
Following LPC discussions, we now report reserved regions through
iommu-group sysfs reserved_regions attribute file.
Reserved regions are populated through the IOMMU get_resv_region
callback (former get_dm_regions), now implemented by amd-iommu,
intel-iommu and arm-smmu:
- the intel-iommu reports the [0xfee00000 - 0xfeefffff] MSI window
as an IOMMU_RESV_NOMAP reserved region.
- the amd-iommu reports device direct mapped regions, the MSI region
and HT regions.
- the arm-smmu reports the MSI window (arbitrarily located at
0x8000000 and 1MB large).
Unsafe interrupt assignment is tested by enumerating all MSI irq
domains and checking MSI remapping is supported in the above hierarchy.
This check is done in case we detect the iommu translates MSI
(an IOMMU_RESV_MSI window exists). Otherwise the IRQ remapping
capability is checked at IOMMU level. Obviously this is a defensive
IRQ safety assessment: Assuming there are several MSI controllers
in the system and at least one does not implement IRQ remapping,
the assignment will be considered as unsafe (even if this controller
is not acessible from the assigned devices).
The series integrates a not officially posted patch from Robin:
"iommu/dma: Allow MSI-only cookies".
Best Regards
Eric
Git: complete series available at
https://github.com/eauger/linux/tree/v4.10-rc2-reserved-v6
History:
PATCHv5 -> PATCHv6
- Introduce IRQ_DOMAIN_FLAG_MSI as suggested by Marc
- irq_domain_is_msi, irq_domain_is_msi_remap,
irq_domain_hierarchical_is_msi_remap,
- set IRQ_DOMAIN_FLAG_MSI in msi_create_irq_domain
- fix compil issue on i386
- rework test at VFIO level
RFCv4 -> PATCHv5
- fix IRQ security assessment by looking at irq domain parents
- check DOMAIN_BUS_FSL_MC_MSI irq domains
- AMD MSI and HT regions are exposed in iommu group sysfs
RFCv3 -> RFCv4:
- arm-smmu driver does not register PCI host bridge windows as
reserved regions anymore
- Implement reserved region get/put callbacks also in arm-smmuv3
- take the iommu_group lock on iommu_get_group_resv_regions
- add a type field in iommu_resv_region instead of using prot
- init the region list_head in iommu_alloc_resv_region, also
add type parameter
- iommu_insert_resv_region manage overlaps and sort reserved
windows
- address IRQ safety assessment by enumerating all the MSI irq
domains and checking the MSI_REMAP flag
- update Documentation/ABI/testing/sysfs-kernel-iommu_groups
RFC v2 -> v3:
- switch to an iommu-group sysfs API
- use new dummy allocator provided by Robin
- dummy allocator initialized by vfio-iommu-type1 after enumerating
the reserved regions
- at the moment ARM MSI base address/size is left unchanged compared
to v2
- we currently report reserved regions and not usable IOVA regions as
requested by Alex
RFC v1 -> v2:
- fix intel_add_reserved_regions
- add mutex lock/unlock in vfio_iommu_type1
Eric Auger (18):
iommu/dma: Allow MSI-only cookies
iommu: Rename iommu_dm_regions into iommu_resv_regions
iommu: Add a new type field in iommu_resv_region
iommu: iommu_alloc_resv_region
iommu: Only map direct mapped regions
iommu: iommu_get_group_resv_regions
iommu: Implement reserved_regions iommu-group sysfs file
iommu/vt-d: Implement reserved region get/put callbacks
iommu/amd: Declare MSI and HT regions as reserved IOVA regions
iommu/arm-smmu: Implement reserved region get/put callbacks
iommu/arm-smmu-v3: Implement reserved region get/put callbacks
irqdomain: Add irq domain MSI and MSI_REMAP flags
genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation
irqdomain: irq_domain_check_msi_remap
irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP
vfio/type1: Allow transparent MSI IOVA allocation
vfio/type1: Check MSI remapping at irq domain level
iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore
drivers/iommu/amd_iommu.c | 54 +++++++++-----
drivers/iommu/arm-smmu-v3.c | 30 +++++++-
drivers/iommu/arm-smmu.c | 30 +++++++-
drivers/iommu/dma-iommu.c | 116 ++++++++++++++++++++++++------
drivers/iommu/intel-iommu.c | 50 +++++++++----
drivers/iommu/iommu.c | 152 ++++++++++++++++++++++++++++++++++++---
drivers/irqchip/irq-gic-v3-its.c | 1 +
drivers/vfio/vfio_iommu_type1.c | 37 +++++++++-
include/linux/dma-iommu.h | 7 ++
include/linux/iommu.h | 46 ++++++++----
include/linux/irqdomain.h | 36 ++++++++++
kernel/irq/irqdomain.c | 39 ++++++++++
kernel/irq/msi.c | 4 +-
13 files changed, 515 insertions(+), 87 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Michał Zegan @ 2017-01-05 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483628549-29486-1-git-send-email-narmstrong@baylibre.com>
Hello.
The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
it actually works, but...
Loading the module causes few errors because of not found frequencies or
something, then it is all okay. However after loading scpi-cpufreq you
cannot actually power the cpu off and on. You will power it off
successfully, but when trying to power it on, the cpufreq driver will
error out, and then after it happens, the cpu that was trying to go
online will be offline again, and that is a little... unfortunate. The
question is, and I cannot really test that: will the module actually
autoload after this change?
W dniu 05.01.2017 o 16:02, Neil Armstrong pisze:
> The current hardware is not able to run with all cores enabled at a
> cluster frequency superior at 1536MHz.
> But the currently shipped u-boot for the platform still reports an OPP
> table with possible DVFS frequency up to 2GHz, and will not change since
> the off-tree linux tree supports limiting the OPPs with a kernel parameter.
> A recent u-boot change reports the boot-time DVFS around 100MHz and
> the default performance cpufreq governor sets the maximum frequency.
> Previous version of u-boot reported to be already at the max OPP and
> left the OPP as is.
> Nevertheless, other governors like ondemand could setup the max frequency
> and make the system crash.
>
> This patch disables the DVFS clock and disables cpufreq.
>
> Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbea..5e63e3b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -137,6 +137,10 @@
> };
> };
>
> +&scpi_dvfs {
> + status = "disabled";
> +};
> +
> &uart_AO {
> status = "okay";
> pinctrl-0 = <&uart_ao_a_pins>;
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 525 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/9c0439b7/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: sun7i: Add wifi dt node on Banana Pro
From: Jörg Krause @ 2017-01-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105181151.i3ttsu5ylrw45br7@lukather>
Hi Maxim,
On Thu, 2017-01-05 at 19:11 +0100, Maxime Ripard wrote:
> Hi J?rg,
>
> On Thu, Jan 05, 2017 at 06:37:53PM +0100, J?rg Krause wrote:
> > The Banana Pro has an AMPAK AP6181 WiFi+Bluetooth module. The WiFi
> > part
> > is a BCM43362 IC connected to MMC3 of the A20 SoC via SDIO. The IC
> > also
> > takes a power enable signal via GPIO.
> >
> > This commit adds a device-tree node to power it up, so the mmc
> > subsys
> > can scan it, and enables the mmc controller which is connected to
> > it.
> >
> > As the wifi enable pin of the AP6181 module is not really a
> > regulator,
> > switch the mmc3 node to the mmc-pwrseq framework for controlling
> > it.
> > This more accurately reflectes how the hardware actually works.
> >
> > Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> > ---
> > Changes v2 (suggested by Maxime Ripard):
> > ? - rename pwrseq node to clarify the function rather what it's
> > ????connected to
> > ? - use dash instead of underscore for the pwrseq node name
> > ? - remove setting pull-ups for mmc3 (default since commit
> > 37bc56128d92)
> >
> > ---
> > ?arch/arm/boot/dts/sun7i-a20-bananapro.dts | 30 ++++++++++++++++++-
> > -----------
> > ?1 file changed, 18 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> > b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> > index 19d63d4049de..77f8fb76c157 100644
> > --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> > +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> > @@ -76,6 +76,13 @@
> > ? };
> > ? };
> > ?
> > + wifi_pwrseq: wifi-pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vmmc3_pin_bananapro>;
> > + reset-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > ? reg_gmac_3v3: gmac-3v3 {
> > ? compatible = "regulator-fixed";
> > ? pinctrl-names = "default";
> > @@ -87,17 +94,6 @@
> > ? enable-active-high;
> > ? gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>;
> > ? };
> > -
> > - reg_vmmc3: vmmc3 {
> > - compatible = "regulator-fixed";
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&vmmc3_pin_bananapro>;
> > - regulator-name = "vmmc3";
> > - regulator-min-microvolt = <3300000>;
> > - regulator-max-microvolt = <3300000>;
> > - enable-active-high;
> > - gpio = <&pio 7 22 GPIO_ACTIVE_HIGH>;
> > - };
> > ?};
> > ?
> > ?&ahci {
> > @@ -166,10 +162,20 @@
> > ?&mmc3 {
> > ? pinctrl-names = "default";
> > ? pinctrl-0 = <&mmc3_pins_a>;
> > - vmmc-supply = <®_vmmc3>;
> > + vmmc-supply = <®_vcc3v3>;
> > + mmc-pwrseq = <&wifi_pwrseq>;
> > ? bus-width = <4>;
> > ? non-removable;
> > + wakeup-source;
>
> Sorry for not spotting that earlier, but this is suspicious. The PIO
> is not able to be wake up the CPU, since it's connected to the GIC
> that is shut down during CPU suspend. Our only wake up source is the
> NMI controller. So either it is not able to wake up the system, or
> the
> interrupt line in not the right one.
Sorry, but I'm not sure I understand...
The "WIFI-HOST-WAKE" line connects "WL_HOST_WAKE" of the AP6210 to pin
EINT15 of the A20 as shown in the schematic of the board [1].
Note, that this is the same hardware configuration as done on the
Banana Pi M1+ [2]. The device tree node for mmc3 of the M1+ has
"wakeup-source" enabled, too, so I inherited it. However, I did not
tested the wake-up feature.
[1] http://mirror.lemaker.org/Banana%20Pro%20Schematic.pdf
[2] https://drive.google.com/file/d/0B4PAo2nW2KfnNTk5WnVSV0lPejA/view?u
sp=sharing
J?rg
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: keystone: Add "ti, da830-uart" compatible string
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
The TI Keystone SoCs have extra UART registers beyond the standard 8250
registers, so we need a new compatible string to indicate this. Also, at
least one of these registers uses the full 32 bits, so we need to specify
reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work as
long as the bootloader configures the SoC UART power management registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v3 changes:
* None
v2 changes:
* This is a new patch in v2
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0c..7d7b9a8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -90,7 +90,7 @@
};
uart0: serial at 02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index 0c5e74e..e91633f 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -35,7 +35,7 @@
/include/ "keystone-k2l-clocks.dtsi"
uart2: serial at 02348400 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -45,7 +45,7 @@
};
uart3: serial at 02348800 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba..9152610 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -98,7 +98,7 @@
/include/ "keystone-clocks.dtsi"
uart0: serial at 02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -108,7 +108,7 @@
};
uart1: serial at 02531000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/4] ARM: da850: Add ti, da830-uart compatible for serial ports
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v3 changes:
* None
v2 changes:
* None
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
interrupt-names = "edm3_tcerrint";
};
serial0: serial at 42000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x42000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
status = "disabled";
};
serial1: serial at 10c000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10c000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
status = "disabled";
};
serial2: serial at 10d000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10d000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/4] serial: 8250: Add new port type for TI DA8xx/66AK2x
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x.
These SoCs have standard 8250 registers plus some extra non-standard
registers.
The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
---
v3 changes:
* Changed list of SoCs to "DA8xx/66AK2x"
v2 changes:
* Added C66x to list of SoCs
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
.data = (void *)PORT_ALTR_16550_F128, },
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
+ { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..3f0c994 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_DA830] = {
+ .name = "TI DA8xx/66AK2x",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO | UART_CAP_AFE,
+ },
};
/* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_out(port, UART_LCR, 0);
}
+ if (port->type == PORT_DA830) {
+ /* Reset the port */
+ serial_port_out(port, UART_IER, 0);
+ serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+ mdelay(10);
+
+ /* Enable Tx, Rx and free run mode */
+ serial_port_out(port, UART_DA830_PWREMU_MGMT,
+ UART_DA830_PWREMU_MGMT_UTRST |
+ UART_DA830_PWREMU_MGMT_URRST |
+ UART_DA830_PWREMU_MGMT_FREE);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..9ec741b 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250 30 /* max port ID */
+#define PORT_DA830 31 /* TI DA8xx/66AK2x */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..274d8fc 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
#define SERIAL_RSA_BAUD_BASE (921600)
#define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
+/* Extra registers for TI DA8xx/66AK2x */
+#define UART_DA830_PWREMU_MGMT 12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE (1 << 0) /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST (1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST (1 << 14) /* Transmitter reset/enable */
+
/*
* Extra serial register definitions for the internal UARTs
* in TI OMAP processors.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/4] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v3 changes:
* None
v2 changes:
* picked up Acked-by:
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x UART
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x
UART. These SoCs have a non-standard register for UART power management that
needs special handling in the UART driver.
Greg, the first two patches will need to go through your tree. Sekhar and
Santosh will pick up the 3 and 4 patches respectively.
v3 changes:
* Shortened list of SoCs to "DA8xx/66AK2x"
v2 changes:
* Added references to C66x SoC in various places, which I assume is an OK
shorthand for TI Keystone processors.
* New patch for Keystone device tree. This is untested as I don't have any
Keystone boards.
David Lechner (4):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI DA8xx/66AK2x
ARM: da850: Add ti,da830-uart compatible for serial ports
ARM: dts: keystone: Add "ti,da830-uart" compatible string
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
9 files changed, 45 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: exynos: Add tm2 touchkey node
From: Krzysztof Kozlowski @ 2017-01-05 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483604833-29746-5-git-send-email-jcsing.lee@samsung.com>
On Thu, Jan 05, 2017 at 05:27:13PM +0900, Jaechul Lee wrote:
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Although I said the patch looks correct, it was not an explicit Review
(and we have a quite serious "Reviewer's statement of oversight") so my
tag should not be added.
No harm was done, but I prefer clearly and explicitly given tags.
Best regards,
Krzysztof
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index aa8584a..dad6fb8 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -17,3 +17,16 @@
> model = "Samsung TM2 board";
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
> +
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey at 20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 8/9] arm64: cpufeature: Expose CPUID registers by emulation
From: Catalin Marinas @ 2017-01-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483552147-9605-9-git-send-email-suzuki.poulose@arm.com>
On Wed, Jan 04, 2017 at 05:49:06PM +0000, Suzuki K. Poulose wrote:
> This patch adds the hook for emulating MRS instruction to
> export the 'user visible' value of supported system registers.
> We emulate only the following id space for system registers:
>
> Op0=3, Op1=0, CRn=0, CRm=[0, 4-7]
>
> The rest will fall back to SIGILL. This capability is also
> advertised via a new HWCAP_CPUID.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Krzysztof Kozlowski @ 2017-01-05 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105092315.swensammin4wbgx5@gangnam.samsung>
On Thu, Jan 05, 2017 at 06:23:15PM +0900, Andi Shyti wrote:
> Hi Chanwoo,
>
> > I add the some comment as following:
> > - ldo23/25/31/38 have the different value between tm2 and tm2e.
>
> Thanks for pointing this out. I planned to do this already in a
> following patch as for now I think it's out from the scope of this
> particular patch.
>
> > - The patch[1] was alread posted. I think you better to rebase this patch on patch[1].
> > [1] https://patchwork.kernel.org/patch/9491769/
> > - ("ARM64: dts: TM2: comply to the samsung pinctrl naming convention")
>
> Yes, I also thought about this, but I didn't know whether it was
> already picked by anyone. I didn't want to stop Jaechul that's
> why I was planning to rebase the other rather than this.
> But you are right, because some bits of the other patches I know
> that have been merged. Thank you!
>
> Krzysztof, do you mind if I send patch 3 as a reply to this
> e-mail? The changes should not affect patch 4, anyway.
By patch 3 you mean this patch? Yes, you can send another version as a
reply-to but please version it (2.1? etc).
Anyway I need a proper rename detection. I pointed proper command last
time. Is it working?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] cpufreq: Remove CONFIG_CPU_FREQ_STAT_DETAILS config option
From: Krzysztof Kozlowski @ 2017-01-05 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4299228a500a889c2b4b9e305674f3d1ea9ae06.1483604760.git.viresh.kumar@linaro.org>
On Thu, Jan 05, 2017 at 01:57:41PM +0530, Viresh Kumar wrote:
> This doesn't have any benefit apart from saving a small amount of memory
> when it is disabled. The ifdef hackery in the code makes it dirty
> unnecessarily.
>
> Clean it up by removing the Kconfig option completely. Few defconfigs
> are also updated and CONFIG_CPU_FREQ_STAT_DETAILS is replaced with
> CONFIG_CPU_FREQ_STAT now in them, as users wanted stats to be enabled.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> arch/arm/configs/exynos_defconfig | 2 +-
> arch/arm/configs/multi_v5_defconfig | 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/mvebu_v5_defconfig | 2 +-
> arch/arm/configs/pxa_defconfig | 2 +-
> arch/arm/configs/shmobile_defconfig | 2 +-
> arch/mips/configs/lemote2f_defconfig | 1 -
> arch/powerpc/configs/ppc6xx_defconfig | 1 -
> arch/sh/configs/sh7785lcr_32bit_defconfig | 2 +-
> drivers/cpufreq/Kconfig | 8 --------
> drivers/cpufreq/cpufreq_stats.c | 14 --------------
> 11 files changed, 7 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 79c415c33f69..809f0bf3042a 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -24,7 +24,7 @@ CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
> CONFIG_CPU_FREQ=y
> -CONFIG_CPU_FREQ_STAT_DETAILS=y
> +CONFIG_CPU_FREQ_STAT=y
> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> CONFIG_CPU_FREQ_GOV_USERSPACE=m
For Exynos:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] mtd: nand: lpc32xx: fix invalid error handling of a requested irq
From: Vladimir Zapolskiy @ 2017-01-05 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105175851.GC50438@google.com>
On 01/05/2017 07:58 PM, Brian Norris wrote:
> On Tue, Jan 03, 2017 at 11:47:46AM +0100, Boris Brezillon wrote:
>> On Tue, 3 Jan 2017 12:16:26 +0200
>> Vladimir Zapolskiy <vz@mleia.com> wrote:
>>> On 01/03/2017 11:12 AM, Boris Brezillon wrote:
>>>> Do you need to backport this fix to stable releases? If that's the
>>>> case, I'll add the Cc: stable tag when applying.
>>>
>>> that will be great if you can add
>>>
>>> Cc: stable at kernel.org # v4.7+
>>>
>>> Please feel free to add also the tag
>>>
>>> Fixes: 8cb17b5ed017 ("irqchip: Add LPC32xx interrupt controller driver")
>>
>> Applied to nand/next (this patch will appear in 4.11).
>
> For next time, checkpatch noticed that you got the stable address wrong:
>
> ERROR:STABLE_ADDRESS: The 'stable' address should be 'stable at vger.kernel.org'
> #17: Cc: stable at kernel.org # v4.7+
>
> Brian
>
sorry, I've git-logged to commit 52bce91165 and pasted the address from
its commit message.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2] ARM: dts: sun7i: Add wifi dt node on Banana Pro
From: Maxime Ripard @ 2017-01-05 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105173753.14024-1-joerg.krause@embedded.rocks>
Hi J?rg,
On Thu, Jan 05, 2017 at 06:37:53PM +0100, J?rg Krause wrote:
> The Banana Pro has an AMPAK AP6181 WiFi+Bluetooth module. The WiFi part
> is a BCM43362 IC connected to MMC3 of the A20 SoC via SDIO. The IC also
> takes a power enable signal via GPIO.
>
> This commit adds a device-tree node to power it up, so the mmc subsys
> can scan it, and enables the mmc controller which is connected to it.
>
> As the wifi enable pin of the AP6181 module is not really a regulator,
> switch the mmc3 node to the mmc-pwrseq framework for controlling it.
> This more accurately reflectes how the hardware actually works.
>
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> ---
> Changes v2 (suggested by Maxime Ripard):
> - rename pwrseq node to clarify the function rather what it's
> connected to
> - use dash instead of underscore for the pwrseq node name
> - remove setting pull-ups for mmc3 (default since commit 37bc56128d92)
>
> ---
> arch/arm/boot/dts/sun7i-a20-bananapro.dts | 30 ++++++++++++++++++------------
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> index 19d63d4049de..77f8fb76c157 100644
> --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> @@ -76,6 +76,13 @@
> };
> };
>
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <&vmmc3_pin_bananapro>;
> + reset-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>;
> + };
> +
> reg_gmac_3v3: gmac-3v3 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> @@ -87,17 +94,6 @@
> enable-active-high;
> gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>;
> };
> -
> - reg_vmmc3: vmmc3 {
> - compatible = "regulator-fixed";
> - pinctrl-names = "default";
> - pinctrl-0 = <&vmmc3_pin_bananapro>;
> - regulator-name = "vmmc3";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - enable-active-high;
> - gpio = <&pio 7 22 GPIO_ACTIVE_HIGH>;
> - };
> };
>
> &ahci {
> @@ -166,10 +162,20 @@
> &mmc3 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins_a>;
> - vmmc-supply = <®_vmmc3>;
> + vmmc-supply = <®_vcc3v3>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> non-removable;
> + wakeup-source;
Sorry for not spotting that earlier, but this is suspicious. The PIO
is not able to be wake up the CPU, since it's connected to the GIC
that is shut down during CPU suspend. Our only wake up source is the
NMI controller. So either it is not able to wake up the system, or the
interrupt line in not the right one.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/67bd8828/attachment.sig>
^ permalink raw reply
* [RFC PATCH 1/7] arm64: Use physical counter for in-kernel reads
From: Marc Zyngier @ 2017-01-05 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210204712.21830-2-christoffer.dall@linaro.org>
[adding the arm64 maintainers, plus Mark as arch timer maintainer]
On 10/12/16 20:47, Christoffer Dall wrote:
> Using the physical counter allows KVM to retain the offset between the
> virtual and physical counter as long as it is actively running a VCPU.
>
> As soon as a VCPU is released, another thread is scheduled or we start
> running userspace applications, we reset the offset to 0, so that VDSO
> operations can still read the virtual counter and get the same view of
> time as the kernel.
>
> This opens up potential improvements for KVM performance.
>
> VHE kernels or kernels using the virtual timer are unaffected by this.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/arm64/include/asm/arch_timer.h | 6 ++++--
> drivers/clocksource/arm_arch_timer.c | 2 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index eaa5bbe..cec2549 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -139,11 +139,13 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
>
> static inline u64 arch_counter_get_cntpct(void)
> {
> + u64 cval;
> /*
> * AArch64 kernel and user space mandate the use of CNTVCT.
> */
> - BUG();
> - return 0;
> + isb();
> + asm volatile("mrs %0, cntpct_el0" : "=r" (cval));
> + return cval;
> }
>
> static inline u64 arch_counter_get_cntvct(void)
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487d..a5b0789 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -597,7 +597,7 @@ static void __init arch_counter_register(unsigned type)
>
> /* Register the CP15 based counter if we have one */
> if (type & ARCH_CP15_TIMER) {
> - if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
> + if (arch_timer_uses_ppi == VIRT_PPI || is_kernel_in_hyp_mode())
Why do we have this is_kernel_in_hyp_mode clause? I can't think of any
reason for a VHE kernel to use the virtual counter at all...
> arch_timer_read_counter = arch_counter_get_cntvct;
> else
> arch_timer_read_counter = arch_counter_get_cntpct;
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 7/9] arm64: cpufeature: Track user visible fields
From: Catalin Marinas @ 2017-01-05 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483552147-9605-8-git-send-email-suzuki.poulose@arm.com>
On Wed, Jan 04, 2017 at 05:49:05PM +0000, Suzuki K. Poulose wrote:
> Track the user visible fields of a CPU feature register. This will be
> used for exposing the value to the userspace. All the user visible
> fields of a feature register will be passed on as it is, while the
> others would be filled with their respective safe value.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> @@ -81,75 +82,75 @@ cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused)
>
>
> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
BTW, as a separate patch I think we need to expose the RDM field in this
register as well, together with a corresponding HWCAP bit.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2017-01-05 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105180151.gooxj3zy53hgojah@lukather>
On Thu, 5 Jan 2017 19:01:51 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Jan 05, 2017 at 06:37:34PM +0100, Emmanuel Vadot wrote:
> >
> > Hi,
> >
> > On Thu, 5 Jan 2017 18:16:01 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > > > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > > > connectors.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > > ---
> > > > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > index 669a1c338c76..fa8c6f60552b 100644
> > > > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > @@ -300,12 +300,14 @@
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&spi1_pins_a>,
> > > > <&spi1_cs0_pins_a>;
> > > > + status = "okay";
> > > > };
> > > >
> > > > &spi2 {
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&spi2_pins_a>,
> > > > <&spi2_cs0_pins_a>;
> > > > + status = "okay";
> > > > };
> > >
> > > Those nodes don't exist unfortunately. Maybe you forgot to send one
> > > patch?
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > It's based on a previous sent patch :
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
> >
> > You said you'll squash the two commits.
>
> Hmmm, indeed, I might have made a mistake on this one and ended up
> dropping it... :/
>
> I reapplied both and squashed them together, thanks (and sorry again)!
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
No problem, thank you!
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Maxime Ripard @ 2017-01-05 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105183734.c56cf3e0be4ad4ac21028851@bidouilliste.com>
On Thu, Jan 05, 2017 at 06:37:34PM +0100, Emmanuel Vadot wrote:
>
> Hi,
>
> On Thu, 5 Jan 2017 18:16:01 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > > connectors.
> > >
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > ---
> > > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > index 669a1c338c76..fa8c6f60552b 100644
> > > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > @@ -300,12 +300,14 @@
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&spi1_pins_a>,
> > > <&spi1_cs0_pins_a>;
> > > + status = "okay";
> > > };
> > >
> > > &spi2 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&spi2_pins_a>,
> > > <&spi2_cs0_pins_a>;
> > > + status = "okay";
> > > };
> >
> > Those nodes don't exist unfortunately. Maybe you forgot to send one
> > patch?
> >
> > Thanks!
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> It's based on a previous sent patch :
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
>
> You said you'll squash the two commits.
Hmmm, indeed, I might have made a mistake on this one and ended up
dropping it... :/
I reapplied both and squashed them together, thanks (and sorry again)!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/a970b7d1/attachment-0001.sig>
^ permalink raw reply
* [PATCH] mtd: nand: lpc32xx: fix invalid error handling of a requested irq
From: Brian Norris @ 2017-01-05 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103114746.141d7d7d@bbrezillon>
On Tue, Jan 03, 2017 at 11:47:46AM +0100, Boris Brezillon wrote:
> On Tue, 3 Jan 2017 12:16:26 +0200
> Vladimir Zapolskiy <vz@mleia.com> wrote:
> > On 01/03/2017 11:12 AM, Boris Brezillon wrote:
> > > Do you need to backport this fix to stable releases? If that's the
> > > case, I'll add the Cc: stable tag when applying.
> >
> > that will be great if you can add
> >
> > Cc: stable at kernel.org # v4.7+
> >
> > Please feel free to add also the tag
> >
> > Fixes: 8cb17b5ed017 ("irqchip: Add LPC32xx interrupt controller driver")
>
> Applied to nand/next (this patch will appear in 4.11).
For next time, checkpatch noticed that you got the stable address wrong:
ERROR:STABLE_ADDRESS: The 'stable' address should be 'stable at vger.kernel.org'
#17: Cc: stable at kernel.org # v4.7+
Brian
^ permalink raw reply
* [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Maxime Ripard @ 2017-01-05 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104140750.7qs4pvggwjdj5cma@rob-hp-laptop>
Hi Rob,
On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Unlike the A64 user manual reports, the third MMC controller on the
> > A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
> > DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
> > This does not affect the other two controllers, so introduce a new
> > DT compatible string to let the driver use different settings for that
> > particular device. This will also help to enable the high-speed transfer
> > modes of that controller later.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
> > drivers/mmc/host/sunxi-mmc.c | 7 +++++++
> > 2 files changed, 8 insertions(+)
>
> Acked-by: Rob Herring <robh@kernel.org>
Some kind of a digression on this: we have three MMC controllers on
this SoC. Like this patch shows, the third one is clearly different,
and supports both more modes, a wider bus, and specific quirks. We
need a new compatible for this one, everything's perfect.
However, the other two are mostly the same, but seems to need
different tuning parameters to get more performances out of the
controller (but this is unclear yet). How do we usually deal with
that?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/6d02f07c/attachment.sig>
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Brian Norris @ 2017-01-05 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105171845.GK4310@atomide.com>
On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > To improve NAND safety we updated the partition layout.
> > > Added barebox backup partition and removed kernel and oftree
> > > partition. They are kept in ubi now.
> >
> > What about the users with earlier partition tables?
> >
> > Please read about "flag day" changes, typically they are not
> > acceptable.
>
> Adding Brian and Adam to Cc. Can you guys come up with some
> solution on this?
I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!
> I'm suggesting we leave the kernel nodes empty and let u-boot
> populate them, so maybe you guys can discuss this on the related
> lists.
That's an option. I've worked with platforms that did something like
this, and that's really one of the only ways you can handle putting
partition information in the device tree. You're really hamstringing
yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.
The best solution would be to try to migrate away from static device
tree representations of partition info entirely. UBI volumes are best
where possible. If not, then some other kind of on-flash data structures
(along the lines of a GPT) with a corresponding MTD partition parser is
an OK alternative. Unfortunately, there isn't any good standard format
for this on MTD, so it's typically all custom -- and so people use the
easiest approach: device tree. And it's even more difficult with NAND,
which has reliability problems, especially with static data (e.g., read
disturb).
Anyway, the parser solution is helpful only if one can properly fix the
"flag day" first. And it requires a little bit more work to be generally
useful; I posted some work for this over a year ago, but bikeshedding
brought it down.
> The rest of the series looks fine to me so applying it into
> omap-for-v4.11/dt.
Brian
^ permalink raw reply
* [RFC 1/4] mm: remove unused TASK_SIZE_OF()
From: Andy Lutomirski @ 2017-01-05 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0258289@AcuExch.aculab.com>
On Thu, Jan 5, 2017 at 1:51 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Dmitry Safonov
>> Sent: 30 December 2016 15:57
>> All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or
>> TASK_SIZE_MAX since:
>> commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for
>> FSBASE/GSBASE upper limits"),
>> commit a06db751c321 ("pagemap: check permissions and capabilities at
>> open time"),
> ...
>> +#define TASK_SIZE (current->thread.task_size)
>
> I'm not sure I like he hidden 'current' argument to an
> apparent constant.
Me neither. But this patch is merely changing the implementation.
^ permalink raw reply
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Andy Lutomirski @ 2017-01-05 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104141959.GC17319@node.shutemov.name>
On Wed, Jan 4, 2017 at 6:19 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> On Tue, Jan 03, 2017 at 10:27:22AM -0800, Andy Lutomirski wrote:
>> On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
>> > And what about stack? I'm not sure that everybody would be happy with
>> > stack in the middle of address space.
>>
>> I would, personally. I think that, for very large address spaces, we
>> should allocate a large block of stack and get rid of the "stack grows
>> down forever" legacy idea. Then we would never need to worry about
>> the stack eventually hitting some other allocation. And 2^57 bytes is
>> hilariously large for a default stack.
>
> The stack in the middle of address space can prevent creating other huuuge
> contiguous mapping. Databases may want this.
Fair enough. OTOH, 2^47 is nowhere near the middle if we were to put
it near the top of the legacy address space.
^ permalink raw reply
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