Re: [patch] dma-pool: warn when coherent pool is depleted
On Sun, Jun 21, 2020 at 01:43:02PM -0700, David Rientjes wrote:
> When a DMA coherent pool is depleted, allocation failures may or may not
> get reported in the kernel log depending on the allocator.
>
> The admin does have a workaround, however, by using coherent_pool= on the
> kernel command line.
>
> Provide some guidance on the failure and a recommended minimum size for
> the pools (double the size).
>
> Signed-off-by: David Rientjes
Tested-by: Guenter Roeck
Also confirmed that coherent_pool=256k works around the crash
I had observed.
Guenter
> ---
> kernel/dma/pool.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -239,12 +239,16 @@ void *dma_alloc_from_pool(struct device *dev, size_t
> size,
> }
>
> val = gen_pool_alloc(pool, size);
> - if (val) {
> + if (likely(val)) {
> phys_addr_t phys = gen_pool_virt_to_phys(pool, val);
>
> *ret_page = pfn_to_page(__phys_to_pfn(phys));
> ptr = (void *)val;
> memset(ptr, 0, size);
> + } else {
> + WARN_ONCE(1, "DMA coherent pool depleted, increase size "
> + "(recommended min coherent_pool=%zuK)\n",
> + gen_pool_size(pool) >> 9);
> }
> if (gen_pool_avail(pool) < atomic_pool_size)
> schedule_work(_pool_work);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[patch] dma-pool: warn when coherent pool is depleted
When a DMA coherent pool is depleted, allocation failures may or may not
get reported in the kernel log depending on the allocator.
The admin does have a workaround, however, by using coherent_pool= on the
kernel command line.
Provide some guidance on the failure and a recommended minimum size for
the pools (double the size).
Signed-off-by: David Rientjes
---
kernel/dma/pool.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -239,12 +239,16 @@ void *dma_alloc_from_pool(struct device *dev, size_t size,
}
val = gen_pool_alloc(pool, size);
- if (val) {
+ if (likely(val)) {
phys_addr_t phys = gen_pool_virt_to_phys(pool, val);
*ret_page = pfn_to_page(__phys_to_pfn(phys));
ptr = (void *)val;
memset(ptr, 0, size);
+ } else {
+ WARN_ONCE(1, "DMA coherent pool depleted, increase size "
+"(recommended min coherent_pool=%zuK)\n",
+ gen_pool_size(pool) >> 9);
}
if (gen_pool_avail(pool) < atomic_pool_size)
schedule_work(_pool_work);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems
On Sun, 21 Jun 2020, Guenter Roeck wrote:
> >> This patch results in a boot failure in some of my powerpc boot tests,
> >> specifically those testing boots from mptsas1068 devices. Error message:
> >>
> >> mptsas :00:02.0: enabling device ( -> 0002)
> >> mptbase: ioc0: Initiating bringup
> >> ioc0: LSISAS1068 A0: Capabilities={Initiator}
> >> mptbase: ioc0: ERROR - Unable to allocate Reply, Request, Chain Buffers!
> >> mptbase: ioc0: ERROR - didn't initialize properly! (-3)
> >> mptsas: probe of :00:02.0 failed with error -3
> >>
> >> Configuration is bamboo:44x/bamboo_defconfig plus various added drivers.
> >> Qemu command line is
> >>
> >> qemu-system-ppc -kernel vmlinux -M bamboo \
> >> -m 256 -no-reboot -snapshot -device mptsas1068,id=scsi \
> >> -device scsi-hd,bus=scsi.0,drive=d0,wwn=0x5000c50015ea71ac -drive \
> >> file=rootfs.ext2,format=raw,if=none,id=d0 \
> >> --append "panic=-1 slub_debug=FZPUA root=/dev/sda mem=256M
> >> console=ttyS0" \
> >> -monitor none -nographic
> >>
> >> canyonlands_defconfig with sam460ex machine and otherwise similar command
> >> line
> >> fails as well.
> >>
> >> Reverting this patch fixes the problem.
> >
> > This looks like the minimum value of 128 KiB is not sufficient, and the
> > bug is in the intention of 1d659236fb43c4d2 ("dma-pool: scale the
> > default DMA coherent pool size with memory capacity")?
> > Before, there was a single pool of (fixed) 256 KiB size, now there are
> > up to three coherent pools (DMA, DMA32, and kernel), albeit of smaller
> > size (128 KiB each).
> >
> > Can you print the requested size in drivers/message/fusion/mptbase.c:
> > PrimeIocFifos()?
>
> 172928 bytes
>
> > Does replacing all SZ_128K by SZ_256K in my patch help?
>
> Yes, it does.
>
The new coherent pools should auto expand when they are close to being
depleted but there's no guarantee that it can be done fast enough.
Switching the min size to be the previous min size (256KB) seems like the
best option and it matches what
Documentation/admin-guide/kernel-parameters.txt still stays.
I'll also send a patch to point in the right direction when this happens.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: kernel BUG at mm/huge_memory.c:2613!
On Fri, 19 Jun 2020, Roman Gushchin wrote: > > > [ 40.287524] BUG: unable to handle page fault for address: > > > a77b833df000 > > > [ 40.287529] #PF: supervisor write access in kernel mode > > > [ 40.287531] #PF: error_code(0x000b) - reserved bit violation > > > [ 40.287532] PGD 40d14e067 P4D 40d14e067 PUD 40d14f067 PMD 3ec54d067 > > > PTE 80001688033d9163 > > > [ 40.287538] Oops: 000b [#2] SMP NOPTI > > > [ 40.287542] CPU: 9 PID: 1986 Comm: pulseaudio Tainted: G D > > > 5.8.0-rc1+ #697 > > > [ 40.287544] Hardware name: Gigabyte Technology Co., Ltd. > > > AB350-Gaming/AB350-Gaming-CF, BIOS F25 01/16/2019 > > > [ 40.287550] RIP: 0010:__memset+0x24/0x30 > > > [ 40.287553] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 > > > d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 > > > 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 > > > d1 f3 > > > [ 40.287556] RSP: 0018:a77b827a7e08 EFLAGS: 00010216 > > > [ 40.287558] RAX: RBX: 90f77dced800 RCX: > > > 08a0 > > > [ 40.287560] RDX: RSI: RDI: > > > a77b833df000 > > > [ 40.287561] RBP: 90f7898c7000 R08: 90f78c507768 R09: > > > a77b833df000 > > > [ 40.287563] R10: a77b833df000 R11: 90f7839f2d40 R12: > > > > > > [ 40.287564] R13: 90f76a802e00 R14: c0cb8880 R15: > > > 90f770f4e700 > > > [ 40.287567] FS: 7f3d8e8df880() GS:90f78ee4() > > > knlGS: > > > [ 40.287569] CS: 0010 DS: ES: CR0: 80050033 > > > [ 40.287570] CR2: a77b833df000 CR3: 0003fa556000 CR4: > > > 003406e0 > > > [ 40.287572] Call Trace: > > > [ 40.287584] snd_pcm_hw_params+0x3fd/0x490 [snd_pcm] > > > [ 40.287593] snd_pcm_common_ioctl+0x1c5/0x1110 [snd_pcm] > > > [ 40.287601] ? snd_pcm_info_user+0x64/0x80 [snd_pcm] > > > [ 40.287608] snd_pcm_ioctl+0x23/0x30 [snd_pcm] > > > [ 40.287613] ksys_ioctl+0x82/0xc0 > > > [ 40.287617] __x64_sys_ioctl+0x16/0x20 > > > [ 40.287622] do_syscall_64+0x4d/0x90 > > > [ 40.287627] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > Hi Roman, > > > > If you have CONFIG_AMD_MEM_ENCRYPT set, this should be resolved by > > > > commit dbed452a078d56bc7f1abecc3edd6a75e8e4484e > > Author: David Rientjes > > Date: Thu Jun 11 00:25:57 2020 -0700 > > > > dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL > > > > Or you might want to wait for 5.8-rc2 instead which includes this fix. > > > > Hello, David! > > Thank you for pointing at it! Unfortunately, there must be something wrong > with drivers, your patch didn't help much. I still see the same stacktrace. > Wow, I'm very surprised. Do you have CONFIG_AMD_MEM_ENCRYPT enabled? Adding Takashi. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 26/36] drm: host1x: fix common struct sg_table related issues
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200618]
[also build test ERROR on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7
v5.7-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-184302
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: arm64-randconfig-r036-20200621 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
ef455a55bcf2cfea04a99c361b182ad18b7f03f1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/host1x/job.c:230:10: error: implicit declaration of function
>> 'iommu_map_sgtable' [-Werror,-Wimplicit-function-declaration]
err = iommu_map_sgtable(host->domain,
^
drivers/gpu/host1x/job.c:230:10: note: did you mean 'dma_map_sgtable'?
include/linux/dma-mapping.h:628:19: note: 'dma_map_sgtable' declared here
static inline int dma_map_sgtable(struct device *dev, struct sg_table *sgt,
^
1 error generated.
vim +/iommu_map_sgtable +230 drivers/gpu/host1x/job.c
100
101 static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
102 {
103 struct host1x_client *client = job->client;
104 struct device *dev = client->dev;
105 struct iommu_domain *domain;
106 unsigned int i;
107 int err;
108
109 domain = iommu_get_domain_for_dev(dev);
110 job->num_unpins = 0;
111
112 for (i = 0; i < job->num_relocs; i++) {
113 struct host1x_reloc *reloc = >relocs[i];
114 dma_addr_t phys_addr, *phys;
115 struct sg_table *sgt;
116
117 reloc->target.bo = host1x_bo_get(reloc->target.bo);
118 if (!reloc->target.bo) {
119 err = -EINVAL;
120 goto unpin;
121 }
122
123 /*
124 * If the client device is not attached to an IOMMU, the
125 * physical address of the buffer object can be used.
126 *
127 * Similarly, when an IOMMU domain is shared between all
128 * host1x clients, the IOVA is already available, so no
129 * need to map the buffer object again.
130 *
131 * XXX Note that this isn't always safe to do because it
132 * relies on an assumption that no cache maintenance is
133 * needed on the buffer objects.
134 */
135 if (!domain || client->group)
136 phys = _addr;
137 else
138 phys = NULL;
139
140 sgt = host1x_bo_pin(dev, reloc->target.bo, phys);
141 if (IS_ERR(sgt)) {
142 err = PTR_ERR(sgt);
143 goto unpin;
144 }
145
146 if (sgt) {
147 unsigned long mask = HOST1X_RELOC_READ |
148 HOST1X_RELOC_WRITE;
149 enum dma_data_direction dir;
150
151 switch (reloc->flags & mask) {
152 case HOST1X_RELOC_READ:
153 dir = DMA_TO_DEVICE;
154 break;
155
156 case HOST1X_RELOC_WRITE:
157 dir = DMA_FROM_DEVICE;
158 break;
159
160 case HOST1X_RELOC_READ | HOST1X_RELOC_WRITE:
161 dir = DMA_BIDIRECTIONAL;
162 break;
163
164 default:
Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems
On 6/21/20 1:35 AM, Geert Uytterhoeven wrote:
> Hi Günter,
>
> On Sat, Jun 20, 2020 at 10:09 PM Guenter Roeck wrote:
>> On Mon, Jun 08, 2020 at 03:22:17PM +0200, Geert Uytterhoeven wrote:
>>> On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
>>> memory pools are much larger than intended (e.g. 2 MiB instead of 128
>>> KiB on a 256 MiB system).
>>>
>>> Fix this by correcting the calculation of the number of GiBs of RAM in
>>> the system. Invert the order of the min/max operations, to keep on
>>> calculating in pages until the last step, which aids readability.
>>>
>>> Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool
>>> size with memory capacity")
>>> Signed-off-by: Geert Uytterhoeven
>>> Acked-by: David Rientjes
>>
>> This patch results in a boot failure in some of my powerpc boot tests,
>> specifically those testing boots from mptsas1068 devices. Error message:
>>
>> mptsas :00:02.0: enabling device ( -> 0002)
>> mptbase: ioc0: Initiating bringup
>> ioc0: LSISAS1068 A0: Capabilities={Initiator}
>> mptbase: ioc0: ERROR - Unable to allocate Reply, Request, Chain Buffers!
>> mptbase: ioc0: ERROR - didn't initialize properly! (-3)
>> mptsas: probe of :00:02.0 failed with error -3
>>
>> Configuration is bamboo:44x/bamboo_defconfig plus various added drivers.
>> Qemu command line is
>>
>> qemu-system-ppc -kernel vmlinux -M bamboo \
>> -m 256 -no-reboot -snapshot -device mptsas1068,id=scsi \
>> -device scsi-hd,bus=scsi.0,drive=d0,wwn=0x5000c50015ea71ac -drive \
>> file=rootfs.ext2,format=raw,if=none,id=d0 \
>> --append "panic=-1 slub_debug=FZPUA root=/dev/sda mem=256M
>> console=ttyS0" \
>> -monitor none -nographic
>>
>> canyonlands_defconfig with sam460ex machine and otherwise similar command
>> line
>> fails as well.
>>
>> Reverting this patch fixes the problem.
>
> This looks like the minimum value of 128 KiB is not sufficient, and the
> bug is in the intention of 1d659236fb43c4d2 ("dma-pool: scale the
> default DMA coherent pool size with memory capacity")?
> Before, there was a single pool of (fixed) 256 KiB size, now there are
> up to three coherent pools (DMA, DMA32, and kernel), albeit of smaller
> size (128 KiB each).
>
> Can you print the requested size in drivers/message/fusion/mptbase.c:
> PrimeIocFifos()?
172928 bytes
> Does replacing all SZ_128K by SZ_256K in my patch help?
Yes, it does.
Guenter
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 6/7] iommu/mediatek: Add REG_MMU_WR_LEN definition preparing for mt6779
On 19/06/2020 12:56, chao hao wrote:
> On Wed, 2020-06-17 at 11:22 +0200, Matthias Brugger wrote:
>>
>> On 17/06/2020 05:00, Chao Hao wrote:
>>> Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN
>>> to improve performance.
>>> This patch add this register definition.
>>
>> Please be more specific what this register is about.
>>
> OK. thanks.
> We can use "has_wr_len" flag to control whether we need to set the
> register. If the register uses default value, iommu will send command to
> EMI without restriction, when the number of commands become more and
> more, it will drop the EMI performance. So when more than
> ten_commands(default value) don't be handled for EMI, IOMMU will stop
> send command to EMI for keeping EMI's performace by enabling write
> throttling mechanism(bit[5][21]=0) in MMU_WR_LEN_CTRL register.
>
> I will write description above to commit message in next version
>
>>>
>>> Signed-off-by: Chao Hao
>>> ---
>>> drivers/iommu/mtk_iommu.c | 10 ++
>>> drivers/iommu/mtk_iommu.h | 2 ++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>>> index a687e8db0e51..c706bca6487e 100644
>>> --- a/drivers/iommu/mtk_iommu.c
>>> +++ b/drivers/iommu/mtk_iommu.c
>>> @@ -46,6 +46,8 @@
>>> #define F_MMU_STANDARD_AXI_MODE_BIT(BIT(3) | BIT(19))
>>>
>>> #define REG_MMU_DCM_DIS0x050
>>> +#define REG_MMU_WR_LEN 0x054
>>> +#define F_MMU_WR_THROT_DIS_BIT (BIT(5) | BIT(21))
>>>
>>> #define REG_MMU_CTRL_REG 0x110
>>> #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
>>> @@ -581,6 +583,12 @@ static int mtk_iommu_hw_init(const struct
>>> mtk_iommu_data *data)
>>> writel_relaxed(regval, data->base + REG_MMU_VLD_PA_RNG);
>>> }
>>> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>>> + if (data->plat_data->has_wr_len) {
>>> + /* write command throttling mode */
>>> + regval = readl_relaxed(data->base + REG_MMU_WR_LEN);
>>> + regval &= ~F_MMU_WR_THROT_DIS_BIT;
>>> + writel_relaxed(regval, data->base + REG_MMU_WR_LEN);
>>> + }
>>>
>>> if (data->plat_data->reset_axi) {
>>> /* The register is called STANDARD_AXI_MODE in this case */
>>> @@ -737,6 +745,7 @@ static int __maybe_unused mtk_iommu_suspend(struct
>>> device *dev)
>>> struct mtk_iommu_suspend_reg *reg = >reg;
>>> void __iomem *base = data->base;
>>>
>>> + reg->wr_len = readl_relaxed(base + REG_MMU_WR_LEN);
>>
>> Can we read/write the register without any side effect although hardware has
>> not
>> implemented it (!has_wr_len)?
>
> It doesn't have side effect. Becasue all the MTK platform have the
> register for iommu HW. If we need to have requirement for performance,
> we can set it by has_wr_len.
> But I'm Sorry, the name of flag(has_wr_len) is not exact, I will rename
> it in next version, ex: "wr_throt_en"
>
>>
>>
>>> reg->misc_ctrl = readl_relaxed(base + REG_MMU_MISC_CTRL);
>>> reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
>>> reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
>>> @@ -761,6 +770,7 @@ static int __maybe_unused mtk_iommu_resume(struct
>>> device *dev)
>>> dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
>>> return ret;
>>> }
>>> + writel_relaxed(reg->wr_len, base + REG_MMU_WR_LEN);
>>> writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
>>> writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
>>> writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
>>> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
>>> index d51ff99c2c71..9971cedd72ea 100644
>>> --- a/drivers/iommu/mtk_iommu.h
>>> +++ b/drivers/iommu/mtk_iommu.h
>>> @@ -25,6 +25,7 @@ struct mtk_iommu_suspend_reg {
>>> u32 int_main_control;
>>> u32 ivrp_paddr;
>>> u32 vld_pa_rng;
>>> + u32 wr_len;
>>> };
>>>
>>> enum mtk_iommu_plat {
>>> @@ -43,6 +44,7 @@ struct mtk_iommu_plat_data {
>>> boolhas_misc_ctrl;
>>> boolhas_sub_comm;
>>> boolhas_vld_pa_rng;
>>> + boolhas_wr_len;
>>
>> Given the fact that we are adding more and more plat_data bool values, I
>> think
>> it would make sense to use a u32 flags register and add the appropriate macro
>> definitions to set and check for a flag present.
>
> Thanks for your advice.
> do you mean like this:
> struct plat_flag {
>
> #define HAS_4GB_MODE BIT(0)
> #define HAS_BCLK BIT(1)
> #define REST_AXI BIT(2)
> ... ...
>
> u32 flag;
> };
>
> struct mtk_iommu_plat_data {
> ..
> struct plat_flag flag;
> ..
> };
>
Nearly, I mean
Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems
Hi Günter,
On Sat, Jun 20, 2020 at 10:09 PM Guenter Roeck wrote:
> On Mon, Jun 08, 2020 at 03:22:17PM +0200, Geert Uytterhoeven wrote:
> > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> > memory pools are much larger than intended (e.g. 2 MiB instead of 128
> > KiB on a 256 MiB system).
> >
> > Fix this by correcting the calculation of the number of GiBs of RAM in
> > the system. Invert the order of the min/max operations, to keep on
> > calculating in pages until the last step, which aids readability.
> >
> > Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool
> > size with memory capacity")
> > Signed-off-by: Geert Uytterhoeven
> > Acked-by: David Rientjes
>
> This patch results in a boot failure in some of my powerpc boot tests,
> specifically those testing boots from mptsas1068 devices. Error message:
>
> mptsas :00:02.0: enabling device ( -> 0002)
> mptbase: ioc0: Initiating bringup
> ioc0: LSISAS1068 A0: Capabilities={Initiator}
> mptbase: ioc0: ERROR - Unable to allocate Reply, Request, Chain Buffers!
> mptbase: ioc0: ERROR - didn't initialize properly! (-3)
> mptsas: probe of :00:02.0 failed with error -3
>
> Configuration is bamboo:44x/bamboo_defconfig plus various added drivers.
> Qemu command line is
>
> qemu-system-ppc -kernel vmlinux -M bamboo \
> -m 256 -no-reboot -snapshot -device mptsas1068,id=scsi \
> -device scsi-hd,bus=scsi.0,drive=d0,wwn=0x5000c50015ea71ac -drive \
> file=rootfs.ext2,format=raw,if=none,id=d0 \
> --append "panic=-1 slub_debug=FZPUA root=/dev/sda mem=256M
> console=ttyS0" \
> -monitor none -nographic
>
> canyonlands_defconfig with sam460ex machine and otherwise similar command line
> fails as well.
>
> Reverting this patch fixes the problem.
This looks like the minimum value of 128 KiB is not sufficient, and the
bug is in the intention of 1d659236fb43c4d2 ("dma-pool: scale the
default DMA coherent pool size with memory capacity")?
Before, there was a single pool of (fixed) 256 KiB size, now there are
up to three coherent pools (DMA, DMA32, and kernel), albeit of smaller
size (128 KiB each).
Can you print the requested size in drivers/message/fusion/mptbase.c:
PrimeIocFifos()?
Does replacing all SZ_128K by SZ_256K in my patch help?
That would waste^H^H^H^H^Hallocate 256 KiB or 512 KiB more, though.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC][PATCH 4/5] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module
On Mon 15 Jun 23:13 PDT 2020, John Stultz wrote:
> Tweaks to allow pinctrl-msm code to be loadable as a module.
> This is needed in order to support having the qcom-scm driver,
> which pinctrl-msm calls into, configured as a module.
>
This means that we need a "depends on QCOM_SCM || QCOM_SCM=n" on all
entries in the Kconfig that selects PINCTRL_MSM, or switch PINCTRL_MSM
to be user selectable and make all the others depend on it.
> Cc: Andy Gross
> Cc: Bjorn Andersson
> Cc: Joerg Roedel
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Linus Walleij
> Cc: Lina Iyer
> Cc: Saravana Kannan
> Cc: Todd Kjos
> Cc: Greg Kroah-Hartman
> Cc: linux-arm-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: John Stultz
> ---
> drivers/pinctrl/qcom/Kconfig | 2 +-
> drivers/pinctrl/qcom/pinctrl-msm.c | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
> index ff1ee159dca2..5a7e1bc621e6 100644
> --- a/drivers/pinctrl/qcom/Kconfig
> +++ b/drivers/pinctrl/qcom/Kconfig
> @@ -2,7 +2,7 @@
> if (ARCH_QCOM || COMPILE_TEST)
>
> config PINCTRL_MSM
> - bool
> + tristate
> select PINMUX
> select PINCONF
> select GENERIC_PINCONF
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 83b7d64bc4c1..54a226f682e9 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -1355,3 +1355,6 @@ int msm_pinctrl_remove(struct platform_device *pdev)
> }
> EXPORT_SYMBOL(msm_pinctrl_remove);
>
> +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. pinctrl-msm driver");
It's the "Qualcomm Technologies, Inc. TLMM driver"
> +MODULE_LICENSE("GPL v2");
> +
Please don't retain my empty line at the end of this file :)
Regards,
Bjorn
> --
> 2.17.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
