RE: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
Hi Paul, I will not be able to make these changes to support modularity any more. Although the support.opensou...@diasemi.com e-mail address for Support is still working, I will not be able to review your patches if you were to re-send them again. Regards, Stephen On 07 December 2018 20:30, Paul Gortmaker > > On 03 December 2018 04:23, Paul Gortmaker wrote: > > > Subject: [PATCH v2 00/22] mfd: demodularization of non-modular drivers > > > > > > [v1 --> v2: add some more commits as requested by Lee (MFD maintainer), > > > update the 00/NN text; re-do build and link testing on new linux-next. ] > > > > > > This group of MFD drivers are all controlled by "bool" Kconfig settings, > > > but contain various amounts of largely pointless uses of infrastructure > > > related to modular operations, even though they can't be built modular. > > > > > > We can easily remove/replace all of it. We are trying to make driver > > > code consistent with the Makefiles/Kconfigs that control them. > > > > For the DA9052 and DA9055, changes: > > > > - drivers/mfd/da9052-core.c | 11 --- > > - drivers/mfd/da9052-i2c.c | 22 ++--- > > - drivers/mfd/da9052-irq.c | 1 - > > - drivers/mfd/da9052-spi.c | 22 ++--- > > - drivers/mfd/da9055-core.c | 13 ++--- > > - drivers/mfd/da9055-i2c.c | 24 ++- > > > > The responsibility can fall back to Dialog for these changes. We will > > submit Kconfig patches for these and make them explicitly non-modular. > > This will remove the ambiguity caused by the Kconfig bool options. > > Just FYI, I dropped the diasemi commits from my v3 send. > > https://lore.kernel.org/lkml/1544213465-16259-1-git-send-email- > paul.gortma...@windriver.com/ > > Thanks for taking on the modular conversions.
RE: [PATCH] mfd: da9063: remove now unused platform_data
Hiya Wolfram, On 22 July 2019 19:26, Wolfram Sang wrote: > To: linux-kernel@vger.kernel.org > Subject: [PATCH] mfd: da9063: remove now unused platform_data > > All preparational patches have been applied, we can now remove the > include file for platform_data. Yiha! > > Signed-off-by: Wolfram Sang > --- > include/Kbuild | 1 - > include/linux/mfd/da9063/pdata.h | 60 > 2 files changed, 61 deletions(-) > delete mode 100644 include/linux/mfd/da9063/pdata.h Acked-by: Steve Twiss Regards, Steve
RE: [PATCH] regulator: da9062: Simplify the code iterating all regulators
On 11 July 2019 12:47, Axel Lin wrote: > To: Steve Twiss; Support Opensource; Liam Girdwood; > linux-kernel@vger.kernel.org > Cc: Axel Lin > Subject: [PATCH] regulator: da9062: Simplify the code iterating all regulators > > It's more straightforward to use for statement here. Thanks Axel, Acked-by: Steve Twiss Regards, Steve
RE: [PATCH] mfd: da9063: occupy second I2C address, too
On 21 June 2019 11:10 Wolfram Sang wrote: > Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too > > > For what it's worth, maybe consider adding a dev_warn attached to the return > > of devm_i2c_new_dummy_device? > > I am in the middle of some API changes. Once those are over, I want to > think about such warnings as a second step. I'd rather have them in the > core than in each and every driver. But this needs more thinking... No problem.
RE: [PATCH] mfd: da9063: occupy second I2C address, too
Hi Wolfram, On 20 June 2019 10:21, Wolfram Sang wrote: > Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too > > > Is this a safety clause? What I mean is, shouldn't the hardware design make > > sure there are not two devices located on the same I2C bus with the same > > slave > > address? > > It is more about preventing userspace to accidently access this address, > and thus the registers behind it. For what it's worth, maybe consider adding a dev_warn attached to the return of devm_i2c_new_dummy_device? Regards, Steve My apologies again for accidentally splitting your original e-mail thread on this: - https://lore.kernel.org/lkml/20190619171806.30116-1-wsa+rene...@sang-engineering.com/
RE: [PATCH] mfd: da9063: occupy second I2C address, too
On 20 June 2019 13:29, Lee Jones wrote: > Subject: Re: [PATCH] mfd: da9063: occupy second I2C address, too > > Why isn't this reply attached (threaded) to the patch. My apologies. It wasn't my intention to split Wolfram's original e-mail thread. I don't usually reply using the mailto: link from lore when creating e-mails. Outlook mustn't support the In-Reply-To header. I'll figure out a different way to reply in future. > Is your mailer broken? It's Windows
Re: [PATCH] mfd: da9063: occupy second I2C address, too
(resend because the e-mail client added HTML formatting to my last reply) Hi Wolfram, On Wed, 19 Jun 2019 19:18:06, Wolfram Sang wrote: > Subject: [PATCH] mfd: da9063: occupy second I2C address, too > > Even though we don't use it yet, we should mark the second I2C address > this device is listening to as used. Sure. There is a second method for accessing higher pages of registers. The DA9063 Datasheet Revision 2.2, 12-Mar-2019, page 96, says this: In 2-WIRE operation, the DA9063 offers an alternative method to access register pages 2 and 3. These pages can be accessed directly by incrementing the device address by one (default read address 0xB3; write address 0xB2). This removes the need to write to the page register before access to pages 2 and 3, thus reducing the traffic on the 2-WIRE bus. Is this a safety clause? What I mean is, shouldn't the hardware design make sure there are not two devices located on the same I2C bus with the same slave address? Regards, Steve > Signed-off-by: Wolfram Sang > Reviewed-by: Peter Rosin > Reviewed-by: Bartosz Golaszewski > Reviewed-by: Kieran Bingham > --- > drivers/mfd/da9063-i2c.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c > index 455de74c0dd2..2133b09f6e7a 100644 > --- a/drivers/mfd/da9063-i2c.c > +++ b/drivers/mfd/da9063-i2c.c > @@ -221,6 +221,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c, > return ret; > } > > + devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter, i2c->addr + 1); > + > return da9063_device_init(da9063, i2c->irq); > } > > -- > 2.20.1
[PATCH V4] regulator: da9061/62: Adjust LDO voltage selection minimum value
From: Felix Riemann According to the DA9061 and DA9062 datasheets the LDO voltage selection registers have a lower value of 0x02. This applies to voltage registers VLDO1_A, VLDO2_A, VLDO3_A and VLDO4_A. This linear offset of 0x02 was previously not observed by the driver, causing the LDO output voltage to be systematically lower by two steps (= 0.1V). This patch fixes the minimum linear selector offset by setting it to a value of 2 and increases the n_voltages by the same amount allowing voltages in the range 0x02 -> 0.9V to 0x38 -> 3.6V to be correctly selected. Also fixes an incorrect calculaton for the n_voltages value in the regulator LDO2. These fixes effect all LDO regulators for DA9061 and DA9062. Acked-by: Steve Twiss Tested-by: Steve Twiss Signed-off-by: Felix Riemann Signed-off-by: Steve Twiss --- Patch history v2 - Fix whitespace problems, slight refactor and correct n_voltages calc v3 - Addition of missing signed-off-by tag from sender v4 - Correct order for Signed-off-by tags in commit message Regards, Steve drivers/regulator/da9062-regulator.c | 40 +--- include/linux/mfd/da9062/registers.h | 3 +++ 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c index a02e048..1cadaae 100644 --- a/drivers/regulator/da9062-regulator.c +++ b/drivers/regulator/da9062-regulator.c @@ -493,12 +493,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO1_CONT, .desc.enable_mask = DA9062AA_LDO1_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO1_A, .desc.vsel_mask = DA9062AA_VLDO1_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO1_A, __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -525,12 +526,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (600))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO2_CONT, .desc.enable_mask = DA9062AA_LDO2_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO2_A, .desc.vsel_mask = DA9062AA_VLDO2_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO2_A, __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -557,12 +559,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO3_CONT, .desc.enable_mask = DA9062AA_LDO3_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO3_A, .desc.vsel_mask = DA9062AA_VLDO3_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO3_A, __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -589,12 +592,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO4_CONT, .desc.enable_mask = DA9062AA_LDO4_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO4_A, .desc.vsel_mask = DA9062AA_VLDO4_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO4_A,
[PATCH V3] regulator: da9061/62: Adjust LDO voltage selection minimum value
From: Felix Riemann According to the DA9061 and DA9062 datasheets the LDO voltage selection registers have a lower value of 0x02. This applies to voltage registers VLDO1_A, VLDO2_A, VLDO3_A and VLDO4_A. This linear offset of 0x02 was previously not observed by the driver, causing the LDO output voltage to be systematically lower by two steps (= 0.1V). This patch fixes the minimum linear selector offset by setting it to a value of 2 and increases the n_voltages by the same amount allowing voltages in the range 0x02 -> 0.9V to 0x38 -> 3.6V to be correctly selected. Also fixes an incorrect calculaton for the n_voltages value in the regulator LDO2. These fixes effect all LDO regulators for DA9061 and DA9062. Acked-by: Steve Twiss Tested-by: Steve Twiss Signed-off-by: Steve Twiss Signed-off-by: Felix Riemann --- Hi Mark, I've added my signed-off tag to the commit patch of V3. Regards, Steve drivers/regulator/da9062-regulator.c | 40 +--- include/linux/mfd/da9062/registers.h | 3 +++ 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c index a02e048..1cadaae 100644 --- a/drivers/regulator/da9062-regulator.c +++ b/drivers/regulator/da9062-regulator.c @@ -493,12 +493,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO1_CONT, .desc.enable_mask = DA9062AA_LDO1_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO1_A, .desc.vsel_mask = DA9062AA_VLDO1_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO1_A, __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -525,12 +526,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (600))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO2_CONT, .desc.enable_mask = DA9062AA_LDO2_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO2_A, .desc.vsel_mask = DA9062AA_VLDO2_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO2_A, __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -557,12 +559,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO3_CONT, .desc.enable_mask = DA9062AA_LDO3_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO3_A, .desc.vsel_mask = DA9062AA_VLDO3_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO3_A, __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -589,12 +592,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO4_CONT, .desc.enable_mask = DA9062AA_LDO4_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO4_A, .desc.vsel_mask = DA9062AA_VLDO4_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO4_A, __builtin_ffs((int)DA9062AA_LDO4_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -7
[PATCH V2] regulator: da9061/62: Adjust LDO voltage selection minimum value
From: Felix Riemann According to the DA9061 and DA9062 datasheets the LDO voltage selection registers have a lower value of 0x02. This applies to voltage registers VLDO1_A, VLDO2_A, VLDO3_A and VLDO4_A. This linear offset of 0x02 was previously not observed by the driver, causing the LDO output voltage to be systematically lower by two steps (= 0.1V). This patch fixes the minimum linear selector offset by setting it to a value of 2 and increases the n_voltages by the same amount allowing voltages in the range 0x02 -> 0.9V to 0x38 -> 3.6V to be correctly selected. Also fixes an incorrect calculaton for the n_voltages value in the regulator LDO2. These fixes effect all LDO regulators for DA9061 and DA9062. Acked-by: Steve Twiss Tested-by: Steve Twiss Signed-off-by: Felix Riemann --- Hi Felix, I have taken your previous patch, fixed the whitespace like we discussed and updated the commit message to add more details. Also, I have simplified your original patch slightly by using a single define in the include file instead of repeating the same value for each LDO[1-4]. Finally, I added a minor typo fix which I found when calculating the LDO2 n_voltages, there was a calculation of (3600-600)/50 instead of (3600-900)/50. I've finished my testing for DA9061 and DA9062 and so I've Acked your patch and added a Tested-by tag. If you are happy with those changes to your patch, I guess you can let the Maintainers take a look. Regards, Steve drivers/regulator/da9062-regulator.c | 40 +--- include/linux/mfd/da9062/registers.h | 3 +++ 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c index a02e048..1cadaae 100644 --- a/drivers/regulator/da9062-regulator.c +++ b/drivers/regulator/da9062-regulator.c @@ -493,12 +493,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO1_CONT, .desc.enable_mask = DA9062AA_LDO1_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO1_A, .desc.vsel_mask = DA9062AA_VLDO1_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO1_A, __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -525,12 +526,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (600))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO2_CONT, .desc.enable_mask = DA9062AA_LDO2_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO2_A, .desc.vsel_mask = DA9062AA_VLDO2_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO2_A, __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -557,12 +559,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 + + DA9062AA_VLDO_A_MIN_SEL, .desc.enable_reg = DA9062AA_LDO3_CONT, .desc.enable_mask = DA9062AA_LDO3_EN_MASK, .desc.vsel_reg = DA9062AA_VLDO3_A, .desc.vsel_mask = DA9062AA_VLDO3_A_MASK, - .desc.linear_min_sel = 0, + .desc.linear_min_sel = DA9062AA_VLDO_A_MIN_SEL, .sleep = REG_FIELD(DA9062AA_VLDO3_A, __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1, sizeof(unsigned int) * 8 - @@ -589,12 +592,13 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev, .desc.ops = &da9062_ldo_ops, .desc.min_uV = (900) * 1000, .desc.uV_step = (50) * 1000, - .desc.n_voltages = ((3600) - (900))/(50) + 1, + .desc.n_voltages = ((3600) - (900))/(50) + 1 +
RE: [PATCH] regulator: da9062: Adjust LDO voltage selection minimum value
Hi Felix, On 18 June 2019 12:08 Felix Riemann wrote: > Subject: AW: [PATCH] regulator: da9062: Adjust LDO voltage selection minimum > value > > Hi Steve, > > A colleague told me that he saw our mail server mix-up whitespaces in text > mails > before, although the copy that got relayed back to me looks okay. Is the patch > usable or should I try to resend it through another server? Yes there is a little bit of a white-space mix-up in both patches -- but I could see what was supposed to happen. I fixed those this morning and I've made a couple of suggestions. But before I send the patch back (for your approval) I am just making some changes to my tests so it picks up this change in future. No need to send it again, thank you. Once I've made certain it does what it is supposed to do, I will send for your review. Regards, Steve
RE: [PATCH] regulator: da9062: Adjust LDO voltage selection minimum value
Hi Felix, On 13 June 2019 14:02, Felix Riemann wrote: > Subject: [PATCH] regulator: da9062: Adjust LDO voltage selection minimum value > > According to the datasheet the LDO's voltage selection registers have > a minimum value of 0x2. This offset was not observed by the driver, > causing the LDO output being two steps (= 0.1V) lower than requested. > > Signed-off-by: Felix Riemann Uh. That looks right. But I want to take a closer look tomorrow along with my tests, which must pass this behaviour. Give me a day or two please. Regards, Steve
[PATCH] mfd: da9063: Fix OTP control register names to match datasheets for DA9063/63L
Mismatch between what is found in the Datasheets for DA9063 and DA9063L provided by Dialog Semiconductor, and the register names provided in the MFD registers file. The changes are for the OTP (one-time-programming) control registers. The two naming errors are OPT instead of OTP, and COUNT instead of CONT (i.e. control). Cc: Stable Signed-off-by: Steve Twiss --- include/linux/mfd/da9063/registers.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/mfd/da9063/registers.h b/include/linux/mfd/da9063/registers.h index 5d42859..844fc29 100644 --- a/include/linux/mfd/da9063/registers.h +++ b/include/linux/mfd/da9063/registers.h @@ -215,9 +215,9 @@ /* DA9063 Configuration registers */ /* OTP */ -#defineDA9063_REG_OPT_COUNT0x101 -#defineDA9063_REG_OPT_ADDR 0x102 -#defineDA9063_REG_OPT_DATA 0x103 +#defineDA9063_REG_OTP_CONT 0x101 +#defineDA9063_REG_OTP_ADDR 0x102 +#defineDA9063_REG_OTP_DATA 0x103 /* Customer Trim and Configuration */ #defineDA9063_REG_T_OFFSET 0x104 -- 1.9.3
RE: [PATCH 12/22] watchdog: da9063_wdt: Use 'dev' instead of dereferencing it repeatedly
Hi Guenter,
On 08 April 2019 20:39, Guenter Roeck:
> Subject: [PATCH 12/22] watchdog: da9063_wdt: Use 'dev' instead of
> dereferencing it repeatedly
>
> Introduce local variable 'struct device *dev' and use it instead of
> dereferencing it repeatedly.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> Cc: Support Opensource
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/da9063_wdt.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/da9063_wdt.c b/drivers/watchdog/da9063_wdt.c
> index 384dca16af8b..06eb9070203c 100644
> --- a/drivers/watchdog/da9063_wdt.c
> +++ b/drivers/watchdog/da9063_wdt.c
> @@ -188,17 +188,18 @@ static const struct watchdog_ops
> da9063_watchdog_ops = {
>
> static int da9063_wdt_probe(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> struct da9063 *da9063;
> struct watchdog_device *wdd;
>
> - if (!pdev->dev.parent)
> + if (!dev->parent)
> return -EINVAL;
None of my previous Acked e-mails in this patch set considered whether the
dev->parent was NULL. But this DA9063 driver does.
Logically, this is correct to check, but ... any thoughts?
Otherwise,
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH 11/22] watchdog: da9062_wdt: Use 'dev' instead of dereferencing it repeatedly
Hi Guenter, On 08 April 2019 20:39, Guenter Roeck wrote: > Subject: [PATCH 11/22] watchdog: da9062_wdt: Use 'dev' instead of > dereferencing it repeatedly > > Introduce local variable 'struct device *dev' and use it instead of > dereferencing it repeatedly. Also replace 'ret = func(); return ret;' > with 'return func();'. > > The conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the scripts > used to generate this commit log are available at > https://github.com/groeck/coccinelle-patches > > Cc: Support Opensource > Signed-off-by: Guenter Roeck Acked-by: Steve Twiss Thanks for that, Regards, Steve
RE: [PATCH 10/22] watchdog: da9055_wdt: Use 'dev' instead of dereferencing it repeatedly
On 08 April 2019 20:39, Guenter Roeck wrote: > Subject: [PATCH 10/22] watchdog: da9055_wdt: Use 'dev' instead of > dereferencing it repeatedly > > Introduce local variable 'struct device *dev' and use it instead of > dereferencing it repeatedly. > > The conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the scripts > used to generate this commit log are available at > https://github.com/groeck/coccinelle-patches > > Cc: Support Opensource > Signed-off-by: Guenter Roeck Acked-by: Steve Twiss Regards, Steve
RE: [PATCH 09/22] watchdog: da9052_wdt: Use 'dev' instead of dereferencing it repeatedly
On 08 April 2019 20:39, Guenter Roeck wrote: > Subject: [PATCH 09/22] watchdog: da9052_wdt: Use 'dev' instead of > dereferencing it repeatedly > > Introduce local variable 'struct device *dev' and use it instead of > dereferencing it repeatedly. > > The conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the scripts > used to generate this commit log are available at > https://github.com/groeck/coccinelle-patches > > Cc: Support Opensource > Signed-off-by: Guenter Roeck Acked-by: Steve Twiss Thanks! Regards, Steve
RE: [PATCH 1/2] rtc: da9063: set range
Hi, > > > drivers/rtc/rtc-da9063.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c > > > index 1b792bcea3c7..53e690b0f3a2 100644 > > > --- a/drivers/rtc/rtc-da9063.c > > > +++ b/drivers/rtc/rtc-da9063.c > > > @@ -475,6 +475,9 @@ static int da9063_rtc_probe(struct platform_device > > > *pdev) > > > da9063_data_to_tm(data, &rtc->alarm_time, rtc); > > > rtc->rtc_sync = false; > > > > > > + if (config->rtc_data_start != RTC_SEC) > > > + rtc->rtc_dev->uie_unsupported = 1; > > > + > > > > I think we should have a comment here, like: > > /* FIXME: Make use of the TICK interrupt once the RTC core supports it */ Is this TICK interrupt suggestion to use the DA9063 TICK interrupt to simulate a second granularity in the AD alarm? If I remember correctly, the original DA9063 patch set which was for AD silicon only, and which was sent to LKML before I took over looking at DA9063, used the DA9063 1-second TICK interrupt to count-down the seconds from the nearest minute in order to simulate second resolution on the RTC alarm for AD. ... yes. Here it is. The original patch was from Krystian Garbaciak and tried to support RTC alarms on the AD silicon to a second resolution by counting down the DA9063 TICK interrupt: https://marc.info/?l=lm-sensors&m=134613501230005&w=2 However, I dropped that patch completely and wrote a new RTC device driver because it didn't work in my tests. The problem was: the TICK interrupt was indistinguishable from the ALARM interrupt for a wake event and when I tested AD silicon to wake up an Android device from suspend or power-off using the RTC IRQ, the device woke up on the ALARM minute (0 seconds), discovered it was not the correct time and immediately went back to sleep. Then it woke-up and returned back to sleep every TICK IRQ second until the correct alarm time was reached (up to 59 times!). At which point it woke up properly. Regards, Steve
RE: [RFC] ARM: dts: imx: Fix the AR803X phy-mode
Hi Fabio,
On 30 March 2019 15:51 Fabio Estevam, wrote:
> Subject: [RFC] ARM: dts: imx: Fix the AR803X phy-mode
>
> Commit 6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode")
> exposed an issue on imx DTS files using AR8031/AR8035 PHYs.
>
> The end result is that the boards can no longer obtain an IP address
> via UDHCP, for example.
[...]
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 +-
[...]
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> index a0705066ccba..185fb17a3500 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -202,7 +202,7 @@
> &fec {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_enet>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> status = "okay";
> };
[...]
This patch looks surprisingly similar to this one ;)
https://lore.kernel.org/patchwork/patch/1052588/
Link:
https://lkml.kernel.org/r/1397569821-5530-4-git-send-email-thomas.petazz...@free-electrons.com
Tested-by: Steve Twiss
Tested-by: Adam Thomson
Signed-off-by: Steve Twiss
Regards,
Steve
RE: [PATCH 5/6] mfd: da9063: remove leftover platform_data definitions
Hi, On 18 March 2019 15:48 Wolfram Sang wrote: > Subject: [PATCH 5/6] mfd: da9063: remove leftover platform_data definitions > > Not used, not needed, remove them. > > Signed-off-by: Wolfram Sang > --- > include/linux/mfd/da9063/pdata.h | 65 > > 1 file changed, 65 deletions(-) > delete mode 100644 include/linux/mfd/da9063/pdata.h > > diff --git a/include/linux/mfd/da9063/pdata.h Thanks! Acked-by: Steve Twiss Tested-by: Steve Twiss Regards, Steve
RE: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id
Here are my thoughts. On 22 March 2019 10:21, Michal Vokáč wrote: > Subject: Re: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use > rgmii-id > > On 22. 03. 19 3:24, Fabio Estevam wrote: > > On Thu, Mar 21, 2019 at 11:15 PM Shawn Guo wrote: > > > >>> Unfortunately, just by looking at the dts files we do not know if a > >>> board uses an AR803x PHY or not, so I am afraid we can not do an > >>> automatic conversion. > >> > >> At least for those we already know? > > > > Yes, I can help preparing a patch that fixes the i.MX boards we know > > use AR8031 PHY. > > AFACT this issue is not AR803x specific. I was hit by the same problem > with QCA833x switch on imx6dl-yapp4. Though, we are currently the only > platform in tree using this chip and Shawn already has the fix in his tree. > > I am not aware of any other PHY drivers that my cause problems. > > $ git log --oneline v5.0..v5.1-rc1 --grep=RGMII --author=Vinod -- drivers/net/ > 6d4cd041f0af net: phy: at803x: disable delay only for RGMII mode > a968b5e9d587 net: dsa: qca8k: Enable delay for RGMII_ID mode > 5ecdd77c61c8 net: dsa: qca8k: disable delay for RGMII mode > cd28d1d6e52e net: phy: at803x: Disable phy delay for RGMII mode If this is more widespread, as Michal points out, this might affect the way the fix is approach then? On 21 March 2019 12:43 Lucas Stach wrote: > > So yes, we currently have lots of broken dtb's in mainline and I am > > wondering what is the proper fix here. [...] > but if the DT is clearly broken and fixing it in a backward > compatible way is not really feasible, I would argue that we should > treat a DT bug like any other bug. There is a way of doing this to preserve backwards compatibility I think. Maybe deprecating the previous DTS phy-mode and replacing it with a new one, phy-mode-v2 instead? At the moment, there is only a weak link between DTS and the driver in the kernel which makes finding the error difficult. Also, it seems that partly, the direction of change is caused by software which is pushing alterations in the DTS -- and not the other way round. Regards, Steve
RE: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id
Hi Fabio,
On 21 March 2019 11:17, Fabio Estevam,
> Subject: Re: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use
> rgmii-id
>
> Hi Abel,
>
> On Thu, Mar 21, 2019 at 5:42 AM Abel Vesa wrote:
>
> > > It seems we have other boards that need to be fixed and we can not
> > > have an old dtb with functional Ethernet with a new kernel.
> > >
> > > Does anyone know if this issue is AR8031 specific?
> >
> > I can confirm the same fix is works on imx6sx too.
>
> imx6sx-sabresd also uses an AR8031 Ethernet PHY.
>
> I also tested that changing the phy-mode to "rgmii-id" fixes Ethernet
> on pico-imx7d with AR8035.
>
> So yes, we currently have lots of broken dtb's in mainline and I am
> wondering what is the proper fix here.
Agreed!
The DT should be an ABI.
> Does anyone know what was the kernel commit that introduced such
> regressions?
I bisected to the original breakage (for the NFS rootfs) back to this commit:
commit 13d0ab6750b20957ac1466da4e44dc0af746ff28
Reverting this commit fixed the problem, but only for the kernel up to that
point: it was a long time ago, and several other fixes were added after that
which meant that by the time the kernel got to v5.0 it was working for me
again.
I bisected the breakage between v5.0 to v5.1-rc1 as this:
commit 3acca1dd17060332cfab15693733cdaf9fba1c90
... which doesn't make sense to me.
Regards,
Steve
---
commit 13d0ab6750b20957ac1466da4e44dc0af746ff28
Author: Heiner Kallweit
Date: Wed Jan 16 08:07:38 2019 +0100
net: phy: check return code when requesting PHY driver module
When requesting the PHY driver module fails we'll bind the genphy
driver later. This isn't obvious to the user and may cause, depending
on the PHY, different types of issues. Therefore check the return code
of request_module(). Note that we only check for failures in loading
the module, not whether a module exists for the respective PHY ID.
v2:
- add comment explaining what is checked and what is not
- return error from phy_device_create() if loading module fails
Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
---
commit 3acca1dd17060332cfab15693733cdaf9fba1c90
Author: Heiner Kallweit
Date: Mon Mar 4 19:39:03 2019 +0100
net: dsa: mv88e6xxx: add call to mv88e6xxx_ports_cmode_init to probe for
new DSA framework
In the original patch I missed to add mv88e6xxx_ports_cmode_init()
to the second probe function, the one for the new DSA framework.
Fixes: ed8fe20205ac ("net: dsa: mv88e6xxx: prevent interrupt storm caused
by mv88e6390x_port_set_cmode")
Reported-by: Shaokun Zhang
Suggested-by: Andrew Lunn
Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
RE: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id
Hi Fabio, On 20 March 2019 12:17, Fabio Estevam wrote: > Subject: Re: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use > rgmii-id > > Hi Steve, > > On Wed, Mar 20, 2019 at 9:06 AM Steve Twiss > wrote: > > > > The PHY used on the Freescale i.MX6Q/DL SABRE boards is qualified as > > 'rgmii' instead of 'rgmii-id'. Meaning the RX and TX delays that were > > This patch declares it as 'rgmii-id', which contradicts the commit log. The PHY used on the Freescale i.MX6Q/DL SABRE boards is qualified as 'rgmii' instead of 'rgmii-id'. Can that be read two ways? I meant the phy-mode is currently qualified as 'rgmii' instead of what it should be: 'rgmii-id'. [...] > > This patch fixes the network problems seen on the Freescale i.MX6Q/DL > > Please provide a Fixes tag. It would be good to know if this fix needs > to be applied to older kernels. I didn't put a Fixes tag in because I find this patch fixes v5.1-rc1 (which I see as broken). But the patch is not needed in v5.0 because I see that as working. So didn't see the need for a Cc: stable. Regards, Steve
[PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id
The PHY used on the Freescale i.MX6Q/DL SABRE boards is qualified as
'rgmii' instead of 'rgmii-id'. Meaning the RX and TX delays that were
previously added by the MAC when required, but are now provided
internally by the PHY (and the MAC should no longer add the RX or TX
delays in this case).
This patch fixes the network problems seen on the Freescale i.MX6Q/DL
SABRE boards and makes a difference when correctly loading the NFS
rootfs on startup.
Link:
https://lkml.kernel.org/r/1397569821-5530-4-git-send-email-thomas.petazz...@free-electrons.com
Tested-by: Steve Twiss
Tested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index a070506..185fb17 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -202,7 +202,7 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
1.9.3
RE: [PATCH v2] regulator: core: fix error path for regulator_set_voltage_unlocked
On 18 March 2019 16:41, Dmitry Osipenko wrote: > Subject: Re: [PATCH v2] regulator: core: fix error path for > regulator_set_voltage_unlocked [...] > Reviewed-by: Dmitry Osipenko Thanks Dmitry. Regards, Steve
[PATCH v2] regulator: core: fix error path for regulator_set_voltage_unlocked
During several error paths in the function
regulator_set_voltage_unlocked() the value of 'ret' can take on negative
error values. However, in calls that go through the 'goto out' statement,
this return value is lost and return 0 is used instead, indicating a
'pass'.
There are several cases where this function should legitimately return a
fail instead of a pass: one such case includes constraints check during
voltage selection in the call to regulator_check_voltage(), which can
have -EINVAL for the case when an unsupported voltage is incorrectly
requested. In that case, -22 is expected as the return value, not 0.
Fixes: 9243a195be7a ("regulator: core: Change voltage setting path")
Cc: stable
Signed-off-by: Steve Twiss
---
drivers/regulator/core.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 68473d0..968dcd9 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3322,15 +3322,12 @@ static int regulator_set_voltage_unlocked(struct
regulator *regulator,
/* for not coupled regulators this will just set the voltage */
ret = regulator_balance_voltage(rdev, state);
- if (ret < 0)
- goto out2;
+ if (ret < 0) {
+ voltage->min_uV = old_min_uV;
+ voltage->max_uV = old_max_uV;
+ }
out:
- return 0;
-out2:
- voltage->min_uV = old_min_uV;
- voltage->max_uV = old_max_uV;
-
return ret;
}
--
1.9.3
RE: [PATCH] regulator: core: fix error path for regulator_set_voltage_unlocked
Hi Dmitry,
Thanks,
On 18 March 2019 16:03, Dmitry Osipenko wrote:
> Subject: Re: [PATCH] regulator: core: fix error path for
> regulator_set_voltage_unlocked
>
> 18.03.2019 18:32, Steve Twiss пишет:
> > During several error paths in the function
> > regulator_set_voltage_unlocked() the value of 'ret' can take on negative
> > error values. However, in calls that go through the 'goto out' statement,
> > this return value is lost and return 0 is used instead, indicating a
> > 'pass'.
> >
> > There are several cases where this function should legitimately return a
> > fail instead of a pass: one such case includes constraints check during
> > voltage selection in the call to regulator_check_voltage(), which can
> > have -EINVAL for the case when an unsupported voltage is incorrectly
> > requested. In that case, -22 is expected as the return value, not 0.
> >
> > Fixes: 9243a195be7a ("regulator: core: Change voltage setting path")
> > Signed-off-by: Steve Twiss
> > ---
> > drivers/regulator/core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 68473d0..caf8743 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -3326,7 +3326,7 @@ static int regulator_set_voltage_unlocked(struct
> regulator *regulator,
> > goto out2;
> >
> > out:
> > - return 0;
> > + return ret;
> > out2:
> > voltage->min_uV = old_min_uV;
> > voltage->max_uV = old_max_uV;
> >
>
> Looks like a good catch.
>
> Probably will be a bit better to write this as:
>
> /* for not coupled regulators this will just set the voltage */
> ret = regulator_balance_voltage(rdev, state);
> - if (ret < 0)
> - goto out2;
> -
> + if (ret < 0) {
> + voltage->min_uV = old_min_uV;
> + voltage->max_uV = old_max_uV;
> + }
> out:
> - return 0;
> -out2:
> - voltage->min_uV = old_min_uV;
> - voltage->max_uV = old_max_uV;
> -
> return ret;
> }
I've just had a very similar conversation with Adam Thomson who sits near me
and also
said the two gotos make it look confusing.
Honestly -- I wasn't convinced because it looked obvious to me, but you are the
second
person to say it ..
CC: Adam Thomson
So, ok. Agreed. :)
I'll make the change and resend.
Regards,
Steve
[PATCH] regulator: core: fix error path for regulator_set_voltage_unlocked
During several error paths in the function
regulator_set_voltage_unlocked() the value of 'ret' can take on negative
error values. However, in calls that go through the 'goto out' statement,
this return value is lost and return 0 is used instead, indicating a
'pass'.
There are several cases where this function should legitimately return a
fail instead of a pass: one such case includes constraints check during
voltage selection in the call to regulator_check_voltage(), which can
have -EINVAL for the case when an unsupported voltage is incorrectly
requested. In that case, -22 is expected as the return value, not 0.
Fixes: 9243a195be7a ("regulator: core: Change voltage setting path")
Signed-off-by: Steve Twiss
---
drivers/regulator/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 68473d0..caf8743 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3326,7 +3326,7 @@ static int regulator_set_voltage_unlocked(struct
regulator *regulator,
goto out2;
out:
- return 0;
+ return ret;
out2:
voltage->min_uV = old_min_uV;
voltage->max_uV = old_max_uV;
--
1.9.3
RE: [PATCH 2/2] regulator: da9055: Convert to regulator core's simplified DT parsing code
Hi Mark,
For the DA9055, I have spoken with the management here. Dialog Semiconductor are
"no longer building the DA9055"; the device doesn't appear on the support portal
or website and; I have been told, "you can remove [it] from your list of
supported products".
But, as always: I realise that the Linux community will have different aims and
I would like to support those as much as I can.
There are many reasons to keep supporting the drivers, and not least because of
your comments from way-back, in 2014:
On Fri, 14 Feb 2014 14:56:43, Mark Brown wrote:
> We do fairly often see problems with people still using old boards for various
> reasons [and it] does not mean that the old silicon has been retired by users
> (even if [it is] just [used] for comparison purposes [...] - "that worked on
> the rev A boards, did we break the software?").
But it does seem that around 97% of this driver has not has not changed since
2014, so we are happy here at Dialog to remove our support from this DA9055
device.
Is there a Linux device driver retirement plan for obsoleted products? :)
Regards,
Steve
On 12 March 2019 15:48, Axel Lin wrote:
> To: Mark Brown
> Subject: [PATCH 2/2] regulator: da9055: Convert to regulator core's
> simplified DT
> parsing code
>
> Use regulator core's simplified DT parsing code to simply the driver
> implementation.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/da9055-regulator.c | 67 +++-
> 1 file changed, 6 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/regulator/da9055-regulator.c b/drivers/regulator/da9055-
> regulator.c
> index 3c6fac793658..b7b4dddf5509 100644
> --- a/drivers/regulator/da9055-regulator.c
> +++ b/drivers/regulator/da9055-regulator.c
> @@ -338,6 +338,8 @@ static const struct regulator_ops da9055_ldo_ops = {
> {\
> .reg_desc = {\
> .name = #_id,\
> + .of_match = of_match_ptr(#_id),\
> + .regulators_node = of_match_ptr("regulators"),\
> .ops = &da9055_ldo_ops,\
> .type = REGULATOR_VOLTAGE,\
> .id = DA9055_ID_##_id,\
> @@ -366,6 +368,8 @@ static const struct regulator_ops da9055_ldo_ops = {
> {\
> .reg_desc = {\
> .name = #_id,\
> + .of_match = of_match_ptr(#_id),\
> + .regulators_node = of_match_ptr("regulators"),\
> .ops = &da9055_buck_ops,\
> .type = REGULATOR_VOLTAGE,\
> .id = DA9055_ID_##_id,\
> @@ -507,59 +511,6 @@ static inline struct da9055_regulator_info
> *find_regulator_info(int id)
> return NULL;
> }
>
> -#ifdef CONFIG_OF
> -static struct of_regulator_match da9055_reg_matches[] = {
> - { .name = "BUCK1", },
> - { .name = "BUCK2", },
> - { .name = "LDO1", },
> - { .name = "LDO2", },
> - { .name = "LDO3", },
> - { .name = "LDO4", },
> - { .name = "LDO5", },
> - { .name = "LDO6", },
> -};
> -
> -static int da9055_regulator_dt_init(struct platform_device *pdev,
> - struct da9055_regulator *regulator,
> - struct regulator_config *config,
> - int regid)
> -{
> - struct device_node *nproot, *np;
> - int ret;
> -
> - nproot = of_node_get(pdev->dev.parent->of_node);
> - if (!nproot)
> - return -ENODEV;
> -
> - np = of_get_child_by_name(nproot, "regulators");
> - if (!np)
> - return -ENODEV;
> -
> - ret = of_regulator_match(&pdev->dev, np,
> &da9055_reg_matches[regid], 1);
> - of_node_put(nproot);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "Error matching regulator: %d\n", ret);
> - return ret;
> - }
> -
> - config->init_data = da9055_reg_matches[regid].init_data;
> - config->of_node = da9055_reg_matches[regid].of_node;
> -
> - if (!config->of_node)
> - return -ENODEV;
> -
> - return 0;
> -}
> -#else
> -static inline int da9055_regulator_dt_init(struct platform_device *pdev,
> -struct da9055_regulator *regulator,
> -struct regulator_config *config,
> -int regid)
> -{
> - return -ENODEV;
> -}
> -#endif /* CONFIG_OF */
> -
> static int da9055_regulator_probe(struct platform_device *pdev)
> {
> struct regulator_config config = { };
> @@ -580,18 +531,12 @@ static int da9055_regulator_probe(struct
> platform_device *pdev)
> }
>
> regulator->da9055 = da9055;
> - config.dev = &pdev->dev;
> + config.dev = da9055->dev;
> config.driver_data = regulator;
> config.regmap = da9055->regmap;
>
> - if (pdata) {
> + if (pdata)
> config.init_data = pdata->regulators[pdev->id];
> - } else {
> - ret = da9055_regulator_dt_init(pdev, regulator, &config,
> -pdev->id);
> - if (ret
RE: [PATCH] regulator: da9052: Include linux/of.h to fix build warning for of_match_ptr
Hi Axel, On 16 March 2019 01:51, Axel Lin wrote: > To: Mark Brown > Subject: [PATCH] regulator: da9052: Include linux/of.h to fix build warning > for > of_match_ptr > > Remove #ifdef CONFIG_OF guard so linux/of.h will be included when > !CONFIG_OF. This fixes build warnings when !CONFIG_OF. > > Reported-by: kbuild test robot > Signed-off-by: Axel Lin Thanks! Acked-by: Steve Twiss Regards, Steve
[PATCH 06/13] regulator: ltc3589: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 3eb2c7ecb7ea ("regulator: Add LTC3589 support")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/ltc3589.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/ltc3589.c b/drivers/regulator/ltc3589.c
index 63f724f..75089b0 100644
--- a/drivers/regulator/ltc3589.c
+++ b/drivers/regulator/ltc3589.c
@@ -419,16 +419,22 @@ static irqreturn_t ltc3589_isr(int irq, void *dev_id)
if (irqstat & LTC3589_IRQSTAT_THERMAL_WARN) {
event = REGULATOR_EVENT_OVER_TEMP;
- for (i = 0; i < LTC3589_NUM_REGULATORS; i++)
+ for (i = 0; i < LTC3589_NUM_REGULATORS; i++) {
+ regulator_lock(ltc3589->regulators[i]);
regulator_notifier_call_chain(ltc3589->regulators[i],
event, NULL);
+ regulator_unlock(ltc3589->regulators[i]);
+ }
}
if (irqstat & LTC3589_IRQSTAT_UNDERVOLT_WARN) {
event = REGULATOR_EVENT_UNDER_VOLTAGE;
- for (i = 0; i < LTC3589_NUM_REGULATORS; i++)
+ for (i = 0; i < LTC3589_NUM_REGULATORS; i++) {
+ regulator_lock(ltc3589->regulators[i]);
regulator_notifier_call_chain(ltc3589->regulators[i],
event, NULL);
+ regulator_unlock(ltc3589->regulators[i]);
+ }
}
/* Clear warning condition */
--
1.9.3
[PATCH 01/13] regulator: da9055: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: f6130be652d0 ("regulator: DA9055 regulator driver")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/da9055-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/da9055-regulator.c
b/drivers/regulator/da9055-regulator.c
index 588c3d24..acba42d 100644
--- a/drivers/regulator/da9055-regulator.c
+++ b/drivers/regulator/da9055-regulator.c
@@ -515,8 +515,10 @@ static irqreturn_t da9055_ldo5_6_oc_irq(int irq, void
*data)
{
struct da9055_regulator *regulator = data;
+ regulator_lock(regulator->rdev);
regulator_notifier_call_chain(regulator->rdev,
REGULATOR_EVENT_OVER_CURRENT, NULL);
+ regulator_unlock(regulator->rdev);
return IRQ_HANDLED;
}
--
1.9.3
[PATCH 03/13] regulator: da9063: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 69ca3e58d178 ("regulator: da9063: Add Dialog DA9063 voltage regulators
support.")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/da9063-regulator.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/da9063-regulator.c
b/drivers/regulator/da9063-regulator.c
index 8cbcd2a..d3ea73a 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -615,9 +615,12 @@ static irqreturn_t da9063_ldo_lim_event(int irq, void
*data)
if (regl->info->oc_event.reg != DA9063_REG_STATUS_D)
continue;
- if (BIT(regl->info->oc_event.lsb) & bits)
+ if (BIT(regl->info->oc_event.lsb) & bits) {
+ regulator_lock(regl->rdev);
regulator_notifier_call_chain(regl->rdev,
REGULATOR_EVENT_OVER_CURRENT, NULL);
+ regulator_unlock(regl->rdev);
+ }
}
return IRQ_HANDLED;
--
1.9.3
[PATCH 04/13] regulator: da9211: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 1028a37daa14 ("regulator: da9211: new regulator driver")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/da9211-regulator.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/regulator/da9211-regulator.c
b/drivers/regulator/da9211-regulator.c
index 109ee12..4d7fe48 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -322,8 +322,10 @@ static irqreturn_t da9211_irq_handler(int irq, void *data)
goto error_i2c;
if (reg_val & DA9211_E_OV_CURR_A) {
+ regulator_lock(chip->rdev[0]);
regulator_notifier_call_chain(chip->rdev[0],
REGULATOR_EVENT_OVER_CURRENT, NULL);
+ regulator_unlock(chip->rdev[0]);
err = regmap_write(chip->regmap, DA9211_REG_EVENT_B,
DA9211_E_OV_CURR_A);
@@ -334,8 +336,10 @@ static irqreturn_t da9211_irq_handler(int irq, void *data)
}
if (reg_val & DA9211_E_OV_CURR_B) {
+ regulator_lock(chip->rdev[1]);
regulator_notifier_call_chain(chip->rdev[1],
REGULATOR_EVENT_OVER_CURRENT, NULL);
+ regulator_unlock(chip->rdev[1]);
err = regmap_write(chip->regmap, DA9211_REG_EVENT_B,
DA9211_E_OV_CURR_B);
--
1.9.3
[PATCH 02/13] regulator: da9062: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 4068e5182ada ("regulator: da9062: DA9062 regulator driver")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/da9062-regulator.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/da9062-regulator.c
b/drivers/regulator/da9062-regulator.c
index 34a70d9..5224304 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -974,8 +974,10 @@ static irqreturn_t da9062_ldo_lim_event(int irq, void
*data)
continue;
if (BIT(regl->info->oc_event.lsb) & bits) {
+ regulator_lock(regl->rdev);
regulator_notifier_call_chain(regl->rdev,
REGULATOR_EVENT_OVER_CURRENT, NULL);
+ regulator_unlock(regl->rdev);
handled = IRQ_HANDLED;
}
}
--
1.9.3
[PATCH 05/13] regulator: lp8755: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: b59320cc5a5e ("regulator: lp8755: new driver for LP8755")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/lp8755.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
index 244822b..d82d307 100644
--- a/drivers/regulator/lp8755.c
+++ b/drivers/regulator/lp8755.c
@@ -372,10 +372,13 @@ static irqreturn_t lp8755_irq_handler(int irq, void *data)
for (icnt = 0; icnt < LP8755_BUCK_MAX; icnt++)
if ((flag0 & (0x4 << icnt))
&& (pchip->irqmask & (0x04 << icnt))
- && (pchip->rdev[icnt] != NULL))
+ && (pchip->rdev[icnt] != NULL)) {
+ regulator_lock(pchip->rdev[icnt]);
regulator_notifier_call_chain(pchip->rdev[icnt],
LP8755_EVENT_PWR_FAULT,
NULL);
+ regulator_unlock(pchip->rdev[icnt]);
+ }
/* read flag1 register */
ret = lp8755_read(pchip, 0x0E, &flag1);
@@ -389,18 +392,24 @@ static irqreturn_t lp8755_irq_handler(int irq, void *data)
/* send OCP event to all regualtor devices */
if ((flag1 & 0x01) && (pchip->irqmask & 0x01))
for (icnt = 0; icnt < LP8755_BUCK_MAX; icnt++)
- if (pchip->rdev[icnt] != NULL)
+ if (pchip->rdev[icnt] != NULL) {
+ regulator_lock(pchip->rdev[icnt]);
regulator_notifier_call_chain(pchip->rdev[icnt],
LP8755_EVENT_OCP,
NULL);
+ regulator_unlock(pchip->rdev[icnt]);
+ }
/* send OVP event to all regualtor devices */
if ((flag1 & 0x02) && (pchip->irqmask & 0x02))
for (icnt = 0; icnt < LP8755_BUCK_MAX; icnt++)
- if (pchip->rdev[icnt] != NULL)
+ if (pchip->rdev[icnt] != NULL) {
+ regulator_lock(pchip->rdev[icnt]);
regulator_notifier_call_chain(pchip->rdev[icnt],
LP8755_EVENT_OVP,
NULL);
+ regulator_unlock(pchip->rdev[icnt]);
+ }
return IRQ_HANDLED;
err_i2c:
--
1.9.3
[PATCH 08/13] regulator: pv88060: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: f307a7e9b7af ("regulator: pv88060: new regulator driver")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/pv88060-regulator.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/regulator/pv88060-regulator.c
b/drivers/regulator/pv88060-regulator.c
index a944605..000c349 100644
--- a/drivers/regulator/pv88060-regulator.c
+++ b/drivers/regulator/pv88060-regulator.c
@@ -276,9 +276,11 @@ static irqreturn_t pv88060_irq_handler(int irq, void *data)
if (reg_val & PV88060_E_VDD_FLT) {
for (i = 0; i < PV88060_MAX_REGULATORS; i++) {
if (chip->rdev[i] != NULL) {
+ regulator_lock(chip->rdev[i]);
regulator_notifier_call_chain(chip->rdev[i],
REGULATOR_EVENT_UNDER_VOLTAGE,
NULL);
+ regulator_unlock(chip->rdev[i]);
}
}
@@ -293,9 +295,11 @@ static irqreturn_t pv88060_irq_handler(int irq, void *data)
if (reg_val & PV88060_E_OVER_TEMP) {
for (i = 0; i < PV88060_MAX_REGULATORS; i++) {
if (chip->rdev[i] != NULL) {
+ regulator_lock(chip->rdev[i]);
regulator_notifier_call_chain(chip->rdev[i],
REGULATOR_EVENT_OVER_TEMP,
NULL);
+ regulator_unlock(chip->rdev[i]);
}
}
--
1.9.3
[PATCH 13/13] regulator: wm831x ldo: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: d1c6b4fe668b ("regulator: Add WM831x LDO support")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/wm831x-ldo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/wm831x-ldo.c b/drivers/regulator/wm831x-ldo.c
index e4a6f88..fcd038e 100644
--- a/drivers/regulator/wm831x-ldo.c
+++ b/drivers/regulator/wm831x-ldo.c
@@ -51,9 +51,11 @@ static irqreturn_t wm831x_ldo_uv_irq(int irq, void *data)
{
struct wm831x_ldo *ldo = data;
+ regulator_lock(ldo->regulator);
regulator_notifier_call_chain(ldo->regulator,
REGULATOR_EVENT_UNDER_VOLTAGE,
NULL);
+ regulator_unlock(ldo->regulator);
return IRQ_HANDLED;
}
--
1.9.3
[PATCH 09/13] regulator: pv88080: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 99cf3af5e2d5 ("regulator: pv88080: new regulator driver")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/pv88080-regulator.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/regulator/pv88080-regulator.c
b/drivers/regulator/pv88080-regulator.c
index 9a08cb2..d99f1b9 100644
--- a/drivers/regulator/pv88080-regulator.c
+++ b/drivers/regulator/pv88080-regulator.c
@@ -384,9 +384,11 @@ static irqreturn_t pv88080_irq_handler(int irq, void *data)
if (reg_val & PV88080_E_VDD_FLT) {
for (i = 0; i < PV88080_MAX_REGULATORS; i++) {
if (chip->rdev[i] != NULL) {
+ regulator_lock(chip->rdev[i]);
regulator_notifier_call_chain(chip->rdev[i],
REGULATOR_EVENT_UNDER_VOLTAGE,
NULL);
+ regulator_unlock(chip->rdev[i]);
}
}
@@ -401,9 +403,11 @@ static irqreturn_t pv88080_irq_handler(int irq, void *data)
if (reg_val & PV88080_E_OVER_TEMP) {
for (i = 0; i < PV88080_MAX_REGULATORS; i++) {
if (chip->rdev[i] != NULL) {
+ regulator_lock(chip->rdev[i]);
regulator_notifier_call_chain(chip->rdev[i],
REGULATOR_EVENT_OVER_TEMP,
NULL);
+ regulator_unlock(chip->rdev[i]);
}
}
--
1.9.3
[PATCH 07/13] regulator: ltc3676: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: 37b918a034fe ("regulator: Add LTC3676 support")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/ltc3676.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/ltc3676.c b/drivers/regulator/ltc3676.c
index 71fd0f2..cd0f112 100644
--- a/drivers/regulator/ltc3676.c
+++ b/drivers/regulator/ltc3676.c
@@ -338,17 +338,23 @@ static irqreturn_t ltc3676_isr(int irq, void *dev_id)
if (irqstat & LTC3676_IRQSTAT_THERMAL_WARN) {
dev_warn(dev, "Over-temperature Warning\n");
event = REGULATOR_EVENT_OVER_TEMP;
- for (i = 0; i < LTC3676_NUM_REGULATORS; i++)
+ for (i = 0; i < LTC3676_NUM_REGULATORS; i++) {
+ regulator_lock(ltc3676->regulators[i]);
regulator_notifier_call_chain(ltc3676->regulators[i],
event, NULL);
+ regulator_unlock(ltc3676->regulators[i]);
+ }
}
if (irqstat & LTC3676_IRQSTAT_UNDERVOLT_WARN) {
dev_info(dev, "Undervoltage Warning\n");
event = REGULATOR_EVENT_UNDER_VOLTAGE;
- for (i = 0; i < LTC3676_NUM_REGULATORS; i++)
+ for (i = 0; i < LTC3676_NUM_REGULATORS; i++) {
+ regulator_lock(ltc3676->regulators[i]);
regulator_notifier_call_chain(ltc3676->regulators[i],
event, NULL);
+ regulator_unlock(ltc3676->regulators[i]);
+ }
}
/* Clear warning condition */
--
1.9.3
[PATCH 10/13] regulator: pv88090: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: c90456e36d9c ("regulator: pv88090: new regulator driver")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/pv88090-regulator.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/regulator/pv88090-regulator.c
b/drivers/regulator/pv88090-regulator.c
index 7a0c159..b4ff646 100644
--- a/drivers/regulator/pv88090-regulator.c
+++ b/drivers/regulator/pv88090-regulator.c
@@ -274,9 +274,11 @@ static irqreturn_t pv88090_irq_handler(int irq, void *data)
if (reg_val & PV88090_E_VDD_FLT) {
for (i = 0; i < PV88090_MAX_REGULATORS; i++) {
if (chip->rdev[i] != NULL) {
+ regulator_lock(chip->rdev[i]);
regulator_notifier_call_chain(chip->rdev[i],
REGULATOR_EVENT_UNDER_VOLTAGE,
NULL);
+ regulator_unlock(chip->rdev[i]);
}
}
@@ -291,9 +293,11 @@ static irqreturn_t pv88090_irq_handler(int irq, void *data)
if (reg_val & PV88090_E_OVER_TEMP) {
for (i = 0; i < PV88090_MAX_REGULATORS; i++) {
if (chip->rdev[i] != NULL) {
+ regulator_lock(chip->rdev[i]);
regulator_notifier_call_chain(chip->rdev[i],
REGULATOR_EVENT_OVER_TEMP,
NULL);
+ regulator_unlock(chip->rdev[i]);
}
}
--
1.9.3
[PATCH 11/13] regulator: wm831x: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: e4ee831f949a ("regulator: Add WM831x DC-DC buck convertor support")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/wm831x-dcdc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index 5a5bc4b..4f5461a 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -183,9 +183,11 @@ static irqreturn_t wm831x_dcdc_uv_irq(int irq, void *data)
{
struct wm831x_dcdc *dcdc = data;
+ regulator_lock(dcdc->regulator);
regulator_notifier_call_chain(dcdc->regulator,
REGULATOR_EVENT_UNDER_VOLTAGE,
NULL);
+ regulator_unlock(dcdc->regulator);
return IRQ_HANDLED;
}
@@ -194,9 +196,11 @@ static irqreturn_t wm831x_dcdc_oc_irq(int irq, void *data)
{
struct wm831x_dcdc *dcdc = data;
+ regulator_lock(dcdc->regulator);
regulator_notifier_call_chain(dcdc->regulator,
REGULATOR_EVENT_OVER_CURRENT,
NULL);
+ regulator_unlock(dcdc->regulator);
return IRQ_HANDLED;
}
--
1.9.3
[PATCH 00/13] Fix backtrace warnings from bad notifier chain calls
Hi Mark, This patch-set fixes a WARN_ON_ONCE() backtrace call caused by not locking the mutex from the function call regulator_notifier_call_chain(). It does this for thirteen regulator drivers by adding a mutex lock surrounding the notifier calls. This missing mutex lock has been around for a while, but the API I have used used here to fix it (i.e. regulator_lock()/regulator_unlock()) has only been in the kernel since v4.18. Therefore as this fix stands, the patches do not port back very far in kernel history. Regards, Steve Steve Twiss (13): regulator: da9055: Fix notifier mutex lock warning regulator: da9062: Fix notifier mutex lock warning regulator: da9063: Fix notifier mutex lock warning regulator: da9211: Fix notifier mutex lock warning regulator: lp8755: Fix notifier mutex lock warning regulator: ltc3589: Fix notifier mutex lock warning regulator: ltc3676: Fix notifier mutex lock warning regulator: pv88060: Fix notifier mutex lock warning regulator: pv88080: Fix notifier mutex lock warning regulator: pv88090: Fix notifier mutex lock warning regulator: wm831x: Fix notifier mutex lock warning regulator: wm831x isink: Fix notifier mutex lock warning regulator: wm831x ldo: Fix notifier mutex lock warning drivers/regulator/da9055-regulator.c | 2 ++ drivers/regulator/da9062-regulator.c | 2 ++ drivers/regulator/da9063-regulator.c | 5 - drivers/regulator/da9211-regulator.c | 4 drivers/regulator/lp8755.c| 15 --- drivers/regulator/ltc3589.c | 10 -- drivers/regulator/ltc3676.c | 10 -- drivers/regulator/pv88060-regulator.c | 4 drivers/regulator/pv88080-regulator.c | 4 drivers/regulator/pv88090-regulator.c | 4 drivers/regulator/wm831x-dcdc.c | 4 drivers/regulator/wm831x-isink.c | 2 ++ drivers/regulator/wm831x-ldo.c| 2 ++ 13 files changed, 60 insertions(+), 8 deletions(-) -- 1.9.3
[PATCH 12/13] regulator: wm831x isink: Fix notifier mutex lock warning
The mutex for the regulator_dev must be controlled by the caller of
the regulator_notifier_call_chain(), as described in the comment
for that function.
Failure to mutex lock and unlock surrounding the notifier call results
in a kernel WARN_ON_ONCE() which will dump a backtrace for the
regulator_notifier_call_chain() when that function call is first made.
The mutex can be controlled using the regulator_lock/unlock() API.
Fixes: d4d6b722e780 ("regulator: Add WM831x ISINK support")
Suggested-by: Adam Thomson
Signed-off-by: Steve Twiss
---
drivers/regulator/wm831x-isink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/regulator/wm831x-isink.c b/drivers/regulator/wm831x-isink.c
index 6dd891d..11f3511 100644
--- a/drivers/regulator/wm831x-isink.c
+++ b/drivers/regulator/wm831x-isink.c
@@ -140,9 +140,11 @@ static irqreturn_t wm831x_isink_irq(int irq, void *data)
{
struct wm831x_isink *isink = data;
+ regulator_lock(isink->regulator);
regulator_notifier_call_chain(isink->regulator,
REGULATOR_EVENT_OVER_CURRENT,
NULL);
+ regulator_unlock(isink->regulator);
return IRQ_HANDLED;
}
--
1.9.3
RE: [PATCH 2/2] regulator: da9063: Convert to use regulator_set/get_current_limit_regmap
On 04 March 2019 13:16, Axel Lin wrote: Hi Axel, > To: Mark Brown > Subject: [PATCH 2/2] regulator: da9063: Convert to use > regulator_set/get_current_limit_regmap > > Use regulator_set/get_current_limit_regmap helpers to save some code. > > Signed-off-by: Axel Lin > --- > drivers/regulator/da9063-regulator.c | 107 +++ > 1 file changed, 28 insertions(+), 79 deletions(-) Thanks again, Acked-by: Steve Twiss Regards, Steve ps. This patch applies to next-20190305. But doesn't cleanly apply cleanly to v5.0, I guess because there are several patches queued up in linux-next, in the same way as the da9062 patch has minor issues for v5.0. Hunk #4 FAILED at 131. Hunk #7 FAILED at 850 2 out of 7 hunks FAILED -- saving rejects to file drivers/regulator/da9063-regulator.c.rej
RE: [PATCH 1/2] regulator: da9062: Convert to use regulator_set/get_current_limit_regmap
Hi Axel, On 04 March 2019 13:16, Axel Lin wrote: > Subject: [PATCH 1/2] regulator: da9062: Convert to use > regulator_set/get_current_limit_regmap > > Use regulator_set/get_current_limit_regmap helpers to save some code. Thanks again, Acked-by: Steve Twiss Regards, Steve ps. This patch applies to next-20190305. But doesn't cleanly apply cleanly to v5.0, I guess because there are several patches queued up in linux-next, e.g. the reverse search of the limit array in the function da9062_set_current_limit() ... etc, etc. Hunk #4 FAILED at 109. Hunk #20 FAILED at 1044 2 out of 20 hunks FAILED -- saving rejects to file drivers/regulator/da9062-regulator.c.rej
RE: [PATCH 10/11] regulator: pv88090: Convert to use regulator_set/get_current_limit_regmap
On 28 February 2019 13:40, Axel Lin wrote:
Hi Axel,
> Subject: [PATCH 10/11] regulator: pv88090: Convert to use
> regulator_set/get_current_limit_regmap
>
> Use regulator_set/get_current_limit_regmap helpers to save some code.
[...]
> @@ -193,8 +155,8 @@ static const struct regulator_ops pv88090_buck_ops = {
> .set_voltage_sel = regulator_set_voltage_sel_regmap,
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .list_voltage = regulator_list_voltage_linear,
> - .set_current_limit = pv88090_set_current_limit,
> - .get_current_limit = pv88090_get_current_limit,
> + .set_current_limit = regulator_set_current_limit_regmap,
> + .get_current_limit = regulator_get_current_limit_regmap,
> };
>
> static const struct regulator_ops pv88090_ldo_ops = {
> @@ -223,10 +185,11 @@ static const struct regulator_ops pv88090_ldo_ops = {
> .enable_mask = PV88090_##regl_name##_EN, \
> .vsel_reg = PV88090_REG_##regl_name##_CONF0, \
> .vsel_mask = PV88090_V##regl_name##_MASK, \
> + .curr_table = limits_array, \
> + .n_current_limits = ARRAY_SIZE(limits_array), \
> + .csel_reg = PV88090_REG_##regl_name##_CONF1, \
> + .csel_mask = PV88090_##regl_name##_ILIM_MASK, \
> },\
> - .current_limits = limits_array, \
> - .n_current_limits = ARRAY_SIZE(limits_array), \
> - .limit_mask = PV88090_##regl_name##_ILIM_MASK, \
> .conf = PV88090_REG_##regl_name##_CONF1, \
> .conf2 = PV88090_REG_##regl_name##_CONF2, \
Acked-by: Steve Twiss ;
Thanks,
Regards,
Steve
RE: [PATCH 09/11] regulator: pv88080: Convert to use regulator_set/get_current_limit_regmap
On 28 February 2019 13:40, Axel Lin wrote:
> Subject: [PATCH 09/11] regulator: pv88080: Convert to use
> regulator_set/get_current_limit_regmap
>
> Use regulator_set/get_current_limit_regmap helpers to save some code.
[...]
Hi Axel,
Looks good to me. Thanks again.
Acked-by: Steve Twiss
Regards,
Steve
[...]
> @@ -315,8 +276,8 @@ static const struct regulator_ops pv88080_buck_ops = {
> .set_voltage_sel = regulator_set_voltage_sel_regmap,
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .list_voltage = regulator_list_voltage_linear,
> - .set_current_limit = pv88080_set_current_limit,
> - .get_current_limit = pv88080_get_current_limit,
> + .set_current_limit = regulator_set_current_limit_regmap,
> + .get_current_limit = regulator_get_current_limit_regmap,
> };
[...]
>
> static const struct regulator_ops pv88080_hvbuck_ops = {
> @@ -341,9 +302,9 @@ static const struct regulator_ops pv88080_hvbuck_ops = {
> .min_uV = min, \
> .uV_step = step, \
> .n_voltages = ((max) - (min))/(step) + 1, \
> + .curr_table = limits_array, \
> + .n_current_limits = ARRAY_SIZE(limits_array), \
> },\
> - .current_limits = limits_array, \
> - .n_current_limits = ARRAY_SIZE(limits_array), \
> }
>
> #define PV88080_HVBUCK(chip, regl_name, min, step, max) \
> @@ -521,9 +482,9 @@ static int pv88080_i2c_probe(struct i2c_client *i2c,
> if (init_data)
> config.init_data = &init_data[i];
>
> - pv88080_regulator_info[i].limit_reg
> + pv88080_regulator_info[i].desc.csel_reg
> = regmap_config->buck_regmap[i].buck_limit_reg;
> - pv88080_regulator_info[i].limit_mask
> + pv88080_regulator_info[i].desc.csel_mask
> = regmap_config->buck_regmap[i].buck_limit_mask;
> pv88080_regulator_info[i].mode_reg
> = regmap_config->buck_regmap[i].buck_mode_reg;
> --
> 2.17.1
RE: [PATCH 08/11] regulator: pv88060: Convert to use regulator_set/get_current_limit_regmap
On 28 February 2019 13:40, Axel Lin wrote:
> Subject: [PATCH 08/11] regulator: pv88060: Convert to use
> regulator_set/get_current_limit_regmap
>
> Use regulator_set/get_current_limit_regmap helpers to save some code.
[...]
Hi Axel,
Looks good to me. Thanks again.
Acked-by: Steve Twiss
Regards,
Steve
> @@ -171,8 +133,8 @@ static const struct regulator_ops pv88060_buck_ops = {
> .set_voltage_sel = regulator_set_voltage_sel_regmap,
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .list_voltage = regulator_list_voltage_linear,
> - .set_current_limit = pv88060_set_current_limit,
> - .get_current_limit = pv88060_get_current_limit,
> + .set_current_limit = regulator_set_current_limit_regmap,
> + .get_current_limit = regulator_get_current_limit_regmap,
> };
>
> static const struct regulator_ops pv88060_ldo_ops = {
> @@ -207,10 +169,11 @@ static const struct regulator_ops pv88060_sw_ops = {
> .enable_mask = PV88060_BUCK_EN, \
> .vsel_reg = PV88060_REG_##regl_name##_CONF0,\
> .vsel_mask = PV88060_VBUCK_MASK,\
> + .curr_table = limits_array,\
> + .n_current_limits = ARRAY_SIZE(limits_array),\
> + .csel_reg = PV88060_REG_##regl_name##_CONF1,\
> + .csel_mask = PV88060_BUCK_ILIM_MASK,\
> },\
> - .current_limits = limits_array,\
> - .n_current_limits = ARRAY_SIZE(limits_array),\
> - .limit_mask = PV88060_BUCK_ILIM_MASK, \
> .conf = PV88060_REG_##regl_name##_CONF1,\
> }
>
> --
> 2.17.1
RE: [PATCH 03/11] regulator: da9055: Convert to use regulator_set/get_current_limit_regmap
On 28 February 2019 13:40, Axel Lin,
> Subject: [PATCH 03/11] regulator: da9055: Convert to use
> regulator_set/get_current_limit_regmap
>
> Use regulator_set/get_current_limit_regmap helpers to save some code.
[...]
> @@ -329,8 +298,8 @@ static const struct regulator_ops da9055_buck_ops = {
> .get_mode = da9055_buck_get_mode,
> .set_mode = da9055_buck_set_mode,
>
> - .get_current_limit = da9055_buck_get_current_limit,
> - .set_current_limit = da9055_buck_set_current_limit,
> + .get_current_limit = regulator_get_current_limit_regmap,
> + .set_current_limit = regulator_set_current_limit_regmap,
>
> .get_voltage_sel = da9055_regulator_get_voltage_sel,
> .set_voltage_sel = da9055_regulator_set_voltage_sel,
> @@ -407,6 +376,10 @@ static const struct regulator_ops da9055_ldo_ops = {
> .uV_step = (step) * 1000,\
> .linear_min_sel = (voffset),\
> .owner = THIS_MODULE,\
> + .curr_table = da9055_current_limits,\
> + .n_current_limits = ARRAY_SIZE(da9055_current_limits),\
> + .csel_reg = DA9055_REG_BUCK_LIM,\
> + .csel_mask = (mbits),\
Hi Axel,
Thanks.
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH 04/11] regulator: da9210: Convert to use regulator_set/get_current_limit_regmap
On 28 February 2019 13:40, Axel Lin wrote:
> Subject: [PATCH 04/11] regulator: da9210: Convert to use
> regulator_set/get_current_limit_regmap
[...]
> @@ -52,8 +48,8 @@ static const struct regulator_ops da9210_buck_ops = {
> .set_voltage_sel = regulator_set_voltage_sel_regmap,
> .get_voltage_sel = regulator_get_voltage_sel_regmap,
> .list_voltage = regulator_list_voltage_linear,
> - .set_current_limit = da9210_set_current_limit,
> - .get_current_limit = da9210_get_current_limit,
> + .set_current_limit = regulator_set_current_limit_regmap,
> + .get_current_limit = regulator_get_current_limit_regmap,
> };
Hi Axel,
Thanks,
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH] regulator: da9062: Use struct_size() in devm_kzalloc()
Hi Gustavo,
On 23 February 2019 01:55, Gustavo A. R. Silva wrote:
> Subject: [PATCH] regulator: da9062: Use struct_size() in devm_kzalloc()
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
Acked-by: Steve Twiss
Thanks,
Regards,
Steve
>
> instance = alloc(struct_size(instance, entry, count), GFP_KERNEL)
>
> Notice that, in this case, variable size is not necessary, hence it is
> removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/regulator/da9062-regulator.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-
> regulator.c
> index 4c5d6ad853f8..b064d8a19d4c 100644
> --- a/drivers/regulator/da9062-regulator.c
> +++ b/drivers/regulator/da9062-regulator.c
> @@ -992,7 +992,6 @@ static int da9062_regulator_probe(struct platform_device
> *pdev)
> struct regulator_config config = { };
> const struct da9062_regulator_info *rinfo;
> int irq, n, ret;
> - size_t size;
> int max_regulators;
>
> switch (chip->chip_type) {
> @@ -1010,9 +1009,8 @@ static int da9062_regulator_probe(struct
> platform_device *pdev)
> }
>
> /* Allocate memory required by usable regulators */
> - size = sizeof(struct da9062_regulators) +
> - max_regulators * sizeof(struct da9062_regulator);
> - regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> + regulators = devm_kzalloc(&pdev->dev, struct_size(regulators, regulator,
> + max_regulators), GFP_KERNEL);
> if (!regulators)
> return -ENOMEM;
>
> --
> 2.20.1
RE: [PATCH] regulator: da9063: Use struct_size() in devm_kzalloc()
Hi Gustavo,
On 21 February 2019 17:57, Gustavo A. R. Silva wrote:
> Subject: [PATCH] regulator: da9063: Use struct_size() in devm_kzalloc()
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
Acked-by: Steve Twiss
Thanks,
Regards,
Steve
RE: [PATCH 1/2] regulator: da9062: Select maximum current in specific range for set_current_limit
Hi Axel,
On 19 February 2019 13:31, Axel Lin wrote:
> To: Mark Brown
> Subject: [PATCH 1/2] regulator: da9062: Select maximum current in specific
> range for set_current_limit
>
> Selecting the minimal value is only true for voltage regulators.
> For current regulators the maximum in the given range should be
> selected instead.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/da9062-regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-
> regulator.c
> index d06e9600fa18..4c5d6ad853f8 100644
> --- a/drivers/regulator/da9062-regulator.c
> +++ b/drivers/regulator/da9062-regulator.c
> @@ -126,7 +126,7 @@ static int da9062_set_current_limit(struct regulator_dev
> *rdev,
> const struct da9062_regulator_info *rinfo = regl->info;
> int n, tval;
>
> - for (n = 0; n < rinfo->n_current_limits; n++) {
> + for (n = rinfo->n_current_limits - 1; n >= 0; n--) {
> tval = rinfo->current_limits[n];
> if (tval >= min_ua && tval <= max_ua)
> return regmap_field_write(regl->ilimit, n);
> --
> 2.17.1
Acked-by: Steve Twiss
Thanks and regards,
Steve
RE: [PATCH 2/2] regulator: da9063: Select maximum current in specific range for set_current_limit
On 19 February 2019 13:31, Axel Lin wrote:
> To: Mark Brown
> Subject: [PATCH 2/2] regulator: da9063: Select maximum current in specific
> range for set_current_limit
>
> Selecting the minimal value is only true for voltage regulators.
> For current regulators the maximum in the given range should be
> selected instead.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/da9063-regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-
> regulator.c
> index 85c45577bad1..a83bbd3dbc37 100644
> --- a/drivers/regulator/da9063-regulator.c
> +++ b/drivers/regulator/da9063-regulator.c
> @@ -167,7 +167,7 @@ static int da9063_set_current_limit(struct regulator_dev
> *rdev,
> const struct da9063_regulator_info *rinfo = regl->info;
> int n, tval;
>
> - for (n = 0; n < rinfo->n_current_limits; n++) {
> + for (n = rinfo->n_current_limits - 1; n >= 0; n--) {
> tval = rinfo->current_limits[n];
> if (tval >= min_uA && tval <= max_uA)
> return regmap_field_write(regl->ilimit, n);
Acked-by: Steve Twiss
RE: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
Hi Geert,
On 29 December 2018 11:14 Geert Uytterhoeven wrote:
> To: Matti Vaittinen
> Cc: mazziesacco...@gmail.com; Mark Brown ; Greg KH
> ; Rafael J. Wysocki ; Linux
> Kernel Mailing List ; Support Opensource
>
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type
> settings
>
> Hi Matti,
>
> On Thu, Dec 27, 2018 at 9:44 AM Matti Vaittinen
> wrote:
> > Do not return error if irq-type setting is requested for
> > controlloer which does not support this. This is how
> > regmap-irq has previously handled the undupported type
> > settings and existing drivers seem to be upset if failure
> > is now reported.
> >
> > Fixes: 1c2928e3e321 ("regmap: regmap-irq/gpio-max77620: add level-irq
> > support")
> > Signed-off-by: Matti Vaittinen
>
> Reported-by: Geert Uytterhoeven
>
> > ---
> >
> > Geert reported that 1c2928e3e321 breaks da9063-rtc on the Renesas
> > Koelsch board:
> >
> >
> https://lore.kernel.org/lkml/20181227075648.GB2461@localhost.localdomain/T/#
> m194616cc88d7b4c2a78f7ce07907608fdb64a092
> >
> > Geert, do you know if anyone vould to test this?
>
> Thanks, that seems to fix the issue with da9063-rtc.
>
> I don't know how to trigger an actual interrupt, though.
>
> > --- a/drivers/base/regmap/regmap-irq.c
> > +++ b/drivers/base/regmap/regmap-irq.c
> > @@ -258,7 +258,7 @@ static int regmap_irq_set_type(struct irq_data *data,
> unsigned int type)
> > const struct regmap_irq_type *t = &irq_data->type;
> >
> > if ((t->types_supported & type) != type)
> > - return -ENOTSUPP;
> > + return 0;
> >
> > reg = t->type_reg_offset / map->reg_stride;
> >
> > --
> > 2.14.3
>
I've run this patch on the DA9063 set-up I have here. And this fixes the
problem.
Acked-by: Steve Twiss
Tested-by: Steve Twiss
Regards,
Steve
My previous report using the unmodified v5.0-rc1 Linux kernel is here:
https://lore.kernel.org/lkml/6ed8e3b22081a4459dac7699f3695fb7022179f...@sw-ex-mbx02.diasemi.com
This v5.0-rc1 Linux kernel failed to allow IRQs for the MFD cells in the
DA9063. But, altering the v5.0-rc1 kernel with the patch given above (to
return 0 instead of -ENOTSUPP in regmap-irq.c), fixes the problem.
A cut-down console output for this result is given below.
--- 8< ---
[...]
da9063 1-0058: Device detected (chip-ID: 0x61, var-ID: 0x60)
[...]
da9063-onkey da9063-onkey: DMA mask not set
input: da9063-onkey as
/devices/soc0/soc/210.aips-bus/21a4000.i2c/i2c-1/1-0058/da9063-onkey/input/input2
da9063-rtc da9063-rtc: DMA mask not set
da9063-rtc da9063-rtc: registered as rtc0
[...]
da9063-watchdog da9063-watchdog: DMA mask not set
[...]
da9063-rtc da9063-rtc: setting system clock to 2000-01-01T00:00:00 UTC
(946684800)
[...]
--- 8< ---
and the results of setting an RTC alarm and waiting for the interrupt outputs
the following:
--- 8< ---
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use BB RTC alarm functional test for TEST with
DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01
00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01
00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of
15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the
alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01
00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01
00:00:15 (+15 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of
25 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the
alarm happened at 2000-01-01 00:00:15
[PASS] Finished running DA9063 set alarm tests for RTC { 1 } on TEST
> cat /proc/interrupts | grep da9063
249: 2 0 0 0 gpio-mxc 11 Level
da9063-irq
302: 0 0 0 0 da9063-irq 0 Level ONKEY
303: 0 0 0 2 da9063-irq 1 Level ALARM
310: 0 0 0 0 da9063-irq 8 Level
LDO_LIM
> uname -a
Linux test 5.0.0-rc1 #1 SMP Tue Jan 8 09:39:30 GMT 2019 armv7l GNU/Linux
--- 8< ---
RE: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
Hi Geert,
On 04 January 2019 at 15:48, Geert Uytterhoeven wrote:
> To: Steve Twiss
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type
> settings
>
> ()Hi Steve,
>
> On Wed, Jan 2, 2019 at 4:31 PM Steve Twiss
> wrote:
> > On 01 January 2019 @17:36, Geert Uytterhoeven wrote:
> > > Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type
> > > settings
> > > On Mon, Dec 31, 2018 at 8:14 PM Mark Brown wrote:
> > > > On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > > > > Geert, do you know if anyone vould to test this?
> > > > > Thanks, that seems to fix the issue with da9063-rtc.
> > > > > I don't know how to trigger an actual interrupt, though.
> > > > If it's a RTC does it have an alarm you can set?
> > > That's what I had expected, too, but there is no alarm file under
> > > /sys/class/rtc/.
> >
> > To communicate with the DA9063 RTC I am use ioctl function calls
> >
> > - RTC_SET_TIME
> > - RTC_RD_TIME
> > - RTC_ALM_SET
> > - RTC_ALM_READ
> > - RTC_AIE_ON
> > - RTC_AIE_OFF
> >
> > -
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rtc.txt
> > -
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/rtc
> >
> > Although I don't use the test programs found in Linux, the ioctl calls I
> > make are shown in the Linux selftests. I believe that Alexandre Belloni
> > updated the RTC tests recently -- but I am not up to date with the latest.
> >
> > git show
> d8da8665e8e34c14f9b20fe3f21dff29b24cbf02:tools/testing/selftests/rtc/rtctest.c
Okay. So, I've got my own RTC tests which I wrote using the ioctl()
commands. I've not used the rtctest from the kernel before.
Also, I would need to look more closely to give you a better reply
for your results.
> root@koelsch:~# tools/testing/selftests/rtc/rtctest
> [==] Running 5 tests from 2 test cases.
> [ RUN ] rtc.date_read
> rtctest.c:49:rtc.date_read:Current RTC date/time is 04/01/2019 14:44:25.
> [ OK ] rtc.date_read
> [ RUN ] rtc.uie_read
> [ OK ] rtc.uie_read
> [ RUN ] rtc.uie_select
> rtctest.c:98:rtc.uie_select:Expected 0 (0) != rc (0)
> rtc.uie_select: Test terminated by assertion
> [ FAIL ] rtc.uie_select
> [ RUN ] rtc.alarm_alm_set
> rtctest.c:137:rtc.alarm_alm_set:Alarm time now set to 14:47:23.
> rtctest.c:148:rtc.alarm_alm_set:Expected 0 (0) != rc (0)
> rtc.alarm_alm_set: Test failed at step #5
> [ FAIL ] rtc.alarm_alm_set
> [ RUN ] rtc.alarm_wkalm_set
> rtctest.c:198:rtc.alarm_wkalm_set:Alarm time now set to 04/01/2019 14:47:28.
> rtctest.c:205:rtc.alarm_wkalm_set:Expected 0 (0) != rc (0)
> rtctest.c:214:rtc.alarm_wkalm_set:Expected new (1546613934) == secs
> (1546613248)
> rtc.alarm_wkalm_set: Test terminated by assertion
> [ FAIL ] rtc.alarm_wkalm_set
> [==] 2 / 5 tests passed.
> [ FAILED ]
> root@koelsch:~#
>
> No interrupt fired, as witnessed by /proc/interrupts, and the pr_info()
> I had added to da9063_alarm_event().
>
> Note that rtctest behaves the same before the regmap irq breakage,
> so this is not a recent regression...
I've just incrementally rebased from v4.18 through to v4.20 and I see the
IRQ working for the DA9063 alarm on my test system. I've not applied any extra
patches and the results below are for the following vanilla kernels: v4.18,
v4.19, v4.20.
The next results are only for regressions in the RTC alarm for the DA9063. I
only ran one simple "TEST" to create an output for you (although I did it twice
to produce two IRQs):
--- 8< ---
v4.18
-
> cat *.res
[PASS] Set RTC alarms functional test for TEST with DA9063-TEST
[PASS] Setting test type to use RTC alarm functional test for TEST with
DA9063-TEST
[PASS] Running set alarm tests for RTC { 1 }
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01
00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01
00:00:05 (+5 secs into the future)
[PASS] Setting the listener on da9063-rtc then waiting for elapsed timeout of
15 seconds...
[PASS] The alarm was triggered on da9063-rtc within the expected time and the
alarm happened at 2000-01-01 00:00:05
[PASS] Running test for test_rtc_prog_set_simple_alarm_seconds()
[PASS] Setting the current date and time from the da9063-rtc as 2000-01-01
00:00:00
[PASS] Setting the alarm date and time from the da9063-rtc as 2000-01-01
00:00:15 (+15 secs into the future)
[PASS] Setting t
RE: [PATCH] regmap: regmap-irq: silently ignore unsupported type settings
Hi Geert,
On 01 January 2019 @17:36, Geert Uytterhoeven wrote:
> Subject: Re: [PATCH] regmap: regmap-irq: silently ignore unsupported type
> settings
> On Mon, Dec 31, 2018 at 8:14 PM Mark Brown wrote:
> > On Sat, Dec 29, 2018 at 12:13:32PM +0100, Geert Uytterhoeven wrote:
> > > > Geert, do you know if anyone vould to test this?
> >
> > > Thanks, that seems to fix the issue with da9063-rtc.
> >
> > > I don't know how to trigger an actual interrupt, though.
> >
> > If it's a RTC does it have an alarm you can set?
>
> That's what I had expected, too, but there is no alarm file under
> /sys/class/rtc/.
>
> Gr{oetje,eeting}s,
>
> Geert
To communicate with the DA9063 RTC I am use ioctl function calls
- RTC_SET_TIME
- RTC_RD_TIME
- RTC_ALM_SET
- RTC_ALM_READ
- RTC_AIE_ON
- RTC_AIE_OFF
-
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/rtc.txt
-
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/rtc
Although I don't use the test programs found in Linux, the ioctl calls I
make are shown in the Linux selftests. I believe that Alexandre Belloni
updated the RTC tests recently -- but I am not up to date with the latest.
git show
d8da8665e8e34c14f9b20fe3f21dff29b24cbf02:tools/testing/selftests/rtc/rtctest.c
Regards,
Steve
RE: [PATCH 21/30] hwmon: (da9052-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR variants
Hi Guenter,
On 10 December 2018 22:09, Guenter Roeck wrote:
> Subject: [PATCH 21/30] hwmon: (da9052-hwmon) Use permission specific
> SENSOR[_DEVICE]_ATTR variants
>
> Use SENSOR[_DEVICE]_ATTR[_2]_{RO,RW,WO} to simplify the source code,
> to improve readbility, and to reduce the chance of inconsistencies.
>
> Also replace any remaining S_ in the driver with octal values.
>
> The conversion was done automatically with coccinelle. The semantic patches
> and the scripts used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches/hwmon/.
>
> This patch does not introduce functional changes. It was verified by
> compiling the old and new files and comparing text and data sizes.
>
> Cc: Support Opensource
> Signed-off-by: Guenter Roeck
> ---
> drivers/hwmon/da9052-hwmon.c | 105
Thanks,
I am assuming this previous patch [01/10] hwmon: Introduce
SENSOR_DEVICE_ATTR_{RO,RW,WO} and variants
from this set, https://patchwork.kernel.org/patch/9489915/ and,
+ #define SENSOR_DEVICE_ATTR_RO(_name, _func, _index)\
+SENSOR_DEVICE_ATTR(_name, 0444, _func##_show, NULL, _index)
Acked-by: Steve Twiss
Regards,
Steve
> ---
> 1 file changed, 39 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c
> index a973eb6a2890..8ec5bf4ce392 100644
> --- a/drivers/hwmon/da9052-hwmon.c
> +++ b/drivers/hwmon/da9052-hwmon.c
> @@ -87,7 +87,7 @@ static inline int da9052_disable_vddout_channel(struct
> da9052 *da9052)
>DA9052_ADCCONT_AUTOVDDEN, 0);
> }
>
> -static ssize_t da9052_read_vddout(struct device *dev,
> +static ssize_t da9052_vddout_show(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> @@ -119,7 +119,7 @@ static ssize_t da9052_read_vddout(struct device *dev,
> return ret;
> }
>
> -static ssize_t da9052_read_ich(struct device *dev,
> +static ssize_t da9052_ich_show(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> @@ -133,7 +133,7 @@ static ssize_t da9052_read_ich(struct device *dev,
> return sprintf(buf, "%d\n", DIV_ROUND_CLOSEST(ret * 39, 10));
> }
>
> -static ssize_t da9052_read_tbat(struct device *dev,
> +static ssize_t da9052_tbat_show(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> @@ -141,7 +141,7 @@ static ssize_t da9052_read_tbat(struct device *dev,
> return sprintf(buf, "%d\n", da9052_adc_read_temp(hwmon->da9052));
> }
>
> -static ssize_t da9052_read_vbat(struct device *dev,
> +static ssize_t da9052_vbat_show(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> @@ -154,7 +154,7 @@ static ssize_t da9052_read_vbat(struct device *dev,
> return sprintf(buf, "%d\n", volt_reg_to_mv(ret));
> }
>
> -static ssize_t da9052_read_misc_channel(struct device *dev,
> +static ssize_t da9052_misc_channel_show(struct device *dev,
> struct device_attribute *devattr,
> char *buf)
> {
> @@ -242,9 +242,8 @@ static ssize_t __da9052_read_tsi(struct device *dev, int
> channel)
> return da9052_get_tsi_result(hwmon, channel);
> }
>
> -static ssize_t da9052_read_tsi(struct device *dev,
> -struct device_attribute *devattr,
> -char *buf)
> +static ssize_t da9052_tsi_show(struct device *dev,
> +struct device_attribute *devattr, char *buf)
> {
> struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> int channel = to_sensor_dev_attr(devattr)->index;
> @@ -260,7 +259,7 @@ static ssize_t da9052_read_tsi(struct device *dev,
> return sprintf(buf, "%d\n", input_tsireg_to_mv(hwmon, ret));
> }
>
> -static ssize_t da9052_read_tjunc(struct device *dev,
> +static ssize_t da9052_tjunc_show(struct device *dev,
>struct device_attribute *devattr, char *buf)
> {
> struct da9052_hwmon *hwmon = dev_get_drvdata(dev);
> @@ -282,7 +281,7 @@ static ssize_t da9052_read_tjunc(struct device *dev,
> return sprintf(buf, "%d\n", 1708 * (tjunc - toffset) - 108800);
> }
>
> -static ssize_t da9052_read_vbbat(struct device *d
RE: [PATCH 22/30] hwmon: (da9055-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR variants
Hi Guenter,
On 10 December 2018 22:09, Guenter Roeck wrote:
> Subject: [PATCH 22/30] hwmon: (da9055-hwmon) Use permission specific
> SENSOR[_DEVICE]_ATTR variants
>
> Use SENSOR[_DEVICE]_ATTR[_2]_{RO,RW,WO} to simplify the source code,
> to improve readbility, and to reduce the chance of inconsistencies.
>
> Also replace any remaining S_ in the driver with octal values.
>
> The conversion was done automatically with coccinelle. The semantic patches
> and the scripts used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches/hwmon/.
>
> This patch does not introduce functional changes. It was verified by
> compiling the old and new files and comparing text and data sizes.
>
> Cc: Support Opensource
> Signed-off-by: Guenter Roeck
> ---
Thanks,
Same again.
Acked-by: Steve Twiss
... with the patch [01/10] hwmon: Introduce SENSOR_DEVICE_ATTR_{RO,RW,WO} and
variants
https://patchwork.kernel.org/patch/9489915/
Regards,
Steve
> drivers/hwmon/da9055-hwmon.c | 41 -
> 1 file changed, 16 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/hwmon/da9055-hwmon.c b/drivers/hwmon/da9055-hwmon.c
> index f6e159cabe23..4de6de683908 100644
> --- a/drivers/hwmon/da9055-hwmon.c
> +++ b/drivers/hwmon/da9055-hwmon.c
> @@ -140,8 +140,9 @@ static int da9055_disable_auto_mode(struct da9055
> *da9055, int channel)
> return da9055_reg_update(da9055, DA9055_REG_ADC_CONT, 1 <<
> channel, 0);
> }
>
> -static ssize_t da9055_read_auto_ch(struct device *dev,
> - struct device_attribute *devattr, char *buf)
> +static ssize_t da9055_auto_ch_show(struct device *dev,
> +struct device_attribute *devattr,
> +char *buf)
> {
> struct da9055_hwmon *hwmon = dev_get_drvdata(dev);
> int ret, adc;
> @@ -176,7 +177,7 @@ static ssize_t da9055_read_auto_ch(struct device *dev,
> return ret;
> }
>
> -static ssize_t da9055_read_tjunc(struct device *dev,
> +static ssize_t da9055_tjunc_show(struct device *dev,
>struct device_attribute *devattr, char *buf)
> {
> struct da9055_hwmon *hwmon = dev_get_drvdata(dev);
> @@ -199,34 +200,24 @@ static ssize_t da9055_read_tjunc(struct device *dev,
> + 3076332, 1));
> }
>
> -static ssize_t show_label(struct device *dev,
> +static ssize_t label_show(struct device *dev,
> struct device_attribute *devattr, char *buf)
> {
> return sprintf(buf, "%s\n",
> input_names[to_sensor_dev_attr(devattr)->index]);
> }
>
> -static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, da9055_read_auto_ch, NULL,
> - DA9055_ADC_VSYS);
> -static SENSOR_DEVICE_ATTR(in0_label, S_IRUGO, show_label, NULL,
> - DA9055_ADC_VSYS);
> -static SENSOR_DEVICE_ATTR(in1_input, S_IRUGO, da9055_read_auto_ch, NULL,
> - DA9055_ADC_ADCIN1);
> -static SENSOR_DEVICE_ATTR(in1_label, S_IRUGO, show_label, NULL,
> - DA9055_ADC_ADCIN1);
> -static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, da9055_read_auto_ch, NULL,
> - DA9055_ADC_ADCIN2);
> -static SENSOR_DEVICE_ATTR(in2_label, S_IRUGO, show_label, NULL,
> - DA9055_ADC_ADCIN2);
> -static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, da9055_read_auto_ch, NULL,
> - DA9055_ADC_ADCIN3);
> -static SENSOR_DEVICE_ATTR(in3_label, S_IRUGO, show_label, NULL,
> - DA9055_ADC_ADCIN3);
> -
> -static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, da9055_read_tjunc,
> NULL,
> - DA9055_ADC_TJUNC);
> -static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL,
> - DA9055_ADC_TJUNC);
> +static SENSOR_DEVICE_ATTR_RO(in0_input, da9055_auto_ch,
> DA9055_ADC_VSYS);
> +static SENSOR_DEVICE_ATTR_RO(in0_label, label, DA9055_ADC_VSYS);
> +static SENSOR_DEVICE_ATTR_RO(in1_input, da9055_auto_ch,
> DA9055_ADC_ADCIN1);
> +static SENSOR_DEVICE_ATTR_RO(in1_label, label, DA9055_ADC_ADCIN1);
> +static SENSOR_DEVICE_ATTR_RO(in2_input, da9055_auto_ch,
> DA9055_ADC_ADCIN2);
> +static SENSOR_DEVICE_ATTR_RO(in2_label, label, DA9055_ADC_ADCIN2);
> +static SENSOR_DEVICE_ATTR_RO(in3_input, da9055_auto_ch,
> DA9055_ADC_ADCIN3);
> +static SENSOR_DEVICE_ATTR_RO(in3_label, label, DA9055_ADC_ADCIN3);
> +
> +static SENSOR_DEVICE_ATTR_RO(temp1_input, da9055_tjunc,
> DA9055_ADC_TJUNC);
> +static SENSOR_DEVICE_ATTR_RO(temp1_label, label, DA9055_ADC_TJUNC);
>
> static struct attribute *da9055_attrs[] = {
> &sensor_dev_attr_in0_input.dev_attr.attr,
> --
> 2.7.4
RE: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
Sorry typo. I meant modular. On 05 December 2018 12:02, Steve Twiss wrote: > Subject: RE: [PATCH v2 00/22] mfd: demodularization of non-modular drivers > > Hi Paul, > > On 03 December 2018 04:23, Paul Gortmaker wrote: > > > Subject: [PATCH v2 00/22] mfd: demodularization of non-modular drivers > > > > [v1 --> v2: add some more commits as requested by Lee (MFD maintainer), > > update the 00/NN text; re-do build and link testing on new linux-next. ] > > > > This group of MFD drivers are all controlled by "bool" Kconfig settings, > > but contain various amounts of largely pointless uses of infrastructure > > related to modular operations, even though they can't be built modular. > > > > We can easily remove/replace all of it. We are trying to make driver > > code consistent with the Makefiles/Kconfigs that control them. > > For the DA9052 and DA9055, changes: > > - drivers/mfd/da9052-core.c | 11 --- > - drivers/mfd/da9052-i2c.c | 22 ++--- > - drivers/mfd/da9052-irq.c | 1 - > - drivers/mfd/da9052-spi.c | 22 ++--- > - drivers/mfd/da9055-core.c | 13 ++--- > - drivers/mfd/da9055-i2c.c | 24 ++- > > The responsibility can fall back to Dialog for these changes. We will > submit Kconfig patches for these and make them explicitly non-modular. Sorry. I meant modular. > This will remove the ambiguity caused by the Kconfig bool options. > > Regards, > Steve > > > This > > means not using modular functions/macros for drivers that can never be > > built as a module. Some of the downfalls this oversight leads to are: > > > > (1) it is easy to accidentally write unused module_exit and remove code > > (2) it can be misleading when reading the source, thinking it can be > > modular when the Makefile and/or Kconfig prohibit it > > (3) it requires the include of the module.h header file which in turn > > includes nearly everything else, thus adding a lot of CPP overhead. > > (4) it gets copied/replicated into other drivers and spreads quickly. > > > > What we see in current drivers falls into one or more of the following > > categories: > > > > 1) include of when it simply isn't needed > > > > 2) Use of MODULE_LICENSE, MODULE_DEVICE_TABLE, MODULE_AUTHOR etc. > >macros that are no-ops for non-modular drivers. > > > > 3) Creation of a module_exit() function that will be compiled and > >linked in but never actually called for non-modular drivers. > > > > 4) Addition of a platform_driver ".remove" function that is bound > >into the struct but will never be called for non-module use cases. > > > > Solution to #1 --> #3 is simple ; we just delete the related code. > > > > The solution to #4 is similar - we delete the ".remove" function and > > the binding into the platform_driver struct. However, since the same > > ".remove" function could also be triggered by an "unbind" (such as for > > pass-through of a device to a guest instance) - so we also explicitly > > disable any unbind for the driver. > > > > The unbind mask allows us to ensure we will see if there was some odd > > corner case out there that was relying on it. Typically it would be a > > multi-port ethernet card passing a port through to a guest, so a > > sensible use case in MFD drivers seems highly unlikely. This same > > solution has already been used in multiple other mainline subsystems. > > > > Build testing was done on drivers/mfd for allyesconfig on x86_64, ARM > > and ARM-64 on a recent linux-next checkout. > > > > Paul. > > > > --- > > > > Cc: Arnd Bergmann > > Cc: Cory Maccarrone > > Cc: David Dajun Chen > > Cc: Dong Aisheng > > Cc: Eric Miao > > Cc: Graeme Gregory > > Cc: Guennadi Liakhovetski > > Cc: Haojian Zhuang > > Cc: Jin Park > > Cc: Jorge Eduardo Candelaria > > Cc: Laxman Dewangan > > Cc: Lee Jones > > Cc: Linus Walleij > > Cc: Mark Brown > > Cc: Mattias Nilsson > > Cc: Michael Hennerich > > Cc: Mike Rapoport > > Cc: Tony Lindgren > > Cc: Venu Byravarasu > > Cc: linux-o...@vger.kernel.org > > Cc: patc...@opensource.cirrus.com > > Cc: Support Opensource > > > > > > Paul Gortmaker (22): > > mfd: aat2870-core: Make it explicitly non-modular > > mfd: adp5520: Make it explicitly non-modular > > mfd: as3711: Make it explic
RE: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
Hi Paul, On 03 December 2018 04:23, Paul Gortmaker wrote: > Subject: [PATCH v2 00/22] mfd: demodularization of non-modular drivers > > [v1 --> v2: add some more commits as requested by Lee (MFD maintainer), > update the 00/NN text; re-do build and link testing on new linux-next. ] > > This group of MFD drivers are all controlled by "bool" Kconfig settings, > but contain various amounts of largely pointless uses of infrastructure > related to modular operations, even though they can't be built modular. > > We can easily remove/replace all of it. We are trying to make driver > code consistent with the Makefiles/Kconfigs that control them. For the DA9052 and DA9055, changes: - drivers/mfd/da9052-core.c | 11 --- - drivers/mfd/da9052-i2c.c | 22 ++--- - drivers/mfd/da9052-irq.c | 1 - - drivers/mfd/da9052-spi.c | 22 ++--- - drivers/mfd/da9055-core.c | 13 ++--- - drivers/mfd/da9055-i2c.c | 24 ++- The responsibility can fall back to Dialog for these changes. We will submit Kconfig patches for these and make them explicitly non-modular. This will remove the ambiguity caused by the Kconfig bool options. Regards, Steve > This > means not using modular functions/macros for drivers that can never be > built as a module. Some of the downfalls this oversight leads to are: > > (1) it is easy to accidentally write unused module_exit and remove code > (2) it can be misleading when reading the source, thinking it can be > modular when the Makefile and/or Kconfig prohibit it > (3) it requires the include of the module.h header file which in turn > includes nearly everything else, thus adding a lot of CPP overhead. > (4) it gets copied/replicated into other drivers and spreads quickly. > > What we see in current drivers falls into one or more of the following > categories: > > 1) include of when it simply isn't needed > > 2) Use of MODULE_LICENSE, MODULE_DEVICE_TABLE, MODULE_AUTHOR etc. >macros that are no-ops for non-modular drivers. > > 3) Creation of a module_exit() function that will be compiled and >linked in but never actually called for non-modular drivers. > > 4) Addition of a platform_driver ".remove" function that is bound >into the struct but will never be called for non-module use cases. > > Solution to #1 --> #3 is simple ; we just delete the related code. > > The solution to #4 is similar - we delete the ".remove" function and > the binding into the platform_driver struct. However, since the same > ".remove" function could also be triggered by an "unbind" (such as for > pass-through of a device to a guest instance) - so we also explicitly > disable any unbind for the driver. > > The unbind mask allows us to ensure we will see if there was some odd > corner case out there that was relying on it. Typically it would be a > multi-port ethernet card passing a port through to a guest, so a > sensible use case in MFD drivers seems highly unlikely. This same > solution has already been used in multiple other mainline subsystems. > > Build testing was done on drivers/mfd for allyesconfig on x86_64, ARM > and ARM-64 on a recent linux-next checkout. > > Paul. > > --- > > Cc: Arnd Bergmann > Cc: Cory Maccarrone > Cc: David Dajun Chen > Cc: Dong Aisheng > Cc: Eric Miao > Cc: Graeme Gregory > Cc: Guennadi Liakhovetski > Cc: Haojian Zhuang > Cc: Jin Park > Cc: Jorge Eduardo Candelaria > Cc: Laxman Dewangan > Cc: Lee Jones > Cc: Linus Walleij > Cc: Mark Brown > Cc: Mattias Nilsson > Cc: Michael Hennerich > Cc: Mike Rapoport > Cc: Tony Lindgren > Cc: Venu Byravarasu > Cc: linux-o...@vger.kernel.org > Cc: patc...@opensource.cirrus.com > Cc: Support Opensource > > > Paul Gortmaker (22): > mfd: aat2870-core: Make it explicitly non-modular > mfd: adp5520: Make it explicitly non-modular > mfd: as3711: Make it explicitly non-modular > mfd: da903x: Make it explicitly non-modular > mfd: da9052-*: Make it explicitly non-modular > mfd: da9055-i2c: Make it explicitly non-modular > mfd: da9055-core: make it explicitly non-modular > mfd: db8500-prcmu: drop unused MODULE_ tags from non-modular code > mfd: htc-i2cpld: Make it explicitly non-modular > mfd: max8925-core: drop unused MODULE_ tags from non-modular code > mfd: rc5t583: Make it explicitly non-modular > mfd: sta2x11: drop unused MODULE_ tags from non-modular code > mfd: syscon: Make it explicitly non-modular > mfd: tps65090: Make it explicitly non-modular > mfd: tps65910: Make it explicitly non-modular > mfd: tps80031: Make it explicitly non-modular > mfd: wm831x-spi: Make it explicitly non-modular > mfd: wm831x-i2c: Make it explicitly non-modular > mfd: wm831x-core: drop unused MODULE_ tags from non-modular code > mfd: wm8350-i2c: Make it explicitly non-modular > mfd: wm8350-core: drop unused MODULE_ tags from non-modular code > mfd: wm8
RE: [PATCH] Input: add error handling for da9052_reg_write
On 11 June 2018 18:30 wrote Dmitry Torokhov
> Subject: Re: [PATCH] Input: add error handling for da9052_reg_write
>
> Hi Zhouyang,
>
> On Mon, Jun 11, 2018 at 01:23:39PM +0800, Zhouyang Jia wrote:
> > When da9052_reg_write fails, the lack of error-handling code may
> > cause unexpected results.
> >
> > This patch adds error-handling code after calling da9052_reg_write.
> >
> > Signed-off-by: Zhouyang Jia
> > ---
> > drivers/input/touchscreen/da9052_tsi.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/touchscreen/da9052_tsi.c
> b/drivers/input/touchscreen/da9052_tsi.c
> > index b5dfd594..60c82a0 100644
> > --- a/drivers/input/touchscreen/da9052_tsi.c
> > +++ b/drivers/input/touchscreen/da9052_tsi.c
> > @@ -319,8 +319,11 @@ static int da9052_ts_probe(struct platform_device
> > *pdev)
> > static int da9052_ts_remove(struct platform_device *pdev)
> > {
> > struct da9052_tsi *tsi = platform_get_drvdata(pdev);
> > + int error;
> >
> > - da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
> > + error = da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
> > + if (error < 0)
> > + return error;
>
> No, this does not help anything. The remove() action must not fail
> (really, having it return an int and not void was an API mistake made
> long time ago), and thus returning early in and event of error failing
> to communicate with the device is a mistake. You really want to release
> the interrupts and memory and unregister input device before returning.
>
> >
> > da9052_free_irq(tsi->da9052, DA9052_IRQ_TSIREADY, tsi);
> > da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
> > --
> > 2.7.4
> >
script?
https://patchwork.kernel.org/project/LKML/list/?submitter=181001
RE: [PATCH v3 07/10] mfd: da9063: Add custom IRQ map for DA9063L
Hi Marek,
Thanks.
On 02 June 2018 11:12, Marek Vasut wrote,
> Subject: [PATCH v3 07/10] mfd: da9063: Add custom IRQ map for DA9063L
>
> While the datasheet for DA9063L (2v1, 23-Mar-2017) lists the RTC register
> block, the DA9063L does not have an RTC. Add custom IRQ map for DA9063L to
> ignore the Alarm and Tick IRQs from the PMIC.
I've added a request to remove the RTC references from the DA9063L datasheet.
Adding that first part to the sentence in the commit log: "While the datasheet
for DA9063L
(2v1, 23-Mar-2017) lists the RTC register block" is just pointing out an
ambiguity from the
datasheet since the it also identifies those registers in Table 102 on page 126
as
"Reserved".
I would like to suggest, the commit log entry: "Add custom IRQ map for DA9063L
to ignore
the Alarm and Tick IRQs from the PMIC".
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: Steve Twiss
> Cc: Wolfram Sang
> Cc: linux-renesas-...@vger.kernel.org
> ---
> V3: New patch
> ---
> drivers/mfd/da9063-irq.c | 55
> ++--
> 1 file changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mfd/da9063-irq.c b/drivers/mfd/da9063-irq.c
> index 5b406ecfc14a..b6a88861cc2e 100644
> --- a/drivers/mfd/da9063-irq.c
> +++ b/drivers/mfd/da9063-irq.c
> @@ -74,8 +74,55 @@ static const struct regmap_irq_chip da9063_irq_chip = {
> .init_ack_masked = true,
> };
>
> +static const struct regmap_irq da9063l_irqs[] = {
> + /* DA9063 event A register */
> + REGMAP_IRQ_REG(DA9063_IRQ_ONKEY,
> DA9063_REG_EVENT_A_OFFSET, DA9063_M_ONKEY),
> + REGMAP_IRQ_REG(DA9063_IRQ_ADC_RDY,
> DA9063_REG_EVENT_A_OFFSET, DA9063_M_ADC_RDY),
> + REGMAP_IRQ_REG(DA9063_IRQ_SEQ_RDY,
> DA9063_REG_EVENT_A_OFFSET, DA9063_M_SEQ_RDY),
> + /* DA9063 event B register */
> + REGMAP_IRQ_REG(DA9063_IRQ_WAKE,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_WAKE),
> + REGMAP_IRQ_REG(DA9063_IRQ_TEMP,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_TEMP),
> + REGMAP_IRQ_REG(DA9063_IRQ_COMP_1V2,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_COMP_1V2),
> + REGMAP_IRQ_REG(DA9063_IRQ_LDO_LIM,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_LDO_LIM),
> + REGMAP_IRQ_REG(DA9063_IRQ_REG_UVOV,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_UVOV),
> + REGMAP_IRQ_REG(DA9063_IRQ_DVC_RDY,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_DVC_RDY),
> + REGMAP_IRQ_REG(DA9063_IRQ_VDD_MON,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_VDD_MON),
> + REGMAP_IRQ_REG(DA9063_IRQ_WARN,
> DA9063_REG_EVENT_B_OFFSET, DA9063_M_VDD_WARN),
> + /* DA9063 event C register */
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI0, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI0),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI1, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI1),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI2, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI2),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI3, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI3),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI4, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI4),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI5, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI5),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI6, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI6),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI7, DA9063_REG_EVENT_C_OFFSET,
> DA9063_M_GPI7),
> + /* DA9063 event D register */
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI8, DA9063_REG_EVENT_D_OFFSET,
> DA9063_M_GPI8),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI9, DA9063_REG_EVENT_D_OFFSET,
> DA9063_M_GPI9),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI10,
> DA9063_REG_EVENT_D_OFFSET, DA9063_M_GPI10),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI11,
> DA9063_REG_EVENT_D_OFFSET, DA9063_M_GPI11),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI12,
> DA9063_REG_EVENT_D_OFFSET, DA9063_M_GPI12),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI13,
> DA9063_REG_EVENT_D_OFFSET, DA9063_M_GPI13),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI14,
> DA9063_REG_EVENT_D_OFFSET, DA9063_M_GPI14),
> + REGMAP_IRQ_REG(DA9063_IRQ_GPI15,
> DA9063_REG_EVENT_D_OFFSET, DA9063_M_GPI15),
> +};
> +
> +static const struct regmap_irq_chip da9063l_irq_chip = {
> + .name = "da9063l-irq",
> + .irqs = da9063l_irqs,
> + .num_irqs = DA9063_NUM_IRQ,
Isn't the number of IRQs in the DA9063L different to the standard DA9063
because of the missing RTC?
Regards,
Steve
> +
> + .num_regs = 4,
> + .status_base = DA9063_REG_EVENT_A,
> + .mask_base = DA9063_REG_IRQ_MASK_A,
> + .ack_base = DA9063_REG_EVENT_A,
> + .init_ack_masked = true,
> +};
> +
> int da9063_irq_init(struct da9063 *da9063)
> {
> + struct regmap_irq_chip *irq_chip;
> int ret;
>
RE: [PATCH v3 03/10] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
On 04 June 2018 19:32, Marek Vasut wrote, > Subject: Re: [PATCH v3 03/10] mfd: da9063: Rename PMIC_DA9063 to > PMIC_CHIP_ID_DA9063 > > On 06/04/2018 02:26 PM, Lee Jones wrote: > > On Sat, 02 Jun 2018, Marek Vasut wrote: > > > >> The PMIC_DA9063 is a complete misnomer, it denotes the value of the > >> DA9063 chip ID register, so rename it as such. It is also the value > >> of chip ID register of DA9063L though, so drop the enum as all the > >> DA9063 "models" share the same chip ID and thus the distinction will > >> have to be made using DT or otherwise. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Geert Uytterhoeven > >> Cc: Lee Jones > >> Cc: Mark Brown > >> Cc: Steve Twiss > >> Cc: Wolfram Sang > >> Cc: linux-renesas-...@vger.kernel.org > >> Acked-by: Mark Brown > >> Reviewed-by: Geert Uytterhoeven > >> --- > >> V2: No change > >> V3: No change > >> --- > >> drivers/mfd/da9063-core.c| 2 +- > >> drivers/mfd/da9063-i2c.c | 2 +- > >> drivers/regulator/da9063-regulator.c | 2 +- > >> include/linux/mfd/da9063/core.h | 4 +--- > >> 4 files changed, 4 insertions(+), 6 deletions(-) > > > > For my own reference: > > Acked-for-MFD-by: Lee Jones > > Thanks. > > Any other comments before I submit the next round in a few days? > Hi Marek, Thanks. I'm reviewing it now. Could you hold off until tomorrow please? Regards, Steve
RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
On 24 May 2018 15:51 Marek Vasut wrote:
Hi Marek,
> To: Steve Twiss ; linux-kernel@vger.kernel.org
> Cc: Marek Vasut ; Geert Uytterhoeven
> ; Lee Jones ; Mark Brown
> ; Wolfram Sang ;
> linux-renesas-...@vger.kernel.org
> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> > On 24 May 2018 @ 12:49 Steve Twiss wrote:
> >>> On 23 May 2018 12:43 Marek Vasut wrote,
> >>>
> >>> To: linux-kernel@vger.kernel.org
> >>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>>
> >>> Add support for DA9063L, which is a reduced variant of the DA9063 with
> >>> less regulators and without RTC.
> >>>
> >>
> >> There's potentially more to this file. Without an RTC the regmap
> >> access tables would change and the usual DA9063 (BB silicon) tables would
> >> become invalid.
> >> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
> >> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new
> >> chip model was needed.
> >>
> >> The new ranges would be this (see below), and would remove any RTC
> >> accesses in the new chip model.
> >>
> >> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> >>{
> >>.range_min = DA9063_REG_PAGE_CON,
> >>.range_max = DA9063_REG_MON_A10_RES,
> >>}, {
> >>.range_min = DA9063_REG_SEQ,
> >>.range_max = DA9063_REG_ID_32_31,
> >>}, {
> >>.range_min = DA9063_REG_SEQ_A,
> >>.range_max = DA9063_REG_AUTO3_LOW,
> >>}, {
> >>.range_min = DA9063_REG_T_OFFSET,
> >>.range_max = DA9063_BB_REG_GP_ID_19,
> >>}, {
> >>.range_min = DA9063_REG_CHIP_ID,
> >>.range_max = DA9063_REG_CHIP_VARIANT,
> >>},
> >> };
> >>
> >> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> >>{
> >>.range_min = DA9063_REG_PAGE_CON,
> >>.range_max = DA9063_REG_PAGE_CON,
> >>}, {
> >>.range_min = DA9063_REG_FAULT_LOG,
> >>.range_max = DA9063_REG_VSYS_MON,
> >>}, {
> >>.range_min = DA9063_REG_SEQ,
> >>.range_max = DA9063_REG_ID_32_31,
> >>}, {
> >>.range_min = DA9063_REG_SEQ_A,
> >>.range_max = DA9063_REG_AUTO3_LOW,
> >>}, {
> >>.range_min = DA9063_REG_CONFIG_I,
> >>.range_max = DA9063_BB_REG_MON_REG_4,
> >>}, {
> >>.range_min = DA9063_BB_REG_GP_ID_0,
> >>.range_max = DA9063_BB_REG_GP_ID_19,
> >>},
> >> };
> >>
> >> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> >>{
> >>.range_min = DA9063_REG_PAGE_CON,
> >>.range_max = DA9063_REG_EVENT_D,
> >>}, {
> >>.range_min = DA9063_REG_CONTROL_A,
> >>.range_max = DA9063_REG_CONTROL_B,
> >>}, {
> >>.range_min = DA9063_REG_CONTROL_E,
> >>.range_max = DA9063_REG_CONTROL_F,
> >>}, {
> >>.range_min = DA9063_REG_BCORE2_CONT,
> >>.range_max = DA9063_REG_LDO11_CONT,
> >>}, {
> >>.range_min = DA9063_REG_DVC_1,
> >>.range_max = DA9063_REG_ADC_MAN,
> >>}, {
> >>.range_min = DA9063_REG_ADC_RES_L,
> >>.range_max = DA9063_REG_MON_A10_RES,
> >>}, {
> >>.range_min = DA9063_REG_SEQ,
> >>.range_max = DA9063_REG_SEQ,
> >>}, {
> >>.range_min = DA9063_REG_EN_32K,
> >>.range_max = DA9063_REG_EN_32K,
> >>}, {
> >>.range_min = DA9063_BB_REG_MON_REG_5,
> >>.range_max = DA9063_BB_REG_MON_REG_6,
> >>},
> >> };
> >>
> >> However this is a larger and more wide-ranging change compared to the
> >> one proposed by Marek, and would require other alterations to fit
> >> this in. Also I'm undecided to what it would really add apart from a
> >> new chip model: I have been told accessing the DA9063 RTC register
> >> locations
> >> has no effect in the DA9063L.
> >
> > Loo
RE: [PATCH 3/6] mfd: da9063: Add DA9063L type
On 23 May 2018 12:42 Marek Vasut wrote:
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut ; Geert Uytterhoeven
> ; Lee Jones ; Mark Brown
> ; Steve Twiss ; Wolfram
> Sang ; linux-renesas-...@vger.kernel.org
> Subject: [PATCH 3/6] mfd: da9063: Add DA9063L type
>
> Add type for DA9063L, which is a reduced variant of the DA9063 without RTC
> block and with less regulators.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: Steve Twiss
> Cc: Wolfram Sang
> Cc: linux-renesas-...@vger.kernel.org
> ---
> include/linux/mfd/da9063/core.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/mfd/da9063/core.h
> b/include/linux/mfd/da9063/core.h index eb234582dcb2..c3e917dd1860 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -33,6 +33,7 @@
>
> enum da9063_type {
> PMIC_TYPE_DA9063 = 0,
> + PMIC_TYPE_DA9063L,
> };
>
> enum da9063_variant_codes {
> --
> 2.16.2
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
Thanks Marek,
On 23 May 2018 12:42 Marek Vasut wrote,
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut ; Geert Uytterhoeven
> ; Lee Jones ; Mark Brown
> ; Steve Twiss ; Wolfram
> Sang ; linux-renesas-...@vger.kernel.org
> Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
>
> The DA9063L does not contain RTC block, unlike the full DA9063.
> Do not allow binding RTC driver on this variant of the chip.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: Steve Twiss
> Cc: Wolfram Sang
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/mfd/da9063-core.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index
> 7360b76b4f72..263c83006413 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
> .of_compatible = "dlg,da9063-onkey",
> },
> {
> + .name = DA9063_DRVNAME_VIBRATION,
> + },
> + { /* Only present on DA9063 , not on DA9063L */
> .name = DA9063_DRVNAME_RTC,
> .num_resources = ARRAY_SIZE(da9063_rtc_resources),
> .resources = da9063_rtc_resources,
> .of_compatible = "dlg,da9063-rtc",
> },
> - {
> - .name = DA9063_DRVNAME_VIBRATION,
> - },
> };
>
> static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@
> int da9063_device_init(struct da9063 *da9063, unsigned int irq) {
> struct da9063_pdata *pdata = da9063->dev->platform_data;
> int model, variant_id, variant_code;
> - int ret;
> + int da9063_devs_len, ret;
>
> ret = da9063_clear_fault_log(da9063);
> if (ret < 0)
> @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned
> int irq)
>
> da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
>
> - ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
> - ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
> - NULL);
> + da9063_devs_len = ARRAY_SIZE(da9063_devs);
> + /* RTC, the last device in the list, is only present on DA9063 */
> + if (da9063->type == PMIC_TYPE_DA9063L)
> + da9063_devs_len -= 1;
> +
> + ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
> + NULL, da9063->irq_base, NULL);
> if (ret)
> dev_err(da9063->dev, "Cannot add MFD cells\n");
>
> --
> 2.16.2
MFD cells definitely has less impact than regmap_range and regmap_irq.
I agree, there's no point in having a completely new
static const struct mfd_cell da9063l_devs[] = { ... } for DA9063L
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
Hi Marek,
On 24 May 2018 @ 12:49 Steve Twiss wrote:
> To: Marek Vasut ; linux-kernel@vger.kernel.org
> Cc: Marek Vasut ; Geert Uytterhoeven
> ; Lee Jones ; Mark Brown
> ; Steve Twiss ; Wolfram
> Sang ; linux-renesas-...@vger.kernel.org
> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Thanks Marek,
>
> > On 23 May 2018 12:43 Marek Vasut wrote,
> >
> > To: linux-kernel@vger.kernel.org
> > Cc: Marek Vasut ; Geert Uytterhoeven
> > ; Lee Jones ;
> > Mark Brown ; Steve Twiss
> > ; Wolfram Sang
> > ; linux-renesas-...@vger.kernel.org
> > Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >
> > Add support for DA9063L, which is a reduced variant of the DA9063 with less
> > regulators and without RTC.
> >
>
> There's potentially more to this file. Without an RTC the regmap access
> tables would change
> and the usual DA9063 (BB silicon) tables would become invalid.
> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
> da9063_bb_volatile_ranges,
> would need to be updated for DA9063L, if a new chip model was needed.
>
> The new ranges would be this (see below), and would remove any RTC accesses
> in the new chip model.
>
> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_MON_A10_RES,
> }, {
> .range_min = DA9063_REG_SEQ,
> .range_max = DA9063_REG_ID_32_31,
> }, {
> .range_min = DA9063_REG_SEQ_A,
> .range_max = DA9063_REG_AUTO3_LOW,
> }, {
> .range_min = DA9063_REG_T_OFFSET,
> .range_max = DA9063_BB_REG_GP_ID_19,
> }, {
> .range_min = DA9063_REG_CHIP_ID,
> .range_max = DA9063_REG_CHIP_VARIANT,
> },
> };
>
> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_PAGE_CON,
> }, {
> .range_min = DA9063_REG_FAULT_LOG,
> .range_max = DA9063_REG_VSYS_MON,
> }, {
> .range_min = DA9063_REG_SEQ,
> .range_max = DA9063_REG_ID_32_31,
> }, {
> .range_min = DA9063_REG_SEQ_A,
> .range_max = DA9063_REG_AUTO3_LOW,
> }, {
> .range_min = DA9063_REG_CONFIG_I,
> .range_max = DA9063_BB_REG_MON_REG_4,
> }, {
> .range_min = DA9063_BB_REG_GP_ID_0,
> .range_max = DA9063_BB_REG_GP_ID_19,
> },
> };
>
> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_EVENT_D,
> }, {
> .range_min = DA9063_REG_CONTROL_A,
> .range_max = DA9063_REG_CONTROL_B,
> }, {
> .range_min = DA9063_REG_CONTROL_E,
> .range_max = DA9063_REG_CONTROL_F,
> }, {
> .range_min = DA9063_REG_BCORE2_CONT,
> .range_max = DA9063_REG_LDO11_CONT,
> }, {
> .range_min = DA9063_REG_DVC_1,
> .range_max = DA9063_REG_ADC_MAN,
> }, {
> .range_min = DA9063_REG_ADC_RES_L,
> .range_max = DA9063_REG_MON_A10_RES,
> }, {
> .range_min = DA9063_REG_SEQ,
> .range_max = DA9063_REG_SEQ,
> }, {
> .range_min = DA9063_REG_EN_32K,
> .range_max = DA9063_REG_EN_32K,
> }, {
> .range_min = DA9063_BB_REG_MON_REG_5,
> .range_max = DA9063_BB_REG_MON_REG_6,
> },
> };
>
> However this is a larger and more wide-ranging change compared to the one
> proposed by Marek,
> and would require other alterations to fit this in. Also I'm undecided to
> what it would really add
> apart from a new chip model: I have been told accessing the DA9063 RTC
> register locations has no
> effect in the DA9063L.
Looking at this further, there is also a new IRQ regmap.
Again this comes down to whether a full chip model is needed or not. If not,
then the IRQ map does not
need to be changed as given. Otherwise the removal of the following:
[DA9063_IRQ_ALARM] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_ALARM,
},
[DA9063_IRQ_TICK] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_TICK,
},
prior to registering the IRQs in the chip model would be needed.
The
RE: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
Hi Marek,
On 23 May 2018 12:42 Marek Vasut wrote:
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut ; Geert Uytterhoeven
> ; Lee Jones ; Mark Brown
> ; Steve Twiss ; Wolfram
> Sang ; linux-renesas-...@vger.kernel.org
> Subject: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
>
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value of chip
> ID register of DA9063L though, so drop the enum as all the
> DA9063 "models" share the same chip ID and thus the distinction will have to
> be made using DT or otherwise.
>
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: Steve Twiss
> Cc: Wolfram Sang
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/mfd/da9063-core.c| 2 +-
> drivers/mfd/da9063-i2c.c | 2 +-
> drivers/regulator/da9063-regulator.c | 2 +-
> include/linux/mfd/da9063/core.h | 4 +---
> 4 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index
> 6c2870d4e754..00b3caee4e21 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -192,7 +192,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned
> int irq)
> dev_err(da9063->dev, "Cannot read chip model id.\n");
> return -EIO;
> }
> - if (model != PMIC_DA9063) {
> + if (model != PMIC_CHIP_ID_DA9063) {
> dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
> return -ENODEV;
> }
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index
> 981805a2c521..7f84030c8d53 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -280,7 +280,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c) }
>
> static const struct i2c_device_id da9063_i2c_id[] = {
> - {"da9063", PMIC_DA9063},
> + { "da9063", PMIC_CHIP_ID_DA9063 },
> {},
> };
> MODULE_DEVICE_TABLE(i2c, da9063_i2c_id); diff --git
> a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
> index 6a8f9cd69f52..87c884ae0064 100644
> --- a/drivers/regulator/da9063-regulator.c
> +++ b/drivers/regulator/da9063-regulator.c
> @@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
> {
> .regulator_info = da9063_regulator_info,
> .n_regulators = ARRAY_SIZE(da9063_regulator_info),
> - .dev_model = PMIC_DA9063,
> + .dev_model = PMIC_CHIP_ID_DA9063,
> },
> { }
> };
> diff --git a/include/linux/mfd/da9063/core.h
> b/include/linux/mfd/da9063/core.h index f3ae65db4c86..664f650d0086 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -29,9 +29,7 @@
> #define DA9063_DRVNAME_RTC "da9063-rtc"
> #define DA9063_DRVNAME_VIBRATION "da9063-vibration"
>
> -enum da9063_models {
> - PMIC_DA9063 = 0x61,
> -};
> +#define PMIC_CHIP_ID_DA9063 0x61
>
> enum da9063_variant_codes {
> PMIC_DA9063_AD = 0x3,
> --
> 2.16.2
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
Thanks Marek,
> On 23 May 2018 12:43 Marek Vasut wrote,
>
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut ; Geert Uytterhoeven
> ;
> Lee Jones ; Mark Brown ; Steve
> Twiss ;
> Wolfram Sang ;
> linux-renesas-...@vger.kernel.org
> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Add support for DA9063L, which is a reduced variant of the DA9063 with less
> regulators and without RTC.
>
There's potentially more to this file. Without an RTC the regmap access tables
would change and the
usual DA9063 (BB silicon) tables would become invalid.
The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
da9063_bb_volatile_ranges,
would need to be updated for DA9063L, if a new chip model was needed.
The new ranges would be this (see below), and would remove any RTC accesses in
the new chip model.
static const struct regmap_range da9063l_bb_readable_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_MON_A10_RES,
}, {
.range_min = DA9063_REG_SEQ,
.range_max = DA9063_REG_ID_32_31,
}, {
.range_min = DA9063_REG_SEQ_A,
.range_max = DA9063_REG_AUTO3_LOW,
}, {
.range_min = DA9063_REG_T_OFFSET,
.range_max = DA9063_BB_REG_GP_ID_19,
}, {
.range_min = DA9063_REG_CHIP_ID,
.range_max = DA9063_REG_CHIP_VARIANT,
},
};
static const struct regmap_range da9063l_bb_writeable_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_PAGE_CON,
}, {
.range_min = DA9063_REG_FAULT_LOG,
.range_max = DA9063_REG_VSYS_MON,
}, {
.range_min = DA9063_REG_SEQ,
.range_max = DA9063_REG_ID_32_31,
}, {
.range_min = DA9063_REG_SEQ_A,
.range_max = DA9063_REG_AUTO3_LOW,
}, {
.range_min = DA9063_REG_CONFIG_I,
.range_max = DA9063_BB_REG_MON_REG_4,
}, {
.range_min = DA9063_BB_REG_GP_ID_0,
.range_max = DA9063_BB_REG_GP_ID_19,
},
};
static const struct regmap_range da9063l_bb_volatile_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_EVENT_D,
}, {
.range_min = DA9063_REG_CONTROL_A,
.range_max = DA9063_REG_CONTROL_B,
}, {
.range_min = DA9063_REG_CONTROL_E,
.range_max = DA9063_REG_CONTROL_F,
}, {
.range_min = DA9063_REG_BCORE2_CONT,
.range_max = DA9063_REG_LDO11_CONT,
}, {
.range_min = DA9063_REG_DVC_1,
.range_max = DA9063_REG_ADC_MAN,
}, {
.range_min = DA9063_REG_ADC_RES_L,
.range_max = DA9063_REG_MON_A10_RES,
}, {
.range_min = DA9063_REG_SEQ,
.range_max = DA9063_REG_SEQ,
}, {
.range_min = DA9063_REG_EN_32K,
.range_max = DA9063_REG_EN_32K,
}, {
.range_min = DA9063_BB_REG_MON_REG_5,
.range_max = DA9063_BB_REG_MON_REG_6,
},
};
However this is a larger and more wide-ranging change compared to the one
proposed by Marek,
and would require other alterations to fit this in. Also I'm undecided to what
it would really add
apart from a new chip model: I have been told accessing the DA9063 RTC register
locations has
no effect in the DA9063L.
If the maintainers are happy with this, and if a chip model addition is really
needed in future
it can be added later if required.
Acked-by: Steve Twiss
Regards,
Steve
> Signed-off-by: Marek Vasut
> Cc: Geert Uytterhoeven
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: Steve Twiss
> Cc: Wolfram Sang
> Cc: linux-renesas-...@vger.kernel.org
> ---
> drivers/mfd/da9063-i2c.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index
> 5544ce8e3363..84bbd2bbcd2a 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = {
>
> static const struct of_device_id da9063_dt_ids[] = {
> { .compatible = "dlg,da9063", },
> + { .compatible = "dlg,da9063l", },
> { }
> };
> MODULE_DEVICE_TABLE(of, da9063_dt_ids); @@ -282,6 +283,7 @@ static int
> da9063_i2c_remove(struct i2c_client *i2c)
>
> static const struct i2c_device_id da9063_i2c_id[] = {
> { "da9063", PMIC_TYPE_DA9063 },
> + { "da9063l", PMIC_TYPE_DA9063L },
> {},
> };
> MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
> --
> 2.16.2
[PATCH V1] mfd: da9062: use core helper regmap_reg_range macros
From: Steve Twiss
Replace multi-line entries in the regmap_range arrays with single
line macros: regmap_reg_range(). This will leave the static structure
array entries for regmap_range unaltered. It will significantly reduce
the line count in the DA9062/61 core file.
Signed-off-by: Steve Twiss
---
This patch applies against linux-next and v4.16-rc7
Hi,
This is a cosmetic tidy up operation. It reduces the line-count in the
file by over 200.
It will replace regmap_range[] array entries, such as this:
{
.range_min = DA9062AA_DEVICE_ID,
.range_max = DA9062AA_CONFIG_ID,
},
with a single line,
regmap_reg_range(DA9062AA_DEVICE_ID, DA9062AA_CONFIG_ID),
Regards,
Steve Twiss, Dialog Semiconductor
drivers/mfd/da9062-core.c | 462 --
1 file changed, 114 insertions(+), 348 deletions(-)
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index fe18115..9f61059 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -365,186 +365,69 @@ static int da9062_get_device_type(struct da9062 *chip)
}
static const struct regmap_range da9061_aa_readable_ranges[] = {
- {
- .range_min = DA9062AA_PAGE_CON,
- .range_max = DA9062AA_STATUS_B,
- }, {
- .range_min = DA9062AA_STATUS_D,
- .range_max = DA9062AA_EVENT_C,
- }, {
- .range_min = DA9062AA_IRQ_MASK_A,
- .range_max = DA9062AA_IRQ_MASK_C,
- }, {
- .range_min = DA9062AA_CONTROL_A,
- .range_max = DA9062AA_GPIO_4,
- }, {
- .range_min = DA9062AA_GPIO_WKUP_MODE,
- .range_max = DA9062AA_GPIO_OUT3_4,
- }, {
- .range_min = DA9062AA_BUCK1_CONT,
- .range_max = DA9062AA_BUCK4_CONT,
- }, {
- .range_min = DA9062AA_BUCK3_CONT,
- .range_max = DA9062AA_BUCK3_CONT,
- }, {
- .range_min = DA9062AA_LDO1_CONT,
- .range_max = DA9062AA_LDO4_CONT,
- }, {
- .range_min = DA9062AA_DVC_1,
- .range_max = DA9062AA_DVC_1,
- }, {
- .range_min = DA9062AA_SEQ,
- .range_max = DA9062AA_ID_4_3,
- }, {
- .range_min = DA9062AA_ID_12_11,
- .range_max = DA9062AA_ID_16_15,
- }, {
- .range_min = DA9062AA_ID_22_21,
- .range_max = DA9062AA_ID_32_31,
- }, {
- .range_min = DA9062AA_SEQ_A,
- .range_max = DA9062AA_WAIT,
- }, {
- .range_min = DA9062AA_RESET,
- .range_max = DA9062AA_BUCK_ILIM_C,
- }, {
- .range_min = DA9062AA_BUCK1_CFG,
- .range_max = DA9062AA_BUCK3_CFG,
- }, {
- .range_min = DA9062AA_VBUCK1_A,
- .range_max = DA9062AA_VBUCK4_A,
- }, {
- .range_min = DA9062AA_VBUCK3_A,
- .range_max = DA9062AA_VBUCK3_A,
- }, {
- .range_min = DA9062AA_VLDO1_A,
- .range_max = DA9062AA_VLDO4_A,
- }, {
- .range_min = DA9062AA_VBUCK1_B,
- .range_max = DA9062AA_VBUCK4_B,
- }, {
- .range_min = DA9062AA_VBUCK3_B,
- .range_max = DA9062AA_VBUCK3_B,
- }, {
- .range_min = DA9062AA_VLDO1_B,
- .range_max = DA9062AA_VLDO4_B,
- }, {
- .range_min = DA9062AA_INTERFACE,
- .range_max = DA9062AA_CONFIG_E,
- }, {
- .range_min = DA9062AA_CONFIG_G,
- .range_max = DA9062AA_CONFIG_K,
- }, {
- .range_min = DA9062AA_CONFIG_M,
- .range_max = DA9062AA_CONFIG_M,
- }, {
- .range_min = DA9062AA_GP_ID_0,
- .range_max = DA9062AA_GP_ID_19,
- }, {
- .range_min = DA9062AA_DEVICE_ID,
- .range_max = DA9062AA_CONFIG_ID,
- },
+ regmap_reg_range(DA9062AA_PAGE_CON, DA9062AA_STATUS_B),
+ regmap_reg_range(DA9062AA_STATUS_D, DA9062AA_EVENT_C),
+ regmap_reg_range(DA9062AA_IRQ_MASK_A, DA9062AA_IRQ_MASK_C),
+ regmap_reg_range(DA9062AA_CONTROL_A, DA9062AA_GPIO_4),
+ regmap_reg_range(DA9062AA_GPIO_WKUP_MODE, DA9062AA_GPIO_OUT3_4),
+ regmap_reg_range(DA9062AA_BUCK1_CONT, DA9062AA_BUCK4_CONT),
+ regmap_reg_range(DA9062AA_BUCK3_CONT, DA9062AA_BUCK3_CONT),
+ regmap_reg_range(DA9062AA_LDO1_CONT, DA9062AA_LDO4_CONT),
+ regmap_reg_range(DA9062AA_DVC_1, DA9062AA_DVC_1),
+ regmap_reg_range(DA9062AA_SEQ, DA9062AA_ID_4_3),
+ regmap_reg_range(DA9062AA_ID_12_11, DA9062AA_ID_16_15),
+ regmap_reg_range(DA9062AA_ID_22_21, DA9062AA_ID_32_31),
+ regmap_reg_range(DA9062AA_SEQ_A, DA9062AA_WAIT),
+ regmap_reg_range(DA9062AA_RESET, DA9062AA_BUCK_ILIM_C),
+ regmap_reg_range(DA9062AA_BUCK1_CFG, DA9062AA_BUCK3_CFG),
+ regmap_reg_range
RE: [PATCH 000/100] rtc: remove cargo culted code
On 02 March 2018 08:57, Alexandre Belloni wrote: > To: Steve Twiss > Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org > Subject: Re: [PATCH 000/100] rtc: remove cargo culted code > > On 02/03/2018 at 08:46:48 +0000, Steve Twiss wrote: > > Hi Alexandre, > > > > Acked for: > > rtc: da9063: stop validating rtc_time in .read_time > > rtc: da9052: stop validating rtc_time in .read_time > > rtc: da9055: stop validating rtc_time in .read_time > > > > Acked-by: Steve Twiss > > [...] > > But after some further looking, I have not got any explicit case of how the > > time read directly from the DA9063 > > registers can be incorrectly represented. So there should be no need to > > check this. > > My point is that it is checked later in the core anyway so you end up > doing: > > da9063_rtc_read_time() > return rtc_valid_tm(tm); > > __rtc_read_time() > if (err < 0) > return err; > err = rtc_valid_tm(tm); > > return err; > > So the check in da9063_rtc_read_time is always pointless. Ahh. I see. Thanks! Regards, Steve
RE: [PATCH 000/100] rtc: remove cargo culted code
On Wed, Feb 21, 2018 at 8:54 PM, Alexandre Belloni wrote: > subject: [PATCH 000/100] rtc: remove cargo culted code > mailing list: linux-kernel@vger.kernel.org Filter messages from this mailing > list > > Hello, > > This series: > - removes useless calls to rtc_valid_tm in .read_time, .set_time and >.set_alarm > - removes code setting default values for RTCs (and lets the core >handle it) > - removes useless "time is invalid" messages at probe time > - removes useless indirect calls > > Those were mostly copy pasted from other drivers Hi Alexandre, Acked for: rtc: da9063: stop validating rtc_time in .read_time rtc: da9052: stop validating rtc_time in .read_time rtc: da9055: stop validating rtc_time in .read_time Acked-by: Steve Twiss Agreed -- rtc_valid_tm() call is cargo cult for the above. (By definition) for DA9063 I was trying to be rigorous. The .read_time function is slightly different here because I can make a copy the alarm time into the RTC time structure to solve an RTC synchronisation problem internally to the DA9063. https://elixir.bootlin.com/linux/v4.5.6/source/drivers/rtc/rtc-da9063.c#L253 But after some further looking, I have not got any explicit case of how the time read directly from the DA9063 registers can be incorrectly represented. So there should be no need to check this. Regards, Steve
RE: [PATCH v4] watchdog: add SPDX identifiers for watchdog subsystem
On 28 February 2018 15:02, Marcus Folkesson wrote: > Subject: [PATCH v4] watchdog: add SPDX identifiers for watchdog subsystem > > - Add SPDX identifier > - Remove boiler plate license text > - If MODULE_LICENSE and boiler plate does not match, go for boiler plate > license Acked-by: Steve Twiss Hi Marcus, Acked for the files below. Regards, Steve [...] > drivers/watchdog/da9052_wdt.c | 6 +--- > drivers/watchdog/da9055_wdt.c | 6 +--- > drivers/watchdog/da9062_wdt.c | 10 +-- > drivers/watchdog/da9063_wdt.c | 5 +--- [...] > diff --git a/drivers/watchdog/da9052_wdt.c > b/drivers/watchdog/da9052_wdt.c > index d6d5006efa71..e263bad99574 100644 > --- a/drivers/watchdog/da9052_wdt.c > +++ b/drivers/watchdog/da9052_wdt.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0+ > /* > * System monitoring driver for DA9052 PMICs. > * > @@ -5,11 +6,6 @@ > * > * Author: Anthony Olech > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > */ > > #include > diff --git a/drivers/watchdog/da9055_wdt.c > b/drivers/watchdog/da9055_wdt.c > index 50bdd1022186..26a5b2984094 100644 > --- a/drivers/watchdog/da9055_wdt.c > +++ b/drivers/watchdog/da9055_wdt.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0+ > /* > * System monitoring driver for DA9055 PMICs. > * > @@ -5,11 +6,6 @@ > * > * Author: David Dajun Chen > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > */ > > #include > diff --git a/drivers/watchdog/da9062_wdt.c > b/drivers/watchdog/da9062_wdt.c > index 814dff6045a4..a001782bbfdb 100644 > --- a/drivers/watchdog/da9062_wdt.c > +++ b/drivers/watchdog/da9062_wdt.c > @@ -1,16 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0+ > /* > * Watchdog device driver for DA9062 and DA9061 PMICs > * Copyright (C) 2015 Dialog Semiconductor Ltd. > * > - * This program is free software; you can redistribute it and/or > - * modify it under the terms of the GNU General Public License > - * as published by the Free Software Foundation; either version 2 > - * of the License, or (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > > #include > diff --git a/drivers/watchdog/da9063_wdt.c > b/drivers/watchdog/da9063_wdt.c > index 2a20fc163ed0..b17ac1bb1f28 100644 > --- a/drivers/watchdog/da9063_wdt.c > +++ b/drivers/watchdog/da9063_wdt.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0+ > /* > * Watchdog driver for DA9063 PMICs. > * > @@ -5,10 +6,6 @@ > * > * Author: Mariusz Wojtasik > * > - * This program is free software; you can redistribute it and/or modify it > - * under the terms of the GNU General Public License as published by the > - * Free Software Foundation; either version 2 of the License, or (at your > - * option) any later version. > */ > > #include
RE: [PATCH] hwmon: da9052 Increase sample rate when using TSI
Hi Martyn, On 19 October 2017 16:52, Martyn Welch wrote: > To: Support Opensource; Jean Delvare; Guenter Roeck > Subject: [PATCH] hwmon: da9052 Increase sample rate when using TSI > > The TSI channel, which is usually used for touchscreen support, but can > be used as 4 general purpose ADCs. When used as a touchscreen interface > the touchscreen driver switches the device into 1ms sampling mode (rather > than the default 10ms economy mode) as recommended by the > manufacturer. > When using the TSI channels as a general purpose ADC we are currently not > doing this and testing suggests that this can result in ADC timeouts: > > [ 5827.198289] da9052 spi2.0: timeout waiting for ADC conversion interrupt > [ 5827.728293] da9052 spi2.0: timeout waiting for ADC conversion interrupt > [ 5993.808335] da9052 spi2.0: timeout waiting for ADC conversion interrupt > [ 5994.328441] da9052 spi2.0: timeout waiting for ADC conversion interrupt > [ 5994.848291] da9052 spi2.0: timeout waiting for ADC conversion interrupt > > Switching to the 1ms timing resolves this issue. > > Cc: sta...@vger.kernel.org > Signed-off-by: Martyn Welch > --- > drivers/hwmon/da9052-hwmon.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c > index 97a62f5..a973eb6 100644 > --- a/drivers/hwmon/da9052-hwmon.c > +++ b/drivers/hwmon/da9052-hwmon.c > @@ -477,6 +477,11 @@ static int da9052_hwmon_probe(struct platform_device > *pdev) > /* disable touchscreen features */ > da9052_reg_write(hwmon->da9052, DA9052_TSI_CONT_A_REG, 0x00); > > + /* Sample every 1ms */ > + da9052_reg_update(hwmon->da9052, DA9052_ADC_CONT_REG, > + DA9052_ADCCONT_ADCMODE, > + DA9052_ADCCONT_ADCMODE); > + Acked-by: Steve Twiss According to the DA9053 Datasheet, Revision 2.1, 31-Aug-2016, Section 18.3, page 143. [The ADC] can be used either in high speed mode with measurements sequences repeated every 1ms or in economy mode with sequences performed every 10ms. Also, DA9053 Datasheet, Revision 2.1, 31-Aug-2016, Section 18.17, Table 56: GP-ADC Control Registers, Register Address R82 ADC_CONT, page 150, Bit 6, ADC_MODE 0: Measurement sequence interval 10 ms (economy mode) 1: Measurement sequence interval 1 ms (recommended for TSI mode) I can't find any reason why a global change to the sampling rate cannot be applied during the ADC measurements in this case. After all, as you said, this is gated by the previous change by Sebastian Reichel which enforces a protection of ADC measurements when using the TSI as a general ADC (see commit ebf555111bc11a5da9144e4af524260731a8b968). Regards, Steve
[PATCH V1] MAINTAINERS: Fix Dialog search term for watchdog binding file
From: Steve Twiss
Commit 340267640d769d3b3af9 ("MAINTAINERS: da9062/61 updates to the Dialog
Semiconductor search terms") contained a typo for the watchdog binding:
da92??-wdt.txt should have read da90??-wdt.txt. This new commit will fix
the error and allows Dialog Semiconductor to follow files for PMIC
bindings correctly.
Signed-off-by: Steve Twiss
Tested-by: Steve Twiss
---
Hi Lee,
This fixes a typo in my previous MAINTAINERS submission.
It probably has minimal impact, but it was incorrect.
Regards,
Steve
This patch applies against linux-mainline and v4.13
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c3feff..7cb50b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4050,7 +4050,7 @@ F:Documentation/devicetree/bindings/mfd/da90*.txt
F: Documentation/devicetree/bindings/input/da90??-onkey.txt
F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
F: Documentation/devicetree/bindings/regulator/da92*.txt
-F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt
+F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt
F: Documentation/devicetree/bindings/sound/da[79]*.txt
F: drivers/gpio/gpio-da90??.c
F: drivers/hwmon/da90??-hwmon.c
--
end-of-patch for PATCH V1
RE: [PATCH 1/1] Revert "mfd: da9061: Fix to remove BBAT_CONT register from chip model"
On 21 August 2017 08:50, Lee Jones wrote:
Hi Lee,
> To: Steve Twiss
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/1] Revert "mfd: da9061: Fix to remove BBAT_CONT
> register from chip model"
>
> On Tue, 15 Aug 2017, Lee Jones wrote:
>
> > This patch was applied to the MFD twice, causing unwanted behavour.
> >
> > This reverts commit b77eb79acca3203883e8d8dbc7f2b842def1bff8.
> >
> > Fixes: b77eb79acca3 ("mfd: da9061: Fix to remove BBAT_CONT register from
> > chip model")
> > Reported-by: Steve Twiss
> > Signed-off-by: Lee Jones
> > ---
> > drivers/mfd/da9062-core.c | 6 ++
> > 1 file changed, 6 insertions(+)
>
> Steve, It would be good to obtain a {Reviewed|Acked}-by from you
> before applying.
>
Sure.
> > diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> > index fbe0f245ce8e..fe1811523e4a 100644
> > --- a/drivers/mfd/da9062-core.c
> > +++ b/drivers/mfd/da9062-core.c
> > @@ -645,6 +645,9 @@ static const struct regmap_range
> > da9062_aa_readable_ranges[] = {
> > .range_min = DA9062AA_VLDO1_B,
> > .range_max = DA9062AA_VLDO4_B,
> > }, {
> > + .range_min = DA9062AA_BBAT_CONT,
> > + .range_max = DA9062AA_BBAT_CONT,
> > + }, {
> > .range_min = DA9062AA_INTERFACE,
> > .range_max = DA9062AA_CONFIG_E,
> > }, {
> > @@ -721,6 +724,9 @@ static const struct regmap_range
> > da9062_aa_writeable_ranges[] = {
> > .range_min = DA9062AA_VLDO1_B,
> > .range_max = DA9062AA_VLDO4_B,
> > }, {
> > + .range_min = DA9062AA_BBAT_CONT,
> > + .range_max = DA9062AA_BBAT_CONT,
> > + }, {
> > .range_min = DA9062AA_GP_ID_0,
> > .range_max = DA9062AA_GP_ID_19,
> > },
This looks good. Thanks for the changes.
Reviewed-by: Steve Twiss
Acked-by: Steve Twiss
Regards,
Steve
RE: [PATCH V1] mfd: da9061: fix to remove BBAT_CONT register from chip model
On 06 June 2017 08:16, Lee Jones wrote:
Hi Lee,
> To: Steve Twiss
> Cc: LINUX-KERNEL; Support Opensource
> Subject: Re: [PATCH V1] mfd: da9061: fix to remove BBAT_CONT register from
> chip model
>
> On Mon, 05 Jun 2017, Steve Twiss wrote:
>
> > From: Steve Twiss
> >
> > Remove the register DA9062AA_BBAT_CONT (0x0C5) from the DA9061 chip model
> > regmap access ranges. This applies to both da9061_aa_readable_ranges[]
> > and da9061_aa_writeable_ranges[].
> >
> > This change is to correct the DA9061 chip model and align it with the
> > latest DA9061 Datasheet.
> >
> > This register previously appeared in the DA9061 Datasheet, Revision 3.2,
> > 01-Mar-2016 and has been removed from later DA9061 datasheet from Dialog,
> > Revision 3.3, 04-Apr-2017.
> >
> > Signed-off-by: Steve Twiss
> >
> > ---
> >
> > Hi Lee,
> >
> > This is a fix to remove DA9062AA_BBAT_CONT register from the DA9061
> > regmap read/write access tables. It only applies to the DA9061 chip,
> > and does not affect the DA9062.
> >
> > No existing kernel code tries to access this register, so the change is
> > just a formality to correct the DA9061 chip model and align it with the
> > DA9061 Datasheet.
> >
> > This patch applies against linux-next and v4.12-rc3
> >
> > Regards,
> > Steve Twiss, Dialog Semiconductor
> >
> >
> > drivers/mfd/da9062-core.c | 6 --
> > 1 file changed, 6 deletions(-)
>
> Applied, thanks.
$ git describe
v4.13-rc5
Looking at linux-mainline today, I noticed a commit that seems to be applied
twice. This patch I sent on 5th June seems to have been duplicated and applied
for
a second time (to the same file), and this has resulted in an error.
$ git log --oneline --author="diasemi.com" -2
b77eb79 mfd: da9061: Fix to remove BBAT_CONT register from chip model
2cd6496 mfd: da9061: Fix to remove BBAT_CONT register from chip model
$ git log --pretty=format:"%h, %cn, %s" | grep b77eb79
b77eb79, Lee Jones, mfd: da9061: Fix to remove BBAT_CONT register from chip
model
Could you revert the b77eb79 commit please?
The original patch only applies to the DA9061 chip model and by duplicating my
original
submission and applying b77eb79, it has also made the same change to the DA9062
chip
model. This is incorrect. The DA9062 and DA90861 chip models are different.
Regards,
Steve
>
> > diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> > index 7f5e8be..fe18115 100644
> > --- a/drivers/mfd/da9062-core.c
> > +++ b/drivers/mfd/da9062-core.c
> > @@ -429,9 +429,6 @@ static int da9062_get_device_type(struct da9062 *chip)
> > .range_min = DA9062AA_VLDO1_B,
> > .range_max = DA9062AA_VLDO4_B,
> > }, {
> > - .range_min = DA9062AA_BBAT_CONT,
> > - .range_max = DA9062AA_BBAT_CONT,
> > - }, {
> > .range_min = DA9062AA_INTERFACE,
> > .range_max = DA9062AA_CONFIG_E,
> > }, {
> > @@ -514,9 +511,6 @@ static int da9062_get_device_type(struct da9062 *chip)
> > .range_min = DA9062AA_VLDO1_B,
> > .range_max = DA9062AA_VLDO4_B,
> > }, {
> > - .range_min = DA9062AA_BBAT_CONT,
> > - .range_max = DA9062AA_BBAT_CONT,
> > - }, {
> > .range_min = DA9062AA_GP_ID_0,
> > .range_max = DA9062AA_GP_ID_19,
> > },
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
RE: [PATCH 2/2] hwmon: da9052: add support for TSI channel
Hi Sebastian,
On 26 June 2017 15:49 Sebastian Reichel wrote:
> Subject: [PATCH 2/2] hwmon: da9052: add support for TSI channel
>
> TSI channel has a 4 channel mux connected to it and is normally
> used for touchscreen support. The hardware may alternatively
> use it as general purpose adc.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/mfd/da9052-i2c.txt | 8 +
> drivers/hwmon/da9052-hwmon.c | 229
> -
> drivers/input/touchscreen/da9052_tsi.c | 5 +
> include/linux/mfd/da9052/da9052.h | 6 +
> 4 files changed, 244 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> index 9554292dc6cb..94f3bb1d9a0a 100644
> --- a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
> @@ -4,6 +4,14 @@ Required properties:
> - compatible : Should be "dlg,da9052", "dlg,da9053-aa",
>"dlg,da9053-ab", or "dlg,da9053-bb"
>
> +Optional properties:
> +- diag,tsi-as-adc : Boolean, if set the X+, X-, Y+, Y- touchscreen
> +input lines are used as general purpose analogue
> + input.
> +- diag,tsiref-microvolt: Voltage applied to the TSIREF pin, which is
> + used as reference voltage when reading TSI
> + pins as ADC. Defaults to
> 250.
> +
"dlg" is the standard vendor prefix we are using for Dialog Semiconductor
bindings. You can find this definition in the kernel file:
./Documentation/devicetree/bindings/vendor-prefixes.txt
> Sub-nodes:
> - regulators : Contain the regulator nodes. The DA9052/53 regulators are
>bound using their names as listed below:
> diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-
> hwmon.c
> index c9832bfacfe5..a0b9d5498ba4 100644
> --- a/drivers/hwmon/da9052-hwmon.c
> +++ b/drivers/hwmon/da9052-hwmon.c
> @@ -20,13 +20,17 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> struct da9052_hwmon {
> - struct da9052 *da9052;
> - struct mutexhwmon_lock;
> + struct da9052 *da9052;
> + struct mutexhwmon_lock;
> + booltsi_as_adc;
> + int tsiref_mv;
> + struct completion tsidone;
> };
>
> static const char * const input_names[] = {
> @@ -37,6 +41,10 @@ static const char * const input_names[] = {
> [DA9052_ADC_IN4]= "ADC IN4",
> [DA9052_ADC_IN5]= "ADC IN5",
> [DA9052_ADC_IN6]= "ADC IN6",
> + [DA9052_ADC_TSI_XP] = "ADC TS X+",
> + [DA9052_ADC_TSI_YP] = "ADC TS Y+",
> + [DA9052_ADC_TSI_XN] = "ADC TS X-",
> + [DA9052_ADC_TSI_YN] = "ADC TS Y-",
> [DA9052_ADC_TJUNC] = "BATTERY JUNCTION TEMP",
> [DA9052_ADC_VBBAT] = "BACK-UP BATTERY VOLTAGE",
> };
> @@ -59,6 +67,11 @@ static inline int vbbat_reg_to_mv(int value)
> return DIV_ROUND_CLOSEST(value * 5000, 1023);
> }
>
> +static inline int input_tsireg_to_mv(struct da9052_hwmon *hwmon, int
> value)
> +{
> + return DIV_ROUND_CLOSEST(value * hwmon->tsiref_mv, 1023);
> +}
> +
> static inline int da9052_enable_vddout_channel(struct da9052 *da9052)
> {
> return da9052_reg_update(da9052, DA9052_ADC_CONT_REG,
> @@ -154,6 +167,103 @@ static ssize_t da9052_read_misc_channel(struct
> device *dev,
> return sprintf(buf, "%d\n", input_reg_to_mv(ret));
> }
>
> +static int da9052_request_tsi_read(struct da9052_hwmon *hwmon, int
> channel)
> +{
> + u8 val = BIT(6); /* TSI_MAN */
There is an explicit #define for bit 6 from the TSI control register B, in the
file include/linux/mfd/da9052/reg.h #define DA9052_TSICONTB_TSIMAN 0X40
> +
> + switch (channel) {
> + case DA9052_ADC_TSI_XP:
> + val |= (0 << 4); /* TSI_MUX */
> + break;
> + case DA9052_ADC_TSI_YP:
> + val |= (1 << 4); /* TSI_MUX */
> + break;
> + case DA9052_ADC_TSI_XN:
> + val |= (2 << 4); /* TSI_MUX */
> + break;
> + case DA9052_ADC_TSI_YN:
> + val |= (3 << 4); /* TSI_MUX */
> + break;
> + }
Same for these magic numbers.
Although I don't find any entries for these in the reg.h file.
The datasheet for DA9053, Revision 2.1, says
(http://www.dialog-semiconductor.com/products/da9053)
bits (5:4) R/W TSI_MUX
Direct setting of MUX selecting which XY pin is routed to ADC_IN7 input.
00: X+ (results will be stored in TSI_XM)
01: Y+ (results will be stored in TSI_YM)
10: X- (results will be stored in TSI_XM)
11: Y- (results will be stored in TSI_YM)
May I suggest adding explicit entries to the reg.h file, somewhere near the
TSI CONTROL REGISTER B BITS li
RE: [PATCH 14/51] rtc: da9063: stop using rtc deprecated functions
Hi Benjamin,
On 20 June 2017 10:35, Benjamin Gaignard wrote:
> Subject: [PATCH 14/51] rtc: da9063: stop using rtc deprecated functions
Probably this subject should be "rtc: da9052" not 63.
> rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
> rely on 32bits variables and that will make rtc break in y2038/2016.
> Stop using those two functions to safer 64bits ones.
>
[...]
> ---
> drivers/rtc/rtc-da9052.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-da9052.c b/drivers/rtc/rtc-da9052.c
> index 4273377..99a0489 100644
> --- a/drivers/rtc/rtc-da9052.c
> +++ b/drivers/rtc/rtc-da9052.c
> @@ -104,17 +104,15 @@ static int da9052_read_alarm(struct da9052_rtc
> *rtc, struct rtc_time *rtc_tm)
> static int da9052_set_alarm(struct da9052_rtc *rtc, struct rtc_time *rtc_tm)
> {
> struct da9052 *da9052 = rtc->da9052;
> - unsigned long alm_time;
> + unsigned long long alm_time;
> int ret;
> uint8_t v[3];
>
> - ret = rtc_tm_to_time(rtc_tm, &alm_time);
> - if (ret != 0)
> - return ret;
> + alm_time = rtc_tm_to_time64(rtc_tm);
But they kind of use the same functions anyway.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/rtc.h?h=v4.12-rc6#n35
And I think they they are abstracted on purpose.
The DA9052/53 hardware can only handle alarms up to the end of 2063.
Regards,
Steve
RE: [PATCH 00/51] rtc: stop using rtc deprecated functions
Hi Pavel, On 20 June 2017 14:26, Pavel Machek wrote: > Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions > > On Tue 2017-06-20 14:24:00, Alexandre Belloni wrote: > > On 20/06/2017 at 14:10:11 +0200, Pavel Machek wrote: > > > On Tue 2017-06-20 12:03:48, Alexandre Belloni wrote: > > > > On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote: > > > > > rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they > > > > > rely on 32bits variables and that will make rtc break in y2038/2016. > > > > > > > > Please don't, because this hide the fact that the hardware will not > > > > handle dates in y2038 anyway and as pointed by Russell a few month ago, > > > > rtc_time_to_tm will be able to catch it but the 64 bit version will > > > > silently ignore it. > > > > > > Reference? Because rtc on PCs stores date in binary coded decimal, so > > > it is likely to break in 2100, not 2038... > > > > I'm not saying it should be done but clearly, that is not the correct > > thing to do for RTCs that are using a single 32 bits register to store > > the time. > > You give one example, I can give you three: armada38x, at91sam9, > > at32ap700x and that just in the beginning of the series. > > I wanted reference to Russell's mail. This is it. https://patchwork.kernel.org/patch/6219401/ Regards, Steve
RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular
Hi Paul, On 06 June 2017 21:23, Paul Gortmaker wrote: > Subject: Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular > > > >As always, the option exists for someone with the hardware and the > > > desire > > >to extend the functionality to make any given driver tristate. But > > > given > > >the number of these tree wide and the fact that I can't test that new > > >extended functionality in all cases, I just make the code consistent > > > with > > >existing Kconfig/Makefile settings that currently restrict them to > > > "bool". > > > > I see your point, however we have many customers and it is unclear whether > > they are using modules for any of these drivers. > > Even if that feature in Kconfig is not enabled, it is possible a tristate > > change has > > been made and is being used, but has not been pushed back into the Linux > > mainline. > > I'd have to suspect that is pretty unlikely, but in the end if you think > these chips have a use case for being modular that isn't just academic, > then there is no reason why they can't be tristate. > > > So I would recommend against removing this feature. > > > > The driver code is being supported by Dialog Semiconductor, where possible. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?h=v4.12-rc4#n3984 > > If there is a question about supporting modules in these drivers, we have > > the > > ability to test on target for da9055/52. > > So, the "conversion" patches would be the trivial one line change from > "bool" to "tristate" and the real effort is the validation. Do you want > to submit those trivial changes after you've had a chance to validate > them? There is no point in me sending you one line patches to test. Sure, agreed. The responsibility can fall back to Dialog for this change. We will submit for these "Make it explicitly non-modular" patches and remove the ambiguity caused by the Kconfig bool options. Regards, Steve
RE: [RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator driver
Hi Mark, On 07 June 2017 10:42, Mark Brown wrote: > Subject: Re: [RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator > driver > > On Wed, Jun 07, 2017 at 09:13:48AM +0100, Steve Twiss wrote: > > From: Steve Twiss > > > > Regulator support for the DA9061 is added into the DA9062 regulator driver. > > I'm missing the other patches in this series and the cover letter, what > are the dependencies here? My apologies Mark. I didn't re-send the cover letter because this regulator patch is the last one and I assumed it would not add anything. Am I confusing you here by not renaming the patch and leaving its subject as [PATCH V7 5/7]? This whole DA9061 patch set was a very long time in the submission process. You Acked the DA9061 regulator patch back in 2016, but it had a compile dependency with the DA9061 MFD patch so it had to wait until that got approved. If the regulator patch had got in first, it would have broken the build. The MFD patch contained a change to the ./include/linux/mfd/da9062/core.h file -- it had a new enum for da9062_compatible_types and these values were used in the MFD, but also appeared in the regulator patch as part of the da9062_regulator_probe(). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=656211b1dfb9e0b68d4e634931432e29a6facf46 According to my records, I think the MFD made it into linux-mainline/v4.12-rc1 as part of Lee Jones' e-mail "[GIT PULL] MFD for v4.12" https://lkml.org/lkml/2017/5/3/91 [I can't check that link, LKML is down atm]. Once the MFD change for DA9062/1 had been added, this unblocked the patch for the regulators. In my test environment here, I've tested the DA9061 and the build by patching v4.12-rc2 with the remaining DA9061 regulator patch. I'm not sure the cover letter for the original V7 patch set will explain much, but I will resend again, this time with the cover letter. Regards, Steve The original components of the PATCH V7 are as follows: [v7,1] https://patchwork.kernel.org/patch/9649905/ [v7,2] https://patchwork.kernel.org/patch/9649921/ [v7,3] https://patchwork.kernel.org/patch/9649889/ [v7,4] https://patchwork.kernel.org/patch/9649927/ [v7,5] https://patchwork.kernel.org/patch/9649895/ [v7,6] https://patchwork.kernel.org/patch/9649917/ [v7,7] https://patchwork.kernel.org/patch/9649913/
[RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator driver
From: Steve Twiss
Regulator support for the DA9061 is added into the DA9062 regulator driver.
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].
The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.
Kconfig is updated to reflect support for DA9061 and DA9062 regulators.
Acked-by: Mark Brown
Signed-off-by: Steve Twiss
---
Hi Mark,
On 06 June 2017 20:03, Mark Brown wrote:
> Subject: Re: [RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO
> regulator driver
>
> On Tue, May 30, 2017 at 10:17:59AM +0100, Lee Jones wrote:
> > On Wed, 24 May 2017, Mark Brown wrote:
>
> > > On Wed, May 24, 2017 at 09:32:43AM +0100, Lee Jones wrote:
> > > > Plan is to push this through the MFD tree.
> > > Great, thanks.
> > Just taking a look at this now. It looks like the dependency:
> > 656211b1dfb9 mfd: Add support for DA9061
> > ... is now in Mainline. Therefore it should be okay to take this
> > directly through the Regulator repo.
>
> OK, can you resend please Steve?
Thanks for taking this patch.
Regards,
Steve
This patch was Acked by Mark Brown, a long time ago, way back in Oct 2016
(https://patchwork.kernel.org/patch/9397787/).
I have kept Mark Brown's Ack attached because there have been no real
code changes since then, but I have recently updated the copyright header
slightly, rebased the code (no changes necessary) and compile tested it
against x86_64.
The MFD files which this patch depended on were accepted into linux-mainline
by Lee Jones. If there is anything in the way of this patch acceptance,
could you please let me know?
This patch applies against linux-next and v4.12-rc2
v6 -> v7
- NO CODE CHANGE
- Compile tested ARCH=x86_64
v5 -> v6
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
v4 -> v5
- Rebased from v4.8 to v4.9
- NO CODE CHANGE
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 6/9] to [PATCH V4 5/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 06/10] to [PATCH V3 6/9]
- Added Ack from Mark Brown
v1 -> v2
- Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated header to use DA9061 and DA9062
As previously:
These changes depend on a header file provided as part of an earlier
patch [V7,4/7] mfd: da9061: MFD core support from this set. The regulator
probe() switches on the chip_type which uses enum da9062_compatible_types
in core.h from this patch.
Regards,
Steve Twiss, Dialog Semiconductor
drivers/regulator/Kconfig| 4 +-
drivers/regulator/da9062-regulator.c | 303 +--
2 files changed, 293 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 48db87d..9de 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -214,11 +214,11 @@ config REGULATOR_DA9055
will be called da9055-regulator.
config REGULATOR_DA9062
- tristate "Dialog Semiconductor DA9062 regulators"
+ tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
This driver can also be built as a module. If so, the module
will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c
b/drivers/regulator/da9062-regulator.c
index 0638c8b..34a70d9 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,6 +1,6 @@
/*
- * da9062-regulator.c - REGULATOR device driver for DA9062
- * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ * Regulator device driver for DA9061 and DA9062.
+ * Copyright (C) 2015-2017 Dialog Semiconductor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -28,6 +28,17 @@
/* Regulator IDs */
enum {
+ DA9061_ID_BUCK1,
+ DA9061_ID_BUCK2,
+ DA9061_ID_BUCK3,
+ DA9061_ID_LDO1,
+ DA9061_ID_LDO2,
+ DA9061_ID_LDO3,
+ DA9061_ID_LDO4,
+ DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
/* Regulator operations */
-/* Current limits array (in uA) BUCK1 and BUCK3.
- Entry indexes correspo
RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular
Hi Paul, On 05 June 2017 20:30, Paul Gortmaker wrote: > Subject: Re: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular > > [RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular] > On 05/06/2017 (Mon 10:30) Steve Twiss wrote: > > > On 03 June 2017 14:04 Paul Gortmaker wrote: > > > The Kconfig currently controlling compilation of this code is: > > > > > > drivers/mfd/Kconfig:config PMIC_DA903X > > > drivers/mfd/Kconfig:bool "Dialog Semiconductor DA9030/DA9034 PMIC > > > Support" > > > > > > ...meaning that it currently is not being built as a module by anyone. > > > > With regards to your four patches, > > > > [4/4] mfd: da9055-i2c: Make it explicitly non-modular - - - > > 2017-06-03 > > [3/4] mfd: da9055-core: make it explicitly non-modular - - - > > 2017-06-03 > > [2/4] mfd: da9052-*: Make it explicitly non-modular- - - > > 2017-06-03 > > [1/4] mfd: da903x: Make it explicitly non-modular - - - 2017-06-03 > > > > Is there an reason not to make the Kconfig tristate? > > Would that not be simpler? > > I explicitly covered that in the 0/4 e-mail: Apologies, I don't seem to have been CC'ed on the 0/4 e-mail, although I got the others. Dialog's developer e-mail addresses come as part of the Support Opensource e-mail distribution list. >As always, the option exists for someone with the hardware and the desire >to extend the functionality to make any given driver tristate. But given >the number of these tree wide and the fact that I can't test that new >extended functionality in all cases, I just make the code consistent with >existing Kconfig/Makefile settings that currently restrict them to "bool". I see your point, however we have many customers and it is unclear whether they are using modules for any of these drivers. Even if that feature in Kconfig is not enabled, it is possible a tristate change has been made and is being used, but has not been pushed back into the Linux mainline. So I would recommend against removing this feature. The driver code is being supported by Dialog Semiconductor, where possible. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?h=v4.12-rc4#n3984 If there is a question about supporting modules in these drivers, we have the ability to test on target for da9055/52. Regards, Steve
[PATCH V1] mfd: da9061: fix to remove BBAT_CONT register from chip model
From: Steve Twiss
Remove the register DA9062AA_BBAT_CONT (0x0C5) from the DA9061 chip model
regmap access ranges. This applies to both da9061_aa_readable_ranges[]
and da9061_aa_writeable_ranges[].
This change is to correct the DA9061 chip model and align it with the
latest DA9061 Datasheet.
This register previously appeared in the DA9061 Datasheet, Revision 3.2,
01-Mar-2016 and has been removed from later DA9061 datasheet from Dialog,
Revision 3.3, 04-Apr-2017.
Signed-off-by: Steve Twiss
---
Hi Lee,
This is a fix to remove DA9062AA_BBAT_CONT register from the DA9061
regmap read/write access tables. It only applies to the DA9061 chip,
and does not affect the DA9062.
No existing kernel code tries to access this register, so the change is
just a formality to correct the DA9061 chip model and align it with the
DA9061 Datasheet.
This patch applies against linux-next and v4.12-rc3
Regards,
Steve Twiss, Dialog Semiconductor
drivers/mfd/da9062-core.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 7f5e8be..fe18115 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -429,9 +429,6 @@ static int da9062_get_device_type(struct da9062 *chip)
.range_min = DA9062AA_VLDO1_B,
.range_max = DA9062AA_VLDO4_B,
}, {
- .range_min = DA9062AA_BBAT_CONT,
- .range_max = DA9062AA_BBAT_CONT,
- }, {
.range_min = DA9062AA_INTERFACE,
.range_max = DA9062AA_CONFIG_E,
}, {
@@ -514,9 +511,6 @@ static int da9062_get_device_type(struct da9062 *chip)
.range_min = DA9062AA_VLDO1_B,
.range_max = DA9062AA_VLDO4_B,
}, {
- .range_min = DA9062AA_BBAT_CONT,
- .range_max = DA9062AA_BBAT_CONT,
- }, {
.range_min = DA9062AA_GP_ID_0,
.range_max = DA9062AA_GP_ID_19,
},
--
end-of-patch for PATCH V1
RE: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular
Hi Paul,
On 03 June 2017 14:04 Paul Gortmaker wrote:
> To: linux-kernel@vger.kernel.org
> Cc: Paul Gortmaker; Support Opensource; Lee Jones; Eric Miao; Mike Rapoport
> Subject: [PATCH 1/4] mfd: da903x: Make it explicitly non-modular
>
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config PMIC_DA903X
> drivers/mfd/Kconfig:bool "Dialog Semiconductor DA9030/DA9034 PMIC
> Support"
>
> ...meaning that it currently is not being built as a module by anyone.
With regards to your four patches,
[4/4] mfd: da9055-i2c: Make it explicitly non-modular - - - 2017-06-03
[3/4] mfd: da9055-core: make it explicitly non-modular - - - 2017-06-03
[2/4] mfd: da9052-*: Make it explicitly non-modular- - - 2017-06-03
[1/4] mfd: da903x: Make it explicitly non-modular - - - 2017-06-03
Is there an reason not to make the Kconfig tristate?
Would that not be simpler?
Previously, something similar was suggested by Geert Uytterhoeven for DA9063:
https://patchwork.kernel.org/patch/7788001/
Regards,
Steve
> Remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
>
> Also explicitly disallow a driver unbind, since that doesn't have a
> sensible use case anyway, and it allows us to drop the ".remove"
> code for non-modular drivers.
>
> Since module_init was not in use by this code, the init ordering
> remains unchanged with this commit.
>
> We replace module.h with init.h and export.h ; the latter since this
> file does export some syms.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
>
> Cc: Support Opensource
> Cc: Lee Jones
> Cc: Eric Miao
> Cc: Mike Rapoport
> Signed-off-by: Paul Gortmaker
> ---
> drivers/mfd/da903x.c | 26 +++---
> 1 file changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mfd/da903x.c b/drivers/mfd/da903x.c
> index 09f367571c58..78edb0558a0f 100644
> --- a/drivers/mfd/da903x.c
> +++ b/drivers/mfd/da903x.c
> @@ -13,7 +13,7 @@
> */
>
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -446,7 +446,6 @@ static const struct i2c_device_id da903x_id_table[] = {
> { "da9034", 1 },
> { },
> };
> -MODULE_DEVICE_TABLE(i2c, da903x_id_table);
>
> static int __remove_subdev(struct device *dev, void *unused)
> {
> @@ -535,20 +534,12 @@ static int da903x_probe(struct i2c_client *client,
> return da903x_add_subdevs(chip, pdata);
> }
>
> -static int da903x_remove(struct i2c_client *client)
> -{
> - struct da903x_chip *chip = i2c_get_clientdata(client);
> -
> - da903x_remove_subdevs(chip);
> - return 0;
> -}
> -
> static struct i2c_driver da903x_driver = {
> .driver = {
> - .name = "da903x",
> + .name = "da903x",
> + .suppress_bind_attrs= true,
> },
> .probe = da903x_probe,
> - .remove = da903x_remove,
> .id_table = da903x_id_table,
> };
>
> @@ -557,14 +548,3 @@ static int __init da903x_init(void)
> return i2c_add_driver(&da903x_driver);
> }
> subsys_initcall(da903x_init);
> -
> -static void __exit da903x_exit(void)
> -{
> - i2c_del_driver(&da903x_driver);
> -}
> -module_exit(da903x_exit);
> -
> -MODULE_DESCRIPTION("PMIC Driver for Dialog Semiconductor DA9034");
> -MODULE_AUTHOR("Eric Miao ");
> -MODULE_AUTHOR("Mike Rapoport ");
> -MODULE_LICENSE("GPL v2");
> --
> 2.11.0
RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
Hi Fabio, On 24 May 2017 14:53 Fabio Estevam wrote, > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD > and RI irqs to be off > On Wed, May 24, 2017 at 9:49 AM, Steve Twiss wrote: > > > I used this tag: jb4.3_1.1.1-ga > > http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?id=jb4.3_1.1.1-ga > > > > This repo is slightly modified for a project I am working on, but it only > > queries > > the I2C for devices before printing out some messages, so minor changes I > > think. Here's the output from the console: > > I am not able to reproduce it using this same U-Boot version on my > mx6sabresd board: > > https://pastebin.com/ppnrnidr That's very interesting. Once I apply the test change from Uwe, I can get a console trace. > Uwe Kleine-König wrote: > > Can you try to just remove the line > > writel(0, sport->port.membase + UFCR); The differences in the kernel console logs are ... My board : Your board differences Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ] : Board: i.MX6Q-SABRESD: unknown-board Board: 0x63011 [POR ] Found PFUZE100! deviceid=10,revid=11 : Found PFUZE100! deviceid=10,revid=10 ... and others, but.. I do not have "console=ttymxc0,115200" in my kernel command line. Yes. I can verify, using the raw linux-next/v4.12-rc2 I get the console error. When I add "console=ttymxc0,115200" to my U-boot environment and the kernel command-line, the kernel console starts working again. That would indicate the test on the i.MX6DL might be misleading, since my colleague ran that using their bootloader set-up. So, my assertion this was only visible on the i.MX6Q could be wrong. There's no way to to check this until tomorrow now. I'll check check on the i.MX6DL using my bootloader environment when I get access to an i.MX6DL board. Regards, Stephen
RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
Hi Fabio, On 24 May 2017 12:53 Fabio Estevam wrote: > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD > and RI irqs to be off > On Wed, May 24, 2017 at 7:32 AM, Steve Twiss wrote: > > > The USB to UART connection gets corrupted. > > If this patch is applied to the kernel, the i.MX6 Q (quad), and only this > > board as far as > > we know, starts to fail. This does *not* change the i.MX6DL and other sabre > > boards > > have been tested on kernelci.org and do not see a problem. > > > > An NXP/Freescale SABRESD i.MX6 Q board is requred. > > > > My system for testing is to TFTP the Linux kernel over an ethernet > > connection. The > > U-boot executes okay and the UART is working at that point. When the kernel > > loads > > the console trace becomes garbled, in the sense that I get the some > > characters being > > output to the console, in the style of the kernel starting up, but they are > > not correct. > > > > I expect the kernel has started ok, but I am unable to read/write through > > the UART > > console because of corruptions. > > > > Console log with the output I am seeing with linux-next/v4.12-rc2 > > --- 8< --- > > U-Boot 2009.08-1-gf65536a (Jan 12 2015 - 15:47:19) > > Thanks for your detailed explanation. > > I also have a mx6q sabresd board here, but the error did not happen > when I use a recent U-Boot version. > > I would like to use the same U-Boot version here as well to help > debugging this problem. For the previous tests I was using a slightly modified U-Boot from an old Freescale Android release JB43_110, but I've just compiled up the standard u-boot from the Freescale git repository, and I get the same results. > Could you please let me know which 2009.08 branch you used? Is it any > one from git.freescale.com > http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/refs/heads ? I used this tag: jb4.3_1.1.1-ga http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/commit/?id=jb4.3_1.1.1-ga This repo is slightly modified for a project I am working on, but it only queries the I2C for devices before printing out some messages, so minor changes I think. Here's the output from the console: --- 8< --- U-Boot 2009.08 (May 24 2017 - 13:15:47) CPU: Freescale i.MX6 family TO1.2 at 792 MHz Thermal sensor with ratio = 200 Temperature: 38 C, calibration data 0x5f15527d mx6q pll1: 792MHz mx6q pll2: 528MHz mx6q pll3: 480MHz mx6q pll8: 50MHz ipg clock : 6600Hz ipg per clock : 6600Hz uart clock: 8000Hz cspi clock: 6000Hz ahb clock : 13200Hz axi clock : 26400Hz emi_slow clock: 13200Hz ddr clock : 52800Hz usdhc1 clock : 19800Hz usdhc2 clock : 19800Hz usdhc3 clock : 19800Hz usdhc4 clock : 19800Hz nfc clock : 2400Hz Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ] Boot Device: SD I2C: ready DRAM: 1 GB MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3 In:serial Out: serial Err: serial Found PFUZE100! deviceid=10,revid=11 Net: got MAC address from IIM: 00:04:9f:02:e3:0a FEC0 [PRIME] Hit any key to stop autoboot: 0 PHY indentify @ 0x1 = 0x004dd074 FEC: Link is Up 796d Using FEC0 device TFTP from server 192.168.2.1; our IP address is 192.168.2.2 Filename 'uImage_dtb.imx6q.v4.12-rc2'. Load address: 0x1200 Loading: # # # # # # # # # # # # # # # # # ## done Bytes transferred = 5951076 (5ace64 hex) ## Booting kernel from Legacy Image at 1200 ...
RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
Hi Fabio,
On 23 May 2017 17:26 Fabio Estevam wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD
> and RI irqs to be off
> On Tue, May 23, 2017 at 9:17 AM, Steve Twiss wrote:
> >
> > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > ensure DCD and RI irqs to be off")
> >
> > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > The console becomes unreadable and unwritable.
> >
> > Tested-by: Steve Twiss
> > Signed-off-by: Steve Twiss
> >
> > ---
> > This patch applies against linux-next and v4.12-rc2
> >
> > Hi,
> >
> > I have been seeing a problem with the serial output console on the i.MX6Q
> > SABRESD, but not the i.MX6DL SABRESD. Everything was fine up to
> > linux-mainline/v4.11 but changed after linux-next/next-20170501.
> >
> > Some bisection has pointed at the commit
> > e61c38d85b7392e033ee03bca46f1d6006156175 which, once removed from my
> > linux-next/v4.12-rc2 build allows the i.MX6Q board to display the console
> > correctly again.
> >
> > This patch removes the original commit e61c38d85b7392e ("serial: imx:
> > setup DCEDTE early and ensure DCD and RI irqs to be off") from linux-next
> > v4.12-rc2 and fixes the serial problem seen in the i.MX6Q SABRESD board.
>
> How can the error be reproduced?
>
> Care to share more details of the error, please?
The USB to UART connection gets corrupted.
If this patch is applied to the kernel, the i.MX6 Q (quad), and only this board
as far as
we know, starts to fail. This does *not* change the i.MX6DL and other sabre
boards
have been tested on kernelci.org and do not see a problem.
An NXP/Freescale SABRESD i.MX6 Q board is requred.
My system for testing is to TFTP the Linux kernel over an ethernet connection.
The
U-boot executes okay and the UART is working at that point. When the kernel
loads
the console trace becomes garbled, in the sense that I get the some characters
being
output to the console, in the style of the kernel starting up, but they are not
correct.
I expect the kernel has started ok, but I am unable to read/write through the
UART
console because of corruptions.
Console log with the output I am seeing with linux-next/v4.12-rc2
--- 8< ---
U-Boot 2009.08-1-gf65536a (Jan 12 2015 - 15:47:19)
CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature: 46 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock : 6600Hz
ipg per clock : 6600Hz
uart clock: 8000Hz
cspi clock: 6000Hz
ahb clock : 13200Hz
axi clock : 26400Hz
emi_slow clock: 13200Hz
ddr clock : 52800Hz
usdhc1 clock : 19800Hz
usdhc2 clock : 19800Hz
usdhc3 clock : 19800Hz
usdhc4 clock : 19800Hz
nfc clock : 2400Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [WDOG ]
Boot Device: SD
I2C: ready
DRAM: 1 GB
MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:serial
Out: serial
Err: serial
Found PFUZE100! deviceid=10,revid=11
Net: got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot: 0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x1200
Loading: #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
Hi Uwe,
On 23 May 2017 17:09, Uwe Kleine-König wrote:
> On Tue, May 23, 2017 at 03:01:26PM +0000, Steve Twiss wrote:
> > On 23 May 2017 15:37, Uwe Kleine-König wrote:
> > > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure
> > > DCD and RI irqs to be off
> > > On Tue, May 23, 2017 at 02:28:11PM +, Steve Twiss wrote:
> > > > On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > > > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > > > >
> > > > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early
> > > > > > and
> > > > > > ensure DCD and RI irqs to be off")
> > > > > > The patch submitted to setup DCEDTE early and ensure DCD and RI
> > > > > > irqs to
> > > > > > be off, causes a serial console display problem the i.MX6Q SABRESD
> > > > > > board.
> > > > > > The console becomes unreadable and unwritable.
> > > > > >
> > > > > > Tested-by: Steve Twiss
> > > > > > Signed-off-by: Steve Twiss
> > > > >
> > > > > You're not the first to report this issue but you still have the
> > > > > chance
> > > > > to be the first to test a suggested patch for it.
> > > >
> > > > I've just applied your patch against a clean linux-next/v4.12-rc2
> > > > I added your patch ...
> > > >
> > > > > http://marc.info/?l=linux-serial&m=149434029912947&w=2
> > > >
> > [...]
> > > > I've added that to my working directory, but I am still seeing the
> > > > corrupted
> > > > console output on the i.MX6 Q (quad) board.
> > >
> > > I don't have a failing board (I think). So here are a few questions
> > > about yours:
> > >
> > > - how does the dts snippet for your failing device look like?
> >
> > I am using the standard DTS from the v4.12-rc2 kernel, no changes.
> > I did an earlier test yesterday using the DTS from v4.11 to see if it was
> > the new
> > imx7 changes that have recently gone into the kernel but I still see the
> > same
> > effect.
> >
> > > - This is not the device the console runs on, right?
> >
> > I am connected through the USB to UART, U22 on the i.MX6Q board.
> > Terminal set to 115200 baud, no parity, 8bit data.
> >
> > > - Can you initialize the device in the bootloader and check if it is
> > > working
> there?
> >
> > I can get U-boot ok for all cases.
> > Once I TFTP the kernel across, I am okay until I get to "Starting kernel
> > ...",
> > then, the UART is "working" in the sense that I get the some characters in
> > the style
> > of the kernel starting up, but they are all garbled.
> >
> > I expect the kernel has started ok, but I am unable to read/write through
> > the UART
> > console because of corruptions.
> >
> > Console log:
> > --- 8< ---
[...]
> > Starting kernel ...
> >
> à ü ü pþ àüþü à àà àüþüàüü þü à ü à à àüŽ àü àü àà
[...]
>
> did you check with an oscilloscope if the baud rate is as expected (hmm,
> but I wouldn't expect my patch to change the baud rate).
I did try several different baudrates on the terminal connection, but I didn't
find any
that worked. I've only checked the obvious ones however. I have not tried to
debug
this problem any further than diagnosing what kernel commit caused the
difference.
We also swapped compilers to begin with, when the first investigation began.
I noticed kernelci.org had some i.MX sabre boards, but used a different compiler
and did not see any problem.
Swapping the compiler made no difference and led us to find it only happened
on the i.MX6Q not the i.MX6DL. The kernelci.org site does not test any i.MX6Q
boards.
> > > - Does it make a difference in Linux if the bootloader used the device
> > > before?
> >
> > If you mean, if U-boot uses the UART console before loading the kernel,
> > then no.
> > Is that what you mean?
>
> I didn't expect that it destroys the console UART so I expected that you
> can make use of a 2nd UART in U-Boot somehow to already initialize the
> port and check if that makes it magically work in Linux.
>
> Note to myself: So we're taking about the UART at 0x0202, it is
> operated in DCE mode.
> > It makes no difference until the kernel is loaded, then the serial
> >
RE: [RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator driver
On 23 May 2017 18:17 Mark Brown > To: Steve Twiss > Subject: Re: [RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator > driver > > On Tue, May 23, 2017 at 02:40:45PM +0100, Steve Twiss wrote: > > > This patch was Acked by Mark Brown, a long time ago, way back in Oct 2016 > > (https://patchwork.kernel.org/patch/9397787/). > > I have kept Mark Brown's Ack attached because there have been no real > > code changes since then, but I have recently updated the copyright header > > slightly, rebased the code (no changes necessary) and compile tested it > > against x86_64. > > > The MFD files which this patch depended on were accepted into linux-next > > by Lee Jones last week. If there is anything in the way of this patch > > acceptance, could you please let me know? > > Given that I've acked this and it depends on the MFD changes I'd have > expected Lee to apply it. If nothing else happens I can apply it after > the next merge window, otherwise either Lee needs to send me a pull > request for the MFD change so I've got the dependency or he needs to > apply this. Hi Mark, Thanks, No problem, just some minor administration. @Lee Could you please send Mark a pull request for the regulator component to the DA9062/61 changes [PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator driver. Regards, Steve
RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
Hi Uwe,
On 23 May 2017 15:37, Uwe Kleine-König wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD
> and RI irqs to be off
> On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> > On 23 May 2017 15:10, Uwe Kleine-König wrote:
> > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > >
> > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > > ensure DCD and RI irqs to be off")
> > > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > > be off, causes a serial console display problem the i.MX6Q SABRESD
> > > > board.
> > > > The console becomes unreadable and unwritable.
> > > >
> > > > Tested-by: Steve Twiss
> > > > Signed-off-by: Steve Twiss
> > >
> > > You're not the first to report this issue but you still have the chance
> > > to be the first to test a suggested patch for it.
> >
> > I've just applied your patch against a clean linux-next/v4.12-rc2
> > I added your patch ...
> >
> > > http://marc.info/?l=linux-serial&m=149434029912947&w=2
> >
[...]
> > I've added that to my working directory, but I am still seeing the corrupted
> > console output on the i.MX6 Q (quad) board.
>
> I don't have a failing board (I think). So here are a few questions
> about yours:
>
> - how does the dts snippet for your failing device look like?
I am using the standard DTS from the v4.12-rc2 kernel, no changes.
I did an earlier test yesterday using the DTS from v4.11 to see if it was the
new
imx7 changes that have recently gone into the kernel but I still see the same
effect.
> - This is not the device the console runs on, right?
I am connected through the USB to UART, U22 on the i.MX6Q board.
Terminal set to 115200 baud, no parity, 8bit data.
> - Can you initialize the device in the bootloader and check if it is working
> there?
I can get U-boot ok for all cases.
Once I TFTP the kernel across, I am okay until I get to "Starting kernel ...",
then, the UART is "working" in the sense that I get the some characters in the
style
of the kernel starting up, but they are all garbled.
I expect the kernel has started ok, but I am unable to read/write through the
UART
console because of corruptions.
Console log:
--- 8< ---
U-Boot 2009.08-1-gf65536a (Jan 12 2015 - 15:47:19)
CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature: 46 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock : 6600Hz
ipg per clock : 6600Hz
uart clock: 8000Hz
cspi clock: 6000Hz
ahb clock : 13200Hz
axi clock : 26400Hz
emi_slow clock: 13200Hz
ddr clock : 52800Hz
usdhc1 clock : 19800Hz
usdhc2 clock : 19800Hz
usdhc3 clock : 19800Hz
usdhc4 clock : 19800Hz
nfc clock : 2400Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [WDOG ]
Boot Device: SD
I2C: ready
DRAM: 1 GB
MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:serial
Out: serial
Err: serial
Found PFUZE100! deviceid=10,revid=11
Net: got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot: 0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x1200
Loading: #
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
###
RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
Hi Uwe,
Thanks for your quick response.
On 23 May 2017 15:10, Uwe Kleine-König wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD
> and RI irqs to be off
> On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> >
> > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > ensure DCD and RI irqs to be off")
> >
> > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > The console becomes unreadable and unwritable.
> >
> > Tested-by: Steve Twiss
> > Signed-off-by: Steve Twiss
>
> You're not the first to report this issue but you still have the chance
> to be the first to test a suggested patch for it.
I've just applied your patch against a clean linux-next/v4.12-rc2
I added your patch ...
> http://marc.info/?l=linux-serial&m=149434029912947&w=2
(this one?)
diff --git a/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
b/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
index 33509b4..2182548 100644
--- a/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
+++ b/gp_sparse/linux-next/v4.12-rc2/drivers/tty/serial/imx.c
@@ -2193,9 +2193,14 @@ static int serial_imx_probe(struct platform_device *pdev)
*/
writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
sport->port.membase + UCR3);
-
} else {
+ unsigned long ucr3 = UCR3_DSR;
+
+ if (!is_imx1_uart(sport))
+ ucr3 |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP;
+
writel(0, sport->port.membase + UFCR);
+ writel(ucr3, sport->port.membase + UCR3);
}
clk_disable_unprepare(sport->clk_ipg);
I've added that to my working directory, but I am still seeing the corrupted
console output on the i.MX6 Q (quad) board.
Best regards
Steve
[RESEND PATCH V7 7/7] MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms
From: Steve Twiss Additions to search terms for files supported by Dialog Semiconductor. This update will allow Dialog support to follow files for device tree bindings (onkey, thermal and watchdog) and source code for chip thermal monitoring drivers. Signed-off-by: Steve Twiss --- Hi all, Is there anybody willing to take this patch through their tree please? Dialog Semiconductor support would like to add to the MAINTAINERS search terms. This update will allow us to follow all of our files for device tree bindings and the source code relating to chip thermal monitoring described in this patch set. All dependencies for this patch have been accepted into linux-next: bindings/input/da90??-onkey.txt -> linux-next.git/commit/?id=406d5a2de0718622241eff35831f6fed0316a7d4 bindings/thermal/da90??-thermal.txt -> linux-next.git/commit/?id=28c1b08d2a156ef16e912a4c618a529e586e5dbc bindings/watchdog/da92??-wdt.txt-> linux-next.git/commit/?id=be62f363a8d5b1703c08d2cb462786a68215bcca drivers/thermal/da90??-thermal.c-> linux-next.git/commit/?id=608567aac3206ae886c79688fbb8a62c473b55ef Regards, Steve Twiss, Dialog Semiconductor This patch applies against linux-next and v4.12-rc2 v6 -> v7 - NO CODE CHANGE - Rebased from v4.11-rc3 to v4.11-rc11 - Updated the commit message - Moved the following names from CC: to TO: e-mail fields - Lee Jones - Liam Girdwood - Mark Brown v5 -> v6 - NO CODE CHANGE - Rebased from v4.8 to v4.11-rc3 - Patch renamed from [PATCH V5 8/8] to [PATCH V5 7/7] v4 -> v5 - NO CODE CHANGE - Rebased from v4.8 to v4.9 v3 -> v4 - NO CODE CHANGE - Patch renamed from [PATCH V3 9/9] to [PATCH V4 8/8] v2 -> v3 - NO CODE CHANGE - Patch renamed from [PATCH V2 10/10] to [PATCH V3 9/9] v1 -> v2 - NO CODE CHANGE MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9e98464..a580bed 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3988,7 +3988,10 @@ W: http://www.dialog-semiconductor.com/products S: Supported F: Documentation/hwmon/da90?? F: Documentation/devicetree/bindings/mfd/da90*.txt +F: Documentation/devicetree/bindings/input/da90??-onkey.txt +F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt F: Documentation/devicetree/bindings/regulator/da92*.txt +F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt F: Documentation/devicetree/bindings/sound/da[79]*.txt F: drivers/gpio/gpio-da90??.c F: drivers/hwmon/da90??-hwmon.c @@ -4003,6 +4006,7 @@ F:drivers/power/supply/da9052-battery.c F: drivers/power/supply/da91??-*.c F: drivers/regulator/da903x.c F: drivers/regulator/da9???-regulator.[ch] +F: drivers/thermal/da90??-thermal.c F: drivers/rtc/rtc-da90??.c F: drivers/video/backlight/da90??_bl.c F: drivers/watchdog/da90??_wdt.c -- end-of-patch for RESEND PATCH V7
[RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator driver
From: Steve Twiss
Regulator support for the DA9061 is added into the DA9062 regulator driver.
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].
The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.
Kconfig is updated to reflect support for DA9061 and DA9062 regulators.
Acked-by: Mark Brown
Signed-off-by: Steve Twiss
---
Hi,
This patch was Acked by Mark Brown, a long time ago, way back in Oct 2016
(https://patchwork.kernel.org/patch/9397787/).
I have kept Mark Brown's Ack attached because there have been no real
code changes since then, but I have recently updated the copyright header
slightly, rebased the code (no changes necessary) and compile tested it
against x86_64.
The MFD files which this patch depended on were accepted into linux-next
by Lee Jones last week. If there is anything in the way of this patch
acceptance, could you please let me know?
Regards,
Steve
This patch applies against linux-next and v4.12-rc2
v6 -> v7
- NO CODE CHANGE
- Compile tested ARCH=x86_64
v5 -> v6
- Rebased from v4.9 to v4.11-rc3
- Modify Copyright to match Dialog latest legal statement
v4 -> v5
- Rebased from v4.8 to v4.9
- NO CODE CHANGE
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 6/9] to [PATCH V4 5/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 06/10] to [PATCH V3 6/9]
- Added Ack from Mark Brown
v1 -> v2
- Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated header to use DA9061 and DA9062
Hi,
I have updated copyright header slightly to match Dialog's legal
expectation, but there are no code changes for this version PATCH V7.
As previously:
These changes depend on a header file provided as part of an earlier
patch [V7,4/7] mfd: da9061: MFD core support from this set. The regulator
probe() switches on the chip_type which uses enum da9062_compatible_types
in core.h from this patch.
Regards,
Steve Twiss, Dialog Semiconductor
drivers/regulator/Kconfig| 4 +-
drivers/regulator/da9062-regulator.c | 303 +--
2 files changed, 293 insertions(+), 14 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 48db87d..9de 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -214,11 +214,11 @@ config REGULATOR_DA9055
will be called da9055-regulator.
config REGULATOR_DA9062
- tristate "Dialog Semiconductor DA9062 regulators"
+ tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
This driver can also be built as a module. If so, the module
will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c
b/drivers/regulator/da9062-regulator.c
index 0638c8b..34a70d9 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,6 +1,6 @@
/*
- * da9062-regulator.c - REGULATOR device driver for DA9062
- * Copyright (C) 2015 Dialog Semiconductor Ltd.
+ * Regulator device driver for DA9061 and DA9062.
+ * Copyright (C) 2015-2017 Dialog Semiconductor
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -28,6 +28,17 @@
/* Regulator IDs */
enum {
+ DA9061_ID_BUCK1,
+ DA9061_ID_BUCK2,
+ DA9061_ID_BUCK3,
+ DA9061_ID_LDO1,
+ DA9061_ID_LDO2,
+ DA9061_ID_LDO3,
+ DA9061_ID_LDO4,
+ DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
/* Regulator operations */
-/* Current limits array (in uA) BUCK1 and BUCK3.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_[BUCK1|BUCK3]
+ * - DA9062_ID_[BUCK1|BUCK2|BUCK4]
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_a_limits[] = {
50, 60, 70, 80, 90, 100, 110, 120,
130, 140, 150, 160, 170, 180, 190, 200
};
-/* Current limits array (in uA) for BUCK2.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_BUCK2
+ * - DA9062_ID_BUCK3
+ * Entry indexes corres
[PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
From: Steve Twiss
Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
ensure DCD and RI irqs to be off")
The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
be off, causes a serial console display problem the i.MX6Q SABRESD board.
The console becomes unreadable and unwritable.
Tested-by: Steve Twiss
Signed-off-by: Steve Twiss
---
This patch applies against linux-next and v4.12-rc2
Hi,
I have been seeing a problem with the serial output console on the i.MX6Q
SABRESD, but not the i.MX6DL SABRESD. Everything was fine up to
linux-mainline/v4.11 but changed after linux-next/next-20170501.
Some bisection has pointed at the commit
e61c38d85b7392e033ee03bca46f1d6006156175 which, once removed from my
linux-next/v4.12-rc2 build allows the i.MX6Q board to display the console
correctly again.
This patch removes the original commit e61c38d85b7392e ("serial: imx:
setup DCEDTE early and ensure DCD and RI irqs to be off") from linux-next
v4.12-rc2 and fixes the serial problem seen in the i.MX6Q SABRESD board.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/tty/serial/imx.c | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 33509b4..b4340b5 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1325,10 +1325,19 @@ static int imx_startup(struct uart_port *port)
if (!is_imx1_uart(sport)) {
temp = readl(sport->port.membase + UCR3);
- temp |= UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
+ /*
+* The effect of RI and DCD differs depending on the UFCR_DCEDTE
+* bit. In DCE mode they control the outputs, in DTE mode they
+* enable the respective irqs. At least the DCD irq cannot be
+* cleared on i.MX25 at least, so it's not usable and must be
+* disabled. I don't have test hardware to check if RI has the
+* same problem but I consider this likely so it's disabled for
+* now, too.
+*/
+ temp |= IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP |
+ UCR3_DTRDEN | UCR3_RI | UCR3_DCD;
if (sport->dte_mode)
- /* disable broken interrupts */
temp &= ~(UCR3_RI | UCR3_DCD);
writel(temp, sport->port.membase + UCR3);
@@ -1610,6 +1619,8 @@ static void imx_flush_buffer(struct uart_port *port)
ufcr = readl(sport->port.membase + UFCR);
ufcr = (ufcr & (~UFCR_RFDIV)) | UFCR_RFDIV_REG(div);
+ if (sport->dte_mode)
+ ufcr |= UFCR_DCEDTE;
writel(ufcr, sport->port.membase + UFCR);
writel(num, sport->port.membase + UBIR);
@@ -2177,27 +2188,6 @@ static int serial_imx_probe(struct platform_device *pdev)
UCR1_TXMPTYEN | UCR1_RTSDEN);
writel_relaxed(reg, sport->port.membase + UCR1);
- if (!is_imx1_uart(sport) && sport->dte_mode) {
- /*
-* The DCEDTE bit changes the direction of DSR, DCD, DTR and RI
-* and influences if UCR3_RI and UCR3_DCD changes the level of
RI
-* and DCD (when they are outputs) or enables the respective
-* irqs. So set this bit early, i.e. before requesting irqs.
-*/
- writel(UFCR_DCEDTE, sport->port.membase + UFCR);
-
- /*
-* Disable UCR3_RI and UCR3_DCD irqs. They are also not
-* enabled later because they cannot be cleared
-* (confirmed on i.MX25) which makes them unusable.
-*/
- writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
- sport->port.membase + UCR3);
-
- } else {
- writel(0, sport->port.membase + UFCR);
- }
-
clk_disable_unprepare(sport->clk_ipg);
/*
--
end-of-patch for PATCH V1
RE: [PATCH V7 4/7] mfd: da9061: MFD core support
On 04 April 2017 09:39, Lee Jones wrote: > Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support > > On Mon, 03 Apr 2017, Steve Twiss wrote: > > From: Steve Twiss > > MFD support for DA9061 is provided as part of the DA9062 device driver. > > > > The registers header file adds two new chip variant IDs defined in DA9061 > > and DA9062 hardware. The core header file adds new software enumerations > > for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration > > for distinguishing between DA9061/62 devices in software. > > > > The core source code adds a new .compatible of_device_id entry. This is > > extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The > > .data entry now holds a reference to the enumerated device type. > > > > A new regmap_irq_chip model is added for DA9061 and this supports the new > > list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the > > new sub system components for DA9061. Support is added for a new DA9061 > > regmap_config which lists the correct readable, writable and volatile > > ranges for this chip. > > > > The probe function uses the device tree compatible string to switch on the > > da9062_compatible_types and configure the correct mfd cells, irq chip and > > regmap config. > > > > Kconfig is updated to reflect support for DA9061 and DA9062 PMICs. > > > > Signed-off-by: Steve Twiss > > Ah, here it is. > > Applied, thanks. Hi Lee, I noticed the DA9061 core support has been added into linux-next, however the commit message was changed from the original title: "mfd: da9061: MFD core support" to add the mistake: "mfd: Add suppfor for DA9061" https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d3fe0806025cacdab1462d5704e1c98ab9db4564 Can this be fixed please? This patch has not been upstreamed into linux-mainline and is still in linux-next. Regards, Steve
[RESEND PATCH V7 1/5] Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
From: Steve Twiss
Add binding information for DA9062 and DA9061 watchdog.
Example bindings for both DA9062 and DA9061 devices are added. For
the DA9061 device, a fallback compatible line is added as a valid
combination of compatible strings.
The original binding for DA9062 (only) used to reside inside the
Documentation/devicetree/bindings/mfd/da9062.txt MFD document.
The da9062-watchdog section was deleted in that file and replaced
with a link to the new DA9061/62 binding information stored in this
patch.
Acked-by: Rob Herring
Signed-off-by: Steve Twiss
---
Hi,
I have just noticed.
The driver code changes for the da9062/61 watchdog have been applied to
the linux kernel. The da9062/61 alterations for
drivers/watchdog/da9062_wdt.c appear in linux-stable/v4.10-rc1. Those
changes are linked to this binding patch, but this patch seems to have
been missed out.
The source code dependency for this patch is given in the commit:
72106c1 v4.10-rc1 watchdog: da9062/61: watchdog driver
I don't see anything blocking for merge of this patch now.
Regards,
Steve
This patch applies against linux-next and v4.11-rc3
v6 -> v7
- NO CODE CHANGE
v5 -> v6
- NO CODE CHANGE
- Rebased from v4.9 to v4.11-rc3
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 2/9] to [PATCH V4 1/8]
- Added Acked-by Rob Herring
v2 -> v3
- Patch renamed from [PATCH V1 02/10] to [PATCH V3 2/9]
- Each compatible line should be a valid combination of compatible
strings, alter DA9061 line to include the fall back compatible string
- Update the commit message to describe this change
- Add information about associated patches from this set without
describing them as being explicitly dependent on this binding
v1 -> v2
- Patch renamed from [PATCH V1 07/10] to [PATCH V2 02/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated the patch description to be explicit about where parts of
this binding had originally been stored
- A second example for DA9061 is provided to highlight the use of a
fall-back compatible option for the DA9062 watchdog driver
As previously:
For the watchdog case: the DA9062 device driver is compatible with the
DA9061 and for this reason there is minimal change required to the DA9062
watchdog device driver. The example for the DA9061 watchdog shows the
use of a fall-back compatible string.
Other information:
The device driver from this patch set (associated with this binding) is
[PATCH V5 6/8] watchdog: da9061: watchdog driver
Regards,
Steve Twiss, Dialog Semiconductor
.../devicetree/bindings/watchdog/da9062-wdt.txt| 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
new file mode 100644
index 000..b935b52
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
@@ -0,0 +1,23 @@
+* Dialog Semiconductor DA9062/61 Watchdog Timer
+
+Required properties:
+
+- compatible: should be one of the following valid compatible string lines:
+ "dlg,da9061-watchdog", "dlg,da9062-watchdog"
+ "dlg,da9062-watchdog"
+
+Example: DA9062
+
+ pmic0: da9062@58 {
+ watchdog {
+ compatible = "dlg,da9062-watchdog";
+ };
+ };
+
+Example: DA9061 using a fall-back compatible for the DA9062 watchdog driver
+
+ pmic0: da9061@58 {
+ watchdog {
+ compatible = "dlg,da9061-watchdog",
"dlg,da9062-watchdog";
+ };
+ };
--
end-of-patch for RESEND PATCH V7
