Re: [PATCH v2 15/25] cris: nand: use the mtd instance embedded in struct nand_chip

2015-12-08 Thread Jesper Nilsson 
On Tue, Dec 01, 2015 at 12:03:12PM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

2015-12-08 Thread Arnd Bergmann 
On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
> On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> >>
> >> Please just drop the /bits/ 16 and use normal cells.
> > 
> > Yeah agreed, makes things less confusing for sure 
> 
> 4.4 will be the first kernel where we will have the new eDMA bindings. I have
> chosen to use 16bit array for specifying the channels used for memcpy
> (ti,edma-memcpy-channels) and for the reserving paRAM slots
> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels and
> 512 paRAM slots. 16bit is more than enough to store this information and it
> even gives us enough room if ever in the future these numbers are going to
> increase (which  they are not).
> 
> But in order to change them to 32bit the driver needs to be changed as well.
> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is not
> yet out, so it might be possible to change the binding document and the driver
> to use 32bit arrays. The driver internally uses 16bit type for these which I'm
> not going to change, but the code parsing the DT needs to be adjusted for the
> new data type.
> 
> If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I
> can cook up the patch(es) to do so.

I hadn't realized that it was already in 4.4-rc. The change should be trivial
enough though, so I'd still do it. If Vinod would rather not change it now,
it's not overly important though.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

2015-12-08 Thread Lucas Stach 
Hi Bjorn,

Am Montag, den 07.12.2015, 21:33 -0600 schrieb Bjorn Helgaas:
> [+cc Jingoo (exynos), Richard, Lucas (imx6), Pratyush (spear13xx)]
> 
> On Fri, Dec 04, 2015 at 11:22:50PM +0200, Grygorii Strashko wrote:
> > On 12/04/2015 08:46 PM, Bjorn Helgaas wrote:
> > > Hi Grygorii,
[...]
> > >>   
> > >> +/*
> > >> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
> > >> + * On -RT and if kernel is booting with "threadirqs" cmd line 
> > >> parameter
> > >> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded 
> > >> but,
> > >> + * in the same time, it's IRQ dispatcher and calls 
> > >> generic_handle_irq(),
> > >> + * which, in turn, will be resolved to handle_simple_irq() call.
> > >> + * The handle_simple_irq() expected to be called with IRQ 
> > >> disabled, as
> > >> + * result kernle will display warning:
> > >> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
> > >> + */
> > >>  ret = devm_request_irq(>dev, pp->irq,
> > >> -   dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
> > >> +   dra7xx_pcie_msi_irq_handler,
> > >> +   IRQF_SHARED | IRQF_NO_THREAD,
> > >> "dra7-pcie-msi", pp);
> > > 
> > > There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
> > > and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
> > > why not?
> > > 
> > > I see your discussion about DRA7 hardware design, but my impression is
> > > that this problem affects anybody who calls dw_handle_msi_irq() from a
> > > handler registered with IRQF_SHARED.
> > 
> > Issue fixed by this patch is not related to IRQF_SHARED. 
> > It will happen on -RT or if kernel will boot with "threadirqs" cmd line 
> > parameter
> > - in both cases these PCI IRQ handlers will be forced to be threaded and,
> > as result, generic_handle_irq() will produce above backtrace.
> > 
> > Personally, I don't have strong opinion about "should similar change be 
> > applied
> > to other PCI drivers or not?" And I think, that owners of those driver 
> > should
> > make such decision.
> 
> If the same issue affects several drivers, I'd like to see them all
> handle it the same way.  Otherwise, somebody coming along later will
> wonder why they're different, and there won't be a good answer.
> 
> I cc'd the other maintainers to see what they think.
> 
Yes, this should absolutely be changed in all drivers, based on the DW
core. There were some patches for this already, but apparently they have
not been applied, because some review feedback wasn't taken care of.

I have a patch titled "PCI: designware: Mark the msi cascade handler
IRQF_NO_THREAD" in my inbox that did this, and I still think it's the
right thing to do.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 18/25] cris: nand: remove useless mtd->priv = chip assignments

2015-12-08 Thread Jesper Nilsson 
On Tue, Dec 01, 2015 at 12:03:15PM +0100, Boris Brezillon wrote:
> mtd_to_nand() now uses the container_of() approach to transform an
> mtd_info pointer into a nand_chip one. Drop useless mtd->priv
> assignments from NAND controller drivers.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

2015-12-08 Thread Sebastian Andrzej Siewior 
* Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:

>The backtrace might be OK (maybe slightly overkill), but all the
>stack addresses are certainly irrelevant and distracting.  We only
>need enough to recognize the problem.  I don't think the modules list
>is relevant either.

I would shorten it to the bare minimum. Also the patch description
itself could be truncated to the required bits…

>> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
>> index 8c36880..0415192 100644
>> --- a/drivers/pci/host/pci-dra7xx.c
>> +++ b/drivers/pci/host/pci-dra7xx.c
>> @@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct 
>> dra7xx_pcie *dra7xx,
>>  return -EINVAL;
>>  }
>>  
>> +/*
>> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
>> + * On -RT and if kernel is booting with "threadirqs" cmd line parameter
>> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
>> + * in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
>> + * which, in turn, will be resolved to handle_simple_irq() call.
>> + * The handle_simple_irq() expected to be called with IRQ disabled, as
>> + * result kernle will display warning:
>> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
>> + */

