All of lore.kernel.org
 help / color / mirror / Atom feed
From: Orson Zhai <orsonzhai@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Lyra Zhang <zhang.lyra@gmail.com>,
	Chunyan Zhang <chunyan.zhang@spreadtrum.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"jslaby@suse.cz" <jslaby@suse.cz>,
	"jason@lakedaemon.net" <jason@lakedaemon.net>,
	"heiko@sntech.de" <heiko@sntech.de>,
	"florian.vaussard@epfl.ch" <florian.vaussard@epfl.ch>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"rrichter@cavium.com" <rrichter@cavium.com>,
	"hytszk@gmail.com" <hytszk@gmail.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"antonynpavlov@gmail.com" <antonynpavlov@gmail.com>,
	"Joel.Schopp@amd.com" <Joel.Schopp@amd.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
	"jorge.ramirez-ortiz@linaro.org" <jorge.ramirez-ortiz@linaro.org>,
	"lee.jones@linaro.org" <lee.jones@linaro.org>,
	"geng.ren@spreadtrum.com" <geng.ren@spreadtrum.com>,
	"zhizhou.zhang@spreadtrum.com" <zhizhou.zhang@spreadtrum.com>,
	"lanqing.liu@spreadtrum.com" <lanqing.liu@spreadtrum.com>,
	"wei.qiao@spreadtrum.com" <wei.qiao@spreadtrum.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	Leo Yan <leo.yan@linaro.org>
Subject: Re: [PATCH v5 2/5] Documentation: DT: Add bindings for Spreadtrum SoC Platform
Date: Sat, 17 Jan 2015 16:10:32 +0800	[thread overview]
Message-ID: <CA+H2tpHA7PRL98VMd3d3jeaOr_6Q5ktmM3fbdaBKRpm_pXVqVw@mail.gmail.com> (raw)
In-Reply-To: <20150116141109.GC22569@leverpostej>

On Fri, Jan 16, 2015 at 10:11 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Jan 16, 2015 at 12:53:16PM +0000, Lyra Zhang wrote:
>> Hi, Mark
>>
>> >> +
>> >> +Required properties:
>> >> +- compatible: must be "sprd,sc9836-uart"
>> >> +- reg: offset and length of the register set for the device
>> >> +- interrupts: exactly one interrupt specifier
>> >> +- clocks: phandles to input clocks.
>> >
>> > The order and relevance of each should be specified. If you have
>> > multiple clocks I would strongly recommend you use clock-names to
>> > distinguish them.
>> >
>>
>> Thank you for the recommendation.
>> but, since we haven't made the clock driver ready, for this initial
>> commit, we just let 4 UARTs share a single fixed 26 MHz clock source.
>> we'll do like you've recommended when we will submit the clock driver
>> in the future.
>
> I'm on about the clock input lines on the UART instance, not the
> providers they come from.
>
> Is there only a single clock input line on each UART? Perhaps multiple
> input lines which are currently fed by the same clock?

________
| 26MHz |-------------------------------------------------
-------------        |                  |
                     |                  |
                _______       ________
               | UART1 |      | UART2 |    .........
               --------------      -------------

the hardware is something like the diagram.

4 Uart modules are all connected to a fixed 26Mhz crystal by power-on default.

There should be a clock-mux between uart and 26Mhz which
could select other clock source such as some pll output.

But as initial commit , we are not ready to describe other inputs by
these muxes.
So  we treat the UART as a simple model with only one fixed-clock input.
And we plan to add the other inputs path back in a not very far future.
Is it appropriate  to do like this?

  Orson


>
> Thanks,
> Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Orson Zhai <orsonzhai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Lyra Zhang <zhang.lyra-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Chunyan Zhang
	<chunyan.zhang-lxIno14LUO0EEoCn2XhGlw@public.gmane.org>,
	"gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org"
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	"arnd-r2nGTMty4D4@public.gmane.org"
	<arnd-r2nGTMty4D4@public.gmane.org>,
	"gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org"
	<gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>,
	"broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
	"ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org"
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
	<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	"jslaby-AlSwsSmVLrQ@public.gmane.org"
	<jslaby-AlSwsSmVLrQ@public.gmane.org>,
	"jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org"
	<jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	"heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org"
	<heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"florian.vaussard-p8DiymsW2f8@public.gmane.org"
	<florian.vaussard-p8DiymsW2f8@public.gmane.org>,
	"andrew-g2DYL2Zd6BY@public.gmane.org"
	<andrew-g2DYL2Zd6BY@public.gmane.org>,
	"rrichter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org"
	<rrichter-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>,
	"hytszk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<hytszk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
	<grant.likely@lin>
