Device tree node for Freescale Gianfar PTP reference clock source selection

2013-09-23 Thread Aida Mynzhasova 

Hi,

Currently, Freescale Gianfar PTP reference clock source is determined 
through hard-coded value in gianfar_ptp driver. I don't think that 
recompilation of the entire module (or even worse - the kernel) is a god 
idea when we want to change one clock source to another. So, I want to 
add new device tree binding, which can be used as:


ptp_clock@24E00 {
compatible = fsl,etsec-ptp;
reg = 0x24E00 0xB0;
interrupts = 12 0x8 13 0x8;
interrupt-parent =  ipic ;
fsl,cksel = 0; /* -- New entry */
fsl,tclk-period = 10;
fsl,tmr-prsc= 100;
fsl,tmr-add = 0x99A4;
fsl,tmr-fiper1  = 0x3B9AC9F6;
fsl,tmr-fiper2  = 0x00018696;
fsl,max-adj = 65998;
};

fsl,cksel acceptable values:

0 for external clock;
1 for eTSEC system clock;
2 for eTSEC1 transmit clock;
3 for RTC clock input.

I am new in this mailing list, and as far as I know, I have to discuss 
all updates for device tree files here before sending patch, which uses 
new attributes.


Also, should I define new bindings in some special way? I want to add 
description of cksel attribute in 
/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt. Is it enough or 
not?


Thanks!

--
Regards,
Aida
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/irq: Run softirqs off the top of the irq stack

2013-09-23 Thread Stephen Rothwell 
Hi Ben,

On Mon, 23 Sep 2013 14:35:58 +1000 Benjamin Herrenschmidt 
b...@kernel.crashing.org wrote:

 diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
 index c69440c..0c9646f 100644
 --- a/arch/powerpc/kernel/irq.c
 +++ b/arch/powerpc/kernel/irq.c
 @@ -443,46 +443,7 @@ void migrate_irqs(void)
  
  static inline void handle_one_irq(unsigned int irq)
  {
 - struct thread_info *curtp, *irqtp;
 - unsigned long saved_sp_limit;
 - struct irq_desc *desc;
 -
 - desc = irq_to_desc(irq);
 - if (!desc)
 - return;
 -
 - /* Switch to the irq stack to handle this */
 - curtp = current_thread_info();
 - irqtp = hardirq_ctx[smp_processor_id()];
 -
 - if (curtp == irqtp) {
 - /* We're already on the irq stack, just handle it */
 - desc-handle_irq(irq, desc);
 - return;
 - }
 -
 - saved_sp_limit = current-thread.ksp_limit;
 -
 - irqtp-task = curtp-task;
 - irqtp-flags = 0;
 -
 - /* Copy the softirq bits in preempt_count so that the
 -  * softirq checks work in the hardirq context. */
 - irqtp-preempt_count = (irqtp-preempt_count  ~SOFTIRQ_MASK) |
 -(curtp-preempt_count  SOFTIRQ_MASK);
  
 - current-thread.ksp_limit = (unsigned long)irqtp +
 - _ALIGN_UP(sizeof(struct thread_info), 16);
 -
 - call_handle_irq(irq, desc, irqtp, desc-handle_irq);
 - current-thread.ksp_limit = saved_sp_limit;
 - irqtp-task = NULL;
 -
 - /* Set any flag that may have been set on the
 -  * alternate stack
 -  */
 - if (irqtp-flags)
 - set_bits(irqtp-flags, curtp-flags);
  }

This function ends up as a single blank line ...

 @@ -519,18 +480,64 @@ void do_IRQ(struct pt_regs *regs)
*/
   irq = ppc_md.get_irq();
  
 - /* We can hard enable interrupts now */
 + /* We can hard enable interrupts now to allow perf interrupts */
   may_hard_irq_enable();
  
   /* And finally process it */
 - if (irq != NO_IRQ)
 - handle_one_irq(irq);

then you remove the only call, so why not just remove the function
completely?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpeXLH2lyAd6.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 04/10] irqdomain: Return errors from irq_create_of_mapping()

2013-09-23 Thread Thierry Reding 
On Sun, Sep 22, 2013 at 04:14:43PM -0500, Rob Herring wrote:
 On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
 thierry.red...@gmail.com wrote:
  Instead of returning 0 for all errors, allow the precise error code to
  be propagated. This will be used in subsequent patches to allow further
  propagation of error codes.
 
  The interrupt number corresponding to the new mapping is returned in an
  output parameter so that the return value is reserved to signal success
  (== 0) or failure ( 0).
 
  Signed-off-by: Thierry Reding tred...@nvidia.com
 
 One comment below, otherwise:
 
 Acked-by: Rob Herring rob.herr...@calxeda.com
 
  diff --git a/arch/powerpc/kernel/pci-common.c 
  b/arch/powerpc/kernel/pci-common.c
  index 905a24b..ae71b14 100644
  --- a/arch/powerpc/kernel/pci-common.c
  +++ b/arch/powerpc/kernel/pci-common.c
  @@ -230,6 +230,7 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
   {
  struct of_irq oirq;
  unsigned int virq;
  +   int ret;
 
  pr_debug(PCI: Try to map irq for %s...\n, pci_name(pci_dev));
 
  @@ -266,8 +267,10 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
   oirq.size, oirq.specifier[0], oirq.specifier[1],
   of_node_full_name(oirq.controller));
 
  -   virq = irq_create_of_mapping(oirq.controller, 
  oirq.specifier,
  -oirq.size);
  +   ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
  +   oirq.size, virq);
  +   if (ret)
  +   virq = NO_IRQ;
  }
  if(virq == NO_IRQ) {
  pr_debug( Failed to map !\n);
 
 Can you get rid of NO_IRQ usage here instead of adding to it.

I was trying to stay consistent with the remainder of the code. PowerPC
is a pretty heavy user of NO_IRQ. Of all 348 references, more than half
(182) are in arch/powerpc, so I'd rather like to get a go-ahead from
Benjamin on this.

That said, perhaps we should just go all the way and get rid of NO_IRQ
for good. Things could get somewhat messy, though. There are a couple of
these spread through the code:

#ifndef NO_IRQ
#define NO_IRQ (-1)
#endif

And this isn't very encouraging either:

$ git grep 'irq.*=.*-1' | wc -l
638

Thierry


pgpI7td10X2n7.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 07/10] of/irq: Propagate errors in of_irq_to_resource_table()

2013-09-23 Thread Thierry Reding 
On Sun, Sep 22, 2013 at 04:08:26PM -0500, Rob Herring wrote:
 On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
 thierry.red...@gmail.com wrote:
  Now that all helpers return precise error codes, this function can
  propagate these errors to the caller properly.
 
  Signed-off-by: Thierry Reding tred...@nvidia.com
  ---
  Changes in v2:
  - return 0 on success or a negative error code on failure
  - convert callers to new calling convention
 
 [snip]
 
  diff --git a/drivers/of/irq.c b/drivers/of/irq.c
  index e4f38c0..6d7f824 100644
  --- a/drivers/of/irq.c
  +++ b/drivers/of/irq.c
  @@ -397,18 +397,20 @@ int of_irq_count(struct device_node *dev)
* @res: array of resources to fill in
* @nr_irqs: the number of IRQs (and upper bound for num of @res elements)
 
 You are effectively changing this to require an exact match rather
 than an upper bound. That seems to be okay since that is what all the
 callers want, but the documentation should be updated.

Done.

*
  - * Returns the size of the filled in table (up to @nr_irqs).
  + * Returns 0 on success or a negative error code on failure.