…not to mention this piece. d7ce4377494a ("powerpc/fsl_msi: mark the msi
cascade handler IRQF_NO_THREAD") fixes the same bug in arch/ppc so they
bypassed you fixing it.

>>  ret = devm_request_irq(>dev, pp->irq,
>> -   dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
>> +   dra7xx_pcie_msi_irq_handler,
>> +   IRQF_SHARED | IRQF_NO_THREAD,
>> "dra7-pcie-msi", pp);
>
>There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
>and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
>why not?

You are right. The request for the handler exynos_pcie_msi_irq_handler(),
imx6_pcie_msi_handler() and spear13xx_pcie_irq_handler() needs same
treatment.
Additionally we have:

arch/mips/pci/msi-octeon.c: if (request_irq(OCTEON_IRQ_PCI_MSI0, 
octeon_msi_interrupt0,
arch/sparc/kernel/pci_msi.c:err = request_irq(irq, sparc64_msiq_interrupt, 
0,
drivers/pci/host/pci-tegra.c:   err = request_irq(msi->irq, tegra_pcie_msi_irq, 
0,
drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(>dev, msi->irq1, 
rcar_pcie_msi_irq,
drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(>dev, msi->irq2, 
rcar_pcie_msi_irq,
drivers/pci/host/pcie-xilinx.c: err = devm_request_irq(dev, port->irq, 
xilinx_pcie_intr_handler,

which require the same kind of fix…

>I see your discussion about DRA7 hardware design, but my impression is
>that this problem affects anybody who calls dw_handle_msi_irq() from a
>handler registered with IRQF_SHARED.

… brecause all of them invoke generic_handle_irq() from the requsted
handler. generic_handle_irq grabs raw_locks and this needs to run in
raw-irq context.
IRQF_SHARED could probably go away. The IRQ is mostlikely exclusive
assigned in each SoC for MSI interrupt demux.

>Bjorn

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

2015-12-08 Thread Ulf Hansson 
On 8 December 2015 at 01:32, Tony Lindgren  wrote:
> * Ulf Hansson  [151207 16:20]:
>> +Linus
>>
>> On 7 December 2015 at 23:54, Tony Lindgren  wrote:
>> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array API")
>> > changed the handling MMC power sequence so GPIOs no longer are optional.
>> >
>> > This broke SDIO WLAN at least for omap5 that can't yet use the reset GPIOs
>> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
>>
>> Can you elaborate on this. Did it break omap5 or not? :-)
>
> Yes it broke WLAN for omap5 that I just got fixed.. It only uses the clocks
> art of the pwrseq currently because of the delay needed.
>
>> Also, I am interested to know more about the waiting period you need.
>> I assume that's because of the HW's characteristic?
>
> At least TI wl12xx and Marvell 8787 need a delay after enabling the the WLAN.
>
>> Why can't we have that being described in DT and then make
>> pwrseq_simple *wait* if needed?
>
> We can, but I'm thinking that we might be better off adding support for
> regulators to pwrseq. Both TI wl12xx and Marvell 8787 get power from the
> battery, and probably have an integrated regulator.

Sounds very reasonable! Perhaps some of the delays can be handled
within the context of the regulator then!?

>
> Also, the delay and the power up sequencey can be more complicated than what
> we currently support. In the 8787 case, pdn pin needs to be asserted for 300ms
> after power pins are stable and while reset is held high.

I am for sure open to extend pwrseq_simple, please go ahead!

The initial version provided a proof of concept and the
infrastructure. I expect and want people to extend it to suit their
HWs.

If we at some point find that pwrseq_simple starts to become too
complex, we may add another pwrseq type with a corresponding new
compatible string.

[...]

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] dmaengine: edma: Add support for DMA filter mapping to slave devices

2015-12-08 Thread Peter Ujfalusi 
On 12/03/2015 05:46 PM, Peter Ujfalusi wrote:
> On 12/03/2015 05:38 PM, Arnd Bergmann wrote:
>> On Thursday 03 December 2015 16:33:12 Peter Ujfalusi wrote:
>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>> index 0675e268d577..46b305ea0d21 100644
>>> --- a/drivers/dma/edma.c
>>> +++ b/drivers/dma/edma.c
>>> @@ -2297,6 +2297,12 @@ static int edma_probe(struct platform_device *pdev)
>>> edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
>>> }
>>>  
>>> +   if (info->slave_map) {
>>> +   ecc->dma_slave.filter_map.map = info->slave_map;
>>> +   ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
>>> +   ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
>>> +   }
>>> +
>>>
>>
>> Just a minor comment here: I think all three assignments can be done
>> unconditionally.
> 
> True.
> 
>> As I mentioned before, I'd also remove 'struct dma_filter'
>> and put the three members in struct dma_device directly. In fact, the
>> filter function can go with the other function pointers for consistency.
> 
> I just like to keep things in one place ;)
> I don't have strong stand on keeping the intermediate 'struct dma_filter'
> Let's hear from Vinod regarding to this


One remaining design issue is on how and where to place the filter related
variables/pointers:

Keep it separated as it was in the RFC and v01 series:

struct dma_slave_map {
const char *devname;
const char *slave;
void *param;
};

struct dma_filter {
dma_filter_fn fn;
int mapcnt;
const struct dma_slave_map *map;
};


struct dma_device {
...
struct dma_filter filter;
...
};

Or to have them under the dma_device directly:

struct dma_device {
...
int filter_mapcnt;
const struct dma_slave_map *filter_map;
...
dma_filter_fn filter_fn;
...
};

Vinod: what is your preference for this?

Thanks,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

2015-12-08 Thread Peter Ujfalusi 
On 12/08/2015 11:51 AM, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
>> On 12/04/2015 11:51 PM, Tony Lindgren wrote:

 Please just drop the /bits/ 16 and use normal cells.
>>>
>>> Yeah agreed, makes things less confusing for sure 
>>
>> 4.4 will be the first kernel where we will have the new eDMA bindings. I have
>> chosen to use 16bit array for specifying the channels used for memcpy
>> (ti,edma-memcpy-channels) and for the reserving paRAM slots
>> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels and
>> 512 paRAM slots. 16bit is more than enough to store this information and it
>> even gives us enough room if ever in the future these numbers are going to
>> increase (which  they are not).
>>
>> But in order to change them to 32bit the driver needs to be changed as well.
>> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is not
>> yet out, so it might be possible to change the binding document and the 
>> driver
>> to use 32bit arrays. The driver internally uses 16bit type for these which 
>> I'm
>> not going to change, but the code parsing the DT needs to be adjusted for the
>> new data type.
>>
>> If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I
>> can cook up the patch(es) to do so.
> 
> I hadn't realized that it was already in 4.4-rc. The change should be trivial
> enough though, so I'd still do it. If Vinod would rather not change it now,
> it's not overly important though.

But this change must be done before we have actual users of these properties,
which is the am33xx, am437x and the da850 conversion series I have sent 
recently.
We might want to have this changed for 4.4 since it is going to be an LTS
release...

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

2015-12-08 Thread Arnd Bergmann 
On Tuesday 08 December 2015 12:22:09 Peter Ujfalusi wrote:
> On 12/08/2015 11:51 AM, Arnd Bergmann wrote:
> > On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
> >> On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> 
>  Please just drop the /bits/ 16 and use normal cells.
> >>>
> >>> Yeah agreed, makes things less confusing for sure 
> >>
> >> 4.4 will be the first kernel where we will have the new eDMA bindings. I 
> >> have
> >> chosen to use 16bit array for specifying the channels used for memcpy
> >> (ti,edma-memcpy-channels) and for the reserving paRAM slots
> >> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels 
> >> and
> >> 512 paRAM slots. 16bit is more than enough to store this information and it
> >> even gives us enough room if ever in the future these numbers are going to
> >> increase (which  they are not).
> >>
> >> But in order to change them to 32bit the driver needs to be changed as 
> >> well.
> >> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is 
> >> not
> >> yet out, so it might be possible to change the binding document and the 
> >> driver
> >> to use 32bit arrays. The driver internally uses 16bit type for these which 
> >> I'm
> >> not going to change, but the code parsing the DT needs to be adjusted for 
> >> the
> >> new data type.
> >>
> >> If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I
> >> can cook up the patch(es) to do so.
> > 
> > I hadn't realized that it was already in 4.4-rc. The change should be 
> > trivial
> > enough though, so I'd still do it. If Vinod would rather not change it now,
> > it's not overly important though.
> 
> But this change must be done before we have actual users of these properties,
> which is the am33xx, am437x and the da850 conversion series I have sent 
> recently.
> We might want to have this changed for 4.4 since it is going to be an LTS
> release...

Yes, that's what I meant: We either get the patch into 4.4 by creating a
branch for Vinod to pull with this change, and base all other changes in your
4.5 series on the same branch, or we don't change it at all.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] irqchip: omap-intc: add support for spurious irq handling

2015-12-08 Thread Sekhar Nori 
Under some conditions, irq sorting procedure used
by INTC can go wrong resulting in a spurious irq
getting reported.

If this condition is not handled, it results in
endless stream of:

unexpected IRQ trap at vector 00

messages from ack_bad_irq()

Handle the spurious interrupt condition in omap-intc
driver to prevent this.

Signed-off-by: Sekhar Nori 
---
v2: increment error irq counter, use pr_err_once,
add a comment on tips to debug spurious irq
condition.

This patch results in a checkpatch warning about
extern definition of irq_err_count, but looks like
thats the prevalent method of accessing that counter.

 drivers/irqchip/irq-omap-intc.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 8587d0f8d8c0..639708de5529 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -47,6 +47,7 @@
 #define INTC_ILR0  0x0100
 
 #define ACTIVEIRQ_MASK 0x7f/* omap2/3 active interrupt bits */
+#define SPURIOUSIRQ_MASK   (0x1ff << 7)
 #define INTCPS_NR_ILR_REGS 128
 #define INTCPS_NR_MIR_REGS 4
 
@@ -330,11 +331,35 @@ static int __init omap_init_irq(u32 base, struct 
device_node *node)
 static asmlinkage void __exception_irq_entry
 omap_intc_handle_irq(struct pt_regs *regs)
 {
+   extern unsigned long irq_err_count;
u32 irqnr;
 
irqnr = intc_readl(INTC_SIR);
+
+   /*
+* A spurious IRQ can result if interrupt that triggered the
+* sorting is no longer active during the sorting (10 INTC
+* functional clock cycles after interrupt assertion). Or a
+* change in interrupt mask affected the result during sorting
+* time. There is no special handling required except ignoring
+* the SIR register value just read and retrying.
+* See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
+*
+* Many a times, a spurious interrupt situation has been fixed
+* by adding a flush for the posted write acking the IRQ in
+* the device driver. Typically, this is going be the device
+* driver whose interrupt was handled just before the spurious
+* IRQ occurred. Pay attention to those device drivers if you
+* run into hitting the spurious IRQ condition below.
+*/
+   if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
+   pr_err_once("%s: spurious irq!\n", __func__);
+   irq_err_count++;
+   omap_ack_irq(NULL);
+   return;
+   }
+
irqnr &= ACTIVEIRQ_MASK;
-   WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
handle_domain_irq(domain, irqnr, regs);
 }
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq handling

2015-12-08 Thread Felipe Balbi 

Hi,

Sekhar Nori  writes:
> Under some conditions, irq sorting procedure used
> by INTC can go wrong resulting in a spurious irq
> getting reported.
>
> If this condition is not handled, it results in
> endless stream of:
>
> unexpected IRQ trap at vector 00
>
> messages from ack_bad_irq()
>
> Handle the spurious interrupt condition in omap-intc
> driver to prevent this.
>
> Signed-off-by: Sekhar Nori 
> ---
> v2: increment error irq counter, use pr_err_once,
> add a comment on tips to debug spurious irq
> condition.
>
> This patch results in a checkpatch warning about
> extern definition of irq_err_count, but looks like
> thats the prevalent method of accessing that counter.
>
>  drivers/irqchip/irq-omap-intc.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 8587d0f8d8c0..639708de5529 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -47,6 +47,7 @@
>  #define INTC_ILR00x0100
>  
>  #define ACTIVEIRQ_MASK   0x7f/* omap2/3 active interrupt 
> bits */
> +#define SPURIOUSIRQ_MASK (0x1ff << 7)
>  #define INTCPS_NR_ILR_REGS   128
>  #define INTCPS_NR_MIR_REGS   4
>  
> @@ -330,11 +331,35 @@ static int __init omap_init_irq(u32 base, struct 
> device_node *node)
>  static asmlinkage void __exception_irq_entry
>  omap_intc_handle_irq(struct pt_regs *regs)
>  {
> + extern unsigned long irq_err_count;
>   u32 irqnr;
>  
>   irqnr = intc_readl(INTC_SIR);
> +
> + /*
> +  * A spurious IRQ can result if interrupt that triggered the
> +  * sorting is no longer active during the sorting (10 INTC
> +  * functional clock cycles after interrupt assertion). Or a
> +  * change in interrupt mask affected the result during sorting
> +  * time. There is no special handling required except ignoring
> +  * the SIR register value just read and retrying.
> +  * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
> +  *
> +  * Many a times, a spurious interrupt situation has been fixed
> +  * by adding a flush for the posted write acking the IRQ in
> +  * the device driver. Typically, this is going be the device
> +  * driver whose interrupt was handled just before the spurious
> +  * IRQ occurred. Pay attention to those device drivers if you
> +  * run into hitting the spurious IRQ condition below.
> +  */
> + if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {

sounds like unlikely() wouldn't hurt here.

> + pr_err_once("%s: spurious irq!\n", __func__);
> + irq_err_count++;
> + omap_ack_irq(NULL);
> + return;
> + }
> +
>   irqnr &= ACTIVEIRQ_MASK;
> - WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>   handle_domain_irq(domain, irqnr, regs);

care to run kernel function profiler against omap_intc_handle_irq()
before and after this patch ?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] mtd: omap_elm: print interrupt resource using %pr

2015-12-08 Thread Arnd Bergmann 
When CONFIG_LPAE is set on ARM, resource_size_t is 64-bit wide
and we get a warning about an incorrect format string for printing
the interrupt number in elm_probe:

drivers/mtd/nand/omap_elm.c: In function 'elm_probe':
drivers/mtd/nand/omap_elm.c:417:23: warning: format '%i' expects argument of 
type 'int', but argument 3 has type 'resource_size_t {aka long long unsigned 
int}' [-Wformat=]

This patch avoids the type mismatch by printing the interrupt as
a resource using the %pr format string.

Signed-off-by: Arnd Bergmann 
---
 drivers/mtd/nand/omap_elm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
index 235ec7992b4c..11f174b07217 100644
--- a/drivers/mtd/nand/omap_elm.c
+++ b/drivers/mtd/nand/omap_elm.c
@@ -414,7 +414,7 @@ static int elm_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, irq->start, elm_isr, 0,
pdev->name, info);
if (ret) {
-   dev_err(>dev, "failure requesting irq %i\n", irq->start);
+   dev_err(>dev, "failure requesting %pr\n", );
return ret;
}
 
-- 
2.1.0.rc2


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

2015-12-08 Thread Tony Lindgren 
* Arnd Bergmann  [151208 02:26]:
> On Tuesday 08 December 2015 12:22:09 Peter Ujfalusi wrote:
> > On 12/08/2015 11:51 AM, Arnd Bergmann wrote:
> > > On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
> > >> On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> > 
> >  Please just drop the /bits/ 16 and use normal cells.
> > >>>
> > >>> Yeah agreed, makes things less confusing for sure 
> > >>
> > >> 4.4 will be the first kernel where we will have the new eDMA bindings. I 
> > >> have
> > >> chosen to use 16bit array for specifying the channels used for memcpy
> > >> (ti,edma-memcpy-channels) and for the reserving paRAM slots
> > >> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels 
> > >> and
> > >> 512 paRAM slots. 16bit is more than enough to store this information and 
> > >> it
> > >> even gives us enough room if ever in the future these numbers are going 
> > >> to
> > >> increase (which  they are not).
> > >>
> > >> But in order to change them to 32bit the driver needs to be changed as 
> > >> well.
> > >> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is 
> > >> not
> > >> yet out, so it might be possible to change the binding document and the 
> > >> driver
> > >> to use 32bit arrays. The driver internally uses 16bit type for these 
> > >> which I'm
> > >> not going to change, but the code parsing the DT needs to be adjusted 
> > >> for the
> > >> new data type.
> > >>
> > >> If Vinod is willing to take update for the DT binding of eDMA for 
> > >> 4.4-rc, I
> > >> can cook up the patch(es) to do so.
> > > 
> > > I hadn't realized that it was already in 4.4-rc. The change should be 
> > > trivial
> > > enough though, so I'd still do it. If Vinod would rather not change it 
> > > now,
> > > it's not overly important though.
> > 
> > But this change must be done before we have actual users of these 
> > properties,
> > which is the am33xx, am437x and the da850 conversion series I have sent 
> > recently.
> > We might want to have this changed for 4.4 since it is going to be an LTS
> > release...
> 
> Yes, that's what I meant: We either get the patch into 4.4 by creating a
> branch for Vinod to pull with this change, and base all other changes in your
> 4.5 series on the same branch, or we don't change it at all.

Sounds good to me. If there's an immutable branch against v4.4-rc1 with just
that change in it will make our lives easier.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: BUG: TI CPSW driver hanging up when setting mac-address to early

2015-12-08 Thread Tony Lindgren 
* ker...@iktek.de  [151207 09:17]:
> Hi Tony,
> 
> there are two ethernet interfaces ( dual-emac-configuration ) used.
> One is connected to another 100mbit switch-ic ( refclk should come from
> switch ic ) via rmii, the other one is connected to a 1gbit fpga rgmii
> interface ( where the clock is served from the fpga ).
> 
> On both interfaces it may happen that the clock isn't present while the
> mac-address is set (fpga may not have been inited, switch chip could be
> held in reset), but this was the same behaviour with previous kernel
> (3.14 with cpsw patched from ti tree) where this configuration worked.
> As the hardware is in field now there is no chance to change hardware.
> 
> On the other hand: when not setting the mac of the interface that early,
> the cpsw seems to init proberly but a ping to the outer world does not
> work either, so something else may be different on the new kernel.

Maybe Mugunthan has some ideas what's going on here.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq_simple: Fix regression with optional GPIOs

2015-12-08 Thread Tony Lindgren 
* Ulf Hansson  [151208 05:18]:
> On 8 December 2015 at 01:32, Tony Lindgren  wrote:
> > * Ulf Hansson  [151207 16:20]:
> >> +Linus
> >>
> >> On 7 December 2015 at 23:54, Tony Lindgren  wrote:
> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
> >> > API")
> >> > changed the handling MMC power sequence so GPIOs no longer are optional.
> >> >
> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
> >> > GPIOs
> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
> >>
> >> Can you elaborate on this. Did it break omap5 or not? :-)
> >
> > Yes it broke WLAN for omap5 that I just got fixed.. It only uses the clocks
> > art of the pwrseq currently because of the delay needed.
> >
> >> Also, I am interested to know more about the waiting period you need.
> >> I assume that's because of the HW's characteristic?
> >
> > At least TI wl12xx and Marvell 8787 need a delay after enabling the the 
> > WLAN.
> >
> >> Why can't we have that being described in DT and then make
> >> pwrseq_simple *wait* if needed?
> >
> > We can, but I'm thinking that we might be better off adding support for
> > regulators to pwrseq. Both TI wl12xx and Marvell 8787 get power from the
> > battery, and probably have an integrated regulator.
> 
> Sounds very reasonable! Perhaps some of the delays can be handled
> within the context of the regulator then!?

