Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Linus Walleij @ 2014-02-03 10:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140123151123.GE8586@lee--X1>

On Thu, Jan 23, 2014 at 4:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > Patch looks good to me. Is there any reason why we should rush this in
>> > for v3.14, or is it okay to go to -next?
>>
>> No rush, but it's been on review like forever so unless there is
>> some noise from the DT people at -rc1 I'd be very happy if you
>> could apply patches 1 & 2 by then.
>
> I'm just waiting for their Ack. If I don't have it soon I'll review it
> myself and any changes will have to come in via subsequent patch
> submissions.
>
> I think it's sensible to head for v3.15 for this set.

So now that v3.14-rc1 is out can we queue this stuff?

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH] [RFC] ARM: ixp4xx: fix timer latch calculation
From: Uwe Kleine-König @ 2014-02-03 10:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140113194259.GG29475@pengutronix.de>

In commit f0402f9b4711 ("ARM: ixp4xx: stop using <mach/timex.h>")
I didn't intend to implement a functional change, but as Olof noticed I
failed---at least a bit. Before this commit the following was used to
determine the latch value used:

	#define IXP4XX_TIMER_FREQ 66666000
	#define CLOCK_TICK_RATE \
		(((IXP4XX_TIMER_FREQ / HZ & ~IXP4XX_OST_RELOAD_MASK) + 1) * HZ)
	#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ)

The complicated calculation was done "b/c the timer register ignores the
bottom 2 bits of the LATCH value." With HZ=100 CLOCK_TICK_RATE used to
calculate to 66666100 and so LATCH to 666661. In ixp4xx_set_mode the
term

	LATCH & ~IXP4XX_OST_RELOAD_MASK

was used to write to the relevant register (with IXP4XX_OST_RELOAD_MASK
being 3) and so effectively 666660 was used.

In commit f0402f9b4711 I translated that to:

	#define IXP4XX_TIMER_FREQ 66666000
	#define IXP4XX_LATCH DIV_ROUND_CLOSEST(IXP4XX_TIMER_FREQ, HZ)

which results in the same register writes, but still doesn't bear in
mind that the two least significant bits cannot be specified (which is
relevant only when HZ or IXP4XX_TIMER_FREQ are changed).

Instead of reverting back to the old approach use a more obvious and
also more correct way to calculate LATCH. (Regarding the more
correct claim: With IXP4XX_TIMER_FREQ == 66665999, the old code resulted
in LATCH = 666657 corresponding to a cycle time of 0.009999940149400597
seconds (error: -6.0e-8 s) while the new approach results in LATCH =
666660 and so a cycle time of 0.010000000150001503 seconds
(error: 1.5e-10 s).)

Fixes: f0402f9b4711 ("ARM: ixp4xx: stop using <mach/timex.h>")
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,

I didn't hear anything back from the ixp4xx maintainers, I didn't find a
reference manual and I don't have an ixp4xx machine to test this patch.
Still I'm confident it works as expected and results in a more exact
clock calculation than both before and after my patch.

Olof requested this to be a seperate patch to not need to reverify the
rest of the series. Does this make the series ready to be merged for
3.15 now? If so, should I send a new pull request with this patch
applied on top of the old request or do you handle that yourself?

Best regards
Uwe

 arch/arm/mach-ixp4xx/common.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 20b62aa30086..37e6cdac1642 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -45,7 +45,15 @@
 #include <asm/mach/time.h>
 
 #define IXP4XX_TIMER_FREQ 66666000
-#define IXP4XX_LATCH DIV_ROUND_CLOSEST(IXP4XX_TIMER_FREQ, HZ)
+
+/*
+ * The timer register doesn't allow to specify the two least significant bits of
+ * the timeout value and assumes them being zero. So make sure IXP4XX_LATCH is
+ * the best value with the two least significant bits unset.
+ */
+#define IXP4XX_LATCH DIV_ROUND_CLOSEST(IXP4XX_TIMER_FREQ, \
+				       (IXP4XX_OST_RELOAD_MASK + 1) * HZ) * \
+			(IXP4XX_OST_RELOAD_MASK + 1)
 
 static void __init ixp4xx_clocksource_init(void);
 static void __init ixp4xx_clockevent_init(void);
-- 
1.8.5.3

^ permalink raw reply related

* [PATCH 16/18] charger: max14577: Add support for MAX77836 charger
From: Lee Jones @ 2014-02-03 10:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-17-git-send-email-k.kozlowski@samsung.com>

On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:

