All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Masami Hiramatsu <masami.hiramatsu@linaro.org>,
	Jassi Brar <jaswinder.singh@linaro.org>
Subject: Re: [PATCH v2 1/6] dt-bindings: dma: uniphier-xdmac: Remove extension register region description
Date: Mon, 23 Mar 2020 11:26:17 +0900	[thread overview]
Message-ID: <20200323112616.E512.4A936039@socionext.com> (raw)
In-Reply-To: <CAK7LNASmZRszPB-o4pzeu0aQM4_cQBkRxwFM2T4_onHA4-1r8w@mail.gmail.com>

On Thu, 19 Mar 2020 23:18:29 +0900 <masahiroy@kernel.org> wrote:

> On Thu, Mar 19, 2020 at 4:51 PM Kunihiko Hayashi
> <hayashi.kunihiko@socionext.com> wrote:
> >
> > The address of the extension register region in example is incorrect,
> > however, this extension register region is optional
> 
> 
> On which SoC is it optional?
> 
> In your previous DT submission, every reg was,
> like this:
> 
> reg = <0x5fc10000 0x1000>, <0x5fc20000 0x800>;
> 
> 
> 
> and you meant
> 
> reg = <0x5fc10000 0x1000>, <0x5fc12000 0x800>;
> 
> ?

Yes. 'Optional' might not be appropriate because all SoCs has the region.

> > and isn't currently
> > referred from the driver, so the description of the region should be
> > suppressed until referred by the driver.
> 
> This sounds like you plan to get it back
> as you extend the driver.

Right, however, it isn't desiable that the description of the region is
changed by extending the driver.

> I checked the datasheet. This controller has more registers,
> so you split the reg into small chunks, the final form will look scary:
> 
> reg = <0x5fc10000 0x1000>, <0x5fc12000 0x800>,
>       <0x5fc14000 0x100>,  <0x5fc15000 0x100>;
> 
> 
> My question is why you did not use a single reg tuple
> that covers the whole registers.
> 
> Is any other hardware reg interleaved in between?

No, there is no other hardware reg between each region.

Surely it seems pointless to divide all tuples individually.
I'll rewrite it to cover entire xdmac reg region.

Thank you,

---
Best Regards,
Kunihiko Hayashi


WARNING: multiple messages have this Message-ID (diff)
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: DTML <devicetree@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Masami Hiramatsu <masami.hiramatsu@linaro.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Jassi Brar <jaswinder.singh@linaro.org>
Subject: Re: [PATCH v2 1/6] dt-bindings: dma: uniphier-xdmac: Remove extension register region description
Date: Mon, 23 Mar 2020 11:26:17 +0900	[thread overview]
Message-ID: <20200323112616.E512.4A936039@socionext.com> (raw)
In-Reply-To: <CAK7LNASmZRszPB-o4pzeu0aQM4_cQBkRxwFM2T4_onHA4-1r8w@mail.gmail.com>

On Thu, 19 Mar 2020 23:18:29 +0900 <masahiroy@kernel.org> wrote:

> On Thu, Mar 19, 2020 at 4:51 PM Kunihiko Hayashi
> <hayashi.kunihiko@socionext.com> wrote:
> >
> > The address of the extension register region in example is incorrect,
> > however, this extension register region is optional
> 
> 
> On which SoC is it optional?
> 
> In your previous DT submission, every reg was,
> like this:
> 
> reg = <0x5fc10000 0x1000>, <0x5fc20000 0x800>;
> 
> 
> 
> and you meant
> 
> reg = <0x5fc10000 0x1000>, <0x5fc12000 0x800>;
> 
> ?

Yes. 'Optional' might not be appropriate because all SoCs has the region.

> > and isn't currently
> > referred from the driver, so the description of the region should be
> > suppressed until referred by the driver.
> 
> This sounds like you plan to get it back
> as you extend the driver.

Right, however, it isn't desiable that the description of the region is
changed by extending the driver.

> I checked the datasheet. This controller has more registers,
> so you split the reg into small chunks, the final form will look scary:
> 
> reg = <0x5fc10000 0x1000>, <0x5fc12000 0x800>,
>       <0x5fc14000 0x100>,  <0x5fc15000 0x100>;
> 
> 
> My question is why you did not use a single reg tuple
> that covers the whole registers.
> 
> Is any other hardware reg interleaved in between?

No, there is no other hardware reg between each region.

Surely it seems pointless to divide all tuples individually.
I'll rewrite it to cover entire xdmac reg region.

Thank you,

---
Best Regards,
Kunihiko Hayashi


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-03-23  2:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19  7:50 [PATCH v2 0/6] Add devicetree features and fixes for UniPhier SoCs Kunihiko Hayashi
2020-03-19  7:50 ` Kunihiko Hayashi
2020-03-19  7:50 ` [PATCH v2 1/6] dt-bindings: dma: uniphier-xdmac: Remove extension register region description Kunihiko Hayashi
2020-03-19  7:50   ` Kunihiko Hayashi
2020-03-19 14:18   ` Masahiro Yamada
2020-03-19 14:18     ` Masahiro Yamada
2020-03-23  2:26     ` Kunihiko Hayashi [this message]
2020-03-23  2:26       ` Kunihiko Hayashi
2020-03-19  7:50 ` [PATCH v2 2/6] ARM: dts: uniphier: Add XDMAC node Kunihiko Hayashi
2020-03-19  7:50   ` Kunihiko Hayashi
2020-03-19  7:50 ` [PATCH v2 3/6] arm64: " Kunihiko Hayashi
2020-03-19  7:50   ` Kunihiko Hayashi
2020-03-19  7:50 ` [PATCH v2 4/6] ARM: dts: uniphier: Add ethernet aliases Kunihiko Hayashi
2020-03-19  7:50   ` Kunihiko Hayashi
2020-03-19  7:50 ` [PATCH v2 5/6] arm64: " Kunihiko Hayashi
2020-03-19  7:50   ` Kunihiko Hayashi
2020-03-19  7:50 ` [PATCH v2 6/6] arm64: dts: uniphier: Stabilize Ethernet RGMII mode of PXs3 ref board Kunihiko Hayashi
2020-03-19  7:50   ` Kunihiko Hayashi

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=20200323112616.E512.4A936039@socionext.com \
    --to=hayashi.kunihiko@socionext.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jaswinder.singh@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=masahiroy@kernel.org \
    --cc=masami.hiramatsu@linaro.org \
    --cc=robh+dt@kernel.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: link
Be 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.