* [PATCH v2 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Linus Walleij @ 2016-11-30 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480351226-3332-4-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This SoC has a separate pin controller for configuring pullup/pulldown
> bias on groups of pins.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * Moved pin-controller at 22c00c device node after gpio at 226000 (there seem to be
> more nodes in proper order here compared to the i2c at 228000 node suggested by
> Sekhar)
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Take this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/3] pinctrl: New driver for TI DA850/OMAP-L138/AM18XX pinconf
From: Linus Walleij @ 2016-11-30 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480351226-3332-3-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This adds a new driver for pinconf on TI DA850/OMAP-L138/AM18XX. These
> SoCs have a separate controller for controlling pullup/pulldown groups.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/3] devicetree: bindings: pinctrl: Add binding for ti, da850-pupd
From: Linus Walleij @ 2016-11-30 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480351226-3332-2-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> Device-tree bindings for TI DA850/OMAP-L138/AM18XX pullup/pulldown
> pinconf controller.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Totally uncontroversial standard bindings so patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 06/10] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Robin Murphy @ 2016-11-30 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e91ce72-9d37-f4be-9224-856a1a4c3e1d@samsung.com>
On 30/11/16 07:54, Marek Szyprowski wrote:
> Hi Sricharan and Robin,
>
>
> On 2016-11-30 01:22, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart
>> <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> [rm: massive PCI hacks]
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/base/dma-mapping.c | 4 ++--
>> drivers/iommu/dma-iommu.c | 1 +
>> drivers/iommu/of_iommu.c | 5 +++--
>> drivers/of/device.c | 9 +++++++--
>> drivers/pci/probe.c | 6 ++++--
>> include/linux/of_device.h | 9 ++++++---
>> include/linux/pci.h | 4 ++--
>> 7 files changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>> index b2a5629..576fdfb 100644
>> --- a/drivers/base/dma-mapping.c
>> +++ b/drivers/base/dma-mapping.c
>> @@ -351,9 +351,9 @@ void dma_common_free_remap(void *cpu_addr, size_t
>> size, unsigned long vm_flags)
>> int dma_configure(struct device *dev)
>> {
>> if (dev_is_pci(dev))
>> - pci_dma_configure(dev);
>> + return pci_dma_configure(dev);
>> else if (dev->of_node)
>> - of_dma_configure(dev, dev->of_node);
>> + return of_dma_configure(dev, dev->of_node);
>> return 0;
>> }
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab866..d2a7a46 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -148,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain
>> *domain, dma_addr_t base,
>> base_pfn = max_t(unsigned long, 1, base >> order);
>> end_pfn = (base + size - 1) >> order;
>> + dev_info(dev, "0x%llx 0x%llx, 0x%llx 0x%llx, 0x%llx 0x%llx\n",
>> base, size, domain->geometry.aperture_start,
>> domain->geometry.aperture_end,
>
> This causes a NULL pointer dereference if caller passes NULL device
> pointer.
> There is such caller in drivers/gpu/drm/exynos/exynos_drm_iommu.h.
> Trivial to fix as it looks like a leftover from developement or
> debugging stage.
Yes, this is some development crap which was never intended to go
upstream. Hence "massive PCI hacks" ;)
Other than the first two patches, the rest of the stuff from me here was
just an experiment which I'm not entirely convinced by the outcome of -
I don't particularly like the resulting fragmentation of having
pci_dma_configure() awkwardly floating around on its own in pci.c.
Robin.
>> *dev->dma_mask, dev->coherent_dma_mask);
>> /* Check the domain allows at least some access to the device... */
>> if (domain->geometry.force_aperture) {
>> if (base > domain->geometry.aperture_end ||
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 349bd1d..9529d6c 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -23,6 +23,7 @@
>> #include <linux/of.h>
>> #include <linux/of_iommu.h>
>> #include <linux/of_pci.h>
>> +#include <linux/pci.h>
>> #include <linux/slab.h>
>> static const struct of_device_id __iommu_of_table_sentinel
>> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct
>> device *dev,
>> ops = ERR_PTR(err);
>> }
>> - return IS_ERR(ops) ? NULL : ops;
>> + return ops;
>> }
>> static int __init of_iommu_init(void)
>> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
>> for_each_matching_node_and_match(np, matches, &match) {
>> const of_iommu_init_fn init_fn = match->data;
>> - if (init_fn(np))
>> + if (init_fn && init_fn(np))
>> pr_err("Failed to initialise IOMMU %s\n",
>> of_node_full_name(np));
>> }
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index 1c843e2..d58595c 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
>> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE
>> events
>> * to fix up DMA configuration.
>> */
>> -void of_dma_configure(struct device *dev, struct device_node *np)
>> +int of_dma_configure(struct device *dev, struct device_node *np)
>> {
>> u64 dma_addr, paddr, size;
>> int ret;
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct
>> device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>> @@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct
>> device_node *np)
>> coherent ? " " : " not ");
>> iommu = of_iommu_configure(dev, np);
>> + if (IS_ERR(iommu))
>> + return PTR_ERR(iommu);
>> +
>> dev_dbg(dev, "device is%sbehind an iommu\n",
>> iommu ? " " : " not ");
>> arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
>> +
>> + return 0;
>> }
>> EXPORT_SYMBOL_GPL(of_dma_configure);
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 04af770..6316cae 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1724,13 +1724,14 @@ static void pci_set_msi_domain(struct pci_dev
>> *dev)
>> * Function to update PCI devices's DMA configuration using the same
>> * info from the OF node or ACPI node of host bridge's parent (if any).
>> */
>> -void pci_dma_configure(struct device *dev)
>> +int pci_dma_configure(struct device *dev)
>> {
>> struct device *bridge =
>> pci_get_host_bridge_device(to_pci_dev(dev));
>> + int ret = 0;
>> if (IS_ENABLED(CONFIG_OF) &&
>> bridge->parent && bridge->parent->of_node) {
>> - of_dma_configure(dev, bridge->parent->of_node);
>> + ret = of_dma_configure(dev, bridge->parent->of_node);
>> } else if (has_acpi_companion(bridge)) {
>> struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
>> enum dev_dma_attr attr = acpi_get_dma_attr(adev);
>> @@ -1742,6 +1743,7 @@ void pci_dma_configure(struct device *dev)
>> }
>> pci_put_host_bridge_device(bridge);
>> + return ret;
>> }
>> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
>> index d20a31a..6dca65c 100644
>> --- a/include/linux/of_device.h
>> +++ b/include/linux/of_device.h
>> @@ -55,7 +55,7 @@ static inline struct device_node
>> *of_cpu_device_node_get(int cpu)
>> return of_node_get(cpu_dev->of_node);
>> }
>> -void of_dma_configure(struct device *dev, struct device_node *np);
>> +int of_dma_configure(struct device *dev, struct device_node *np);
>> void of_dma_deconfigure(struct device *dev);
>> #else /* CONFIG_OF */
>> @@ -99,8 +99,11 @@ static inline struct device_node
>> *of_cpu_device_node_get(int cpu)
>> {
>> return NULL;
>> }
>> -static inline void of_dma_configure(struct device *dev, struct
>> device_node *np)
>> -{}
>> +
>> +static inline int of_dma_configure(struct device *dev, struct
>> device_node *np)
>> +{
>> + return 0;
>> +}
>> static inline void of_dma_deconfigure(struct device *dev)
>> {}
>> #endif /* CONFIG_OF */
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index d04f651..989ca44 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -870,7 +870,7 @@ struct resource *pci_find_parent_resource(const
>> struct pci_dev *dev,
>> #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn :
>> false))
>> #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
>> -void pci_dma_configure(struct device *dev);
>> +int pci_dma_configure(struct device *dev);
>> /* Generic PCI functions exported to card drivers */
>> @@ -1604,7 +1604,7 @@ static inline struct pci_dev
>> *pci_get_bus_and_slot(unsigned int bus,
>> #define dev_is_pf(d) (false)
>> #define dev_num_vf(d) (0)
>> -static inline void pci_dma_configure(struct device *dev) { }
>> +static inline int pci_dma_configure(struct device *dev) { return 0; }
>> #endif /* CONFIG_PCI */
>>
>
> Best regards
^ permalink raw reply
* [PATCH v3 2/2] ARM: tse850_defconfig: add Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
MAINTAINERS | 1 +
arch/arm/configs/tse850_defconfig | 223 ++++++++++++++++++++++++++++++++++++++
2 files changed, 224 insertions(+)
create mode 100644 arch/arm/configs/tse850_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 9dfe877f47e0..d8eb3843dbd4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2345,6 +2345,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/axentia.txt
F: arch/arm/boot/dts/axentia-*
+F: arch/arm/configs/tse850_defconfig
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/arch/arm/configs/tse850_defconfig b/arch/arm/configs/tse850_defconfig
new file mode 100644
index 000000000000..f6076e7e1669
--- /dev/null
+++ b/arch/arm/configs/tse850_defconfig
@@ -0,0 +1,223 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_AT91=y
+CONFIG_SOC_SAMA5D3=y
+# CONFIG_CACHE_L2X0 is not set
+CONFIG_AEABI=y
+CONFIG_UACCESS_WITH_MEMCPY=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
+CONFIG_KEXEC=y
+CONFIG_VFP=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPGRE_DEMUX=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_UDP_DIAG=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+CONFIG_IPV6_SIT_6RD=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_SNMP=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_SET_RBTREE=y
+CONFIG_NFT_SET_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_HASH=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_ATMEL_TCLIB=y
+CONFIG_ATMEL_SSC=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+CONFIG_MACB=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_MICREL_PHY=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_LEGACY_PTY_COUNT=4
+CONFIG_SERIAL_ATMEL=y
+CONFIG_SERIAL_ATMEL_CONSOLE=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_AT91=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET=y
+CONFIG_SENSORS_JC42=y
+CONFIG_WATCHDOG=y
+CONFIG_AT91SAM9X_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_PCM_OSS=y
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_USB is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_ATMEL_SOC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
+# CONFIG_HID_GENERIC is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_STORAGE_REALTEK=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_ISD200=y
+CONFIG_USB_STORAGE_USBAT=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_STORAGE_ALAUDA=y
+CONFIG_USB_STORAGE_ONETOUCH=y
+CONFIG_USB_STORAGE_KARMA=y
+CONFIG_USB_STORAGE_CYPRESS_ATACB=y
+CONFIG_USB_STORAGE_ENE_UB6250=y
+CONFIG_USB_UAS=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_ATMEL_USBA=y
+CONFIG_USB_G_SERIAL=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AT91RM9200=y
+CONFIG_DMADEVICES=y
+CONFIG_AT_HDMAC=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_AT91_ADC=y
+CONFIG_ENVELOPE_DETECTOR=y
+CONFIG_DPOT_DAC=y
+CONFIG_MCP4531=y
+CONFIG_PWM=y
+CONFIG_PWM_ATMEL=y
+CONFIG_PWM_ATMEL_TCB=y
+CONFIG_EXT4_FS=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+CONFIG_STRIP_ASM_SYMS=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_SHA1=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEV_ATMEL_AES=y
+CONFIG_CRYPTO_DEV_ATMEL_TDES=y
+CONFIG_CRYPTO_DEV_ATMEL_SHA=y
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
5 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index 000000000000..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+============================================
+
+Linea CPU module
+----------------
+
+Required root node properties:
+compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+----------------
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 130e927824b5..9dfe877f47e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2339,6 +2339,13 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda@axentia.se>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/axentia-*
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
M: Mauro Carvalho Chehab <mchehab@kernel.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 58a3024f7edc..8ca735b82891 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ axentia-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/axentia-linea.dtsi b/arch/arm/boot/dts/axentia-linea.dtsi
new file mode 100644
index 000000000000..5a47d847149c
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-linea.dtsi
@@ -0,0 +1,53 @@
+/*
+ * axentia-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&main {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom at 51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/axentia-tse850-3.dts b/arch/arm/boot/dts/axentia-tse850-3.dts
new file mode 100644
index 000000000000..4e7c8bea2873
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-tse850-3.dts
@@ -0,0 +1,276 @@
+/*
+ * axentia-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "axentia-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,ssc-controller = <&ssc0>;
+ axentia,audio-codec = <&pcm5142>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv at c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2 at 100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree at 180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs at 10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42 at 18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104 at 28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142 at 4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom at 50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy at 3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
2.1.4
^ permalink raw reply related
* [PATCH v3 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
changes v2 -> v3
- document the new compatible strings prefixed with "axentia,".
changes v1 -> v2
- squash the fixup into the correct patch, sorry for the noise.
After finally having all essintial drivers upstreamed (the
last ones are currently in -next) I would like to have the
dts and the defconfig also upstreamed.
Cheers,
Peter
Peter Rosin (2):
ARM: dts: add devicetree for the Axentia TSE-850
ARM: tse850_defconfig: add Axentia TSE-850
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
arch/arm/configs/tse850_defconfig | 223 +++++++++++++++++
6 files changed, 580 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
create mode 100644 arch/arm/configs/tse850_defconfig
--
2.1.4
^ permalink raw reply
* [PATCH 3/5] dt-bindings: spi: Add documentation for the Armada 3700 SPI Controller
From: Mark Brown @ 2016-11-30 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129143939.3191-4-romain.perier@free-electrons.com>
On Tue, Nov 29, 2016 at 03:39:37PM +0100, Romain Perier wrote:
> This adds the devicetree bindings documentation for the SPI controller
> present in the Marvell Armada 3700 SoCs.
Please submit patches using subject lines reflecting the style for the
subsystem. This makes it easier for people to identify relevant
patches. Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/48fcfac2/attachment.sig>
^ permalink raw reply
* [PATCH] watchdog: meson: Remove unneeded platform MODULE_ALIAS
From: Javier Martinez Canillas @ 2016-11-30 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66487a0e-1d20-519f-6cbf-645f8bfd33da@roeck-us.net>
Hello Guenter,
On 11/30/2016 07:59 AM, Guenter Roeck wrote:
> On 11/29/2016 06:57 AM, Javier Martinez Canillas wrote:
>> Hello Wim,
>>
>> On 10/20/2016 07:28 PM, Guenter Roeck wrote:
>>> On Wed, Oct 19, 2016 at 04:49:42PM -0300, Javier Martinez Canillas wrote:
>>>> The Amlogic Meson is a DT-only platform, which means the devices are
>>>> registered via OF and not using the legacy platform devices support.
>>>>
>>>> So there's no need to have a MODULE_ALIAS("platform:meson-gxbb-wdt")
>>>> since the reported uevent MODALIAS to user-space will be the OF one.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>
>>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>
>> Any comments about this patch? There are other two similar fixes for
>> watchdog drivers that were also reviewed by Guenter but never picked:
>>
>> https://lkml.org/lkml/2016/10/14/412
>> https://lkml.org/lkml/2016/10/14/413
>>
>> Best regards,
>>
> The patches are all in my watchdog-next branch, so Wim will hopefully
> pick them up for the next release.
>
Great, thanks a lot for the info.
> Guenter
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Florian Weimer @ 2016-11-30 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130120654.GJ1574@e103592.cambridge.arm.com>
On 11/30/2016 01:06 PM, Dave Martin wrote:
> I'm concerned here that there may be no sensible fixed size for the
> signal frame. We would make it ridiculously large in order to minimise
> the chance of hitting this problem again -- but then it would be
> ridiculously large, which is a potential problem for massively threaded
> workloads.
What's ridiculously large?
We could add a system call to get the right stack size. But as it
depends on VL, I'm not sure what it looks like. Particularly if you
need determine the stack size before creating a thread that uses a
specific VL setting.
> For setcontext/setjmp, we don't save/restore any SVE state due to the
> caller-save status of SVE, and I would not consider it necessary to
> save/restore VL itself because of the no-change-on-the-fly policy for
> this.
Okay, so we'd potentially set it on thread creation only? That might
not be too bad.
I really want to avoid a repeat of the setxid fiasco, where we need to
run code on all threads to get something that approximates the
POSIX-mandated behavior (process attribute) from what the kernel
provides (thread/task attribute).
> I'm not familiar with resumable functions/executors -- are these in
> the C++ standards yet (not that that would cause me to be familiar
> with them... ;) Any implementation of coroutines (i.e.,
> cooperative switching) is likely to fall under the "setcontext"
> argument above.
There are different ways to implement coroutines. Stack switching (like
setcontext) is obviously impacted by non-uniform register sizes. But
even the most conservative variant, rather similar to switch-based
emulation you sometimes see in C coroutine implementations, might have
trouble restoring the state if it just cannot restore the saved state
due to register size reductions.
Thanks,
Florian
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Szabolcs Nagy @ 2016-11-30 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130120654.GJ1574@e103592.cambridge.arm.com>
On 30/11/16 12:06, Dave Martin wrote:
> For setcontext/setjmp, we don't save/restore any SVE state due to the
> caller-save status of SVE, and I would not consider it necessary to
> save/restore VL itself because of the no-change-on-the-fly policy for
> this.
the problem is not changing VL within a thread,
but that setcontext can resume a context of a
different thread which had different VL and there
might be SVE regs spilled on the stack according
to that.
(i consider this usage undefined, but at least
the gccgo runtime does this)
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Lorenzo Pieralisi @ 2016-11-30 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00c901d24aa1$7d851730$788f4590$@codeaurora.org>
Hi Sricharan,
On Wed, Nov 30, 2016 at 06:04:13AM +0530, Sricharan wrote:
> Hi Lorenzo,
>
> >-----Original Message-----
> >From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Lorenzo Pieralisi
> >Sent: Monday, November 28, 2016 11:44 PM
> >To: Sricharan <sricharan@codeaurora.org>
> >Cc: linux-arm-msm at vger.kernel.org; joro at 8bytes.org; will.deacon at arm.com; tfiga at chromium.org; iommu at lists.linux-
> >foundation.org; srinivas.kandagatla at linaro.org; laurent.pinchart at ideasonboard.com; 'Robin Murphy' <robin.murphy@arm.com>;
> >linux-arm-kernel at lists.infradead.org; m.szyprowski at samsung.com
> >Subject: Re: [PATCH V3 0/8] IOMMU probe deferral support
> >
> >On Mon, Nov 28, 2016 at 11:12:08PM +0530, Sricharan wrote:
> >
> >[...]
> >
> >> >Cool. We're rather hoping that the ACPI stuff is good to go for 4.10
> >> >now, so it's probably worth pulling the rest of that in (beyond the one
> >> >patch I picked) to make sure the of_dma_configure/acpi_dma_configure
> >> >paths don't inadvertently diverge.
> >> >
> >>
> >> I rebased and was testing your branch with Lorenzo's series. One thing
> >> i am still trying to get right is the acpi_dma_configure call. With your
> >> series dma_configure calls pci_dma/of_dma configure, so i am just adding
> >> acpi_dma_configure call there for non-pci ACPI devices as well. I see that
> >> acpi_dma_configure right now is called from acpi_bind_one and
> >> iort_add_smmu_platform_device, both go through the really_probe function
> >> path, so moving acpi_dma_configure from the above the two functions
> >> to dma_configure. I remember we discussed this on another thread, so
> >> hopefully it is correct. I do not have an platform to test the ACPI though.
> >> I will take some testing help on V4 for this.
> >
> >I am happy to test it for you please just send me a pointer at your v4
> >code.
> >
> I posted the v4 and CCed you there. So i am little skeptical about the acpi
> changes that i have posted. I was checking for a function equivalent
> in acpi as of_match_node in DT, to figure out if the iommu_spec.np that
> the master device is pointing to is there in the iommu_of_table and based
> on that we can decide if to defer the probe. I was seeing iort_scan_node
> was its equivalent. But if that is not correct, then last patch has to be reworked.
> Anyways will be good to know your feedback on this.
Sure I will test it asap, thanks for putting it together.
Thanks,
Lorenzo
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-11-30 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH=s-POegNL2HLV3EGPt=b-jrJ4OOwpBFTfysMaX0TNgSw=3Hg@mail.gmail.com>
On Wed, Nov 30, 2016 at 11:08:50AM +0100, Florian Weimer wrote:
> On 11/25/2016 08:38 PM, Dave Martin wrote:
> >The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which
> >adds extra SIMD functionality and supports much larger vectors.
> >
> >This series implements core Linux support for SVE.
> >
> >Recipents not copied on the whole series can find the rest of the
> >patches in the linux-arm-kernel archives [2].
> >
> >
> >The first 5 patches "arm64: signal: ..." factor out the allocation and
> >placement of state information in the signal frame. The first three
> >are prerequisites for the SVE support patches.
> >
> >Patches 04-05 implement expansion of the signal frame, and may remain
> >controversial due to ABI break issues:
> >
> > * Discussion is needed on how userspace should detect/negotiate signal
> > frame size in order for this expansion mechanism to be workable.
>
> I'm leaning towards a simple increase in the glibc headers (despite the ABI
> risk), plus a personality flag to disable really wide vector registers in
> case this causes problems with old binaries.
I'm concerned here that there may be no sensible fixed size for the
signal frame. We would make it ridiculously large in order to minimise
the chance of hitting this problem again -- but then it would be
ridiculously large, which is a potential problem for massively threaded
workloads.
Or we could be more conservative, but risk a re-run of similar ABI
breaks in the future.
A personality flag may also discourage use of larger vectors, even
though the vast majority of software will work fine with them.
> A more elaborate mechanism will likely introduce more bugs than it makes
> existing applications working, due to its complexity.
Yes, I was a bit concerned about this when I tried to sketch something
out.
[...]
> > * No independent SVE vector length configuration per thread. This is
> > planned, but will follow as a separate add-on series.
>
> Per-thread register widths will likely make coroutine switching (setcontext)
> and C++ resumable functions/executors quite challenging.
>
> Can you detail your plans in this area?
>
> Thanks,
> Florian
I'll also respond to Yao's question here, since it's closely related:
On Wed, Nov 30, 2016 at 09:56:14AM +0000, Yao Qi wrote:
[...]
> If I read "independent SVE vector length configuration per thread"
> correctly, SVE vector length can be different in each thread, so the
> size of vector registers is different too. In GDB, we describe registers
> by "target description" which is per process, not per thread.
>
> --
> Yao (??)
So, my key goal is to support _per-process_ vector length control.
>From the kernel perspective, it is easiest to achieve this by providing
per-thread control since that is the unit that context switching acts
on.
How useful it really is to have threads with different VLs in the same
process is an open question. It's theoretically useful for runtime
environments, which may want to dispatch code optimised for different
VLs -- changing the VL on-the-fly within a single thread is not
something I want to encourage, due to overhead and ABI issues, but
switching between threads of different VLs would be more manageable.
However, I expect mixing different VLs within a single process to be
very much a special case -- it's not something I'd expect to work with
general-purpose code.
Since the need for indepent VLs per thread is not proven, we could
* forbid it -- i.e., only a thread-group leader with no children is
permitted to change the VL, which is then inherited by any child threads
that are subsequently created
* permit it only if a special flag is specified when requesting the VL
change
* permit it and rely on userspace to be sensible -- easiest option for
the kernel.
For setcontext/setjmp, we don't save/restore any SVE state due to the
caller-save status of SVE, and I would not consider it necessary to
save/restore VL itself because of the no-change-on-the-fly policy for
this.
I'm not familiar with resumable functions/executors -- are these in
the C++ standards yet (not that that would cause me to be familiar
with them... ;) Any implementation of coroutines (i.e.,
cooperative switching) is likely to fall under the "setcontext"
argument above.
Thoughts?
---Dave
^ permalink raw reply
* [PATCH 2/2] ACPI: Ignore Consumer/Producer for QWord/DWord/Word Address Space
From: Lorenzo Pieralisi @ 2016-11-30 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129184334.7618.5495.stgit@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Nov 29, 2016 at 12:43:34PM -0600, Bjorn Helgaas wrote:
> Per ACPI spec r6.0, sec 6.4.3.5.1, 2, 3, Bit [0] of General Flags (the
> Consumer/Producer bit) should be ignored for QWord/DWord/Word Address Space
> descriptors. The Consumer/Producer bit is defined only for the Extended
> Address Space descriptor.
>
> Ignore Consumer/Producer except for Extended Address Space descriptors.
>
> Note that for QWord/DWord/Word descriptors, we previously applied the
> translation offset (_TRA) only when the Consumer/Producer bit was set.
"..Consumer/Producer bit was clear" ? If that bit was set:
struct acpi_resource_address->producer_consumer == ACPI_CONSUMER
and we are not applying the _TRA offset in that case, right ?
Thanks,
Lorenzo
> This patch changes that: for those descriptors, we ignore Consumer/Producer
> and always apply the translation offset.
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/acpi/resource.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 2732d39e..b45cd8f 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -261,11 +261,16 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> * primary side. Non-bridge devices must list 0 for all Address
> * Translation offset bits.
> */
> - if (addr->producer_consumer == ACPI_PRODUCER)
> + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
> + if (addr->producer_consumer == ACPI_PRODUCER)
> + offset = attr->translation_offset;
> + else if (attr->translation_offset)
> + pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> + attr->translation_offset);
> + } else {
> offset = attr->translation_offset;
> - else if (attr->translation_offset)
> - pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
> - attr->translation_offset);
> + }
> +
> start = attr->minimum + offset;
> end = attr->maximum + offset;
>
> @@ -294,7 +299,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> return false;
> }
>
> - if (addr->producer_consumer == ACPI_PRODUCER)
> + if (ares->type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
> + addr->producer_consumer == ACPI_PRODUCER)
> res->flags |= IORESOURCE_WINDOW;
>
> if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
>
> --
> 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
^ permalink raw reply
* Unable to use perf in VM
From: Marc Zyngier @ 2016-11-30 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70374841-ecb1-a6c3-ed43-0f39e2d5fec2@riken.jp>
+ Shannon
On 29/11/16 22:04, Itaru Kitayama wrote:
> Hi,
>
> In a VM (virsh controlled, KVM acceleration enabled) on a recent
> kvmarm kernel host, I find I am unable to use perf to obtain
> performance statistics for a complex task like kernel build.
> (I've verified this is seen with a Fedora 25 VM and host combination
> as well)
> APM folks CC'ed think this might be caused by a bug in the core PMU
> framework code, thus I'd like to have experts opinion on this issue.
>
> [root at localhost linux]# perf stat -B make
> CHK include/config/kernel.release
> [ 119.617684] git[1144]: undefined instruction: pc=fffffc000808ff30
> [ 119.623040] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
> [ 119.627607] Internal error: undefined instruction: 0 [#1] SMP
[...]
In a VM running mainline hosted on an AMD Seattle box:
Performance counter stats for 'make':
1526089.499304 task-clock:u (msec) # 0.932 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
29527793 page-faults:u # 0.019 M/sec
2913174122673 cycles:u # 1.909 GHz
2365040892322 instructions:u # 0.81 insn per cycle
<not supported> branches:u
32049215378 branch-misses:u # 0.00% of all branches
1637.531444837 seconds time elapsed
Running the same host kernel on a Mustang system, the guest explodes
in the way you reported. The failing instruction always seems to be
an access to pmxevcntr_el0 (I've seen both reads and writes).
Funnily enough, it dies if you try any HW event other than cycles
("perf stat -e cycles ls" works, and "perf stat -e instructions ls"
explodes). Which would tend to indicate that we're screwing up
the counter selection, but I have no proof of that (specially that
the Seattle guest is working just as expected).
Shannon, any idea?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Suzuki K Poulose @ 2016-11-30 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124184436.GG7452@e104818-lin.cambridge.arm.com>
On 24/11/16 18:44, Catalin Marinas wrote:
> Hi Suzuki,
>
> On Thu, Nov 24, 2016 at 01:40:09PM +0000, Suzuki K. Poulose wrote:
>> --- /dev/null
>> +++ b/Documentation/arm64/cpu-feature-registers.txt
>> @@ -0,0 +1,198 @@
>> + ARM64 CPU Feature Registers
>> + ===========================
>> +
>> +Author: Suzuki K Poulose <suzuki.poulose@arm.com>
>> +
>> +
>> +This file describes the API for exporting the AArch64 CPU ID/feature
>> +registers to userspace. The availability of this API is advertised
>> +via the HWCAP_CPUID in HWCAPs.
>
> s/API/ABI/ maybe?
Sure
>
>> +
>> +1. Motivation
>> +---------------
>> +
>> +The ARM architecture defines a set of feature registers, which describe
>> +the capabilities of the CPU/system. Access to these system registers is
>> +restricted from EL0 and there is no reliable way for an application to
>> +extract this information to make better decisions at runtime. There is
>> +limited information available to the application via HWCAPs, however
>> +there are some issues with their usage.
>> +
>> + a) Any change to the HWCAPs requires an update to userspace (e.g libc)
>> + to detect the new changes, which can take a long time to appear in
>> + distributions. Exposing the registers allows applications to get the
>> + information without requiring updates to the toolchains.
>> +
>> + b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
>> + when ld is initialised at startup time).
>> +
>> + c) HWCAPs cannot represent non-boolean information effectively. The
>> + architecture defines a canonical format for representing features
>> + in the ID registers; this is well defined and is capable of
>> + representing all valid architecture variations. Exposing the ID
>> + registers avoids having to come up with HWCAP representations and
>> + parsing code.
>
> For point (c) above, we don't (yet?) have an actual case on AArch64
> where HWCAP needs more than a boolean value.
>
> And just to clarify my position: I consider that we should continue to
> expose HWCAP for new features (e.g. SVE) in parallel with the CPUID
> access emulation. There are different use-cases for them (i.e. dynamic
> loader uses HWCAP for the ifunc resolver).
Ok. So would you like to have the point (c) removed ? Or should I just add,
that we don't have such a feature yet.
>
>> +3. Implementation
>> +--------------------
>> +
>> +The infrastructure is built on the emulation of the 'MRS' instruction.
>> +Accessing a restricted system register from an application generates an
>> +exception and ends up in SIGILL being delivered to the process.
>> +The infrastructure hooks into the exception handler and emulates the
>> +operation if the source belongs to the supported system register space.
>> +
>> +The infrastructure emulates only the following system register space:
>> + Op0=3, Op1=0, CRn=0
>> +
>> +(See Table C5-6 'System instruction encodings for non-Debug System
>> +register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
>> +registers).
>> +
>> +
>> +The following rules are applied to the value returned by the
>> +infrastructure:
>> +
>> + a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
>> + b) The value of a reserved field is populated with the reserved
>> + value as defined by the architecture.
>> + c) The value of a field marked as not 'visible', is set to indicate
>> + the feature is missing (as defined by the architecture).
>
> I don't understand point (c) above. If it is marked as not 'visible', it
> is always reported to user as 0. The above could be misinterpreted as
> reporting missing architecture features.
>
Part of the reason is that, 0 may be unsafe or undefined by architecture for some fields.
e.g, ID_AA64PFR0_EL1: EL1/EL0 : 0 is undefined. We choose 0x1, which indicates
EL1/EL0 both only have AArch64.
So, we always fall back to the safe value for that particular feature,
which happens to be 0 for most, but not all.
> [...]
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 94c188f..fb331de 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -81,6 +81,10 @@ static bool __maybe_unused
>> cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused);
>>
>>
>> +/*
>> + * NOTE: Any changes to the visibility of features should be kept in
>> + * sync with the documentation of the CPU feature register API.
>
> s/API/ABI/
>
Sure, will make changes everywhere.
Thanks
Suzuki
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Arnd Bergmann @ 2016-11-30 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129221508.10551-1-grygorii.strashko@ti.com>
On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
> range->num_irqs++;
>
> - if (oirq.args_count == 3)
> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
> range->irqs[i].cpu_map =
> (oirq.args[2] & 0x0000ff00) >> 8;
>
I think you mean CONFIG_SMP, not SMP. With the change above, the
code will never be executed.
Arnd
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Siddhesh Poyarekar @ 2016-11-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1a361500-fc8e-b591-103e-3e3c9e0ba31d@arm.com>
On Wednesday 30 November 2016 05:00 PM, Suzuki K Poulose wrote:
>> This doesn't seem to be implemented in this patchset.
>
> This is already available upstream.
Ah OK, I seem to have missed that thread.
Thanks,
Siddhesh
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Catalin Marinas @ 2016-11-30 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2f9a241-8453-0b2c-25db-e603b89acf46@reserved-bit.com>
On Wed, Nov 30, 2016 at 04:44:52PM +0530, Siddhesh Poyarekar wrote:
> On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
> > + d) CPU Identification :
> > + MIDR_EL1 is exposed to help identify the processor. On a
> > + heterogeneous system, this could be racy (just like getcpu()). The
> > + process could be migrated to another CPU by the time it uses the
> > + register value, unless the CPU affinity is set. Hence, there is no
> > + guarantee that the value reflects the processor that it is
> > + currently executing on. The REVIDR is not exposed due to this
> > + constraint, as REVIDR makes sense only in conjunction with the
> > + MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
> > + at:
> > +
> > + /sys/devices/system/cpu/cpu$ID/regs/identification/
> > + \- midr
> > + \- revidr
> > +
>
> This doesn't seem to be implemented in this patchset.
No. However, we merged the functionality above already and forgot about
the documentation part, so we just clarify it now.
--
Catalin
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Suzuki K Poulose @ 2016-11-30 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e2f9a241-8453-0b2c-25db-e603b89acf46@reserved-bit.com>
On 30/11/16 11:14, Siddhesh Poyarekar wrote:
> On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
>> + d) CPU Identification :
>> + MIDR_EL1 is exposed to help identify the processor. On a
>> + heterogeneous system, this could be racy (just like getcpu()). The
>> + process could be migrated to another CPU by the time it uses the
>> + register value, unless the CPU affinity is set. Hence, there is no
>> + guarantee that the value reflects the processor that it is
>> + currently executing on. The REVIDR is not exposed due to this
>> + constraint, as REVIDR makes sense only in conjunction with the
>> + MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
>> + at:
>> +
>> + /sys/devices/system/cpu/cpu$ID/regs/identification/
>> + \- midr
>> + \- revidr
>> +
>
> This doesn't seem to be implemented in this patchset.
This is already available upstream.
Thanks
Suzuki
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH v4 00/10] IOMMU probe deferral support
From: Sricharan @ 2016-11-30 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90b1ad92-f7e6-b512-0676-90b96af10710@samsung.com>
Hi Marek,
>
>On 2016-11-30 01:22, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>> | |
>> pci_bus_add_device (device_add/driver_register)
>> | |
>> device_attach device_initial_probe
>> | |
>> __device_attach_driver __device_attach_driver
>> |
>> driver_probe_device
>> |
>> really_probe
>> |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> Tested with platform and pci devices for probe deferral
>> and reprobe on arm64 based platform. Added the patches [9,10],
>> drivers: acpi: Configure acpi devices dma operation at probe time
>> drivers: acpi: Handle IOMMU lookup failure with deferred probing or error
>> for doing the dma ops configuration at probe time for acpi based platform
>> as well. Did not have a acpi based platform to test the changes and with
>> my still catching up knowledge on acpi/enumeration those two patches needs
>> to be reviewed/tested more.
>
>I've checked this patchset on my development boards: Odroid U3
>(ARM/Exynos4412),
>XU3 (ARM/Exynos5422) and TM2 (ARM64/Exynos5433) and my queued patches
>for Exynos
>IOMMU driver [1]. Besides the issue with an excessive dev_info, which
>causes NULL
>pointer dereference (reported in reply to patch #6), it works fine on
>all those
>platforms! Please add (again) my:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>[1] https://www.spinics.net/lists/linux-samsung-soc/msg56354.html
>
>> Previous post of this series [5].
Thanks for the testing every time.
Regards,
Sricharan
>>
>> [V4]
>> * Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Added the patches for moving the dma ops configuration of
>> acpi based devices to probe time as well.
>> [V3]
>> * Removed the patch to split dma_masks/dma_ops configuration
>> separately based on review comments that both masks and ops are
>> required only during the device probe time.
>>
>> * Reworked the series based on Generic DT bindings series.
>>
>> * Added call to iommu's remove_device in the cleanup path for arm and
>> arm64.
>>
>> * Removed the notifier trick in arm64 to handle early device
>> registration.
>>
>> * Added reset of dma_ops in cleanup path for arm based on comments.
>>
>> * Fixed the pci_iommu_configure path and tested with PCI device as
>> well.
>>
>> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>> last post.
>>
>> * Fixed few other cosmetic comments.
>>
>> [V2]
>> * Updated the Initial post to call dma_configure/deconfigure from
>> generic code
>>
>> * Added iommu add_device callback from of_iommu_configure path
>>
>> [V1]
>> * Initial post from Laurent Pinchart [1]
>>
>> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
>> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
>> [3] https://lkml.org/lkml/2016/11/21/141
>> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
>> [5] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460832.html
>>
>> Laurent Pinchart (3):
>> of: dma: Move range size workaround to of_dma_get_range()
>> of: dma: Make of_dma_deconfigure() public
>> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>>
>> Robin Murphy (3):
>> iommu/of: Refactor of_iommu_configure() for error handling
>> iommu/of: Prepare for deferred IOMMU configuration
>> iommu/arm-smmu: Clean up early-probing workarounds
>>
>> Sricharan R (4):
>> drivers: platform: Configure dma operations at probe time
>> arm64: dma-mapping: Remove the notifier trick to handle early setting
>> of dma_ops
>> drivers: acpi: Configure acpi devices dma operation at probe time
>> drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>> error
>>
>> arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>> drivers/acpi/arm64/iort.c | 17 +++++-
>> drivers/acpi/glue.c | 6 --
>> drivers/acpi/scan.c | 7 ++-
>> drivers/base/dd.c | 10 ++++
>> drivers/base/dma-mapping.c | 32 +++++++++++
>> drivers/iommu/arm-smmu-v3.c | 35 +-----------
>> drivers/iommu/arm-smmu.c | 58 +++----------------
>> drivers/iommu/dma-iommu.c | 1 +
>> drivers/iommu/of_iommu.c | 114 +++++++++++++++++++++++++++-----------
>> drivers/of/address.c | 20 ++++++-
>> drivers/of/device.c | 36 ++++++------
>> drivers/of/platform.c | 10 +---
>> drivers/pci/probe.c | 17 +++---
>> include/acpi/acpi_bus.h | 2 +-
>> include/linux/acpi.h | 7 ++-
>> include/linux/dma-mapping.h | 3 +
>> include/linux/of_device.h | 10 +++-
>> include/linux/pci.h | 5 ++
>> 19 files changed, 238 insertions(+), 284 deletions(-)
>>
>
>Best regards
>--
>Marek Szyprowski, PhD
>Samsung R&D Institute Poland
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 06/10] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Sricharan @ 2016-11-30 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e91ce72-9d37-f4be-9224-856a1a4c3e1d@samsung.com>
Hi,
>Hi Sricharan and Robin,
>
>
>On 2016-11-30 01:22, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> [rm: massive PCI hacks]
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/base/dma-mapping.c | 4 ++--
>> drivers/iommu/dma-iommu.c | 1 +
>> drivers/iommu/of_iommu.c | 5 +++--
>> drivers/of/device.c | 9 +++++++--
>> drivers/pci/probe.c | 6 ++++--
>> include/linux/of_device.h | 9 ++++++---
>> include/linux/pci.h | 4 ++--
>> 7 files changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>> index b2a5629..576fdfb 100644
>> --- a/drivers/base/dma-mapping.c
>> +++ b/drivers/base/dma-mapping.c
>> @@ -351,9 +351,9 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
>> int dma_configure(struct device *dev)
>> {
>> if (dev_is_pci(dev))
>> - pci_dma_configure(dev);
>> + return pci_dma_configure(dev);
>> else if (dev->of_node)
>> - of_dma_configure(dev, dev->of_node);
>> + return of_dma_configure(dev, dev->of_node);
>> return 0;
>> }
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab866..d2a7a46 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -148,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> base_pfn = max_t(unsigned long, 1, base >> order);
>> end_pfn = (base + size - 1) >> order;
>>
>> + dev_info(dev, "0x%llx 0x%llx, 0x%llx 0x%llx, 0x%llx 0x%llx\n", base, size, domain->geometry.aperture_start, domain-
>>geometry.aperture_end,
>
>This causes a NULL pointer dereference if caller passes NULL device pointer.
>There is such caller in drivers/gpu/drm/exynos/exynos_drm_iommu.h.
>Trivial to fix as it looks like a leftover from developement or
>debugging stage.
>
My bad, i should have removed it before posting. Noticed this, but missed to remove it.
Will do so.
Regards,
Sricharan
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Siddhesh Poyarekar @ 2016-11-30 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479994809-9081-10-git-send-email-suzuki.poulose@arm.com>
On Thursday 24 November 2016 07:10 PM, Suzuki K Poulose wrote:
> + d) CPU Identification :
> + MIDR_EL1 is exposed to help identify the processor. On a
> + heterogeneous system, this could be racy (just like getcpu()). The
> + process could be migrated to another CPU by the time it uses the
> + register value, unless the CPU affinity is set. Hence, there is no
> + guarantee that the value reflects the processor that it is
> + currently executing on. The REVIDR is not exposed due to this
> + constraint, as REVIDR makes sense only in conjunction with the
> + MIDR. Alternately, MIDR_EL1 and REVIDR_EL1 are exposed via sysfs
> + at:
> +
> + /sys/devices/system/cpu/cpu$ID/regs/identification/
> + \- midr
> + \- revidr
> +
This doesn't seem to be implemented in this patchset.
Siddhesh
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Szabolcs Nagy @ 2016-11-30 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a35d1ae-73df-03a5-c9d6-1a52754acf25@redhat.com>
On 30/11/16 10:08, Florian Weimer wrote:
> On 11/25/2016 08:38 PM, Dave Martin wrote:
>> The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which
>> adds extra SIMD functionality and supports much larger vectors.
>>
>> This series implements core Linux support for SVE.
>>
>> Recipents not copied on the whole series can find the rest of the
>> patches in the linux-arm-kernel archives [2].
>>
>>
>> The first 5 patches "arm64: signal: ..." factor out the allocation and
>> placement of state information in the signal frame. The first three
>> are prerequisites for the SVE support patches.
>>
>> Patches 04-05 implement expansion of the signal frame, and may remain
>> controversial due to ABI break issues:
>>
>> * Discussion is needed on how userspace should detect/negotiate signal
>> frame size in order for this expansion mechanism to be workable.
>
> I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to
> disable really wide vector registers in case this causes problems with old binaries.
>
if the kernel does not increase the size and libc
does not add size checks then old binaries would
work with new libc just fine..
but that's non-conforming, posix requires the check.
if the kernel increases the size then it has to be
changed in bionic and musl as well and old binaries
may break.
> A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to
> its complexity.
>
>> The remaining patches implement initial SVE support for Linux, with the
>> following limitations:
>>
>> * No KVM/virtualisation support for guests.
>>
>> * No independent SVE vector length configuration per thread. This is
>> planned, but will follow as a separate add-on series.
>
> Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable
> functions/executors quite challenging.
>
i'd assume it's undefined to context switch to a different
thread or to resume a function on a different thread
(because the implementation can cache thread local state
on the stack: e.g. errno pointer).. of course this does
not stop ppl from doing it, but the practice is questionable.
> Can you detail your plans in this area?
>
> Thanks,
> Florian
^ permalink raw reply
* [PATCH v10 09/13] drm/mediatek: add mipi_tx data rate check
From: CK Hu @ 2016-11-30 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-10-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> modify data rate limitation (>lGbps/lane) for mipitx
>
I think MT2701 DRM can work correctly without this patch.
Why do you put this patch in MT2701 series?
Maybe you can send this patch independently.
Regards,
CK
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index fd84914..1ef00ac 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>
> dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>
> - if (mipi_tx->data_rate >= 500000000) {
> + if (mipi_tx->data_rate > 1250000000) {
> + return -EINVAL;
> + } else if (mipi_tx->data_rate >= 500000000) {
> txdiv = 1;
> txdiv0 = 0;
> txdiv1 = 0;
^ 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