Re: [PATCH 2/2] Add basic devices support for Nook Color
(adding Felipe to cc)
Felipe, can you comment on the mUSB part, please?
On 04/27/11 19:12, Oleg Drokin wrote:
Hello!
Thanks for the feedback.
On Apr 27, 2011, at 4:49 AM, Mike Rapoport wrote:
MMC/SD interface, i2c, usb.
You should have added these at the first patch instead of Android devices.
So, basically you want all board file changes to come as a single patch,
right?
I would split you series into three patches:
1) TWL updates
2) addition of board-encore
3) defconfig updates
The patch that adds board-encore would include MMC, i2c and mUSB.
---
arch/arm/configs/encore-nookcolor-defconfig | 2015
+++
The defconfig should be a separate patch. You should rather add encore board
options to omap2plus_defconfig.
Hm, ok.
+static struct i2c_board_info __initdata encore_i2c_bus2_info[] = {
+};
+
+
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
This kind of ifdefery is handled inside the musb driver. I'd set the mode to
MUSB_OTG unless you want to explicitly limit it to HOST or PERIPHERAL
Actually it's not.
If I set MUSB_OTG here and then I choose PERIPHERAL mode in the kernel config,
the musb transceiver code will complain about board file and kernel config
mismatch.
The Nook Color is advertised as peripheral device, but OTG must be working too
(not totally working at this point) I think there is value to be able to
configure it
in two different modes.
Frankly, I haven't tried choosing different modes in the kernel config and in
the board data. Still, I believe that board data should define desired operation
mode and the driver should do the best effort to enable the controller in the
desired mode.
Bye,
Oleg
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross ccr...@google.com wrote: On Wed, Apr 27, 2011 at 12:26 PM, Thomas Gleixner t...@linutronix.de wrote: Forget OMAP implementation details for a while, sit back and look at the big picture. Here's my proposal for DVFS: - DVFS is implemented in drivers/clk/dvfs.c, and is called by the common clock implementation to adjust the voltages, if necessary, on regular clk_* calls. - Platform code provides mappings in the form (clk, regulator, max frequency, min voltage) to the dvfs code. - Everything that is in OPP today gets converted to helper functions inside the dvfs implementation, and is never called from SoC code (except to pass tables at init), or from drivers. - OPP can be recreated in the future as a upper level policy manager for clocks that need to move together, if that is ever necessary. It would not know anything about voltages. - A few common policy implementations need to be added to the common clock implementation, like temperature limits. I hope that my previous reply answered this. For Tegra: - DVFS continues to be accessed by calling clk_* functions For OMAP: - DVFS is triggered by hwmod through clk_* functions. Any cross-arch driver can continue to call clk_* functions. OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. We need them in runtime. A device a may want to guarantee that a device b to be at least 200MHz or faster while it does some operations. Then, a will opp_disable(b, 100MHz and others); and opp_enable(b, them) later on. We have similar issues with multimedia blocks (MFC, Camera, FB, GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay on catching up a workload (1.5x the sampling rate in average, 2.0x the sampling rate in worst cases), which may incur flickering/tearing issues with multimedia streams. On the other hand, a general thermal monitor or battery manager might want to limit energy usage by disabling top performance clocks if it is too hot or the battery level is low. ___ linux-pm mailing list linux...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- MyungJoo Ham (함명주), Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
* Nicolas Pitre nicolas.pi...@linaro.org [110428 01:12]: On Wed, 27 Apr 2011, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110427 05:44]: We can't overwrite the running code when relocating only a small amount, say 0x100 or so. There's no need to relocate all the way past the compressed kernel, we just need to relocate past the size of the code in head.o. Updated patch below using the GOT end instead of the compressed image end. Oops, the mov should be movle of course. Updated patch below. This is wrong. You're using r12 before it is fixed up with the proper offset. Hmm I see. I guess I was thinking it only needs to be fixed up after the relocation. And this could simply be fixed with a big enough constant like this: diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 8dab5e3..71fc1d9 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -250,8 +250,11 @@ restart: adr r0, LC0 * Because we always copy ahead, we need to do it from the end and go * backward in case the source and destination overlap. */ - /* Round up to next 256-byte boundary. */ - add r10, r10, #256 + /* + * Round to a 256-byte boundary on the next page. This + * avoids overwriting ourself if the offset is small. + */ + add r10, r10, #4096 bic r10, r10, #255 sub r9, r6, r5 @ size to copy Yeah that's what I had originally, but then we'll be potentially hitting the same bug again once more cache flushing code etc gets added. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 10:59 PM, MyungJoo Ham myungjoo@samsung.com wrote: What one instance of DVFS (devfreq) controls are clocks and regulators. (a device may have multiple regulators as well as multiple clocks) What one instance of DVFS (devfreq) monitors (device load and/or temperature) is a device that uses the clocks and regulators. If we focus on the things that are controlled by DVFS, connecting DVFS with clock seems fine; however, DVFS's decision is based on the status of the device and the decision (monitoring result) configures a set of clocks and regulators. The clocks are not configured independently from others if the clocks are used by a DVFS-capable device. The frequency/voltage pair (OPP in this patch) associated with a device becomes a representative value of a specific configuration that configures the set of clocks and regulators. This is quite similar with CPUFREQ. CPUFREQ provides a single frequency value as a result of monitoring; however the machine's cpufreq driver may set multiple clocks and multiple voltage regulators based on the representative value (which is usually the core clock) although the cpufreq driver may need to control many more clocks with different frequencies. With multiple clocks of a device, if there is a clock that is required to be set independently from the representative clock with DVFS, it means that the DVFS monitoring result (load/temperature) is not a scalar value but a vector (multi-dimensional value). That implies that we need to monitor different and independent values, which in turn, implies that we need separated devices. Note that the DVFS monitor result from load and temperature combined is not a multi-dimensional value because the temperature limits maximum possible frequency or voltage and the load gives preferred lower bound of frequency that can be overridden by the limit set by temperature. Therefore, having one DVFS per clock where multiple clocks are attached to a device will create multiple monitors that monitor the same object(device behavior) with same metrics (load and temperature). Besides, the reason I've started with target callback, not clk and regulator names or pointers is that a device may have multiple clks and regulators and the OPP may only show the representative clock/regulators as CPUFREQ does. Especially when the order of transitions of those multiple clocks and regulators matter (if they are in a single device, it sometimes does), running a DVFS per clock, not per device, will be bothersome if not disasterous. I understand the need for some sort of governor that can use device state to determine the necessary clock frequencies. Where I disagree is the connection to voltages. The governor should ONLY determine the frequencies desired, and the voltage required to meet those frequencies should be determined by the clock framework, based only on the clock and the frequency. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross ccr...@google.com wrote: OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. We need them in runtime. A device a may want to guarantee that a device b to be at least 200MHz or faster while it does some operations. Then, a will opp_disable(b, 100MHz and others); and opp_enable(b, them) later on. We have similar issues with multimedia blocks (MFC, Camera, FB, GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay on catching up a workload (1.5x the sampling rate in average, 2.0x the sampling rate in worst cases), which may incur flickering/tearing issues with multimedia streams. On the other hand, a general thermal monitor or battery manager might want to limit energy usage by disabling top performance clocks if it is too hot or the battery level is low. That sounds like a very strange api, when what you really mean is clk_set_min_rate or clk_set_max_rate. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Thu, Apr 28, 2011 at 3:44 PM, Colin Cross ccr...@google.com wrote: On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross ccr...@google.com wrote: OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. We need them in runtime. A device a may want to guarantee that a device b to be at least 200MHz or faster while it does some operations. Then, a will opp_disable(b, 100MHz and others); and opp_enable(b, them) later on. We have similar issues with multimedia blocks (MFC, Camera, FB, GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay on catching up a workload (1.5x the sampling rate in average, 2.0x the sampling rate in worst cases), which may incur flickering/tearing issues with multimedia streams. On the other hand, a general thermal monitor or battery manager might want to limit energy usage by disabling top performance clocks if it is too hot or the battery level is low. That sounds like a very strange api, when what you really mean is clk_set_min_rate or clk_set_max_rate. Essentially, that's what needed. However, with clk_set_min/max_rate, don't we need to let another device to be consumer of other devices' clocks? Not just introducing a device to other devices? ___ linux-pm mailing list linux...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/linux-pm -- MyungJoo Ham (함명주), Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 11:50 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Thu, Apr 28, 2011 at 3:44 PM, Colin Cross ccr...@google.com wrote: On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross ccr...@google.com wrote: OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. We need them in runtime. A device a may want to guarantee that a device b to be at least 200MHz or faster while it does some operations. Then, a will opp_disable(b, 100MHz and others); and opp_enable(b, them) later on. We have similar issues with multimedia blocks (MFC, Camera, FB, GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay on catching up a workload (1.5x the sampling rate in average, 2.0x the sampling rate in worst cases), which may incur flickering/tearing issues with multimedia streams. On the other hand, a general thermal monitor or battery manager might want to limit energy usage by disabling top performance clocks if it is too hot or the battery level is low. That sounds like a very strange api, when what you really mean is clk_set_min_rate or clk_set_max_rate. Essentially, that's what needed. However, with clk_set_min/max_rate, don't we need to let another device to be consumer of other devices' clocks? Not just introducing a device to other devices? Yes, but that's effectively what you're doing through a backwards api anyways. The question is, for these complicated clock scenarios where the final frequency of a clock depends on so many factors, should that control go through the clock framework, or through some sort of global clock governor (which is where OPP would reappear). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Thu, Apr 28, 2011 at 3:43 PM, Colin Cross ccr...@google.com wrote:
I understand the need for some sort of governor that can use device
state to determine the necessary clock frequencies. Where I disagree
is the connection to voltages. The governor should ONLY determine the
frequencies desired, and the voltage required to meet those
frequencies should be determined by the clock framework, based only on
the clock and the frequency.
Yes, as long as AVS(Adaptive Voltage Scaling) is not involved, devfreq
does not need to care about voltages and let device driver (such as
the target callback or its callee) take care of voltages. Besides, my
impression on AVS is that AVS wouldn't be depending on software DVFS
scheme, at least with some AVS test on S5PC110. So, I'd say that it's
safe to let devfreq framework handle frequency only and let target
callback handle anything else except for choosing representative clock
frequency.
However, if we are going to detach devfreq from OPP, we only need to
provide frequency list at init and { an interface to control max/min
freq or an interface to lookup max/min freq of corresponding
representative clock. }
___
linux-pm mailing list
linux...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
ps. In our AVS test, the device drivers had nothing to do with voltage
scaling except for initializing devices. The H/W did everything about
voltage scaling dynamically.
Thanks,
MyungJoo.
--
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2plus: GPIO cleanup mach-omap2/*
On 04/27/11 18:58, Grazvydas Ignotas wrote: On Wed, Apr 27, 2011 at 5:01 PM, Tony Lindgren t...@atomide.com wrote: * Igor Grinberg grinb...@compulab.co.il [110427 02:02]: use gpio_request_one|array() instead of multiple gpiolib calls, remove unneeded variables, etc. Great :) I think this does conflict with Mike's omap: cleanup board files series though. Yep, as I've stated in the description ;) I've started working on this before Mike submitted his series and now I want to get some responses before any rebase work is done. -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Thu, Apr 28, 2011 at 4:06 PM, Colin Cross ccr...@google.com wrote: On Wed, Apr 27, 2011 at 11:50 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Thu, Apr 28, 2011 at 3:44 PM, Colin Cross ccr...@google.com wrote: On Wed, Apr 27, 2011 at 11:12 PM, MyungJoo Ham myungjoo@samsung.com wrote: On Thu, Apr 28, 2011 at 5:48 AM, Colin Cross ccr...@google.com wrote: OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. We need them in runtime. A device a may want to guarantee that a device b to be at least 200MHz or faster while it does some operations. Then, a will opp_disable(b, 100MHz and others); and opp_enable(b, them) later on. We have similar issues with multimedia blocks (MFC, Camera, FB, GPU) and CPU/Memory Bus. Ondemand governor of CPUFREQ has some delay on catching up a workload (1.5x the sampling rate in average, 2.0x the sampling rate in worst cases), which may incur flickering/tearing issues with multimedia streams. On the other hand, a general thermal monitor or battery manager might want to limit energy usage by disabling top performance clocks if it is too hot or the battery level is low. That sounds like a very strange api, when what you really mean is clk_set_min_rate or clk_set_max_rate. Essentially, that's what needed. However, with clk_set_min/max_rate, don't we need to let another device to be consumer of other devices' clocks? Not just introducing a device to other devices? Yes, but that's effectively what you're doing through a backwards api anyways. The question is, for these complicated clock scenarios where the final frequency of a clock depends on so many factors, should that control go through the clock framework, or through some sort of global clock governor (which is where OPP would reappear). In the use cases of runtime clock setting by devfreq or other devices mentioned above, we are controlling the device's performance with the representative clock of the device, not a specific clock among the clocks that the device has. For a device A with clock a1 and a2, another device B would not control both a1 and a2 directly to get the guaranteed performance from A. Besides, B should not do so if there are specific orders, delays, and other controls for A to properly change performance. Therefore, my answer is that it would be preferred to control through some wrapper/interface/or anything that is connected to the device of the controlled clocks (and let the device's callback or something control its clocks), not to control through clock framework directly. In this version of devfreq+OPP, these are handled by the target callback. Cheers! - MyungJoo -- MyungJoo Ham, Ph.D. Mobile Software Platform Lab, Digital Media and Communications (DMC) Business Samsung Electronics cell: 82-10-6714-2858 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
* Tony Lindgren t...@atomide.com [110427 23:35]: * Nicolas Pitre nicolas.pi...@linaro.org [110428 01:12]: On Wed, 27 Apr 2011, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110427 05:44]: We can't overwrite the running code when relocating only a small amount, say 0x100 or so. There's no need to relocate all the way past the compressed kernel, we just need to relocate past the size of the code in head.o. Updated patch below using the GOT end instead of the compressed image end. Oops, the mov should be movle of course. Updated patch below. This is wrong. You're using r12 before it is fixed up with the proper offset. Hmm I see. I guess I was thinking it only needs to be fixed up after the relocation. Here's this one with r12 calculation fixed using r0 delta. Also updated it to use movlt instead of movle as that should be sufficient. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Wed, 27 Apr 2011 02:06:13 -0700 Subject: [PATCH] ARM: Fix relocation to move past the running code Otherwise we end up overwriting ourselves partially when relocating less than size of the running code in head.S. Without this patch, a system will not boot if the compressed image load address is slightly less than where the compressed image gets relocated. For example, using mkimage to set the load address to something like zreladdr + uncompressed image size - 0x100 will make the system hang without this patch. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -282,10 +282,12 @@ dtb_check_done: /* * Check to see if we will overwrite ourselves. + * r0 = delta * r4 = final kernel address * r5 = start of this image * r9 = size of decompressed image * r10 = end of this image, including bss/stack/malloc space if non XIP + * r12 = GOT end, fixed up with delta in r0 if relocating * We basically want: * r4 - 16k page directory = r10 - OK * r4 + image length = r5 - OK @@ -297,11 +299,20 @@ dtb_check_done: cmp r10, r5 bls wont_overwrite + /* +* Check if the relocate address overlaps the running code in +* head.S. In that case we need to relocate past the code +* to avoid overwriting some of the running code. +*/ + add r12, r12, r0@ fixup GOT end with delta + cmp r10, r12@ relocating less than GOT end? + movlt r10, r12@ if so, relocate to GOT end + /* * Relocate ourselves past the end of the decompressed kernel. * r5 = start of this image * r6 = _edata - * r10 = end of the decompressed kernel + * r10 = end of the decompressed kernel or end of GOT end if larger * Because we always copy ahead, we need to do it from the end and go * backward in case the source and destination overlap. */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] OMAP: GPIO: cleanup, consolidation, etc. (v2)
Kevin, On Fri, Apr 22, 2011 at 02:05, Kevin Hilman khil...@ti.com wrote: Here's an updated version of my work-in-progress GPIO cleanups. I now understand that others have some similar work in progress, so these are posted (to linux-omap only, for now) so that we can begin collaboration on the GPIO cleanups. This series applies on top of v2.6.39-rc4 plus the generic irq_chip series from Thomas Gleixner since in addition to the cleanups, I started moving the GPIO IRQ handling over to use generic irq_chip (last patch in series.) This work in progress is available in my wip/gpio-cleanup branch. I tested the patch series in wip/gpio-cleanup branch. Here are the results: Compile tested for: - omap1_defconfig - omap2plus_defconfig Boot test (Failed on the following board): - OMAP1710-H3 Boot test (Success on the following boards): - OMAP2420-H4 - OMAP3430-SDP - OMAP3430-Zoom2 - OMAP3630-Zoom3 - OMAP4430-SDP - OMAP4430-Blaze GPIO module functionality testing (success on the following boards): - OMAP2420-H4 - OMAP3430-SDP - OMAP3430-Zoom2 - OMAP3630-Zoom3 - OMAP4430-SDP - OMAP4430-Blaze PM Testing (success as given below): OMAP3430-SDP: retention, off_mode, system_wide suspend, gpio wakeup OMAP3630-Zoom3: retention, system_wide suspend using the following: echo 5 /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 /sys/devices/platform/omap/omap_uart.3/sleep_timeout echo '5' /debug/pm_debug/wakeup_timer_seconds echo 1 /debug/pm_debug/sleep_while_idle echo 1 /debug/pm_debug/enable_off_mode -V Charulatha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [RFC PATCH] PM: Introduce generic DVFS framework with device-specific OPPs
On Wed, Apr 27, 2011 at 01:48:52PM -0700, Colin Cross wrote: OPP currently has opp_enable and opp_disable functions. I don't understand why these are needed, they are only used at init time to determine available voltages, which could be handled by never passing unavailable voltages to the dvfs implementation. I queried this when OPP was originally added. The motivation which was given (which seemed fairly reasonable) was to reduce the number of data tables for similar parts and board designs. That did seem like something which it was reasonable to factor out in some way, though possibly with a different mechanism. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Vaingede rekomenduoja Tau nera pulti neviltin, taciau uzdirbti
nesunkiai pasipelnyti stai si titulini puslapi ir pamegink uzsidirbti pinigus sau jau artimiausioje ateityje su instrukcija susipazink stai cia http://www.jevgenija-skaistule.info Eidvile ir Vytautas jau uzsidirbk tai, ko nusipelnei! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache
On Fri, Apr 15, 2011 at 06:26:40AM -0500, Gupta, Ramesh wrote: Russell, On Thu, Apr 14, 2011 at 5:30 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote: From: Ramesh Gupta grgu...@ti.com This patch is to flush the iommu page table entries from L1 and L2 caches using dma_map_single. This also simplifies the implementation by removing the functions flush_iopgd_range/flush_iopte_range. No. This usage is just wrong. If you're going to use the DMA API then unmap it, otherwise the DMA API debugging will go awol. Thank you for the comments, this particular memory is always a write from the A9 for MMU programming and only read from the slave processor, that is the reason for not calling the unmap. I can re-look into the changes to call unmap in a proper way as this impacts the DMA API. Are there any other ways to perform only flush the memory from L1/L2 caches? We _could_ invent a new API to deal with this, which is probably going to be far better in the longer term for page table based iommus. That's going to need some thought - eg, do we need to pass a struct device argument for the iommu cache flushing so we know whether we need to flush or not (eg, if we have cache coherent iommus)... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MTD: s3c2410_nand: Add option to disable hw ECC at runtime
On Fri, Apr 15, 2011 at 05:01:11PM +0300, Artem Bityutskiy wrote: Well, I got this understanding by talking to the OMAP maintainer and by chatting with rmk. But I might be wrong. So the understanding is that board data extending is banned, at least for a while. And the arm world has to consolidate and probably switch to the DT tree approach. This would be painful, this would make some vendors to return to behind the curtains, so this would be a step back in the short run. Well, what Linus desires from ARM folk is a concerted effort to get the ARM tree 'under control' and stop the thing forever increasing without any apparant control. Linus has said is that if arch/arm/mach* show up with significant numbers of net additional lines of code in the diffstat, he'll refuse to pull the git tree. (See various mails from Linus on linux-arm-kernel.) My preference is to limit this merge window to just consolidation and bug fixes so that we can show that we're taking the issue seriously and are putting a decent amount of effort into addressing the problem. However, the problem with adding new stuff is that it dilutes the diffstat, and makes it much harder to show that we're doing what's required. Eg, lets say we end up removing 1000 LOC, but end up adding 1000 LOC of new platform data via other trees. I don't think Linus will be pleased when he comes to the end of the merge window and arch/arm/ again shows up heavily in the statistics without a significant reduction. I suspect if that were to happen, things will get much harder for us. When you bear in mind that in total, arch/arm was pusing 60k lines of new code into the kernel _each_ merge window. If we manage to reduce the size of arch/arm by only 10k, it is really just a small drop in the ocean in comparison - we need much more effort than that... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] OMAP: DMA: mstandby mode and runtime pm support
On Tue, Apr 19, 2011 at 04:05:17AM -0700, Tony Lindgren wrote: * G, Manjunath Kondaiah manj...@ti.com [110328 07:29]: G, Manjunath Kondaiah (4): OMAP2+: PM: omap device: API's for handling mstandby mode OMAP2+: DMA: prevent races while setting M idle mode to nostandby OMAP: PM: DMA: Enable runtime pm OMAP: DMA: Fix: context restore during off mode arch/arm/mach-omap1/dma.c |1 + arch/arm/mach-omap2/dma.c | 16 ++ arch/arm/mach-omap2/omap_hwmod.c | 42 ++ arch/arm/plat-omap/dma.c | 196 + arch/arm/plat-omap/include/plat/dma.h |1 + arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/omap_device.c | 62 8 files changed, 291 insertions(+), 33 deletions(-) With the DMA code too we need to do the cleanup to move it to drivers/dma before adding new features. It also needs to conform to the DMA engine API, which is not well documented. The points to watch out for are: 1. it passes lockdep. 2. drivers _can_ submit new slave transactions during a previous slave transaction callback. 3. callbacks must be made from tasklet context. 4. terminating a transaction dma dma_terminate_all() should not call any callbacks (as they may submit new transactions, causing DMA to restart.) I think that's about it, but there may be more. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
On Mon, Apr 04, 2011 at 03:17:25PM +0530, Santosh Shilimkar wrote:
From 4d8d4e5c99c1477a8cb04b525ff5a2d93bbdacfd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 4 Apr 2011 14:20:08 +0530
Subject: [PATCH] OMAP: SRAM: Fix warning: format '%08lx' expects type
'long unsigned int'
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
While at this, convert SRAM printk(* ) to pr_*().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/sram.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..6af3d0b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR Could not detect SRAM size\n);
+ pr_err(Could not detect SRAM size\n);
omap_sram_size = 0x4000;
}
}
@@ -221,10 +221,10 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n,
- __pfn_to_phys(omap_sram_io_desc[0].pfn),
- omap_sram_io_desc[0].virtual,
-omap_sram_io_desc[0].length);
+ pr_info(SRAM: Mapped pa 0x%08llx to va 0x%08lx size: 0x%lx\n,
+ (long long) __pfn_to_phys(omap_sram_io_desc[0].pfn),
+ omap_sram_io_desc[0].virtual,
+ omap_sram_io_desc[0].length);
/*
* Normally devicemaps_init() would flush caches and tlb after
@@ -252,7 +252,7 @@ static void __init omap_map_sram(void)
void *omap_sram_push_address(unsigned long size)
{
if (size (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
- printk(KERN_ERR Not enough space in SRAM\n);
+ pr_err(Not enough space in SRAM\n);
return NULL;
}
This looks much better.
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
It looks like Tony hasn't taken it... Tony, are you going to handle
this patch?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
On Wed, Apr 27, 2011 at 12:23:18AM -0400, Oleg Drokin wrote:
Hello!
On Apr 24, 2011, at 6:09 PM, Mike Rapoport wrote:
-void __init usb_musb_init(struct omap_musb_board_data *board_data)
+static struct omap_musb_board_data musb_default_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
In fact can you make it more generic with ifdefs like this?
(since there are tons of boards taht are client only or would like to be
compiled in some other way):
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
If this is something that's desired, then it should not be done via ifdefs
but by platforms passing the mode argument into an initialization function.
Eventually, when we switch to some DT like system, this is the kind of
information that would be obtained from DT, and identifying this stuff
now will help when DT stuff comes along.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Initial BN Nook Color support, take two
Hello! Ok, this is a second attempt at BN Nook Color board file submission. USB peripheral mode is fully operational as is serial console and MMC/SDCard. I threw away all the android stuff as suggested, also cleaned up voltage regulators and removed the ones our twl chip actually does not have (contrary to my previous beliefs). Bye, Oleg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Add tps65921 chip
From: Oleg Drokin gr...@linuxhacker.ru
---
drivers/mfd/twl-core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 960b5be..3daebcc 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1107,6 +1107,8 @@ static const struct i2c_device_id twl_ids[] = {
{ tps65950, 0 }, /* catalog version of twl5030 */
{ tps65930, TPS_SUBSET }, /* fewer LDOs and DACs; no charger */
{ tps65920, TPS_SUBSET }, /* fewer LDOs; no codec or charger */
+ { tps65921, TPS_SUBSET }, /* fewer LDOs; no codec, no LED
+ and vibrator. Charger in USB module*/
{ twl6030, TWL6030_CLASS }, /* Phoenix power chip */
{ /* end of list */ },
};
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Initial BN Nook Color (encore) support.
From: Oleg Drokin gr...@linuxhacker.ru
Bare-bones board file, comes with serial console, gpio keys,
MMC/SDCard and USB support.
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-omap3encore.c | 380 ++
arch/arm/plat-omap/include/plat/uncompress.h |1 +
arch/arm/tools/mach-types|2 +-
5 files changed, 389 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3encore.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..5370561 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO
for full description please see the products webpage at
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
+config MACH_ENCORE
+bool Barnes Noble Encore (Nook Color)
+depends on ARCH_OMAP3
+select OMAP_PACKAGE_CBP
+
config MACH_OVERO
bool Gumstix Overo board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 512b152..b894777 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -189,6 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) +=
board-omap3logic.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \
hsmmc.o
+obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
diff --git a/arch/arm/mach-omap2/board-omap3encore.c
b/arch/arm/mach-omap2/board-omap3encore.c
new file mode 100644
index 000..c7bf8de
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3encore.c
@@ -0,0 +1,380 @@
+/*
+ *
+ * Copyright (C) 2008 Texas Instruments Inc.
+ * Vikram Pandita vikram.pand...@ti.com
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * April 2011 Oleg Drokin gr...@linuxhacker.ru - Port to 2.6.39
+ *
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/gpio_keys.h
+#include linux/err.h
+
+#include linux/spi/spi.h
+#include linux/i2c/twl.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include mach/hardware.h
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include mach/gpio.h
+#include plat/board.h
+#include plat/common.h
+#include plat/usb.h
+#include plat/mux.h
+#include plat/sram.h
+#include plat/mmc.h
+#include plat/omap-serial.h
+#include plat/system.h
+
+#include mux.h
+#include hsmmc.h
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+/* Encore-specific device-info and i2c addresses. */
+/* Battery, bus 1 */
+#define MAX17042_I2C_SLAVE_ADDRESS 0x36
+#define MAX17042_GPIO_FOR_IRQ 100
+
+/*addition of MAXIM8903/TI GPIO mapping WRT schematics */
+#define MAX8903_UOK_GPIO_FOR_IRQ 115
+#define MAX8903_DOK_GPIO_FOR_IRQ 114
+#define MAX8903_GPIO_CHG_EN110
+#define MAX8903_GPIO_CHG_STATUS111
+#define MAX8903_GPIO_CHG_FLT 101
+#define MAX8903_GPIO_CHG_IUSB 102
+#define MAX8903_GPIO_CHG_USUS 104
+#define MAX8903_GPIO_CHG_ILM 61
+
+/* TI WLAN */
+#define ENCORE_WIFI_PMENA_GPIO 22
+#define ENCORE_WIFI_IRQ_GPIO 15
+#define ENCORE_WIFI_EN_POW 16
+
+/* Accelerometer i2c bus 1*/
+#define KXTF9_I2C_SLAVE_ADDRESS0x0F
+#define KXTF9_GPIO_FOR_PWR 34
+#define KXTF9_GPIO_FOR_IRQ 113
+
+/* Touch screen i2c bus 2*/
+#define CYTTSP_I2C_SLAVEADDRESS34
+#define ENCORE_CYTTSP_GPIO 99
+#define ENCORE_CYTTSP_RESET_GPIO 46
+
+/* Audio codec, i2c bus 2 */
+#define AUDIO_CODEC_POWER_ENABLE_GPIO 103
+#define AUDIO_CODEC_RESET_GPIO 37
+#define AUDIO_CODEC_IRQ_GPIO 59
+#define AIC3100_I2CSLAVEADDRESS0x18
+
+
+/* Different HW revisions */
+#define BOARD_ENCORE_REV_EVT1A 0x1
+#define BOARD_ENCORE_REV_EVT1B 0x2
+#define BOARD_ENCORE_REV_EVT2 0x3
+#define BOARD_ENCORE_REV_DVT 0x4
+#define BOARD_ENCORE_REV_PVT 0x5
+#define BOARD_ENCORE_REV_UNKNOWN 0x6
+
+static inline int is_encore_board_evt2(void)
+{
+return (system_rev = BOARD_ENCORE_REV_EVT2);
+}
+
+static inline int is_encore_board_evt1b(void)
+{
+return (system_rev == BOARD_ENCORE_REV_EVT1B);
+}
+
+static int encore_twl4030_keymap[] = {
+ KEY(0, 0, KEY_HOME),
+ KEY(0, 1, KEY_VOLUMEUP),
+
Re: [PATCH 2/2] Add basic devices support for Nook Color
Hello!
On Apr 28, 2011, at 2:14 AM, Mike Rapoport wrote:
+static struct omap_musb_board_data musb_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
This kind of ifdefery is handled inside the musb driver. I'd set the mode to
MUSB_OTG unless you want to explicitly limit it to HOST or PERIPHERAL
Actually it's not.
If I set MUSB_OTG here and then I choose PERIPHERAL mode in the kernel
config,
the musb transceiver code will complain about board file and kernel config
mismatch.
The Nook Color is advertised as peripheral device, but OTG must be working
too
(not totally working at this point) I think there is value to be able to
configure it
in two different modes.
Frankly, I haven't tried choosing different modes in the kernel config and in
the board data. Still, I believe that board data should define desired
operation
mode and the driver should do the best effort to enable the controller in the
desired mode.
The desired operation mode is dependent on musb configuration.
E.g. see n8x0 board file for the example of the same thing.
Bye,
Olg--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
Hello!
On Apr 28, 2011, at 10:18 AM, Russell King - ARM Linux wrote:
-void __init usb_musb_init(struct omap_musb_board_data *board_data)
+static struct omap_musb_board_data musb_default_board_data = {
+ .interface_type = MUSB_INTERFACE_ULPI,
+ .mode = MUSB_OTG,
In fact can you make it more generic with ifdefs like this?
(since there are tons of boards taht are client only or would like to be
compiled in some other way):
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
If this is something that's desired, then it should not be done via ifdefs
but by platforms passing the mode argument into an initialization function.
Eventually, when we switch to some DT like system, this is the kind of
information that would be obtained from DT, and identifying this stuff
now will help when DT stuff comes along.
Frankly, I am not even sure why the mode needs to be supplied by the board at
all.
The musb code already has a very similar switch in musb_plat and so it totally
looks like
a duplicated specification of the same thing from the board file and from
generic musb code where the original init value is then ignored.
I see that in .29 the board file did not need to specify usb mode and it was
all decided
in musb-specific code, and I have no idea why that was later changed to the way
it is now.
Would it just be better if a patch removing mode field from struct
omap_musb_board_data
is adopted like this (warning - not a real patch)?
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 35559f7..c7f834f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -129,7 +129,6 @@ void __init usb_musb_init(struct omap_musb_board_data *board
musb_plat.clock = ick;
musb_plat.board_data = board_data;
musb_plat.power = board_data-power 1;
- musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
if (cpu_is_omap44xx())
Bye,
Oleg--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap: musb: introduce default baord config
On Thu, Apr 28, 2011 at 12:21:47PM -0400, Oleg Drokin wrote:
Frankly, I am not even sure why the mode needs to be supplied by the board at
all.
The musb code already has a very similar switch in musb_plat and so it
totally looks like
a duplicated specification of the same thing from the board file and from
generic musb code where the original init value is then ignored.
I see that in .29 the board file did not need to specify usb mode and it was
all decided
in musb-specific code, and I have no idea why that was later changed to the
way it is now.
Would it just be better if a patch removing mode field from struct
omap_musb_board_data
is adopted like this (warning - not a real patch)?
Hmm, it looks to me like we're ending up with two layers on top of
each other, both trying to provide some kind of generic board interface.
I think they should be squashed together. And that:
static struct musb_hdrc_platform_data musb_plat = {
#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
.mode = MUSB_HOST,
#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
.mode = MUSB_PERIPHERAL,
#endif
in usb-musb.c needs the same treatment as I mentioned in the previous
message if it really is board specific. If not, I see no reason why
the above can't go into the musb driver itself.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V4 0/4] cpuidle: global registration of idle states with per-cpu statistics
The following patch series implements global registration of cpuidle states, and also has the necessary data structure changes to accommodate the per-cpu writable members of the cpuidle_states structure. Previous version of the series (V3) is at https://lkml.org/lkml/2011/4/20/23 This series applies on 2.6.39-rc5 with Len Brown's pm_idle() cleanup version 3 (https://lkml.org/lkml/2011/4/2/8) plus the patch https://lkml.org/lkml/diff/2011/4/25/54/1 Changes from previous version (V3): 1. Compile tested for ARM using the following configs: da8xx_omapl_defconfig, kirkwood_defconfig, stamp9g20_defconfig, omap2plus_defconfig. Boot tested on Panda SoC (OMAP4430) but it doesn't really use cpuidle. 2. Boot tested on x86 nehalem with multiple C-states for both intel_idle and acpi_idle drivers. 3. Boot tested on T60p thinkpad that has T2600 cpu with multiple C-states. Additionally tested the case when C-state tables change on AC - Battery power switch. 4. De-duplicated code in [1/4] and moved common code related to update of cpuidle statistics to drivers/cpuidle/cpuidle.c 5. Handled the case when acpi_processor_cst_has_changed() is called on x86 on switching power from AC - Battery. The implementation is just a prototype. Please provide suggestions. Brief description of the patches: The core change in this series is to split the cpuidle_device structure into parts that can be global and parts that has to remain per-cpu. The per-cpu pieces are mostly generic statistics that can be independent of current running driver. As a result of these changes, there is single copy of cpuidle_states structure and single registration done by one cpu. The low level driver is free to set per-cpu driver data on each cpu if needed using the cpuidle_set_statedata() as the case today. Only in very rare cases asymmetric C-states exist which can be handled within the cpuidle driver. Most architectures do not have asymmetric C-states. First two patches in the series facilitate splitting of cpuidle_states and cpuidle_device structure and next two patches do the actual split, change the API's and make existing code follow the changed API. [1/4] - Move the idle residency accounting part from cpuidle.c to the respective low level drivers, so that the accounting can be accurately maintained if the driver decides to demote the chosen (suggested) by the governor. [2/4] - removes the cpuidle_device()-prepare API since is is not widely used and the only use case was to allow software demotion using CPUIDLE_FLAG_IGNORE flag. Both these functions can be absorbed within the cpuidle back-end driver ad hence deprecating the prepare routine and the CPUIDLE_FLAG_IGNORE flag. - Ref: https://lkml.org/lkml/2011/3/25/52 [3/4] - Splits the usage statistics (read/write) part out of cpuidle_state structure, so that the states can become read only and hence made global. [4/4] - most APIs will now need to pass pointer to both global cpuidle_driver and per-cpu cpuidle_device structure. Thanks, -Trinabh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V4 1/4] cpuidle: Move dev-last_residency update to driver enter routine, remove dev-last_state
Cpuidle governor only suggests the state to enter using the
governor-select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.
Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.
Reference:
https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
arch/arm/mach-at91/cpuidle.c | 10 +++-
arch/arm/mach-davinci/cpuidle.c |9 +++-
arch/arm/mach-kirkwood/cpuidle.c | 12 -
arch/arm/mach-omap2/cpuidle34xx.c | 61 +++
arch/sh/kernel/cpu/shmobile/cpuidle.c | 12 +++--
drivers/acpi/processor_idle.c | 75 ++---
drivers/cpuidle/cpuidle.c | 33 +++
drivers/cpuidle/governors/ladder.c| 13 ++
drivers/cpuidle/governors/menu.c |7 ++-
drivers/idle/intel_idle.c | 12 -
include/linux/cpuidle.h |7 +--
11 files changed, 157 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..4696a0d 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,7 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
@@ -41,10 +41,10 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
do_gettimeofday(before);
- if (state == dev-states[0])
+ if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
- else if (state == dev-states[1]) {
+ else if (index == 1) {
asm(b 1f; .align 5; 1:);
asm(mcr p15, 0, r0, c7, c10, 4); /* drain write buffer */
saved_lpr = sdram_selfrefresh_enable();
@@ -55,7 +55,9 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev-last_residency = idle_time;
+ return index;
}
/* Initialize CPU idle by registering the idle states */
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..ca8582a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,9 +78,9 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(state);
+ struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
struct timeval before, after;
int idle_time;
@@ -98,7 +98,10 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
- return idle_time;
+
+ dev-last_residency = idle_time;
+
+ return index;
}
static int __init davinci_cpuidle_probe(struct platform_device *pdev)
diff --git a/arch/arm/mach-kirkwood/cpuidle.c b/arch/arm/mach-kirkwood/cpuidle.c
index f68d33f..358dd80 100644
--- a/arch/arm/mach-kirkwood/cpuidle.c
+++ b/arch/arm/mach-kirkwood/cpuidle.c
@@ -32,17 +32,17 @@ static DEFINE_PER_CPU(struct cpuidle_device,
kirkwood_cpuidle_device);
/* Actual code that puts the SoC in different idle states */
static int kirkwood_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state)
+ int index)
{
struct timeval before, after;
int idle_time;
local_irq_disable();
do_gettimeofday(before);
- if (state == dev-states[0])
+ if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
- else if (state == dev-states[1]) {
+ else if (index == 1) {
/*
* Following
[RFC PATCH V4 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev-prepare()
The cpuidle_device-prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this mechanism is not required.
Also this removes per-cpu flags from cpuidle_state enabling
it to be made global.
Ref: https://lkml.org/lkml/2011/3/25/52
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle.c| 10 --
drivers/cpuidle/governors/menu.c |2 --
include/linux/cpuidle.h |3 ---
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 0f97261..a194527 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -83,16 +83,6 @@ int cpuidle_idle_call(void)
hrtimer_peek_ahead_timers();
#endif
- /*
-* Call the device's prepare function before calling the
-* governor's select function. -prepare gives the device's
-* cpuidle driver a chance to update any dynamic information
-* of its cpuidle states for the current idle period, e.g.
-* state availability, latencies, residencies, etc.
-*/
- if (dev-prepare)
- dev-prepare(dev);
-
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
if (need_resched()) {
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index e4b200c..af724e8 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -288,8 +288,6 @@ static int menu_select(struct cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i dev-state_count; i++) {
struct cpuidle_state *s = dev-states[i];
- if (s-flags CPUIDLE_FLAG_IGNORE)
- continue;
if (s-target_residency data-predicted_us)
continue;
if (s-exit_latency latency_req)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8da811b..c6d85cf 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -47,7 +47,6 @@ struct cpuidle_state {
/* Idle State Flags */
#define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable?
*/
-#define CPUIDLE_FLAG_IGNORE(0x100) /* ignore during this idle period */
#define CPUIDLE_DRIVER_FLAGS_MASK (0x)
@@ -93,8 +92,6 @@ struct cpuidle_device {
struct completion kobj_unregister;
void*governor_data;
int safe_state_index;
-
- int (*prepare) (struct cpuidle_device *dev);
};
DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V4 3/4] cpuidle: Split cpuidle_state structure and move per-cpu statistics fields
This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
arch/arm/mach-davinci/cpuidle.c |5 ++--
arch/arm/mach-omap2/cpuidle34xx.c | 13 ++
drivers/acpi/processor_idle.c | 25 ++--
drivers/cpuidle/cpuidle.c | 11 +
drivers/cpuidle/sysfs.c | 15 +++-
drivers/idle/intel_idle.c | 46 +++--
include/linux/cpuidle.h | 25
7 files changed, 87 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index ca8582a..f2d2f34 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -80,7 +80,8 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
static int davinci_enter_idle(struct cpuidle_device *dev,
int index)
{
- struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
+ struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+ struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
struct timeval before, after;
int idle_time;
@@ -142,7 +143,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
strcpy(device-states[1].desc, WFI and DDR Self Refresh);
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
- cpuidle_set_statedata(device-states[1], davinci_states[1]);
+ cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 92dd080..3f89036 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -123,7 +123,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
int index)
{
struct omap3_processor_cx *cx =
- cpuidle_get_statedata(dev-states[index]);
+ cpuidle_get_statedata(dev-states_usage[index]);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
int idle_time;
@@ -183,10 +183,11 @@ static int next_valid_state(struct cpuidle_device *dev,
int index)
{
struct cpuidle_state *curr = dev-states[index];
+ struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct omap3_processor_cx *cx;
int next_index = -1;
- cx = (struct omap3_processor_cx *)cpuidle_get_statedata(curr);
+ cx = (struct omap3_processor_cx *)cpuidle_get_statedata(curr_usage);
/* Check if current state is valid */
if (cx-valid) {
@@ -217,7 +218,7 @@ static int next_valid_state(struct cpuidle_device *dev,
for (; idx = OMAP3_STATE_C1; idx--) {
struct omap3_processor_cx *cx;
- cx = cpuidle_get_statedata(dev-states[idx]);
+ cx = cpuidle_get_statedata(dev-states_usage[idx]);
if (cx-valid) {
next_index = idx;
break;
@@ -257,7 +258,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
goto select_state;
}
- cx = cpuidle_get_statedata(state);
+ cx = cpuidle_get_statedata(dev-states_usage[index]);
core_next_state = cx-core_state;
/*
@@ -501,6 +502,7 @@ int __init omap3_idle_init(void)
int i, count = 0;
struct omap3_processor_cx *cx;
struct cpuidle_state *state;
+ struct cpuidle_state_usage *state_usage;
struct cpuidle_device *dev;
mpu_pd = pwrdm_lookup(mpu_pwrdm);
@@ -517,10 +519,11 @@ int __init omap3_idle_init(void)
for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
cx = omap3_power_states[i];
state = dev-states[count];
+ state_usage = dev-states_usage[count];
if (!cx-valid)
continue;
- cpuidle_set_statedata(state, cx);
+ cpuidle_set_statedata(state_usage, cx);
state-exit_latency = cx-sleep_latency + cx-wakeup_latency;
state-target_residency = cx-threshold;
state-flags = cx-flags;
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index decec1e..e888c9e 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -744,14 +744,13 @@ static inline
[RFC PATCH V4 4/4] cpuidle: Single/Global registration of idle states
This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.
ToDo:
1. Handle the case when idle states may change at run time
and acpi_processor_cst_has_changed() routine is called in a
better way than the current solution in this patch.
Ref: https://lkml.org/lkml/2011/4/25/83
Signed-off-by: Trinabh Gupta trin...@linux.vnet.ibm.com
---
arch/arm/mach-at91/cpuidle.c | 31 +++--
arch/arm/mach-davinci/cpuidle.c | 39 ---
arch/arm/mach-kirkwood/cpuidle.c | 30 +++--
arch/arm/mach-omap2/cpuidle34xx.c | 95
arch/sh/kernel/cpu/shmobile/cpuidle.c | 18 ++-
drivers/acpi/processor_driver.c | 20 +--
drivers/acpi/processor_idle.c | 193 +
drivers/cpuidle/cpuidle.c | 45 ++--
drivers/cpuidle/driver.c | 25
drivers/cpuidle/governors/ladder.c| 26 +++-
drivers/cpuidle/governors/menu.c | 20 ++-
drivers/cpuidle/sysfs.c |3 -
drivers/idle/intel_idle.c | 80 ++
include/acpi/processor.h |1
include/linux/cpuidle.h | 19 ++-
15 files changed, 448 insertions(+), 197 deletions(-)
diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 4696a0d..93178f6 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,6 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
/* Actual code that puts the SoC in different idle states */
static int at91_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct timeval before, after;
@@ -64,27 +65,29 @@ static int at91_enter_idle(struct cpuidle_device *dev,
static int at91_init_cpuidle(void)
{
struct cpuidle_device *device;
-
- cpuidle_register_driver(at91_idle_driver);
+ struct cpuidle_driver *driver = at91_idle_driver;
device = per_cpu(at91_cpuidle_device, smp_processor_id());
device-state_count = AT91_MAX_STATES;
+ driver-state_count = AT91_MAX_STATES;
/* Wait for interrupt state */
- device-states[0].enter = at91_enter_idle;
- device-states[0].exit_latency = 1;
- device-states[0].target_residency = 1;
- device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[0].name, WFI);
- strcpy(device-states[0].desc, Wait for interrupt);
+ driver-states[0].enter = at91_enter_idle;
+ driver-states[0].exit_latency = 1;
+ driver-states[0].target_residency = 1;
+ driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[0].name, WFI);
+ strcpy(driver-states[0].desc, Wait for interrupt);
/* Wait for interrupt and RAM self refresh state */
- device-states[1].enter = at91_enter_idle;
- device-states[1].exit_latency = 10;
- device-states[1].target_residency = 1;
- device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
- strcpy(device-states[1].name, RAM_SR);
- strcpy(device-states[1].desc, WFI and RAM Self Refresh);
+ driver-states[1].enter = at91_enter_idle;
+ driver-states[1].exit_latency = 10;
+ driver-states[1].target_residency = 1;
+ driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
+ strcpy(driver-states[1].name, RAM_SR);
+ strcpy(driver-states[1].desc, WFI and RAM Self Refresh);
+
+ cpuidle_register_driver(at91_idle_driver);
if (cpuidle_register_device(device)) {
printk(KERN_ERR at91_init_cpuidle: Failed registering\n);
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f2d2f34..dbeeccd 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,6 +78,7 @@ static struct davinci_ops
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
/* Actual code that puts the SoC in different idle states */
static int davinci_enter_idle(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
int index)
{
struct cpuidle_state_usage *state_usage = dev-states_usage[index];
@@ -109,6 +110,7 @@ static int __init davinci_cpuidle_probe(struct
platform_device *pdev)
{
int ret;
struct cpuidle_device *device;
+ struct cpuidle_driver *driver = davinci_idle_driver;
struct davinci_cpuidle_config *pdata = pdev-dev.platform_data;
device = per_cpu(davinci_cpuidle_device, smp_processor_id());
@@ -120,32 +122,33
Re: [PATCH 4/4] omap: musb: introduce default baord config
Hello!
On Apr 28, 2011, at 12:28 PM, Russell King - ARM Linux wrote:
mm, it looks to me like we're ending up with two layers on top of
each other, both trying to provide some kind of generic board interface.
I think they should be squashed together. And that:
static struct musb_hdrc_platform_data musb_plat = {
#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
.mode = MUSB_HOST,
#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
.mode = MUSB_PERIPHERAL,
#endif
in usb-musb.c needs the same treatment as I mentioned in the previous
message if it really is board specific. If not, I see no reason why
the above can't go into the musb driver itself.
In the end it's chip dependent. And the musb can work in all three modes.
Of course the board dictates if the power is supplied to the bus in host
mode and such, but even that could be worked around as nokia 9x0 saga for
USB host shows.
So to me it looks like something totally in realm of musb driver itself.
Nothing bad happens if you configure your MUSB as say OTG while in fact only
peripheral mode was implemented, it continues to work as it did.
Of course enabling HOST mode may not magically make things work, but
I suspect this could be addressed from Kconfig itself instead.
Now I totally expect musb maintainer to jump in and explain
how many misconceptions I have ;)
Bye,
Oleg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache
Hi Russel, On Thu, Apr 28, 2011 at 8:40 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Apr 15, 2011 at 06:26:40AM -0500, Gupta, Ramesh wrote: Russell, On Thu, Apr 14, 2011 at 5:30 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote: From: Ramesh Gupta grgu...@ti.com This patch is to flush the iommu page table entries from L1 and L2 caches using dma_map_single. This also simplifies the implementation by removing the functions flush_iopgd_range/flush_iopte_range. No. This usage is just wrong. If you're going to use the DMA API then unmap it, otherwise the DMA API debugging will go awol. Thank you for the comments, this particular memory is always a write from the A9 for MMU programming and only read from the slave processor, that is the reason for not calling the unmap. I can re-look into the changes to call unmap in a proper way as this impacts the DMA API. Are there any other ways to perform only flush the memory from L1/L2 caches? We _could_ invent a new API to deal with this, which is probably going to be far better in the longer term for page table based iommus. That's going to need some thought - eg, do we need to pass a struct device argument for the iommu cache flushing so we know whether we need to flush or not (eg, if we have cache coherent iommus)... I agree with you, right now these functions are taking only start and end arguments but we can pass a struct deivice to these functions. thank you and regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial BN Nook Color support, take two
On Thu, 28 Apr 2011, gr...@linuxhacker.ru wrote: Hello! Ok, this is a second attempt at BN Nook Color board file submission. USB peripheral mode is fully operational as is serial console and MMC/SDCard. It's good that you're sending these patches, but please also: - Add a Signed-off-by: to each patch (see item 12 of Documentation/SubmittingPatches) - Cc Vikram, the original author of the board file, in the patch messages - Cc the linux-arm-ker...@lists.infradead.org mailing list - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Initial BN Nook Color support, take two
Hello! On Apr 28, 2011, at 1:05 PM, Paul Walmsley wrote: Ok, this is a second attempt at BN Nook Color board file submission. USB peripheral mode is fully operational as is serial console and MMC/SDCard. It's good that you're sending these patches, but please also: - Add a Signed-off-by: to each patch (see item 12 of Documentation/SubmittingPatches) Ah, sure. Somehow I assumed this one is auto generated for the patch submitter. (never was a problem in the past at least). - Cc Vikram, the original author of the board file, in the patch messages Ok, though I am not sure he is the original author of the nook color board file (since (C) 2008 well predates the Nook Color), the work I base this all off is from NookColor BN source code drop and unfortunately people that worked on it did not identify themselves (or I don't see it) aside from just names in some debug comments. - Cc the linux-arm-ker...@lists.infradead.org mailing list Ok, I am expecting the patch will still get quite a bit of scrutiny so I'll wait for more feedback and next submission would be conforming. Thanks! Bye, Oleg-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mtd: nand: Fix bad block identification issue
On Wed, 2011-04-27 at 17:39 +0530, Saxena, Parth wrote: This patch solves the above issue for omap by initialising badblockbits. We are working further on this to find a generic fix to the problem in nand_base.c. But it looks like the generic solution is to return the line which was accidentally removed, how about this patch From: Artem Bityutskiy artem.bityuts...@nokia.com Date: Thu, 28 Apr 2011 20:26:59 +0300 Subject: [PATCH] mtd: return badblockbits back In commit c7b28e25cb9beb943aead770ff14551b55fa8c79 the initialization of the backblockbits was accidentally removed. This patch returns it back, because otherwise some NAND drivers are broken. This problem was reported by Saxena, Parth parth.sax...@ti.com here: http://lists.infradead.org/pipermail/linux-mtd/2011-April/035221.html Reported-by: Saxena, Parth parth.sax...@ti.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Cc: sta...@kernel.org [2.6.36+] --- drivers/mtd/nand/nand_base.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 15510f2..5a7f817 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3106,6 +3106,8 @@ ident_done: chip-chip_shift += 32 - 1; } + chip-badblockbits = 8; + /* Set the bad block position */ if (mtd-writesize 512 || (busw NAND_BUSWIDTH_16)) chip-badblockpos = NAND_LARGE_BADBLOCK_POS; -- 1.7.2.3 -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Staging: Westbridge: replace custom debug macros with pr_...() macros
On Thu, 28 Apr 2011 20:48:41 +0200, Sutharsan sutharsan.t...@gmail.com
wrote:
@@ -2121,7 +2121,7 @@ static int cyasgadget_initialize(void)
cy_as_dev-dev_handle = cyasdevice_getdevhandle();
if (0 == cy_as_dev-dev_handle) {
#ifndef NDEBUG
- cy_as_hal_print_message(1 cy_as_gadget:
+ pr_debug(1 cy_as_gadget:
no west bridge device\n);
#endif
retval = -EFAULT;
That's actually incorrect. You should not have 1 in the
string. Not only that, 1 means that the message was actually
KERN_ALERT not KERN_DEBUG -- it looks like that is a mistake though.
At any rate, though, if you are using pr_debug() you don't need to
check for NDEBUG macro.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Staging: Westbridge: replace custom debug macros with pr_...() macros
On Thu, Apr 28, 2011 at 11:48:41AM -0700, Sutharsan wrote: From Sutharsan Ramamoorthy s...@cypress.com This patch replaces custom debug macros with Linux kernel's pr_...() macros. Why not use the dev_dbg() and other macros instead of these? You do have access to a struct device for all of these places in the code, right? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-2.6.38 error: kernel/power/consoleearlysuspend.c:28: error: implicit declaration of function ‘acquire_console_sem’
Hi, I get the following error when compiling using the omap2plus_defconfig, for the Overo Fire COM module, using linux-2.6.38. kernel/power/consoleearlysuspend.c: In function ‘console_early_suspend’: kernel/power/consoleearlysuspend.c:28: error: implicit declaration of function ‘acquire_console_sem’ kernel/power/consoleearlysuspend.c:34: error: implicit declaration of function ‘release_console_sem’ make[2]: *** [kernel/power/consoleearlysuspend.o] Error 1 Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] TI816X: Add minimal hwmod data
Hi On Wed, 27 Apr 2011, Hemant Pedanekar wrote: This patch adds minimum required hwmod data (e.g., UARTs) for bootup of TI816X. to review these patches, I'll need a copy of the TRM. Could you point me to it or send me one, please? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] TI816X: Add minimal hwmod data
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Thursday, April 28, 2011 3:35 PM to review these patches, I'll need a copy of the TRM. Could you point me to it or send me one, please? http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprugx8 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Initial BN Nook Color (encore) support.
Hi, Nook color has Ti OMAP 3621. 3621 CPU Support is not available in current kernel, adding CPU support will be nice before board. BN is set to release new source code in few days, taking new code as porting base is also recommended. Regards, Abimanyu G On Thu, Apr 28, 2011 at 9:27 PM, gr...@linuxhacker.ru wrote: From: Oleg Drokin gr...@linuxhacker.ru Bare-bones board file, comes with serial console, gpio keys, MMC/SDCard and USB support. --- arch/arm/mach-omap2/Kconfig | 5 + arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/board-omap3encore.c | 380 ++ arch/arm/plat-omap/include/plat/uncompress.h | 1 + arch/arm/tools/mach-types | 2 +- 5 files changed, 389 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3encore.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b997a35..5370561 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO for full description please see the products webpage at http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit +config MACH_ENCORE + bool Barnes Noble Encore (Nook Color) + depends on ARCH_OMAP3 + select OMAP_PACKAGE_CBP + config MACH_OVERO bool Gumstix Overo board depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 512b152..b894777 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -189,6 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o \ hsmmc.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o \ + hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ diff --git a/arch/arm/mach-omap2/board-omap3encore.c b/arch/arm/mach-omap2/board-omap3encore.c new file mode 100644 index 000..c7bf8de --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3encore.c @@ -0,0 +1,380 @@ +/* + * + * Copyright (C) 2008 Texas Instruments Inc. + * Vikram Pandita vikram.pand...@ti.com + * + * Modified from mach-omap2/board-ldp.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * April 2011 Oleg Drokin gr...@linuxhacker.ru - Port to 2.6.39 + * + */ + +#include linux/kernel.h +#include linux/platform_device.h +#include linux/gpio_keys.h +#include linux/err.h + +#include linux/spi/spi.h +#include linux/i2c/twl.h +#include linux/regulator/machine.h +#include linux/regulator/fixed.h +#include mach/hardware.h +#include asm/mach-types.h +#include asm/mach/arch.h + +#include mach/gpio.h +#include plat/board.h +#include plat/common.h +#include plat/usb.h +#include plat/mux.h +#include plat/sram.h +#include plat/mmc.h +#include plat/omap-serial.h +#include plat/system.h + +#include mux.h +#include hsmmc.h +#include sdram-hynix-h8mbx00u0mer-0em.h + +/* Encore-specific device-info and i2c addresses. */ +/* Battery, bus 1 */ +#define MAX17042_I2C_SLAVE_ADDRESS 0x36 +#define MAX17042_GPIO_FOR_IRQ 100 + +/*addition of MAXIM8903/TI GPIO mapping WRT schematics */ +#define MAX8903_UOK_GPIO_FOR_IRQ 115 +#define MAX8903_DOK_GPIO_FOR_IRQ 114 +#define MAX8903_GPIO_CHG_EN 110 +#define MAX8903_GPIO_CHG_STATUS 111 +#define MAX8903_GPIO_CHG_FLT 101 +#define MAX8903_GPIO_CHG_IUSB 102 +#define MAX8903_GPIO_CHG_USUS 104 +#define MAX8903_GPIO_CHG_ILM 61 + +/* TI WLAN */ +#define ENCORE_WIFI_PMENA_GPIO 22 +#define ENCORE_WIFI_IRQ_GPIO 15 +#define ENCORE_WIFI_EN_POW 16 + +/* Accelerometer i2c bus 1*/ +#define KXTF9_I2C_SLAVE_ADDRESS 0x0F +#define KXTF9_GPIO_FOR_PWR 34 +#define KXTF9_GPIO_FOR_IRQ 113 + +/* Touch screen i2c bus 2*/ +#define CYTTSP_I2C_SLAVEADDRESS 34 +#define ENCORE_CYTTSP_GPIO 99 +#define ENCORE_CYTTSP_RESET_GPIO 46 + +/* Audio codec, i2c bus 2 */ +#define AUDIO_CODEC_POWER_ENABLE_GPIO 103 +#define AUDIO_CODEC_RESET_GPIO 37 +#define AUDIO_CODEC_IRQ_GPIO 59 +#define AIC3100_I2CSLAVEADDRESS 0x18 + + +/* Different HW revisions */ +#define BOARD_ENCORE_REV_EVT1A 0x1 +#define BOARD_ENCORE_REV_EVT1B 0x2 +#define BOARD_ENCORE_REV_EVT2 0x3 +#define
Re: [PATCH 1/2] Initial BN Nook Color (encore) support.
Hello! Is there any special support needed for 3621, though? My understanding is that's just 3630 without a phone part? The .29 kernel they had only added is_omap3621 stuff that's not called anywhere, but smartreflex code (I guess that's might be useful to add too of course). I know about the new code drop is coming, but I don't expect there to be any basic stuff changes (and this board file is coming pretty barebones right now), besides I am not so optimistic to actually expect this patch to be merged right away, but I am already gathering valuable feedback. ;) BTW I saw in the archives that you are also working a port, do you have your tree hosted anywhere? Bye, Oleg On Apr 28, 2011, at 7:34 PM, Abimanyu Gottumukkala wrote: Hi, Nook color has Ti OMAP 3621. 3621 CPU Support is not available in current kernel, adding CPU support will be nice before board. BN is set to release new source code in few days, taking new code as porting base is also recommended. Regards, Abimanyu G On Thu, Apr 28, 2011 at 9:27 PM, gr...@linuxhacker.ru wrote: From: Oleg Drokin gr...@linuxhacker.ru Bare-bones board file, comes with serial console, gpio keys, MMC/SDCard and USB support. --- arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-omap3encore.c | 380 ++ arch/arm/plat-omap/include/plat/uncompress.h |1 + arch/arm/tools/mach-types|2 +- 5 files changed, 389 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3encore.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b997a35..5370561 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO for full description please see the products webpage at http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit +config MACH_ENCORE +bool Barnes Noble Encore (Nook Color) +depends on ARCH_OMAP3 +select OMAP_PACKAGE_CBP + config MACH_OVERO bool Gumstix Overo board depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 512b152..b894777 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -189,6 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \ hsmmc.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o \ + hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ diff --git a/arch/arm/mach-omap2/board-omap3encore.c b/arch/arm/mach-omap2/board-omap3encore.c new file mode 100644 index 000..c7bf8de --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3encore.c @@ -0,0 +1,380 @@ +/* + * + * Copyright (C) 2008 Texas Instruments Inc. + * Vikram Pandita vikram.pand...@ti.com + * + * Modified from mach-omap2/board-ldp.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * April 2011 Oleg Drokin gr...@linuxhacker.ru - Port to 2.6.39 + * + */ + +#include linux/kernel.h +#include linux/platform_device.h +#include linux/gpio_keys.h +#include linux/err.h + +#include linux/spi/spi.h +#include linux/i2c/twl.h +#include linux/regulator/machine.h +#include linux/regulator/fixed.h +#include mach/hardware.h +#include asm/mach-types.h +#include asm/mach/arch.h + +#include mach/gpio.h +#include plat/board.h +#include plat/common.h +#include plat/usb.h +#include plat/mux.h +#include plat/sram.h +#include plat/mmc.h +#include plat/omap-serial.h +#include plat/system.h + +#include mux.h +#include hsmmc.h +#include sdram-hynix-h8mbx00u0mer-0em.h + +/* Encore-specific device-info and i2c addresses. */ +/* Battery, bus 1 */ +#define MAX17042_I2C_SLAVE_ADDRESS 0x36 +#define MAX17042_GPIO_FOR_IRQ 100 + +/*addition of MAXIM8903/TI GPIO mapping WRT schematics */ +#define MAX8903_UOK_GPIO_FOR_IRQ 115 +#define MAX8903_DOK_GPIO_FOR_IRQ 114 +#define MAX8903_GPIO_CHG_EN110 +#define MAX8903_GPIO_CHG_STATUS111 +#define MAX8903_GPIO_CHG_FLT 101 +#define MAX8903_GPIO_CHG_IUSB 102 +#define MAX8903_GPIO_CHG_USUS 104 +#define MAX8903_GPIO_CHG_ILM 61 + +/* TI WLAN */ +#define ENCORE_WIFI_PMENA_GPIO 22 +#define ENCORE_WIFI_IRQ_GPIO 15 +#define
RE: [PATCH 1/2] TI816X: Add minimal hwmod data
On Thu, 28 Apr 2011, Grosen, Mark wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Thursday, April 28, 2011 3:35 PM to review these patches, I'll need a copy of the TRM. Could you point me to it or send me one, please? http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprugx8 Thanks Mark! - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
