diff for duplicates of <20130822224331.8231.75743@quantum> diff --git a/a/1.txt b/N1/1.txt index 88ddf32..320dd88 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,106 +5,157 @@ Quoting Sascha Hauer (2013-08-22 14:00:35) > > > > 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: -> > > > > > > > > > > > > Also I would make this option required. Use a dummy +> > > > > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wro= +te: +> > > > > > > > > > > > > Also I would make this option required. Use a dum= +my > > > > > > > > > > > > > clock for > > > > > > > > > > > > > mux > > > > > > > > > > > > > inputs that are grounded for a specific SoC. -> > > > > > > > > > > > -> > > > > > > > > > > > Some clocks are not from CCM and we haven't defined in +> > > > > > > > > > > > = + +> > > > > > > > > > > > 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: +> > > > > > > > > > > > so in most cases we can't provide a phandle for the= +m, eg: > > > > > > > > > > > > spdif_ext. -> > > > > > > > > > > > I think it's a bit hard to force it to be 'required'. An +> > > > > > > > > > > > I think it's a bit hard to force it to be 'required= +'. An > > > > > > > > > > > > 'optional' -> > > > > > > > > > > > looks more flexible to me and a default one is ensured +> > > > > > > > > > > > looks more flexible to me and a default one is ensu= +red > > > > > > > > > > > > even if > > > > > > > > > > > > it's > > > > > > > > > > > > missing. -> > > > > > > > > > > -> > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for all input +> > > > > > > > > > > = + +> > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for al= +l 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 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 +> > > > > > > > = + +> > > > > > > > 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 +> > > > > > = + +> > > > > > 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, +> > > > > > 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 +> > > > > = + +> > > > > When you say some platforms, you presumably mean the platform cod= +e in +> > > > > Linux? A dummy clock sounds like a completely Linux-specific abst= +raction +> > > > > 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 +> > > > > = + +> > > > > * If a clock is wired up and running (as presumably the dummy clo= +ck is), +> > > > > then surely it's a fixed-clock (it's running, we and we have no c= +ontrol +> > > > > 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 tha= +t. 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 any= +thing. = + +> > > > It should be able to describe hardware that is available on given s= +ystem, = + > > > > not list what hardware is not available. -> > > +> > > = + > > > I wasn't clear. The dummy clock IS a completely Linux-specific > > > abstraction. -> > > -> > > I'm not advocating a dummy clock in DT. I am advocating consolidation of +> > > = + +> > > I'm not advocating a dummy clock in DT. I am advocating consolidation= + of > > > the implementation of a clock that does nothing into the clock core. > > > This code could easily live in drivers/clk/clk.c instead of having > > > everyone open-code it. -> > > +> > > = + > > > As far as specifying a dummy clock in DT? I dunno. DT should describe > > > real hardware so there isn't much use for a dummy clock. -> > -> > +> > = + +> > = + > > Sorry, I misunderstood. Good to hear we're on the same page :) -> > -> > > +> > = + +> > > = + > > > I'm guessing one of the reasons for such a clock are drivers do not > > > honor the clk.h api and they freak out when clk_get gives them a NULL > > > pointer? -> > +> > = + > > I'm not sure. Sascha, could you shed some light on the matter? -> +> = + > The original reason introducing the dummy clocks in the i.MX dtbs > was to provide devices a clock which the driver requests but is > not software controllable. We often have the case where the same > devices are on several SoCs, but not on all of them all clocks have > a bit to en/disable them. -> +> = + > Anyway, to accomplish this we don't need dummy clocks. We can just > describe the real clocks. @@ -116,7 +167,8 @@ It is probably better for you define a clock which only implements the .recalc_rate callback. If the rate of this clock changes without Linux having knowledge of it you can use the CLK_GET_RATE_NOCACHE flag. -> +> = + > BTW with the S/PDIF core on which not all mux inputs are connected > to actual clocks we could also describe the unconnected inputs as > ground clocks with rate 0. This way we describe something which @@ -128,7 +180,8 @@ rate of zero from the perspective of the Linux implementation. Do you think it worthwhile to have a DT binding for a grounded clock? That is not an entirely uncommon case. -> +> = + > Background to why it might be a good idea to connect a ground clock > to the unconnected input pins is that a driver has a chance to > successfully grab all clocks. Otherwise how does the driver distinguish @@ -140,10 +193,13 @@ based on the value returned from clk_get? Regards, Mike -> +> = + > Sascha -> -> -- +> = + +> -- = + > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | diff --git a/a/content_digest b/N1/content_digest index d182a34..fc2e66d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -35,106 +35,157 @@ "> > > > 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" - "> > > > > > > > > > > > > Also I would make this option required. Use a dummy\n" + "> > > > > > > > > On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wro=\n" + "te:\n" + "> > > > > > > > > > > > > Also I would make this option required. Use a dum=\n" + "my\n" "> > > > > > > > > > > > > clock for\n" "> > > > > > > > > > > > > mux\n" "> > > > > > > > > > > > > inputs that are grounded for a specific SoC.\n" - "> > > > > > > > > > > > \n" - "> > > > > > > > > > > > Some clocks are not from CCM and we haven't defined in\n" + "> > > > > > > > > > > > =\n" + "\n" + "> > > > > > > > > > > > Some clocks are not from CCM and we haven't defined=\n" + " in\n" "> > > > > > > > > > > > imx6q-clk.txt,\n" - "> > > > > > > > > > > > so in most cases we can't provide a phandle for them, eg:\n" + "> > > > > > > > > > > > so in most cases we can't provide a phandle for the=\n" + "m, eg:\n" "> > > > > > > > > > > > spdif_ext.\n" - "> > > > > > > > > > > > I think it's a bit hard to force it to be 'required'. An\n" + "> > > > > > > > > > > > I think it's a bit hard to force it to be 'required=\n" + "'. An\n" "> > > > > > > > > > > > 'optional'\n" - "> > > > > > > > > > > > looks more flexible to me and a default one is ensured\n" + "> > > > > > > > > > > > looks more flexible to me and a default one is ensu=\n" + "red\n" "> > > > > > > > > > > > even if\n" "> > > > > > > > > > > > it's\n" "> > > > > > > > > > > > missing.\n" - "> > > > > > > > > > > \n" - "> > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for all input\n" + "> > > > > > > > > > > =\n" + "\n" + "> > > > > > > > > > > <&clks 0> is the dummy clock. This can be used for al=\n" + "l 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" - "> > > > > > > > I guess we need some discussion on dummy clocks vs skipped clocks.\n" + "> > > > > > > > =\n" + "\n" + "> > > > > > > > I guess we need some discussion on dummy clocks vs skipped =\n" + "clocks.\n" "> > > > > > > > I think we want some consistency on this, don't we?\n" - "> > > > > > > > \n" - "> > > > > > > > If we really need a dummy clock, then we might also want a generic\n" + "> > > > > > > > =\n" + "\n" + "> > > > > > > > If we really need a dummy clock, then we might also want a =\n" + "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" - "> > > > > > Some platforms have a fake clock which defines noops callbacks and\n" + "> > > > > > =\n" + "\n" + "> > > > > > Some platforms have a fake clock which defines noops callbacks =\n" + "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" + "> > > > > > implementation. A central one could be registered by the clock =\n" + "core,\n" "> > > > > > as\n" "> > > > > > is done by the regulator core.\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" + "> > > > > =\n" + "\n" + "> > > > > When you say some platforms, you presumably mean the platform cod=\n" + "e in\n" + "> > > > > Linux? A dummy clock sounds like a completely Linux-specific abst=\n" + "raction\n" + "> > > > > rather than a description of the hardware, and I don't see why we=\n" + " need\n" "> > > > > that in the DT:\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" - "> > > > > * 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" + "> > > > > =\n" + "\n" + "> > > > > * If a clock is wired up and running (as presumably the dummy clo=\n" + "ck is),\n" + "> > > > > then surely it's a fixed-clock (it's running, we and we have no c=\n" + "ontrol\n" + "> > > > > over it, but we presumably know its rate) and can be described as=\n" + " such?\n" + "> > > > > =\n" + "\n" + "> > > > > * If no clock is wired up, then we should be able to describe tha=\n" + "t. If a\n" + "> > > > > driver believes that a clock is required when it isn't (for some =\n" + "level\n" + "> > > > > of functionality), then that driver should be fixed up to support=\n" + " 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 any=\n" + "thing. =\n" + "\n" + "> > > > It should be able to describe hardware that is available on given s=\n" + "ystem, =\n" + "\n" "> > > > not list what hardware is not available.\n" - "> > > \n" + "> > > =\n" + "\n" "> > > I wasn't clear. The dummy clock IS a completely Linux-specific\n" "> > > abstraction.\n" - "> > > \n" - "> > > I'm not advocating a dummy clock in DT. I am advocating consolidation of\n" + "> > > =\n" + "\n" + "> > > I'm not advocating a dummy clock in DT. I am advocating consolidation=\n" + " of\n" "> > > the implementation of a clock that does nothing into the clock core.\n" "> > > This code could easily live in drivers/clk/clk.c instead of having\n" "> > > everyone open-code it.\n" - "> > > \n" + "> > > =\n" + "\n" "> > > As far as specifying a dummy clock in DT? I dunno. DT should describe\n" "> > > real hardware so there isn't much use for a dummy clock.\n" - "> > \n" - "> > \n" + "> > =\n" + "\n" + "> > =\n" + "\n" "> > Sorry, I misunderstood. Good to hear we're on the same page :)\n" - "> > \n" - "> > > \n" + "> > =\n" + "\n" + "> > > =\n" + "\n" "> > > I'm guessing one of the reasons for such a clock are drivers do not\n" "> > > honor the clk.h api and they freak out when clk_get gives them a NULL\n" "> > > pointer?\n" - "> > \n" + "> > =\n" + "\n" "> > I'm not sure. Sascha, could you shed some light on the matter?\n" - "> \n" + "> =\n" + "\n" "> The original reason introducing the dummy clocks in the i.MX dtbs\n" "> was to provide devices a clock which the driver requests but is\n" "> not software controllable. We often have the case where the same\n" "> devices are on several SoCs, but not on all of them all clocks have\n" "> a bit to en/disable them.\n" - "> \n" + "> =\n" + "\n" "> Anyway, to accomplish this we don't need dummy clocks. We can just\n" "> describe the real clocks.\n" "\n" @@ -146,7 +197,8 @@ ".recalc_rate callback. If the rate of this clock changes without Linux\n" "having knowledge of it you can use the CLK_GET_RATE_NOCACHE flag.\n" "\n" - "> \n" + "> =\n" + "\n" "> BTW with the S/PDIF core on which not all mux inputs are connected\n" "> to actual clocks we could also describe the unconnected inputs as\n" "> ground clocks with rate 0. This way we describe something which\n" @@ -158,7 +210,8 @@ "Do you think it worthwhile to have a DT binding for a grounded clock?\n" "That is not an entirely uncommon case.\n" "\n" - "> \n" + "> =\n" + "\n" "> Background to why it might be a good idea to connect a ground clock\n" "> to the unconnected input pins is that a driver has a chance to\n" "> successfully grab all clocks. Otherwise how does the driver distinguish\n" @@ -170,13 +223,16 @@ "Regards,\n" "Mike\n" "\n" - "> \n" + "> =\n" + "\n" "> Sascha\n" - "> \n" - "> -- \n" + "> =\n" + "\n" + "> -- =\n" + "\n" "> Pengutronix e.K. | |\n" "> Industrial Linux Solutions | http://www.pengutronix.de/ |\n" "> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |\n" > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -e44a5db2a81e2c4a0774331c877169ca6b1cfd62ae2c53917bead01fa5e07d79 +c2438a3d22087a8a4ac7923c53261bc0094290147a4ec83be30b5565c2999d67
diff --git a/a/content_digest b/N2/content_digest index d182a34..958c198 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -10,22 +10,22 @@ "Date\0Thu, 22 Aug 2013 15:43:31 -0700\0" "To\0Sascha Hauer <s.hauer@pengutronix.de>" " 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\0Tomasz Figa <tomasz.figa@gmail.com>" + 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> - Nicolin Chen <b42378@freescale.com> - Tomasz Figa <tomasz.figa@gmail.com> - rob.herring@calxeda.com <rob.herring@calxeda.com> - timur@tabi.org <timur@tabi.org> + 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 Sascha Hauer (2013-08-22 14:00:35)\n" @@ -179,4 +179,4 @@ "> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |\n" > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -e44a5db2a81e2c4a0774331c877169ca6b1cfd62ae2c53917bead01fa5e07d79 +d5b0b4460e194017a3c643026d622c509d8e446b3f12a40561511d9765cfe7f3
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.