> Add support for MAX77836 charger to the max14577 driver. The MAX77836
> charger is almost the same as 14577 model except:
>  - No dead-battery detection;
>  - Support for special charger (like in max77693);
>  - Support for DX over-voltage protection (like in max77693);
>  - Lower values of charging current (two times lower current for
>    slow/fast charge, much lower EOC current);
>  - Slightly different values in ChgTyp field of STATUS2 register. On
>    MAX14577 0x6 is reserved and 0x7 dead battery. On the MAX77836 the
>    0x6 means special charger and 0x7 is reserved. Regardless of these
>    differences the driver maps them to one enum maxim_muic_charger_type.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Anton Vorontsov <anton@enomsg.org>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> ---
>  drivers/extcon/extcon-max14577.c     |    2 +-
>  drivers/power/max14577_charger.c     |   81 +++++++++++++++++++++++++++-------
>  include/linux/mfd/max14577-private.h |   57 +++++++++++++++++-------
>  3 files changed, 106 insertions(+), 34 deletions(-)

For the MFD changes:
  Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 15/18] regulator: max14577: Add support for max77836 regulators
From: Lee Jones @ 2014-02-03 10:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-16-git-send-email-k.kozlowski@samsung.com>

On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:

> Add support for MAX77836 chipset and its additional two LDO regulators.
> These LDO regulators are controlled by the PMIC block with additional
> regmap (different I2C slave address).
> 
> The MAX77836 charger and safeout regulators are almost identical to
> MAX14577. The registry layout is the same, except values for charger's
> current. The patch adds simple mapping between device type and supported
> current by the charger regulator.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/regulator/max14577.c         |  275 +++++++++++++++++++++++++++++-----
>  include/linux/mfd/max14577-private.h |   32 +++-
>  include/linux/mfd/max14577.h         |   10 ++
>  3 files changed, 281 insertions(+), 36 deletions(-)

For the MFD changes:
  Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 14/18] extcon: max14577: Add support for max77836
From: Lee Jones @ 2014-02-03 10:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-15-git-send-email-k.kozlowski@samsung.com>

On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:

> Add support for MAX77836 chipset to the max14577 extcon driver. The
> MAX77836 MUIC has additional interrupts (VIDRM, ADC1K) so IRQ handling
> is split up into two functions: max14577_parse_irq() and
> max77836_parse_irq().
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/extcon/extcon-max14577.c     |  107 ++++++++++++++++++++++++++++------
>  drivers/mfd/max14577.c               |    1 +
>  include/linux/mfd/max14577-private.h |    3 +
>  3 files changed, 93 insertions(+), 18 deletions(-)

For the MFD changes:
  Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 13/18] mfd: max77836: Add max77836 support to max14577 driver
From: Lee Jones @ 2014-02-03 10:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-14-git-send-email-k.kozlowski@samsung.com>

On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:

> Add Maxim 77836 support to max14577 driver. The chipsets have same MUIC
> component so the extcon, charger and regulators are almost the same. The
> max77836 however has also PMIC and Fuel Gauge.
> 
> The MAX77836 uses three I2C slave addresses and has additional interrupts
> (related to PMIC and Fuel Gauge). It has also Interrupt Source register,
> just like MAX77686 and MAX77693.
> 
> The MAX77836 PMIC's TOPSYS and INTSRC interrupts are reported in the
> PMIC block. The PMIC block has different I2C slave address and uses own
> regmap so another regmap_irq_chip is needed.
> 
> Since we have two regmap_irq_chip, use shared interrupts on MAX77836.
> 
> This patch adds additional defines and functions to the max14577 MFD core
> driver so the driver will handle both chipsets.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/mfd/max14577.c               |  215 ++++++++++++++++++++++++++++++++--
>  include/linux/mfd/max14577-private.h |   85 +++++++++++++-
>  include/linux/mfd/max14577.h         |    7 +-
>  3 files changed, 296 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> index 224aba8c5b3f..5b10f6f89834 100644
> --- a/drivers/mfd/max14577.c
> +++ b/drivers/mfd/max14577.c
> @@ -1,7 +1,7 @@
>  /*
> - * max14577.c - mfd core driver for the Maxim 14577
> + * max14577.c - mfd core driver for the Maxim 14577/77836

We may wish to consider changing the name of this file at a later
date.

> - * Copyright (C) 2013 Samsung Electrnoics
> + * Copyright (C) 2013,2014 Samsung Electrnoics

You can remove the the '2013' completely now.

>   * Chanwoo Choi <cw00.choi@samsung.com>
>   * Krzysztof Kozlowski <k.kozlowski@samsung.com>
>   *
> @@ -37,11 +37,31 @@ static struct mfd_cell max14577_devs[] = {
>  	{ .name = "max14577-charger", },
>  };
>  
> +static struct mfd_cell max77836_devs[] = {
> +	{
> +		.name = "max77836-muic",
> +		.of_compatible = "maxim,max77836-muic",
> +	},
> +	{
> +		.name = "max77836-regulator",
> +		.of_compatible = "maxim,max77836-regulator",
> +	},
> +	{ .name = "max77836-charger", },

Why doesn't the charger require a compatible string?

> +	{
> +		.name = "max77836-battery",
> +		.of_compatible = "maxim,max77836-battery",
> +	},
> +};
> +
> @@ -56,6 +76,29 @@ static bool max14577_muic_volatile_reg(struct device *dev, unsigned int reg)
>  	return false;
>  }
>  
> +static bool max77836_muic_volatile_reg(struct device *dev, unsigned int reg)
> +{
> +	/* Any max14577 volatile registers are also max77836 volatile. */
> +	if (max14577_muic_volatile_reg(dev, reg))
> +		return true;

