diff for duplicates of <20130822071910.8231.47324@quantum> diff --git a/a/1.txt b/N1/1.txt index 6321e0a..0066c8b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,7 +2,8 @@ Quoting Tomasz Figa (2013-08-21 14:34:55) > On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote: > > On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote: > > > Quoting Mark Rutland (2013-08-19 02:35:43) -> > > +> > > = + > > > > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote: > > > > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote: > > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote: @@ -10,7 +11,8 @@ Quoting Tomasz Figa (2013-08-21 14:34:55) > > > > > > > > > > clock for > > > > > > > > > > mux > > > > > > > > > > inputs that are grounded for a specific SoC. -> > > > > > > > > +> > > > > > > > > = + > > > > > > > > > Some clocks are not from CCM and we haven't defined in > > > > > > > > > imx6q-clk.txt, > > > > > > > > > so in most cases we can't provide a phandle for them, eg: @@ -21,58 +23,74 @@ Quoting Tomasz Figa (2013-08-21 14:34:55) > > > > > > > > > even if > > > > > > > > > it's > > > > > > > > > missing. -> > > > > > > > +> > > > > > > > = + > > > > > > > > <&clks 0> is the dummy clock. This can be used for all input > > > > > > > > clocks > > > > > > > > not > > > > > > > > defined by the SoC. -> > > > > > > +> > > > > > > = + > > > > > > > Where does this assumption come from? Is it documented > > > > > > > anywhere? -> > > > > > +> > > > > > = + > > > > > > This is how all i.MX clock bindings currently are. See > > > > > > Documentation/devicetree/bindings/clock/imx*-clock.txt -> > > > > +> > > > > = + > > > > > OK, thanks. -> > > > > +> > > > > = + > > > > > I guess we need some discussion on dummy clocks vs skipped clocks. > > > > > I think we want some consistency on this, don't we? -> > > > > +> > > > > = + > > > > > If we really need a dummy clock, then we might also want a generic > > > > > way to specify it. -> > > > +> > > > = + > > > > What do we actually mean by a "dummy clock"? We already have > > > > bindings > > > > for "fixed-clock" and co friends describe relatively simple > > > > preconfigured clocks. -> > > +> > > = + > > > Some platforms have a fake clock which defines noops callbacks and > > > basically doesn't do anything. This is analogous to the dummy > > > regulator > > > implementation. A central one could be registered by the clock core, > > > as > > > is done by the regulator core. -> > +> > = + > > When you say some platforms, you presumably mean the platform code in > > Linux? A dummy clock sounds like a completely Linux-specific abstraction > > rather than a description of the hardware, and I don't see why we need > > that in the DT: -> > +> > = + > > * If a clock is wired up and running (as presumably the dummy clock is), > > then surely it's a fixed-clock (it's running, we and we have no control > > over it, but we presumably know its rate) and can be described as such? -> > +> > = + > > * If no clock is wired up, then we should be able to describe that. If a > > driver believes that a clock is required when it isn't (for some level > > of functionality), then that driver should be fixed up to support the > > clock as being optional. -> > +> > = + > > Am I missing something? -> +> = + > I second that. -> -> Moreover, I don't think that device tree should deal with dummy anything. -> It should be able to describe hardware that is available on given system, +> = + +> Moreover, I don't think that device tree should deal with dummy anything. = + +> It should be able to describe hardware that is available on given system, = + > not list what hardware is not available. I wasn't clear. The dummy clock IS a completely Linux-specific @@ -93,6 +111,7 @@ pointer? Regards, Mike -> +> = + > Best regards, > Tomasz diff --git a/a/content_digest b/N1/content_digest index e1cfd38..1951376 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -29,7 +29,8 @@ "> On Wednesday 21 of August 2013 09:50:15 Mark Rutland wrote:\n" "> > On Tue, Aug 20, 2013 at 01:06:25AM +0100, Mike Turquette wrote:\n" "> > > Quoting Mark Rutland (2013-08-19 02:35:43)\n" - "> > > \n" + "> > > =\n" + "\n" "> > > > On Sat, Aug 17, 2013 at 04:17:18PM +0100, Tomasz Figa wrote:\n" "> > > > > On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote:\n" "> > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote:\n" @@ -37,7 +38,8 @@ "> > > > > > > > > > clock for\n" "> > > > > > > > > > mux\n" "> > > > > > > > > > inputs that are grounded for a specific SoC.\n" - "> > > > > > > > > \n" + "> > > > > > > > > =\n" + "\n" "> > > > > > > > > Some clocks are not from CCM and we haven't defined in\n" "> > > > > > > > > imx6q-clk.txt,\n" "> > > > > > > > > so in most cases we can't provide a phandle for them, eg:\n" @@ -48,58 +50,74 @@ "> > > > > > > > > even if\n" "> > > > > > > > > it's\n" "> > > > > > > > > missing.\n" - "> > > > > > > > \n" + "> > > > > > > > =\n" + "\n" "> > > > > > > > <&clks 0> is the dummy clock. This can be used for all input\n" "> > > > > > > > clocks\n" "> > > > > > > > not\n" "> > > > > > > > defined by the SoC.\n" - "> > > > > > > \n" + "> > > > > > > =\n" + "\n" "> > > > > > > Where does this assumption come from? Is it documented\n" "> > > > > > > anywhere?\n" - "> > > > > > \n" + "> > > > > > =\n" + "\n" "> > > > > > This is how all i.MX clock bindings currently are. See\n" "> > > > > > Documentation/devicetree/bindings/clock/imx*-clock.txt\n" - "> > > > > \n" + "> > > > > =\n" + "\n" "> > > > > OK, thanks.\n" - "> > > > > \n" + "> > > > > =\n" + "\n" "> > > > > I guess we need some discussion on dummy clocks vs skipped clocks.\n" "> > > > > I think we want some consistency on this, don't we?\n" - "> > > > > \n" + "> > > > > =\n" + "\n" "> > > > > If we really need a dummy clock, then we might also want a generic\n" "> > > > > way to specify it.\n" - "> > > > \n" + "> > > > =\n" + "\n" "> > > > What do we actually mean by a \"dummy clock\"? We already have\n" "> > > > bindings\n" "> > > > for \"fixed-clock\" and co friends describe relatively simple\n" "> > > > preconfigured clocks.\n" - "> > > \n" + "> > > =\n" + "\n" "> > > Some platforms have a fake clock which defines noops callbacks and\n" "> > > basically doesn't do anything. This is analogous to the dummy\n" "> > > regulator\n" "> > > implementation. A central one could be registered by the clock core,\n" "> > > as\n" "> > > is done by the regulator core.\n" - "> > \n" + "> > =\n" + "\n" "> > When you say some platforms, you presumably mean the platform code in\n" "> > Linux? A dummy clock sounds like a completely Linux-specific abstraction\n" "> > rather than a description of the hardware, and I don't see why we need\n" "> > that in the DT:\n" - "> > \n" + "> > =\n" + "\n" "> > * If a clock is wired up and running (as presumably the dummy clock is),\n" "> > then surely it's a fixed-clock (it's running, we and we have no control\n" "> > over it, but we presumably know its rate) and can be described as such?\n" - "> > \n" + "> > =\n" + "\n" "> > * If no clock is wired up, then we should be able to describe that. If a\n" "> > driver believes that a clock is required when it isn't (for some level\n" "> > of functionality), then that driver should be fixed up to support the\n" "> > clock as being optional.\n" - "> > \n" + "> > =\n" + "\n" "> > Am I missing something?\n" - "> \n" + "> =\n" + "\n" "> I second that.\n" - "> \n" - "> Moreover, I don't think that device tree should deal with dummy anything. \n" - "> It should be able to describe hardware that is available on given system, \n" + "> =\n" + "\n" + "> Moreover, I don't think that device tree should deal with dummy anything. =\n" + "\n" + "> It should be able to describe hardware that is available on given system, =\n" + "\n" "> not list what hardware is not available.\n" "\n" "I wasn't clear. The dummy clock IS a completely Linux-specific\n" @@ -120,8 +138,9 @@ "Regards,\n" "Mike\n" "\n" - "> \n" + "> =\n" + "\n" "> Best regards,\n" > Tomasz -d06ae092f74992ac7abb5045ad92ca415e11ab27dbc3e506ad50ff01582b8ee1 +b6258cc91943d1e281ffa51f5f046ba69c6f7d060158359fbae4d2d4f2de7ce0
diff --git a/a/content_digest b/N2/content_digest index e1cfd38..8d825e7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -7,22 +7,22 @@ "Date\0Thu, 22 Aug 2013 00:19:10 -0700\0" "To\0Tomasz Figa <tomasz.figa@gmail.com>" " Mark Rutland <mark.rutland@arm.com>\0" - "Cc\0devicetree@vger.kernel.org <devicetree@vger.kernel.org>" - alsa-devel@alsa-project.org <alsa-devel@alsa-project.org> - lars@metafoo.de <lars@metafoo.de> + "Cc\0Sascha Hauer <s.hauer@pengutronix.de>" + Nicolin Chen <b42378@freescale.com> ian.campbell@citrix.com <ian.campbell@citrix.com> Pawel Moll <Pawel.Moll@arm.com> - swarren@wwwdotorg.org <swarren@wwwdotorg.org> - festevam@gmail.com <festevam@gmail.com> - Sascha Hauer <s.hauer@pengutronix.de> - Nicolin Chen <b42378@freescale.com> - timur@tabi.org <timur@tabi.org> - rob.herring@calxeda.com <rob.herring@calxeda.com> + galak@codeaurora.org <galak@codeaurora.org> broonie@kernel.org <broonie@kernel.org> + lars@metafoo.de <lars@metafoo.de> p.zabel@pengutronix.de <p.zabel@pengutronix.de> - galak@codeaurora.org <galak@codeaurora.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> + alsa-devel@alsa-project.org <alsa-devel@alsa-project.org> + devicetree@vger.kernel.org <devicetree@vger.kernel.org> + timur@tabi.org <timur@tabi.org> + rob.herring@calxeda.com <rob.herring@calxeda.com> shawn.guo@linaro.org <shawn.guo@linaro.org> - " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" + festevam@gmail.com <festevam@gmail.com> + " swarren@wwwdotorg.org <swarren@wwwdotorg.org>\0" "\00:1\0" "b\0" "Quoting Tomasz Figa (2013-08-21 14:34:55)\n" @@ -124,4 +124,4 @@ "> Best regards,\n" > Tomasz -d06ae092f74992ac7abb5045ad92ca415e11ab27dbc3e506ad50ff01582b8ee1 +0c53506208ecea353987ff8e89e4b51b70901b97428af3036e8c878ec73afc8e
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.