Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code

2010-07-18 Thread Artem Bityutskiy 
On Fri, 2010-07-16 at 10:20 -0400, Josh Boyer wrote:
 On Fri, Jul 16, 2010 at 02:29:02PM +0200, Christian Dietrich wrote:
 The config options for REDWOOD_[456] were commented out in the powerpc
 Kconfig. The ifdefs referencing this options therefore are dead and all
 references to this can be removed (Also dependencies in other KConfig
 files).
 
 Signed-off-by: Christian Dietrich qy03f...@stud.informatik.uni-erlangen.de
 Signed-off-by: Christoph Egger sicce...@cs.fau.de
 
 This seems fine with me.
 
 The only question is which tree it coms through.  I'm happy to take it
 in via mine if the netdev and MTD people are fine with that.  Otherwise,
 my ack is below.
 
 Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com

You know how slow MTD people may be sometimes, so I'd suggest you to
merge this via whatever tree. David is in CC, he'll complain if he is
unhappy, I think.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

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

RE: [PATCH v2]460EX on-chip SATA driverresubmisison

2010-07-18 Thread Rupjyoti Sarmah 
Hi Sergei,

Thanks for your suggestions.
I would look into them and submit a patch for style improvement some time
later.

Regards,
Rup


-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Saturday, July 17, 2010 9:21 PM
To: Rupjyoti Sarmah
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
rsar...@apm.com; jgar...@pobox.com; s...@denx.de; linuxppc-...@ozlabs.org
Subject: Re: [PATCH v2]460EX on-chip SATA driverresubmisison

Hello.

Rupjyoti Sarmah wrote:

 This patch enables the on-chip DWC SATA controller of the AppliedMicro
processor 460EX.

Too bad thius has already been applied but here's my (mostly
stylistic)
comments anyway:

 Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com
 Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com
 Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com

[...]

 diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
 new file mode 100644
 index 000..ea24c1e
 --- /dev/null
 +++ b/drivers/ata/sata_dwc_460ex.c
 @@ -0,0 +1,1756 @@
 +/*
 + * drivers/ata/sata_dwc_460ex.c

Filenames in the heading comments have long been frowned upon.

 +#ifdef CONFIG_SATA_DWC_DEBUG

I don't see this option defined anywahere.

 +#define DEBUG
 +#endif
 +
 +#ifdef CONFIG_SATA_DWC_VDEBUG

The same about this one.

 +#define VERBOSE_DEBUG
 +#define DEBUG_NCQ
 +#endif
[...]
 +/* SATA DMA driver Globals */
 +#define DMA_NUM_CHANS1
 +#define DMA_NUM_CHAN_REGS8
 +
 +/* SATA DMA Register definitions */
 +#define AHB_DMA_BRST_DFLT64  /* 16 data items burst length*/

Please put a space before */.

 +struct ahb_dma_regs {
 + struct dma_chan_regschan_regs[DMA_NUM_CHAN_REGS];
 + struct dma_interrupt_regs interrupt_raw;/* Raw Interrupt
*/
 + struct dma_interrupt_regs interrupt_status; /* Interrupt
Status */
 + struct dma_interrupt_regs interrupt_mask;   /* Interrupt Mask
*/
 + struct dma_interrupt_regs interrupt_clear;  /* Interrupt Clear
*/
 + struct dmareg   statusInt;  /* Interrupt combined*/

No camelCase please, rename it to status_int.

 +#define  DMA_CTL_BLK_TS(size)((size)  0x00FFF)  /* Blk
Transfer size */
 +#define DMA_CHANNEL(ch)  (0x0001  (ch))/* Select
channel */
 + /* Enable channel */
 +#define  DMA_ENABLE_CHAN(ch) ((0x0001  (ch)) |
\
 +  ((0x1  (ch))  8))
 + /* Disable channel */
 +#define  DMA_DISABLE_CHAN(ch)(0x | ((0x1 
(ch))  8))