New line here please.

> +	switch (reg) {
> +	case MAX77836_FG_REG_VCELL_MSB ... MAX77836_FG_REG_SOC_LSB:
> +	case MAX77836_FG_REG_CRATE_MSB ... MAX77836_FG_REG_CRATE_LSB:
> +	case MAX77836_FG_REG_STATUS_H ... MAX77836_FG_REG_STATUS_L:
> +		/* fall through */

It's okay not to have these here. We know how switch statements
work. ;)

> +	case MAX77836_PMIC_REG_INTSRC:
> +		/* fall through */
> +	case MAX77836_PMIC_REG_TOPSYS_INT:
> +		/* fall through */
> +	case MAX77836_PMIC_REG_TOPSYS_STAT:
> +		return true;
> +	default:
> +		break;
> +	}
> +	return false;
> +}
> +
> +

Superfluous new line here.

> +static const struct regmap_irq_chip max77836_muic_irq_chip = {
> +	.name			= "max77836-muic",
> +	.status_base		= MAXIM_MUIC_REG_INT1,
> +	.mask_base		= MAXIM_MUIC_REG_INTMASK1,
> +	.mask_invert		= 1,

I'd prefer the use of 'true' or 'false' for bools.

> +	.num_regs		= 3,
> +	.irqs			= max77836_muic_irqs,
> +	.num_irqs		= ARRAY_SIZE(max77836_muic_irqs),
> +};
> +

<snip>

> +static const struct regmap_irq_chip max77836_pmic_irq_chip = {
> +	.name			= "max77836-pmic",
> +	.status_base		= MAX77836_PMIC_REG_TOPSYS_INT,
> +	.mask_base		= MAX77836_PMIC_REG_TOPSYS_INT_MASK,
> +	.mask_invert		= 0,

'false' please.

> +	.num_regs		= 1,
> +	.irqs			= max77836_pmic_irqs,
> +	.num_irqs		= ARRAY_SIZE(max77836_pmic_irqs),
> +};
> +

<snip>

