All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	"pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org"
	<pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Allen Martin <amartin-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Alexandre Courbot
	<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] arm64: dts: Add initial device tree support for Tegra132
Date: Fri, 23 Jan 2015 09:57:19 -0700	[thread overview]
Message-ID: <54C27D6F.9000006@wwwdotorg.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1501231038130.5450-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>

On 01/23/2015 04:31 AM, Paul Walmsley wrote:
> + Arto, Terje for comments on the host1x section
> + Stephen Warren for comments on the serial DT data

> On Wed, 21 Jan 2015, Mark Rutland wrote:
>
>> As mentioned in my reply to the DT list patch [1], there are a couple of
>> bits I'd like to see cleaned up first, but in the meantime I have some
>> comments from my first pass of the dtsi below. Some of these may equally
>> apply to existing dts(i) files.
>>
>> I see a few undocumented compatible strings (at least when comparing
>> against mainline). If there are other series or trees I should be
>> looking at, any pointers would be appreciated. If not, documentation
>> updates would be nice (checkpatch should complain otherwise).

>> On Fri, Jan 16, 2015 at 11:45:29AM +0000, Paul Walmsley wrote:
>>>
>>> Add an initial device tree file for the Tegra132 SoC.  The DT file is
>>> based on arch/arm/boot/dts/tegra124.dtsi and
>>> arch/arm/boot/dts/tegra114.dtsi, with the following significant
>>> changes:
>>>
>>> - Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster
>>> - Devices are arranged by bus, rather than in a flat topology
>>> - No polling delays have been defined for the thermal zones.  I don't
>>>    believe that this is a property of the SoC hardware, but rather of a
>>>    given use-case.

>>> diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi b/arch/arm64/boot/dts/tegra/tegra132.dtsi
>>> +               /*
>>> +                * There are two serial drivers: an 8250 based simple
>>> +                * serial driver and an APB DMA based serial driver
>>> +                * for higher baudrate and performance. To enable the
>>> +                * 8250 based driver, the compatible string is
>>> +                * "nvidia,tegra132-uart", "nvidia,tegra124-uart",
>>> +                * "nvidia,tegra20-uart" and to enable the APB DMA
>>> +                * based serial driver, the compatible string is
>>> +                * "nvidia,tegra132-hsuart", "nvidia,tegra124-hsuart",
>>> +                * "nvidia,tegra30-hsuart".
>>> +                */
>>
>> Is there any reason to continue with this split?
>>
>> Surely if the only difference is DMA, the presence of dmas and dma-names
>> should be sufficient to get the driver to do the right thing, and if you
>> need to disable DMA for debugging that could be a command-line option.

I vaguely recall asking for the DMA support to be integrated into the 
regular 8250 driver instead when the separate DMA-capable driver was 
first added. I /think/ there was resistance to this because adding lots 
of different SoC-specific ways to do DMA into the existing 8250 driver 
would complicate it even more, and hence be unmaintainable.

I assume that reasoning is still valid.

Perhaps what we need is more fine-grained driver selection, not just 
based on compatible value. Something like:

if compatible == nvidia,tegra20-uart:
   if node.has_prop("enable-dma"):
     driver = Tegra-specfic DMA capable UART driver
   else:
     driver = Common 8250 driver

Is that something that of_serial.c could/should be enhanced to do? That 
said, the whole reasoning behind separate compatible properties before 
was that compatible is supposed to "drive" driver selection. At least, 
that's what I was told then.

>> Does the binding and/or driver support aliases so you can get consistent
>> numbering? It would be nice to have.

I believe either the serial core or serial driver(s) support DT aliases 
now, yes.

>> Do these UARTs work with earlycon?

I do not know.

>> It would be nice to have a /chosen/stdout-path (ideally with rate) so as
>> to get output consistently without command line options being required.
>
> Stephen Warren might be the best person to directly respond to these
> issues.  This is all legacy DT data from previous Tegra SoCs.
>
>>
>>> +               uarta: serial@0,70006000 {
>>> +                       compatible = "nvidia,tegra132-uart", "nvidia,tegra124-uart", "nvidia,tegra20-uart";
>>> +                       reg = <0x0 0x70006000 0x0 0x40>;
>>> +                       reg-shift = <2>;
>>> +                       interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>> +                       clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>> +                       resets = <&tegra_car 6>;
>>> +                       reset-names = "serial";
>>> +                       dmas = <&apbdma 8>, <&apbdma 8>;
>>> +                       dma-names = "rx", "tx";
>>> +                       status = "disabled";
>>> +               };

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: dts: Add initial device tree support for Tegra132
Date: Fri, 23 Jan 2015 09:57:19 -0700	[thread overview]
Message-ID: <54C27D6F.9000006@wwwdotorg.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1501231038130.5450@utopia.booyaka.com>

On 01/23/2015 04:31 AM, Paul Walmsley wrote:
> + Arto, Terje for comments on the host1x section
> + Stephen Warren for comments on the serial DT data

> On Wed, 21 Jan 2015, Mark Rutland wrote:
>
>> As mentioned in my reply to the DT list patch [1], there are a couple of
>> bits I'd like to see cleaned up first, but in the meantime I have some
>> comments from my first pass of the dtsi below. Some of these may equally
>> apply to existing dts(i) files.
>>
>> I see a few undocumented compatible strings (at least when comparing
>> against mainline). If there are other series or trees I should be
>> looking at, any pointers would be appreciated. If not, documentation
>> updates would be nice (checkpatch should complain otherwise).

