Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-10-09 12:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAD=GYpYKL9=uY=Fks2xO6oK3bJ772yo4EiJ1tJkVU9PheSD+Cw@mail.gmail.com>

On Sat, Oct 08, 2016 at 08:43:51PM -0700, Joel Fernandes wrote:
> On Thu, Sep 29, 2016 at 1:18 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> >> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> >> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> >> awfully bad for STB. And the ftrace log also shows __free_vmap_area
> >> contributes most latency now. I noticed that Joel mentioned the same
> >> issue[1] on x86 platform and gave two solutions, but it seems no patch
> >> is sent out for this purpose.
> >>
> >> This patch adopts Joel's first solution, but I use 16MB per core
> >> rather than 8MB per core for the number of lazy_max_pages. After this
> >> patch, the preemptoff tracer reports a max 6455us latency, reduced to
> >> 1/4 of original result.
> >
> > My understanding is that
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 91f44e78c516..3f7c6d6969ac 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
> >  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> >                                         int sync, int force_flush)
> >  {
> > -       static DEFINE_SPINLOCK(purge_lock);
> >         struct llist_node *valist;
> >         struct vmap_area *va;
> >         struct vmap_area *n_va;
> > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> >          * should not expect such behaviour. This just simplifies locking for
> >          * the case that isn't actually used at the moment anyway.
> >          */
> > -       if (!sync && !force_flush) {
> > -               if (!spin_trylock(&purge_lock))
> > -                       return;
> > -       } else
> > -               spin_lock(&purge_lock);
> > -
> >         if (sync)
> >                 purge_fragmented_blocks_allcpus();
> >
> > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> >                         __free_vmap_area(va);
> >                 spin_unlock(&vmap_area_lock);
> >         }
> > -       spin_unlock(&purge_lock);
> >  }
> >
> [..]
> > should now be safe. That should significantly reduce the preempt-disabled
> > section, I think.
> 
> I believe that the purge_lock is supposed to prevent concurrent purges
> from happening.
> 
> For the case where if you have another concurrent overflow happen in
> alloc_vmap_area() between the spin_unlock and purge :
> 
> spin_unlock(&vmap_area_lock);
> if (!purged)
>    purge_vmap_area_lazy();
> 
> Then the 2 purges would happen at the same time and could subtract
> vmap_lazy_nr twice.

That itself is not the problem, as each instance of
__purge_vmap_area_lazy() operates on its own freelist, and so there will
be no double accounting.

However, removing the lock removes the serialisation which does mean
that alloc_vmap_area() will not block on another thread conducting the
purge, and so it will try to reallocate before that is complete and the
free area made available. It also means that we are doing the
atomic_sub(vmap_lazy_nr) too early.

That supports making the outer lock a mutex as you suggested. But I think
cond_resched_lock() is better for the vmap_area_lock (just because it
turns out to be an expensive loop and we may want the reschedule).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply

* [PATCH 5/9] mtd: nand: Expose data interface for ONFI mode 0
From: Boris Brezillon @ 2016-10-09 11:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161009051248.GC10199@brian-ubuntu>

Hi Brian,

On Sat, 8 Oct 2016 22:12:48 -0700
Brian Norris <computersforpeace@gmail.com> wrote:

> On Thu, Sep 15, 2016 at 02:56:25PM +0200, Boris Brezillon wrote:
> > On Thu, 15 Sep 2016 10:32:49 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >   
> > > The nand layer will need ONFI mode 0 to use it as timing mode
> > > before and right after reset.
> > > 
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > ---
> > >  drivers/mtd/nand/nand_timings.c | 11 +++++++++++
> > >  include/linux/mtd/nand.h        |  2 ++
> > >  2 files changed, 13 insertions(+)
> > > 
> > > diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c
> > > index 608d098..9cdbc16 100644
> > > --- a/drivers/mtd/nand/nand_timings.c
> > > +++ b/drivers/mtd/nand/nand_timings.c
> > > @@ -297,3 +297,14 @@ int onfi_init_data_interface(struct nand_chip *chip,
> > >  
> > >  	return 0;
> > >  }
> > > +
> > > +/**
> > > + * nand_get_default_data_interface - [NAND Interface] Retrieve NAND
> > > + * data interface for mode 0. This is used as default timing after
> > > + * reset.
> > > + */
> > > +const struct nand_data_interface *nand_get_default_data_interface(void)
> > > +{
> > > +	return &onfi_sdr_timings[0];
> > > +}
> > > +EXPORT_SYMBOL(nand_get_default_data_interface);  
> > 
> > You export nand_get_default_data_interface() here, but you don't export
> > onfi_init_data_interface().
> > None of these functions should be called from NAND controller drivers,
> > so they don't need to be exported. ITOH, the prototypes are public
> > (defined in nand.h), so nothing prevents a driver from calling these
> > functions.  
> 
> A bit late, but we can still change things for the next cycle of
> course...
> 
> > I don't know what's the best solution here:
> > 1/ Export both nand_get_default_data_interface() and
> >    onfi_init_data_interface()  
> 
> I don't really like this one. We shouldn't export them if we don't want
> people to use them in modules. And I'm sure the various compile-test
> builders out there would complain eventually if someone did.

Yes, I had the feeling it was the wrong choice, but it was also the
less invasive one ;-).

> 
> > 2/ Do not export them, but keep their prototypes in nand.h with a
> >    comment saying that they should not be directly called by NAND
> >    controller drivers  
> 
> Could be OK.

I don't like that one. It just bloats nand.h with things that are not
supposed to be exported to NAND controller drivers, which just adds
more confusion (the NAND framework is already hard to
follow/understand, let's try not to make it worse).

> 
> > 3/ Removing the prototypes from nand.h and defining them in nand_base.c
> >    (or in a private header).  
> 
> I like this one. Why not add a drivers/mtd/nand/nand.h that's intended
> for the nand.{o,ko} module only?

I like this one too. I'll try to come up with something (maybe with a
different name, like core.h, to prevent developers from including this
file in their NAND controller drivers).

Thanks,

Boris

^ permalink raw reply

* [PATCH] ahci: qoriq: added ls1046a platform support
From: yuantian.tang at nxp.com @ 2016-10-09  8:57 UTC (permalink / raw)
  To: linux-arm-kernel

From: Tang Yuantian <Yuantian.Tang@nxp.com>

Ls1046a is a new introduced soc which supports ATA3.0.

Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
 drivers/ata/ahci_qoriq.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 1eba8df..9884c8c 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -46,11 +46,13 @@
 #define LS1021A_AXICC_ADDR	0xC0
 
 #define SATA_ECC_DISABLE	0x00020000