What's the point of OR'ing with zero?

 +/*
 + * Commonly used DWC SATA driver Macros
 + */
 +#define HSDEV_FROM_HOST(host)  ((struct sata_dwc_device *)\
 + (host)-private_data)
 +#define HSDEV_FROM_AP(ap)  ((struct sata_dwc_device *)\
 + (ap)-host-private_data)
 +#define HSDEVP_FROM_AP(ap)   ((struct sata_dwc_device_port *)\
 + (ap)-private_data)
 +#define HSDEV_FROM_QC(qc)((struct sata_dwc_device *)\
 + (qc)-ap-host-private_data)
 +#define HSDEV_FROM_HSDEVP(p) ((struct sata_dwc_device *)\
 + (hsdevp)-hsdev)

Are you sure it's '(hsdevp)', not '(p)'?

 +struct sata_dwc_host_priv {
 + void__iomem  *scr_addr_sstatus;
 + u32 sata_dwc_sactive_issued ;
 + u32 sata_dwc_sactive_queued ;

Remove spaces befoer semicolons, please.

 +static void sata_dwc_tf_dump(struct ata_taskfile *tf)
 +{
 + dev_vdbg(host_pvt.dwc_dev, taskfile cmd: 0x%02x protocol: %s
flags:
 + 0x%lx device: %x\n, tf-command, ata_get_cmd_descript\

There's no need to use \ outside macro defintions.

 +/*
 + * Function: get_burst_length_encode
 + * arguments: datalength: length in bytes of data
 + * returns value to be programmed in register corrresponding to data
length
 + * This value is effectively the log(base 2) of the length
 + */
 +static  int get_burst_length_encode(int datalength)
 +{
 + int items = datalength  2;/* div by 4 to get lword count */
 +
 + if (items = 64)
 + return 5;
 +
 + if (items = 32)
 + return 4;
 +
 + if (items = 16)
 + return 3;
 +
 + if (items = 8)
 + return 2;
 +
 + if (items = 4)
 + return 1;
 +
 + return 0;
 +}

Hmm, there should be a function in the kernel to calculate 2^n order
from
size, something like get_count_order()...

 +/*
 + * Function: dma_dwc_interrupt
 + * arguments: irq, dev_id, pt_regs
 + * returns channel number if available else -1
 + * Interrupt Handler for DW AHB SATA DMA
 + */
 +static irqreturn_t dma_dwc_interrupt(int irq, void *hsdev_instance)
 +{
 + int chan;
 + u32 tfr_reg, err_reg;
 + unsigned long flags;
 + struct sata_dwc_device *hsdev =
 + (struct sata_dwc_device

Re: Badness with the kernel version 2.6.35-rc1-git1 running on P6 box

2010-07-18 Thread David Miller 
From: Eric Dumazet eric.duma...@gmail.com
Date: Fri, 16 Jul 2010 14:20:42 +0200

 Le vendredi 16 juillet 2010 à 11:56 +0200, Eric Dumazet a écrit :
 
 [PATCH] ehea: ehea_get_stats() should use GFP_KERNEL
 
 ehea_get_stats() is called in process context and should use GFP_KERNEL
 allocation instead of GFP_ATOMIC.
 
 Clearing stats at beginning of ehea_get_stats() is racy in case of
 concurrent stat readers.
 
 get_stats() can also use netdev net_device_stats, instead of a private
 copy.
 
 Reported-by: divya dipra...@linux.vnet.ibm.com
 Signed-off-by: Eric Dumazet eric.duma...@gmail.com
 ---
  drivers/net/ehea/ehea.h  |1 -
  drivers/net/ehea/ehea_main.c |6 ++
  2 files changed, 2 insertions(+), 5 deletions(-)
 
 
 
 Hmm, net-next-2.6 contains following patch :

If people think ehea usage is ubiquitous enough to deserve a backport
of this to net-2.6, fine.  But personally I don't think it's worth it.

Can someone close the kernel bugzilla 16406 created for this bug?  This
patch we have already obviously would fix this issue.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

2010-07-18 Thread Benjamin Herrenschmidt 
On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
 On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock m...@freescale.com 
 wrote:
  To build a proper flat device tree for kexec we need to know which
  memreserve region was used for the device tree for the currently
  running kernel, so we can remove it and replace it with the new
  memreserve for the kexec'ed kernel
 
  Signed-off-by: Matthew McClintock m...@freescale.com
 
 Hi Matthew.
 
 I don't understand.  Why does userspace need to know about the old
 memreserve sections?  Doesn't kexec tear down all of the old
 allocations anyway?  How are they relevant for constructing the dtb
 for the kexec kernel?  I'll need a lot more details before I consider
 merging this.
 
 Also, please cc: me and Ben Herrenschmidt on powerpc related device
 tree changes.

I admit to be the victim of a similar misunderstanding...

Care to explain in more details ? (with examples)

Cheers,
Ben.

 Cheers,
 g.
 
  ---
  V4: Fixed misspelling
 
  V3: Remove unneeded cast, and fixed indentation screw up
 
  V2: messed up changes
 
   arch/powerpc/kernel/prom.c |   45 
  
   1 files changed, 45 insertions(+), 0 deletions(-)
 
  diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
  index fd9359a..ff3e240 100644
  --- a/arch/powerpc/kernel/prom.c
  +++ b/arch/powerpc/kernel/prom.c
  @@ -32,6 +32,7 @@
   #include linux/debugfs.h
   #include linux/irq.h
   #include linux/lmb.h
  +#include linux/bootmem.h
 
   #include asm/prom.h
   #include asm/rtas.h
  @@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
   }
   __initcall(export_flat_device_tree);
   #endif
  +
  +#ifdef CONFIG_KEXEC
  +static phys_addr_t flat_dt_start;
  +static phys_addr_t flat_dt_end;
  +
  +static struct property flat_dt_start_prop = {
  +   .name = linux,devicetree-start,
  +   .length = sizeof(phys_addr_t),
  +   .value = flat_dt_start,
  +};
  +
  +static struct property flat_dt_end_prop = {
  +   .name = linux,devicetree-end,
  +   .length = sizeof(phys_addr_t),
  +   .value = flat_dt_end,
  +};
  +
  +static int __init export_flat_device_tree_phys_addr(void)
  +{
  +   struct property *prop;
  +   struct device_node *node;
  +
  +   node = of_find_node_by_path(/chosen);
  +   if (!node)
  +   return -ENOENT;
  +
  +   prop = of_find_property(node, linux,devicetree-start, NULL);
  +   if (prop)
  +   prom_remove_property(node, prop);
  +
  +   prop = of_find_property(node, linux,devicetree-end, NULL);
  +   if (prop)
  +   prom_remove_property(node, prop);
  +
  +   flat_dt_start = virt_to_phys(initial_boot_params);
  +   flat_dt_end = virt_to_phys(initial_boot_params)
  +   + initial_boot_params-totalsize;
  +   prom_add_property(node, flat_dt_start_prop);
  +   prom_add_property(node, flat_dt_end_prop);
  +
  +   return 0;
  +}
  +__initcall(export_flat_device_tree_phys_addr);
  +#endif
  --
  1.6.6.1
 
 
  ___
  Linuxppc-dev mailing list
  Linuxppc-dev@lists.ozlabs.org
  https://lists.ozlabs.org/listinfo/linuxppc-dev
 
 
 
 


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

Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code

2010-07-18 Thread Benjamin Herrenschmidt 
On Fri, 2010-07-16 at 14:29 +0200, Christian Dietrich wrote:
 The config options for REDWOOD_[456] were commented out in the powerpc
 Kconfig. The ifdefs referencing this options therefore are dead and all
 references to this can be removed (Also dependencies in other KConfig
 files).
 
 Signed-off-by: Christian Dietrich qy03f...@stud.informatik.uni-erlangen.de
 Signed-off-by: Christoph Egger sicce...@cs.fau.de

Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org

 ---
  arch/powerpc/platforms/40x/Kconfig |   16 -
  drivers/mtd/maps/Kconfig   |2 +-
  drivers/mtd/maps/redwood.c |   43 
 
  drivers/net/Kconfig|2 +-
  drivers/net/smc91x.h   |   37 ---
  5 files changed, 2 insertions(+), 98 deletions(-)
 
 diff --git a/arch/powerpc/platforms/40x/Kconfig 
 b/arch/powerpc/platforms/40x/Kconfig
 index ec64264..b721764 100644
 --- a/arch/powerpc/platforms/40x/Kconfig
 +++ b/arch/powerpc/platforms/40x/Kconfig
 @@ -71,22 +71,6 @@ config MAKALU
   help
 This option enables support for the AMCC PPC405EX board.
  
 -#config REDWOOD_5
 -#bool Redwood-5
 -#depends on 40x
 -#default n
 -#select STB03xxx
 -#help
 -#  This option enables support for the IBM STB04 evaluation board.
 -
 -#config REDWOOD_6
 -#bool Redwood-6
 -#depends on 40x
 -#default n
 -#select STB03xxx
 -#help
 -#  This option enables support for the IBM STBx25xx evaluation board.
 -
  #config SYCAMORE
  #bool Sycamore
  #depends on 40x
 diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
 index f22bc9f..6629d09 100644
 --- a/drivers/mtd/maps/Kconfig
 +++ b/drivers/mtd/maps/Kconfig
 @@ -321,7 +321,7 @@ config MTD_CFI_FLAGADM
  
  config MTD_REDWOOD
   tristate CFI Flash devices mapped on IBM Redwood
 - depends on MTD_CFI  ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
 + depends on MTD_CFI
   help
 This enables access routines for the flash chips on the IBM
 Redwood board. If you have one of these boards and would like to
 diff --git a/drivers/mtd/maps/redwood.c b/drivers/mtd/maps/redwood.c
 index 933c0b6..d2c9db0 100644
 --- a/drivers/mtd/maps/redwood.c
 +++ b/drivers/mtd/maps/redwood.c
 @@ -22,8 +22,6 @@
  
  #include asm/io.h
  
 -#if !defined (CONFIG_REDWOOD_6)
 -
  #define WINDOW_ADDR 0xffc0
  #define WINDOW_SIZE 0x0040
  
 @@ -69,47 +67,6 @@ static struct mtd_partition redwood_flash_partitions[] = {
   }
  };
  
 -#else /* CONFIG_REDWOOD_6 */
 -/* FIXME: the window is bigger - armin */
 -#define WINDOW_ADDR 0xff80
 -#define WINDOW_SIZE 0x0080
 -
 -#define RW_PART0_OF  0
 -#define RW_PART0_SZ  0x40/* 4 MiB data */
 -#define RW_PART1_OF  RW_PART0_OF + RW_PART0_SZ
 -#define RW_PART1_SZ  0x1 /* 64K VPD */
 -#define RW_PART2_OF  RW_PART1_OF + RW_PART1_SZ
 -#define RW_PART2_SZ  0x40 - (0x1 + 0x2)
 -#define RW_PART3_OF  RW_PART2_OF + RW_PART2_SZ
 -#define RW_PART3_SZ  0x2
 -
 -static struct mtd_partition redwood_flash_partitions[] = {
 - {
 - .name = Redwood filesystem,
 - .offset = RW_PART0_OF,
 - .size = RW_PART0_SZ
 - },
 - {
 - .name = Redwood OpenBIOS Vital Product Data,
 - .offset = RW_PART1_OF,
 - .size = RW_PART1_SZ,
 - .mask_flags = MTD_WRITEABLE /* force read-only */
 - },
 - {
 - .name = Redwood kernel,
 - .offset = RW_PART2_OF,
 - .size = RW_PART2_SZ
 - },
 - {
 - .name = Redwood OpenBIOS,
 - .offset = RW_PART3_OF,
 - .size = RW_PART3_SZ,
 - .mask_flags = MTD_WRITEABLE /* force read-only */
 - }
 -};
 -
 -#endif /* CONFIG_REDWOOD_6 */
 -
  struct map_info redwood_flash_map = {
   .name = IBM Redwood,
   .size = WINDOW_SIZE,
 diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
 index ce2fcdd..313d306 100644
 --- a/drivers/net/Kconfig
 +++ b/drivers/net/Kconfig
 @@ -913,7 +913,7 @@ config SMC91X
   tristate SMC 91C9x/91C1xxx support
   select CRC32
   select MII
 - depends on ARM || REDWOOD_5 || REDWOOD_6 || M32R || SUPERH || \
 + depends on ARM || M32R || SUPERH || \
   MIPS || BLACKFIN || MN10300 || COLDFIRE
   help
 This is a driver for SMC's 91x series of Ethernet chipsets,
 diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
 index 8d2772c..ee74791 100644
 --- a/drivers/net/smc91x.h
 +++ b/drivers/net/smc91x.h
 @@ -83,43 +83,6 @@ static inline void SMC_outw(u16 val, void __iomem *ioaddr, 
 int reg)
   }
  }
  
 -#elif defined(CONFIG_REDWOOD_5) || defined(CONFIG_REDWOOD_6)
 -
 -/* We can only do 16-bit reads and writes in the static memory space. */
 -#define SMC_CAN_USE_8BIT 0
 -#define SMC_CAN_USE_16BIT1
 -#define SMC_CAN_USE_32BIT0
 -#define SMC_NOWAIT   1
 -

Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

2010-07-18 Thread Benjamin Herrenschmidt 
On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
 What is your starting point?  Where does the device tree (and
 memreserve list) come from
 that you're passing to kexec?  My first impression is that if you have
 to scrub the memreserve list, then the source being used to
 obtain the memreserves is either faulty or unsuitable to the task.

The kernel should ultimately pass the thing to userspace I reckon, with
an appropriate hook for platform code to insert/recover reserved
regions.

Ben.


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

Re: linux-next: build failure after merge of the final tree (powerpc related)

2010-07-18 Thread Benjamin Herrenschmidt 
On Fri, 2010-07-16 at 17:19 +1000, Stephen Rothwell wrote:
 Hi all,
 
 After merging the final tree, today's linux-next build (powerpc
 allmodconfig) failed like this:
 
 ERROR: of_i8042_kbd_irq [drivers/input/serio/i8042.ko] undefined!
 ERROR: of_i8042_aux_irq [drivers/input/serio/i8042.ko] undefined!
 
 Presumably missing EXPORT_SYMBOLs ..

Thanks. I'll fix that up.

Cheers,
Ben.



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

Re: [PPC64/Power7 - 2.6.35-rc5] Bad relocation warnings while Building a CONFIG_RELOCATABLE kernel with CONFIG_ISERIES enabled

2010-07-18 Thread Benjamin Herrenschmidt 
On Thu, 2010-07-15 at 17:05 +0530, Subrata Modak wrote:
 commit e62cee42e66dcca83aae02748535f62e0f564a0c solved the problem for
 2.6.34-rc6. However some other bad relocation warnings generated against
 2.6.35-rc5 on Power7/ppc64 below:
 
 MODPOST 2004 modules^M
 WARNING: 2 bad relocations^M
 c0008590 R_PPC64_ADDR32.text+0x40008460^M
 c0008594 R_PPC64_ADDR32.text+0x40008598^M

I think this is KVM + CONFIG_RELOCATABLE. Caused by:

.global kvmppc_trampoline_lowmem
kvmppc_trampoline_lowmem:
.long kvmppc_handler_lowmem_trampoline - CONFIG_KERNEL_START

.global kvmppc_trampoline_enter
kvmppc_trampoline_enter:
.long kvmppc_handler_trampoline_enter - CONFIG_KERNEL_START

Alex, can you turn these into 64-bit on ppc64 so the relocator
can grok them ?

Cheers,
Ben.

 Config file attached.
 
 Regards--
 Subrata
 
 On Fri, 2010-05-07 at 15:40 +1000, Paul Mackerras wrote:
  On Wed, May 05, 2010 at 05:20:51PM +0530, Subrata Modak wrote:
  
   I built 2.6.34-rc6 with the attached Fedora Config file
   (config-2.6.33.1-19.fc13.ppc64) on my P5 Fedora Box and got the
   following warning. Is the following expected ?
   
   CALLarch/powerpc/relocs_check.pl
   Building modules, stage 2.
   WARNING: 4 bad relocations
   c007216e R_PPC64_ADDR16_HIGHEST  __ksymtab+0x009dcec8
   c0072172 R_PPC64_ADDR16_HIGHER  __ksymtab+0x009dcec8
   c007217a R_PPC64_ADDR16_HI  __ksymtab+0x009dcec8
   c007217e R_PPC64_ADDR16_LO  __ksymtab+0x009dcec8
  
  No, it's not expected.  It's in iSeries code, so you could avoid it
  just by disabling CONFIG_ISERIES (I don't think any distro still
  supports legacy iSeries).  I'll post a patch to fix the problem
  properly.
  
  Paul.
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev


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

Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

2010-07-18 Thread Matthew McClintock 

On Jul 17, 2010, at 11:41 AM, Segher Boessenkool wrote:

 Yes. Where would we get a list of memreserve sections?
 
 I would say the list of reserves that are not under the control of
 Linux should be explicitly described in the device tree proper.  For
 instance, if you have a region that firmware depends on, then have a
 node for describing the firmware and a property stating the memory
 regions that it depends on.  The memreserve regions can be generated
 from that.
 
 Ok, so we could traverse the tree node-by-bode for a
 persistent-memreserve property and add them to the /memreserve/ list in
 the kexec user space tools?
 
 I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
 David Gibson, and other device tree experts on whether or not that
 exact property naming is a good one.
 
 Let's take a step back: what exactly _are_ memreserve sections, what
 are they used for, who (kernel, firmware, bootloader, etc.) holds what
 responsibility wrt them?
 

On the platform I'm working on (mpc85xx) they can be the following:

1) Boot page (aka cpu-release-addr) - always present on MP
2) Flat Device Tree - always present
3) Initrd - optional

