Message ID | 20200831081025.2721320-1-nobuhiro1.iwamatsu@toshiba.co.jp (mailing list archive) |
---|---|
Headers | show |
Series | Add Toshiba Visconti ARM64 Platform support | expand |
On Mon, Aug 31, 2020 at 10:10 AM Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: > > Visconti is a series of Toshiba's SoCs targeting image processing > applications[0]. These set of patches adds support for Visconti5 a Arm > v8 based SoC. > > The series add minimal support for the Visconti5 SoC and the TMPV7708 RM > main board. Peripherals such as UART, SPI, I2c and timer use Arm's > IP and work with the existing kernel drivers in the tree. The series > includes a pinctrl driver to select appropriate functions on the pins. The arch/arm64 series looks all reasonable to me, nice work! Once the review from the DT and pinctrl maintainers is completed and you have received their Acked-by or Reviewed-by tags, please send the series with those tags to soc@kernel.org for inclusion, keeping everyone else on Cc. I'd leave it up to Linus Walleij whether he wants to merge the pinctrl driver through his subsystem tree, or whether we should pick it up through the soc tree, either way works for the initial merge. For any updates to the pinctrl driver and additional subsystem support (clk, media, ...) in later releases there is no need to Cc the SoC maintainers as those should just get merged through the subsystem while we take care of the DT files. > NOTE: Because Visconti5 does not have PSCI, it uses spin-table with enable-method. This sounds like an odd choice. Is this a permanent defect in the SoC or the firmware, or do you expect to change this later once the firmware has been fixed? Note that most systems require PSCI anyway for cpuidle support. If there is any EL2 or EL3 mode firmware already, this is where support for processor bringup should be implemented. If there is none, you can usually implement it using a small EL3 trampoline in the bootloader. > And this patch series does not include a clock framework, so it is a > device-tree file that uses clocks with fixed-clock. This will be replaced by > the clock driver in the future. This is ok for bringup, though we usually recommend to merge the clk driver at the same time as the SoC, in order to avoid having an incompatible DT change when adding the clk driver. Arnd
Hi, Thanks for your review and comment. On Mon, Aug 31, 2020 at 11:19:02AM +0200, Arnd Bergmann wrote: > On Mon, Aug 31, 2020 at 10:10 AM Nobuhiro Iwamatsu > <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: > > > > Visconti is a series of Toshiba's SoCs targeting image processing > > applications[0]. These set of patches adds support for Visconti5 a Arm > > v8 based SoC. > > > > The series add minimal support for the Visconti5 SoC and the TMPV7708 RM > > main board. Peripherals such as UART, SPI, I2c and timer use Arm's > > IP and work with the existing kernel drivers in the tree. The series > > includes a pinctrl driver to select appropriate functions on the pins. > > The arch/arm64 series looks all reasonable to me, nice work! > > Once the review from the DT and pinctrl maintainers is completed > and you have received their Acked-by or Reviewed-by tags, please > send the series with those tags to soc@kernel.org for inclusion, keeping > everyone else on Cc. > > I'd leave it up to Linus Walleij whether he wants to merge the pinctrl driver > through his subsystem tree, or whether we should pick it up through > the soc tree, either way works for the initial merge. For any updates to > the pinctrl driver and additional subsystem support (clk, media, ...) > in later releases there is no need to Cc the SoC maintainers as those > should just get merged through the subsystem while we take care > of the DT files. Thank you for the explanation. I will do that. BTW, I searched the process for this but I couldn't find any detailed documentation. Could you tell me if you know? > > > NOTE: Because Visconti5 does not have PSCI, it uses spin-table with enable-method. > > This sounds like an odd choice. Is this a permanent defect in the SoC > or the firmware, or do you expect to change this later once the firmware > has been fixed? I will change it later when the firmware is fixed. > > Note that most systems require PSCI anyway for cpuidle support. If there > is any EL2 or EL3 mode firmware already, this is where support for > processor bringup should be implemented. If there is none, you can > usually implement it using a small EL3 trampoline in the bootloader. > Yes, I understand that. Our firmware team and I are currently considering a fix. > > And this patch series does not include a clock framework, so it is a > > device-tree file that uses clocks with fixed-clock. This will be replaced by > > the clock driver in the future. > > This is ok for bringup, though we usually recommend to merge the clk driver > at the same time as the SoC, in order to avoid having an incompatible DT > change when adding the clk driver. Yes, I do this with caution. > > Arnd > Best regards, Nobuhiro
Hi Iwamatsu-san, Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> writes: > Hi, > > Thanks for your review and comment. > > On Mon, Aug 31, 2020 at 11:19:02AM +0200, Arnd Bergmann wrote: >> On Mon, Aug 31, 2020 at 10:10 AM Nobuhiro Iwamatsu >> <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: >> > >> > Visconti is a series of Toshiba's SoCs targeting image processing >> > applications[0]. These set of patches adds support for Visconti5 a Arm >> > v8 based SoC. >> > >> > The series add minimal support for the Visconti5 SoC and the TMPV7708 RM >> > main board. Peripherals such as UART, SPI, I2c and timer use Arm's >> > IP and work with the existing kernel drivers in the tree. The series >> > includes a pinctrl driver to select appropriate functions on the pins. >> >> The arch/arm64 series looks all reasonable to me, nice work! >> >> Once the review from the DT and pinctrl maintainers is completed >> and you have received their Acked-by or Reviewed-by tags, please >> send the series with those tags to soc@kernel.org for inclusion, keeping >> everyone else on Cc. >> >> I'd leave it up to Linus Walleij whether he wants to merge the pinctrl driver >> through his subsystem tree, or whether we should pick it up through >> the soc tree, either way works for the initial merge. For any updates to >> the pinctrl driver and additional subsystem support (clk, media, ...) >> in later releases there is no need to Cc the SoC maintainers as those >> should just get merged through the subsystem while we take care >> of the DT files. > > Thank you for the explanation. I will do that. > BTW, I searched the process for this but I couldn't find any detailed > documentation. Could you tell me if you know? I am not sure if this is documented, but SoC support (device tree, some drivers, and config changes) usually go through the arm-soc tree curated by Arnd, Olof and Kevin. The MAINTAINERS entry for ARM64 port tries to call this out but it is not obvious that architecture and platforms support is maintained separately though in coordination. Hope this helps. Thanks, Punit [...]
On Tue, Sep 1, 2020 at 12:41 AM Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: > On Mon, Aug 31, 2020 at 11:19:02AM +0200, Arnd Bergmann wrote: > > On Mon, Aug 31, 2020 at 10:10 AM Nobuhiro Iwamatsu > > <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: > > > > > > Visconti is a series of Toshiba's SoCs targeting image processing > > > applications[0]. These set of patches adds support for Visconti5 a Arm > > > v8 based SoC. > > > > > > The series add minimal support for the Visconti5 SoC and the TMPV7708 RM > > > main board. Peripherals such as UART, SPI, I2c and timer use Arm's > > > IP and work with the existing kernel drivers in the tree. The series > > > includes a pinctrl driver to select appropriate functions on the pins. > > > > The arch/arm64 series looks all reasonable to me, nice work! > > > > Once the review from the DT and pinctrl maintainers is completed > > and you have received their Acked-by or Reviewed-by tags, please > > send the series with those tags to soc@kernel.org for inclusion, keeping > > everyone else on Cc. > > > > I'd leave it up to Linus Walleij whether he wants to merge the pinctrl driver > > through his subsystem tree, or whether we should pick it up through > > the soc tree, either way works for the initial merge. For any updates to > > the pinctrl driver and additional subsystem support (clk, media, ...) > > in later releases there is no need to Cc the SoC maintainers as those > > should just get merged through the subsystem while we take care > > of the DT files. > > Thank you for the explanation. I will do that. > BTW, I searched the process for this but I couldn't find any detailed > documentation. Could you tell me if you know? We never documented this well, sorry about that. Generally speaking, if you only have small updates (a few patches at a time), feel free to send those patches to soc@kernel.org once you consider them ready for inclusion. On 32-bit architectures as well as the more widely used 64-bit platforms with many .dts files, please send pull requests that group the patches into logical topics. Once you are listed in the MAINTAINERS file and you want to host a git tree on git.kernel.org for that purpose, you can apply for a kernel.org account and send pull request from there as well as have the tree integrated into linux-next for earlier testing. On the more specialized platforms without third-party machine support in the kernel, that is usually not necessary. In either case, patches and pull requests should be based on an early -rc tag from mainline Linux (normally -rc1) and get sent between -rc1 and roughly -rc5 for new features. Bug fixes can be sent at any time regardless of the current -rc, with a balance between sending them quickly and collecting multiple of them into a pull request to reduce the number of merges. Please let us know whether bug fixes should be applied only at the next merge window, on current kernels, or backported to previous releases, using the "Fixes:" and "Cc: stable@vger.kernel.org" tags as appropriate. The default is to backport bug fixes as far back as they apply, unless there is a reason not to. Arnd
Hi, Thanks for your comment. On Tue, Sep 01, 2020 at 09:50:56AM +0200, Arnd Bergmann wrote: > On Tue, Sep 1, 2020 at 12:41 AM Nobuhiro Iwamatsu > <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: > > On Mon, Aug 31, 2020 at 11:19:02AM +0200, Arnd Bergmann wrote: > > > On Mon, Aug 31, 2020 at 10:10 AM Nobuhiro Iwamatsu > > > <nobuhiro1.iwamatsu@toshiba.co.jp> wrote: > > > > > > > > Visconti is a series of Toshiba's SoCs targeting image processing > > > > applications[0]. These set of patches adds support for Visconti5 a Arm > > > > v8 based SoC. > > > > > > > > The series add minimal support for the Visconti5 SoC and the TMPV7708 RM > > > > main board. Peripherals such as UART, SPI, I2c and timer use Arm's > > > > IP and work with the existing kernel drivers in the tree. The series > > > > includes a pinctrl driver to select appropriate functions on the pins. > > > > > > The arch/arm64 series looks all reasonable to me, nice work! > > > > > > Once the review from the DT and pinctrl maintainers is completed > > > and you have received their Acked-by or Reviewed-by tags, please > > > send the series with those tags to soc@kernel.org for inclusion, keeping > > > everyone else on Cc. > > > > > > I'd leave it up to Linus Walleij whether he wants to merge the pinctrl driver > > > through his subsystem tree, or whether we should pick it up through > > > the soc tree, either way works for the initial merge. For any updates to > > > the pinctrl driver and additional subsystem support (clk, media, ...) > > > in later releases there is no need to Cc the SoC maintainers as those > > > should just get merged through the subsystem while we take care > > > of the DT files. > > > > Thank you for the explanation. I will do that. > > BTW, I searched the process for this but I couldn't find any detailed > > documentation. Could you tell me if you know? > > We never documented this well, sorry about that. > No problem. > Generally speaking, if you only have small updates (a few patches > at a time), feel free to send those patches to soc@kernel.org once > you consider them ready for inclusion. > > On 32-bit architectures as well as the more widely used 64-bit > platforms with many .dts files, please send pull requests that group > the patches into logical topics. Once you are listed in the > MAINTAINERS file and you want to host a git tree on git.kernel.org > for that purpose, you can apply for a kernel.org account and > send pull request from there as well as have the tree integrated > into linux-next for earlier testing. On the more specialized platforms > without third-party machine support in the kernel, that is usually not > necessary. > > In either case, patches and pull requests should be based on > an early -rc tag from mainline Linux (normally -rc1) and get sent > between -rc1 and roughly -rc5 for new features. Bug fixes can > be sent at any time regardless of the current -rc, with a balance > between sending them quickly and collecting multiple of them > into a pull request to reduce the number of merges. Please let > us know whether bug fixes should be applied only at the next > merge window, on current kernels, or backported to previous > releases, using the "Fixes:" and "Cc: stable@vger.kernel.org" > tags as appropriate. The default is to backport bug fixes as far > back as they apply, unless there is a reason not to. > Thank you for the detailed explanation. The above explanation was very useful. > Arnd > Best regards, Nobuhiro