+#define LS1046A_SATA_ECC_DIS	0x80000000
 
 enum ahci_qoriq_type {
 	AHCI_LS1021A,
 	AHCI_LS1043A,
 	AHCI_LS2080A,
+	AHCI_LS1046A,
 };
 
 struct ahci_qoriq_priv {
@@ -63,6 +65,7 @@ static const struct of_device_id ahci_qoriq_of_match[] = {
 	{ .compatible = "fsl,ls1021a-ahci", .data = (void *)AHCI_LS1021A},
 	{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
 	{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
+	{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
 	{},
 };
 MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
@@ -175,6 +178,13 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
 		writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
 		writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
 		break;
+
+	case AHCI_LS1046A:
+		writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
+		writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+		writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
+		writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+		break;
 	}
 
 	return 0;
@@ -204,9 +214,9 @@ static int ahci_qoriq_probe(struct platform_device *pdev)
 
 	qoriq_priv->type = (enum ahci_qoriq_type)of_id->data;
 
-	if (qoriq_priv->type == AHCI_LS1021A) {
-		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-				"sata-ecc");
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+			"sata-ecc");
+	if (res) {
 		qoriq_priv->ecc_addr = devm_ioremap_resource(dev, res);
 		if (IS_ERR(qoriq_priv->ecc_addr))
 			return PTR_ERR(qoriq_priv->ecc_addr);
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH v3 3/4] ARM: dts: am33xx: add DMA properties for tscadc
From: Jonathan Cameron @ 2016-10-09  8:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161005090443.24576-4-mugunthanvnm@ti.com>

On 05/10/16 10:04, Mugunthan V N wrote:
> Add DMA properties for tscadc
> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Do the binding docs need updating to reflect this?  I can't immediately
find the relevant doc to check!

Jonathan
> ---
>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 98748c6..6d607b8 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -917,6 +917,8 @@
>  			interrupts = <16>;
>  			ti,hwmods = "adc_tsc";
>  			status = "disabled";
> +			dmas = <&edma 53 0>, <&edma 57 0>;
> +			dma-names = "fifo0", "fifo1";
>  
>  			tsc {
>  				compatible = "ti,am3359-tsc";
> 

^ permalink raw reply

* [PATCH v3 2/4] drivers: iio: ti_am335x_adc: add dma support
From: Jonathan Cameron @ 2016-10-09  8:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161005090443.24576-3-mugunthanvnm@ti.com>

On 05/10/16 10:04, Mugunthan V N wrote:
> This patch adds the required pieces to ti_am335x_adc driver for
> DMA support
> 
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Hi,

Just the one question inline.  I'll also need an Ack from Lee as
this touches code in mfd (as does the previous patch).
We have obviously missed this merge window, so no particular rush.

Otherwise, looking very nice indeed.  Got to get my BBB out and play
with this now ;)

Jonathan
> ---
>  drivers/iio/adc/ti_am335x_adc.c      | 148 ++++++++++++++++++++++++++++++++++-
>  include/linux/mfd/ti_am335x_tscadc.h |   7 ++
>  2 files changed, 152 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index c3cfacca..ad9dec3 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -30,10 +30,28 @@
>  #include <linux/iio/buffer.h>
>  #include <linux/iio/kfifo_buf.h>
>  
> +#include <linux/dmaengine.h>
> +#include <linux/dma-mapping.h>
> +
> +#define DMA_BUFFER_SIZE		SZ_2K
> +
> +struct tiadc_dma {
> +	struct dma_slave_config	conf;
> +	struct dma_chan		*chan;
> +	dma_addr_t		addr;
> +	dma_cookie_t		cookie;
> +	u8			*buf;
> +	int			current_period;
> +	int			period_size;
> +	u8			fifo_thresh;
> +};
> +
>  struct tiadc_device {
>  	struct ti_tscadc_dev *mfd_tscadc;
> +	struct tiadc_dma dma;
>  	struct mutex fifo1_lock; /* to protect fifo access */
>  	int channels;
> +	int total_ch_enabled;
>  	u8 channel_line[8];
>  	u8 channel_step[8];
>  	int buffer_en_ch_steps;
> @@ -198,6 +216,67 @@ static irqreturn_t tiadc_worker_h(int irq, void *private)
>  	return IRQ_HANDLED;
>  }
>  
> +static void tiadc_dma_rx_complete(void *param)
> +{
> +	struct iio_dev *indio_dev = param;
> +	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> +	struct tiadc_dma *dma = &adc_dev->dma;
> +	u8 *data;
> +	int i;
> +
> +	data = dma->buf + dma->current_period * dma->period_size;
> +	dma->current_period = 1 - dma->current_period; /* swap the buffer ID */
> +
> +	for (i = 0; i < dma->period_size; i += indio_dev->scan_bytes) {
> +		iio_push_to_buffers(indio_dev, data);
> +		data += indio_dev->scan_bytes;
> +	}
Hmm. Another case for the mooted iio_push_to_buffers_multi. Guess
we should move on with that one ;)
> +}
> +
> +static int tiadc_start_dma(struct iio_dev *indio_dev)
> +{
> +	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> +	struct tiadc_dma *dma = &adc_dev->dma;
> +	struct dma_async_tx_descriptor *desc;
> +
> +	dma->current_period = 0; /* We start to fill period 0 */
> +	/*
> +	 * Make the fifo thresh as the multiple of total number of
> +	 * channels enabled, so make sure that cyclic DMA period
> +	 * length is also a multiple of total number of channels
> +	 * enabled. This ensures that no invalid data is reported
> +	 * to the stack via iio_push_to_buffers().
> +	 */
> +	dma->fifo_thresh = rounddown(FIFO1_THRESHOLD + 1,
> +				     adc_dev->total_ch_enabled) - 1;
> +	/* Make sure that period length is multiple of fifo thresh level */
> +	dma->period_size = rounddown(DMA_BUFFER_SIZE / 2,
> +				    (dma->fifo_thresh + 1) * sizeof(u16));
> +
> +	dma->conf.src_maxburst = dma->fifo_thresh + 1;
> +	dmaengine_slave_config(dma->chan, &dma->conf);
> +
> +	desc = dmaengine_prep_dma_cyclic(dma->chan, dma->addr,
> +					 dma->period_size * 2,
> +					 dma->period_size, DMA_DEV_TO_MEM,
> +					 DMA_PREP_INTERRUPT);
> +	if (!desc)
> +		return -EBUSY;
> +
> +	desc->callback = tiadc_dma_rx_complete;
> +	desc->callback_param = indio_dev;
> +
> +	dma->cookie = dmaengine_submit(desc);
> +
> +	dma_async_issue_pending(dma->chan);
> +
> +	tiadc_writel(adc_dev, REG_FIFO1THR, dma->fifo_thresh);
> +	tiadc_writel(adc_dev, REG_DMA1REQ, dma->fifo_thresh);
> +	tiadc_writel(adc_dev, REG_DMAENABLE_SET, DMA_FIFO1);
> +
> +	return 0;
> +}
> +
>  static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>  {
>  	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> @@ -218,20 +297,30 @@ static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>  static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>  {
>  	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> +	struct tiadc_dma *dma = &adc_dev->dma;
> +	unsigned int irq_enable;
>  	unsigned int enb = 0;
>  	u8 bit;
>  
>  	tiadc_step_config(indio_dev);
> -	for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels)
> +	for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels) {
>  		enb |= (get_adc_step_bit(adc_dev, bit) << 1);
> +		adc_dev->total_ch_enabled++;
> +	}
>  	adc_dev->buffer_en_ch_steps = enb;
>  
> +	if (dma->chan)
> +		tiadc_start_dma(indio_dev);
> +
>  	am335x_tsc_se_set_cache(adc_dev->mfd_tscadc, enb);
>  
>  	tiadc_writel(adc_dev,  REG_IRQSTATUS, IRQENB_FIFO1THRES
>  				| IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW);
> -	tiadc_writel(adc_dev,  REG_IRQENABLE, IRQENB_FIFO1THRES
> -				| IRQENB_FIFO1OVRRUN);
> +
> +	irq_enable = IRQENB_FIFO1OVRRUN;
> +	if (!dma->chan)
> +		irq_enable |= IRQENB_FIFO1THRES;
This changes the non dma behaviour as we no longer set IRQENB_FIFO1THRES.
Why?  Was it wrong before?
> +	tiadc_writel(adc_dev,  REG_IRQENABLE, irq_enable);
>  
>  	return 0;
>  }
> @@ -239,12 +328,18 @@ static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>  static int tiadc_buffer_predisable(struct iio_dev *indio_dev)
>  {
>  	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> +	struct tiadc_dma *dma = &adc_dev->dma;
>  	int fifo1count, i, read;
>  
>  	tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
>  				IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW));
>  	am335x_tsc_se_clr(adc_dev->mfd_tscadc, adc_dev->buffer_en_ch_steps);
>  	adc_dev->buffer_en_ch_steps = 0;
> +	adc_dev->total_ch_enabled = 0;
> +	if (dma->chan) {
> +		tiadc_writel(adc_dev, REG_DMAENABLE_CLEAR, 0x2);
> +		dmaengine_terminate_async(dma->chan);
> +	}
>  
>  	/* Flush FIFO of leftover data in the time it takes to disable adc */
>  	fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
> @@ -430,6 +525,41 @@ static const struct iio_info tiadc_info = {
>  	.driver_module = THIS_MODULE,
>  };
>  
> +static int tiadc_request_dma(struct platform_device *pdev,
> +			     struct tiadc_device *adc_dev)
> +{
> +	struct tiadc_dma	*dma = &adc_dev->dma;
> +	dma_cap_mask_t		mask;
> +
> +	/* Default slave configuration parameters */
> +	dma->conf.direction = DMA_DEV_TO_MEM;
> +	dma->conf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> +	dma->conf.src_addr = adc_dev->mfd_tscadc->tscadc_phys_base + REG_FIFO1;
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_CYCLIC, mask);
> +
> +	/* Get a channel for RX */
> +	dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
> +	if (IS_ERR(dma->chan)) {
> +		int ret = PTR_ERR(dma->chan);
> +
> +		dma->chan = NULL;
> +		return ret;
> +	}
> +
> +	/* RX buffer */
> +	dma->buf = dma_alloc_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
> +				      &dma->addr, GFP_KERNEL);
> +	if (!dma->buf)
> +		goto err;
> +
> +	return 0;
> +err:
> +	dma_release_channel(dma->chan);
> +	return -ENOMEM;
> +}
> +
>  static int tiadc_parse_dt(struct platform_device *pdev,
>  			  struct tiadc_device *adc_dev)
>  {
> @@ -512,8 +642,14 @@ static int tiadc_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, indio_dev);
>  
> +	err = tiadc_request_dma(pdev, adc_dev);
> +	if (err && err == -EPROBE_DEFER)
> +		goto err_dma;
> +
>  	return 0;
>  
> +err_dma:
> +	iio_device_unregister(indio_dev);
>  err_buffer_unregister:
>  	tiadc_iio_buffered_hardware_remove(indio_dev);
>  err_free_channels:
> @@ -525,8 +661,14 @@ static int tiadc_remove(struct platform_device *pdev)
>  {
>  	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>  	struct tiadc_device *adc_dev = iio_priv(indio_dev);
> +	struct tiadc_dma *dma = &adc_dev->dma;
>  	u32 step_en;
>  
> +	if (dma->chan) {
> +		dma_free_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
> +				  dma->buf, dma->addr);
> +		dma_release_channel(dma->chan);
> +	}
>  	iio_device_unregister(indio_dev);
>  	tiadc_iio_buffered_hardware_remove(indio_dev);
>  	tiadc_channels_remove(indio_dev);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> index e45a208..b9a53e0 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -23,6 +23,8 @@
>  #define REG_IRQENABLE		0x02C
>  #define REG_IRQCLR		0x030
>  #define REG_IRQWAKEUP		0x034
> +#define REG_DMAENABLE_SET	0x038
> +#define REG_DMAENABLE_CLEAR	0x03c
>  #define REG_CTRL		0x040
>  #define REG_ADCFSM		0x044
>  #define REG_CLKDIV		0x04C
> @@ -36,6 +38,7 @@
>  #define REG_FIFO0THR		0xE8
>  #define REG_FIFO1CNT		0xF0
>  #define REG_FIFO1THR		0xF4
> +#define REG_DMA1REQ		0xF8
>  #define REG_FIFO0		0x100
>  #define REG_FIFO1		0x200
>  
> @@ -126,6 +129,10 @@
>  #define FIFOREAD_DATA_MASK (0xfff << 0)
>  #define FIFOREAD_CHNLID_MASK (0xf << 16)
>  
> +/* DMA ENABLE/CLEAR Register */
> +#define DMA_FIFO0		BIT(0)
> +#define DMA_FIFO1		BIT(1)
> +
>  /* Sequencer Status */
>  #define SEQ_STATUS BIT(5)
>  #define CHARGE_STEP		0x11
> 

