Messages in this thread | | | Subject | Re: [PATCH v1] spi: fix client driver breakages when using GPIO descriptors | From | Grant Likely <> | Date | Wed, 25 Nov 2020 09:19:15 +0000 |
| |
On 18/11/2020 11:40, Mark Brown wrote: > On Wed, Nov 18, 2020 at 02:03:41AM +0100, Linus Walleij wrote: >> On Mon, Nov 16, 2020 at 10:06 PM Mark Brown <broonie@kernel.org> wrote: > >>> I think the main push in the other direction has always been people who >>> want to not have to write a driver at all and put absolutely everything >>> into DT which has scaling issues :/ > >> What I can't understand is what gave them that idea. > >> This thing looks like a dream to these people for example: >> https://gist.github.com/Minecrell/56c2b20118ba00a9723f0785301bc5ec#file-dsi_panel_s6e88a0_ams452ef01_qhd_octa_video-dtsi >> And it looks like a nightmare to me. > >> (There is even a tool to convert this description into a proper display >> driver now.) > >> It just seems to be one of those golden hammer things: everything >> start to look like nails. > > What people think they were sold was the idea that they shouldn't have > to write driver code or upstream things, something with more AML like > capabilities (not realising that AML works partly because ACPI hugely > constrains system design).
And is also untrue. AML only provides an API abstraction for a specific power management model. All the actual driving of the device still requires driver code and requires reading devices-specific properties out of the ACPI node.
g.
| |