*/
   int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
  int nr_irqs)
   {
  -   int i;
  +   int i, ret;
 
  -   for (i = 0; i  nr_irqs; i++, res++)
  -   if (!of_irq_to_resource(dev, i, res))
 
 The error handling here needs to be updated in the previous patch.

Yes, you're right.

Thanks,
Thierry


pgpTRhF43wOhS.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc: make kernel module helper endian-safe.

2013-09-23 Thread David Laight 
 --- a/arch/powerpc/kernel/module_64.c
 +++ b/arch/powerpc/kernel/module_64.c
 @@ -62,6 +62,16 @@ struct ppc64_stub_entry
 r2) into the stub. */
  static struct ppc64_stub_entry ppc64_stub =
  { .jump = {
 +#ifdef __LITTLE_ENDIAN__
 + 0x00, 0x00, 0x82, 0x3d, /* addis   r12,r2, high */
 + 0x00, 0x00, 0x8c, 0x39, /* addir12,r12, low */
 + /* Save current r2 value in magic place on the stack. */
 + 0x28, 0x00, 0x41, 0xf8, /* std r2,40(r1) */
 + 0x20, 0x00, 0x6c, 0xe9, /* ld  r11,32(r12) */
 + 0x28, 0x00, 0x4c, 0xe8, /* ld  r2,40(r12) */
 + 0xa6, 0x03, 0x69, 0x7d, /* mtctr   r11 */
 + 0x20, 0x04, 0x80, 0x4e  /* bctr */
 +#else
   0x3d, 0x82, 0x00, 0x00, /* addis   r12,r2, high */
   0x39, 0x8c, 0x00, 0x00, /* addir12,r12, low */
   /* Save current r2 value in magic place on the stack. */
 @@ -70,6 +80,7 @@ static struct ppc64_stub_entry ppc64_stub =
   0xe8, 0x4c, 0x00, 0x28, /* ld  r2,40(r12) */
   0x7d, 0x69, 0x03, 0xa6, /* mtctr   r11 */
   0x4e, 0x80, 0x04, 0x20  /* bctr */
 +#endif

Seems to me that should be a list of 32bit constants.

David



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] powerpc: make ftrace endian-safe.

2013-09-23 Thread David Laight 
 --- a/arch/powerpc/kernel/ftrace.c
 +++ b/arch/powerpc/kernel/ftrace.c
 @@ -174,7 +174,11 @@ __ftrace_make_nop(struct module *mod,
 
   pr_devel( %08x %08x\n, jmp[0], jmp[1]);
 
 +#ifdef __LITTLE_ENDIAN__
 + ptr = ((unsigned long)jmp[1]  32) + jmp[0];
 +#else
   ptr = ((unsigned long)jmp[0]  32) + jmp[1];
 +#endif
 

Why not just:
ptr = *(__u64 *)jmp;

Or, if alignment isn't guaranteed, something that is
equivalent to:
ptr = *(__u64 __attribute__((aligned(4))) *)jmp;

David



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 0/6] perf: New conditional branch filter

2013-09-23 Thread Anshuman Khandual 
On 09/21/2013 12:25 PM, Stephane Eranian wrote:
 On Tue, Sep 10, 2013 at 4:06 AM, Michael Ellerman
 mich...@ellerman.id.au wrote:
 
  On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
 This patchset is the re-spin of the original branch stack sampling
   patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This 
   patchset
   also enables SW based branch filtering support for PPC64 platforms 
   which have
   branch stack sampling support. With this new enablement, the branch 
   filter support
   for PPC64 platforms have been extended to include all these 
   combinations discussed
   below with a sample test application program.
 
  ...
 
   Mixed filters
   -
   (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog
   Error:
   The perf.data file has no samples!
  
   NOTE: As expected. The HW filters all the branches which are calls and 
   SW tries to find return
   branches in that given set. Both the filters are mutually exclussive, 
   so obviously no samples
   found in the end profile.
 
  The semantics of multiple filters is not clear to me. It could be an OR,
  or an AND. You have implemented AND, does that match existing behaviour
  on x86 for example?
 
 The semantic on the API is OR. AND does not make sense: CALL  RETURN?
 On x86, the HW filter is an OR (default: ALL, set bit to disable a
 type). I suspect
 it is similar on PPC.

Hey Stephane,

In POWER8 BHRB, we have got three HW PMU filters out of which we are trying
to use two of them PERF_SAMPLE_BRANCH_ANY_CALL and PERF_SAMPLE_BRANCH_COND
respectively.

(1) These filters are exclusive of each other and cannot be OR-ed with each 
other

(2) The SW filters are applied on the branch record set captured with BHRB
which have the HW filters applied. So the working set is already reduced
with the HW PMU filters. SW filter goes through the working set and figures
out which one of them satisfy the SW filter criteria and gets picked up. The
SW filter cannot find out branches records which matches the criteria 
outside
of BHRB captured set. So we cannot OR the filters.

This makes the combination of HW and SW filter inherently an AND not OR.

(3) But once we have captured the BHRB filtered data with HW PMU filter, 
multiple SW
filters (if requested) can be applied either in OR or AND manner.

It should be either like
(1) (HW_FILTER_1)  (SW_FILTER_1)  (SW_FILTER_2)
or like
(2) (HW_FILTER_1)  (SW_FILTER_1 || SW_FILTER_2)

NOTE: I admit that the current validate_instruction() function does not do
either of them correctly. Will fix it in the next iteration.

(4) These combination of filters are not supported right now because

(a) We are unable to process two HW PMU filters simultaneously
(b) We have not worked on replacement SW filter for either of the HW 
filters

(1) (HW_FILTER_1), (HW_FILTER_2)
(2) (HW_FILTER_1), (HW_FILTER_2), (SW_FILTER_1)
(3) (HW_FILTER_1), (HW_FILTER_2), (SW_FILTER_1), (SW_FILTER_2)

   How ever these combination of filters can be supported right now.

(1) (HW_FILTER_1)
(2) (HW_FILTER_2)

(3) (SW_FILTER_1)
(4) (SW_FILTER_2)
(5) (SW_FILTER_1), (SW_FILTER_2)

(6)  (HW_FILTER_1), (SW_FILTER_1)
(7)  (HW_FILTER_1), (SW_FILTER_2)
(8)  (HW_FILTER_1), (SW_FILTER_1), (SW_FILTER_2)
(9)  (HW_FILTER_2), (SW_FILTER_1)
(10) (HW_FILTER_2), (SW_FILTER_2)
(11) (HW_FILTER_2), (SW_FILTER_1), (SW_FILTER_2)


Given the situation as explained here, which semantic would be better for single
HW and multiple SW filters. Accordingly validate_instruction() function will 
have
to be re-implemented. But I believe OR-ing the SW filters will be preferable.

(1) (HW_FILTER_1)  (SW_FILTER_1)  (SW_FILTER_2)
or
(2) (HW_FILTER_1)  (SW_FILTER_1 || SW_FILTER_2)

Please let me know your inputs and suggestions on this. Thank you.

Regards
Anshuman

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/irq: Run softirqs off the top of the irq stack

2013-09-23 Thread Benjamin Herrenschmidt 
On Mon, 2013-09-23 at 17:56 +1000, Stephen Rothwell wrote:
 Hi Ben,
 
 On Mon, 23 Sep 2013 14:35:58 +1000 Benjamin Herrenschmidt 
 b...@kernel.crashing.org wrote:
 
  diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
  index c69440c..0c9646f 100644
  --- a/arch/powerpc/kernel/irq.c
  +++ b/arch/powerpc/kernel/irq.c
  @@ -443,46 +443,7 @@ void migrate_irqs(void)
   
   static inline void handle_one_irq(unsigned int irq)
   {
  -   struct thread_info *curtp, *irqtp;
  -   unsigned long saved_sp_limit;
  -   struct irq_desc *desc;
  -
  -   desc = irq_to_desc(irq);
  -   if (!desc)
  -   return;
  -
  -   /* Switch to the irq stack to handle this */
  -   curtp = current_thread_info();
  -   irqtp = hardirq_ctx[smp_processor_id()];
  -
  -   if (curtp == irqtp) {
  -   /* We're already on the irq stack, just handle it */
  -   desc-handle_irq(irq, desc);
  -   return;
  -   }
  -
  -   saved_sp_limit = current-thread.ksp_limit;
  -
  -   irqtp-task = curtp-task;
  -   irqtp-flags = 0;
  -
  -   /* Copy the softirq bits in preempt_count so that the
  -* softirq checks work in the hardirq context. */
  -   irqtp-preempt_count = (irqtp-preempt_count  ~SOFTIRQ_MASK) |
  -  (curtp-preempt_count  SOFTIRQ_MASK);
   
  -   current-thread.ksp_limit = (unsigned long)irqtp +
  -   _ALIGN_UP(sizeof(struct thread_info), 16);
  -
  -   call_handle_irq(irq, desc, irqtp, desc-handle_irq);
  -   current-thread.ksp_limit = saved_sp_limit;
  -   irqtp-task = NULL;
  -
  -   /* Set any flag that may have been set on the
  -* alternate stack
  -*/
  -   if (irqtp-flags)
  -   set_bits(irqtp-flags, curtp-flags);
   }
 
 This function ends up as a single blank line ...
 
  @@ -519,18 +480,64 @@ void do_IRQ(struct pt_regs *regs)
   */
  irq = ppc_md.get_irq();
   
  -   /* We can hard enable interrupts now */
  +   /* We can hard enable interrupts now to allow perf interrupts */
  may_hard_irq_enable();
   
  /* And finally process it */
  -   if (irq != NO_IRQ)
  -   handle_one_irq(irq);
 
 then you remove the only call, so why not just remove the function
 completely?

Because I'm an idiot ? :-)

I moved bits and pieces to do_IRQ and forgot to remove the remainder
(and gcc didn't warn :-)

Cheers,
Ben.



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call

2013-09-23 Thread Vinod Koul 
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
 The DMA API requires drivers to call the appropriate dma_set_mask()
 functions before doing any DMA mapping.  Add this required call to
 the AMBA PL08x driver.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod
 ---
  drivers/dma/amba-pl08x.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
 index fce46c5..e51a983 100644
 --- a/drivers/dma/amba-pl08x.c
 +++ b/drivers/dma/amba-pl08x.c
 @@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const 
 struct amba_id *id)
   if (ret)
   return ret;
  
 + /* Ensure that we can do DMA */
 + ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
 + if (ret)
 + goto out_no_pl08x;
 +
   /* Create the driver state holder */
   pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
   if (!pl08x) {
 -- 
 1.7.4.4
 
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

2013-09-23 Thread Vinod Koul 
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
 register_platform_device_full() can setup the DMA mask provided the
 appropriate member is set in struct platform_device_info.  So lets
 make that be the case.  This avoids a direct reference to the DMA
 masks by this driver.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com

This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?

~Vinod

 ---
  drivers/dma/edma.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index ff50ff4..7f9fe30 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
  static const struct platform_device_info edma_dev_info0 = {
   .name = edma-dma-engine,
   .id = 0,
 + .dma_mask = DMA_BIT_MASK(32),
  };
  
  static const struct platform_device_info edma_dev_info1 = {
   .name = edma-dma-engine,
   .id = 1,
 + .dma_mask = DMA_BIT_MASK(32),
  };


  
  static int edma_init(void)
 @@ -720,8 +722,6 @@ static int edma_init(void)
   ret = PTR_ERR(pdev0);
   goto out;
   }
 - pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
 - pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   }
  
   if (EDMA_CTLRS == 2) {
 @@ -731,8 +731,6 @@ static int edma_init(void)
   platform_device_unregister(pdev0);
   ret = PTR_ERR(pdev1);
   }
 - pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
 - pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   }
  
  out:
 -- 
 1.7.4.4
 
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