When kexec'ing a kernel, we will provide new memory regions for the flat device 
tree and the initrd (if present). However, all others will not be replaced by 
kexec and should either be tossed or preserved. The question is how to decide 
what to do... save them all by default? Save none of them? If we save them all 
at a minimum we need to remove/replace the device tree and initrd regions as 
well. So we need a way to identify which regions correspond to these.

Grant and I talked and though a property that lives in the device tree 
describing a persistant-memreseve might work. And Mitch talked about an 
available memory property to go along with the current one which could be used 
to determine which ranges were invalid and need a memreserve for...

-Matthew

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


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

Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

2010-07-18 Thread Matthew McClintock 
On Jul 18, 2010, at 6:41 PM, Benjamin Herrenschmidt wrote:
 On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
 On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock m...@freescale.com 
 wrote:
 To build a proper flat device tree for kexec we need to know which
 memreserve region was used for the device tree for the currently
 running kernel, so we can remove it and replace it with the new
 memreserve for the kexec'ed kernel
 
 Signed-off-by: Matthew McClintock m...@freescale.com
 
 Hi Matthew.
 
 I don't understand.  Why does userspace need to know about the old
 memreserve sections?  Doesn't kexec tear down all of the old
 allocations anyway?  How are they relevant for constructing the dtb
 for the kexec kernel?  I'll need a lot more details before I consider
 merging this.
 
 Also, please cc: me and Ben Herrenschmidt on powerpc related device
 tree changes.
 
 I admit to be the victim of a similar misunderstanding...
 
 Care to explain in more details ? (with examples)
 

