Re: [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings
On 12/05/2011 05:46 PM, Mark Brown wrote: And what I'm saying is that my main concern is that you're publishing documenting a binding which isn't intended to be the the final binding and which there's no intention that anyone should use directly anyway. I felt it is the right thing to document the current situation. The documentation will be updated as we can move away from the ti,hwmods tag from DT. I can place comment in the documentation for omap-dmic, omap-mcpdm stating that the use of ti,hwmods is required at the moment, but it is temporally solution. -- Péter -- 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: [PATCHv7 3/7] omap3: voltage: fix channel configuration
On Mon, 2011-12-05 at 12:23 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: On Fri, 2011-12-02 at 15:55 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: OMAP3 uses the default settings for VDD1 channel, otherwise the settings will overlap with VDD2 and attempting to modify VDD1 voltage will actually change VDD2 voltage. Signed-off-by: Tero Kristo t-kri...@ti.com I've forgotten a bit how this was supposed to work (again), Can you elaborate more on how this fails? There is a diagram in the OMAP TRM for setting the bits in this register, however the racen fix part appears to be needed only for omap4. I can drop this part of the fix from the series if you want for the next version, alternatively I can split this patch into two. A separate patch, with a descriptive changelog would be preferred. The idea for this part of the fix is anyway that the channel configuration is more complex in omap4, we define volt_reg and cmd_reg addresses for each omap4_X_pmic, however we only want to enable racen bit only if cmd and volt register addresses are the same. This part still doesn't make sense to me. If the volt register address (RA_VOL in OMAP4 terms) and command register address (RA_CMD) are the same, then RACEN shouldn't matter, since either way the commands go the same address. My understanding of RACEN is that it is only for the case where RA_VOL and RA_CMD are different, so you can select between them. I am not sure if you got the polarity of the bit right. RACEN should be enabled only if the register addresses are the same. My understanding is that: if command register is defined = RAC=1, if voltage register is defined = RAV=1. If VFSM should use voltage register address for sending voltage commands = RACEN=1, otherwise it will use command register address. The current code assumes that if you pass in command register address you plan to use it. If it isn't being used (RACEN == 0) then the PMIC setup should probably not pass in a separate command register address. What am I missing (or mis-reading in the TRM) here? The register addresses defined in omap_twl for omap4 pmics are different, and this is causing trouble at the moment if RACEN is enabled, as VFSM commands will end up going to voltage register address. One could probably also argue that the register addresses for these should be the same... The documentation for this part of the chip is rather bad anyway. Added Nishanth to CC as he might have some comments on this also. -Tero -- 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: [regression] Re: [PATCH 3/7] mfd: twl4030-irq: drop the kthread
On Wed, Dec 7, 2011 at 8:51 AM, Felipe Balbi ba...@ti.com wrote: On Tue, Dec 06, 2011 at 05:28:58PM +0200, Felipe Contreras wrote: On Thu, Jun 30, 2011 at 12:51 PM, Felipe Balbi ba...@ti.com wrote: ... and use threaded IRQ infrastructure. Later patches will come dropping both workqueues and setting the nested thread flag. There's something wrong. When I boot my Nokia N900 with this, as soon as I press a key from the keyboard the whole device hangs. I don't see anything on the console framebuffer, and with a jig I can't boot from MMC, so there isn't much more I can provide at the moment. Funny, this booted fine on my beagle and MMC card uses a twl GPIO for card detection. Maybe it's something fairly obvious that I missed :-( Did you try typing anything? That's where the problem happened on my side. I'll try to flash a system to NAND, since I can't seem to just get the MMC to work when the cover is open and the device is connected to the jig to see if I can see something from serial console. You don't have any idea about what to try? -- Felipe Contreras -- 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: [regression] Re: [PATCH 3/7] mfd: twl4030-irq: drop the kthread
On Wed, 7 Dec 2011 13:04:03 +0200 Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Dec 7, 2011 at 8:51 AM, Felipe Balbi ba...@ti.com wrote: On Tue, Dec 06, 2011 at 05:28:58PM +0200, Felipe Contreras wrote: On Thu, Jun 30, 2011 at 12:51 PM, Felipe Balbi ba...@ti.com wrote: ... and use threaded IRQ infrastructure. Later patches will come dropping both workqueues and setting the nested thread flag. There's something wrong. When I boot my Nokia N900 with this, as soon as I press a key from the keyboard the whole device hangs. I don't see anything on the console framebuffer, and with a jig I can't boot from MMC, so there isn't much more I can provide at the moment. Funny, this booted fine on my beagle and MMC card uses a twl GPIO for card detection. Maybe it's something fairly obvious that I missed :-( Did you try typing anything? That's where the problem happened on my side. I'll try to flash a system to NAND, since I can't seem to just get the MMC to work when the cover is open and the device is connected to the jig to see if I can see something from serial console. You don't have any idea about what to try? Try the patches I posted to linux-kernel on Nov 27: Subject: [PATCH 0/4] fixes for twl4030-irq in mainline and following http://lkml.org/lkml/2011/11/26/92 I think I hit exactly the same bug and you and (eventually) fix it (that was a fun learning experience). NeilBrown signature.asc Description: PGP signature
Re: [PATCH 2/2] Revert ARM: RX-51: Enable isp1704 power on/off
On 12/05/2011 07:31 PM, Felipe Contreras wrote: Should probably have CC'ed linux-omap. On Mon, Dec 5, 2011 at 7:23 PM, Felipe Contreras felipe.contre...@nokia.com wrote: From: Felipe Contrerasfelipe.contre...@gmail.com This reverts commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2. This seems to break USB networking stuff. I don't think revert is needed since CONFIG_CHARGER_ISP1704=y should make it working. Although I don't know do we really need to drive the ISP1704 into reset in board-rx51-peripherals.c? Would it be better to leave gpio state as it was set by the bootloader and let the driver to do reset sequence if needed? http://marc.info/?l=linux-omapm=130795363204884w=2 -- 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 63/65] OMAPDSS: APPLY: add checking of ovls/mgrs settings
Hi,
On Tuesday 22 November 2011 02:52 PM, Tomi Valkeinen wrote:
Add checks for overlay and manager settings. The checks are a bit
complex, as we need to observe the bigger picture instead of overlays
and managers independently. Things like the used display and the zorder
of other overlays affect the validity of the settings.
Minor comment:
dss_ovl_check, dss_mgr_check and dss_mgr_check_zorder don't really
qualify as functions which do actual applying of configurations, they
could be moved from apply.c to manager.c and overlay.c.
Archit
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
drivers/video/omap2/dss/apply.c | 215 ++-
1 files changed, 212 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 5d933b9..72afa85 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -166,6 +166,169 @@ static bool mgr_manual_update(struct omap_overlay_manager
*mgr)
return mgr-device-caps OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
}
+/* Check if overlay parameters are compatible with display */
+static int dss_ovl_check(struct omap_overlay *ovl,
+ struct omap_overlay_info *info, struct omap_dss_device *dssdev)
+{
+ u16 outw, outh;
+ u16 dw, dh;
+
+ if (dssdev == NULL)
+ return 0;
+
+ dssdev-driver-get_resolution(dssdev,dw,dh);
+
+ if ((ovl-caps OMAP_DSS_OVL_CAP_SCALE) == 0) {
+ outw = info-width;
+ outh = info-height;
+ } else {
+ if (info-out_width == 0)
+ outw = info-width;
+ else
+ outw = info-out_width;
+
+ if (info-out_height == 0)
+ outh = info-height;
+ else
+ outh = info-out_height;
+ }
+
+ if (dw info-pos_x + outw) {
+ DSSERR(overlay %d horizontally not inside the display area
+ (%d + %d= %d)\n,
+ ovl-id, info-pos_x, outw, dw);
+ return -EINVAL;
+ }
+
+ if (dh info-pos_y + outh) {
+ DSSERR(overlay %d vertically not inside the display area
+ (%d + %d= %d)\n,
+ ovl-id, info-pos_y, outh, dh);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int dss_mgr_check_zorder(struct omap_overlay_manager *mgr,
+ struct omap_overlay_info **overlay_infos)
+{
+ struct omap_overlay *ovl1, *ovl2;
+ struct ovl_priv_data *op1, *op2;
+ struct omap_overlay_info *info1, *info2;
+
+ list_for_each_entry(ovl1,mgr-overlays, list) {
+ op1 = get_ovl_priv(ovl1);
+ info1 = overlay_infos[ovl1-id];
+
+ if (info1 == NULL)
+ continue;
+
+ list_for_each_entry(ovl2,mgr-overlays, list) {
+ if (ovl1 == ovl2)
+ continue;
+
+ op2 = get_ovl_priv(ovl2);
+ info2 = overlay_infos[ovl2-id];
+
+ if (info2 == NULL)
+ continue;
+
+ if (info1-zorder == info2-zorder) {
+ DSSERR(overlays %d and %d have the same
+ zorder %d\n,
+ ovl1-id, ovl2-id, info1-zorder);
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int dss_mgr_check(struct omap_overlay_manager *mgr,
+ struct omap_dss_device *dssdev,
+ struct omap_overlay_manager_info *info,
+ struct omap_overlay_info **overlay_infos)
+{
+ struct omap_overlay *ovl;
+ int r;
+
+ if (dss_has_feature(FEAT_ALPHA_FREE_ZORDER)) {
+ r = dss_mgr_check_zorder(mgr, overlay_infos);
+ if (r)
+ return r;
+ }
+
+ list_for_each_entry(ovl,mgr-overlays, list) {
+ struct omap_overlay_info *oi;
+ int r;
+
+ oi = overlay_infos[ovl-id];
+
+ if (oi == NULL)
+ continue;
+
+ r = dss_ovl_check(ovl, oi, dssdev);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+static int dss_check_settings_low(struct omap_overlay_manager *mgr,
+ struct omap_dss_device *dssdev, bool applying)
+{
+ struct omap_overlay_info *oi;
+ struct omap_overlay_manager_info *mi;
+ struct omap_overlay *ovl;
+ struct omap_overlay_info *ois[MAX_DSS_OVERLAYS];
+ struct ovl_priv_data *op;
+ struct mgr_priv_data *mp;
+
+ mp = get_mgr_priv(mgr);
+
+ if (applying mp-user_info_dirty)
+
Re: [PATCH 58/65] OMAPDSS: APPLY: add wait_pending_extra_info_updates()
On Tuesday 22 November 2011 02:51 PM, Tomi Valkeinen wrote:
Add wait_pending_extra_info_updates() function which can be used to wait
until any extra_info changes have been taken into use by the hardware.
This can be only called when holding the apply mutex, so that other
threads cannot insert new extra_info changes.
This will be used to handle fifo-configurations.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
drivers/video/omap2/dss/apply.c | 70 +++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 76b5b02..75db522 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -106,6 +106,7 @@ static struct {
static spinlock_t data_lock;
/* lock for blocking functions */
static DEFINE_MUTEX(apply_lock);
+static DECLARE_COMPLETION(extra_updated_completion);
static void dss_register_vsync_isr(void);
@@ -232,6 +233,70 @@ static bool need_go(struct omap_overlay_manager *mgr)
return false;
}
+/* returns true if an extra_info field is currently being updated */
+static bool extra_info_update_ongoing(void)
+{
+ const int num_ovls = omap_dss_get_num_overlays();
+ struct ovl_priv_data *op;
+ struct omap_overlay *ovl;
+ struct mgr_priv_data *mp;
+ int i;
+ bool eid;
+
+ for (i = 0; i num_ovls; ++i) {
+ ovl = omap_dss_get_overlay(i);
+ op = get_ovl_priv(ovl);
+
+ if (!op-enabled)
+ continue;
+
+ mp = get_mgr_priv(ovl-manager);
+
+ if (!mp-enabled)
+ continue;
+
+ eid = op-extra_info_dirty || op-shadow_extra_info_dirty;
+
+ if (!eid)
+ continue;
+
+ if (ovl_manual_update(ovl) !mp-updating)
+ continue;
+
+ return true;
+ }
+
+ return false;
+}
+
+/* wait until no extra_info updates are pending */
+static void wait_pending_extra_info_updates(void)
+{
+ bool updating;
+ unsigned long flags;
+ unsigned long t;
+
+ spin_lock_irqsave(data_lock, flags);
+
+ updating = extra_info_update_ongoing();
+
+ if (!updating) {
+ spin_unlock_irqrestore(data_lock, flags);
+ return;
+ }
+
+ init_completion(extra_updated_completion);
+
+ spin_unlock_irqrestore(data_lock, flags);
+
+ t = msecs_to_jiffies(500);
+ wait_for_completion_timeout(extra_updated_completion, t);
+
+ updating = extra_info_update_ongoing();
+
+ WARN_ON(updating);
+}
This function isn't used, are you planning to use it later?
Archit
+
int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
{
unsigned long timeout = msecs_to_jiffies(500);
@@ -553,6 +618,7 @@ static void dss_apply_irq_handler(void *data, u32 mask)
{
const int num_mgrs = dss_feat_get_num_mgrs();
int i;
+ bool extra_updating;
spin_lock(data_lock);
@@ -582,6 +648,10 @@ static void dss_apply_irq_handler(void *data, u32 mask)
dss_write_regs();
+ extra_updating = extra_info_update_ongoing();
+ if (!extra_updating)
+ complete_all(extra_updated_completion);
+
if (!need_isr())
dss_unregister_vsync_isr();
--
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 58/65] OMAPDSS: APPLY: add wait_pending_extra_info_updates()
On Wed, 2011-12-07 at 18:37 +0530, Archit Taneja wrote:
On Tuesday 22 November 2011 02:51 PM, Tomi Valkeinen wrote:
+/* wait until no extra_info updates are pending */
+static void wait_pending_extra_info_updates(void)
+{
+ bool updating;
+ unsigned long flags;
+ unsigned long t;
+
+ spin_lock_irqsave(data_lock, flags);
+
+ updating = extra_info_update_ongoing();
+
+ if (!updating) {
+ spin_unlock_irqrestore(data_lock, flags);
+ return;
+ }
+
+ init_completion(extra_updated_completion);
+
+ spin_unlock_irqrestore(data_lock, flags);
+
+ t = msecs_to_jiffies(500);
+ wait_for_completion_timeout(extra_updated_completion, t);
+
+ updating = extra_info_update_ongoing();
+
+ WARN_ON(updating);
+}
This function isn't used, are you planning to use it later?
Yes, it's used with the fifo-merge stuff. It could be added later, but
as it's related to the extra_info stuff, I think it fits better here
than with the fifo merge series.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [regression] Re: [PATCH 3/7] mfd: twl4030-irq: drop the kthread
On Wed, Dec 07, 2011 at 01:04:03PM +0200, Felipe Contreras wrote: On Wed, Dec 7, 2011 at 8:51 AM, Felipe Balbi ba...@ti.com wrote: On Tue, Dec 06, 2011 at 05:28:58PM +0200, Felipe Contreras wrote: On Thu, Jun 30, 2011 at 12:51 PM, Felipe Balbi ba...@ti.com wrote: ... and use threaded IRQ infrastructure. Later patches will come dropping both workqueues and setting the nested thread flag. There's something wrong. When I boot my Nokia N900 with this, as soon as I press a key from the keyboard the whole device hangs. I don't see anything on the console framebuffer, and with a jig I can't boot from MMC, so there isn't much more I can provide at the moment. Funny, this booted fine on my beagle and MMC card uses a twl GPIO for card detection. Maybe it's something fairly obvious that I missed :-( Did you try typing anything? That's where the problem happened on my side. beagle doesn't have keyboard ;-) I'll try to flash a system to NAND, since I can't seem to just get the MMC to work when the cover is open and the device is connected to the jig to see if I can see something from serial console. You don't have any idea about what to try? you could cut the back cover so that it just fits the device on the jig (I did that to an old cover), then it works just fine :-) -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
Hi, On Wed, Dec 7, 2011 at 6:01 AM, Sylwester Nawrocki snj...@gmail.com wrote: On 12/06/2011 03:07 PM, Ming Lei wrote: Hi, Thanks for your review. On Tue, Dec 6, 2011 at 5:55 AM, Sylwester Nawrocki snj...@gmail.com wrote: Hi Ming, (I've pruned the Cc list, leaving just the mailing lists) On 12/02/2011 04:02 PM, Ming Lei wrote: This patch introduces one driver for face detection purpose. The driver is responsible for all v4l2 stuff, buffer management and other general things, and doesn't touch face detection hardware directly. Several interfaces are exported to low level drivers (such as the coming omap4 FD driver)which will communicate with face detection hw module. So the driver will make driving face detection hw modules more easy. I would hold on for a moment on implementing generic face detection module which is based on the V4L2 video device interface. We need to first define an API that would be also usable at sub-device interface level (http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html). If we can define a good/stable enough APIs between kernel and user space, I think the patches can be merged first. For internal kernel APIs, we should allow it to evolve as new hardware comes or new features are to be introduced. I also don't see a problem in discussing it a bit more;) OK, fair enough, let's discuss it, :-) I understand the API you mentioned here should belong to kernel internal API, correct me if it is wrong. Yes, I meant the in kernel design, i.e. generic face detection kernel module and an OMAP4 FDIF driver. It makes lots of sense to separate common code in this way, maybe even when there would be only OMAP devices using it. Yes, that is the motivation of the generic FD module. I think we can focus on two use cases for the generic FD now: - one is to detect faces from user space image data - another one is to detect faces in image data generated from HW(SoC internal bus, resize hardware) For OMAP4 hardware, input data is always from physically continuous memory directly, so it is very easy to support the two cases. For the use case 2, if buffer copy is to be avoided, we can use the coming shared dma-buf[1] to pass the image buffer produced by other HW to FD hw directly. For other FD hardware, if it supports to detect faces in image data from physically continuous memory, I think the patch is OK to support it. If the FD hw doesn't support to detect faces from physically continuous memory, I have some questions: how does user space app to parse the FD result if application can't get the input image data? If user space can get image data, how does it connect the image data with FD result? and what standard v4l2 ways(v4l2_buffer?) can the app use to describe the image data? I'm sure now the Samsung devices won't fit in video output node based driver design. They read image data in different ways and also the FD result format is totally different. I think user space will need the FD result, so it is very important to define API to describe the FD result format to user space. And the input about your FD HW result format is certainly helpful to define the API. AFAICS OMAP4 FDIF processes only data stored in memory, thus it seems reasonable to use the videodev interface for passing data to the kernel from user space. But there might be face detection devices that accept data from other H/W modules, e.g. transferred through SoC internal data buses between image processing pipeline blocks. Thus any new interfaces need to be designed with such devices in mind. Also the face detection hardware block might now have an input DMA engine in it, the data could be fed from memory through some other subsystem (e.g. resize/colour converter). Then the driver for that subsystem would implement a video node. I think the direct input image or frame data to FD should be from memory no matter the actual data is from external H/W modules or input DMA because FD will take lot of time to detect faces in one image or frame and FD can't have so much memory to cache several images or frames data. Sorry, I cannot provide much details at the moment, but there exists hardware that reads data from internal SoC buses and even if it uses some sort of cache memory it doesn't necessarily have to be available for the user. Without some hardware background, it is not easy to give a generic FD module design. Still the FD result is associated with an image frame for such H/W, but not necessarily with a memory buffer queued by a user application. For user space application, it doesn't make sense to handle FD results only without image data. Even though there are other ways of input image data to FD, user space still need to know the image data, so it makes sense to associate FD result with a memory buffer. How long it approximately takes to process single image for OMAP4 FDIF ? See the link[2], and my test result is basically consistent with the
Re: [regression] Re: [PATCH 3/7] mfd: twl4030-irq: drop the kthread
On 12/07/2011 03:39 PM, Felipe Balbi wrote: I'll try to flash a system to NAND, since I can't seem to just get the MMC to work when the cover is open and the device is connected to the jig to see if I can see something from serial console. You don't have any idea about what to try? you could cut the back cover so that it just fits the device on the jig (I did that to an old cover), then it works just fine :-) You could also go without breaking the back cover by putting a magnet on top the hal sensor (like tape a piece from a fridge magnet). See here the place: http://talk.maemo.org/showthread.php?p=1008775 Another option is to to set .gpio_cd = -EINVAL for external mmc in arch/arm/mach-omap2/board-rx51-peripherals.c. -- 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: [regression] Re: [PATCH 3/7] mfd: twl4030-irq: drop the kthread
On Wed, Dec 7, 2011 at 1:30 PM, NeilBrown ne...@suse.de wrote: Try the patches I posted to linux-kernel on Nov 27: Subject: [PATCH 0/4] fixes for twl4030-irq in mainline and following http://lkml.org/lkml/2011/11/26/92 I think I hit exactly the same bug and you and (eventually) fix it (that was a fun learning experience). Yeap, those patches fix the issue :) Cheers. -- Felipe Contreras -- 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/4] fixes for twl4030-irq in mainline
On Sat, Nov 26, 2011 at 10:17 PM, NeilBrown ne...@suse.de wrote: The recent tidying up of twl4030-irq seems to have left it broken. At least it doesn't work for me on my gta04 (www.gta04.org). The first interrupt from the device freezes the whole system (by being constantly delivered) The following 4 patches make it work for me and addresses some other less critical issues like a typo in a comment :-) I also hit the same issue on the N900. These patches fix the problem for me: Tested-by: Felipe Contreras felipe.contre...@gmail.com -- Felipe Contreras -- 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: [regression] Re: [PATCH 3/7] mfd: twl4030-irq: drop the kthread
On Wed, Dec 7, 2011 at 3:59 PM, Jarkko Nikula jarkko.nik...@bitmer.com wrote: On 12/07/2011 03:39 PM, Felipe Balbi wrote: I'll try to flash a system to NAND, since I can't seem to just get the MMC to work when the cover is open and the device is connected to the jig to see if I can see something from serial console. You don't have any idea about what to try? you could cut the back cover so that it just fits the device on the jig (I did that to an old cover), then it works just fine :-) You could also go without breaking the back cover by putting a magnet on top the hal sensor (like tape a piece from a fridge magnet). See here the place: http://talk.maemo.org/showthread.php?p=1008775 Another option is to to set .gpio_cd = -EINVAL for external mmc in arch/arm/mach-omap2/board-rx51-peripherals.c. Nice. That gpio_cd trick did it :) -- Felipe Contreras -- 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/7] Introducing a generic AMP framework
On Wed, Dec 7, 2011 at 12:09 AM, Saravana Kannan skan...@codeaurora.org wrote: Yes, I did realize it's not used in the code. I just wanted to prevent what I considered a misuse of AMP. Thanks for accommodating my request. Sure thing, and thanks for the feedback. Dropping the 'amp' prefix also went well with my gut feeling that remoteproc and rpmsg should again be made as independent top-level subsystems, just like they were in the first patch set submission; they're not really coupled, and putting them together under the 'amp' folder just confused people and somewhat convoluted development. I suspect that once the basic functionality will be merged, the development of remoteproc and rpmsg will become completely orthogonal and it would then make sense to start queueing patches separately, so I've created two trees for them: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git Though at this point splitting the patches into two separate trees will just make it harder for people to work with the code, so both trees currently have the entire patch-set (and some other wip stuff). I've also created a for-next branch which I'll send to Stephen, and then we could start doing linear development (there's a bunch of patches I'll post soon, including stuff that was reported-by Stephen earlier) - that will hopefully make it easier for people to use this code, but also to review patches. 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/RFC] ARM: OMAP: MUSB: disable omap_device auto-suspend
Felipe Balbi ba...@ti.com writes: Hi, On Mon, Nov 28, 2011 at 04:56:30PM -0800, Kevin Hilman wrote: The MUSB driver does not currently implment suspend/resume callbacks, this is not entirelly true, actually. Such methods are missing for omap2430 glue layer, not for MUSB itself. And the fact is that it's only missing because we failed to use UNIVERSAL_DEV_PM_OPS for declaring dev_pm_ops structure. I guess that also means that nobody has tested MUSB host suspend/resume with devices attached. Can you see if this patch helps: Sure. That patch makes sense, and seems necessary, but doesn't fix the problem. The root of the problem is that the PM domain code will call the driver's runtime PM methods late in the suspend if the device is not already runtime suspended. In your patch, you make the driver's suspend/resume methods call the runtime methods, but, the PM core doesn't know that that the device is now runtime suspended, so the OMAP PM domain code will still call the driver's runtime PM methods to try and suspend the device. In the case of this glue layer, the runtime PM methods call some PHY code which is trying to use I2C. When this happens late in the suspend process, I2C may already be suspended, so you get a bunch of I2C timeouts. 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
[GIT PULL] More omap1 boot regression fixes for v3.2-rc4
Hi Arnd Olof, Please pull omap1 fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes These are still needed to deal with breakage of moving reprogramming of the DPLL1 later on in commit a66cb3454f220f49f900646ebdc76cb943319eb7. That commit caused multiple issues for omap1 boards that did not have OMAP_CLOCKS_SET_BY_BOOTLOADER set. This series fixes issues for boards booting at less than 60MHz rate, at least Amstrad Delta is known to not work without this series. Regards, Tony The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416: Linus Torvalds (1): Linux 3.2-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Janusz Krzysztofik (3): ARM: OMAP1: Remove unsafe clock values from omap1_defconfig ARM: OMAP1: Fix ckctl value used for dpll1 defualt rate ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram Tony Lindgren (1): ARM: OMAP1: Fix reprogramming of DPLL1 for systems that boot at rates below 60MHz arch/arm/configs/omap1_defconfig |5 - arch/arm/mach-omap1/clock_data.c | 12 ++-- 2 files changed, 10 insertions(+), 7 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] omap: rx51: initialize isp1704 properly
From: Heikki Krogerus kro...@gmail.com
Without this USB networking doesn't work as the link is never detected.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index a1d0257..faac1fc 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -193,7 +193,7 @@ static struct platform_device rx51_charger_device = {
static void __init rx51_charger_init(void)
{
WARN_ON(gpio_request_one(RX51_USB_TRANSCEIVER_RST_GPIO,
- GPIOF_OUT_INIT_LOW, isp1704_reset));
+ GPIOF_OUT_INIT_HIGH, isp1704_reset));
platform_device_register(rx51_charger_device);
}
--
1.7.8.rc1.14.g248db
--
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/4] ARM: OMAP2+: Interrupt controllers adaptation to DT
Hi Tony and Rob, Here is the series to take advantage of the new DT interrupt init mechanism. Thanks to Mark's CONFIG_MULTI_IRQ_HANDLER series, OMAP4 just has to use the default GIC binding and does not need some OMAP specific hacks anymore. OMAP2 and 3 are using a simple interrupt controller that can thus expose a simpler binding. This series is based on rmk/devel-stable branch to get Mark's series + a couple of OMAP fixes. An extra fix is needed before for the board-generic.c file: [PATCH] ARM: OMAP2+: board-generic: Add missing handle_irq The series with all the dependencies merged is available here for reference: git://gitorious.org/omap-pm/linux.git for_3.3/2_dt_irq Regards, Benoit Benoit Cousson (4): arm/dts: OMAP4: Update DTS file with new GIC bindings ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 +++ arch/arm/boot/dts/omap3.dtsi |6 ++- arch/arm/boot/dts/omap4.dtsi |3 +- arch/arm/mach-omap2/board-generic.c| 30 + arch/arm/mach-omap2/common.h | 10 ++ arch/arm/mach-omap2/irq.c | 35 ++-- 6 files changed, 91 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt -- 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] arm/dts: OMAP4: Update DTS file with new GIC bindings
The GIC binding was updated in 3.2 and expect 3 interrupt-cells.
- Update the #interrupt-cells
- interrupt-parent seems to be needed as well for the top level GIC
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap4.dtsi |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..bede009 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,7 +95,8 @@
gic: interrupt-controller@48241000 {
compatible = arm,cortex-a9-gic;
interrupt-controller;
- #interrupt-cells = 1;
+ interrupt-parent;
+ #interrupt-cells = 3;
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
--
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 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/arm/omap/intc.txt | 27 +++
arch/arm/mach-omap2/common.h | 10 ++
arch/arm/mach-omap2/irq.c | 35 ++--
3 files changed, 69 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ ti,omap2-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap2-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..bcfccc2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -156,6 +156,16 @@ void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 42b1d65..cafc663 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -17,6 +17,9 @@
#include mach/hardware.h
#include asm/exception.h
#include asm/mach/irq.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/irqdomain.h
/* selected INTC register offsets */
@@ -166,7 +169,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank-base_reg = ioremap(base, SZ_4K);
if (!bank-base_reg) {
- printk(KERN_ERR Could not ioremap irq bank%i\n, i);
+ pr_err(Could not ioremap irq bank%i\n, i);
continue;
}
@@ -179,8 +182,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
nr_banks++;
}
- printk(KERN_INFO Total of %ld interrupts on %d active controller%s\n,
- nr_of_irqs, nr_banks, nr_banks 1 ? s : );
+ pr_info(Total of %ld interrupts on %d active controller%s\n,
+ nr_of_irqs, nr_banks, nr_banks 1 ? s : );
}
void __init omap2_init_irq(void)
@@ -236,6 +239,32 @@ asmlinkage void __exception_irq_entry
omap2_intc_handle_irq(struct pt_regs *regs
omap_intc_handle_irq(base_addr, regs);
}
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ struct resource res;
+ u32 nr_irqs;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, res)) {
+ WARN(1, unable to get intc registers\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, ti,intc-size, nr_irqs)) {
+ WARN(1, unable to get intc-size\n);
+ return -EINVAL;
+ }
+
+ omap_init_irq(res.start, nr_irqs);
+ irq_domain_add_simple(node, 0);
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
--
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 3/4] arm/dts: OMAP3: Add interrupt-controller bindings for INTC
Update the DTS with the proper information required by the
INTC bindings.
- Add the number of interrupt lines
- Add the reg and the compatible entries.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/boot/dts/omap3.dtsi |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..6866dc7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -54,10 +54,12 @@
ranges;
ti,hwmods = l3_main;
- intc: interrupt-controller@1 {
- compatible = ti,omap3-intc;
+ intc: interrupt-controller@4820 {
+ compatible = ti,omap2-intc;
interrupt-controller;
#interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
};
};
};
--
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 4/4] ARM: OMAP2+: board-generic: Use of_irq_init API
Use the of_irq_init API introduced in 3.2 to handle
interrupt-controller with DT.
Update the irq_match table to map the proper XXX_of_init
functions for INTC and GIC drivers.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring rob.herr...@calxeda.com
---
arch/arm/mach-omap2/board-generic.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a0e9595..16c301e 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -12,6 +12,7 @@
* published by the Free Software Foundation.
*/
#include linux/io.h
+#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
#include linux/i2c/twl.h
@@ -24,6 +25,17 @@
#include common.h
#include common-board-devices.h
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = ti,omap2-intc, .data = intc_of_init, },
+ { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+ { }
+};
+
+static void __init omap_init_irq(void)
+{
+ of_irq_init(irq_match);
+}
+
/*
* XXX: Still needed to boot until the i2c twl driver is adapted to
* device-tree
@@ -58,18 +70,8 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-static struct of_device_id intc_match[] __initdata = {
- { .compatible = ti,omap3-intc, },
- { .compatible = arm,cortex-a9-gic, },
- { }
-};
-
static void __init omap_generic_init(void)
{
- struct device_node *node = of_find_matching_node(NULL, intc_match);
- if (node)
- irq_domain_add_simple(node, 0);
-
omap_serial_init();
omap_sdrc_init(NULL, NULL);
@@ -103,7 +105,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -122,7 +124,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened
Device Tree))
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
- .init_irq = omap2_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap2_intc_handle_irq,
.init_machine = omap_generic_init,
.timer = omap2_timer,
@@ -141,7 +143,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
- .init_irq = omap3_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap3_init,
.timer = omap3_timer,
@@ -160,7 +162,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device
Tree))
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = gic_init_irq,
+ .init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
.init_machine = omap4_init,
.timer = omap4_timer,
--
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
ASoC broken on 3.2-rc4?
I just began working with 3.2-rc4 on Overo and Beagleboard xM. On both machines I see the driver init, but no alsa device created. For example on Overo: Advanced Linux Sound Architecture Driver Version 1.0.24. snip overo SoC init ALSA device list: No soundcards found. Has anyone else seen this? Just want to make sure it isn't a known issue before digging in and debugging. Steve -- 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-V5 1/3] arm:omap:am33xx: Update common OMAP machine specific sources
* hvaib...@ti.com hvaib...@ti.com [111201 22:08]:
From: Afzal Mohammed af...@ti.com
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Applying this one updated for the map_io and common.h changes, updated
patch below. The other two will have to wait a little because of the
machine_id dependency.
Regards,
Tony
From: Afzal Mohammed af...@ti.com
Date: Fri, 2 Dec 2011 12:13:22 +0530
Subject: [PATCH] arm:omap:am33xx: Update common OMAP machine specific sources
This patch updates the common machine specific source files for
support for AM33XX/AM335x with cpu type, macros for identification of
AM33XX/AM335X device.
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
[t...@atomide.com: updated for map_io and common.h changes]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 5d0064a..c1ab6bc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3517,6 +3517,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+ } else if (cpu_is_am33xx()) {
+ cpu_mask = RATE_IN_AM33XX;
+ cpu_clkflg = CK_AM33XX;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 684b8a7..c900dcb 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -128,6 +128,27 @@ void __init omap2_set_globals_ti816x(void)
{
__omap2_set_globals(ti816x_globals);
}
+
+#define AM33XX_TAP_BASE(AM33XX_CTRL_BASE + \
+ TI816X_CONTROL_DEVICE_ID - 0x204)
+
+static struct omap_globals am33xx_globals = {
+ .class = AM335X_CLASS,
+ .tap= AM33XX_L4_WK_IO_ADDRESS(AM33XX_TAP_BASE),
+ .ctrl = AM33XX_L4_WK_IO_ADDRESS(AM33XX_CTRL_BASE),
+ .prm= AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+ .cm = AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE),
+};
+
+void __init omap2_set_globals_am33xx(void)
+{
+ __omap2_set_globals(am33xx_globals);
+}
+
+void __init am33xx_map_io(void)
+{
+ omapam33xx_map_common_io();
+}
#endif
#if defined(CONFIG_ARCH_OMAP4)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..9b733e3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -60,6 +60,14 @@ static inline void omapti816x_map_common_io(void)
}
#endif
+#ifdef CONFIG_SOC_OMAPAM33XX
+extern void omapam33xx_map_common_io(void);
+#else
+static inline void omapam33xx_map_common_io(void)
+{
+}
+#endif
+
#ifdef CONFIG_ARCH_OMAP4
extern void omap44xx_map_common_io(void);
#else
@@ -107,6 +115,7 @@ void omap2_set_globals_243x(void);
void omap2_set_globals_3xxx(void);
void omap2_set_globals_443x(void);
void omap2_set_globals_ti816x(void);
+void omap2_set_globals_am33xx(void);
/* These get called from omap2_set_globals_(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
@@ -117,6 +126,7 @@ void omap2_set_globals_prcm(struct omap_globals *);
void omap242x_map_io(void);
void omap243x_map_io(void);
void omap3_map_io(void);
+void am33xx_map_io(void);
void omap4_map_io(void);
/**
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 27ad722..7ab09f7 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -340,6 +340,10 @@ static void __init omap3_check_revision(const char
**cpu_rev)
break;
}
break;
+ case 0xb944:
+ omap_revision = AM335X_REV_ES1_0;
+ *cpu_rev = 1.0;
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -432,6 +436,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? AM3517 : AM3505;
} else if (cpu_is_ti816x()) {
cpu_name = TI816X;
+ } else if (cpu_is_am335x()) {
+ cpu_name = AM335X;
} else if (omap3_has_iva() omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = OMAP3430/3530;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3f565dd..088d2ba 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -183,7 +183,24 @@ static struct map_desc omapti816x_io_desc[] __initdata = {
.pfn= __phys_to_pfn(L4_34XX_PHYS),
Re: [PATCH-V5 0/3] Introducing TI's New SoC/board AM335XEVM
* Kevin Hilman khil...@ti.com [111206 15:52]: hvaib...@ti.com writes: From: Vaibhav Hiremath hvaib...@ti.com This patch set adds support for AM335x device having Cortex-A8 MPU. Official website - http://www.ti.com/product/am3359 AM335X is treated as another OMAP3 variant, where, along with existing cpu class OMAP34XX, new cpu class AM33XX is created and the respective type is AM335X, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks return success for AM335X. Also, I have validated OMAP3 boot test with this patch-series on OMAP3EVM. Tony, this series looks good to me. I've also tested it on a BeagleBone, so feel free to also add: Tested-by: Kevin Hilman khil...@ti.com Thanks looks good to me. We still need the machine_id update to apply patches 2 and 3 in this series, so applying only the first patch into soc branch for now. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2/3: intc: Add DT support for TI interrupt controller
On 12/07/2011 02:50 PM, Benoit Cousson wrote:
Add a function to initialize the OMAP2/3 interrupt controller (INTC)
using a device tree node.
Replace some printk() with the proper pr_ macro.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/arm/omap/intc.txt | 27 +++
arch/arm/mach-omap2/common.h | 10 ++
arch/arm/mach-omap2/irq.c | 35
++--
3 files changed, 69 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt
b/Documentation/devicetree/bindings/arm/omap/intc.txt
new file mode 100644
index 000..f2583e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/intc.txt
@@ -0,0 +1,27 @@
+* OMAP Interrupt Controller
+
+OMAP2/3 are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+ ti,omap2-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a u32 and the value shall be 1.
+
+ The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+ intc: interrupt-controller@1 {
+ compatible = ti,omap2-intc;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ ti,intc-size = 96;
+ reg = 0x4820 0x1000;
+ };
+
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 012bac7..bcfccc2 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -156,6 +156,16 @@ void omap3_intc_resume_idle(void);
void omap2_intc_handle_irq(struct pt_regs *regs);
void omap3_intc_handle_irq(struct pt_regs *regs);
+struct device_node;
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node
*parent);
+#else
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ return 0;
+}
+#endif
+
/*
* wfi used in low power code. Directly opcode is used instead
* of instruction to avoid mulit-omap build break
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 42b1d65..cafc663 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -17,6 +17,9 @@
#include mach/hardware.h
#include asm/exception.h
#include asm/mach/irq.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/irqdomain.h
/* selected INTC register offsets */
@@ -166,7 +169,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
/* Static mapping, never released */
bank-base_reg = ioremap(base, SZ_4K);
if (!bank-base_reg) {
- printk(KERN_ERR Could not ioremap irq bank%i\n, i);
+ pr_err(Could not ioremap irq bank%i\n, i);
continue;
}
@@ -179,8 +182,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
nr_banks++;
}
- printk(KERN_INFO Total of %ld interrupts on %d active controller%s\n,
-nr_of_irqs, nr_banks, nr_banks 1 ? s : );
+ pr_info(Total of %ld interrupts on %d active controller%s\n,
+ nr_of_irqs, nr_banks, nr_banks 1 ? s : );
}
void __init omap2_init_irq(void)
@@ -236,6 +239,32 @@ asmlinkage void __exception_irq_entry
omap2_intc_handle_irq(struct pt_regs *regs
omap_intc_handle_irq(base_addr, regs);
}
+#ifdef CONFIG_OF
+int __init intc_of_init(struct device_node *node, struct device_node *parent)
+{
+ struct resource res;
+ u32 nr_irqs;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, res)) {
+ WARN(1, unable to get intc registers\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, ti,intc-size, nr_irqs)) {
+ WARN(1, unable to get intc-size\n);
+ return -EINVAL;
There is no default value that makes sense?
+ }
+
+ omap_init_irq(res.start, nr_irqs);
+ irq_domain_add_simple(node, 0);
Have you read the NO_IRQ thread...
Is 0 ever a valid interrupt for a driver? If so, you must not use 0 for
the base. I would pick 16 to skip over legacy ISA irqs.
irqdomains should always be enabled regardless of CONFIG_OF. So either
you can leave it as is if OF is always enabled for OMAP, or you should
move domain setup into omap_init_irq.
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Re: [RFC PATCH 00/11] arm:omap:am33xx: Add basic voltage, power, clock HWMOD data
* Vaibhav Hiremath hvaib...@ti.com [20 08:44]: 34 files changed, 7525 insertions(+), 15 deletions(-) Clearly we can't merge this amount of static SoC specific hwmod/mux data after the all that's been discussed over this year. We just have to have a better way of doing this. For now, we already have the SoC specific init functions available, so I suggest taking a hard look how to dynamically allocate these data structures and populate them with the SoC specific init functions. Then later on we may be able to pass some of the data such as module base addresses from device tree. But I'm guessing that the SoC specific inits should already squeeze this down into something tolerable. 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: RFC: bq2415x_charger driver
Hi Pali, On 07.12.2011 23:03, Pali Rohár wrote: Hello, I'm sending preview of my implementation of bq2415x charger driver. Now all code is in one kernel module bq2415x_charger which has more interfaces (power_supply, sysfs, regulator). It is still unfinished, missing more bq2415x configuration like sysfs entires for boost, voltages or platform hooks (e.g. rx51 isp1704). This driver will have similar sysfs interface as in Joerg Reisenweber spec http://maemo.cloud-7.de/bq24150-sysnode.spec.txt . Driver should be replacemnt for Nokia N900 proprietary charging program BME. I was inspirated by driver bq27x00_battery and other bq2415x implementaton by Aliaksei Katovich and Felipe Contreras. Please comment implementation and write what should be added or modified in driver (it is still not complete). There are well defined policies regarding patch review in the Linux kernel mailing lists. I encourage you to take a look at http://felipec.wordpress.com/2009/10/25/git-send-email-tricks/ -- With best wishes, Vladimir -- 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: bq2415x_charger driver
On Wednesday 07 December 2011 23:25:12 Vladimir Zapolskiy wrote: Hi Pali, On 07.12.2011 23:03, Pali Rohár wrote: Hello, I'm sending preview of my implementation of bq2415x charger driver. Now all code is in one kernel module bq2415x_charger which has more interfaces (power_supply, sysfs, regulator). It is still unfinished, missing more bq2415x configuration like sysfs entires for boost, voltages or platform hooks (e.g. rx51 isp1704). This driver will have similar sysfs interface as in Joerg Reisenweber spec http://maemo.cloud-7.de/bq24150-sysnode.spec.txt . Driver should be replacemnt for Nokia N900 proprietary charging program BME. I was inspirated by driver bq27x00_battery and other bq2415x implementaton by Aliaksei Katovich and Felipe Contreras. Please comment implementation and write what should be added or modified in driver (it is still not complete). There are well defined policies regarding patch review in the Linux kernel mailing lists. I encourage you to take a look at http://felipec.wordpress.com/2009/10/25/git-send-email-tricks/ Ok, I do not know where to put this driver, so I only send files. Here is diff diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c new file mode 100644 index 000..eb9957a --- /dev/null +++ b/drivers/power/bq2415x_charger.c @@ -0,0 +1,1115 @@ +/* +bq2415x_charger.c - bq2415x charger driver +Copyright (C) 2011 Pali Rohár pali.ro...@gmail.com + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +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. + +You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., +51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +*/ + +/* + Datasheets: + http://www.ti.com/product/bq24150 + http://www.ti.com/product/bq24150a + http://www.ti.com/product/bq24152 + http://www.ti.com/product/bq24153 + http://www.ti.com/product/bq24153a + http://www.ti.com/product/bq24155 +*/ + +#include linux/version.h +#include linux/module.h +#include linux/param.h +#include linux/err.h +#include linux/workqueue.h +#include linux/sysfs.h +#include linux/platform_device.h +#include linux/regulator/driver.h +#include linux/power_supply.h +#include linux/idr.h +#include linux/leds.h +#include linux/i2c.h +#include linux/slab.h + +#include bq2415x_charger.h + +#define BQ2415X_WATCHDOG_TIMEOUT 10 + +#define BQ2415X_REG_STATUS 0x00 +#define BQ2415X_REG_CONTROL0x01 +#define BQ2415X_REG_VOLTAGE0x02 +#define BQ2415X_REG_VENDER 0x03 +#define BQ2415X_REG_CURRENT0x04 + +/* reset state for all registers */ +#define BQ2415X_RESET_STATUS BIT(6) +#define BQ2415X_RESET_CONTROL (BIT(4)|BIT(5)) +#define BQ2415X_RESET_VOLTAGE (BIT(1)|BIT(3)) +#define BQ2415X_RESET_CURRENT (BIT(0)|BIT(3)|BIT(7)) + +/* status register */ +#define BQ2415X_BIT_TMR_RST7 +#define BQ2415X_BIT_OTG7 +#define BQ2415X_BIT_EN_STAT6 +#define BQ2415X_MASK_STAT (BIT(4)|BIT(5)) +#define BQ2415X_SHIFT_STAT 4 +#define BQ2415X_BIT_BOOST 3 +#define BQ2415X_MASK_FAULT (BIT(0)|BIT(1)|BIT(2)) +#define BQ2415X_SHIFT_FAULT0 + +/* control register */ +#define BQ2415X_MASK_LIMIT (BIT(6)|BIT(7)) +#define BQ2415X_SHIFT_LIMIT6 +#define BQ2415X_MASK_VLOWV (BIT(4)|BIT(5)) +#define BQ2415X_SHIFT_VLOWV4 +#define BQ2415X_BIT_TE 3 +#define BQ2415X_BIT_CE 2 +#define BQ2415X_BIT_HZ_MODE1 +#define BQ2415X_BIT_OPA_MODE 0 + +/* voltage register */ +#define BQ2415X_MASK_VO (BIT(2)|BIT(3)|BIT(4)|BIT(5)|BIT(6)|BIT(7)) +#define BQ2415X_SHIFT_VO 2 +#define BQ2415X_BIT_OTG_PL 1 +#define BQ2415X_BIT_OTG_EN 0 + +/* vender register */ +#define BQ2415X_MASK_VENDER(BIT(5)|BIT(6)|BIT(7)) +#define BQ2415X_SHIFT_VENDER 5 +#define BQ2415X_MASK_PN(BIT(3)|BIT(4)) +#define BQ2415X_SHIFT_PN 4 +#define BQ2415X_MASK_REVISION (BIT(0)|BIT(1)|BIT(2)) +#define BQ2415X_SHIFT_REVISION 0 + +/* current register */ +/* RESET BIT(7) */ +#define BQ2415X_MASK_VI_CHRG (BIT(4)|BIT(5)|BIT(6)) +#define BQ2415X_SHIFT_VI_CHRG 4 +/* N/A BIT(3) */ +#define
Re: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
* Sergio Aguirre saagui...@ti.com [30 15:40]: Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. I suggest you do a device tree only binding for new drivers. arch/arm/mach-omap2/board-4430sdp-camera.c| 221 arch/arm/mach-omap2/board-omap4panda-camera.c | 198 arch/arm/mach-omap2/devices.c | 40 + That leaves out most of the code above. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] staging: tidspbridge: request dmtimer clocks on init
On Sat, Nov 19, 2011 at 12:18 AM, Omar Ramirez Luna omar.rami...@ti.com wrote: Given that dm timer framework doesn't support request of clocks by soft | hard irqs because some recent changes, tidspbridge needs to request its clocks on init and enable/disable them on demand. This was first seen on 3.2-rc1. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com This looks similar similar to this one: http://article.gmane.org/gmane.linux.ports.arm.omap/61816 Are you sure this is what we want instead of that one? Cheers. -- Felipe Contreras -- 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: rx51: enable tsc2005 touchscreen
* Aaro Koskinen aaro.koski...@nokia.com [111202 07:52]: Enable TSC2005 touchscreen driver on the RX-51 board by providing the needed platform data. Thanks applying this into board branch with the ealier Reviewed-by from Sebastian Reichel. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] ARM: OMAP: TI81XX: Prepare for addition of TI814X support
* Hemant Pedanekar hema...@ti.com [111009 18:06]: This patch updates existing macros, functions used for TI816X, to enable addition of other SoCs belonging to TI81XX family (e.g., TI814X). The approach taken is to use TI81XX/ti81xx for code/data going to be common across all TI81XX devices. cpu_is_ti81xx() is introduced to handle code common across TI81XX devices. In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved in mach-omap2/common.c as same will be used for TI814X and is not board specific. Looks like this series needs a rebase after the map_io and common.h changes. Can you please rebase against the current omap soc branch at commit 24a5e092a387e4c8e93f33448da334bd3fd15192? 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: [RFC PATCH] arm:omap: cleanup split omap2/3/4_check_revision function
* Hiremath, Vaibhav hvaib...@ti.com [22 21:56]:
This patch doesn't change functionality or behavior of the code
execution; it barely cleans up the code and splits into SoC
specific implementation for ID and feature detection; makes
easier to add new SoC (especially for AM devices where we do not have
feature register).
...
If there are not review comments, can this be merged?
Sorry for the delay, the idea is good now that we don't need the
revision check super early any longer. Few comments below.
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -226,9 +226,9 @@ static void __init omap4_check_features(void)
}
}
-static void __init ti816x_check_features(void)
+static void __init omap3_add_def_features(void)
{
- omap_features = OMAP3_HAS_NEON;
+ omap_features = OMAP3_HAS_NEON | OMAP3_HAS_L2CACHE;
}
static void __init omap3_check_revision(const char **cpu_rev)
Can you please split this patch a bit? First a patch that does not
change the behaviour except adds the SoC specific revision checks.
@@ -393,6 +394,7 @@ void __init omap2430_init_early(void)
void __init omap3_init_early(void)
{
omap2_set_globals_3xxx();
+ omap3xxx_check_revision(true);
omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
@@ -425,6 +427,7 @@ void __init am35xx_init_early(void)
void __init ti816x_init_early(void)
{
omap2_set_globals_ti816x();
+ omap3xxx_check_revision(false);
omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
Maybe just call ti816x_check_features separately?
omap3xxx_check_revision();
omap3xxx_check_features();
and
omap3xxx_check_revision();
ti816x_check_features();
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: id: add chip id recognition for omap4430 es2.3
* David Anders x0132...@ti.com [07 09:43]: allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf Thanks applying into soc branch. Tony Signed-off-by: David Anders x0132...@ti.com --- arch/arm/mach-omap2/id.c |6 -- arch/arm/plat-omap/include/plat/cpu.h |1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index d27daf9..6681238 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -386,8 +386,10 @@ static void __init omap4_check_revision(void) omap_revision = OMAP4430_REV_ES2_1; break; case 4: - default: omap_revision = OMAP4430_REV_ES2_2; + case 6: + default: + omap_revision = OMAP4430_REV_ES2_3; } break; case 0xb94e: @@ -400,7 +402,7 @@ static void __init omap4_check_revision(void) break; default: /* Unknown default to latest silicon rev as default */ - omap_revision = OMAP4430_REV_ES2_2; + omap_revision = OMAP4430_REV_ES2_3; } pr_info(OMAP%04x ES%d.%d\n, omap_rev() 16, diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 649b370..a2fc6d3 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -416,6 +416,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define OMAP4430_REV_ES2_0 (OMAP443X_CLASS | (0x20 8)) #define OMAP4430_REV_ES2_1 (OMAP443X_CLASS | (0x21 8)) #define OMAP4430_REV_ES2_2 (OMAP443X_CLASS | (0x22 8)) +#define OMAP4430_REV_ES2_3 (OMAP443X_CLASS | (0x23 8)) #define OMAP446X_CLASS 0x44600044 #define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8)) -- 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] AM35xx: disable checking for reserved feature bits
Hi, * Kevin Hilman khil...@ti.com [08 16:23]: Ilya Yanok ya...@emcraft.com writes: Bits corresponding to the IVA and ISP features in OMAP_STATUS register are reserved on AM35xx and checking for them results in wrong results. Ouch. So we don't want to check for this features on AM35xx. Signed-off-by: Ilya Yanok ya...@emcraft.com This feature selection mechanism is clearly not scaling to newer SoCs. While this patch works around the problem, IMO, we need a more scalable solution. Agreed. For features like IVA and ISP (and SGX) which are acutally IP blocks on the SoC, not features per-se, what we really need to be doing is checking for the presence of the IP block, not checking a bit in a register that's not consistent across various SoCs. We already have all the knowledge about whether the IP blocks are present in the SoC-specific hwmod data. So checking for the feature of a specific IP block should instead be done using an omap_hwmod_lookup(). However, there's a bit of a snag because this feature detection is currently done before the hwmods are registered. As a quick-and-dirty proof of concept, the patch/hack below moves the feature checking after the hwmod init (omap3 only currently) and uses omap_hwmod_lookup() to check whether a given IP block exists. I only did a quick test on one OMAP3 platform (3430/n900) and it seems to work.The init order changes need some more thought, as I didn't fully validate whether the feature detection can be safely moved later for all platforms. This is just to show the direction we should be taking this SoC detection for newer SoCs. This should be coordinated with the splitting of feature detection as posted by Vaibhave in thread [RFC PATCH] arm:omap: cleanup split omap2/3/4_check_revision function thread. We no longer need the SoC detection super early, so I suggest we make the feature detection separate from SoC detection. The SoC specific init can then call: omap3_check_revision(); ti816x_check_features(); 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
[PATCHv2] omap: id: add chip id recognition for omap4430 es2.3
allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf Signed-off-by: David Anders x0132...@ti.com --- arch/arm/mach-omap2/id.c |7 +-- arch/arm/plat-omap/include/plat/cpu.h |1 + 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index d27daf9..a0878e0 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -386,8 +386,11 @@ static void __init omap4_check_revision(void) omap_revision = OMAP4430_REV_ES2_1; break; case 4: - default: omap_revision = OMAP4430_REV_ES2_2; + break; + case 6: + default: + omap_revision = OMAP4430_REV_ES2_3; } break; case 0xb94e: @@ -400,7 +403,7 @@ static void __init omap4_check_revision(void) break; default: /* Unknown default to latest silicon rev as default */ - omap_revision = OMAP4430_REV_ES2_2; + omap_revision = OMAP4430_REV_ES2_3; } pr_info(OMAP%04x ES%d.%d\n, omap_rev() 16, diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 649b370..a2fc6d3 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -416,6 +416,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define OMAP4430_REV_ES2_0 (OMAP443X_CLASS | (0x20 8)) #define OMAP4430_REV_ES2_1 (OMAP443X_CLASS | (0x21 8)) #define OMAP4430_REV_ES2_2 (OMAP443X_CLASS | (0x22 8)) +#define OMAP4430_REV_ES2_3 (OMAP443X_CLASS | (0x23 8)) #define OMAP446X_CLASS 0x44600044 #define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 8)) -- 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] omap: id: add chip id recognition for omap4430 es2.3
Tony, On 12/07/2011 05:43 PM, Tony Lindgren wrote: * David Andersx0132...@ti.com [07 09:43]: allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf Thanks applying into soc branch. i have a v2 of this patch that corrects a missing break. please apply v2 instead Tony thanks Dave Signed-off-by: David Andersx0132...@ti.com --- arch/arm/mach-omap2/id.c |6 -- arch/arm/plat-omap/include/plat/cpu.h |1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index d27daf9..6681238 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -386,8 +386,10 @@ static void __init omap4_check_revision(void) omap_revision = OMAP4430_REV_ES2_1; break; case 4: - default: omap_revision = OMAP4430_REV_ES2_2; + case 6: + default: + omap_revision = OMAP4430_REV_ES2_3; } break; case 0xb94e: @@ -400,7 +402,7 @@ static void __init omap4_check_revision(void) break; default: /* Unknown default to latest silicon rev as default */ - omap_revision = OMAP4430_REV_ES2_2; + omap_revision = OMAP4430_REV_ES2_3; } pr_info(OMAP%04x ES%d.%d\n, omap_rev() 16, diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 649b370..a2fc6d3 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -416,6 +416,7 @@ IS_OMAP_TYPE(3517, 0x3517) #define OMAP4430_REV_ES2_0(OMAP443X_CLASS | (0x20 8)) #define OMAP4430_REV_ES2_1(OMAP443X_CLASS | (0x21 8)) #define OMAP4430_REV_ES2_2(OMAP443X_CLASS | (0x22 8)) +#define OMAP4430_REV_ES2_3 (OMAP443X_CLASS | (0x23 8)) #define OMAP446X_CLASS0x44600044 #define OMAP4460_REV_ES1_0(OMAP446X_CLASS | (0x10 8)) -- 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 4/4] mcx: initial support for HTKW mcx board
* Ilya Yanok ya...@emcraft.com [21 15:46]: Hi Tony, On 19.11.2011 04:36, Tony Lindgren wrote: Well, it already boots with DT actually. Did you mean booting with DT and board-generic? I have to admit I don't know how to proceed here: Good to hear you're already playing with it. Yes, let's work on making all the boards work with DT and board-generic.. Hm, do you think it's absolutely necessary to make everybody work with board-generic? It will require a lot of additional bindings to get rid of all machine-specific code. I've just thought that on PowerPC we don't have such strict rules: if some boards are really similar they share common machine file but if we need something specific for the new board we can create it's own machine file. Well ideally yes we would remove the board files completely eventually. But that will take a while, so I can carry your board file in testing-board branch. board-generic initialize twl4030 which we don't have on our board... Could you give me some pointer how I'm supposed to handle this? .. we should only initialize twl4030/twl6030 if the DT compatible flag for it is set. But we're still missing the DT bindings for those :( For now, maybe try to fix the twl4030 probe so it won't do anything unless the I2C device is found? That turned to be not such a big problem. Device is not present so we have tons of error messages but somehow it works. The bigger problem is that we have different regulator chip attached. How am I supposed to register supplies/consumers data with it? Does anybody working on DT bindings for the regulator framework? Rajendra has posted some regulator DT patches. I believe they have a dependency to the deferred probe patches in many cases though. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: ID: Chip detection for OMAP4470
* Iziumtsev, Leonid x0153...@ti.com [10 06:21]: From: Leonid Iziumtsev x0153...@ti.com Add support for detection of the next chip in the OMAP4 family: OMAP4470 ES1.0 For more details on OMAP4470, visit: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12869contentId=123362 Thanks applying into soc branch. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] am35xx-emac: move generic EMAC init to separate file
* Ilya Yanok ya...@emcraft.com [16 16:01]: AM35xx SoCs include DaVinci EMAC IP. Initialization code in board-am3517evm.c is pretty board independent and will work for any AM35xx based board so move this code to it's own file to be reused by other boards. Should this be just called emac-common.c? Or is it so am35xx specific that it won't work with others? + clk_add_alias(NULL, dev_name(am35xx_emac_device.dev), + emac_clk, am35xx_emac_device.dev); + clk_add_alias(NULL, dev_name(am35xx_mdio_device.dev), + phy_clk, am35xx_emac_device.dev); Hmm after moving the code and should be a separate patch, don't we already have these clock aliases in cloc3xxx_data.c? 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: [PATCHv2] omap: id: add chip id recognition for omap4430 es2.3
* David Anders x0132...@ti.com [111207 15:29]: allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf I have the earlier one already applied, this seems to be the exact same patch, right? 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: [PATCHv2] omap: id: add chip id recognition for omap4430 es2.3
Tony, On 12/07/2011 06:23 PM, Tony Lindgren wrote: * David Andersx0132...@ti.com [111207 15:29]: allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf I have the earlier one already applied, this seems to be the exact same patch, right? same core patch, with a break; added to the case 4. if you would rather i can provide a one line fix patch Tony 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: [PATCHv2] omap: id: add chip id recognition for omap4430 es2.3
* David Anders x0132...@ti.com [111207 15:54]: Tony, On 12/07/2011 06:23 PM, Tony Lindgren wrote: * David Andersx0132...@ti.com [111207 15:29]: allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdf I have the earlier one already applied, this seems to be the exact same patch, right? same core patch, with a break; added to the case 4. Ah OK. if you would rather i can provide a one line fix patch No need, have not pushed it out yet so I'll update it before pushing out. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support
On Tue, Nov 8, 2011 at 8:00 AM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified to use timer-func_base OCP_CFG should not use this wrapper anymore. Instead use __raw_writel() directly and use timer-io_base instead to write to OCP_CFG. The timer-sys_stat is valid only if timer-revision is 1. In the context restore function make this correction. Save the contexts and loss count when timer is stopped. Also, disable the clock. Else, clock usecount would become imbalanced. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com It looks like this patch is doing 3 things, so I think this patch should be split into 3 logical patches. -- Felipe Contreras -- 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 6/6] cbus: retu: implement irq_domain support
* Felipe Balbi ba...@ti.com [23 08:23]:
Hi,
On Wed, Nov 23, 2011 at 04:00:48PM +0200, Felipe Balbi wrote:
Then, when moving to devicetree, we can list
IRQs as 1, 2, 3. It's the only way to have a
sane devicetree actually.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/cbus/retu.c | 42 +++---
1 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/cbus/retu.c b/drivers/cbus/retu.c
index 25fa405..f25e0a3 100644
--- a/drivers/cbus/retu.c
+++ b/drivers/cbus/retu.c
@@ -25,7 +25,7 @@
#include linux/module.h
#include linux/init.h
-
+#include linux/irqdomain.h
#include linux/slab.h
#include linux/kernel.h
#include linux/errno.h
@@ -46,6 +46,7 @@ struct retu {
struct mutexmutex;
struct device *dev;
+ struct irq_domain irq_domain;
struct irq_chip irq_chip;
int irq_base;
@@ -199,11 +200,9 @@ static irqreturn_t retu_irq_handler(int irq, void
*_retu)
while (idr) {
unsigned long pending = __ffs(idr);
- unsigned intirq;
idr = ~BIT(pending);
- irq = pending + retu-irq_base;
- handle_nested_irq(irq);
+ handle_nested_irq(pending);
This is particular, I'm not sure if it's correct. Not sure if we should
use hw IRQ number of linux IRQ number. A boot test should be enough to
verify though.
This one does not seem to work, so pushing only the first five. The watchdog
seems to be kicked, so looks like they work.
Tony
[2.810638] tahvo tahvo: Betty v2.1 found
[2.819549] Unable to handle kernel NULL pointer dereference at virtual
address
[2.828430] pgd = c0004000
[2.831420] [] *pgd=
[2.835205] Internal error: Oops: 5 [#1] SMP
[2.839691] Modules linked in:
[2.842926] CPU: 0Not tainted (3.2.0-rc2-01686-gf3667721-dirty #231)
[2.850097] PC is at irq_domain_add+0x10/0x154
[2.854766] LR is at retu_probe+0x130/0x358
[2.859161] pc : [c009dda4]lr : [c0426294]psr: 6013
[2.859191] sp : c7827eb8 ip : 0001 fp : c0537458
[2.871215] r10: c066bf68 r9 : c0bf4418 r8 : 0068
[2.876708] r7 : 0001 r6 : c7a888ec r5 : c7a888a0 r4 : 0001
[2.883575] r3 : r2 : c7825400 r1 : c06caf80 r0 : c7a888ec
[2.890441] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[2.898101] Control: 00c5387d Table: 80004000 DAC: 0017
[2.904144] Process swapper (pid: 1, stack limit = 0xc78262f8)
[2.910278] Stack: (0xc7827eb8 to 0xc7828000)
[2.914855] 7ea0:
0001 c7a888a0
[2.923461] 7ec0: c7a8890c 0078 0068 c0426294
c069d090 c066bf68
[2.932067] 7ee0: c066bf68 c069d090 c0291024 c068f8d0 c0bf25b0 c069d090
c06a7480 c02922ac
[2.940673] 7f00: c066bf68 c0290ef8 c066bf68 c066bf9c c069d090 c0291024
c068f8d0
[2.949279] 7f20: c7abb5e0 c02910b8 c7827f38 c069d090 c0290724
c781a658 c78641b0
[2.957885] 7f40: c0537458 c061b0ac c069d090 c069d090 c0290034
c0537458 c0233bd0
[2.966491] 7f60: c061b50c c061b0ac c069d090 0013 c7826000 c05f6958
c02916bc
[2.975097] 7f80: c061b50c c061b0ac c061b5f4 0013 c7826000 c0008688
c0626880 c009e650
[2.983703] 7fa0: 005f c061b5f4 35390013
019a
[2.992309] 7fc0: c067cf94 c061b50c c061b0ac c061b5f4 0013
[3.000915] 7fe0: c05d0298 c05d0200 c0014f88 c0014f88
ff9f
[3.009521] [c009dda4] (irq_domain_add+0x10/0x154) from [c0426294]
(retu_probe+0x130/0x358)
[3.018707] [c0426294] (retu_probe+0x130/0x358) from [c02922ac]
(platform_drv_probe+0x18/0x1c)
[3.028167] [c02922ac] (platform_drv_probe+0x18/0x1c) from [c0290ef8]
(driver_probe_device+0x98/0x1c4)
[3.038330] [c0290ef8] (driver_probe_device+0x98/0x1c4) from [c02910b8]
(__driver_attach+0x94/0x98)
[3.048217] [c02910b8] (__driver_attach+0x94/0x98) from [c0290724]
(bus_for_each_dev+0x60/0x8c)
[3.057739] [c0290724] (bus_for_each_dev+0x60/0x8c) from [c0290034]
(bus_add_driver+0x198/0x260)
[3.067352] [c0290034] (bus_add_driver+0x198/0x260) from [c02916bc]
(driver_register+0x6c/0x148)
[3.076965] [c02916bc] (driver_register+0x6c/0x148) from [c0008688]
(do_one_initcall+0x34/0x180)
[3.086578] [c0008688] (do_one_initcall+0x34/0x180) from [c05d0298]
(kernel_init+0x98/0x144)
[3.095855] [c05d0298] (kernel_init+0x98/0x144) from [c0014f88]
(kernel_thread_exit+0x0/0x8)
[3.105102] Code: e92d41f0 e1a06000 e5903014 e5907010 (e5933000)
[3.111816] ---[ end trace 539355b8447db297 ]---
[3.116729] Kernel panic - not syncing: Attempted to kill init!
--
To unsubscribe from this list: send the line unsubscribe linux-omap
Re: [RFC PATCH v1 5/7] media: v4l2: introduce two IOCTLs for face detection
Hi,
On Tue, Dec 6, 2011 at 6:15 AM, Sylwester Nawrocki snj...@gmail.com wrote:
On 12/02/2011 04:02 PM, Ming Lei wrote:
This patch introduces two new IOCTLs and related data
structure defination which will be used by the coming
face detection video device.
The two IOCTLs and related data structure are used by
user space application to retrieve the results of face
detection. They can be called after one v4l2_buffer
has been ioctl(VIDIOC_DQBUF) and before it will be
ioctl(VIDIOC_QBUF).
The utility fdif[1] is useing the two IOCTLs to find
faces deteced in raw images or video streams.
[1],http://kernel.ubuntu.com/git?p=ming/fdif.git;a=shortlog;h=refs/heads/v4l2-fdif
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/media/video/v4l2-ioctl.c | 38
include/linux/videodev2.h | 70
++
include/media/v4l2-ioctl.h | 6 +++
3 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..fc6266f 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2140,6 +2140,30 @@ static long __video_do_ioctl(struct file *file,
dbgarg(cmd, index=%d, b-index);
break;
}
+ case VIDIOC_G_FD_RESULT:
+ {
+ struct v4l2_fd_result *fr = arg;
+
+ if (!ops-vidioc_g_fd_result)
+ break;
+
+ ret = ops-vidioc_g_fd_result(file, fh, fr);
+
+ dbgarg(cmd, index=%d, fr-buf_index);
+ break;
+ }
+ case VIDIOC_G_FD_COUNT:
+ {
+ struct v4l2_fd_count *fc = arg;
+
+ if (!ops-vidioc_g_fd_count)
+ break;
+
+ ret = ops-vidioc_g_fd_count(file, fh, fc);
+
+ dbgarg(cmd, index=%d, fc-buf_index);
+ break;
+ }
default:
if (!ops-vidioc_default)
break;
@@ -2234,6 +2258,20 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
}
break;
}
+
+ case VIDIOC_G_FD_RESULT: {
+ struct v4l2_fd_result *fr = parg;
+
+ if (fr-face_cnt != 0) {
+ *user_ptr = (void __user *)fr-fd;
+ *kernel_ptr = (void *)fr-fd;
+ *array_size = sizeof(struct v4l2_fd_detection)
+ * fr-face_cnt;
+ ret = 1;
+ }
+ break;
+
+ }
}
return ret;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..073eb4d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2160,6 +2160,74 @@ struct v4l2_create_buffers {
__u32 reserved[8];
};
+/**
+ * struct v4l2_obj_detection
+ * @buf_index: entry, index of v4l2_buffer for face detection
+ * @centerx: return, position in x direction of detected object
+ * @centery: return, position in y direction of detected object
+ * @angle: return, angle of detected object
+ * 0 deg ~ 359 deg, vertical is 0 deg, clockwise
+ * @sizex: return, size in x direction of detected object
+ * @sizey: return, size in y direction of detected object
+ * @confidence: return, confidence level of detection result
+ * 0: the heighest level, 9: the lowest level
Hmm, not a good idea to align a public interface to the capabilities
of a single hardware implementation.
I think that the current omap interface is general enough, so why can't
we use it as public interface?
min/max confidence could be queried with
relevant controls and here we could remove the line implying range.
No, the confidence is used to describe the probability about
the correctness of the current detection result. Anyway, no FD can
make sure that it is 100% correct. Other HW can normalize its
confidence level to 0~9 so that application can handle it easily, IMO.
+ * @reserved: future extensions
+ */
+struct v4l2_obj_detection {
+ __u16 centerx;
+ __u16 centery;
+ __u16 angle;
+ __u16 sizex;
+ __u16 sizey;
How about using struct v4l2_rect in place of centerx/centery, sizex/sizey ?
After all it describes a rectangle. We could also use struct
v4l2_frmsize_discrete
for size but there seems to be missing en equivalent for position, e.g.
Maybe user space would like to plot a circle or ellipse over the detected
objection, and I am sure that I have seen this kind of plot over detected
face before.
struct v4l2_position {
__s32 x;
__s32 y;
};
+ __u16 confidence;
+ __u32 reserved[4];
+};
+
+#define V4L2_FD_HAS_LEFT_EYE 0x1
+#define V4L2_FD_HAS_RIGHT_EYE 0x2
+#define V4L2_FD_HAS_MOUTH
Re: [GIT PULL] More omap1 boot regression fixes for v3.2-rc4
On Wed, Dec 7, 2011 at 11:40 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Please pull omap1 fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Thanks, pulled into fixes. -Olof -- 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/7] Introducing a generic AMP framework
Hi Rusty, On Wed, Nov 23, 2011 at 11:58 AM, Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Nov 23, 2011 at 3:33 AM, Rusty Russell ru...@rustcorp.com.au wrote: That would imply that I'd done more than glance over them, and unfortunately I haven't :( Np, thanks for glancing :) I'd still like to ask for your Ack at least for the virtio_ids.h change (please see below, and for the full patch, see http://www.spinics.net/lists/linux-omap/msg59537.html): Anyone following our threads will know you approved it, but I'm still technically required to have your explicit ack as long as the patch isn't going through your tree. I can always add something like: Virtio_ids.h-change-acked-by: Rusty Russell ru...@rustcorp.com.au So it doesn't imply anything else but this specific change, or I can just put that hunk in a separate patch, and add then add your Acked-by (so it doesn't imply anything on the rest of the patch set). Does that sound reasonable to you ? Thanks, Ohad. diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 85bb0bb..b37c521 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -34,6 +34,7 @@ #define VIRTIO_ID_CONSOLE 3 /* virtio console */ #define VIRTIO_ID_RNG 4 /* virtio ring */ #define VIRTIO_ID_BALLOON 5 /* virtio balloon */ +#define VIRTIO_ID_RPMSG7 /* virtio remote processor messaging * #define VIRTIO_ID_9P 9 /* 9p virtio console */ #endif /* _LINUX_VIRTIO_IDS_H */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] amp/omap: add a remoteproc driver
Hi Tony, On Tue, Oct 25, 2011 at 11:48 AM, Ohad Ben-Cohen o...@wizery.com wrote: Add a remoteproc driver for OMAP4, so we can boot the dual-M3 Ducati and DSP subsystems. Use the omap_device_* API to control the hardware state, and utilize the OMAP mailbox to interrupt the remote processor when a new message is pending (the mailbox payload is used to tell it which virtqueue was the message placed in). Conversely, when an inbound mailbox message arrives, tell the remoteproc core which virtqueue is triggered. Later we will also use the mailbox payload to signal omap-specific events like remote crashes (which will be used to trigger remoteproc recovery) and power management transitions. At that point we will also extend the remoteproc core to support this. Based on (but now quite far from) work done by Fernando Guzman Lugo fernando.l...@ti.com and Hari Kanigeri h-kanige...@ti.com. Designed with Brian Swetland swetl...@google.com. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: Brian Swetland swetl...@google.com Cc: Arnd Bergmann a...@arndb.de Cc: Grant Likely grant.lik...@secretlab.ca Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: Rusty Russell ru...@rustcorp.com.au Cc: Andrew Morton a...@linux-foundation.org Cc: Greg KH g...@kroah.com Cc: Stephen Boyd sb...@codeaurora.org --- arch/arm/plat-omap/include/plat/remoteproc.h | 56 ++ drivers/amp/remoteproc/Kconfig | 21 +++ drivers/amp/remoteproc/Makefile | 4 +- drivers/amp/remoteproc/omap_remoteproc.c | 248 ++ drivers/amp/remoteproc/omap_remoteproc.h | 69 +++ 5 files changed, 397 insertions(+), 1 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h create mode 100644 drivers/amp/remoteproc/omap_remoteproc.c create mode 100644 drivers/amp/remoteproc/omap_remoteproc.h I'm about to add this to linux-next (minus the 'amp' wording); can I please have your Acked-by for this (at least for the plat-omap change) ? 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