2013-09-23 Thread Vinod Koul 
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
 On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
  Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
   The DMA API requires drivers to call the appropriate dma_set_mask()
   functions before doing any DMA mapping.  Add this required call to
   the AMBA PL08x driver.
  ^--- copy and paste error - should of course be PL330
 
 Fixed, thanks.
with fixed changelog...

Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod

-- 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

2013-09-23 Thread Russell King - ARM Linux 
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
 On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
  register_platform_device_full() can setup the DMA mask provided the
  appropriate member is set in struct platform_device_info.  So lets
  make that be the case.  This avoids a direct reference to the DMA
  masks by this driver.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 Acked-by: Vinod Koul vinod.k...@intel.com
 
 This also brings me question that should we force the driver to use the
 dma_set_mask_and_coherent() API or they have below flexiblity too?

There's two issues here:
1. dma_set_mask_and_coherent() will only work if dev-dma_mask points at
   some storage for the mask.  This needs to have .dma_mask in the
   platform_device_info initialised.

2. Yes, this driver should also be calling the appropriate DMA mask setting
   functions in addition to having the mask initialized at device creation
   time.

Here's a replacement patch, though maybe it would be better to roll all
the additions of dma_set_mask_and_coherent() in drivers/dma into one
patch?  In other words, combine the addition of this with these two
patches:

dma: pl330: add dma_set_mask_and_coherent() call
dma: pl08x: add dma_set_mask_and_coherent() call

8=
From: Russell King rmk+ker...@arm.linux.org.uk
Subject: [PATCH] DMA-API: dma: edma.c: no need to explicitly initialize DMA
 masks

register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info.  So lets
make that be the case.  This avoids a direct reference to the DMA
masks by this driver.

While here, add the dma_set_mask_and_coherent() call which the DMA API
requires DMA-using drivers to call.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 drivers/dma/edma.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..fd5e48c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -631,6 +631,10 @@ static int edma_probe(struct platform_device *pdev)
struct edma_cc *ecc;
int ret;
 
