ion to
remove them all. But to me, the DRM-based solution for those displays
is still very young, so it makes sense to leave a bit of time for
people to convert the drivers over to the new DRM-based solution.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
quot;, you're thinking about drivers for I2C or
SPI connected displays.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
ry simple I2C-based or SPI-based displays,
and DRM is I believe overkill for such displays. Last time I talked
with Laurent Pinchart about such drivers, I believe he said that such
simple drivers could probably continue to use the fbdev subsystem.
Or are there some plans to make the writing
learly heavily based on Mehdi's work, wouldn't it make sense
to preserve Mehdi's authorship for the patches?
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
eally Mehdi's code anymore, but just inspired, then you should
set yourself as the author (Author: field of the git commit + the first
Signed-off-by), and credit Mehdi via a Co-developed-by: tag.
In any case, thanks a lot for this pushing this work, much appreciated!
Thomas
--
Thomas Peta
new
parameter, you'll have 8 variants. Doesn't seem really good.
What about reset_control_get(struct device *, const char *, int flags)
to replace all those variants ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
h
sting reset_control_get_*() functions, rather than introducing
separate exclusive variants ?
Indeed, with a "int flags" argument you could in the future add more
variants/behaviors without actually multiplying the number of
functions. Something like the "flags" argument for
whole, no? Maybe you need to suffix
it with "-audio", like the existing compatible string for audio in this
driver.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
l, it would definitely help in
understanding the shortcomings/limitations.
Thanks a lot!
Thomas Petazzoni
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
rify what is the "reference" user-space user of UIO that
exists today?
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
stem. It's a weird custom device that doesn't fit in any
existing subsystem, and that happens to do "peripheral DMA" (i.e the IP
block is DMA-capable itself, without relying on a separate DMA
controller). So this (very valid) recommendation from the UIO
documentation doesn't
Hello Christoph,
On Mon, 14 Apr 2025 04:24:21 -0700
Christoph Hellwig wrote:
> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
> > What this patch series is about is to add new user-space interface to
> > extend the existing UIO subsystem.
>
> Which as
but they would have an on-going maintenance effort for the whole
community).
> And that is what people usually don't want and that's why no in-tree
> solution exists for this.
And that doesn't make sense because UIO already exists, and allows to
achieve 95% of what people already
located through a sane API is not reducing the safety of
anything compared to what UIO already allows today.
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
14 matches
Mail list logo