Yes that's in the regulator binding. As long as the pwrseq code can sleep
there's no problem with that.

> > Also, the delay and the power up sequencey can be more complicated than what
> > we currently support. In the 8787 case, pdn pin needs to be asserted for 
> > 300ms
> > after power pins are stable and while reset is held high.
> 
> I am for sure open to extend pwrseq_simple, please go ahead!
> 
> The initial version provided a proof of concept and the
> infrastructure. I expect and want people to extend it to suit their
> HWs.
> 
> If we at some point find that pwrseq_simple starts to become too
> complex, we may add another pwrseq type with a corresponding new
> compatible string.

Yeah OK I'll take a look when I get a chance.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

2015-12-08 Thread Tony Lindgren 
* Tony Lindgren  [151201 15:43]:
> The timer clock aliases are needed early on dm814x. Let's also
> add the aliases for the interconnects and MMC.
> 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Tero Kristo 
> Signed-off-by: Tony Lindgren 

Anybody from the clock department care to ack this one? I'd like to
get this series into Linux next as it fixes some some issues.

Regards,

Tony


>  drivers/clk/ti/clk-814x.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
> index e172920..9e85fcc 100644
> --- a/drivers/clk/ti/clk-814x.c
> +++ b/drivers/clk/ti/clk-814x.c
> @@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
>   DT_CLK(NULL, "devosc_ck", "devosc_ck"),
>   DT_CLK(NULL, "mpu_ck", "mpu_ck"),
>   DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
> + DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
>   DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
> + DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
>   DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
>   DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
>   DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
> + DT_CLK(NULL, "timer1_fck", "timer1_fck"),
> + DT_CLK(NULL, "timer2_fck", "timer2_fck"),
>   DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
>   DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
>   { .node_name = NULL },
> -- 
> 2.6.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