+   ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+
ecc = devm_kzalloc(pdev-dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
dev_err(pdev-dev, Can't allocate controller\n);
@@ -702,11 +706,13 @@ static struct platform_device *pdev0, *pdev1;
 static const struct platform_device_info edma_dev_info0 = {
.name = edma-dma-engine,
.id = 0,
+   .dma_mask = DMA_BIT_MASK(32),
 };
 
 static const struct platform_device_info edma_dev_info1 = {
.name = edma-dma-engine,
.id = 1,
+   .dma_mask = DMA_BIT_MASK(32),
 };
 
 static int edma_init(void)
@@ -720,8 +726,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
-   pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
-   pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
 
if (EDMA_CTLRS == 2) {
@@ -731,8 +735,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
-   pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
-   pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
 
 out:
-- 
1.7.4.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/kernel: fix endian issue in rtas_pci

2013-09-23 Thread Cédric Le Goater 
Signed-off-by: Cédric Le Goater c...@fr.ibm.com
---
 arch/powerpc/kernel/rtas_pci.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index 6e7b7cd..7d4c717 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -223,7 +223,7 @@ unsigned long get_phb_buid(struct device_node *phb)
 static int phb_set_bus_ranges(struct device_node *dev,
  struct pci_controller *phb)
 {
-   const int *bus_range;
+   const __be32 *bus_range;
unsigned int len;
 
bus_range = of_get_property(dev, bus-range, len);
@@ -231,8 +231,8 @@ static int phb_set_bus_ranges(struct device_node *dev,
return 1;
}
 
-   phb-first_busno =  bus_range[0];
-   phb-last_busno  =  bus_range[1];
+   phb-first_busno = be32_to_cpu(bus_range[0]);
+   phb-last_busno  = be32_to_cpu(bus_range[1]);
 
return 0;
 }
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

2013-09-23 Thread Nicolas Ferre 

On 20/09/2013 00:01, Russell King :

The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask().  Only arch and bus code should access this
member directly.

Convert all direct write accesses to using the correct API.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
  drivers/usb/chipidea/ci_hdrc_imx.c |5 +++--
  drivers/usb/dwc3/dwc3-exynos.c |5 +++--
  drivers/usb/gadget/lpc32xx_udc.c   |4 +++-
  drivers/usb/host/ehci-atmel.c  |5 +++--


For Atmel driver:

Acked-by: Nicolas Ferre nicolas.fe...@atmel.com

[..]


diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 3b645ff..5831a88 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
 */
if (!pdev-dev.dma_mask)
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
-   if (!pdev-dev.coherent_dma_mask)
-   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   retval = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+   if (retval)
+   goto fail_create_hcd;

hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd) {


[..]

Thanks,
--
Nicolas Ferre
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] ppc, vio fix modalias_show return values

2013-09-23 Thread Prarit Bhargava 
modalias_show() should return an empty string on error, not -ENODEV.

This causes the following false and annoying error:

 find /sys/devices -name modalias -print0 | xargs -0 cat /dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such device

Signed-off-by: Prarit Bhargava pra...@redhat.com
---
 arch/powerpc/kernel/vio.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 78a3506..d38cc08 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1530,11 +1530,15 @@ static ssize_t modalias_show(struct device *dev, struct 
device_attribute *attr,
const char *cp;
 
dn = dev-of_node;
-   if (!dn)
-   return -ENODEV;
+   if (!dn) {
+   strcat(buf, \n);
+   return strlen(buf);
+   }
cp = of_get_property(dn, compatible, NULL);
-   if (!cp)
-   return -ENODEV;
+   if (!cp) {
+   strcat(buf, \n);
+   return strlen(buf);
+   }
 
return sprintf(buf, vio:T%sS%s\n, vio_dev-type, cp);
 }
-- 
1.7.9.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] ppc, vio fix modalias_show return values

2013-09-23 Thread Prarit Bhargava 
[2nd try at this ... 1st one seems to have gone AWOL]

modalias_show() should return an empty string on error, not -ENODEV.

This causes the following false and annoying error:

 find /sys/devices -name modalias -print0 | xargs -0 cat /dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such device

Signed-off-by: Prarit Bhargava pra...@redhat.com
Cc: Paul Mackerras pau...@samba.org
Cc: Steve Best sb...@us.ibm.com
---
 arch/powerpc/kernel/vio.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 78a3506..d38cc08 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1530,11 +1530,15 @@ static ssize_t modalias_show(struct device *dev, struct 
device_attribute *attr,
const char *cp;
 
dn = dev-of_node;
-   if (!dn)
-   return -ENODEV;
+   if (!dn) {
+   strcat(buf, \n);
+   return strlen(buf);
+   }
cp = of_get_property(dn, compatible, NULL);
-   if (!cp)
-   return -ENODEV;
+   if (!cp) {
+   strcat(buf, \n);
+   return strlen(buf);
+   }
 
return sprintf(buf, vio:T%sS%s\n, vio_dev-type, cp);
 }
-- 
1.7.9.3

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v10 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

2013-09-23 Thread Stephen Warren 
On 09/18/2013 04:15 AM, hongbo.zh...@freescale.com wrote:
 From: Hongbo Zhang hongbo.zh...@freescale.com
 
 Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
 the device tree nodes for them.

 diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt 
 b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt

 +Required properties:
 +
 +- compatible: must include fsl,elo3-dma
 +- reg   : DMA General Status Registers, i.e. DGSR0 which contains
 +  status for channel 1~4, and DGSR1 for channel 5~8

Is that a single entry, which is large enough to cover both registers,
or a pair of entries, one per register? Reading the text, I might assume
the former, but looking at the examples, it's the latter.

...
 +Example:
 +dma@100300 {
 + #address-cells = 1;
 + #size-cells = 1;
 + compatible = fsl,elo3-dma;
 + reg = 0x100300 0x4,
 +   0x100600 0x4;

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2][v3] powerpc/fsl-booke: Add initial T104x_QDS board support

2013-09-23 Thread Scott Wood 
On Fri, 2013-09-20 at 19:23 -0500, Timur Tabi wrote:
 Scott Wood wrote:
  The patch is not lying.  It is describing the board, not what the
  patch supports.  This was something you used to constantly tell people
  to do...
 
 The patch says:
 
   DIU supports video at up to 1280x1024x32bpp
 
 How is this not misleading?

Does it have different limits on this board?

 I understand that the patch describes the board, and that's correct.  It 
 should also indicate which major functionality is not supported.  I was 
 expecting something like this:
 
 - Video
   - DIU hardware is capable of video up to 1280x1024x32bpp
   - DIU support is currently not implemented

Sure, it would be nice to point out notable limitations in the board
support.  That doesn't mean that it's lying as is, as it's quite
obviously a cut and paste from some other document rather than a
meaningful description of the patch itself.  I've never been a fan of
this sort of changelog, as we've discussed in the past.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

2013-09-23 Thread Russell King - ARM Linux 
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
 On Thu, 19 Sep 2013, Russell King wrote:
 
  The correct way for a driver to specify the coherent DMA mask is
  not to directly access the field in the struct device, but to use
  dma_set_coherent_mask().  Only arch and bus code should access this
  member directly.
  
  Convert all direct write accesses to using the correct API.
  
  Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
 
  diff --git a/drivers/usb/host/ehci-platform.c 
  b/drivers/usb/host/ehci-platform.c
  index f6b790c..5b0cd2d 100644
  --- a/drivers/usb/host/ehci-platform.c
  +++ b/drivers/usb/host/ehci-platform.c
 
  @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device 
  *dev)
  dev-dev.platform_data = ehci_platform_defaults;
  if (!dev-dev.dma_mask)
  dev-dev.dma_mask = dev-dev.coherent_dma_mask;
  -   if (!dev-dev.coherent_dma_mask)
  -   dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
  +   err = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
  +   if (err)
  +   return err;
   
  pdata = dev_get_platdata(dev-dev);
 
 ehci-platform.c is a generic file, intended for use by multiple
 platforms.  Is it not possible that on some platforms, the arch or bus
 code may already have initialized the DMA masks?  Isn't something like 
 this (i.e., DMA bindings) planned for Device Tree?
 
 By eliminating the tests above and calling dma_set_coherent_mask or
 dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
 would overwrite those initial settings.
 
 I don't know to what extent the same may be true for the other,
 platform-specific, drivers changed by this patch.  But it's something 
 to be aware of.

Please check the DMA API documentation:

=
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has.  It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.

The query is performed via a call to dma_set_mask():

int dma_set_mask(struct device *dev, u64 mask);

The query for consistent allocations is performed via a call to
dma_set_coherent_mask():

int dma_set_coherent_mask(struct device *dev, u64 mask);
=

So, All drivers which use DMA are supposed to issue the appropriate
calls to check the DMA masks before they perform DMA, even if the
default is correct.

And yes, this is all part of sorting out the DT mess - we should
start not from the current mess (which is really totally haphazard)
but from the well established position of how the DMA API _should_
be used.  What that means is that all drivers should be issuing
these calls as appropriate today.

The default mask setup when the device is created is just that -
it's a default mask, and it should not be used to decide anything
about the device.  That's something which the driver should compute
on its own accord and then inform the various other layers via the
appropriate call.

Remember, on PCI, even when we have 64-bit, we do not declare PCI
devices with a 64-bit DMA mask: that's up to PCI device drivers to
_try_ to set a 64-bit DMA mask, which when successful _allows_ them
to use 64-bit DMA.  If it fails, they have to only use 32-bit.  If
they want a smaller mask, the _driver_ has to set the smaller mask,
not the device creating code.

The reason we're into this (particularly on ARM) is that we got lazy
because we could get by with declaring a DMA mask at device creation
time, since all devices were statically declared.  Now it's time to
get rid of those old lazy ways and start doing things correctly and
to the requirements of the APIs.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

2013-09-23 Thread Alan Stern 
On Thu, 19 Sep 2013, Russell King wrote:

 The correct way for a driver to specify the coherent DMA mask is
 not to directly access the field in the struct device, but to use
 dma_set_coherent_mask().  Only arch and bus code should access this
 member directly.
 
 Convert all direct write accesses to using the correct API.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

 diff --git a/drivers/usb/host/ehci-platform.c 
 b/drivers/usb/host/ehci-platform.c
 index f6b790c..5b0cd2d 100644
 --- a/drivers/usb/host/ehci-platform.c
 +++ b/drivers/usb/host/ehci-platform.c

 @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device *dev)
   dev-dev.platform_data = ehci_platform_defaults;
   if (!dev-dev.dma_mask)
   dev-dev.dma_mask = dev-dev.coherent_dma_mask;
 - if (!dev-dev.coherent_dma_mask)
 - dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
 + err = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
 + if (err)
 + return err;
  
   pdata = dev_get_platdata(dev-dev);

ehci-platform.c is a generic file, intended for use by multiple
platforms.  Is it not possible that on some platforms, the arch or bus
code may already have initialized the DMA masks?  Isn't something like 
this (i.e., DMA bindings) planned for Device Tree?

By eliminating the tests above and calling dma_set_coherent_mask or
dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
would overwrite those initial settings.

I don't know to what extent the same may be true for the other,
platform-specific, drivers changed by this patch.  But it's something 
to be aware of.

Alan Stern

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/irq: Run softirqs off the top of the irq stack

2013-09-23 Thread Linus Torvalds 
On Sun, Sep 22, 2013 at 9:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:

 This is the band aid discussed so far for the stack overflow
 problem for powerpc.