> +static int max77836_init(struct maxim_core *maxim_core)
> +{
> +	int ret;
> +	u8 intsrc_mask;
> +
> +	maxim_core->i2c_pmic = i2c_new_dummy(maxim_core->i2c->adapter,
> +			I2C_ADDR_PMIC);
> +	if (!maxim_core->i2c_pmic) {
> +		dev_err(maxim_core->dev, "Failed to register PMIC I2C device\n");
> +		return -EPERM;

Not sure this is the best errno to return.

Perhaps -ENODEV would be more suitable?

<snip>

>  #define MAXIM_STATUS2_CHGTYP_MASK	(0x7 << MAXIM_STATUS2_CHGTYP_SHIFT)
>  #define MAXIM_STATUS2_CHGDETRUN_MASK	(0x1 << MAXIM_STATUS2_CHGDETRUN_SHIFT)
>  #define MAXIM_STATUS2_DCDTMR_MASK	(0x1 << MAXIM_STATUS2_DCDTMR_SHIFT)
>  #define MAXIM_STATUS2_DBCHG_MASK	(0x1 << MAXIM_STATUS2_DBCHG_SHIFT)
>  #define MAXIM_STATUS2_VBVOLT_MASK	(0x1 << MAXIM_STATUS2_VBVOLT_SHIFT)
> +#define MAX77836_STATUS2_VIDRM_MASK	(0x1 << MAX77836_STATUS2_VIDRM_SHIFT)

It's up to you, but all of these "0x1 <<"s can be replaced with the
BIT() macro if you so wished.

>  /* MAX14577 STATUS3 register */
>  #define MAXIM_STATUS3_EOC_SHIFT		0
> @@ -232,6 +242,70 @@ enum maxim_muic_charger_type {
>  
>  
>  

Do all of these extra new lines really exist, or is it just a patch
thing? If they do, can you get rid of them please?

> +/* Slave addr = 0x46: PMIC */
> +enum max77836_pmic_reg {
> +	MAX77836_COMP_REG_COMP1			= 0x60,
> +
> +	MAX77836_LDO_REG_CNFG1_LDO1		= 0x51,
> +	MAX77836_LDO_REG_CNFG2_LDO1		= 0x52,
> +	MAX77836_LDO_REG_CNFG1_LDO2		= 0x53,
> +	MAX77836_LDO_REG_CNFG2_LDO2		= 0x54,
> +	MAX77836_LDO_REG_CNFG_LDO_BIAS		= 0x55,
> +
> +	MAX77836_PMIC_REG_PMIC_ID		= 0x20,
> +	MAX77836_PMIC_REG_PMIC_REV		= 0x21,
> +	MAX77836_PMIC_REG_INTSRC		= 0x22,
> +	MAX77836_PMIC_REG_INTSRC_MASK		= 0x23,
> +	MAX77836_PMIC_REG_TOPSYS_INT		= 0x24,
> +	MAX77836_PMIC_REG_TOPSYS_INT_MASK	= 0x26,
> +	MAX77836_PMIC_REG_TOPSYS_STAT		= 0x28,
> +	MAX77836_PMIC_REG_MRSTB_CNTL		= 0x2A,
> +	MAX77836_PMIC_REG_LSCNFG		= 0x2B,
> +
> +	MAX77836_PMIC_REG_END,
> +};

Any reason why these aren't in numerical order?

<snip>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Ivan Khoronzhuk @ 2014-02-03 10:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <52E9D23D.2080506@ti.com>

I've sent v5.
Please, look at it http://www.spinics.net/lists/arm-kernel/msg303953.html

On 01/30/2014 06:17 AM, Sekhar Nori wrote:
> On Wednesday 29 January 2014 08:50 PM, Ivan Khoronzhuk wrote:
>> Hi Sekhar,
>>
>> Do you want me to correct it?
> Yes, please!
>
> Thanks,
> Sekhar
>

^ permalink raw reply

* [PATCH 10/18] mfd: max14577: Add detection of device type
From: Lee Jones @ 2014-02-03  9:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-11-git-send-email-k.kozlowski@samsung.com>

> This patch continues the preparation for adding support for max77836
> device to existing max14577 driver.
> 
> Add enum for types of devices supported by this driver. The device type
> will be detected by matching of_device_id, or i2c_device_id as a
> fallback.
> 
> The patch also moves to separate function the code related to displaying
> DeviceID register values.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/mfd/max14577.c               |   61 +++++++++++++++++++++++-----------
>  include/linux/mfd/max14577-private.h |   12 ++++---
>  2 files changed, 50 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> index 1d8104213b3e..224aba8c5b3f 100644
> --- a/drivers/mfd/max14577.c
> +++ b/drivers/mfd/max14577.c
> @@ -20,6 +20,7 @@

<snip>

> +static void max14577_print_dev_type(struct maxim_core *maxim_core)
> +{
> +	u8 reg_data, vendor_id, device_id;
> +	int ret = max14577_read_reg(maxim_core->regmap_muic,
> +			MAXIM_MUIC_REG_DEVICEID, &reg_data);

I'm not a big fan of declaring variables whilst feeding them with
function return values. Can you separate the two please?

> +	if (ret) {
> +		dev_err(maxim_core->dev, "Failed to read DEVICEID
> register: %d\n",

I think this is too many chars.

> +				ret);
> +		return;
> +	}
> +

<snip>

> -	ret = max14577_read_reg(maxim_core->regmap_muic,
> -			MAXIM_MUIC_REG_DEVICEID, &reg_data);
> -	if (ret) {
> -		dev_err(maxim_core->dev, "Device not found on this channel: %d\n",
> -				ret);
> -		return ret;
> +	if (np) {
> +		const struct of_device_id *of_id =
> +			of_match_device(max14577_dt_match, &i2c->dev);

Again this is a bit messy. Bring it down onto a separate line.

> +		if (of_id)
> +			maxim_core->dev_type = (unsigned int)of_id->data;
> +	} else {
> +		maxim_core->dev_type = id->driver_data;
>  	}

<snip>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 09/18] mfd: max14577: Add "muic" suffix to regmap and irq_chip
From: Lee Jones @ 2014-02-03  9:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-10-git-send-email-k.kozlowski@samsung.com>

> This patch continues the preparation for adding support for max77836
> device to existing max14577 driver.
> 
> Add "muic" suffix to regmap and irq_data fields in maxim_core state
> container to prepare for max77836 support.
> This is only a rename-like patch, new code is not added.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/extcon/extcon-max14577.c     |   17 +++++++++--------
>  drivers/mfd/max14577.c               |   22 +++++++++++-----------
>  drivers/power/max14577_charger.c     |    8 ++++----
>  drivers/regulator/max14577.c         |    2 +-
>  include/linux/mfd/max14577-private.h |    4 ++--
>  5 files changed, 27 insertions(+), 26 deletions(-)

Happy to apply this with maintainer Acks.
  Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* NFS client broken in Linus' tip
From: Takashi Iwai @ 2014-02-03  9:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391378678.8123.5.camel@leira.trondhjem.org>

At Sun, 02 Feb 2014 17:04:38 -0500,
Trond Myklebust wrote:
> 
> On Sun, 2014-02-02 at 12:27 +0000, Russell King - ARM Linux wrote:
> > On Sat, Feb 01, 2014 at 01:03:28AM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Jan 31, 2014 at 03:59:30PM -0500, Trond Myklebust wrote:
> > > > On Thu, 2014-01-30 at 15:38 +0000, Russell King - ARM Linux wrote:
> > > > > On Thu, Jan 30, 2014 at 06:32:08AM -0800, Christoph Hellwig wrote:
> > > > > > On Thu, Jan 30, 2014 at 02:27:52PM +0000, Russell King - ARM Linux wrote:
> > > > > > > Yes and no.  I still end up with an empty /etc/mtab, but the file now
> > > > > > > exists.  However, I can create and echo data into /etc/mtab, but it seems
> > > > > > > that can't happen at boot time.
> > > > > > 
> > > > > > Odd.  Can you disable CONFIG_NFSD_V3_ACL for now to isolate the issue?
> > > > > 
> > > > > Unfortunately, that results in some problem at boot time, which
> > > > > ultimately ends up with the other three CPUs being stopped, and
> > > > > hence the original reason scrolls off the screen before it can be
> > > > > read... even at 1920p.
> > > > > 
> > > > Hi Russell,
> > > > 
> > > > The following patch fixes the issue for me.
> > > 
> > > It doesn't entirely fix the issue for me, instead we've got even weirder
> > > behaviour:
> > > 
> > > root at cubox-i4:~# ls -al test
> > > ls: cannot access test: No such file or directory
> > > root at cubox-i4:~# touch test
> > > root at cubox-i4:~# ls -al test
> > > -rw-r--r-- 1 root root 0 Feb  1 01:01 test
> > > root at cubox-i4:~# echo foo > test
> > > root at cubox-i4:~# ls -al test
> > > -rw-r--r-- 1 root root 4 Feb  1 01:01 test
> > > root at cubox-i4:~# cat test
> > > foo
> > > root at cubox-i4:~# rm test
> > > root at cubox-i4:~# echo foo > test
> > > -bash: test: Operation not supported
> > > root at cubox-i4:~# ls -al test
> > > -rw-r--r-- 1 root root 0 Feb  1 01:01 test
> > 
> > FYI, I just tested Linus' tip, and NFS is still broken.
> > 
> Hi Russell,
> 
> The following patch should fix the above problem. It needs to be applied
> on top of the one I sent you previously.

I've hit the same problem, and your two patches seem fixing it.
I tested them on top of 3.14-rc1.  Feel free to take my tested-by tag

  Tested-by: Takashi Iwai <tiwai@suse.de>


> In addition, you will want to
> apply Noah Massey's patch from
> http://lkml.kernel.org/r/1391135472-9639-1-git-send-email-Noah.Massey at gmail.com 

Do I still need to test this one, too?


Thanks!

Takashi

^ permalink raw reply

* [PATCH 08/18] mfd: max14577: Rename state container to maxim_core
From: Lee Jones @ 2014-02-03  9:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-9-git-send-email-k.kozlowski@samsung.com>

> This patch continues the preparation for adding support for max77836
> device to existing max14577 driver.
> 
> The patch renames the struct "max14577" state container to "maxim_core".
> This is only a rename-like patch, new code is not added.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/extcon/extcon-max14577.c     |   22 +++++------
>  drivers/mfd/max14577.c               |   68 +++++++++++++++++-----------------
>  drivers/power/max14577_charger.c     |   16 ++++----
>  drivers/regulator/max14577.c         |    6 +--
>  include/linux/mfd/max14577-private.h |    5 ++-
>  5 files changed, 60 insertions(+), 57 deletions(-)

Need some more maintainer Acks here.

> -struct max14577 {
> +/*
> + * State container for max14577-like drivers.
> + */

I don't think this comment is required.

Besides that, the code looks fine:
  Acked-by: Lee Jones <lee.jones@linaro.org>

> +struct maxim_core {
>  	struct device *dev;
>  	struct i2c_client *i2c; /* Slave addr = 0x4A */
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 07/18] mfd: max14577: Rename and add MAX14577 symbols to prepare for max77836
From: Lee Jones @ 2014-02-03  9:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-8-git-send-email-k.kozlowski@samsung.com>

> This patch prepares for adding support for max77836 device to existing
> max14577 driver:
> 1. Renames most of symbols and defines prefixed with MAX14577 to MAXIM.
> 2. Adds prefixes (MAXIM or MAX14577) to defines without any MAX* prefix.
> 
> This is only a rename-like patch, new code is not added.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/extcon/extcon-max14577.c     |  105 ++++-----
>  drivers/mfd/max14577.c               |   51 ++---
>  drivers/power/max14577_charger.c     |   81 +++----
>  drivers/regulator/max14577.c         |   44 ++--
>  include/linux/mfd/max14577-private.h |  399 ++++++++++++++++------------------
>  include/linux/mfd/max14577.h         |    2 +-
>  6 files changed, 333 insertions(+), 349 deletions(-)

I think the name changes instil some clarity here.

I still need the other Acks before applying the patch though.

For now you can have my:
  Acked-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH] arm64: KVM: Add VGIC device control for arm64
From: Marc Zyngier @ 2014-02-03  9:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1391377262-30188-1-git-send-email-christoffer.dall@linaro.org>

On 2014-02-02 21:41, Christoffer Dall wrote:
> This fixes the build breakage introduced by
> c07a0191ef2de1f9510f12d1f88e3b0b5cd8d66f and adds support for the 
> device
> control API and save/restore of the VGIC state for ARMv8.
>
> The defines were simply missing from the arm64 header files and
> uaccess.h must be implicitly imported from somewhere else on arm.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>

Acked-by: Marc Zyngier <marc.zyngier@arm.com>

         M.

> ---
>  arch/arm64/include/uapi/asm/kvm.h | 9 +++++++++
>  virt/kvm/arm/vgic.c               | 1 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm64/include/uapi/asm/kvm.h
> b/arch/arm64/include/uapi/asm/kvm.h
> index 495ab6f..eaf54a3 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -148,6 +148,15 @@ struct kvm_arch_memory_slot {
>  #define KVM_REG_ARM_TIMER_CNT		ARM64_SYS_REG(3, 3, 14, 3, 2)
>  #define KVM_REG_ARM_TIMER_CVAL		ARM64_SYS_REG(3, 3, 14, 0, 2)
>
> +/* Device Control API: ARM VGIC */
> +#define KVM_DEV_ARM_VGIC_GRP_ADDR	0
> +#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS	1
> +#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS	2
> +#define   KVM_DEV_ARM_VGIC_CPUID_SHIFT	32
> +#define   KVM_DEV_ARM_VGIC_CPUID_MASK	(0xffULL <<
> KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT	0
> +#define   KVM_DEV_ARM_VGIC_OFFSET_MASK	(0xffffffffULL <<
> KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> +
>  /* KVM_IRQ_LINE irq field index values */
>  #define KVM_ARM_IRQ_TYPE_SHIFT		24
>  #define KVM_ARM_IRQ_TYPE_MASK		0xff
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index be456ce..8ca405c 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -24,6 +24,7 @@
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/of_irq.h>
> +#include <linux/uaccess.h>
>
>  #include <linux/irqchip/arm-gic.h>

-- 
Fast, cheap, reliable. Pick two.

^ permalink raw reply

* [PATCH 05/18] mfd: max14577: Use of_match_ptr() in i2c_driver
From: Lee Jones @ 2014-02-03  9:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-6-git-send-email-k.kozlowski@samsung.com>

> Use of_match_ptr() in assignment of i2c_driver.of_match_table.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/mfd/max14577.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> index 2ac2f2d7cea6..75b37082a3fe 100644
> --- a/drivers/mfd/max14577.c
> +++ b/drivers/mfd/max14577.c
> @@ -224,7 +224,7 @@ static struct i2c_driver max14577_i2c_driver = {
>  		.name = "max14577",
>  		.owner = THIS_MODULE,
>  		.pm = &max14577_pm,
> -		.of_match_table = max14577_dt_match,
> +		.of_match_table = of_match_ptr(max14577_dt_match),

Are you sure this is required?

>  	},
>  	.probe = max14577_i2c_probe,
>  	.remove = max14577_i2c_remove,

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 04/18] mfd: max14577: Add of_compatible to extcon mfd_cell
From: Lee Jones @ 2014-02-03  9:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-5-git-send-email-k.kozlowski@samsung.com>

On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:

> Add of_compatible ("maxim,max14577-muic") to the mfd_cell for extcon
> driver. If entry with such compatible is present in the DTS, the extcon
> driver will have of_node set.
> 
> This may be useful for extcon consumers and it is documented in
> bindings documentation.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/mfd/max14577.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 03/18] mfd: max14577: Remove not needed header inclusion
From: Lee Jones @ 2014-02-03  9:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-4-git-send-email-k.kozlowski@samsung.com>

> Remove not needed max14577-private.h header inclusion in the main driver
> header. Remove obvious comment.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  include/linux/mfd/max14577.h |    5 -----
>  1 file changed, 5 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 02/18] mfd: max14577: Remove unused enum max14577_irq_source
From: Lee Jones @ 2014-02-03  9:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390911522-28209-3-git-send-email-k.kozlowski@samsung.com>

> Remove unused symbol: enum max14577_irq_source.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  include/linux/mfd/max14577-private.h |    8 --------
>  1 file changed, 8 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 5/5 v2] clk: versatile: respect parent rate in ICST clock
From: Linus Walleij @ 2014-02-03  9:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390254865-15488-1-git-send-email-linus.walleij@linaro.org>

On Mon, Jan 20, 2014 at 10:54 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:

> If the ICST clock has a parent, respect the rate of the parent
> when calculating the clock frequency. As this involves modifying
> the ICST parameter struct, make a cloned copy (the divisor
> arrays should be safe) so we can update the .ref field.
>
> Do not define the reference clock on the Integrator as we have
> the reference clock from the device tree. Keep it everywhere
> else.
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - As Russell observed: the params are static objects, so if
>   we want to alter them, we better make a copy of them.
>
> Hi Mike, looking for an ACK for this one as well.

Hi Mike,

Ping on this!

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH 4/5] clk: versatile: pass a parent to the ICST clock
From: Linus Walleij @ 2014-02-03  9:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390251324-6369-1-git-send-email-linus.walleij@linaro.org>

