On Thu, 30 Sep 2021, Tomasz Figa wrote: > 2021年9月30日(木) 20:51 Lee Jones <lee.jones@xxxxxxxxxx>: > > > > On Thu, 30 Sep 2021, Tomasz Figa wrote: > > > > > 2021年9月30日(木) 18:23 Lee Jones <lee.jones@xxxxxxxxxx>: > > > > > > > > I've taken the liberty of cherry-picking some of the points you have > > > > reiteratted a few times. Hopefully I can help to address them > > > > adequently. > > > > > > > > On Thu, 30 Sep 2021, Krzysztof Kozlowski wrote: > > > > > Reminder: these are essential drivers and all Exynos platforms must have > > > > > them as built-in (at least till someone really tests this on multiple > > > > > setups). > > > > > > > > > Therefore I don't agree with calling it a "problem" that we select > > > > > *necessary* drivers for supported platforms. It's by design - supported > > > > > platforms should receive them without ability to remove. > > > > > > > > > The selected drivers are essential for supported platforms. > > > > > > > > SoC specific drivers are only essential/necessary/required in > > > > images designed to execute solely on a platform that requires them. > > > > For a kernel image which is designed to be generic i.e. one that has > > > > the ability to boot on vast array of platforms, the drivers simply > > > > have to be *available*. > > > > > > > > Forcing all H/W drivers that are only *potentially* utilised on *some* > > > > platforms as core binary built-ins doesn't make any technical sense. > > > > The two most important issues this causes are image size and a lack of > > > > configurability/flexibility relating to real-world application i.e. > > > > the one issue we already agreed upon; H/W or features that are too > > > > new (pre-release). > > > > > > > > Bloating a generic kernel with potentially hundreds of unnecessary > > > > drivers that will never be executed in the vast majority of instances > > > > doesn't achieve anything. If we have a kernel image that has the > > > > ability to boot on 10's of architectures which have 10's of platforms > > > > each, that's a whole host of unused/wasted executable space. > > > > > > > > In order for vendors to work more closely with upstream, they need the > > > > ability to over-ride a *few* drivers to supplement them with some > > > > functionality which they believe provides them with a competitive edge > > > > (I think you called this "value-add" before) prior to the release of a > > > > device. This is a requirement that cannot be worked around. > > > > > > [Chiming in as a clock driver sub-maintainer and someone who spent a > > > non-insignificant part of his life on SoC driver bring-up - not as a > > > Google employee.] > > > > > > I'd argue that the proper way for them to achieve it would be to > > > extend the upstream frameworks and/or existing drivers with > > > appropriate APIs to allow their downstream modules to plug into what's > > > already available upstream. > > > > Is that the same as exporting symbols to framework APIs? > > > > Since this is already a method GKI uses to allow external modules to > > interact with the core kernel/frameworks. However, it's not possible > > to upstream these without an upstream user for each one. > > Not necessary the core frameworks, could also be changing the ways the > existing drivers register to allow additional drivers to extend the > functionality rather than completely overwrite them. It's really hard > to tell what the right way would be without knowing the exact things > they find missing in the upstream drivers. As for upstream users, this > is exactly the point - upstream is a bidirectional effort, one takes > from it and should contribute things back. > > Generally, the subsystems being mentioned here are so basic (clock, > pinctrl, rtc), that I really can't imagine what kind of rocket science > one might want to hide for competitive reasons... If it's for an > entire SoC, I wonder why Intel and AMD don't have similar concerns and > contribute support for their newest hardware far before the release. I don't have visibility into the driver-overrides I'm afraid. I do know that code-space can be a problem though. So any way we can make the core binary smaller (i.e. remove anything that can be built as a module) will have a positive effect. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