I don't think it's a band-aid in any way, except perhaps in the
sense that there are certainly other things we can also do in this
series (ie I liked Frederic's cleanups etc).

 Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/irq: Run softirqs off the top of the irq stack

2013-09-23 Thread Benjamin Herrenschmidt 
On Mon, 2013-09-23 at 09:47 -0700, Linus Torvalds wrote:
 On Sun, Sep 22, 2013 at 9:35 PM, Benjamin Herrenschmidt
 b...@kernel.crashing.org wrote:
 
  This is the band aid discussed so far for the stack overflow
  problem for powerpc.
 
 I don't think it's a band-aid in any way, except perhaps in the
 sense that there are certainly other things we can also do in this
 series (ie I liked Frederic's cleanups etc).

Ah yes, I thought of it as a band-aid in the sense that a better
approach would be to switch to the irq stack earlier like x86_64 does
but that would be a lot more invasive. Definitely something I would look
into if I was to tackle changing how we do per-cpu and the PACA though.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 5/6 v7] kvm: booke: clear host tlb reference flag on guest tlb invalidation

2013-09-23 Thread Scott Wood 
On Mon, 2013-09-23 at 09:12 +0530, Bharat Bhushan wrote:
 On booke, struct tlbe_ref contains host tlb mapping information
 (pfn: for guest-pfn to pfn, flags: attribute associated with this mapping)
 for a guest tlb entry. So when a guest creates a TLB entry then
 struct tlbe_ref is set to point to valid pfn and set attributes in
 flags field of the above said structure. When a guest TLB entry is
 invalidated then flags field of corresponding struct tlbe_ref is
 updated to point that this is no more valid, also we selectively clear
 some other attribute bits, example: if E500_TLB_BITMAP was set then we clear
 E500_TLB_BITMAP, if E500_TLB_TLB0 is set then we clear this.
 
 Ideally we should clear complete flags as this entry is invalid and does not
 have anything to re-used. The other part of the problem is that when we use
 the same entry again then also we do not clear (started doing or-ing etc).
 
 So far it was working because the selectively clearing mentioned above
 actually clears flags what was set during TLB mapping. But the problem
 starts coming when we add more attributes to this then we need to selectively
 clear them and which is not needed.
 
 This patch we do both
 - Clear flags when invalidating;
 - Clear flags when reusing same entry later
 
 Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
 ---
 v6-7
  - Comment re-phrased

Reviewed-by: Scott Wood scottw...@freescale.com

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] powerpc/85xx: introduce corenet_generic machine

2013-09-23 Thread Scott Wood 
On Sun, 2013-09-22 at 15:42 +0800, Kevin Hao wrote:
 In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
 p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
 machine name. So this introduces a cornet_generic machine to support
 all these boards to avoid the code duplication.
 
 With these changes the file corenet_ds.h becomes useless. Just delete
 it.
 
 Signed-off-by: Kevin Hao haoke...@gmail.com
 ---
 v2:
   - Fix the typo in subject.
   - Fold the original patch 2 into this one.
   - Change the machine name from CORENET GENERIC to CORENET Generic.

CoreNet shouldn't be allcaps either.

 diff --git a/arch/powerpc/platforms/85xx/Kconfig 
 b/arch/powerpc/platforms/85xx/Kconfig
 index de2eb93..3bee943 100644
 --- a/arch/powerpc/platforms/85xx/Kconfig
 +++ b/arch/powerpc/platforms/85xx/Kconfig
 @@ -228,6 +228,7 @@ config P2041_RDB
   select GPIO_MPC8XXX
   select HAS_RAPIDIO
   select PPC_EPAPR_HV_PIC
 + select CORENET_GENERIC
   help
 This option enables support for the P2041 RDB board
  
 @@ -241,6 +242,7 @@ config P3041_DS
   select GPIO_MPC8XXX
   select HAS_RAPIDIO
   select PPC_EPAPR_HV_PIC
 + select CORENET_GENERIC
   help
 This option enables support for the P3041 DS board
  
 @@ -254,6 +256,7 @@ config P4080_DS
   select GPIO_MPC8XXX
   select HAS_RAPIDIO
   select PPC_EPAPR_HV_PIC
 + select CORENET_GENERIC
   help
 This option enables support for the P4080 DS board

As discussed earlier, I'd prefer if this were combined into one kconfig
option.  The help text can list boards that are known to work with it.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property

2013-09-23 Thread Scott Wood 
On Tue, 2013-09-17 at 06:06 -0500, Hu Mingkai-B21284 wrote:
 Scott,
 Sorry for the delayed response.
 Please fine my comments.
 Thanks,
 Mingkai
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Thursday, September 12, 2013 9:16 AM
  To: Hu Mingkai-B21284
  Cc: Wood Scott-B07421; linuxppc-...@ozlabs.org
  Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI partitions
  property
  
  On Tue, 2013-09-10 at 21:07 -0500, Hu Mingkai-B21284 wrote:
  
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, September 11, 2013 7:33 AM
To: Hu Mingkai-B21284
Cc: linuxppc-...@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: DTS - re-organize the SPI
partitions property
   
What happens to exsting users whose flash is laid out the existing
way, when they upgrade to these device trees?
   
  
   The SPI flash layout should be mapping the new device tree.
  
   If the existing device tree is used to deploy the SPI flash, the
   following issues must be run into as the commit message described:
  
   1. Kernel images would be overlapped with U-Boot image.
   2. Kernel images would be overlapped with FMAN ucode.
   3. Saving environment variables will crash the kernel image.
  
  Has the SPI U-Boot image always been larger than 512K for all these
  platforms?  Why, given that we're under 512K for other boot modes?
  
 
 For DPAA platform, the ld script used to link the u-boot image is 
 ./arch/powerpc/cpu/mpc85xx/u-boot.lds which will generate the 512K u-boot
 Image. This image will be split into 64bytes and appended PBL command for 
 Each 64bytes pieces, so the size of final image must be greater than 512K.

What is the entry point in SRAM when you load from PBL?  If it is (or
can be made to be) the beginning of the image rather than the end, then
turn off the resetvec and the fixed image size that results.

We really should not be putting partition layout info in the device
tree to begin with...
   
   OK, I will remove the layout diagram in the commit message.
  
  That's not what I meant.  I meant that the dts should be describing
  hardware, and this is the sort of trouble we run into when we deviate
  from that.  A better way would be to use the mtdparts command line option.
  Even better would be some sort of on-flash partition table.
  
 
 You're right, but maybe some customer has already used the device tree 
 partition table...

My main point was to encourage us to shift away from this rather than to
rip it out right this instant.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] powerpc/85xx: introduce corenet_generic machine

2013-09-23 Thread Kevin Hao 
On Mon, Sep 23, 2013 at 05:33:58PM -0500, Scott Wood wrote:
 On Sun, 2013-09-22 at 15:42 +0800, Kevin Hao wrote:
  In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
  p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
  machine name. So this introduces a cornet_generic machine to support
  all these boards to avoid the code duplication.
  
  With these changes the file corenet_ds.h becomes useless. Just delete
  it.
  
  Signed-off-by: Kevin Hao haoke...@gmail.com
  ---
  v2:
- Fix the typo in subject.
- Fold the original patch 2 into this one.
- Change the machine name from CORENET GENERIC to CORENET Generic.
 
 CoreNet shouldn't be allcaps either.

OK. Will change it to CoreNet Generic.

 
  diff --git a/arch/powerpc/platforms/85xx/Kconfig 
  b/arch/powerpc/platforms/85xx/Kconfig
  index de2eb93..3bee943 100644
  --- a/arch/powerpc/platforms/85xx/Kconfig
  +++ b/arch/powerpc/platforms/85xx/Kconfig
  @@ -228,6 +228,7 @@ config P2041_RDB
  select GPIO_MPC8XXX
  select HAS_RAPIDIO
  select PPC_EPAPR_HV_PIC
  +   select CORENET_GENERIC
  help
This option enables support for the P2041 RDB board
   
  @@ -241,6 +242,7 @@ config P3041_DS
  select GPIO_MPC8XXX
  select HAS_RAPIDIO
  select PPC_EPAPR_HV_PIC
  +   select CORENET_GENERIC
  help
This option enables support for the P3041 DS board
   
  @@ -254,6 +256,7 @@ config P4080_DS
  select GPIO_MPC8XXX
  select HAS_RAPIDIO
  select PPC_EPAPR_HV_PIC
  +   select CORENET_GENERIC
  help
This option enables support for the P4080 DS board
 
 As discussed earlier, I'd prefer if this were combined into one kconfig
 option.  The help text can list boards that are known to work with it.