2015-12-08 Thread Felipe Balbi 

Hi,

Grygorii Strashko  writes:
> ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> Timekeeping core misbehaves. For example, execution of command
> "sleep 5" will take 10 sec instead of 5.
>
> Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
> it for clocking ARM TWD and Global timer (same way as on OMAP4).
>
> Cc: Tony Lindgren 
> Cc: Felipe Balbi 
> Cc: Tero Kristo 
> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
> nodes")
> Signed-off-by: Grygorii Strashko 

this seems to be the best fix for this problem, yeah.

Reviewed-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

2015-12-08 Thread Grygorii Strashko 

Hi Tony, Felipe, Tero,
On 12/03/2015 08:04 PM, Grygorii Strashko wrote:

On 12/03/2015 06:35 PM, Tony Lindgren wrote:

* Grygorii Strashko  [151130 07:58]:

ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
Timekeeping core misbehaves. For example, execution of command
"sleep 5" will take 10 sec instead of 5.

Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
it for clocking ARM TWD and Global timer (same way as on OMAP4).

Cc: Tony Lindgren 
Cc: Felipe Balbi 
Cc: Tero Kristo 
Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
nodes")
Signed-off-by: Grygorii Strashko 


Is this fix alone enough or do you still need to disable other the ARM
timers in the board specific dts file?



