> +static struct sk_buff *am65_cpsw_alloc_skb(struct net_device *ndev, unsigned int len)
> +{
> + struct page *page;
> + struct sk_buff *skb;
> +
> + page = dev_alloc_pages(0);
You are likely to get better performance if you use the page_pool.
When FEC added XDP support, the first set of changes was to make use
of page_pool. That improved the drivers performance. Then XDP was
added on top. Maybe you can follow that pattern.
Andrew
On Mon, Feb 26, 2024 at 03:01:50PM +0100, amergnat(a)baylibre.com wrote:
> index 000000000000..13e95c227114
> --- /dev/null
> +++ b/sound/soc/codecs/mt6357.c
> @@ -0,0 +1,1805 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MT6357 ALSA SoC audio codec driver
> + *
Please use a C++ comment for the whole comment to make it clearer that
this is intentional.
> +static void set_playback_gpio(struct mt6357_priv *priv, bool enable)
> +{
> + if (enable) {
> + /* set gpio mosi mode */
> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_CLR, GPIO_MODE2_CLEAR_ALL);
> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_SET, GPIO8_MODE_SET_AUD_CLK_MOSI |
> + GPIO9_MODE_SET_AUD_DAT_MOSI0 |
> + GPIO10_MODE_SET_AUD_DAT_MOSI1 |
> + GPIO11_MODE_SET_AUD_SYNC_MOSI);
This would be a lot more legible if you worked out the values to set and
then had a single set of writes, currently the indentation makes it very
hard to read. Similarly for other similar functions.
> +static int mt6357_put_volsw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_component *component = snd_soc_kcontrol_component(kcontrol);
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(component);
> + struct soc_mixer_control *mc = (struct soc_mixer_control *)kcontrol->private_value;
> + unsigned int reg;
> + int ret;
> +
> + ret = snd_soc_put_volsw(kcontrol, ucontrol);
> + if (ret < 0)
> + return ret;
> +
> + switch (mc->reg) {
> + case MT6357_ZCD_CON2:
> + regmap_read(priv->regmap, MT6357_ZCD_CON2, ®);
> + priv->ana_gain[ANALOG_VOLUME_HPOUTL] =
> + (reg & AUD_HPL_GAIN_MASK) >> AUD_HPL_GAIN_SFT;
> + priv->ana_gain[ANALOG_VOLUME_HPOUTR] =
> + (reg & AUD_HPR_GAIN_MASK) >> AUD_HPR_GAIN_SFT;
> + break;
It would probably be less code and would definitely be clearer and
simpler to just read the values when we need them rather than constatly
keeping a cache separate to the register cache.
> + /* ul channel swap */
> + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1, 0),
On/off controls should end in Switch.
> +static const char * const hslo_mux_map[] = {
> + "Open", "DACR", "Playback", "Test mode"
> +};
> +
> +static int hslo_mux_map_value[] = {
> + 0x0, 0x1, 0x2, 0x3,
> +};
Why not just use a normal mux here, there's no missing values or
reordering? Similarly for other muxes.
> +static unsigned int mt6357_read(struct snd_soc_component *codec, unsigned int reg)
> +{
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(codec);
> + unsigned int val;
> +
> + pr_debug("%s() reg = 0x%x", __func__, reg);
> + regmap_read(priv->regmap, reg, &val);
> + return val;
> +}
Remove these, there are vastly more logging facilities as standard in
the regmap core.
> +/* Reg bit defines */
> +/* MT6357_GPIO_DIR0 */
> +#define GPIO8_DIR_MASK BIT(8)
> +#define GPIO8_DIR_INPUT 0
Please namespace your defines, these look very generic.
Il 26/02/24 09:50, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
>
> Rename all "mtk_drm_hdmi" to "mtk_hdmi":
> - To align the naming rule
> - To reduce the code size
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Il 26/02/24 09:50, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
>
> Rename all "mtk_drm_crtc" to "mtk_crtc" due to the following benefits:
> - Lower the matches when searching the native drm_crtc* codes
> - Reduce the code size
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Il 26/02/24 09:50, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
>
> Rename all "mtk_drm_ddp_comp" to "mtk_ddp_comp":
> - To align the naming rule
> - To reduce the code size
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Il 26/02/24 09:50, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
>
> Rename all "mtk_drm_plane" to "mtk_plane":
> - To align the naming rule
> - To reduce the code size
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Il 26/02/24 09:50, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
>
> Rename all "mtk_drm_gem" to "mtk_gem":
> - To align the naming rule
> - To reduce the code size
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>
Il 26/02/24 09:50, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
>
> Rename functions of mtk_ddp_comp:
> - To align the naming rule
> - To reduce the code size
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com>
Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>
On Thu, Feb 22, 2024 at 05:33:48PM +0100, Marco Pagani wrote:
> >
> > In this context, the TTM unit tests fail as well in qemu, with worse result:
> > It seems there is some bad cleanup after a failed test case, causing list
> > corruptions in the drm core and ultimately a crash. I don't know if this
> > is also caused by the missing dma_mask initialization.
> >
>
> That's interesting. Which --arch argument are you using to run the
> tests with QEMU?
Example (I am not sure if any of those parameters matters; it is just one
of my tests):
qemu-system-x86_64 -kernel arch/x86/boot/bzImage -M q35 -cpu IvyBridge \
-no-reboot -snapshot -smp 2 \
-device e1000,netdev=net0 -netdev user,id=net0 -m 512 \
-drive file=rootfs.ext2,format=raw,if=ide \
--append "earlycon=uart8250,io,0x3f8,9600n8 root=/dev/sda1 console=ttyS0" \
-d unimp,guest_errors -nographic -monitor none
This results in:
[ ... ]
[ 5.989496] KTAP version 1
[ 5.989639] # Subtest: ttm_device
[ 5.989711] # module: ttm_device_test
[ 5.989760] 1..5
[ 6.002044] ok 1 ttm_device_init_basic
[ 6.013557] ok 2 ttm_device_init_multiple
ILLOPC: ffffffffb8ac9350: 0f 0b
[ 6.022481] ok 3 ttm_device_fini_basic
[ 6.026172] ------------[ cut here ]------------
[ 6.026315] WARNING: CPU: 1 PID: 1575 at drivers/gpu/drm/ttm/ttm_device.c:206 ttm_device_init+0x170/0x190
...
[ 6.135016] ok 3 Above the allocation limit
[ 6.138759] ------------[ cut here ]------------
[ 6.138925] WARNING: CPU: 1 PID: 1595 at kernel/dma/mapping.c:503 dma_alloc_attrs+0xf6/0x100
...
[ 6.143850] # ttm_pool_alloc_basic: ASSERTION FAILED at drivers/gpu/drm/ttm/tests/ttm_pool_test.c:162
[ 6.143850] Expected err == 0, but
[ 6.143850] err == -12 (0xfffffffffffffff4)
[ 6.148824] not ok 4 One page, with coherent DMA mappings enabled
From there things go downhill.
[ 6.152821] list_add corruption. prev->next should be next (ffffffffbbd53950), but was 0000000000000000. (prev=ffff8af1c38f9e20).
and so on until the emulation crashes.
Guenter
Hi Marco,
On 2/22/24 07:32, Marco Pagani wrote:
>
>
> On 2024-02-18 16:49, Guenter Roeck wrote:
>> Hi,
>>
>> On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote:
>>> This patch introduces an initial KUnit test suite for GEM objects
>>> backed by shmem buffers.
>>>
>>> Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com>
>>> Signed-off-by: Marco Pagani <marpagan(a)redhat.com>
>>
>> When running this in qemu, I get lots of warnings backtraces in the drm
>> core.
>>
>> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:327
>> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:173
>> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:385
>> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:211
>> WARNING: CPU: 0 PID: 1345 at kernel/dma/mapping.c:194
>> WARNING: CPU: 0 PID: 1347 at drivers/gpu/drm/drm_gem_shmem_helper.c:429
>> WARNING: CPU: 0 PID: 1349 at drivers/gpu/drm/drm_gem_shmem_helper.c:445
>>
>> It looks like dma_resv_assert_held() asserts each time it is executed.
>> The backtrace in kernel/dma/mapping.c is triggered by
>> if (WARN_ON_ONCE(!dev->dma_mask))
>> return 0;
>> in __dma_map_sg_attrs().
>>
>> Is this a possible problem in the test code, or can it be caused by
>> some limitations or bugs in the qemu emulation ? If so, do you have any
>> thoughts or ideas what those limitations / bugs might be ?
>
> Hi Guenter,
>
> Thanks for reporting this issue. As you correctly noted, the warnings appear to
> be caused by the dma_mask in the mock device being uninitialized. I'll send a
> patch to fix it soon.
>
Thanks a lot for the update.
In this context, the TTM unit tests fail as well in qemu, with worse result:
It seems there is some bad cleanup after a failed test case, causing list
corruptions in the drm core and ultimately a crash. I don't know if this
is also caused by the missing dma_mask initialization.
Thanks,
Guenter
Hi,
On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote:
> This patch introduces an initial KUnit test suite for GEM objects
> backed by shmem buffers.
>
> Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com>
> Signed-off-by: Marco Pagani <marpagan(a)redhat.com>
When running this in qemu, I get lots of warnings backtraces in the drm
core.
WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:327
WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:173
WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:385
WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:211
WARNING: CPU: 0 PID: 1345 at kernel/dma/mapping.c:194
WARNING: CPU: 0 PID: 1347 at drivers/gpu/drm/drm_gem_shmem_helper.c:429
WARNING: CPU: 0 PID: 1349 at drivers/gpu/drm/drm_gem_shmem_helper.c:445
It looks like dma_resv_assert_held() asserts each time it is executed.
The backtrace in kernel/dma/mapping.c is triggered by
if (WARN_ON_ONCE(!dev->dma_mask))
return 0;
in __dma_map_sg_attrs().
Is this a possible problem in the test code, or can it be caused by
some limitations or bugs in the qemu emulation ? If so, do you have any
thoughts or ideas what those limitations / bugs might be ?
Thanks,
Guenter
They rather fundamentally break the entire concept of zero copy, so if
an exporter manages to hand these out things will break all over.
Luckily there's not too many case that use
swiotlb_sync_single_for_device/cpu():
- The generic iommu dma-api code in drivers/iommu/dma-iommu.c. We can
catch that with sg_dma_is_swiotlb() reliably.
- The generic direct dma code in kernel/dma/direct.c. We can mostly
catch that with looking for a NULL dma_ops, except for some powerpc
special cases.
- Xen, which I don't bother to catch here.
Implement these checks in dma_buf_map_attachment when
CONFIG_DMA_API_DEBUG is enabled.
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: "Christian König" <christian.koenig(a)amd.com>
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
Cc: Paul Cercueil <paul(a)crapouillou.net>
---
Entirely untested, but since I sent the mail with the idea I figured I
might as well type it up after I realized there's a lot fewer cases to
check. That is, if I haven't completely misread the dma-api and swiotlb
code.
-Sima
---
drivers/dma-buf/dma-buf.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d1e7f823fbdb..d6f95523f995 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -28,6 +28,12 @@
#include <linux/mount.h>
#include <linux/pseudo_fs.h>
+#ifdef CONFIG_DMA_API_DEBUG
+#include <linux/dma-direct.h>
+#include <linux/dma-map-ops.h>
+#include <linux/swiotlb.h>
+#endif
+
#include <uapi/linux/dma-buf.h>
#include <uapi/linux/magic.h>
@@ -1149,10 +1155,13 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
#ifdef CONFIG_DMA_API_DEBUG
if (!IS_ERR(sg_table)) {
struct scatterlist *sg;
+ struct device *dev = attach->dev;
u64 addr;
int len;
int i;
+ bool is_direct_dma = !get_dma_ops(dev);
+
for_each_sgtable_dma_sg(sg_table, sg, i) {
addr = sg_dma_address(sg);
len = sg_dma_len(sg);
@@ -1160,7 +1169,15 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
pr_debug("%s: addr %llx or len %x is not page aligned!\n",
__func__, addr, len);
}
+
+ if (is_direct_dma) {
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ WARN_ON_ONCE(is_swiotlb_buffer(dev, paddr));
+ }
}
+
+ WARN_ON_ONCE(sg_dma_is_swiotlb(sg));
}
#endif /* CONFIG_DMA_API_DEBUG */
return sg_table;
--
2.43.0