On Mon, Jan 20, 2014 at 9:55 PM, Linus Walleij <linus.walleij@linaro.org> wrote:

> As we want to actually define the parent frequency in the device
> tree for the ICST clocks, modify the clock registration function
> to take a parent argument.
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Hi Mike, looking for an ACK to take this through the Integrator
> and ARM SOC tree.

Hi Mike,

Ping on this!

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH 2/5] irqchip: support cascaded VICs
From: Linus Walleij @ 2014-02-03  9:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390397471-6802-3-git-send-email-linus.walleij@linaro.org>

On Wed, Jan 22, 2014 at 2:31 PM, Linus Walleij <linus.walleij@linaro.org> wrote:

> This adds support for a VIC to be cascaded off another IRQ.
> On the Integrator/AP logical module IM-PD1 there is a VIC
> cascaded off the central FPGA IRQ controller so this is
> needed for that to work out.
>
> In order for the plug-in board to be able to register all
> the devices with their IRQs relative to the offset of the
> base obtained for the cascaded VIC, the base IRQ number
> is passed back to the caller.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> tglx: if you're happy with this pls ACK it so I can take this
> through the ARM SoC tree.

Ping on this, too.

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH 1/5] irqchip: vic: update the base IRQ member correctly
From: Linus Walleij @ 2014-02-03  9:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1390397471-6802-2-git-send-email-linus.walleij@linaro.org>