This one is independent and it's required for -rc, because ARM TWD timer will 
be selected
now for am43xx even if http://www.spinics.net/lists/arm-kernel/msg459649.html
is not merged yet ;) in case of omap2plus_defconfig build.




Are there any comments objection?
Could this patch be merged as part of -rc cycle?

--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

2015-12-08 Thread Tero Kristo 

On 12/08/2015 06:57 PM, Tony Lindgren wrote:

* Tony Lindgren  [151201 15:43]:

The timer clock aliases are needed early on dm814x. Let's also
add the aliases for the interconnects and MMC.

Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 


Anybody from the clock department care to ack this one?


Sorry been rather busy lately...


I'd like to
get this series into Linux next as it fixes some some issues.


Yeah looks good to me, don't have access to dm814x so can't test.

Acked-by: Tero Kristo 

Are you planning to push this via omap tree if this is critical for you?

-Tero



Regards,

Tony



  drivers/clk/ti/clk-814x.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
index e172920..9e85fcc 100644
--- a/drivers/clk/ti/clk-814x.c
+++ b/drivers/clk/ti/clk-814x.c
@@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
DT_CLK(NULL, "devosc_ck", "devosc_ck"),
DT_CLK(NULL, "mpu_ck", "mpu_ck"),
DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
+   DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
+   DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
+   DT_CLK(NULL, "timer1_fck", "timer1_fck"),
+   DT_CLK(NULL, "timer2_fck", "timer2_fck"),
DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
{ .node_name = NULL },
--
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

