Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed

* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-21 13:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJZ5v0h3ax4+UCm57VYqV3SVzOZ3A5Ajykks10J49rj1O4VkvQ@mail.gmail.com>

On Sat, Nov 19, 2016 at 12:02:24AM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 17, 2016 at 6:59 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > Add a writeup about how PCI host bridges should be described in ACPI
> > using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table.
> >
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> 
> Looks great overall, but I have a few comments (below).

Thanks a lot for taking a look, Rafael!  I applied all your suggestions.

Bjorn

^ permalink raw reply

* [PATCH 8/9] mtd: nand: mxc: implement onfi get/set features
From: Boris Brezillon @ 2016-11-21 13:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1473928373-8680-9-git-send-email-s.hauer@pengutronix.de>

Hi Sascha,

On Thu, 15 Sep 2016 10:32:52 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> To be able to support different ONFI timing modes we have to implement
> the onfi_set_features and onfi_get_features. Tested on an i.MX25 SoC.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  drivers/mtd/nand/mxc_nand.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index 5173fad..1db8299 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -1239,6 +1239,57 @@ static void mxc_nand_command(struct mtd_info *mtd, unsigned command,
>  	}
>  }
>  
> +static int mxc_nand_onfi_set_features(struct mtd_info *mtd, struct nand_chip *chip,
> +			int addr, uint8_t *subfeature_param)
> +{
> +	struct nand_chip *nand_chip = mtd_to_nand(mtd);
> +	struct mxc_nand_host *host = nand_get_controller_data(nand_chip);
> +	int i;
> +
> +	if (!chip->onfi_version ||
> +	    !(le16_to_cpu(chip->onfi_params.opt_cmd)
> +	      & ONFI_OPT_CMD_SET_GET_FEATURES))
> +		return -EINVAL;
> +
> +	host->buf_start = 0;
> +
> +	for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i)
> +		chip->write_byte(mtd, subfeature_param[i]);
> +
> +	memcpy32_toio(host->main_area0, host->data_buf, mtd->writesize);
> +	host->devtype_data->send_cmd(host, NAND_CMD_SET_FEATURES, false);
> +	mxc_do_addr_cycle(mtd, addr, -1);
> +	host->devtype_data->send_page(mtd, NFC_INPUT);

I've been working with an mx27 board embedding a NAND device lately,
and had a closer look at the NAND controller IP.
With this IP, you're not able to send only 4 bytes of data, and I'm
sure sure what you're doing here (sending a full page of data) works
for a SET_FEATURE command.

Do you have a way to test it (my NAND is not ONFI compliant)? By test
it, I mean, set a timing mode using SET_FEATURE and check if the new
mode has been applied using GET_FEATURE.