On Wed, Jan 22, 2014 at 2:31 PM, Linus Walleij <linus.walleij@linaro.org> wrote:

> When passing 0 as the irq base the VIC driver will dynamically
> allocate a number of consecutive interrupt descriptors at some
> available number range. Make sure this number is recorded in
> the state container rather than the passed-in zero argument
> in this case.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> tglx: if you're happy with this pls ACK it so I can take this
> through the ARM SoC tree.

Ping on this.
Wanna queue up some stuff in ARM SoC.

Yours,
Linus Walleij

^ permalink raw reply

* Why are imprecise external aborts masked on recent kernel while booting ?
From: Fabrice Gasnier @ 2014-02-03  9:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140131170827.GH15937@n2100.arm.linux.org.uk>

Hi Russell,

Thank you for your help.
I just tried following patch on both 3.10 and above vanilla 3.13.1.
Unfortunately, these instructions have no effect on the arm cpsr.
I dumped regs right after msr instruction have been executed. It remains 
untouched :

Here is assembly from gdb:

    0xc064a400 <+128>:    mov    r3, #256    ; 0x100
    0xc064a404 <+132>:    mrs    r2, CPSR
    0xc064a408 <+136>:    bic    r2, r2, r3
    0xc064a40c <+140>:    msr    CPSR_c, r2