2015-12-08 Thread Tony Lindgren 
* Tero Kristo  [151208 11:25]:
> On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >
> >Anybody from the clock department care to ack this one?
> 
> Sorry been rather busy lately...
>
> >I'd like to
> >get this series into Linux next as it fixes some some issues.
> 
> Yeah looks good to me, don't have access to dm814x so can't test.
> 
> Acked-by: Tero Kristo 

Thanks.

> Are you planning to push this via omap tree if this is critical for you?

Yes this series needs to be merged in certain order to keep t410
booting. Should not conflict with anything else AFAIK.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

2015-12-08 Thread Tero Kristo 

On 12/08/2015 10:11 PM, Tony Lindgren wrote:

* Tero Kristo  [151208 11:25]:

On 12/08/2015 06:57 PM, Tony Lindgren wrote:


Anybody from the clock department care to ack this one?


Sorry been rather busy lately...


I'd like to
get this series into Linux next as it fixes some some issues.


Yeah looks good to me, don't have access to dm814x so can't test.

Acked-by: Tero Kristo 


Thanks.


Are you planning to push this via omap tree if this is critical for you?


Yes this series needs to be merged in certain order to keep t410
booting. Should not conflict with anything else AFAIK.


Ok at least I am fine with that. The dm81xx clock alias file is pretty 
independent of anything else.


-Tero

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 bis 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-12-08 Thread Brian Norris 
Hi Boris,

On Wed, Dec 02, 2015 at 09:50:01AM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 
> Cc: Julia Lawall 
> ---
> Most of those changes were generated with the coccinelle script added
> in commit c671312 "coccinelle: nand: detect and correct drivers embedding
> an mtd_info object"
> ---
> Changes since v2:
> - fix several compilation errors/warnings
> 
>  drivers/mtd/nand/ams-delta.c   | 13 ++--
>  drivers/mtd/nand/atmel_nand.c  | 13 ++--
>  drivers/mtd/nand/au1550nd.c| 19 ++---
>  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
>  drivers/mtd/nand/bcm47xxnflash/main.c  |  8 ++-
>  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
>  drivers/mtd/nand/bf5xx_nand.c  | 12 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c   | 13 ++--
>  drivers/mtd/nand/cafe_nand.c   |  8 +--
>  drivers/mtd/nand/cmx270_nand.c | 11 ++-

There's another error here, I think ^^^