Upon first examining the details of getting kexec working on our platform I 
noticed our device tree passed from u-boot contained an additional memreserve 
section for the boot page. Subsequently, I've been trying to preserve the ones 
passed in for the kexec'ed kernel thinking anyone could add anything they 
wanted for their own particular needs and would quite possibly need those 
regions preserved across reboots.

Recently, I've discovered the boot page address is given in the device tree as 
a property. So, for our platform (mpc85xx) in particular, I'm back to not 
needing the read the old memreserve sections... I can completely reconstruct 
the appropriate memreserve regions for kexec'ing from the information passed in 
the device tree.

That isn't to say there might not be more memreserve regions that are not there 
for some valid reason. I'm not sure if we need to attempt to address another 
scenario where there are other memreserve regions. So this would be a good time 
to address this issue if anyone believes it is a worthwhile pursuit to have a 
mechanism to have memreserve regions persistent across kexec'ing - or any other 
reboot.

-Matthew


 Cheers,
 Ben.
 
 Cheers,
 g.
 
 ---
 V4: Fixed misspelling
 
 V3: Remove unneeded cast, and fixed indentation screw up
 
 V2: messed up changes
 
 arch/powerpc/kernel/prom.c |   45 
 
 1 files changed, 45 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
 index fd9359a..ff3e240 100644
 --- a/arch/powerpc/kernel/prom.c
 +++ b/arch/powerpc/kernel/prom.c
 @@ -32,6 +32,7 @@
 #include linux/debugfs.h
 #include linux/irq.h
 #include linux/lmb.h
 +#include linux/bootmem.h
 
 #include asm/prom.h
 #include asm/rtas.h
 @@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
 }
 __initcall(export_flat_device_tree);
 #endif
 +
 +#ifdef CONFIG_KEXEC
 +static phys_addr_t flat_dt_start;
 +static phys_addr_t flat_dt_end;
 +
 +static struct property flat_dt_start_prop = {
 +   .name = linux,devicetree-start,
 +   .length = sizeof(phys_addr_t),
 +   .value = flat_dt_start,
 +};
 +
 +static struct property flat_dt_end_prop = {
 +   .name = linux,devicetree-end,
 +   .length = sizeof(phys_addr_t),
 +   .value = flat_dt_end,
 +};
 +
 +static int __init export_flat_device_tree_phys_addr(void)
 +{
 +   struct property *prop;
 +   struct device_node *node;
 +
 +   node = of_find_node_by_path(/chosen);
 +   if (!node)
 +   return -ENOENT;
 +
 +   prop = of_find_property(node, linux,devicetree-start, NULL);
 +   if (prop)
 +   prom_remove_property(node, prop);
 +
 +   prop = of_find_property(node, linux,devicetree-end, NULL);
 +   if (prop)
 +   prom_remove_property(node, prop);
 +
 +   flat_dt_start = virt_to_phys(initial_boot_params);
 +   flat_dt_end = virt_to_phys(initial_boot_params)
 +   + initial_boot_params-totalsize;
 +   prom_add_property(node, flat_dt_start_prop);
 +   prom_add_property(node, flat_dt_end_prop);
 +
 +   return 0;
 +}
 +__initcall(export_flat_device_tree_phys_addr);
 +#endif
 --
 1.6.6.1
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev
 
 
 
 
 
 
 


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

Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

