Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/04/2014 08:47 PM, Mark Brown wrote: On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote: I still need help with one thing that isn't clear to me though. The DT is parsed when calling regulator_register. But then how do I fetch my "private" settings in there BEFORE the regulator gets enabled? The feedback resistors and regulator mode must be set to the correct board before the output is enabled, otherwise it may damage the chip and its periferals. Add a callback for this. Javier and/or Krzysztof were looking at this for some other stuff, though I think they were intending to add core functionality for their specific feature. I've run out of my hours-to-spend-on-driver-submission budget for this period , so it'll be at least a week before I can post a new version. The good news is that I have upgrading the kernel to 3.17 on the planning board now, so that'll at least reduce the version gap. Mike. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On wto, 2014-11-04 at 19:47 +, Mark Brown wrote: > On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote: > > > I still need help with one thing that isn't clear to me though. The DT is > > parsed when calling regulator_register. But then how do I fetch my "private" > > settings in there BEFORE the regulator gets enabled? The feedback resistors > > and regulator mode must be set to the correct board before the output is > > enabled, otherwise it may damage the chip and its periferals. > > Add a callback for this. Javier and/or Krzysztof were looking at this > for some other stuff, though I think they were intending to add core > functionality for their specific feature. I needed a callback and added such. The callback was called on each DT node parsed. However I dropped that idea because it turned our to be unsuitable to my case. I needed to feed regulator_config.ena_gpio with data parsed from such callback. But the callback called from inside the regulator_register() has the regulator_config const. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On wto, 2014-11-04 at 19:47 +, Mark Brown wrote: On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote: I still need help with one thing that isn't clear to me though. The DT is parsed when calling regulator_register. But then how do I fetch my private settings in there BEFORE the regulator gets enabled? The feedback resistors and regulator mode must be set to the correct board before the output is enabled, otherwise it may damage the chip and its periferals. Add a callback for this. Javier and/or Krzysztof were looking at this for some other stuff, though I think they were intending to add core functionality for their specific feature. I needed a callback and added such. The callback was called on each DT node parsed. However I dropped that idea because it turned our to be unsuitable to my case. I needed to feed regulator_config.ena_gpio with data parsed from such callback. But the callback called from inside the regulator_register() has the regulator_config const. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/04/2014 08:47 PM, Mark Brown wrote: On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote: I still need help with one thing that isn't clear to me though. The DT is parsed when calling regulator_register. But then how do I fetch my private settings in there BEFORE the regulator gets enabled? The feedback resistors and regulator mode must be set to the correct board before the output is enabled, otherwise it may damage the chip and its periferals. Add a callback for this. Javier and/or Krzysztof were looking at this for some other stuff, though I think they were intending to add core functionality for their specific feature. I've run out of my hours-to-spend-on-driver-submission budget for this period , so it'll be at least a week before I can post a new version. The good news is that I have upgrading the kernel to 3.17 on the planning board now, so that'll at least reduce the version gap. Mike. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote: > I still need help with one thing that isn't clear to me though. The DT is > parsed when calling regulator_register. But then how do I fetch my "private" > settings in there BEFORE the regulator gets enabled? The feedback resistors > and regulator mode must be set to the correct board before the output is > enabled, otherwise it may damage the chip and its periferals. Add a callback for this. Javier and/or Krzysztof were looking at this for some other stuff, though I think they were intending to add core functionality for their specific feature. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/04/2014 12:34 PM, Mark Brown wrote: On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote: On 11/03/2014 06:38 PM, Mike Looijmans wrote: You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say "no" to that. It should be easy to backport the support into your current kernel, it's just a few commits and there hasn't been much development in this area of the code. Can you take a look at doing that please? I can cherry-pick about 4 commits to get the updated core into my 3.15 tree. I still need help with one thing that isn't clear to me though. The DT is parsed when calling regulator_register. But then how do I fetch my "private" settings in there BEFORE the regulator gets enabled? The feedback resistors and regulator mode must be set to the correct board before the output is enabled, otherwise it may damage the chip and its periferals. The only two drivers using the regulators_node (tps65217 and isl9305.c) don't have any private values in the DT. M. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/04/2014 12:34 PM, Mark Brown wrote: On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote: On 11/03/2014 06:38 PM, Mike Looijmans wrote: You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say "no" to that. It should be easy to backport the support into your current kernel, it's just a few commits and there hasn't been much development in this area of the code. Can you take a look at doing that please? That option hadn't crossed my mind yet, I'll look into it. More important than that: Since this chip powers the IO banks, we need it for our own products, and hence it has to work (also) on the current 3.15 kernel. Using APIs from 3.18 wouold render the driver useless to ourselves. This is just not at all important upstream, sorry. The kernel moves on and internal APIs within the kernel move on so it is expected that code used in production won't be the latest and greatest upstream code. I realize that, but then the result would be that I'll stop working on getting the driver into mainline and force customers to use a patch or use our fork of linux. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote: > On 11/03/2014 06:38 PM, Mike Looijmans wrote: > >>You need to develop against current versions of the kernel, this is > >>something that was merged into Linus' tree during the merge window. > >Is this an absolute show-stopper for you? > >With some effort I could move from our current 3.15 to 3.17, but even that > >wouldn't be recent enough then. I can justify spending a few days on getting > >the driver integrated into mainline, even if the initial version cost less > >than that; but moving everything to mainline is going to take weeks and the > >boss is definitely going to say "no" to that. It should be easy to backport the support into your current kernel, it's just a few commits and there hasn't been much development in this area of the code. Can you take a look at doing that please? > More important than that: Since this chip powers the IO banks, we need it > for our own products, and hence it has to work (also) on the current 3.15 > kernel. Using APIs from 3.18 wouold render the driver useless to ourselves. This is just not at all important upstream, sorry. The kernel moves on and internal APIs within the kernel move on so it is expected that code used in production won't be the latest and greatest upstream code. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/03/2014 06:38 PM, Mike Looijmans wrote: On 3-11-2014 16:10, Mark Brown wrote: On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: On 11/03/2014 01:09 PM, Mark Brown wrote: No function calls, just use regulators_node. What is unclear about the functionality? I don't understand what you mean by "regulators_node". "grep -R regulators_node *" in the kernel source tree returns no results, nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say "no" to that. More important than that: Since this chip powers the IO banks, we need it for our own products, and hence it has to work (also) on the current 3.15 kernel. Using APIs from 3.18 wouold render the driver useless to ourselves. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/03/2014 06:38 PM, Mike Looijmans wrote: On 3-11-2014 16:10, Mark Brown wrote: On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: On 11/03/2014 01:09 PM, Mark Brown wrote: No function calls, just use regulators_node. What is unclear about the functionality? I don't understand what you mean by regulators_node. grep -R regulators_node * in the kernel source tree returns no results, nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say no to that. More important than that: Since this chip powers the IO banks, we need it for our own products, and hence it has to work (also) on the current 3.15 kernel. Using APIs from 3.18 wouold render the driver useless to ourselves. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote: On 11/03/2014 06:38 PM, Mike Looijmans wrote: You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say no to that. It should be easy to backport the support into your current kernel, it's just a few commits and there hasn't been much development in this area of the code. Can you take a look at doing that please? More important than that: Since this chip powers the IO banks, we need it for our own products, and hence it has to work (also) on the current 3.15 kernel. Using APIs from 3.18 wouold render the driver useless to ourselves. This is just not at all important upstream, sorry. The kernel moves on and internal APIs within the kernel move on so it is expected that code used in production won't be the latest and greatest upstream code. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/04/2014 12:34 PM, Mark Brown wrote: On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote: On 11/03/2014 06:38 PM, Mike Looijmans wrote: You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say no to that. It should be easy to backport the support into your current kernel, it's just a few commits and there hasn't been much development in this area of the code. Can you take a look at doing that please? That option hadn't crossed my mind yet, I'll look into it. More important than that: Since this chip powers the IO banks, we need it for our own products, and hence it has to work (also) on the current 3.15 kernel. Using APIs from 3.18 wouold render the driver useless to ourselves. This is just not at all important upstream, sorry. The kernel moves on and internal APIs within the kernel move on so it is expected that code used in production won't be the latest and greatest upstream code. I realize that, but then the result would be that I'll stop working on getting the driver into mainline and force customers to use a patch or use our fork of linux. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/04/2014 12:34 PM, Mark Brown wrote: On Tue, Nov 04, 2014 at 09:55:14AM +0100, Mike Looijmans wrote: On 11/03/2014 06:38 PM, Mike Looijmans wrote: You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say no to that. It should be easy to backport the support into your current kernel, it's just a few commits and there hasn't been much development in this area of the code. Can you take a look at doing that please? I can cherry-pick about 4 commits to get the updated core into my 3.15 tree. I still need help with one thing that isn't clear to me though. The DT is parsed when calling regulator_register. But then how do I fetch my private settings in there BEFORE the regulator gets enabled? The feedback resistors and regulator mode must be set to the correct board before the output is enabled, otherwise it may damage the chip and its periferals. The only two drivers using the regulators_node (tps65217 and isl9305.c) don't have any private values in the DT. M. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Tue, Nov 04, 2014 at 02:35:50PM +0100, Mike Looijmans wrote: I still need help with one thing that isn't clear to me though. The DT is parsed when calling regulator_register. But then how do I fetch my private settings in there BEFORE the regulator gets enabled? The feedback resistors and regulator mode must be set to the correct board before the output is enabled, otherwise it may damage the chip and its periferals. Add a callback for this. Javier and/or Krzysztof were looking at this for some other stuff, though I think they were intending to add core functionality for their specific feature. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 3-11-2014 16:10, Mark Brown wrote: On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: On 11/03/2014 01:09 PM, Mark Brown wrote: No function calls, just use regulators_node. What is unclear about the functionality? I don't understand what you mean by "regulators_node". "grep -R regulators_node *" in the kernel source tree returns no results, nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say "no" to that. -- Mike Looijmans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: > On 11/03/2014 01:09 PM, Mark Brown wrote: > >No function calls, just use regulators_node. What is unclear about the > >functionality? > I don't understand what you mean by "regulators_node". > "grep -R regulators_node *" in the kernel source tree returns no results, > nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/03/2014 01:09 PM, Mark Brown wrote:
On Mon, Nov 03, 2014 at 09:10:08AM +0100, Mike Looijmans wrote:
On 10/30/2014 05:51 PM, Mark Brown wrote:
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I've been reworking the driver, but this is the only feedback comment I
didn't quite understand. What is it that I'm expected to do here? Probably
just the name of the method I'm supposed to call here would be enough.
No function calls, just use regulators_node. What is unclear about the
functionality?
I don't understand what you mean by "regulators_node".
"grep -R regulators_node *" in the kernel source tree returns no results, nor
does http://lxr.free-electrons.com/ident?i=regulators_node
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Mon, Nov 03, 2014 at 09:10:08AM +0100, Mike Looijmans wrote:
> On 10/30/2014 05:51 PM, Mark Brown wrote:
> >>+ np_child = of_get_child_by_name(np_regulators,
> >>+ ltc3562_regulators[i].name);
> >>+ if (np_child == NULL) {
> >Use the core support for looking up constraints please - set
> >regulators_node and so on.
> I've been reworking the driver, but this is the only feedback comment I
> didn't quite understand. What is it that I'm expected to do here? Probably
> just the name of the method I'm supposed to call here would be enough.
No function calls, just use regulators_node. What is unclear about the
functionality?
signature.asc
Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 10/30/2014 05:51 PM, Mark Brown wrote:
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
+ np = of_node_get(i2c->dev.of_node);
+ np_regulators = of_get_child_by_name(np, "regulators");
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I've been reworking the driver, but this is the only feedback comment I didn't
quite understand. What is it that I'm expected to do here? Probably just the
name of the method I'm supposed to call here would be enough.
The rest of your feedback I've processed and tested the results.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 10/30/2014 05:51 PM, Mark Brown wrote:
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
+ np = of_node_get(i2c-dev.of_node);
+ np_regulators = of_get_child_by_name(np, regulators);
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I've been reworking the driver, but this is the only feedback comment I didn't
quite understand. What is it that I'm expected to do here? Probably just the
name of the method I'm supposed to call here would be enough.
The rest of your feedback I've processed and tested the results.
Mike.
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Mon, Nov 03, 2014 at 09:10:08AM +0100, Mike Looijmans wrote:
On 10/30/2014 05:51 PM, Mark Brown wrote:
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I've been reworking the driver, but this is the only feedback comment I
didn't quite understand. What is it that I'm expected to do here? Probably
just the name of the method I'm supposed to call here would be enough.
No function calls, just use regulators_node. What is unclear about the
functionality?
signature.asc
Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 11/03/2014 01:09 PM, Mark Brown wrote:
On Mon, Nov 03, 2014 at 09:10:08AM +0100, Mike Looijmans wrote:
On 10/30/2014 05:51 PM, Mark Brown wrote:
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I've been reworking the driver, but this is the only feedback comment I
didn't quite understand. What is it that I'm expected to do here? Probably
just the name of the method I'm supposed to call here would be enough.
No function calls, just use regulators_node. What is unclear about the
functionality?
I don't understand what you mean by regulators_node.
grep -R regulators_node * in the kernel source tree returns no results, nor
does http://lxr.free-electrons.com/ident?i=regulators_node
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: On 11/03/2014 01:09 PM, Mark Brown wrote: No function calls, just use regulators_node. What is unclear about the functionality? I don't understand what you mean by regulators_node. grep -R regulators_node * in the kernel source tree returns no results, nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 3-11-2014 16:10, Mark Brown wrote: On Mon, Nov 03, 2014 at 03:48:56PM +0100, Mike Looijmans wrote: On 11/03/2014 01:09 PM, Mark Brown wrote: No function calls, just use regulators_node. What is unclear about the functionality? I don't understand what you mean by regulators_node. grep -R regulators_node * in the kernel source tree returns no results, nor does http://lxr.free-electrons.com/ident?i=regulators_node You need to develop against current versions of the kernel, this is something that was merged into Linus' tree during the merge window. Is this an absolute show-stopper for you? With some effort I could move from our current 3.15 to 3.17, but even that wouldn't be recent enough then. I can justify spending a few days on getting the driver integrated into mainline, even if the initial version cost less than that; but moving everything to mainline is going to take weeks and the boss is definitely going to say no to that. -- Mike Looijmans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Fri, Oct 31, 2014 at 03:07:57PM +0100, Mike Looijmans wrote: > On 30-10-2014 17:51, Mark Brown wrote: > >This appears to be reimplementing regmap (including a cache). Please > >use that instead. Pretty much the entire driver could then be replaced > >with the regmap helpers, none of the operations look like they'd be > >needed, and you'd get the regmap diagnostic infrastructure. > The chip doesn't have an I2C register map, it uses "commands". > It does not support read transactions at all, it will NACK those. The first > byte contains a bit mask that tells which outputs are to be configured and > in what mode, the next is the enable bit and setpoint value. The first byte > already contains data, it's not just an address. If that's the case the code is really rather unclear about what it's doing - the use of "reg" for what's being written doesn't help, nor does the fact that what looks like a cache is being kept. The code should either use regmap or make it clear why that doesn't fit well. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 30-10-2014 17:51, Mark Brown wrote:
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix "lltc" to devicetree properties. Use the same property names
as the ltc3589 driver. Remove default-voltage property. Use
devm_register_regulator.
As covered in SubmittingPatches things like this should be after ---.
+Required properties:
+- compatible: "ltc3562"
This needs a vendor in the compatible string.
Will do.
+Required child node:
+- regulators: Contains four regulator child nodes R400B, R600B, R400A, R600A,
+ specifying the initialization data as documented in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
All regulator child nodes should be optional.
+ R600A_reg: R600A {
+ regulator-name = "R600A";
Remove these regulator-names, this is for the name of the supplies on
the board not the regulator itself.
+static int ltc3562_write(struct i2c_client *i2c, u8 reg_a, u8 reg_b);
+static int ltc3562_dummy_write(struct i2c_client *i2c);
This appears to be reimplementing regmap (including a cache). Please
use that instead. Pretty much the entire driver could then be replaced
with the regmap helpers, none of the operations look like they'd be
needed, and you'd get the regmap diagnostic infrastructure.
The chip doesn't have an I2C register map, it uses "commands".
It does not support read transactions at all, it will NACK those. The
first byte contains a bit mask that tells which outputs are to be
configured and in what mode, the next is the enable bit and setpoint
value. The first byte already contains data, it's not just an address.
I would have used regmap if I thought it'd help (if only for the
diagnostics), but it simply doesn't fit here.
If you insist, I can probably get it to fit on regmap, but that would
still mean implementing some custom write method that translates between
some non-existing registry format and what the chip really wants.
+ np = of_node_get(i2c->dev.of_node);
+ np_regulators = of_get_child_by_name(np, "regulators");
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I'll dig into it, seems that there's more infrastructure here to use.
+static struct i2c_driver ltc3562_i2c_driver = {
+ .driver = {
+ .name = "LTC3562",
+ .owner = THIS_MODULE,
+ },
+ .probe= ltc3562_i2c_probe,
+ .id_table = ltc3562_i2c_id,
+};
You need to supply an of_match_table too.
Hmm, that would explain why I couldn't get it to work using
"lltc,ltc3562" during our first attempts at the driver.
--
Mike Looijmans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On 30-10-2014 17:51, Mark Brown wrote:
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix lltc to devicetree properties. Use the same property names
as the ltc3589 driver. Remove default-voltage property. Use
devm_register_regulator.
As covered in SubmittingPatches things like this should be after ---.
+Required properties:
+- compatible: ltc3562
This needs a vendor in the compatible string.
Will do.
+Required child node:
+- regulators: Contains four regulator child nodes R400B, R600B, R400A, R600A,
+ specifying the initialization data as documented in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
All regulator child nodes should be optional.
+ R600A_reg: R600A {
+ regulator-name = R600A;
Remove these regulator-names, this is for the name of the supplies on
the board not the regulator itself.
+static int ltc3562_write(struct i2c_client *i2c, u8 reg_a, u8 reg_b);
+static int ltc3562_dummy_write(struct i2c_client *i2c);
This appears to be reimplementing regmap (including a cache). Please
use that instead. Pretty much the entire driver could then be replaced
with the regmap helpers, none of the operations look like they'd be
needed, and you'd get the regmap diagnostic infrastructure.
The chip doesn't have an I2C register map, it uses commands.
It does not support read transactions at all, it will NACK those. The
first byte contains a bit mask that tells which outputs are to be
configured and in what mode, the next is the enable bit and setpoint
value. The first byte already contains data, it's not just an address.
I would have used regmap if I thought it'd help (if only for the
diagnostics), but it simply doesn't fit here.
If you insist, I can probably get it to fit on regmap, but that would
still mean implementing some custom write method that translates between
some non-existing registry format and what the chip really wants.
+ np = of_node_get(i2c-dev.of_node);
+ np_regulators = of_get_child_by_name(np, regulators);
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
I'll dig into it, seems that there's more infrastructure here to use.
+static struct i2c_driver ltc3562_i2c_driver = {
+ .driver = {
+ .name = LTC3562,
+ .owner = THIS_MODULE,
+ },
+ .probe= ltc3562_i2c_probe,
+ .id_table = ltc3562_i2c_id,
+};
You need to supply an of_match_table too.
Hmm, that would explain why I couldn't get it to work using
lltc,ltc3562 during our first attempts at the driver.
--
Mike Looijmans
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Fri, Oct 31, 2014 at 03:07:57PM +0100, Mike Looijmans wrote: On 30-10-2014 17:51, Mark Brown wrote: This appears to be reimplementing regmap (including a cache). Please use that instead. Pretty much the entire driver could then be replaced with the regmap helpers, none of the operations look like they'd be needed, and you'd get the regmap diagnostic infrastructure. The chip doesn't have an I2C register map, it uses commands. It does not support read transactions at all, it will NACK those. The first byte contains a bit mask that tells which outputs are to be configured and in what mode, the next is the enable bit and setpoint value. The first byte already contains data, it's not just an address. If that's the case the code is really rather unclear about what it's doing - the use of reg for what's being written doesn't help, nor does the fact that what looks like a cache is being kept. The code should either use regmap or make it clear why that doesn't fit well. signature.asc Description: Digital signature
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
> The ltc3562 is an I2C controlled regulator supporting 4 independent
> outputs.
>
> v2: Prefix "lltc" to devicetree properties. Use the same property names
> as the ltc3589 driver. Remove default-voltage property. Use
> devm_register_regulator.
As covered in SubmittingPatches things like this should be after ---.
> +Required properties:
> +- compatible: "ltc3562"
This needs a vendor in the compatible string.
> +Required child node:
> +- regulators: Contains four regulator child nodes R400B, R600B, R400A, R600A,
> + specifying the initialization data as documented in
> + Documentation/devicetree/bindings/regulator/regulator.txt.
All regulator child nodes should be optional.
> + R600A_reg: R600A {
> + regulator-name = "R600A";
Remove these regulator-names, this is for the name of the supplies on
the board not the regulator itself.
> +static int ltc3562_write(struct i2c_client *i2c, u8 reg_a, u8 reg_b);
> +static int ltc3562_dummy_write(struct i2c_client *i2c);
This appears to be reimplementing regmap (including a cache). Please
use that instead. Pretty much the entire driver could then be replaced
with the regmap helpers, none of the operations look like they'd be
needed, and you'd get the regmap diagnostic infrastructure.
> + np = of_node_get(i2c->dev.of_node);
> + np_regulators = of_get_child_by_name(np, "regulators");
> + np_child = of_get_child_by_name(np_regulators,
> + ltc3562_regulators[i].name);
> + if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
> +static struct i2c_driver ltc3562_i2c_driver = {
> + .driver = {
> + .name = "LTC3562",
> + .owner = THIS_MODULE,
> + },
> + .probe= ltc3562_i2c_probe,
> + .id_table = ltc3562_i2c_id,
> +};
You need to supply an of_match_table too.
signature.asc
Description: Digital signature
[PATCH v2] Add ltc3562 voltage regulator driver
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix "lltc" to devicetree properties. Use the same property names
as the ltc3589 driver. Remove default-voltage property. Use
devm_register_regulator.
Signed-off-by: Mike Looijmans
---
.../devicetree/bindings/regulator/ltc3562.txt | 56
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/ltc3562.c| 337
4 files changed, 401 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/ltc3562.txt
create mode 100644 drivers/regulator/ltc3562.c
diff --git a/Documentation/devicetree/bindings/regulator/ltc3562.txt
b/Documentation/devicetree/bindings/regulator/ltc3562.txt
new file mode 100644
index 000..81ed923
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ltc3562.txt
@@ -0,0 +1,56 @@
+Linear Technology LTC3562 I2C controlled 4-output regulator
+
+Required properties:
+- compatible: "ltc3562"
+- reg: I2C slave address
+
+Required child node:
+- regulators: Contains four regulator child nodes R400B, R600B, R400A, R600A,
+ specifying the initialization data as documented in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators. The
+nodes for R400A and R600A additionally need to specify the resistor values of
+their external feedback voltage dividers:
+
+Required properties (A-type only):
+- lltc,fb-voltage-divider: An array of two integers containing the resistor
+ values R1 and R2 of the feedback voltage divider. Both values must remain in
+ the range 1..1000, only their quotient matters.
+
+Example:
+
+ ltc3562: ltc3562@65 {
+ compatible = "ltc3562";
+ reg = <0x65>;
+ regulators {
+ R400B_reg: R400B {
+ regulator-name = "R400B";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ R600B_reg: R600B {
+ regulator-name = "R600B";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ R400A_reg: R400A {
+ regulator-name = "R400A";
+ regulator-min-microvolt = <425000>;
+ regulator-max-microvolt = <800>;
+ lltc,fb-voltage-divider = <1, 1>;
+ };
+ R600A_reg: R600A {
+ regulator-name = "R600A";
+ regulator-min-microvolt = <425000>;
+ regulator-max-microvolt = <180>;
+ lltc,fb-voltage-divider = <316, 100>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 55d7b7b..4012601 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -300,6 +300,13 @@ config REGULATOR_LP8788
help
This driver supports LP8788 voltage regulator chip.
+config REGULATOR_LTC3562
+ tristate "LCT3562 quad output voltage regulator"
+ depends on I2C
+ help
+ This enables support for the LCT3562 quad output voltage regulator
+ controlled via I2C.
+
config REGULATOR_LTC3589
tristate "LTC3589 8-output voltage regulator"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1029ed3..9a15146 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
+obj-$(CONFIG_REGULATOR_LTC3562) += ltc3562.o
obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
obj-$(CONFIG_REGULATOR_MAX14577) += max14577.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
diff --git a/drivers/regulator/ltc3562.c b/drivers/regulator/ltc3562.c
new file mode 100644
index 000..b73eee7
--- /dev/null
+++ b/drivers/regulator/ltc3562.c
@@ -0,0 +1,337 @@
+/*
+ * Regulator driver for Linear Technology LTC3562
+ *
+ * Copyright (C) 2014 Topic Embedded Products
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under
[PATCH v2] Add ltc3562 voltage regulator driver
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix lltc to devicetree properties. Use the same property names
as the ltc3589 driver. Remove default-voltage property. Use
devm_register_regulator.
Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
.../devicetree/bindings/regulator/ltc3562.txt | 56
drivers/regulator/Kconfig |7 +
drivers/regulator/Makefile |1 +
drivers/regulator/ltc3562.c| 337
4 files changed, 401 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/ltc3562.txt
create mode 100644 drivers/regulator/ltc3562.c
diff --git a/Documentation/devicetree/bindings/regulator/ltc3562.txt
b/Documentation/devicetree/bindings/regulator/ltc3562.txt
new file mode 100644
index 000..81ed923
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ltc3562.txt
@@ -0,0 +1,56 @@
+Linear Technology LTC3562 I2C controlled 4-output regulator
+
+Required properties:
+- compatible: ltc3562
+- reg: I2C slave address
+
+Required child node:
+- regulators: Contains four regulator child nodes R400B, R600B, R400A, R600A,
+ specifying the initialization data as documented in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators. The
+nodes for R400A and R600A additionally need to specify the resistor values of
+their external feedback voltage dividers:
+
+Required properties (A-type only):
+- lltc,fb-voltage-divider: An array of two integers containing the resistor
+ values R1 and R2 of the feedback voltage divider. Both values must remain in
+ the range 1..1000, only their quotient matters.
+
+Example:
+
+ ltc3562: ltc3562@65 {
+ compatible = ltc3562;
+ reg = 0x65;
+ regulators {
+ R400B_reg: R400B {
+ regulator-name = R400B;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ R600B_reg: R600B {
+ regulator-name = R600B;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ R400A_reg: R400A {
+ regulator-name = R400A;
+ regulator-min-microvolt = 425000;
+ regulator-max-microvolt = 800;
+ lltc,fb-voltage-divider = 1, 1;
+ };
+ R600A_reg: R600A {
+ regulator-name = R600A;
+ regulator-min-microvolt = 425000;
+ regulator-max-microvolt = 180;
+ lltc,fb-voltage-divider = 316, 100;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 55d7b7b..4012601 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -300,6 +300,13 @@ config REGULATOR_LP8788
help
This driver supports LP8788 voltage regulator chip.
+config REGULATOR_LTC3562
+ tristate LCT3562 quad output voltage regulator
+ depends on I2C
+ help
+ This enables support for the LCT3562 quad output voltage regulator
+ controlled via I2C.
+
config REGULATOR_LTC3589
tristate LTC3589 8-output voltage regulator
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1029ed3..9a15146 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
+obj-$(CONFIG_REGULATOR_LTC3562) += ltc3562.o
obj-$(CONFIG_REGULATOR_LTC3589) += ltc3589.o
obj-$(CONFIG_REGULATOR_MAX14577) += max14577.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
diff --git a/drivers/regulator/ltc3562.c b/drivers/regulator/ltc3562.c
new file mode 100644
index 000..b73eee7
--- /dev/null
+++ b/drivers/regulator/ltc3562.c
@@ -0,0 +1,337 @@
+/*
+ * Regulator driver for Linear Technology LTC3562
+ *
+ * Copyright (C) 2014 Topic Embedded Products
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the
Re: [PATCH v2] Add ltc3562 voltage regulator driver
On Thu, Oct 30, 2014 at 12:26:55PM +0100, Mike Looijmans wrote:
The ltc3562 is an I2C controlled regulator supporting 4 independent
outputs.
v2: Prefix lltc to devicetree properties. Use the same property names
as the ltc3589 driver. Remove default-voltage property. Use
devm_register_regulator.
As covered in SubmittingPatches things like this should be after ---.
+Required properties:
+- compatible: ltc3562
This needs a vendor in the compatible string.
+Required child node:
+- regulators: Contains four regulator child nodes R400B, R600B, R400A, R600A,
+ specifying the initialization data as documented in
+ Documentation/devicetree/bindings/regulator/regulator.txt.
All regulator child nodes should be optional.
+ R600A_reg: R600A {
+ regulator-name = R600A;
Remove these regulator-names, this is for the name of the supplies on
the board not the regulator itself.
+static int ltc3562_write(struct i2c_client *i2c, u8 reg_a, u8 reg_b);
+static int ltc3562_dummy_write(struct i2c_client *i2c);
This appears to be reimplementing regmap (including a cache). Please
use that instead. Pretty much the entire driver could then be replaced
with the regmap helpers, none of the operations look like they'd be
needed, and you'd get the regmap diagnostic infrastructure.
+ np = of_node_get(i2c-dev.of_node);
+ np_regulators = of_get_child_by_name(np, regulators);
+ np_child = of_get_child_by_name(np_regulators,
+ ltc3562_regulators[i].name);
+ if (np_child == NULL) {
Use the core support for looking up constraints please - set
regulators_node and so on.
+static struct i2c_driver ltc3562_i2c_driver = {
+ .driver = {
+ .name = LTC3562,
+ .owner = THIS_MODULE,
+ },
+ .probe= ltc3562_i2c_probe,
+ .id_table = ltc3562_i2c_id,
+};
You need to supply an of_match_table too.
signature.asc
Description: Digital signature
