On 14/05/12 19:06, Mark Brown wrote:
On Mon, May 14, 2012 at 06:39:00PM +0100, Lee Jones wrote:
Okay, so can you suggest a way to marry up the constraints found in DT to
the remainder of the settings found in the driver without pointlessly
applying it all to the DT itself (which is was some of
On Mon, May 14, 2012 at 06:39:00PM +0100, Lee Jones wrote:
> Okay, so can you suggest a way to marry up the constraints found in DT to
> the remainder of the settings found in the driver without pointlessly
> applying it all to the DT itself (which is was some of the other drives
> have done)?
Th
On Mon, May 14, 2012 at 04:49:21PM +0100, Lee Jones wrote:
> >You should be using of_regulator_match() for this (I think it's supposed
> >to do an equivalent job...) rather than open coding.
> I've ripped this out completely and the code appears to continue be
> fully functional. Happy days! :)
On Monday 14 May 2012, Lee Jones wrote:
> > You should be using of_regulator_match() for this (I think it's supposed
> > to do an equivalent job...) rather than open coding.
>
> I've ripped this out completely and the code appears to continue be
> fully functional. Happy days! :)
Ok, very good!
On Mon, May 14, 2012 at 04:57:39PM +0100, Lee Jones wrote:
> >>pdata = dev_get_platdata(ab8500->dev);
> >>- if (!pdata) {
> >>- dev_err(&pdev->dev, "null pdata\n");
> >>+ if (!pdata&& !np) {
> >>+ dev_err(&pdev->dev, "null pdata and no device tree found\n");
> >>
pdata = dev_get_platdata(ab8500->dev);
- if (!pdata) {
- dev_err(&pdev->dev, "null pdata\n");
+ if (!pdata&& !np) {
+ dev_err(&pdev->dev, "null pdata and no device tree found\n");
return -EINVAL;
}
Neither should be mandato
Hi Mark,
Looking at this now.
+static __devinit int
+ab8500_regulator_of_probe(struct platform_device *pdev, struct device_node *np)
+{
+ struct regulator_init_data *ab8500_regulator;
+ struct device_node *child;
+ int err, value, i, id = 0;
+
+ /* Initialise regulator r
On 08/05/12 15:57, Mark Brown wrote:
On Tue, May 08, 2012 at 03:54:09PM +0100, Lee Jones wrote:
On 08/05/12 14:34, Mark Brown wrote:
Looking at the usage here it looks like most of this stuff shouldn't be
there even with non-DT stuff, we probably don't want to add DT bindings
for those bits.A
On Tue, May 08, 2012 at 03:54:09PM +0100, Lee Jones wrote:
> On 08/05/12 14:34, Mark Brown wrote:
> >Looking at the usage here it looks like most of this stuff shouldn't be
> >there even with non-DT stuff, we probably don't want to add DT bindings
> >for those bits.All the voltage setting is not a
On 08/05/12 14:34, Mark Brown wrote:
On Tue, May 08, 2012 at 01:38:18PM +0100, Lee Jones wrote:
On 08/05/12 13:19, Mark Brown wrote:
It's been kicking around for review for a little while longer than that
(it was waiting for review while Rhyland was on holiday), and in any
case half the reaso
On Tue, May 08, 2012 at 02:36:46PM +, Arnd Bergmann wrote:
> Right, which is what the driver has done since 79568b9412 "regulator:
> initialization for ab8500 regulators" with your ack, so we decided not
> to change that and simply move the init data from platform code
> to the device tree.
Y
On Tuesday 08 May 2012, Mark Brown wrote:
> On Tue, May 08, 2012 at 01:48:14PM +, Arnd Bergmann wrote:
> > On Tuesday 08 May 2012, Lee Jones wrote:
>
> > > I did run this past Arnd before writing the code and he agreed that this
> > > would be suitable; however, if you know of a better way in
On Tue, May 08, 2012 at 01:48:14PM +, Arnd Bergmann wrote:
> On Tuesday 08 May 2012, Lee Jones wrote:
> > I did run this past Arnd before writing the code and he agreed that this
> > would be suitable; however, if you know of a better way in which I can
> > do this, I'd be pleased to hear of
On Tuesday 08 May 2012, Lee Jones wrote:
> This piece of code plucks pre-defined initialisation values and from the
> Device Tree and uses them to set-up regulator related registers on the
> u8500. See 'struct ab8500_regulator_reg_init ab8500_regulator_reg_init'
> in arch/arm/mach-ux500/board-mo
On Tue, May 08, 2012 at 01:38:18PM +0100, Lee Jones wrote:
> On 08/05/12 13:19, Mark Brown wrote:
> >It's been kicking around for review for a little while longer than that
> >(it was waiting for review while Rhyland was on holiday), and in any
> >case half the reason for adding infrastructure is
On 08/05/12 13:19, Mark Brown wrote:
On Tue, May 08, 2012 at 01:04:49PM +0100, Lee Jones wrote:
On 07/05/12 18:08, Mark Brown wrote:
You should be using of_regulator_match() for this (I think it's supposed
to do an equivalent job...) rather than open coding.
of_regulator_match() didn't exi
On Tue, May 08, 2012 at 01:04:49PM +0100, Lee Jones wrote:
> On 07/05/12 18:08, Mark Brown wrote:
> >You should be using of_regulator_match() for this (I think it's supposed
> >to do an equivalent job...) rather than open coding.
> of_regulator_match() didn't exist when I wrote this. In fact, it
On 07/05/12 18:08, Mark Brown wrote:
On Fri, May 04, 2012 at 07:23:24PM +0100, Lee Jones wrote:
Once again, please try to make sure your changelog matches the
subsystem. This also isn't consistent with the other regulator change
further up the series :(
You've also not included any binding doc
On Fri, May 04, 2012 at 07:23:24PM +0100, Lee Jones wrote:
Once again, please try to make sure your changelog matches the
subsystem. This also isn't consistent with the other regulator change
further up the series :(
You've also not included any binding documenation here, binding
documentation s
Here we setup the ab8500 regulator driver for DT. We first do
this in the normal way, by providing a match structure during
initialisation, but then we provide information so that
whilst probing we can use existing data structures to do DT
look-ups. We do that by embedding DT property names into
ab
20 matches
Mail list logo
