From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, ext Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>, Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-sunxi <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> Subject: Re: [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC Date: Thu, 19 Jan 2017 21:11:49 +0800 [thread overview] Message-ID: <128701484831509@web34m.yandex.ru> (raw) In-Reply-To: <CACRpkdaTVY7Of5bKyk81xA2kUnZVMQ8LnWEJosg7Ns3s5nAEYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 19.01.2017, 17:23, "Linus Walleij" <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>: > On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote: > >> Any future SoCs could then just use that compatible and would describe >> the SoC details in the DT, like it's meant to be and like we do already, >> but extended by putting the mux value in there as well. >> So the only kernel contribution would then be the DT, really, (...) > > Your different positions have existed since the inception of the > pinctrl subsystem: > > - One camp (myself included) wanted to describe the hardware mostly > in the driver: functions, groups etc are tables in the driver file. > > - Another camp (OMAP included) think that the device tree should take > store most things: groups functions, etc. > > What we know for sure should be described in DT is how different > IP blocks are connected in an SoC (e.g. interrupts, clocks, DMA > channels, regulators) and on the of course outside of the SoC, on > the board. > > The question here is whether the way a hardware has instantiated > a certain IP block when doing physical compilation in their > Verilog, VHDL or SystemC files, is something that should be > described in DT. > > Many companies have developed tools to > extract this data from their hardware design files and provide > it to developers as a blob och incomprehensible data, such was > the situation for OMAP for example. So to them it made most > sense to implement pinctrl-single, just parsing that data into > DTS(I) files. > > Other companies (such as STMicroelectronics) instead put a > team of people to write a datasheet with a special chapter > on how pins etc are connected, and programmers are given > this datasheet and need to again type in the data and define > groups etc. > > Whether parametrization of a HW block should be done in the > driver file from the compatible string or with custom attributes > in the node is not a simple answer to the question. OF is vague > on this kind of things: both solutions exist. > > Allwinner and Qualcomm authors faced a situation such as that > they were given a code dump and no datasheet and no data > tables either. That creates an especially complicated situation > where none of the above scenarios apply. Allwinner do give user manual about the pin controller, and they're used when we write the pinctrl-sunxi driver. > > What we/you need to ask: what is most helpful for the Allwinner > community? What makes the barrier low for new contributions, > and makes it easiest to cooperate? > > I try to live by this motto from IETF: > > "rough consensus and running code" > > Please do the same. > > Yours, > Linus Walleij -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout.
WARNING: multiple messages have this Message-ID (diff)
From: icenowy@aosc.xyz (Icenowy Zheng) To: linux-arm-kernel@lists.infradead.org Subject: [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC Date: Thu, 19 Jan 2017 21:11:49 +0800 [thread overview] Message-ID: <128701484831509@web34m.yandex.ru> (raw) In-Reply-To: <CACRpkdaTVY7Of5bKyk81xA2kUnZVMQ8LnWEJosg7Ns3s5nAEYQ@mail.gmail.com> 19.01.2017, 17:23, "Linus Walleij" <linus.walleij@linaro.org>: > On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara <andre.przywara@arm.com> wrote: > >> ?Any future SoCs could then just use that compatible and would describe >> ?the SoC details in the DT, like it's meant to be and like we do already, >> ?but extended by putting the mux value in there as well. >> ?So the only kernel contribution would then be the DT, really, (...) > > Your different positions have existed since the inception of the > pinctrl subsystem: > > - One camp (myself included) wanted to describe the hardware mostly > ??in the driver: functions, groups etc are tables in the driver file. > > - Another camp (OMAP included) think that the device tree should take > ??store most things: groups functions, etc. > > What we know for sure should be described in DT is how different > IP blocks are connected in an SoC (e.g. interrupts, clocks, DMA > channels, regulators) and on the of course outside of the SoC, on > the board. > > The question here is whether the way a hardware has instantiated > a certain IP block when doing physical compilation in their > Verilog, VHDL or SystemC files, is something that should be > described in DT. > > Many companies have developed tools to > extract this data from their hardware design files and provide > it to developers as a blob och incomprehensible data, such was > the situation for OMAP for example. So to them it made most > sense to implement pinctrl-single, just parsing that data into > DTS(I) files. > > Other companies (such as STMicroelectronics) instead put a > team of people to write a datasheet with a special chapter > on how pins etc are connected, and programmers are given > this datasheet and need to again type in the data and define > groups etc. > > Whether parametrization of a HW block should be done in the > driver file from the compatible string or with custom attributes > in the node is not a simple answer to the question. OF is vague > on this kind of things: both solutions exist. > > Allwinner and Qualcomm authors faced a situation such as that > they were given a code dump and no datasheet and no data > tables either. That creates an especially complicated situation > where none of the above scenarios apply. Allwinner do give user manual about the pin controller, and they're used when we write the pinctrl-sunxi driver. > > What we/you need to ask: what is most helpful for the Allwinner > community? What makes the barrier low for new contributions, > and makes it easiest to cooperate? > > I try to live by this motto from IETF: > > ???"rough consensus and running code" > > Please do the same. > > Yours, > Linus Walleij
next prev parent reply other threads:[~2017-01-19 13:11 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-23 12:50 [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC Icenowy Zheng 2016-12-23 12:50 ` Icenowy Zheng [not found] ` <20161223125001.1176-1-icenowy-ymACFijhrKM@public.gmane.org> 2016-12-23 12:50 ` [PATCH 2/2] arm64: allwinner: Kconfig: add essential pinctrl driver for H5 Icenowy Zheng 2016-12-23 12:50 ` Icenowy Zheng 2016-12-26 14:33 ` [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC André Przywara 2016-12-26 14:33 ` [linux-sunxi] " André Przywara 2016-12-26 14:33 ` André Przywara [not found] ` <1280f095-ab03-93f8-14d2-99d13ba1ce55-5wv7dgnIgG8@public.gmane.org> 2016-12-30 12:55 ` Linus Walleij 2016-12-30 12:55 ` [linux-sunxi] " Linus Walleij 2016-12-30 12:55 ` Linus Walleij 2016-12-30 19:42 ` Tony Lindgren 2016-12-30 19:42 ` Tony Lindgren 2016-12-30 19:42 ` Tony Lindgren [not found] ` <CACRpkdYQhfid3VRcaj=7as_+Zg=pX3Svp9FJ_W_Ft8nVuoZqKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-01-05 22:42 ` Maxime Ripard 2017-01-05 22:42 ` [linux-sunxi] " Maxime Ripard 2017-01-05 22:42 ` Maxime Ripard 2017-01-09 0:16 ` André Przywara 2017-01-09 0:16 ` [linux-sunxi] " André Przywara 2017-01-09 0:16 ` André Przywara 2017-01-16 16:31 ` Maxime Ripard 2017-01-16 16:31 ` Maxime Ripard 2017-01-16 16:31 ` Maxime Ripard 2017-01-18 9:44 ` Andre Przywara 2017-01-18 9:44 ` [linux-sunxi] " Andre Przywara 2017-01-18 9:44 ` Andre Przywara [not found] ` <87a535d3-1170-c388-ce7d-4921e69f4cab-5wv7dgnIgG8@public.gmane.org> 2017-01-19 9:23 ` Linus Walleij 2017-01-19 9:23 ` [linux-sunxi] " Linus Walleij 2017-01-19 9:23 ` Linus Walleij [not found] ` <CACRpkdaTVY7Of5bKyk81xA2kUnZVMQ8LnWEJosg7Ns3s5nAEYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-01-19 13:11 ` Icenowy Zheng [this message] 2017-01-19 13:11 ` Icenowy Zheng [not found] ` <128701484831509-mf8Frdr2Tdlxpj1cXAZ9Bg@public.gmane.org> 2017-01-19 17:29 ` Maxime Ripard 2017-01-19 17:29 ` [linux-sunxi] " Maxime Ripard 2017-01-19 17:29 ` Maxime Ripard 2017-01-19 17:41 ` Maxime Ripard 2017-01-19 17:41 ` [linux-sunxi] " Maxime Ripard 2017-01-19 17:41 ` Maxime Ripard 2017-01-26 10:03 ` Linus Walleij 2017-01-26 10:03 ` [linux-sunxi] " Linus Walleij 2017-01-26 10:03 ` Linus Walleij
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=128701484831509@web34m.yandex.ru \ --to=icenowy-ymacfijhrkm@public.gmane.org \ --cc=andre.przywara-5wv7dgnIgG8@public.gmane.org \ --cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \ --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \ --cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \ --cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \ --cc=wens-jdAy2FN1RRM@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.