Subject: Re: [PATCH v5 2/5] Documentation: DT: Add bindings for Spreadtrum SoC Platform
Date: Sat, 17 Jan 2015 16:10:32 +0800	[thread overview]
Message-ID: <CA+H2tpHA7PRL98VMd3d3jeaOr_6Q5ktmM3fbdaBKRpm_pXVqVw@mail.gmail.com> (raw)
In-Reply-To: <20150116141109.GC22569@leverpostej>

On Fri, Jan 16, 2015 at 10:11 PM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Fri, Jan 16, 2015 at 12:53:16PM +0000, Lyra Zhang wrote:
>> Hi, Mark
>>
>> >> +
>> >> +Required properties:
>> >> +- compatible: must be "sprd,sc9836-uart"
>> >> +- reg: offset and length of the register set for the device
>> >> +- interrupts: exactly one interrupt specifier
>> >> +- clocks: phandles to input clocks.
>> >
>> > The order and relevance of each should be specified. If you have
>> > multiple clocks I would strongly recommend you use clock-names to
>> > distinguish them.
>> >
>>
>> Thank you for the recommendation.
>> but, since we haven't made the clock driver ready, for this initial
>> commit, we just let 4 UARTs share a single fixed 26 MHz clock source.
>> we'll do like you've recommended when we will submit the clock driver
>> in the future.
>
> I'm on about the clock input lines on the UART instance, not the
> providers they come from.
>
> Is there only a single clock input line on each UART? Perhaps multiple
> input lines which are currently fed by the same clock?

________
| 26MHz |-------------------------------------------------
-------------        |                  |
                     |                  |
                _______       ________
               | UART1 |      | UART2 |    .........
               --------------      -------------

the hardware is something like the diagram.

4 Uart modules are all connected to a fixed 26Mhz crystal by power-on default.

There should be a clock-mux between uart and 26Mhz which
could select other clock source such as some pll output.

But as initial commit , we are not ready to describe other inputs by
these muxes.
So  we treat the UART as a simple model with only one fixed-clock input.
And we plan to add the other inputs path back in a not very far future.
Is it appropriate  to do like this?

  Orson


>
> Thanks,
> Mark.

WARNING: multiple messages have this Message-ID (diff)
From: orsonzhai@gmail.com (Orson Zhai)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 2/5] Documentation: DT: Add bindings for Spreadtrum SoC Platform
Date: Sat, 17 Jan 2015 16:10:32 +0800	[thread overview]
Message-ID: <CA+H2tpHA7PRL98VMd3d3jeaOr_6Q5ktmM3fbdaBKRpm_pXVqVw@mail.gmail.com> (raw)
In-Reply-To: <20150116141109.GC22569@leverpostej>

On Fri, Jan 16, 2015 at 10:11 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Jan 16, 2015 at 12:53:16PM +0000, Lyra Zhang wrote:
>> Hi, Mark
>>
>> >> +
>> >> +Required properties:
>> >> +- compatible: must be "sprd,sc9836-uart"
>> >> +- reg: offset and length of the register set for the device
>> >> +- interrupts: exactly one interrupt specifier
>> >> +- clocks: phandles to input clocks.
>> >
>> > The order and relevance of each should be specified. If you have
>> > multiple clocks I would strongly recommend you use clock-names to
>> > distinguish them.
>> >
>>
>> Thank you for the recommendation.
>> but, since we haven't made the clock driver ready, for this initial
>> commit, we just let 4 UARTs share a single fixed 26 MHz clock source.
>> we'll do like you've recommended when we will submit the clock driver
>> in the future.
>
> I'm on about the clock input lines on the UART instance, not the
> providers they come from.
>
> Is there only a single clock input line on each UART? Perhaps multiple
> input lines which are currently fed by the same clock?

________
| 26MHz |-------------------------------------------------
-------------        |                  |
                     |                  |
                _______       ________
               | UART1 |      | UART2 |    .........
               --------------      -------------

the hardware is something like the diagram.

4 Uart modules are all connected to a fixed 26Mhz crystal by power-on default.

There should be a clock-mux between uart and 26Mhz which
could select other clock source such as some pll output.

But as initial commit , we are not ready to describe other inputs by
these muxes.
So  we treat the UART as a simple model with only one fixed-clock input.
And we plan to add the other inputs path back in a not very far future.
Is it appropriate  to do like this?

  Orson