2010-07-18 Thread Grant Likely 
On Sun, Jul 18, 2010 at 10:28 PM, Matthew McClintock m...@freescale.com wrote:
 On Jul 18, 2010, at 6:41 PM, Benjamin Herrenschmidt wrote:
 On Thu, 2010-07-15 at 00:21 -0600, Grant Likely wrote:
 On Wed, Jul 14, 2010 at 9:18 AM, Matthew McClintock m...@freescale.com 
 wrote:
 To build a proper flat device tree for kexec we need to know which
 memreserve region was used for the device tree for the currently
 running kernel, so we can remove it and replace it with the new
 memreserve for the kexec'ed kernel

 Signed-off-by: Matthew McClintock m...@freescale.com

 Hi Matthew.

 I don't understand.  Why does userspace need to know about the old
 memreserve sections?  Doesn't kexec tear down all of the old
 allocations anyway?  How are they relevant for constructing the dtb
 for the kexec kernel?  I'll need a lot more details before I consider
 merging this.

 Also, please cc: me and Ben Herrenschmidt on powerpc related device
 tree changes.

 I admit to be the victim of a similar misunderstanding...

 Care to explain in more details ? (with examples)


 Upon first examining the details of getting kexec working on our platform I 
 noticed our device tree passed from u-boot contained an additional memreserve 
 section for the boot page. Subsequently, I've been trying to preserve the 
 ones passed in for the kexec'ed kernel thinking anyone could add anything 
 they wanted for their own particular needs and would quite possibly need 
 those regions preserved across reboots.

 Recently, I've discovered the boot page address is given in the device tree 
 as a property. So, for our platform (mpc85xx) in particular, I'm back to not 
 needing the read the old memreserve sections... I can completely reconstruct 
 the appropriate memreserve regions for kexec'ing from the information passed 
 in the device tree.

 That isn't to say there might not be more memreserve regions that are not 
 there for some valid reason. I'm not sure if we need to attempt to address 
 another scenario where there are other memreserve regions. So this would be a 
 good time to address this issue if anyone believes it is a worthwhile pursuit 
 to have a mechanism to have memreserve regions persistent across kexec'ing - 
 or any other reboot.