OK, will do.

Thanks,
Kevin
 
 -Scott
 
 
 


pgpUKUYTFYwX4.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/3] powerpc/85xx: introduce corenet_generic machine

2013-09-23 Thread Kevin Hao 
v3:
  - Update the patch 1 according to Scoot's comment.
  - Introduce one new patch to combine the board kernel options into one.

v2:
  - Fold the original patch 2 into patch 1.
  - Update the patch 1 according to Scott and Kumar's comments.
  - Introduce a new patch to rename the corenet_ds.c to corenet_generic.c.

v1:
This patch series introduces a common machine to support p2041rdb, p3041ds,
p4080ds, p5020ds, p5040ds, t4240qds and b4qds to avoid the code duplication.
Boot test on p5020ds and p4080ds.

Kevin Hao (3):
  powerpc/85xx: introduce corenet_generic machine
  powerpc/85xx: rename the corenet_ds.c to corenet_generic.c
  powerpc/85xx: use one kernel option for all the CoreNet_Generic boards

 arch/powerpc/configs/corenet32_smp_defconfig  |   6 +-
 arch/powerpc/configs/corenet64_smp_defconfig  |   5 +-
 arch/powerpc/configs/ppc64e_defconfig |   2 +-
 arch/powerpc/platforms/85xx/Kconfig   |  87 ++--
 arch/powerpc/platforms/85xx/Makefile  |   8 +-
 arch/powerpc/platforms/85xx/b4_qds.c  |  97 --
 arch/powerpc/platforms/85xx/corenet_ds.c  |  96 --
 arch/powerpc/platforms/85xx/corenet_ds.h  |  19 ---
 arch/powerpc/platforms/85xx/corenet_generic.c | 182 ++
 arch/powerpc/platforms/85xx/p2041_rdb.c   |  87 
 arch/powerpc/platforms/85xx/p3041_ds.c|  89 -
 arch/powerpc/platforms/85xx/p4080_ds.c|  87 
 arch/powerpc/platforms/85xx/p5020_ds.c|  93 -
 arch/powerpc/platforms/85xx/p5040_ds.c|  84 
 arch/powerpc/platforms/85xx/t4240_qds.c   |  93 -
 15 files changed, 195 insertions(+), 840 deletions(-)
 delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
 delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h
 create mode 100644 arch/powerpc/platforms/85xx/corenet_generic.c
 delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
 delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c

-- 
1.8.3.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 1/3] powerpc/85xx: introduce corenet_generic machine

2013-09-23 Thread Kevin Hao 
In the current kernel, the board files for p2041rdb, p3041ds, p4080ds,
p5020ds, p5040ds, t4240qds and b4qds are almost the same except the
machine name. So this introduces a cornet_generic machine to support
all these boards to avoid the code duplication.

With these changes the file corenet_ds.h becomes useless. Just delete
it.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v3:
  - Change the machine name from CORENET Generic to CoreNet Generic.

v2:
  - Fix the typo in subject.
  - Fold the original patch 2 into this one.
  - Change the machine name from CORENET GENERIC to CORENET Generic.

v1:
  - This patch is based on http://patchwork.ozlabs.org/patch/274390/

 arch/powerpc/platforms/85xx/Kconfig  | 10 
 arch/powerpc/platforms/85xx/Makefile |  8 +--
 arch/powerpc/platforms/85xx/b4_qds.c | 97 
 arch/powerpc/platforms/85xx/corenet_ds.c | 86 
 arch/powerpc/platforms/85xx/corenet_ds.h | 19 ---
 arch/powerpc/platforms/85xx/p2041_rdb.c  | 87 
 arch/powerpc/platforms/85xx/p3041_ds.c   | 89 -
 arch/powerpc/platforms/85xx/p4080_ds.c   | 87 
 arch/powerpc/platforms/85xx/p5020_ds.c   | 93 --
 arch/powerpc/platforms/85xx/p5040_ds.c   | 84 ---
 arch/powerpc/platforms/85xx/t4240_qds.c  | 93 --
 11 files changed, 97 insertions(+), 656 deletions(-)
 delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
 delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h
 delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
 delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
 delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c

diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index de2eb93..3bee943 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -228,6 +228,7 @@ config P2041_RDB
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the P2041 RDB board
 
@@ -241,6 +242,7 @@ config P3041_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the P3041 DS board
 
@@ -254,6 +256,7 @@ config P4080_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the P4080 DS board
 
@@ -278,6 +281,7 @@ config P5020_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the P5020 DS board
 
@@ -292,6 +296,7 @@ config P5040_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the P5040 DS board
 
@@ -323,6 +328,7 @@ config T4240_QDS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the T4240 QDS board
 
@@ -337,6 +343,7 @@ config B4_QDS
select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+   select CORENET_GENERIC
help
  This option enables support for the B4 QDS board
  The B4 application development system B4 QDS is a complete
@@ -348,3 +355,6 @@ endif # FSL_SOC_BOOKE
 
 config TQM85xx
bool
+
+config CORENET_GENERIC
+   bool
diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index 53c9f75..a6c281d 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,13 +18,7 @@ obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
 obj-$(CONFIG_P1022_DS)+= p1022_ds.o
 obj-$(CONFIG_P1022_RDK)   += p1022_rdk.o
 obj-$(CONFIG_P1023_RDS)   += p1023_rds.o
-obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o corenet_ds.o
-obj-$(CONFIG_P3041_DS)+= p3041_ds.o corenet_ds.o
-obj-$(CONFIG_P4080_DS)+= p4080_ds.o corenet_ds.o
-obj-$(CONFIG_P5020_DS)+= p5020_ds.o corenet_ds.o
-obj-$(CONFIG_P5040_DS)+= p5040_ds.o corenet_ds.o
-obj-$(CONFIG_T4240_QDS)   += t4240_qds.o corenet_ds.o
-obj-$(CONFIG_B4_QDS) += b4_qds.o corenet_ds.o
+obj-$(CONFIG_CORENET_GENERIC)   += corenet_ds.o
 obj-$(CONFIG_STX_GP3)+= stx_gp3.o
 obj-$(CONFIG_TQM85xx)+= tqm85xx.o
 obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/b4_qds.c

[PATCH v3 2/3] powerpc/85xx: rename the corenet_ds.c to corenet_generic.c

2013-09-23 Thread Kevin Hao 
This file is also used by some RDB and QDS boards. So the name seems
not so accurate. Rename it to corenet_generic.c. Also update the
function names in this file according to the change.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
v3: No change.

v2: A new patch in v2.

 arch/powerpc/platforms/85xx/Makefile |  2 +-
 .../platforms/85xx/{corenet_ds.c = corenet_generic.c}   | 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)
 rename arch/powerpc/platforms/85xx/{corenet_ds.c = corenet_generic.c} (93%)

diff --git a/arch/powerpc/platforms/85xx/Makefile 
b/arch/powerpc/platforms/85xx/Makefile
index a6c281d..dd4c0b5 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
 obj-$(CONFIG_P1022_DS)+= p1022_ds.o
 obj-$(CONFIG_P1022_RDK)   += p1022_rdk.o
 obj-$(CONFIG_P1023_RDS)   += p1023_rds.o
-obj-$(CONFIG_CORENET_GENERIC)   += corenet_ds.o
+obj-$(CONFIG_CORENET_GENERIC)   += corenet_generic.o
 obj-$(CONFIG_STX_GP3)+= stx_gp3.o
 obj-$(CONFIG_TQM85xx)+= tqm85xx.o
 obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
similarity index 93%
rename from arch/powerpc/platforms/85xx/corenet_ds.c
rename to arch/powerpc/platforms/85xx/corenet_generic.c
index 8e0285a..fbd871e 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -32,7 +32,7 @@
 #include sysdev/fsl_pci.h
 #include smp.h
 