>> On Fri, Jan 16, 2015 at 11:45:29AM +0000, Paul Walmsley wrote:
>>>
>>> Add an initial device tree file for the Tegra132 SoC.  The DT file is
>>> based on arch/arm/boot/dts/tegra124.dtsi and
>>> arch/arm/boot/dts/tegra114.dtsi, with the following significant
>>> changes:
>>>
>>> - Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster
>>> - Devices are arranged by bus, rather than in a flat topology
>>> - No polling delays have been defined for the thermal zones.  I don't
>>>    believe that this is a property of the SoC hardware, but rather of a
>>>    given use-case.

>>> diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi b/arch/arm64/boot/dts/tegra/tegra132.dtsi
>>> +               /*
>>> +                * There are two serial drivers: an 8250 based simple
>>> +                * serial driver and an APB DMA based serial driver
>>> +                * for higher baudrate and performance. To enable the
>>> +                * 8250 based driver, the compatible string is
>>> +                * "nvidia,tegra132-uart", "nvidia,tegra124-uart",
>>> +                * "nvidia,tegra20-uart" and to enable the APB DMA
>>> +                * based serial driver, the compatible string is
>>> +                * "nvidia,tegra132-hsuart", "nvidia,tegra124-hsuart",
>>> +                * "nvidia,tegra30-hsuart".
>>> +                */
>>
>> Is there any reason to continue with this split?
>>
>> Surely if the only difference is DMA, the presence of dmas and dma-names
>> should be sufficient to get the driver to do the right thing, and if you
>> need to disable DMA for debugging that could be a command-line option.

I vaguely recall asking for the DMA support to be integrated into the 
regular 8250 driver instead when the separate DMA-capable driver was 
first added. I /think/ there was resistance to this because adding lots 
of different SoC-specific ways to do DMA into the existing 8250 driver 
would complicate it even more, and hence be unmaintainable.

I assume that reasoning is still valid.

Perhaps what we need is more fine-grained driver selection, not just 
based on compatible value. Something like:

if compatible == nvidia,tegra20-uart:
   if node.has_prop("enable-dma"):
     driver = Tegra-specfic DMA capable UART driver
   else:
     driver = Common 8250 driver

Is that something that of_serial.c could/should be enhanced to do? That 
said, the whole reasoning behind separate compatible properties before 
was that compatible is supposed to "drive" driver selection. At least, 
that's what I was told then.

>> Does the binding and/or driver support aliases so you can get consistent
>> numbering? It would be nice to have.

I believe either the serial core or serial driver(s) support DT aliases 
now, yes.

>> Do these UARTs work with earlycon?

I do not know.

>> It would be nice to have a /chosen/stdout-path (ideally with rate) so as
>> to get output consistently without command line options being required.
>
> Stephen Warren might be the best person to directly respond to these
> issues.  This is all legacy DT data from previous Tegra SoCs.
>
>>
>>> +               uarta: serial at 0,70006000 {
>>> +                       compatible = "nvidia,tegra132-uart", "nvidia,tegra124-uart", "nvidia,tegra20-uart";
>>> +                       reg = <0x0 0x70006000 0x0 0x40>;
>>> +                       reg-shift = <2>;
>>> +                       interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>>> +                       clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>> +                       resets = <&tegra_car 6>;
>>> +                       reset-names = "serial";
>>> +                       dmas = <&apbdma 8>, <&apbdma 8>;
>>> +                       dma-names = "rx", "tx";
>>> +                       status = "disabled";
>>> +               };

  parent reply	other threads:[~2015-01-23 16:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 11:45 [PATCH] arm64: dts: Add initial device tree support for Tegra132 Paul Walmsley
2015-01-16 11:45 ` Paul Walmsley
     [not found] ` <alpine.DEB.2.02.1501161139180.9776-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2015-01-21 16:13   ` Mark Rutland
2015-01-21 16:13     ` Mark Rutland
2015-01-23 11:31     ` Paul Walmsley
2015-01-23 11:31       ` Paul Walmsley
     [not found]       ` <alpine.DEB.2.02.1501231038130.5450-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2015-01-23 11:44         ` Mark Rutland
2015-01-23 11:44           ` Mark Rutland
2015-01-23 12:03           ` Thierry Reding
2015-01-23 12:03             ` Thierry Reding
     [not found]             ` <20150123120355.GA15126-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2015-01-23 12:17               ` Mark Rutland
2015-01-23 12:17                 ` Mark Rutland
2015-01-23 12:14         ` Arto Merilainen
2015-01-23 12:14           ` Arto Merilainen
     [not found]           ` <54C23B08.6070503-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-01-23 12:22             ` Mark Rutland
2015-01-23 12:22               ` Mark Rutland
2015-01-23 16:57         ` Stephen Warren [this message]
2015-01-23 16:57           ` Stephen Warren
     [not found]           ` <54C27D6F.9000006-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2015-01-23 17:34             ` Mark Rutland
2015-01-23 17:34               ` Mark Rutland
2015-01-23 17:47               ` Stephen Warren
2015-01-23 17:47                 ` Stephen Warren

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=54C27D6F.9000006@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=Catalin.Marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=Pawel.Moll-5wv7dgnIgG8@public.gmane.org \
    --cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=amartin-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org \
    --cc=pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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: 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.