^ permalink raw reply

* [PATCH v2 1/2] dt-bindings: add bindings doc for ZTE VOU display controller
From: Shawn Guo @ 2016-10-09  7:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161003174429.GA26054@rob-hp-laptop>

On Mon, Oct 03, 2016 at 12:44:29PM -0500, Rob Herring wrote:
> > +Example:
> > +
> > +vou: vou at 1440000 {
> > +	compatible = "zte,zx296718-vou";
> > +	#address-cells = <1>;
> > +	#size-cells = <1>;
> > +	reg = <0x1440000 0x10000>;
> > +	ranges;
> 
> You still have overlapping addresses. Explicitly list the sub ranges in 
> reg here used by the VOU driver if the driver usage doesn't overlap. If 
> there is overlap (2 drivers accessing the same range), then you need 
> some APIs between the components (or possibly regmap).

The driver matching "zte,zx296718-vou" doesn't map or access the any
'reg' address.  The 'reg' property here is more like a hint telling
that the VOU block covers the address space of all child devices.

I will simply drop the 'reg' property here.

> Also, don't do an empty ranges here. Fill it in so the child nodes are 
> just offsets of 0x1440000

Okay.  I thought that empty 'ranges' is fine as long as parent and child
address spaces are identical (1:1 mapping).

So with your suggestion, I made the changes below.  Let me know if this
is still not what you are asking for.

Shawn

-----8<-----------------

diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt
index d03ba4c4810c..6bb4ab2517ef 100644
--- a/Documentation/devicetree/bindings/display/zte,vou.txt
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -56,14 +56,13 @@ vou: vou@1440000 {
        compatible = "zte,zx296718-vou";
        #address-cells = <1>;
        #size-cells = <1>;
-       reg = <0x1440000 0x10000>;
-       ranges;
+       ranges = <0 0x1440000 0x10000>;
 
-       dpc: dpc at 1440000 {
+       dpc: dpc at 0 {
                compatible = "zte,zx296718-dpc";
-               reg = <0x1440000 0x1000>, <0x1441000 0x1000>,
-                     <0x1445000 0x1000>, <0x1446000 0x1000>,
-                     <0x144a000 0x1000>;
+               reg = <0x0000 0x1000>, <0x1000 0x1000>,
+                     <0x5000 0x1000>, <0x6000 0x1000>,
+                     <0xa000 0x1000>;
                reg-names = "osd", "timing_ctrl",
                            "dtrc", "vou_ctrl",
                            "otfppu";
@@ -74,9 +73,9 @@ vou: vou at 1440000 {
                              "main_wclk", "aux_wclk";
        };
 
-       hdmi: hdmi at 144c000 {
+       hdmi: hdmi at c000 {
                compatible = "zte,zx296718-hdmi";
-               reg = <0x144c000 0x4000>;
+               reg = <0xc000 0x4000>;
                interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>;

^ permalink raw reply related

* [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings
From: Troy Jia @ 2016-10-09  7:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474253068.23153.2.camel@intel.com>

> -----Original Message-----
> From: Zhang Rui [mailto:rui.zhang at intel.com]
> Sent: Monday, September 19, 2016 10:44 AM
> To: Leo Li <pku.leo@gmail.com>; Rob Herring <robh@kernel.org>
> Cc: Troy Jia <hongtao.jia@nxp.com>; devicetree at vger.kernel.org; linux-
> pm at vger.kernel.org; linuxppc-dev <linuxppc-dev@lists.ozlabs.org>; lkml <linux-
> kernel at vger.kernel.org>; Scott Wood <scott.wood@nxp.com>; Eduardo Valentin
> <edubezval@gmail.com>; Kumar Gala <galak@codeaurora.org>; Shawn Guo
> <shawnguo@kernel.org>; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings
> 
> On ?, 2016-09-14 at 11:40 -0500, Leo Li wrote:
> > On Wed, Jun 8, 2016 at 2:52 PM, Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Tue, Jun 07, 2016 at 11:27:34AM +0800, Jia Hongtao wrote:
> > > >
> > > > For different types of SoC the sensor id and endianness may vary.
> > > > "#thermal-sensor-cells" is used to provide sensor id information.
> > > > "little-endian" property is to tell the endianness of TMU.
> > > >
> > > > Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
> > > > ---
> > > > Changes for V2:
> > > > * Remove formatting chnages.
> > > >
> > > > ?Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7
> > > > +++++++
> > > > ?1 file changed, 7 insertions(+)
> > > Acked-by: Rob Herring <robh@kernel.org>
> > Hi Zhang Rui,
> >
> > Since you have applied the driver patch, can you also apply the
> > binding patch???The binding is supposed to go with the driver.
> >
> 
> Do you mean I should take both patch 1/7 and 7/7? I can not see the other patches
> in this patch set.

Yes, please take 7/7 as well.
I also reworked the device tree patches and you can find them here:
https://patchwork.kernel.org/patch/9368377/
https://patchwork.kernel.org/patch/9368381/
https://patchwork.kernel.org/patch/9368383/
https://patchwork.kernel.org/patch/9368379/
https://patchwork.kernel.org/patch/9368385/

-Hongtao.

> 
> thanks,
> rui

^ permalink raw reply

* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Tomasz Figa @ 2016-10-09  7:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1472987060-28293-1-git-send-email-krzk@kernel.org>

Hi Krzysztof,

2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>
> Hi,
>
> Changes since v2
> ================
> 1. Combine separate patchsets into one. Previously I sent separately the fixes
>    and changes for S3C platforms.
> 2. Fix issues pointed during review.
> 3. Add review tags.
>
> Changes since v1
> ================
> 1. Follow Arnd's suggestion about moving the macros to common place.
> 2. Subjects: replace "GPIO" with "pinctrl".
> 3. There were some major changes here so I did not add Javier's
>    reviewed-by and tested-by tags.
>
> Merging
> =======
> Patches #1 and #2 should probably go through pinctrl tree. In that case I would
> appreciate a stable branch/tag so DTS could base on top of it.
>
> Goal
> ====
> Increase readability:
>         uart0_data: uart0-data {
>                 samsung,pins = "gpa0-0", "gpa0-1";
> -               samsung,pin-function = <2>;
> -               samsung,pin-pud = <0>;
> -               samsung,pin-drv = <0>;
> +               samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> +               samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> +               samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;

I like the idea, thanks for cleaning this up. However I'd like to
bikeshed the prefix a bit. Since the properties are already prefixed
by "samsung,", I think it would make much more sense to also prefix
the generic values with "SAMSUNG_". Of course for soc/family-specific
values, the soc/family name prefix sounds right.

Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
however hurts the consistency and could confuse the people writing new
dts files.

Best regards,
Tomasz

^ permalink raw reply

* [RESEND PATCH v6, 3/5] usb: xhci-mtk: make IPPC register optional
From: Chunfeng Yun @ 2016-10-09  6:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1474437277-27201-4-git-send-email-chunfeng.yun@mediatek.com>

On Wed, 2016-09-21 at 13:54 +0800, Chunfeng Yun wrote:
> Make IPPC register optional to support host side of dual-role mode,
> due to it is moved into common glue layer for simplification.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
>  drivers/usb/host/xhci-mtk.c |   36 +++++++++++++++++++++++++++++-------
>  1 file changed, 29 insertions(+), 7 deletions(-)

Hi Mathias,

    Would you please take a little time out of your busy schedule and
help review this patch?

    Thank you very much.

^ permalink raw reply

* [PATCH V2 5/5] arm64:dt:ls2080a: Add TMU device tree support for LS2080A
From: Jia Hongtao @ 2016-10-09  6:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475995626-14049-1-git-send-email-hongtao.jia@nxp.com>

From: Hongtao Jia <hongtao.jia@nxp.com>

Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts  |   2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts  |   2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts |   2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi     | 116 +++++++++++++++++++--
 4 files changed, 111 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
index b0dd010..8bc1f8f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
@@ -46,7 +46,7 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2080a.dtsi"
+#include "fsl-ls2080a.dtsi"
 
 / {
 	model = "Freescale Layerscape 2080a QDS Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
index ad0ebb8..265e0a8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts
@@ -46,7 +46,7 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2080a.dtsi"
+#include "fsl-ls2080a.dtsi"
 
 / {
 	model = "Freescale Layerscape 2080a RDB Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts b/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
index 505d038..290604b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
@@ -46,7 +46,7 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2080a.dtsi"
+#include "fsl-ls2080a.dtsi"
 
 / {
 	model = "Freescale Layerscape 2080a software Simulator model";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 337da90..723185e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -44,6 +44,8 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include <dt-bindings/thermal/thermal.h>
+
 / {
 	compatible = "fsl,ls2080a";
 	interrupt-parent = <&gic>;
@@ -62,15 +64,16 @@
 		 */
 
 		/* We have 4 clusters having 2 Cortex-A57 cores each */
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x0>;
 			clocks = <&clockgen 1 0>;
 			next-level-cache = <&cluster0_l2>;
+			#cooling-cells = <2>;
 		};
 
-		cpu at 1 {
+		cpu1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x1>;
@@ -78,15 +81,16 @@
 			next-level-cache = <&cluster0_l2>;
 		};
 
-		cpu at 100 {
+		cpu2: cpu at 100 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x100>;
 			clocks = <&clockgen 1 1>;
 			next-level-cache = <&cluster1_l2>;
+			#cooling-cells = <2>;
 		};
 
-		cpu at 101 {
+		cpu3: cpu at 101 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x101>;
@@ -94,15 +98,16 @@
 			next-level-cache = <&cluster1_l2>;
 		};
 
-		cpu at 200 {
+		cpu4: cpu at 200 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x200>;
 			clocks = <&clockgen 1 2>;
 			next-level-cache = <&cluster2_l2>;
+			#cooling-cells = <2>;
 		};
 
-		cpu at 201 {
+		cpu5: cpu at 201 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x201>;
@@ -110,15 +115,16 @@
 			next-level-cache = <&cluster2_l2>;
 		};
 
-		cpu at 300 {
+		cpu6: cpu at 300 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x300>;
 			clocks = <&clockgen 1 3>;
 			next-level-cache = <&cluster3_l2>;
+			#cooling-cells = <2>;
 		};
 
-		cpu at 301 {
+		cpu7: cpu at 301 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a57";
 			reg = <0x301>;
@@ -215,6 +221,100 @@
 			clocks = <&sysclk>;
 		};
 
+		tmu: tmu at 1f80000 {
+			compatible = "fsl,qoriq-tmu";
+			reg = <0x0 0x1f80000 0x0 0x10000>;
+			interrupts = <0 23 0x4>;
+			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x30062>;
+			fsl,tmu-calibration = <0x00000000 0x00000026
+					       0x00000001 0x0000002d
+					       0x00000002 0x00000032
+					       0x00000003 0x00000039
+					       0x00000004 0x0000003f
+					       0x00000005 0x00000046
+					       0x00000006 0x0000004d
+					       0x00000007 0x00000054
+					       0x00000008 0x0000005a
+					       0x00000009 0x00000061
+					       0x0000000a 0x0000006a
+					       0x0000000b 0x00000071
+
+					       0x00010000 0x00000025
+					       0x00010001 0x0000002c
+					       0x00010002 0x00000035
+					       0x00010003 0x0000003d
+					       0x00010004 0x00000045
+					       0x00010005 0x0000004e
+					       0x00010006 0x00000057
+					       0x00010007 0x00000061
+					       0x00010008 0x0000006b
+					       0x00010009 0x00000076
+
+					       0x00020000 0x00000029
+					       0x00020001 0x00000033
+					       0x00020002 0x0000003d
+					       0x00020003 0x00000049
+					       0x00020004 0x00000056
+					       0x00020005 0x00000061
+					       0x00020006 0x0000006d
+
+					       0x00030000 0x00000021
+					       0x00030001 0x0000002a
+					       0x00030002 0x0000003c
+					       0x00030003 0x0000004e>;
+			little-endian;
+			#thermal-sensor-cells = <1>;
+		};
+
+		thermal-zones {
+			cpu_thermal: cpu-thermal {
+				polling-delay-passive = <1000>;
+				polling-delay = <5000>;
+
+				thermal-sensors = <&tmu 4>;
+
+				trips {
+					cpu_alert: cpu-alert {
+						temperature = <75000>;
+						hysteresis = <2000>;
+						type = "passive";
+					};
+					cpu_crit: cpu-crit {
+						temperature = <85000>;
+						hysteresis = <2000>;
+						type = "critical";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&cpu_alert>;
+						cooling-device =
+							<&cpu0 THERMAL_NO_LIMIT
+							THERMAL_NO_LIMIT>;
+					};
+					map1 {
+						trip = <&cpu_alert>;
+						cooling-device =
+							<&cpu2 THERMAL_NO_LIMIT
+							THERMAL_NO_LIMIT>;
+					};
+					map2 {
+						trip = <&cpu_alert>;
+						cooling-device =
+							<&cpu4 THERMAL_NO_LIMIT
+							THERMAL_NO_LIMIT>;
+					};
+					map3 {
+						trip = <&cpu_alert>;
+						cooling-device =
+							<&cpu6 THERMAL_NO_LIMIT
+							THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
+
 		serial0: serial at 21c0500 {
 			compatible = "fsl,ns16550", "ns16550a";
 			reg = <0x0 0x21c0500 0x0 0x100>;
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH V2 4/5] arm64:dt:ls1043a: Add TMU device tree support for LS1043A
From: Jia Hongtao @ 2016-10-09  6:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475995626-14049-1-git-send-email-hongtao.jia@nxp.com>

From: Hongtao Jia <hongtao.jia@nxp.com>

Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi    | 78 +++++++++++++++++++++++
 3 files changed, 80 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index dd9e919..0989d63 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -45,7 +45,7 @@
  */
 
 /dts-v1/;
-/include/ "fsl-ls1043a.dtsi"
+#include "fsl-ls1043a.dtsi"
 
 / {
 	model = "LS1043A QDS Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index d2313e0..c37110b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -45,7 +45,7 @@
  */
 
 /dts-v1/;
-/include/ "fsl-ls1043a.dtsi"
+#include "fsl-ls1043a.dtsi"
 
 / {
 	model = "LS1043A RDB Board";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 220ac70..41e5dc1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -44,6 +44,8 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include <dt-bindings/thermal/thermal.h>
+
 / {
 	compatible = "fsl,ls1043a";
 	interrupt-parent = <&gic>;
@@ -66,6 +68,7 @@
 			reg = <0x0>;
 			clocks = <&clockgen 1 0>;
 			next-level-cache = <&l2>;
+			#cooling-cells = <2>;
 		};
 
 		cpu1: cpu at 1 {
@@ -254,6 +257,81 @@
 			big-endian;
 		};
 
+		tmu: tmu at 1f00000 {
+			compatible = "fsl,qoriq-tmu";
+			reg = <0x0 0x1f00000 0x0 0x10000>;
+			interrupts = <0 33 0x4>;
+			fsl,tmu-range = <0xb0000 0x9002a 0x6004c 0x30062>;
+			fsl,tmu-calibration = <0x00000000 0x00000026
+					       0x00000001 0x0000002d
+					       0x00000002 0x00000032
+					       0x00000003 0x00000039
+					       0x00000004 0x0000003f
+					       0x00000005 0x00000046
+					       0x00000006 0x0000004d
+					       0x00000007 0x00000054
+					       0x00000008 0x0000005a
+					       0x00000009 0x00000061
+					       0x0000000a 0x0000006a
+					       0x0000000b 0x00000071
+
+					       0x00010000 0x00000025
+					       0x00010001 0x0000002c
+					       0x00010002 0x00000035
+					       0x00010003 0x0000003d
+					       0x00010004 0x00000045
+					       0x00010005 0x0000004e
+					       0x00010006 0x00000057
+					       0x00010007 0x00000061
+					       0x00010008 0x0000006b
+					       0x00010009 0x00000076
+
+					       0x00020000 0x00000029
+					       0x00020001 0x00000033
+					       0x00020002 0x0000003d
+					       0x00020003 0x00000049
+					       0x00020004 0x00000056
+					       0x00020005 0x00000061
+					       0x00020006 0x0000006d
+
+					       0x00030000 0x00000021
+					       0x00030001 0x0000002a
+					       0x00030002 0x0000003c
+					       0x00030003 0x0000004e>;
+			#thermal-sensor-cells = <1>;
+		};
+
+		thermal-zones {
+			cpu_thermal: cpu-thermal {
+				polling-delay-passive = <1000>;
+				polling-delay = <5000>;
+
+				thermal-sensors = <&tmu 3>;
+
+				trips {
+					cpu_alert: cpu-alert {
+						temperature = <85000>;
+						hysteresis = <2000>;
+						type = "passive";
+					};
+					cpu_crit: cpu-crit {
+						temperature = <95000>;
+						hysteresis = <2000>;
+						type = "critical";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&cpu_alert>;
+						cooling-device =
+							<&cpu0 THERMAL_NO_LIMIT
+							THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
+
 		dspi0: dspi at 2100000 {
 			compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
 			#address-cells = <1>;
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH V2 3/5] arm:dt:ls1021a: Add TMU device tree support for LS1021A
From: Jia Hongtao @ 2016-10-09  6:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475995626-14049-1-git-send-email-hongtao.jia@nxp.com>

From: Hongtao Jia <hongtao.jia@nxp.com>

Also add nodes and properties for thermal management support.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/arm/boot/dts/ls1021a.dtsi | 84 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..282d854 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -47,6 +47,7 @@
 
 #include "skeleton64.dtsi"
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	compatible = "fsl,ls1021a";
@@ -70,14 +71,15 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu at f00 {
+		cpu0: cpu at f00 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <0xf00>;
 			clocks = <&cluster1_clk>;
+			#cooling-cells = <2>;
 		};
 
-		cpu at f01 {
+		cpu1: cpu at f01 {
 			compatible = "arm,cortex-a7";
 			device_type = "cpu";
 			reg = <0xf01>;
@@ -251,6 +253,84 @@
 			};
 		};
 
+		tmu: tmu at 1f00000 {
+			compatible = "fsl,qoriq-tmu";
+			reg = <0x0 0x1f00000 0x0 0x10000>;
+			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+			fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x30061>;
+			fsl,tmu-calibration = <0x00000000 0x0000000f
+					       0x00000001 0x00000017
+					       0x00000002 0x0000001e
+					       0x00000003 0x00000026
+					       0x00000004 0x0000002e
+					       0x00000005 0x00000035
+					       0x00000006 0x0000003d
+					       0x00000007 0x00000044
+					       0x00000008 0x0000004c
+					       0x00000009 0x00000053
+					       0x0000000a 0x0000005b
+					       0x0000000b 0x00000064
+
+					       0x00010000 0x00000011
+					       0x00010001 0x0000001c
+					       0x00010002 0x00000024
+					       0x00010003 0x0000002b
+					       0x00010004 0x00000034
+					       0x00010005 0x00000039
+					       0x00010006 0x00000042
+					       0x00010007 0x0000004c
+					       0x00010008 0x00000051
+					       0x00010009 0x0000005a
+					       0x0001000a 0x00000063
+
+					       0x00020000 0x00000013
+					       0x00020001 0x00000019
+					       0x00020002 0x00000024
+					       0x00020003 0x0000002c
+					       0x00020004 0x00000035
+					       0x00020005 0x0000003d
+					       0x00020006 0x00000046
+					       0x00020007 0x00000050
+					       0x00020008 0x00000059
+
+					       0x00030000 0x00000002
+					       0x00030001 0x0000000d
+					       0x00030002 0x00000019
+					       0x00030003 0x00000024>;
+			#thermal-sensor-cells = <1>;
+		};
+
+		thermal-zones {
+			cpu_thermal: cpu-thermal {
+				polling-delay-passive = <1000>;
+				polling-delay = <5000>;
+
+				thermal-sensors = <&tmu 0>;
+
+				trips {
+					cpu_alert: cpu-alert {
+						temperature = <85000>;
+						hysteresis = <2000>;
+						type = "passive";
+					};
+					cpu_crit: cpu-crit {
+						temperature = <95000>;
+						hysteresis = <2000>;
+						type = "critical";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&cpu_alert>;
+						cooling-device =
+							<&cpu0 THERMAL_NO_LIMIT
+							THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
+
 		dspi0: dspi at 2100000 {
 			compatible = "fsl,ls1021a-v1.0-dspi";
 			#address-cells = <1>;
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH V2 2/5] powerpc/mpc85xx: Update TMU device tree node for T1023/T1024
From: Jia Hongtao @ 2016-10-09  6:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475995626-14049-1-git-send-email-hongtao.jia@nxp.com>

From: Hongtao Jia <hongtao.jia@nxp.com>

SoC compatible string and endianness property are added according to the
new bindings.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 6e0b489..bce762a 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -321,7 +321,7 @@
 				       0x00030001 0x0000000d
 				       0x00030002 0x00000019
 				       0x00030003 0x00000024>;
-		#thermal-sensor-cells = <0>;
+		#thermal-sensor-cells = <1>;
 	};
 
 	thermal-zones {
@@ -329,7 +329,7 @@
 			polling-delay-passive = <1000>;
 			polling-delay = <5000>;
 
-			thermal-sensors = <&tmu>;
+			thermal-sensors = <&tmu 0>;
 
 			trips {
 				cpu_alert: cpu-alert {
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH V2 1/5] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042
From: Jia Hongtao @ 2016-10-09  6:47 UTC (permalink / raw)
  To: linux-arm-kernel

From: Hongtao Jia <hongtao.jia@nxp.com>

SoC compatible string and endianness property are added according to the
new bindings.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 44e399b..145c7f4 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -526,7 +526,7 @@
 
 				       0x00030000 0x00000012
 				       0x00030001 0x0000001d>;
-		#thermal-sensor-cells = <0>;
+		#thermal-sensor-cells = <1>;
 	};
 
 	thermal-zones {
@@ -534,7 +534,7 @@
 			polling-delay-passive = <1000>;
 			polling-delay = <5000>;
 
-			thermal-sensors = <&tmu>;
+			thermal-sensors = <&tmu 2>;
 
 			trips {
 				cpu_alert: cpu-alert {
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH v2 4/4] ARM: sunxi: enable battery on reference design tablets
From: Icenowy Zheng @ 2016-10-09  6:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161009062714.5085-1-icenowy@aosc.xyz>

Since battery is one part of the reference design of Allwinner tablets,
enable the battery node of reference design tablets.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes since v1:
- Applied to reference design tablet, not Q8 only now.
- Add support for sun5i reference design tablet.

 arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi | 4 ++++
 arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
index 20cc940..9e17b46 100644
--- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
@@ -92,6 +92,10 @@
 
 #include "axp209.dtsi"
 
+&battery {
+	status = "okay";
+};
+
 &lradc {
 	vref-supply = <&reg_ldo2>;
 };
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 9d90361..74517ab 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -112,6 +112,10 @@
 
 #include "axp22x.dtsi"
 
+&battery {
+	status = "okay";
+};
+
 &reg_aldo1 {
 	regulator-always-on;
 	regulator-min-microvolt = <3000000>;
-- 
2.10.0

^ permalink raw reply related

* [PATCH v2 3/4] ARM: dts: add battery node for axp20x/axp22x dtsi
From: Icenowy Zheng @ 2016-10-09  6:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161009062714.5085-1-icenowy@aosc.xyz>

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes since v1:
- Add support for AXP20x.

 arch/arm/boot/dts/axp209.dtsi | 5 +++++
 arch/arm/boot/dts/axp22x.dtsi | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index afbe89c..1602987 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -91,6 +91,11 @@
 		};
 	};
 
+	battery: battery {
+		compatible = "x-powers,axp202-battery";
+		status = "disabled";
+	};
+
 	usb_power_supply: usb_power_supply {
 		compatible = "x-powers,axp202-usb-power-supply";
 		status = "disabled";
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 458b668..a09ba3f 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -148,6 +148,11 @@
 		};
 	};
 
+	battery: battery {
+		compatible = "x-powers,axp221-battery";
+		status = "disabled";
+	};
+
 	usb_power_supply: usb_power_supply {
 		compatible = "x-powers,axp221-usb-power-supply";
 		status = "disabled";
-- 
2.10.0

^ permalink raw reply related

* [PATCH v2 2/4] power: add axp20x-battery driver
From: Icenowy Zheng @ 2016-10-09  6:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161009062714.5085-1-icenowy@aosc.xyz>

This driver is the battery power supply driver of axp20x PMIC.

This driver currently contains only capacity and current properties (for
axp20x only capacity is supported now) , however it's easy to implement more
properties.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes since v1:
- Add initial support for AXP20x.

 drivers/mfd/axp20x.c                  |  28 ++++
 drivers/power/supply/Makefile         |   1 +
 drivers/power/supply/axp20x_battery.c | 277 ++++++++++++++++++++++++++++++++++
 3 files changed, 306 insertions(+)
 create mode 100644 drivers/power/supply/axp20x_battery.c

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 17877b2..ebccb22 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -141,6 +141,15 @@ static struct resource axp20x_ac_power_supply_resources[] = {
 	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
 };
 
+static struct resource axp20x_battery_resources[] = {
+	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_BATT_PLUGIN, "BATT_PLUGIN"),
+	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_BATT_REMOVAL, "BATT_REMOVAL"),
+	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_BATT_ENT_ACT_MODE, "BATT_ENT_ACT_MODE"),
+	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_BATT_EXIT_ACT_MODE, "BATT_EXIT_ACT_MODE"),
+	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_CHARG, "CHARG"),
+	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_CHARG_DONE, "CHARG_DONE"),
+};
+
 static struct resource axp20x_pek_resources[] = {
 	{
 		.name	= "PEK_DBR",
@@ -162,6 +171,15 @@ static struct resource axp20x_usb_power_supply_resources[] = {
 	DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_NOT_VALID, "VBUS_NOT_VALID"),
 };
 
+static struct resource axp22x_battery_resources[] = {
+	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_PLUGIN, "BATT_PLUGIN"),
+	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_REMOVAL, "BATT_REMOVAL"),
+	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_ENT_ACT_MODE, "BATT_ENT_ACT_MODE"),
+	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_BATT_EXIT_ACT_MODE, "BATT_EXIT_ACT_MODE"),
+	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG, "CHARG"),
+	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_CHARG_DONE, "CHARG_DONE"),
+};
+
 static struct resource axp22x_usb_power_supply_resources[] = {
 	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_PLUGIN, "VBUS_PLUGIN"),
 	DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
@@ -520,6 +538,11 @@ static struct mfd_cell axp20x_cells[] = {
 		.num_resources	= ARRAY_SIZE(axp20x_ac_power_supply_resources),
 		.resources	= axp20x_ac_power_supply_resources,
 	}, {
+		.name		= "axp20x-battery",
+		.of_compatible	= "x-powers,axp202-battery",
+		.num_resources	= ARRAY_SIZE(axp20x_battery_resources),
+		.resources	= axp20x_battery_resources,
+	}, {
 		.name		= "axp20x-usb-power-supply",
 		.of_compatible	= "x-powers,axp202-usb-power-supply",
 		.num_resources	= ARRAY_SIZE(axp20x_usb_power_supply_resources),
@@ -535,6 +558,11 @@ static struct mfd_cell axp22x_cells[] = {
 	}, {
 		.name			= "axp20x-regulator",
 	}, {
+		.name		= "axp20x-battery",
+		.of_compatible	= "x-powers,axp221-battery",
+		.num_resources	= ARRAY_SIZE(axp22x_battery_resources),
+		.resources	= axp22x_battery_resources,
+	}, {
 		.name		= "axp20x-usb-power-supply",
 		.of_compatible	= "x-powers,axp221-usb-power-supply",
 		.num_resources	= ARRAY_SIZE(axp22x_usb_power_supply_resources),
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 36c599d..01271d3 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY)	+= generic-adc-battery.o
 
 obj-$(CONFIG_PDA_POWER)		+= pda_power.o
 obj-$(CONFIG_APM_POWER)		+= apm_power.o
+obj-$(CONFIG_AXP20X_POWER)	+= axp20x_battery.o
 obj-$(CONFIG_AXP20X_POWER)	+= axp20x_usb_power.o
 obj-$(CONFIG_MAX8925_POWER)	+= max8925_power.o
 obj-$(CONFIG_WM831X_BACKUP)	+= wm831x_backup.o
diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
new file mode 100644
index 0000000..67ee58f
--- /dev/null
+++ b/drivers/power/supply/axp20x_battery.c
@@ -0,0 +1,277 @@
+/*
+ * AXP20x PMIC battery status driver
+ *
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ * Copyright (C) 2015 Hans de Goede <hdegoede@redhat.com>
+ * Copyright (C) 2014 Bruno Pr?mont <bonbons@linux-vserver.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define DRVNAME "axp20x-battery"
+
+#define AXP20X_PWR_STATUS_ACIN_USED BIT(6)
+#define AXP20X_PWR_STATUS_VBUS_USED BIT(4)
+#define AXP20X_PWR_STATUS_BAT_DIRECTION BIT(2)
+
+#define AXP20X_OP_MODE_CHARGING BIT(6)
+#define AXP20X_OP_MODE_BATTERY_PRESENT BIT(5)
+#define AXP20X_OP_MODE_BATTERY_ACTIVE BIT(3)
+
+#define AXP20X_CAPACITY_CORRECT BIT(7)
+
+struct axp20x_battery {
+	struct axp20x_dev *axp20x;
+	struct regmap *regmap;
+	struct power_supply *supply;
+};
+
+static irqreturn_t axp20x_battery_irq(int irq, void *devid)
+{
+	struct axp20x_battery *power = devid;
+
+	power_supply_changed(power->supply);
+
+	return IRQ_HANDLED;
+}
+
+static int axp20x_battery_get_property(struct power_supply *psy,
+	enum power_supply_property psp, union power_supply_propval *val)
+{
+	struct axp20x_battery *power = power_supply_get_drvdata(psy);
+	unsigned int input, op_mode, capacity, dh, dl;
+	int ret, ext;
+
+	/* All the properties below need the input-status reg value */
+	ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
+	if (ret)
+		return ret;
+
+	ret = regmap_read(power->regmap, AXP20X_PWR_OP_MODE, &op_mode);
+	if (ret)
+		return ret;
+
+	switch (psp) {
+	case POWER_SUPPLY_PROP_HEALTH:
+		if (!(op_mode & AXP20X_OP_MODE_BATTERY_PRESENT)) {
+			val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
+			break;
+		}
+
+		val->intval = POWER_SUPPLY_HEALTH_GOOD;
+
+		if (op_mode & AXP20X_OP_MODE_BATTERY_ACTIVE) {
+			/* AXP20X is now trying to re-activate the battery */
+			val->intval = POWER_SUPPLY_HEALTH_DEAD;
+			break;
+		}
+		break;
+	case POWER_SUPPLY_PROP_PRESENT:
+		val->intval = !!(op_mode & AXP20X_OP_MODE_BATTERY_PRESENT);
+		break;
+	case POWER_SUPPLY_PROP_CAPACITY:
+		ret = regmap_read(power->regmap, AXP20X_FG_RES, &capacity);
+		if (ret)
+			return ret;
+		if (capacity & AXP20X_CAPACITY_CORRECT)
+			val->intval = capacity & (~AXP20X_CAPACITY_CORRECT);
+		else
+			return -EIO;
+		/* from axp_capchange function of Allwinner 3.4 driver */
+		if (val->intval == 127)
+			val->intval = 100;
+		break;
+	case POWER_SUPPLY_PROP_STATUS:
+		if (!(op_mode & AXP20X_OP_MODE_BATTERY_PRESENT)) {
+			val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+			break;
+		}
+
+		ret = regmap_read(power->regmap, AXP20X_FG_RES, &capacity);
+		if (ret)
+			return ret;
+
+		ext = (input & AXP20X_PWR_STATUS_ACIN_USED) ||
+		      (input & AXP20X_PWR_STATUS_VBUS_USED);
+
+		if (op_mode & AXP20X_OP_MODE_CHARGING)
+			val->intval = POWER_SUPPLY_STATUS_CHARGING;
+		else if (!(input & AXP20X_PWR_STATUS_BAT_DIRECTION) && !ext)
+			val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+		else if (capacity == (100 | AXP20X_CAPACITY_CORRECT) ||
+			 capacity == (127 | AXP20X_CAPACITY_CORRECT))
+			val->intval = POWER_SUPPLY_STATUS_FULL;
+		else
+			val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+		break;
+	case POWER_SUPPLY_PROP_CURRENT_NOW:
+		ret = regmap_read(power->regmap, AXP20X_BATT_DISCHRG_I_H, &dh);
+		if (ret)
+			return ret;
+		ret = regmap_read(power->regmap, AXP20X_BATT_DISCHRG_I_L, &dl);
+		if (ret)
+			return ret;
+		/* it's a 12 bit integer, high 8-bit is stored in dh */
+		val->intval = dh << 4 | dl >> 4;
+		break;
+	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+		ret = regmap_read(power->regmap, AXP20X_BATT_V_H, &dh);
+		if (ret)
+			return ret;
+		ret = regmap_read(power->regmap, AXP20X_BATT_V_L, &dl);
+		if (ret)
+			return ret;
+		/* it's a 12 bit integer, high 8-bit is stored in dh */
+		val->intval = dh << 4 | dl >> 4;
+		/* The formula below is from axp22_vbat_to_mV function
+		 * of Allwinner 3.4 kernel.
+		 */
+		val->intval = val->intval * 1100 / 1000;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static enum power_supply_property axp20x_battery_properties[] = {
+	POWER_SUPPLY_PROP_CAPACITY,
+	POWER_SUPPLY_PROP_HEALTH,
+	POWER_SUPPLY_PROP_PRESENT,
+	POWER_SUPPLY_PROP_STATUS,
+};
+
+static const struct power_supply_desc axp20x_battery_desc = {
+	.name = "axp20x-battery",
+	.type = POWER_SUPPLY_TYPE_BATTERY,
+	.properties = axp20x_battery_properties,
+	.num_properties = ARRAY_SIZE(axp20x_battery_properties),
+	.get_property = axp20x_battery_get_property,
+};
+
+static enum power_supply_property axp22x_battery_properties[] = {
+	POWER_SUPPLY_PROP_CAPACITY,
+	POWER_SUPPLY_PROP_HEALTH,
+	POWER_SUPPLY_PROP_PRESENT,
+	POWER_SUPPLY_PROP_STATUS,
+	POWER_SUPPLY_PROP_CURRENT_NOW,
+	POWER_SUPPLY_PROP_VOLTAGE_NOW,
+};
+
+static const struct power_supply_desc axp22x_battery_desc = {
+	.name = "axp20x-battery",
+	.type = POWER_SUPPLY_TYPE_BATTERY,
+	.properties = axp22x_battery_properties,
+	.num_properties = ARRAY_SIZE(axp22x_battery_properties),
+	.get_property = axp20x_battery_get_property,
+};
+
+static int axp20x_battery_probe(struct platform_device *pdev)
+{
+	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+	struct power_supply_config psy_cfg = {};
+	struct axp20x_battery *power;
+	static const char * const axp20x_irq_names[] = {
+		"BATT_PLUGIN", "BATT_REMOVAL", "BATT_ENT_ACT_MODE",
+		"BATT_EXIT_ACT_MODE", "CHARG", "CHARG_DONE", NULL };
+	static const char * const axp22x_irq_names[] = {
+		"BATT_PLUGIN", "BATT_REMOVAL", "BATT_ENT_ACT_MODE",
+		"BATT_EXIT_ACT_MODE", "CHARG", "CHARG_DONE", NULL };
+	static const char * const *irq_names;
+	const struct power_supply_desc *battery_desc;
+	int i, irq, ret;
+
+	if (!of_device_is_available(pdev->dev.of_node))
+		return -ENODEV;
+
+	if (!axp20x) {
+		dev_err(&pdev->dev, "Parent drvdata not set\n");
+		return -EINVAL;
+	}
+
+	power = devm_kzalloc(&pdev->dev, sizeof(*power), GFP_KERNEL);
+	if (!power)
+		return -ENOMEM;
+
+	power->axp20x = axp20x;
+	power->regmap = axp20x->regmap;
+
+	switch (power->axp20x->variant) {
+	case AXP202_ID:
+	case AXP209_ID:
+		battery_desc = &axp20x_battery_desc;
+		irq_names = axp20x_irq_names;
+		break;
+	case AXP221_ID:
+	case AXP223_ID:
+		battery_desc = &axp22x_battery_desc;
+		irq_names = axp22x_irq_names;
+		break;
+	default:
+		dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
+			axp20x->variant);
+		return -EINVAL;
+	}
+
+	psy_cfg.of_node = pdev->dev.of_node;
+	psy_cfg.drv_data = power;
+
+	power->supply = devm_power_supply_register(&pdev->dev, battery_desc,
+						   &psy_cfg);
+	if (IS_ERR(power->supply))
+		return PTR_ERR(power->supply);
+
+	/* Request irqs after registering, as irqs may trigger immediately */
+	for (i = 0; irq_names[i]; i++) {
+		irq = platform_get_irq_byname(pdev, irq_names[i]);
+		if (irq < 0) {
+			dev_warn(&pdev->dev, "No IRQ for %s: %d\n",
+				 irq_names[i], irq);
+			continue;
+		}
+		irq = regmap_irq_get_virq(axp20x->regmap_irqc, irq);
+		ret = devm_request_any_context_irq(&pdev->dev, irq,
+				axp20x_battery_irq, 0, DRVNAME, power);
+		if (ret < 0)
+			dev_warn(&pdev->dev, "Error requesting %s IRQ: %d\n",
+				 irq_names[i], ret);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id axp20x_battery_match[] = {
+	{ .compatible = "x-powers,axp202-battery" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, axp20x_battery_match);
+
+static struct platform_driver axp20x_battery_driver = {
+	.probe = axp20x_battery_probe,
+	.driver = {
+		.name = DRVNAME,
+		.of_match_table = axp20x_battery_match,
+	},
+};
+
+module_platform_driver(axp20x_battery_driver);
+
+MODULE_AUTHOR("Icenowy Zheng <icenowy@aosc.xyz>");
+MODULE_DESCRIPTION("AXP20x PMIC battery status driver");
+MODULE_LICENSE("GPL");
-- 
2.10.0

^ permalink raw reply related

* [PATCH v2 1/4] mfd: axp20x: add adc volatile ranges for axp22x
From: Icenowy Zheng @ 2016-10-09  6:27 UTC (permalink / raw)
  To: linux-arm-kernel

AXP22x has also some different register map than axp20x, they're also
added here.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes since v1:
- Nothing.

 drivers/mfd/axp20x.c       | 1 +
 include/linux/mfd/axp20x.h | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index fd80b09..17877b2 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -97,6 +97,7 @@ static const struct regmap_range axp22x_volatile_ranges[] = {
 	regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
 	regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
 	regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
+	regmap_reg_range(AXP22X_PMIC_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
 	regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
 };
 
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 0be4982..ad3d9c7 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -201,6 +201,10 @@ enum {
 #define AXP20X_OCV_MAX			0xf
 
 /* AXP22X specific registers */
+#define AXP22X_PMIC_ADC_H		0x56
+#define AXP22X_PMIC_ADC_L		0x57
+#define AXP22X_TS_ADC_H			0x58
+#define AXP22X_TS_ADC_L			0x59
 #define AXP22X_BATLOW_THRES1		0xe6
 
 /* AXP288 specific registers */
-- 
2.10.0

^ permalink raw reply related

* [PATCH 5/9] mtd: nand: Expose data interface for ONFI mode 0
From: Brian Norris @ 2016-10-09  5:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160915145625.15e81012@bbrezillon>

On Thu, Sep 15, 2016 at 02:56:25PM +0200, Boris Brezillon wrote:
> On Thu, 15 Sep 2016 10:32:49 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > The nand layer will need ONFI mode 0 to use it as timing mode
> > before and right after reset.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> >  drivers/mtd/nand/nand_timings.c | 11 +++++++++++
> >  include/linux/mtd/nand.h        |  2 ++
> >  2 files changed, 13 insertions(+)
> > 
> > diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c
> > index 608d098..9cdbc16 100644
> > --- a/drivers/mtd/nand/nand_timings.c
> > +++ b/drivers/mtd/nand/nand_timings.c
> > @@ -297,3 +297,14 @@ int onfi_init_data_interface(struct nand_chip *chip,
> >  
> >  	return 0;
> >  }
> > +
> > +/**
> > + * nand_get_default_data_interface - [NAND Interface] Retrieve NAND
> > + * data interface for mode 0. This is used as default timing after
> > + * reset.
> > + */
> > +const struct nand_data_interface *nand_get_default_data_interface(void)
> > +{
> > +	return &onfi_sdr_timings[0];
> > +}
> > +EXPORT_SYMBOL(nand_get_default_data_interface);
> 
> You export nand_get_default_data_interface() here, but you don't export
> onfi_init_data_interface().
> None of these functions should be called from NAND controller drivers,
> so they don't need to be exported. ITOH, the prototypes are public
> (defined in nand.h), so nothing prevents a driver from calling these
> functions.

A bit late, but we can still change things for the next cycle of
course...

> I don't know what's the best solution here:
> 1/ Export both nand_get_default_data_interface() and
>    onfi_init_data_interface()

I don't really like this one. We shouldn't export them if we don't want
people to use them in modules. And I'm sure the various compile-test
builders out there would complain eventually if someone did.

> 2/ Do not export them, but keep their prototypes in nand.h with a
>    comment saying that they should not be directly called by NAND
>    controller drivers

Could be OK.

> 3/ Removing the prototypes from nand.h and defining them in nand_base.c
>    (or in a private header).

I like this one. Why not add a drivers/mtd/nand/nand.h that's intended
for the nand.{o,ko} module only?

> Brian, Richard, Sascha, any comments?

Brian

^ permalink raw reply

* [PATCH] MAINTAINERS: Add ARM64-specific ACPI maintainers entry
From: Hanjun Guo @ 2016-10-09  3:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161005112540.22189-1-lorenzo.pieralisi@arm.com>

On 10/05/2016 07:25 PM, Lorenzo Pieralisi wrote:
> The ARM64 architecture defines ARM64 specific ACPI bindings to
> configure and set-up arch specific components. To simplify
> code reviews/updates and streamline the maintainership structure
> supporting the arch specific code, a new arm64 directory was created in
> /drivers/acpi, to contain ACPI code that is specific to ARM64
> architecture.
>
> Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
> the newly created subdirectory and respective code content.
>
> Lorenzo Pieralisi will be in charge of submitting and managing
> the pull requests on behalf of all maintainers listed.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Link: http://lkml.kernel.org/r/1603704.EGiVTcCxLR at vostro.rjw.lan

Acked-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks
Hanjun

^ permalink raw reply

* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Joel Fernandes @ 2016-10-09  3:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160929081818.GE28107@nuc-i3427.alporthouse.com>

On Thu, Sep 29, 2016 at 1:18 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
>> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
>> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
>> awfully bad for STB. And the ftrace log also shows __free_vmap_area
>> contributes most latency now. I noticed that Joel mentioned the same
>> issue[1] on x86 platform and gave two solutions, but it seems no patch
>> is sent out for this purpose.
>>
>> This patch adopts Joel's first solution, but I use 16MB per core
>> rather than 8MB per core for the number of lazy_max_pages. After this
>> patch, the preemptoff tracer reports a max 6455us latency, reduced to
>> 1/4 of original result.
>
> My understanding is that
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 91f44e78c516..3f7c6d6969ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
>  static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>                                         int sync, int force_flush)
>  {
> -       static DEFINE_SPINLOCK(purge_lock);
>         struct llist_node *valist;
>         struct vmap_area *va;
>         struct vmap_area *n_va;
> @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>          * should not expect such behaviour. This just simplifies locking for
>          * the case that isn't actually used at the moment anyway.
>          */
> -       if (!sync && !force_flush) {
> -               if (!spin_trylock(&purge_lock))
> -                       return;
> -       } else
> -               spin_lock(&purge_lock);
> -
>         if (sync)
>                 purge_fragmented_blocks_allcpus();
>
> @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>                         __free_vmap_area(va);
>                 spin_unlock(&vmap_area_lock);
>         }
> -       spin_unlock(&purge_lock);
>  }
>
[..]
> should now be safe. That should significantly reduce the preempt-disabled
> section, I think.

I believe that the purge_lock is supposed to prevent concurrent purges
from happening.

For the case where if you have another concurrent overflow happen in
alloc_vmap_area() between the spin_unlock and purge :

spin_unlock(&vmap_area_lock);
if (!purged)
   purge_vmap_area_lazy();

Then the 2 purges would happen at the same time and could subtract
vmap_lazy_nr twice.

I had proposed to change it to mutex in [1]. How do you feel about
that? Let me know your suggestions, thanks. I am also Ok with reducing
the lazy_max_pages value.

[1] http://lkml.iu.edu/hypermail/linux/kernel/1603.2/04803.html

Regards,
Joel

^ permalink raw reply

* [PATCH v6 3/3] pci:add support aer/pme interrupts with none MSI/MSI-X/INTx mode
From: Po Liu @ 2016-10-09  2:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161008204959.GA17455@rob-hp-laptop>

Hi Rob,

Best regards,
Liu Po

>  -----Original Message-----
>  From: Rob Herring [mailto:robh at kernel.org]
>  Sent: Sunday, October 09, 2016 4:50 AM
>  To: Po Liu
>  Cc: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>  linux-kernel at vger.kernel.org; devicetree at vger.kernel.org; Bjorn Helgaas;
>  Shawn Guo; Marc Zyngier; Roy Zang; Mingkai Hu; Stuart Yoder; Leo Li;
>  Arnd Bergmann; M.H. Lian; Murali Karicheri
>  Subject: Re: [PATCH v6 3/3] pci:add support aer/pme interrupts with none
>  MSI/MSI-X/INTx mode
>  
>  On Fri, Sep 30, 2016 at 05:11:37PM +0800, Po Liu wrote:
>  > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
>  > When chip support the aer/pme interrupts with none MSI/MSI-X/INTx
>  > mode, maybe there is interrupt line for aer pme etc. Search the
>  > interrupt number in the fdt file. Then fixup the dev->irq with it.
>  
>  Again, explain why you are breaking compatibility. Will an old dtb using
>  "intr" still work with this change? It should normally. There are some
>  exceptions, but you need to say what they are.
>  
Ok, understand.

>  >
>  > Signed-off-by: Po Liu <po.liu@nxp.com>
>  > ---
>  > changes for v6:
>  > 	- modify bindings for "aer""pme";
>  > 	- changing to the hood method to implement the aer pme interrupt;
>  > 	- add pme interrupt in the same way;
>  >
>  >  .../devicetree/bindings/pci/layerscape-pci.txt     | 13 +++++--
>  >  arch/arm/kernel/bios32.c                           | 43
>  ++++++++++++++++++++++
>  >  arch/arm64/kernel/pci.c                            | 43
>  ++++++++++++++++++++++
>  >  drivers/pci/pcie/portdrv_core.c                    | 31
>  +++++++++++++++-
>  >  include/linux/pci.h                                |  1 +
>  >  5 files changed, 126 insertions(+), 5 deletions(-)
>  >
>  > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > index 41e9f55..51ed49e 100644
>  > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > @@ -18,8 +18,12 @@ Required properties:
>  >  - reg: base addresses and lengths of the PCIe controller
>  >  - interrupts: A list of interrupt outputs of the controller. Must
>  contain an
>  >    entry for each entry in the interrupt-names property.
>  > -- interrupt-names: Must include the following entries:
>  > -  "intr": The interrupt that is asserted for controller interrupts
>  > +- interrupt-names: It could include the following entries:
>  
>  "Could" is not strong enough. Every valid combination of interrupts
>  should correspond to a specific compatible string. A given version of
>  h/w either has these interrupts or not.

Ok, will change to 'must'.

>  
>  > +  "aer": Asserted for aer interrupt when chip support the aer
>  interrupt with
>  > +		 none MSI/MSI-X/INTx mode,but there is interrupt line for
>  aer.
>  > +  "pme": Asserted for pme interrupt when chip support the pme
>  interrupt with
>  > +		 none MSI/MSI-X/INTx mode,but there is interrupt line for
>  pme.
>  > +  ......
>  >  - fsl,pcie-scfg: Must include two entries.
>  >    The first entry must be a link to the SCFG device node
>  >    The second entry must be '0' or '1' based on physical PCIe
>  controller index.

^ permalink raw reply

* [PATCH v2 2/2] ls1043ardb: add ds26522 node to dts
From: Zhao Qiang @ 2016-10-09  2:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475979159-20597-1-git-send-email-qiang.zhao@nxp.com>

add ds26522 node to fsl-ls1043a-rdb.dts

Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
Changes for v2:
	- na

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index a6a39fc..7f93bcc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -122,6 +122,22 @@
 		reg = <0>;
 		spi-max-frequency = <1000000>; /* input clock */
 	};
+
+	slic at 2 {
+		compatible = "maxim,ds26522";
+		reg = <2>;
+		spi-max-frequency = <2000000>;
+		fsl,spi-cs-sck-delay = <100>;
+		fsl,spi-sck-cs-delay = <50>;
+	};
+
+	slic at 3 {
+		compatible = "maxim,ds26522";
+		reg = <3>;
+		spi-max-frequency = <2000000>;
+		fsl,spi-cs-sck-delay = <100>;
+		fsl,spi-sck-cs-delay = <50>;
+	};
 };
 
 &uqe {
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH v2 1/2] ls1043ardb: add qe node to ls1043ardb
From: Zhao Qiang @ 2016-10-09  2:12 UTC (permalink / raw)
  To: linux-arm-kernel

Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
---
Changes for v2:
	- use "fsl,ucc-hdlc" directly

 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 16 ++++++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi    | 66 +++++++++++++++++++++++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
index 4084631..a6a39fc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -124,6 +124,22 @@
 	};
 };
 
+&uqe {
+	ucc_hdlc: ucc at 2000 {
+		compatible = "fsl,ucc-hdlc";
+		rx-clock-name = "clk8";
+		tx-clock-name = "clk9";
+		fsl,rx-sync-clock = "rsync_pin";
+		fsl,tx-sync-clock = "tsync_pin";
+		fsl,tx-timeslot-mask = <0xfffffffe>;
+		fsl,rx-timeslot-mask = <0xfffffffe>;
+		fsl,tdm-framer-type = "e1";
+		fsl,tdm-id = <0>;
+		fsl,siram-entry-id = <0>;
+		fsl,tdm-interface;
+	};
+};
+
 &duart0 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..f6b6775 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -388,6 +388,72 @@
 			#interrupt-cells = <2>;
 		};
 
+		uqe: uqe at 2400000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			device_type = "qe";
+			compatible = "fsl,qe", "simple-bus";
+			ranges = <0x0 0x0 0x2400000 0x40000>;
+			reg = <0x0 0x2400000 0x0 0x480>;
+			brg-frequency = <100000000>;
+			bus-frequency = <200000000>;
+
+			fsl,qe-num-riscs = <1>;
+			fsl,qe-num-snums = <28>;
+
+			qeic: qeic at 80 {
+				compatible = "fsl,qe-ic";
+				reg = <0x80 0x80>;
+				#address-cells = <0>;
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				interrupts = <0 77 0x04 0 77 0x04>;
+			};
+
+			si1: si at 700 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "fsl,ls1043-qe-si",
+						"fsl,t1040-qe-si";
+				reg = <0x700 0x80>;
+			};
+
+			siram1: siram at 1000 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "fsl,ls1043-qe-siram",
+						"fsl,t1040-qe-siram";
+				reg = <0x1000 0x800>;
+			};
+
+			ucc at 2000 {
+				cell-index = <1>;
+				reg = <0x2000 0x200>;
+				interrupts = <32>;
+				interrupt-parent = <&qeic>;
+			};
+
+			ucc at 2200 {
+				cell-index = <3>;
+				reg = <0x2200 0x200>;
+				interrupts = <34>;
+				interrupt-parent = <&qeic>;
+			};
+
+			muram at 10000 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "fsl,qe-muram", "fsl,cpm-muram";
+				ranges = <0x0 0x10000 0x6000>;
+
+				data-only at 0 {
+					compatible = "fsl,qe-muram-data",
+					"fsl,cpm-muram-data";
+					reg = <0x0 0x6000>;
+				};
+			};
+		};
+
 		lpuart0: serial at 2950000 {
 			compatible = "fsl,ls1021a-lpuart";
 			reg = <0x0 0x2950000 0x0 0x1000>;
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [RFC 05/10] dt-bindings: pinctrl: meson: update gpio dt-bindings
From: Rob Herring @ 2016-10-09  1:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475593708-10526-6-git-send-email-jbrunet@baylibre.com>

On Tue, Oct 04, 2016 at 05:08:23PM +0200, Jerome Brunet wrote:
> Add description for the interrupt-parent property of the gpio sub-node
> If provided here, this property must be a phandle to an interrupt
> controller suitable for meson pinctrl, like the meson gpio interrupt
> controller.
> 
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
>  Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 4 ++++
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply


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