-void __init corenet_ds_pic_init(void)
+void __init corenet_gen_pic_init(void)
 {
struct mpic *mpic;
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
@@ -50,7 +50,7 @@ void __init corenet_ds_pic_init(void)
 /*
  * Setup the architecture
  */
-void __init corenet_ds_setup_arch(void)
+void __init corenet_gen_setup_arch(void)
 {
mpc85xx_smp_init();
 
@@ -91,7 +91,7 @@ static const struct of_device_id of_device_ids[] = {
{}
 };
 
-int __init corenet_ds_publish_devices(void)
+int __init corenet_gen_publish_devices(void)
 {
return of_platform_bus_probe(NULL, of_device_ids, NULL);
 }
@@ -159,8 +159,8 @@ static int __init corenet_generic_probe(void)
 define_machine(corenet_generic) {
.name   = CoreNet Generic,
.probe  = corenet_generic_probe,
-   .setup_arch = corenet_ds_setup_arch,
-   .init_IRQ   = corenet_ds_pic_init,
+   .setup_arch = corenet_gen_setup_arch,
+   .init_IRQ   = corenet_gen_pic_init,
 #ifdef CONFIG_PCI
.pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
 #endif
@@ -175,7 +175,7 @@ define_machine(corenet_generic) {
 #endif
 };
 
-machine_arch_initcall(corenet_generic, corenet_ds_publish_devices);
+machine_arch_initcall(corenet_generic, corenet_gen_publish_devices);
 
 #ifdef CONFIG_SWIOTLB
 machine_arch_initcall(corenet_generic, swiotlb_setup_bus_notifier);
-- 
1.8.3.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 3/3] powerpc/85xx: use one kernel option for all the CoreNet_Generic boards

2013-09-23 Thread Kevin Hao 
Currently all these boards use the same machine struct and also select
the same kernel options, so it seems a bit of redundant to keep one
separate kernel option for each board. Also update the defconfigs
according to this change.

Signed-off-by: Kevin Hao haoke...@gmail.com
---
A new patch in v3.

 arch/powerpc/configs/corenet32_smp_defconfig |  6 +-
 arch/powerpc/configs/corenet64_smp_defconfig |  5 +-
 arch/powerpc/configs/ppc64e_defconfig|  2 +-
 arch/powerpc/platforms/85xx/Kconfig  | 97 +++-
 4 files changed, 12 insertions(+), 98 deletions(-)

diff --git a/arch/powerpc/configs/corenet32_smp_defconfig 
b/arch/powerpc/configs/corenet32_smp_defconfig
index 3dfab4c..1d9cb29 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -23,11 +23,7 @@ CONFIG_MODVERSIONS=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_MAC_PARTITION=y
-CONFIG_P2041_RDB=y
-CONFIG_P3041_DS=y
-CONFIG_P4080_DS=y
-CONFIG_P5020_DS=y
-CONFIG_P5040_DS=y
+CONFIG_CORENET_GENERIC=y
 CONFIG_HIGHMEM=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_BINFMT_MISC=m
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig 
b/arch/powerpc/configs/corenet64_smp_defconfig
index fa94fb3..63508dd 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -21,10 +21,7 @@ CONFIG_MODVERSIONS=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_MAC_PARTITION=y
-CONFIG_B4_QDS=y
-CONFIG_P5020_DS=y
-CONFIG_P5040_DS=y
-CONFIG_T4240_QDS=y
+CONFIG_CORENET_GENERIC=y
 # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
 CONFIG_BINFMT_MISC=m
 CONFIG_MATH_EMULATION=y
diff --git a/arch/powerpc/configs/ppc64e_defconfig 
b/arch/powerpc/configs/ppc64e_defconfig
index 0085dc4..0a6be6d 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -23,7 +23,7 @@ CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_MAC_PARTITION=y
 CONFIG_EFI_PARTITION=y
-CONFIG_P5020_DS=y
+CONFIG_CORENET_GENERIC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=y
 CONFIG_CPU_FREQ_GOV_USERSPACE=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index 3bee943..04456fb 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -218,36 +218,8 @@ config GE_IMP3A
  This board is a 3U CompactPCI Single Board Computer with a Freescale
  P2020 processor.
 
-config P2041_RDB
-   bool Freescale P2041 RDB
-   select DEFAULT_UIMAGE
-   select PPC_E500MC
-   select PHYS_64BIT
-   select SWIOTLB
-   select ARCH_REQUIRE_GPIOLIB
-   select GPIO_MPC8XXX
-   select HAS_RAPIDIO
-   select PPC_EPAPR_HV_PIC
-   select CORENET_GENERIC
-   help
- This option enables support for the P2041 RDB board
-
-config P3041_DS
-   bool Freescale P3041 DS
-   select DEFAULT_UIMAGE
-   select PPC_E500MC
-   select PHYS_64BIT
-   select SWIOTLB
-   select ARCH_REQUIRE_GPIOLIB
-   select GPIO_MPC8XXX
-   select HAS_RAPIDIO
-   select PPC_EPAPR_HV_PIC
-   select CORENET_GENERIC
-   help
- This option enables support for the P3041 DS board
-
-config P4080_DS
-   bool Freescale P4080 DS
+config CORENET_GENERIC
+   bool Freescale CoreNet Generic
select DEFAULT_UIMAGE
select PPC_E500MC
select PHYS_64BIT
@@ -256,50 +228,20 @@ config P4080_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
-   select CORENET_GENERIC
help
- This option enables support for the P4080 DS board
+ This option enables support for the P2041 RDB, P3041 DS, P4080 DS, 
P5020 DS
+ and P5040 DS boards
 
 config SGY_CTS1000
tristate Servergy CTS-1000 support
select GPIOLIB
select OF_GPIO
-   depends on P4080_DS
+   depends on CORENET_GENERIC
help
  Enable this to support functionality in Servergy's CTS-1000 systems.
 
 endif # PPC32
 
-config P5020_DS
-   bool Freescale P5020 DS
-   select DEFAULT_UIMAGE
-   select E500
-   select PPC_E500MC
-   select PHYS_64BIT
-   select SWIOTLB
-   select ARCH_REQUIRE_GPIOLIB
-   select GPIO_MPC8XXX
-   select HAS_RAPIDIO
-   select PPC_EPAPR_HV_PIC
-   select CORENET_GENERIC
-   help
- This option enables support for the P5020 DS board
-
-config P5040_DS
-   bool Freescale P5040 DS
-   select DEFAULT_UIMAGE
-   select E500
-   select PPC_E500MC
-   select PHYS_64BIT
-   select SWIOTLB
-   select ARCH_REQUIRE_GPIOLIB
-   select GPIO_MPC8XXX
-   select HAS_RAPIDIO
-   select PPC_EPAPR_HV_PIC
-   select CORENET_GENERIC
-   help
- This option enables support for the P5040 DS board
-
 config PPC_QEMU_E500
bool QEMU generic e500

[PATCH] powerpc: Remove ksp_limit on ppc64

2013-09-23 Thread Benjamin Herrenschmidt 
We've been keeping that field in thread_struct for a while, it contains
the limit of the current stack pointer and is meant to be used for
detecting stack overflows.

It has a few problems however:

 - First, it was never actually *used* on 64-bit. Set and updated but
not actually exploited

 - When switching stack to/from irq and softirq stacks, it's update
is racy unless we hard disable interrupts, which is costly. This
is fine on 32-bit as we don't soft-disable there but not on 64-bit.

Thus rather than fixing 2 in order to implement 1 in some hypothetical
future, let's remove the code completely from 64-bit. In order to avoid
a clutter of ifdef's, we remove the updates from C code completely
during interrupt stack switching, and instead maintain it from the
asm helper that is used to do the stack switching in the first place.

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---

Applies on top of powerpc/irq: Run softirqs off the top of the irq stack

 arch/powerpc/include/asm/processor.h |  4 +---
 arch/powerpc/kernel/asm-offsets.c|  3 ++-
 arch/powerpc/kernel/irq.c| 12 
 arch/powerpc/kernel/misc_32.S| 16 
 arch/powerpc/kernel/process.c|  3 ++-
 arch/powerpc/lib/sstep.c |  3 ++-
 6 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index e378ccc..ce4de5a 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -149,8 +149,6 @@ typedef struct {
 
 struct thread_struct {
unsigned long   ksp;/* Kernel stack pointer */
-   unsigned long   ksp_limit;  /* if ksp = ksp_limit stack overflow */
-
 #ifdef CONFIG_PPC64
unsigned long   ksp_vsid;
 #endif
@@ -162,6 +160,7 @@ struct thread_struct {
 #endif
 #ifdef CONFIG_PPC32
void*pgdir; /* root of page-table tree */
+   unsigned long   ksp_limit;  /* if ksp = ksp_limit stack overflow */
 #endif
 #ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
@@ -321,7 +320,6 @@ struct thread_struct {
 #else
 #define INIT_THREAD  { \
.ksp = INIT_SP, \
-   .ksp_limit = INIT_SP_LIMIT, \
.regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \
.fs = KERNEL_DS, \
.fpr = {{0}}, \
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index d8958be..502c7a4 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -80,10 +80,11 @@ int main(void)
DEFINE(TASKTHREADPPR, offsetof(struct task_struct, thread.ppr));
 #else
DEFINE(THREAD_INFO, offsetof(struct task_struct, stack));
+   DEFINE(THREAD_INFO_GAP, _ALIGN_UP(sizeof(struct thread_info), 16));
+   DEFINE(KSP_LIMIT, offsetof(struct thread_struct, ksp_limit));
 #endif /* CONFIG_PPC64 */
 
DEFINE(KSP, offsetof(struct thread_struct, ksp));
-   DEFINE(KSP_LIMIT, offsetof(struct thread_struct, ksp_limit));
DEFINE(PT_REGS, offsetof(struct thread_struct, regs));
 #ifdef CONFIG_BOOKE
DEFINE(THREAD_NORMSAVES, offsetof(struct thread_struct, normsave[0]));
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 2234a12..57d286a 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -496,7 +496,6 @@ void do_IRQ(struct pt_regs *regs)
 {
struct pt_regs *old_regs = set_irq_regs(regs);
struct thread_info *curtp, *irqtp;
-   unsigned long saved_sp_limit;
 
/* Switch to the irq stack to handle this */
curtp = current_thread_info();
@@ -509,12 +508,6 @@ void do_IRQ(struct pt_regs *regs)
return;
}
 
-   /* Adjust the stack limit */
-   saved_sp_limit = current-thread.ksp_limit;
-   current-thread.ksp_limit = (unsigned long)irqtp +
-   _ALIGN_UP(sizeof(struct thread_info), 16);
-
-
/* Prepare the thread_info in the irq stack */
irqtp-task = curtp-task;
irqtp-flags = 0;
@@ -526,7 +519,6 @@ void do_IRQ(struct pt_regs *regs)
call_do_irq(regs, irqtp);
 
/* Restore stack limit */
-   current-thread.ksp_limit = saved_sp_limit;
irqtp-task = NULL;
 
/* Copy back updates to the thread_info */
@@ -604,16 +596,12 @@ void irq_ctx_init(void)
 static inline void do_softirq_onstack(void)
 {
struct thread_info *curtp, *irqtp;
-   unsigned long saved_sp_limit = current-thread.ksp_limit;
 
curtp = current_thread_info();
irqtp = softirq_ctx[smp_processor_id()];
irqtp-task = curtp-task;
irqtp-flags = 0;
-   current-thread.ksp_limit = (unsigned long)irqtp +
-   _ALIGN_UP(sizeof(struct thread_info), 16);
call_do_softirq(irqtp);
-   current-thread.ksp_limit = saved_sp_limit;
irqtp-task = NULL;
 
/* Set any flag that may have been set on the
diff --git

[PATCH v2] powerpc/irq: Run softirqs off the top of the irq stack

2013-09-23 Thread Benjamin Herrenschmidt 
Nowadays, irq_exit() calls __do_softirq() pretty much directly
instead of calling do_softirq() which switches to the decicated
softirq stack.

This has lead to observed stack overflows on powerpc since we call
irq_enter() and irq_exit() outside of the scope that switches to
the irq stack.

This fixes it by moving the stack switching up a level, making
irq_enter() and irq_exit() run off the irq stack.

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

v2: Garbage collect now empty handle_one_irq()

---
 arch/powerpc/include/asm/irq.h |   4 +-
 arch/powerpc/kernel/irq.c  | 104 -
 arch/powerpc/kernel/misc_32.S  |   9 ++--
 arch/powerpc/kernel/misc_64.S  |  10 ++--
 4 files changed, 62 insertions(+), 65 deletions(-)

diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0e40843..41f13ce 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -69,9 +69,9 @@ extern struct thread_info *softirq_ctx[NR_CPUS];
 
 extern void irq_ctx_init(void);
 extern void call_do_softirq(struct thread_info *tp);
-extern int call_handle_irq(int irq, void *p1,
-  struct thread_info *tp, void *func);
+extern void call_do_irq(struct pt_regs *regs, struct thread_info *tp);
 extern void do_IRQ(struct pt_regs *regs);
+extern void __do_irq(struct pt_regs *regs);
 
 int irq_choose_cpu(const struct cpumask *mask);
 
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index c69440c..2234a12 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -441,50 +441,6 @@ void migrate_irqs(void)
 }
 #endif
 
-static inline void handle_one_irq(unsigned int irq)
-{
-   struct thread_info *curtp, *irqtp;
-   unsigned long saved_sp_limit;
-   struct irq_desc *desc;
-
-   desc = irq_to_desc(irq);
-   if (!desc)
-   return;
-
-   /* Switch to the irq stack to handle this */
-   curtp = current_thread_info();
-   irqtp = hardirq_ctx[smp_processor_id()];
-
-   if (curtp == irqtp) {
-   /* We're already on the irq stack, just handle it */
-   desc-handle_irq(irq, desc);
-   return;
-   }
-
-   saved_sp_limit = current-thread.ksp_limit;
-
-   irqtp-task = curtp-task;
-   irqtp-flags = 0;
-
-   /* Copy the softirq bits in preempt_count so that the
-* softirq checks work in the hardirq context. */
-   irqtp-preempt_count = (irqtp-preempt_count  ~SOFTIRQ_MASK) |
-  (curtp-preempt_count  SOFTIRQ_MASK);
-
-   current-thread.ksp_limit = (unsigned long)irqtp +
-   _ALIGN_UP(sizeof(struct thread_info), 16);
-
-   call_handle_irq(irq, desc, irqtp, desc-handle_irq);
-   current-thread.ksp_limit = saved_sp_limit;
-   irqtp-task = NULL;
-
-   /* Set any flag that may have been set on the
-* alternate stack
-*/
-   if (irqtp-flags)
-   set_bits(irqtp-flags, curtp-flags);
-}
-
 static inline void check_stack_overflow(void)
 {
 #ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -501,9 +457,9 @@ static inline void check_stack_overflow(void)
 #endif
 }
 
-void do_IRQ(struct pt_regs *regs)
+void __do_irq(struct pt_regs *regs)
 {
-   struct pt_regs *old_regs = set_irq_regs(regs);
+   struct irq_desc *desc;
unsigned int irq;
 
irq_enter();
@@ -519,18 +475,64 @@ void do_IRQ(struct pt_regs *regs)
 */
irq = ppc_md.get_irq();
 
-   /* We can hard enable interrupts now */
+   /* We can hard enable interrupts now to allow perf interrupts */
may_hard_irq_enable();
 
/* And finally process it */
-   if (irq != NO_IRQ)
-   handle_one_irq(irq);
-   else
+   if (unlikely(irq == NO_IRQ))
__get_cpu_var(irq_stat).spurious_irqs++;
+   else {
+   desc = irq_to_desc(irq);
+   if (likely(desc))
+   desc-handle_irq(irq, desc);
+   }
 
trace_irq_exit(regs);
 
irq_exit();
+}
+
+void do_IRQ(struct pt_regs *regs)
+{
+   struct pt_regs *old_regs = set_irq_regs(regs);
+   struct thread_info *curtp, *irqtp;
+   unsigned long saved_sp_limit;
+
+   /* Switch to the irq stack to handle this */
+   curtp = current_thread_info();
+   irqtp = hardirq_ctx[raw_smp_processor_id()];
+
+   /* Already there ? */
+   if (unlikely(curtp == irqtp)) {
+   __do_irq(regs);
+   set_irq_regs(old_regs);
+   return;
+   }
+
+   /* Adjust the stack limit */
+   saved_sp_limit = current-thread.ksp_limit;
+   current-thread.ksp_limit = (unsigned long)irqtp +
+   _ALIGN_UP(sizeof(struct thread_info), 16);
+
+
+   /* Prepare the thread_info in the irq stack */
+   irqtp-task = curtp-task;
+   irqtp-flags = 0;
+
+   /* Copy the preempt_count so that the [soft]irq checks work. */
+