RE: [v12, 0/8] Fix eSDHC host version register bug

2016-10-18 Thread Y.B. Lu
+ Greg Hi Greg, I submitted this patchset for a MMC bug fix, and introduce the below patch which needs your ACK. > > Arnd Bergmann (1): > > base: soc: introduce soc_device_match() interface https://patchwork.kernel.org/patch/9342913/ Could you help to review it and give some comments or ACK.

RE: [v12, 0/8] Fix eSDHC host version register bug

2016-10-18 Thread Y.B. Lu
> -Original Message- > From: Ulf Hansson [mailto:ulf.hans...@linaro.org] > Sent: Tuesday, October 18, 2016 6:48 PM > To: Y.B. Lu > Cc: linux-mmc; Scott Wood; Arnd Bergmann; linuxppc-...@lists.ozlabs.org; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- >

[PATCH v6 15/16] drivers: acpi: iort: add single mapping function

2016-10-18 Thread Lorenzo Pieralisi
The current IORT id mapping API requires components to provide an input requester ID (a Bus-Device-Function (BDF) identifier for PCI devices) to translate an input identifier to an output identifier through an IORT range mapping. Named components do not have an identifiable source ID therefore

[PATCH v6 13/16] drivers: iommu: arm-smmu: add IORT configuration

2016-10-18 Thread Lorenzo Pieralisi
In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU components. Add static configuration

[PATCH v6 14/16] drivers: acpi: iort: replace rid map type with type mask

2016-10-18 Thread Lorenzo Pieralisi
IORT tables provide data that allow the kernel to carry out device ID mappings between endpoints and system components (eg interrupt controllers, IOMMUs). When the mapping for a given device ID is carried out, the translation mechanism is done on a per-subsystem basis rather than a component

[PATCH v6 16/16] drivers: acpi: iort: introduce iort_iommu_configure

2016-10-18 Thread Lorenzo Pieralisi
DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the

[PATCH v6 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage

2016-10-18 Thread Lorenzo Pieralisi
Current ARM SMMU driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used also

[PATCH v6 11/16] drivers: iommu: arm-smmu-v3: add IORT configuration

2016-10-18 Thread Lorenzo Pieralisi
In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU v3 components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU v3 components. Add static

[PATCH v6 08/16] drivers: acpi: iort: add node match function

2016-10-18 Thread Lorenzo Pieralisi
Device drivers (eg ARM SMMU) need to know if a specific component is part of the IORT table, so that kernel data structures are not initialized at initcalls time if the respective component is not part of the IORT table. To this end, this patch adds a trivial function that allows detecting if a

[PATCH v6 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions

2016-10-18 Thread Lorenzo Pieralisi
Current ARM SMMU probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU driver features. In order to allow probing the ARM SMMU with other firmwares than DT, this patch splits the ARM SMMU init functions into DT and HW specific portions

[PATCH v6 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

2016-10-18 Thread Lorenzo Pieralisi
The of_iommu_{set/get}_ops() API is used to associate a device tree node with a specific set of IOMMU operations. The same kernel interface is required on systems booting with ACPI, where devices are not associated with a device tree node, therefore the interface requires generalization. The

[PATCH v6 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage

2016-10-18 Thread Lorenzo Pieralisi
Current ARM SMMU v3 driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used

[PATCH v6 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type

2016-10-18 Thread Lorenzo Pieralisi
On systems booting with a device tree, every struct device is associated with a struct device_node, that provides its DT firmware representation. The device node can be used in generic kernel contexts (eg IRQ translation, IOMMU streamid mapping), to retrieve the properties associated with the

[PATCH v6 10/16] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

2016-10-18 Thread Lorenzo Pieralisi
Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[PATCH v6 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration

2016-10-18 Thread Lorenzo Pieralisi
The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective fwnode.

[PATCH v6 07/16] drivers: acpi: implement acpi_dma_configure

2016-10-18 Thread Lorenzo Pieralisi
On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

[PATCH v6 00/16] ACPI IORT ARM SMMU support

2016-10-18 Thread Lorenzo Pieralisi
This patch series is v6 of a previous posting: https://lkml.org/lkml/2016/9/9/418 v5 -> v6 - Rebased against v4.9-rc1 - Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC - Moved platform devices creation into IORT code - Updated fwnode handling - Added default

[PATCH v6 09/16] drivers: acpi: iort: add support for ARM SMMU platform devices creation

2016-10-18 Thread Lorenzo Pieralisi
In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

[PATCH v6 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing

2016-10-18 Thread Lorenzo Pieralisi
Since commit e647b532275b ("ACPI: Add early device probing infrastructure") the kernel has gained the infrastructure that allows adding linker script section entries to execute ACPI driver callbacks (ie probe routines) for all subsystems that register a table entry in the respective kernel section

Re: [PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec

2016-10-18 Thread Yong Wu
On Mon, 2016-10-17 at 12:49 +0100, Robin Murphy wrote: > Our per-device data consists of the M4U instance and firmware-provided > list of LARB IDs, which is a perfect fit for the generic iommu_fwspec > machinery. Use that directly as a simpler alternative to the custom > archdata code. > > CC:

Re: [v12, 0/8] Fix eSDHC host version register bug

2016-10-18 Thread Ulf Hansson
On 21 September 2016 at 08:57, Yangbo Lu wrote: > This patchset is used to fix a host version register bug in the > T4240-R1.0-R2.0 > eSDHC controller. To match the SoC version and revision, 10 previous version > patchsets had tried many methods but all of them were rejected