CPSR.A bit is still set after these instructions : 0x600001d3
Although, I see it has been cleared in r2: 0x600000d3

Please advise.
Thanks,
BR,
Fabrice
On 01/31/2014 06:08 PM, Russell King - ARM Linux wrote:
>> Is it possible to unmask imprecise data aborts earlier in the boot
>> >process (e.g. before PCIe bus enumeration, when drivers are being probed)
>> >?
> How about this patch?
>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 172ee18ff124..b0ff06f49cd0 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -900,6 +900,15 @@ void __init early_trap_init(void *vectors_base)
>   
>   	flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
>   	modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> +
> +	/* Enable imprecise aborts */
> +	asm volatile(
> +		"mrs	%0, cpsr\n"
> +	"	bic	%0, %0, %1\n"
> +	"	msr	cpsr_c, %0"
> +		: "=&r" (i)
> +		: "r" (PSR_A_BIT));
> +
>   #else /* ifndef CONFIG_CPU_V7M */
>   	/*
>   	 * on V7-M there is no need to copy the vector table to a dedicated

^ permalink raw reply

* [PATCH v4] ARM/serial: at91: switch atmel serial to use gpiolib
From: Uwe Kleine-König @ 2014-02-03  9:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdbHNo1bLxKaCCuOBiRq+JEpEPXdmQpr4BKAiORcb2snfw@mail.gmail.com>

On Mon, Feb 03, 2014 at 09:34:31AM +0100, Linus Walleij wrote:
> On Sat, Feb 1, 2014 at 12:16 AM, Olof Johansson <olof@lixom.net> wrote:
> > On Fri, Jan 31, 2014 at 04:04:36PM +0100, Richard Genoud wrote:
> 
> >> I can't find this patch in linux-next, did I missed something ?
> >
> > Yeah, looks like we dropped the ball on it. We'll queue it up for 3.15 as soon
> > as -rc1 is out.
> 
> OK it's out now ;-)
I included it in my drop-<mach/timex.h> series that I wish to go into
3.15, too. The patch is the first in my series, commit 354e57f3a0a2. If
you want to take this patch but not my series, please still take this
one to prevent it going in twice.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH v4] ARM/serial: at91: switch atmel serial to use gpiolib
From: Linus Walleij @ 2014-02-03  8:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140131231618.GC11138@quad.lixom.net>

On Sat, Feb 1, 2014 at 12:16 AM, Olof Johansson <olof@lixom.net> wrote:
> On Fri, Jan 31, 2014 at 04:04:36PM +0100, Richard Genoud wrote:

>> I can't find this patch in linux-next, did I missed something ?
>
> Yeah, looks like we dropped the ball on it. We'll queue it up for 3.15 as soon
> as -rc1 is out.

OK it's out now ;-)

Yours,
Linus Walleij

^ permalink raw reply

* [PATCH 1/4] ARM: STi: add stid127 soc support
From: Alexandre Torgue @ 2014-02-03  8:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201401312115.33731.arnd@arndb.de>

On 01/31/2014 09:15 PM, Arnd Bergmann wrote:
> On Friday 31 January 2014, srinivas kandagatla wrote:
>
>>> Sorry if I missed the initial review, but can you explain
>>> why this is needed to start with?
>> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we  set
>> the way-size explicit here.
> Unfortunately, we keep going back and forth on the L2 cache controller
> setup between "it should work automatically" and "we don't want to
> have configuration data in DT", where my personal opinion is that
> the first one is more important here.
>
> Now, there are a couple of properties that are defined in
> Documentation/devicetree/bindings/arm/l2cc.txt to let some of the
> things get set up automatically already. Can you check which bits
> are missing there, if any? Are they better described as "configuration"
> or "hardware" settings?
Hi Arnd,

Thanks for remarks. I will a have a look on it, but unfortunately not 
before 2 weeks.


Alex.

>
> 	Arnd

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox