Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1265488 > unrolled thread

The alignment mismatch issues between the of_reserved_mem and the CMA setup requirement

Started byLiu Jason <Hui.Liu@freescale.com>
First post2015-11-09 10:40 +0100
Last post2015-11-10 04:30 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

Contents

  The alignment mismatch issues between the of_reserved_mem and the CMA  setup requirement Liu Jason <Hui.Liu@freescale.com> - 2015-11-09 10:40 +0100
    Re: The alignment mismatch issues between the of_reserved_mem and the  CMA setup requirement Rob Herring <robh+dt@kernel.org> - 2015-11-09 15:30 +0100
      RE: The alignment mismatch issues between the of_reserved_mem and the  CMA setup requirement Liu Jason <Hui.Liu@freescale.com> - 2015-11-10 04:30 +0100

#1265488 — The alignment mismatch issues between the of_reserved_mem and the CMA setup requirement

FromLiu Jason <Hui.Liu@freescale.com>
Date2015-11-09 10:40 +0100
SubjectThe alignment mismatch issues between the of_reserved_mem and the CMA setup requirement
Message-ID<qsR5F-4AF-47@gated-at.bofh.it>
There is an alignment mismatch issue between the of_reserved_mem and the CMA setup requirement.

The alignment in Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt


alignment (optional) - length based on parent's #size-cells
                        - Address boundary for alignment of allocation.


But this is not exactly match the CMA setup requirement if the alignment not set or set it not correctly.

The of_reserved_mem will get the alignment from the DTS and pass it to __memblock_alloc_base to
do the memory block allocation. If no alignment property in the DTS, the align will be SMP_CACHE_BYTES

BUT, The CMA setup require the alignment as the following in the code:

align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)

static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
        phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
        phys_addr_t mask = align - 1;
        unsigned long node = rmem->fdt_node;
        struct cma *cma;
        int err;

        if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
            of_get_flat_dt_prop(node, "no-map", NULL))
                return -EINVAL;

        if ((rmem->base & mask) || (rmem->size & mask)) {
                pr_err("Reserved memory: incorrect alignment of CMA region\n");
                return -EINVAL;
        }
        <snip>
}

So, there is very likely that the alignment mismatch between the of_reserved_mem and the CMA setup requirement.
The sanity check in the rmem_cma_setup will fail and CMA not get set up in the end, this is not expected for CMA.

In the test, there will be following err log when this mismatch happen.

Reserved memory: incorrect alignment of CMA region.

The following patch to fix this issue, any comments? 

=======================================================================================

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 62f467b..a20d4d3 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -124,6 +124,15 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
                align = dt_mem_next_cell(dt_root_addr_cells, &prop);
        }

+       if (of_flat_dt_is_compatible(node,"shared-dma-pool")) {
+               phys_addr_t align_required = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+                if (!align || align != ALIGN(align, align_required)) {
+                        pr_warn("Reserved memory: the alignment not set up correctly in '%s' node."
+                               "change from %pa to %pa \n", uname, &align, &align_required);
+                        align = align_required;
+                }
+        }
+

Best Regards,
Jason Liu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1265716 — Re: The alignment mismatch issues between the of_reserved_mem and the CMA setup requirement

FromRob Herring <robh+dt@kernel.org>
Date2015-11-09 15:30 +0100
SubjectRe: The alignment mismatch issues between the of_reserved_mem and the CMA setup requirement
Message-ID<qsVCi-7yE-15@gated-at.bofh.it>
In reply to#1265488
On Mon, Nov 9, 2015 at 3:39 AM, Liu Jason <Hui.Liu@freescale.com> wrote:
> There is an alignment mismatch issue between the of_reserved_mem and the CMA setup requirement.
>
> The alignment in Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
>
> alignment (optional) - length based on parent's #size-cells
>                         - Address boundary for alignment of allocation.
>
>
> But this is not exactly match the CMA setup requirement if the alignment not set or set it not correctly.
>
> The of_reserved_mem will get the alignment from the DTS and pass it to __memblock_alloc_base to
> do the memory block allocation. If no alignment property in the DTS, the align will be SMP_CACHE_BYTES

IMO, any alignment requirement in the DTB should reflect h/w alignment
requirements. We can't know what alignment the OS wants. So if the OS
needs to further increase the alignment, it should adjust the
alignment.

