diff for duplicates of <20151021155312.20687.73917@quantum> diff --git a/a/1.txt b/N1/1.txt index 48f1666..827d63a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,110 +2,84 @@ Quoting Maxime Ripard (2015-10-21 07:53:35) > On Tue, Oct 20, 2015 at 09:29:39AM -0700, Michael Turquette wrote: > > Quoting Maxime Ripard (2015-10-20 07:40:47) > > > Hi Mike, -> > > = - +> > > > > > On Tue, Oct 20, 2015 at 06:43:43AM -0700, Michael Turquette wrote: > > > > Hi Maxime, -> > > > = - +> > > > > > > > Quoting Maxime Ripard (2015-10-20 00:36:45) -> > > > > +struct clk *clk_register_multiplier(struct device *dev, const ch= -ar *name, +> > > > > +struct clk *clk_register_multiplier(struct device *dev, const char *name, > > > > > + const char *parent_name, > > > > > + unsigned long flags, -> > > > > + void __iomem *reg, u8 shift, = -u8 width, -> > > > > + u8 clk_mult_flags, spinlock_t= - *lock) +> > > > > + void __iomem *reg, u8 shift, u8 width, +> > > > > + u8 clk_mult_flags, spinlock_t *lock) > > > > > +{ -> > > > = - -> > > > Patch looks good in general. However this is a good opportunity to = -stop +> > > > +> > > > Patch looks good in general. However this is a good opportunity to stop > > > > the madness around the registration functions in these basic clock > > > > types. -> > > > = - +> > > > > > > > clk_register is really all that we need since we've had struct -> > > > clk_init_data for a while. Initializing a multiplier should be as s= -imple +> > > > clk_init_data for a while. Initializing a multiplier should be as simple > > > > as: -> > > > = - -> > > > struct clk_multiplier clk_foo =3D { -> > > > .hw.init =3D &(struct clk_init_data){ -> > > > .name =3D "foo", -> > > > .parent_names =3D (const char *[]){ +> > > > +> > > > struct clk_multiplier clk_foo = { +> > > > .hw.init = &(struct clk_init_data){ +> > > > .name = "foo", +> > > > .parent_names = (const char *[]){ > > > > "bar", > > > > }, -> > > > .num_parents =3D 1; -> > > > .ops =3D &clk_multiplier_ops, +> > > > .num_parents = 1; +> > > > .ops = &clk_multiplier_ops, > > > > }, -> > > > .reg =3D 0xd34db33f, -> > > > .shift =3D 1, -> > > > .width =3D 2, +> > > > .reg = 0xd34db33f, +> > > > .shift = 1, +> > > > .width = 2, > > > > }; -> > > > = - +> > > > > > > > clk_register(dev, &clk_foo.hw); -> > > > = - +> > > > > > > > This is nice since it turns these basic clocks into even more of a > > > > library and less of a poor mans driver. -> > > > = - +> > > > > > > > (I really hope the above works. I did not test it) -> > > > = - +> > > > > > > > Is it possible you can convert to using this method, and if it is -> > > > correct for you then just remove clk_multiplier_register altogether= -? (In -> > > > fact you might not use the registration function at all since you u= -se +> > > > correct for you then just remove clk_multiplier_register altogether? (In +> > > > fact you might not use the registration function at all since you use > > > > the composite clock...) -> > > = - +> > > > > > This chunk of code has been here since v2, which has been first posted > > > in May, two and half kernel releases ago. -> > > = - +> > > > > > In the meantime, we had a full-blown DMA driver and a quite unusual > > > ASoC driver merged. For some reason, this is the only piece of the > > > audio support that is missing for us, while at the same time it's the > > > most trivial. -> > > = - +> > > > > > If that's the only issue you have with this patch, I'm fine with > > > sending a subsequent patch this week. But I'd be really unhappy with > > > sending yet another version for a single change, while you had 5 > > > monthes to review it, and we discussed it several times on IRC and > > > face to face. -> > = - +> > > > The change can go in later. It's not a prerequisite. I had a feeling > > you'd be grumpy about me asking but I thought I'd try anyways. I won't > > even ask if you got sign-off from Jim on whether this works for his > > platforms ;-) -> = - +> > I asked several times, he never replied... :/ -> = - +> > > The copy/paste nature of these basic clock types really sucks and it is > > one of many reasons that I am hesitant to accept them and slow to merge > > them... -> = - +> > I guess we cover all cases now? So it shouldn't grow that much. -> = - +> > > Anyways it seems that you are not using the registration function at all > > so I might just follow up with a patch to remove it. -> > = - +> > > > I can pick these 5 patches directly, or do you plan to send a PR? -> = - +> > I have a pull request coming for you with a single patch, I can apply > them on that branch and send you the PR later today if it's okay? @@ -114,14 +88,11 @@ Sounds good to me. Regards, Mike -> = - +> > Thanks, > Maxime -> = - -> -- = - +> +> -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com diff --git a/a/content_digest b/N1/content_digest index 89d618b..71f4747 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,128 +4,94 @@ "ref\020151020144047.GA10947@lukather\0" "ref\020151020162939.20687.32769@quantum\0" "ref\020151021145335.GF10947@lukather\0" - "From\0Michael Turquette <mturquette@baylibre.com>\0" - "Subject\0Re: [PATCH v6 1/5] clk: Add a basic multiplier clock\0" + "From\0mturquette@baylibre.com (Michael Turquette)\0" + "Subject\0[PATCH v6 1/5] clk: Add a basic multiplier clock\0" "Date\0Wed, 21 Oct 2015 08:53:12 -0700\0" - "To\0Maxime Ripard <maxime.ripard@free-electrons.com>" - "\0" - "Cc\0Stephen Boyd <sboyd@codeaurora.org>" - Emilio Lopez <emilio@elopez.com.ar> - linux-arm-kernel@lists.infradead.org - linux-clk@vger.kernel.org - Chen-Yu Tsai <wens@csie.org> - Hans de Goede <hdegoede@redhat.com> - " linux-sunxi@googlegroups.com\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Quoting Maxime Ripard (2015-10-21 07:53:35)\n" "> On Tue, Oct 20, 2015 at 09:29:39AM -0700, Michael Turquette wrote:\n" "> > Quoting Maxime Ripard (2015-10-20 07:40:47)\n" "> > > Hi Mike,\n" - "> > > =\n" - "\n" + "> > > \n" "> > > On Tue, Oct 20, 2015 at 06:43:43AM -0700, Michael Turquette wrote:\n" "> > > > Hi Maxime,\n" - "> > > > =\n" - "\n" + "> > > > \n" "> > > > Quoting Maxime Ripard (2015-10-20 00:36:45)\n" - "> > > > > +struct clk *clk_register_multiplier(struct device *dev, const ch=\n" - "ar *name,\n" + "> > > > > +struct clk *clk_register_multiplier(struct device *dev, const char *name,\n" "> > > > > + const char *parent_name,\n" "> > > > > + unsigned long flags,\n" - "> > > > > + void __iomem *reg, u8 shift, =\n" - "u8 width,\n" - "> > > > > + u8 clk_mult_flags, spinlock_t=\n" - " *lock)\n" + "> > > > > + void __iomem *reg, u8 shift, u8 width,\n" + "> > > > > + u8 clk_mult_flags, spinlock_t *lock)\n" "> > > > > +{\n" - "> > > > =\n" - "\n" - "> > > > Patch looks good in general. However this is a good opportunity to =\n" - "stop\n" + "> > > > \n" + "> > > > Patch looks good in general. However this is a good opportunity to stop\n" "> > > > the madness around the registration functions in these basic clock\n" "> > > > types.\n" - "> > > > =\n" - "\n" + "> > > > \n" "> > > > clk_register is really all that we need since we've had struct\n" - "> > > > clk_init_data for a while. Initializing a multiplier should be as s=\n" - "imple\n" + "> > > > clk_init_data for a while. Initializing a multiplier should be as simple\n" "> > > > as:\n" - "> > > > =\n" - "\n" - "> > > > struct clk_multiplier clk_foo =3D {\n" - "> > > > .hw.init =3D &(struct clk_init_data){\n" - "> > > > .name =3D \"foo\",\n" - "> > > > .parent_names =3D (const char *[]){\n" + "> > > > \n" + "> > > > struct clk_multiplier clk_foo = {\n" + "> > > > .hw.init = &(struct clk_init_data){\n" + "> > > > .name = \"foo\",\n" + "> > > > .parent_names = (const char *[]){\n" "> > > > \"bar\",\n" "> > > > },\n" - "> > > > .num_parents =3D 1;\n" - "> > > > .ops =3D &clk_multiplier_ops,\n" + "> > > > .num_parents = 1;\n" + "> > > > .ops = &clk_multiplier_ops,\n" "> > > > },\n" - "> > > > .reg =3D 0xd34db33f,\n" - "> > > > .shift =3D 1,\n" - "> > > > .width =3D 2,\n" + "> > > > .reg = 0xd34db33f,\n" + "> > > > .shift = 1,\n" + "> > > > .width = 2,\n" "> > > > };\n" - "> > > > =\n" - "\n" + "> > > > \n" "> > > > clk_register(dev, &clk_foo.hw);\n" - "> > > > =\n" - "\n" + "> > > > \n" "> > > > This is nice since it turns these basic clocks into even more of a\n" "> > > > library and less of a poor mans driver.\n" - "> > > > =\n" - "\n" + "> > > > \n" "> > > > (I really hope the above works. I did not test it)\n" - "> > > > =\n" - "\n" + "> > > > \n" "> > > > Is it possible you can convert to using this method, and if it is\n" - "> > > > correct for you then just remove clk_multiplier_register altogether=\n" - "? (In\n" - "> > > > fact you might not use the registration function at all since you u=\n" - "se\n" + "> > > > correct for you then just remove clk_multiplier_register altogether? (In\n" + "> > > > fact you might not use the registration function at all since you use\n" "> > > > the composite clock...)\n" - "> > > =\n" - "\n" + "> > > \n" "> > > This chunk of code has been here since v2, which has been first posted\n" "> > > in May, two and half kernel releases ago.\n" - "> > > =\n" - "\n" + "> > > \n" "> > > In the meantime, we had a full-blown DMA driver and a quite unusual\n" "> > > ASoC driver merged. For some reason, this is the only piece of the\n" "> > > audio support that is missing for us, while at the same time it's the\n" "> > > most trivial.\n" - "> > > =\n" - "\n" + "> > > \n" "> > > If that's the only issue you have with this patch, I'm fine with\n" "> > > sending a subsequent patch this week. But I'd be really unhappy with\n" "> > > sending yet another version for a single change, while you had 5\n" "> > > monthes to review it, and we discussed it several times on IRC and\n" "> > > face to face.\n" - "> > =\n" - "\n" + "> > \n" "> > The change can go in later. It's not a prerequisite. I had a feeling\n" "> > you'd be grumpy about me asking but I thought I'd try anyways. I won't\n" "> > even ask if you got sign-off from Jim on whether this works for his\n" "> > platforms ;-)\n" - "> =\n" - "\n" + "> \n" "> I asked several times, he never replied... :/\n" - "> =\n" - "\n" + "> \n" "> > The copy/paste nature of these basic clock types really sucks and it is\n" "> > one of many reasons that I am hesitant to accept them and slow to merge\n" "> > them...\n" - "> =\n" - "\n" + "> \n" "> I guess we cover all cases now? So it shouldn't grow that much.\n" - "> =\n" - "\n" + "> \n" "> > Anyways it seems that you are not using the registration function at all\n" "> > so I might just follow up with a patch to remove it.\n" - "> > =\n" - "\n" + "> > \n" "> > I can pick these 5 patches directly, or do you plan to send a PR?\n" - "> =\n" - "\n" + "> \n" "> I have a pull request coming for you with a single patch, I can apply\n" "> them on that branch and send you the PR later today if it's okay?\n" "\n" @@ -134,16 +100,13 @@ "Regards,\n" "Mike\n" "\n" - "> =\n" - "\n" + "> \n" "> Thanks,\n" "> Maxime\n" - "> =\n" - "\n" - "> -- =\n" - "\n" + "> \n" + "> -- \n" "> Maxime Ripard, Free Electrons\n" "> Embedded Linux, Kernel and Android engineering\n" > http://free-electrons.com -964735a1436548757392e0e9e879a6b628f3af57b4042706bc199a5b86b0862c +65327aa08312f8b40f9de83bfb9914650620208d6aadd667e6ba16ffe95192a2
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.