> +
> +	return 0;
> +}
> +
> +static int mxc_nand_onfi_get_features(struct mtd_info *mtd, struct nand_chip *chip,
> +			int addr, uint8_t *subfeature_param)
> +{
> +	struct nand_chip *nand_chip = mtd_to_nand(mtd);
> +	struct mxc_nand_host *host = nand_get_controller_data(nand_chip);
> +	int i;
> +
> +	if (!chip->onfi_version ||
> +	    !(le16_to_cpu(chip->onfi_params.opt_cmd)
> +	      & ONFI_OPT_CMD_SET_GET_FEATURES))
> +		return -EINVAL;
> +
> +	*(uint32_t *)host->main_area0 = 0xdeadbeef;
> +
> +	host->devtype_data->send_cmd(host, NAND_CMD_GET_FEATURES, false);
> +	mxc_do_addr_cycle(mtd, addr, -1);
> +	host->devtype_data->send_page(mtd, NFC_OUTPUT);
> +	memcpy32_fromio(host->data_buf, host->main_area0, 512);
> +	host->buf_start = 0;
> +
> +	for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i)
> +		*subfeature_param++ = chip->read_byte(mtd);
> +
> +	return 0;
> +}
> +
>  /*
>   * The generic flash bbt decriptors overlap with our ecc
>   * hardware, so define some i.MX specific ones.
> @@ -1513,6 +1564,8 @@ static int mxcnd_probe(struct platform_device *pdev)
>  	this->read_word = mxc_nand_read_word;
>  	this->write_buf = mxc_nand_write_buf;
>  	this->read_buf = mxc_nand_read_buf;
> +	this->onfi_set_features = mxc_nand_onfi_set_features;
> +	this->onfi_get_features = mxc_nand_onfi_get_features;
>  
>  	host->clk = devm_clk_get(&pdev->dev, NULL);
>  	if (IS_ERR(host->clk))

^ permalink raw reply

* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 13:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121132419.GF1041@n2100.armlinux.org.uk>

On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any ->enable() was called at startup time. I need to revisit
> > this as I remember Daniel was commenting that this was not needed.
> 
> Removing that test results in:
> 
> [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
> 
> and the kernel hanging, seemingly in an IRQs-off region.

Right, I need to sort this one out. Are you doing these tests out of
some tagged branch that I can get in sync with?

Best regards,
Liviu

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

^ permalink raw reply

* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-21 13:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87c8a24b-0812-7850-cb3f-7be691bab432@st.com>

Hello Peppe,

On 21-11-2016 12:52, Giuseppe CAVALLARO wrote:
> Hello Joao
> 
> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>> Hello,
>>
>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a single
>>>>> file
>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
>>>>> related stuff.
>>>>>
>>>>> Our strategy would be:
>>>>>
>>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
>>>>> related stuff to be reused by the platform / pci drivers
>>>>> d) Add a set of features to the "core driver" that we have available
>>>>> internally
>>>>
>>>> Note that there are actually two drivers in mainline for this hardware:
>>>>
>>>>  drivers/net/ethernet/synopsis/
>>>>  drivers/net/ethernet/stmicro/stmmac/
>>>
>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>> please refer this driver once before you start.
>>>
>>> You can start adding missing feature of 4.x in stmmac driver.
>>
>> Thanks you all for all the info.
>> Well, I think we are in a good position to organize the ethernet drivers
>> concerning Synopsys IPs.
>>
>> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>> vendor using the same IP it should be able to reuse the commonn operations. But
>> I would put that discussion for later :)
>>
>> For now I suggest that for we create ethernet/qos and create there a folder
>> called dwc (designware controller) where all the synopsys qos IP specific code
>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
>> figure out a clean interface for "client drivers" like stmmac to interact with
>> the new qos driver.
>>
>> What do you think about this approach?
> 
> The stmmac drivers run since many years on several platforms
> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
> configurations starting from 3.1x to 3.7x databooks.

Great!

> 
> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
> are fully working.

Synopsys QoS IP is a separated hardware component, so it should be reusable by
all implementations using it and so have its own "core driver" and platform +
pci glue drivers. This is necessary for example in hardware validation, where
you prototype an IP and instantiate its drivers and test it.

Was there a strong reason to integrate QoS features directly in stmmac and not
in synopsys/dwc_eth_qos.*?

> 
> Also the stmmac has platform, device-tree and pcie supports and
> a lot of maintained glue-logic files.
> 
> It is fully documented inside the kernel tree.

Thanks for the information, I am going to check it out.

> 
> I am happy to have new enhancements from other developers.
> So, on my side, if you want to spend your time on improving it on your
> platforms please feel free to do it!
> 
> Concerning the stmicro/stmmac naming, these come from a really old
> story and have no issue to adopt new folder/file names.

Thank you for your availability!

> 
> I am also open to merge fixes and changes from ethernet/synopsis.
> I want to point you on some benchmarks made by Alex some months ago
> (IIRC) that showed an stmmac winner (due to the several optimizations
> analyzed and reviewed in this mailing list).
> 
> Peppe
> 

Thanks
Joao

^ permalink raw reply

* [PATCH v3 1/2] mfd: pm8xxx: add support to pm8821
From: Lee Jones @ 2016-11-21 13:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1479211312-1431-1-git-send-email-srinivas.kandagatla@linaro.org>

On Tue, 15 Nov 2016, Srinivas Kandagatla wrote:

> This patch adds support to PM8821 PMIC and interrupt support.
> PM8821 is companion device that supplements primary PMIC PM8921 IC.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes since v2:
> 	- removed few empty lines spotted by Bjorn
> 	- rephrased some debug prints suggested by Bjorn
> 	
>  .../devicetree/bindings/mfd/qcom-pm8xxx.txt        |   1 +
>  drivers/mfd/qcom-pm8xxx.c                          | 231 ++++++++++++++++++++-
>  2 files changed, 222 insertions(+), 10 deletions(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index 37a088f..9e5eba4 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -10,6 +10,7 @@ voltages and other various functionality to Qualcomm SoCs.
>  	Value type: <string>
>  	Definition: must be one of:
>  		    "qcom,pm8058"
> +		    "qcom,pm8821"
>  		    "qcom,pm8921"
>  
>  - #address-cells:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..f08758f 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> @@ -39,6 +39,20 @@
>  #define	SSBI_REG_ADDR_IRQ_CONFIG	(SSBI_REG_ADDR_IRQ_BASE + 7)
>  #define	SSBI_REG_ADDR_IRQ_RT_STATUS	(SSBI_REG_ADDR_IRQ_BASE + 8)
>  
> +#define	PM8821_SSBI_REG_ADDR_IRQ_BASE	0x100
> +#define	PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
> +#define	PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
> +#define	PM8821_SSBI_REG(m, b, offset) \
> +			((m == 0) ? \
> +			(PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
> +			(PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
> +#define	PM8821_SSBI_ADDR_IRQ_ROOT(m, b)		PM8821_SSBI_REG(m, b, 0x0)
> +#define	PM8821_SSBI_ADDR_IRQ_CLEAR(m, b)	PM8821_SSBI_REG(m, b, 0x01)
> +#define	PM8821_SSBI_ADDR_IRQ_MASK(m, b)		PM8821_SSBI_REG(m, b, 0x08)
> +#define	PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b)	PM8821_SSBI_REG(m, b, 0x0f)
> +
> +#define	PM8821_BLOCKS_PER_MASTER	7
> +
>  #define	PM_IRQF_LVL_SEL			0x01	/* level select */
>  #define	PM_IRQF_MASK_FE			0x02	/* mask falling edge */
>  #define	PM_IRQF_MASK_RE			0x04	/* mask rising edge */
> @@ -54,6 +68,7 @@
>  #define REG_HWREV_2		0x0E8  /* PMIC4 revision 2 */
>  
>  #define PM8XXX_NR_IRQS		256
> +#define PM8821_NR_IRQS		112
>  
>  struct pm_irq_chip {
>  	struct regmap		*regmap;
> @@ -65,6 +80,12 @@ struct pm_irq_chip {
>  	u8			config[0];
>  };
>  
> +struct pm_irq_data {
> +	int num_irqs;
> +	const struct irq_domain_ops  *irq_domain_ops;
> +	void (*irq_handler)(struct irq_desc *desc);
> +};
> +
>  static int pm8xxx_read_block_irq(struct pm_irq_chip *chip, unsigned int bp,
>  				 unsigned int *ip)
>  {
> @@ -182,6 +203,78 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
>  	chained_irq_exit(irq_chip, desc);
>  }
>  
> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
> +				     int master, int block)
> +{
> +	int pmirq, irq, i, ret;
> +	unsigned int bits;
> +
> +	ret = regmap_read(chip->regmap,
> +			  PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
> +	if (ret) {
> +		pr_err("Reading block %d failed ret=%d", block, ret);
> +		return;
> +	}
> +
> +	/* Convert block offset to global block number */
> +	block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
> +
> +	/* Check IRQ bits */
> +	for (i = 0; i < 8; i++) {
> +		if (bits & BIT(i)) {
> +			pmirq = block * 8 + i;
> +			irq = irq_find_mapping(chip->irqdomain, pmirq);
> +			generic_handle_irq(irq);
> +		}
> +	}
> +}
> +
> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
> +					     int master, u8 master_val)
> +{
> +	int block;
> +
> +	for (block = 1; block < 8; block++)
> +		if (master_val & BIT(block))
> +			pm8821_irq_block_handler(chip, master, block);
> +}
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> +	struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> +	struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> +	unsigned int master;
> +	int ret;
> +
> +	chained_irq_enter(irq_chip, desc);
> +	ret = regmap_read(chip->regmap,
> +			  PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> +	if (ret) {
> +		pr_err("Failed to read master 0 ret=%d\n", ret);
> +		goto done;
> +	}
> +
> +	/* bits 1 through 7 marks the first 7 blocks in master 0 */
> +	if (master & GENMASK(7, 1))
> +		pm8821_irq_master_handler(chip, 0, master);
> +
> +	/* bit 0 marks if master 1 contains any bits */
> +	if (!(master & BIT(0)))
> +		goto done;
> +
> +	ret = regmap_read(chip->regmap,
> +			  PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
> +	if (ret) {
> +		pr_err("Failed to read master 1 ret=%d\n", ret);
> +		goto done;
> +	}
> +
> +	pm8821_irq_master_handler(chip, 1, master);
> +
> +done:
> +	chained_irq_exit(irq_chip, desc);
> +}
> +
>  static void pm8xxx_irq_mask_ack(struct irq_data *d)
>  {
>  	struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> @@ -299,6 +392,104 @@ static const struct irq_domain_ops pm8xxx_irq_domain_ops = {
>  	.map = pm8xxx_irq_domain_map,
>  };
>  
> +static void pm8821_irq_mask_ack(struct irq_data *d)
> +{
> +	struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> +	unsigned int pmirq = irqd_to_hwirq(d);
> +	u8 block, master;
> +	int irq_bit, rc;
> +
> +	block = pmirq / 8;
> +	master = block / PM8821_BLOCKS_PER_MASTER;
> +	irq_bit = pmirq % 8;
> +	block %= PM8821_BLOCKS_PER_MASTER;
> +
> +	rc = regmap_update_bits(chip->regmap,
> +				PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> +				BIT(irq_bit), BIT(irq_bit));
> +	if (rc) {
> +		pr_err("Failed to mask IRQ:%d rc=%d\n", pmirq, rc);
> +		return;
> +	}
> +
> +	rc = regmap_update_bits(chip->regmap,
> +				PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
> +				BIT(irq_bit), BIT(irq_bit));
> +	if (rc)
> +		pr_err("Failed to CLEAR IRQ:%d rc=%d\n", pmirq, rc);
> +}
> +
> +static void pm8821_irq_unmask(struct irq_data *d)
> +{
> +	struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> +	unsigned int pmirq = irqd_to_hwirq(d);
> +	int irq_bit, rc;
> +	u8 block, master;
> +
> +	block = pmirq / 8;
> +	master = block / PM8821_BLOCKS_PER_MASTER;
> +	irq_bit = pmirq % 8;
> +	block %= PM8821_BLOCKS_PER_MASTER;
> +
> +	rc = regmap_update_bits(chip->regmap,
> +				PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> +				BIT(irq_bit), ~BIT(irq_bit));
> +	if (rc)
> +		pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
> +
> +}
> +
> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
> +					enum irqchip_irq_state which,
> +					bool *state)
> +{
> +	struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> +	int rc, pmirq = irqd_to_hwirq(d);
> +	u8 block, irq_bit, master;
> +	unsigned int bits;
> +
> +	block = pmirq / 8;
> +	master = block / PM8821_BLOCKS_PER_MASTER;
> +	irq_bit = pmirq % 8;
> +	block %= PM8821_BLOCKS_PER_MASTER;
> +
> +	rc = regmap_read(chip->regmap,
> +		PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
> +	if (rc) {
> +		pr_err("Reading Status of IRQ %d failed rc=%d\n", pmirq, rc);
> +		return rc;
> +	}
> +
> +	*state = !!(bits & BIT(irq_bit));
> +
> +	return rc;
> +}
> +
> +static struct irq_chip pm8821_irq_chip = {
> +	.name		= "pm8821",
> +	.irq_mask_ack	= pm8821_irq_mask_ack,
> +	.irq_unmask	= pm8821_irq_unmask,
> +	.irq_get_irqchip_state = pm8821_irq_get_irqchip_state,
> +	.flags		= IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE,
> +};
> +
> +static int pm8821_irq_domain_map(struct irq_domain *d, unsigned int irq,
> +				   irq_hw_number_t hwirq)
> +{
> +	struct pm_irq_chip *chip = d->host_data;
> +
> +	irq_set_chip_and_handler(irq, &pm8821_irq_chip, handle_level_irq);
> +	irq_set_chip_data(irq, chip);
> +	irq_set_noprobe(irq);
> +
> +	return 0;
> +}
> +
> +static const struct irq_domain_ops pm8821_irq_domain_ops = {
> +	.xlate = irq_domain_xlate_twocell,
> +	.map = pm8821_irq_domain_map,
> +};
> +
>  static const struct regmap_config ssbi_regmap_config = {
>  	.reg_bits = 16,
>  	.val_bits = 8,
> @@ -308,22 +499,41 @@ static const struct regmap_config ssbi_regmap_config = {
>  	.reg_write = ssbi_reg_write
>  };
>  
> +static const struct pm_irq_data pm8xxx_data = {
> +	.num_irqs = PM8XXX_NR_IRQS,
> +	.irq_domain_ops = &pm8xxx_irq_domain_ops,
> +	.irq_handler = pm8xxx_irq_handler,
> +};
> +
> +static const struct pm_irq_data pm8821_data = {
> +	.num_irqs = PM8821_NR_IRQS,
> +	.irq_domain_ops = &pm8821_irq_domain_ops,
> +	.irq_handler = pm8821_irq_handler,
> +};
> +
>  static const struct of_device_id pm8xxx_id_table[] = {
> -	{ .compatible = "qcom,pm8018", },
> -	{ .compatible = "qcom,pm8058", },
> -	{ .compatible = "qcom,pm8921", },
> +	{ .compatible = "qcom,pm8018", .data = &pm8xxx_data},
> +	{ .compatible = "qcom,pm8058", .data = &pm8xxx_data},
> +	{ .compatible = "qcom,pm8821", .data = &pm8821_data},
> +	{ .compatible = "qcom,pm8921", .data = &pm8xxx_data},
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
>  
>  static int pm8xxx_probe(struct platform_device *pdev)
>  {
> +	const struct pm_irq_data *data;
>  	struct regmap *regmap;
>  	int irq, rc;
>  	unsigned int val;
>  	u32 rev;
>  	struct pm_irq_chip *chip;
> -	unsigned int nirqs = PM8XXX_NR_IRQS;
> +
> +	data = of_device_get_match_data(&pdev->dev);
> +	if (!data) {
> +		dev_err(&pdev->dev, "No matching driver data found\n");
> +		return -EINVAL;
> +	}
>  
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq < 0)
> @@ -354,25 +564,26 @@ static int pm8xxx_probe(struct platform_device *pdev)
>  	rev |= val << BITS_PER_BYTE;
>  
>  	chip = devm_kzalloc(&pdev->dev, sizeof(*chip) +
> -					sizeof(chip->config[0]) * nirqs,
> -					GFP_KERNEL);
> +			    sizeof(chip->config[0]) * data->num_irqs,
> +			    GFP_KERNEL);
>  	if (!chip)
>  		return -ENOMEM;
>  
>  	platform_set_drvdata(pdev, chip);
>  	chip->regmap = regmap;
> -	chip->num_irqs = nirqs;
> +	chip->num_irqs = data->num_irqs;
>  	chip->num_blocks = DIV_ROUND_UP(chip->num_irqs, 8);
>  	chip->num_masters = DIV_ROUND_UP(chip->num_blocks, 8);
>  	spin_lock_init(&chip->pm_irq_lock);
>  
> -	chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node, nirqs,
> -						&pm8xxx_irq_domain_ops,
> +	chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node,
> +						data->num_irqs,
> +						data->irq_domain_ops,
>  						chip);
>  	if (!chip->irqdomain)
>  		return -ENODEV;
>  
> -	irq_set_chained_handler_and_data(irq, pm8xxx_irq_handler, chip);
> +	irq_set_chained_handler_and_data(irq, data->irq_handler, chip);
>  	irq_set_irq_wake(irq, 1);
>  
>  	rc = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);

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

^ permalink raw reply

* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Christoffer Dall @ 2016-11-21 13:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CALicx6snqsSbaKYcj9kt0nt8y2wdTbrY1PKOq-SrGTepCfSZSg@mail.gmail.com>

On Mon, Nov 21, 2016 at 06:56:08PM +0530, Vijay Kilari wrote:
> On Mon, Nov 21, 2016 at 3:49 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Nov 18, 2016 at 10:28:34PM +0530, Vijay Kilari wrote:
> >> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
> >> <christoffer.dall@linaro.org> wrote:
> >> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
> >> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
> >> >> <christoffer.dall@linaro.org> wrote:
> >> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
> >> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >> >>
> >> >> >> VGICv3 CPU interface registers are accessed using
> >> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> >> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
> >> >> >> is used to identify the cpu for registers access.
> >> >> >>
> >> >> >> The version of VGIC v3 specification is define here
> >> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
> >> >> >>
> >> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> >> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >> >> ---
> >> >> >>  arch/arm64/include/uapi/asm/kvm.h   |   3 +
> >> >> >>  arch/arm64/kvm/Makefile             |   1 +
> >> >> >>  include/kvm/arm_vgic.h              |   9 +
> >> >> >>  virt/kvm/arm/vgic/vgic-kvm-device.c |  27 +++
> >> >> >>  virt/kvm/arm/vgic/vgic-mmio-v3.c    |  19 +++
> >> >> >>  virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
> >> >> >>  virt/kvm/arm/vgic/vgic-v3.c         |   8 +
> >> >> >>  virt/kvm/arm/vgic/vgic.h            |   4 +
> >> >> >>  8 files changed, 395 insertions(+)
> >> >> >>
> >> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> >> >> >> index 56dc08d..91c7137 100644
> >> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
> >> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
> >> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
> >> >> >>                       (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
> >> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT      0
> >> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK       (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> >> >> >> +#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
> >> >> >>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> >> >> >>  #define KVM_DEV_ARM_VGIC_GRP_CTRL    4
> >> >> >>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> >> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS    6
> >> >> >> +
> >> >> >>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT 0
> >> >> >>
> >> >> >>  /* Device Control API on vcpu fd */
> >> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> >> >> >> index d50a82a..1a14e29 100644
> >> >> >> --- a/arch/arm64/kvm/Makefile
> >> >> >> +++ b/arch/arm64/kvm/Makefile
> >> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
> >> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
> >> >> >
> >> >> > Thi is making me wonder:  Are we properly handling GICv3 save/restore
> >> >> > for AArch32 now that we have GICv3 support for AArch32?  By properly I
> >> >> > mean that either it is clearly only supported on AArch64 systems or it's
> >> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
> >> >> > on AArch32.
> >> >>
> >> >> It supports both AArch64 and AArch64 in handling of system registers
> >> >> save/restore.
> >> >> All system registers that we save/restore are 32-bit for both aarch64
> >> >> and aarch32.
> >> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
> >> >> are same. However the codes sent by qemu is matched and register
> >> >> are handled properly irrespective of AArch32 or AArch64.
> >> >>
> >> >> I don't have platform which support AArch32 guests to verify.
> >> >
> >> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
> >> > that has a GICv3.
> >> >
> >> > I just tried to do a v7 compile with your patches, and it results in an
> >> > epic failure, so there's something for you to look at.
> >> >
> >> >> >
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
> >> >> >> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> >> >> >> index 002f092..730a18a 100644
> >> >> >> --- a/include/kvm/arm_vgic.h
> >> >> >> +++ b/include/kvm/arm_vgic.h
> >> >> >> @@ -71,6 +71,9 @@ struct vgic_global {
> >> >> >>
> >> >> >>       /* GIC system register CPU interface */
> >> >> >>       struct static_key_false gicv3_cpuif;
> >> >> >> +
> >> >> >> +     /* Cache ICH_VTR_EL2 reg value */
> >> >> >> +     u32                     ich_vtr_el2;
> >> >> >>  };
> >> >> >>
> >> >> >>  extern struct vgic_global kvm_vgic_global_state;
> >> >> >> @@ -269,6 +272,12 @@ struct vgic_cpu {
> >> >> >>       u64 pendbaser;
> >> >> >>
> >> >> >>       bool lpis_enabled;
> >> >> >> +
> >> >> >> +     /* Cache guest priority bits */
> >> >> >> +     u32 num_pri_bits;
> >> >> >> +
> >> >> >> +     /* Cache guest interrupt ID bits */
> >> >> >> +     u32 num_id_bits;
> >> >> >>  };
> >> >> >>
> >> >> >>  extern struct static_key_false vgic_v2_cpuif_trap;
> >> >> >> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
> >> >> >> index 6c7d30c..da532d1 100644
> >> >> >> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> >> >> >> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> >> >> >> @@ -504,6 +504,14 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
> >> >> >>               if (!is_write)
> >> >> >>                       *reg = tmp32;
> >> >> >>               break;
> >> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> >> >> >> +             u64 regid;
> >> >> >> +
> >> >> >> +             regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
> >> >> >> +             ret = vgic_v3_cpu_sysregs_uaccess(vcpu, is_write,
> >> >> >> +                                               regid, reg);
> >> >> >> +             break;
> >> >> >> +     }
> >> >> >>       default:
> >> >> >>               ret = -EINVAL;
> >> >> >>               break;
> >> >> >> @@ -537,6 +545,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
> >> >> >>               reg = tmp32;
> >> >> >>               return vgic_v3_attr_regs_access(dev, attr, &reg, true);
> >> >> >>       }
> >> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> >> >> >> +             u64 __user *uaddr = (u64 __user *)(long)attr->addr;
> >> >> >> +             u64 reg;
> >> >> >> +
> >> >> >> +             if (get_user(reg, uaddr))
> >> >> >> +                     return -EFAULT;
> >> >> >> +
> >> >> >> +             return vgic_v3_attr_regs_access(dev, attr, &reg, true);
> >> >> >> +     }
> >> >> >>       }
> >> >> >>       return -ENXIO;
> >> >> >>  }
> >> >> >> @@ -563,6 +580,15 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
> >> >> >>               tmp32 = reg;
> >> >> >>               return put_user(tmp32, uaddr);
> >> >> >>       }
> >> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> >> >> >> +             u64 __user *uaddr = (u64 __user *)(long)attr->addr;
> >> >> >> +             u64 reg;
> >> >> >> +
> >> >> >> +             ret = vgic_v3_attr_regs_access(dev, attr, &reg, false);
> >> >> >> +             if (ret)
> >> >> >> +                     return ret;
> >> >> >> +             return put_user(reg, uaddr);
> >> >> >> +     }
> >> >> >>       }
> >> >> >>
> >> >> >>       return -ENXIO;
> >> >> >> @@ -581,6 +607,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
> >> >> >>               break;
> >> >> >>       case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> >> >> >>       case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
> >> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
> >> >> >>               return vgic_v3_has_attr_regs(dev, attr);
> >> >> >>       case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
> >> >> >>               return 0;
> >> >> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> >> >> index b35fb83..519b919 100644
> >> >> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> >> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> >> >> @@ -23,6 +23,7 @@
> >> >> >>
> >> >> >>  #include "vgic.h"
> >> >> >>  #include "vgic-mmio.h"
> >> >> >> +#include "sys_regs.h"
> >> >> >>
> >> >> >>  /* extract @num bytes at @offset bytes offset in data */
> >> >> >>  unsigned long extract_bytes(u64 data, unsigned int offset,
> >> >> >> @@ -639,6 +640,24 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> >> >> >>               nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
> >> >> >>               break;
> >> >> >>       }
> >> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> >> >> >> +             u64 reg, id;
> >> >> >> +             unsigned long vgic_mpidr, mpidr_reg;
> >> >> >> +             struct kvm_vcpu *vcpu;
> >> >> >> +
> >> >> >> +             vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
> >> >> >> +                           KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
> >> >> >> +
> >> >> >> +             /* Convert plain mpidr value to MPIDR reg format */
> >> >> >> +             mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
> >> >> >> +
> >> >> >> +             vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr_reg);
> >> >> >> +             if (!vcpu)
> >> >> >> +                     return -EINVAL;
> >> >> >> +
> >> >> >> +             id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
> >> >> >> +             return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, &reg);
> >> >> >> +     }
> >> >> >>       default:
> >> >> >>               return -ENXIO;
> >> >> >>       }
> >> >> >> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >> >> >> new file mode 100644
> >> >> >> index 0000000..69d8597
> >> >> >> --- /dev/null
> >> >> >> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
> >> >> >
> >> >> > Shouldn't we have a GPL header here?
> >> >> >
> >> >> >> @@ -0,0 +1,324 @@
> >> >> >> +#include <linux/irqchip/arm-gic-v3.h>
> >> >> >> +#include <linux/kvm.h>
> >> >> >> +#include <linux/kvm_host.h>
> >> >> >> +#include <kvm/iodev.h>
> >> >> >> +#include <kvm/arm_vgic.h>
> >> >> >> +#include <asm/kvm_emulate.h>
> >> >> >> +#include <asm/kvm_arm.h>
> >> >> >> +#include <asm/kvm_mmu.h>
> >> >> >> +
> >> >> >> +#include "vgic.h"
> >> >> >> +#include "vgic-mmio.h"
> >> >> >> +#include "sys_regs.h"
> >> >> >> +
> >> >> >> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >> >> >> +                         const struct sys_reg_desc *r)
> >> >> >> +{
> >> >> >> +     struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
> >> >> >> +     struct vgic_vmcr vmcr;
> >> >> >> +     u64 val;
> >> >> >> +     u32 num_pri_bits, num_id_bits;
> >> >> >> +
> >> >> >> +     vgic_get_vmcr(vcpu, &vmcr);
> >> >> >> +     if (p->is_write) {
> >> >> >> +             val = p->regval;
> >> >> >> +
> >> >> >> +             /*
> >> >> >> +              * Does not allow update of ICC_CTLR_EL1 if HW does not support
> >> >> >> +              * guest programmed ID and PRI bits
> >> >> >> +              */
> >> >> >
> >> >> > I would suggest rewording this comment:
> >> >> > Disallow restoring VM state not supported by this hardware.
> >> >> >
> >> >> >> +             num_pri_bits = ((val & ICC_CTLR_EL1_PRI_BITS_MASK) >>
> >> >> >> +                             ICC_CTLR_EL1_PRI_BITS_SHIFT) + 1;
> >> >> >> +             if (num_pri_bits > vgic_v3_cpu->num_pri_bits)
> >> >> >> +                     return false;
> >> >> >> +
> >> >> >> +             vgic_v3_cpu->num_pri_bits = num_pri_bits;
> >> >> >
> >> >> > hmmm, this looks weird to me, because vgic_v3_cpu->num_pri_bits I don't
> >> >> > understand which effect this is intended to have?
> >> >> >
> >> >> > Sure, it may limit what you do with other registers later, but since
> >> >> > there's no ordering requirement that the ctlr be restored first, I'm not
> >> >> > sure it makes sense.
> >> >> >
> >> >> > Also, since this field is RO in the ICH_VTR, we'll have a strange
> >> >> > situation during runtime after a GICv3 restore where the
> >> >> > vgic_v3_cpu->num_pri_its differs from the hardware's ICH_VTR_EL2 field,
> >> >> > which is never the case if you didn't do a save/restore.
> >> >>
> >> >> Yes, but in any case, vgic_v3_cpu->num_pri_bits will be always less
> >> >> than HW supported
> >> >> value.
> >> >>
> >> >
> >> > So answer my question:  What is the intended effect of writing this
> >> > value?  Is it just so that if you migrate this platform back again, then
> >> > you're checking compatibility with what the guest would potentially do,
> >>
> >> Yes
> >
> > Then add a comment explaining that
> >
> >> and also to limit the valid aprn registers access as you said above.
> >> But that has ordering restriction. Which I think we should follow.
> >>
> >
> > I'm sorry, now I'm confused.  Is there an ordering requirement in the
> > API, or how should we follow this?
> 
> There is  no ordering requirement mentioned in the API doc.
> However the APRn registers depends on num_pri_bits. Hence first
> ICC_CTLR_EL1 should be restored  before APRn restore.
> 
> If ordering is not followed then APRn registers restore is allowed
> as per hw supported num_pri_bits.
> 
> This should be mentioned in doc.

How about just having a consistency check function that you call from
uaccess updates to both functions, and in that way avoid requireing any
ordering which is likely to not be followed etc.?

Thanks,
-Christoffer

^ permalink raw reply

* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Christoffer Dall @ 2016-11-21 13:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CALicx6sxchAbDJ2rioTytwFG1C0tD-Fnr4HC-DweSdkkCF7BFw@mail.gmail.com>

On Mon, Nov 21, 2016 at 07:02:36PM +0530, Vijay Kilari wrote:
> On Sun, Nov 20, 2016 at 6:50 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Sat, Nov 19, 2016 at 12:18:53AM +0530, Vijay Kilari wrote:
> >> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
> >> <christoffer.dall@linaro.org> wrote:
> >> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
> >> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
> >> >> <christoffer.dall@linaro.org> wrote:
> >> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
> >> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >> >>
> >> >> >> VGICv3 CPU interface registers are accessed using
> >> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> >> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
> >> >> >> is used to identify the cpu for registers access.
> >> >> >>
> >> >> >> The version of VGIC v3 specification is define here
> >> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
> >> >> >>
> >> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
> >> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> >> >> ---
> >> >> >>  arch/arm64/include/uapi/asm/kvm.h   |   3 +
> >> >> >>  arch/arm64/kvm/Makefile             |   1 +
> >> >> >>  include/kvm/arm_vgic.h              |   9 +
> >> >> >>  virt/kvm/arm/vgic/vgic-kvm-device.c |  27 +++
> >> >> >>  virt/kvm/arm/vgic/vgic-mmio-v3.c    |  19 +++
> >> >> >>  virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
> >> >> >>  virt/kvm/arm/vgic/vgic-v3.c         |   8 +
> >> >> >>  virt/kvm/arm/vgic/vgic.h            |   4 +
> >> >> >>  8 files changed, 395 insertions(+)
> >> >> >>
> >> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> >> >> >> index 56dc08d..91c7137 100644
> >> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
> >> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
> >> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
> >> >> >>                       (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
> >> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT      0
> >> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK       (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> >> >> >> +#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
> >> >> >>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> >> >> >>  #define KVM_DEV_ARM_VGIC_GRP_CTRL    4
> >> >> >>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> >> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS    6
> >> >> >> +
> >> >> >>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT 0
> >> >> >>
> >> >> >>  /* Device Control API on vcpu fd */
> >> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
> >> >> >> index d50a82a..1a14e29 100644
> >> >> >> --- a/arch/arm64/kvm/Makefile
> >> >> >> +++ b/arch/arm64/kvm/Makefile
> >> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
> >> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
> >> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
> >> >> >
> >> >> > Thi is making me wonder:  Are we properly handling GICv3 save/restore
> >> >> > for AArch32 now that we have GICv3 support for AArch32?  By properly I
> >> >> > mean that either it is clearly only supported on AArch64 systems or it's
> >> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
> >> >> > on AArch32.
> >> >>
> >> >> It supports both AArch64 and AArch64 in handling of system registers
> >> >> save/restore.
> >> >> All system registers that we save/restore are 32-bit for both aarch64
> >> >> and aarch32.
> >> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
> >> >> are same. However the codes sent by qemu is matched and register
> >> >> are handled properly irrespective of AArch32 or AArch64.
> >> >>
> >> >> I don't have platform which support AArch32 guests to verify.
> >> >
> >> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
> >> > that has a GICv3.
> >> >
> >> > I just tried to do a v7 compile with your patches, and it results in an
> >> > epic failure, so there's something for you to look at.
> >> >
> >>
> >> Could you please share you config file?. I tried with multi_v7 defconfig with
> >> CONFIG KVM and CONFIG_KVM_ARM_HOST enabled. it compiled for me.
> >
> > I think this has to do with which branch you apply your patches to.
> > When applied to kvmarm/next, it fails.
> >
> > Here's the integration I did:
> > https://git.linaro.org/people/christoffer.dall/linux-kvm-arm.git tmp-gicv3-migrate-v8
> >
> > Here's the config:
> > https://transfer.sh/xkAxp/.config
> >
> 
> Thanks for shareing the details, I could reproduce them.
> However virt/kvm/arm/vgic/vgic-sys-reg-v3.c is written with
> sys_regs_desc for AArch64.
> For AArch32/v7, it has be to coproc_reg. I propose to add separate file for arm
> which handles ICC* reg save/restore using coproc_reg.

That might make sense.  In that case they want to be moved into
arch/arm/kvm/ and arch/arm64/kvm/

-Christoffer

^ permalink raw reply

* [PATCH] mfd: twl-core: export twl_get_regmap
From: Russell King - ARM Linux @ 2016-11-21 13:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKP5S=28xVyNE=Q7hd2UbtOmT=12ayrcWM5m1OTvk5kGN5pZrw@mail.gmail.com>

On Mon, Nov 21, 2016 at 12:03:03PM +0200, Nicolae Rosia wrote:
> On Mon, Nov 21, 2016 at 11:31 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > Passing data between drivers using *_set_drvdata() is a layering
> > violation:
> >
> > 1. Driver data is supposed to be driver private data associated with
> >    the currently bound driver.
> > 2. The driver data pointer is NULL'd when the driver unbinds from the
> >    device.  See __device_release_driver() and the
> >    dev_set_drvdata(dev, NULL).
> > 3. It will break with CONFIG_DEBUG_TEST_DRIVER_REMOVE enabled for a
> >    similar reason to (2).
> >
> > So, do not pass data between drivers using *_set_drvdata() - any
> > examples in the kernel already are founded on bad practice, are
> > fragile, and are already broken for some kernel configurations.
> 
> After inspecting mfd_add_device, it seems that it creates a
> platform_device which has the parent set to the driver calling the
> function.
> Isn't module unloading forbidden if there is a parent->child
> relationship in place and you're removing the parent?

Forget this idea that there's any connection between modules and
the struct device relationships - there isn't anything of the kind!

Each struct device is refcounted, and child devices will hold a
reference to their parent device, so the parent device doesn't get
freed before its children are all gone.

That's a completely separate issue to when a struct device is bound
to a struct device_driver - it's entirely possible for parent drivers
to be unbound at any time, even when there are child drivers in place.

There are cases where we want that to happen - think of any driver
which is a bus driver in itself - eg, PCMCIA, MMC, USB, etc.  These
drivers enumerate their children, and destroy their children when
the driver is unbound - but the driver has to be in the process of
being unbound for that to happen.  That process may very well start
with the child devices being bound to their drivers.

What makes the child drivers unbind is when the bus driver deletes
the child struct devices.

> What should be the best practice to share data between drivers?
> Reference counted data?

I guess so, but you will still have a race if you do something like:

	struct parent_private_data *parent_priv = dev_get_drvdata(dev->parent);

Yes, that'll get the parent's driver private data, but what you don't
know is whether the pointer remains valid, and even if you do as the
very next step:

	kref_get(&parent_priv->kref);

you don't know whether parent_priv was kfree()d between these two
statements.

However, if the parent driver creates the struct device that you're
using and deletes the struct device before it frees its private data,
then you can be sure that parent_priv will be valid, because the child
drivers will be unbound during the parent driver's ->remove function,
_before_ the private data is freed.

> In the case of TWL, the twl-core is just a simple container for
> regmaps - all other "sub devices" are using those regmaps to access
> the I2C device's registers, it makes no sense to remove the parent
> driver since it does *nothing*.

I can't comment on what twl-core is doing, I haven't looked at it in
ages, but most MFD drivers have the parent device creating and destroying
their children, so it should be fine.

My original comment was more along the lines of a parent device poking
driver-private data into the child devices it was creating for the
child drivers to pick up.  However, it's worth discussing the validity
cases of the parent's driver data too, as per the above.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* [PATCH v5 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121133247.29889-1-romain.perier@free-electrons.com>

This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---

Changes in v5:
 - Added the tag 'Acked-by', by Rob Herring

Changes in v2:
 - Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
   and not "marvell,armada-3700".

 Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
    compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
    For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
    as shown in the example below.
+   For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
 
 Recommended properties :
 
-- 
2.9.3

^ permalink raw reply related

* [PATCH v5 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121133247.29889-1-romain.perier@free-electrons.com>

The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  4 ++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 18 ++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
 	};
 };
 
+&i2c0 {
+	status = "okay";
+};
+
 /* CON3 */
 &sata {
 	status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd587..1b0fd21 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
 			/* 32M internal register @ 0xd000_0000 */
 			ranges = <0x0 0x0 0xd0000000 0x2000000>;
 
+			i2c0: i2c at 11000 {
+				compatible = "marvell,armada-3700-i2c";
+				reg = <0x11000 0x24>;
+				clocks = <&nb_periph_clk 10>;
+				interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+				mrvl,i2c-fast-mode;
+				status = "disabled";
+			};
+
+			i2c1: i2c at 11080 {
+				compatible = "marvell,armada-3700-i2c";
+				reg = <0x11080 0x24>;
+				clocks = <&nb_periph_clk 9>;
+				interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+				mrvl,i2c-fast-mode;
+				status = "disabled";
+			};
+
 			uart0: serial at 12000 {
 				compatible = "marvell,armada-3700-uart";
 				reg = <0x12000 0x400>;
-- 
2.9.3

^ permalink raw reply related

* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121133247.29889-1-romain.perier@free-electrons.com>

The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).

This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---

Changes in v5:
 - Don't define registers for armada-3700, we can re-use the ones
   for PXA3XX.
 - Define registers mask when OF is not used, in probe_pdata. 

Changes in v4:
 - Replaced the type of hs_mask and fm_mask by u32, instead of
   unsigned int, As writel() take an u32 as first argument...

Changes in v3:
 - Replaced the type of hs_mask and fm_mask by unsigned int,
   instead of unsigned long.

 drivers/i2c/busses/Kconfig   |  2 +-
 drivers/i2c/busses/i2c-pxa.c | 24 ++++++++++++++++++++++--
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
 
 config I2C_PXA
 	tristate "Intel PXA2XX I2C adapter"
-	depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+	depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
 	help
 	  If you have devices in the PXA I2C bus, say yes to this option.
 	  This driver can also be built as a module.  If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..374d17c 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -98,6 +98,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
 	{ "pxa3xx-pwri2c",	REGS_PXA3XX },
 	{ "ce4100-i2c",		REGS_CE4100 },
 	{ "pxa910-i2c",		REGS_PXA910 },
+	{ "armada-3700-i2c",	REGS_PXA3XX  },
 	{ },
 };
 MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +123,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
 #define ICR_SADIE	(1 << 13)	   /* slave address detected int enable */
 #define ICR_UR		(1 << 14)	   /* unit reset */
 #define ICR_FM		(1 << 15)	   /* fast mode */
+#define ICR_BUSMODE_FM	(1 << 16)	   /* shifted fast mode for armada-3700 */
 #define ICR_HS		(1 << 16)	   /* High Speed mode */
+#define ICR_BUSMODE_HS	(1 << 17)	   /* shifted high speed mode for armada-3700 */
 #define ICR_GPIOEN	(1 << 19)	   /* enable GPIO mode for SCL in HS */
 
 #define ISR_RWM		(1 << 0)	   /* read/write mode */
@@ -193,6 +196,8 @@ struct pxa_i2c {
 	unsigned char		master_code;
 	unsigned long		rate;
 	bool			highmode_enter;
+	u32			fm_mask;
+	u32			hs_mask;
 };
 
 #define _IBMR(i2c)	((i2c)->reg_ibmr)
@@ -503,8 +508,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
 		writel(i2c->slave_addr, _ISAR(i2c));
 
 	/* set control register values */
-	writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
-	writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+	writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+	writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
 
 #ifdef CONFIG_I2C_PXA_SLAVE
 	dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1142,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
 	{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
 	{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
 	{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+	{ .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_PXA3XX },
 	{}
 };
 MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1164,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
 		i2c->use_pio = 1;
 	if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
 		i2c->fast_mode = 1;
+	if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+		i2c->fm_mask = ICR_BUSMODE_FM;
+		i2c->hs_mask = ICR_BUSMODE_HS;
+	} else {
+		i2c->fm_mask = ICR_FM;
+		i2c->hs_mask = ICR_HS;
+	}
 
 	*i2c_types = (enum pxa_i2c_types)(of_id->data);
 
@@ -1181,6 +1194,13 @@ static int i2c_pxa_probe_pdata(struct platform_device *pdev,
 			i2c->master_code = 0xe;
 		i2c->rate = plat->rate;
 	}
+	if (!strcmp(id->name, "armada-3700-i2c")) {
+		i2c->fm_mask = ICR_BUSMODE_FM;
+		i2c->hs_mask = ICR_BUSMODE_HS;
+	} else {
+		i2c->fm_mask = ICR_FM;
+		i2c->hs_mask = ICR_HS;
+	}
 	return 0;
 }
 
-- 
2.9.3

^ permalink raw reply related

* [PATCH v5 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
  To: linux-arm-kernel

This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.

Romain Perier (3):
  i2c: pxa: Add support for the I2C units found in Armada 3700
  arm64: dts: marvell: Add I2C definitions for the Armada 3700
  dt-bindings: i2c: pxa: Update the documentation for the Armada 3700

 Documentation/devicetree/bindings/i2c/i2c-pxa.txt |  1 +
 arch/arm64/boot/dts/marvell/armada-3720-db.dts    |  4 ++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi      | 18 +++++++++++++++++
 drivers/i2c/busses/Kconfig                        |  2 +-
 drivers/i2c/busses/i2c-pxa.c                      | 24 +++++++++++++++++++++--
 5 files changed, 46 insertions(+), 3 deletions(-)

-- 
2.9.3

^ permalink raw reply

* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-11-21 13:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161120132005.GC23588@cbox>

On Sun, Nov 20, 2016 at 6:50 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Sat, Nov 19, 2016 at 12:18:53AM +0530, Vijay Kilari wrote:
>> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
>> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
>> >> <christoffer.dall@linaro.org> wrote:
>> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
>> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >>
>> >> >> VGICv3 CPU interface registers are accessed using
>> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >> >> is used to identify the cpu for registers access.
>> >> >>
>> >> >> The version of VGIC v3 specification is define here
>> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >> >>
>> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >> ---
>> >> >>  arch/arm64/include/uapi/asm/kvm.h   |   3 +
>> >> >>  arch/arm64/kvm/Makefile             |   1 +
>> >> >>  include/kvm/arm_vgic.h              |   9 +
>> >> >>  virt/kvm/arm/vgic/vgic-kvm-device.c |  27 +++
>> >> >>  virt/kvm/arm/vgic/vgic-mmio-v3.c    |  19 +++
>> >> >>  virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
>> >> >>  virt/kvm/arm/vgic/vgic-v3.c         |   8 +
>> >> >>  virt/kvm/arm/vgic/vgic.h            |   4 +
>> >> >>  8 files changed, 395 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> index 56dc08d..91c7137 100644
>> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
>> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> >> >>                       (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT      0
>> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK       (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> >> >> +#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> >> >>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> >> >>  #define KVM_DEV_ARM_VGIC_GRP_CTRL    4
>> >> >>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS    6
>> >> >> +
>> >> >>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT 0
>> >> >>
>> >> >>  /* Device Control API on vcpu fd */
>> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> >> >> index d50a82a..1a14e29 100644
>> >> >> --- a/arch/arm64/kvm/Makefile
>> >> >> +++ b/arch/arm64/kvm/Makefile
>> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> >> >
>> >> > Thi is making me wonder:  Are we properly handling GICv3 save/restore
>> >> > for AArch32 now that we have GICv3 support for AArch32?  By properly I
>> >> > mean that either it is clearly only supported on AArch64 systems or it's
>> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
>> >> > on AArch32.
>> >>
>> >> It supports both AArch64 and AArch64 in handling of system registers
>> >> save/restore.
>> >> All system registers that we save/restore are 32-bit for both aarch64
>> >> and aarch32.
>> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
>> >> are same. However the codes sent by qemu is matched and register
>> >> are handled properly irrespective of AArch32 or AArch64.
>> >>
>> >> I don't have platform which support AArch32 guests to verify.
>> >
>> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
>> > that has a GICv3.
>> >
>> > I just tried to do a v7 compile with your patches, and it results in an
>> > epic failure, so there's something for you to look at.
>> >
>>
>> Could you please share you config file?. I tried with multi_v7 defconfig with
>> CONFIG KVM and CONFIG_KVM_ARM_HOST enabled. it compiled for me.
>
> I think this has to do with which branch you apply your patches to.
> When applied to kvmarm/next, it fails.
>
> Here's the integration I did:
> https://git.linaro.org/people/christoffer.dall/linux-kvm-arm.git tmp-gicv3-migrate-v8
>
> Here's the config:
> https://transfer.sh/xkAxp/.config
>

Thanks for shareing the details, I could reproduce them.
However virt/kvm/arm/vgic/vgic-sys-reg-v3.c is written with
sys_regs_desc for AArch64.
For AArch32/v7, it has be to coproc_reg. I propose to add separate file for arm
which handles ICC* reg save/restore using coproc_reg.

> Here's the compile output:
>
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c:26:22: fatal error: sys_regs.h: No such file or directory
>  #include "sys_regs.h"
>                       ^
> compilation terminated.
> make[2]: *** [arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_parse_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:438:29: error: ?KVM_DEV_ARM_VGIC_V3_MPIDR_MASK? undeclared (first use in this function)
>   vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
>                              ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:438:29: note: each undeclared identifier is reported only once for each function it appears in
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:439:9: error: ?KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT? undeclared (first use in this function)
>          KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
>          ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:441:2: error: implicit declaration of function ?MPIDR_LEVEL_SHIFT? [-Werror=implicit-function-declaration]
>   mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
>   ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_attr_regs_access?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:497:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:505:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:508:25: error: ?KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK? undeclared (first use in this function)
>    regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>                          ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:513:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:516:24: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK? undeclared (first use in this function)
>    info = (attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
>                         ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:517:4: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT? undeclared (first use in this function)
>     KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT;
>     ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:518:15: error: ?VGIC_LEVEL_INFO_LINE_LEVEL? undeclared (first use in this function)
>    if (info == VGIC_LEVEL_INFO_LINE_LEVEL) {
>                ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:522:5: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK? undeclared (first use in this function)
>      KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
>      ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_set_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:554:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:565:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:574:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_get_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:600:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:611:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:620:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_has_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:647:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:648:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:652:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
>   case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>        ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:653:22: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK? undeclared (first use in this function)
>    if (((attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
>                       ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:654:9: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT? undeclared (first use in this function)
>          KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT) ==
>          ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:655:9: error: ?VGIC_LEVEL_INFO_LINE_LEVEL? undeclared (first use in this function)
>          VGIC_LEVEL_INFO_LINE_LEVEL)
>          ^
> cc1: some warnings being treated as errors
> make[2]: *** [arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.o] Error 1
> make[1]: *** [arch/arm/kvm] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [sub-make] Error 2
>
> Thanks,
> -Christoffer

^ permalink raw reply

* Synopsys Ethernet QoS Driver
From: Lars Persson @ 2016-11-21 13:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87c8a24b-0812-7850-cb3f-7be691bab432@st.com>



> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
> 
> Hello Joao
> 
>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>> Hello,
>> 
>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a single file
>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
>>>>> related stuff.
>>>>> 
>>>>> Our strategy would be:
>>>>> 
>>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
>>>>> related stuff to be reused by the platform / pci drivers
>>>>> d) Add a set of features to the "core driver" that we have available internally
>>>> 
>>>> Note that there are actually two drivers in mainline for this hardware:
>>>> 
>>>> drivers/net/ethernet/synopsis/
>>>> drivers/net/ethernet/stmicro/stmmac/
>>> 
>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>> please refer this driver once before you start.
>>> 
>>> You can start adding missing feature of 4.x in stmmac driver.
>> 
>> Thanks you all for all the info.
>> Well, I think we are in a good position to organize the ethernet drivers
>> concerning Synopsys IPs.
>> 
>> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>> vendor using the same IP it should be able to reuse the commonn operations. But
>> I would put that discussion for later :)
>> 
>> For now I suggest that for we create ethernet/qos and create there a folder
>> called dwc (designware controller) where all the synopsys qos IP specific code
>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
>> figure out a clean interface for "client drivers" like stmmac to interact with
>> the new qos driver.
>> 
>> What do you think about this approach?
> 
> The stmmac drivers run since many years on several platforms
> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
> configurations starting from 3.1x to 3.7x databooks.
> 
> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
> are fully working.
> 
> Also the stmmac has platform, device-tree and pcie supports and
> a lot of maintained glue-logic files.
> 
> It is fully documented inside the kernel tree.
> 
> I am happy to have new enhancements from other developers.
> So, on my side, if you want to spend your time on improving it on your
> platforms please feel free to do it!
> 
> Concerning the stmicro/stmmac naming, these come from a really old
> story and have no issue to adopt new folder/file names.
> 
> I am also open to merge fixes and changes from ethernet/synopsis.
> I want to point you on some benchmarks made by Alex some months ago
> (IIRC) that showed an stmmac winner (due to the several optimizations
> analyzed and reviewed in this mailing list).
> 
> Peppe
> 

Hello Joao and others,

As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the most mature driver, the stmmac.

I hope that the code can migrate into an ethernet/synopsys folder to keep the convention of naming the folder after the vendor. This makes it easy for others to find the driver. 

The dwc_eth_qos.c will eventually be removed and its DT binding interface can then be implemented in the stmmac driver.

- Lars

>> 
>> 
>>> 
>>>> 
>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>> 
>>>> The former only supports 4.x of the hardware.
>>>> 
>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>> with several features not present in the former (for example: TX/RX
>>>> interrupt coalescing, EEE, PTP).
>>>> 
>>>> Have you evaluated both drivers?  Why have you decided to work on the
>>>> former rather than the latter?
>>> 
>>> 
>> 
>> Thanks.
>> 
>> 
>> 
>> 
> 

^ permalink raw reply

* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Ulf Hansson @ 2016-11-21 13:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478210075-92045-2-git-send-email-lina.iyer@linaro.org>

On 3 November 2016 at 22:54, Lina Iyer <lina.iyer@linaro.org> wrote:
> Re-using idle state definition provided by arm,idle-state for domain
> idle states creates a lot of confusion and limits further evolution of
> the domain idle definition. To keep things clear and simple, define a
> idle states for domain using a new compatible "domain-idle-state".
>
> Fix existing PM domains code to look for the newly defined compatible.
>
> Cc: <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>  .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
>  .../devicetree/bindings/power/power_domain.txt     |  8 +++---
>  drivers/base/power/domain.c                        |  2 +-
>  3 files changed, 38 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
>
> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> new file mode 100644
> index 0000000..eefc7ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> @@ -0,0 +1,33 @@
> +PM Domain Idle State Node:
> +
> +A domain idle state node represents the state parameters that will be used to
> +select the state when there are no active components in the domain.
> +
> +The state node has the following parameters -
> +
> +- compatible:
> +       Usage: Required
> +       Value type: <string>
> +       Definition: Must be "domain-idle-state".
> +
> +- entry-latency-us
> +       Usage: Required
> +       Value type: <prop-encoded-array>
> +       Definition: u32 value representing worst case latency in
> +                   microseconds required to enter the idle state.
> +                   The exit-latency-us duration may be guaranteed
> +                   only after entry-latency-us has passed.
> +
> +- exit-latency-us
> +       Usage: Required
> +       Value type: <prop-encoded-array>
> +       Definition: u32 value representing worst case latency
> +                   in microseconds required to exit the idle state.
> +
> +- min-residency-us
> +       Usage: Required
> +       Value type: <prop-encoded-array>
> +       Definition: u32 value representing minimum residency duration
> +                   in microseconds after which the idle state will yield
> +                   power benefits after overcoming the overhead in entering
> +i                  the idle state.
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index e165036..723e1ad 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -31,7 +31,7 @@ Optional properties:
>
>  - domain-idle-states : A phandle of an idle-state that shall be soaked into a
>                  generic domain power state. The idle state definitions are
> -                compatible with arm,idle-state specified in [1].
> +                compatible with domain-idle-state specified in [1].
>    The domain-idle-state property reflects the idle state of this PM domain and
>    not the idle states of the devices or sub-domains in the PM domain. Devices
>    and sub-domains have their own idle-states independent of the parent
> @@ -85,7 +85,7 @@ Example 3:
>         };
>
>         DOMAIN_RET: state at 0 {
> -               compatible = "arm,idle-state";
> +               compatible = "domain-idle-state";
>                 reg = <0x0>;
>                 entry-latency-us = <1000>;
>                 exit-latency-us = <2000>;
> @@ -93,7 +93,7 @@ Example 3:
>         };
>
>         DOMAIN_PWR_DN: state at 1 {
> -               compatible = "arm,idle-state";
> +               compatible = "domain-idle-state";
>                 reg = <0x1>;
>                 entry-latency-us = <5000>;
>                 exit-latency-us = <8000>;
> @@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
>  inside a PM domain with index 0 of a power controller represented by a node
>  with the label "power".
>
> -[1]. Documentation/devicetree/bindings/arm/idle-states.txt
> +[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 661737c..f0bc672 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
>  EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
>  static const struct of_device_id idle_state_match[] = {
> -       { .compatible = "arm,idle-state", },
> +       { .compatible = "domain-idle-state", },
>         { }
>  };
>
> --
> 2.7.4
>

^ permalink raw reply

* [GIT PULL] Allwinner DT changes for 4.10
From: Maxime Ripard @ 2016-11-21 13:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161119002316.GN8882@localhost>

Hi Olof,

On Fri, Nov 18, 2016 at 04:23:16PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Tue, Nov 15, 2016 at 09:41:22PM +0100, Maxime Ripard wrote:
> > Hi Arnd, Olof,
> > 
> > Here is our pull request for the next merge window.
> > 
> > Thanks!
> > Maxime
> > 
> > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> > 
> >   Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> > 
> > are available in the git repository at:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-4.10
> > 
> > for you to fetch changes up to e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
> > 
> >   ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
> > 
> > ----------------------------------------------------------------
> > Allwinner DT additions for 4.10
> > 
> > The usual bunch of DT additions, but most notably:
> >   - A31 DRM driver
> >   - A31 audio codec
> >   - WiFi for the A80-Based boards and the CHIP
> >   - Support for the NextThing Co CHIP Pro (the first board with NAND
> >     enabled)
> >   - New boards: NanoPi M1,
> > 
> [...]
> 
> > Maxime Ripard (16):
> >       ARM: sun5i: a13-olinuxino: Enable VGA bridge
> >       ARM: gr8: Add the UART3
> >       ARM: gr8: Fix typo in the i2s mclk pin group
> >       ARM: gr8: Add missing pwm channel 1 pin
> >       ARM: gr8: Add UART2 pins
> >       ARM: gr8: Add UART3 pins
> >       ARM: gr8: Add CHIP Pro support
> >       ARM: sun5i: chip: Enable Wi-Fi SDIO chip
> >       ARM: sun5i: Rename A10s pins
> >       ARM: sun5i: Add SPI2 pins
> >       ARM: sun5i: Add RGB 565 LCD pins
> >       ARM: sun5i: chip: Add optional buses
> >       ARM: gr8: evb: Enable SPDIF
> >       ARM: gr8: evb: Add i2s codec
> >       ARM: sun8i: sina33: Enable USB gadget
> >       ARM: sunxi: Add the missing clocks to the pinctrl nodes
> > 
> [...]
> 
> >  arch/arm/boot/dts/Makefile                         |   1 +
> >  arch/arm/boot/dts/ntc-gr8-chip-pro.dts             | 266 +++++++++++++++++++++
> >  arch/arm/boot/dts/ntc-gr8-evb.dts                  |  33 +++
> >  arch/arm/boot/dts/ntc-gr8.dtsi                     |  47 +++-
> >  arch/arm/boot/dts/sun4i-a10.dtsi                   |   3 +-
> 
> NTC isn't the SoC manufacturer, and we try to keep the prefixes down to
> manufacturer to keep the namespace a little more manageable, even if
> we never got subdirectories setup as on arm64.
> 
> I think this should probably be sun4i-a10-gr8 or sun4i-r8-gr8 as prefix?

The users really expect a SoC from Nextthing, it's always been
marketed that way, the marking on the SoC also says so, etc. The fact
that it's been a design in cooperation with Allwinner, and that the
design is based on some earlier family is an implementation detail,
and I'd really like not for it to have the sun5i prefix, it's just
confusing.

And the ntc prefix has been asked for during the reviews...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/93468ce6/attachment.sig>

^ permalink raw reply

* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-11-21 13:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121101930.GD23588@cbox>

On Mon, Nov 21, 2016 at 3:49 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 18, 2016 at 10:28:34PM +0530, Vijay Kilari wrote:
>> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
>> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
>> >> <christoffer.dall@linaro.org> wrote:
>> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
>> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >>
>> >> >> VGICv3 CPU interface registers are accessed using
>> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >> >> is used to identify the cpu for registers access.
>> >> >>
>> >> >> The version of VGIC v3 specification is define here
>> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >> >>
>> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >> ---
>> >> >>  arch/arm64/include/uapi/asm/kvm.h   |   3 +
>> >> >>  arch/arm64/kvm/Makefile             |   1 +
>> >> >>  include/kvm/arm_vgic.h              |   9 +
>> >> >>  virt/kvm/arm/vgic/vgic-kvm-device.c |  27 +++
>> >> >>  virt/kvm/arm/vgic/vgic-mmio-v3.c    |  19 +++
>> >> >>  virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
>> >> >>  virt/kvm/arm/vgic/vgic-v3.c         |   8 +
>> >> >>  virt/kvm/arm/vgic/vgic.h            |   4 +
>> >> >>  8 files changed, 395 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> index 56dc08d..91c7137 100644
>> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
>> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> >> >>                       (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT      0
>> >> >>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK       (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> >> >> +#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> >> >>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> >> >>  #define KVM_DEV_ARM_VGIC_GRP_CTRL    4
>> >> >>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS    6
>> >> >> +
>> >> >>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT 0
>> >> >>
>> >> >>  /* Device Control API on vcpu fd */
>> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> >> >> index d50a82a..1a14e29 100644
>> >> >> --- a/arch/arm64/kvm/Makefile
>> >> >> +++ b/arch/arm64/kvm/Makefile
>> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> >> >
>> >> > Thi is making me wonder:  Are we properly handling GICv3 save/restore
>> >> > for AArch32 now that we have GICv3 support for AArch32?  By properly I
>> >> > mean that either it is clearly only supported on AArch64 systems or it's
>> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
>> >> > on AArch32.
>> >>
>> >> It supports both AArch64 and AArch64 in handling of system registers
>> >> save/restore.
>> >> All system registers that we save/restore are 32-bit for both aarch64
>> >> and aarch32.
>> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
>> >> are same. However the codes sent by qemu is matched and register
>> >> are handled properly irrespective of AArch32 or AArch64.
>> >>
>> >> I don't have platform which support AArch32 guests to verify.
>> >
>> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
>> > that has a GICv3.
>> >
>> > I just tried to do a v7 compile with your patches, and it results in an
>> > epic failure, so there's something for you to look at.
>> >
>> >> >
>> >> >>  kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
>> >> >>  kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
>> >> >> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>> >> >> index 002f092..730a18a 100644
>> >> >> --- a/include/kvm/arm_vgic.h
>> >> >> +++ b/include/kvm/arm_vgic.h
>> >> >> @@ -71,6 +71,9 @@ struct vgic_global {
>> >> >>
>> >> >>       /* GIC system register CPU interface */
>> >> >>       struct static_key_false gicv3_cpuif;
>> >> >> +
>> >> >> +     /* Cache ICH_VTR_EL2 reg value */
>> >> >> +     u32                     ich_vtr_el2;
>> >> >>  };
>> >> >>
>> >> >>  extern struct vgic_global kvm_vgic_global_state;
>> >> >> @@ -269,6 +272,12 @@ struct vgic_cpu {
>> >> >>       u64 pendbaser;
>> >> >>
>> >> >>       bool lpis_enabled;
>> >> >> +
>> >> >> +     /* Cache guest priority bits */
>> >> >> +     u32 num_pri_bits;
>> >> >> +
>> >> >> +     /* Cache guest interrupt ID bits */
>> >> >> +     u32 num_id_bits;
>> >> >>  };
>> >> >>
>> >> >>  extern struct static_key_false vgic_v2_cpuif_trap;
>> >> >> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> >> index 6c7d30c..da532d1 100644
>> >> >> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> >> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> >> @@ -504,6 +504,14 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
>> >> >>               if (!is_write)
>> >> >>                       *reg = tmp32;
>> >> >>               break;
>> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> +             u64 regid;
>> >> >> +
>> >> >> +             regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> >> >> +             ret = vgic_v3_cpu_sysregs_uaccess(vcpu, is_write,
>> >> >> +                                               regid, reg);
>> >> >> +             break;
>> >> >> +     }
>> >> >>       default:
>> >> >>               ret = -EINVAL;
>> >> >>               break;
>> >> >> @@ -537,6 +545,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>> >> >>               reg = tmp32;
>> >> >>               return vgic_v3_attr_regs_access(dev, attr, &reg, true);
>> >> >>       }
>> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> +             u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> >> >> +             u64 reg;
>> >> >> +
>> >> >> +             if (get_user(reg, uaddr))
>> >> >> +                     return -EFAULT;
>> >> >> +
>> >> >> +             return vgic_v3_attr_regs_access(dev, attr, &reg, true);
>> >> >> +     }
>> >> >>       }
>> >> >>       return -ENXIO;
>> >> >>  }
>> >> >> @@ -563,6 +580,15 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
>> >> >>               tmp32 = reg;
>> >> >>               return put_user(tmp32, uaddr);
>> >> >>       }
>> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> +             u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> >> >> +             u64 reg;
>> >> >> +
>> >> >> +             ret = vgic_v3_attr_regs_access(dev, attr, &reg, false);
>> >> >> +             if (ret)
>> >> >> +                     return ret;
>> >> >> +             return put_user(reg, uaddr);
>> >> >> +     }
>> >> >>       }
>> >> >>
>> >> >>       return -ENXIO;
>> >> >> @@ -581,6 +607,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>> >> >>               break;
>> >> >>       case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
>> >> >>       case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
>> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
>> >> >>               return vgic_v3_has_attr_regs(dev, attr);
>> >> >>       case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>> >> >>               return 0;
>> >> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> >> index b35fb83..519b919 100644
>> >> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> >> @@ -23,6 +23,7 @@
>> >> >>
>> >> >>  #include "vgic.h"
>> >> >>  #include "vgic-mmio.h"
>> >> >> +#include "sys_regs.h"
>> >> >>
>> >> >>  /* extract @num bytes at @offset bytes offset in data */
>> >> >>  unsigned long extract_bytes(u64 data, unsigned int offset,
>> >> >> @@ -639,6 +640,24 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> >> >>               nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
>> >> >>               break;
>> >> >>       }
>> >> >> +     case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> +             u64 reg, id;
>> >> >> +             unsigned long vgic_mpidr, mpidr_reg;
>> >> >> +             struct kvm_vcpu *vcpu;
>> >> >> +
>> >> >> +             vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
>> >> >> +                           KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
>> >> >> +
>> >> >> +             /* Convert plain mpidr value to MPIDR reg format */
>> >> >> +             mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
>> >> >> +
>> >> >> +             vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr_reg);
>> >> >> +             if (!vcpu)
>> >> >> +                     return -EINVAL;
>> >> >> +
>> >> >> +             id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> >> >> +             return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, &reg);
>> >> >> +     }
>> >> >>       default:
>> >> >>               return -ENXIO;
>> >> >>       }
>> >> >> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >> >> new file mode 100644
>> >> >> index 0000000..69d8597
>> >> >> --- /dev/null
>> >> >> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >> >
>> >> > Shouldn't we have a GPL header here?
>> >> >
>> >> >> @@ -0,0 +1,324 @@
>> >> >> +#include <linux/irqchip/arm-gic-v3.h>
>> >> >> +#include <linux/kvm.h>
>> >> >> +#include <linux/kvm_host.h>
>> >> >> +#include <kvm/iodev.h>
>> >> >> +#include <kvm/arm_vgic.h>
>> >> >> +#include <asm/kvm_emulate.h>
>> >> >> +#include <asm/kvm_arm.h>
>> >> >> +#include <asm/kvm_mmu.h>
>> >> >> +
>> >> >> +#include "vgic.h"
>> >> >> +#include "vgic-mmio.h"
>> >> >> +#include "sys_regs.h"
>> >> >> +
>> >> >> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> >> +                         const struct sys_reg_desc *r)
>> >> >> +{
>> >> >> +     struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
>> >> >> +     struct vgic_vmcr vmcr;
>> >> >> +     u64 val;
>> >> >> +     u32 num_pri_bits, num_id_bits;
>> >> >> +
>> >> >> +     vgic_get_vmcr(vcpu, &vmcr);
>> >> >> +     if (p->is_write) {
>> >> >> +             val = p->regval;
>> >> >> +
>> >> >> +             /*
>> >> >> +              * Does not allow update of ICC_CTLR_EL1 if HW does not support
>> >> >> +              * guest programmed ID and PRI bits
>> >> >> +              */
>> >> >
>> >> > I would suggest rewording this comment:
>> >> > Disallow restoring VM state not supported by this hardware.
>> >> >
>> >> >> +             num_pri_bits = ((val & ICC_CTLR_EL1_PRI_BITS_MASK) >>
>> >> >> +                             ICC_CTLR_EL1_PRI_BITS_SHIFT) + 1;
>> >> >> +             if (num_pri_bits > vgic_v3_cpu->num_pri_bits)
>> >> >> +                     return false;
>> >> >> +
>> >> >> +             vgic_v3_cpu->num_pri_bits = num_pri_bits;
>> >> >
>> >> > hmmm, this looks weird to me, because vgic_v3_cpu->num_pri_bits I don't
>> >> > understand which effect this is intended to have?
>> >> >
>> >> > Sure, it may limit what you do with other registers later, but since
>> >> > there's no ordering requirement that the ctlr be restored first, I'm not
>> >> > sure it makes sense.
>> >> >
>> >> > Also, since this field is RO in the ICH_VTR, we'll have a strange
>> >> > situation during runtime after a GICv3 restore where the
>> >> > vgic_v3_cpu->num_pri_its differs from the hardware's ICH_VTR_EL2 field,
>> >> > which is never the case if you didn't do a save/restore.
>> >>
>> >> Yes, but in any case, vgic_v3_cpu->num_pri_bits will be always less
>> >> than HW supported
>> >> value.
>> >>
>> >
>> > So answer my question:  What is the intended effect of writing this
>> > value?  Is it just so that if you migrate this platform back again, then
>> > you're checking compatibility with what the guest would potentially do,
>>
>> Yes
>
> Then add a comment explaining that
>
>> and also to limit the valid aprn registers access as you said above.
>> But that has ordering restriction. Which I think we should follow.
>>
>
> I'm sorry, now I'm confused.  Is there an ordering requirement in the
> API, or how should we follow this?

There is  no ordering requirement mentioned in the API doc.
However the APRn registers depends on num_pri_bits. Hence first
ICC_CTLR_EL1 should be restored  before APRn restore.

If ordering is not followed then APRn registers restore is allowed
as per hw supported num_pri_bits.

This should be mentioned in doc.

^ permalink raw reply

* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 13:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161121125653.GJ1005@e106497-lin.cambridge.arm.com>

On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember Daniel was commenting that this was not needed.

Removing that test results in:

[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out

and the kernel hanging, seemingly in an IRQs-off region.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* [PATCH 03/10] mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner A23
From: Lee Jones @ 2016-11-21 13:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-4-wens@csie.org>

On Sat, 12 Nov 2016, Chen-Yu Tsai wrote:

> The PRCM block on the A23 contains a message box like interface to
> the registers for the analog path controls of the internal codec.
> 
> Add a sub-device for it.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  drivers/mfd/sun6i-prcm.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
> index 011fcc555945..4abbf2ede944 100644
> --- a/drivers/mfd/sun6i-prcm.c
> +++ b/drivers/mfd/sun6i-prcm.c
> @@ -12,6 +12,9 @@
>  #include <linux/init.h>
>  #include <linux/of.h>
>  
> +#define SUN8I_CODEC_ANALOG_BASE	0x1c0
> +#define SUN8I_CODEC_ANALOG_END	(SUN8I_CODEC_ANALOG_BASE + 0x4 - 1)
> +
>  struct prcm_data {
>  	int nsubdevs;
>  	const struct mfd_cell *subdevs;
> @@ -57,6 +60,14 @@ static const struct resource sun6i_a31_apb0_rstc_res[] = {
>  	},
>  };
>  
> +static const struct resource sun8i_codec_analog_res[] = {
> +	{
> +		.start	= SUN8I_CODEC_ANALOG_BASE,
> +		.end	= SUN8I_CODEC_ANALOG_END,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +};

Use the DEVICE_RES_* macros.

>  static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
>  	{
>  		.name = "sun6i-a31-ar100-clk",
> @@ -109,6 +120,12 @@ static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
>  		.num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
>  		.resources = sun6i_a31_apb0_rstc_res,
>  	},
> +	{
> +		.name		= "sun8i-codec-analog",
> +		.of_compatible	= "allwinner,sun8i-a23-codec-analog",
> +		.num_resources	= ARRAY_SIZE(sun8i_codec_analog_res),
> +		.resources	= sun8i_codec_analog_res,
> +	},
>  };
>  
>  static const struct prcm_data sun6i_a31_prcm_data = {

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

^ permalink raw reply

* [PATCH] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Milo Kim @ 2016-11-21 13:15 UTC (permalink / raw)
  To: linux-arm-kernel

AC and USB interrupts are related with external power input.
PB interrupt means push button pressed or released event.
Use better human readable definitions.

Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++--
 include/dt-bindings/mfd/tps65217.h        | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index dc561d5..1848d58 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -319,13 +319,13 @@
 	ti,pmic-shutdown-controller;
 
 	charger {
-		interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
+		interrupts = <TPS65217_IRQ_AC_POWER>, <TPS65217_IRQ_USB_POWER>;
 		interrupts-names = "AC", "USB";
 		status = "okay";
 	};
 
 	pwrbutton {
-		interrupts = <TPS65217_IRQ_PB>;
+		interrupts = <TPS65217_IRQ_PUSHBUTTON>;
 		status = "okay";
 	};
 
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
index cafb9e6..0293fdd 100644
--- a/include/dt-bindings/mfd/tps65217.h
+++ b/include/dt-bindings/mfd/tps65217.h
@@ -19,8 +19,8 @@
 #ifndef __DT_BINDINGS_TPS65217_H__
 #define __DT_BINDINGS_TPS65217_H__
 
-#define TPS65217_IRQ_USB	0
-#define TPS65217_IRQ_AC		1
-#define TPS65217_IRQ_PB		2
+#define TPS65217_IRQ_USB_POWER		0	/* USB power state change */
+#define TPS65217_IRQ_AC_POWER		1	/* AC power state change */
+#define TPS65217_IRQ_PUSHBUTTON		2	/* Push button state change */
 
 #endif
-- 
2.9.3

^ permalink raw reply related

* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Sergei Shtylyov @ 2016-11-21 13:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <93373c309a703b57690216db4106a4a534929c15.1479726397.git.horms+renesas@verge.net.au>

Hello.

On 11/21/2016 03:05 PM, Simon Horman wrote:

> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This changes SDHI0 pin names for H3ULCB board
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> index 8d0ac076d8e2..6ffb0517421a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> @@ -163,13 +163,13 @@
>  		function = "avb";
>  	};
>
> -	sdhi0_pins_3v3: sd0_3v3 {
> +	sdhi0_pins: sd0 {
>  		groups = "sdhi0_data4", "sdhi0_ctrl";
>  		function = "sdhi0";
>  		power-source = <3300>;
>  	};
>
> -	sdhi0_pins_1v8: sd0_1v8 {
> +	sdhi0_pins_uhs: sd0 {

    I'm afraid the following will just override the props of the node above 
which is not what we ant.

>  		groups = "sdhi0_data4", "sdhi0_ctrl";
>  		function = "sdhi0";
>  		power-source = <1800>;
[...]

MBR, Sergei

^ permalink raw reply

* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Rafael J. Wysocki @ 2016-11-21 13:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87zikt6mc1.fsf@arm.com>

On Mon, Nov 21, 2016 at 1:37 PM, Brendan Jackman
<brendan.jackman@arm.com> wrote:
> Hi,
>
> On Thu, Nov 03 2016 at 21:54, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Re-using idle state definition provided by arm,idle-state for domain
>> idle states creates a lot of confusion and limits further evolution of
>> the domain idle definition. To keep things clear and simple, define a
>> idle states for domain using a new compatible "domain-idle-state".
>>
>> Fix existing PM domains code to look for the newly defined compatible.
>
> This looks good to me, pinging for review from others/queue for merge.

Well, I need an ACK from at least one DT bindings maintainer so that I
can queue it up.

>> Cc: <devicetree@vger.kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>>  .../bindings/power/domain-idle-state.txt           | 33 ++++++++++++++++++++++
>>  .../devicetree/bindings/power/power_domain.txt     |  8 +++---
>>  drivers/base/power/domain.c                        |  2 +-
>>  3 files changed, 38 insertions(+), 5 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
>> new file mode 100644
>> index 0000000..eefc7ed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
>> @@ -0,0 +1,33 @@
>> +PM Domain Idle State Node:
>> +
>> +A domain idle state node represents the state parameters that will be used to
>> +select the state when there are no active components in the domain.
>> +
>> +The state node has the following parameters -
>> +
>> +- compatible:
>> +     Usage: Required
>> +     Value type: <string>
>> +     Definition: Must be "domain-idle-state".
>> +
>> +- entry-latency-us
>> +     Usage: Required
>> +     Value type: <prop-encoded-array>
>> +     Definition: u32 value representing worst case latency in
>> +                 microseconds required to enter the idle state.
>> +                 The exit-latency-us duration may be guaranteed
>> +                 only after entry-latency-us has passed.
>> +
>> +- exit-latency-us
>> +     Usage: Required
>> +     Value type: <prop-encoded-array>
>> +     Definition: u32 value representing worst case latency
>> +                 in microseconds required to exit the idle state.
>> +
>> +- min-residency-us
>> +     Usage: Required
>> +     Value type: <prop-encoded-array>
>> +     Definition: u32 value representing minimum residency duration
>> +                 in microseconds after which the idle state will yield
>> +                 power benefits after overcoming the overhead in entering
>> +i                the idle state.
>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>> index e165036..723e1ad 100644
>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>> @@ -31,7 +31,7 @@ Optional properties:
>>
>>  - domain-idle-states : A phandle of an idle-state that shall be soaked into a
>>                  generic domain power state. The idle state definitions are
>> -                compatible with arm,idle-state specified in [1].
>> +                compatible with domain-idle-state specified in [1].
>>    The domain-idle-state property reflects the idle state of this PM domain and
>>    not the idle states of the devices or sub-domains in the PM domain. Devices
>>    and sub-domains have their own idle-states independent of the parent
>> @@ -85,7 +85,7 @@ Example 3:
>>       };
>>
>>       DOMAIN_RET: state at 0 {
>> -             compatible = "arm,idle-state";
>> +             compatible = "domain-idle-state";
>>               reg = <0x0>;
>>               entry-latency-us = <1000>;
>>               exit-latency-us = <2000>;
>> @@ -93,7 +93,7 @@ Example 3:
>>       };
>>
>>       DOMAIN_PWR_DN: state at 1 {
>> -             compatible = "arm,idle-state";
>> +             compatible = "domain-idle-state";
>>               reg = <0x1>;
>>               entry-latency-us = <5000>;
>>               exit-latency-us = <8000>;
>> @@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
>>  inside a PM domain with index 0 of a power controller represented by a node
>>  with the label "power".
>>
>> -[1]. Documentation/devicetree/bindings/arm/idle-states.txt
>> +[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 661737c..f0bc672 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
>>  EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>>
>>  static const struct of_device_id idle_state_match[] = {
>> -     { .compatible = "arm,idle-state", },
>> +     { .compatible = "domain-idle-state", },
>>       { }
>>  };
> --

Thanks,
Rafael

^ permalink raw reply

* [PATCH] clk: sunxi-ng: sun6i-a31: Enable PLL-MIPI LDOs when ungating it
From: Maxime Ripard @ 2016-11-21 13:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161118071557.30195-1-wens@csie.org>

On Fri, Nov 18, 2016 at 03:15:57PM +0800, Chen-Yu Tsai wrote:
> The PLL-MIPI clock is somewhat special as it has its own LDOs which
> need to be turned on for this PLL to actually work and output a clock
> signal.
> 
> Add the 2 LDO enable bits to the gate bits. This fixes issues with
> the TCON not sending vblank interrupts when the tcon and dot clock are
> indirectly clocked from the PLL-MIPI clock.
> 
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/9c40b2a4/attachment.sig>

^ permalink raw reply

* [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Milo Kim @ 2016-11-21 13:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161118151051.GV4082@atomide.com>

On 11/19/2016 12:10 AM, Tony Lindgren wrote:
>>> +#define TPS65217_IRQ_USB	0
>>> > > +#define TPS65217_IRQ_AC		1
>>> > > +#define TPS65217_IRQ_PB		2
>> >
>> > What are "AC" and "PB".  Seeing as these are meant to be "human
>> > readable", let's make them more human friendly.
> Good idea. Milo, please do an incremental single follow-up patch as
> I already have applied this and the dts changes using it.

Thanks for catching this. Let me send a patch soon.

Best regards,
Milo

^ permalink raw reply

* [GIT PULL] Allwinner late DT changes for 4.10
From: Maxime Ripard @ 2016-11-21 13:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161119002733.GA15902@localhost>

On Fri, Nov 18, 2016 at 04:27:33PM -0800, Olof Johansson wrote:
> On Tue, Nov 15, 2016 at 10:00:34PM +0100, Maxime Ripard wrote:
> > Hi Arnd, Olof,
> > 
> > Here is a pull request that should be merged after the pinctrl PR,
> > hence probably in your late PR.
> > 
> > This is just a mechanic conversion to the generic pinconf bindings and
> > removal of the useless pinmux properties we had.
> > 
> > This is based on the previous DT PR I just sent.
> > 
> > Thanks!
> > Maxime
> > 
> > The following changes since commit e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
> > 
> >   ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
> > 
> > are available in the git repository at:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-late-for-4.10
> > 
> > for you to fetch changes up to 1d20ba07ea57ae227a925302b42221df5b830f2b:
> > 
> >   ARM: sunxi: Convert pinctrl nodes to generic bindings (2016-11-15 21:56:30 +0100)
> 
> Nice cleanup!
> 
> Unfortuantely, see comment on previous pull request, so this would need
> to be rebased.
> 
> Also, this won't work since this branch does not contain the required
> pinctrl changes. If we merge this without basing it on those changes we lose
> bisectability.
> 
> It'd be easiest if you just held off on these until right after 4.10-rc1, and
> we could get them in before -rc2.

That works for me. I'll respin it as soon as rc1 is out.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/e2a43eee/attachment.sig>

^ permalink raw reply

page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]

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