>  drivers/mtd/nand/cs553x_nand.c | 13 ++--
>  drivers/mtd/nand/davinci_nand.c| 30 
>  drivers/mtd/nand/denali.c  | 68 ++
>  drivers/mtd/nand/denali.h  |  1 -
>  drivers/mtd/nand/diskonchip.c  | 11 ++-
>  drivers/mtd/nand/docg4.c   | 23 +++---
>  drivers/mtd/nand/fsl_elbc_nand.c   | 26 ---
>  drivers/mtd/nand/fsl_ifc_nand.c| 28 
>  drivers/mtd/nand/fsl_upm.c | 28 
>  drivers/mtd/nand/fsmc_nand.c   | 56 ---
>  drivers/mtd/nand/gpio.c| 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 23 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
>  drivers/mtd/nand/hisi504_nand.c| 13 ++--
>  drivers/mtd/nand/jz4740_nand.c |  9 ++-
>  drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
>  drivers/mtd/nand/lpc32xx_slc.c |  7 +-
>  drivers/mtd/nand/mpc5121_nfc.c |  3 +-
>  drivers/mtd/nand/mxc_nand.c|  5 +-
>  drivers/mtd/nand/nandsim.c | 12 ++--
>  drivers/mtd/nand/ndfc.c| 24 ---
>  drivers/mtd/nand/nuc900_nand.c | 24 +++
>  drivers/mtd/nand/omap2.c   | 98 
> +++---
>  drivers/mtd/nand/orion_nand.c  |  4 +-
>  drivers/mtd/nand/pasemi_nand.c | 12 ++--
>  drivers/mtd/nand/plat_nand.c   | 15 ++--
>  drivers/mtd/nand/pxa3xx_nand.c | 33 -
>  drivers/mtd/nand/r852.c| 34 -
>  drivers/mtd/nand/r852.h|  1 -
>  drivers/mtd/nand/s3c2410.c | 23 +++---
>  drivers/mtd/nand/sh_flctl.c|  8 +--
>  drivers/mtd/nand/sharpsl.c | 22 +++---
>  drivers/mtd/nand/socrates_nand.c   |  5 +-
>  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
>  drivers/mtd/nand/tmio_nand.c   | 10 +--
>  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
>  drivers/mtd/nand/vf610_nfc.c   |  8 ++-
>  include/linux/mtd/sh_flctl.h   |  3 +-
>  49 files changed, 432 insertions(+), 394 deletions(-)
> 

...

> diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> index 43bded6..84d027e 100644
> --- a/drivers/mtd/nand/cmx270_nand.c
> +++ b/drivers/mtd/nand/cmx270_nand.c
> @@ -160,10 +160,8 @@ static int __init cmx270_init(void)
>   gpio_direction_input(GPIO_NAND_RB);
>  
>   /* Allocate memory for MTD device structure and private data */
> - cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
> -   sizeof(struct nand_chip),
> -   GFP_KERNEL);
> - if (!cmx270_nand_mtd) {
> + this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> + if (!this) {
>   ret = -ENOMEM;
>   goto err_kzalloc;
>   }
> @@ -175,8 +173,7 @@ static int __init cmx270_init(void)
>   goto err_ioremap;
>   }
>  
> - /* Get pointer to private data */
> - this = (struct nand_chip *)(_nand_mtd[1]);
> + cmx270_nand_mtd = nand_to_mtd(this);

So, you make cmx270_nand_mtd no longer kzalloc()'d, but I still see the
cmx270_init() function end with:

err_scan:
iounmap(cmx270_nand_io);
err_ioremap:
kfree(cmx270_nand_mtd);  <- *** this! ***
err_kzalloc:
gpio_free(GPIO_NAND_RB);
err_gpio_request:

Re: [PATCH v2 00/25] mtd: nand: refactor the NAND subsystem (part 1)

2015-12-08 Thread Brian Norris 
Hi,

On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> Hello,
> 
> This huge series aims at clarifying the relationship between the mtd and
> nand_chip structures and hiding NAND framework internals to NAND
> controller drivers.
> 
> The first part of the series provide an mtd_to_nand() helper to hide the
> way mtd and nand_chip are linked together.
> 
> The second part of the series embeds the mtd structure into the nand_chip
> one so that NAND controller drivers don't have to bother allocating the
> MTD device and linking it with the NAND chip.
> 
> The last part of the series hides accesses to the chip->priv field behind
> two helper functions.
> 
> This allows removal of some of the boilerplate code done in all NAND
> controller drivers, but most importantly, it unifies a bit the way NAND
> chip structures are instantiated (even though we still have two different
> kinds of drivers: those embedding the nand_chip struct into their private
> nand chip representation, and those allocating two different structures
> and linking them together with the chip->priv field).
> 
> As said in the title, this refactoring is only the first step. I plan to
> rework the NAND controller / NAND chip separation for pretty much the same
> reasons: clarifying the separation between the two concepts, and getting
> rid of more boilerplate code in NAND controller drivers.
> 
> Stay tuned ;-).
> 
> Best Regards,
> 
> Boris
> 
> Changes since v1:
> - dropped already applied patches
> - fixed some typos
> - manually fixed some modifications omitted by the coccinelle scripts
> - manually reworked modifactions done by coccinelle scripts to improve
>   readability and fix coding style issues
> 
> Boris Brezillon (25):
>   ARM: nand: make use of mtd_to_nand() where appropriate

I've sent this (+ the introduction of mtd_to_nand()) in a pull request
to arm-soc, as well as to l2-mtd.git.

>   blackfin: nand: make use of mtd_to_nand() where appropriate
>   cris: nand: make use of mtd_to_nand() where appropriate
>   mips: nand: make use of mtd_to_nand() where appropriate

I've based these on v4.4-rc1 and brought them into l2-mtd.git, in case
any arch/{blackfin,cris,mips}/ people want to pull them in too.

>   sh: nand: make use of mtd_to_nand() where appropriate
>   mtd: nand: make use of mtd_to_nand() in NAND core code
>   mtd: nand: make use of mtd_to_nand() in NAND drivers
>   staging: mt29f_spinand: make use of mtd_to_nand()
>   mtd: nand: embed an mtd_info structure into nand_chip
>   mtd: nand: add nand_to_mtd() helper