No, we haven't needed anything to date, so no sense trying to design a
solution for a theoretical need.  Leave it be for now.

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

Re: Re: hi, i have two flashs, but my kernel can only find one , how cani write the dts?

2010-07-18 Thread Grant Likely 
On Sun, Jul 18, 2010 at 9:56 PM, hacklu embedway.t...@gmail.com wrote:

 thanks very much! it works well now~~
 but i found in my system,if i add the 0x prefix it will cause a syntax error

Ah, your dts file is in the old version 0 format.  You must be on an
older kernel, or at least haven't updated your dts file to the new
format after upgrading.

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

Re: [PATCH V4] powerpc/prom: Export device tree physical address via proc

2010-07-18 Thread Matthew McClintock 

On Jul 18, 2010, at 7:09 PM, Benjamin Herrenschmidt wrote:

 On Thu, 2010-07-15 at 10:22 -0600, Grant Likely wrote:
 What is your starting point?  Where does the device tree (and
 memreserve list) come from
 that you're passing to kexec?  My first impression is that if you have
 to scrub the memreserve list, then the source being used to
 obtain the memreserves is either faulty or unsuitable to the task.
 
 The kernel should ultimately pass the thing to userspace I reckon, with
 an appropriate hook for platform code to insert/recover reserved
 regions.
 