>
> Thanks,
> Mark.

  reply	other threads:[~2015-01-17  8:10 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <sc9836-v5>
2015-01-16 10:00 ` [PATCH v5 0/5] Add Spreadtrum Sharkl64 Platform support Chunyan Zhang
2015-01-16 10:00   ` Chunyan Zhang
2015-01-16 10:00   ` Chunyan Zhang
2015-01-16 10:00   ` [PATCH v5 1/5] Documentation: DT: Renamed of-serial.txt to 8250.txt Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 14:11     ` Rob Herring
2015-01-16 14:11       ` Rob Herring
2015-01-16 14:11       ` Rob Herring
2015-01-16 10:00   ` [PATCH v5 2/5] Documentation: DT: Add bindings for Spreadtrum SoC Platform Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:21     ` Mark Rutland
2015-01-16 10:21       ` Mark Rutland
2015-01-16 10:21       ` Mark Rutland
2015-01-16 12:53       ` Lyra Zhang
2015-01-16 12:53         ` Lyra Zhang
2015-01-16 12:53         ` Lyra Zhang
2015-01-16 14:11         ` Mark Rutland
2015-01-16 14:11           ` Mark Rutland
2015-01-16 14:11           ` Mark Rutland
2015-01-17  8:10           ` Orson Zhai [this message]
2015-01-17  8:10             ` Orson Zhai
2015-01-17  8:10             ` Orson Zhai
2015-01-16 10:00   ` [PATCH v5 3/5] arm64: dts: Add support for Spreadtrum SC9836 SoC in dts and Makefile Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:35     ` Mark Rutland
2015-01-16 10:35       ` Mark Rutland
2015-01-16 10:35       ` Mark Rutland
2015-01-16 12:49       ` Orson Zhai
2015-01-16 12:49         ` Orson Zhai
2015-01-16 12:49         ` Orson Zhai
2015-01-16 14:09         ` Mark Rutland
2015-01-16 14:09           ` Mark Rutland
2015-01-16 14:09           ` Mark Rutland
2015-01-17  8:47           ` Orson Zhai
2015-01-17  8:47             ` Orson Zhai
2015-01-17  8:47             ` Orson Zhai
2015-01-16 10:00   ` [PATCH v5 4/5] arm64: Add support for Spreadtrum's Sharkl64 Platform in Kconfig and defconfig Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:48     ` Mark Rutland
2015-01-16 10:48       ` Mark Rutland
2015-01-16 10:48       ` Mark Rutland
2015-01-16 11:50       ` Lyra Zhang
2015-01-16 11:50         ` Lyra Zhang
2015-01-16 11:50         ` Lyra Zhang
2015-01-16 10:00   ` [PATCH v5 5/5] tty/serial: Add Spreadtrum sc9836-uart driver support Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:00     ` Chunyan Zhang
2015-01-16 10:26     ` Arnd Bergmann
2015-01-16 10:26       ` Arnd Bergmann
2015-01-16 11:02     ` Baruch Siach
2015-01-16 11:02       ` Baruch Siach
2015-01-16 11:02       ` Baruch Siach
2015-01-16 15:20     ` Peter Hurley
2015-01-16 15:20       ` Peter Hurley
2015-01-16 15:20       ` Peter Hurley
2015-01-20 12:11       ` Orson Zhai
2015-01-20 12:11         ` Orson Zhai
2015-01-20 13:39         ` Peter Hurley
2015-01-20 13:39           ` Peter Hurley
2015-01-16 16:41     ` Rob Herring
2015-01-16 16:41       ` Rob Herring
2015-01-16 16:41       ` Rob Herring
2015-01-19  9:55       ` Lyra Zhang
2015-01-19  9:55         ` Lyra Zhang
2015-01-19  9:55         ` Lyra Zhang
2015-01-19 14:11         ` Rob Herring
2015-01-19 14:11           ` Rob Herring
2015-01-19 14:11           ` Rob Herring
2015-01-20  7:37           ` Lyra Zhang
2015-01-20  7:37             ` Lyra Zhang
2015-01-20  7:37             ` Lyra Zhang
2015-01-20  8:41             ` Orson Zhai
2015-01-20  8:41               ` Orson Zhai
2015-01-20  8:41               ` Orson Zhai
2015-01-20 20:17             ` Rob Herring
2015-01-20 20:17               ` Rob Herring
2015-01-20 20:17               ` Rob Herring

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=CA+H2tpHA7PRL98VMd3d3jeaOr_6Q5ktmM3fbdaBKRpm_pXVqVw@mail.gmail.com \
    --to=orsonzhai@gmail.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Joel.Schopp@amd.com \
    --cc=Pawel.Moll@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=andrew@lunn.ch \
    --cc=antonynpavlov@gmail.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=chunyan.zhang@spreadtrum.com \
    --cc=devicetree@vger.kernel.org \
    --cc=florian.vaussard@epfl.ch \
    --cc=galak@codeaurora.org \
    --cc=geng.ren@spreadtrum.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=hytszk@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jason@lakedaemon.net \
    --cc=jorge.ramirez-ortiz@linaro.org \
    --cc=jslaby@suse.cz \
    --cc=lanqing.liu@spreadtrum.com \
    --cc=lee.jones@linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rrichter@cavium.com \
    --cc=shawn.guo@linaro.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=wei.qiao@spreadtrum.com \
    --cc=zhang.lyra@gmail.com \
    --cc=zhizhou.zhang@spreadtrum.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 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.