>
> BUT, The CMA setup require the alignment as the following in the code:
>
> align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order)
>
> static int __init rmem_cma_setup(struct reserved_mem *rmem)
> {
>         phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
>         phys_addr_t mask = align - 1;
>         unsigned long node = rmem->fdt_node;
>         struct cma *cma;
>         int err;
>
>         if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
>             of_get_flat_dt_prop(node, "no-map", NULL))
>                 return -EINVAL;
>
>         if ((rmem->base & mask) || (rmem->size & mask)) {
>                 pr_err("Reserved memory: incorrect alignment of CMA region\n");
>                 return -EINVAL;
>         }
>         <snip>
> }
>
> So, there is very likely that the alignment mismatch between the of_reserved_mem and the CMA setup requirement.
> The sanity check in the rmem_cma_setup will fail and CMA not get set up in the end, this is not expected for CMA.
>
> In the test, there will be following err log when this mismatch happen.
>
> Reserved memory: incorrect alignment of CMA region.
>
> The following patch to fix this issue, any comments?
>
> =======================================================================================
>
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 62f467b..a20d4d3 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -124,6 +124,15 @@ static int __init __reserved_mem_alloc_size(unsigned long node,
>                 align = dt_mem_next_cell(dt_root_addr_cells, &prop);
>         }
>
> +       if (of_flat_dt_is_compatible(node,"shared-dma-pool")) {
> +               phys_addr_t align_required = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
> +                if (!align || align != ALIGN(align, align_required)) {
> +                        pr_warn("Reserved memory: the alignment not set up correctly in '%s' node."
> +                               "change from %pa to %pa \n", uname, &align, &align_required);
> +                        align = align_required;
> +                }
> +        }

You simply need the max required from the DT (which could be more) or
CMA, so this can be simplified to:

align = max(align, PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));

I don't think you should warn here either.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1266203 — RE: The alignment mismatch issues between the of_reserved_mem and the CMA setup requirement

