Re: [PATCH 04/32] MAINTAINERS: update fsl,dpaa2-console.yaml reference
On 4/1/2021 3:17 PM, Mauro Carvalho Chehab wrote:
> Changeset 616fde2dd60f ("dt-bindings: misc: convert fsl,dpaa2-console from
> txt to YAML")
> renamed: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt
> to: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml.
>
> Update its cross-reference accordingly.
>
> Fixes: 616fde2dd60f ("dt-bindings: misc: convert fsl,dpaa2-console from txt
> to YAML")
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 53c66a6908b7..de9637196526 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7274,7 +7274,7 @@ M: Li Yang
> L: linuxppc-...@lists.ozlabs.org
> L: linux-arm-ker...@lists.infradead.org
> S: Maintained
> -F: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt
> +F: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml
> F: Documentation/devicetree/bindings/soc/fsl/
> F: drivers/soc/fsl/
> F: include/linux/fsl/
>
Re: [PATCH 0/3] bus: fsl-mc: minor updates
On 2/8/2021 7:09 PM, Ioana Ciornei wrote: > From: Ioana Ciornei > > This patch set adds a fix on the userspace support of the fsl-mc bus. > Other than that, a missing device type is added and some other commands > to the list of the accepted ones. > > Dan Carpenter (1): > bus: fsl-mc: Fix test for end of loop > > Ioana Ciornei (2): > bus: fsl-mc: add the dpdbg device type > bus: fsl-mc: list more commands as accepted through the ioctl > > drivers/bus/fsl-mc/fsl-mc-bus.c | 6 > drivers/bus/fsl-mc/fsl-mc-uapi.c | 52 +++- > 2 files changed, 57 insertions(+), 1 deletion(-) > For the series: Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu
Re: [PATCH 0/5] bus: fsl-mc: add userspace support
On 1/27/2021 4:02 PM, Greg KH wrote: > On Thu, Jan 14, 2021 at 07:07:47PM +0200, Ioana Ciornei wrote: >> From: Ioana Ciornei >> >> This patch set adds userspace support in the fsl-mc bus along with a >> rescan attribute to the root DPRC container. An earlier discussion on >> this functionality can be found at the link below. I didn't continue >> with the versioning scheme since quite some time has passed since the >> last discussion. >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F11%2F20%2F1162data=04%7C01%7Claurentiu.tudor%40nxp.com%7C8d74c7b04f864d17419508d8c2cc3e10%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637473529759283328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kDWLNqq91k5LW74jgZ%2Blu%2FZJfCmeLUZm5DccUiS4m94%3Dreserved=0 >> >> The FSL_MC_SEND_MC_COMMAND ioctl acts as a direct passthrough to the >> Management Complex (or MC) by passing fixed-length command/response >> pairs. Keeping in mind that the MC manages DPAA2 hardware resources and >> provides and object-based abstraction for sofware drivers, the proposed >> ioctl interface enables userspace tools to do the following: >> - Get layout information about the available resources abstracted and >>exported by the Management Complex firmware. This is especially >>useful to generate a complete description of the current hardware >>resource partitioning. >> - Manage DPAA2 objects lifecycle (create, destroy) and establish >>connection between different components as needed. >> >> The ioctl interface is intended for dynamic usecases where DPAA2 objects >> need to be created on demand or destroyed so that the underlying >> hardware resources can be further repurposed. In static usecases, >> depending on the requirements, a firmware configuration file can be used >> to describe the needed DPAA2 objects, their attributes or any link >> between them. >> >> Each command received through the ioctl interface is first checked >> against a list of accepted MC commands. Also, commands which would alter >> the hardware resource management require CAP_NET_ADMIN. The command is >> also check so that it does not contain garbage beyond the maximum size >> expected for that command id. > > I need an ack from the maintainers here before I can take this series. > Sorry, got caught with other things and forgot about it. Done. --- Thanks & Best Regards, Laurentiu
Re: [PATCH 0/5] bus: fsl-mc: add userspace support
On 1/14/2021 7:07 PM, Ioana Ciornei wrote: > From: Ioana Ciornei > > This patch set adds userspace support in the fsl-mc bus along with a > rescan attribute to the root DPRC container. An earlier discussion on > this functionality can be found at the link below. I didn't continue > with the versioning scheme since quite some time has passed since the > last discussion. > https://lkml.org/lkml/2018/11/20/1162 > > The FSL_MC_SEND_MC_COMMAND ioctl acts as a direct passthrough to the > Management Complex (or MC) by passing fixed-length command/response > pairs. Keeping in mind that the MC manages DPAA2 hardware resources and > provides and object-based abstraction for sofware drivers, the proposed > ioctl interface enables userspace tools to do the following: > - Get layout information about the available resources abstracted and >exported by the Management Complex firmware. This is especially >useful to generate a complete description of the current hardware >resource partitioning. > - Manage DPAA2 objects lifecycle (create, destroy) and establish >connection between different components as needed. > > The ioctl interface is intended for dynamic usecases where DPAA2 objects > need to be created on demand or destroyed so that the underlying > hardware resources can be further repurposed. In static usecases, > depending on the requirements, a firmware configuration file can be used > to describe the needed DPAA2 objects, their attributes or any link > between them. > > Each command received through the ioctl interface is first checked > against a list of accepted MC commands. Also, commands which would alter > the hardware resource management require CAP_NET_ADMIN. The command is > also check so that it does not contain garbage beyond the maximum size > expected for that command id. > > Ioana Ciornei (5): > bus: fsl-mc: move fsl_mc_command struct in a uapi header > bus: fsl-mc: export mc_cmd_hdr_read_cmdid() to the fsl-mc bus > bus: fsl-mc: add fsl-mc userspace support > bus: fsl-mc: add bus rescan attribute > bus: fsl-mc: add autorescan sysfs > > Documentation/ABI/stable/sysfs-bus-fsl-mc | 19 + > .../userspace-api/ioctl/ioctl-number.rst | 1 + > MAINTAINERS | 2 + > drivers/bus/fsl-mc/Kconfig| 7 + > drivers/bus/fsl-mc/Makefile | 3 + > drivers/bus/fsl-mc/dprc-driver.c | 33 +- > drivers/bus/fsl-mc/fsl-mc-bus.c | 96 +++ > drivers/bus/fsl-mc/fsl-mc-private.h | 49 ++ > drivers/bus/fsl-mc/fsl-mc-uapi.c | 547 ++ > drivers/bus/fsl-mc/mc-sys.c | 2 +- > include/linux/fsl/mc.h| 8 +- > include/uapi/linux/fsl_mc.h | 34 ++ > 12 files changed, 789 insertions(+), 12 deletions(-) > create mode 100644 Documentation/ABI/stable/sysfs-bus-fsl-mc > create mode 100644 drivers/bus/fsl-mc/fsl-mc-uapi.c > create mode 100644 include/uapi/linux/fsl_mc.h > For the series: Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu
[PATCH] bus: fsl-mc: add missing __iomem attribute
From: Laurentiu Tudor
This pointer to an i/o register block is missing the __iomem attribute,
so add it. The issue was found by 0-day sparse run.
Reported-by: kernel test robot
Signed-off-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index b8e6acdf932e..5a8fc68d6109 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -41,7 +41,7 @@ struct fsl_mc {
struct fsl_mc_device *root_mc_bus_dev;
u8 num_translation_ranges;
struct fsl_mc_addr_translation_range *translation_ranges;
- void *fsl_mc_regs;
+ void __iomem *fsl_mc_regs;
};
/**
--
2.17.1
Re: [PATCH] bus: fsl-mc: fix error return code in fsl_mc_object_allocate()
On 12/4/2020 10:02 AM, Zhang Changzhong wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 197f4d6a4a00 ("staging: fsl-mc: fsl-mc object allocator driver")
> Reported-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
Acked-by: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> drivers/bus/fsl-mc/fsl-mc-allocator.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-allocator.c
> b/drivers/bus/fsl-mc/fsl-mc-allocator.c
> index e71a6f5..2d7c764 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-allocator.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-allocator.c
> @@ -292,8 +292,10 @@ int __must_check fsl_mc_object_allocate(struct
> fsl_mc_device *mc_dev,
> goto error;
>
> mc_adev = resource->data;
> - if (!mc_adev)
> + if (!mc_adev) {
> + error = -EINVAL;
> goto error;
> + }
>
> mc_adev->consumer_link = device_link_add(_dev->dev,
>_adev->dev,
>
Re: [PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings
Hi Robin,
Sorry for the late reply, we had a few days of over here. Comments inline.
On 11/25/2020 8:10 PM, Robin Murphy wrote:
> On 2020-11-25 15:50, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> Add a NXP specific hook to preserve SMMU mappings present at
>> boot time (created by the boot loader). These are needed for
>> MC firmware present on some NXP chips to continue working
>> across kernel boot and SMMU initialization.
>>
>> Signed-off-by: Laurentiu Tudor
>> ---
>> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 33 ++
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
>> b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
>> index 7fed89c9d18a..ca07d9d4be69 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
>> @@ -187,6 +187,36 @@ static const struct arm_smmu_impl
>> mrvl_mmu500_impl = {
>> .reset = arm_mmu500_reset,
>> };
>> +static int nxp_cfg_probe(struct arm_smmu_device *smmu)
>> +{
>> + int i, cnt = 0;
>> + u32 smr;
>> +
>> + for (i = 0; i < smmu->num_mapping_groups; i++) {
>> + smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
>> +
>> + if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
>
> I bet this is fun over kexec...
Right. I haven't even considered kexec.
> Note that the Qualcomm special case got a bit of a free pass since it
> involves working around a totally broken hypervisor, plus gets to play
> the "nobody sane will run an enterprise distro on their phone" card to
> an extent; I don't think the likes of Layerscape kit get it quite so
> easy ;)
I agree that this is not ideal, but the plan here was to have something
to boot vanilla kernel OOB on our chips, which is something on my mind
for quite a while now. I do realize that we won't get away with it
in the long run.
>> + smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
>> + smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
>> + smmu->smrs[i].valid = true;
>> +
>> + smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
>> + smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
>> + smmu->s2crs[i].cbndx = 0xff;
>> +
>> + cnt++;
>> + }
>> + }
>> +
>> + dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt,
>> + cnt == 1 ? "" : "s");
>
> That gets you around the initial SMMU reset, but what happens for the
> arbitrarily long period of time between the MC device getting attached
> to a default domain and the MC driver actually probing and (presumably)
> being able to map and reinitialise its firmware?
Perhaps I'm missing something, but won't the MC firmware live based on
this bypass mapping created by the bootloader and that gets preserved?
>> +
>> + return 0;
>> +}
>> +
>> +static const struct arm_smmu_impl nxp_impl = {
>> + .cfg_probe = nxp_cfg_probe,
>> +};
>
> I believe you're mostly using MMU-500, so you probably don't want to
> simply throw out the relevant errata workarounds.
>
>> struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device
>> *smmu)
>> {
>> @@ -226,5 +256,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
>> arm_smmu_device *smmu)
>> if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
>> smmu->impl = _mmu500_impl;
>> + if (of_property_read_bool(np, "nxp,keep-boot-mappings"))
>> + smmu->impl = _impl;
>
> Normally you'd get a "what about ACPI?" here, but given the number of
> calls and email threads we've had specifically about trying to make ACPI
> support for these platforms work, that gets upgraded to at least a "WHAT
> ABOUT ACPI!?" :P
I do have ACPI in mind, but for now I just wanted to have a
first impression on the approach. One idea I was pondering on was to
have this property in the MC node (quick reminder: MC is exposed as a NC
in ACPI, should be able to replicate the property in there too). In the
mean time, we are in collaboration with our partners on using RMRR by
adding support for it in the arm-smmu-v2 driver.
> But seriously, the case of device firmware in memory being active before
> handover to Linux is *literally* the original reason behind IORT RMRs.
> We already know we need a way to specify the equivalent thing for DT
> systems, such that both can be handled commonly. I really don't want to
> have to support a vendor-specific mechanism for not-even-fully-solving a
> completely generic issue, sorry.
>
I remember that some months ago there was a proposal from nvidia [1] to
map per-device reserved memory into SMMU. Would it make sense to revive
it as it seemed a viable solution for our case too?
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=213701=%2A=both
---
Best Regards, Laurentiu
[PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings
From: Laurentiu Tudor
Add a NXP specific hook to preserve SMMU mappings present at
boot time (created by the boot loader). These are needed for
MC firmware present on some NXP chips to continue working
across kernel boot and SMMU initialization.
Signed-off-by: Laurentiu Tudor
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 33 ++
1 file changed, 33 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 7fed89c9d18a..ca07d9d4be69 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -187,6 +187,36 @@ static const struct arm_smmu_impl mrvl_mmu500_impl = {
.reset = arm_mmu500_reset,
};
+static int nxp_cfg_probe(struct arm_smmu_device *smmu)
+{
+ int i, cnt = 0;
+ u32 smr;
+
+ for (i = 0; i < smmu->num_mapping_groups; i++) {
+ smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
+
+ if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
+ smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
+ smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
+ smmu->smrs[i].valid = true;
+
+ smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
+ smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
+ smmu->s2crs[i].cbndx = 0xff;
+
+ cnt++;
+ }
+ }
+
+ dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt,
+ cnt == 1 ? "" : "s");
+
+ return 0;
+}
+
+static const struct arm_smmu_impl nxp_impl = {
+ .cfg_probe = nxp_cfg_probe,
+};
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
{
@@ -226,5 +256,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;
+ if (of_property_read_bool(np, "nxp,keep-boot-mappings"))
+ smmu->impl = _impl;
+
return smmu;
}
--
2.17.1
[PATCH] bus: fsl-mc: added missing fields to dprc_rsp_get_obj_region structure
From: Laurentiu Tudor
'type' and 'flags' fields were missing from dprc_rsp_get_obj_region
structure therefore the MC Bus driver was not receiving proper flags
from MC like DPRC_REGION_CACHEABLE.
Signed-off-by: Cristian Sovaiala
Signed-off-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/dprc.c | 2 ++
drivers/bus/fsl-mc/fsl-mc-private.h | 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
index 57b097caf255..27b0a01bad9b 100644
--- a/drivers/bus/fsl-mc/dprc.c
+++ b/drivers/bus/fsl-mc/dprc.c
@@ -576,6 +576,8 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
rsp_params = (struct dprc_rsp_get_obj_region *)cmd.params;
region_desc->base_offset = le64_to_cpu(rsp_params->base_offset);
region_desc->size = le32_to_cpu(rsp_params->size);
+ region_desc->type = rsp_params->type;
+ region_desc->flags = le32_to_cpu(rsp_params->flags);
if (dprc_major_ver > 6 || (dprc_major_ver == 6 && dprc_minor_ver >= 3))
region_desc->base_address = le64_to_cpu(rsp_params->base_addr);
else
diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h
b/drivers/bus/fsl-mc/fsl-mc-private.h
index 85ca5fdee581..c932387641fa 100644
--- a/drivers/bus/fsl-mc/fsl-mc-private.h
+++ b/drivers/bus/fsl-mc/fsl-mc-private.h
@@ -211,12 +211,13 @@ struct dprc_cmd_get_obj_region {
struct dprc_rsp_get_obj_region {
/* response word 0 */
- __le64 pad;
+ __le64 pad0;
/* response word 1 */
__le64 base_offset;
/* response word 2 */
__le32 size;
- __le32 pad2;
+ u8 type;
+ u8 pad2[3];
/* response word 3 */
__le32 flags;
__le32 pad3;
--
2.17.1
[PATCH v4] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- Changes in v4: - use $ref to point to fsl,qoriq-mc-dpmac binding Changes in v3: - dropped duplicated "fsl,qoriq-mc-dpmac" schema and replaced with reference to it - fixed a dt_binding_check warning Changes in v2: - fixed errors reported by yamllint - dropped multiple unnecessary quotes - used schema instead of text in description - added constraints on dpmac reg property .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 -- .../bindings/misc/fsl,qoriq-mc.yaml | 186 + .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 193 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a
[PATCH v3] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- Changes in v3: - dropped duplicated "fsl,qoriq-mc-dpmac" schema and replaced with reference to it - fixed a dt_binding_check warning Changes in v2: - fixed errors reported by yamllint - dropped multiple unnecessary quotes - used schema instead of text in description - added constraints on dpmac reg property .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 -- .../bindings/misc/fsl,qoriq-mc.yaml | 187 + .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 194 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a node named "dpmacs" which contains -the following
Re: [PATCH v2 2/2] dt-bindings: misc: convert fsl, qoriq-mc from txt to YAML
On 11/10/2020 7:20 PM, Rob Herring wrote:
> On Mon, Nov 9, 2020 at 4:11 PM Rob Herring wrote:
>>
>> On Mon, 09 Nov 2020 12:46:35 +0200, Laurentiu Tudor wrote:
>>> From: Ionut-robert Aron
>>>
>>> Convert fsl,qoriq-mc to YAML in order to automate the verification
>>> process of dts files. In addition, update MAINTAINERS accordingly
>>> and, while at it, add some missing files.
>>>
>>> Signed-off-by: Ionut-robert Aron
>>> [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema]
>>> Signed-off-by: Laurentiu Tudor
>>> ---
>>> Changes in v2:
>>> - fixed errors reported by yamllint
>>> - dropped multiple unnecessary quotes
>>> - used schema instead of text in description
>>> - added constraints on dpmac reg property
>>>
>>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196
>>> .../bindings/misc/fsl,qoriq-mc.yaml | 210 ++
>>> .../ethernet/freescale/dpaa2/overview.rst | 5 +-
>>> MAINTAINERS | 4 +-
>>> 4 files changed, 217 insertions(+), 198 deletions(-)
>>> delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>> create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
>>>
>>
>> Applied, thanks!
>
> And now dropped. This duplicates what's in commit 0dbcd4991719
> ("dt-bindings: net: add the DPAA2 MAC DTS definition") and has
> warnings from it:
>
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.example.dt.yaml:
> dpmac@1: $nodename:0: 'dpmac@1' does not match '^ethernet(@.*)?$'
> From schema:
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
>
My patch converts the .txt devicetree/bindings/misc/fsl,qoriq-mc.yaml
while the commit you mention creates
devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml, but at a first sight
there seems to be some duplication. Will sync internally with my
colleagues and return with a resolution. Thanks and sorry for the trouble.
---
Best Regards, Laurentiu
[PATCH v2 2/2] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- Changes in v2: - fixed errors reported by yamllint - dropped multiple unnecessary quotes - used schema instead of text in description - added constraints on dpmac reg property .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 .../bindings/misc/fsl,qoriq-mc.yaml | 210 ++ .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 217 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a node named "dpmacs" which contains -the following properties: - -- #address-cells - Value type: - Definition: Must be present if dpmac sub-nodes are defined and must -
[PATCH v2 1/2] dt-bindings: misc: convert fsl,dpaa2-console from txt to YAML
From: Ionut-robert Aron Convert fsl,dpaa2-console to YAML in order to automate the verification process of dts files. Signed-off-by: Ionut-robert Aron Signed-off-by: Laurentiu Tudor --- Changes in v2: - add missing additionalProperties .../bindings/misc/fsl,dpaa2-console.txt | 11 .../bindings/misc/fsl,dpaa2-console.yaml | 25 +++ 2 files changed, 25 insertions(+), 11 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt deleted file mode 100644 index 1442ba5d2d98.. --- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt +++ /dev/null @@ -1,11 +0,0 @@ -DPAA2 console support - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,dpaa2-console". -- reg -Value type: -Definition: A standard property. Specifies the region where the MCFBA -(MC firmware base address) register can be found. diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml new file mode 100644 index ..271a3eafc054 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml @@ -0,0 +1,25 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/fsl,dpaa2-console.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 console support + +maintainers: + - Laurentiu Tudor + +properties: + compatible: +const: "fsl,dpaa2-console" + + reg: +description: A standard property. Specifies the region where the MCFBA +(MC firmware base address) register can be found. + +required: + - compatible + - reg + +additionalProperties: false -- 2.17.1
Re: [PATCH 2/2] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
Hi Rob, On 11/5/2020 9:17 PM, Rob Herring wrote: > On Thu, Nov 05, 2020 at 04:11:14PM +0200, Laurentiu Tudor wrote: >> From: Ionut-robert Aron >> >> Convert fsl,qoriq-mc to YAML in order to automate the verification >> process of dts files. In addition, update MAINTAINERS accordingly >> and, while at it, add some missing files. >> >> Signed-off-by: Ionut-robert Aron >> [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] >> Signed-off-by: Laurentiu Tudor >> --- >> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 >> .../bindings/misc/fsl,qoriq-mc.yaml | 218 ++ >> .../ethernet/freescale/dpaa2/overview.rst | 5 +- >> MAINTAINERS | 4 +- >> 4 files changed, 225 insertions(+), 198 deletions(-) >> delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt >> create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml > > [...] > >> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml >> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml >> new file mode 100644 >> index ..9e89fd8eb635 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml >> @@ -0,0 +1,218 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +# Copyright 2020 NXP >> +%YAML 1.2 >> +--- >> +$id: >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fmisc%2Ffsl%2Cqoriq-mc.yaml%23data=04%7C01%7Claurentiu.tudor%40nxp.com%7C64a5aeb6fee5459041db08d881bf7bf2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637402006701140599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fkXEIYUqXK1Dn6AqZtYLzro8nwJNCPJFI1Q9F9fRYxE%3Dreserved=0 >> +$schema: >> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23data=04%7C01%7Claurentiu.tudor%40nxp.com%7C64a5aeb6fee5459041db08d881bf7bf2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637402006701140599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X7k0Sxh7uPo11GgkGCeaKKMzHdu0gtphKheyJeROZ9Q%3Dreserved=0 >> + >> +maintainers: >> + - Laurentiu Tudor >> + >> +title: Freescale Management Complex >> + >> +description: | >> + The Freescale Management Complex (fsl-mc) is a hardware resource >> + manager that manages specialized hardware objects used in >> + network-oriented packet processing applications. After the fsl-mc >> + block is enabled, pools of hardware resources are available, such as >> + queues, buffer pools, I/O interfaces. These resources are building >> + blocks that can be used to create functional hardware objects/devices >> + such as network interfaces, crypto accelerator instances, L2 switches, >> + etc. >> + >> + For an overview of the DPAA2 architecture and fsl-mc bus see: >> + Documentation/networking/device_drivers/freescale/dpaa2/overview.rst >> + >> + As described in the above overview, all DPAA2 objects in a DPRC share the >> + same hardware "isolation context" and a 10-bit value called an ICID >> + (isolation context id) is expressed by the hardware to identify >> + the requester. >> + >> + The generic 'iommus' property is insufficient to describe the relationship >> + between ICIDs and IOMMUs, so an iommu-map property is used to define >> + the set of possible ICIDs under a root DPRC and how they map to >> + an IOMMU. >> + >> + For generic IOMMU bindings, see: >> + Documentation/devicetree/bindings/iommu/iommu.txt. >> + >> + For arm-smmu binding, see: >> + Documentation/devicetree/bindings/iommu/arm,smmu.yaml. >> + >> + MC firmware binary images can be found here: >> + >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fqoriq-mc-binarydata=04%7C01%7Claurentiu.tudor%40nxp.com%7C64a5aeb6fee5459041db08d881bf7bf2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637402006701140599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QKyEydXdS2AzqS7BlXVXDXpdjHfGL1%2BEdx95F1j5OHM%3Dreserved=0 >> + >> +properties: >> + compatible: >> +const: "fsl,qoriq-mc" > > Don't need quotes. > >> +description: "Must be 'fsl,qoriq-mc'. A Freescale Management Complex > > Drop > > The schema says that. > >> +
[PATCH 2/2] bus: fsl-mc: make sure MC firmware is up and running
Some bootloaders might pause the MC firmware before starting the
kernel to ensure that MC will not cause faults as soon as SMMU
probes due to no configuration being in place for the firmware.
Make sure that MC is resumed at probe time as its SMMU setup should
be done by now.
Also included, a comment fix on how PL and BMT bits are packed in
the StreamID.
Signed-off-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 42 +++--
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 806766b1b45f..b8e6acdf932e 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -60,6 +60,9 @@ struct fsl_mc_addr_translation_range {
phys_addr_t start_phys_addr;
};
+#define FSL_MC_GCR10x0
+#define GCR1_P1_STOP BIT(31)
+
#define FSL_MC_FAPR0x28
#define MC_FAPR_PL BIT(18)
#define MC_FAPR_BMTBIT(17)
@@ -973,21 +976,36 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
return PTR_ERR(mc->fsl_mc_regs);
}
- if (mc->fsl_mc_regs && IS_ENABLED(CONFIG_ACPI) &&
- !dev_of_node(>dev)) {
- mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
+ if (mc->fsl_mc_regs) {
/*
-* HW ORs the PL and BMT bit, places the result in bit 15 of
-* the StreamID and ORs in the ICID. Calculate it accordingly.
+* Some bootloaders pause the MC firmware before booting the
+* kernel so that MC will not cause faults as soon as the
+* SMMU probes due to the fact that there's no configuration
+* in place for MC.
+* At this point MC should have all its SMMU setup done so make
+* sure it is resumed.
*/
- mc_stream_id = (mc_stream_id & 0x) |
+ writel(readl(mc->fsl_mc_regs + FSL_MC_GCR1) & (~GCR1_P1_STOP),
+ mc->fsl_mc_regs + FSL_MC_GCR1);
+
+ if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(>dev)) {
+ mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
+ /*
+* HW ORs the PL and BMT bit, places the result in bit
+* 14 of the StreamID and ORs in the ICID. Calculate it
+* accordingly.
+*/
+ mc_stream_id = (mc_stream_id & 0x) |
((mc_stream_id & (MC_FAPR_PL | MC_FAPR_BMT)) ?
- 0x4000 : 0);
- error = acpi_dma_configure_id(>dev, DEV_DMA_COHERENT,
- _stream_id);
- if (error)
- dev_warn(>dev, "failed to configure dma: %d.\n",
-error);
+ BIT(14) : 0);
+ error = acpi_dma_configure_id(>dev,
+ DEV_DMA_COHERENT,
+ _stream_id);
+ if (error)
+ dev_warn(>dev,
+"failed to configure dma: %d.\n",
+error);
+ }
}
/*
--
2.17.1
[PATCH 1/2] bus: fsl-mc: add back accidentally dropped error check
A previous patch accidentally dropped an error check, so add it back.
Fixes: aef85b56c3c1 ("bus: fsl-mc: MC control registers are not always
available")
Signed-off-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 76a6ee505d33..806766b1b45f 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -967,8 +967,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mc);
plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (plat_res)
+ if (plat_res) {
mc->fsl_mc_regs = devm_ioremap_resource(>dev, plat_res);
+ if (IS_ERR(mc->fsl_mc_regs))
+ return PTR_ERR(mc->fsl_mc_regs);
+ }
if (mc->fsl_mc_regs && IS_ENABLED(CONFIG_ACPI) &&
!dev_of_node(>dev)) {
--
2.17.1
[PATCH 1/2] dt-bindings: misc: convert fsl,dpaa2-console from txt to YAML
From: Ionut-robert Aron Convert fsl,dpaa2-console to YAML in order to automate the verification process of dts files. Signed-off-by: Ionut-robert Aron Signed-off-by: Laurentiu Tudor --- .../bindings/misc/fsl,dpaa2-console.txt | 11 - .../bindings/misc/fsl,dpaa2-console.yaml | 23 +++ 2 files changed, 23 insertions(+), 11 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt deleted file mode 100644 index 1442ba5d2d98.. --- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt +++ /dev/null @@ -1,11 +0,0 @@ -DPAA2 console support - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,dpaa2-console". -- reg -Value type: -Definition: A standard property. Specifies the region where the MCFBA -(MC firmware base address) register can be found. diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml new file mode 100644 index ..9ffb864d8b58 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml @@ -0,0 +1,23 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/fsl,dpaa2-console.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 console support + +maintainers: + - Laurentiu Tudor + +properties: + compatible: +const: "fsl,dpaa2-console" + + reg: +description: A standard property. Specifies the region where the MCFBA +(MC firmware base address) register can be found. + +required: + - compatible + - reg -- 2.17.1
[PATCH 2/2] dt-bindings: misc: convert fsl,qoriq-mc from txt to YAML
From: Ionut-robert Aron Convert fsl,qoriq-mc to YAML in order to automate the verification process of dts files. In addition, update MAINTAINERS accordingly and, while at it, add some missing files. Signed-off-by: Ionut-robert Aron [laurentiu.tu...@nxp.com: update MINTAINERS, updates & fixes in schema] Signed-off-by: Laurentiu Tudor --- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 196 .../bindings/misc/fsl,qoriq-mc.yaml | 218 ++ .../ethernet/freescale/dpaa2/overview.rst | 5 +- MAINTAINERS | 4 +- 4 files changed, 225 insertions(+), 198 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt deleted file mode 100644 index 7b486d4985dc.. --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ /dev/null @@ -1,196 +0,0 @@ -* Freescale Management Complex - -The Freescale Management Complex (fsl-mc) is a hardware resource -manager that manages specialized hardware objects used in -network-oriented packet processing applications. After the fsl-mc -block is enabled, pools of hardware resources are available, such as -queues, buffer pools, I/O interfaces. These resources are building -blocks that can be used to create functional hardware objects/devices -such as network interfaces, crypto accelerator instances, L2 switches, -etc. - -For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst - -As described in the above overview, all DPAA2 objects in a DPRC share the -same hardware "isolation context" and a 10-bit value called an ICID -(isolation context id) is expressed by the hardware to identify -the requester. - -The generic 'iommus' property is insufficient to describe the relationship -between ICIDs and IOMMUs, so an iommu-map property is used to define -the set of possible ICIDs under a root DPRC and how they map to -an IOMMU. - -For generic IOMMU bindings, see -Documentation/devicetree/bindings/iommu/iommu.txt. - -For arm-smmu binding, see: -Documentation/devicetree/bindings/iommu/arm,smmu.yaml. - -The MSI writes are accompanied by sideband data which is derived from the ICID. -The msi-map property is used to associate the devices with both the ITS -controller and the sideband data which accompanies the writes. - -For generic MSI bindings, see -Documentation/devicetree/bindings/interrupt-controller/msi.txt. - -For GICv3 and GIC ITS bindings, see: -Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml. - -Required properties: - -- compatible -Value type: -Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex -compatible with this binding must have Block Revision -Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in -the MC control register region. - -- reg -Value type: -Definition: A standard property. Specifies one or two regions -defining the MC's registers: - - -the first region is the command portal for the -this machine and must always be present - - -the second region is the MC control registers. This -region may not be present in some scenarios, such -as in the device tree presented to a virtual machine. - -- ranges -Value type: -Definition: A standard property. Defines the mapping between the child -MC address space and the parent system address space. - -The MC address space is defined by 3 components: - - -Valid values for region type are - 0x0 - MC portals - 0x1 - QBMAN portals - -- #address-cells -Value type: -Definition: Must be 3. (see definition in 'ranges' property) - -- #size-cells -Value type: -Definition: Must be 1. - -Sub-nodes: - -The fsl-mc node may optionally have dpmac sub-nodes that describe -the relationship between the Ethernet MACs which belong to the MC -and the Ethernet PHYs on the system board. - -The dpmac nodes must be under a node named "dpmacs" which contains -the following properties: - -- #address-cells - Value type: - Definition: Must be present if dpmac sub-nodes are defined and must - have a value of 1. - -- #size-cells - Value type: - Definition: Must be present if dpmac sub-nodes are defined and mu
Re: [PATCH] soc: fsl: dpio: Change 'cpumask_t mask' to global variable
Hi,
Thanks for finding this. Comment inline.
On 10/14/2020 10:27 AM, Yi Wang wrote:
> From: Hao Si
>
> The local variable 'cpumask_t mask' is in the stack memory, and its address
> is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> But the memory area where this variable is located is at risk of being
> modified.
>
> During LTP testing, the following error was generated:
>
> Unable to handle kernel paging request at virtual address 12e9b790
> Mem abort info:
> ESR = 0x9607
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x0007
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp = 75ac5e07
> [12e9b790] pgd=0027dbffe003, pud=0027dbffd003,
> pmd=0027b6d61003, pte=
> Internal error: Oops: 9607 [#1] PREEMPT SMP
> Modules linked in: xt_conntrack
> Process read_all (pid: 20171, stack limit = 0x44ea4095)
> CPU: 14 PID: 20171 Comm: read_all Tainted: GB W
> Hardware name: NXP Layerscape LX2160ARDB (DT)
> pstate: 8085 (Nzcv daIf -PAN -UAO)
> pc : irq_affinity_hint_proc_show+0x54/0xb0
> lr : irq_affinity_hint_proc_show+0x4c/0xb0
> sp : 1138bc10
> x29: 1138bc10 x28: d131d1e0
> x27: 007000c0 x26: 8025b9480dc0
> x25: 8025b9480da8 x24: 03ff
> x23: 8027334f8300 x22: 80272e97d000
> x21: 80272e97d0b0 x20: 8025b9480d80
> x19: 09a49000 x18:
> x17: x16:
> x15: x14:
> x13: x12: 0040
> x11: x10: 802735b79b88
> x9 : x8 :
> x7 : 09a49848 x6 : 0003
> x5 : x4 : 08157d6c
> x3 : 1138bc10 x2 : 12e9b790
> x1 : x0 :
> Call trace:
> irq_affinity_hint_proc_show+0x54/0xb0
> seq_read+0x1b0/0x440
> proc_reg_read+0x80/0xd8
> __vfs_read+0x60/0x178
> vfs_read+0x94/0x150
> ksys_read+0x74/0xf0
> __arm64_sys_read+0x24/0x30
> el0_svc_common.constprop.0+0xd8/0x1a0
> el0_svc_handler+0x34/0x88
> el0_svc+0x10/0x14
> Code: f9001bbf 943e0732 f94066c2 b462 (f9400041)
> ---[ end trace b495bdcb0b3b732b ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
> Kernel Offset: disabled
> CPU features: 0x0,21006008
> Memory Limit: none
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Fix it by changing 'cpumask_t mask' to global variable.
>
> Signed-off-by: Hao Si
> Signed-off-by: Lin Chen
> Signed-off-by: Yi Wang
> ---
> drivers/soc/fsl/dpio/dpio-driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c
> b/drivers/soc/fsl/dpio/dpio-driver.c
> index 7b642c3..b31ec53 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -31,6 +31,7 @@ struct dpio_priv {
> struct dpaa2_io *io;
> };
>
> +static cpumask_t mask;
There can be multiple dpio devices with their associated driver
instances so it's not ok to make the variable global. Please place it in
the driver's private data and while at it, please rename it to cpu_mask.
---
Thanks & Best Regards, Laurentiu
Re: [PATCH v5 00/13] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support
Hi Greg, On 10/2/2020 4:55 PM, Greg KH wrote: > On Tue, Sep 29, 2020 at 02:06:41PM +0300, Laurentiu Tudor wrote: >> >> >> On 9/29/2020 11:54 AM, Diana Craciun wrote: >>> The vfio-mc bus driver needs some additional services to be exported by the >>> mc-bus driver like: >>> - a way to reset the DPRC container >>> - driver_override support >>> - functions to setup/tear down a DPRC >>> - functions for allocating the pool of interrupts. In case of VFIO the >>> interrupts are not configured at probe time, but later by userspace >>> request >>> >>> v4 -> v5 >>> - dprc_celanup should not fail >>> >>> v3 -> v4 >>> - Rebased on the latest kernel. >>> - Exported a dprc_remove function >>> >>> v2 -> v3 >>> - Add a new version for dprc_get_obj_region >>> - Export the cacheability bus specific bits defines >>> >>> v1 -> v2 >>> - Remove driver_override propagation through various functions >>> - Cache the DPRC API version >>> >>> The patches are related with "vfio/fsl-mc: VFIO support for FSL-MC >>> devices" patches, but the series were split because they are targeting >>> different subsystems. However, the mc-bus patches may suffer changes >>> when addressing the VFIO review comments. >>> >>> The patches do not address the comment regarding moving driver_override >>> in the core code. I prefer not to tie these patches on that change and >>> address that separately. >>> >>> Bharat Bhushan (3): >>> bus/fsl-mc: add support for 'driver_override' in the mc-bus >>> bus/fsl-mc: Add dprc-reset-container support >>> bus/fsl-mc: Extend ICID size from 16bit to 32bit >>> >>> Diana Craciun (10): >>> bus/fsl-mc: Do no longer export the total number of irqs outside >>> dprc_scan_objects >>> bus/fsl-mc: Add a new parameter to dprc_scan_objects function >>> bus/fsl-mc: Set the QMAN/BMAN region flags >>> bus/fsl-mc: Cache the DPRC API version >>> bus/fsl-mc: Export dprc_scan/dprc_remove functions to be used by >>> multiple entities >>> bus/fsl-mc: Export a cleanup function for DPRC >>> bus/fsl-mc: Add a container setup function >>> bus/fsl_mc: Do not rely on caller to provide non NULL mc_io >>> bus/fsl-mc: Export IRQ pool handling functions to be used by VFIO >>> bus/fsl-mc: Add a new version for dprc_get_obj_region command >>> >>> drivers/bus/fsl-mc/dprc-driver.c | 190 -- >>> drivers/bus/fsl-mc/dprc.c | 141 +++ >>> drivers/bus/fsl-mc/fsl-mc-allocator.c | 12 +- >>> drivers/bus/fsl-mc/fsl-mc-bus.c | 64 - >>> drivers/bus/fsl-mc/fsl-mc-private.h | 31 ++--- >>> drivers/bus/fsl-mc/mc-io.c| 7 +- >>> include/linux/fsl/mc.h| 41 +- >>> 7 files changed, 359 insertions(+), 127 deletions(-) >>> >> >> For the series: >> Reviewed-by: Laurentiu Tudor >> Acked-by: Laurentiu Tudor > > Do you want me to take these patches in my tree, or are they going to > Linus some other way? I'm prefectly fine with you picking up the patches through your tree. --- Thanks & Best Regards, Laurentiu
Re: [PATCH v5 00/13] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support
On 9/29/2020 11:54 AM, Diana Craciun wrote: > The vfio-mc bus driver needs some additional services to be exported by the > mc-bus driver like: > - a way to reset the DPRC container > - driver_override support > - functions to setup/tear down a DPRC > - functions for allocating the pool of interrupts. In case of VFIO the > interrupts are not configured at probe time, but later by userspace > request > > v4 -> v5 > - dprc_celanup should not fail > > v3 -> v4 > - Rebased on the latest kernel. > - Exported a dprc_remove function > > v2 -> v3 > - Add a new version for dprc_get_obj_region > - Export the cacheability bus specific bits defines > > v1 -> v2 > - Remove driver_override propagation through various functions > - Cache the DPRC API version > > The patches are related with "vfio/fsl-mc: VFIO support for FSL-MC > devices" patches, but the series were split because they are targeting > different subsystems. However, the mc-bus patches may suffer changes > when addressing the VFIO review comments. > > The patches do not address the comment regarding moving driver_override > in the core code. I prefer not to tie these patches on that change and > address that separately. > > Bharat Bhushan (3): > bus/fsl-mc: add support for 'driver_override' in the mc-bus > bus/fsl-mc: Add dprc-reset-container support > bus/fsl-mc: Extend ICID size from 16bit to 32bit > > Diana Craciun (10): > bus/fsl-mc: Do no longer export the total number of irqs outside > dprc_scan_objects > bus/fsl-mc: Add a new parameter to dprc_scan_objects function > bus/fsl-mc: Set the QMAN/BMAN region flags > bus/fsl-mc: Cache the DPRC API version > bus/fsl-mc: Export dprc_scan/dprc_remove functions to be used by > multiple entities > bus/fsl-mc: Export a cleanup function for DPRC > bus/fsl-mc: Add a container setup function > bus/fsl_mc: Do not rely on caller to provide non NULL mc_io > bus/fsl-mc: Export IRQ pool handling functions to be used by VFIO > bus/fsl-mc: Add a new version for dprc_get_obj_region command > > drivers/bus/fsl-mc/dprc-driver.c | 190 -- > drivers/bus/fsl-mc/dprc.c | 141 +++ > drivers/bus/fsl-mc/fsl-mc-allocator.c | 12 +- > drivers/bus/fsl-mc/fsl-mc-bus.c | 64 - > drivers/bus/fsl-mc/fsl-mc-private.h | 31 ++--- > drivers/bus/fsl-mc/mc-io.c | 7 +- > include/linux/fsl/mc.h| 41 +- > 7 files changed, 359 insertions(+), 127 deletions(-) > For the series: Reviewed-by: Laurentiu Tudor Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu
[PATCH v2 2/2] bus: fsl-mc: MC control registers are not always available
As per the device tree binding, in certain scenarios such as
virtualization scenarios, the MC control registers are not
available so don't error out if they are not present.
Signed-off-by: Laurentiu Tudor
---
Changes in v2:
- dropped useless NULL check
- restore IS_ERR() usage
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index b0449df117e8..b4177eccbf50 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -916,10 +916,9 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
mc->fsl_mc_regs = devm_ioremap_resource(>dev, plat_res);
- if (IS_ERR(mc->fsl_mc_regs))
- return PTR_ERR(mc->fsl_mc_regs);
- if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(>dev)) {
+ if (!IS_ERR(mc->fsl_mc_regs) && IS_ENABLED(CONFIG_ACPI) &&
+ !dev_of_node(>dev)) {
mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
/*
* HW ORs the PL and BMT bit, places the result in bit 15 of
--
2.17.1
[PATCH v2 1/2] bus: fsl-mc: don't assume an iommu is always present
There are certain scenarios where an iommu is not present, e.g. booting in a VM. Let's support these scenarios by dropping the check. Signed-off-by: Laurentiu Tudor --- Changes in v2: - none drivers/bus/fsl-mc/fsl-mc-bus.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index b69794e7364d..b0449df117e8 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -908,9 +908,6 @@ static int fsl_mc_bus_probe(struct platform_device *pdev) u32 mc_portal_size, mc_stream_id; struct resource *plat_res; - if (!iommu_present(_mc_bus_type)) - return -EPROBE_DEFER; - mc = devm_kzalloc(>dev, sizeof(*mc), GFP_KERNEL); if (!mc) return -ENOMEM; -- 2.17.1
Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings
On 9/4/2020 6:55 PM, Bjorn Andersson wrote:
> Based on previous attempts and discussions this is the latest attempt at
> inheriting stream mappings set up by the bootloader, for e.g. boot splash or
> efifb.
>
> Per Will's request this builds on the work by Jordan and Rob for the Adreno
> SMMU support. It applies cleanly ontop of v16 of their series, which can be
> found at
> https://lore.kernel.org/linux-arm-msm/20200901164707.2645413-1-robdcl...@gmail.com/
>
> Bjorn Andersson (8):
> iommu/arm-smmu: Refactor context bank allocation
> iommu/arm-smmu: Delay modifying domain during init
> iommu/arm-smmu: Consult context bank allocator for identify domains
> iommu/arm-smmu-qcom: Emulate bypass by using context banks
> iommu/arm-smmu-qcom: Consistently initialize stream mappings
> iommu/arm-smmu: Add impl hook for inherit boot mappings
> iommu/arm-smmu: Provide helper for allocating identity domain
> iommu/arm-smmu-qcom: Setup identity domain for boot mappings
>
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 111 ++-
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 122 ++---
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 14 ++-
> 3 files changed, 205 insertions(+), 42 deletions(-)
>
Tested on a NXP LX2160A with John's tree [1] and below diff [2], so for
the whole series:
Tested-by: Laurentiu Tudor
[1]
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/db845c-mainline-WIP
[2]
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -190,11 +190,43 @@ static const struct arm_smmu_impl mrvl_mmu500_impl = {
.reset = arm_mmu500_reset,
};
+static int nxp_smmu_inherit_mappings(struct arm_smmu_device *smmu)
+{
+ u32 smr;
+ int i, cnt = 0;
+
+ for (i = 0; i < smmu->num_mapping_groups; i++) {
+ smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
+
+ if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
+ smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
+ smmu->smrs[i].mask =
FIELD_GET(ARM_SMMU_SMR_MASK, smr);
+ smmu->smrs[i].valid = true;
+
+ smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
+ smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
+ smmu->s2crs[i].count++;
+
+ cnt++;
+ }
+ }
+
+ dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt,
+ cnt == 1 ? "" : "s");
+
+ return 0;
+}
+
+static const struct arm_smmu_impl nxp_impl = {
+ .inherit_mappings = nxp_smmu_inherit_mappings,
+};
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
{
const struct device_node *np = smmu->dev->of_node;
/*
* Set the impl for model-specific implementation quirks first,
* such that platform integration quirks can pick it up and
@@ -229,5 +261,12 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;
+ if (of_property_read_bool(np, "nxp,keep-bypass-mappings"))
+ smmu->impl = _impl;
---
Best Regards, Laurentiu
[PATCH 1/2] bus: fsl-mc: don't assume an iommu is always present
There are certain scenarios where an iommu is not present, e.g. booting in a VM. Let's support these scenarios by dropping the check. Signed-off-by: Laurentiu Tudor --- drivers/bus/fsl-mc/fsl-mc-bus.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c index b69794e7364d..b0449df117e8 100644 --- a/drivers/bus/fsl-mc/fsl-mc-bus.c +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c @@ -908,9 +908,6 @@ static int fsl_mc_bus_probe(struct platform_device *pdev) u32 mc_portal_size, mc_stream_id; struct resource *plat_res; - if (!iommu_present(_mc_bus_type)) - return -EPROBE_DEFER; - mc = devm_kzalloc(>dev, sizeof(*mc), GFP_KERNEL); if (!mc) return -ENOMEM; -- 2.17.1
[PATCH 2/2] bus: fsl-mc: MC control registers are not always available
As per the device tree binding, in certain scenarios such as
virtualization scenarios, the MC control registers are not
available so don't error out if they are not present.
Signed-off-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index b0449df117e8..7345ecef93f8 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -915,11 +915,11 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mc);
plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- mc->fsl_mc_regs = devm_ioremap_resource(>dev, plat_res);
- if (IS_ERR(mc->fsl_mc_regs))
- return PTR_ERR(mc->fsl_mc_regs);
+ if (plat_res)
+ mc->fsl_mc_regs = devm_ioremap_resource(>dev, plat_res);
- if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(>dev)) {
+ if (mc->fsl_mc_regs && IS_ENABLED(CONFIG_ACPI) &&
+ !dev_of_node(>dev)) {
mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR);
/*
* HW ORs the PL and BMT bit, places the result in bit 15 of
--
2.17.1
Re: [PATCH v4 00/13] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support
On 8/26/2020 12:25 PM, Diana Craciun wrote: > The vfio-mc bus driver needs some additional services to be exported by the > mc-bus driver like: > - a way to reset the DPRC container > - driver_override support > - functions to setup/tear down a DPRC > - functions for allocating the pool of interrupts. In case of VFIO the > interrupts are not configured at probe time, but later by userspace > request > > v3 -> v4 > - Rebased on the latest kernel. > - Exported a dprc_remove function > > v2 -> v3 > - Add a new version for dprc_get_obj_region > - Export the cacheability bus specific bits defines > > v1 -> v2 > - Remove driver_override propagation through various functions > - Cache the DPRC API version > > The patches are related with "vfio/fsl-mc: VFIO support for FSL-MC > devices" patches, but the series were split because they are targeting > different subsystems. However, the mc-bus patches may suffer changes > when addressing the VFIO review comments. > > The patches do not address the comment regarding moving driver_override > in the core code. I prefer not to tie these patches on that change and > address that separately. > > Bharat Bhushan (3): > bus/fsl-mc: add support for 'driver_override' in the mc-bus > bus/fsl-mc: Add dprc-reset-container support > bus/fsl-mc: Extend ICID size from 16bit to 32bit > > Diana Craciun (10): > bus/fsl-mc: Do no longer export the total number of irqs outside > dprc_scan_objects > bus/fsl-mc: Add a new parameter to dprc_scan_objects function > bus/fsl-mc: Set the QMAN/BMAN region flags > bus/fsl-mc: Cache the DPRC API version > bus/fsl-mc: Export dprc_scan/dprc_remove functions to be used by > multiple entities > bus/fsl-mc: Export a cleanup function for DPRC > bus/fsl-mc: Add a container setup function > bus/fsl_mc: Do not rely on caller to provide non NULL mc_io > bus/fsl-mc: Export IRQ pool handling functions to be used by VFIO > bus/fsl-mc: Add a new version for dprc_get_obj_region command > > drivers/bus/fsl-mc/dprc-driver.c | 175 -- > drivers/bus/fsl-mc/dprc.c | 141 + > drivers/bus/fsl-mc/fsl-mc-allocator.c | 12 +- > drivers/bus/fsl-mc/fsl-mc-bus.c | 64 +- > drivers/bus/fsl-mc/fsl-mc-private.h | 31 ++--- > drivers/bus/fsl-mc/mc-io.c | 7 +- > include/linux/fsl/mc.h| 41 +- > 7 files changed, 349 insertions(+), 122 deletions(-) > For the series: Reviewed-by: Laurentiu Tudor Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu
Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings
Hi Bjorn, On 9/4/2020 6:55 PM, Bjorn Andersson wrote: > Based on previous attempts and discussions this is the latest attempt at > inheriting stream mappings set up by the bootloader, for e.g. boot splash or > efifb. > > Per Will's request this builds on the work by Jordan and Rob for the Adreno > SMMU support. It applies cleanly ontop of v16 of their series, which can be > found at > https://lore.kernel.org/linux-arm-msm/20200901164707.2645413-1-robdcl...@gmail.com/ Is there a git repo available with all the patches put together? --- Thanks & Best Regards, Laurentiu
[PATCH] bus: fsl-mc: add missing __iomem attribute
This pointer to an i/o register block is missing the __iomem attribute,
so add it. The issue was found with sparse.
Reported-by: kernel test robot
Signed-off-by: Laurentiu Tudor
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 324d49d6df89..bb1056b7dc0a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -40,7 +40,7 @@ struct fsl_mc {
struct fsl_mc_device *root_mc_bus_dev;
u8 num_translation_ranges;
struct fsl_mc_addr_translation_range *translation_ranges;
- void *fsl_mc_regs;
+ void __iomem *fsl_mc_regs;
};
/**
--
2.17.1
Re: [PATCH 5/5] iommu/arm-smmu: Setup identity domain for boot mappings
On 7/9/2020 10:57 PM, Bjorn Andersson wrote:
> On Thu 09 Jul 08:50 PDT 2020, Laurentiu Tudor wrote:
>
>>
>>
>> On 7/9/2020 8:01 AM, Bjorn Andersson wrote:
>>> With many Qualcomm platforms not having functional S2CR BYPASS a
>>> temporary IOMMU domain, without translation, needs to be allocated in
>>> order to allow these memory transactions.
>>>
>>> Unfortunately the boot loader uses the first few context banks, so
>>> rather than overwriting a active bank the last context bank is used and
>>> streams are diverted here during initialization.
>>>
>>> This also performs the readback of SMR registers for the Qualcomm
>>> platform, to trigger the mechanism.
>>>
>>> This is based on prior work by Thierry Reding and Laurentiu Tudor.
>>>
>>> Signed-off-by: Bjorn Andersson
>>> ---
>>> drivers/iommu/arm-smmu-qcom.c | 11 +
>>> drivers/iommu/arm-smmu.c | 80 +--
>>> drivers/iommu/arm-smmu.h | 3 ++
>>> 3 files changed, 90 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
>>> index 86b1917459a4..397df27c1d69 100644
>>> --- a/drivers/iommu/arm-smmu-qcom.c
>>> +++ b/drivers/iommu/arm-smmu-qcom.c
>>> @@ -26,6 +26,7 @@ static const struct of_device_id
>>> qcom_smmu_client_of_match[] = {
>>> static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
>>> {
>>> unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups -
>>> 1);
>>> + u32 smr;
>>> u32 reg;
>>> int i;
>>>
>>> @@ -56,6 +57,16 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device
>>> *smmu)
>>> }
>>> }
>>>
>>> + for (i = 0; i < smmu->num_mapping_groups; i++) {
>>> + smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
>>> +
>>> + if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
>>> + smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
>>> + smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
>>> + smmu->smrs[i].valid = true;
>>> + }
>>> + }
>>> +
>>> return 0;
>>> }
>>>
>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>> index e2d6c0aaf1ea..a7cb27c1a49e 100644
>>> --- a/drivers/iommu/arm-smmu.c
>>> +++ b/drivers/iommu/arm-smmu.c
>>> @@ -652,7 +652,8 @@ static void arm_smmu_write_context_bank(struct
>>> arm_smmu_device *smmu, int idx)
>>> }
>>>
>>> static int arm_smmu_init_domain_context(struct iommu_domain *domain,
>>> - struct arm_smmu_device *smmu)
>>> + struct arm_smmu_device *smmu,
>>> + bool boot_domain)
>>> {
>>> int irq, start, ret = 0;
>>> unsigned long ias, oas;
>>> @@ -770,6 +771,15 @@ static int arm_smmu_init_domain_context(struct
>>> iommu_domain *domain,
>>> ret = -EINVAL;
>>> goto out_unlock;
>>> }
>>> +
>>> + /*
>>> +* Use the last context bank for identity mappings during boot, to
>>> +* avoid overwriting in-use bank configuration while we're setting up
>>> +* the new mappings.
>>> +*/
>>> + if (boot_domain)
>>> + start = smmu->num_context_banks - 1;
>>> +
>>> ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
>>> smmu->num_context_banks);
>>> if (ret < 0)
>>> @@ -1149,7 +1159,10 @@ static int arm_smmu_attach_dev(struct iommu_domain
>>> *domain, struct device *dev)
>>> struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>>> struct arm_smmu_master_cfg *cfg;
>>> struct arm_smmu_device *smmu;
>>> + bool free_identity_domain = false;
>>> + int idx;
>>> int ret;
>>> + int i;
>>>
>>> if (!fwspec || fwspec->ops != _smmu_ops) {
>>> dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
>>> @@ -1174,7 +1187,7 @@ static int arm_smmu_attach_dev(struct iommu_domain
>>> *domain, struct device *dev)
>>> return ret;
>>>
>>> /* En
Re: [PATCH 0/3] bus: fsl-mc: scattered updates
On 7/17/2020 6:47 PM, Ioana Ciornei wrote: > This patch set adds some scattered updates to the fsl-mc bus: first we > add some missing device types that can be found on the bus, then there > is a change needed for the PREEMPT_RT variant and the probe order for the > newly added objects on the fsl-mc bus is changed so that allocatable > objects are probed at first since they are being used by any other > driver. > > Grigore Popescu (1): > bus: fsl-mc: probe the allocatable objects first > > Ioana Ciornei (1): > bus: fsl-mc: add missing device types > > Laurentiu Tudor (1): > bus: fsl-mc: use raw spin lock to serialize mc cmds > > drivers/bus/fsl-mc/dprc-driver.c | 57 ++-- > drivers/bus/fsl-mc/fsl-mc-bus.c | 30 + > drivers/bus/fsl-mc/mc-io.c | 2 +- > drivers/bus/fsl-mc/mc-sys.c | 4 +-- > include/linux/fsl/mc.h | 32 +- > 5 files changed, 104 insertions(+), 21 deletions(-) > For the series: Reviewed-by: Laurentiu Tudor --- Best Regards, Laurentiu
Re: [PATCH v3] bus: fsl-mc: fix invalid free in fsl_mc_device_add
On 7/9/2020 6:31 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis flags this error
>
> fsl-mc-bus.c:695:2: warning: Attempt to free released memory [unix.Malloc]
> kfree(mc_dev);
> ^
>
> The problem block of code is
>
> mc_bus = kzalloc(sizeof(*mc_bus), GFP_KERNEL);
> if (!mc_bus)
> return -ENOMEM;
>
> mc_dev = _bus->mc_dev;
>
> mc_bus's structure contains a mc_dev element,
> freeing it later is not appropriate.
>
> So check if mc_bus was allocated before freeing mc_dev
>
> This is a case where checkpatch
>
> WARNING: kfree(NULL) is safe and this check is probably not required
> + if (mc_bus)
> + kfree(mc_bus);
>
> is wrong.
>
> Fixes: a042fbed0290 ("staging: fsl-mc: simplify couple of deallocations")
>
> Signed-off-by: Tom Rix
> ---
> v1: add a comment to explain freeing uniqueness
> v2: add gregkh's suggestion to comment.
>
> drivers/bus/fsl-mc/fsl-mc-bus.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 40526da5c6a6..839d96d03f0d 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -691,8 +691,16 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
>
> error_cleanup_dev:
> kfree(mc_dev->regions);
> - kfree(mc_bus);
> - kfree(mc_dev);
> + /*
> + * mc_bus allocates a private version of mc_dev
> + * it is not appropriate to free the private version.
> + * Which means we have to check the pointer before freeing it.
> + * Do not remove this check.
> + */
> + if (mc_bus)
> + kfree(mc_bus);
> + else
> + kfree(mc_dev);
>
> return error;
> }
>
Thanks, Tom!
Reviewed-by: Laurentiu Tudor
---
Best Regards, Laurentiu
Re: [PATCH 5/5] iommu/arm-smmu: Setup identity domain for boot mappings
On 7/9/2020 8:01 AM, Bjorn Andersson wrote:
> With many Qualcomm platforms not having functional S2CR BYPASS a
> temporary IOMMU domain, without translation, needs to be allocated in
> order to allow these memory transactions.
>
> Unfortunately the boot loader uses the first few context banks, so
> rather than overwriting a active bank the last context bank is used and
> streams are diverted here during initialization.
>
> This also performs the readback of SMR registers for the Qualcomm
> platform, to trigger the mechanism.
>
> This is based on prior work by Thierry Reding and Laurentiu Tudor.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/iommu/arm-smmu-qcom.c | 11 +
> drivers/iommu/arm-smmu.c | 80 +--
> drivers/iommu/arm-smmu.h | 3 ++
> 3 files changed, 90 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index 86b1917459a4..397df27c1d69 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -26,6 +26,7 @@ static const struct of_device_id
> qcom_smmu_client_of_match[] = {
> static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
> {
> unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups -
> 1);
> + u32 smr;
> u32 reg;
> int i;
>
> @@ -56,6 +57,16 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device
> *smmu)
> }
> }
>
> + for (i = 0; i < smmu->num_mapping_groups; i++) {
> + smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
> +
> + if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
> + smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
> + smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
> + smmu->smrs[i].valid = true;
> + }
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index e2d6c0aaf1ea..a7cb27c1a49e 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -652,7 +652,8 @@ static void arm_smmu_write_context_bank(struct
> arm_smmu_device *smmu, int idx)
> }
>
> static int arm_smmu_init_domain_context(struct iommu_domain *domain,
> - struct arm_smmu_device *smmu)
> + struct arm_smmu_device *smmu,
> + bool boot_domain)
> {
> int irq, start, ret = 0;
> unsigned long ias, oas;
> @@ -770,6 +771,15 @@ static int arm_smmu_init_domain_context(struct
> iommu_domain *domain,
> ret = -EINVAL;
> goto out_unlock;
> }
> +
> + /*
> + * Use the last context bank for identity mappings during boot, to
> + * avoid overwriting in-use bank configuration while we're setting up
> + * the new mappings.
> + */
> + if (boot_domain)
> + start = smmu->num_context_banks - 1;
> +
> ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
> smmu->num_context_banks);
> if (ret < 0)
> @@ -1149,7 +1159,10 @@ static int arm_smmu_attach_dev(struct iommu_domain
> *domain, struct device *dev)
> struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> struct arm_smmu_master_cfg *cfg;
> struct arm_smmu_device *smmu;
> + bool free_identity_domain = false;
> + int idx;
> int ret;
> + int i;
>
> if (!fwspec || fwspec->ops != _smmu_ops) {
> dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
> @@ -1174,7 +1187,7 @@ static int arm_smmu_attach_dev(struct iommu_domain
> *domain, struct device *dev)
> return ret;
>
> /* Ensure that the domain is finalised */
> - ret = arm_smmu_init_domain_context(domain, smmu);
> + ret = arm_smmu_init_domain_context(domain, smmu, false);
> if (ret < 0)
> goto rpm_put;
>
> @@ -1190,9 +1203,34 @@ static int arm_smmu_attach_dev(struct iommu_domain
> *domain, struct device *dev)
> goto rpm_put;
> }
>
> + /* Decrement use counter for any references to the identity domain */
> + mutex_lock(>stream_map_mutex);
> + if (smmu->identity) {
> + struct arm_smmu_domain *identity =
> to_smmu_domain(smmu->identity);
> +
> + for_each_cfg_sme(cfg, fwspec, i, idx) {
> + dev_err(smmu->dev, "%s() %#x\n", __func__,
> smmu->smrs[idx].id);
Debug leftovers?
Apart from that I plan to give this a go on some NXP chips. Will keep
you updated.
Thanks a lot Bjorn.
---
Best Regards, Laurentiu
Re: [PATCH v3 13/13] bus/fsl-mc: Add a new version for dprc_get_obj_region command
On 7/6/2020 3:42 PM, Diana Craciun wrote:
> From: Diana Craciun
>
> The region size reported by the firmware for mc and software
> portals was less than allocated by the hardware. This may be
> problematic when mmapping the region in user space because the
> region size is less than page size. However the size as reserved
> by the hardware is 64K.
Should we also mention in the commit msg that this shows up when
compiling the kernel with 64K page size support, or it's obvious enough?
> Signed-off-by: Diana Craciun
> ---
> drivers/bus/fsl-mc/dprc.c | 38 ++---
> drivers/bus/fsl-mc/fsl-mc-private.h | 3 +++
> 2 files changed, 27 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
> index 3f08752c2c19..ba292c56fe19 100644
> --- a/drivers/bus/fsl-mc/dprc.c
> +++ b/drivers/bus/fsl-mc/dprc.c
> @@ -536,20 +536,30 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
> return err;
> }
>
> - /**
> - * MC API version 6.3 introduced a new field to the region
> - * descriptor: base_address. If the older API is in use then the base
> - * address is set to zero to indicate it needs to be obtained elsewhere
> - * (typically the device tree).
> - */
> - if (dprc_major_ver > 6 || (dprc_major_ver == 6 && dprc_minor_ver >= 3))
> - cmd.header =
> - mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG_V2,
> - cmd_flags, token);
> - else
> - cmd.header =
> - mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG,
> - cmd_flags, token);
> + if (dprc_major_ver > 6 || (dprc_major_ver == 6 && dprc_minor_ver >= 6))
> {
> + /**
> + * MC API version 6.6 changed the size of the MC portals and
> software
> + * portals to 64K (as implemented by hardware). If older API is
> in use the
> + * size reported is less (64 bytes for mc portals and 4K for
> software
> + * portals).
> + */
Here and below, there's no need to use kernel-doc style comments. And a
nit: there's an extra blank line here.
---
Best Regards, Laurentiu
> + cmd.header = mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG_V3,
> + cmd_flags, token);
> +
> + } else if (dprc_major_ver == 6 && dprc_minor_ver >= 3) {
> + /**
> + * MC API version 6.3 introduced a new field to the region
> + * descriptor: base_address. If the older API is in use then
> the base
> + * address is set to zero to indicate it needs to be obtained
> elsewhere
> + * (typically the device tree).
> + */
> + cmd.header = mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG_V2,
> + cmd_flags, token);
> + } else {
> + cmd.header = mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG,
> + cmd_flags, token);
> + }
>
> cmd_params = (struct dprc_cmd_get_obj_region *)cmd.params;
> cmd_params->obj_id = cpu_to_le32(obj_id);
> diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h
> b/drivers/bus/fsl-mc/fsl-mc-private.h
> index e6fcff12c68d..8d65273a78d7 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-private.h
> +++ b/drivers/bus/fsl-mc/fsl-mc-private.h
> @@ -80,10 +80,12 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
> /* DPRC command versioning */
> #define DPRC_CMD_BASE_VERSION1
> #define DPRC_CMD_2ND_VERSION 2
> +#define DPRC_CMD_3RD_VERSION 3
> #define DPRC_CMD_ID_OFFSET 4
>
> #define DPRC_CMD(id) (((id) << DPRC_CMD_ID_OFFSET) | DPRC_CMD_BASE_VERSION)
> #define DPRC_CMD_V2(id) (((id) << DPRC_CMD_ID_OFFSET) |
> DPRC_CMD_2ND_VERSION)
> +#define DPRC_CMD_V3(id) (((id) << DPRC_CMD_ID_OFFSET) |
> DPRC_CMD_3RD_VERSION)
>
> /* DPRC command IDs */
> #define DPRC_CMDID_CLOSEDPRC_CMD(0x800)
> @@ -105,6 +107,7 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
> #define DPRC_CMDID_GET_OBJ DPRC_CMD(0x15A)
> #define DPRC_CMDID_GET_OBJ_REG DPRC_CMD(0x15E)
> #define DPRC_CMDID_GET_OBJ_REG_V2 DPRC_CMD_V2(0x15E)
> +#define DPRC_CMDID_GET_OBJ_REG_V3 DPRC_CMD_V3(0x15E)
> #define DPRC_CMDID_SET_OBJ_IRQ DPRC_CMD(0x15F)
>
> #define DPRC_CMDID_GET_CONNECTION DPRC_CMD(0x16C)
>
Re: [PATCH v2 00/12] bus/fsl-mc: Extend mc-bus driver functionalities in preparation for mc-bus VFIO support
On 5/7/2020 10:34 AM, Diana Craciun wrote: > The vfio-mc bus driver needs some additional services to be exported by the > mc-bus driver like: > - a way to reset the DPRC container > - driver_override support > - functions to setup/tear down a DPRC > - functions for allocating the pool of interrupts. In case of VFIO the > interrupts are not configured at probe time, but later by userspace > request > > v1 -> v2 > - Remove driver_override propagation through various functions > - Cache the DPRC API version > > The patches are related with "vfio/fsl-mc: VFIO support for FSL-MC > devices" patches, but the series were split because they are targeting > different subsystems. However, the mc-bus patches may suffer changes > when addressing the VFIO review comments. > > Bharat Bhushan (3): > bus/fsl-mc: add support for 'driver_override' in the mc-bus > bus/fsl-mc: Add dprc-reset-container support > bus/fsl-mc: Extend ICID size from 16bit to 32bit > > Diana Craciun (9): > bus/fsl-mc: Do no longer export the total number of irqs outside > dprc_scan_objects > bus/fsl-mc: Add a new parameter to dprc_scan_objects function > bus/fsl-mc: Set the QMAN/BMAN region flags > bus/fsl-mc: Cache the DPRC API version > bus/fsl-mc: Export a dprc scan function to be used by multiple > entities > bus/fsl-mc: Export a cleanup function for DPRC > bus/fsl-mc: Add a container setup function > bus/fsl_mc: Do not rely on caller to provide non NULL mc_io > bus/fsl-mc: Export IRQ pool handling functions to be used by VFIO > > drivers/bus/fsl-mc/dprc-driver.c | 181 -- > drivers/bus/fsl-mc/dprc.c | 103 +-- > drivers/bus/fsl-mc/fsl-mc-allocator.c | 12 +- > drivers/bus/fsl-mc/fsl-mc-bus.c | 64 - > drivers/bus/fsl-mc/fsl-mc-private.h | 28 ++-- > drivers/bus/fsl-mc/mc-io.c| 7 +- > include/linux/fsl/mc.h| 29 - > 7 files changed, 313 insertions(+), 111 deletions(-) > For the whole series: Reviewed-by: Laurentiu Tudor --- Best Regards, Laurentiu
Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()
On 22.10.2019 16:25, Robin Murphy wrote:
> On 22/10/2019 13:55, Laurentiu Tudor wrote:
>> From: Laurentiu Tudor
>>
>> Introduce a new dma map op called dma_addr_to_phys_addr() that converts
>> a dma address to the physical address backing it up and add wrapper for
>> it.
>
> I'd really love it if there was a name which could encapsulate that this
> is *only* for extreme special cases of constrained descriptors/pagetable
> entries/etc. where there's simply no practical way to keep track of a
> CPU address alongside the DMA address, and the only option is this
> potentially-arbitrarily-complex operation (I mean, on some systems it
> may end up taking locks and poking hardware).
>
> Either way it's tricky - much as I don't like adding an interface which
> is ripe for drivers to misuse, I also really don't want hacks like
> bdf95923086f shoved into other APIs to compensate, so on balance I'd
> probably consider this proposal ever so slightly the lesser evil.
>
>> Signed-off-by: Laurentiu Tudor
>> ---
>> include/linux/dma-mapping.h | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index 4a1c4fca475a..5965d159c9a9 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -132,6 +132,8 @@ struct dma_map_ops {
>> u64 (*get_required_mask)(struct device *dev);
>> size_t (*max_mapping_size)(struct device *dev);
>> unsigned long (*get_merge_boundary)(struct device *dev);
>> + phys_addr_t (*dma_addr_to_phys_addr)(struct device *dev,
>> + dma_addr_t dma_handle);
>
> I'd be inclined to name the internal callback something a bit snappier
> like .get_phys_addr.
Alright. Want me to also rename the wrapper to something like
dma_get_phys_addr()? Sounds a bit nicer to me.
>> };
>> #define DMA_MAPPING_ERROR (~(dma_addr_t)0)
>> @@ -442,6 +444,19 @@ static inline int dma_mapping_error(struct device
>> *dev, dma_addr_t dma_addr)
>> return 0;
>> }
>> +static inline phys_addr_t dma_addr_to_phys_addr(struct device *dev,
>> + dma_addr_t dma_handle)
>> +{
>> + const struct dma_map_ops *ops = get_dma_ops(dev);
>> +
>> + if (dma_is_direct(ops))
>> + return (phys_addr_t)dma_handle;
>
> Well that's not right, is it - remember why you had that namespace
> collision? ;)
>
Ugh, correct. Don't know what I was thinking. Will rework the check.
---
Thanks & Best Regards, Laurentiu
Re: [PATCH 19/20] dpaa_eth: add dpaa_dma_to_virt()
On 09.10.2019 10:39, Christoph Hellwig wrote: > On Tue, Oct 08, 2019 at 03:10:40PM +0300, Madalin Bucur wrote: >> Centralize the phys_to_virt() calls. > > You don't need to centralize those, you need to fix them. Calling > phys_to_virt on a dma_addr is completely bogus. > Yeah, that's on my TODO list [1] for quite a while, among others. I'll return to it as soon as I'm done with the burning stuff I'm currently on. [1] https://patchwork.kernel.org/patch/10968947/ --- Best Regards, Laurentiu
RE: [PATCH 1/3] bus: fsl-mc: remove explicit device_link_del
Hi Leo,
> -Original Message-
> From: Li Yang
> Sent: Friday, August 16, 2019 2:13 AM
> To: Ioana Ciornei
> Cc: Laurentiu Tudor ; Roy Pledge
> ; lkml
> Subject: Re: [PATCH 1/3] bus: fsl-mc: remove explicit device_link_del
> Importance: High
>
> On Wed, Jul 3, 2019 at 9:58 AM Ioana Ciornei wrote:
> >
> > Starting with commit 72175d4ea4c4 ("driver core: Make driver core own
> > stateful device links") stateful device links are owned by the driver
> > core and should not be explicitly removed on device unbind. Delete all
> > device_link_del appearances from the fsl-mc bus.
> >
> > Signed-off-by: Ioana Ciornei
>
> Hi Laurentiu,
>
> What do you think of this patches? I can take it through fsl/soc if
> you can ACK it.
Looks good to me, so for the whole series:
Acked-By: Laurentiu Tudor
> Regards,
> Leo
>
> > ---
> > drivers/bus/fsl-mc/fsl-mc-allocator.c | 1 -
> > drivers/bus/fsl-mc/mc-io.c| 1 -
> > 2 files changed, 2 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-allocator.c b/drivers/bus/fsl-
> mc/fsl-mc-allocator.c
> > index 8ad77246f322..cc7bb900f524 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-allocator.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-allocator.c
> > @@ -330,7 +330,6 @@ void fsl_mc_object_free(struct fsl_mc_device
> *mc_adev)
> >
> > fsl_mc_resource_free(resource);
> >
> > - device_link_del(mc_adev->consumer_link);
> > mc_adev->consumer_link = NULL;
> > }
> > EXPORT_SYMBOL_GPL(fsl_mc_object_free);
> > diff --git a/drivers/bus/fsl-mc/mc-io.c b/drivers/bus/fsl-mc/mc-io.c
> > index 3ae574a58cce..d9629fc13a15 100644
> > --- a/drivers/bus/fsl-mc/mc-io.c
> > +++ b/drivers/bus/fsl-mc/mc-io.c
> > @@ -255,7 +255,6 @@ void fsl_mc_portal_free(struct fsl_mc_io *mc_io)
> > fsl_destroy_mc_io(mc_io);
> > fsl_mc_resource_free(resource);
> >
> > - device_link_del(dpmcp_dev->consumer_link);
> > dpmcp_dev->consumer_link = NULL;
> > }
> > EXPORT_SYMBOL_GPL(fsl_mc_portal_free);
> > --
> > 1.9.1
> >
RE: [PATCH v7 3/5] usb: host: ohci-sm501: init genalloc for local memory
Hello, > -Original Message- > From: Guenter Roeck On Behalf Of Guenter Roeck > Sent: Thursday, June 13, 2019 9:06 PM > > On 6/13/19 8:34 AM, Fredrik Noring wrote: > > Hi Guenter, > > > >> Thanks for the confirmation. Do you see the problem only with the > >> ohci-sm501 driver or also with others ? > > > > All are likely affected, but it depends, because I believe the problem > is > > that the USB subsystem runs out of memory. Please try the attached patch! > > > > The pool assumed 4096 byte page alignment for every allocation, which is > > excessive given that many requests are for 16 and 32 bytes. In the patch > > below, I have turned down the order to 5, which is good enough for the > ED > > and TD structures of the OHCI, but not enough for the HCCA that needs > 256 > > byte alignment. With some luck, the WARN_ON_ONCE will not trigger in > your > > test, though. If it does, you may try to increase the order from 5 to 8. > > > > You are right, the patch below fixes the problem. I did not get the > warning > with order==5. Nevertheless, I also tested with order==8; that works as > well. Sorry for the late reply, I was OOO for past week+ and many thanks for taking a look at this. So if my understanding is correct, an order of PAGE_SHIFT is too large and leads to waste of memory and in the end to an out of memory condition. This leaves me wondering what a safe order value would be. I'll try to look into the legacy dma coherent allocation code maybe I can gather some info on the subject. --- Best Regards, Laurentiu > > > I have observed strange things happen when the USB subsystem runs out of > > memory. The mass storage drivers often seem to busy-wait on -ENOMEM, > > consuming a lot of processor resources. It would be much more efficient > > to sleep waiting for memory to become available. > > > > In your case I suspect that allocation failures are not correctly > > attributed. Certain kinds of temporary freezes may also occur, as the > > various devices are reset due to host memory allocation errors. > > > Fredrik > > > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > > --- a/drivers/usb/core/hcd.c > > +++ b/drivers/usb/core/hcd.c > > @@ -3011,7 +3011,7 @@ int usb_hcd_setup_local_mem(struct usb_hcd *hcd, > phys_addr_t phys_addr, > > int err; > > void __iomem *local_mem; > > > > - hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, > PAGE_SHIFT, > > + hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, 5, > > dev_to_node(hcd->self.sysdev), > > dev_name(hcd->self.sysdev)); > > if (IS_ERR(hcd->localmem_pool)) > > diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c > > --- a/drivers/usb/host/ohci-hcd.c > > +++ b/drivers/usb/host/ohci-hcd.c > > @@ -517,6 +517,7 @@ static int ohci_init (struct ohci_hcd *ohci) > > GFP_KERNEL); > > if (!ohci->hcca) > > return -ENOMEM; > > + WARN_ON_ONCE(ohci->hcca_dma & 0xff); > > > > if ((ret = ohci_mem_init (ohci)) < 0) > > ohci_stop (hcd); > >
Re: [PATCH v7 0/5] prerequisites for device reserved local mem rework
On 31.05.2019 19:43, Christoph Hellwig wrote: > On Wed, May 29, 2019 at 02:06:12PM +0000, Laurentiu Tudor wrote: >> Thanks, hope this time everything is fine. > > I've applied it to the dma-mapping tree now. > >> When you get the time, please let me know your ideas on the next steps. > > I think the next step is to move the call to > dma_alloc_from_dev_coherent from dma_alloc_attrs into the ->alloc > instances. The only onces that really need it for now are the > generic and legacy arm dma-direct code, and drivers/iommu/dma-iommu.c > as well as the ARM DMA API code, as those are the ones use for > architectures that declare coherent regions. The other iommus are > not used on OF platforms (at least that's what my analysis said a while > ago, feel free to double check it) Thanks for the details. I'll be OOO next week so probably I'll start looking into it next next week. --- Best Regards, Laurentiu
RE: [PATCH v7 0/5] prerequisites for device reserved local mem rework
> -Original Message- > From: Christoph Hellwig > Sent: Friday, May 31, 2019 7:43 PM > > On Wed, May 29, 2019 at 02:06:12PM +0000, Laurentiu Tudor wrote: > > Thanks, hope this time everything is fine. > > I've applied it to the dma-mapping tree now. > > > When you get the time, please let me know your ideas on the next steps. > > I think the next step is to move the call to > dma_alloc_from_dev_coherent from dma_alloc_attrs into the ->alloc > instances. The only onces that really need it for now are the > generic and legacy arm dma-direct code, and drivers/iommu/dma-iommu.c > as well as the ARM DMA API code, as those are the ones use for > architectures that declare coherent regions. The other iommus are > not used on OF platforms (at least that's what my analysis said a while > ago, feel free to double check it) Thanks. I'll start looking into it starting next week. Keep in touch. --- Best Regards, Laurentiu
Re: [PATCH v7 0/5] prerequisites for device reserved local mem rework
Hi Christoph, On 29.05.2019 14:37, Christoph Hellwig wrote: > On Wed, May 29, 2019 at 04:34:27AM -0700, Greg KH wrote: >> Reviewed-by: Greg Kroah-Hartman >> >> Christoph, this is going through your tree, right? > > Yes, I'll pіck it up. > Thanks, hope this time everything is fine. When you get the time, please let me know your ideas on the next steps. --- Best Regards, Laurentiu
Re: [PATCH v7 2/5] USB: use genalloc for USB HCs with local memory
On 29.05.2019 13:38, Greg KH wrote: > On Wed, May 29, 2019 at 01:28:40PM +0300, laurentiu.tu...@nxp.com wrote: >> From: Laurentiu Tudor >> >> For HCs that have local memory, replace the current DMA API usage >> with a genalloc generic allocator to manage the mappings for these >> devices. To help users, introduce a new HCD API, >> usb_hcd_setup_local_mem() that will setup up the genalloc backing >> up the device local memory. It will be used in subsequent patches. >> This is in preparation for dropping the existing "coherent" dma >> mem declaration APIs. Current implementation was relying on a short >> circuit in the DMA API that in the end, was acting as an allocator >> for these type of devices. >> For sh arch to compile GENERIC_ALLOCATOR needs to be selected in >> Kconfig. >> >> For context, see thread here: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F4%2F22%2F357data=02%7C01%7Claurentiu.tudor%40nxp.com%7Cade28e1f322c4502cd4808d6e421d0ba%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636947231220264072sdata=xvmzDztMbeD9GwlcAfx7bBoxhARWgB3vmQkqiE81Lbg%3Dreserved=0 >> >> Signed-off-by: Laurentiu Tudor >> Signed-off-by: Fredrik Noring >> Tested-by: Fredrik Noring >> Reported-by: kbuild test robot >> --- >> drivers/usb/Kconfig | 1 + >> drivers/usb/core/buffer.c | 9 + >> drivers/usb/core/hcd.c | 36 >> drivers/usb/host/ohci-hcd.c | 23 ++- >> drivers/usb/host/ohci-mem.c | 35 +++ >> drivers/usb/host/ohci.h | 2 ++ >> include/linux/usb/hcd.h | 5 + >> 7 files changed, 102 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig >> index e4b27413f528..389c57d8eba7 100644 >> --- a/drivers/usb/Kconfig >> +++ b/drivers/usb/Kconfig >> @@ -45,6 +45,7 @@ config USB_ARCH_HAS_HCD >> config USB >> tristate "Support for Host-side USB" >> depends on USB_ARCH_HAS_HCD >> +select GENERIC_ALLOCATOR > > Are there any arches that does not have GENERIC_ALLOCATOR? I don't want > to suddenly cut off a bunch of working systems from having USB support. > lkp report mentions only sh, but even if there are others, I think that now having the explicit select should cover them, right? --- Best Regards, Laurentiu
[PATCH v7 1/5] lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations
From: Fredrik Noring
gen_pool_dma_zalloc() is a zeroed memory variant of gen_pool_dma_alloc().
Document return values of both, and indicate NULL as a "%NULL" constant.
Signed-off-by: Fredrik Noring
Tested-by: Fredrik Noring
---
include/linux/genalloc.h | 1 +
lib/genalloc.c | 29 -
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index dd0a452373e7..6c62eeca754f 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -121,6 +121,7 @@ extern unsigned long gen_pool_alloc_algo(struct gen_pool *,
size_t,
genpool_algo_t algo, void *data);
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
+void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 7e85d1e37a6e..5db43476a19b 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -337,12 +337,14 @@ EXPORT_SYMBOL(gen_pool_alloc_algo);
* gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
* @pool: pool to allocate from
* @size: number of bytes to allocate from the pool
- * @dma: dma-view physical address return value. Use NULL if unneeded.
+ * @dma: dma-view physical address return value. Use %NULL if unneeded.
*
* Allocate the requested number of bytes from the specified pool.
* Uses the pool allocation function (with first-fit algorithm by default).
* Can not be used in NMI handler on architectures without
* NMI-safe cmpxchg implementation.
+ *
+ * Return: virtual address of the allocated memory, or %NULL on failure
*/
void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
{
@@ -362,6 +364,31 @@ void *gen_pool_dma_alloc(struct gen_pool *pool, size_t
size, dma_addr_t *dma)
}
EXPORT_SYMBOL(gen_pool_dma_alloc);
+/**
+ * gen_pool_dma_zalloc - allocate special zeroed memory from the pool for
+ * DMA usage
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @dma: dma-view physical address return value. Use %NULL if unneeded.
+ *
+ * Allocate the requested number of zeroed bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ *
+ * Return: virtual address of the allocated zeroed memory, or %NULL on failure
+ */
+void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
+{
+ void *vaddr = gen_pool_dma_alloc(pool, size, dma);
+
+ if (vaddr)
+ memset(vaddr, 0, size);
+
+ return vaddr;
+}
+EXPORT_SYMBOL(gen_pool_dma_zalloc);
+
/**
* gen_pool_free - free allocated special memory back to the pool
* @pool: pool to free to
--
2.17.1
[PATCH v7 2/5] USB: use genalloc for USB HCs with local memory
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices. To help users, introduce a new HCD API,
usb_hcd_setup_local_mem() that will setup up the genalloc backing
up the device local memory. It will be used in subsequent patches.
This is in preparation for dropping the existing "coherent" dma
mem declaration APIs. Current implementation was relying on a short
circuit in the DMA API that in the end, was acting as an allocator
for these type of devices.
For sh arch to compile GENERIC_ALLOCATOR needs to be selected in
Kconfig.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
Signed-off-by: Fredrik Noring
Tested-by: Fredrik Noring
Reported-by: kbuild test robot
---
drivers/usb/Kconfig | 1 +
drivers/usb/core/buffer.c | 9 +
drivers/usb/core/hcd.c | 36
drivers/usb/host/ohci-hcd.c | 23 ++-
drivers/usb/host/ohci-mem.c | 35 +++
drivers/usb/host/ohci.h | 2 ++
include/linux/usb/hcd.h | 5 +
7 files changed, 102 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index e4b27413f528..389c57d8eba7 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -45,6 +45,7 @@ config USB_ARCH_HAS_HCD
config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
+ select GENERIC_ALLOCATOR
select USB_COMMON
select NLS # for UTF-8 strings
---help---
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index f641342cdec0..d2064ad7ad14 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -124,6 +125,9 @@ void *hcd_buffer_alloc(
if (size == 0)
return NULL;
+ if (hcd->localmem_pool)
+ return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
+
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(bus->sysdev) &&
@@ -152,6 +156,11 @@ void hcd_buffer_free(
if (!addr)
return;
+ if (hcd->localmem_pool) {
+ gen_pool_free(hcd->localmem_pool, (unsigned long)addr, size);
+ return;
+ }
+
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(bus->sysdev) &&
!(hcd->driver->flags & HCD_LOCAL_MEM))) {
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 94d22551fc1b..29b96e5e8621 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -3039,6 +3041,40 @@ usb_hcd_platform_shutdown(struct platform_device *dev)
}
EXPORT_SYMBOL_GPL(usb_hcd_platform_shutdown);
+int usb_hcd_setup_local_mem(struct usb_hcd *hcd, phys_addr_t phys_addr,
+ dma_addr_t dma, size_t size)
+{
+ int err;
+ void *local_mem;
+
+ hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, PAGE_SHIFT,
+ dev_to_node(hcd->self.sysdev),
+ dev_name(hcd->self.sysdev));
+ if (IS_ERR(hcd->localmem_pool))
+ return PTR_ERR(hcd->localmem_pool);
+
+ local_mem = devm_memremap(hcd->self.sysdev, phys_addr,
+ size, MEMREMAP_WC);
+ if (!local_mem)
+ return -ENOMEM;
+
+ /*
+* Here we pass a dma_addr_t but the arg type is a phys_addr_t.
+* It's not backed by system memory and thus there's no kernel mapping
+* for it.
+*/
+ err = gen_pool_add_virt(hcd->localmem_pool, (unsigned long)local_mem,
+ dma, size, dev_to_node(hcd->self.sysdev));
+ if (err < 0) {
+ dev_err(hcd->self.sysdev, "gen_pool_add_virt failed with %d\n",
+ err);
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_hcd_setup_local_mem);
+
/*-*/
#if IS_ENABLED(CONFIG_USB_MON)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 210181fd98d2..b200b19b44fa 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -505,8 +506,15 @@ static int ohci_init (struct ohci_hcd *ohci)
timer_setup(>io_watchdog, io_watchdog_func, 0);
ohci->prev_frame_no = IO_WATCHDOG_OFF;
- ohci->hcca = dma_alloc_coherent (hcd-&
[PATCH v7 0/5] prerequisites for device reserved local mem rework
From: Laurentiu Tudor For HCs that have local memory, replace the current DMA API usage with a genalloc generic allocator to manage the mappings for these devices. This is in preparation for dropping the existing "coherent" dma mem declaration APIs. Current implementation was relying on a short circuit in the DMA API that in the end, was acting as an allocator for these type of devices. Only compiled tested, so any volunteers willing to test are most welcome. Thank you! For context, see thread here: https://lkml.org/lkml/2019/4/22/357 Changes in v7: - drop useless __iomem annotation to fix sparse warning - select GENERIC_ALLOCATOR to fix compilation on sh arch Changes in v6: - drop some unneeded initializations (Alan) - use device name for genpool instead of misleading "ohci-hcd" (Alan) - updated some comments (Alan, Fredrik) - added Tested-By tags Changes in v5: - updated first patch to preserve bisectability (Christoph, Greg) - fixed a few more places where dma api was still being used (e.g. td_alloc, ed_alloc) (Fredrik) - included patch from Fredrik adding gen_pool_dma_zalloc() api - added patch that drops HCD_LOCAL_MEM altogether (Greg) - set td_cache / ed_cache to null for devices with local mem (Fredrik) - introduce usb_hcd_setup_local_mem() that sets up the genalloc pool for drivers and updated drivers to use it Changes in v4: - created mapping for local mem - fix genalloc misuse Changes in v3: - rearranged calls into genalloc simplifying the code a bit (Christoph) - dropped RFC prefix Changes in v2: - use genalloc also in core usb (based on comment from Robin) - moved genpool decl to usb_hcd to be accesible from core usb Fredrik Noring (1): lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations Laurentiu Tudor (4): USB: use genalloc for USB HCs with local memory usb: host: ohci-sm501: init genalloc for local memory usb: host: ohci-tmio: init genalloc for local memory USB: drop HCD_LOCAL_MEM flag drivers/usb/Kconfig| 1 + drivers/usb/core/buffer.c | 17 drivers/usb/core/hcd.c | 51 -- drivers/usb/host/ehci-hcd.c| 2 +- drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/ohci-hcd.c| 25 + drivers/usb/host/ohci-mem.c| 35 --- drivers/usb/host/ohci-sm501.c | 50 +++-- drivers/usb/host/ohci-tmio.c | 15 -- drivers/usb/host/ohci.h| 2 ++ drivers/usb/host/uhci-hcd.c| 2 +- include/linux/genalloc.h | 1 + include/linux/usb/hcd.h| 6 +++- lib/genalloc.c | 29 ++- 14 files changed, 172 insertions(+), 66 deletions(-) -- 2.17.1
[PATCH v7 3/5] usb: host: ohci-sm501: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-sm501.c | 47 +++
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index c26228c25f99..b710e100aec9 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -110,40 +110,18 @@ static int ohci_hcd_sm501_drv_probe(struct
platform_device *pdev)
goto err0;
}
- /* The sm501 chip is equipped with local memory that may be used
-* by on-chip devices such as the video controller and the usb host.
-* This driver uses dma_declare_coherent_memory() to make sure
-* usb allocations with dma_alloc_coherent() allocate from
-* this local memory. The dma_handle returned by dma_alloc_coherent()
-* will be an offset starting from 0 for the first local memory byte.
-*
-* So as long as data is allocated using dma_alloc_coherent() all is
-* fine. This is however not always the case - buffers may be allocated
-* using kmalloc() - so the usb core needs to be told that it must copy
-* data into our local memory if the buffers happen to be placed in
-* regular memory. The HCD_LOCAL_MEM flag does just that.
-*/
-
- retval = dma_declare_coherent_memory(dev, mem->start,
-mem->start - mem->parent->start,
-resource_size(mem));
- if (retval) {
- dev_err(dev, "cannot declare coherent memory\n");
- goto err1;
- }
-
/* allocate, reserve and remap resources for registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(dev, "no resource definition for registers\n");
retval = -ENOENT;
- goto err2;
+ goto err1;
}
hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
if (!hcd) {
retval = -ENOMEM;
- goto err2;
+ goto err1;
}
hcd->rsrc_start = res->start;
@@ -164,6 +142,24 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
ohci_hcd_init(hcd_to_ohci(hcd));
+ /* The sm501 chip is equipped with local memory that may be used
+* by on-chip devices such as the video controller and the usb host.
+* This driver uses genalloc so that usb allocations with
+* gen_pool_dma_alloc() allocate from this local memory. The dma_handle
+* returned by gen_pool_dma_alloc() will be an offset starting from 0
+* for the first local memory byte.
+*
+* So as long as data is allocated using gen_pool_dma_alloc() all is
+* fine. This is however not always the case - buffers may be allocated
+* using kmalloc() - so the usb core needs to be told that it must copy
+* data into our local memory if the buffers happen to be placed in
+* regular memory. The HCD_LOCAL_MEM flag does just that.
+*/
+
+ if (usb_hcd_setup_local_mem(hcd, mem->start,
+ mem->start - mem->parent->start,
+ resource_size(mem)) < 0)
+ goto err5;
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval)
goto err5;
@@ -181,8 +177,6 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
err3:
usb_put_hcd(hcd);
-err2:
- dma_release_declared_memory(dev);
err1:
release_mem_region(mem->start, resource_size(mem));
err0:
@@ -197,7 +191,6 @@ static int ohci_hcd_sm501_drv_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
- dma_release_declared_memory(>dev);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (mem)
release_mem_region(mem->start, resource_size(mem));
--
2.17.1
[PATCH v7 5/5] USB: drop HCD_LOCAL_MEM flag
From: Laurentiu Tudor
With the addition of the local memory allocator, the HCD_LOCAL_MEM
flag can be dropped and the checks against it replaced with a check
for the localmem_pool ptr being initialized.
Signed-off-by: Laurentiu Tudor
Tested-by: Fredrik Noring
---
drivers/usb/core/buffer.c | 8 +++-
drivers/usb/core/hcd.c | 15 ++-
drivers/usb/host/ehci-hcd.c| 2 +-
drivers/usb/host/fotg210-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c| 2 +-
drivers/usb/host/ohci-sm501.c | 5 +++--
drivers/usb/host/ohci-tmio.c | 2 +-
drivers/usb/host/uhci-hcd.c| 2 +-
include/linux/usb/hcd.h| 1 -
9 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index d2064ad7ad14..1359b78a624e 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -68,7 +68,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(hcd->self.sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM)))
+!hcd->localmem_pool))
return 0;
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
@@ -130,8 +130,7 @@ void *hcd_buffer_alloc(
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
@@ -162,8 +161,7 @@ void hcd_buffer_free(
}
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
kfree(addr);
return;
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 29b96e5e8621..fe631d18c1ed 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1347,14 +1347,14 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* using regular system memory - like pci devices doing bus mastering.
*
* To support host controllers with limited dma capabilities we provide dma
- * bounce buffers. This feature can be enabled using the HCD_LOCAL_MEM flag.
+ * bounce buffers. This feature can be enabled by initializing
+ * hcd->localmem_pool using usb_hcd_setup_local_mem().
* For this to work properly the host controller code must first use the
* function dma_declare_coherent_memory() to point out which memory area
* that should be used for dma allocations.
*
- * The HCD_LOCAL_MEM flag then tells the usb code to allocate all data for
- * dma using dma_alloc_coherent() which in turn allocates from the memory
- * area pointed out with dma_declare_coherent_memory().
+ * The initialized hcd->localmem_pool then tells the usb code to allocate all
+ * data for dma using the genalloc API.
*
* So, to summarize...
*
@@ -1364,9 +1364,6 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* (a) "normal" kernel memory is no good, and
* (b) there's not enough to share
*
- * - The only *portable* hook for such stuff in the
- * DMA framework is dma_declare_coherent_memory()
- *
* - So we use that, even though the primary requirement
* is that the memory be "local" (hence addressable
* by that device), not "coherent".
@@ -1533,7 +1530,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
urb->setup_dma))
return -EAGAIN;
urb->transfer_flags |= URB_SETUP_MAP_SINGLE;
- } else if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ } else if (hcd->localmem_pool) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
>setup_dma,
@@ -1603,7 +1600,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
else
urb->transfer_flags |=
URB_DMA_MAP_SINGLE;
}
- } else if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ } else if (hcd->localmem_pool) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
>transfer_dma,
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index cdafa97f632d..9da7e22848c9 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -559,7 +559,7 @@ static int ehci_init(struct usb_hcd *hcd)
ehci->command = temp;
/* Acc
[PATCH v7 4/5] usb: host: ohci-tmio: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-tmio.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index f88a0370659f..3b84ce0c3f29 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -224,11 +224,6 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
goto err_ioremap_regs;
}
- ret = dma_declare_coherent_memory(>dev, sram->start, sram->start,
- resource_size(sram));
- if (ret)
- goto err_dma_declare;
-
if (cell->enable) {
ret = cell->enable(dev);
if (ret)
@@ -239,6 +234,11 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
+ ret = usb_hcd_setup_local_mem(hcd, sram->start, sram->start,
+ resource_size(sram));
+ if (ret < 0)
+ goto err_enable;
+
ret = usb_add_hcd(hcd, irq, 0);
if (ret)
goto err_add_hcd;
@@ -254,8 +254,6 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
if (cell->disable)
cell->disable(dev);
err_enable:
- dma_release_declared_memory(>dev);
-err_dma_declare:
iounmap(hcd->regs);
err_ioremap_regs:
iounmap(tmio->ccr);
@@ -276,7 +274,6 @@ static int ohci_hcd_tmio_drv_remove(struct platform_device
*dev)
tmio_stop_hc(dev);
if (cell->disable)
cell->disable(dev);
- dma_release_declared_memory(>dev);
iounmap(hcd->regs);
iounmap(tmio->ccr);
usb_put_hcd(hcd);
--
2.17.1
[PATCH v6 4/5] usb: host: ohci-tmio: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-tmio.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index f88a0370659f..3b84ce0c3f29 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -224,11 +224,6 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
goto err_ioremap_regs;
}
- ret = dma_declare_coherent_memory(>dev, sram->start, sram->start,
- resource_size(sram));
- if (ret)
- goto err_dma_declare;
-
if (cell->enable) {
ret = cell->enable(dev);
if (ret)
@@ -239,6 +234,11 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
+ ret = usb_hcd_setup_local_mem(hcd, sram->start, sram->start,
+ resource_size(sram));
+ if (ret < 0)
+ goto err_enable;
+
ret = usb_add_hcd(hcd, irq, 0);
if (ret)
goto err_add_hcd;
@@ -254,8 +254,6 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
if (cell->disable)
cell->disable(dev);
err_enable:
- dma_release_declared_memory(>dev);
-err_dma_declare:
iounmap(hcd->regs);
err_ioremap_regs:
iounmap(tmio->ccr);
@@ -276,7 +274,6 @@ static int ohci_hcd_tmio_drv_remove(struct platform_device
*dev)
tmio_stop_hc(dev);
if (cell->disable)
cell->disable(dev);
- dma_release_declared_memory(>dev);
iounmap(hcd->regs);
iounmap(tmio->ccr);
usb_put_hcd(hcd);
--
2.17.1
[PATCH v6 5/5] USB: drop HCD_LOCAL_MEM flag
From: Laurentiu Tudor
With the addition of the local memory allocator, the HCD_LOCAL_MEM
flag can be dropped and the checks against it replaced with a check
for the localmem_pool ptr being initialized.
Signed-off-by: Laurentiu Tudor
Tested-by: Fredrik Noring
---
drivers/usb/core/buffer.c | 8 +++-
drivers/usb/core/hcd.c | 15 ++-
drivers/usb/host/ehci-hcd.c| 2 +-
drivers/usb/host/fotg210-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c| 2 +-
drivers/usb/host/ohci-sm501.c | 5 +++--
drivers/usb/host/ohci-tmio.c | 2 +-
drivers/usb/host/uhci-hcd.c| 2 +-
include/linux/usb/hcd.h| 1 -
9 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index d2064ad7ad14..1359b78a624e 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -68,7 +68,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(hcd->self.sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM)))
+!hcd->localmem_pool))
return 0;
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
@@ -130,8 +130,7 @@ void *hcd_buffer_alloc(
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
@@ -162,8 +161,7 @@ void hcd_buffer_free(
}
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
kfree(addr);
return;
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 1aad11f4142c..b65785fae11a 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1347,14 +1347,14 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* using regular system memory - like pci devices doing bus mastering.
*
* To support host controllers with limited dma capabilities we provide dma
- * bounce buffers. This feature can be enabled using the HCD_LOCAL_MEM flag.
+ * bounce buffers. This feature can be enabled by initializing
+ * hcd->localmem_pool using usb_hcd_setup_local_mem().
* For this to work properly the host controller code must first use the
* function dma_declare_coherent_memory() to point out which memory area
* that should be used for dma allocations.
*
- * The HCD_LOCAL_MEM flag then tells the usb code to allocate all data for
- * dma using dma_alloc_coherent() which in turn allocates from the memory
- * area pointed out with dma_declare_coherent_memory().
+ * The initialized hcd->localmem_pool then tells the usb code to allocate all
+ * data for dma using the genalloc API.
*
* So, to summarize...
*
@@ -1364,9 +1364,6 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* (a) "normal" kernel memory is no good, and
* (b) there's not enough to share
*
- * - The only *portable* hook for such stuff in the
- * DMA framework is dma_declare_coherent_memory()
- *
* - So we use that, even though the primary requirement
* is that the memory be "local" (hence addressable
* by that device), not "coherent".
@@ -1533,7 +1530,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
urb->setup_dma))
return -EAGAIN;
urb->transfer_flags |= URB_SETUP_MAP_SINGLE;
- } else if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ } else if (hcd->localmem_pool) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
>setup_dma,
@@ -1603,7 +1600,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
else
urb->transfer_flags |=
URB_DMA_MAP_SINGLE;
}
- } else if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ } else if (hcd->localmem_pool) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
>transfer_dma,
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index cdafa97f632d..9da7e22848c9 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -559,7 +559,7 @@ static int ehci_init(struct usb_hcd *hcd)
ehci->command = temp;
/* Acc
[PATCH v6 0/5] prerequisites for device reserved local mem rework
From: Laurentiu Tudor For HCs that have local memory, replace the current DMA API usage with a genalloc generic allocator to manage the mappings for these devices. This is in preparation for dropping the existing "coherent" dma mem declaration APIs. Current implementation was relying on a short circuit in the DMA API that in the end, was acting as an allocator for these type of devices. Only compiled tested, so any volunteers willing to test are most welcome. Thank you! For context, see thread here: https://lkml.org/lkml/2019/4/22/357 Changes in v6: - drop some unneeded initializations (Alan) - use device name for genpool instead of misleading "ohci-hcd" (Alan) - updated some comments (Alan, Fredrik) - added Tested-By tags Changes in v5: - updated first patch to preserve bisectability (Christoph, Greg) - fixed a few more places where dma api was still being used (e.g. td_alloc, ed_alloc) (Fredrik) - included patch from Fredrik adding gen_pool_dma_zalloc() api - added patch that drops HCD_LOCAL_MEM altogether (Greg) - set td_cache / ed_cache to null for devices with local mem (Fredrik) - introduce usb_hcd_setup_local_mem() that sets up the genalloc pool for drivers and updated drivers to use it Changes in v4: - created mapping for local mem - fix genalloc misuse Changes in v3: - rearranged calls into genalloc simplifying the code a bit (Christoph) - dropped RFC prefix Changes in v2: - use genalloc also in core usb (based on comment from Robin) - moved genpool decl to usb_hcd to be accesible from core usb Fredrik Noring (1): lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations Laurentiu Tudor (4): USB: use genalloc for USB HCs with local memory usb: host: ohci-sm501: init genalloc for local memory usb: host: ohci-tmio: init genalloc for local memory USB: drop HCD_LOCAL_MEM flag drivers/usb/core/buffer.c | 17 drivers/usb/core/hcd.c | 51 -- drivers/usb/host/ehci-hcd.c| 2 +- drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/ohci-hcd.c| 25 + drivers/usb/host/ohci-mem.c| 35 --- drivers/usb/host/ohci-sm501.c | 50 +++-- drivers/usb/host/ohci-tmio.c | 15 -- drivers/usb/host/ohci.h| 2 ++ drivers/usb/host/uhci-hcd.c| 2 +- include/linux/genalloc.h | 1 + include/linux/usb/hcd.h| 6 +++- lib/genalloc.c | 29 ++- 13 files changed, 171 insertions(+), 66 deletions(-) -- 2.17.1
[PATCH v6 1/5] lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations
From: Fredrik Noring
gen_pool_dma_zalloc() is a zeroed memory variant of gen_pool_dma_alloc().
Document return values of both, and indicate NULL as a "%NULL" constant.
Signed-off-by: Fredrik Noring
Tested-by: Fredrik Noring
---
include/linux/genalloc.h | 1 +
lib/genalloc.c | 29 -
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index dd0a452373e7..6c62eeca754f 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -121,6 +121,7 @@ extern unsigned long gen_pool_alloc_algo(struct gen_pool *,
size_t,
genpool_algo_t algo, void *data);
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
+void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 7e85d1e37a6e..5db43476a19b 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -337,12 +337,14 @@ EXPORT_SYMBOL(gen_pool_alloc_algo);
* gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
* @pool: pool to allocate from
* @size: number of bytes to allocate from the pool
- * @dma: dma-view physical address return value. Use NULL if unneeded.
+ * @dma: dma-view physical address return value. Use %NULL if unneeded.
*
* Allocate the requested number of bytes from the specified pool.
* Uses the pool allocation function (with first-fit algorithm by default).
* Can not be used in NMI handler on architectures without
* NMI-safe cmpxchg implementation.
+ *
+ * Return: virtual address of the allocated memory, or %NULL on failure
*/
void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
{
@@ -362,6 +364,31 @@ void *gen_pool_dma_alloc(struct gen_pool *pool, size_t
size, dma_addr_t *dma)
}
EXPORT_SYMBOL(gen_pool_dma_alloc);
+/**
+ * gen_pool_dma_zalloc - allocate special zeroed memory from the pool for
+ * DMA usage
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @dma: dma-view physical address return value. Use %NULL if unneeded.
+ *
+ * Allocate the requested number of zeroed bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ *
+ * Return: virtual address of the allocated zeroed memory, or %NULL on failure
+ */
+void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
+{
+ void *vaddr = gen_pool_dma_alloc(pool, size, dma);
+
+ if (vaddr)
+ memset(vaddr, 0, size);
+
+ return vaddr;
+}
+EXPORT_SYMBOL(gen_pool_dma_zalloc);
+
/**
* gen_pool_free - free allocated special memory back to the pool
* @pool: pool to free to
--
2.17.1
[PATCH v6 2/5] USB: use genalloc for USB HCs with local memory
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices. To help users, introduce a new HCD API,
usb_hcd_setup_local_mem() that will setup up the genalloc backing
up the device local memory. It will be used in subsequent patches.
This is in preparation for dropping the existing "coherent" dma
mem declaration APIs. Current implementation was relying on a short
circuit in the DMA API that in the end, was acting as an allocator
for these type of devices.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
Signed-off-by: Fredrik Noring
Tested-by: Fredrik Noring
---
drivers/usb/core/buffer.c | 9 +
drivers/usb/core/hcd.c | 36
drivers/usb/host/ohci-hcd.c | 23 ++-
drivers/usb/host/ohci-mem.c | 35 +++
drivers/usb/host/ohci.h | 2 ++
include/linux/usb/hcd.h | 5 +
6 files changed, 101 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index f641342cdec0..d2064ad7ad14 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -124,6 +125,9 @@ void *hcd_buffer_alloc(
if (size == 0)
return NULL;
+ if (hcd->localmem_pool)
+ return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
+
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(bus->sysdev) &&
@@ -152,6 +156,11 @@ void hcd_buffer_free(
if (!addr)
return;
+ if (hcd->localmem_pool) {
+ gen_pool_free(hcd->localmem_pool, (unsigned long)addr, size);
+ return;
+ }
+
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(bus->sysdev) &&
!(hcd->driver->flags & HCD_LOCAL_MEM))) {
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 94d22551fc1b..1aad11f4142c 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -3039,6 +3041,40 @@ usb_hcd_platform_shutdown(struct platform_device *dev)
}
EXPORT_SYMBOL_GPL(usb_hcd_platform_shutdown);
+int usb_hcd_setup_local_mem(struct usb_hcd *hcd, phys_addr_t phys_addr,
+ dma_addr_t dma, size_t size)
+{
+ int err;
+ void __iomem *local_mem;
+
+ hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, PAGE_SHIFT,
+ dev_to_node(hcd->self.sysdev),
+ dev_name(hcd->self.sysdev));
+ if (IS_ERR(hcd->localmem_pool))
+ return PTR_ERR(hcd->localmem_pool);
+
+ local_mem = devm_memremap(hcd->self.sysdev, phys_addr,
+ size, MEMREMAP_WC);
+ if (!local_mem)
+ return -ENOMEM;
+
+ /*
+* Here we pass a dma_addr_t but the arg type is a phys_addr_t.
+* It's not backed by system memory and thus there's no kernel mapping
+* for it.
+*/
+ err = gen_pool_add_virt(hcd->localmem_pool, (unsigned long)local_mem,
+ dma, size, dev_to_node(hcd->self.sysdev));
+ if (err < 0) {
+ dev_err(hcd->self.sysdev, "gen_pool_add_virt failed with %d\n",
+ err);
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_hcd_setup_local_mem);
+
/*-*/
#if IS_ENABLED(CONFIG_USB_MON)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 210181fd98d2..b200b19b44fa 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -505,8 +506,15 @@ static int ohci_init (struct ohci_hcd *ohci)
timer_setup(>io_watchdog, io_watchdog_func, 0);
ohci->prev_frame_no = IO_WATCHDOG_OFF;
- ohci->hcca = dma_alloc_coherent (hcd->self.controller,
- sizeof(*ohci->hcca), >hcca_dma, GFP_KERNEL);
+ if (hcd->localmem_pool)
+ ohci->hcca = gen_pool_dma_alloc(hcd->localmem_pool,
+ sizeof(*ohci->hcca),
+ >hcca_dma);
+ else
+ ohci->hcca = dma_alloc_coherent(hcd->self.controller,
+ sizeof(*ohci->hcca),
+
[PATCH v6 3/5] usb: host: ohci-sm501: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-sm501.c | 47 +++
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index c26228c25f99..b710e100aec9 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -110,40 +110,18 @@ static int ohci_hcd_sm501_drv_probe(struct
platform_device *pdev)
goto err0;
}
- /* The sm501 chip is equipped with local memory that may be used
-* by on-chip devices such as the video controller and the usb host.
-* This driver uses dma_declare_coherent_memory() to make sure
-* usb allocations with dma_alloc_coherent() allocate from
-* this local memory. The dma_handle returned by dma_alloc_coherent()
-* will be an offset starting from 0 for the first local memory byte.
-*
-* So as long as data is allocated using dma_alloc_coherent() all is
-* fine. This is however not always the case - buffers may be allocated
-* using kmalloc() - so the usb core needs to be told that it must copy
-* data into our local memory if the buffers happen to be placed in
-* regular memory. The HCD_LOCAL_MEM flag does just that.
-*/
-
- retval = dma_declare_coherent_memory(dev, mem->start,
-mem->start - mem->parent->start,
-resource_size(mem));
- if (retval) {
- dev_err(dev, "cannot declare coherent memory\n");
- goto err1;
- }
-
/* allocate, reserve and remap resources for registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(dev, "no resource definition for registers\n");
retval = -ENOENT;
- goto err2;
+ goto err1;
}
hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
if (!hcd) {
retval = -ENOMEM;
- goto err2;
+ goto err1;
}
hcd->rsrc_start = res->start;
@@ -164,6 +142,24 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
ohci_hcd_init(hcd_to_ohci(hcd));
+ /* The sm501 chip is equipped with local memory that may be used
+* by on-chip devices such as the video controller and the usb host.
+* This driver uses genalloc so that usb allocations with
+* gen_pool_dma_alloc() allocate from this local memory. The dma_handle
+* returned by gen_pool_dma_alloc() will be an offset starting from 0
+* for the first local memory byte.
+*
+* So as long as data is allocated using gen_pool_dma_alloc() all is
+* fine. This is however not always the case - buffers may be allocated
+* using kmalloc() - so the usb core needs to be told that it must copy
+* data into our local memory if the buffers happen to be placed in
+* regular memory. The HCD_LOCAL_MEM flag does just that.
+*/
+
+ if (usb_hcd_setup_local_mem(hcd, mem->start,
+ mem->start - mem->parent->start,
+ resource_size(mem)) < 0)
+ goto err5;
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval)
goto err5;
@@ -181,8 +177,6 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
err3:
usb_put_hcd(hcd);
-err2:
- dma_release_declared_memory(dev);
err1:
release_mem_region(mem->start, resource_size(mem));
err0:
@@ -197,7 +191,6 @@ static int ohci_hcd_sm501_drv_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
- dma_release_declared_memory(>dev);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (mem)
release_mem_region(mem->start, resource_size(mem));
--
2.17.1
Re: [PATCH v5 2/5] USB: use genalloc for USB HCs with local memory
On 21.05.2019 18:27, Fredrik Noring wrote:
> Thanks Laurentiu!
>
>> --- a/include/linux/usb/hcd.h
>> +++ b/include/linux/usb/hcd.h
>> @@ -216,6 +216,9 @@ struct usb_hcd {
>> #defineHC_IS_RUNNING(state) ((state) & __ACTIVE)
>> #defineHC_IS_SUSPENDED(state) ((state) & __SUSPEND)
>>
>> +/* allocator for HCs having local memory */
>> +struct gen_pool *localmem_pool;
>> +
>
> I have tested patches 1, 2 and 5, and they seem to work. Nice!
Great! Thanks for testing. I'll add your Tested-By tags on the patches
you mentioned.
> May I suggest clarifying the NULL pointers? I think that may help someone
> debugging or maintaining this in the future. Something like this:
Sure, will include in v6.
---
Best Regards, Laurentiu
Re: [PATCH v5 2/5] USB: use genalloc for USB HCs with local memory
Hello Alan,
On 21.05.2019 20:20, Alan Stern wrote:
> On Tue, 21 May 2019 laurentiu.tu...@nxp.com wrote:
>
>> From: Laurentiu Tudor
>>
>> For HCs that have local memory, replace the current DMA API usage
>> with a genalloc generic allocator to manage the mappings for these
>> devices. To help users, introduce a new HCD API,
>> usb_hcd_setup_local_mem() that will setup up the genalloc backing
>> up the device local memory. It will be used in subsequent patches.
>> This is in preparation for dropping the existing "coherent" dma
>> mem declaration APIs. Current implementation was relying on a short
>> circuit in the DMA API that in the end, was acting as an allocator
>> for these type of devices.
>>
>> For context, see thread here:
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F4%2F22%2F357data=02%7C01%7Claurentiu.tudor%40nxp.com%7Cdc4a76b04b874b75bd5408d6de109d86%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636940560281957207sdata=JQ1iJc%2Fw%2BwHdTFvaOT%2FYHBx%2BVQlpHWlf346q7sclfcg%3Dreserved=0
>>
>> Signed-off-by: Laurentiu Tudor
>> Signed-off-by: Fredrik Noring
>> ---
>
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -29,6 +29,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>> #include
>> @@ -3039,6 +3041,40 @@ usb_hcd_platform_shutdown(struct platform_device *dev)
>> }
>> EXPORT_SYMBOL_GPL(usb_hcd_platform_shutdown);
>>
>> +int usb_hcd_setup_local_mem(struct usb_hcd *hcd, phys_addr_t phys_addr,
>> +dma_addr_t dma, size_t size)
>> +{
>> +int err;
>> +void __iomem *local_mem;
>> +
>> +hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, PAGE_SHIFT,
>> + dev_to_node(hcd->self.sysdev),
>> + "ohci-hcd");
>
> Surely that string is a mistake. You could use
> dev_name(hcd->self.sysdev) or a name passed by the caller.
Sorry, missed that. Will go with dev_name() if that's ok with you.
>> +if (IS_ERR(hcd->localmem_pool))
>> +return PTR_ERR(hcd->localmem_pool);
>> +
>> +local_mem = devm_memremap(hcd->self.sysdev, phys_addr,
>> + size, MEMREMAP_WC);
>> +if (!local_mem)
>> +return -ENOMEM;
>> +
>> +/*
>> + * Here we pass a dma_addr_t but the arg type is a phys_addr_t.
>> + * It's not backed by system memory and thus there's no kernel mapping
>> + * for it.
>> + */
>> +err = gen_pool_add_virt(hcd->localmem_pool, (unsigned long)local_mem,
>> +dma, size, dev_to_node(hcd->self.sysdev));
>> +if (err < 0) {
>> +dev_err(hcd->self.sysdev, "gen_pool_add_virt failed with %d\n",
>> +err);
>> +return err;
>> +}
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_hcd_setup_local_mem);
>
> If you have a usb_hcd_setup_local_mem() function then you should also
> have a usb_hcd_remove_local_mem() function.
Even if all resources that are allocated are device managed?
>> --- a/drivers/usb/host/ohci-mem.c
>> +++ b/drivers/usb/host/ohci-mem.c
>> @@ -36,6 +36,12 @@ static void ohci_hcd_init (struct ohci_hcd *ohci)
>>
>> static int ohci_mem_init (struct ohci_hcd *ohci)
>> {
>> +if (ohci_to_hcd(ohci)->localmem_pool) {
>> +ohci->td_cache = NULL;
>> +ohci->ed_cache = NULL;
>> +return 0;
>> +}
>
> This really isn't necessary. The entire ohci_hcd structure is
> initialized to 0 when it is first allocated.
Will drop.
>> --- a/include/linux/usb/hcd.h
>> +++ b/include/linux/usb/hcd.h
>> @@ -216,6 +216,9 @@ struct usb_hcd {
>> #defineHC_IS_RUNNING(state) ((state) & __ACTIVE)
>> #defineHC_IS_SUSPENDED(state) ((state) & __SUSPEND)
>>
>> +/* allocator for HCs having local memory */
>
> "allocator" is the wrong word -- an allocator is something that
> allocates. Perhaps "memory area" or something along those lines.
Alright, I will rework.
---
Thanks & Best Regards, Laurentiu
[PATCH v5 0/5] prerequisites for device reserved local mem rework
From: Laurentiu Tudor For HCs that have local memory, replace the current DMA API usage with a genalloc generic allocator to manage the mappings for these devices. This is in preparation for dropping the existing "coherent" dma mem declaration APIs. Current implementation was relying on a short circuit in the DMA API that in the end, was acting as an allocator for these type of devices. Only compiled tested, so any volunteers willing to test are most welcome. Thank you! For context, see thread here: https://lkml.org/lkml/2019/4/22/357 Changes in v5: - updated first patch to preserve bisectability (Christoph, Greg) - fixed a few more places where dma api was still being used (e.g. td_alloc, ed_alloc) (Fredrik) - included patch from Fredrik adding gen_pool_dma_zalloc() api - added patch that drops HCD_LOCAL_MEM altogether (Greg) - set td_cache / ed_cache to null for devices with local mem (Fredrik) - introduce usb_hcd_setup_local_mem() that sets up the genalloc pool for drivers and updated drivers to use it Changes in v4: - created mapping for local mem - fix genalloc misuse Changes in v3: - rearranged calls into genalloc simplifying the code a bit (Christoph) - dropped RFC prefix Changes in v2: - use genalloc also in core usb (based on comment from Robin) - moved genpool decl to usb_hcd to be accesible from core usb Fredrik Noring (1): lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations Laurentiu Tudor (4): USB: use genalloc for USB HCs with local memory usb: host: ohci-sm501: init genalloc for local memory usb: host: ohci-tmio: init genalloc for local memory USB: drop HCD_LOCAL_MEM flag drivers/usb/core/buffer.c | 17 drivers/usb/core/hcd.c | 51 -- drivers/usb/host/ehci-hcd.c| 2 +- drivers/usb/host/fotg210-hcd.c | 2 +- drivers/usb/host/ohci-hcd.c| 25 + drivers/usb/host/ohci-mem.c| 34 --- drivers/usb/host/ohci-sm501.c | 50 +++-- drivers/usb/host/ohci-tmio.c | 15 -- drivers/usb/host/uhci-hcd.c| 2 +- include/linux/genalloc.h | 1 + include/linux/usb/hcd.h| 6 +++- lib/genalloc.c | 29 ++- 12 files changed, 168 insertions(+), 66 deletions(-) -- 2.17.1
[PATCH v5 5/5] USB: drop HCD_LOCAL_MEM flag
From: Laurentiu Tudor
With the addition of the local memory allocator, the HCD_LOCAL_MEM
flag can be dropped and the checks against it replaced with a check
for the localmem_pool ptr being initialized.
Signed-off-by: Laurentiu Tudor
---
drivers/usb/core/buffer.c | 8 +++-
drivers/usb/core/hcd.c | 15 ++-
drivers/usb/host/ehci-hcd.c| 2 +-
drivers/usb/host/fotg210-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c| 2 +-
drivers/usb/host/ohci-sm501.c | 5 +++--
drivers/usb/host/ohci-tmio.c | 2 +-
drivers/usb/host/uhci-hcd.c| 2 +-
include/linux/usb/hcd.h| 1 -
9 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index d2064ad7ad14..1359b78a624e 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -68,7 +68,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(hcd->self.sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM)))
+!hcd->localmem_pool))
return 0;
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
@@ -130,8 +130,7 @@ void *hcd_buffer_alloc(
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
@@ -162,8 +161,7 @@ void hcd_buffer_free(
}
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
kfree(addr);
return;
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index a1aa54f2db20..95b8b7483c3d 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1347,14 +1347,14 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* using regular system memory - like pci devices doing bus mastering.
*
* To support host controllers with limited dma capabilities we provide dma
- * bounce buffers. This feature can be enabled using the HCD_LOCAL_MEM flag.
+ * bounce buffers. This feature can be enabled by initializing
+ * hcd->localmem_pool using usb_hcd_setup_local_mem().
* For this to work properly the host controller code must first use the
* function dma_declare_coherent_memory() to point out which memory area
* that should be used for dma allocations.
*
- * The HCD_LOCAL_MEM flag then tells the usb code to allocate all data for
- * dma using dma_alloc_coherent() which in turn allocates from the memory
- * area pointed out with dma_declare_coherent_memory().
+ * The initialized hcd->localmem_pool then tells the usb code to allocate all
+ * data for dma using the genalloc API.
*
* So, to summarize...
*
@@ -1364,9 +1364,6 @@ EXPORT_SYMBOL_GPL(usb_hcd_unlink_urb_from_ep);
* (a) "normal" kernel memory is no good, and
* (b) there's not enough to share
*
- * - The only *portable* hook for such stuff in the
- * DMA framework is dma_declare_coherent_memory()
- *
* - So we use that, even though the primary requirement
* is that the memory be "local" (hence addressable
* by that device), not "coherent".
@@ -1533,7 +1530,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
urb->setup_dma))
return -EAGAIN;
urb->transfer_flags |= URB_SETUP_MAP_SINGLE;
- } else if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ } else if (hcd->localmem_pool) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
>setup_dma,
@@ -1603,7 +1600,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
else
urb->transfer_flags |=
URB_DMA_MAP_SINGLE;
}
- } else if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ } else if (hcd->localmem_pool) {
ret = hcd_alloc_coherent(
urb->dev->bus, mem_flags,
>transfer_dma,
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index cdafa97f632d..9da7e22848c9 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -559,7 +559,7 @@ static int ehci_init(struct usb_hcd *hcd)
ehci->command = temp;
/* Accept arbitrarily long scatte
[PATCH v5 3/5] usb: host: ohci-sm501: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-sm501.c | 47 +++
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index c26228c25f99..b710e100aec9 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -110,40 +110,18 @@ static int ohci_hcd_sm501_drv_probe(struct
platform_device *pdev)
goto err0;
}
- /* The sm501 chip is equipped with local memory that may be used
-* by on-chip devices such as the video controller and the usb host.
-* This driver uses dma_declare_coherent_memory() to make sure
-* usb allocations with dma_alloc_coherent() allocate from
-* this local memory. The dma_handle returned by dma_alloc_coherent()
-* will be an offset starting from 0 for the first local memory byte.
-*
-* So as long as data is allocated using dma_alloc_coherent() all is
-* fine. This is however not always the case - buffers may be allocated
-* using kmalloc() - so the usb core needs to be told that it must copy
-* data into our local memory if the buffers happen to be placed in
-* regular memory. The HCD_LOCAL_MEM flag does just that.
-*/
-
- retval = dma_declare_coherent_memory(dev, mem->start,
-mem->start - mem->parent->start,
-resource_size(mem));
- if (retval) {
- dev_err(dev, "cannot declare coherent memory\n");
- goto err1;
- }
-
/* allocate, reserve and remap resources for registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(dev, "no resource definition for registers\n");
retval = -ENOENT;
- goto err2;
+ goto err1;
}
hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
if (!hcd) {
retval = -ENOMEM;
- goto err2;
+ goto err1;
}
hcd->rsrc_start = res->start;
@@ -164,6 +142,24 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
ohci_hcd_init(hcd_to_ohci(hcd));
+ /* The sm501 chip is equipped with local memory that may be used
+* by on-chip devices such as the video controller and the usb host.
+* This driver uses genalloc so that usb allocations with
+* gen_pool_dma_alloc() allocate from this local memory. The dma_handle
+* returned by gen_pool_dma_alloc() will be an offset starting from 0
+* for the first local memory byte.
+*
+* So as long as data is allocated using gen_pool_dma_alloc() all is
+* fine. This is however not always the case - buffers may be allocated
+* using kmalloc() - so the usb core needs to be told that it must copy
+* data into our local memory if the buffers happen to be placed in
+* regular memory. The HCD_LOCAL_MEM flag does just that.
+*/
+
+ if (usb_hcd_setup_local_mem(hcd, mem->start,
+ mem->start - mem->parent->start,
+ resource_size(mem)) < 0)
+ goto err5;
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval)
goto err5;
@@ -181,8 +177,6 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
err3:
usb_put_hcd(hcd);
-err2:
- dma_release_declared_memory(dev);
err1:
release_mem_region(mem->start, resource_size(mem));
err0:
@@ -197,7 +191,6 @@ static int ohci_hcd_sm501_drv_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
- dma_release_declared_memory(>dev);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
if (mem)
release_mem_region(mem->start, resource_size(mem));
--
2.17.1
[PATCH v5 2/5] USB: use genalloc for USB HCs with local memory
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices. To help users, introduce a new HCD API,
usb_hcd_setup_local_mem() that will setup up the genalloc backing
up the device local memory. It will be used in subsequent patches.
This is in preparation for dropping the existing "coherent" dma
mem declaration APIs. Current implementation was relying on a short
circuit in the DMA API that in the end, was acting as an allocator
for these type of devices.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
Signed-off-by: Fredrik Noring
---
drivers/usb/core/buffer.c | 9 +
drivers/usb/core/hcd.c | 36
drivers/usb/host/ohci-hcd.c | 23 ++-
drivers/usb/host/ohci-mem.c | 34 ++
include/linux/usb/hcd.h | 5 +
5 files changed, 98 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index f641342cdec0..d2064ad7ad14 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -124,6 +125,9 @@ void *hcd_buffer_alloc(
if (size == 0)
return NULL;
+ if (hcd->localmem_pool)
+ return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
+
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(bus->sysdev) &&
@@ -152,6 +156,11 @@ void hcd_buffer_free(
if (!addr)
return;
+ if (hcd->localmem_pool) {
+ gen_pool_free(hcd->localmem_pool, (unsigned long)addr, size);
+ return;
+ }
+
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
(!is_device_dma_capable(bus->sysdev) &&
!(hcd->driver->flags & HCD_LOCAL_MEM))) {
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 94d22551fc1b..a1aa54f2db20 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -3039,6 +3041,40 @@ usb_hcd_platform_shutdown(struct platform_device *dev)
}
EXPORT_SYMBOL_GPL(usb_hcd_platform_shutdown);
+int usb_hcd_setup_local_mem(struct usb_hcd *hcd, phys_addr_t phys_addr,
+ dma_addr_t dma, size_t size)
+{
+ int err;
+ void __iomem *local_mem;
+
+ hcd->localmem_pool = devm_gen_pool_create(hcd->self.sysdev, PAGE_SHIFT,
+ dev_to_node(hcd->self.sysdev),
+ "ohci-hcd");
+ if (IS_ERR(hcd->localmem_pool))
+ return PTR_ERR(hcd->localmem_pool);
+
+ local_mem = devm_memremap(hcd->self.sysdev, phys_addr,
+ size, MEMREMAP_WC);
+ if (!local_mem)
+ return -ENOMEM;
+
+ /*
+* Here we pass a dma_addr_t but the arg type is a phys_addr_t.
+* It's not backed by system memory and thus there's no kernel mapping
+* for it.
+*/
+ err = gen_pool_add_virt(hcd->localmem_pool, (unsigned long)local_mem,
+ dma, size, dev_to_node(hcd->self.sysdev));
+ if (err < 0) {
+ dev_err(hcd->self.sysdev, "gen_pool_add_virt failed with %d\n",
+ err);
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_hcd_setup_local_mem);
+
/*-*/
#if IS_ENABLED(CONFIG_USB_MON)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 210181fd98d2..b200b19b44fa 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -505,8 +506,15 @@ static int ohci_init (struct ohci_hcd *ohci)
timer_setup(>io_watchdog, io_watchdog_func, 0);
ohci->prev_frame_no = IO_WATCHDOG_OFF;
- ohci->hcca = dma_alloc_coherent (hcd->self.controller,
- sizeof(*ohci->hcca), >hcca_dma, GFP_KERNEL);
+ if (hcd->localmem_pool)
+ ohci->hcca = gen_pool_dma_alloc(hcd->localmem_pool,
+ sizeof(*ohci->hcca),
+ >hcca_dma);
+ else
+ ohci->hcca = dma_alloc_coherent(hcd->self.controller,
+ sizeof(*ohci->hcca),
+ >hcca_dma,
+
[PATCH v5 4/5] usb: host: ohci-tmio: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-tmio.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index f88a0370659f..3b84ce0c3f29 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -224,11 +224,6 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
goto err_ioremap_regs;
}
- ret = dma_declare_coherent_memory(>dev, sram->start, sram->start,
- resource_size(sram));
- if (ret)
- goto err_dma_declare;
-
if (cell->enable) {
ret = cell->enable(dev);
if (ret)
@@ -239,6 +234,11 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
+ ret = usb_hcd_setup_local_mem(hcd, sram->start, sram->start,
+ resource_size(sram));
+ if (ret < 0)
+ goto err_enable;
+
ret = usb_add_hcd(hcd, irq, 0);
if (ret)
goto err_add_hcd;
@@ -254,8 +254,6 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device
*dev)
if (cell->disable)
cell->disable(dev);
err_enable:
- dma_release_declared_memory(>dev);
-err_dma_declare:
iounmap(hcd->regs);
err_ioremap_regs:
iounmap(tmio->ccr);
@@ -276,7 +274,6 @@ static int ohci_hcd_tmio_drv_remove(struct platform_device
*dev)
tmio_stop_hc(dev);
if (cell->disable)
cell->disable(dev);
- dma_release_declared_memory(>dev);
iounmap(hcd->regs);
iounmap(tmio->ccr);
usb_put_hcd(hcd);
--
2.17.1
[PATCH v5 1/5] lib/genalloc.c: Add gen_pool_dma_zalloc() for zeroed DMA allocations
From: Fredrik Noring
gen_pool_dma_zalloc() is a zeroed memory variant of gen_pool_dma_alloc().
Document return values of both, and indicate NULL as a "%NULL" constant.
Signed-off-by: Fredrik Noring
---
include/linux/genalloc.h | 1 +
lib/genalloc.c | 29 -
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index dd0a452373e7..6c62eeca754f 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -121,6 +121,7 @@ extern unsigned long gen_pool_alloc_algo(struct gen_pool *,
size_t,
genpool_algo_t algo, void *data);
extern void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size,
dma_addr_t *dma);
+void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
extern void gen_pool_for_each_chunk(struct gen_pool *,
void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 7e85d1e37a6e..5db43476a19b 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -337,12 +337,14 @@ EXPORT_SYMBOL(gen_pool_alloc_algo);
* gen_pool_dma_alloc - allocate special memory from the pool for DMA usage
* @pool: pool to allocate from
* @size: number of bytes to allocate from the pool
- * @dma: dma-view physical address return value. Use NULL if unneeded.
+ * @dma: dma-view physical address return value. Use %NULL if unneeded.
*
* Allocate the requested number of bytes from the specified pool.
* Uses the pool allocation function (with first-fit algorithm by default).
* Can not be used in NMI handler on architectures without
* NMI-safe cmpxchg implementation.
+ *
+ * Return: virtual address of the allocated memory, or %NULL on failure
*/
void *gen_pool_dma_alloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
{
@@ -362,6 +364,31 @@ void *gen_pool_dma_alloc(struct gen_pool *pool, size_t
size, dma_addr_t *dma)
}
EXPORT_SYMBOL(gen_pool_dma_alloc);
+/**
+ * gen_pool_dma_zalloc - allocate special zeroed memory from the pool for
+ * DMA usage
+ * @pool: pool to allocate from
+ * @size: number of bytes to allocate from the pool
+ * @dma: dma-view physical address return value. Use %NULL if unneeded.
+ *
+ * Allocate the requested number of zeroed bytes from the specified pool.
+ * Uses the pool allocation function (with first-fit algorithm by default).
+ * Can not be used in NMI handler on architectures without
+ * NMI-safe cmpxchg implementation.
+ *
+ * Return: virtual address of the allocated zeroed memory, or %NULL on failure
+ */
+void *gen_pool_dma_zalloc(struct gen_pool *pool, size_t size, dma_addr_t *dma)
+{
+ void *vaddr = gen_pool_dma_alloc(pool, size, dma);
+
+ if (vaddr)
+ memset(vaddr, 0, size);
+
+ return vaddr;
+}
+EXPORT_SYMBOL(gen_pool_dma_zalloc);
+
/**
* gen_pool_free - free allocated special memory back to the pool
* @pool: pool to free to
--
2.17.1
Re: [PATCH v4 2/3] usb: host: ohci-sm501: init genalloc for local memory
On 21.05.2019 13:39, Christoph Hellwig wrote:
> On Thu, May 16, 2019 at 02:47:20PM +0300, laurentiu.tu...@nxp.com wrote:
>> +hcd->localmem_pool = devm_gen_pool_create(dev, PAGE_SHIFT,
>> + dev_to_node(dev),
>> + "ohci-sm501");
>> +if (IS_ERR(hcd->localmem_pool)) {
>> +retval = PTR_ERR(hcd->localmem_pool);
>> +goto err5;
>> +}
>> +
>> +local_mem = devm_ioremap(dev, mem->start, resource_size(mem));
>> +if (!local_mem) {
>> +retval = -ENOMEM;
>> +goto err5;
>> +}
>> +
>> +retval = gen_pool_add_virt(hcd->localmem_pool,
>> + (unsigned long)local_mem,
>> + mem->start - mem->parent->start,
>> + resource_size(mem),
>> + dev_to_node(dev));
>
> I wonder if having a helper for these operations would be useful,
> explaining what we do here. That is create a pool for a resource,
> where the virtual address is the ioremap of said resource. We
> could also make that a managed API so that you can get rid of the
> cleanup path.
This is close to what I've already prepared in the next spin. It's a new
usb hcd api so it's not as abstract as your idea. I think we can discuss
on it after I'll send it.
---
Best Regards, Laurentiu
Re: [PATCH v4 1/3] USB: use genalloc for USB HCs with local memory
On 21.05.2019 11:16, Greg KH wrote: > On Thu, May 16, 2019 at 02:47:19PM +0300, laurentiu.tu...@nxp.com wrote: >> From: Laurentiu Tudor >> >> For HCs that have local memory, replace the current DMA API usage >> with a genalloc generic allocator to manage the mappings for these >> devices. >> This is in preparation for dropping the existing "coherent" dma >> mem declaration APIs. Current implementation was relying on a short >> circuit in the DMA API that in the end, was acting as an allocator >> for these type of devices. >> >> For context, see thread here: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F4%2F22%2F357data=02%7C01%7Claurentiu.tudor%40nxp.com%7Cf5242fb28d154ff9653208d6ddc4b41c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636940234237524499sdata=KEEUP1KH%2BaraWcVKogeYBzrauh%2FFTzGjSxjk%2BuNozjA%3Dreserved=0 >> >> Signed-off-by: Laurentiu Tudor >> --- >> drivers/usb/core/buffer.c | 15 +++ >> drivers/usb/host/ohci-hcd.c | 23 ++- >> include/linux/usb/hcd.h | 3 +++ >> 3 files changed, 32 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c >> index f641342cdec0..22a8f3f5679b 100644 >> --- a/drivers/usb/core/buffer.c >> +++ b/drivers/usb/core/buffer.c >> @@ -16,6 +16,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> @@ -124,10 +125,12 @@ void *hcd_buffer_alloc( >> if (size == 0) >> return NULL; >> >> +if (hcd->driver->flags & HCD_LOCAL_MEM) >> +return gen_pool_dma_alloc(hcd->localmem_pool, size, dma); > > Does this patch now break things? hcd->localmem_pool at this point in > time is NULL, so this call will fail. There's no chance for any host > controller driver to actually set up this pool in this patch, so is > bisection broken? Unfortunately, yes. I could lump the patches together but I think Christoph suggestion is much better. > I think you fix this up in later patches, right? Correct. The last 2 patches update the driver. > And if so, why do we even need HCD_LOCAL_MEM anymore? Can't we just > test for the presence of hcd->localmem_pool in order to determine which > allocation method to use? Sure. There are a few more places that need updates but no big deal. --- Best Regards, Laurentiu
Re: [RFC PATCH v2 0/3] prerequisites for device reserved local mem rework
Hello Fredrik, On 17.05.2019 20:41, Fredrik Noring wrote: > Hi Laurentiu, > >>> that I tracked down to the calls >>> >>>hub_port_init >>> -> usb_control_msg >>> -> usb_internal_control_msg >>> -> usb_start_wait_urb >>> -> usb_submit_urb >>> -> usb_hcd_submit_urb >>> -> hcd->driver->urb_enqueue >>> -> ohci_urb_enqueue >>> -> ed_get >>> -> ed_alloc > > I found that the generic OHCI driver takes a wrong turn here, in ed_alloc, > and eventually also in td_alloc. Fortunately, your patch can be easily > extended to fix them as well. Please see attached patch below. > > With that, the OHCI seems to work as expected with HCD_LOCAL_MEM. :) Wow, that's excellent news! Thanks a lot for looking into this. Are you ok if I add your Signed-Off-by and maybe also Tested-by in the first patch of the series? As a side note, I plan to add a new HCD function and name it something like hcd_setup_local_mem() that would take care of setting up the genalloc for drivers. > Would you like me to submit gen_pool_dma_zalloc as a separate patch? Yes, I think it would make sense to put the new API in a distinct patch. I think we can either include it in the next version of the patch series or you can submit separately and I'll mention it as dependency for this patch series, however you prefer. --- Thanks & Best Regards, Laurentiu
Re: [GIT PULL] updates to soc/fsl drivers for v5.2
Hello, Did this pull request somehow slipped through? --- Thanks & Best Regards, Laurentiu On 01.05.2019 23:37, Li Yang wrote: > Hi arm-soc maintainers, > > Please help to merge for-next patches for the upcoming merge window. Thanks > > Regards, > Leo > > > The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: > >Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) > > are available in the Git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git > tags/soc-fsl-next-v5.2 > > for you to fetch changes up to 1c8f39946c033de08e382025d7ac7f55fbca57eb: > >soc: fsl: qbman_portals: add APIs to retrieve the probing status > (2019-05-01 15:09:59 -0500) > > > NXP/FSL SoC driver updates for v5.2 > > DPAA2 Console driver > - Add driver to export two char devices to dump logs for MC and >AIOP > > DPAA2 DPIO driver > - Add support for memory backed QBMan portals > - Increase the timeout period to prevent false error > - Add APIs to retrieve QBMan portal probing status > > DPAA Qman driver > - Only make liodn fixup on powerpc SoCs with PAMU iommu > > Guts driver > - Add definition for LX2160a SoC > > > Ioana Ciornei (2): >Documentation: DT: Add entry for DPAA2 console >soc: fsl: add DPAA2 console support > > Laurentiu Tudor (2): >soc: fsl: qman: fixup liodns only on ppc targets >soc: fsl: qbman_portals: add APIs to retrieve the probing status > > Roy Pledge (2): >bus: mc-bus: Add support for mapping shareable portals >soc: fsl: dpio: Add support for memory backed QBMan portals > > Vabhav Sharma (1): >soc: fsl: guts: Add definition for LX2160A > > Youri Querry (1): >soc: fsl: dpio: Increase timeout for QBMan Management Commands > > .../devicetree/bindings/misc/fsl,dpaa2-console.txt | 11 + > MAINTAINERS| 1 + > drivers/bus/fsl-mc/dprc.c | 30 +- > drivers/bus/fsl-mc/fsl-mc-bus.c| 15 +- > drivers/bus/fsl-mc/fsl-mc-private.h| 17 +- > drivers/soc/fsl/Kconfig| 10 + > drivers/soc/fsl/Makefile | 1 + > drivers/soc/fsl/dpaa2-console.c| 329 > + > drivers/soc/fsl/dpio/dpio-driver.c | 23 +- > drivers/soc/fsl/dpio/qbman-portal.c| 148 +++-- > drivers/soc/fsl/dpio/qbman-portal.h| 9 +- > drivers/soc/fsl/guts.c | 6 + > drivers/soc/fsl/qbman/bman_portal.c| 20 +- > drivers/soc/fsl/qbman/qman_ccsr.c | 2 +- > drivers/soc/fsl/qbman/qman_portal.c| 21 +- > drivers/soc/fsl/qbman/qman_priv.h | 9 +- > include/soc/fsl/bman.h | 8 + > include/soc/fsl/qman.h | 9 + > 18 files changed, 618 insertions(+), 51 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt > create mode 100644 drivers/soc/fsl/dpaa2-console.c > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kerneldata=02%7C01%7Claurentiu.tudor%40nxp.com%7Cce3ff1bdc08b445447e408d6ce757dc9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636923401346806528sdata=DXh5Men7Mw1lttFbJskOzdLfSMqClpMr9lu9qJQV5H8%3Dreserved=0 >
[PATCH v4 0/3] prerequisites for device reserved local mem rework
From: Laurentiu Tudor For HCs that have local memory, replace the current DMA API usage with a genalloc generic allocator to manage the mappings for these devices. This is in preparation for dropping the existing "coherent" dma mem declaration APIs. Current implementation was relying on a short circuit in the DMA API that in the end, was acting as an allocator for these type of devices. Only compiled tested, so any volunteers willing to test are most welcome. Thank you! For context, see thread here: https://lkml.org/lkml/2019/4/22/357 Changes in v4: - created mapping for local mem - fix genalloc misuse Changes in v3: - rearranged calls into genalloc simplifying the code a bit (Christoph) - dropped RFC prefix Changes in v2: - use genalloc also in core usb (based on comment from Robin) - moved genpool decl to usb_hcd to be accesible from core usb Laurentiu Tudor (3): USB: use genalloc for USB HCs with local memory usb: host: ohci-sm501: init genalloc for local memory usb: host: ohci-tmio: init genalloc for local memory drivers/usb/core/buffer.c | 15 +--- drivers/usb/host/ohci-hcd.c | 23 +--- drivers/usb/host/ohci-sm501.c | 66 +-- drivers/usb/host/ohci-tmio.c | 32 - include/linux/usb/hcd.h | 3 ++ 5 files changed, 95 insertions(+), 44 deletions(-) -- 2.17.1
[PATCH v3 2/3] usb: host: ohci-sm501: init genalloc for local memory
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/host/ohci-sm501.c | 60 +++
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index c26228c25f99..8b829eca04ab 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -110,40 +111,18 @@ static int ohci_hcd_sm501_drv_probe(struct
platform_device *pdev)
goto err0;
}
- /* The sm501 chip is equipped with local memory that may be used
-* by on-chip devices such as the video controller and the usb host.
-* This driver uses dma_declare_coherent_memory() to make sure
-* usb allocations with dma_alloc_coherent() allocate from
-* this local memory. The dma_handle returned by dma_alloc_coherent()
-* will be an offset starting from 0 for the first local memory byte.
-*
-* So as long as data is allocated using dma_alloc_coherent() all is
-* fine. This is however not always the case - buffers may be allocated
-* using kmalloc() - so the usb core needs to be told that it must copy
-* data into our local memory if the buffers happen to be placed in
-* regular memory. The HCD_LOCAL_MEM flag does just that.
-*/
-
- retval = dma_declare_coherent_memory(dev, mem->start,
-mem->start - mem->parent->start,
-resource_size(mem));
- if (retval) {
- dev_err(dev, "cannot declare coherent memory\n");
- goto err1;
- }
-
/* allocate, reserve and remap resources for registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(dev, "no resource definition for registers\n");
retval = -ENOENT;
- goto err2;
+ goto err1;
}
hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
if (!hcd) {
retval = -ENOMEM;
- goto err2;
+ goto err1;
}
hcd->rsrc_start = res->start;
@@ -164,6 +143,36 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
ohci_hcd_init(hcd_to_ohci(hcd));
+ /* The sm501 chip is equipped with local memory that may be used
+* by on-chip devices such as the video controller and the usb host.
+* This driver uses genalloc so that usb allocations with
+* gen_pool_dma_alloc() allocate from this local memory. The dma_handle
+* returned by gen_pool_dma_alloc() will be an offset starting from 0
+* for the first local memory byte.
+*
+* So as long as data is allocated using gen_pool_dma_alloc() all is
+* fine. This is however not always the case - buffers may be allocated
+* using kmalloc() - so the usb core needs to be told that it must copy
+* data into our local memory if the buffers happen to be placed in
+* regular memory. The HCD_LOCAL_MEM flag does just that.
+*/
+
+ hcd->localmem_pool = devm_gen_pool_create(dev, PAGE_SHIFT,
+ dev_to_node(dev),
+ "ohci-sm501");
+ if (IS_ERR(hcd->localmem_pool)) {
+ retval = PTR_ERR(hcd->localmem_pool);
+ goto err5;
+ }
+ retval = gen_pool_add_virt(hcd->localmem_pool,
+ (unsigned long)mem->start -
+ mem->parent->start,
+ mem->start, resource_size(mem),
+ dev_to_node(dev));
+ if (retval < 0) {
+ dev_err(dev, "failed to add to pool: %d\n", retval);
+ goto err5;
+ }
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval)
goto err5;
@@ -181,8 +190,6 @@ static int ohci_hcd_sm501_drv_probe(struct platform_device
*pdev)
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
err3:
usb_put_hcd(hcd);
-err2:
- dma_release_declared_memory(dev);
err1:
release_mem_region(mem->start, resource_size(mem));
err0:
@@ -197,7 +204,6 @@ static int ohci_hcd_sm501_drv_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
release_
[PATCH v3 0/3] prerequisites for device reserved local mem rework
From: Laurentiu Tudor For HCs that have local memory, replace the current DMA API usage with a genalloc generic allocator to manage the mappings for these devices. This is in preparation for dropping the existing "coherent" dma mem declaration APIs. Current implementation was relying on a short circuit in the DMA API that in the end, was acting as an allocator for these type of devices. Only compiled tested, so any volunteers willing to test are most welcome. Thank you! For context, see thread here: https://lkml.org/lkml/2019/4/22/357 Changes in v3: - rearranged calls into genalloc simplifying the code a bit (Christoph) - dropped RFC prefix Changes in v2: - use genalloc also in core usb (based on comment from Robin) - moved genpool decl to usb_hcd to be accesible from core usb Laurentiu Tudor (3): USB: use genalloc for USB HCs with local memory usb: host: ohci-sm501: init genalloc for local memory usb: host: ohci-tmio: init genalloc for local memory drivers/usb/core/buffer.c | 16 +++--- drivers/usb/host/ohci-hcd.c | 23 +++--- drivers/usb/host/ohci-sm501.c | 60 +++ drivers/usb/host/ohci-tmio.c | 23 +- include/linux/usb/hcd.h | 3 ++ 5 files changed, 81 insertions(+), 44 deletions(-) -- 2.17.1
[PATCH v3 1/3] USB: use genalloc for USB HCs with local memory
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices.
This is in preparation for dropping the existing "coherent" dma
mem declaration APIs. Current implementation was relying on a short
circuit in the DMA API that in the end, was acting as an allocator
for these type of devices.
For context, see thread here: https://lkml.org/lkml/2019/4/22/357
Signed-off-by: Laurentiu Tudor
---
drivers/usb/core/buffer.c | 16
drivers/usb/host/ohci-hcd.c | 23 ++-
include/linux/usb/hcd.h | 3 +++
3 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index f641342cdec0..09669208b032 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -124,10 +125,12 @@ void *hcd_buffer_alloc(
if (size == 0)
return NULL;
+ if (hcd->driver->flags & HCD_LOCAL_MEM)
+ return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
+
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
@@ -152,9 +155,14 @@ void hcd_buffer_free(
if (!addr)
return;
+ if (hcd->driver->flags & HCD_LOCAL_MEM) {
+ gen_pool_free(hcd->localmem_pool, (unsigned long)addr,
+ size);
+ return;
+ }
+
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
- (!is_device_dma_capable(bus->sysdev) &&
-!(hcd->driver->flags & HCD_LOCAL_MEM))) {
+ !is_device_dma_capable(bus->sysdev)) {
kfree(addr);
return;
}
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 210181fd98d2..f9462c372943 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -505,8 +506,15 @@ static int ohci_init (struct ohci_hcd *ohci)
timer_setup(>io_watchdog, io_watchdog_func, 0);
ohci->prev_frame_no = IO_WATCHDOG_OFF;
- ohci->hcca = dma_alloc_coherent (hcd->self.controller,
- sizeof(*ohci->hcca), >hcca_dma, GFP_KERNEL);
+ if (hcd->driver->flags & HCD_LOCAL_MEM)
+ ohci->hcca = gen_pool_dma_alloc(hcd->localmem_pool,
+ sizeof(*ohci->hcca),
+ >hcca_dma);
+ else
+ ohci->hcca = dma_alloc_coherent(hcd->self.controller,
+ sizeof(*ohci->hcca),
+ >hcca_dma,
+ GFP_KERNEL);
if (!ohci->hcca)
return -ENOMEM;
@@ -990,9 +998,14 @@ static void ohci_stop (struct usb_hcd *hcd)
remove_debug_files (ohci);
ohci_mem_cleanup (ohci);
if (ohci->hcca) {
- dma_free_coherent (hcd->self.controller,
- sizeof *ohci->hcca,
- ohci->hcca, ohci->hcca_dma);
+ if (hcd->driver->flags & HCD_LOCAL_MEM)
+ gen_pool_free(hcd->localmem_pool,
+ (unsigned long)ohci->hcca,
+ sizeof(*ohci->hcca));
+ else
+ dma_free_coherent(hcd->self.controller,
+ sizeof(*ohci->hcca),
+ ohci->hcca, ohci->hcca_dma);
ohci->hcca = NULL;
ohci->hcca_dma = 0;
}
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 695931b03684..0fee81ef5d52 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -215,6 +215,9 @@ struct usb_hcd {
#defineHC_IS_RUNNING(state) ((state) & __ACTIVE)
#defineHC_IS_SUSPENDED(state) ((state) & __SUSPEND)
+ /* allocator for HCs having local memory */
+ struct gen_pool *localmem_pool;
+
/* more shared queuing code would be good; it should support
* smarter scheduling, handle transaction translators, etc;
* input size of periodic table to an interrupt scheduler.
--
2.17.1
RE: [RFC PATCH 0/3] prerequisites for device reserved local mem rework
Hi Robin, > -Original Message- > From: Robin Murphy > Sent: Friday, May 10, 2019 6:04 PM > > Hi Laurentiu, > > On 10/05/2019 15:56, wrote: > > From: Laurentiu Tudor > > > > For HCs that have local memory, replace the current DMA API usage > > with a genalloc generic allocator to manage the mappings for these > > devices. > > This is in preparation for dropping the existing "coherent" dma > > mem declaration APIs. Current implementation was relying on a short > > circuit in the DMA API that in the end, was acting as an allocator > > for these type of devices. > > > > Only compiled tested, so any volunteers willing to test are most welcome. > > Based on my diggings into this in the past, I would expect that you need > to do something about hcd_alloc_coherent() as well. Indeed looks like it. Thanks a lot for the pointer, I'll dig into it. --- Best Regards, Laurentiu > > > > > Thank you! > > > > For context, see thread here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org > %2Flkml%2F2019%2F4%2F22%2F357data=02%7C01%7Claurentiu.tudor%40nxp.com > %7C1ad4c377d109419121b808d6d558b0b0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 > %7C0%7C636930974257581614sdata=pNRPPIoBmZ7UBfip%2FjRBYiMgGT3pf1riWLn2 > DS%2Fotl4%3Dreserved=0 > > > > Laurentiu Tudor (3): > >ohci-hcd: use genalloc for USB HCs with local memory > >usb: host: ohci-sm501: init genalloc for local memory > >usb: host: ohci-tmio: init genalloc for local memory > > > > drivers/usb/host/ohci-hcd.c | 21 +--- > > drivers/usb/host/ohci-sm501.c | 63 +++ > > drivers/usb/host/ohci-tmio.c | 23 - > > drivers/usb/host/ohci.h | 3 ++ > > 4 files changed, 69 insertions(+), 41 deletions(-) > >
Re: [RFC PATCH] dma-mapping: create iommu mapping for newly allocated dma coherent mem
Hi Christoph,
On 24.04.2019 17:57, Christoph Hellwig wrote:
> I'd be happy to offload all of the mentioned tasks to you if you
> volunteer.
Alright, I think I mostly got it and can start with the two usb drivers
you mentioned. Just need a few clarifications, please see inline.
> I think the first step is to move the two USB controller that can only
> DMA to their own BAR off the existing DMA coherent infrastructure. The
> controllers are already identified using the HCD_LOCAL_MEM flag, so we
> just need to key off that in the hcd_buffer_* routines and call into a
So if HCD_LOCAL_MEM is set I should call into the gen_pool api instead
of existing dma_{alloc,free}_coherent().
> genalloc that has been fed using the bar, replacing the current
> dma_declare_coherent usage. Take a look at drivers/pci/p2pdma.c
> for another example of allocating bits of a BAR using genalloc.
Where should I place the reference to the gen_pool? How does local_pool
in 'struct hcd_usb' sound?
---
Thanks & Best Regards, Laurentiu
[PATCH v2] i2c: imx: don't leak the i2c adapter on error
From: Laurentiu Tudor
Make sure to free the i2c adapter on the error exit path.
Signed-off-by: Laurentiu Tudor
Reviewed-by: Mukesh Ojha
Reviewed-by: Uwe Kleine-Konig
Fixes: e1ab9a468e3b ("i2c: imx: improve the error handling in
i2c_imx_dma_request()")
---
Changes in v2:
- fixed formatting glitch
drivers/i2c/busses/i2c-imx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 42fed40198a0..c0c3043b5d61 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1169,11 +1169,13 @@ static int i2c_imx_probe(struct platform_device *pdev)
/* Init DMA config if supported */
ret = i2c_imx_dma_request(i2c_imx, phy_addr);
if (ret < 0)
- goto clk_notifier_unregister;
+ goto del_adapter;
dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n");
return 0; /* Return OK */
+del_adapter:
+ i2c_del_adapter(_imx->adapter);
clk_notifier_unregister:
clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
rpm_disable:
--
2.17.1
[PATCH] i2c: imx: don't leak the i2c adapter on error
From: Laurentiu Tudor Make sure to free the i2c adapter on the error exit path. Signed-off-by: Laurentiu Tudor --- drivers/i2c/busses/i2c-imx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 42fed40198a0..2dfd33f48cd8 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -1169,11 +1169,13 @@ static int i2c_imx_probe(struct platform_device *pdev) /* Init DMA config if supported */ ret = i2c_imx_dma_request(i2c_imx, phy_addr); if (ret < 0) - goto clk_notifier_unregister; + goto del_adapter; dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n"); return 0; /* Return OK */ +del_adapter: +i2c_del_adapter(_imx->adapter); clk_notifier_unregister: clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb); rpm_disable: -- 2.17.1
Re: [RESEND] i2c: imx: defer probing on dma channel request
Hi Leo, On 27.03.2019 20:47, Li Yang wrote: > On Wed, Mar 27, 2019 at 8:46 AM Laurentiu Tudor > wrote: >> >> Hello, >> >> Just FYI, I'm still seeing issues with the dma driver compiled _out_, >> trying to test i2c without dma support. I get the crash below in generic >> driver code later in the boot process, debug is in progress. > > That probably means the dma API shouldn't return -EPROBE_DEFER when > the driver is not compiled in? Right, problem is that the dmaengine doesn't do this check, or in other words is presumes that if you have a "dmas" property in the device tree pointing to a certain dma controller then it's expected that the driver for that dma controller is compiled in. I'll could try to look for a possibility to add such a check but I'm not very optimistic. On a side, I found the cause of the crash: the i2c adapter created in the i2c probe function is leaked on the error path and the device created behind it messes the deferal mechanism in the generic device code. I'll submit a patch to fix the leak. --- Best Regards, Laurentiu >> >> P.S. This is seen on an NXP LS1043A chip. >> >> [5.152697] Unable to handle kernel NULL pointer dereference at >> virtual address 0010 >> [5.161483] Mem abort info: >> [5.164311] ESR = 0x9604 >> [5.167407] Exception class = DABT (current EL), IL = 32 bits >> [5.173391] device_initialize: dev = 800027756808 >> [5.178446] usb 4-1: new SuperSpeed Gen 1 USB device number 2 using >> xhci-hcd >> [5.185489] SET = 0, FnV = 0 >> [5.188532] EA = 0, S1PTW = 0 >> [5.191676] Data abort info: >> [5.194599] ISV = 0, ISS = 0x0004 >> [5.198476] CM = 0, WnR = 0 >> [5.201485] [0010] user address but active_mm is swapper >> [5.207894] Internal error: Oops: 9604 [#1] PREEMPT SMP >> [5.213455] Modules linked in: >> [5.216502] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted >> 5.1.0-rc2-next-20190327-00021-g7b1a4c075381-dirty #15 >> [5.226489] Hardware name: LS1043A RDB Board (DT) >> [5.231189] Workqueue: events deferred_probe_work_func >> [5.236317] pstate: a005 (NzCv daif -PAN -UAO) >> [5.241098] pc : device_reorder_to_tail+0x13c/0x1b8 >> [5.245965] lr : device_reorder_to_tail+0xd8/0x1b8 >> [5.250743] sp : 11823c70 >> [5.254046] x29: 11823c70 x28: >> [5.259347] x27: 117abcd8 x26: 11293a20 >> [5.264649] x25: 1102a000 x24: 1102a708 >> [5.269950] x23: 1102a700 x22: 10d28000 >> [5.275251] x21: 80007393b9a0 x20: fff8 >> [5.280552] x19: 80007393b8f0 x18: >> [5.285853] x17: 0002 x16: >> [5.291154] x15: 1127d6c8 x14: 017e >> [5.296454] x13: 0001 x12: >> [5.301755] x11: x10: 0980 >> [5.307055] x9 : 118238c0 x8 : 800073872560 >> [5.312356] x7 : 800073871d00 x6 : 0058 >> [5.317656] x5 : 000f x4 : 0100 >> [5.322957] x3 : 80006a351000 x2 : 0991ec05b7534200 >> [5.328257] x1 : fff8 x0 : >> [5.333560] Process kworker/0:1 (pid: 18, stack limit = >> 0x(ptrval)) >> [5.340509] Call trace: >> [5.342945] device_reorder_to_tail+0x13c/0x1b8 >> [5.347466] device_for_each_child+0x50/0xa8 >> [5.351725] device_reorder_to_tail+0xc4/0x1b8 >> [5.356157] device_pm_move_to_tail+0x34/0x50 >> [5.360502] deferred_probe_work_func+0x64/0xa0 >> [5.365023] process_one_work+0x1c8/0x320 >> [5.369021] worker_thread+0x234/0x428 >> [5.372761] kthread+0xf4/0x120 >> [5.375892] ret_from_fork+0x10/0x18 >> [5.379458] Code: 911c2318 911c02f7 d0004e19 b4000274 (f9400e84) >> [5.385541] ---[ end trace ab4b151d346a8d41 ]--- >> >> --- >> Best Regards, Laurentiu >> >> On 25.03.2019 19:12, Steven Price wrote: >>> On 25/03/2019 15:30, laurentiu.tu...@nxp.com wrote: >>>> From: Laurentiu Tudor >>>> >>>> If the dma controller is not yet probed, defer i2c probe. >>>> The error path in probe was slightly modified (no functional change) >>> >>> There is a functional change for cases like: >>> >>>> ret = pm_runtime_get_sync(>dev); >>>> if (ret < 0) >>>> goto rpm_disable; >>> >>> .
Re: [RESEND] i2c: imx: defer probing on dma channel request
Hello,
Just FYI, I'm still seeing issues with the dma driver compiled _out_,
trying to test i2c without dma support. I get the crash below in generic
driver code later in the boot process, debug is in progress.
P.S. This is seen on an NXP LS1043A chip.
[5.152697] Unable to handle kernel NULL pointer dereference at
virtual address 0010
[5.161483] Mem abort info:
[5.164311] ESR = 0x9604
[5.167407] Exception class = DABT (current EL), IL = 32 bits
[5.173391] device_initialize: dev = 800027756808
[5.178446] usb 4-1: new SuperSpeed Gen 1 USB device number 2 using
xhci-hcd
[5.185489] SET = 0, FnV = 0
[5.188532] EA = 0, S1PTW = 0
[5.191676] Data abort info:
[5.194599] ISV = 0, ISS = 0x0004
[5.198476] CM = 0, WnR = 0
[5.201485] [0010] user address but active_mm is swapper
[5.207894] Internal error: Oops: 9604 [#1] PREEMPT SMP
[5.213455] Modules linked in:
[5.216502] CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted
5.1.0-rc2-next-20190327-00021-g7b1a4c075381-dirty #15
[5.226489] Hardware name: LS1043A RDB Board (DT)
[5.231189] Workqueue: events deferred_probe_work_func
[5.236317] pstate: a005 (NzCv daif -PAN -UAO)
[5.241098] pc : device_reorder_to_tail+0x13c/0x1b8
[5.245965] lr : device_reorder_to_tail+0xd8/0x1b8
[5.250743] sp : 11823c70
[5.254046] x29: 11823c70 x28:
[5.259347] x27: 117abcd8 x26: 11293a20
[5.264649] x25: 1102a000 x24: 1102a708
[5.269950] x23: 1102a700 x22: 10d28000
[5.275251] x21: 80007393b9a0 x20: fff8
[5.280552] x19: 80007393b8f0 x18:
[5.285853] x17: 0002 x16:
[5.291154] x15: 1127d6c8 x14: 017e
[5.296454] x13: 0001 x12:
[5.301755] x11: x10: 0980
[5.307055] x9 : 118238c0 x8 : 800073872560
[5.312356] x7 : 800073871d00 x6 : 0058
[5.317656] x5 : 000f x4 : 0100
[5.322957] x3 : 80006a351000 x2 : 0991ec05b7534200
[5.328257] x1 : fff8 x0 :
[5.333560] Process kworker/0:1 (pid: 18, stack limit =
0x(ptrval))
[5.340509] Call trace:
[5.342945] device_reorder_to_tail+0x13c/0x1b8
[5.347466] device_for_each_child+0x50/0xa8
[5.351725] device_reorder_to_tail+0xc4/0x1b8
[5.356157] device_pm_move_to_tail+0x34/0x50
[5.360502] deferred_probe_work_func+0x64/0xa0
[5.365023] process_one_work+0x1c8/0x320
[5.369021] worker_thread+0x234/0x428
[5.372761] kthread+0xf4/0x120
[5.375892] ret_from_fork+0x10/0x18
[5.379458] Code: 911c2318 911c02f7 d0004e19 b4000274 (f9400e84)
[5.385541] ---[ end trace ab4b151d346a8d41 ]---
---
Best Regards, Laurentiu
On 25.03.2019 19:12, Steven Price wrote:
> On 25/03/2019 15:30, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> If the dma controller is not yet probed, defer i2c probe.
>> The error path in probe was slightly modified (no functional change)
>
> There is a functional change for cases like:
>
>> ret = pm_runtime_get_sync(>dev);
>> if (ret < 0)
>> goto rpm_disable;
>
> ...as rpm_disable will no longer fall through to the call of
> clk_disable_unprepare().
>
>> to avoid triggering this WARN_ON():
>> "cg-pll0-div1 already disabled
>> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
>
> I'm also not sure how this WARN_ON was hit. i2c_imx_probe() calls
> clk_prepare_enable() which should increment the reference count. So it
> should always be possible to decrememt the enable_count. What am I missing?
>
>> Signed-off-by: Laurentiu Tudor
>> ---
>> drivers/i2c/busses/i2c-imx.c | 21 +
>> 1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> index 42fed40198a0..4e34b1572756 100644
>> --- a/drivers/i2c/busses/i2c-imx.c
>> +++ b/drivers/i2c/busses/i2c-imx.c
>> @@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
>> pdev->name, i2c_imx);
>> if (ret) {
>> dev_err(>dev, "can't claim irq %d\n", irq);
>> -goto clk_disable;
>> +clk_disable_unprepare(i2c_imx->clk);
>> +return ret;
>> }
>>
>> /* Init queue */
>> @@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device
>> *pdev)
>> pm_runtime_mark_last_busy(>dev);
>> pm_runtime_put_autosuspend
Re: [RESEND] i2c: imx: defer probing on dma channel request
Hi Steve,
Thanks for the review! Few comments inline.
On 25.03.2019 19:12, Steven Price wrote:
> On 25/03/2019 15:30, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> If the dma controller is not yet probed, defer i2c probe.
>> The error path in probe was slightly modified (no functional change)
>
> There is a functional change for cases like:
>
>> ret = pm_runtime_get_sync(>dev);
>> if (ret < 0)
>> goto rpm_disable;
>
> ...as rpm_disable will no longer fall through to the call of
> clk_disable_unprepare().
Good point, I missed that.
>> to avoid triggering this WARN_ON():
>> "cg-pll0-div1 already disabled
>> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
>
> I'm also not sure how this WARN_ON was hit. i2c_imx_probe() calls
> clk_prepare_enable() which should increment the reference count. So it
> should always be possible to decrememt the enable_count. What am I missing?
I am no longer able to replicate this. Perhaps in the mean time changes
in the clk core fixed this corner case.
>> Signed-off-by: Laurentiu Tudor
>> ---
>> drivers/i2c/busses/i2c-imx.c | 21 +
>> 1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> index 42fed40198a0..4e34b1572756 100644
>> --- a/drivers/i2c/busses/i2c-imx.c
>> +++ b/drivers/i2c/busses/i2c-imx.c
>> @@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
>> pdev->name, i2c_imx);
>> if (ret) {
>> dev_err(>dev, "can't claim irq %d\n", irq);
>> -goto clk_disable;
>> +clk_disable_unprepare(i2c_imx->clk);
>> +return ret;
>> }
>>
>> /* Init queue */
>> @@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device
>> *pdev)
>> pm_runtime_mark_last_busy(>dev);
>> pm_runtime_put_autosuspend(>dev);
>>
>> +/* Init DMA config if supported */
>> +ret = i2c_imx_dma_request(i2c_imx, phy_addr);
>> +if (ret) {
>> +if (ret != -EPROBE_DEFER)
>> +dev_info(>dev, "can't use DMA, using PIO
>> instead.\n");
>> +else
>> +goto del_adapter;
>> +}
>> +
>
> This can be simplified by reversing the condition:
Well, in the mean time I just found out that this commit [1] fixes the
issue I was seeing so I think the patch is no longer needed.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next=e1ab9a468e3b1
---
Best Regards, Laurentiu
[RESEND] i2c: imx: defer probing on dma channel request
From: Laurentiu Tudor
If the dma controller is not yet probed, defer i2c probe.
The error path in probe was slightly modified (no functional change)
to avoid triggering this WARN_ON():
"cg-pll0-div1 already disabled
WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
Signed-off-by: Laurentiu Tudor
---
drivers/i2c/busses/i2c-imx.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 42fed40198a0..4e34b1572756 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
pdev->name, i2c_imx);
if (ret) {
dev_err(>dev, "can't claim irq %d\n", irq);
- goto clk_disable;
+ clk_disable_unprepare(i2c_imx->clk);
+ return ret;
}
/* Init queue */
@@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device *pdev)
pm_runtime_mark_last_busy(>dev);
pm_runtime_put_autosuspend(>dev);
+ /* Init DMA config if supported */
+ ret = i2c_imx_dma_request(i2c_imx, phy_addr);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_info(>dev, "can't use DMA, using PIO
instead.\n");
+ else
+ goto del_adapter;
+ }
+
dev_dbg(_imx->adapter.dev, "claimed irq %d\n", irq);
dev_dbg(_imx->adapter.dev, "device resources: %pR\n", res);
dev_dbg(_imx->adapter.dev, "adapter name: \"%s\"\n",
i2c_imx->adapter.name);
- /* Init DMA config if supported */
- ret = i2c_imx_dma_request(i2c_imx, phy_addr);
- if (ret < 0)
- goto clk_notifier_unregister;
-
dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n");
return 0; /* Return OK */
+del_adapter:
+ i2c_del_adapter(_imx->adapter);
clk_notifier_unregister:
clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
rpm_disable:
@@ -1182,8 +1189,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_suspended(>dev);
pm_runtime_dont_use_autosuspend(>dev);
-clk_disable:
- clk_disable_unprepare(i2c_imx->clk);
return ret;
}
--
2.17.1
RE: [PATCH v2 1/2] i2c: imx: fix dma_request_chan error handling
Hi Wolfram,
> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: Wednesday, January 23, 2019 12:52 AM
>
> On Wed, Jan 16, 2019 at 01:28:54PM +0200, Laurentiu Tudor wrote:
> > Use the correct error pointer when extracting the error code.
> >
> > Fixes: ea1e5f176e97 ("i2c: imx: notify about real errors on dma
> i2c_imx_dma_request")
>
> This is not the sha1 in my tree. Maybe you rebased? I applied another
> patch meanwhile fixing the same issue. Still thanks!
I don't know, perhaps I was on some transient snapshot. Anyway, good that in
the end it's fixed.
---
Best Regards, Laurentiu
> > Signed-off-by: Laurentiu Tudor
> > ---
> > drivers/i2c/busses/i2c-imx.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> > index 09b124547669..42fed40198a0 100644
> > --- a/drivers/i2c/busses/i2c-imx.c
> > +++ b/drivers/i2c/busses/i2c-imx.c
> > @@ -287,7 +287,7 @@ static int i2c_imx_dma_request(struct imx_i2c_struct
> *i2c_imx,
> >
> > dma->chan_tx = dma_request_chan(dev, "tx");
> > if (IS_ERR(dma->chan_tx)) {
> > - ret = PTR_ERR(dma->chan_rx);
> > + ret = PTR_ERR(dma->chan_tx);
> > if (ret != -ENODEV && ret != -EPROBE_DEFER)
> > dev_err(dev, "can't request DMA tx channel (%d)\n",
> ret);
> > goto fail_al;
> > --
> > 2.17.1
> >
Re: [PATCH] dmaengine: fsl-edma: dma map slave device address
Hi Angelo,
On 18.01.2019 23:50, Angelo Dureghello wrote:
> Hi Laurentiu,
>
> On Fri, Jan 18, 2019 at 12:06:23PM +0200, Laurentiu Tudor wrote:
>> This mapping needs to be created in order for slave dma transfers
>> to work on systems with SMMU. The implementation mostly mimics the
>> one in pl330 dma driver, authored by Robin Murphy.
>>
>> Signed-off-by: Laurentiu Tudor
>> Suggested-by: Robin Murphy
>> ---
>> Original approach was to add the missing mappings in the i2c client driver,
>> see here for discussion:
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F1026013%2Fdata=02%7C01%7Claurentiu.tudor%40nxp.com%7C7861dfe95dfb4fceeb8208d67d907488%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636834456718898365sdata=XM5shQdcIRgFLtCmuRuFtViR6ttPDWI%2BNHXoPi68Xs8%3Dreserved=0
>>
>> drivers/dma/fsl-edma-common.c | 66 ---
>> drivers/dma/fsl-edma-common.h | 4 +++
>> drivers/dma/fsl-edma.c| 1 +
>> drivers/dma/mcf-edma.c| 1 +
>> 4 files changed, 68 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
>> index 8876c4c1bb2c..0e95ee24b6d4 100644
>> --- a/drivers/dma/fsl-edma-common.c
>> +++ b/drivers/dma/fsl-edma-common.c
>> @@ -6,6 +6,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "fsl-edma-common.h"
>>
>> @@ -173,12 +174,62 @@ int fsl_edma_resume(struct dma_chan *chan)
>> }
>> EXPORT_SYMBOL_GPL(fsl_edma_resume);
>>
>> +static void fsl_edma_unprep_slave_dma(struct fsl_edma_chan *fsl_chan)
>> +{
>> +if (fsl_chan->dma_dir != DMA_NONE)
>> +dma_unmap_resource(fsl_chan->vchan.chan.device->dev,
>> + fsl_chan->dma_dev_addr,
>> + fsl_chan->dma_dev_size,
>> + fsl_chan->dma_dir, 0);
>> +fsl_chan->dma_dir = DMA_NONE;
>> +}
>> +
>> +static bool fsl_edma_prep_slave_dma(struct fsl_edma_chan *fsl_chan,
>> +enum dma_transfer_direction dir)
>> +{
>> +struct device *dev = fsl_chan->vchan.chan.device->dev;
>> +enum dma_data_direction dma_dir;
>> +phys_addr_t addr = 0;
>> +u32 size = 0;
>> +
>> +switch (dir) {
>> +case DMA_MEM_TO_DEV:
>> +dma_dir = DMA_FROM_DEVICE;
>> +addr = fsl_chan->cfg.dst_addr;
>> +size = fsl_chan->cfg.dst_maxburst;
>> +break;
>> +case DMA_DEV_TO_MEM:
>> +dma_dir = DMA_TO_DEVICE;
>> +addr = fsl_chan->cfg.src_addr;
>> +size = fsl_chan->cfg.src_maxburst;
>> +break;
>> +default:
>> +dma_dir = DMA_NONE;
>> +break;
>> +}
>> +
>> +/* Already mapped for this config? */
>> +if (fsl_chan->dma_dir == dma_dir)
>> +return true;
>> +
>> +fsl_edma_unprep_slave_dma(fsl_chan);
>> +
>> +fsl_chan->dma_dev_addr = dma_map_resource(dev, addr, size, dma_dir, 0);
>> +if (dma_mapping_error(dev, fsl_chan->dma_dev_addr))
>> +return false;
>> +fsl_chan->dma_dev_size = size;
>> +fsl_chan->dma_dir = dma_dir;
>> +
>> +return true;
>> +}
>> +
>> int fsl_edma_slave_config(struct dma_chan *chan,
>> struct dma_slave_config *cfg)
>> {
>> struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
>>
>> memcpy(_chan->cfg, cfg, sizeof(*cfg));
>> +fsl_edma_unprep_slave_dma(fsl_chan);
>>
>> return 0;
>> }
>> @@ -378,6 +429,9 @@ struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
>> if (!is_slave_direction(direction))
>> return NULL;
>>
>> +if (!fsl_edma_prep_slave_dma(fsl_chan, direction))
>> +return NULL;
>> +
>> sg_len = buf_len / period_len;
>> fsl_desc = fsl_edma_alloc_desc(fsl_chan, sg_len);
>> if (!fsl_desc)
>> @@ -409,11 +463,11 @@ struct dma_async_tx_descriptor
>> *fsl_edma_prep_dma_cyclic(
>>
>> if (direction == DMA_MEM_TO_DEV) {
>> src_addr = dma_buf_next;
>> -dst_addr = fsl_chan->cfg.dst_addr;
>> +dst_addr = fsl_chan->dma_dev_addr;
>>
[PATCH] dmaengine: fsl-edma: dma map slave device address
This mapping needs to be created in order for slave dma transfers
to work on systems with SMMU. The implementation mostly mimics the
one in pl330 dma driver, authored by Robin Murphy.
Signed-off-by: Laurentiu Tudor
Suggested-by: Robin Murphy
---
Original approach was to add the missing mappings in the i2c client driver,
see here for discussion: https://patchwork.ozlabs.org/patch/1026013/
drivers/dma/fsl-edma-common.c | 66 ---
drivers/dma/fsl-edma-common.h | 4 +++
drivers/dma/fsl-edma.c| 1 +
drivers/dma/mcf-edma.c| 1 +
4 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c
index 8876c4c1bb2c..0e95ee24b6d4 100644
--- a/drivers/dma/fsl-edma-common.c
+++ b/drivers/dma/fsl-edma-common.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include "fsl-edma-common.h"
@@ -173,12 +174,62 @@ int fsl_edma_resume(struct dma_chan *chan)
}
EXPORT_SYMBOL_GPL(fsl_edma_resume);
+static void fsl_edma_unprep_slave_dma(struct fsl_edma_chan *fsl_chan)
+{
+ if (fsl_chan->dma_dir != DMA_NONE)
+ dma_unmap_resource(fsl_chan->vchan.chan.device->dev,
+ fsl_chan->dma_dev_addr,
+ fsl_chan->dma_dev_size,
+ fsl_chan->dma_dir, 0);
+ fsl_chan->dma_dir = DMA_NONE;
+}
+
+static bool fsl_edma_prep_slave_dma(struct fsl_edma_chan *fsl_chan,
+ enum dma_transfer_direction dir)
+{
+ struct device *dev = fsl_chan->vchan.chan.device->dev;
+ enum dma_data_direction dma_dir;
+ phys_addr_t addr = 0;
+ u32 size = 0;
+
+ switch (dir) {
+ case DMA_MEM_TO_DEV:
+ dma_dir = DMA_FROM_DEVICE;
+ addr = fsl_chan->cfg.dst_addr;
+ size = fsl_chan->cfg.dst_maxburst;
+ break;
+ case DMA_DEV_TO_MEM:
+ dma_dir = DMA_TO_DEVICE;
+ addr = fsl_chan->cfg.src_addr;
+ size = fsl_chan->cfg.src_maxburst;
+ break;
+ default:
+ dma_dir = DMA_NONE;
+ break;
+ }
+
+ /* Already mapped for this config? */
+ if (fsl_chan->dma_dir == dma_dir)
+ return true;
+
+ fsl_edma_unprep_slave_dma(fsl_chan);
+
+ fsl_chan->dma_dev_addr = dma_map_resource(dev, addr, size, dma_dir, 0);
+ if (dma_mapping_error(dev, fsl_chan->dma_dev_addr))
+ return false;
+ fsl_chan->dma_dev_size = size;
+ fsl_chan->dma_dir = dma_dir;
+
+ return true;
+}
+
int fsl_edma_slave_config(struct dma_chan *chan,
struct dma_slave_config *cfg)
{
struct fsl_edma_chan *fsl_chan = to_fsl_edma_chan(chan);
memcpy(_chan->cfg, cfg, sizeof(*cfg));
+ fsl_edma_unprep_slave_dma(fsl_chan);
return 0;
}
@@ -378,6 +429,9 @@ struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
if (!is_slave_direction(direction))
return NULL;
+ if (!fsl_edma_prep_slave_dma(fsl_chan, direction))
+ return NULL;
+
sg_len = buf_len / period_len;
fsl_desc = fsl_edma_alloc_desc(fsl_chan, sg_len);
if (!fsl_desc)
@@ -409,11 +463,11 @@ struct dma_async_tx_descriptor *fsl_edma_prep_dma_cyclic(
if (direction == DMA_MEM_TO_DEV) {
src_addr = dma_buf_next;
- dst_addr = fsl_chan->cfg.dst_addr;
+ dst_addr = fsl_chan->dma_dev_addr;
soff = fsl_chan->cfg.dst_addr_width;
doff = 0;
} else {
- src_addr = fsl_chan->cfg.src_addr;
+ src_addr = fsl_chan->dma_dev_addr;
dst_addr = dma_buf_next;
soff = 0;
doff = fsl_chan->cfg.src_addr_width;
@@ -444,6 +498,9 @@ struct dma_async_tx_descriptor *fsl_edma_prep_slave_sg(
if (!is_slave_direction(direction))
return NULL;
+ if (!fsl_edma_prep_slave_dma(fsl_chan, direction))
+ return NULL;
+
fsl_desc = fsl_edma_alloc_desc(fsl_chan, sg_len);
if (!fsl_desc)
return NULL;
@@ -468,11 +525,11 @@ struct dma_async_tx_descriptor *fsl_edma_prep_slave_sg(
if (direction == DMA_MEM_TO_DEV) {
src_addr = sg_dma_address(sg);
- dst_addr = fsl_chan->cfg.dst_addr;
+ dst_addr = fsl_chan->dma_dev_addr;
soff = fsl_chan->cfg.dst_addr_width;
doff = 0;
} else {
- src_addr = fsl_chan->cfg.src_addr;
+ src_addr = fsl_chan->d
Re: [RFC PATCH] i2c: imx: dma map the i2c data i/o register
Hi Robin,
On 16.01.2019 19:55, Robin Murphy wrote:
> On 16/01/2019 16:17, Laurentiu Tudor wrote:
>> This is an attempt to fix an iommu exception when doing dma to the
>> i2c controller with EDMA. Without these mappings the smmu raises a
>> context fault [1] exactly with the address of the i2c data i/o reg.
>> This was seen on an NXP LS1043A chip while working on enabling SMMU.
>
> Rather than gradually adding much the same code to potentially every
> possible client driver, can it not be implemented once in the edma
> driver as was done for pl330 and rcar-dmac? That also sidesteps any of
> the nastiness of smuggling a dma_addr_t via a phys_addr_t variable.
Thanks for the pointer. I was actually unsure where this should be
tackled: either i2c or dma side. Plus I somehow managed to completely
miss the support added in the dma drivers you mention. I'll start
looking into stealing some of your code [1]. :-)
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4d6d74e22096543cb3b35e717cf1b9aea3655f37
---
Best Regards, Laurentiu
>
>> [1] arm-smmu 900.iommu: Unhandled context fault: fsr=0x402,
>> iova=0x02180004, fsynr=0x150021, cb=7
>>
>> Signed-off-by: Laurentiu Tudor
>> ---
>> drivers/i2c/busses/i2c-imx.c | 57 +---
>> 1 file changed, 47 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> index 4e34b1572756..07cc8f4b45b9 100644
>> --- a/drivers/i2c/busses/i2c-imx.c
>> +++ b/drivers/i2c/busses/i2c-imx.c
>> @@ -202,6 +202,9 @@ struct imx_i2c_struct {
>> struct pinctrl_state *pinctrl_pins_gpio;
>> struct imx_i2c_dma *dma;
>> +
>> + dma_addr_t dma_tx_addr;
>> + dma_addr_t dma_rx_addr;
>> };
>> static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
>> @@ -274,17 +277,20 @@ static inline unsigned char
>> imx_i2c_read_reg(struct imx_i2c_struct *i2c_imx,
>> /* Functions for DMA support */
>> static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
>> - dma_addr_t phy_addr)
>> + phys_addr_t phy_addr)
>> {
>> struct imx_i2c_dma *dma;
>> struct dma_slave_config dma_sconfig;
>> struct device *dev = _imx->adapter.dev;
>> int ret;
>> + phys_addr_t i2dr_pa;
>> dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
>> if (!dma)
>> return -ENOMEM;
>> + i2dr_pa = phy_addr + (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
>> +
>> dma->chan_tx = dma_request_chan(dev, "tx");
>> if (IS_ERR(dma->chan_tx)) {
>> ret = PTR_ERR(dma->chan_tx);
>> @@ -293,15 +299,25 @@ static int i2c_imx_dma_request(struct
>> imx_i2c_struct *i2c_imx,
>> goto fail_al;
>> }
>> - dma_sconfig.dst_addr = phy_addr +
>> - (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
>> + i2c_imx->dma_tx_addr = dma_map_resource(dma->chan_tx->device->dev,
>> + i2dr_pa,
>> + DMA_SLAVE_BUSWIDTH_1_BYTE,
>> + DMA_MEM_TO_DEV, 0);
>> + ret = dma_mapping_error(dma->chan_tx->device->dev,
>> + i2c_imx->dma_tx_addr);
>> + if (ret) {
>> + dev_err(dev, "can't dma map tx destination (%d)\n", ret);
>> + goto fail_tx;
>> + }
>> +
>> + dma_sconfig.dst_addr = i2c_imx->dma_tx_addr;
>> dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>> dma_sconfig.dst_maxburst = 1;
>> dma_sconfig.direction = DMA_MEM_TO_DEV;
>> ret = dmaengine_slave_config(dma->chan_tx, _sconfig);
>> if (ret < 0) {
>> dev_err(dev, "can't configure tx channel (%d)\n", ret);
>> - goto fail_tx;
>> + goto fail_tx_dma;
>> }
>> dma->chan_rx = dma_request_chan(dev, "rx");
>> @@ -309,18 +325,28 @@ static int i2c_imx_dma_request(struct
>> imx_i2c_struct *i2c_imx,
>> ret = PTR_ERR(dma->chan_rx);
>> if (ret != -ENODEV && ret != -EPROBE_DEFER)
>> dev_err(dev, "can't request DMA rx channel (%d)\n", ret);
>> - goto fail_tx;
>> + goto fail_tx_dma;
>> }
>> - dma_sconfig.src_addr = phy_addr +
>> - (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
>> + i2c_imx->dma_rx_addr = dma_map_resource(dma->chan_rx-
[RFC PATCH] i2c: imx: dma map the i2c data i/o register
This is an attempt to fix an iommu exception when doing dma to the
i2c controller with EDMA. Without these mappings the smmu raises a
context fault [1] exactly with the address of the i2c data i/o reg.
This was seen on an NXP LS1043A chip while working on enabling SMMU.
[1] arm-smmu 900.iommu: Unhandled context fault: fsr=0x402,
iova=0x02180004, fsynr=0x150021, cb=7
Signed-off-by: Laurentiu Tudor
---
drivers/i2c/busses/i2c-imx.c | 57 +---
1 file changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 4e34b1572756..07cc8f4b45b9 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -202,6 +202,9 @@ struct imx_i2c_struct {
struct pinctrl_state *pinctrl_pins_gpio;
struct imx_i2c_dma *dma;
+
+ dma_addr_t dma_tx_addr;
+ dma_addr_t dma_rx_addr;
};
static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
@@ -274,17 +277,20 @@ static inline unsigned char imx_i2c_read_reg(struct
imx_i2c_struct *i2c_imx,
/* Functions for DMA support */
static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
- dma_addr_t phy_addr)
+ phys_addr_t phy_addr)
{
struct imx_i2c_dma *dma;
struct dma_slave_config dma_sconfig;
struct device *dev = _imx->adapter.dev;
int ret;
+ phys_addr_t i2dr_pa;
dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
if (!dma)
return -ENOMEM;
+ i2dr_pa = phy_addr + (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+
dma->chan_tx = dma_request_chan(dev, "tx");
if (IS_ERR(dma->chan_tx)) {
ret = PTR_ERR(dma->chan_tx);
@@ -293,15 +299,25 @@ static int i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
goto fail_al;
}
- dma_sconfig.dst_addr = phy_addr +
- (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+ i2c_imx->dma_tx_addr = dma_map_resource(dma->chan_tx->device->dev,
+ i2dr_pa,
+ DMA_SLAVE_BUSWIDTH_1_BYTE,
+ DMA_MEM_TO_DEV, 0);
+ ret = dma_mapping_error(dma->chan_tx->device->dev,
+ i2c_imx->dma_tx_addr);
+ if (ret) {
+ dev_err(dev, "can't dma map tx destination (%d)\n", ret);
+ goto fail_tx;
+ }
+
+ dma_sconfig.dst_addr = i2c_imx->dma_tx_addr;
dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
dma_sconfig.dst_maxburst = 1;
dma_sconfig.direction = DMA_MEM_TO_DEV;
ret = dmaengine_slave_config(dma->chan_tx, _sconfig);
if (ret < 0) {
dev_err(dev, "can't configure tx channel (%d)\n", ret);
- goto fail_tx;
+ goto fail_tx_dma;
}
dma->chan_rx = dma_request_chan(dev, "rx");
@@ -309,18 +325,28 @@ static int i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
ret = PTR_ERR(dma->chan_rx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
dev_err(dev, "can't request DMA rx channel (%d)\n",
ret);
- goto fail_tx;
+ goto fail_tx_dma;
}
- dma_sconfig.src_addr = phy_addr +
- (IMX_I2C_I2DR << i2c_imx->hwdata->regshift);
+ i2c_imx->dma_rx_addr = dma_map_resource(dma->chan_rx->device->dev,
+ i2dr_pa,
+ DMA_SLAVE_BUSWIDTH_1_BYTE,
+ DMA_DEV_TO_MEM, 0);
+ ret = dma_mapping_error(dma->chan_rx->device->dev,
+ i2c_imx->dma_rx_addr);
+ if (ret) {
+ dev_err(dev, "can't dma map rx source (%d)\n", ret);
+ goto fail_rx;
+ }
+
+ dma_sconfig.src_addr = i2c_imx->dma_rx_addr;
dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
dma_sconfig.src_maxburst = 1;
dma_sconfig.direction = DMA_DEV_TO_MEM;
ret = dmaengine_slave_config(dma->chan_rx, _sconfig);
if (ret < 0) {
dev_err(dev, "can't configure rx channel (%d)\n", ret);
- goto fail_rx;
+ goto fail_rx_dma;
}
i2c_imx->dma = dma;
@@ -330,8 +356,14 @@ static int i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
return 0;
+fail_rx_dma:
+ dma_unmap_resource(dma->chan_rx->device->dev, i2c_imx->dma_rx_addr,
+ DMA_SLAVE_BUSWIDTH_1_BYTE, DM
[PATCH v2 2/2] i2c: imx: defer probing on dma channel request
If the dma controller is not yet probed, defer i2c probe.
The error path in probe was slightly modified (no functional change)
to avoid triggering this WARN_ON():
"cg-pll0-div1 already disabled
WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
Signed-off-by: Laurentiu Tudor
---
Changes in v2:
- rebased on latest i2c tree
- fix small error introduced by a previous commit (first patch)
drivers/i2c/busses/i2c-imx.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 42fed40198a0..4e34b1572756 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
pdev->name, i2c_imx);
if (ret) {
dev_err(>dev, "can't claim irq %d\n", irq);
- goto clk_disable;
+ clk_disable_unprepare(i2c_imx->clk);
+ return ret;
}
/* Init queue */
@@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device *pdev)
pm_runtime_mark_last_busy(>dev);
pm_runtime_put_autosuspend(>dev);
+ /* Init DMA config if supported */
+ ret = i2c_imx_dma_request(i2c_imx, phy_addr);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_info(>dev, "can't use DMA, using PIO
instead.\n");
+ else
+ goto del_adapter;
+ }
+
dev_dbg(_imx->adapter.dev, "claimed irq %d\n", irq);
dev_dbg(_imx->adapter.dev, "device resources: %pR\n", res);
dev_dbg(_imx->adapter.dev, "adapter name: \"%s\"\n",
i2c_imx->adapter.name);
- /* Init DMA config if supported */
- ret = i2c_imx_dma_request(i2c_imx, phy_addr);
- if (ret < 0)
- goto clk_notifier_unregister;
-
dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n");
return 0; /* Return OK */
+del_adapter:
+ i2c_del_adapter(_imx->adapter);
clk_notifier_unregister:
clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
rpm_disable:
@@ -1182,8 +1189,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_suspended(>dev);
pm_runtime_dont_use_autosuspend(>dev);
-clk_disable:
- clk_disable_unprepare(i2c_imx->clk);
return ret;
}
--
2.17.1
[PATCH v2 1/2] i2c: imx: fix dma_request_chan error handling
Use the correct error pointer when extracting the error code.
Fixes: ea1e5f176e97 ("i2c: imx: notify about real errors on dma
i2c_imx_dma_request")
Signed-off-by: Laurentiu Tudor
---
drivers/i2c/busses/i2c-imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 09b124547669..42fed40198a0 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -287,7 +287,7 @@ static int i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
dma->chan_tx = dma_request_chan(dev, "tx");
if (IS_ERR(dma->chan_tx)) {
- ret = PTR_ERR(dma->chan_rx);
+ ret = PTR_ERR(dma->chan_tx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
dev_err(dev, "can't request DMA tx channel (%d)\n",
ret);
goto fail_al;
--
2.17.1
Re: [PATCH] i2c: imx: defer probing on dma channel request
Hello, On 15.01.2019 23:55, Wolfram Sang wrote: > Hi, > > On Tue, Jan 15, 2019 at 04:03:32PM +0200, Laurentiu Tudor wrote: >> If the dma controller is not yet probed, defer i2c probe. >> The error path in probe was slightly modified (no functional change) >> to avoid triggering this WARN_ON(): >> "cg-pll0-div1 already disabled >> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0" >> >> Signed-off-by: Laurentiu Tudor > > I just applied this series to i2c/for-next: > > http://patchwork.ozlabs.org/project/linux-i2c/list/?series=85099=* > > I haven't checked carefully but maybe it fixes/changes your issue? Not really as it doesn't seem to defer probing until the dma controller gets probed. > If not, your patch most likely will need a rebase on top of the above. Will rebase on latest i2c tree and re-send. --- Best Regards, Laurentiu
[PATCH] i2c: imx: defer probing on dma channel request
If the dma controller is not yet probed, defer i2c probe.
The error path in probe was slightly modified (no functional change)
to avoid triggering this WARN_ON():
"cg-pll0-div1 already disabled
WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
Signed-off-by: Laurentiu Tudor
---
drivers/i2c/busses/i2c-imx.c | 45 +---
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index fa9ad53845d9..5a28d25ff9b6 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -273,8 +273,8 @@ static inline unsigned char imx_i2c_read_reg(struct
imx_i2c_struct *i2c_imx,
}
/* Functions for DMA support */
-static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
- dma_addr_t phy_addr)
+static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
+ dma_addr_t phy_addr)
{
struct imx_i2c_dma *dma;
struct dma_slave_config dma_sconfig;
@@ -283,11 +283,12 @@ static void i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
if (!dma)
- return;
+ return -ENOMEM;
- dma->chan_tx = dma_request_slave_channel(dev, "tx");
- if (!dma->chan_tx) {
- dev_dbg(dev, "can't request DMA tx channel\n");
+ dma->chan_tx = dma_request_slave_channel_reason(dev, "tx");
+ if (IS_ERR(dma->chan_tx)) {
+ ret = PTR_ERR(dma->chan_tx);
+ dma->chan_tx = NULL;
goto fail_al;
}
@@ -301,10 +302,10 @@ static void i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
dev_dbg(dev, "can't configure tx channel\n");
goto fail_tx;
}
-
- dma->chan_rx = dma_request_slave_channel(dev, "rx");
- if (!dma->chan_rx) {
- dev_dbg(dev, "can't request DMA rx channel\n");
+ dma->chan_rx = dma_request_slave_channel_reason(dev, "rx");
+ if (IS_ERR(dma->chan_rx)) {
+ ret = PTR_ERR(dma->chan_rx);
+ dma->chan_rx = NULL;
goto fail_tx;
}
@@ -324,7 +325,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
dev_info(dev, "using %s (tx) and %s (rx) for DMA transfers\n",
dma_chan_name(dma->chan_tx), dma_chan_name(dma->chan_rx));
- return;
+ return 0;
fail_rx:
dma_release_channel(dma->chan_rx);
@@ -332,7 +333,8 @@ static void i2c_imx_dma_request(struct imx_i2c_struct
*i2c_imx,
dma_release_channel(dma->chan_tx);
fail_al:
devm_kfree(dev, dma);
- dev_info(dev, "can't use DMA, using PIO instead.\n");
+
+ return ret;
}
static void i2c_imx_dma_callback(void *arg)
@@ -1106,7 +1108,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
pdev->name, i2c_imx);
if (ret) {
dev_err(>dev, "can't claim irq %d\n", irq);
- goto clk_disable;
+ clk_disable_unprepare(i2c_imx->clk);
+ return ret;
}
/* Init queue */
@@ -1156,17 +1159,25 @@ static int i2c_imx_probe(struct platform_device *pdev)
pm_runtime_mark_last_busy(>dev);
pm_runtime_put_autosuspend(>dev);
+ /* Init DMA config if supported */
+ ret = i2c_imx_dma_request(i2c_imx, phy_addr);
+ if (ret) {
+ if (ret != -EPROBE_DEFER)
+ dev_info(>dev, "can't use DMA, using PIO
instead.\n");
+ else
+ goto del_adapter;
+ }
+
dev_dbg(_imx->adapter.dev, "claimed irq %d\n", irq);
dev_dbg(_imx->adapter.dev, "device resources: %pR\n", res);
dev_dbg(_imx->adapter.dev, "adapter name: \"%s\"\n",
i2c_imx->adapter.name);
dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n");
- /* Init DMA config if supported */
- i2c_imx_dma_request(i2c_imx, phy_addr);
-
return 0; /* Return OK */
+del_adapter:
+ i2c_del_adapter(_imx->adapter);
clk_notifier_unregister:
clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
rpm_disable:
@@ -1175,8 +1186,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
pm_runtime_set_suspended(>dev);
pm_runtime_dont_use_autosuspend(>dev);
-clk_disable:
- clk_disable_unprepare(i2c_imx->clk);
return ret;
}
--
2.17.1
Re: [PATCH] drivers/bus/fsl-mc/dpbp.c: Remove duplicate header
On 09.11.2018 11:51, Brajeswar Ghosh wrote: > Remove linux/fsl/mc.h which is included more than once > > Signed-off-by: Brajeswar Ghosh Acked-by: Laurentiu Tudor --- Best Regards, Laurentiu > --- > drivers/bus/fsl-mc/dpbp.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/bus/fsl-mc/dpbp.c b/drivers/bus/fsl-mc/dpbp.c > index 17e3c5d2f22e..9003cd3698a5 100644 > --- a/drivers/bus/fsl-mc/dpbp.c > +++ b/drivers/bus/fsl-mc/dpbp.c > @@ -5,7 +5,6 @@ >*/ > #include > #include > -#include > > #include "fsl-mc-private.h" > >
RE: [PATCH 0/5] soc: fsl: add device links support for devices on the fsl-mc bus
> -Original Message- > From: Ioana Ciornei > Sent: Monday, December 10, 2018 6:50 PM > > The fsl-mc bus discovers and exports devices dynamically allocated > by the Management Complex firmware. > This patch set adds the ability to automatically create a device link > between a consumer device on the fsl-mc bus and a supplier one. > For example, a dpni device (a network interface) requests access to a > dpio device (I/O portal) using the dpaa2_io_service_register function > which is enhanced to also add the corresponding device link between > them. > > The first 3 patches set the stage for a proper handling of device > links while the following 2 are the ones that add the actual links. > > The internal management of the links is not exported to the consumer > driver, but it's rather included in the functions that actually allocate > the provider device: fsl_mc_portal_allocate, fsl_mc_object_allocate and > dpaa2_io_service_register. > > Ioana Ciornei (4): > soc: fsl: dpio: keep a per dpio device MC portal > soc: fsl: dpio: store a backpointer to the device backing the dpaa2_io > soc: fsl: dpio: add a device_link at dpaa2_io_service_register > bus: fsl-mc: automatically add a device_link on > fsl_mc_[portal,object]_allocate > > Roy Pledge (1): > soc: fsl: dpio: perform DPIO Reset on Probe > > drivers/bus/fsl-mc/fsl-mc-allocator.c| 11 +++ > drivers/bus/fsl-mc/mc-io.c | 13 + > drivers/crypto/caam/caamalg_qi2.c| 6 +++--- > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 9 + > drivers/soc/fsl/dpio/dpio-cmd.h | 1 + > drivers/soc/fsl/dpio/dpio-driver.c | 18 +- > drivers/soc/fsl/dpio/dpio-service.c | 23 > --- > drivers/soc/fsl/dpio/dpio.c | 23 > +++ > drivers/soc/fsl/dpio/dpio.h | 4 > include/linux/fsl/mc.h | 1 + > include/soc/fsl/dpaa2-io.h | 9 ++--- > 11 files changed, 96 insertions(+), 22 deletions(-) Reviewed-by: Laurentiu Tudor --- Best Regards, Laurentiu
Re: [PATCH v1 1/2] bus: mc-bus: Add support for mapping shareable portals
Hi Roy,
On 30.10.2018 22:30, Roy Pledge wrote:
> Starting with v5 of NXP QBMan devices the hardware supports using
> regular cacheable/shareable memory as the backing store for the
> portals.
>
> This patch adds support for the new portal mode by switching to
> use the DPRC get object region v2 command which returns both
> a base address and offset for the portal memory. The new portal
> region is identified as shareable through the addition of a new
> flag.
>
> Signed-off-by: Roy Pledge
> ---
> drivers/bus/fsl-mc/dprc.c | 3 ++-
> drivers/bus/fsl-mc/fsl-mc-bus.c | 14 --
> drivers/bus/fsl-mc/fsl-mc-private.h | 17 ++---
> 3 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
> index 1c3f621..bde856d 100644
> --- a/drivers/bus/fsl-mc/dprc.c
> +++ b/drivers/bus/fsl-mc/dprc.c
> @@ -461,8 +461,9 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
>
> /* retrieve response parameters */
> rsp_params = (struct dprc_rsp_get_obj_region *)cmd.params;
> - region_desc->base_offset = le64_to_cpu(rsp_params->base_addr);
> + region_desc->base_offset = le64_to_cpu(rsp_params->base_offset);
> region_desc->size = le32_to_cpu(rsp_params->size);
> + region_desc->base_address = le64_to_cpu(rsp_params->base_addr);
>
> return 0;
> }
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index f0404c6..25ad422 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -487,10 +487,18 @@ static int fsl_mc_device_get_mmio_regions(struct
> fsl_mc_device *mc_dev,
> "dprc_get_obj_region() failed: %d\n", error);
> goto error_cleanup_regions;
> }
> -
> - error = translate_mc_addr(mc_dev, mc_region_type,
> + /* Older MC only returned region offset and no base address
> + * If base address is in the region_desc use it otherwise
> + * revert to old mechanism
> + */
> + if (region_desc.base_address)
> + regions[i].start = region_desc.base_address +
> + region_desc.base_offset;
> + else
> + error = translate_mc_addr(mc_dev, mc_region_type,
> region_desc.base_offset,
> [i].start);
> +
> if (error < 0) {
> dev_err(parent_dev,
> "Invalid MC offset: %#x (for %s.%d\'s region
> %d)\n",
> @@ -504,6 +512,8 @@ static int fsl_mc_device_get_mmio_regions(struct
> fsl_mc_device *mc_dev,
> regions[i].flags = IORESOURCE_IO;
> if (region_desc.flags & DPRC_REGION_CACHEABLE)
> regions[i].flags |= IORESOURCE_CACHEABLE;
> + if (region_desc.flags & DPRC_REGION_SHAREABLE)
> + regions[i].flags |= IORESOURCE_MEM;
> }
>
> mc_dev->regions = regions;
> diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h
> b/drivers/bus/fsl-mc/fsl-mc-private.h
> index ea11b4f..28e40d1 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-private.h
> +++ b/drivers/bus/fsl-mc/fsl-mc-private.h
> @@ -79,9 +79,11 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
>
> /* DPRC command versioning */
> #define DPRC_CMD_BASE_VERSION 1
> +#define DPRC_CMD_2ND_VERSION 2
> #define DPRC_CMD_ID_OFFSET 4
>
> #define DPRC_CMD(id)(((id) << DPRC_CMD_ID_OFFSET) |
> DPRC_CMD_BASE_VERSION)
> +#define DPRC_CMD_V2(id) (((id) << DPRC_CMD_ID_OFFSET) |
> DPRC_CMD_2ND_VERSION)
>
> /* DPRC command IDs */
> #define DPRC_CMDID_CLOSEDPRC_CMD(0x800)
> @@ -99,7 +101,7 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
> #define DPRC_CMDID_GET_CONT_ID DPRC_CMD(0x830)
> #define DPRC_CMDID_GET_OBJ_COUNTDPRC_CMD(0x159)
> #define DPRC_CMDID_GET_OBJ DPRC_CMD(0x15A)
> -#define DPRC_CMDID_GET_OBJ_REG DPRC_CMD(0x15E)
> +#define DPRC_CMDID_GET_OBJ_REG DPRC_CMD_V2(0x15E)
I see you're bumping this command's version to v2. Will we still be
compatible with older MC firmware versions?
---
Best Regards, Laurentiu
Re: [PATCH v1 1/2] bus: mc-bus: Add support for mapping shareable portals
Hi Roy,
On 30.10.2018 22:30, Roy Pledge wrote:
> Starting with v5 of NXP QBMan devices the hardware supports using
> regular cacheable/shareable memory as the backing store for the
> portals.
>
> This patch adds support for the new portal mode by switching to
> use the DPRC get object region v2 command which returns both
> a base address and offset for the portal memory. The new portal
> region is identified as shareable through the addition of a new
> flag.
>
> Signed-off-by: Roy Pledge
> ---
> drivers/bus/fsl-mc/dprc.c | 3 ++-
> drivers/bus/fsl-mc/fsl-mc-bus.c | 14 --
> drivers/bus/fsl-mc/fsl-mc-private.h | 17 ++---
> 3 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
> index 1c3f621..bde856d 100644
> --- a/drivers/bus/fsl-mc/dprc.c
> +++ b/drivers/bus/fsl-mc/dprc.c
> @@ -461,8 +461,9 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
>
> /* retrieve response parameters */
> rsp_params = (struct dprc_rsp_get_obj_region *)cmd.params;
> - region_desc->base_offset = le64_to_cpu(rsp_params->base_addr);
> + region_desc->base_offset = le64_to_cpu(rsp_params->base_offset);
> region_desc->size = le32_to_cpu(rsp_params->size);
> + region_desc->base_address = le64_to_cpu(rsp_params->base_addr);
>
> return 0;
> }
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index f0404c6..25ad422 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -487,10 +487,18 @@ static int fsl_mc_device_get_mmio_regions(struct
> fsl_mc_device *mc_dev,
> "dprc_get_obj_region() failed: %d\n", error);
> goto error_cleanup_regions;
> }
> -
> - error = translate_mc_addr(mc_dev, mc_region_type,
> + /* Older MC only returned region offset and no base address
> + * If base address is in the region_desc use it otherwise
> + * revert to old mechanism
> + */
> + if (region_desc.base_address)
> + regions[i].start = region_desc.base_address +
> + region_desc.base_offset;
> + else
> + error = translate_mc_addr(mc_dev, mc_region_type,
> region_desc.base_offset,
> [i].start);
> +
> if (error < 0) {
> dev_err(parent_dev,
> "Invalid MC offset: %#x (for %s.%d\'s region
> %d)\n",
> @@ -504,6 +512,8 @@ static int fsl_mc_device_get_mmio_regions(struct
> fsl_mc_device *mc_dev,
> regions[i].flags = IORESOURCE_IO;
> if (region_desc.flags & DPRC_REGION_CACHEABLE)
> regions[i].flags |= IORESOURCE_CACHEABLE;
> + if (region_desc.flags & DPRC_REGION_SHAREABLE)
> + regions[i].flags |= IORESOURCE_MEM;
> }
>
> mc_dev->regions = regions;
> diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h
> b/drivers/bus/fsl-mc/fsl-mc-private.h
> index ea11b4f..28e40d1 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-private.h
> +++ b/drivers/bus/fsl-mc/fsl-mc-private.h
> @@ -79,9 +79,11 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
>
> /* DPRC command versioning */
> #define DPRC_CMD_BASE_VERSION 1
> +#define DPRC_CMD_2ND_VERSION 2
> #define DPRC_CMD_ID_OFFSET 4
>
> #define DPRC_CMD(id)(((id) << DPRC_CMD_ID_OFFSET) |
> DPRC_CMD_BASE_VERSION)
> +#define DPRC_CMD_V2(id) (((id) << DPRC_CMD_ID_OFFSET) |
> DPRC_CMD_2ND_VERSION)
>
> /* DPRC command IDs */
> #define DPRC_CMDID_CLOSEDPRC_CMD(0x800)
> @@ -99,7 +101,7 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
> #define DPRC_CMDID_GET_CONT_ID DPRC_CMD(0x830)
> #define DPRC_CMDID_GET_OBJ_COUNTDPRC_CMD(0x159)
> #define DPRC_CMDID_GET_OBJ DPRC_CMD(0x15A)
> -#define DPRC_CMDID_GET_OBJ_REG DPRC_CMD(0x15E)
> +#define DPRC_CMDID_GET_OBJ_REG DPRC_CMD_V2(0x15E)
I see you're bumping this command's version to v2. Will we still be
compatible with older MC firmware versions?
---
Best Regards, Laurentiu
[PATCH v3 16/22] arm64: dts: ls1046a: add smmu node
From: Laurentiu Tudor
This allows for the SMMU device to be probed by the SMMU kernel driver.
Signed-off-by: Laurentiu Tudor
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 42 +++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index ef83786b8b90..07a853a0aeaa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -228,6 +228,48 @@
bus-width = <4>;
};
+ mmu: iommu@900 {
+ compatible = "arm,mmu-500";
+ reg = <0 0x900 0 0x40>;
+ dma-coherent;
+ #global-interrupts = <2>;
+ #iommu-cells = <1>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ };
+
scfg: scfg@157 {
compatible = "fsl,ls1046a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
--
2.17.1
[PATCH v3 16/22] arm64: dts: ls1046a: add smmu node
From: Laurentiu Tudor
This allows for the SMMU device to be probed by the SMMU kernel driver.
Signed-off-by: Laurentiu Tudor
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 42 +++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index ef83786b8b90..07a853a0aeaa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -228,6 +228,48 @@
bus-width = <4>;
};
+ mmu: iommu@900 {
+ compatible = "arm,mmu-500";
+ reg = <0 0x900 0 0x40>;
+ dma-coherent;
+ #global-interrupts = <2>;
+ #iommu-cells = <1>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ };
+
scfg: scfg@157 {
compatible = "fsl,ls1046a-scfg", "syscon";
reg = <0x0 0x157 0x0 0x1>;
--
2.17.1
Re: [GIT PULL] fixes for soc/fsl drivers for v4.19 take 2
Hi Leo, On 02.10.2018 01:58, Li Yang wrote: > Hi arm-soc maintainers, > > Please merge the updated fix for the following issue. > > Regards, > Leo > > The following changes since commit 96fc74333f84cfdf8d434c6c07254e215e2aad00: > >soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift() (2018-09-25 > 13:57:26 -0700) > > are available in the Git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git > soc-fsl-fix-v4.19-2 > > for you to fetch changes up to 5a1eb8b9542884592a018829bb1ff20c9695d925: > >soc: fsl: qman_portals: defer probe after qman's probe (2018-10-01 > 17:47:43 -0500) > > > NXP/FSL SoC driver fixes for v4.19 round 2 > > - Fix crash of qman_portal by deferring its probe if qman is not probed > > > Laurentiu Tudor (2): >soc: fsl: qbman: add APIs to retrieve the probing status >soc: fsl: qman_portals: defer probe after qman's probe There's a similar fix for bman portals [1]. I was under the impression that you plan to pick that up too. [1] "soc/fsl/bman_portals: defer probe after bman's probe", found here: https://lore.kernel.org/patchwork/patch/992009/ --- Thanks & Best Regards, Laurentiu
Re: [GIT PULL] fixes for soc/fsl drivers for v4.19 take 2
Hi Leo, On 02.10.2018 01:58, Li Yang wrote: > Hi arm-soc maintainers, > > Please merge the updated fix for the following issue. > > Regards, > Leo > > The following changes since commit 96fc74333f84cfdf8d434c6c07254e215e2aad00: > >soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift() (2018-09-25 > 13:57:26 -0700) > > are available in the Git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git > soc-fsl-fix-v4.19-2 > > for you to fetch changes up to 5a1eb8b9542884592a018829bb1ff20c9695d925: > >soc: fsl: qman_portals: defer probe after qman's probe (2018-10-01 > 17:47:43 -0500) > > > NXP/FSL SoC driver fixes for v4.19 round 2 > > - Fix crash of qman_portal by deferring its probe if qman is not probed > > > Laurentiu Tudor (2): >soc: fsl: qbman: add APIs to retrieve the probing status >soc: fsl: qman_portals: defer probe after qman's probe There's a similar fix for bman portals [1]. I was under the impression that you plan to pick that up too. [1] "soc/fsl/bman_portals: defer probe after bman's probe", found here: https://lore.kernel.org/patchwork/patch/992009/ --- Thanks & Best Regards, Laurentiu
Re: [PATCH] bus: fsl-mc: explicitly define the fsl_mc_command endianness
On 02.10.2018 15:16, Ioana Ciornei wrote:
> Both the header and the command parameters of the fsl_mc_command are
> 64-bit little-endian words. Use the appropriate type to explicitly
> specify their endianness.
>
> Signed-off-by: Ioana Ciornei
Reviewed-By: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> include/linux/fsl/mc.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
> index f27cb14..96c54bb 100644
> --- a/include/linux/fsl/mc.h
> +++ b/include/linux/fsl/mc.h
> @@ -210,8 +210,8 @@ struct mc_cmd_header {
> };
>
> struct fsl_mc_command {
> - u64 header;
> - u64 params[MC_CMD_NUM_OF_PARAMS];
> + __le64 header;
> + __le64 params[MC_CMD_NUM_OF_PARAMS];
> };
>
> enum mc_cmd_status {
> @@ -238,11 +238,11 @@ enum mc_cmd_status {
> /* Command completion flag */
> #define MC_CMD_FLAG_INTR_DIS0x01
>
> -static inline u64 mc_encode_cmd_header(u16 cmd_id,
> -u32 cmd_flags,
> -u16 token)
> +static inline __le64 mc_encode_cmd_header(u16 cmd_id,
> + u32 cmd_flags,
> + u16 token)
> {
> - u64 header = 0;
> + __le64 header = 0;
> struct mc_cmd_header *hdr = (struct mc_cmd_header *)
>
> hdr->cmd_id = cpu_to_le16(cmd_id);
>
Re: [PATCH] bus: fsl-mc: explicitly define the fsl_mc_command endianness
On 02.10.2018 15:16, Ioana Ciornei wrote:
> Both the header and the command parameters of the fsl_mc_command are
> 64-bit little-endian words. Use the appropriate type to explicitly
> specify their endianness.
>
> Signed-off-by: Ioana Ciornei
Reviewed-By: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> include/linux/fsl/mc.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
> index f27cb14..96c54bb 100644
> --- a/include/linux/fsl/mc.h
> +++ b/include/linux/fsl/mc.h
> @@ -210,8 +210,8 @@ struct mc_cmd_header {
> };
>
> struct fsl_mc_command {
> - u64 header;
> - u64 params[MC_CMD_NUM_OF_PARAMS];
> + __le64 header;
> + __le64 params[MC_CMD_NUM_OF_PARAMS];
> };
>
> enum mc_cmd_status {
> @@ -238,11 +238,11 @@ enum mc_cmd_status {
> /* Command completion flag */
> #define MC_CMD_FLAG_INTR_DIS0x01
>
> -static inline u64 mc_encode_cmd_header(u16 cmd_id,
> -u32 cmd_flags,
> -u16 token)
> +static inline __le64 mc_encode_cmd_header(u16 cmd_id,
> + u32 cmd_flags,
> + u16 token)
> {
> - u64 header = 0;
> + __le64 header = 0;
> struct mc_cmd_header *hdr = (struct mc_cmd_header *)
>
> hdr->cmd_id = cpu_to_le16(cmd_id);
>
[PATCH v2 08/22] soc/fsl/qbman_portals: add APIs to retrieve the probing status
From: Laurentiu Tudor
Add a couple of new APIs to check the probing status of the required
cpu bound qman and bman portals:
'int bman_portals_probed()' and 'int qman_portals_probed()'.
They return the following values.
* 1 if qman/bman portals were all probed correctly
* 0 if qman/bman portals were not yet probed
* -1 if probing of qman/bman portals failed
Drivers that use qman/bman portal driver services are required to use
these APIs before calling any functions exported by these drivers or
otherwise they will crash the kernel.
First user will be the dpaa1 ethernet driver, coming in a subsequent
patch.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_portal.c | 10 ++
drivers/soc/fsl/qbman/qman_portal.c | 10 ++
include/soc/fsl/bman.h | 8
include/soc/fsl/qman.h | 9 +
4 files changed, 37 insertions(+)
diff --git a/drivers/soc/fsl/qbman/bman_portal.c
b/drivers/soc/fsl/qbman/bman_portal.c
index f9edd28894fd..8048d35de8a2 100644
--- a/drivers/soc/fsl/qbman/bman_portal.c
+++ b/drivers/soc/fsl/qbman/bman_portal.c
@@ -32,6 +32,7 @@
static struct bman_portal *affine_bportals[NR_CPUS];
static struct cpumask portal_cpus;
+static int __bman_portals_probed;
/* protect bman global registers and global data shared among portals */
static DEFINE_SPINLOCK(bman_lock);
@@ -85,6 +86,12 @@ static int bman_online_cpu(unsigned int cpu)
return 0;
}
+int bman_portals_probed(void)
+{
+ return __bman_portals_probed;
+}
+EXPORT_SYMBOL_GPL(bman_portals_probed);
+
static int bman_portal_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -148,6 +155,7 @@ static int bman_portal_probe(struct platform_device *pdev)
spin_lock(_lock);
cpu = cpumask_next_zero(-1, _cpus);
if (cpu >= nr_cpu_ids) {
+ __bman_portals_probed = 1;
/* unassigned portal, skip init */
spin_unlock(_lock);
return 0;
@@ -173,6 +181,8 @@ static int bman_portal_probe(struct platform_device *pdev)
err_ioremap2:
memunmap(pcfg->addr_virt_ce);
err_ioremap1:
+__bman_portals_probed = 1;
+
return -ENXIO;
}
diff --git a/drivers/soc/fsl/qbman/qman_portal.c
b/drivers/soc/fsl/qbman/qman_portal.c
index eef93cab84f1..1b2fc981c269 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -39,6 +39,7 @@ EXPORT_SYMBOL(qman_dma_portal);
#define CONFIG_FSL_DPA_PIRQ_FAST 1
static struct cpumask portal_cpus;
+static int __qman_portals_probed;
/* protect qman global registers and global data shared among portals */
static DEFINE_SPINLOCK(qman_lock);
@@ -219,6 +220,12 @@ static int qman_online_cpu(unsigned int cpu)
return 0;
}
+int qman_portals_probed(void)
+{
+ return __qman_portals_probed;
+}
+EXPORT_SYMBOL_GPL(qman_portals_probed);
+
static int qman_portal_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -306,6 +313,7 @@ static int qman_portal_probe(struct platform_device *pdev)
spin_lock(_lock);
cpu = cpumask_next_zero(-1, _cpus);
if (cpu >= nr_cpu_ids) {
+ __qman_portals_probed = 1;
/* unassigned portal, skip init */
spin_unlock(_lock);
return 0;
@@ -336,6 +344,8 @@ static int qman_portal_probe(struct platform_device *pdev)
err_ioremap2:
memunmap(pcfg->addr_virt_ce);
err_ioremap1:
+ __qman_portals_probed = -1;
+
return -ENXIO;
}
diff --git a/include/soc/fsl/bman.h b/include/soc/fsl/bman.h
index 5b99cb2ea5ef..173e4049d963 100644
--- a/include/soc/fsl/bman.h
+++ b/include/soc/fsl/bman.h
@@ -133,5 +133,13 @@ int bman_acquire(struct bman_pool *pool, struct bm_buffer
*bufs, u8 num);
* failed to probe or 0 if the bman driver did not probed yet.
*/
int bman_is_probed(void);
+/**
+ * bman_portals_probed - Check if all cpu bound bman portals are probed
+ *
+ * Returns 1 if all the required cpu bound bman portals successfully probed,
+ * -1 if probe errors appeared or 0 if the bman portals did not yet finished
+ * probing.
+ */
+int bman_portals_probed(void);
#endif /* __FSL_BMAN_H */
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 597783b8a3a0..7732e48081eb 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -1194,4 +1194,13 @@ int qman_release_cgrid(u32 id);
*/
int qman_is_probed(void);
+/**
+ * qman_portals_probed - Check if all cpu bound qman portals are probed
+ *
+ * Returns 1 if all the required cpu bound qman portals successfully probed,
+ * -1 if probe errors appeared or 0 if the qman portals did not yet finished
+ * probing.
+ */
+int qman_portals_probed(void);
+
#endif /* __FSL_QMAN_H */
--
2.17.1