Or possibly in the device tree itself? As I mentioned in my previous email - my 
particular case can already be handled by the information passed in the device 
tree (as I recently discovered), is this something we would want to make 
generic for the device tree or add platform code to expose these memreserve 
regions?

-Matthew


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

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-18 Thread Grant Likely 
On Fri, Jul 16, 2010 at 5:49 PM, Jamie Lokier ja...@shareable.org wrote:
 Daniel Walker wrote:
  But all the rest is arbitrary and could be part of common shared
  profiles or the like in defconfig format.

 I'm sure most people will want to have a config isolated to their
 specific device. That to me seems reasonable because everyone wants the
 smallest possible kernel they can get for their given device.

Just to be clear (specifically for me as a maintainer) the purpose of
defconfigs is not to provide the best optimized kernel configuration
for each given board.  defconfigs are useful as a reasonable working
starting point, and to provide build coverage testing.

 Indeed, but people who want the smallest possible kernel for their
 specific device _in a particular use context_ tend to want:

  - To disable support for parts of the device they aren't using.
    For example, an SoC with integrated ethernet that isn't actually
    wired up on their board, or where they're using an external ethernet
    chip instead for some reason.

  - To choose what's modular and what isn't, even for integrated
    parts.  For example to control the bootup sequence, they might
    want to delay integrated USB and IDE initialisation, which is done by
    making those modular and loading them after bringing up a splash
    screen earlier in the boot scripts.

 So there is still a need to be able to override the drivers and
 settings, but it's still incredibly useful to have defaults which
 describe the SoC or board accurately.

Yes.  The defconfig is only a starting point.  Maintaining the actual
config for the shipped kernel is the job of the distribution vendor
and I have zero interest in maintaining those configurations in the
kernel tree.

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