我假设您的板上有针对I2C/GPIO/PWM/UART接口的平台特定驱动程序（它应该是BSP[Board-support-package]的一部分）。
这只是你不想使用内核设备驱动程序框架，并希望从用户空间做的事情.我已经在这种情况下，因此我知道，它可以是多么诱人，特别是，如果你不精通内核设备驱动程序.
a.速度：你提到了，但你可能没有完全掌握原因。
速度效率来自于避免内核和用户空间进程之间的上下文切换。下面是一个例子：

/* A loop in kernel code which reads a register 100 time */
for (i = 0 ; i < 100 ; i++ )
{
  __kernel_read_reg(...);
}

/* A loop in User-space code which reads a register 100 time */
for ( i= 0 ; i < 100; i++)
{
   __user_read_reg(...);
}

字符串

• _read_reg（）在功能上是相同的。假设__user_read_reg（）将经历一个典型的系统调用过程，它必须为每个__user_read_reg（...）执行一次上下文切换，这代价太高了。

你可能会说，“我们可以mmap（）硬件寄存器，避免系统调用这样的操作”。当然，你可以这样做，但我要说的是：接近硬件的操作（例如：寄存器读或写或处理中断）应该尽可能快地完成。上下文切换中涉及的延迟会影响性能。
B.现有/测试/良好构建的子系统：
如果你在Linux内核中看到一个I2C子系统，它提供了一个经过良好测试的，健壮的框架，可以很容易地重用。你不必在用户空间编写完整的I2C子系统（处理所有设备类型，速度，各种配置等）。重用”已经完成的“可能是内核设备驱动程序的一个很大的优势。
c.从基于轮询的方法转向基于中断的机制
如果你没有在内核驱动程序中处理中断，你必须在用户空间进程中使用某种轮询机制.根据系统，它可能不是处理硬件更改的非常可靠的方式.对于快速设备肯定不准确/可靠.
一般来说，基于中断的机制，在这种机制下，你可以尽可能快地处理关键的更改（硬件中断上下文），并将非关键的工作负载转移到用户空间或其他内核机制，这是处理设备的更可靠的方法。
当然，除了以上三个论点之外，还可能有更多的论点和反论点。
您可能感兴趣的另一个线程在这里：Userspace vs kernel space driver

在内核中有通用的用户空间驱动子系统：* 用户空间IO驱动 *。
控制设备的逻辑不一定必须在内核内，因为设备不需要利用内核提供的任何其他资源。
因此，用户空间驱动程序是简单的驱动程序，它只允许对设备寄存器的内存访问和服务中断。
你说你正在使用用户空间程序来控制USB，GPIO，I2C，PWM？
在内核中已经有了这些子系统的内核驱动程序，所以你的用户空间程序可能已经在使用这些子系统的内核驱动程序了。