RE: [PATCH 0/3] GPMC NAND isr using standard API
On Tue, 2012-05-22 at 04:26 +, Mohammed, Afzal wrote: Tony, Artem, how should the conflict between omap mtd trees be handled for patch series ? You merge the 2 trees and work on top of that? Or you wait for 3.5-r1 when everything is merged and work on top of that? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Afzal On Thu, 10 May 2012, Mohammed, Afzal wrote: On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote: (attribution lost) Major reason was that there are some boards that rely on bootloader settings, eg. kernel does not do any setting for smsc911x. I did not want to break those, at least it causes problem with omap3evm, see below But this is the whole point. The Linux GPMC driver and integration code should be setting up the GPMC registers based on board file and/or DT data, before the kernel touches any GPMC devices. We don't want to rely on the bootloader settings unless we absolutely have no other choice. Otherwise, the stability of the kernel could easily be impacted by the bootloader's GPMC timings and other register settings, and we want to minimize those potential sources of variation. So if we absolutely have no choice than to keep HWMOD_INIT_NO_RESET here, which doesn't sound like the case so far, we need to understand exactly why this is so. There are 14 out of 20 boards partially or fully relying on bootloader settings. I will try to do configuration for smsc911x in Kernel itself, this is the only one that can be tested from my side (on omap3evm), but there are other peripherals like NOR, quaduart, onenand-flash (different from omap-onenand), then smc91x (timings are not set from kernel for sdp boards), these would affect 7 boards of both omap2 omap3. To get configuration done from Kernel properly without having these boards is too tough for me. I'd suggest implementing two ways of programming the GPMC from the kernel. The first, preferred, method would be used with boards that we have timing data for that is independent from the GPMC clock rate -- i.e., timing data in nanoseconds or picoseconds. These boards will be capable of CORE DVFS. The second, deprecated, method would be used with boards that we only have GPMC clock rate-dependent timing data for -- i.e., raw GPMC register data. These boards will not be CORE DVFS-capable. It should be possible for the kernel to configure the GPMC with either one of these methods, either from DT or from platform_data. I'd suggest starting by adding code to allow a board file/DT to configure the GPMC to set the timings for a given chip-select based on clock rate-independent data (the first method above). Some good starting points for this code would be in the arch/arm/mach-omap2/gpmc-*.c files. Then the rate-independent data can be added for the boards which have available schematics or for which we have the data. For the DT case, you'll probably need to define a clock rate-independent binding if you haven't already. Next, I'd suggest implementing the code to allow GPMC timing configuration from raw register data (the second method above). This is hackish but for some boards, this is all we'll have. This will also presumably require some extra DT bindings for the register data. If this method is used, this code should also call a PM function to block clock rate changes on the GPMC clock, and an explanatory warning should be logged to the console. For boards that we don't have access to, and all someone would have are the register values set by the bootloader, I'd propose a phased approach: 1. The kernel should log the bootloader-provided GPMC timing registers to the console during boot, along with a warning message that indicates that GPMC for these boards will cease to function in the near future unless patches are provided to update the kernel board file and/or DT data with the GPMC register contents. This should allow people who have those boards and who care about them to submit kernel patches to allow the GPMC-attached devices to continue to function. 2. A patch to Documentation/feature-removal-schedule.txt should be submitted which states that support for implicit bootloader GPMC timings will be removed within two or three kernel releases. 3. The board maintainers and anyone who has contributed to the mainline git tree for those boards who seems to actually have the board should be contacted with a short E-mail message asking them to update their board GPMC timings. 4. When the expiration date specified in #2 is released, HWMOD_INIT_NO_RESET would be removed from the GPMC hwmod, and the GPMC code should refuse to initialize unless explicit timing data has been provided. If this protocol is followed, I wouldn't have a significant objection to specifying HWMOD_INIT_NO_RESET for the GPMC. That's because, under these conditions, the flag will only be present for a short period of time, and there will be a strong incentive for people with those boards to update the mainline board file/DT data with the GPMC timings. Otherwise their boards will be broken. Another issue on OMAP3EVM is the detection of evm revision based on phy id, by reading hardcoded address, 0x2c00. It had to be skipped to reach till above
RE: [PATCH 0/3] GPMC NAND isr using standard API
Hi Artem,
On Tue, May 22, 2012 at 11:44:43, Artem Bityutskiy wrote:
You merge the 2 trees and work on top of that? Or you wait for 3.5-r1
when everything is merged and work on top of that?
I will merge 2 trees do
Tony, are you ok with that ?
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH V2] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
Hello, On Mon, May 21, 2012 at 6:14 PM, Menon, Nishanth n...@ti.com wrote: On Mon, May 21, 2012 at 9:51 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: On Mon, May 21, 2012 at 08:36:35AM -0500, ext Nishanth Menon wrote: Sat, May 19, 2012 at 4:52 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: I guess it is time to properly document this increasing busy loop delay.. As it is getting closer to ms scale.. Does the following sound good? /* Maximum time for Voltage Processor to enter or exit idle */ Sounds way better :-). If you have an estimation of how long it takes in the average case, it might help. But I am OK already with the above, in case you don't have the estimation. /* * Maximum time for Voltage Processor to enter or exit idle * worst case is around 100uSec depending on when we intercepted VP * we use 5 times worst case value to be sure that the system flags * invalid condition */ better? Yes! Thanks. Regards, Nishanth Menon -- Eduardo Valentin -- 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 2/4] ARM: OMAP2: Remove legacy USB FS support
On Mon, May 21, 2012 at 12:01:06PM -0700, Tony Lindgren wrote:
The FS (Full Speed) USB controller is available on 2420 and 2430,
but not being used.
Out of the 2420 based boards only Nokia N8X0 are seeing active
development and they have external HS (High Speed) TUSB controller.
On omap 2430sdp there is MUSB HS controller, so there's no need
to use the legacy USB FS controller.
That leaves only H4 and Apollon boards that could use the FS USB
controller. As both H4 and Apollon boards are old proprietary
development boards, it's unlikely that we have any active
developers working on those boards using the USB.
So remove the FS USB support for omap2 machines. Patches are
welcome if somebody wants to instead fix it all up to the
current standards.
Cc: linux-...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig |2
arch/arm/mach-omap2/Makefile|3
arch/arm/mach-omap2/board-2430sdp.c | 11 -
arch/arm/mach-omap2/board-apollon.c | 18 --
arch/arm/mach-omap2/board-h4.c | 13 -
arch/arm/mach-omap2/usb-fs.c| 359
---
6 files changed, 406 deletions(-)
delete mode 100644 arch/arm/mach-omap2/usb-fs.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0e4dd67..042f157 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -64,13 +64,11 @@ config SOC_OMAP2420
depends on ARCH_OMAP2
default y
select OMAP_DM_TIMER
- select ARCH_OMAP_OTG
config SOC_OMAP2430
bool OMAP2430 support
depends on ARCH_OMAP2
default y
- select ARCH_OMAP_OTG
config SOC_OMAP3430
bool OMAP3430 support
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fa742f3..664224f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -244,9 +244,6 @@ obj-y +=
$(omap-flash-y) $(omap-flash-m)
omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o
obj-y+= $(omap-hsmmc-m)
$(omap-hsmmc-y)
-
-usbfs-$(CONFIG_ARCH_OMAP_OTG):= usb-fs.o
-obj-y+= $(usbfs-m) $(usbfs-y)
obj-y+= usb-musb.o
obj-y+= omap_phy_internal.o
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 99ca6ba..6523aea 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -254,16 +254,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct omap_usb_config sdp2430_usb_config __initdata = {
- .otg= 1,
-#ifdef CONFIG_USB_GADGET_OMAP
- .hmc_mode = 0x0,
-#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
- .hmc_mode = 0x1,
-#endif
- .pins[0]= 3,
-};
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -280,7 +270,6 @@ static void __init omap_2430sdp_init(void)
omap_serial_init();
omap_sdrc_init(NULL, NULL);
omap_hsmmc_init(mmc);
- omap2_usbfs_init(sdp2430_usb_config);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP);
usb_musb_init(NULL);
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 502c31e..519bcd3 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -35,7 +35,6 @@
#include asm/mach/flash.h
#include plat/led.h
-#include plat/usb.h
#include plat/board.h
#include common.h
#include plat/gpmc.h
@@ -253,13 +252,6 @@ out:
clk_put(gpmc_fck);
}
-static struct omap_usb_config apollon_usb_config __initdata = {
- .register_dev = 1,
- .hmc_mode = 0x14, /* 0:dev 1:host1 2:disable */
-
- .pins[0]= 6,
-};
-
static struct panel_generic_dpi_data apollon_panel_data = {
.name = apollon,
};
@@ -297,15 +289,6 @@ static void __init apollon_led_init(void)
gpio_request_array(apollon_gpio_leds, ARRAY_SIZE(apollon_gpio_leds));
}
-static void __init apollon_usb_init(void)
-{
- /* USB device */
- /* DEVICE_SUSPEND */
- omap_mux_init_signal(mcbsp2_clkx.gpio_12, 0);
- gpio_request_one(12, GPIOF_OUT_INIT_LOW, USB suspend);
- omap2_usbfs_init(apollon_usb_config);
-}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -321,7 +304,6 @@ static void __init omap_apollon_init(void)
apollon_init_smc91x();
Re: [PATCH 1/4] ARM: OMAP3: There is no FS USB controller on omap3
On Mon, May 21, 2012 at 12:01:02PM -0700, Tony Lindgren wrote: We should not select ARCH_OMAP_OTG as the hardware does not have the legacy FS (Full Speed) USB interface. Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 4cf5142..0e4dd67 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -76,7 +76,6 @@ config SOC_OMAP3430 bool OMAP3430 support depends on ARCH_OMAP3 default y - select ARCH_OMAP_OTG config SOC_TI81XX bool TI81XX support -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/4] ARM: OMAP: Make FS USB omap1 only
On Mon, May 21, 2012 at 12:01:09PM -0700, Tony Lindgren wrote: As the FS USB code is not being actively used for omap2+ there's no point keeping it around for omap2+. Let's make the FS USB platform init code omap1 only so we can remove the last user of omap_read/write for omap2+, and simplify things for further USB, DMA, and device tree related work. While at it, also group the mach includes for the related drivers. Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Felipe Balbi ba...@ti.com Are you planning to send this on v3.5 or v3.6 ? I guess it's too late for v3.5 ?!? --- arch/arm/mach-omap1/board-ams-delta.c |2 arch/arm/mach-omap1/board-generic.c |4 - arch/arm/mach-omap1/board-h2.c |2 arch/arm/mach-omap1/board-h3.c |2 arch/arm/mach-omap1/board-htcherald.c |2 arch/arm/mach-omap1/board-innovator.c |2 arch/arm/mach-omap1/board-nokia770.c|2 arch/arm/mach-omap1/board-osk.c |2 arch/arm/mach-omap1/board-palmte.c |2 arch/arm/mach-omap1/board-palmtt.c |2 arch/arm/mach-omap1/board-palmz71.c |2 arch/arm/mach-omap1/board-sx1.c |2 arch/arm/mach-omap1/board-voiceblue.c |3 arch/arm/mach-omap1/clock_data.c|3 arch/arm/mach-omap1/include/mach/usb.h | 165 ++ arch/arm/mach-omap1/usb.c | 116 ++ arch/arm/plat-omap/Makefile |2 arch/arm/plat-omap/include/plat/board.h | 38 -- arch/arm/plat-omap/include/plat/usb.h | 196 --- arch/arm/plat-omap/usb.c| 145 --- drivers/usb/gadget/Kconfig |2 drivers/usb/gadget/omap_udc.c |3 drivers/usb/host/Kconfig|2 drivers/usb/host/ohci-omap.c|7 + drivers/usb/otg/isp1301_omap.c |2 25 files changed, 310 insertions(+), 400 deletions(-) create mode 100644 arch/arm/mach-omap1/include/mach/usb.h delete mode 100644 arch/arm/plat-omap/usb.c diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index f2f8a58..c534698 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -37,12 +37,12 @@ #include plat/board-ams-delta.h #include plat/keypad.h #include plat/mux.h -#include plat/usb.h #include plat/board.h #include mach/hardware.h #include mach/ams-delta-fiq.h #include mach/camera.h +#include mach/usb.h #include iomap.h #include common.h diff --git a/arch/arm/mach-omap1/board-generic.c b/arch/arm/mach-omap1/board-generic.c index e75e2d5..6ec385e 100644 --- a/arch/arm/mach-omap1/board-generic.c +++ b/arch/arm/mach-omap1/board-generic.c @@ -23,8 +23,10 @@ #include asm/mach/map.h #include plat/mux.h -#include plat/usb.h #include plat/board.h + +#include mach/usb.h + #include common.h /* assume no Mini-AB port */ diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c index a28e989..44a4ab1 100644 --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -40,11 +40,11 @@ #include plat/dma.h #include plat/tc.h #include plat/irda.h -#include plat/usb.h #include plat/keypad.h #include plat/flash.h #include mach/hardware.h +#include mach/usb.h #include common.h #include board-h2.h diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c index 108a864..86cb5a0 100644 --- a/arch/arm/mach-omap1/board-h3.c +++ b/arch/arm/mach-omap1/board-h3.c @@ -40,13 +40,13 @@ #include plat/mux.h #include plat/tc.h -#include plat/usb.h #include plat/keypad.h #include plat/dma.h #include plat/flash.h #include mach/hardware.h #include mach/irqs.h +#include mach/usb.h #include common.h #include board-h3.h diff --git a/arch/arm/mach-omap1/board-htcherald.c b/arch/arm/mach-omap1/board-htcherald.c index 118a9d4..b3f6e94 100644 --- a/arch/arm/mach-omap1/board-htcherald.c +++ b/arch/arm/mach-omap1/board-htcherald.c @@ -44,10 +44,10 @@ #include plat/omap7xx.h #include plat/board.h #include plat/keypad.h -#include plat/usb.h #include plat/mmc.h #include mach/irqs.h +#include mach/usb.h #include common.h diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c index 7970223..f21c296 100644 --- a/arch/arm/mach-omap1/board-innovator.c +++ b/arch/arm/mach-omap1/board-innovator.c @@ -35,11 +35,11 @@ #include plat/flash.h #include plat/fpga.h #include plat/tc.h -#include plat/usb.h #include plat/keypad.h #include plat/mmc.h #include mach/hardware.h +#include mach/usb.h #include iomap.h #include common.h diff --git
Re: [PATCH 4/4] USB: Remove omap2 support from omap_udc.c
On Mon, May 21, 2012 at 12:01:11PM -0700, Tony Lindgren wrote:
There are no active users of this code for omap2 as
the boards in use have either TUSB or MUSB controller.
While at it, also fix warnings related to uninitialized
dc_clk and hhc_clk.
Cc: linux-...@vger.kernel.org
Cc: Felipe Balbi ba...@ti.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Tony Lindgren t...@atomide.com
This one doesn't depend on the rest of the series, I can take it myself
to v3.6 or you can take it with your series:
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/gadget/omap_udc.c | 113
-
1 file changed, 23 insertions(+), 90 deletions(-)
diff --git a/drivers/usb/gadget/omap_udc.c b/drivers/usb/gadget/omap_udc.c
index 2acf06c..913587f 100644
--- a/drivers/usb/gadget/omap_udc.c
+++ b/drivers/usb/gadget/omap_udc.c
@@ -62,9 +62,6 @@
#define DMA_ADDR_INVALID(~(dma_addr_t)0)
-#define OMAP2_DMA_CH(ch) (((ch) - 1) 1)
-#define OMAP24XX_DMA(name, ch) (OMAP24XX_DMA_##name + OMAP2_DMA_CH(ch))
-
/*
* The OMAP UDC needs _very_ early endpoint setup: before enabling the
* D+ pullup to allow enumeration. That's too early for the gadget
@@ -537,12 +534,8 @@ static void next_in_dma(struct omap_ep *ep, struct
omap_req *req)
: OMAP_DMA_SYNC_ELEMENT;
int dma_trigger = 0;
- if (cpu_is_omap24xx())
- dma_trigger = OMAP24XX_DMA(USB_W2FC_TX0, ep-dma_channel);
-
/* measure length in either bytes or packets */
if ((cpu_is_omap16xx() length = UDC_TXN_TSC)
- || (cpu_is_omap24xx() length ep-maxpacket)
|| (cpu_is_omap15xx() length ep-maxpacket)) {
txdma_ctrl = UDC_TXN_EOT | length;
omap_set_dma_transfer_params(ep-lch, OMAP_DMA_DATA_TYPE_S8,
@@ -601,28 +594,14 @@ static void next_out_dma(struct omap_ep *ep, struct
omap_req *req)
int dma_trigger = 0;
u16 w;
- if (cpu_is_omap24xx())
- dma_trigger = OMAP24XX_DMA(USB_W2FC_RX0, ep-dma_channel);
-
- /* NOTE: we filtered out short reads before, so we know
- * the buffer has only whole numbers of packets.
- * except MODE SELECT(6) sent the 24 bytes data in OMAP24XX DMA mode
- */
- if (cpu_is_omap24xx() packets ep-maxpacket) {
- omap_set_dma_transfer_params(ep-lch, OMAP_DMA_DATA_TYPE_S8,
- packets, 1, OMAP_DMA_SYNC_ELEMENT,
- dma_trigger, 0);
- req-dma_bytes = packets;
- } else {
- /* set up this DMA transfer, enable the fifo, start */
- packets /= ep-ep.maxpacket;
- packets = min(packets, (unsigned)UDC_RXN_TC + 1);
- req-dma_bytes = packets * ep-ep.maxpacket;
- omap_set_dma_transfer_params(ep-lch, OMAP_DMA_DATA_TYPE_S16,
- ep-ep.maxpacket 1, packets,
- OMAP_DMA_SYNC_ELEMENT,
- dma_trigger, 0);
- }
+ /* set up this DMA transfer, enable the fifo, start */
+ packets /= ep-ep.maxpacket;
+ packets = min(packets, (unsigned)UDC_RXN_TC + 1);
+ req-dma_bytes = packets * ep-ep.maxpacket;
+ omap_set_dma_transfer_params(ep-lch, OMAP_DMA_DATA_TYPE_S16,
+ ep-ep.maxpacket 1, packets,
+ OMAP_DMA_SYNC_ELEMENT,
+ dma_trigger, 0);
omap_set_dma_dest_params(ep-lch, OMAP_DMA_PORT_EMIFF,
OMAP_DMA_AMODE_POST_INC, req-req.dma + req-req.actual,
0, 0);
@@ -761,10 +740,7 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
ep-dma_channel = channel;
if (is_in) {
- if (cpu_is_omap24xx())
- dma_channel = OMAP24XX_DMA(USB_W2FC_TX0, channel);
- else
- dma_channel = OMAP_DMA_USB_W2FC_TX0 - 1 + channel;
+ dma_channel = OMAP_DMA_USB_W2FC_TX0 - 1 + channel;
status = omap_request_dma(dma_channel,
ep-ep.name, dma_error, ep, ep-lch);
if (status == 0) {
@@ -781,11 +757,7 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
0, 0);
}
} else {
- if (cpu_is_omap24xx())
- dma_channel = OMAP24XX_DMA(USB_W2FC_RX0, channel);
- else
- dma_channel = OMAP_DMA_USB_W2FC_RX0 - 1 + channel;
-
+ dma_channel = OMAP_DMA_USB_W2FC_RX0 - 1 + channel;
status = omap_request_dma(dma_channel,
ep-ep.name, dma_error, ep, ep-lch);
if (status == 0) {
@@ -809,7 +781,7 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
omap_disable_dma_irq(ep-lch,
Re: [PATCH] OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
On Mon, 2012-05-21 at 21:47 -0500, Ricardo Neri wrote: genirq requires that the IRQ requests that do not provided a handler to use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line is reenabled while the interrupt is still asserted. While this situation may not happen in edge type interrupts, genirq still requires to use IRQF_ONESHOT. Also, remove the IRQF_DISABLED as the flag is now a NOOP and has been deprecated. Thanks, I'll apply. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/7] remoteproc: resource table overhaul
Hi Michal, On Tue, May 22, 2012 at 8:51 AM, Michal Simek mon...@monstr.eu wrote: Simple enabling RSC_VDEV in rproc_handle_rsc doesn't work. Sure - you'll need to actually plug the vrings allocation code there, too (i.e. this requires some coding, it's not a 1-liner). BTW: I am using kernel modules and there is no dependency for virtio_rpmsg_bus in remoteproc module in sense if you load remoteproc module you also need to load virtio_rpmsg_bus to get firmware to work. This is expected: remoteproc only provides means for booting and controlling remote processors and it doesn't boot them upfront. To actually boot a remote processor, and do something useful with it, one needs to load a module which utilizes remoteproc's API (e.g. virtio_rpmsg_bus, but YMMV). ~ # lsmod ~ # modprobe zynq_remoteproc zynq_remoteproc: Unknown symbol rproc_register (err 0) zynq_remoteproc: Unknown symbol rproc_alloc (err 0) zynq_remoteproc: Unknown symbol rproc_vq_interrupt (err 0) zynq_remoteproc: Unknown symbol rproc_free (err 0) zynq_remoteproc: Unknown symbol rproc_unregister (err 0) We don't have these errors - have you tried looking into them ? Btw do you plan on submitting the code for zynq_remoteproc ? Can you see the same behavior on omap? Except the Unknown symbol errors, everything else looks good. Thanks, Ohad. -- 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] remoteproc/omap: fix dev_err typo
For some reason one of the dev_err invocations is using a wrong
device so fix that.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/remoteproc/omap_remoteproc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 69425c4..de138e30 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -182,7 +182,7 @@ static int __devinit omap_rproc_probe(struct
platform_device *pdev)
ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
if (ret) {
- dev_err(pdev-dev.parent, dma_set_coherent_mask: %d\n, ret);
+ dev_err(pdev-dev, dma_set_coherent_mask: %d\n, ret);
return ret;
}
--
1.7.5.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
Re: [PATCH 1/7] remoteproc: resource table overhaul
Hi Ohad and Michal yes I can share my patch, remoteproc has evolved and my patch is not aligned on latest version of remote proc (especially since remoteproc: remove the single rpmsg vdev limitation). Ohad, for alignment I can take the latest branch of kernel.org (remoteproc) branch for-next? /BR Ludovic Barré On 05/22/2012 07:51 AM, Michal Simek wrote: Hi Ohad and Ludovic, 2012/5/21 Ohad Ben-Cohen o...@wizery.com mailto:o...@wizery.com Hi Michal, On Mon, May 21, 2012 at 4:02 PM, Michal Simek mon...@monstr.eu mailto:mon...@monstr.eu wrote: I have looked at it and tested on latest and greatest and the problem is still there. Ok, I see why this is happening. We're now allocating the vrings' DMA in -find_vqs() just before we boot the remote processor, and we release it on -del_vqs(). These are the virtio handlers for setting up and tearing down the vrings, so it makes sense to do so, but as a result, we still don't get the early carveout allocation you wanted. I have looked at the code and path is rproc_fw_config_virtio - rproc_handliefirtion_rsc - rproc_handle_vdev Please note that rproc_handle_vdev doesn't allocate any DMA at this point, and the allocation path is now quite different - it begins with virtio_rpmsg_bus probing and then calling into the -find_vqs() handler. For me it is necessary to ensure that dma_alloc_coherent in rproc_alloc_vring is called after carveout allocation just because dma_alloc_cohorent takes mermory from preallocated pool which starts at 0x0. ok. I also don't have any other advance mechanism how to ensure mapping for the second arm core. Probably the best way to ensure this (without it breaking unexpectedly again as remoteproc evolves) is to have separate sub-devices for different kind of memories, which remoteproc could then look up using something like device_find_child(). Ludovic is exploring this direction too, because STE also needs to bind specific memory regions with predefined purposes, without depending on the order of DMA allocations. It is good that someone else has similar requirements. I think Ludovic already has a preliminary patch which he may be able to share with you. Ludovic: Can you share your patch with us? I would like to try it. Here is log which I need to get. Look at attached patch which exactly show you what I need to do which I have tested. Yes, I see. Another temporary approach might be moving the vrings' allocations to the rproc_handle_rsc table (in the RSC_VDEV slot), but I'm not sure we want to merge this as well because this solution too is only hiding the real issue and not solving it permanently. Simple enabling RSC_VDEV in rproc_handle_rsc doesn't work. BTW: I am using kernel modules and there is no dependency for virtio_rpmsg_bus in remoteproc module in sense if you load remoteproc module you also need to load virtio_rpmsg_bus to get firmware to work. I think that will be good to create that dependency automatically because you need to load virtio_rpmsg_bus when you problem remoteproc module. ~ # lsmod ~ # modprobe zynq_remoteproc zynq_remoteproc: Unknown symbol rproc_register (err 0) zynq_remoteproc: Unknown symbol rproc_alloc (err 0) zynq_remoteproc: Unknown symbol rproc_vq_interrupt (err 0) zynq_remoteproc: Unknown symbol rproc_free (err 0) zynq_remoteproc: Unknown symbol rproc_unregister (err 0) CPU1: shutdown zynq_remoteproc 0.remoteproc-test: 0.remoteproc-test is available zynq_remoteproc 0.remoteproc-test: Note: remoteproc is still under development and considered experimental. zynq_remoteproc 0.remoteproc-test: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. ~ # zynq_remoteproc 0.remoteproc-test: registered virtio0 (type 7) ~ # lsmod zynq_remoteproc 4346 0 - Live 0xbf01f000 remoteproc 13831 1 zynq_remoteproc, Live 0xbf018000 virtio 2840 1 remoteproc, Live 0xbf008000 virtio_ring 4965 1 remoteproc, Live 0xbf013000 ~ # ~ # modprobe virtio_rpmsg_bus zynq_remoteproc 0.remoteproc-test: powering up 0.remoteproc-test zynq_remoteproc 0.remoteproc-test: Booting fw image test, size 2351790 zynq_remoteproc 0.remoteproc-test: remote processor 0.remoteproc-test is now up virtio_rpmsg_bus virtio0: rpmsg host is online virtio_rpmsg_bus virtio0: creating channel rpmsg-timer-statistic addr 0x50 ~ # ~ # lsmod virtio_rpmsg_bus 7575 0 - Live 0xbf024000 zynq_remoteproc 4346 1 - Live 0xbf01f000 remoteproc 13831 1 zynq_remoteproc, Live 0xbf018000 virtio 2840 2 virtio_rpmsg_bus,remoteproc, Live 0xbf008000 virtio_ring 4965 2 virtio_rpmsg_bus,remoteproc, Live 0xbf013000 ~ # Can you see the same behavior on omap? Thanks, Michal -- 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
Re: [PATCH 1/7] remoteproc: resource table overhaul
Hi Ludovic, On Tue, May 22, 2012 at 12:14 PM, frq09524 ludovic.ba...@stericsson.com wrote: Ohad, for alignment I can take the latest branch of kernel.org (remoteproc) branch for-next? Sure, it's pretty much updated sans a few simple changes. Thanks, Ohad. -- 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] backlight: initialize struct backlight_properties properly
On Mon, May 21, 2012 at 8:24 AM, Corentin Chary corentin.ch...@gmail.com wrote: In all these files, the .power field was never correctly initialized. Signed-off-by: Corentin Chary corentin.ch...@gmail.com --- drivers/gpu/drm/i915/intel_panel.c | 1 + drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 1 + I've taken these two hunks into drm-next. Dave. -- 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
[GIT PULL] OMAP DSS for v3.5
Hi Florian, Here are the OMAP DSS changes for 3.5. I really tried this time to send the pull request early, but here I am again, sending it when the merge window has already opened... A few late-found bugs caused some unnecessary delays. I'm using github this time instead of gitorious, as gitorious seems to be down. This is my first pull request with a signed tag, I hope everything is correct. Note that there's a merge for small branch with omap board file changes (e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07) that is also pulled by Tony for the linux-omap tree. This is meant to help avoid conflicts in the board files. Tomi The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c: Linux 3.4-rc4 (2012-04-21 14:47:52 -0700) are available in the git repository at: git://github.com/tomba/linux.git tags/omapdss-for-3.5 for you to fetch changes up to e92a5b28f71aea01b281f9c89d97a4bc5b24748f: OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300) Omapdss driver changes for 3.5 merge window. Lots of normal development commits, but perhaps most notable changes are: * HDMI rework to properly decouple the HDMI audio part from the HDMI video part. * Restructure omapdss core driver so that it's possible to implement device tree support. This included changing how platform data is passed to the drivers, changing display device registration and improving the panel driver's ability to configure the underlying video output interface. * Basic support for DSI packet interleaving Archit Taneja (19): OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size OMAPDSS: DISPC: Use a common function to set manager timings OMAPDSS: DISPC: Clean up manager timing/size functions OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump OMAPDSS: HDMI: define and dump CORE registers in correct order OMAPDSS: Fix DSI_FCLK clock source selection OMAPDSS: DISPC: Remove Fake VSYNC support OMAPDSS: APPLY: Add manager timings as extra_info in private data OMAPDSS: Apply manager timings instead of direct DISPC writes OMAPDSS: MANAGER: Create a function to check manager timings OMAPDSS: APPLY: Don't check manager settings if it is disabled OMAPDSS: APPLY: Remove display dependency from overlay and manager checks OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC OMAPDSS: Apply VENC timings even if panel is disabled Axel Castaneda Gonzalez (1): OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop Chandrabhanu Mahapatra (5): OMAPDSS: DISPC: Enable predecimation OMAPDSS: DISPC: Handle synclost errors in OMAP3 OMAPDSS: DISPC: Correct DISPC functional clock usage OMAPDSS: DISPC: Update Accumulator configuration for chroma plane OMAPDSS: DISPC: Support rotation through TILER Grazvydas Ignotas (5): OMAPDSS: OMAPFB: check for matching memory size early OMAPDSS: provide default get_timings function for panels OMAPDSS: TPO-TD03MTEA1: add set/check timing functions OMAPDSS: VENC: allow switching venc output type at runtime OMAPDSS: OMAPFB: always allow to configure overlay Jan Weitzel (1): ARM: OMAP2+ Add Primview displays to panel-generic Mark Brown (4): OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage OMAPDSS: VENC: Check for errors from regulator_enable() OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable() OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay Peter Meerwald (1): OMAPFB: remove unused FB_OMAP_BOOTLOADER_INIT config option Ricardo Neri (15): OMAPDSS: Provide an interface for audio support OMAPDSS: HDMI: Split audio_enable into audio_enable/disable OMAPDSS: HDMI: Split video_enable into video_enable/disable OMAPDSS: HDMI: Remove ASoC codec OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings OMAPDSS: HDMI: Decouple HDMI audio from ASoC OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio OMAPDSS: HDMI: Relocate N/CTS calculation OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation OMAPDSS: HDMI: Add an audio configuration function OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order OMAPDSS: HDMI: Panel:
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Paul, On Tue, May 22, 2012 at 12:17:30, Paul Walmsley wrote: Hi Afzal On Thu, 10 May 2012, Mohammed, Afzal wrote: On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote: (attribution lost) Hmm, second time, normally I try to delete as much as possible contents from the original mail to make it more readable while keeping the core I'd suggest implementing two ways of programming the GPMC from the kernel. The first, preferred, method would be used with boards that we have timing data for that is independent from the GPMC clock rate -- i.e., timing data in nanoseconds or picoseconds. These boards will be capable of CORE DVFS. The second, deprecated, method would be used with boards that we only have GPMC clock rate-dependent timing data for -- i.e., raw GPMC register data. These boards will not be CORE DVFS-capable. It should be possible for the kernel to configure the GPMC with either one of these methods, either from DT or from platform_data. I'd suggest starting by adding code to allow a board file/DT to configure the GPMC to set the timings for a given chip-select based on clock rate-independent data (the first method above). Some good starting points for this code would be in the arch/arm/mach-omap2/gpmc-*.c files. Then the rate-independent data can be added for the boards which have available schematics or for which we have the data. For the DT case, you'll probably need to define a clock rate-independent binding if you haven't already. Next, I'd suggest implementing the code to allow GPMC timing configuration from raw register data (the second method above). This is hackish but for some boards, this is all we'll have. This will also presumably require some extra DT bindings for the register data. If this method is used, this code should also call a PM function to block clock rate changes on the GPMC clock, and an explanatory warning should be logged to the console. For boards that we don't have access to, and all someone would have are the register values set by the bootloader, I'd propose a phased approach: 1. The kernel should log the bootloader-provided GPMC timing registers to the console during boot, along with a warning message that indicates that GPMC for these boards will cease to function in the near future unless patches are provided to update the kernel board file and/or DT data with the GPMC register contents. This should allow people who have those boards and who care about them to submit kernel patches to allow the GPMC-attached devices to continue to function. 2. A patch to Documentation/feature-removal-schedule.txt should be submitted which states that support for implicit bootloader GPMC timings will be removed within two or three kernel releases. 3. The board maintainers and anyone who has contributed to the mainline git tree for those boards who seems to actually have the board should be contacted with a short E-mail message asking them to update their board GPMC timings. 4. When the expiration date specified in #2 is released, HWMOD_INIT_NO_RESET would be removed from the GPMC hwmod, and the GPMC code should refuse to initialize unless explicit timing data has been provided. If this protocol is followed, I wouldn't have a significant objection to specifying HWMOD_INIT_NO_RESET for the GPMC. That's because, under these conditions, the flag will only be present for a short period of time, and there will be a strong incentive for people with those boards to update the mainline board file/DT data with the GPMC timings. Otherwise their boards will be broken. Summarized GPMC tasks as per my understanding based on Tony's yours comments and that I am working on as follows, 1. convert to driver 2. remove dependency of bootloader for configuration Approach being taken is to migrate to driver while keeping old interface w.r.t boards intact (i.e. configuring gpmc in board files for old interface can be done the way it is done now, tasks now achieved in gpmc_init would be done by probe, only that much, but that would not make any difference for boards using old interface) along with having new interface till all boards are converted to use new interface. Once all boards are converted to use new interface, old interface would be removed. For boards using new interface, in probe, in addition to the tasks presently done by gpmc_init, it would do configuring for boards, creating platform devices for the peripherals connected. Configuration that is not presently done in Kernel would be handled the way you have suggested; first preference clk rate independent, if not possible then use register values, if that also not possible do as per your points 1-4. GPMC configuration that would be added newly in the Kernel would be using new interface Tony, Paul, please let me know if you have any divergent views on the above. Another issue on OMAP3EVM is the
[PATCH] remoteproc: block premature rproc booting
When an rproc instance is registered, remoteproc asynchronously
loads its firmware in order to tell which vdevs it supports.
Later on those vdevs are registered, and when probed, their drivers
usually trigger powering on of the remote processor.
OTOH, non-standard scenarios might involve early invocation of
rproc_boot even before the asynchronous fw loading has completed.
We're not sure we really want to support those scenarios, but right
now we do (e.g. via rproc_get_by_name), so let's simply fix this race
by blocking those premature rproc_boot() flows until the async fw
loading is completed.
Reported-and-tested-by: Sjur Brandeland sjur.brandel...@stericsson.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
drivers/remoteproc/remoteproc_core.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 40e2b2d..464ea4f 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -1141,6 +1141,18 @@ int rproc_boot(struct rproc *rproc)
dev = rproc-dev;
+ /*
+* if asynchronoush fw loading is underway, wait up to 65 secs
+* (just a bit more than the firmware request's timeout)
+*/
+ ret = wait_for_completion_interruptible_timeout(
+ rproc-firmware_loading_complete,
+ msecs_to_jiffies(65000));
+ if (ret = 0) {
+ dev_err(dev, async fw loading isn't complete: %d\n, ret);
+ return ret ? ret : -ETIMEDOUT;
+ }
+
ret = mutex_lock_interruptible(rproc-lock);
if (ret) {
dev_err(dev, can't lock rproc %s: %d\n, rproc-name, ret);
--
1.7.5.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
Re: [PATCH 1/7] remoteproc: resource table overhaul
hi Ohad
In my previous patch, to find the correct subdevice that match with
physical memory, I used pa member of rproc_mem_entry.
but today in these 2 resources: fw_rsc_trace, fw_rsc_vdev_vring, pa
menber has been removed.
for fw_rsc_trace it's not a problem, because use rproc_da_to_va and
carveout feature.
but for fw_rsc_vdev_vring, I think use da member, like this.
dev = rproc_dma_find_dev(rproc, (phys_addr_t) vring-da);
va = dma_alloc_coherent(dev, size, dma, GFP_KERNEL);
if (!va) {
dev_err(dev, dma_alloc_coherent failed\n);
return -EINVAL;
}
are you OK ?
/BR
Ludovic Barré
On 05/22/2012 11:22 AM, Ohad Ben-Cohen wrote:
Hi Ludovic,
On Tue, May 22, 2012 at 12:14 PM, frq09524ludovic.ba...@stericsson.com wrote:
Ohad, for alignment I can take the latest branch of kernel.org (remoteproc)
branch for-next?
Sure, it's pretty much updated sans a few simple changes.
Thanks,
Ohad.
--
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 V3 1/3] ARM: OMAP3+: PM: VP: ensure VP is idle before disable
From: Wenbiao Wang ww...@ti.com Voltage Processor state machine transition to disable need to occur from IDLE state. When we transition OPP in a functioning system, the call sequence for an OPP transition is as follows: omap_sr_disable - sr class 3 disable - vp disable - sr disable forceupdate to voltage/frequency scale depending on which OPP we are transitioning to. If we hit a critical timing window where SR had commanded VP for a voltage transition and VP is in the middle of operating on that command, it needs to go through a few states before going to update state(where it actually sends the command to VC). Initial view of h/w owners is that the state disable of VP is expected to be sampled for the next transition. Instead, to be on a safer side, we ensure that the valid states of the VP state machine is diligently followed by software. This can be done by waiting for VP to be in idle prior to disabling VP. Existing prints have been updated to ensure context is available on error messages. As part of this change, increase timeout for VP idle check to improbable 500uSec to be certain that system is indeed unable to continue before crashing out with error(worst case expectancy remains the same 3-100uSec depending on when we caught VP). Update macro documentation as well Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Eduardo Valentin eduardo.valen...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org [n...@ti.com: port from android] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Wenbiao Wang ww...@ti.com --- V3: updated documenation for VP_IDLE_TIMEOUT macro V2: http://marc.info/?t=13373654251r=1w=2 arch/arm/mach-omap2/vp.c | 15 +-- arch/arm/mach-omap2/vp.h |9 +++-- 2 files changed, 20 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c index f95c1ba..925d869 100644 --- a/arch/arm/mach-omap2/vp.c +++ b/arch/arm/mach-omap2/vp.c @@ -262,6 +262,17 @@ void omap_vp_disable(struct voltagedomain *voltdm) return; } + /* +* Wait for VP idle Typical latency is 2us. Maximum latency is ~100us +* Depending on if we catch VP in the middle of an SR operation. +*/ + omap_test_timeout((voltdm-read(vp-vstatus)), + VP_IDLE_TIMEOUT, timeout); + + if (timeout = VP_IDLE_TIMEOUT) + pr_warning(%s: vdd_%s idle timedout before disable\n, + __func__, voltdm-name); + /* Disable VP */ vpconfig = voltdm-read(vp-vpconfig); vpconfig = ~vp-common-vpconfig_vpenable; @@ -274,8 +285,8 @@ void omap_vp_disable(struct voltagedomain *voltdm) VP_IDLE_TIMEOUT, timeout); if (timeout = VP_IDLE_TIMEOUT) - pr_warning(%s: vdd_%s idle timedout\n, - __func__, voltdm-name); + pr_warning(%s: vdd_%s idle timedout after disable\n, + __func__, voltdm-name); vp-enabled = false; diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..79b159f 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -30,8 +30,13 @@ struct voltagedomain; #define OMAP4_VP_VDD_IVA_ID 1 #define OMAP4_VP_VDD_MPU_ID 2 -/* XXX document */ -#define VP_IDLE_TIMEOUT200 +/* + * Maximum time for Voltage Processor to enter or exit idle + * worst case is around 100uSec depending on when we intercepted VP + * we use 5 times worst case value to be sure that the system flags + * invalid condition + */ +#define VP_IDLE_TIMEOUT500 #define VP_TRANXDONE_TIMEOUT 300 /** -- 1.7.9.5 -- 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: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote: On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote: On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote: Cousson, Benoitb-cous...@ti.com writes: On 4/24/2012 4:46 PM, Tero Kristo wrote: On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: From: Rajendra Nayakrna...@ti.com On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relyed on the power domain level context status. Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. Potentially? Is that the case on OMAP4/5 today? I don't see any for OMAP4 in mainline. No, we don;t have any such cases today in either OMAP4 or OMAP5. If zero really is a valid offset somewhere (where?), then we could use -1 (or USHRT_MAX in this case.) This makes sense for OMAP4 and beyond (and same with having a flag to indicate the *lack* of having the feature) as it will mean just adding a few entries in hwmod data files to indicate IP blocks (very few) which do not support this feature. However since none of OMAP2/3 varients (except I guess the AM family) support this, it would also mean we mark *most* blocks in OMAP2/3 to indicate they *lack* this feature, which would mean bloating the OMAP2/3 data files, but your comment below about doing it for all IPs during hwmod registration makes sense at least for OMAP2 since *all* blocks can be marked at registration. OMAP3 would probably need more data files to be updated to indicate which ones support and which ones don't. Having said that I also see 'context_reg' being defined inside omap_hwmod_omap4_prcm would need to be fixed if we have to support this for SoCs which fall as OMAP3 varients. I just went back and looked at Vaibhavs patch which adds am33xx hwmod data and I think none of what I said above is a problem. I think we can safely mark the few blocks on OMAP4 which do not have a valid context_reg with -1 or USHRT_MAX as you suggested and mark all OMAP2/3 blocks with this at registration. Benoit/Paul, does that sound good? Any comments to this? This is blocking v6 for this set. Also, who is going to generate the hwmod data? -Tero Yeah, but still, every OMAP4 IPs are supporting that except two of them I guess, so it is a pity to add that to every IPs. We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not supporting that. Since OMAP 2 3 does not have this feature at all, we can check on the cpu revision. I think the issue raised by Rajendra was about AM35xx that looks like an OMAP3 variant but does have these registers like an OMAP4 variant:-( If AM335x is missing it for *all* IPs, that's easy enough to solve without bloating the data file: just set .context_offs field (or flag) to the magic value for all IPs during hwmod registration. Paul/Benoit should make the call whether to use a special value in the .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I agree with Benoit that it should indicate the *lack* of the feature, since having the feature is the norm. Kevin -- 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: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
On 5/22/2012 4:20 PM, Tero Kristo wrote: On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote: On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote: On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote: Cousson, Benoitb-cous...@ti.com writes: On 4/24/2012 4:46 PM, Tero Kristo wrote: On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: From: Rajendra Nayakrna...@ti.com On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relyed on the power domain level context status. Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. Potentially? Is that the case on OMAP4/5 today? I don't see any for OMAP4 in mainline. No, we don;t have any such cases today in either OMAP4 or OMAP5. If zero really is a valid offset somewhere (where?), then we could use -1 (or USHRT_MAX in this case.) This makes sense for OMAP4 and beyond (and same with having a flag to indicate the *lack* of having the feature) as it will mean just adding a few entries in hwmod data files to indicate IP blocks (very few) which do not support this feature. However since none of OMAP2/3 varients (except I guess the AM family) support this, it would also mean we mark *most* blocks in OMAP2/3 to indicate they *lack* this feature, which would mean bloating the OMAP2/3 data files, but your comment below about doing it for all IPs during hwmod registration makes sense at least for OMAP2 since *all* blocks can be marked at registration. OMAP3 would probably need more data files to be updated to indicate which ones support and which ones don't. Having said that I also see 'context_reg' being defined inside omap_hwmod_omap4_prcm would need to be fixed if we have to support this for SoCs which fall as OMAP3 varients. I just went back and looked at Vaibhavs patch which adds am33xx hwmod data and I think none of what I said above is a problem. I think we can safely mark the few blocks on OMAP4 which do not have a valid context_reg with -1 or USHRT_MAX as you suggested and mark all OMAP2/3 blocks with this at registration. Benoit/Paul, does that sound good? Any comments to this? This is blocking v6 for this set. That's OK for me. Also, who is going to generate the hwmod data? Well, in that case, only two entries have to be changed I guess, but I'll update anyway the scripts to populate the missing one with the macros you will create. Benoit -- 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 6/9] ARM: OMAP2+: Fix external clock support for dmtimers
Hi Benoit, On 05/21/2012 11:58 AM, Cousson, Benoit wrote: Hi Jon, On 5/16/2012 1:35 AM, Jon Hunter wrote: From: Jon Hunterjon-hun...@ti.com Currently, the dmtimer determines whether an timer can support an external clock source (sys_altclk) for driving the timer by the IP version. Only OMAP24xx devices can support an external clock source, but the IP version between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates that OMAP3 devices can use an external clock source. Rather than use the IP version, use the OMAP_TIMER_HAS_ALTCLK flag added to the HWMOD timer device attributes. By doing this, this allows us to eliminate the timer_ip_version variable passed as part of the platform data. I do not think this is the right way to handle that. The timer IP itself does have only one input clock. This is the mux before that clock that will have several inputs depending on the SoC revision. So this is purely PRCM stuff and has nothing to do with the timer IP itself. The OMAP_TIMER_HAS_ALTCLK is thus not a timer IP information and cannot be stored inside timer hwmod. Ok, understood. In fact, if the alt clock is there the alt_clk alias will be there and thus you can use the clk_get(dev, alt_clk) to figure out if the clock is there or not. Ok, I can do this and did think about it, but then wondered why it had been done this way in the first place? However, I prefer this approach too as it simplifies the code :-) So I modify how this is handled. Cheers Jon -- 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 6/9] ARM: OMAP2+: Fix external clock support for dmtimers
On 5/22/2012 5:04 PM, Jon Hunter wrote: ... In fact, if the alt clock is there the alt_clk alias will be there and thus you can use the clk_get(dev, alt_clk) to figure out if the clock is there or not. Ok, I can do this and did think about it, but then wondered why it had been done this way in the first place? Yeah, I don't know but I guess this is probably some OMAP1 legacy stuff... Benoit -- 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] USB: Remove omap2 support from omap_udc.c
* Felipe Balbi ba...@ti.com [120522 00:15]: On Mon, May 21, 2012 at 12:01:11PM -0700, Tony Lindgren wrote: There are no active users of this code for omap2 as the boards in use have either TUSB or MUSB controller. While at it, also fix warnings related to uninitialized dc_clk and hhc_clk. Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Tony Lindgren t...@atomide.com This one doesn't depend on the rest of the series, I can take it myself to v3.6 or you can take it with your series: Yes you can take this one. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: OMAP: Make FS USB omap1 only
* Felipe Balbi ba...@ti.com [120522 00:14]: On Mon, May 21, 2012 at 12:01:09PM -0700, Tony Lindgren wrote: As the FS USB code is not being actively used for omap2+ there's no point keeping it around for omap2+. Let's make the FS USB platform init code omap1 only so we can remove the last user of omap_read/write for omap2+, and simplify things for further USB, DMA, and device tree related work. While at it, also group the mach includes for the related drivers. Cc: linux-...@vger.kernel.org Cc: Felipe Balbi ba...@ti.com Cc: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Felipe Balbi ba...@ti.com Are you planning to send this on v3.5 or v3.6 ? I guess it's too late for v3.5 ?!? First one I can merge as a fix, patches 2 and 3 for v3.6, then patch 4 up to you, I suggest v3.6. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
* Paul Walmsley p...@pwsan.com [120521 23:51]: Next, I'd suggest implementing the code to allow GPMC timing configuration from raw register data (the second method above). This is hackish but for some boards, this is all we'll have. This will also presumably require some extra DT bindings for the register data. If this method is used, this code should also call a PM function to block clock rate changes on the GPMC clock, and an explanatory warning should be logged to the console. Also something to note here is that generating dynamic timings from the fixed GPMC register values won't work for other frequencies. As far as I remember, the main problem trying to convert fixed value GPMC timings into dynamic timings is the fact that some GPMC values calculated depend on clock cycles, while other values depend on time. So the cycle values remain unknown trying to upsample from fixed timings. For boards that we don't have access to, and all someone would have are the register values set by the bootloader, I'd propose a phased approach: 1. The kernel should log the bootloader-provided GPMC timing registers to the console during boot, along with a warning message that indicates that GPMC for these boards will cease to function in the near future unless patches are provided to update the kernel board file and/or DT data with the GPMC register contents. This should allow people who have those boards and who care about them to submit kernel patches to allow the GPMC-attached devices to continue to function. Unfortunately for many of the older boards these values will probably remain unknown. So the better approach here is to just disable frequency scaling for these cases. Otherwise we'll be breaking old boards with smsc911x where the timings for the FPGA controlling smsc911x are unknown. If we somehow manage to get those values without breaking support for these boards, then yes I agree we should deprecate hardcoded and bootloader values. 2. A patch to Documentation/feature-removal-schedule.txt should be submitted which states that support for implicit bootloader GPMC timings will be removed within two or three kernel releases. I'm fine with that assuming we somehow first have the values for the most commonly used boards for smsc911x. But before that happens, we can't really deprecate bootloader set GPMC values. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] GPMC NAND isr using standard API
* Mohammed, Afzal af...@ti.com [120522 00:05]: Hi Artem, On Tue, May 22, 2012 at 11:44:43, Artem Bityutskiy wrote: You merge the 2 trees and work on top of that? Or you wait for 3.5-r1 when everything is merged and work on top of that? I will merge 2 trees do Tony, are you ok with that ? I suggest you guys do your own merge of the two trees until -rc1 is out, then start using -rc1 as the base like Artem suggested. 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
[PATCH 0/2] OMAPDSS: write-through caching support for omapfb
This is a very simple few-liner patchset, which allows to optionally enable write-through caching for OMAP DSS framebuffer. The problem with the current writecombine cacheability attribute is that it only speeds up writes. Uncached reads are slow, even though the use of NEON mitigates this problem a bit. Traditionally, xf86-video-fbdev DDX is using shadow framebuffer in the system memory. Which contains a copy of the framebuffer data for the purpose of providing fast read access to it when needed. Framebuffer read access is required not so often, but it still gets used for scrolling and moving windows around in Xorg server. And the users perceive their linux desktop as rather sluggish when these operations are not fast enough. In the case of ARM hardware, framebuffer is typically physically located in the main memory. And the processors still support write-through cacheability attribute. According to ARM ARM, the writes done to write-through cached memory inside the level of cache are visible to all observers outside the level of cache without the need of explicit cache maintenance (same rule as for non-cached memory). So write-through cache is a perfect choice when only CPU is allowed to modify the data in the framebuffer and everyone else (screen refresh DMA) is only reading it. That is, assuming that write-through cached memory provides good performance and there are no quirks. As the framebuffer reads become fast, the need for shadow framebuffer disappears. And at least for ARM11 and Cortex-A8 processors, the performance of write-through cache is really good. Cortex-A9 is another story, because all pages marked as Write-Through are supposedly treated as Non-Cacheable: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388h/CBBFDIJD.html So OMAP4 is out of luck. But OMAP3 based hardware can have a nice graphics performance boost. And OMAP3 actually needs it a lot more. PS. The xf86-video-omapfb-0.1.1 driver does not even use shadow framebuffer (ouch!). So its users, if any, should see an immediate speedup. Siarhei Siamashka (2): ARM: pgtable: add pgprot_writethrough() macro OMAPDSS: Optionally enable write-through cache for the framebuffer Documentation/arm/OMAP/DSS | 10 ++ arch/arm/include/asm/pgtable.h |3 +++ drivers/video/omap2/omapfb/omapfb-main.c |7 ++- 3 files changed, 19 insertions(+), 1 deletions(-) -- 1.7.3.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] ARM: pgtable: add pgprot_writethrough() macro
Needed for remapping pages with write-through cacheable attribute. May be useful for framebuffers. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- arch/arm/include/asm/pgtable.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h index f66626d..04297fa 100644 --- a/arch/arm/include/asm/pgtable.h +++ b/arch/arm/include/asm/pgtable.h @@ -103,6 +103,9 @@ extern pgprot_t pgprot_kernel; #define pgprot_stronglyordered(prot) \ __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED) +#define pgprot_writethrough(prot) \ + __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_WRITETHROUGH) + #ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE #define pgprot_dmacoherent(prot) \ __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE | L_PTE_XN) -- 1.7.3.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 2/2] OMAPDSS: Optionally enable write-through cache for the framebuffer
Write-through cached framebuffer eliminates the need for using shadow framebuffer in xf86-video-fbdev DDX. At the very least this reduces memory footprint, but the performance is also the same or better when moving windows or scrolling on ARM11 and Cortex-A8 hardware. Benchmark with xf86-video-fbdev on IGEPv2 board (TI DM3730, 1GHz), 1280x1024 screen resolution and 32bpp desktop color depth: $ x11perf -scroll500 -copywinwin500 -copypixpix500 \ -copypixwin500 -copywinpix500 -- omapfb.vram_cache=n, Option ShadowFB true in xorg.conf 1 trep @ 3.4583 msec ( 289.0/sec): Scroll 500x500 pixels 6000 trep @ 4.3255 msec ( 231.0/sec): Copy 500x500 from window to window 8000 trep @ 3.2738 msec ( 305.0/sec): Copy 500x500 from pixmap to window 8000 trep @ 3.1707 msec ( 315.0/sec): Copy 500x500 from window to pixmap 8000 trep @ 3.4761 msec ( 288.0/sec): Copy 500x500 from pixmap to pixmap -- omapfb.vram_cache=n, Option ShadowFB false in xorg.conf 5000 trep @ 5.2357 msec ( 191.0/sec): Scroll 500x500 pixels 1200 trep @ 21.0346 msec ( 47.5/sec): Copy 500x500 from window to window 8000 trep @ 3.1590 msec ( 317.0/sec): Copy 500x500 from pixmap to window 6000 trep @ 4.5062 msec ( 222.0/sec): Copy 500x500 from window to pixmap 8000 trep @ 3.4767 msec ( 288.0/sec): Copy 500x500 from pixmap to pixmap -- omapfb.vram_cache=y, Option ShadowFB true in xorg.conf 1 trep @ 3.4580 msec ( 289.0/sec): Scroll 500x500 pixels 6000 trep @ 4.3424 msec ( 230.0/sec): Copy 500x500 from window to window 8000 trep @ 3.2673 msec ( 306.0/sec): Copy 500x500 from pixmap to window 8000 trep @ 3.1626 msec ( 316.0/sec): Copy 500x500 from window to pixmap 8000 trep @ 3.4733 msec ( 288.0/sec): Copy 500x500 from pixmap to pixmap -- omapfb.vram_cache=y, Option ShadowFB false in xorg.conf 1 trep @ 3.4893 msec ( 287.0/sec): Scroll 500x500 pixels 8000 trep @ 4.0600 msec ( 246.0/sec): Copy 500x500 from window to window 8000 trep @ 3.1565 msec ( 317.0/sec): Copy 500x500 from pixmap to window 8000 trep @ 3.1373 msec ( 319.0/sec): Copy 500x500 from window to pixmap 8000 trep @ 3.4631 msec ( 289.0/sec): Copy 500x500 from pixmap to pixmap Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com --- Documentation/arm/OMAP/DSS | 10 ++ drivers/video/omap2/omapfb/omapfb-main.c |7 ++- 2 files changed, 16 insertions(+), 1 deletions(-) diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index 888ae7b..4e41a15 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -293,6 +293,16 @@ omapfb.rotate=angle omapfb.mirror=y|n - Default mirror for all framebuffers. Only works with DMA rotation. +omapfb.vram_cache=y|n + - Sets the framebuffer memory to be write-through cached. This may be + useful in the configurations where only CPU is allowed to write to + the framebuffer and eliminate the need for enabling shadow + framebuffer in Xorg DDX drivers such as xf86-video-fbdev and + xf86-video-omapfb. Enabling write-through cache is only useful + for ARM11 and Cortex-A8 processors. Cortex-A9 does not support + write-through cache well, see Cortex-A9 behavior for Normal Memory + Cacheable memory regions section in Cortex-A9 TRM for more details. + omapdss.def_disp=display - Name of default display, to which all overlays will be connected. Common examples are lcd or tv. diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index b00db40..a684920 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -46,6 +46,7 @@ static char *def_vram; static bool def_vrfb; static int def_rotate; static bool def_mirror; +static bool def_vram_cache; static bool auto_update; static unsigned int auto_update_freq; module_param(auto_update, bool, 0); @@ -1123,7 +1124,10 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma) vma-vm_pgoff = off PAGE_SHIFT; vma-vm_flags |= VM_IO | VM_RESERVED; - vma-vm_page_prot = pgprot_writecombine(vma-vm_page_prot); + if (def_vram_cache) + vma-vm_page_prot = pgprot_writethrough(vma-vm_page_prot); + else + vma-vm_page_prot = pgprot_writecombine(vma-vm_page_prot); vma-vm_ops = mmap_user_ops; vma-vm_private_data = rg; if (io_remap_pfn_range(vma, vma-vm_start, off PAGE_SHIFT, @@ -2493,6 +2497,7 @@ module_param_named(vram, def_vram, charp, 0); module_param_named(rotate, def_rotate, int, 0); module_param_named(vrfb, def_vrfb, bool, 0); module_param_named(mirror, def_mirror, bool, 0); +module_param_named(vram_cache, def_vram_cache, bool, 0444); /* late_initcall to let panel/ctrl drivers loaded first. * I guess better option would be a more dynamic approach, -- 1.7.3.4 -- To unsubscribe from this
[PATCH 0/5] ARM: OMAP: Fix OMAP1 dmtimer support
From: Jon Hunter jon-hun...@ti.com OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the omap_dm_timer_request() function fails to allocate a dmtimer because the call to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply because the clock data for the OMAP1 dmtimers is not present. Although we can simply fix the OMAP1 dmtimers by adding the clock data for the dmtimers, this is simply the tip of the iceberg. The OMAP1 devices do not currently support clk_set_parent to dynamically change the clock source. So if we just add the clock data for the dmtimers, when the dmtimer clock source is changed by the existing omap1_dm_timer_set_src() function, the clock framework will not be updated to reflect the current parent clock. This patch set addresses these issues by ... 1. Making the code to set a parent clock common between OMAP1 and OMAP2+ 2. Adds the OMAP1 dmtimer clock data 3. Removes architecture specific code to set the dmtimer clock source and adds a common function that uses the clock framework This series has been tested on an OMAP5912 OSK, OMAP2430 SDP, OMAP3430 Beagle and OMAP4460 Panda. Jon Hunter (5): ARM: OMAP: Move clkt_clksel.c to plat-omap directory ARM: OMAP2+: Remove omap2_clk_set_parent function ARM: OMAP2+: Simplify dmtimer clock aliases ARM: OMAP1: Add dmtimer clock data ARM: OMAP: For all OMAP devices use clock framework to set dmtimer clock source arch/arm/mach-omap1/clock.h |3 - arch/arm/mach-omap1/clock_data.c | 142 +++- arch/arm/mach-omap1/timer.c | 15 +- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/clkt34xx_dpll3m2.c|2 +- arch/arm/mach-omap2/clkt_clksel.c | 510 - arch/arm/mach-omap2/clock.c | 15 +- arch/arm/mach-omap2/clock.h | 11 - arch/arm/mach-omap2/clock2420_data.c | 177 -- arch/arm/mach-omap2/clock2430_data.c | 175 -- arch/arm/mach-omap2/clock3xxx_data.c | 252 +++--- arch/arm/mach-omap2/clock44xx_data.c | 498 ++-- arch/arm/mach-omap2/timer.c | 61 arch/arm/plat-omap/Makefile |2 +- arch/arm/plat-omap/clkt_clksel.c | 508 arch/arm/plat-omap/clock.c|1 + arch/arm/plat-omap/dmtimer.c | 43 ++- arch/arm/plat-omap/include/plat/clock.h | 16 +- arch/arm/plat-omap/include/plat/dmtimer.h |1 - 19 files changed, 1211 insertions(+), 1223 deletions(-) delete mode 100644 arch/arm/mach-omap2/clkt_clksel.c create mode 100644 arch/arm/plat-omap/clkt_clksel.c -- 1.7.9.5 -- 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/5] ARM: OMAP2+: Remove omap2_clk_set_parent function
From: Jon Hunter jon-hun...@ti.com
The function omap2_clk_set_parent is just a wrapper for the
omap_clksel_set_parent() function. Now we have moved the
omap_clksel_set_parent() function into the plat-omap directory for all OMAP
devices to use, we should just use this function directly and we can eliminate
the OMAP2 function.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock.c | 13 +
arch/arm/plat-omap/clkt_clksel.c |3 +++
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 2049cb2..b17d539 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -385,17 +385,6 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate)
return ret;
}
-int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent)
-{
- if (!clk-clksel)
- return -EINVAL;
-
- if (clk-parent == new_parent)
- return 0;
-
- return omap_clksel_set_parent(clk, new_parent);
-}
-
/* OMAP3/4 non-CORE DPLL clkops */
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
@@ -532,7 +521,7 @@ struct clk_functions omap2_clk_functions = {
.clk_disable= omap2_clk_disable,
.clk_round_rate = omap2_clk_round_rate,
.clk_set_rate = omap2_clk_set_rate,
- .clk_set_parent = omap2_clk_set_parent,
+ .clk_set_parent = omap_clksel_set_parent,
.clk_disable_unused = omap2_clk_disable_unused,
};
diff --git a/arch/arm/plat-omap/clkt_clksel.c b/arch/arm/plat-omap/clkt_clksel.c
index 85622f8..e47b704 100644
--- a/arch/arm/plat-omap/clkt_clksel.c
+++ b/arch/arm/plat-omap/clkt_clksel.c
@@ -484,6 +484,9 @@ int omap_clksel_set_parent(struct clk *clk, struct clk
*new_parent)
if (!clk-clksel || !clk-clksel_mask)
return -EINVAL;
+ if (clk-parent == new_parent)
+ return 0;
+
parent_div = _get_div_and_fieldval(new_parent, clk, field_val);
if (!parent_div)
return -EINVAL;
--
1.7.9.5
--
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 3/5] ARM: OMAP2+: Simplify dmtimer clock aliases
From: Jon Hunter jon-hun...@ti.com
The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a con-id string to search for the appropriate functional clock.
Currently, we define a clock alias for each functional clock source each timer
supports. Some functional clock sources are common to all of the timers on a
device and so for these clock sources we can use a single alias with a unique
con-id string.
The possible functional clock sources for an OMAP device are a 32kHz clock,
a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
reduces code, speeds-up searches and clock initialisation time.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 39 +++---
arch/arm/mach-omap2/clock2430_data.c | 39 +++---
arch/arm/mach-omap2/clock3xxx_data.c | 26 ++-
arch/arm/mach-omap2/clock44xx_data.c | 34 +++--
arch/arm/mach-omap2/timer.c |6 +++---
5 files changed, 23 insertions(+), 121 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index dbae064..84dfde7 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1901,42 +1901,9 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
CLK(musb-hdrc,fck, osc_ck,CK_242X),
- CLK(omap_timer.1, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.2, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.3, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.4, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.5, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.6, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.7, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.8, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.9, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.10,32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.11,32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.12,32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.1, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.2, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.3, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.4, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.5, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.6, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.7, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.8, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.9, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.10,sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.11,sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.12,sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.1, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.2, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.3, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.4, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.5, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.6, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.7, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.8, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.9, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.10,alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.11,alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.12,alt_ck, alt_ck,CK_243X),
+ CLK(NULL, timer_32k_ck, func_32k_ck, CK_243X),
+ CLK(NULL, timer_sys_ck, sys_ck,CK_243X),
+ CLK(NULL, timer_ext_ck, alt_ck,CK_243X),
};
/*
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index b8c3869..7c1f83d 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -2000,42 +2000,9 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, mdm_intc_ick, mdm_intc_ick, CK_243X),
CLK(omap_hsmmc.0, mmchsdb_fck, mmchsdb1_fck, CK_243X),
CLK(omap_hsmmc.1, mmchsdb_fck, mmchsdb2_fck, CK_243X),
- CLK(omap_timer.1, 32k_ck, func_32k_ck,
[PATCH 4/5] ARM: OMAP1: Add dmtimer clock data
From: Jon Hunter jon-hun...@ti.com
Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/clock_data.c | 140 ++
1 file changed, 140 insertions(+)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index d60f690..27acf4c 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -83,6 +83,12 @@ static struct clk ck_ref = {
.rate = 1200,
};
+static struct clk ck_32k = {
+ .name = ck_32k,
+ .ops= clkops_null,
+ .rate = 32768,
+};
+
static struct clk ck_dpll1 = {
.name = ck_dpll1,
.ops= clkops_null,
@@ -677,6 +683,127 @@ static struct clk i2c_ick = {
.recalc = followparent_recalc,
};
+static const struct clksel_rate div_1_0_rates[] = {
+ { .div = 1, .val = 0, .flags = CK_16XX | CK_1710 },
+ { .div = 0 },
+};
+static const struct clksel_rate div_1_1_rates[] = {
+ { .div = 1, .val = 1, .flags = CK_16XX | CK_1710 },
+ { .div = 0 },
+};
+static const struct clksel_rate div_1_2_rates[] = {
+ { .div = 1, .val = 2, .flags = CK_16XX | CK_1710 },
+ { .div = 0 },
+};
+
+static struct clk timer_extclk = {
+ .name = timer_extclk,
+ .ops= clkops_null,
+};
+
+static const struct clksel timer_sel[] = {
+ { .parent = armxor_ck.clk, .rates = div_1_0_rates },
+ { .parent = ck_32k, .rates = div_1_1_rates },
+ { .parent = timer_extclk, .rates = div_1_2_rates },
+ { .parent = NULL },
+};
+
+static struct clk timer1_fck = {
+ .name = timer1_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(1) | BIT(0),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer2_fck = {
+ .name = timer2_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(3) | BIT(2),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer3_fck = {
+ .name = timer3_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(5) | BIT(4),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer4_fck = {
+ .name = timer4_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(7) | BIT(6),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer5_fck = {
+ .name = timer5_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(9) | BIT(8),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer6_fck = {
+ .name = timer6_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(11) | BIT(10),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer7_fck = {
+ .name = timer7_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(13) | BIT(12),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct
[PATCH 5/5] ARM: OMAP: For all OMAP devices use clock framework to set dmtimer clock source
From: Jon Hunter jon-hun...@ti.com
OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's parent. Now OMAP1
can use the clock framework to set the parent clock, remove the architecture
specific functions and use a common function to set the parent clock for all
OMAP devices. This common function is based upon the OMAP2+
omap2_dm_timer_set_src() as this was using the clock framework.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c | 15 +--
arch/arm/mach-omap2/timer.c | 61 -
arch/arm/plat-omap/dmtimer.c | 43 +++-
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
4 files changed, 43 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 64c65bc..6ef4f6d 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -41,19 +41,6 @@
#define OMAP1_DM_TIMER_COUNT 8
-static int omap1_dm_timer_set_src(struct platform_device *pdev,
- int source)
-{
- int n = (pdev-id - 1) 1;
- u32 l;
-
- l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
- l |= source n;
- omap_writel(l, MOD_CONF_CTRL_1);
-
- return 0;
-}
-
static int __init omap1_dm_timer_init(void)
{
int i;
@@ -139,7 +126,7 @@ static int __init omap1_dm_timer_init(void)
goto err_free_pdata;
}
- pdata-set_timer_src = omap1_dm_timer_set_src;
+ pdata-timer_ip_version = OMAP_TIMER_IP_VERSION_1;
pdata-needs_manual_reset = 1;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f1d8453..304a9c8 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -394,66 +394,6 @@ OMAP_SYS_TIMER(4)
#endif
/**
- * omap2_dm_timer_set_src - change the timer input clock source
- * @pdev: timer platform device pointer
- * @source:array index of parent clock source
- */
-static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
-{
- int ret;
- struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
- struct clk *fclk, *parent;
- char *parent_name = NULL;
-
- fclk = clk_get(pdev-dev, fck);
- if (IS_ERR_OR_NULL(fclk)) {
- dev_err(pdev-dev, %s: %d: clk_get() FAILED\n,
- __func__, __LINE__);
- return -EINVAL;
- }
-
- switch (source) {
- case OMAP_TIMER_SRC_SYS_CLK:
- parent_name = timer_sys_ck;
- break;
-
- case OMAP_TIMER_SRC_32_KHZ:
- parent_name = timer_32k_ck;
- break;
-
- case OMAP_TIMER_SRC_EXT_CLK:
- if (pdata-timer_ip_version == OMAP_TIMER_IP_VERSION_1) {
- parent_name = timer_ext_ck;
- break;
- }
- dev_err(pdev-dev, %s: %d: invalid clk src.\n,
- __func__, __LINE__);
- clk_put(fclk);
- return -EINVAL;
- }
-
- parent = clk_get(pdev-dev, parent_name);
- if (IS_ERR_OR_NULL(parent)) {
- dev_err(pdev-dev, %s: %d: clk_get() %s FAILED\n,
- __func__, __LINE__, parent_name);
- clk_put(fclk);
- return -EINVAL;
- }
-
- ret = clk_set_parent(fclk, parent);
- if (IS_ERR_VALUE(ret)) {
- dev_err(pdev-dev, %s: clk_set_parent() to %s FAILED\n,
- __func__, parent_name);
- ret = -EINVAL;
- }
-
- clk_put(parent);
- clk_put(fclk);
-
- return ret;
-}
-
-/**
* omap_timer_init - build and register timer device with an
* associated timer hwmod
* @oh:timer hwmod pointer to be used to build timer device
@@ -501,7 +441,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
*/
sscanf(oh-name, timer%2d, id);
- pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
/* Mark clocksource and clockevent timers as reserved */
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 3b0cfeb..a344998 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -378,6 +378,8 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
{
int ret;
+ char *parent_name = NULL;
+ struct clk *fclk, *parent;
struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
@@ -388,7 +390,46 @@ int omap_dm_timer_set_source(struct
Re: [PATCH 0/2] OMAPDSS: write-through caching support for omapfb
On Tue, May 22, 2012 at 10:54 PM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: And at least for ARM11 and Cortex-A8 processors, the performance of write-through cache is really good. Cortex-A9 is another story, because all pages marked as Write-Through are supposedly treated as Non-Cacheable: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388h/CBBFDIJD.html So OMAP4 is out of luck. I don't have Pandaboard ES, but still tried to experiment changing the following line in the kernel sources to benchmark different types of caching for the framebuffer on Origen board (Exynos 4210): https://github.com/torvalds/linux/blob/v3.4/drivers/media/video/videobuf2-memops.c#L158 It was not a totally clean experiment, because 500x500 16bpp pixel buffer is much smaller than 1MiB L2 cache and the performance numbers may be a bit odd. Also I have not checked whether the same buffer may be mapped with different cacheability attributes anywhere else (which would be bad). But still it was interesting to see whether write-through cache is of any use and whether it could serve as a replacement for shadowfb. Origen board, Exynos 4210, Cortex-A9 1.2GHz, 1920x1080 screen resolution, 16bpp desktop color depth (I did not find any obvious way how to change it to 32bpp yet): $ x11perf -scroll500 -copywinwin500 -copypixpix500 \ -copypixwin500 -copywinpix500 -- pgprot_noncached + shadowfb 10 trep @ 0.2708 msec ( 3690.0/sec): Scroll 500x500 pixels 4 trep @ 0.7307 msec ( 1370.0/sec): Copy 500x500 from window to window 6 trep @ 0.5471 msec ( 1830.0/sec): Copy 500x500 from pixmap to window 6 trep @ 0.5822 msec ( 1720.0/sec): Copy 500x500 from window to pixmap 4 trep @ 0.6584 msec ( 1520.0/sec): Copy 500x500 from pixmap to pixmap -- pgprot_writecombine + shadowfb 10 trep @ 0.2612 msec ( 3830.0/sec): Scroll 500x500 pixels 4 trep @ 0.7058 msec ( 1420.0/sec): Copy 500x500 from window to window 6 trep @ 0.5262 msec ( 1900.0/sec): Copy 500x500 from pixmap to window 6 trep @ 0.5797 msec ( 1730.0/sec): Copy 500x500 from window to pixmap 4 trep @ 0.6554 msec ( 1530.0/sec): Copy 500x500 from pixmap to pixmap -- pgprot_writethrough + shadowfb 10 trep @ 0.2609 msec ( 3830.0/sec): Scroll 500x500 pixels 4 trep @ 0.7018 msec ( 1420.0/sec): Copy 500x500 from window to window 6 trep @ 0.5260 msec ( 1900.0/sec): Copy 500x500 from pixmap to window 6 trep @ 0.5758 msec ( 1740.0/sec): Copy 500x500 from window to pixmap 4 trep @ 0.6569 msec ( 1520.0/sec): Copy 500x500 from pixmap to pixmap -- pgprot_noncached 3500 trep @ 7.5972 msec ( 132.0/sec): Scroll 500x500 pixels 1800 trep @ 14.7146 msec ( 68.0/sec): Copy 500x500 from window to window 6000 trep @ 4.6501 msec ( 215.0/sec): Copy 500x500 from pixmap to window 8000 trep @ 3.3500 msec ( 299.0/sec): Copy 500x500 from window to pixmap 4 trep @ 0.6546 msec ( 1530.0/sec): Copy 500x500 from pixmap to pixmap -- pgprot_writecombine 1 trep @ 2.9439 msec ( 340.0/sec): Scroll 500x500 pixels 6000 trep @ 5.7246 msec ( 175.0/sec): Copy 500x500 from window to window 6 trep @ 0.4213 msec ( 2370.0/sec): Copy 500x500 from pixmap to window 12000 trep @ 2.2423 msec ( 446.0/sec): Copy 500x500 from window to pixmap 4 trep @ 0.6648 msec ( 1500.0/sec): Copy 500x500 from pixmap to pixmap -- pgprot_writethrough 4 trep @ 0.7103 msec ( 1410.0/sec): Scroll 500x500 pixels 2 trep @ 1.3024 msec ( 768.0/sec): Copy 500x500 from window to window 8 trep @ 0.3933 msec ( 2540.0/sec): Copy 500x500 from pixmap to window 18000 trep @ 1.3967 msec ( 716.0/sec): Copy 500x500 from window to pixmap 4 trep @ 0.6548 msec ( 1530.0/sec): Copy 500x500 from pixmap to pixmap Without shadowfb, the performance of writecombine looks to be better than noncached. And writethrough is clearly the fastest. Still even writethrough is no match for shadowfb on Cortex-A9 (unlike ARM11 and Cortex-A8). So is Cortex-A9 a lost cause? Maybe experimenting with page table entries and tweaking inner/outer cacheability attributes could provide something? From the first glance, it looks like read performance for write-through cached memory is rather bad on Cortex-A9. But still there is some speedup, so it does not seem to be treated as totally non-cached. And at least PL310 L2 cache controller has some support for Cacheable write-through, allocate on read: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/ch02s03s01.html -- Best regards, Siarhei Siamashka -- 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] ARM: OMAP: DMTIMER clean-up in preparation for device-tree
Hi Tony, Paul, On 05/17/2012 11:48 AM, Paul Walmsley wrote: On Thu, 17 May 2012, Jon Hunter wrote: Yes that's right. What is your preference here, the options are ... 1. Move the clkt_clksel.c file to arch/arm/plat-omap and change the omap2_xxx API names to omap_xxx. 2. Add the functions in clkt_clksel.c to arch/arm/plat-omap/clock.c and get rid of clkt_clksel.c altogether. #1. I have posted a new series here [1] to fix omap1 dmtimers and commonise the code to set dmtimer source clock between omap1 and omap2. My plan is to rebase this series on top of that, if you are ok with those changes. [1] http://marc.info/?l=linux-omapm=133771799505501w=2 Cheers Jon -- 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] backlight: initialize struct backlight_properties properly
On Mon, 21 May 2012 09:24:35 +0200
Corentin Chary corentin.ch...@gmail.com wrote:
In all these files, the .power field was never correctly initialized.
...
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
else
return -ENODEV;
+ memset(props, 0, sizeof(props));
This code is all still quite fragile. What happens if we add a new
field to backlight_properties? We need to go edit a zillion drivers?
There are two ways of fixing this:
a) write and use
void backlight_properties_init(struct backlight_properties *props,
int type, int max_brightness, etc);
or
b) edit all sites to do
struct backlight_properties bl_props = {
.type = BACKLIGHT_RAW,
.max_brighness = intel_panel_get_max_backlight(dev),
.power = FB_BLANK_UNBLANK,
};
they're largely equivalent - the struct will be zeroed out and
then certain fields will be initialised. a) is a bit better because
some future field may not want the all-zeroes pattern (eg, a spinlock).
But they're both better than what we have now!
--
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/5] ARM: OMAP1: Add dmtimer clock data
On 05/22/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
Add clock data for the 8 dmtimers present on OMAP16xx (including OMAP5912)
and OMAP17xx devices. These timers support 3 different clock sources which
are the 32kHz clock, ARMXOR clock and an external clock source.
A couple additional comments here. This patch also ...
1. Adds clock nodes for the omap1 32kHz clock source and the dmtimer
external clock source.
2. Defines a clk_set_parent() function for OMAP1 devices.
3. Adds a call to propagate_rate() for the 32kHz clock source, so that
any clocks that default to the 32kHz clock are populated with the
correct rate on start-up. I noticed that when rebooting the 5912 OSK
that if the dmtimer was previously set to the 32kHz clock on the
next boot the parent would still be 32kHz but the rate would show up
as 0. This fixed the problem.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/clock_data.c | 140
++
1 file changed, 140 insertions(+)
diff --git a/arch/arm/mach-omap1/clock_data.c
b/arch/arm/mach-omap1/clock_data.c
index d60f690..27acf4c 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -83,6 +83,12 @@ static struct clk ck_ref = {
.rate = 1200,
};
+static struct clk ck_32k = {
+ .name = ck_32k,
+ .ops= clkops_null,
+ .rate = 32768,
+};
+
static struct clk ck_dpll1 = {
.name = ck_dpll1,
.ops= clkops_null,
@@ -677,6 +683,127 @@ static struct clk i2c_ick = {
.recalc = followparent_recalc,
};
+static const struct clksel_rate div_1_0_rates[] = {
+ { .div = 1, .val = 0, .flags = CK_16XX | CK_1710 },
+ { .div = 0 },
+};
+static const struct clksel_rate div_1_1_rates[] = {
+ { .div = 1, .val = 1, .flags = CK_16XX | CK_1710 },
+ { .div = 0 },
+};
+static const struct clksel_rate div_1_2_rates[] = {
+ { .div = 1, .val = 2, .flags = CK_16XX | CK_1710 },
+ { .div = 0 },
+};
+
+static struct clk timer_extclk = {
+ .name = timer_extclk,
+ .ops= clkops_null,
+};
+
+static const struct clksel timer_sel[] = {
+ { .parent = armxor_ck.clk, .rates = div_1_0_rates },
+ { .parent = ck_32k, .rates = div_1_1_rates },
+ { .parent = timer_extclk, .rates = div_1_2_rates },
+ { .parent = NULL },
+};
+
+static struct clk timer1_fck = {
+ .name = timer1_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(1) | BIT(0),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer2_fck = {
+ .name = timer2_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(3) | BIT(2),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer3_fck = {
+ .name = timer3_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(5) | BIT(4),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer4_fck = {
+ .name = timer4_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(7) | BIT(6),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer5_fck = {
+ .name = timer5_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask= BIT(9) | BIT(8),
+ .parent = armxor_ck.clk,
+ .flags = CLOCK_NO_IDLE_PARENT,
+ .recalc = followparent_recalc,
+};
+
+static struct clk timer6_fck = {
+ .name = timer6_fck,
+ .ops= clkops_generic,
+ .init = omap_init_clksel_parent,
+ .clksel = timer_sel,
+ .clksel_reg = OMAP1_IO_ADDRESS(MOD_CONF_CTRL_1),
+ .clksel_mask=
Re: [PATCH 5/5] ARM: OMAP: For all OMAP devices use clock framework to set dmtimer clock source
On 05/22/2012 03:17 PM, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
OMAP1 and OMAP2+ devices had architecture specific functions for configuring
the dmtimer clock source. This was simply because the OMAP1 devices did not
support the clock framework for dynamically setting a clock's parent. Now
OMAP1
can use the clock framework to set the parent clock, remove the architecture
specific functions and use a common function to set the parent clock for all
OMAP devices. This common function is based upon the OMAP2+
omap2_dm_timer_set_src() as this was using the clock framework.
One comment ...
For now, I have not removed the timer_ip_version test when attempting
to set the dmtimer to an external clock source (see below). I plan to
remove this in a follow-up series to clean-up the platform data for the
dmtimer. I could have also done it here, but I was thinking that this
should be in its own patch. Hence for now, I am also setting the
timer_ip_version for OMAP1 devices to OMAP_TIMER_IP_VERSION_1 so an
external clock source can be selected.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c | 15 +--
arch/arm/mach-omap2/timer.c | 61
-
arch/arm/plat-omap/dmtimer.c | 43 +++-
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
4 files changed, 43 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 64c65bc..6ef4f6d 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -41,19 +41,6 @@
#define OMAP1_DM_TIMER_COUNT 8
-static int omap1_dm_timer_set_src(struct platform_device *pdev,
- int source)
-{
- int n = (pdev-id - 1) 1;
- u32 l;
-
- l = omap_readl(MOD_CONF_CTRL_1) ~(0x03 n);
- l |= source n;
- omap_writel(l, MOD_CONF_CTRL_1);
-
- return 0;
-}
-
static int __init omap1_dm_timer_init(void)
{
int i;
@@ -139,7 +126,7 @@ static int __init omap1_dm_timer_init(void)
goto err_free_pdata;
}
- pdata-set_timer_src = omap1_dm_timer_set_src;
+ pdata-timer_ip_version = OMAP_TIMER_IP_VERSION_1;
pdata-needs_manual_reset = 1;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f1d8453..304a9c8 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -394,66 +394,6 @@ OMAP_SYS_TIMER(4)
#endif
/**
- * omap2_dm_timer_set_src - change the timer input clock source
- * @pdev:timer platform device pointer
- * @source: array index of parent clock source
- */
-static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
-{
- int ret;
- struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
- struct clk *fclk, *parent;
- char *parent_name = NULL;
-
- fclk = clk_get(pdev-dev, fck);
- if (IS_ERR_OR_NULL(fclk)) {
- dev_err(pdev-dev, %s: %d: clk_get() FAILED\n,
- __func__, __LINE__);
- return -EINVAL;
- }
-
- switch (source) {
- case OMAP_TIMER_SRC_SYS_CLK:
- parent_name = timer_sys_ck;
- break;
-
- case OMAP_TIMER_SRC_32_KHZ:
- parent_name = timer_32k_ck;
- break;
-
- case OMAP_TIMER_SRC_EXT_CLK:
- if (pdata-timer_ip_version == OMAP_TIMER_IP_VERSION_1) {
- parent_name = timer_ext_ck;
- break;
- }
- dev_err(pdev-dev, %s: %d: invalid clk src.\n,
- __func__, __LINE__);
- clk_put(fclk);
- return -EINVAL;
- }
-
- parent = clk_get(pdev-dev, parent_name);
- if (IS_ERR_OR_NULL(parent)) {
- dev_err(pdev-dev, %s: %d: clk_get() %s FAILED\n,
- __func__, __LINE__, parent_name);
- clk_put(fclk);
- return -EINVAL;
- }
-
- ret = clk_set_parent(fclk, parent);
- if (IS_ERR_VALUE(ret)) {
- dev_err(pdev-dev, %s: clk_set_parent() to %s FAILED\n,
- __func__, parent_name);
- ret = -EINVAL;
- }
-
- clk_put(parent);
- clk_put(fclk);
-
- return ret;
-}
-
-/**
* omap_timer_init - build and register timer device with an
* associated timer hwmod
* @oh: timer hwmod pointer to be used to build timer device
@@ -501,7 +441,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
*/
sscanf(oh-name, timer%2d, id);
- pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
/* Mark clocksource and clockevent timers as reserved */
diff --git
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Hi Greg, This series has Kevin's comments incorporated. Kevin, Can i have your Ack for this series? Thanks, Kevin -- Regards and Thanks, Keerthy -- Regards and Thanks, Keerthy -- 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
