* [PATCH 0/5] Fix some bugs on RV32 build fail and issue. @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: palmer, aou; +Cc: vincentc, linux-riscv, linux-kernel, zong, Zong Li This patches fix up the building fail, less function and other issue on RV32. Vincent Chen (1): RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap Zong Li (4): RISC-V: Build tishift only on 64-bit RISC-V: Use swiotlb on RV64 only lib: Add umoddi3 and udivmoddi4 of GCC library routines RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 arch/riscv/Kconfig | 1 + arch/riscv/kernel/setup.c | 3 + arch/riscv/lib/Makefile | 3 +- arch/riscv/mm/ioremap.c | 2 +- lib/Kconfig | 3 + lib/Makefile | 1 + lib/udivmoddi4.c | 291 ++++++++++++++++++++++++++++++++++++++++++++++ lib/umoddi3.c | 16 +++ 8 files changed, 318 insertions(+), 2 deletions(-) create mode 100644 lib/udivmoddi4.c create mode 100644 lib/umoddi3.c -- 2.7.4 ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 0/5] Fix some bugs on RV32 build fail and issue. @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: linux-riscv This patches fix up the building fail, less function and other issue on RV32. Vincent Chen (1): RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap Zong Li (4): RISC-V: Build tishift only on 64-bit RISC-V: Use swiotlb on RV64 only lib: Add umoddi3 and udivmoddi4 of GCC library routines RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 arch/riscv/Kconfig | 1 + arch/riscv/kernel/setup.c | 3 + arch/riscv/lib/Makefile | 3 +- arch/riscv/mm/ioremap.c | 2 +- lib/Kconfig | 3 + lib/Makefile | 1 + lib/udivmoddi4.c | 291 ++++++++++++++++++++++++++++++++++++++++++++++ lib/umoddi3.c | 16 +++ 8 files changed, 318 insertions(+), 2 deletions(-) create mode 100644 lib/udivmoddi4.c create mode 100644 lib/umoddi3.c -- 2.7.4 ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 1/5] RISC-V: Build tishift only on 64-bit 2018-09-18 9:19 ` Zong Li @ 2018-09-18 9:19 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: palmer, aou; +Cc: vincentc, linux-riscv, linux-kernel, zong, Zong Li Only RV64 supports 128 integer size. Signed-off-by: Zong Li <zong@andestech.com> --- arch/riscv/lib/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 445ec84..5739bd0 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -2,6 +2,7 @@ lib-y += delay.o lib-y += memcpy.o lib-y += memset.o lib-y += uaccess.o -lib-y += tishift.o + +lib-(CONFIG_64BIT) += tishift.o lib-$(CONFIG_32BIT) += udivdi3.o -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 1/5] RISC-V: Build tishift only on 64-bit @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: linux-riscv Only RV64 supports 128 integer size. Signed-off-by: Zong Li <zong@andestech.com> --- arch/riscv/lib/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 445ec84..5739bd0 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -2,6 +2,7 @@ lib-y += delay.o lib-y += memcpy.o lib-y += memset.o lib-y += uaccess.o -lib-y += tishift.o + +lib-(CONFIG_64BIT) += tishift.o lib-$(CONFIG_32BIT) += udivdi3.o -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 1/5] RISC-V: Build tishift only on 64-bit 2018-09-18 9:19 ` Zong Li @ 2018-09-21 6:58 ` Christoph Hellwig -1 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 6:58 UTC (permalink / raw) To: Zong Li; +Cc: palmer, aou, vincentc, zong, linux-riscv, linux-kernel On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > Only RV64 supports 128 integer size. > > Signed-off-by: Zong Li <zong@andestech.com> This looks fine. Just curious, what do we even need 128-bit integers for on riscv64? Did you see any issues if you drop it entirely? ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 1/5] RISC-V: Build tishift only on 64-bit @ 2018-09-21 6:58 ` Christoph Hellwig 0 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 6:58 UTC (permalink / raw) To: linux-riscv On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > Only RV64 supports 128 integer size. > > Signed-off-by: Zong Li <zong@andestech.com> This looks fine. Just curious, what do we even need 128-bit integers for on riscv64? Did you see any issues if you drop it entirely? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 1/5] RISC-V: Build tishift only on 64-bit 2018-09-21 6:58 ` Christoph Hellwig (?) @ 2018-09-25 2:33 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-25 2:33 UTC (permalink / raw) To: hch Cc: Palmer Dabbelt, aou, Vincent Chen, Zong Li, linux-riscv, Linux Kernel Mailing List Christoph Hellwig <hch@infradead.org> 於 2018年9月21日 週五 下午2:58寫道: > > On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > > Only RV64 supports 128 integer size. > > > > Signed-off-by: Zong Li <zong@andestech.com> > > This looks fine. Just curious, what do we even need 128-bit integers > for on riscv64? Did you see any issues if you drop it entirely? You can refer to this issue, but I didn't try it. https://github.com/riscv/riscv-linux/issues/136 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 1/5] RISC-V: Build tishift only on 64-bit @ 2018-09-25 2:33 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-25 2:33 UTC (permalink / raw) To: hch Cc: Zong Li, aou, Palmer Dabbelt, Linux Kernel Mailing List, Vincent Chen, linux-riscv Christoph Hellwig <hch@infradead.org> 於 2018年9月21日 週五 下午2:58寫道: > > On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > > Only RV64 supports 128 integer size. > > > > Signed-off-by: Zong Li <zong@andestech.com> > > This looks fine. Just curious, what do we even need 128-bit integers > for on riscv64? Did you see any issues if you drop it entirely? You can refer to this issue, but I didn't try it. https://github.com/riscv/riscv-linux/issues/136 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 1/5] RISC-V: Build tishift only on 64-bit @ 2018-09-25 2:33 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-25 2:33 UTC (permalink / raw) To: linux-riscv Christoph Hellwig <hch@infradead.org> ? 2018?9?21? ?? ??2:58??? > > On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > > Only RV64 supports 128 integer size. > > > > Signed-off-by: Zong Li <zong@andestech.com> > > This looks fine. Just curious, what do we even need 128-bit integers > for on riscv64? Did you see any issues if you drop it entirely? You can refer to this issue, but I didn't try it. https://github.com/riscv/riscv-linux/issues/136 ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 2/5] RISC-V: Use swiotlb on RV64 only 2018-09-18 9:19 ` Zong Li @ 2018-09-18 9:19 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: palmer, aou; +Cc: vincentc, linux-riscv, linux-kernel, zong, Zong Li Only RV64 supports swiotlb. Signed-off-by: Zong Li <zong@andestech.com> --- arch/riscv/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index aee6031..872a280 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -227,7 +227,10 @@ void __init setup_arch(char **cmdline_p) setup_bootmem(); paging_init(); unflatten_device_tree(); + +#ifdef CONFIG_64bit swiotlb_init(1); +#endif #ifdef CONFIG_SMP setup_smp(); -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 2/5] RISC-V: Use swiotlb on RV64 only @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: linux-riscv Only RV64 supports swiotlb. Signed-off-by: Zong Li <zong@andestech.com> --- arch/riscv/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index aee6031..872a280 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -227,7 +227,10 @@ void __init setup_arch(char **cmdline_p) setup_bootmem(); paging_init(); unflatten_device_tree(); + +#ifdef CONFIG_64bit swiotlb_init(1); +#endif #ifdef CONFIG_SMP setup_smp(); -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 2/5] RISC-V: Use swiotlb on RV64 only 2018-09-18 9:19 ` Zong Li @ 2018-09-21 6:59 ` Christoph Hellwig -1 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 6:59 UTC (permalink / raw) To: Zong Li; +Cc: palmer, aou, vincentc, zong, linux-riscv, linux-kernel On Tue, Sep 18, 2018 at 05:19:14PM +0800, Zong Li wrote: > Only RV64 supports swiotlb. > > Signed-off-by: Zong Li <zong@andestech.com> Reviewed-by: Christoph Hellwig <hch@lst.de> ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 2/5] RISC-V: Use swiotlb on RV64 only @ 2018-09-21 6:59 ` Christoph Hellwig 0 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 6:59 UTC (permalink / raw) To: linux-riscv On Tue, Sep 18, 2018 at 05:19:14PM +0800, Zong Li wrote: > Only RV64 supports swiotlb. > > Signed-off-by: Zong Li <zong@andestech.com> Reviewed-by: Christoph Hellwig <hch@lst.de> ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-18 9:19 ` Zong Li @ 2018-09-18 9:19 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: palmer, aou; +Cc: vincentc, linux-riscv, linux-kernel, zong, Zong Li Add umoddi3 and udivmoddi4 support for 32-bit. Signed-off-by: Zong Li <zong@andestech.com> --- lib/Kconfig | 3 + lib/Makefile | 1 + lib/udivmoddi4.c | 291 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ lib/umoddi3.c | 16 +++ 4 files changed, 311 insertions(+) create mode 100644 lib/udivmoddi4.c create mode 100644 lib/umoddi3.c diff --git a/lib/Kconfig b/lib/Kconfig index a3928d4..d82f206 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -621,3 +621,6 @@ config GENERIC_LIB_CMPDI2 config GENERIC_LIB_UCMPDI2 bool + +config GENERIC_LIB_UMODDI3 + bool diff --git a/lib/Makefile b/lib/Makefile index ca3f7eb..51bf24d 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -271,3 +271,4 @@ obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o +obj-$(CONFIG_GENERIC_LIB_UMODDI3) += umoddi3.o udivmoddi4.o diff --git a/lib/udivmoddi4.c b/lib/udivmoddi4.c new file mode 100644 index 0000000..69f2d36 --- /dev/null +++ b/lib/udivmoddi4.c @@ -0,0 +1,291 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/libgcc.h> + +#define count_leading_zeros(COUNT, X) ((COUNT) = __builtin_clz(X)) + +#define W_TYPE_SIZE 32 + +#define __ll_B ((unsigned long) 1 << (W_TYPE_SIZE / 2)) +#define __ll_lowpart(t) ((unsigned long) (t) & (__ll_B - 1)) +#define __ll_highpart(t) ((unsigned long) (t) >> (W_TYPE_SIZE / 2)) + +/* If we still don't have umul_ppmm, define it using plain C. */ +#if !defined(umul_ppmm) +#define umul_ppmm(w1, w0, u, v) \ + do { \ + unsigned long __x0, __x1, __x2, __x3; \ + unsigned short __ul, __vl, __uh, __vh; \ + \ + __ul = __ll_lowpart(u); \ + __uh = __ll_highpart(u); \ + __vl = __ll_lowpart(v); \ + __vh = __ll_highpart(v); \ + \ + __x0 = (unsigned long) __ul * __vl; \ + __x1 = (unsigned long) __ul * __vh; \ + __x2 = (unsigned long) __uh * __vl; \ + __x3 = (unsigned long) __uh * __vh; \ + \ + __x1 += __ll_highpart(__x0); \ + __x1 += __x2; \ + if (__x1 < __x2) \ + __x3 += __ll_B; \ + \ + (w1) = __x3 + __ll_highpart(__x1); \ + (w0) = __ll_lowpart(__x1) * __ll_B + __ll_lowpart(__x0);\ + } while (0) +#endif + +#if !defined(sub_ddmmss) +#define sub_ddmmss(sh, sl, ah, al, bh, bl) \ + do { \ + unsigned long __x; \ + __x = (al) - (bl); \ + (sh) = (ah) - (bh) - (__x > (al)); \ + (sl) = __x; \ + } while (0) +#endif + +/* Define this unconditionally, so it can be used for debugging. */ +#define __udiv_qrnnd_c(q, r, n1, n0, d) \ + do { \ + unsigned long __d1, __d0, __q1, __q0; \ + unsigned long __r1, __r0, __m; \ + __d1 = __ll_highpart(d); \ + __d0 = __ll_lowpart(d); \ + \ + __r1 = (n1) % __d1; \ + __q1 = (n1) / __d1; \ + __m = (unsigned long) __q1 * __d0; \ + __r1 = __r1 * __ll_B | __ll_highpart(n0); \ + if (__r1 < __m) { \ + __q1--, __r1 += (d); \ + if (__r1 >= (d)) \ + if (__r1 < __m) \ + __q1--, __r1 += (d); \ + } \ + __r1 -= __m; \ + \ + __r0 = __r1 % __d1; \ + __q0 = __r1 / __d1; \ + __m = (unsigned long) __q0 * __d0; \ + __r0 = __r0 * __ll_B | __ll_lowpart(n0); \ + if (__r0 < __m) { \ + __q0--, __r0 += (d); \ + if (__r0 >= (d)) \ + if (__r0 < __m) \ + __q0--, __r0 += (d); \ + } \ + __r0 -= __m; \ + \ + (q) = (unsigned long) __q1 * __ll_B | __q0; \ + (r) = __r0; \ + } while (0) + +/* If udiv_qrnnd was not defined for this processor, use __udiv_qrnnd_c. */ +#if !defined(udiv_qrnnd) +#define UDIV_NEEDS_NORMALIZATION 1 +#define udiv_qrnnd __udiv_qrnnd_c +#endif + +unsigned long long __udivmoddi4(unsigned long long u, unsigned long long v, + unsigned long long *rp) +{ + const DWunion nn = {.ll = u }; + const DWunion dd = {.ll = v }; + DWunion rr, ww; + unsigned long d0, d1, n0, n1, n2; + unsigned long q0 = 0, q1 = 0; + unsigned long b, bm; + + d0 = dd.s.low; + d1 = dd.s.high; + n0 = nn.s.low; + n1 = nn.s.high; + +#if !UDIV_NEEDS_NORMALIZATION + + if (d1 == 0) { + if (d0 > n1) { + /* 0q = nn / 0D */ + + udiv_qrnnd(q0, n0, n1, n0, d0); + q1 = 0; + + /* Remainder in n0. */ + } else { + /* qq = NN / 0d */ + + if (d0 == 0) + /* Divide intentionally by zero. */ + d0 = 1 / d0; + + udiv_qrnnd(q1, n1, 0, n1, d0); + udiv_qrnnd(q0, n0, n1, n0, d0); + + /* Remainder in n0. */ + } + + if (rp != 0) { + rr.s.low = n0; + rr.s.high = 0; + *rp = rr.ll; + } +#else /* UDIV_NEEDS_NORMALIZATION */ + + if (d1 == 0) { + if (d0 > n1) { + /* 0q = nn / 0D */ + + count_leading_zeros(bm, d0); + + if (bm != 0) { + /* + * Normalize, i.e. make the most significant bit + * of the denominator set. + */ + + d0 = d0 << bm; + n1 = (n1 << bm) | (n0 >> (W_TYPE_SIZE - bm)); + n0 = n0 << bm; + } + + udiv_qrnnd(q0, n0, n1, n0, d0); + q1 = 0; + + /* Remainder in n0 >> bm. */ + } else { + /* qq = NN / 0d */ + + if (d0 == 0) + /* Divide intentionally by zero. */ + d0 = 1 / d0; + + count_leading_zeros(bm, d0); + + if (bm == 0) { + /* + * From (n1 >= d0) /\ (the most significant bit + * of d0 is set), conclude (the most significant + * bit of n1 is set) /\ (theleading quotient + * digit q1 = 1). + * + * This special case is necessary, not an + * optimization. (Shifts counts of W_TYPE_SIZE + * are undefined.) + */ + + n1 -= d0; + q1 = 1; + } else { + /* Normalize. */ + + b = W_TYPE_SIZE - bm; + + d0 = d0 << bm; + n2 = n1 >> b; + n1 = (n1 << bm) | (n0 >> b); + n0 = n0 << bm; + + udiv_qrnnd(q1, n1, n2, n1, d0); + } + + /* n1 != d0... */ + + udiv_qrnnd(q0, n0, n1, n0, d0); + + /* Remainder in n0 >> bm. */ + } + + if (rp != 0) { + rr.s.low = n0 >> bm; + rr.s.high = 0; + *rp = rr.ll; + } +#endif /* UDIV_NEEDS_NORMALIZATION */ + + } else { + if (d1 > n1) { + /* 00 = nn / DD */ + + q0 = 0; + q1 = 0; + + /* Remainder in n1n0. */ + if (rp != 0) { + rr.s.low = n0; + rr.s.high = n1; + *rp = rr.ll; + } + } else { + /* 0q = NN / dd */ + + count_leading_zeros(bm, d1); + if (bm == 0) { + /* + * From (n1 >= d1) /\ (the most significant bit + * of d1 is set), conclude (the most significant + * bit of n1 is set) /\ (the quotient digit q0 = + * 0 or 1). + * + * This special case is necessary, not an + * optimization. + */ + + /* + * The condition on the next line takes + * advantage of that n1 >= d1 (true due to + * program flow). + */ + if (n1 > d1 || n0 >= d0) { + q0 = 1; + sub_ddmmss(n1, n0, n1, n0, d1, d0); + } else { + q0 = 0; + } + + q1 = 0; + + if (rp != 0) { + rr.s.low = n0; + rr.s.high = n1; + *rp = rr.ll; + } + } else { + unsigned long m1, m0; + /* Normalize. */ + + b = W_TYPE_SIZE - bm; + + d1 = (d1 << bm) | (d0 >> b); + d0 = d0 << bm; + n2 = n1 >> b; + n1 = (n1 << bm) | (n0 >> b); + n0 = n0 << bm; + + udiv_qrnnd(q0, n1, n2, n1, d1); + umul_ppmm(m1, m0, q0, d0); + + if (m1 > n1 || (m1 == n1 && m0 > n0)) { + q0--; + sub_ddmmss(m1, m0, m1, m0, d1, d0); + } + + q1 = 0; + + /* Remainder in (n1n0 - m1m0) >> bm. */ + if (rp != 0) { + sub_ddmmss(n1, n0, n1, n0, m1, m0); + rr.s.low = (n1 << b) | (n0 >> bm); + rr.s.high = n1 >> bm; + *rp = rr.ll; + } + } + } + } + + ww.s.low = q0; + ww.s.high = q1; + return ww.ll; +} diff --git a/lib/umoddi3.c b/lib/umoddi3.c new file mode 100644 index 0000000..85b2b86 --- /dev/null +++ b/lib/umoddi3.c @@ -0,0 +1,16 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/module.h> +#include <linux/libgcc.h> + +extern unsigned long long __udivmoddi4(unsigned long long u, + unsigned long long v, + unsigned long long *rp); + +unsigned long long __umoddi3(unsigned long long u, unsigned long long v) +{ + unsigned long long w; + (void)__udivmoddi4(u, v, &w); + return w; +} +EXPORT_SYMBOL(__umoddi3); -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: linux-riscv Add umoddi3 and udivmoddi4 support for 32-bit. Signed-off-by: Zong Li <zong@andestech.com> --- lib/Kconfig | 3 + lib/Makefile | 1 + lib/udivmoddi4.c | 291 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ lib/umoddi3.c | 16 +++ 4 files changed, 311 insertions(+) create mode 100644 lib/udivmoddi4.c create mode 100644 lib/umoddi3.c diff --git a/lib/Kconfig b/lib/Kconfig index a3928d4..d82f206 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -621,3 +621,6 @@ config GENERIC_LIB_CMPDI2 config GENERIC_LIB_UCMPDI2 bool + +config GENERIC_LIB_UMODDI3 + bool diff --git a/lib/Makefile b/lib/Makefile index ca3f7eb..51bf24d 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -271,3 +271,4 @@ obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o +obj-$(CONFIG_GENERIC_LIB_UMODDI3) += umoddi3.o udivmoddi4.o diff --git a/lib/udivmoddi4.c b/lib/udivmoddi4.c new file mode 100644 index 0000000..69f2d36 --- /dev/null +++ b/lib/udivmoddi4.c @@ -0,0 +1,291 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/libgcc.h> + +#define count_leading_zeros(COUNT, X) ((COUNT) = __builtin_clz(X)) + +#define W_TYPE_SIZE 32 + +#define __ll_B ((unsigned long) 1 << (W_TYPE_SIZE / 2)) +#define __ll_lowpart(t) ((unsigned long) (t) & (__ll_B - 1)) +#define __ll_highpart(t) ((unsigned long) (t) >> (W_TYPE_SIZE / 2)) + +/* If we still don't have umul_ppmm, define it using plain C. */ +#if !defined(umul_ppmm) +#define umul_ppmm(w1, w0, u, v) \ + do { \ + unsigned long __x0, __x1, __x2, __x3; \ + unsigned short __ul, __vl, __uh, __vh; \ + \ + __ul = __ll_lowpart(u); \ + __uh = __ll_highpart(u); \ + __vl = __ll_lowpart(v); \ + __vh = __ll_highpart(v); \ + \ + __x0 = (unsigned long) __ul * __vl; \ + __x1 = (unsigned long) __ul * __vh; \ + __x2 = (unsigned long) __uh * __vl; \ + __x3 = (unsigned long) __uh * __vh; \ + \ + __x1 += __ll_highpart(__x0); \ + __x1 += __x2; \ + if (__x1 < __x2) \ + __x3 += __ll_B; \ + \ + (w1) = __x3 + __ll_highpart(__x1); \ + (w0) = __ll_lowpart(__x1) * __ll_B + __ll_lowpart(__x0);\ + } while (0) +#endif + +#if !defined(sub_ddmmss) +#define sub_ddmmss(sh, sl, ah, al, bh, bl) \ + do { \ + unsigned long __x; \ + __x = (al) - (bl); \ + (sh) = (ah) - (bh) - (__x > (al)); \ + (sl) = __x; \ + } while (0) +#endif + +/* Define this unconditionally, so it can be used for debugging. */ +#define __udiv_qrnnd_c(q, r, n1, n0, d) \ + do { \ + unsigned long __d1, __d0, __q1, __q0; \ + unsigned long __r1, __r0, __m; \ + __d1 = __ll_highpart(d); \ + __d0 = __ll_lowpart(d); \ + \ + __r1 = (n1) % __d1; \ + __q1 = (n1) / __d1; \ + __m = (unsigned long) __q1 * __d0; \ + __r1 = __r1 * __ll_B | __ll_highpart(n0); \ + if (__r1 < __m) { \ + __q1--, __r1 += (d); \ + if (__r1 >= (d)) \ + if (__r1 < __m) \ + __q1--, __r1 += (d); \ + } \ + __r1 -= __m; \ + \ + __r0 = __r1 % __d1; \ + __q0 = __r1 / __d1; \ + __m = (unsigned long) __q0 * __d0; \ + __r0 = __r0 * __ll_B | __ll_lowpart(n0); \ + if (__r0 < __m) { \ + __q0--, __r0 += (d); \ + if (__r0 >= (d)) \ + if (__r0 < __m) \ + __q0--, __r0 += (d); \ + } \ + __r0 -= __m; \ + \ + (q) = (unsigned long) __q1 * __ll_B | __q0; \ + (r) = __r0; \ + } while (0) + +/* If udiv_qrnnd was not defined for this processor, use __udiv_qrnnd_c. */ +#if !defined(udiv_qrnnd) +#define UDIV_NEEDS_NORMALIZATION 1 +#define udiv_qrnnd __udiv_qrnnd_c +#endif + +unsigned long long __udivmoddi4(unsigned long long u, unsigned long long v, + unsigned long long *rp) +{ + const DWunion nn = {.ll = u }; + const DWunion dd = {.ll = v }; + DWunion rr, ww; + unsigned long d0, d1, n0, n1, n2; + unsigned long q0 = 0, q1 = 0; + unsigned long b, bm; + + d0 = dd.s.low; + d1 = dd.s.high; + n0 = nn.s.low; + n1 = nn.s.high; + +#if !UDIV_NEEDS_NORMALIZATION + + if (d1 == 0) { + if (d0 > n1) { + /* 0q = nn / 0D */ + + udiv_qrnnd(q0, n0, n1, n0, d0); + q1 = 0; + + /* Remainder in n0. */ + } else { + /* qq = NN / 0d */ + + if (d0 == 0) + /* Divide intentionally by zero. */ + d0 = 1 / d0; + + udiv_qrnnd(q1, n1, 0, n1, d0); + udiv_qrnnd(q0, n0, n1, n0, d0); + + /* Remainder in n0. */ + } + + if (rp != 0) { + rr.s.low = n0; + rr.s.high = 0; + *rp = rr.ll; + } +#else /* UDIV_NEEDS_NORMALIZATION */ + + if (d1 == 0) { + if (d0 > n1) { + /* 0q = nn / 0D */ + + count_leading_zeros(bm, d0); + + if (bm != 0) { + /* + * Normalize, i.e. make the most significant bit + * of the denominator set. + */ + + d0 = d0 << bm; + n1 = (n1 << bm) | (n0 >> (W_TYPE_SIZE - bm)); + n0 = n0 << bm; + } + + udiv_qrnnd(q0, n0, n1, n0, d0); + q1 = 0; + + /* Remainder in n0 >> bm. */ + } else { + /* qq = NN / 0d */ + + if (d0 == 0) + /* Divide intentionally by zero. */ + d0 = 1 / d0; + + count_leading_zeros(bm, d0); + + if (bm == 0) { + /* + * From (n1 >= d0) /\ (the most significant bit + * of d0 is set), conclude (the most significant + * bit of n1 is set) /\ (theleading quotient + * digit q1 = 1). + * + * This special case is necessary, not an + * optimization. (Shifts counts of W_TYPE_SIZE + * are undefined.) + */ + + n1 -= d0; + q1 = 1; + } else { + /* Normalize. */ + + b = W_TYPE_SIZE - bm; + + d0 = d0 << bm; + n2 = n1 >> b; + n1 = (n1 << bm) | (n0 >> b); + n0 = n0 << bm; + + udiv_qrnnd(q1, n1, n2, n1, d0); + } + + /* n1 != d0... */ + + udiv_qrnnd(q0, n0, n1, n0, d0); + + /* Remainder in n0 >> bm. */ + } + + if (rp != 0) { + rr.s.low = n0 >> bm; + rr.s.high = 0; + *rp = rr.ll; + } +#endif /* UDIV_NEEDS_NORMALIZATION */ + + } else { + if (d1 > n1) { + /* 00 = nn / DD */ + + q0 = 0; + q1 = 0; + + /* Remainder in n1n0. */ + if (rp != 0) { + rr.s.low = n0; + rr.s.high = n1; + *rp = rr.ll; + } + } else { + /* 0q = NN / dd */ + + count_leading_zeros(bm, d1); + if (bm == 0) { + /* + * From (n1 >= d1) /\ (the most significant bit + * of d1 is set), conclude (the most significant + * bit of n1 is set) /\ (the quotient digit q0 = + * 0 or 1). + * + * This special case is necessary, not an + * optimization. + */ + + /* + * The condition on the next line takes + * advantage of that n1 >= d1 (true due to + * program flow). + */ + if (n1 > d1 || n0 >= d0) { + q0 = 1; + sub_ddmmss(n1, n0, n1, n0, d1, d0); + } else { + q0 = 0; + } + + q1 = 0; + + if (rp != 0) { + rr.s.low = n0; + rr.s.high = n1; + *rp = rr.ll; + } + } else { + unsigned long m1, m0; + /* Normalize. */ + + b = W_TYPE_SIZE - bm; + + d1 = (d1 << bm) | (d0 >> b); + d0 = d0 << bm; + n2 = n1 >> b; + n1 = (n1 << bm) | (n0 >> b); + n0 = n0 << bm; + + udiv_qrnnd(q0, n1, n2, n1, d1); + umul_ppmm(m1, m0, q0, d0); + + if (m1 > n1 || (m1 == n1 && m0 > n0)) { + q0--; + sub_ddmmss(m1, m0, m1, m0, d1, d0); + } + + q1 = 0; + + /* Remainder in (n1n0 - m1m0) >> bm. */ + if (rp != 0) { + sub_ddmmss(n1, n0, n1, n0, m1, m0); + rr.s.low = (n1 << b) | (n0 >> bm); + rr.s.high = n1 >> bm; + *rp = rr.ll; + } + } + } + } + + ww.s.low = q0; + ww.s.high = q1; + return ww.ll; +} diff --git a/lib/umoddi3.c b/lib/umoddi3.c new file mode 100644 index 0000000..85b2b86 --- /dev/null +++ b/lib/umoddi3.c @@ -0,0 +1,16 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/module.h> +#include <linux/libgcc.h> + +extern unsigned long long __udivmoddi4(unsigned long long u, + unsigned long long v, + unsigned long long *rp); + +unsigned long long __umoddi3(unsigned long long u, unsigned long long v) +{ + unsigned long long w; + (void)__udivmoddi4(u, v, &w); + return w; +} +EXPORT_SYMBOL(__umoddi3); -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-18 9:19 ` Zong Li @ 2018-09-21 7:00 ` Christoph Hellwig -1 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 7:00 UTC (permalink / raw) To: Zong Li; +Cc: palmer, aou, vincentc, zong, linux-riscv, linux-kernel On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > Add umoddi3 and udivmoddi4 support for 32-bit. This probably wants a better explanation of why you need them. > index 0000000..69f2d36 > --- /dev/null > +++ b/lib/udivmoddi4.c > @@ -0,0 +1,291 @@ > +// SPDX-License-Identifier: GPL-2.0 Who wrote this code, where does it come from? ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-21 7:00 ` Christoph Hellwig 0 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 7:00 UTC (permalink / raw) To: linux-riscv On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > Add umoddi3 and udivmoddi4 support for 32-bit. This probably wants a better explanation of why you need them. > index 0000000..69f2d36 > --- /dev/null > +++ b/lib/udivmoddi4.c > @@ -0,0 +1,291 @@ > +// SPDX-License-Identifier: GPL-2.0 Who wrote this code, where does it come from? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-21 7:00 ` Christoph Hellwig (?) @ 2018-09-25 2:19 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-25 2:19 UTC (permalink / raw) To: hch; +Cc: palmer, aou, vincentc, zong, linux-riscv, linux-kernel Christoph Hellwig <hch@infradead.org> 於 2018年9月21日 週五 下午3:00寫道: > > On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > > Add umoddi3 and udivmoddi4 support for 32-bit. > > This probably wants a better explanation of why you need them. > > > index 0000000..69f2d36 > > --- /dev/null > > +++ b/lib/udivmoddi4.c > > @@ -0,0 +1,291 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > Who wrote this code, where does it come from? The RV32 need the umoddi3 to do modulo when the operands are long long type, like other libraries implementation such as ucmpdi2, lshrdi3 and so on. I encounter the undefined reference 'umoddi3' when I use the in house dma driver, although it is in house driver, but I think that umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for flexible extension in the future. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-25 2:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-25 2:19 UTC (permalink / raw) To: hch; +Cc: zong, aou, palmer, linux-kernel, vincentc, linux-riscv Christoph Hellwig <hch@infradead.org> 於 2018年9月21日 週五 下午3:00寫道: > > On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > > Add umoddi3 and udivmoddi4 support for 32-bit. > > This probably wants a better explanation of why you need them. > > > index 0000000..69f2d36 > > --- /dev/null > > +++ b/lib/udivmoddi4.c > > @@ -0,0 +1,291 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > Who wrote this code, where does it come from? The RV32 need the umoddi3 to do modulo when the operands are long long type, like other libraries implementation such as ucmpdi2, lshrdi3 and so on. I encounter the undefined reference 'umoddi3' when I use the in house dma driver, although it is in house driver, but I think that umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for flexible extension in the future. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-25 2:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-25 2:19 UTC (permalink / raw) To: linux-riscv Christoph Hellwig <hch@infradead.org> ? 2018?9?21? ?? ??3:00??? > > On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > > Add umoddi3 and udivmoddi4 support for 32-bit. > > This probably wants a better explanation of why you need them. > > > index 0000000..69f2d36 > > --- /dev/null > > +++ b/lib/udivmoddi4.c > > @@ -0,0 +1,291 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > Who wrote this code, where does it come from? The RV32 need the umoddi3 to do modulo when the operands are long long type, like other libraries implementation such as ucmpdi2, lshrdi3 and so on. I encounter the undefined reference 'umoddi3' when I use the in house dma driver, although it is in house driver, but I think that umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for flexible extension in the future. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-25 2:19 ` Zong Li (?) @ 2018-09-25 7:20 ` Andreas Schwab -1 siblings, 0 replies; 38+ messages in thread From: Andreas Schwab @ 2018-09-25 7:20 UTC (permalink / raw) To: Zong Li; +Cc: hch, palmer, aou, vincentc, zong, linux-riscv, linux-kernel On Sep 25 2018, Zong Li <zongbox@gmail.com> wrote: > The RV32 need the umoddi3 to do modulo when the operands are long long > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > so on. I encounter the undefined reference 'umoddi3' when I use the in > house dma driver, although it is in house driver, but I think that > umoddi3 is a common function for RV32. You probably should use the macros from <asm/div64.h> instead. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-25 7:20 ` Andreas Schwab 0 siblings, 0 replies; 38+ messages in thread From: Andreas Schwab @ 2018-09-25 7:20 UTC (permalink / raw) To: Zong Li; +Cc: vincentc, aou, zong, palmer, linux-kernel, hch, linux-riscv On Sep 25 2018, Zong Li <zongbox@gmail.com> wrote: > The RV32 need the umoddi3 to do modulo when the operands are long long > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > so on. I encounter the undefined reference 'umoddi3' when I use the in > house dma driver, although it is in house driver, but I think that > umoddi3 is a common function for RV32. You probably should use the macros from <asm/div64.h> instead. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-25 7:20 ` Andreas Schwab 0 siblings, 0 replies; 38+ messages in thread From: Andreas Schwab @ 2018-09-25 7:20 UTC (permalink / raw) To: linux-riscv On Sep 25 2018, Zong Li <zongbox@gmail.com> wrote: > The RV32 need the umoddi3 to do modulo when the operands are long long > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > so on. I encounter the undefined reference 'umoddi3' when I use the in > house dma driver, although it is in house driver, but I think that > umoddi3 is a common function for RV32. You probably should use the macros from <asm/div64.h> instead. Andreas. -- Andreas Schwab, SUSE Labs, schwab at suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-25 7:20 ` Andreas Schwab (?) @ 2018-09-26 7:12 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-26 7:12 UTC (permalink / raw) To: schwab Cc: hch, Palmer Dabbelt, aou, Vincent Chen, Zong Li, linux-riscv, Linux Kernel Mailing List Andreas Schwab <schwab@suse.de> 於 2018年9月25日 週二 下午3:20寫道: > > On Sep 25 2018, Zong Li <zongbox@gmail.com> wrote: > > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. > > You probably should use the macros from <asm/div64.h> instead. Hi Andreas, This doesn't work for me, the divisor of my case is also long long type. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-26 7:12 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-26 7:12 UTC (permalink / raw) To: schwab Cc: Vincent Chen, aou, Zong Li, Palmer Dabbelt, Linux Kernel Mailing List, hch, linux-riscv Andreas Schwab <schwab@suse.de> 於 2018年9月25日 週二 下午3:20寫道: > > On Sep 25 2018, Zong Li <zongbox@gmail.com> wrote: > > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. > > You probably should use the macros from <asm/div64.h> instead. Hi Andreas, This doesn't work for me, the divisor of my case is also long long type. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-26 7:12 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-26 7:12 UTC (permalink / raw) To: linux-riscv Andreas Schwab <schwab@suse.de> ? 2018?9?25? ?? ??3:20??? > > On Sep 25 2018, Zong Li <zongbox@gmail.com> wrote: > > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. > > You probably should use the macros from <asm/div64.h> instead. Hi Andreas, This doesn't work for me, the divisor of my case is also long long type. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-25 2:19 ` Zong Li (?) @ 2018-09-25 15:25 ` Christoph Hellwig -1 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-25 15:25 UTC (permalink / raw) To: Zong Li; +Cc: hch, palmer, aou, vincentc, zong, linux-riscv, linux-kernel On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > The RV32 need the umoddi3 to do modulo when the operands are long long > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > so on. I encounter the undefined reference 'umoddi3' when I use the in > house dma driver, although it is in house driver, but I think that > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > copies from libgcc in gcc. There are other functions use the > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > flexible extension in the future. I don't think libgcc is GPLv2 licensed, is it? Also please retain the copyright notices from libgcc. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-25 15:25 ` Christoph Hellwig 0 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-25 15:25 UTC (permalink / raw) To: Zong Li; +Cc: vincentc, aou, zong, palmer, linux-kernel, hch, linux-riscv On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > The RV32 need the umoddi3 to do modulo when the operands are long long > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > so on. I encounter the undefined reference 'umoddi3' when I use the in > house dma driver, although it is in house driver, but I think that > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > copies from libgcc in gcc. There are other functions use the > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > flexible extension in the future. I don't think libgcc is GPLv2 licensed, is it? Also please retain the copyright notices from libgcc. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-25 15:25 ` Christoph Hellwig 0 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-25 15:25 UTC (permalink / raw) To: linux-riscv On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > The RV32 need the umoddi3 to do modulo when the operands are long long > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > so on. I encounter the undefined reference 'umoddi3' when I use the in > house dma driver, although it is in house driver, but I think that > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > copies from libgcc in gcc. There are other functions use the > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > flexible extension in the future. I don't think libgcc is GPLv2 licensed, is it? Also please retain the copyright notices from libgcc. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines 2018-09-25 15:25 ` Christoph Hellwig (?) @ 2018-09-26 2:40 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-26 2:40 UTC (permalink / raw) To: hch Cc: Palmer Dabbelt, aou, Vincent Chen, Zong Li, linux-riscv, Linux Kernel Mailing List Christoph Hellwig <hch@infradead.org> 於 2018年9月25日 週二 下午11:25寫道: > > On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > > copies from libgcc in gcc. There are other functions use the > > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > > flexible extension in the future. > > I don't think libgcc is GPLv2 licensed, is it? Also please retain > the copyright notices from libgcc. I will give next version patch. Thanks. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-26 2:40 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-26 2:40 UTC (permalink / raw) To: hch Cc: Zong Li, aou, Palmer Dabbelt, Linux Kernel Mailing List, Vincent Chen, linux-riscv Christoph Hellwig <hch@infradead.org> 於 2018年9月25日 週二 下午11:25寫道: > > On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > > copies from libgcc in gcc. There are other functions use the > > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > > flexible extension in the future. > > I don't think libgcc is GPLv2 licensed, is it? Also please retain > the copyright notices from libgcc. I will give next version patch. Thanks. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines @ 2018-09-26 2:40 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-26 2:40 UTC (permalink / raw) To: linux-riscv Christoph Hellwig <hch@infradead.org> ? 2018?9?25? ?? ??11:25??? > > On Tue, Sep 25, 2018 at 10:19:55AM +0800, Zong Li wrote: > > The RV32 need the umoddi3 to do modulo when the operands are long long > > type, like other libraries implementation such as ucmpdi2, lshrdi3 and > > so on. I encounter the undefined reference 'umoddi3' when I use the in > > house dma driver, although it is in house driver, but I think that > > umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are > > copies from libgcc in gcc. There are other functions use the > > udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for > > flexible extension in the future. > > I don't think libgcc is GPLv2 licensed, is it? Also please retain > the copyright notices from libgcc. I will give next version patch. Thanks. ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 4/5] RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 2018-09-18 9:19 ` Zong Li @ 2018-09-18 9:19 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: palmer, aou; +Cc: vincentc, linux-riscv, linux-kernel, zong, Zong Li On 32-bit, it need to use __umoddi3 by some drivers. Signed-off-by: Zong Li <zong@andestech.com> --- arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index a344980..dc262fa 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -108,6 +108,7 @@ config ARCH_RV32I select GENERIC_LIB_ASHRDI3 select GENERIC_LIB_LSHRDI3 select GENERIC_LIB_UCMPDI2 + select GENERIC_LIB_UMODDI3 config ARCH_RV64I bool "RV64I" -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 4/5] RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: linux-riscv On 32-bit, it need to use __umoddi3 by some drivers. Signed-off-by: Zong Li <zong@andestech.com> --- arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index a344980..dc262fa 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -108,6 +108,7 @@ config ARCH_RV32I select GENERIC_LIB_ASHRDI3 select GENERIC_LIB_LSHRDI3 select GENERIC_LIB_UCMPDI2 + select GENERIC_LIB_UMODDI3 config ARCH_RV64I bool "RV64I" -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap 2018-09-18 9:19 ` Zong Li @ 2018-09-18 9:19 ` Zong Li -1 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: palmer, aou; +Cc: vincentc, linux-riscv, linux-kernel, zong From: Vincent Chen <vincentc@andestech.com> For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK. Signed-off-by: Vincent Chen <vincentc@andestech.com> --- arch/riscv/mm/ioremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/mm/ioremap.c b/arch/riscv/mm/ioremap.c index 70ef272..bd2f2db 100644 --- a/arch/riscv/mm/ioremap.c +++ b/arch/riscv/mm/ioremap.c @@ -42,7 +42,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, size_t size, /* Page-align mappings */ offset = addr & (~PAGE_MASK); - addr &= PAGE_MASK; + addr -= offset; size = PAGE_ALIGN(size + offset); area = get_vm_area_caller(size, VM_IOREMAP, caller); -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* [PATCH 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap @ 2018-09-18 9:19 ` Zong Li 0 siblings, 0 replies; 38+ messages in thread From: Zong Li @ 2018-09-18 9:19 UTC (permalink / raw) To: linux-riscv From: Vincent Chen <vincentc@andestech.com> For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK. Signed-off-by: Vincent Chen <vincentc@andestech.com> --- arch/riscv/mm/ioremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/mm/ioremap.c b/arch/riscv/mm/ioremap.c index 70ef272..bd2f2db 100644 --- a/arch/riscv/mm/ioremap.c +++ b/arch/riscv/mm/ioremap.c @@ -42,7 +42,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, size_t size, /* Page-align mappings */ offset = addr & (~PAGE_MASK); - addr &= PAGE_MASK; + addr -= offset; size = PAGE_ALIGN(size + offset); area = get_vm_area_caller(size, VM_IOREMAP, caller); -- 2.7.4 ^ permalink raw reply related [flat|nested] 38+ messages in thread
* Re: [PATCH 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap 2018-09-18 9:19 ` Zong Li @ 2018-09-21 7:00 ` Christoph Hellwig -1 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 7:00 UTC (permalink / raw) To: Zong Li; +Cc: palmer, aou, vincentc, zong, linux-riscv, linux-kernel On Tue, Sep 18, 2018 at 05:19:17PM +0800, Zong Li wrote: > From: Vincent Chen <vincentc@andestech.com> > > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero > after AND with PAGE_MASK because the data type of PAGE_MASK is > unsigned long. To fix this problem, the page alignment is done by > subtracting the page offset instead of AND with PAGE_MASK. > > Signed-off-by: Vincent Chen <vincentc@andestech.com> Looks fine, Reviewed-by: Christoph Hellwig <hch@lst.de> ^ permalink raw reply [flat|nested] 38+ messages in thread
* [PATCH 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap @ 2018-09-21 7:00 ` Christoph Hellwig 0 siblings, 0 replies; 38+ messages in thread From: Christoph Hellwig @ 2018-09-21 7:00 UTC (permalink / raw) To: linux-riscv On Tue, Sep 18, 2018 at 05:19:17PM +0800, Zong Li wrote: > From: Vincent Chen <vincentc@andestech.com> > > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero > after AND with PAGE_MASK because the data type of PAGE_MASK is > unsigned long. To fix this problem, the page alignment is done by > subtracting the page offset instead of AND with PAGE_MASK. > > Signed-off-by: Vincent Chen <vincentc@andestech.com> Looks fine, Reviewed-by: Christoph Hellwig <hch@lst.de> ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2018-09-26 7:14 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-18 9:19 [PATCH 0/5] Fix some bugs on RV32 build fail and issue Zong Li 2018-09-18 9:19 ` Zong Li 2018-09-18 9:19 ` [PATCH 1/5] RISC-V: Build tishift only on 64-bit Zong Li 2018-09-18 9:19 ` Zong Li 2018-09-21 6:58 ` Christoph Hellwig 2018-09-21 6:58 ` Christoph Hellwig 2018-09-25 2:33 ` Zong Li 2018-09-25 2:33 ` Zong Li 2018-09-25 2:33 ` Zong Li 2018-09-18 9:19 ` [PATCH 2/5] RISC-V: Use swiotlb on RV64 only Zong Li 2018-09-18 9:19 ` Zong Li 2018-09-21 6:59 ` Christoph Hellwig 2018-09-21 6:59 ` Christoph Hellwig 2018-09-18 9:19 ` [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines Zong Li 2018-09-18 9:19 ` Zong Li 2018-09-21 7:00 ` Christoph Hellwig 2018-09-21 7:00 ` Christoph Hellwig 2018-09-25 2:19 ` Zong Li 2018-09-25 2:19 ` Zong Li 2018-09-25 2:19 ` Zong Li 2018-09-25 7:20 ` Andreas Schwab 2018-09-25 7:20 ` Andreas Schwab 2018-09-25 7:20 ` Andreas Schwab 2018-09-26 7:12 ` Zong Li 2018-09-26 7:12 ` Zong Li 2018-09-26 7:12 ` Zong Li 2018-09-25 15:25 ` Christoph Hellwig 2018-09-25 15:25 ` Christoph Hellwig 2018-09-25 15:25 ` Christoph Hellwig 2018-09-26 2:40 ` Zong Li 2018-09-26 2:40 ` Zong Li 2018-09-26 2:40 ` Zong Li 2018-09-18 9:19 ` [PATCH 4/5] RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 Zong Li 2018-09-18 9:19 ` Zong Li 2018-09-18 9:19 ` [PATCH 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap Zong Li 2018-09-18 9:19 ` Zong Li 2018-09-21 7:00 ` Christoph Hellwig 2018-09-21 7:00 ` Christoph Hellwig
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.