devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
To: Joshua Milas <josh.milas@gmail.com>, Inochi Amaoto <inochiama@gmail.com>
Cc: michael.opdenacker@rootcommit.com, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	unicorn_wang@outlook.com, paul.walmsley@sifive.com,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
	alexander.sverdlin@gmail.com, rabenda.cn@gmail.com,
	thomas.bonnefille@bootlin.com, chao.wei@sophgo.com,
	liujingqi@lanxincomputing.com, devicetree@vger.kernel.org,
	sophgo@lists.linux.dev, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 2/3] arm64: dts: sophgo: add initial Milk-V Duo S board support
Date: Sun, 26 Oct 2025 22:48:50 +0000 (UTC)	[thread overview]
Message-ID: <4bdad288-250b-4e94-abea-eb231fba5beb@rootcommit.com> (raw)
In-Reply-To: <aP6UJFPP-ReYPzmq@sleek>

Hi Joshua

Thanks a lot for working on support for Milk-V Duo S. I'll be happy to 
test your V3 :)

On 10/26/25 22:35, Joshua Milas wrote:
> Inochi,
>
> Thanks for pointing me twards duo-pinmux. I was able to use it to get
> the default config which is uart0, spi3, and i2c4. I can change the
> dts to match, but...
>
>> I suggest enabling devices that are accessed by default
> Would we rather enable anything that can be accessed by the pinmux?

If I understand correctly, you can't do that because there will be 
conflicts.
 From the Duo S pinout diagram 
(https://milkv.io/duo-s/duos-pinout.webp), on headers 41 and 39, you 
have to choose between MIPI, I2C2, PWM12/13 or SD1. If at least 2 of 
these are selected at the same time, there will be a conflict, and I 
assume that the pinctrl controller driver will flag it.

Then it sounds complicated to define a default combination for the whole 
board, because it's like a default use model. Who gets to choose? What 
Inochi suggests is to follow the vendor kernel choice, which would 
correspond to the way the vendor intended the board to be used. However 
the community could choose another default way to use the board, so the 
choice may be up to the first contributor to the mainline kernel for 
this board, possibly revised through later discussions.

I guess there are cases when the choice is easy:

- When only one configuration is available for a set of pins
- When there are important devices on I2C or SPI buses on the board. 
Then, you want to find a way to prioritize such buses. Fortunately, I 
guess the board design also guides you to the right choice.

I was facing the the same question today on another board, and that's 
why I'm happy it's raised here. As thousands of DTS files have been 
written before, I'd love to hear from people with experience on this 
topic. Are guidelines written anywhere for board DTS creators?

Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/


  reply	other threads:[~2025-10-26 22:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-11  1:48 [PATCH 0/3] Add initial Milk-V Duo S board support Joshua Milas
2025-10-11  1:48 ` [PATCH 1/3] dt-bindings: soc: sophgo: add Milk-V Duo S board compatibles Joshua Milas
2025-10-11  1:50   ` Inochi Amaoto
2025-10-11  1:48 ` [PATCH 2/3] arm64: dts: sophgo: add initial Milk-V Duo S board support Joshua Milas
2025-10-11  1:56   ` Inochi Amaoto
2025-10-11 19:19     ` Joshua Milas
2025-10-13  0:43       ` Inochi Amaoto
2025-10-26 21:35         ` Joshua Milas
2025-10-26 22:48           ` Michael Opdenacker [this message]
2025-10-28 23:23             ` Joshua Milas
2025-10-29  0:53             ` Inochi Amaoto
2025-10-30 12:50               ` Michael Opdenacker
2025-10-11  1:48 ` [PATCH 3/3] riscv64: " Joshua Milas
2025-10-11  1:57   ` Inochi Amaoto
2025-10-11  2:16 ` [PATCH 0/3] Add " Chen Wang
2025-10-14  3:27 ` Chen Wang

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=4bdad288-250b-4e94-abea-eb231fba5beb@rootcommit.com \
    --to=michael.opdenacker@rootcommit.com \
    --cc=alex@ghiti.fr \
    --cc=alexander.sverdlin@gmail.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=chao.wei@sophgo.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=inochiama@gmail.com \
    --cc=josh.milas@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=liujingqi@lanxincomputing.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rabenda.cn@gmail.com \
    --cc=robh@kernel.org \
    --cc=sophgo@lists.linux.dev \
    --cc=thomas.bonnefille@bootlin.com \
    --cc=unicorn_wang@outlook.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).