diff for duplicates of <2297276.nzTbucM52b@diego> diff --git a/a/1.txt b/N1/1.txt index e48e6d1..1d2b456 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,68 +1,55 @@ Am Donnerstag, 28. April 2016, 16:20:04 schrieb Joel Stanley: -> On Wed, Apr 27, 2016 at 6:42 PM, Heiko St=FCbner <heiko@sntech.de> wr= -ote: +> On Wed, Apr 27, 2016 at 6:42 PM, Heiko St?bner <heiko@sntech.de> wrote: > > Am Mittwoch, 27. April 2016, 18:01:00 schrieb Joel Stanley: > >> > From what I remember exposing the clock controller as one block > >> > (instead > >> > of -> >> > declaring each clock individually in the dts) is still the prefe= -rred +> >> > declaring each clock individually in the dts) is still the preferred > >> > way > >> > but I don't think I can find Mike's mail from back then easily. -> >>=20 -> >> I can't picture how that would look. I took my lead from the moxar= -t +> >> +> >> I can't picture how that would look. I took my lead from the moxart > >> clock driver; is there a better example that I should follow? -> >=20 +> > > > qcom, samsung, rockchip, hisilicon, imx, ... ->=20 +> > I had a look here, and they appear to be much more complex than I -> need. The qcom directory is 41000 lines of code! The moxart driver is= - -> similar to what we do, but as you mentioned it is not arranged how yo= -u +> need. The qcom directory is 41000 lines of code! The moxart driver is +> similar to what we do, but as you mentioned it is not arranged how you > want it. -I'm by no means authoritative ;-), but from what you describe below, cl= -k- -asm9260.c or clk-efm32gg.c might be going in that direction of very sim= -ple=20 +I'm by no means authoritative ;-), but from what you describe below, clk- +asm9260.c or clk-efm32gg.c might be going in that direction of very simple clock-controllers. -Sorry about pointing to more complex drivers for bigger socs at first := --) +Sorry about pointing to more complex drivers for bigger socs at first :-) -> > I guess the design would depend on the actual layout of your clock-= - / +> > I guess the design would depend on the actual layout of your clock- / > > system- controller - aka what else is contained there. ->=20 -> In the fourth generation parts, such as the ast2400, we have this lay= -out: ->=20 +> +> In the fourth generation parts, such as the ast2400, we have this layout: +> > clock rate > ----------------------------- > clk_clkin 48000000 > clk_hpll 384000000 > clk_apb 48000000 ->=20 -> clkin is the oscillator that may be running at 24, 25 or 48MHz. We ca= -n +> +> clkin is the oscillator that may be running at 24, 25 or 48MHz. We can > determine this from the strapping register. ->=20 +> > The hpll divisor is controlled by strapping resistors, and indicated > in the strapping register. ->=20 +> > The apb is controlled by a register in the SCU, the Aspeed's > bucket-of-bits for controlling various parts of the soc. -I remember that from working on Samsung s3c24xx socs, the system-contro= -ller=20 +I remember that from working on Samsung s3c24xx socs, the system-controller area also worked as sort of catch-all :-) . ->=20 -> In our case we want don't need to adjust any clocks. We do want struc= -t +> +> In our case we want don't need to adjust any clocks. We do want struct > clk's so attached device drivers to know how fast they are being > clocked. How do you see this laid out? diff --git a/a/content_digest b/N1/content_digest index ff2b092..cc1ce67 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,87 +1,67 @@ "ref\01461225849-28074-1-git-send-email-joel@jms.id.au\0" "ref\04459295.XmBqACy0jk@diego\0" "ref\0CACPK8Xdm_ZAyfUNbwEYrZuUZS4cP3YMkrkVbGNeiVmeFF6j3Cw@mail.gmail.com\0" - "From\0Heiko St\303\274bner <heiko@sntech.de>\0" - "Subject\0Re: [PATCH v2 03/11] doc/devicetree: Add Aspeed clock bindings\0" + "From\0heiko@sntech.de (Heiko St\303\274bner)\0" + "Subject\0[PATCH v2 03/11] doc/devicetree: Add Aspeed clock bindings\0" "Date\0Thu, 28 Apr 2016 09:25:38 +0200\0" - "To\0Joel Stanley <joel@jms.id.au>\0" - "Cc\0linux-arm-kernel@lists.infradead.org" - Arnd Bergmann <arnd@arndb.de> - Benjamin Herrenschmidt <benh@kernel.crashing.org> - Jeremy Kerr <jk@ozlabs.org> - Michael Turquette <mturquette@baylibre.com> - sboyd@codeaurora.org - " linux-clk@vger.kernel.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Am Donnerstag, 28. April 2016, 16:20:04 schrieb Joel Stanley:\n" - "> On Wed, Apr 27, 2016 at 6:42 PM, Heiko St=FCbner <heiko@sntech.de> wr=\n" - "ote:\n" + "> On Wed, Apr 27, 2016 at 6:42 PM, Heiko St?bner <heiko@sntech.de> wrote:\n" "> > Am Mittwoch, 27. April 2016, 18:01:00 schrieb Joel Stanley:\n" "> >> > From what I remember exposing the clock controller as one block\n" "> >> > (instead\n" "> >> > of\n" - "> >> > declaring each clock individually in the dts) is still the prefe=\n" - "rred\n" + "> >> > declaring each clock individually in the dts) is still the preferred\n" "> >> > way\n" "> >> > but I don't think I can find Mike's mail from back then easily.\n" - "> >>=20\n" - "> >> I can't picture how that would look. I took my lead from the moxar=\n" - "t\n" + "> >> \n" + "> >> I can't picture how that would look. I took my lead from the moxart\n" "> >> clock driver; is there a better example that I should follow?\n" - "> >=20\n" + "> > \n" "> > qcom, samsung, rockchip, hisilicon, imx, ...\n" - ">=20\n" + "> \n" "> I had a look here, and they appear to be much more complex than I\n" - "> need. The qcom directory is 41000 lines of code! The moxart driver is=\n" - "\n" - "> similar to what we do, but as you mentioned it is not arranged how yo=\n" - "u\n" + "> need. The qcom directory is 41000 lines of code! The moxart driver is\n" + "> similar to what we do, but as you mentioned it is not arranged how you\n" "> want it.\n" "\n" - "I'm by no means authoritative ;-), but from what you describe below, cl=\n" - "k-\n" - "asm9260.c or clk-efm32gg.c might be going in that direction of very sim=\n" - "ple=20\n" + "I'm by no means authoritative ;-), but from what you describe below, clk-\n" + "asm9260.c or clk-efm32gg.c might be going in that direction of very simple \n" "clock-controllers.\n" "\n" - "Sorry about pointing to more complex drivers for bigger socs at first :=\n" - "-)\n" + "Sorry about pointing to more complex drivers for bigger socs at first :-)\n" "\n" "\n" - "> > I guess the design would depend on the actual layout of your clock-=\n" - " /\n" + "> > I guess the design would depend on the actual layout of your clock- /\n" "> > system- controller - aka what else is contained there.\n" - ">=20\n" - "> In the fourth generation parts, such as the ast2400, we have this lay=\n" - "out:\n" - ">=20\n" + "> \n" + "> In the fourth generation parts, such as the ast2400, we have this layout:\n" + "> \n" "> clock rate\n" "> -----------------------------\n" "> clk_clkin 48000000\n" "> clk_hpll 384000000\n" "> clk_apb 48000000\n" - ">=20\n" - "> clkin is the oscillator that may be running at 24, 25 or 48MHz. We ca=\n" - "n\n" + "> \n" + "> clkin is the oscillator that may be running at 24, 25 or 48MHz. We can\n" "> determine this from the strapping register.\n" - ">=20\n" + "> \n" "> The hpll divisor is controlled by strapping resistors, and indicated\n" "> in the strapping register.\n" - ">=20\n" + "> \n" "> The apb is controlled by a register in the SCU, the Aspeed's\n" "> bucket-of-bits for controlling various parts of the soc.\n" "\n" - "I remember that from working on Samsung s3c24xx socs, the system-contro=\n" - "ller=20\n" + "I remember that from working on Samsung s3c24xx socs, the system-controller \n" "area also worked as sort of catch-all :-) .\n" "\n" - ">=20\n" - "> In our case we want don't need to adjust any clocks. We do want struc=\n" - "t\n" + "> \n" + "> In our case we want don't need to adjust any clocks. We do want struct\n" "> clk's so attached device drivers to know how fast they are being\n" "> clocked. How do you see this laid out?\n" "\n" see drivers referenced above. -f864f8a19b6f22c6ff5d705365fc3ac1cceebd2a7feb6e23cfbe9bd017a505b3 +ac45d9e810380136ca9b9a2543b14c1c0c5590250e3b12bac7e636947457471a
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.