Re: Which microcode patch for MPC870?
Which microcode patch should be selected for MPC870? In the old 2.4 kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I believe USB microcode is irrelevant here. So it comes down the other two choices. Of course do I really need the patch? My board has I2C and SMC1, but no SPI. I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the following compilation error: These errors were fixed by http://patchwork.ozlabs.org/patch/58262/ and http://patchwork.ozlabs.org/patch/58263/ Thanks a lot for the info, Anton. Then the question is which patch should be selected. I don't enable any patch and the SMC UART works properly. Next I'm going to enable I2C but I don't know whether a microcode patch is required or not. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ramdisk size is larger than 4MB
One way to lift this limitation is to relocate the bootwrapper to somewhere else, say for example, 0x100 so that a 16MB initramfs can be loaded. If the bootwrapper is relocated, what else would be affected by this relocation? It should be fine to just change it locally. It would be a problem to change it upstream for all boards, since some supported boards have only 16MB (or even 8MB) of RAM. I'll definitely try to change it locally first. Would a configurable base address for the bootwrapper an acceptable solution? Another option is to provide a vmlinux_alloc callback to stick the kernel somewhere other than zero, at the cost of an extra image copy once the kernel runs to get itself back down to zero. This wasn't done in cuboot because it was considered better to adjust the bootwrapper link address at build time based on the kernel+ramfs image size, but that never got implemented. Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if the image fits there, and calls malloc otherwise? I'll look into this too. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
create_proc_read_entry() may fail, if so return -ENOMEM.
Signed-off-by: Kulikov Vasiliy sego...@gmail.com
---
drivers/usb/gadget/fsl_udc_core.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 08a9a62..c3d1545 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2128,7 +2128,7 @@ static int fsl_proc_read(char *page, char **start, off_t
off, int count,
#else /* !CONFIG_USB_GADGET_DEBUG_FILES */
-#define create_proc_file() do {} while (0)
+#define create_proc_file() ({ (void *)1; })
#define remove_proc_file() do {} while (0)
#endif /* CONFIG_USB_GADGET_DEBUG_FILES */
@@ -2373,9 +2373,14 @@ static int __init fsl_udc_probe(struct platform_device
*pdev)
ret = -ENOMEM;
goto err_unregister;
}
- create_proc_file();
+ if (create_proc_file() == 0) {
+ ret = -ENOMEM;
+ goto err_pool;
+ }
return 0;
+err_pool:
+ dma_pool_destroy(udc_controller-td_pool);
err_unregister:
device_unregister(udc_controller-gadget.dev);
err_free_irq:
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote: This set of patches de-couples the idea that there is a single directory in sysfs for each memory section. The intent of the patches is to reduce the number of sysfs directories created to resolve a boot-time performance issue. On very large systems boot time are getting very long (as seen on powerpc hardware) due to the enormous number of sysfs directories being created. On a system with 1 TB of memory we create ~63,000 directories. For even larger systems boot times are being measured in hours. Greg, Kame, how do we proceed with these ? I'm happy to put them in powerpc.git with appropriate acks or will you take them ? I thought there would be at least one more round of these patches based on the review comments, right? I'll be glad to take them when everyone agrees with them. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
On Sat, 2010-07-31 at 12:55 -0700, Greg KH wrote: On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote: This set of patches de-couples the idea that there is a single directory in sysfs for each memory section. The intent of the patches is to reduce the number of sysfs directories created to resolve a boot-time performance issue. On very large systems boot time are getting very long (as seen on powerpc hardware) due to the enormous number of sysfs directories being created. On a system with 1 TB of memory we create ~63,000 directories. For even larger systems boot times are being measured in hours. Greg, Kame, how do we proceed with these ? I'm happy to put them in powerpc.git with appropriate acks or will you take them ? I thought there would be at least one more round of these patches based on the review comments, right? Yes, but I was nontheless inquiring whether I should pick them up after said repost :-) I'll be glad to take them when everyone agrees with them. Ok, good, one less thing to worry about in powerpc patchwork :-) Cheers, Ben. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On 26 Jun 2010, at 00:04, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Jun 22, 2010 at 5:00 PM, Mark Brown On Tue, Jun 15, 2010 at 12:05:05PM -0400, Eric Millbrandt wrote: These patches reimplement the reset fuction in the ac97 to use gpio pins instead of using the mpc5200 ac97 reset functionality in the psc. This avoids a problem in which attached ac97 devices go into test mode appear unresponsive. These patches were tested on a pcm030 baseboard and on custom hardware with a wm9715 audio codec/touchscreen controller. Grant, are you OK with this series? Yes, I'm going to pick it up. I'm a little concerned with a collision with multi codec here. It'd be handy if you could keep it separate in case it needs merging into both trees (or we could merge via ASoC only). Hmmm. Yeah, probably better to take it via your tree then. I've currently got patch 1 in linux-next, but I'll drop it before asking benh to pull. Go ahead and add my acked-by. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