FromLiu Jason <Hui.Liu@freescale.com>
Date2015-11-10 04:30 +0100
SubjectRE: The alignment mismatch issues between the of_reserved_mem and the CMA setup requirement
Message-ID<qt7N7-81B-9@gated-at.bofh.it>
In reply to#1265716
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb2IgSGVycmluZyBbbWFpbHRv
OnJvYmgrZHRAa2VybmVsLm9yZ10NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwOSwgMjAxNSAx
MDoyNiBQTQ0KPiBUbzogTGl1IEh1aS1SNjQzNDMNCj4gQ2M6IGRldmljZXRyZWVAdmdlci5rZXJu
ZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtlcm5l
bEBsaXN0cy5pbmZyYWRlYWQub3JnOyBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207DQo+IGdyYW50
Lmxpa2VseUBsaW5hcm8ub3JnDQo+IFN1YmplY3Q6IFJlOiBUaGUgYWxpZ25tZW50IG1pc21hdGNo
IGlzc3VlcyBiZXR3ZWVuIHRoZSBvZl9yZXNlcnZlZF9tZW0NCj4gYW5kIHRoZSBDTUEgc2V0dXAg
cmVxdWlyZW1lbnQNCj4gDQo+IE9uIE1vbiwgTm92IDksIDIwMTUgYXQgMzozOSBBTSwgTGl1IEph
c29uIDxIdWkuTGl1QGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPiA+IFRoZXJlIGlzIGFuIGFsaWdu
bWVudCBtaXNtYXRjaCBpc3N1ZSBiZXR3ZWVuIHRoZSBvZl9yZXNlcnZlZF9tZW0gYW5kDQo+IHRo
ZSBDTUEgc2V0dXAgcmVxdWlyZW1lbnQuDQo+ID4NCj4gPiBUaGUgYWxpZ25tZW50IGluDQo+ID4g
RG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Jlc2VydmVkLW1lbW9yeS9yZXNlcnZl
ZC1tZW1vcnkudHh0DQo+ID4NCj4gPg0KPiA+IGFsaWdubWVudCAob3B0aW9uYWwpIC0gbGVuZ3Ro
IGJhc2VkIG9uIHBhcmVudCdzICNzaXplLWNlbGxzDQo+ID4gICAgICAgICAgICAgICAgICAgICAg
ICAgLSBBZGRyZXNzIGJvdW5kYXJ5IGZvciBhbGlnbm1lbnQgb2YgYWxsb2NhdGlvbi4NCj4gPg0K
PiA+DQo+ID4gQnV0IHRoaXMgaXMgbm90IGV4YWN0bHkgbWF0Y2ggdGhlIENNQSBzZXR1cCByZXF1
aXJlbWVudCBpZiB0aGUNCj4gYWxpZ25tZW50IG5vdCBzZXQgb3Igc2V0IGl0IG5vdCBjb3JyZWN0
bHkuDQo+ID4NCj4gPiBUaGUgb2ZfcmVzZXJ2ZWRfbWVtIHdpbGwgZ2V0IHRoZSBhbGlnbm1lbnQg
ZnJvbSB0aGUgRFRTIGFuZCBwYXNzIGl0IHRvDQo+ID4gX19tZW1ibG9ja19hbGxvY19iYXNlIHRv
IGRvIHRoZSBtZW1vcnkgYmxvY2sgYWxsb2NhdGlvbi4gSWYgbm8NCj4gPiBhbGlnbm1lbnQgcHJv
cGVydHkgaW4gdGhlIERUUywgdGhlIGFsaWduIHdpbGwgYmUgU01QX0NBQ0hFX0JZVEVTDQo+IA0K
PiBJTU8sIGFueSBhbGlnbm1lbnQgcmVxdWlyZW1lbnQgaW4gdGhlIERUQiBzaG91bGQgcmVmbGVj
dCBoL3cgYWxpZ25tZW50DQo+IHJlcXVpcmVtZW50cy4gV2UgY2FuJ3Qga25vdyB3aGF0IGFsaWdu
bWVudCB0aGUgT1Mgd2FudHMuIFNvIGlmIHRoZSBPUw0KPiBuZWVkcyB0byBmdXJ0aGVyIGluY3Jl
YXNlIHRoZSBhbGlnbm1lbnQsIGl0IHNob3VsZCBhZGp1c3QgdGhlIGFsaWdubWVudC4NCj4gDQoN
CkFncmVlLg0KDQo+ID4NCj4gPiBCVVQsIFRoZSBDTUEgc2V0dXAgcmVxdWlyZSB0aGUgYWxpZ25t
ZW50IGFzIHRoZSBmb2xsb3dpbmcgaW4gdGhlIGNvZGU6DQo+ID4NCj4gPiBhbGlnbiA9IFBBR0Vf
U0laRSA8PCBtYXgoTUFYX09SREVSIC0gMSwgcGFnZWJsb2NrX29yZGVyKQ0KPiA+DQo+ID4gc3Rh
dGljIGludCBfX2luaXQgcm1lbV9jbWFfc2V0dXAoc3RydWN0IHJlc2VydmVkX21lbSAqcm1lbSkg
ew0KPiA+ICAgICAgICAgcGh5c19hZGRyX3QgYWxpZ24gPSBQQUdFX1NJWkUgPDwgbWF4KE1BWF9P
UkRFUiAtIDEsDQo+IHBhZ2VibG9ja19vcmRlcik7DQo+ID4gICAgICAgICBwaHlzX2FkZHJfdCBt
YXNrID0gYWxpZ24gLSAxOw0KPiA+ICAgICAgICAgdW5zaWduZWQgbG9uZyBub2RlID0gcm1lbS0+
ZmR0X25vZGU7DQo+ID4gICAgICAgICBzdHJ1Y3QgY21hICpjbWE7DQo+ID4gICAgICAgICBpbnQg
ZXJyOw0KPiA+DQo+ID4gICAgICAgICBpZiAoIW9mX2dldF9mbGF0X2R0X3Byb3Aobm9kZSwgInJl
dXNhYmxlIiwgTlVMTCkgfHwNCj4gPiAgICAgICAgICAgICBvZl9nZXRfZmxhdF9kdF9wcm9wKG5v
ZGUsICJuby1tYXAiLCBOVUxMKSkNCj4gPiAgICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7
DQo+ID4NCj4gPiAgICAgICAgIGlmICgocm1lbS0+YmFzZSAmIG1hc2spIHx8IChybWVtLT5zaXpl
ICYgbWFzaykpIHsNCj4gPiAgICAgICAgICAgICAgICAgcHJfZXJyKCJSZXNlcnZlZCBtZW1vcnk6
IGluY29ycmVjdCBhbGlnbm1lbnQgb2YgQ01BDQo+IHJlZ2lvblxuIik7DQo+ID4gICAgICAgICAg
ICAgICAgIHJldHVybiAtRUlOVkFMOw0KPiA+ICAgICAgICAgfQ0KPiA+ICAgICAgICAgPHNuaXA+
DQo+ID4gfQ0KPiA+DQo+ID4gU28sIHRoZXJlIGlzIHZlcnkgbGlrZWx5IHRoYXQgdGhlIGFsaWdu
bWVudCBtaXNtYXRjaCBiZXR3ZWVuIHRoZQ0KPiBvZl9yZXNlcnZlZF9tZW0gYW5kIHRoZSBDTUEg
c2V0dXAgcmVxdWlyZW1lbnQuDQo+ID4gVGhlIHNhbml0eSBjaGVjayBpbiB0aGUgcm1lbV9jbWFf
c2V0dXAgd2lsbCBmYWlsIGFuZCBDTUEgbm90IGdldCBzZXQgdXANCj4gaW4gdGhlIGVuZCwgdGhp
cyBpcyBub3QgZXhwZWN0ZWQgZm9yIENNQS4NCj4gPg0KPiA+IEluIHRoZSB0ZXN0LCB0aGVyZSB3
aWxsIGJlIGZvbGxvd2luZyBlcnIgbG9nIHdoZW4gdGhpcyBtaXNtYXRjaCBoYXBwZW4uDQo+ID4N
Cj4gPiBSZXNlcnZlZCBtZW1vcnk6IGluY29ycmVjdCBhbGlnbm1lbnQgb2YgQ01BIHJlZ2lvbi4N
Cj4gPg0KPiA+IFRoZSBmb2xsb3dpbmcgcGF0Y2ggdG8gZml4IHRoaXMgaXNzdWUsIGFueSBjb21t
ZW50cz8NCj4gPg0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPiA9PT09PT09PT09PT09PT09PQ0KPiA+
DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvb2Yvb2ZfcmVzZXJ2ZWRfbWVtLmMNCj4gPiBiL2Ry
aXZlcnMvb2Yvb2ZfcmVzZXJ2ZWRfbWVtLmMgaW5kZXggNjJmNDY3Yi4uYTIwZDRkMyAxMDA2NDQN
Cj4gPiAtLS0gYS9kcml2ZXJzL29mL29mX3Jlc2VydmVkX21lbS5jDQo+ID4gKysrIGIvZHJpdmVy
cy9vZi9vZl9yZXNlcnZlZF9tZW0uYw0KPiA+IEBAIC0xMjQsNiArMTI0LDE1IEBAIHN0YXRpYyBp
bnQgX19pbml0DQo+IF9fcmVzZXJ2ZWRfbWVtX2FsbG9jX3NpemUodW5zaWduZWQgbG9uZyBub2Rl
LA0KPiA+ICAgICAgICAgICAgICAgICBhbGlnbiA9IGR0X21lbV9uZXh0X2NlbGwoZHRfcm9vdF9h
ZGRyX2NlbGxzLCAmcHJvcCk7DQo+ID4gICAgICAgICB9DQo+ID4NCj4gPiArICAgICAgIGlmIChv
Zl9mbGF0X2R0X2lzX2NvbXBhdGlibGUobm9kZSwic2hhcmVkLWRtYS1wb29sIikpIHsNCj4gPiAr
ICAgICAgICAgICAgICAgcGh5c19hZGRyX3QgYWxpZ25fcmVxdWlyZWQgPSBQQUdFX1NJWkUgPDwg
bWF4KE1BWF9PUkRFUg0KPiAtIDEsIHBhZ2VibG9ja19vcmRlcik7DQo+ID4gKyAgICAgICAgICAg
ICAgICBpZiAoIWFsaWduIHx8IGFsaWduICE9IEFMSUdOKGFsaWduLCBhbGlnbl9yZXF1aXJlZCkp
IHsNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgcHJfd2FybigiUmVzZXJ2ZWQgbWVtb3J5
OiB0aGUgYWxpZ25tZW50IG5vdA0KPiBzZXQgdXAgY29ycmVjdGx5IGluICclcycgbm9kZS4iDQo+
ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiY2hhbmdlIGZyb20gJXBhIHRvICVw
YSBcbiIsIHVuYW1lLA0KPiAmYWxpZ24sICZhbGlnbl9yZXF1aXJlZCk7DQo+ID4gKyAgICAgICAg
ICAgICAgICAgICAgICAgIGFsaWduID0gYWxpZ25fcmVxdWlyZWQ7DQo+ID4gKyAgICAgICAgICAg
ICAgICB9DQo+ID4gKyAgICAgICAgfQ0KPiANCj4gWW91IHNpbXBseSBuZWVkIHRoZSBtYXggcmVx
dWlyZWQgZnJvbSB0aGUgRFQgKHdoaWNoIGNvdWxkIGJlIG1vcmUpIG9yIENNQSwNCj4gc28gdGhp
cyBjYW4gYmUgc2ltcGxpZmllZCB0bzoNCj4gDQo+IGFsaWduID0gbWF4KGFsaWduLCBQQUdFX1NJ
WkUgPDwgbWF4KE1BWF9PUkRFUiAtIDEsIHBhZ2VibG9ja19vcmRlcikpOw0KPiANCj4gSSBkb24n
dCB0aGluayB5b3Ugc2hvdWxkIHdhcm4gaGVyZSBlaXRoZXIuDQoNCklmIGRvbid0IHdhbnQgdG8g
Z2l2ZSBzb21lIG1lc3NhZ2UgdG8gdGVsbCB0aGF0IHRoZSBhbGlnbm1lbnQgaW4gdGhlIERUUyBz
cGVjaWZpZWQgaGFzIGJlZW4NClVwZGF0ZWQsIHRoZSBjb2RlIGNhbiBiZSBzaW1wbGVyIGFzIHlv
dSBzYWlkLiANCg0KDQpJIGNhbiBzdWJtaXQgb25lIHBhdGNoIGZvciB0aGlzIGlmIHRoZXJlIGlz
IG5vIG1vcmUgY29tbWVudHMgb24gdGhpcy4gDQoNCj4gDQo+IFJvYg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web