Pulled the rest up to here into l2-mtd.git.

>   coccinelle: nand: detect and correct drivers embedding an mtd_info
> object

I believe Julia had comments on this. That probably would go through the
kbuild tree in the end anyway (?).

>   mtd: nand: use the mtd instance embedded in struct nand_chip

There's still at least one problem in this patch (commented on the
patch). It touches a lot of drivers, so any extra review would be great.

>   mtd: nand: update the documentation to reflect framework changes
>   staging: mt29f_spinand: use the mtd instance embedded in struct
> nand_chip
>   cris: nand: use the mtd instance embedded in struct nand_chip
>   mtd: nand: update mtd_to_nand()
>   mtd: nand: remove useless mtd->priv = chip assignments
>   cris: nand: remove useless mtd->priv = chip assignments
>   staging: mt29f_spinand: remove useless mtd->priv = chip assignment
>   mtd: nand: simplify nand_dt_init() usage
>   mtd: nand: kill the chip->flash_node field
>   mtd: nand: add helpers to access ->priv
>   ARM: make use of nand_set/get_controller_data() helpers
>   mtd: nand: make use of nand_set/get_controller_data() helpers
>   staging: mt29f_spinand: make use of nand_set/get_controller_data()
> helpers

All the rest look good to me. I'll wait until I get a good copy of patch
12 before taking them.

Brian

>  Documentation/DocBook/mtdnand.tmpl |  31 +++---
>  arch/arm/mach-ep93xx/snappercl15.c |   4 +-
>  arch/arm/mach-ep93xx/ts72xx.c  |   4 +-
>  arch/arm/mach-imx/mach-qong.c  |   2 +-
>  arch/arm/mach-ixp4xx/ixdp425-setup.c   |   6 +-
>  arch/arm/mach-omap1/board-nand.c   |   2 +-
>  arch/arm/mach-orion5x/ts78xx-setup.c   |   6 +-
>  arch/arm/mach-pxa/balloon3.c   |   2 +-
>  arch/arm/mach-pxa/em-x270.c|   2 +-
>  arch/arm/mach-pxa/palmtx.c |   2 +-
>  arch/blackfin/mach-bf537/boards/stamp.c|   2 +-
>  arch/blackfin/mach-bf561/boards/acvilon.c  |   2 +-
>  arch/cris/arch-v32/drivers/mach-a3/nandflash.c |   8 +-
>  arch/cris/arch-v32/drivers/mach-fs/nandflash.c |   8 +-
>  arch/mips/alchemy/devboards/db1200.c   |   2 +-
>  arch/mips/alchemy/devboards/db1300.c   |   2 +-
>  arch/mips/alchemy/devboards/db1550.c   |   2 +-
>  arch/mips/pnx833x/common/platform.c|   2 +-
>  arch/mips/rb532/devices.c

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

2015-12-08 Thread Pratyush Anand 
On Tue, Dec 8, 2015 at 2:53 PM, Lucas Stach  wrote:
> Hi Bjorn,
>
> Am Montag, den 07.12.2015, 21:33 -0600 schrieb Bjorn Helgaas:
>> [+cc Jingoo (exynos), Richard, Lucas (imx6), Pratyush (spear13xx)]
>>
>> On Fri, Dec 04, 2015 at 11:22:50PM +0200, Grygorii Strashko wrote:
>> > On 12/04/2015 08:46 PM, Bjorn Helgaas wrote:
>> > > Hi Grygorii,
> [...]
>> > >>
>> > >> +/*
>> > >> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
>> > >> + * On -RT and if kernel is booting with "threadirqs" cmd line 
>> > >> parameter
>> > >> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded 
>> > >> but,
>> > >> + * in the same time, it's IRQ dispatcher and calls 
>> > >> generic_handle_irq(),
>> > >> + * which, in turn, will be resolved to handle_simple_irq() 
>> > >> call.
>> > >> + * The handle_simple_irq() expected to be called with IRQ 
>> > >> disabled, as
>> > >> + * result kernle will display warning:
>> > >> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
>> > >> + */
>> > >>  ret = devm_request_irq(>dev, pp->irq,
>> > >> -   dra7xx_pcie_msi_irq_handler, 
>> > >> IRQF_SHARED,
>> > >> +   dra7xx_pcie_msi_irq_handler,
>> > >> +   IRQF_SHARED | IRQF_NO_THREAD,
>> > >> "dra7-pcie-msi", pp);
>> > >
>> > > There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
>> > > and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
>> > > why not?
>> > >
>> > > I see your discussion about DRA7 hardware design, but my impression is
>> > > that this problem affects anybody who calls dw_handle_msi_irq() from a
>> > > handler registered with IRQF_SHARED.
>> >
>> > Issue fixed by this patch is not related to IRQF_SHARED.
>> > It will happen on -RT or if kernel will boot with "threadirqs" cmd line 
>> > parameter
>> > - in both cases these PCI IRQ handlers will be forced to be threaded and,
>> > as result, generic_handle_irq() will produce above backtrace.
>> >
>> > Personally, I don't have strong opinion about "should similar change be 
>> > applied
>> > to other PCI drivers or not?" And I think, that owners of those driver 
>> > should
>> > make such decision.
>>
>> If the same issue affects several drivers, I'd like to see them all
>> handle it the same way.  Otherwise, somebody coming along later will
>> wonder why they're different, and there won't be a good answer.
>>
>> I cc'd the other maintainers to see what they think.
>>

I too agree with the change for SPEAr13xx as well.

~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html