Re: [PATCH] twl4030_wdt: Disable watchdog while probing
Hi Timo, It seems that in this patch, you disable the watchdog regardless whether the registration fails or not. I wonder if this is a good thing to do. What if the bootloader have already enabled the watchdog and then user space booting fails for some reason before any process is able to open and re-enable the watchdog? We could end up with a hung system that does not have the watchdog enabled. Maybe we should disable the watchdog only in case the registration actually fails? And even in that case, do we want to disable the watchdog? What are the situations where watchdog registration can fail? Is there a possibility that we would like to leave watchdog running in such case and cause a reboot (say, something bad happened before the watchdog module was loaded and the system ran out of memory, which causes watchdog registration to fail)? Maybe there is something I've missed, but this kind of questions came in my mind.. The default behaviour should be to stop the watchdog. Why? you will probably ask. Let's first take a step back and go to the basis of the watchdog userspace API. In essence userspace start the watchdog by opening /dev/watchdog, then pings the watchdog by writing to /dev/watchdog and stops the watchdog when /dev/watchdog is being closed. That's the basis of the API and it does mean that the watchdog should not be running unless userspace starts the watchdog by opening /dev/watchdog. Later on ioctl calls have been added to extend functionality, we also added extra feautures like the Magic Close feauture (so that a close is not always stopping the watchdog - this to prevent userspace daemon crashes) and the nowayout feature (to prevent a watchdog from being stopped once started). So default is that the watchdog doesn't work unless userspace starts it. That's the API like it is now. So let's take a second step back and look at why we want/need watchdog's: we want them to make sure that our systems can reboot when the systems becomes unstable and crashes. The decision to reboot a system actually is driven by userspace: if userspace pings the watchdog then we now the system is stable enough, if not then we reboot. And that's why we have a grey zone: userspace control is only there after the system has booted. And the system is only booted and available for userspace after the filesystem checks are done. So that's why in the past the people that wrote the first watchdog's disabled all watchdog's before userspace was able to control the watchdog: you didn't want (and in most cases still don't want) your system to be rebooted during a filesystem check (because after the reboot, the filesystem will have to be checked again which could result in an endless loop). And this still is the default behaviour. On the other hand: systems are faster, we have other types of filesystems, we use flash-drives, ... . So for some embedded systems you might want to secure booting in a different way then what we used to do on traditional systems. The way I see it is to add a module_parameter that allows you to have the driver keep the watchdog active on start and don't stop it. The default behaviour would be to stop the watchdog, but it gives you the possibility to override the default. This is how I was adding this to the generic watchdog framework. (I'm doing some last veryfications before releasing it for comments). I hope the reasoning is clearer now and that your questions are answered. (If not, just let me know which questions you still have). = bottom line: this patch adds the correct default behaviour and should not be changed. Feel free to add the module-parameter to keep the watchog running at start. Kind regards, Wim. -- 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/2] omap: rx51: Add supplies and data for the tpa6130a2 headphone amplifier
On Tue, May 18, 2010 at 07:51:09PM +0200, Jarkko Nikula wrote:
On Tue, 18 May 2010 15:48:48 +0300
Eduardo Valentin eduardo.valen...@nokia.com wrote:
@@ -285,6 +287,9 @@ static struct regulator_consumer_supply
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+ /* tpa6130a2 */
+ REGULATOR_SUPPLY(CPVSS, 2-0060),
Isn't CPVSS grounded? Well that wouldn't hurt to put it here, but it doesnt
belong to vmmc2 though.
Thanks Eduardo! For me it looks this CPVSS supply is miss-added to the
tpa6130a2 as spec says for this pin:
Negative supply generated by the charge pump. Decouple to pin 19 on
the QFN or a CPVSS B2 15, 16 P GND plane. Use a 1 μF capacitor.
right.
I'll send a fix first to the tpa6130a2 and repost this one after that.
OK. good.
--
Jarkko
--
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/4] fbdev: add a MIPI DSI header
On Wed, 19 May 2010, Tomi Valkeinen wrote:
Hi,
On Wed, 2010-05-19 at 10:08 +0200, ext Guennadi Liakhovetski wrote:
Hi Tomi
On Wed, 19 May 2010, Tomi Valkeinen wrote:
The file name is mipi_dsi.h, the comment talks about MIPI, and the file
contains defines for MIPI DSI and MIPI DCS. If you want the file to
contain defines about all MIPI specs, I think the file name should be
just mipi.h.
No, the header is just intended for DSI, the comment could be made more
specific, yes, but DCS is a part of DSI, isn't it?
No, DCS is a spec of its own. DCS can be used on non-DSI displays also.
For example N800 and N900 use DCS commands, but they are not DSI
displays.
Yes, right, I should have said they are related;) How about calling the
header mipi_display.h? This would then unite DSI, DCS, DBI and DPI?
Creating a separate header for each of these standards seems like an
overkill to me. We could then put MIPI CSI and CPI standards in an
include/media/mipi_camera.h. Not sure where to put various other MIPI
standards, I guess, we'll have to think about it as a need arises.
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DSI_H
+#define MIPI_DSI_H
+
+#include linux/types.h
+
+enum mipi_dsi_cmd {
I think these are DSI datatypes, not commands.
hm, write, shut down, mode off, mode on sound like commands to me,
and I think I saw them called commands in the spec, but yes, some of them
are just packet or data types... I'll double-check, thanks.
Well, true, this is not a clear thing. MIPI DSI spec talks about turn
on peripheral command. But the numbers are DSI data types, according to
the spec, and not all of them are commands.
Ok, how about telegram types then?
+ MIPI_DSI_DCS_SHORT_WRITE= 5,
Please use the same number format for all enums. So this should be 0x05.
Where does this requirement come from? Is it in CodingStyle?;)
I don't know, but mixing different formats looks ugly to me =).
This seems to be subjective;) But I'm not religious about it, and since
Nokia (C) is the first in this file I might as well just accept your
proposal;)
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+ MIPI_DSI_COLOR_MODE_OFF = 2,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 3,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 4,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+ MIPI_DSI_NULL_PACKET= 9,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0xc,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0xd,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0xe,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+enum mipi_dcs_cmd {
While the MIPI specs define a certain set of commands, the real panels
usually implement also their own custom commands. That's why I don't
think enum is a good choice here.
Yes, that's a valid point, I'll have to think about it more.
I think a simple solution would be to just use defines, and have
functions that take the command as u8. That's what the OMAP DSI driver
does. If you have better ideas, please share =).
The same applies for the DSI commands/datatypes, although I haven't seen
a panel that has custom DSI datatypes.
As others voted for unnamed enums, how about using them?
Concerning omap2 display drivers,
Re: [PATCH 1/4] fbdev: add a MIPI DSI header
On Thu, 2010-05-20 at 10:07 +0200, ext Guennadi Liakhovetski wrote: Yes, right, I should have said they are related;) How about calling the header mipi_display.h? This would then unite DSI, DCS, DBI and DPI? Creating a separate header for each of these standards seems like an overkill to me. We could then put MIPI CSI and CPI standards in an include/media/mipi_camera.h. Not sure where to put various other MIPI standards, I guess, we'll have to think about it as a need arises. mipi_display.h sounds good to me. Well, true, this is not a clear thing. MIPI DSI spec talks about turn on peripheral command. But the numbers are DSI data types, according to the spec, and not all of them are commands. Ok, how about telegram types then? I wouldn't invent a new word for this =). The DSI spec talks about commands, data types and transactions, I think we should pick one of them. Perhaps this is already approaching nitpicking, but: As only some of the commands/datatypes/transactions are commands, I think that's not proper word. All of them have a data type number, and I guess they all are transactions. So Turn On Peripheral Command is a transaction, and its data type is 0x32. I guess if the enum is named, it should then be mipi_dsi_transaction. But then, which one of these would be more correct: dsi_send(enum mipi_dsi_transaction transaction) dsi_send(u8 datatype) As I said previously, I haven't seen any panel using custom datatypes, but I wouldn't be surprised if some panel does. In that sense I would go for using u8, and then perhaps leaving the enum unnamed. What do you think? As others voted for unnamed enums, how about using them? Sounds good. Concerning omap2 display drivers, AFAICS the only thing we want to change there is to switch them too to using the common header and telegram type Yep, I think that's the only change for now. and command names? So far I don't see a need for a generic MIPI (display) subsystem in the kernel with an own bus type, API etc. We could of course create a simpe bus with callbacks for sending short and long packets and reading data back, but do we really need it ATM? This is something I've been thinking about for some time. I even made some prototypes for it, but I didn't have time to go forward with it. It would of course be nice to use the same panel driver on different boards, so I think this is definitely something to think about in the future. Tomi -- 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/4] fbdev: add a MIPI DSI header
On Thu, May 20, 2010 at 11:32:49AM +0300, Tomi Valkeinen wrote: On Thu, 2010-05-20 at 10:07 +0200, ext Guennadi Liakhovetski wrote: Yes, right, I should have said they are related;) How about calling the header mipi_display.h? This would then unite DSI, DCS, DBI and DPI? Creating a separate header for each of these standards seems like an overkill to me. We could then put MIPI CSI and CPI standards in an include/media/mipi_camera.h. Not sure where to put various other MIPI standards, I guess, we'll have to think about it as a need arises. mipi_display.h sounds good to me. if there are extra mipi standards which should be taken care of, why not include/linux/mipi/[display.h camera.h other1.h other2.h...] ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote: But with that, you still shift the burden of exchanging that app with an feature-equivalent non-broken version to the user. which is not user friendly and not necessary if you have a smart enough kernel. and _without that_, you shift the burden of having a working power management completely into the kernel. Forcing the kernel to deal with completely broken apps. What will happen is that apps developers won't boder thinking about power consumption since the kernel is smart enough to fix their mess. To me that's much bigger burden to the kernel than the other option is to apps. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 10:57:40AM +0200, ext Felipe Balbi wrote: boder thinking about power consumption since the kernel is smart ^I mean bother -- balbi DefectiveByDesign.org -- 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/4] fbdev: add a MIPI DSI header
On Thu, 20 May 2010, Felipe Balbi wrote: On Thu, May 20, 2010 at 11:32:49AM +0300, Tomi Valkeinen wrote: On Thu, 2010-05-20 at 10:07 +0200, ext Guennadi Liakhovetski wrote: Yes, right, I should have said they are related;) How about calling the header mipi_display.h? This would then unite DSI, DCS, DBI and DPI? Creating a separate header for each of these standards seems like an overkill to me. We could then put MIPI CSI and CPI standards in an include/media/mipi_camera.h. Not sure where to put various other MIPI standards, I guess, we'll have to think about it as a need arises. mipi_display.h sounds good to me. if there are extra mipi standards which should be taken care of, why not include/linux/mipi/[display.h camera.h other1.h other2.h...] ? I thought about this too, but I prefer to separate them thematically: put display standards under video/, camera under media/ etc. This way including these headers from respective drivers and platform code would look more naturally, IMHO. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] twl4030_wdt: Disable watchdog while probing
Hi Wim, On Thu, 2010-05-20 at 09:46 +0200, ext Wim Van Sebroeck wrote: = bottom line: this patch adds the correct default behaviour and should not be changed. Feel free to add the module-parameter to keep the watchog running at start. Thanks for the detailed explanation. I was worried about the kernel and the early user space booting being in the grey area where errors might occurr which can cause the device (I'm talking about embedded devices here) to go into failed state without watchdog being able to reboot the machinge. But as you said, this can be fixed by adding additional module parameters that override this default behavior, so I have no further objections for this patch. Acked-By: Timo Kokkonen timo.t.kokko...@nokia.com -- 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/3 v2] musb: AM35x: Workaround for fifo read issue
Hi, AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- Patch created against linus'tree + all musb patches in Greg's queue Changes from v1: - removed unnecessary parens. - Removed 'memcpy' for 32 bit read loops. drivers/usb/musb/am3517.c| 30 ++ drivers/usb/musb/musb_core.c |2 ++ 2 files changed, 32 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c index b74e664..3299c66 100644 --- a/drivers/usb/musb/am3517.c +++ b/drivers/usb/musb/am3517.c [...] + } +} diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 4093f6d..9c59a8e 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -262,6 +262,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src) } } +#if !defined(CONFIG_MACH_OMAP3517EVM) Fixes/workaround based on CONFIG_MACH_OMAP3517EVM will be good only for OMAP3517EVM and would not scale well to other boards based on AM35x. (As commented earlier by Sergei) I just got to know of another board LIZARD based on AM35x so we really need to find a solution for this. This problem is due to the fact that AM35x is based on OMAP35x but musb ip Is updated to RTL1.8 using CPPI4.1 DMA engine thus we need to have a config option to differentiate musb ips between actual OMAP3 and AM35x platforms. I am thinking of adding new config option OMAP_MUSB_RTL18 which should be selected by all the boards based on AM35x in arch/arm/mach-omap2/Kconfig. The same config option can be used for all the workaround/fixes specific to AM35x musb platform. -- diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b72ae06..3ab1156 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -95,6 +95,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX select OMAP_PACKAGE_CBB + select OMAP_MUSB_RTL18 config PMIC_TPS65023 bool TPS65023 Power Module -- Does anyone has a better option to fix this issue or any comment on this approach? Regards, Ajay /* * Unload an endpoint's FIFO */ @@ -299,6 +300,7 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8 *dst) readsb(fifo, dst, len); } } +#endif #endif /* normal PIO */ -- 1.6.2.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/4 v2] fbdev: add a MIPI DSI header
This header adds defines for MIPI DSI and DCS commands and data formats. See
http://www.mipi.org/ for details.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Ok, how about this? If this is acceptable I'll repost other patches too,
adjusted accordingly.
v1 - v2:
1. renamed mpi_dsi.h to mipi_display.h
2. improved introductory comment
3. changed 10 enum values to match others as 0x0N
4. changed command to transaction
5. added a couple of missing transaction types
6. enums are now unnamed
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
new file mode 100644
index 000..93a4d61
--- /dev/null
+++ b/include/video/mipi_display.h
@@ -0,0 +1,118 @@
+/*
+ * Defines for Mobile Industry Processor Interface (MIPI(R))
+ * Display Working Group standards: DSI, DCS, DBI, DPI
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DISPLAY_H
+#define MIPI_DISPLAY_H
+
+/* MIPI DSI transaction types */
+enum {
+ MIPI_DSI_V_SYNC_START = 0x01,
+ MIPI_DSI_V_SYNC_END = 0x11,
+ MIPI_DSI_H_SYNC_START = 0x21,
+ MIPI_DSI_H_SYNC_END = 0x31,
+
+ MIPI_DSI_COLOR_MODE_OFF = 0x02,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 0x03,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+
+ MIPI_DSI_DCS_SHORT_WRITE= 0x05,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+
+ MIPI_DSI_DCS_READ = 0x06,
+
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+
+ MIPI_DSI_END_OF_TRANSMISSION= 0x08,
+
+ MIPI_DSI_NULL_PACKET= 0x09,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+/* MIPI DCS commands */
+enum {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_CURVE= 0x26,
+ MIPI_DCS_SET_DISPLAY_OFF= 0x28,
+ MIPI_DCS_SET_DISPLAY_ON = 0x29,
+ MIPI_DCS_SET_COLUMN_ADDRESS = 0x2A,
+ MIPI_DCS_SET_PAGE_ADDRESS = 0x2B,
+ MIPI_DCS_WRITE_MEMORY_START = 0x2C,
+ MIPI_DCS_WRITE_LUT = 0x2D,
+ MIPI_DCS_READ_MEMORY_START = 0x2E,
+ MIPI_DCS_SET_PARTIAL_AREA = 0x30,
+ MIPI_DCS_SET_SCROLL_AREA= 0x33,
+ MIPI_DCS_SET_TEAR_OFF = 0x34,
+ MIPI_DCS_SET_TEAR_ON= 0x35,
+ MIPI_DCS_SET_ADDRESS_MODE = 0x36,
+
Re: [PATCH 3/3 v2] musb: AM35x: Workaround for fifo read issue
Hello. Gupta, Ajay Kumar wrote: AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- Patch created against linus'tree + all musb patches in Greg's queue Changes from v1: - removed unnecessary parens. - Removed 'memcpy' for 32 bit read loops. drivers/usb/musb/am3517.c| 30 ++ drivers/usb/musb/musb_core.c |2 ++ 2 files changed, 32 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c index b74e664..3299c66 100644 --- a/drivers/usb/musb/am3517.c +++ b/drivers/usb/musb/am3517.c [...] + } +} diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 4093f6d..9c59a8e 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -262,6 +262,7 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len, const u8 *src) } } +#if !defined(CONFIG_MACH_OMAP3517EVM) Fixes/workaround based on CONFIG_MACH_OMAP3517EVM will be good only for OMAP3517EVM and would not scale well to other boards based on AM35x. (As commented earlier by Sergei) I just got to know of another board LIZARD based on AM35x so we really need to find a solution for this. This problem is due to the fact that AM35x is based on OMAP35x but musb ip Is updated to RTL1.8 using CPPI4.1 DMA engine Is that really the only difference? thus we need to have a config option to differentiate musb ips between actual OMAP3 and AM35x platforms. I am thinking of adding new config option OMAP_MUSB_RTL18 which should be selected by all the boards based on AM35x in arch/arm/mach-omap2/Kconfig. The same config option can be used for all the workaround/fixes specific to AM35x musb platform. -- diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b72ae06..3ab1156 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -95,6 +95,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX select OMAP_PACKAGE_CBB + select OMAP_MUSB_RTL18 config PMIC_TPS65023 bool TPS65023 Power Module -- Does anyone has a better option to fix this issue or any comment on this approach? Why not introduce CONFIG_ARCH_AM35x instead? WBR, Sergei -- 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/3 v2] musb: AM35x: Workaround for fifo read issue
Gupta, Ajay Kumar wrote: Fixes/workaround based on CONFIG_MACH_OMAP3517EVM will be good only for OMAP3517EVM and would not scale well to other boards based on AM35x. (As commented earlier by Sergei) I just got to know of another board LIZARD based on AM35x so we really need to find a solution for this. This problem is due to the fact that AM35x is based on OMAP35x but musb ip Is updated to RTL1.8 using CPPI4.1 DMA engine thus we need to have a config option to differentiate musb ips between actual OMAP3 and AM35x platforms. I am thinking of adding new config option OMAP_MUSB_RTL18 which should be selected by all the boards based on AM35x in arch/arm/mach-omap2/Kconfig. The same config option can be used for all the workaround/fixes specific to AM35x musb platform. -- diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b72ae06..3ab1156 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -95,6 +95,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX select OMAP_PACKAGE_CBB + select OMAP_MUSB_RTL18 config PMIC_TPS65023 bool TPS65023 Power Module -- Does anyone has a better option to fix this issue or any comment on this approach? It would not scale very well - we already have multi-omap builds that select support for multiple boards. If the AM35x boards are part of such builds, then mutually exclusive config options won't work - already n8x0 MUSB is exclusive with 243x/omap3. If it is possible to detect the AM35x at runtime, then we could handle this well. Also, a similar set of changes will be needed for the DMA code as well (right now we can pick only one of the DMA engines at a time). - Anand -- 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/3 v2] musb: AM35x: Workaround for fifo read issue
Hi, Gupta, Ajay Kumar wrote: AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com [...] +#if !defined(CONFIG_MACH_OMAP3517EVM) Fixes/workaround based on CONFIG_MACH_OMAP3517EVM will be good only for OMAP3517EVM and would not scale well to other boards based on AM35x. (As commented earlier by Sergei) I just got to know of another board LIZARD based on AM35x so we really need to find a solution for this. This problem is due to the fact that AM35x is based on OMAP35x but musb ip Is updated to RTL1.8 using CPPI4.1 DMA engine Is that really the only difference? Other difference: USB PHY is built inside the ip itself. Additionally, there is an errata which restricts byte/word (8/16 bit) data read which is due to the bus interface on AM35x. thus we need to have a config option to differentiate musb ips between actual OMAP3 and AM35x platforms. I am thinking of adding new config option OMAP_MUSB_RTL18 which should be selected by all the boards based on AM35x in arch/arm/mach- omap2/Kconfig. The same config option can be used for all the workaround/fixes specific to AM35x musb platform. -- diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b72ae06..3ab1156 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -95,6 +95,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX select OMAP_PACKAGE_CBB + select OMAP_MUSB_RTL18 config PMIC_TPS65023 bool TPS65023 Power Module -- Does anyone has a better option to fix this issue or any comment on this approach? Why not introduce CONFIG_ARCH_AM35x instead? This is fine with me but don't know if Tony would agree with it. -Ajay WBR, Sergei -- 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/3 v2] musb: AM35x: Workaround for fifo read issue
Hi, Fixes/workaround based on CONFIG_MACH_OMAP3517EVM will be good only for OMAP3517EVM and would not scale well to other boards based on AM35x. (As commented earlier by Sergei) I just got to know of another board LIZARD based on AM35x so we really need to find a solution for this. This problem is due to the fact that AM35x is based on OMAP35x but musb ip Is updated to RTL1.8 using CPPI4.1 DMA engine thus we need to have a config option to differentiate musb ips between actual OMAP3 and AM35x platforms. I am thinking of adding new config option OMAP_MUSB_RTL18 which should be selected by all the boards based on AM35x in arch/arm/mach- omap2/Kconfig. The same config option can be used for all the workaround/fixes specific to AM35x musb platform. -- diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b72ae06..3ab1156 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -95,6 +95,7 @@ config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 ARCH_OMAP34XX select OMAP_PACKAGE_CBB + select OMAP_MUSB_RTL18 config PMIC_TPS65023 bool TPS65023 Power Module -- Does anyone has a better option to fix this issue or any comment on this approach? It would not scale very well - we already have multi-omap builds that select support for multiple boards. If the AM35x boards are part of such builds, then mutually exclusive config options won't work - already n8x0 MUSB is exclusive with 243x/omap3. AM35x musb needs different initialization sequence which involves PHY configuration etc. being done in drivers/usb/musb/am3517.c. am3517.c also need to handle different ISR routine and all CPPi4.1 DMA related programmings. If it is possible to detect the AM35x at runtime, then we could handle this well. Also, a similar set of changes will be needed for the DMA code as well (right now we can pick only one of the DMA engines at a time). We do have such mechanism cpu_is_omap3517() but how about compilation flags for am3517.c? Do you intend to have different initialization sequence, ISR function and CPPI4.1 DMA programmings within drivers/usb/musb/omap2430.c ? -Ajay - Anand -- 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] mfd: twl5031: Rename sih modules
Fix the names of twl5031 specific sih modules to match
the documentation.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
drivers/mfd/twl4030-irq.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 202bdd5..097f24d 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -232,10 +232,11 @@ static const struct sih sih_modules_twl5031[8] = {
},
[6] = {
/*
-* ACI doesn't use the same SIH organization.
-* For example, it supports only one interrupt line
+* ECI/DBI doesn't use the same SIH organization.
+* For example, it supports only one interrupt output line.
+* That is, the interrupts are seen on both INT1 and INT2 lines.
*/
- .name = aci,
+ .name = eci_dbi,
.module = TWL5031_MODULE_ACCESSORY,
.bits = 9,
.bytes_ixr = 2,
@@ -247,8 +248,8 @@ static const struct sih sih_modules_twl5031[8] = {
},
[7] = {
- /* Accessory */
- .name = acc,
+ /* Audio accessory */
+ .name = audio,
.module = TWL5031_MODULE_ACCESSORY,
.control_offset = TWL5031_ACCSIHCTRL,
.bits = 2,
--
1.6.0.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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 20 May 2010 11:57:40 +0300 Felipe Balbi m...@felipebalbi.com wrote: On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote: But with that, you still shift the burden of exchanging that app with an feature-equivalent non-broken version to the user. which is not user friendly and not necessary if you have a smart enough kernel. and _without that_, you shift the burden of having a working power management completely into the kernel. Forcing the kernel to deal with completely broken apps. What will happen is that apps developers won't boder thinking about power consumption since the kernel is smart enough to fix their mess. To me that's much bigger burden to the kernel than the other option is to apps. You said that already. For me this sounds like you want to take the users hostage in order to get nice (poweraware) apps. Robust system design can take crap and perform well. Users will most of the time prefer a robust system over a nicely designed system. (Just think of the ak-47) I think we just have to agree to disagree here? Cheers, Flo p.s.: don't take me seriously, i'm just a user -- 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/3 v2] musb: AM35x: Workaround for fifo read issue
On Thu, May 20, 2010 at 11:41:14AM +0200, ext Gadiyar, Anand wrote:
It would not scale very well - we already have multi-omap builds
that select support for multiple boards. If the AM35x boards are
part of such builds, then mutually exclusive config options won't
work - already n8x0 MUSB is exclusive with 243x/omap3.
If it is possible to detect the AM35x at runtime, then we could
handle this well. Also, a similar set of changes will be needed for
the DMA code as well (right now we can pick only one of the DMA
engines at a time).
it's time to split out platform code from musb core. I was thinking of
having omap2430.c blackfin.c tusb6010.c davinci.c be a platform_device
that instantiates musb_hdrc platform_device. It would also ioremap() the
area and pass the gotten/enabled clock to musb. Then we can have all of
the platforms enabled since the board files would pass down the
platform_device for the platform code. Something like:
arch/arm/mach-omap2/usb-musb.c:
static struct platform_device omap_musb = {
.dev= {
.name = omap-hsusbotg,/* using the IP block name */
},
[..]
};
[..]
platform_device_register(omap_musb);
drivers/usb/musb/omap2430.c:
static struct musb_platform_data omap_musb_data;
static int __init omap_musb_probe(struct platform_device *pdev)
{
clk = clk_get(pdev-dev, ick);
base = ioremap(res-start, resource_size(res));
omap_musb_data.clk = clk;
omap_musb_data.base = base;
[... all other necessary fields, like mode, etc]
musb_pdev = platform_device_alloc(musb_hdrc, -1);
musb_pdev-dev.parent = pdev-dev;
platform_device_add_data(musb_pdev, omap_musb_data);
platform_device_add(musb_pdev);
return 0;
}
static int __exit omap_musb_remove(struct platform_device *pdev)
{
clk_put(clk);
iounmap(base);
platform_device_del(musb_pdev);
return 0;
}
[...]
io functions could also be passed through this platform_device so that
we remove the insane amounts of ifdefs. Also context save/restore could
be done a per-platform basis. Since the platform-code would be a parent
to musb_hdrc, platform-code's suspend would be called before musb_hdrc
suspend, then we would save context at that point already.
Any other ifdefferry on anything would be easier to remove with this
approach and it also means we can have one musb_hdrc.ko for all (well
arm-based only) boards and be sure it would work. We would just need to
put something similar down for dma engines.
--
balbi
DefectiveByDesign.org
--
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
[PATCHv2 1/2] omap: rx51: Use REGULATOR_SUPPLY macro when initializing regulator consumers
There is REGULATOR_SUPPLY macro available for initializing the struct
regulator_consumer_supply so use it where applicable (all other supplies
than vdds_sdi) as it improves the readability.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v2:
No functional changes but short description added, rebased on top of 7b93a0d
and added Eduardo's ack to v1.
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 43 ++---
1 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 966f5f8..e8ac47c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -272,48 +272,27 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
{} /* Terminator */
};
-static struct regulator_consumer_supply rx51_vmmc1_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.0,
-};
+static struct regulator_consumer_supply rx51_vmmc1_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
-static struct regulator_consumer_supply rx51_vaux3_supply = {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vaux3_supply =
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
-static struct regulator_consumer_supply rx51_vsim_supply = {
- .supply = vmmc_aux,
- .dev_name = mmci-omap-hs.1,
-};
+static struct regulator_consumer_supply rx51_vsim_supply =
+ REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
- {
- .supply = AVDD,
- .dev_name = 2-0018,
- },
- {
- .supply = DRVDD,
- .dev_name = 2-0018,
- },
+ REGULATOR_SUPPLY(AVDD, 2-0018),
+ REGULATOR_SUPPLY(DRVDD, 2-0018),
/* Keep vmmc as last item. It is not iterated for newer boards */
- {
- .supply = vmmc,
- .dev_name = mmci-omap-hs.1,
- },
+ REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
static struct regulator_consumer_supply rx51_vio_supplies[] = {
/* tlv320aic3x digital supplies */
- {
- .supply = IOVDD,
- .dev_name = 2-0018
- },
- {
- .supply = DVDD,
- .dev_name = 2-0018
- },
+ REGULATOR_SUPPLY(IOVDD, 2-0018),
+ REGULATOR_SUPPLY(DVDD, 2-0018),
};
#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
--
1.7.1
--
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
[PATCHv2 2/2] omap: rx51: Add supply and data for the tpa6130a2 headphone amplifier
With these and upcoming change to tpa6130a2 driver it's possible to add
support for the TPA6130A2 headphone amplifier.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
v2:
- Rebased on top of 7b93a0d
- Only Vdd supply added as the CPVSS turned out to be miss defined in
tpa6130a2. Thanks to Eduardo Valentin eduardo.valen...@nokia.com for
noticing.
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e8ac47c..9e618b6 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -33,6 +33,8 @@
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include sound/tpa6130a2-plat.h
+
#include mux.h
#include hsmmc.h
@@ -285,6 +287,8 @@ static struct regulator_consumer_supply
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+ /* tpa6130a2 */
+ REGULATOR_SUPPLY(Vdd, 2-0060),
/* Keep vmmc as last item. It is not iterated for newer boards */
REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
};
@@ -667,10 +671,19 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
},
};
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
+ .id = TPA6130A2,
+ .power_gpio = 98,
+};
+
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
},
+ {
+ I2C_BOARD_INFO(tpa6130a2, 0x60),
+ .platform_data = rx51_tpa6130a2_data,
+ }
};
static int __init rx51_i2c_init(void)
--
1.7.1
--
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/3 v2] musb: AM35x: Workaround for fifo read issue
On Thu, May 20, 2010 at 12:06:30PM +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: arm-based only) boards and be sure it would work. We would just need to put something similar down for dma engines. and of course, the same platform-code could instantiate a dma engine platform_device but that's trickier, I guess, since the base address would have to be used by two drivers, then platform code would have to handle synchronization. -- balbi DefectiveByDesign.org -- 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] OMAP:GPIO:hwmod: add GPIO hwmods for OMAP3
On 4/22/2010 5:55 PM, Varadarajan, Charulatha wrote:
Add hwmod structures for GPIO module on OMAP3
[snip]
+
+static struct omap_hwmod omap3xxx_gpio1_hwmod = {
+ .name = gpio1_hwmod,
You should remove the _hwmod prefix of all the hwmod name in order to
align with the convention we have on OMAP4.
It will increase the data size without bringing any extra information.
Thanks,
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] OMAP:GPIO:hwmod: add GPIO hwmods for OMAP3
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 20, 2010 3:43 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
t...@atomide.com;
khil...@deeprootsystems.com
Subject: Re: [PATCH 6/9] OMAP:GPIO:hwmod: add GPIO hwmods for OMAP3
On 4/22/2010 5:55 PM, Varadarajan, Charulatha wrote:
Add hwmod structures for GPIO module on OMAP3
[snip]
+
+static struct omap_hwmod omap3xxx_gpio1_hwmod = {
+ .name = gpio1_hwmod,
You should remove the _hwmod prefix of all the hwmod name in order to
align with the convention we have on OMAP4.
It will increase the data size without bringing any extra information.
Yep. Will change the naming convention as followed in OMAP4.
Thanks,
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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
Hi, On Thu, May 20, 2010 at 12:05:19PM +0200, ext Florian Mickler wrote: You said that already. For me this sounds like you want to take the users hostage in order to get nice (poweraware) apps. not the users, no. The app developers. They should know what bad applications can cause to a nicely done system. Robust system design can take crap and perform well. Users will most of the time prefer a robust system over a nicely designed system. (Just think of the ak-47) (hope you're talking about the gun :-p) put some bad bullets on ak-47 and see if it behaves well, a really crappy trigger will also make it fail. How robust can a system be with badly chosen components ? I think we just have to agree to disagree here? I think so. -- balbi DefectiveByDesign.org -- 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 v2] omap4: Fix multi-omap boot with reset un-used clocks
-Original Message- From: Menon, Nishanth Sent: Thursday, May 20, 2010 7:19 AM To: Tony Lindgren Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org; Paul Walmsley Subject: Re: [PATCH v2] omap4: Fix multi-omap boot with reset un-used clocks Tony Lindgren had written, on 05/19/2010 08:24 PM, the following: * Nishanth Menon n...@ti.com [100519 18:03]: Tony Lindgren had written, on 05/19/2010 08:06 PM, the following: * Nishanth Menon n...@ti.com [100519 17:58]: Tony Lindgren had written, on 05/19/2010 08:00 PM, the following: * Nishanth Menon n...@ti.com [100519 12:56]: looks like network is still not functional on SDP4430. different issue Oh so Ethernet does not work either? What's wrong with that? I was told offline that the driver is somewhere in the net ML on the way I believe in parallel.. I dont have collaborative links though :( Santosh, Can you point out the status? I thought I have those in omap-testing and merged into the master branch in linux-omap: ks8851: Add caching of CCR register ks8851: Low level functions for read/write to companion eeprom ks8851: companion eeprom access through ethtool Okay then it makes this an operator error - I have been playing with vanilla linus 2.6.34 tree and adding just the basic patches I need.. I can give the omap-testing a whirl.. OK, cool. tried with omap_testing i pulled a few mins back, omap3_defconfig with CONFIG_EARLY_PRINTK enabled Good news: need as pointed out by Santosh - a) http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27363.html b) this patch for NFS even to try. Bad news: Same results I got as in linus tree - NAK for NFS booting :( full log: http://pastebin.mozilla.org/725960 from the log, I dont see the driver probe even starting up or any reports as you posted above (which I guess is from Blaze).. Tried LO master and networks works great. ** Texas Instruments X-Loader 1.41 (Jan 17 2010 - 23:12:44) Starting OS Bootloader from EMMC ... U-Boot 1.1.4-g0aa2aebd-dirty (Feb 6 2010 - 17:10:35) Load address: 0x80e8 DRAM: 512 MB Flash: 0 kB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Micrel KS8851SNL OMAP44XX SDP # t;bootm ks8851snl ethernet initialized ethaddr rom: 00:08:01:28:43:4D port status information = 0x8400 BOOTP broadcast 1 Using Micrel KS8851SN device TFTP from server 172.24.190.46; our IP address is 172.24.190.176 Filename 'santosh/uImage'. Load address: 0x9030 Loading: T # # # # # ## done Bytes transferred = 1690656 (19cc20 hex) ## Booting image at 9030 ... Image Name: Linux-2.6.34-08151-g1674c0c Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1690592 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-08151-g1674c0c (a0393...@a0393909-desktop) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 SMP PREEMPT Thu May 20 15:50:53 IST 2010 CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP4430 4430SDP board Memory policy: ECC disabled, Data cache writealloc OMAP4430 ES1.0 SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0x10 FIXME: omap44xx_sram_init not implemented PERCPU: Embedded 6 pages/cpu @c0715000 s3584 r8192 d12800 u65536 pcpu-alloc: s3584 r8192 d12800 u65536 alloc=16*4096 pcpu-alloc: [0] 0 [0] 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 117602 Kernel command line: mem=463M console=ttyS2,115200n8 noinitrd rootdelay=1 root=/dev/nfs rw nfsroot=172.24.190.46:/ubuntu/nfs-share/omap4_next ,nolock,tcp,rsize=1024,wsize=1024 ip=dhcp PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 463MB = 463MB total Memory: 466420k/466420k available, 7692k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xdd00 - 0xf800 ( 432 MB) lowmem : 0xc000 - 0xdcf0 ( 463 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc002a000 ( 136 kB) .text : 0xc002a000 - 0xc0326000 (3056 kB) .data : 0xc0326000 - 0xc0357200 ( 197 kB) SLUB:
Re: [PATCH 1/4] fbdev: add a MIPI DSI header
On Thu, 20 May 2010, Tomi Valkeinen wrote: On Thu, 2010-05-20 at 10:07 +0200, ext Guennadi Liakhovetski wrote: Yes, right, I should have said they are related;) How about calling the header mipi_display.h? This would then unite DSI, DCS, DBI and DPI? Creating a separate header for each of these standards seems like an overkill to me. We could then put MIPI CSI and CPI standards in an include/media/mipi_camera.h. Not sure where to put various other MIPI standards, I guess, we'll have to think about it as a need arises. mipi_display.h sounds good to me. Well, true, this is not a clear thing. MIPI DSI spec talks about turn on peripheral command. But the numbers are DSI data types, according to the spec, and not all of them are commands. Ok, how about telegram types then? I wouldn't invent a new word for this =). The DSI spec talks about commands, data types and transactions, I think we should pick one of them. Perhaps this is already approaching nitpicking, but: As only some of the commands/datatypes/transactions are commands, I think that's not proper word. All of them have a data type number, and I guess they all are transactions. So Turn On Peripheral Command is a transaction, and its data type is 0x32. Yes, transaction looks good to me. I guess if the enum is named, it should then be mipi_dsi_transaction. But then, which one of these would be more correct: dsi_send(enum mipi_dsi_transaction transaction) dsi_send(u8 datatype) As I said previously, I haven't seen any panel using custom datatypes, but I wouldn't be surprised if some panel does. In that sense I would go for using u8, and then perhaps leaving the enum unnamed. What do you think? Yes, I'd use u8 too, because the specs define transaction types to take 6 bits and DCS commands to be 8-bit ints. But, you know, doesn't our case fall under case (b) of Chapter 5 Typedefs of CodingStyle?:) I mean, wouldn't it make sense to create two typedefs for these to add some type-safety? In fact, transaction types cannot be user-defined / proprietary, right? So, for that an enum would work. It's only DCS commands that allow extensions. But making transaction type an enum and command a typedef would be ugly, and making a typedef for an enum is frowned upon too... As others voted for unnamed enums, how about using them? Sounds good. Concerning omap2 display drivers, AFAICS the only thing we want to change there is to switch them too to using the common header and telegram type Yep, I think that's the only change for now. and command names? So far I don't see a need for a generic MIPI (display) subsystem in the kernel with an own bus type, API etc. We could of course create a simpe bus with callbacks for sending short and long packets and reading data back, but do we really need it ATM? This is something I've been thinking about for some time. I even made some prototypes for it, but I didn't have time to go forward with it. It would of course be nice to use the same panel driver on different boards, so I think this is definitely something to think about in the future. But you only need specific panel drivers if you want to support their proprietary commands? Otherwise you only need a set of parameters - timeing requirements etc. - which you can perfectly just pass in platform data? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 01:27:25PM +0200, ext Vladimir Pantelic wrote: Felipe Balbi wrote: Hi, On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote: Please note that this approach is not too practical for vendors who ship systems like cell phones to the general public. yeah, tell me about it :-p during development on MeeGo devices we try to tackle down as much as possible the use_time offenders and start by filing bugs to those apps, instead of fixing their issues in kernel space. And you will continue doing that once the Meego app store has 100k apps? I'm not here speaking for MeeGo. I'm presenting my own feelings and my own opinion regarding this issue. Don't bring the company into the game, please. -- balbi DefectiveByDesign.org -- 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] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
Fix board data to support device only, host only and OTG roles.
The board data hardcodes the mode to OTG or Peripheral.
This fix will allow to use Peripheral, Host and OTG
roles independently.
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
---
Based on top of today's mainline.
Applies cleanly on linux-omap master also.
arch/arm/mach-omap2/board-2430sdp.c |6 ++
arch/arm/mach-omap2/board-3430sdp.c |6 ++
arch/arm/mach-omap2/board-4430sdp.c |6 ++
arch/arm/mach-omap2/board-cm-t35.c |6 ++
arch/arm/mach-omap2/board-devkit8000.c |6 ++
arch/arm/mach-omap2/board-igep0020.c |6 ++
arch/arm/mach-omap2/board-ldp.c |6 ++
arch/arm/mach-omap2/board-omap3beagle.c |6 ++
arch/arm/mach-omap2/board-omap3evm.c |6 ++
arch/arm/mach-omap2/board-omap3pandora.c |6 ++
arch/arm/mach-omap2/board-omap3touchbook.c |6 ++
arch/arm/mach-omap2/board-overo.c|6 ++
arch/arm/mach-omap2/board-rx51.c |6 ++
arch/arm/mach-omap2/board-zoom-peripherals.c |6 ++
14 files changed, 84 insertions(+)
Index: mainline/arch/arm/mach-omap2/board-2430sdp.c
===
--- mainline.orig/arch/arm/mach-omap2/board-2430sdp.c
+++ mainline/arch/arm/mach-omap2/board-2430sdp.c
@@ -195,7 +195,13 @@ static struct omap2_hsmmc_info mmc[] __i
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
.power = 100,
};
Index: mainline/arch/arm/mach-omap2/board-ldp.c
===
--- mainline.orig/arch/arm/mach-omap2/board-ldp.c
+++ mainline/arch/arm/mach-omap2/board-ldp.c
@@ -385,7 +385,13 @@ static struct omap_board_mux board_mux[]
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
.power = 100,
};
Index: mainline/arch/arm/mach-omap2/board-omap3beagle.c
===
--- mainline.orig/arch/arm/mach-omap2/board-omap3beagle.c
+++ mainline/arch/arm/mach-omap2/board-omap3beagle.c
@@ -432,7 +432,13 @@ static struct omap_board_mux board_mux[]
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
.power = 100,
};
Index: mainline/arch/arm/mach-omap2/board-overo.c
===
--- mainline.orig/arch/arm/mach-omap2/board-overo.c
+++ mainline/arch/arm/mach-omap2/board-overo.c
@@ -415,7 +415,13 @@ static struct omap_board_mux board_mux[]
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
.power = 100,
};
Index: mainline/arch/arm/mach-omap2/board-3430sdp.c
===
--- mainline.orig/arch/arm/mach-omap2/board-3430sdp.c
+++ mainline/arch/arm/mach-omap2/board-3430sdp.c
@@ -778,7 +778,13 @@ static struct flash_partitions sdp_flash
static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
+#ifdef CONFIG_USB_MUSB_OTG
.mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
.power = 100,
};
Index: mainline/arch/arm/mach-omap2/board-omap3pandora.c
===
--- mainline.orig/arch/arm/mach-omap2/board-omap3pandora.c
+++
[pm-wip/uart][PATCH 0/6]: Serial HWMOD updation and cleanup.
Patch series is based on remotes/origin/pm-wip/govindraj branch from Kevin's PM tree. Patches are tested with 3430SDP. Have updated 2420/2430 hwmod data files it would be great if some one can test the same. Govindraj.R (6): Serial: Clean up set_uart_globals. Serial: Add UART4 hwmod data. Serial: Modify OMAP3 hwmod data file with uart data. Serial: Add UART hwmod data for 2420. Serial: Add UART hwmod data for 2430. Serial: Update UART HWMOD layer. arch/arm/mach-omap2/omap_hwmod_2420_data.c | 184 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 184 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 +- arch/arm/mach-omap2/prcm-common.h |2 + arch/arm/mach-omap2/serial.c | 38 +++ arch/arm/plat-omap/common.c| 17 --- arch/arm/plat-omap/include/plat/common.h |1 - arch/arm/plat-omap/include/plat/dma.h |2 + arch/arm/plat-omap/include/plat/irqs.h |2 + 9 files changed, 449 insertions(+), 47 deletions(-) -- 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
[pm-wip/uart][PATCH 1/6] Serial: Clean up set_uart_globals.
Remove set_uart_globals function as this will not be
needed as physical address for uarts will be taken from
hwmod data file.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |5 -
arch/arm/plat-omap/common.c | 17 -
arch/arm/plat-omap/include/plat/common.h |1 -
3 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a95bc25..7d0dc3a 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -102,11 +102,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
-
-void __init omap2_set_globals_uart(struct omap_globals *omap2_globals)
-{
-}
-
static struct omap_device_pm_latency omap_uart_latency[] = {
{
.deactivate_func = omap_device_idle_hwmods,
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index f12f0e3..354267e 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -252,7 +252,6 @@ static void __init __omap2_set_globals(struct omap_globals
*omap2_globals)
omap2_set_globals_sdrc(omap2_globals);
omap2_set_globals_control(omap2_globals);
omap2_set_globals_prcm(omap2_globals);
- omap2_set_globals_uart(omap2_globals);
}
#endif
@@ -267,9 +266,6 @@ static struct omap_globals omap242x_globals = {
.ctrl = OMAP2420_CTRL_BASE,
.prm= OMAP2420_PRM_BASE,
.cm = OMAP2420_CM_BASE,
- .uart1_phys = OMAP2_UART1_BASE,
- .uart2_phys = OMAP2_UART2_BASE,
- .uart3_phys = OMAP2_UART3_BASE,
};
void __init omap2_set_globals_242x(void)
@@ -288,9 +284,6 @@ static struct omap_globals omap243x_globals = {
.ctrl = OMAP243X_CTRL_BASE,
.prm= OMAP2430_PRM_BASE,
.cm = OMAP2430_CM_BASE,
- .uart1_phys = OMAP2_UART1_BASE,
- .uart2_phys = OMAP2_UART2_BASE,
- .uart3_phys = OMAP2_UART3_BASE,
};
void __init omap2_set_globals_243x(void)
@@ -309,9 +302,6 @@ static struct omap_globals omap3_globals = {
.ctrl = OMAP343X_CTRL_BASE,
.prm= OMAP3430_PRM_BASE,
.cm = OMAP3430_CM_BASE,
- .uart1_phys = OMAP3_UART1_BASE,
- .uart2_phys = OMAP3_UART2_BASE,
- .uart3_phys = OMAP3_UART3_BASE,
};
void __init omap2_set_globals_343x(void)
@@ -321,8 +311,6 @@ void __init omap2_set_globals_343x(void)
void __init omap2_set_globals_36xx(void)
{
- omap3_globals.uart4_phys = OMAP3_UART4_BASE;
-
__omap2_set_globals(omap3_globals);
}
#endif
@@ -335,10 +323,6 @@ static struct omap_globals omap4_globals = {
.prm= OMAP4430_PRM_BASE,
.cm = OMAP4430_CM_BASE,
.cm2= OMAP4430_CM2_BASE,
- .uart1_phys = OMAP4_UART1_BASE,
- .uart2_phys = OMAP4_UART2_BASE,
- .uart3_phys = OMAP4_UART3_BASE,
- .uart4_phys = OMAP4_UART4_BASE,
};
void __init omap2_set_globals_443x(void)
@@ -346,7 +330,6 @@ void __init omap2_set_globals_443x(void)
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
- omap2_set_globals_uart(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 7556e27..3167a9d 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -68,7 +68,6 @@ void omap2_set_globals_tap(struct omap_globals *);
void omap2_set_globals_sdrc(struct omap_globals *);
void omap2_set_globals_control(struct omap_globals *);
void omap2_set_globals_prcm(struct omap_globals *);
-void omap2_set_globals_uart(struct omap_globals *);
/**
* omap_test_timeout - busy-loop, testing a condition
--
1.6.3.3
--
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
[pm-wip/uart][PATCH 2/6] Serial: Add UART4 hwmod data.
Introduce UART4 hwmod data for OMAP3630
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54
arch/arm/mach-omap2/prcm-common.h |2 +
arch/arm/plat-omap/include/plat/dma.h |2 +
arch/arm/plat-omap/include/plat/irqs.h |2 +
4 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5f74c34..079a65e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -86,6 +86,7 @@ static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
static struct omap_hwmod omap3xxx_uart1_hwmod;
static struct omap_hwmod omap3xxx_uart2_hwmod;
static struct omap_hwmod omap3xxx_uart3_hwmod;
+static struct omap_hwmod omap3xxx_uart4_hwmod;
static struct omap_hwmod omap3xxx_mmc1_hwmod;
static struct omap_hwmod omap3xxx_mmc2_hwmod;
static struct omap_hwmod omap3xxx_mmc3_hwmod;
@@ -151,6 +152,24 @@ static struct omap_hwmod_ocp_if omap3_l4_per__uart3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L4 PER - UART4 interface */
+static struct omap_hwmod_addr_space omap3xxx_uart4_addr_space[] = {
+ {
+ .pa_start = OMAP3_UART4_BASE,
+ .pa_end = OMAP3_UART4_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_per__uart4 = {
+ .master = omap3xxx_l4_per_hwmod,
+ .slave = omap3xxx_uart4_hwmod,
+ .clk= uart4_ick,
+ .addr = omap3xxx_uart4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_uart4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4 CORE - MMC1 interface */
static struct omap_hwmod_addr_space omap3xxx_mmc1_addr_space[] = {
{
@@ -257,6 +276,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_slaves[] =
{
/* Master interfaces on the L4_PER interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[] = {
omap3_l4_per__uart3,
+ omap3_l4_per__uart4,
};
/* L4 PER */
@@ -425,6 +445,40 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* UART4 */
+
+static struct omap_hwmod_irq_info uart4_mpu_irqs[] = {
+ { .irq = INT_36XX_UART4_IRQ, },
+};
+
+static struct omap_hwmod_dma_info uart4_sdma_chs[] = {
+ { .name = rx, .dma_ch = OMAP36XX_DMA_UART4_RX, },
+ { .name = tx, .dma_ch = OMAP36XX_DMA_UART4_TX, },
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_uart4_slaves[] = {
+ omap3_l4_per__uart4,
+};
+
+static struct omap_hwmod omap3xxx_uart4_hwmod = {
+ .name = uart4,
+ .mpu_irqs = uart4_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(uart4_mpu_irqs),
+ .sdma_chs = uart4_sdma_chs,
+ .sdma_chs_cnt = ARRAY_SIZE(uart4_sdma_chs),
+ .main_clk = uart4_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3630_EN_UART4_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_uart4_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_uart4_slaves),
+ .class = uart_class,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
+};
+
/* MMC/SD/SDIO common */
static struct omap_hwmod_class_sysconfig mmc_sysc = {
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 90f603d..0fc20c9 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -390,6 +390,8 @@
#define OMAP3430_EN_MPU_SHIFT 1
/* CM_FCLKEN_PER, CM_ICLKEN_PER, PM_WKEN_PER shared bits */
+#define OMAP3630_EN_UART4 (1 18)
+#define OMAP3630_EN_UART4_SHIFT18
#define OMAP3430_EN_GPIO6 (1 17)
#define OMAP3430_EN_GPIO6_SHIFT17
#define OMAP3430_EN_GPIO5 (1 16)
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..105bdb5 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -319,6 +319,8 @@
#define OMAP34XX_DMA_USIM_TX 79 /* S_DMA_78 */
#define OMAP34XX_DMA_USIM_RX 80 /* S_DMA_79 */
+#define OMAP36XX_DMA_UART4_TX 81 /* S_DMA_80 */
+#define OMAP36XX_DMA_UART4_RX 82 /* S_DMA_81 */
/**/
#define OMAP1_DMA_TOUT_IRQ (1 0)
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 4017019..1732cca 100644
---
[pm-wip/uart][PATCH 3/6] Serial: Modify OMAP3 hwmod data file with uart data.
With this patch we retain uart name and just uart
rather than uart_hwmod as per autogenerated file for
omap4 just to retain common names across hwmod data files.
Also pass rx channel id as first dma platform parameter
to driver.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 ++--
arch/arm/mach-omap2/serial.c |2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 079a65e..580ca5b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -350,8 +350,8 @@ static struct omap_hwmod_irq_info uart1_mpu_irqs[] = {
};
static struct omap_hwmod_dma_info uart1_sdma_chs[] = {
- { .name = tx, .dma_ch = OMAP24XX_DMA_UART1_TX, },
{ .name = rx, .dma_ch = OMAP24XX_DMA_UART1_RX, },
+ { .name = tx, .dma_ch = OMAP24XX_DMA_UART1_TX, },
};
static struct omap_hwmod_ocp_if *omap3xxx_uart1_slaves[] = {
@@ -359,7 +359,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_uart1_slaves[] = {
};
static struct omap_hwmod omap3xxx_uart1_hwmod = {
- .name = uart1_hwmod,
+ .name = uart1,
.mpu_irqs = uart1_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(uart1_mpu_irqs),
.sdma_chs = uart1_sdma_chs,
@@ -384,8 +384,8 @@ static struct omap_hwmod_irq_info uart2_mpu_irqs[] = {
};
static struct omap_hwmod_dma_info uart2_sdma_chs[] = {
- { .name = tx, .dma_ch = OMAP24XX_DMA_UART2_TX, },
{ .name = rx, .dma_ch = OMAP24XX_DMA_UART2_RX, },
+ { .name = tx, .dma_ch = OMAP24XX_DMA_UART2_TX, },
};
static struct omap_hwmod_ocp_if *omap3xxx_uart2_slaves[] = {
@@ -393,7 +393,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_uart2_slaves[] = {
};
static struct omap_hwmod omap3xxx_uart2_hwmod = {
- .name = uart2_hwmod,
+ .name = uart2,
.mpu_irqs = uart2_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(uart2_mpu_irqs),
.sdma_chs = uart2_sdma_chs,
@@ -418,8 +418,8 @@ static struct omap_hwmod_irq_info uart3_mpu_irqs[] = {
};
static struct omap_hwmod_dma_info uart3_sdma_chs[] = {
- { .name = tx, .dma_ch = OMAP24XX_DMA_UART3_TX, },
{ .name = rx, .dma_ch = OMAP24XX_DMA_UART3_RX, },
+ { .name = tx, .dma_ch = OMAP24XX_DMA_UART3_TX, },
};
static struct omap_hwmod_ocp_if *omap3xxx_uart3_slaves[] = {
@@ -427,7 +427,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_uart3_slaves[] = {
};
static struct omap_hwmod omap3xxx_uart3_hwmod = {
- .name = uart3_hwmod,
+ .name = uart3,
.mpu_irqs = uart3_mpu_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(uart3_mpu_irqs),
.sdma_chs = uart3_sdma_chs,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 7d0dc3a..9b71c1e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -578,7 +578,7 @@ void __init omap_serial_early_init(void)
struct omap_uart_state *uart;
snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN,
-uart%d_hwmod, i + 1);
+uart%d, i + 1);
oh = omap_hwmod_lookup(oh_name);
if (!oh)
break;
--
1.6.3.3
--
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
[pm-wip/uart][PATCH 4/6] Serial: Add UART hwmod data for 2420.
Add UART HWMOD data into 2420 hmwod data file.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 184
1 files changed, 184 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index eb7ee24..96dd4f4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/serial.h
#include omap_hwmod_common_data.h
@@ -69,6 +70,9 @@ static struct omap_hwmod omap2420_l3_hwmod = {
};
static struct omap_hwmod omap2420_l4_wkup_hwmod;
+static struct omap_hwmod omap2420_uart1_hwmod;
+static struct omap_hwmod omap2420_uart2_hwmod;
+static struct omap_hwmod omap2420_uart3_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -77,6 +81,60 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L4 CORE - UART1 interface */
+static struct omap_hwmod_addr_space omap2420_uart1_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART1_BASE,
+ .pa_end = OMAP2_UART1_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_uart1_hwmod,
+ .clk= uart1_ick,
+ .addr = omap2420_uart1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_uart1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - UART2 interface */
+static struct omap_hwmod_addr_space omap2420_uart2_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART2_BASE,
+ .pa_end = OMAP2_UART2_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_uart2_hwmod,
+ .clk= uart2_ick,
+ .addr = omap2420_uart2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_uart2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - UART3 interface */
+static struct omap_hwmod_addr_space omap2420_uart3_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART3_BASE,
+ .pa_end = OMAP2_UART3_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart3 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_uart3_hwmod,
+ .clk= uart3_ick,
+ .addr = omap2420_uart3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_uart3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] = {
omap2420_l3__l4_core,
@@ -85,6 +143,9 @@ static struct omap_hwmod_ocp_if *omap2420_l4_core_slaves[] =
{
/* Master interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2420_l4_core_masters[] = {
omap2420_l4_core__l4_wkup,
+ omap2_l4_core__uart1,
+ omap2_l4_core__uart2,
+ omap2_l4_core__uart3,
};
/* L4 CORE */
@@ -133,11 +194,134 @@ static struct omap_hwmod omap2420_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/* UART */
+
+static struct omap_hwmod_class_sysconfig uart_sysc = {
+ .rev_offs = 0x50,
+ .sysc_offs = 0x54,
+ .syss_offs = 0x58,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class uart_class = {
+ .name = uart,
+ .sysc = uart_sysc,
+};
+
+/* UART1 */
+
+static struct omap_hwmod_irq_info uart1_mpu_irqs[] = {
+ { .irq = INT_24XX_UART1_IRQ, },
+};
+
+static struct omap_hwmod_dma_info uart1_sdma_chs[] = {
+ { .name = rx, .dma_ch = OMAP24XX_DMA_UART1_RX, },
+ { .name = tx, .dma_ch = OMAP24XX_DMA_UART1_TX, },
+};
+
+static struct omap_hwmod_ocp_if *omap2420_uart1_slaves[] = {
+ omap2_l4_core__uart1,
+};
+
+static struct omap_hwmod omap2420_uart1_hwmod = {
+ .name = uart1,
+ .mpu_irqs = uart1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(uart1_mpu_irqs),
+ .sdma_chs =
[pm-wip/uart][PATCH 5/6] Serial: Add UART hwmod data for 2430.
Add UART HWMOD data into 2430 hmwod data file.
Cc: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 184
1 files changed, 184 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index d9c92aa..3a02532 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/serial.h
#include plat/mmc.h
#include omap_hwmod_common_data.h
@@ -73,6 +74,9 @@ static struct omap_hwmod omap2430_l3_hwmod = {
static struct omap_hwmod omap2430_l4_wkup_hwmod;
static struct omap_hwmod omap2430_mmc1_hwmod;
static struct omap_hwmod omap2430_mmc2_hwmod;
+static struct omap_hwmod omap2430_uart1_hwmod;
+static struct omap_hwmod omap2430_uart2_hwmod;
+static struct omap_hwmod omap2430_uart3_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2430_l4_core__l4_wkup = {
@@ -118,6 +122,60 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mmc2 = {
};
+/* L4 CORE - UART1 interface */
+static struct omap_hwmod_addr_space omap2430_uart1_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART1_BASE,
+ .pa_end = OMAP2_UART1_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart1 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_uart1_hwmod,
+ .clk= uart1_ick,
+ .addr = omap2430_uart1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_uart1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - UART2 interface */
+static struct omap_hwmod_addr_space omap2430_uart2_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART2_BASE,
+ .pa_end = OMAP2_UART2_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart2 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_uart2_hwmod,
+ .clk= uart2_ick,
+ .addr = omap2430_uart2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_uart2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - UART3 interface */
+static struct omap_hwmod_addr_space omap2430_uart3_addr_space[] = {
+ {
+ .pa_start = OMAP2_UART3_BASE,
+ .pa_end = OMAP2_UART3_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2_l4_core__uart3 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_uart3_hwmod,
+ .clk= uart3_ick,
+ .addr = omap2430_uart3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_uart3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[] = {
omap2430_l3__l4_core,
@@ -144,6 +202,9 @@ static struct omap_hwmod omap2430_l4_core_hwmod = {
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap2430_l4_wkup_slaves[] = {
omap2430_l4_core__l4_wkup,
+ omap2_l4_core__uart1,
+ omap2_l4_core__uart2,
+ omap2_l4_core__uart3,
};
/* Master interfaces on the L4_WKUP interconnect */
@@ -283,11 +344,134 @@ static struct omap_hwmod omap2430_mmc2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/* UART */
+
+static struct omap_hwmod_class_sysconfig uart_sysc = {
+ .rev_offs = 0x50,
+ .sysc_offs = 0x54,
+ .syss_offs = 0x58,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class uart_class = {
+ .name = uart,
+ .sysc = uart_sysc,
+};
+
+/* UART1 */
+
+static struct omap_hwmod_irq_info uart1_mpu_irqs[] = {
+ { .irq = INT_24XX_UART1_IRQ, },
+};
+
+static struct omap_hwmod_dma_info uart1_sdma_chs[] = {
+ { .name = rx, .dma_ch = OMAP24XX_DMA_UART1_RX, },
+ { .name = tx, .dma_ch = OMAP24XX_DMA_UART1_TX, },
+};
+
+static struct omap_hwmod_ocp_if *omap2430_uart1_slaves[] = {
+ omap2_l4_core__uart1,
+};
+
+static struct omap_hwmod omap2430_uart1_hwmod = {
+ .name = uart1,
+ .mpu_irqs = uart1_mpu_irqs,
+
RE: [PATCH v4] OMAP3: Registering sgx device and it's platform data
-Original Message-
From: Menon, Nishanth
Sent: Thursday, May 13, 2010 9:02 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Agarwal, Preshit; Tony
Lindgren; Kevin Hilman; Turquette, Mike; V, Hemanth
Subject: Re: [PATCH v4] OMAP3: Registering sgx device and
it's platform data
G, Manjunath Kondaiah had written, on 05/13/2010 12:06 AM,
the following:
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Signed-off-by: Preshit Agarwal preshit.agar...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@ti.com
Cc: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/devices.c | 21
+++--
arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 +++
2 files changed, 30 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 2271b9b..6349ee5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,7 +26,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
-
+#include mach/omap_sgxdef.h
#include mux.h
#if defined(CONFIG_VIDEO_OMAP2) ||
defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -786,6 +786,23 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+struct sgx_platform_data omap_sgx_data = {
+ .set_min_bus_tput = NULL,
+};
+
+static struct platform_device powervr_device = {
+ .name= pvrsrvkm,
+ .id = -1,
+ .dev= {
+ .platform_data = omap_sgx_data,
+ }
+};
+
+static void omap_init_sgx(void)
+{
+ (void) platform_device_register(powervr_device);
+}
+
/*
-*/
static int __init omap2_init_devices(void)
@@ -800,7 +817,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
-
+ omap_init_sgx();
should'nt we depend on has_sgx_feature?
I will change it to: if (omap3_has_sgx) omap_init_sgx();
-Manjunath--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
Hi, Subject: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles. Fix board data to support device only, host only and OTG roles. The board data hardcodes the mode to OTG or Peripheral. This fix will allow to use Peripheral, Host and OTG roles independently. Signed-off-by: Maulik Mankad x0082...@ti.com Same set of code snippet getting repeated across the files. Isn't it good to have them at same commom file usb-musb.c ? I think better remove .mode parameter from board_data if its not needed anyways if some board supports only some specific mode they can select those specifc config only. -Ajay-- 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] OMAP3: Registering sgx device and it's platform data
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, May 14, 2010 10:10 PM
To: G, Manjunath Kondaiah
Cc: linux-omap@vger.kernel.org; Agarwal, Preshit; Tony
Lindgren; Turquette, Mike; V, Hemanth
Subject: Re: [PATCH v4] OMAP3: Registering sgx device and
it's platform data
Manjunatha GK manj...@ti.com writes:
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Now the patch content doesn't match the description as you no
longer call omap_pm_set_min_bus_tput()...
Signed-off-by: Preshit Agarwal preshit.agar...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@ti.com
Cc: Hemanth V heman...@ti.com
---
arch/arm/mach-omap2/devices.c | 21
+++--
arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 +++
2 files changed, 30 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 2271b9b..6349ee5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,7 +26,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
-
+#include mach/omap_sgxdef.h
#include mux.h
#if defined(CONFIG_VIDEO_OMAP2) ||
defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -786,6 +786,23 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+struct sgx_platform_data omap_sgx_data = {
+ .set_min_bus_tput = NULL,
+};
When I suggested you remove the #ifdef CONFIG_PM, I was expecting
you to leave the omap_pm_set_min_bus_tput() part.
The point was that the driver itself should choose whether or
not to call
pdata-set_min_bus_tput() using #ifdef or other runtime decisions.
I agree with your point. I will have only:
.set_min_bus_tput = omap_pm_set_min_bus_tput,
Let driver decide calling this using #ifdef or other runtime decisions.
-Manjunath--
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/4] fbdev: add a MIPI DSI header
On Thu, 2010-05-20 at 13:03 +0200, ext Guennadi Liakhovetski wrote: Yes, I'd use u8 too, because the specs define transaction types to take 6 bits and DCS commands to be 8-bit ints. But, you know, doesn't our case fall under case (b) of Chapter 5 Typedefs of CodingStyle?:) I mean, CodingStyle says: if there is a clear reason for why it under certain circumstances might be an unsigned int and under other configurations might be unsigned long, then by all means go ahead and use a typedef. In our case the DSI transactions and DCS commands are always 6 and 8 bits, so I don't think it applies. And the transaction datatypes and DCS commands are really just payload sent to the peripheral, and the peripheral can do anything it wants with those. wouldn't it make sense to create two typedefs for these to add some But wouldn't a typedef basically lock the possible transactions or DCS commands that you can give to the functions? And that was the original problem also. type-safety? In fact, transaction types cannot be user-defined / proprietary, right? So, for that an enum would work. It's only DCS Why they cannot be? I don't see any technical problem there, at least. And while I don't have any current use to extend transactions, I wouldn't want to limit it for any possible future use either. But you only need specific panel drivers if you want to support their proprietary commands? Otherwise you only need a set of parameters - timeing requirements etc. - which you can perfectly just pass in platform data? That's true. I guess you've gotten it easy, if you only have DSI video mode panels that do not need any special care =). Command mode panels are usually slightly more complex, and especially early prototypes of the panels can require quite a lot of trickery. And then there are DSI hubs, which make DSI command mode panels look trivial... Tomi -- 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] OMAP2/3: Keypad: Fix memory leak
From: Damodar x0132...@ti.com
This patch corrects Possible memory leak of 'input' allocated
through input_allocate_device and Suspicious dereference of pointer 'pdata'
before NULL check
Signed-off-by: Damodar Santhapuri x0132...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 7aa59e0..aa13aec 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -326,30 +326,34 @@ static int __devinit twl4030_kp_program(struct
twl4030_keypad *kp)
*/
static int __devinit twl4030_kp_probe(struct platform_device *pdev)
{
- struct twl4030_keypad_data *pdata = pdev-dev.platform_data;
- const struct matrix_keymap_data *keymap_data = pdata-keymap_data;
+ struct twl4030_keypad_data *pdata;
+ const struct matrix_keymap_data *keymap_data;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
-
+ if (!pdev) {
+ printk(KERN_ERR Invalid platorm_device\n);
+ return -EINVAL;
+ }
+ pdata = pdev-dev.platform_data;
if (!pdata || !pdata-rows || !pdata-cols ||
pdata-rows TWL4030_MAX_ROWS || pdata-cols TWL4030_MAX_COLS) {
dev_err(pdev-dev, Invalid platform_data\n);
return -EINVAL;
}
-
+ keymap_data = pdata-keymap_data;
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
+ if (!kp)
+ return -ENOMEM;
input = input_allocate_device();
- if (!kp || !input) {
+ if (!input) {
error = -ENOMEM;
- goto err1;
+ goto err0;
}
-
/* Get the debug Device */
kp-dbg_dev = pdev-dev;
kp-input = input;
-
kp-n_rows = pdata-rows;
kp-n_cols = pdata-cols;
kp-irq = platform_get_irq(pdev, 0);
@@ -424,6 +428,7 @@ err2:
input = NULL;
err1:
input_free_device(input);
+err0:
kfree(kp);
return error;
}
--
1.7.0.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] OMAP: McSPI: Fix Null pointer check
From: Satish x0124...@ti.com Fix Null pointer check for pointer r in omap2_mcspi_remove() function. Signed-off-by: Satish Kumar x0124...@ti.com Signed-off-by: Manjunatha GK manj...@ti.com Cc: Tony Lindgren t...@atomide.com --- drivers/spi/omap2_mcspi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index e0de0d0..a95d306 100644 --- a/drivers/spi/omap2_mcspi.c +++ b/drivers/spi/omap2_mcspi.c @@ -1198,6 +1198,8 @@ static int __exit omap2_mcspi_remove(struct platform_device *pdev) clk_put(mcspi-ick); r = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (r == NULL) + return -EINVAL; release_mem_region(r-start, (r-end - r-start) + 1); base = mcspi-base; -- 1.7.0.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] OMAP: FB: Fix Null pointer check
From: Satish Kumar satis...@ti.com
Fix Null pointer check for display pointer in omapfb_blank().
Signed-off-by: Satish Kumar satis...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/video/omap2/omapfb/omapfb-main.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..63268cf 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1217,6 +1217,11 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
int do_update = 0;
int r = 0;
+ if (display == NULL) {
+ printk(KERN_ERR omapfb_blank: fb2display returned NULL\n);
+ return -EINVAL;
+ }
+
omapfb_lock(fbdev);
switch (blank) {
--
1.7.0.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] OMAP: Fix Memory leak
From: Satish x0124...@ti.com
The memory allocated for sgt structure is not freed on error
when sg_alloc_table is called in sg_alloc_table().
Signed-off-by: Satish Kumar x0124...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/iovmm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index e43983b..8ce0de2 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -140,8 +140,10 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags)
return ERR_PTR(-ENOMEM);
err = sg_alloc_table(sgt, nr_entries, GFP_KERNEL);
- if (err)
+ if (err) {
+ kfree(sgt);
return ERR_PTR(err);
+ }
pr_debug(%s: sgt:%p(%d entries)\n, __func__, sgt, nr_entries);
--
1.7.0.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/4 v2] fbdev: add a MIPI DSI header
On Thu, 2010-05-20 at 11:30 +0200, ext Guennadi Liakhovetski wrote: This header adds defines for MIPI DSI and DCS commands and data formats. See http://www.mipi.org/ for details. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Ok, how about this? If this is acceptable I'll repost other patches too, adjusted accordingly. Something that is missing are transaction types from peripheral to the host. I think they should be defined here also. But what should the prefix be for them... MIPI_DSI_RX_? I don't know. Tomi -- 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 v3 1/3] omap3 gpmc: functionality enhancement
On Thu, May 20, 2010 at 11:08 AM, Ghorai, Sukumar s-gho...@ti.com wrote:
Vimal,
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: 2010-05-20 00:01
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
t...@atomide.com; sako...@gmail.com; m...@compulab.co.il;
artem.bityuts...@nokia.com; peter.bar...@gmail.com
Subject: Re: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
On Wed, May 19, 2010 at 11:34 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
+
+ case GPMC_CONFIG_RDY_BSY:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
IIRC, at least in OMAP2/3, ready/busy pin is not in use (not
connected).
On the Logic OMAP3530 LV SOM and Torpedo modules, the R/B# pin of the
NAND in the Micron mt29c2g4maklajg-6it POP part is connected to the
WAIT0 pin on the OMAP3530 and I'm looking to use it to speed up NAND
accesses
[Ghorai] So better keep this feature,
Yes, looks like there are some boards which can still take advantage of
this.
[...]
@@ -456,13 +572,20 @@ EXPORT_SYMBOL(gpmc_prefetch_enable);
/**
* gpmc_prefetch_reset - disables and stops the prefetch engine
*/
-void gpmc_prefetch_reset(void)
+int gpmc_prefetch_reset(int cs)
{
+ if (gpmc_pref_used == cs)
+ gpmc_pref_used = -EINVAL;
+ else
+ return -EINVAL;
+
This is also not required. As, this function will be called only if
prefetch was used.
[Ghorai] Agree. Can you see this input too?
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28520.html
Exactly, this is what I am telling here. Enable prefetch engine call
is already being check for *busy* or not.
[...]
+int gpmc_ecc_init(int cs, int ecc_size)
+{
+ unsigned int val = 0x0;
+
+ /* check if ecc engine already by another cs */
+ if (gpmc_ecc_used == -EINVAL)
+ gpmc_ecc_used = cs;
+ else
+ return -EBUSY;
Here few things need be to consider:
1. 'init' is supposed to done once for every instance of driver
during
probe
2. But ECC engine, too, have only one instance at a time, So
3. As long as all NAND chip are supposed to use same ECC machenism,
we
can go for only one time 'init' for all drivers, perhaps in
gpmc_nand.c.
4. But in case, different instances of driver (or NAND chip) requires
different ECC machenism (for ex. Hamming or BCH, or even with
different capabilities of error correction),
this will no longer vailid. Then rather we should have something like
'gpmc_ecc_config' call to configer ECC engine for everytime a driver
needs it (something like as it is done for prefetch engine).
[Ghorai]
a. do you think it will reduce the throughput?
No. But in current implementation it will be called for each instance
driver. (see my 3rd point)
b. Moreover I think we will take this as 5th patch as cleanup/
improvemnt.
c. And how to know that ECC engine is in used other driver should not
use it? Any bit to know that ecc engine is busy, as we check for prefetch?
Do not really remember config registers. Perhaps there is no way.
But I guess you should check into register GPMC_ECC_CONFIG at bit 1.
This is the bit we are setting to enable ECC calculation, IIRC.
d. any further input on http://www.mail-archive.com/linux-
o...@vger.kernel.org/msg28520.html
And this what I was suggesting in my point 4. In my example
'gpmc_ecc_config' is analogy to 'gpmc_ecc_request'.
I said *config*, since in such scenario you need to configer HW
ECCconfig register everytime as well, rather just checking
availability and enabling.
[Ghorai] still I feel we should not mix this patch with cleanup. And yes if
possible this will be the 5th one as cleanup.
4th one - prefetch cleanup
5th one - ecc cleanup.
Do you think still missing anything for this patch?
As long as you take care of current comments, I do not have any
further comment for now.
--
Regards,
Vimal Singh
--
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] DSPBRIDGE: fix incorrect reset in bridge_brd_start function
Guzman Lugo, Fernando wrote: From 595a54c6a886d8e707e04cbf5d0d9b6d6de7c6ec Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Tue, 18 May 2010 20:14:20 -0500 Subject: [PATCH] DSPBRIDGE: fix incorrect reset in bridge_brd_start function IVA mmu reset was not being done properly, so dsp bootaddress was not copied to SYSC register. Given as a result DSP was not booting from that address after reloading baseimage. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- drivers/dsp/bridge/core/tiomap3430.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/core/tiomap3430.c b/drivers/dsp/bridge/core/tiomap3430.c index c7b0d83..805e6f3 100644 --- a/drivers/dsp/bridge/core/tiomap3430.c +++ b/drivers/dsp/bridge/core/tiomap3430.c @@ -443,7 +443,7 @@ static dsp_status bridge_brd_start(struct bridge_dev_context *hDevContext, /* Reset and Unreset the RST2, so that BOOTADDR is copied to * IVA2 SYSC register */ (*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2, - OMAP3430_RST1_IVA2, OMAP3430_IVA2_MOD, RM_RSTCTRL); + OMAP3430_RST2_IVA2, OMAP3430_IVA2_MOD, RM_RSTCTRL); udelay(100); (*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2, 0, OMAP3430_IVA2_MOD, RM_RSTCTRL); Tested by: Deepak chitrikideepak.chitr...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Fix Memory leak
On Thu, May 20, 2010 at 7:59 PM, Manjunatha GK manj...@ti.com wrote: From: Satish x0124...@ti.com The memory allocated for sgt structure is not freed on error when sg_alloc_table is called in sg_alloc_table(). Typo mistake: correct sg_alloc_table to sgtable_alloc for second time. -- Regards, Vimal Singh -- 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] OMAP2/3: Keypad: Fix memory leak
On Thu, May 20, 2010 at 7:59 PM, Manjunatha GK manj...@ti.com wrote:
From: Damodar x0132...@ti.com
This patch corrects Possible memory leak of 'input' allocated
through input_allocate_device and Suspicious dereference of pointer 'pdata'
before NULL check
Signed-off-by: Damodar Santhapuri x0132...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 7aa59e0..aa13aec 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -326,30 +326,34 @@ static int __devinit twl4030_kp_program(struct
twl4030_keypad *kp)
*/
static int __devinit twl4030_kp_probe(struct platform_device *pdev)
{
- struct twl4030_keypad_data *pdata = pdev-dev.platform_data;
- const struct matrix_keymap_data *keymap_data = pdata-keymap_data;
+ struct twl4030_keypad_data *pdata;
+ const struct matrix_keymap_data *keymap_data;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
-
+ if (!pdev) {
+ printk(KERN_ERR Invalid platorm_device\n);
+ return -EINVAL;
+ }
+ pdata = pdev-dev.platform_data;
if (!pdata || !pdata-rows || !pdata-cols ||
pdata-rows TWL4030_MAX_ROWS || pdata-cols TWL4030_MAX_COLS) {
dev_err(pdev-dev, Invalid platform_data\n);
return -EINVAL;
}
-
+ keymap_data = pdata-keymap_data;
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
+ if (!kp)
+ return -ENOMEM;
input = input_allocate_device();
- if (!kp || !input) {
+ if (!input) {
error = -ENOMEM;
- goto err1;
+ goto err0;
If I am not mistaking you should still goto 'err1', as
'input_register_device' is yet not called.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
I think better remove .mode parameter from board_data if its not needed anyways But it *IS* needed, as I explained before... if some board supports only some specific mode they can select those specifc config only. No they can't. Recall that kernels are expected to run on multiple boards. Which means that the same kernel should be able to work correctly on a board with a peripheral-only USB connector ... and on a board with an OTG connector. The way to pass that information to the MUSB driver is through the platform data. On the peripheral-only config the host code won't kick in. On the OTG-enabled config, it will kick in as needed (as will the peripheral mode). And so on. If you were to rely on Kconfig options, then at least one of those boards would work incorrectly. So that's not an option. -- 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] OMAP2/3: Keypad: Fix memory leak
On Thu, May 20, 2010 at 8:41 PM, Vimal Singh vimal.neww...@gmail.com wrote:
On Thu, May 20, 2010 at 7:59 PM, Manjunatha GK manj...@ti.com wrote:
From: Damodar x0132...@ti.com
This patch corrects Possible memory leak of 'input' allocated
through input_allocate_device and Suspicious dereference of pointer 'pdata'
before NULL check
Signed-off-by: Damodar Santhapuri x0132...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 7aa59e0..aa13aec 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -326,30 +326,34 @@ static int __devinit twl4030_kp_program(struct
twl4030_keypad *kp)
*/
static int __devinit twl4030_kp_probe(struct platform_device *pdev)
{
- struct twl4030_keypad_data *pdata = pdev-dev.platform_data;
- const struct matrix_keymap_data *keymap_data = pdata-keymap_data;
+ struct twl4030_keypad_data *pdata;
+ const struct matrix_keymap_data *keymap_data;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
-
+ if (!pdev) {
+ printk(KERN_ERR Invalid platorm_device\n);
+ return -EINVAL;
+ }
+ pdata = pdev-dev.platform_data;
if (!pdata || !pdata-rows || !pdata-cols ||
pdata-rows TWL4030_MAX_ROWS || pdata-cols TWL4030_MAX_COLS)
{
dev_err(pdev-dev, Invalid platform_data\n);
return -EINVAL;
}
-
+ keymap_data = pdata-keymap_data;
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
+ if (!kp)
+ return -ENOMEM;
input = input_allocate_device();
- if (!kp || !input) {
+ if (!input) {
error = -ENOMEM;
- goto err1;
+ goto err0;
If I am not mistaking you should still goto 'err1', as
'input_register_device' is yet not called.
Sorry, my ignorance that device is yet not allocated.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
On Thu, May 20, 2010 at 05:15:30PM +0200, ext David Brownell wrote: I think better remove .mode parameter from board_data if its not needed anyways But it *IS* needed, as I explained before... if some board supports only some specific mode they can select those specifc config only. No they can't. Recall that kernels are expected to run on multiple boards. Which means that the same kernel should be able to work correctly on a board with a peripheral-only USB connector ... and on a board with an OTG connector. The way to pass that information to the MUSB driver is through the platform data. On the peripheral-only config the host code won't kick in. On the OTG-enabled config, it will kick in as needed (as will the peripheral mode). And so on. If you were to rely on Kconfig options, then at least one of those boards would work incorrectly. So that's not an option. that's basically why I had made mode a parameter to usb_musb_init() so boards could pass they're own configuration. We still have the Kconfig to allow single board peripheral only defconfigs (line n900_defconfig) to remove unnecessary code from the kernel. -- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
Subject: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles. Fix board data to support device only, host only and OTG roles. The board data hardcodes the mode to OTG or Peripheral. Or host. That's correct... because the *BOARD* is hard-wired that way. Based on what connector is present, the driver uses that board-specific data to ensure it's exposing the right capabilities. (Example, a host-only board won't expose either OTG or peripheral capabilities, etc.) This fix will allow to use Peripheral, Host and OTG roles independently. The driver has had that capability almost forever... If you're saying that somebody broke the mode setup logic in the driver, which originally tested the board capabilities before it enabled the relevant driver capabilities, then the solution is to un-break that code ... not to further break it. ISTR it was pretty straightforward: boards with a host or peripheral connector could only enter that driver mode, but boards with an OTG connector could enter either driver mode. This affected initialization (one or both sides of the USB stack needed initialization before the driver could properly start) as well as role switching at runtime (either based on ID-sensing in the connector, or HNP). As of something like a year and a half ago, the cable based role switching worked pretty well (ID sensing) and HNP behaved at least partially, although there were some OTG conformance test failures (timing etc, but the roles did switch correctly via HNP, verified with both OMAP3 and DaVinci boards). Now the PITA was that the Mentor IP doesn't clearly document some of the key initialization or role switching steps. I recall losing over a month trying to make sense of what they wanted, since their state machine didn't match the OTG spec. I could easily believe that some patch broke that again. Which means someone might need to bisect things to fix a bug they inserted... Peripheral mode init was fragile to an extreme; changing the sequence was almost guaranteed to break something. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
+#ifdef CONFIG_USB_MUSB_OTG + .mode = MUSB_OTG, +#elif defined(CONFIG_USB_MUSB_HDRC_HCD) + .mode = MUSB_HOST, +#elif defined(CONFIG_USB_GADGET_MUSB_HDRC) .mode = MUSB_PERIPHERAL, +#endif = MUSB_PERIPHERAL, +#endif By the way ... the #ifdeffery should indeed vanish from all board configs except the Davinci DM6446 EVM. That board is kind of quirky in terms of USB support, and needs jumpering to get host or peripheral mode (and can't do OTG). I suspect some of the other boards did a bad thing and tried emulating what that board did. But the description for such a patch would emphasize removing bogus ifdeffery, to match the board hardware (which is not conditional but is instead fixed). -- 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/4 v3] fbdev: add a MIPI DSI header
This header adds defines for MIPI DSI and DCS commands and data formats. See
http://www.mipi.org/ for details.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v2 - v3:
1. added peripheral-to-processor transaction types
v1 - v2:
1. renamed mpi_dsi.h to mipi_display.h
2. improved introductory comment
3. changed 10 enum values to match others as 0x0N
4. changed command to transaction
5. added a couple of missing transaction types
6. enums are now unnamed
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
new file mode 100644
index 000..ddcc8ca
--- /dev/null
+++ b/include/video/mipi_display.h
@@ -0,0 +1,130 @@
+/*
+ * Defines for Mobile Industry Processor Interface (MIPI(R))
+ * Display Working Group standards: DSI, DCS, DBI, DPI
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DISPLAY_H
+#define MIPI_DISPLAY_H
+
+/* MIPI DSI Processor-to-Peripheral transaction types */
+enum {
+ MIPI_DSI_V_SYNC_START = 0x01,
+ MIPI_DSI_V_SYNC_END = 0x11,
+ MIPI_DSI_H_SYNC_START = 0x21,
+ MIPI_DSI_H_SYNC_END = 0x31,
+
+ MIPI_DSI_COLOR_MODE_OFF = 0x02,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 0x03,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+
+ MIPI_DSI_DCS_SHORT_WRITE= 0x05,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+
+ MIPI_DSI_DCS_READ = 0x06,
+
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+
+ MIPI_DSI_END_OF_TRANSMISSION= 0x08,
+
+ MIPI_DSI_NULL_PACKET= 0x09,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+/* MIPI DSI Peripheral-to-Processor transaction types */
+enum {
+ MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT= 0x02,
+ MIPI_DSI_RX_END_OF_TRANSMISSION = 0x08,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE = 0x11,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE = 0x12,
+ MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE = 0x1a,
+ MIPI_DSI_RX_DCS_LONG_READ_RESPONSE = 0x1c,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE = 0x21,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE = 0x22,
+};
+
+/* MIPI DCS commands */
+enum {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_CURVE= 0x26,
+
Re: [PATCH 10/11] OMAP: GPIO: Implement GPIO as a platform device
Cousson, Benoit b-cous...@ti.com writes:
Hi Charu
From: Varadarajan, Charulatha
From: Cousson, Benoit
Sent: Tuesday, May 18, 2010 10:55 PM
Hi Charu,
On 5/18/2010 4:50 PM, Charulatha V wrote:
[snip]
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-
omap2/clock2420_data.c
index d932b14..a693403 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1802,8 +1802,14 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, uart2_fck,uart2_fck, CK_242X),
CLK(NULL, uart3_ick,uart3_ick, CK_242X),
CLK(NULL, uart3_fck,uart3_fck, CK_242X),
- CLK(NULL, gpios_ick,gpios_ick, CK_242X),
- CLK(NULL, gpios_fck,gpios_fck, CK_242X),
+ CLK(omap-gpio.0, ick,gpios_ick, CK_242X),
+ CLK(omap-gpio.1, ick,gpios_ick, CK_242X),
+ CLK(omap-gpio.2, ick,gpios_ick, CK_242X),
+ CLK(omap-gpio.3, ick,gpios_ick, CK_242X),
+ CLK(omap-gpio.0, fck,gpios_fck, CK_242X),
+ CLK(omap-gpio.1, fck,gpios_fck, CK_242X),
+ CLK(omap-gpio.2, fck,gpios_fck, CK_242X),
+ CLK(omap-gpio.3, fck,gpios_fck, CK_242X),
Are you sure that this is still needed? In theory Paul removed the
dependency a couple of months ago.
HWMOD does not need that anymore at least, it is relying on the clock
name only.
You are right. These are not required if hwmod is used. But
here we use pm_runtime APIs which needs clk_get/ clk_enable in
case of CONFIG_PM_RUNTIME is not defined.
Also in OMAP34, for dbck we need clk_get/clk_enable to be
used as opt_clk is
taken care by the driver. Hence the above changes are required.
That still looks wrong to me. We cannot keep exposing manual clock management
method in case runtime_pm is not used.
It makes the whole hwmod isolation stuff a little bit useless, it forces us
to maintain some dummy clocks node...
In that case you should use the omap_device to enable the device.
I agree, the !CONFIG_PM_RUNTIME case can still use omap_device API.
Dbck are listed as opt_clock in the hwmod struct and thus can be accesses.
Agreed.
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: [PATCH] omap:hwmod-remove prm header from prm-regbits-xxxx headers
Hari Kanigeri h-kanige...@ti.com writes: The prm-regbits-.h header files are not dependent on prm.h header file. Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 + This file is not in mailine, or linux-omap master. Please state any dependencies in this part of the changelog. Kevin arch/arm/mach-omap2/prm-regbits-24xx.h |1 - arch/arm/mach-omap2/prm-regbits-34xx.h |1 - arch/arm/mach-omap2/prm-regbits-44xx.h |1 - 4 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 667633c..88cc9ca 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -26,6 +26,7 @@ #include omap_hwmod_common_data.h #include cm.h +#include prm.h #include prm-regbits-44xx.h /* Base offset for all OMAP4 interrupts external to MPUSS */ diff --git a/arch/arm/mach-omap2/prm-regbits-24xx.h b/arch/arm/mach-omap2/prm-regbits-24xx.h index 4002051..fd763b5 100644 --- a/arch/arm/mach-omap2/prm-regbits-24xx.h +++ b/arch/arm/mach-omap2/prm-regbits-24xx.h @@ -14,7 +14,6 @@ * published by the Free Software Foundation. */ -#include prm.h /* Bits shared between registers */ diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h b/arch/arm/mach-omap2/prm-regbits-34xx.h index 8f21bae..ef7fd5e 100644 --- a/arch/arm/mach-omap2/prm-regbits-34xx.h +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h @@ -14,7 +14,6 @@ * published by the Free Software Foundation. */ -#include prm.h /* Shared register bits */ diff --git a/arch/arm/mach-omap2/prm-regbits-44xx.h b/arch/arm/mach-omap2/prm-regbits-44xx.h index 597be4a..ef7af7e 100644 --- a/arch/arm/mach-omap2/prm-regbits-44xx.h +++ b/arch/arm/mach-omap2/prm-regbits-44xx.h @@ -22,7 +22,6 @@ #ifndef __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_44XX_H #define __ARCH_ARM_MACH_OMAP2_PRM_REGBITS_44XX_H -#include prm.h /* -- 1.7.0 -- 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 -- 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/6] OMAP: hwmod: Temporary disable dependency
Benoit Cousson b-cous...@ti.com writes: From: Rajendra Nayak rna...@ti.com Dependency not supported yet, hence comment all dependency handling code in hwmod. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 2fff39f..302f2c8 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -908,7 +908,9 @@ static int _enable(struct omap_hwmod *oh) /* XXX mux balls */ +#if 0 _add_initiator_dep(oh, mpu_oh); +#endif _enable_clocks(oh); r = _wait_target_ready(oh); @@ -949,7 +951,9 @@ static int _idle(struct omap_hwmod *oh) if (oh-class-sysc) _sysc_idle(oh); +#if 0 _del_initiator_dep(oh, mpu_oh); +#endif At least, the temporaty hack should use cpu_is_* as to not break OMAP3. 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: [PATCH 6/6] OMAP: hwmod: Temp fixes to get hwmod registers work
Benoit Cousson b-cous...@ti.com writes: From: Rajendra Nayak rna...@ti.com Do not disable any clocks yet since not all drivers are adapted and rely on bootloader to enable clocks Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 302f2c8..9f7cb9f 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -524,6 +524,8 @@ static int _disable_clocks(struct omap_hwmod *oh) pr_debug(omap_hwmod: %s: disabling clocks\n, oh-name); + return 0; + again, a cpu_is_* would be preferred, even for a temporary hack as this obviously affects OMAP3 as well. 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: [PATCH v4 0/5] Adding MMC Support on OMAP4430 SDP
- Original Message - From: Tony Lindgren t...@atomide.com To: kishore kadiyala kishore.kadiy...@ti.com Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; madhu...@ti.com; jarkko.lavi...@nokia.com; r...@arm.linux.org.uk; p...@pwsan.com; santosh.shilim...@ti.com Sent: Thursday, May 20, 2010 6:28 AM Subject: Re: [PATCH v4 0/5] Adding MMC Support on OMAP4430 SDP * kishore kadiyala kishore.kadiy...@ti.com [100519 08:39]: FYI, the MMC on omap4 is not quite there yet at least on my board. It mostly detects the card with omap_4430sdp_defconfig, but fails always unless CONFIG_RTC_DRV_TWL92330=y.. This is without CONFIG_SMP as it oopses. Hope you are referring CONFIG_RTC_DRV_TWL92330 to omap3_defconfig and not to omap_4430sdp_defconfig. Sorry I meant CONFIG_RTC_DRV_TWL4030 in the omap_4430sdp_defconfig. If you take that out, MMC is never detected. Even disabling CONFIG_RTC_DRV_TWL4030 in omap_4430sdp_defconfig, card gets detected always on booting up. With omap_4430sdp_defconfig , I've tested on 4430SDP and Blaze and always Cards on MMC1 MMC2 gets detected once bootedup. Are you able to actually mount root on the MMC with let's say current linux-omap master branch? Yes I booted with file system mounted on card present on MMC1, and I can see cards getting detected properly and also filesystem gettting mounted. Here are the boot logs with CONFIG_RTC_DRV_TWL4030 disabled and filesystem on ext2 partition of card present on MMC1 http://pastebin.mozilla.org/726228 Regards, Kishore Also MMC is never detected with omap3_defconfig. With omap3_defconfig + disabling CONFIG_OMAP_RESET_CLOCKS, I've tested on 4430SDP and Blaze and always Cards on MMC1 MMC2 gets detected on bootup. That should be fixed so CONFIG_OMAP_RESET_CLOCKS works. Otherwise we're relying on some random clocks being enabled. I've piled all these patches into linux-omap master branch for easy testing. Let me know if I missed some patch. Following is the commit ID :1674c0ceabfb7726246989874bb4da7bcb55ea89 used on LO master branch for testing. All the patches were merged. OK, thanks for checking that. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
during development on MeeGo devices we try to tackle down as much as possible the use_time offenders and start by filing bugs to those apps, instead of fixing their issues in kernel space. Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to see some fixes be appropriately in-kernel; maybe not many though. When reading about this suspend block stuff, does anyone else hear eachoes of APM? It's been ages since that was used, but ISTR it also leveraged handshaking between kernel and userspace. Are there lessons to be applied from there to this discussion? On first principles, I don't see anything wrong with acknowledging that the kernel doesn't have a whole system PM view and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request. Just what that broad PM view consists of gets kind of system-specific. For OMAP hardware, with smart device-level power reduction active almost all the time, it may look different from an ACPI laptop where the BIOS is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially off-ness). And you will continue doing that once the Meego app store has 100k apps? I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... -- 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/5] gpiolib: introduce set_debounce method
On Mon, 17 May 2010 13:02:30 +0300
felipe.ba...@nokia.com wrote:
From: Felipe Balbi felipe.ba...@nokia.com
Few architectures, like OMAP, allow you to set
a debouncing time for the gpio before generating
the IRQ. Teach gpiolib about that.
...
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1447,6 +1447,49 @@ fail:
}
EXPORT_SYMBOL_GPL(gpio_direction_output);
+/**
+ * gpio_set_debounce - sets @debounce time for a @gpio
+ * @gpio: the gpio to set debounce time
+ * @debounce: debounce time is microseconds
+ */
+int gpio_set_debounce(unsigned gpio, unsigned debounce)
+{
+ unsigned long flags;
+ struct gpio_chip*chip;
+ struct gpio_desc*desc = gpio_desc[gpio];
+ int status = -EINVAL;
+
+ spin_lock_irqsave(gpio_lock, flags);
+
+ if (!gpio_is_valid(gpio))
+ goto fail;
+ chip = desc-chip;
+ if (!chip || !chip-set || !chip-set_debounce)
+ goto fail;
+ gpio -= chip-base;
+ if (gpio = chip-ngpio)
+ goto fail;
+ status = gpio_ensure_requested(desc, gpio);
+ if (status 0)
+ goto fail;
+
+ /* now we know the gpio is valid and chip won't vanish */
+
+ spin_unlock_irqrestore(gpio_lock, flags);
+
+ might_sleep_if(extra_checks chip-can_sleep);
+
+ return chip-set_debounce(chip, gpio, debounce);
+
+fail:
+ spin_unlock_irqrestore(gpio_lock, flags);
+ if (status)
+ pr_debug(%s: gpio-%d status %d\n,
+ __func__, gpio, status);
+
+ return status;
+}
+EXPORT_SYMBOL_GPL(gpio_set_debounce);
nitlet: I suspect this function is taking gpio_lock sooner than it
strictly needs to. Find-tuning that would decrease contention by an
insignificant amount ;)
--
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/6] teach gpiolib about gpio debouncing
On Mon, 17 May 2010 13:02:29 +0300 felipe.ba...@nokia.com wrote: From: Felipe Balbi felipe.ba...@nokia.com Hi all, I'm resending this series since no-one has had any further comments for quite some time. Adding Andrew Morton to the loop also since David Brownell didn't pick the patch neither comment to any version of it. David's been very quiet lately - please always cc me on gpio patches. When were these first sent? Has there been any feedback or external testing? I'm not seeing anything in the changelogs which helps me to understand how important this feature is and it's rather late to be merging 2.6.35 feature work.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:hwmod-remove prm header from prm-regbits-xxxx headers
Hi Kevin -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, May 20, 2010 12:13 PM To: Kanigeri, Hari Cc: Paul Walmsley; Linux Omap Subject: Re: [PATCH] omap:hwmod-remove prm header from prm-regbits- headers Hari Kanigeri h-kanige...@ti.com writes: The prm-regbits-.h header files are not dependent on prm.h header file. Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 + This file is not in mailine, or linux-omap master. Please state any dependencies in this part of the changelog. This is based on the latest omap4_next branch on dev.omapzoom.org, so most probably didn't make it to linux omap yet. I came to know through Benoit that this file is auto-generated using Perl script, so I guess this change can be handled in the generator script. Thank you, Best regards, Hari -- 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 v2 1/3] scheduler: cpuacct: Enable platform hooks to track cpuusage for CPU frequencies
V2:
- Rebased off of Thomas Renninger's cgroup_cpuacct refactoring.
- Renamed function struct to cpuacct_chrage_calls from cpuacct_cpufreq_calls
Introduce new platform callback hooks for cpuacct for tracking CPU frequencies
Not all platforms / architectures have a set CPU_FREQ_TABLE defined
for CPU transition speeds. In order to track time spent in at various
CPU frequencies, we enable platform callbacks from cpuacct for this accounting.
Architectures that support overclock boosting, or don't have pre-defined
frequency tables can implement their own bucketing system that makes sense
given their cpufreq scaling abilities.
New file:
cpuacct.cpufreq reports the CPU time (in nanoseconds) spent at each CPU
frequency.
Signed-off-by: Mike Chan m...@android.com
---
Documentation/cgroups/cpuacct.txt |4 +++
include/linux/cpuacct.h | 41 +++
kernel/cgroup_cpuaccount.c| 49 +
3 files changed, 94 insertions(+), 0 deletions(-)
create mode 100644 include/linux/cpuacct.h
diff --git a/Documentation/cgroups/cpuacct.txt
b/Documentation/cgroups/cpuacct.txt
index 8b93094..600d2d0 100644
--- a/Documentation/cgroups/cpuacct.txt
+++ b/Documentation/cgroups/cpuacct.txt
@@ -40,6 +40,10 @@ system: Time spent by tasks of the cgroup in kernel mode.
user and system are in USER_HZ unit.
+cpuacct.cpufreq file gives CPU time (in nanoseconds) spent at each CPU
+frequency. Platform hooks must be implemented inorder to properly track
+time at each CPU frequency.
+
cpuacct controller uses percpu_counter interface to collect user and
system times. This has two side effects:
diff --git a/include/linux/cpuacct.h b/include/linux/cpuacct.h
new file mode 100644
index 000..6205d29
--- /dev/null
+++ b/include/linux/cpuacct.h
@@ -0,0 +1,41 @@
+/* include/linux/cpuacct.h
+ *
+ * Copyright (C) 2010 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _CPUACCT_H_
+#define _CPUACCT_H_
+
+#ifdef CONFIG_CGROUP_CPUACCT
+
+#include linux/cgroup.h
+
+/*
+ * Platform specific CPU frequency hooks for cpuacct. These functions are
+ * called from the scheduler.
+ */
+struct cpuacct_charge_calls {
+ /*
+* Platforms can take advantage of this data and use
+* per-cpu allocations if necessary.
+*/
+ void (*init) (void **cpuacct_data);
+ void (*charge) (void *cpuacct_data, u64 cputime, unsigned int cpu);
+ void (*show) (void *cpuacct_data, struct cgroup_map_cb *cb);
+};
+
+int cpuacct_charge_register(struct cpuacct_charge_calls *fn);
+
+#endif /* CONFIG_CGROUPS */
+
+#endif /* _CPUACCT_H_ */
diff --git a/kernel/cgroup_cpuaccount.c b/kernel/cgroup_cpuaccount.c
index 0ad356a..11799a7 100644
--- a/kernel/cgroup_cpuaccount.c
+++ b/kernel/cgroup_cpuaccount.c
@@ -7,6 +7,7 @@
#include linux/slab.h
#include linux/seq_file.h
#include linux/err.h
+#include linux/cpuacct.h
#include asm/cputime.h
@@ -26,8 +27,30 @@ struct cpuacct {
u64 __percpu *cpuusage;
struct percpu_counter cpustat[CPUACCT_STAT_NSTATS];
struct cpuacct *parent;
+ struct cpuacct_charge_calls *cpufreq_fn;
+ void *cpuacct_data;
};
+static struct cpuacct *cpuacct_root;
+
+/* Default calls for cpufreq accounting */
+static struct cpuacct_charge_calls *cpuacct_cpufreq;
+int cpuacct_charge_register(struct cpuacct_charge_calls *fn)
+{
+ cpuacct_cpufreq = fn;
+
+ /*
+* Root node is created before platform can register callbacks,
+* initalize here.
+*/
+ if (cpuacct_root fn) {
+ cpuacct_root-cpufreq_fn = fn;
+ if (fn-init)
+ fn-init(cpuacct_root-cpuacct_data);
+ }
+ return 0;
+}
+
struct cgroup_subsys cpuacct_subsys;
/* return cpu accounting group corresponding to this container */
@@ -62,8 +85,16 @@ static struct cgroup_subsys_state *cpuacct_create(
if (percpu_counter_init(ca-cpustat[i], 0))
goto out_free_counters;
+ ca-cpufreq_fn = cpuacct_cpufreq;
+
+ /* If available, have platform code initalize cpu frequency data */
+ if (ca-cpufreq_fn ca-cpufreq_fn-init)
+ ca-cpufreq_fn-init(ca-cpuacct_data);
+
if (cgrp-parent)
ca-parent = cgroup_ca(cgrp-parent);
+ else
+ cpuacct_root = ca;
return ca-css;
@@ -191,6 +222,16 @@ static int cpuacct_stats_show(struct cgroup *cgrp, struct
cftype *cft,
return 0;
}
+static int
[PATCH v2 0/3] Enable CPU frequency and power tracking in cpuacct cgroup
v2: Rebased off of Thomas Renninger's patch for cgroups_cpuacct refactoring, which is based off of linus's tree. Thomas it might be easier to merge our patches if you take these patches and put them in a series ontop of your original patches (presuming there are no objections to your patch). This patch series introduces cpu frequency and power tracking for cpuacct cgroups. A similar patch set was discussed a while back and it was concluded that due to varying architectures (ppc, x86 with overboot) you cannot account for frequencies and their power consumption generically in sched.c, thus we have platform specific hooks the cpuacct can call into (if available). This patch series is not 3 instead of 4. I have left out the power implementation for OMAP due to implementation conflicts in linux-next. Mike Chan (3): scheduler: cpuacct: Enable platform hooks to track cpuusage for CPU frequencies scheduler: cpuacct: Enable platform callbacks for cpuacct power tracking omap: cpu: Implement callbacks for cpu frequency tracking in cpuacct Documentation/cgroups/cpuacct.txt |7 arch/arm/plat-omap/cpu-omap.c | 67 +++- include/linux/cpuacct.h | 43 +++ kernel/cgroup_cpuaccount.c| 69 + 4 files changed, 185 insertions(+), 1 deletions(-) create mode 100644 include/linux/cpuacct.h Signed-off-by: Mike Chan m...@android.com -- 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 v2 2/3] scheduler: cpuacct: Enable platform callbacks for cpuacct power tracking
V2:
- Rebased off Thomass Renninger's cgroup_cpuacct refactoring
Platform must register cpu power function that return power in
milliWatt seconds.
New file:
cpuacct.power reports the power consumed in milliWatt seconds
Signed-off-by: Mike Chan m...@android.com
---
Documentation/cgroups/cpuacct.txt |3 +++
include/linux/cpuacct.h |4 +++-
kernel/cgroup_cpuaccount.c| 24 ++--
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/cgroups/cpuacct.txt
b/Documentation/cgroups/cpuacct.txt
index 600d2d0..84e471b 100644
--- a/Documentation/cgroups/cpuacct.txt
+++ b/Documentation/cgroups/cpuacct.txt
@@ -44,6 +44,9 @@ cpuacct.cpufreq file gives CPU time (in nanoseconds) spent at
each CPU
frequency. Platform hooks must be implemented inorder to properly track
time at each CPU frequency.
+cpuacct.power file gives CPU power consumed (in milliWatt seconds). Platform
+must provide and implement power callback functions.
+
cpuacct controller uses percpu_counter interface to collect user and
system times. This has two side effects:
diff --git a/include/linux/cpuacct.h b/include/linux/cpuacct.h
index 6205d29..c17a634 100644
--- a/include/linux/cpuacct.h
+++ b/include/linux/cpuacct.h
@@ -31,7 +31,9 @@ struct cpuacct_charge_calls {
*/
void (*init) (void **cpuacct_data);
void (*charge) (void *cpuacct_data, u64 cputime, unsigned int cpu);
- void (*show) (void *cpuacct_data, struct cgroup_map_cb *cb);
+ void (*cpufreq_show) (void *cpuacct_data, struct cgroup_map_cb *cb);
+ /* Returns power consumed in milliWatt seconds */
+ u64 (*power_usage) (void *cpuacct_data);
};
int cpuacct_charge_register(struct cpuacct_charge_calls *fn);
diff --git a/kernel/cgroup_cpuaccount.c b/kernel/cgroup_cpuaccount.c
index 11799a7..d9bf889 100644
--- a/kernel/cgroup_cpuaccount.c
+++ b/kernel/cgroup_cpuaccount.c
@@ -226,12 +226,28 @@ static int cpuacct_cpufreq_show(struct cgroup *cgrp,
struct cftype *cft,
struct cgroup_map_cb *cb)
{
struct cpuacct *ca = cgroup_ca(cgrp);
- if (ca-cpufreq_fn ca-cpufreq_fn-show)
- ca-cpufreq_fn-show(ca-cpuacct_data, cb);
+ if (ca-cpufreq_fn ca-cpufreq_fn-cpufreq_show)
+ ca-cpufreq_fn-cpufreq_show(ca-cpuacct_data, cb);
return 0;
}
+/* return total cpu power usage (milliWatt second) of a group */
+static u64 cpuacct_powerusage_read(struct cgroup *cgrp, struct cftype *cft)
+{
+ int i;
+ struct cpuacct *ca = cgroup_ca(cgrp);
+ u64 totalpower = 0;
+
+ if (ca-cpufreq_fn ca-cpufreq_fn-power_usage)
+ for_each_present_cpu(i) {
+ totalpower += ca-cpufreq_fn-power_usage(
+ ca-cpuacct_data);
+ }
+
+ return totalpower;
+}
+
static struct cftype files[] = {
{
.name = usage,
@@ -250,6 +266,10 @@ static struct cftype files[] = {
.name = cpufreq,
.read_map = cpuacct_cpufreq_show,
},
+ {
+ .name = power,
+ .read_u64 = cpuacct_powerusage_read
+ },
};
static int cpuacct_populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
--
1.7.0.1
--
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 v2 3/3] omap: cpu: Implement callbacks for cpu frequency tracking in cpuacct
Implement OMAP platform specific scheduler callbacks for tracking
cpu frequencies per cpuacct cgroup.
Signed-off-by: Mike Chan m...@android.com
---
arch/arm/plat-omap/cpu-omap.c | 67 -
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 6d3d333..176417a 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -21,6 +21,8 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/slab.h
+#include linux/cpuacct.h
#include mach/hardware.h
#include plat/clock.h
@@ -38,6 +40,10 @@ static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
+#ifdef CONFIG_CGROUP_CPUACCT
+static int freq_index;
+#endif
+
/* TODO: Add support for SDRAM timing changes */
int omap_verify_speed(struct cpufreq_policy *policy)
@@ -96,6 +102,11 @@ static int omap_target(struct cpufreq_policy *policy,
freqs.old, freqs.new);
#endif
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
+#ifdef CONFIG_CGROUP_CPUACCT
+ /* Update freq_index before cpufreq transition post notification. */
+ cpufreq_frequency_table_target(policy, freq_table, freqs.new,
+ CPUFREQ_RELATION_L, freq_index);
+#endif
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
return ret;
@@ -125,7 +136,14 @@ static int __init omap_cpu_init(struct cpufreq_policy
*policy)
policy-cpuinfo.max_freq = clk_round_rate(mpu_clk,
VERY_HI_RATE) / 1000;
}
-
+#ifdef CONFIG_CGROUP_CPUACCT
+ /*
+* Update freq_index, since we are using the extact frequency
+* we can use any relation.
+*/
+ cpufreq_frequency_table_target(policy, freq_table, policy-cur,
+ CPUFREQ_RELATION_L, freq_index);
+#endif
/* FIXME: what's the actual transition time? */
policy-cpuinfo.transition_latency = 300 * 1000;
@@ -169,3 +187,50 @@ arch_initcall(omap_cpufreq_init);
* cpufreq_frequency_table_put_attr()
*/
+#ifdef CONFIG_CGROUP_CPUACCT
+/*
+ * Omap platform calls for cpuacct frequency accounting.
+ */
+
+static void omap_cpuacct_freq_init(void **cpuacct_data)
+{
+ /* MAX_VDD1_OPP is gone, define a table size to fit available values */
+ *cpuacct_data = kzalloc(sizeof(u64) * 8, GFP_KERNEL);
+}
+
+/* Called with rcu_read_lock() held. */
+static void omap_cpuacct_freq_charge(void *cpuacct_data, u64 cputime, unsigned
int cpu)
+{
+ u64 *cpuacct_freq = cpuacct_data;
+ if (freq_index 0)
+ return;
+
+ cpuacct_freq[freq_index] += cputime;
+}
+
+static void omap_cpuacct_freq_show(void *cpuacct_data, struct cgroup_map_cb
*cb)
+{
+ int i;
+ char buf[32];
+ u64 *cpuacct_freq = cpuacct_data;
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+ snprintf(buf, sizeof(buf), %u, freq_table[i].frequency);
+ cb-fill(cb, buf, cpuacct_freq[i]);
+ }
+}
+
+static struct cpuacct_charge_calls omap_cpuacct_cpufreq = {
+ .init = omap_cpuacct_freq_init,
+ .charge = omap_cpuacct_freq_charge,
+ .cpufreq_show = omap_cpuacct_freq_show,
+};
+
+static int __init omap_cpuacct_init(void)
+{
+ freq_index = -1;
+ cpuacct_charge_register(omap_cpuacct_cpufreq);
+ return 0;
+}
+
+early_initcall(omap_cpuacct_init);
+#endif
--
1.7.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, May 20, 2010 at 10:40:17AM -0700, David Brownell wrote: Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to hey come on, there's no judgement call for an app polling every second to check battery status or some other status that doesn't change that frequently. I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... that's my feeling too. I don't see any needs for suspend blockers in any real system. I acknowledge we need tools probing power consumption to be shipped to production device, that's a good idea, but forcing apps to modify just to have that UI fill up some treeview, I think it's a bit too much. -- balbi -- 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/6] teach gpiolib about gpio debouncing
On Thu, May 20, 2010 at 11:04:31AM -0700, Andrew Morton wrote: On Mon, 17 May 2010 13:02:29 +0300 felipe.ba...@nokia.com wrote: From: Felipe Balbi felipe.ba...@nokia.com Hi all, I'm resending this series since no-one has had any further comments for quite some time. Adding Andrew Morton to the loop also since David Brownell didn't pick the patch neither comment to any version of it. David's been very quiet lately - please always cc me on gpio patches. When were these first sent? Has there been any feedback or external testing? I'm not seeing anything in the changelogs which helps me to understand how important this feature is and it's rather late to be merging 2.6.35 feature work.. I guess we could leave it to 2.6.36 since OMAP is currently the only user and we have our own omap-specific ways of setting debounce time on gpios. That would also give people more time to complain if they think the api should change somehow. -- balbi -- 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/5] gpiolib: introduce set_debounce method
+EXPORT_SYMBOL_GPL(gpio_set_debounce); nitlet: I suspect this function is taking gpio_lock sooner than it strictly needs to. Find-tuning that would decrease contention by an insignificant amount ;) We need this for Intel MID boxes as well Andrew - so its a generic need. Alan -- 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/5] gpiolib: introduce set_debounce method
On Thu, 20 May 2010 20:04:17 +0100 Alan Cox a...@lxorguk.ukuu.org.uk wrote: +EXPORT_SYMBOL_GPL(gpio_set_debounce); nitlet: I suspect this function is taking gpio_lock sooner than it strictly needs to. Find-tuning that would decrease contention by an insignificant amount ;) We need this for Intel MID boxes as well Andrew - so its a generic need. Thanks. I'm still wobbling on the 35-vs-36 line. Is that a big need or a little need? What user-visible problem does it solve, etc? Did anyone test it on the MID boxes? etc ;) -- 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/5] gpiolib: introduce set_debounce method
On Mon, May 17, 2010 at 01:02:30PM +0300, felipe.ba...@nokia.com wrote: From: Felipe Balbi felipe.ba...@nokia.com Few architectures, like OMAP, allow you to set a debouncing time for the gpio before generating the IRQ. Teach gpiolib about that. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com This would be generally useful for embedded systems, especially where the interrupt concerned is a wake source. It allows drivers to avoid spurious interrupts from noisy sources so if the hardware supports it the driver can avoid having to explicitly wait for the signal to become stable and software has to cope with fewer events. We've lived without it for quite some time, though. -- 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 v2 0/3] Enable CPU frequency and power tracking in cpuacct cgroup
Hi Mike, On Thursday 20 May 2010 08:42:21 pm Mike Chan wrote: v2: Rebased off of Thomas Renninger's patch for cgroups_cpuacct refactoring, thanks. A general comment: I don't know much about the cgroup stuff. I am also not sure how exactly power can be measured on this arch based on frequency accounting (there also were some threads I was not aware of?) A signed-off-by or reviewed-by from someone who is more involved in this omap stuff would probably not that bad. Still I Iike this interface and I could imagine others hook into it as well, for whatever has to be cpu cgroup accounted. My two cents..., Thomas -- 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][v2] omap:iommu-enable TLB miss interrupt
The current iommu module doesn't provide the mechanism to get MMU fault on TLB miss when working with locked TLB entries and TWL disabled. To get the TLB miss interrupt, the TWL should be disabled. This patch set provides the option to enable/disable TWL and to enable TLB miss interrupt. Based on Hiroshi, the initial patch set was revised to add more flexibility to enable TWL. Hari Kanigeri (2): omap: iommu-update irq mask to be specific about twl and tlb omap: iommu-add functionality to get TLB miss interrupt arch/arm/mach-omap2/iommu2.c| 36 --- arch/arm/plat-omap/include/plat/iommu.h |2 + arch/arm/plat-omap/iommu.c | 17 ++ 3 files changed, 47 insertions(+), 8 deletions(-) -- 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] omap: iommu-add functionality to get TLB miss interrupt
In order to enable TLB miss interrupt, the TWL should be
disabled. This patch provides the functionality to get the
MMU fault interrupt for a TLB miss in the cases where the
users are working with the locked TLB entries and with TWL
disabled.
New interface is added to select twl and to enable TLB miss
interrupt.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ramesh Gupta grgu...@ti.com
Signed-off-by: Hiroshi Doyu hiroshi.d...@nokia.com
---
arch/arm/mach-omap2/iommu2.c| 26 +-
arch/arm/plat-omap/include/plat/iommu.h |2 ++
arch/arm/plat-omap/iommu.c | 17 +
3 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index ebbdae2..3cfe1c4 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -65,6 +65,25 @@
((pgsz) == MMU_CAM_PGSZ_64K) ? 0x :\
((pgsz) == MMU_CAM_PGSZ_4K) ? 0xf000 : 0)
+
+static void omap2_iommu_set_twl(struct iommu *obj, bool on)
+{
+ u32 l = iommu_read_reg(obj, MMU_CNTL);
+
+ if (on)
+ iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ else
+ iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+
+ l = ~MMU_CNTL_MASK;
+ if (on)
+ l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
+ else
+ l |= (MMU_CNTL_MMU_EN);
+
+ iommu_write_reg(obj, l, MMU_CNTL);
+}
+
static int omap2_iommu_enable(struct iommu *obj)
{
u32 l, pa;
@@ -100,13 +119,9 @@ static int omap2_iommu_enable(struct iommu *obj)
l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
iommu_write_reg(obj, l, MMU_SYSCONFIG);
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
iommu_write_reg(obj, pa, MMU_TTB);
- l = iommu_read_reg(obj, MMU_CNTL);
- l = ~MMU_CNTL_MASK;
- l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
- iommu_write_reg(obj, l, MMU_CNTL);
+ omap2_iommu_set_twl(obj, true);
return 0;
}
@@ -304,6 +319,7 @@ static const struct iommu_functions omap2_iommu_ops = {
.enable = omap2_iommu_enable,
.disable= omap2_iommu_disable,
+ .set_twl= omap2_iommu_set_twl,
.fault_isr = omap2_iommu_fault_isr,
.tlb_read_cr= omap2_tlb_read_cr,
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0752af9..33c7d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -80,6 +80,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
+ void (*set_twl)(struct iommu *obj, bool on);
u32 (*fault_isr)(struct iommu *obj, u32 *ra);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -143,6 +144,7 @@ extern void iotlb_cr_to_e(struct cr_regs *cr, struct
iotlb_entry *e);
extern u32 iotlb_cr_to_virt(struct cr_regs *cr);
extern int load_iotlb_entry(struct iommu *obj, struct iotlb_entry *e);
+extern void iommu_set_twl(struct iommu *obj, bool on);
extern void flush_iotlb_page(struct iommu *obj, u32 da);
extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end);
extern void flush_iotlb_all(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b2b3937..aa064e1 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -370,6 +370,23 @@ void flush_iotlb_all(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(flush_iotlb_all);
+/**
+ * iommu_set_twl - enable/disable table walking logic
+ * @obj: target iommu
+ * @on:enable/disable
+ *
+ * Function used to enable/disable TWL. If one wants to work
+ * exclusively with locked TLB entries and receive notifications
+ * for TLB miss then call this function to disable TWL.
+ */
+void iommu_set_twl(struct iommu *obj, bool on)
+{
+ clk_enable(obj-clk);
+ arch_iommu-set_twl(obj, on);
+ clk_disable(obj-clk);
+}
+EXPORT_SYMBOL_GPL(iommu_set_twl);
+
#if defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
ssize_t iommu_dump_ctx(struct iommu *obj, char *buf, ssize_t bytes)
--
1.7.0
--
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] omap: iommu-update irq mask to be specific about twl and tlb
Revise the IRQ mask definitions to handle the MMU faults related to TWL fault as well as TLB miss fault. Signed-off-by: Hari Kanigeri h-kanige...@ti.com Signed-off-by: Hiroshi Doyu hiroshi.d...@nokia.com --- arch/arm/mach-omap2/iommu2.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c index e82da68..ebbdae2 100644 --- a/arch/arm/mach-omap2/iommu2.c +++ b/arch/arm/mach-omap2/iommu2.c @@ -44,9 +44,13 @@ #define MMU_IRQ_EMUMISS(1 2) #define MMU_IRQ_TRANSLATIONFAULT (1 1) #define MMU_IRQ_TLBMISS(1 0) -#define MMU_IRQ_MASK \ - (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_EMUMISS | \ -MMU_IRQ_TRANSLATIONFAULT) + +#define __MMU_IRQ_FAULT\ + (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_EMUMISS | MMU_IRQ_TRANSLATIONFAULT) +#define MMU_IRQ_MASK \ + (__MMU_IRQ_FAULT | MMU_IRQ_TABLEWALKFAULT | MMU_IRQ_TLBMISS) +#define MMU_IRQ_TWL_MASK (__MMU_IRQ_FAULT | MMU_IRQ_TABLEWALKFAULT) +#define MMU_IRQ_TLB_MISS_MASK (__MMU_IRQ_FAULT | MMU_IRQ_TLBMISS) /* MMU_CNTL */ #define MMU_CNTL_SHIFT 1 @@ -96,7 +100,7 @@ static int omap2_iommu_enable(struct iommu *obj) l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE); iommu_write_reg(obj, l, MMU_SYSCONFIG); - iommu_write_reg(obj, MMU_IRQ_MASK, MMU_IRQENABLE); + iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE); iommu_write_reg(obj, pa, MMU_TTB); l = iommu_read_reg(obj, MMU_CNTL); -- 1.7.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues
Hi Felipe, On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Also, I noticed an important problem. Your code assumes that we would always have a bunch of scattered pages, Just a small note: the pages can be contiguous even in normal memory allocation (not with framebuffer). That's perfectly ok and there's no problem with that in the code. however you are not taking into account bridge_brd_mem_map() where vm_flags have VM_IO... in that case get_user_pages() is skipped completely. This code-path is important in order to mmap framebuffer memory, which is contiguous. So, in this case there are no pages too keep track at all. I gave some thought to this, and I concluded that nothing needs to be changed in the patches for this scenario. You see, in this case, as you said, no pages were pinned in memory using get_user_pages. This is perfectly fine since the MM application writes to a physical writecombine framebuffer memory which is not cached or swapped out. If the MM application will try to begin a DMA operation on this memory it will immediately fail because no related mapping will be found. This should actually be the expected behavior in such case: there really isn't a mapping to this buffer since there's no point to have it in VM_IO memory, and applications should not even try to flush/inv such memory: it's just redundant. IOW, the support for this scenario is actually to have no support : just return an error, which is what already happens. 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 v2 0/3] Enable CPU frequency and power tracking in cpuacct cgroup
On Thu, May 20, 2010 at 2:01 PM, Thomas Renninger tr...@suse.de wrote: Hi Mike, On Thursday 20 May 2010 08:42:21 pm Mike Chan wrote: v2: Rebased off of Thomas Renninger's patch for cgroups_cpuacct refactoring, thanks. A general comment: I don't know much about the cgroup stuff. Perhaps Paul Menage or Balbir Singh can look and sign off on the API's? I am also not sure how exactly power can be measured on this arch based on If you know how much time was spent at each frequency executing code, you can calculate how much power was consumed if the platform (with hooks) provide power numbers (in milliWatts) for the power at frequency X. I did some initial testing on Motorola Droid comparing to a power meter and I got within 2% variance. frequency accounting (there also were some threads I was not aware of?) A signed-off-by or reviewed-by from someone who is more involved in this omap stuff would probably not that bad. OMAP was the closest with mainline support I could provide an example how to use these hooks. I'm hoping for some blessing from some people on the linux-omap list for that. However can we possibly just stack the first two patches to get the API in? This will make it easier to fixup the omap hooks if they don't get in. -- Mike Still I Iike this interface and I could imagine others hook into it as well, for whatever has to be cpu cgroup accounted. My two cents..., Thomas -- To unsubscribe from this list: send the line unsubscribe cpufreq in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
Future of resource framework?
I'm not sure if this has been discussed, yet but since it seems that the resource framework will not be making it upstream, I am curious what are the replacements under consideration. I am starting to see similar issues on other platforms (msm / tegra) so more generic (non-omap) solution might be something to consider. -- Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gpiolib: introduce set_debounce method
This would be generally useful for embedded systems, especially where the interrupt concerned is a wake source. It allows drivers to avoid spurious interrupts from noisy sources so if the hardware supports it the driver can avoid having to explicitly wait for the signal to become stable and software has to cope with fewer events. True. Not all GPIOs have hardware debounce though, so offering this capability sort of begs the question of where/how to provide a software debounce mechanism too... We've lived without it for quite some time, though. I looked at adding debounce support to the generic GPIO calls (and thus gpiolib) some time back, but decided against it. I forget why at this time (check list archives) but it wasn't because of lack of utility in certain contexts. One thing to watch out for is just how variable the hardware capabilities are. Atmel GPIOs have something like a fixed number of 32K clock cycles for debounce, twl4030 had something odd, OMAPs were more like the Atmel chips but with a different clock. In some cases debouncing had to be ganged, not per-GPIO. And so forth. - 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
Re: [PATCH] mfd: twl5031: Rename sih modules
Hi Ilkka,
On Thu, May 20, 2010 at 01:04:20PM +0300, Ilkka Koskinen wrote:
Fix the names of twl5031 specific sih modules to match
the documentation.
Patch applied, thanks.
Cheers,
Samuel.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
drivers/mfd/twl4030-irq.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 202bdd5..097f24d 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -232,10 +232,11 @@ static const struct sih sih_modules_twl5031[8] = {
},
[6] = {
/*
- * ACI doesn't use the same SIH organization.
- * For example, it supports only one interrupt line
+ * ECI/DBI doesn't use the same SIH organization.
+ * For example, it supports only one interrupt output line.
+ * That is, the interrupts are seen on both INT1 and INT2 lines.
*/
- .name = aci,
+ .name = eci_dbi,
.module = TWL5031_MODULE_ACCESSORY,
.bits = 9,
.bytes_ixr = 2,
@@ -247,8 +248,8 @@ static const struct sih sih_modules_twl5031[8] = {
},
[7] = {
- /* Accessory */
- .name = acc,
+ /* Audio accessory */
+ .name = audio,
.module = TWL5031_MODULE_ACCESSORY,
.control_offset = TWL5031_ACCSIHCTRL,
.bits = 2,
--
1.6.0.4
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
-0700, David Brownell wrote: Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to hey come on, there's no judgement call for an app polling every second to check battery status or some other status that doesn't change that frequently. Or something as broken as a non-terminating CPU loop ... Of course not. But if there's a kernel mechanism exposed to userspace which really sucks down power ... either it's done correctly and the problem is userspace abusing it, or it's done wrong so that it's not possible to be used correctly. There are some things that just cost power, and that cost can't be escaped. -- 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: Future of resource framework?
Mike Chan had written, on 05/20/2010 05:37 PM, the following: I'm not sure if this has been discussed, yet but since it seems that the resource framework will not be making it upstream, I am curious http://marc.info/?l=linux-omapm=127206504624556w=2 (we are getting to the one month expiry date btw..) what are the replacements under consideration. I am starting to see similar issues on other platforms (msm / tegra) so more generic (non-omap) solution might be something to consider. I know of one by Sanjeev Premi: [1] http://marc.info/?l=linux-omapm=125716806431649w=2 it should be rather trivial to adapt it to opp layer and make it work. -- Regards, Nishanth Menon -- 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
collaboration on hwmod conversions and runtime PM
Hello, There has been quite a bit of activity on the hwmod front, but no common place to combine patches for testing. To that end, I've update the pm-wip/hwmods branch in my tree to the two fixes/cleanup series from Benoit (which will be merged via for 2.6.35): [PATCH 00/10] OMAP: HWMOD fixes and cleanup [PATCH 0/5] OMAP4: PRCM: Spring cleanup On top of this, there is the pm-wip/hwmods-omap4 branch which includes the OMAP4 series from Benoit [PATCH 0/6] OMAP: hwmod: Full data set for OMAP4430 ES1.0 so that conversions for OMAP4 can also be done and tested. Note that I've reverted the two temporary patches in this series since they cause problems on OMAP3, On top of this, there is the pm-wip/runtime branch which includes the base runtime PM implementation for OMAP. On top of this there are work-in-progress branches for the conversions for UART (pm-wip/uart) and MMC (pm-wip/mmc) 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
[PATCH] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2fff39f..a127c9b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -939,7 +939,13 @@ static int _enable(struct omap_hwmod *oh)
*/
static int _idle(struct omap_hwmod *oh)
{
- if (oh-_state != _HWMOD_STATE_ENABLED) {
+ /*
+* To idle, hwmod must be enabled, EXCEPT if hwmod was
+* initialized using the INIT_NO_IDLE flag. In this case it
+* will not yet be enabled so we have to allow it to be idled.
+*/
+ if ((oh-_state != _HWMOD_STATE_ENABLED)
+ !(oh-flags HWMOD_INIT_NO_IDLE)) {
WARN(1, omap_hwmod: %s: idle state can only be entered from
enabled state\n, oh-name);
return -EINVAL;
@@ -954,6 +960,9 @@ static int _idle(struct omap_hwmod *oh)
oh-_state = _HWMOD_STATE_IDLE;
+ /* Clear init flag which should only affect first call to idle */
+ oh-flags = ~HWMOD_INIT_NO_IDLE;
+
return 0;
}
--
1.7.0.2
--
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
