RE: [PATCH] usb: musb: Offmode fix for idle path
Hello,
-Original Message-
From: Sripathy, Vishwanath
Sent: Thursday, July 08, 2010 7:14 PM
To: Kalliguddi, Hema; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org
Cc: Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: RE: [PATCH] usb: musb: Offmode fix for idle path
Hema,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kalliguddi, Hema
Sent: Thursday, July 08, 2010 3:59 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Kalliguddi, Hema; Mankad, Maulik Ojas; Felipe Balbi;
Tony Lindgren; Kevin Hilman
Subject: [PATCH] usb: musb: Offmode fix for idle path
From: Hema HK hem...@ti.com
With OMAP coreoff support usb was not functional as context
was getting
lost after wakeup from coreoff. And also usb was blocking the coreoff
after loading the gadget driver even with no cable connected
sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not used, configure in force idle and
force standby mode.
When it is being used, configure in smart standby and smart
idle mode.
So while attempting to coreoff the usb is configured to
force standby and
force idle mode, after wakeup configured in smart idle and
smart standby.
Since clock used for musb is auto gated, there is no need to
specifically
enable/disable the clock. Removed enable/disable clock in
suspend resume api.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
Based off : Kevin pm branch.
arch/arm/mach-omap2/pm34xx.c |4
arch/arm/mach-omap2/usb-musb.c| 15 +++
arch/arm/plat-omap/include/plat/usb.h |2 ++
drivers/usb/musb/musb_core.c | 11 ---
drivers/usb/musb/omap2430.c | 32
5 files changed, 49 insertions(+), 15 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
=
==
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
@@ -431,6 +431,8 @@ void omap_sram_idle(void)
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+/* Save MUSB context */
+musb_context_save_restore(1);
Do you really need to save and restore USB context in every OS
Idle? Can't it be done on a need basis like when USB is connected?
No. There are some transperent PHYs in which the connect/disconnect events
are not reported as interrupts.
In that case there is no way know when to save and restore.
We can do the optimization of saving the context only when needed.
}
}
@@ -479,6 +481,8 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+/* Restore MUSB context */
+musb_context_save_restore(0);
/*
* Errata 1.164 fix : OTG autoidle can prevent
* sleep
Index: linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
=
==
--- linux-omap-pm.orig/arch/arm/mach-omap2/usb-musb.c
+++ linux-omap-pm/arch/arm/mach-omap2/usb-musb.c
@@ -177,6 +177,21 @@ void __init usb_musb_init(struct omap_mu
usb_musb_pm_init();
}
+void musb_context_save_restore(int save)
+{
+struct device *dev = musb_device.dev;
+struct device_driver *drv = dev-driver;
+if (dev-driver) {
+
+const struct dev_pm_ops *pm = drv-pm;
+
+if (save)
+pm-suspend(dev);
+else
+pm-resume_noirq(dev);
+}
+}
+
#else
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
Index: linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
=
==
--- linux-omap-pm.orig/arch/arm/plat-omap/include/plat/usb.h
+++ linux-omap-pm/arch/arm/plat-omap/include/plat/usb.h
@@ -82,6 +82,8 @@ extern void usb_ohci_init(const struct o
/* This is needed for OMAP3 errata 1.164: enabled autoidle
can prevent sleep */
extern void usb_musb_disable_autoidle(void);
+/* For saving and restoring the musb context during off/wakeup*/
+extern void musb_context_save_restore(int save);
#endif
void omap_usb_init(struct omap_usb_config *pdata);
Index: linux-omap-pm/drivers/usb/musb/musb_core.c
omap3 flash issue
While doing powercycles with an OMAP3 board I got several strange
effects on my board.
So even when mounting the root-partiton as read only ( ... noinitrd
root=/dev/mtdblock6 ro rootfstype=jffs2 ... ) I 've got sometimes (1
in a 100 trials) a bunch of message while mounting:
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0026:
0xff30 instead
And later on
JFFS2 notice: (365) jffs2_get_inode_nodes: Node header CRC failed at
0x260090. {6144,773c,840fc11a,cc0c0e28}
Another time I get a
uncorrectable error :
Which is coming from nand_ecc.c (this is below the filesystem I guess).
The strange thing is, this errors/messages are disappeared in the next boot.
I suspected the RAM/Flash hardware but on the other hand it unpacks
the kernel a few 100 times, but never get a CRC error.
Looking into kernel sources I found special omap2.c with some nand
related code. I am using a standard 2.6.33 kernel.
Does someone have a good advice what the reason for that might be. Any
help is welcome.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [ARM] video/omap2/tdo35s: fix visual artefacts
TDO35S samples the data on the falling adge of the pixel clock,
therefore the data strobe should be on the raising edge.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
.../video/omap2/displays/panel-toppoly-tdo35s.c|8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
index fa434ca..e320e67 100644
--- a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -73,8 +73,12 @@ static void toppoly_tdo_panel_power_off(struct
omap_dss_device *dssdev)
static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
{
- dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
- OMAP_DSS_LCD_IHS;
+ dssdev-panel.config = OMAP_DSS_LCD_TFT |
+ OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS |
+ OMAP_DSS_LCD_IPC |
+ OMAP_DSS_LCD_ONOFF;
+
dssdev-panel.timings = toppoly_tdo_panel_timings;
return 0;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [ARM] omap/board-cm-t35: fix visual artefacts
CM-T35 DVI transmitter sampling the data on the raising edge of the pixel clock, therefore the data strobe should happen on the falling edge. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Mike Rapoport m...@compulab.co.il --- arch/arm/mach-omap2/board-cm-t35.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index e679a2c..015ebf8 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -349,6 +349,8 @@ static int cm_t35_panel_enable_dvi(struct omap_dss_device *dssdev) return -EINVAL; } + dssdev-panel.config |= OMAP_DSS_LCD_IPC | OMAP_DSS_LCD_ONOFF; + gpio_set_value(dvi_en_gpio, 0); dvi_enabled = 1; -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap3: sr: improve errors handling
On Fri, 2010-07-09 at 16:20 +0300, Artem Bityutskiy wrote: From: Artem Bityutskiy artem.bityuts...@nokia.com Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Please, discard this patch, I'll send a new one with amended subject. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
Hello Thara,
On Fri, 2 Jul 2010 15:48:25 +0530
Thara Gopinath th...@ti.com wrote:
#include plat/common.h
@@ -38,21 +39,45 @@
*/
struct omap_opp_def {
char *hwmod_name;
+ char *vdd_name;
unsigned long freq;
unsigned long u_volt;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+
bool enabled;
};
It looks strange to me that per-OPP methods are needed to set/get the
rate. These should only be needed at the device level, no ?
And indeed, in your patch 6/7, for every device, the same get/set rate
methods are used for all OPPs of a given device.
+struct device_opp {
+ struct list_head node;
+ char *vdd_name;
+
+ struct omap_hwmod *oh;
+ struct device *dev;
+ struct omap_volt_domain *volt_domain;
+
+ struct list_head opp_list;
+ u32 opp_count;
+ u32 enabled_opp_count;
+
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
+};
I know this structure already exists, but do we really need a new
structure for this ? Couldn't these infos (OPP list, set/get rate
methods) be stored in an existing device-specific structure (omap_hwmod
for hardware-related things are omap_device for ~software-related
things) ?
For example, why aren't OPPs attached to the hwmod description of the
particular device ? These OPPs definitions really look like a
characteristic of a particular IP, don't they ?
Whatever choice is made, this structure probably needs a comment on top
of it explaining what it does, since the name isn't very obvious IMO.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug in onenand_base ?
Hello,
2010/7/8 Artem Bityutskiy dedeki...@gmail.com:
On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
Hello,
2010/7/8 Artem Bityutskiy dedeki...@gmail.com:
On Thu, 2010-07-08 at 11:55 +0200, Enric Balletbò i Serra wrote:
Hello,
I made new tests regarding this issue. Looks like the problem is
reading from the OneNAND device.
Did you try older kernel and then bisecting who is responsible for the
breakage?
Yes, before commit
5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5988af2319781bc8e0ce418affec4e09cfa77907
my OneNAND is working, after the commit, the OneNAND support is broken.
Ok, we could revert it, but it is better to fix it. CCing the author of
the commit.
Comparing the onenand_base.c file before commit
5988af2319781bc8e0ce418affec4e09cfa77907 (mtd: Flex-OneNAND support)
and after the commit I made a little patch which seems solves the
issue. The patch has two parts.
The first part replaces line 380 with 'page = (int) (addr
this-page_shift);' like before apply the Flex-OneNAND support. I
suppose this is not the better solution, but with this the nandtest
tool works for me. Maybe the author of the commit can clarify this.
The second part (1964) adds two lines which I think are missed when
the Flex-OneNAND support was applied.
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index 26caf25..a39d906 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -377,7 +377,7 @@ static int onenand_command(struct mtd_info *mtd,
int cmd, loff_t addr, size_t le
default:
block = onenand_block(this, addr);
- page = (int) (addr - onenand_addr(this, block))
this-page_shift;
+ page = (int) (addr this-page_shift);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
@@ -1961,6 +1961,9 @@ static int onenand_write_ops_nolock(struct
mtd_info *mtd, loff_t to,
/* In partial page write we don't update bufferram */
onenand_update_bufferram(mtd, to, !ret !subpage);
+ ONENAND_SET_BUFFERRAM1(this);
+ onenand_update_bufferram(mtd, to +
this-writesize, !ret !subpage);
+
if (ret) {
printk(KERN_ERR %s: write failed %d\n,
__func__, ret);
Best regards,
Enric
--
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: ARM defconfig files
Hi Linus, On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-König wrote: I think my mail hit your inbox during your vacation. As this is quite important for the ARM people and there isn't much time left, can you please comment? As you havn't replied up to now I wonder if that just means that you still plan to remove all defconfig files or if you are just busy doing other things. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
On Mon, 12 Jul 2010, Thomas Petazzoni wrote: I know this structure already exists, but do we really need a new structure for this ? Couldn't these infos (OPP list, set/get rate methods) be stored in an existing device-specific structure (omap_hwmod for hardware-related things are omap_device for ~software-related things) ? For example, why aren't OPPs attached to the hwmod description of the particular device ? These OPPs definitions really look like a characteristic of a particular IP, don't they ? hwmod data is intended to be used for RTL-level data, e.g., data that is invariant of the underlying process technology. OPP data can vary by the underlying fabrication process or per-die speed validation (e.g., speed-binning). So I don't think it belongs in the hwmod data. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
musb_hdrc: usb_disconnect is not called when the USB device is disconnected.
Hello, When I disconnect an USB pendrive using twl4030 otg as host (step 2) the usb_disconnect function is not called. OTOH if I reconnect the device (step 3), then the usb_disconnect function is called. Does anyone have any ideas why usb_disconnect is not called when the device is removed? Steps to see the feature: Step 1 : Plug a USB pendrive: [ 2116.491546] usb 1-1: new high speed USB device using musb_hdrc and address 6 [ 2116.751861] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2116.758697] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2116.765899] usb 1-1: Product: Mass Storage [ 2116.770019] usb 1-1: Manufacturer: 2.0 [ 2116.773834] usb 1-1: SerialNumber: A15B7B60 [ 2116.786468] scsi4 : usb-storage 1-1:1.0 [ 2117.797332] scsi 4:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2117.813293] sd 4:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 2117.829040] sd 4:0:0:0: [sda] Write Protect is off [ 2117.834014] sd 4:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2117.834014] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.849212] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.856597] sda: sda1 [ 2117.965698] sd 4:0:0:0: [sda] Assuming drive cache: write through [ 2117.971954] sd 4:0:0:0: [sda] Attached SCSI removable disk [ 2118.738769] FAT: bogus number of reserved sectors [ 2118.743621] VFS: Can't find a valid FAT filesystem on dev sda. Step 2: Unplug the USB pendrive [ nothing here ] Step 3: Plug the USB pendrive: [ 2218.820556] usb 1-1: USB disconnect, address 6 [ 2219.139831] usb 1-1: new high speed USB device using musb_hdrc and address 7 [ 2219.400146] usb 1-1: New USB device found, idVendor=058f, idProduct=6387 [ 2219.406951] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2219.414184] usb 1-1: Product: Mass Storage [ 2219.418304] usb 1-1: Manufacturer: 2.0 [ 2219.422119] usb 1-1: SerialNumber: A15B7B60 [ 2219.434875] scsi5 : usb-storage 1-1:1.0 [ 2220.445770] scsi 5:0:0:0: Direct-Access 2.0 Flash Disk 8.07 PQ: 0 ANSI: 2 [ 2220.461547] sd 5:0:0:0: [sda] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 2220.476379] sd 5:0:0:0: [sda] Write Protect is off [ 2220.481323] sd 5:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 2220.481323] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.497314] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.504516] sda: sda1 [ 2220.603790] sd 5:0:0:0: [sda] Assuming drive cache: write through [ 2220.610015] sd 5:0:0:0: [sda] Attached SCSI removable disk [ 2221.378570] FAT: bogus number of reserved sectors [ 2221.383453] VFS: Can't find a valid FAT filesystem on dev sda. Thanks in advance, Enric -- 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: device: improve errors handling
On Mon, 12 Jul 2010, Artem Bityutskiy wrote: From: Artem Bityutskiy artem.bityuts...@nokia.com Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Looks fine to me, platform_device_add_data() can return -ENOMEM in the unlikely event that its kmemdup() fails. Acked-by: Paul Walmsley p...@pwsan.com Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com Acked-by: Nishanth Menon n...@ti.com --- arch/arm/plat-omap/omap_device.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index ea0d659..d2b1609 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -407,7 +407,9 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id, od-pdev.num_resources = res_count; od-pdev.resource = res; - platform_device_add_data(od-pdev, pdata, pdata_len); + ret = platform_device_add_data(od-pdev, pdata, pdata_len); + if (ret) + goto odbs_exit4; od-pm_lats = pm_lats; od-pm_lats_cnt = pm_lats_cnt; -- 1.7.1.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: device: improve errors handling
Tony, by the way, On Mon, 12 Jul 2010, Paul Walmsley wrote: On Mon, 12 Jul 2010, Artem Bityutskiy wrote: From: Artem Bityutskiy artem.bityuts...@nokia.com Do not forget to check the 'platform_device_add_data()' error code in 'omap_device_build_ss()'. Looks fine to me, platform_device_add_data() can return -ENOMEM in the unlikely event that its kmemdup() fails. Acked-by: Paul Walmsley p...@pwsan.com you want to take this one, or want me to queue it up for .37? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 Uwe Kleine-König u.kleine-koe...@pengutronix.de: As you havn't replied up to now I wonder if that just means that you still plan to remove all defconfig files or if you are just busy doing other things. The reason I haven't replied is that (a) I don't think this really solves the issue, in that the resulting files still aren't human-readable, and as such I suspect it doesn't solve the problem in the long run: people will continue to just run make config and then copy the resulting .config file as a defconfig file. and (b) even if ARM were to go this way, and run the scripts to minimize the defconfig files, that's not something _I_ would do. If I get tired of seeing the insane pull requests where 90% of the crap is just defconfig noise, then _my_ solution will be to remove the crap because I simply am never going to be the person who maintains those defconfig files. See? Especially the (b) part is relevant - I am simply not going to be the person who tries to clean up after other people sh*tting all over their trees with defconfig files. If I do something, it will be total surgery, ie keep your damn broken defconfig files somewhere else than in my tree - I'm tired of your stupidities. It will not be I'll be your mother and clean up your room every day after you made a mess. So if the ARM people decide that your script is a good way to clean up the mess, I might be happy with that. But that would require that they NEVER EVER try to push me a update that contains an un-cleaned-up defconfig file. If they do, and the defconfig files end up showing up big in git history, then the approach has failed. See? The reason I'm not replying to your approach is that it's simply not for me to do so (and no, I don't think it's maintainable, but I haven't tried it, so..) Linus -- 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: ARM defconfig files
On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote: So if the ARM people decide that your script is a good way to clean up the mess, I might be happy with that. But that would require that they NEVER EVER try to push me a update that contains an un-cleaned-up defconfig file. Does this mean that you aren't going to delete all the defconfigs during the next merge window if we come up with an alternative solution to yours? When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. -- 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: ARM defconfig files
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. There are always other solutions. I seriously doubt that Uwe's is a maintainable one. That said, even a one-time reduce the size of that stinking pile of sh*t is probably better than nothing. I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. Linus -- 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: ARM defconfig files
Hello Linus, On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. There are always other solutions. I seriously doubt that Uwe's is a maintainable one. That said, even a one-time reduce the size of that stinking pile of sh*t is probably better than nothing. I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. If it helps the powerpc people I can reduce their defconfigs, too. Best regards Uwe [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 Uwe Kleine-König (1): ARM: reduce defconfigs arch/arm/configs/acs5k_defconfig | 1146 -- arch/arm/configs/acs5k_tiny_defconfig | 860 -- arch/arm/configs/afeb9260_defconfig| 1157 +-- arch/arm/configs/am200epdkit_defconfig | 1044 + arch/arm/configs/am3517_evm_defconfig | 1250 --- arch/arm/configs/ams_delta_defconfig | 1224 +-- arch/arm/configs/ap4evb_defconfig | 722 - arch/arm/configs/assabet_defconfig | 862 +-- arch/arm/configs/at572d940hfek_defconfig | 1318 +--- arch/arm/configs/at91cap9adk_defconfig | 1107 +- arch/arm/configs/at91rm9200dk_defconfig| 955 +--- arch/arm/configs/at91rm9200ek_defconfig| 942 +--- arch/arm/configs/at91sam9260ek_defconfig | 958 +--- arch/arm/configs/at91sam9261ek_defconfig | 1087 +- arch/arm/configs/at91sam9263ek_defconfig | 1103 +- arch/arm/configs/at91sam9g20ek_defconfig | 1049 + arch/arm/configs/at91sam9rlek_defconfig| 864 +-- arch/arm/configs/ateb9200_defconfig| 1222 +-- arch/arm/configs/badge4_defconfig | 1178 +-- arch/arm/configs/bcmring_defconfig | 721 - arch/arm/configs/cam60_defconfig | 1089 +- arch/arm/configs/carmeva_defconfig | 696 + arch/arm/configs/cerfcube_defconfig| 851 +-- arch/arm/configs/cm_t35_defconfig | 1577 +-- arch/arm/configs/cm_x2xx_defconfig | 1774 +- arch/arm/configs/cm_x300_defconfig | 1565 -- arch/arm/configs/cns3420vb_defconfig | 759 - arch/arm/configs/colibri_pxa270_defconfig | 1556 -- arch/arm/configs/colibri_pxa300_defconfig | 1082 - arch/arm/configs/collie_defconfig | 887 +-- arch/arm/configs/corgi_defconfig | 1621 +--- arch/arm/configs/cpu9260_defconfig | 1225 +-- arch/arm/configs/cpu9g20_defconfig | 1215 +-- arch/arm/configs/cpuat91_defconfig | 1207 +-- arch/arm/configs/csb337_defconfig | 1113 +- arch/arm/configs/csb637_defconfig | 1124 +- arch/arm/configs/da8xx_omapl_defconfig | 1205 -- arch/arm/configs/davinci_all_defconfig | 1641 --- arch/arm/configs/devkit8000_defconfig | 1732 + arch/arm/configs/dove_defconfig| 1482 - arch/arm/configs/ebsa110_defconfig | 692 + arch/arm/configs/ecbat91_defconfig | 1226 +-- arch/arm/configs/edb7211_defconfig | 554 +--- arch/arm/configs/em_x270_defconfig | 1554 +-- arch/arm/configs/ep93xx_defconfig | 1340 arch/arm/configs/eseries_pxa_defconfig | 1128 - arch/arm/configs/ezx_defconfig | 1582 +--- arch/arm/configs/footbridge_defconfig | 1185 +-- arch/arm/configs/fortunet_defconfig| 538 +--- arch/arm/configs/g3evm_defconfig | 717 - arch/arm/configs/g4evm_defconfig
Re: ARM defconfig files
2010/7/12 Uwe Kleine-König u.kleine-koe...@pengutronix.de: I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. Well, I can hardly refuse a pull that removes almost 200k lines. So I'd happily pull it. Just this single line in your email is a very very powerful thing: 177 files changed, 652 insertions(+), 194157 deletions(-) However, before I would pull, I'd definitely like to make sure we at least have some way forward too, and clarify some issues. So I have a couple of questions: - is this guaranteed to be a no-op as things stand now, and what are the secondary effects of it? Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. - what happens when somebody wants to update the defconfig files? This is a question that involves a number of people, because over the last half year, we've had lots of people changing them. git shortlog -ns on that ARM config directory gives 39 people in the last half year, with the top looking roughly like 26 Ben Dooks 10 Tony Lindgren 4 Haojian Zhuang 4 Kukjin Kim 3 Santosh Shilimkar 3 Sriram 2 Janusz Krzysztofik and how are these people going to do their updates going forward without re-introducing the noise? IOW, I'd _love_ to get rid of almost 200k lines of noise and your approach would seem to have the advantage that it's invisible to users. But I would want to get some kind of assurance that it's practical to do so. Linus -- 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: ARM defconfig files
On Mon, 12 Jul 2010, Uwe Kleine-König wrote: On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: I hope you at least do agree that the current situation is a steaming pile of sh*t. And yes, I _will_ remove the crap, both from POWER and ARM, unless I see some serious tries at fixing it. We all agree this is a pile of sh*t, as the truly valuable data is drawned down into it. The diffstat numbers below certainly shows it rather clearly. Linus, please pull this git tree. This should functionally be a no op, while giving us a better footing to develop a final solution. I'm willing to try my solution, some others on the linux-arm-kernel lists considered it worth trying, too. Feel free to pull my tree[1]. Russell refused to take defconfig changes for a while now, so I don't expect merge problems if you do. ACK. If it helps the powerpc people I can reduce their defconfigs, too. Best regards Uwe [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 Uwe Kleine-König (1): ARM: reduce defconfigs arch/arm/configs/acs5k_defconfig | 1146 -- arch/arm/configs/acs5k_tiny_defconfig | 860 -- arch/arm/configs/afeb9260_defconfig| 1157 +-- arch/arm/configs/am200epdkit_defconfig | 1044 + arch/arm/configs/am3517_evm_defconfig | 1250 --- arch/arm/configs/ams_delta_defconfig | 1224 +-- arch/arm/configs/ap4evb_defconfig | 722 - arch/arm/configs/assabet_defconfig | 862 +-- arch/arm/configs/at572d940hfek_defconfig | 1318 +--- arch/arm/configs/at91cap9adk_defconfig | 1107 +- arch/arm/configs/at91rm9200dk_defconfig| 955 +--- arch/arm/configs/at91rm9200ek_defconfig| 942 +--- arch/arm/configs/at91sam9260ek_defconfig | 958 +--- arch/arm/configs/at91sam9261ek_defconfig | 1087 +- arch/arm/configs/at91sam9263ek_defconfig | 1103 +- arch/arm/configs/at91sam9g20ek_defconfig | 1049 + arch/arm/configs/at91sam9rlek_defconfig| 864 +-- arch/arm/configs/ateb9200_defconfig| 1222 +-- arch/arm/configs/badge4_defconfig | 1178 +-- arch/arm/configs/bcmring_defconfig | 721 - arch/arm/configs/cam60_defconfig | 1089 +- arch/arm/configs/carmeva_defconfig | 696 + arch/arm/configs/cerfcube_defconfig| 851 +-- arch/arm/configs/cm_t35_defconfig | 1577 +-- arch/arm/configs/cm_x2xx_defconfig | 1774 +- arch/arm/configs/cm_x300_defconfig | 1565 -- arch/arm/configs/cns3420vb_defconfig | 759 - arch/arm/configs/colibri_pxa270_defconfig | 1556 -- arch/arm/configs/colibri_pxa300_defconfig | 1082 - arch/arm/configs/collie_defconfig | 887 +-- arch/arm/configs/corgi_defconfig | 1621 +--- arch/arm/configs/cpu9260_defconfig | 1225 +-- arch/arm/configs/cpu9g20_defconfig | 1215 +-- arch/arm/configs/cpuat91_defconfig | 1207 +-- arch/arm/configs/csb337_defconfig | 1113 +- arch/arm/configs/csb637_defconfig | 1124 +- arch/arm/configs/da8xx_omapl_defconfig | 1205 -- arch/arm/configs/davinci_all_defconfig | 1641 --- arch/arm/configs/devkit8000_defconfig | 1732 + arch/arm/configs/dove_defconfig| 1482 - arch/arm/configs/ebsa110_defconfig | 692 + arch/arm/configs/ecbat91_defconfig | 1226 +-- arch/arm/configs/edb7211_defconfig | 554 +--- arch/arm/configs/em_x270_defconfig | 1554 +-- arch/arm/configs/ep93xx_defconfig | 1340 arch/arm/configs/eseries_pxa_defconfig | 1128 - arch/arm/configs/ezx_defconfig | 1582 +--- arch/arm/configs/footbridge_defconfig | 1185 +-- arch/arm/configs/fortunet_defconfig| 538 +--- arch/arm/configs/g3evm_defconfig | 717 - arch/arm/configs/g4evm_defconfig | 722 - arch/arm/configs/h3600_defconfig | 1084 - arch/arm/configs/h5000_defconfig |
Re: ARM defconfig files
On Mon, 12 Jul 2010, Linus Torvalds wrote: I'd happily pull it. Just this single line in your email is a very very powerful thing: 177 files changed, 652 insertions(+), 194157 deletions(-) However, before I would pull, I'd definitely like to make sure we at least have some way forward too, and clarify some issues. So I have a couple of questions: - is this guaranteed to be a no-op as things stand now, and what are the secondary effects of it? Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious issue should be noticed right away. - what happens when somebody wants to update the defconfig files? This is a question that involves a number of people, because over the last half year, we've had lots of people changing them. git shortlog -ns on that ARM config directory gives 39 people in the last half year, with the top looking roughly like 26 Ben Dooks 10 Tony Lindgren 4 Haojian Zhuang 4 Kukjin Kim 3 Santosh Shilimkar 3 Sriram 2 Janusz Krzysztofik and how are these people going to do their updates going forward without re-introducing the noise? IOW, I'd _love_ to get rid of almost 200k lines of noise and your approach would seem to have the advantage that it's invisible to users. But I would want to get some kind of assurance that it's practical to do so. I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Nicolas -- 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: ARM defconfig files
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote: Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious issue should be noticed right away. You aren't really answering the question. The thing is, the wholesale removal wouldn't happen during the late -rc anyway, and it wouldn't cause any merge issues (merge conflicts where the file is just to be removed are trivial to take care of). So I'm really asking about the issue of how does this work during the late -rc phase. Where the _timing_ is the important thing. Because I could as easily pull after 2.6.35 is out. That has it's own downsides (with all the merging going on), but at the same time, it's clearly the right time for a large change. So when I ask about timing and how does this work in late -rc, it's really about how safe it is to do now. Because if it isn't very obviously safe, I can't pull it. One part of the obviously safe thing is verification for each defconfig file that the end result is identical with the reduced version. Uwe implied that it was, and that was clearly the intention, but was there some explicit verification that yes, the before-and-after configurations are 100% the same? Also, I assume that while it's _mostly_ a transparent change to users, it does require that people do make oldconfig with the reduced defconfig file first, in order to avoid having to answer with the defaults. No? And the reduced defconfig files obviously do depend on the default in the Kconfig files themselves, so it does have that kind of fairly subtle semantic change that may not be entirely obvious or easy to notice. So from a timing standpoint, I just want to be convinced that late -rc really is the right thing. I'm not entirely sure it is, even though I do see advantages. I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. I also haven't actually seen the script - I don't think Uwe ever posted it - so maybe it's some very fragile thing. Hard to judge on no real information ;^p Linus -- 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: ARM defconfig files
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote: I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. I can (partially) speak for powerpc. If ARM uses this approach, then I think we can do the same. After the defconfigs are trimmed, I certainly won't pick up any more full defconfigs. Of course, I'm also operating under the assumption that this is a temporary measure until one of the better solutions is implemented. I do suspect that the trimmed defconfigs will tend to be unstable and will still require manual maintenance. I think the Kconfig fragments approach is the most promising if the dependencies issue can be solved. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
Hi Linus,
On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote:
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
Put another way: I realize that fairly late in the -rc series is
actually a really good time to do this, rather than during the merge
window itself when things are in flux. However, while it would be a
good time to pull this for that reason, it's also a _horrible_ time to
pull if it then regresses the defconfig uses, or if it causes horrible
problems for linux-next merging etc.
This cannot be any worse than wholesale removal of those files as you
were contemplating at some point. Furthermore, on ARM we have someone
providing automatic rebuild of all defconfigs already, so any serious
issue should be noticed right away.
You aren't really answering the question. The thing is, the wholesale
removal wouldn't happen during the late -rc anyway, and it wouldn't
cause any merge issues (merge conflicts where the file is just to be
removed are trivial to take care of).
So I'm really asking about the issue of how does this work during the
late -rc phase. Where the _timing_ is the important thing.
Because I could as easily pull after 2.6.35 is out. That has it's own
downsides (with all the merging going on), but at the same time, it's
clearly the right time for a large change.
I hoped you to pull this in during the merge window, but doing it now is
OK for me, too.
So when I ask about timing and how does this work in late -rc, it's
really about how safe it is to do now. Because if it isn't very
obviously safe, I can't pull it.
One part of the obviously safe thing is verification for each
defconfig file that the end result is identical with the reduced
version. Uwe implied that it was, and that was clearly the intention,
but was there some explicit verification that yes, the
before-and-after configurations are 100% the same?
I'm pretty sure it's 100% save as I only kick a line in the defconfig if
the result doesn't change. Well, modulo bugs in my script. But now
that it's public you can convince yourself it's (hopefully) correct.
Also, I assume that while it's _mostly_ a transparent change to users,
it does require that people do make oldconfig with the reduced
defconfig file first, in order to avoid having to answer with the
defaults. No?
No, $(make ..._defconfig) is enough to get the full .config.
And the reduced defconfig files obviously do depend on
the default in the Kconfig files themselves, so it does have that kind
of fairly subtle semantic change that may not be entirely obvious or
easy to notice.
Right.
So from a timing standpoint, I just want to be convinced that late
-rc really is the right thing. I'm not entirely sure it is, even
though I do see advantages.
I think Uwe could provide his script and add it to the kernel tree.
Then all architectures could benefit from it. Having the defconfig
files contain only those options which are different from the defaults
is certainly more readable, even on x86.
Quite possible. But maintainers would need to be on the lookout of
people actually using the script, and refusing to apply patches that
re-introduce the whole big thing.
I also haven't actually seen the script - I don't think Uwe ever
posted it - so maybe it's some very fragile thing. Hard to judge on no
real information ;^p
See attachment. It's just:
for each line:
kick $line if $(make ..._defconfig) results in the same config
without $line
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-König u.kleine-koe...@pengutronix.de
import re
import subprocess
import os
import sys
# This prevents including a timestamp in the .config which makes comparing a
# bit easier.
os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please'
# XXX: get these using getopt
kernel_tree = '' # os.path.join(os.environ['HOME'], 'gsrc', 'linux-2.6')
arch = 'arm'
target = sys.argv[1]
defconfig_src = os.path.join(kernel_tree, 'arch/%s/configs/%s' % (arch, target))
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
origconfig = list(open('.config'))
config = list(origconfig)
config_size = os.stat('.config').st_size
i = 0
while i len(config):
print 'test for %r' % config[i]
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + 1:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) ==
origconfig:
del config[i]
else:
i += 1
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config)
defconfig.close()
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote: On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. That's not true. What's true is that you didn't seem to _understand_ my solution, so I tried to push the understanding of it. That's your point of view. My viewpoint was that I had read your email, thought of some alternative solution, proposed it and the result was shot down without any apparant thought about it. That gave the impression that you _only_ wanted to see your own solution. The result of that has been very little in the way of progress towards either your, or my alternative solutions - and apart from a few Kconfig corner quirk patches, the only major work that's happened has been from Uwe. So in that regard, I support Uwe's patches as a means to prevent the impending loss of build coverage from facilities such as linux-next and the ARM kernel autobuilder, as that's the only option that's currently available. As far as timing goes, I see no reason for it to be merged during -rc. As has already been said, I'm intending _not_ to make the defconfig situation any worse by accepting patches which add to the mess, as I'm also mindful that its exactly those kinds of patches are the cause of this problem. Now, I'm happy to take Uwe's tree through mine for the next merge window _iff_ you find his solution acceptable, and you want that to happen. I'll also use this opportunity to warn you now - especially as you also complained about the amount of churn. There is an effort to try to allow a single ARM kernel to boot on a wider range of platforms with more differences than it currently does. This is going to mean a certain amount of restructuring, and a lot of additional patches over time to gradually convert the code. So, I'm expecting that there will be even _more_ patches - some fairly big - to come over the next year or so. To give an idea - if we change the structure which defines a machine's properties, we're going to be changing 348 files under arch/arm to match. Clearly that's also going to give you a problem with diffstat being swamped. -- 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: ARM defconfig files
On Mon, 12 Jul 2010, Linus Torvalds wrote: On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote: Put another way: I realize that fairly late in the -rc series is actually a really good time to do this, rather than during the merge window itself when things are in flux. However, while it would be a good time to pull this for that reason, it's also a _horrible_ time to pull if it then regresses the defconfig uses, or if it causes horrible problems for linux-next merging etc. This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious issue should be noticed right away. You aren't really answering the question. The thing is, the wholesale removal wouldn't happen during the late -rc anyway, and it wouldn't cause any merge issues (merge conflicts where the file is just to be removed are trivial to take care of). I'll answer for myself only. Others are free to pitch in if they have a different opinion. Since this issue came up, RMK refused to merge any changes to the arch/arm/configs directory. Therefore a lot of those files aren't quite up to date anymore anyway. We simply skipped the usual defconfig updates that used to be sent around -rc4. And that's for the few defconfig files that people cared to update. A bunch of less frequently used targets are probably out of date since many kernel versions ago. Those files are mainly used as a convenience for build testing. We tend to cram as many profiles together as we can to limit the number of different test builds. The remaining files are (supposed to be) incompatible configurations. So I doubt anyone is using them verbatim for deployed systems. If anything they should be reference configurations not final product ones. So I'm really asking about the issue of how does this work during the late -rc phase. Where the _timing_ is the important thing. Given what I said above, I think that: 1) Those files aren't critical. They're damn useful indeed, but a glitch in a defconfig file is far from being as important as a glitch in the very code they refer to. So I don't think this is all that critical if the pull is applied late in the -rc period. 2) Doing it sooner rather than later is IMHO the best thing to do. At least we could now focus on maintaining and even improving on that state rather than going on in circles wondering what to do with it. People would be able to think about how to update their defconfig files in the new form now instead of simply not updating it at all as it has been the case for a while until something happens. So to me this is all in favor for a merge before next merge window. During the merge window this would create even more headaches. So when I ask about timing and how does this work in late -rc, it's really about how safe it is to do now. Because if it isn't very obviously safe, I can't pull it. As I said above, those files aren't that critical and no one should end up in trouble if something is not exactly right after this merge. So this makes it pretty safe to me. One part of the obviously safe thing is verification for each defconfig file that the end result is identical with the reduced version. Uwe implied that it was, and that was clearly the intention, but was there some explicit verification that yes, the before-and-after configurations are 100% the same? I'll let Uwe answer this. Also, I assume that while it's _mostly_ a transparent change to users, it does require that people do make oldconfig with the reduced defconfig file first, in order to avoid having to answer with the defaults. No? And the reduced defconfig files obviously do depend on the default in the Kconfig files themselves, so it does have that kind of fairly subtle semantic change that may not be entirely obvious or easy to notice. That is going to be the case regardless of the merge timing for this. So from a timing standpoint, I just want to be convinced that late -rc really is the right thing. I'm not entirely sure it is, even though I do see advantages. I do too. At least this is positive progress for some bad issue that no one could ever get very passionate about. Better keep the momentum. I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Quite possible. But maintainers would need to be on the lookout of people actually using the script, and refusing to apply patches that re-introduce the whole big thing. Pretty easy to see on the diffstat graph. Anyway, I'm sure once the script is available then an army of kernel janitors will be busy trying to find
Re: [PATCH resend] omap: 3630: disable TLL SAR on 3630 ES1
On Sat, 10 Jul 2010, Anand Gadiyar wrote: USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it enabled could result in incorrect register restores as the OMAP exits off-mode. This could potentially result in unexpected wakeup events. This is fixed in ES1.1. So disable it for ES1.0s. Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Paul Walmsley p...@pwsan.com --- This is a fix for buggy hardware, and it would be nice to see this in the next merge window too. Depends on the patch I just posted which adds the CHIP_GE_OMAP3630ES1_1 macro https://patchwork.kernel.org/patch/47/ Verified against the OMAP3630 errata PDF from June 16. Anand, could you please add an erratum ID to the commit message or to a comment in the code? Tony, once Anand does that, it's Acked-by: Paul Walmsley p...@pwsan.com if you want it for .36; otherwise, for .37, I'd be happy to queue it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2: powerdomain: Add break in switch statement
On Fri, 9 Jul 2010, Thomas Weber wrote: Add a missing break at end of switch statement. At the moment it is a fall through to WARN_ON(1) and return -EEXIST. Signed-off-by: Thomas Weber we...@corscience.de Thanks Thomas. Tony, this is Acked-by: Paul Walmsley p...@pwsan.com if you want it for .36; otherwise, can queue it for .37 here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote: [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 BTW, looking at the most common entries in there, I think we might at some point want to change some of the defaults in the respective Kconfig files. Right now an empty defconfig would result in a configuration without file system, networking or modules: sort arch/arm/configs/* | uniq -c | sort -n | tail -n 30 114 CONFIG_BLK_DEV_RAM=y 116 CONFIG_BLK_DEV_INITRD=y 116 CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug 117 CONFIG_NFS_FS=y 118 CONFIG_MTD_CHAR=y 119 CONFIG_INOTIFY=y 122 # CONFIG_BLK_DEV_BSG is not set 122 CONFIG_IP_PNP=y 123 # CONFIG_IPV6 is not set 123 CONFIG_MTD_BLOCK=y 125 CONFIG_FPE_NWFPE=y 127 CONFIG_NET_ETHERNET=y 128 CONFIG_LOG_BUF_SHIFT=14 128 CONFIG_MTD=y 131 CONFIG_PACKET=y 132 # CONFIG_INPUT_MOUSE is not set 133 CONFIG_DEBUG_KERNEL=y 134 CONFIG_EXT2_FS=y 138 CONFIG_MODULE_UNLOAD=y 139 CONFIG_TMPFS=y 142 CONFIG_NETDEVICES=y 147 CONFIG_ZBOOT_ROM_BSS=0x0 147 CONFIG_ZBOOT_ROM_TEXT=0x0 151 CONFIG_INET=y 151 CONFIG_UNIX=y 153 CONFIG_NET=y 156 # CONFIG_VGA_CONSOLE is not set 158 CONFIG_MODULES=y 164 CONFIG_SYSVIPC=y 174 CONFIG_EXPERIMENTAL=y Also, some of the defconfigs contain stuff that arguably does not belong into a defconfig and could be removed in the next merge window, e.g. ezx_defconfig:CONFIG_LOCALVERSION=-ezx200910312315 pnx4008_defconfig:CONFIG_DECNET=m at572d940hfek_defconfig:CONFIG_SGI_PARTITION=y Arnd -- 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: ARM defconfig files
On Mon, 12 Jul 2010, Arnd Bergmann wrote: On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote: [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e: Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1 BTW, looking at the most common entries in there, I think we might at some point want to change some of the defaults in the respective Kconfig files. Right now an empty defconfig would result in a configuration without file system, networking or modules: We need to come up with a scheme that allows for expressing the most likely options you might want if you have machine x and/or machine y selected. Those likely options are for drivers corresponding to hardware soldered on the board or integrated into a SOC and therefore which is not optional. Right now this information is carried in the defconfig files. Without that you need to lookup various datasheets and wade through thousands of Kconfig options. Compared to that, stuff like filesystems and networking protocols are optional items that currently are more arbitrarily included into or excluded from the defconfig files. I think that the first category of options should automatically be selected on a per machine basis depending on BASE_CONFIG or the like and expressed directly in the Kconfig files. Typically there are very few of those (like a dozen or so for some example target I looked at). Nicolas
Re: ARM defconfig files
On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre n...@fluxnic.net wrote: For the record, I do support Uwe's work too. I do wish it could go in now so that from that point going forward we could only focus on improving the thing instead of having to care about implications during the merge window. Ok, I merged it. I do love the diffstat. And while it may not be optimal or a final solution, nobody seems to hate it either. Linus -- 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 01/11] staging: tidspbridge: remove custom TRUE FALSE
bool has standard true and false, we dont need to introduce
our own TRUE and FALSE macros.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c |6 +++---
.../staging/tidspbridge/dynload/dload_internal.h |3 ---
drivers/staging/tidspbridge/dynload/header.h |2 --
drivers/staging/tidspbridge/gen/gb.c |2 +-
drivers/staging/tidspbridge/hw/GlobalTypes.h | 10 --
.../staging/tidspbridge/include/dspbridge/dbtype.h | 11 ---
drivers/staging/tidspbridge/pmgr/dbll.c|4 ++--
drivers/staging/tidspbridge/pmgr/dmm.c |2 +-
drivers/staging/tidspbridge/rmgr/node.c|2 +-
9 files changed, 8 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 60fca91..25c1271 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1863,10 +1863,10 @@ bool wait_for_start(struct bridge_dev_context
*dev_context, u32 dw_sync_addr)
while (*((volatile u16 *)dw_sync_addr) --timeout)
udelay(10);
- /* If timed out: return FALSE */
+ /* If timed out: return false */
if (!timeout) {
pr_err(%s: Timed out waiting DSP to Start\n, __func__);
- return FALSE;
+ return false;
}
- return TRUE;
+ return true;
}
diff --git a/drivers/staging/tidspbridge/dynload/dload_internal.h
b/drivers/staging/tidspbridge/dynload/dload_internal.h
index 8037561..5a17e6c 100644
--- a/drivers/staging/tidspbridge/dynload/dload_internal.h
+++ b/drivers/staging/tidspbridge/dynload/dload_internal.h
@@ -23,9 +23,6 @@
* Internal state definitions for the dynamic loader
*/
-#define TRUE 1
-#define FALSE 0
-
/* type used for relocation intermediate results */
typedef s32 rvalue;
diff --git a/drivers/staging/tidspbridge/dynload/header.h
b/drivers/staging/tidspbridge/dynload/header.h
index 5cef360..04623f1 100644
--- a/drivers/staging/tidspbridge/dynload/header.h
+++ b/drivers/staging/tidspbridge/dynload/header.h
@@ -14,8 +14,6 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*/
-#define TRUE 1
-#define FALSE 0
#ifndef NULL
#define NULL 0
#endif
diff --git a/drivers/staging/tidspbridge/gen/gb.c
b/drivers/staging/tidspbridge/gen/gb.c
index f1a9dd3..d007233 100644
--- a/drivers/staging/tidspbridge/gen/gb.c
+++ b/drivers/staging/tidspbridge/gen/gb.c
@@ -161,7 +161,7 @@ bool gb_test(struct gb_t_map *map, u32 bitn)
mask = 1L (bitn % BITS_PER_LONG);
word = map-words[bitn / BITS_PER_LONG];
- state = word mask ? TRUE : FALSE;
+ state = word mask ? true : false;
return state;
}
diff --git a/drivers/staging/tidspbridge/hw/GlobalTypes.h
b/drivers/staging/tidspbridge/hw/GlobalTypes.h
index 9b55150..ba045eb 100644
--- a/drivers/staging/tidspbridge/hw/GlobalTypes.h
+++ b/drivers/staging/tidspbridge/hw/GlobalTypes.h
@@ -20,16 +20,6 @@
#define _GLOBALTYPES_H
/*
- * Definition: TRUE, FALSE
- *
- * DESCRIPTION: Boolean Definitions
- */
-#ifndef TRUE
-#define FALSE 0
-#define TRUE (!(FALSE))
-#endif
-
-/*
* Definition: NULL
*
* DESCRIPTION: Invalid pointer
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h
b/drivers/staging/tidspbridge/include/dspbridge/dbtype.h
index de65a82..0b2cb93 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dbtype.h
@@ -42,17 +42,6 @@
#endif
/*===*/
-/* Boolean constants */
-/*===*/
-
-#ifndef FALSE
-#define FALSE 0
-#endif
-#ifndef TRUE
-#define TRUE1
-#endif
-
-/*===*/
/* NULL(Definition is language specific) */
/*===*/
diff --git a/drivers/staging/tidspbridge/pmgr/dbll.c
b/drivers/staging/tidspbridge/pmgr/dbll.c
index 3636aa3..3a50071 100644
--- a/drivers/staging/tidspbridge/pmgr/dbll.c
+++ b/drivers/staging/tidspbridge/pmgr/dbll.c
@@ -1225,7 +1225,7 @@ static int dbll_rmm_alloc(struct dynamic_loader_allocate
*this,
int status = 0;
u32 mem_sect_type;
struct rmm_addr rmm_addr_obj;
- s32 ret = TRUE;
+ s32 ret = true;
unsigned stype = DLOAD_SECTION_TYPE(info-type);
char *token = NULL;
char *sz_sec_last_token = NULL;
@@ -1314,7 +1314,7 @@ func_cont:
rmm_handle, mem_sect_type,
alloc_size, align,
(u32 *) rmm_addr_obj,
-
[PATCH 06/11] staging: tidspbridge: remove GlobalTypes.h
Remove custom globaltypes.h header Signed-off-by: Nishanth Menon n...@ti.com --- drivers/staging/tidspbridge/hw/GlobalTypes.h | 289 -- drivers/staging/tidspbridge/hw/MMURegAcM.h |1 - drivers/staging/tidspbridge/hw/hw_defs.h |2 - drivers/staging/tidspbridge/hw/hw_mmu.c | 32 --- 4 files changed, 0 insertions(+), 324 deletions(-) delete mode 100644 drivers/staging/tidspbridge/hw/GlobalTypes.h diff --git a/drivers/staging/tidspbridge/hw/GlobalTypes.h b/drivers/staging/tidspbridge/hw/GlobalTypes.h deleted file mode 100644 index 2f8e69b..000 --- a/drivers/staging/tidspbridge/hw/GlobalTypes.h +++ /dev/null @@ -1,289 +0,0 @@ -/* - * GlobalTypes.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * Global HW definitions - * - * Copyright (C) 2007 Texas Instruments, Inc. - * - * This package is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef _GLOBALTYPES_H -#define _GLOBALTYPES_H - -/* - * Definition: RET_CODE_BASE - * - * DESCRIPTION: Base value for return code offsets - */ -#define RET_CODE_BASE 0 - -/* - * Definition: *BIT_OFFSET - * - * DESCRIPTION: offset in bytes from start of 32-bit word. - */ -#define LOWER16BIT_OFFSET0 -#define UPPER16BIT_OFFSET2 - -#define LOWER8BIT_OFFSET 0 -#define LOWER_MIDDLE8BIT_OFFSET1 -#define UPPER_MIDDLE8BIT_OFFSET2 -#define UPPER8BIT_OFFSET 3 - -#define LOWER8BIT_OF16_OFFSET 0 -#define UPPER8BIT_OF16_OFFSET 1 - -/* - * Definition: *BIT_SHIFT - * - * DESCRIPTION: offset in bits from start of 32-bit word. - */ -#define LOWER16BIT_SHIFT 0 -#define UPPER16BIT_SHIFT 16 - -#define LOWER8BIT_SHIFT 0 -#define LOWER_MIDDLE8BIT_SHIFT8 -#define UPPER_MIDDLE8BIT_SHIFT16 -#define UPPER8BIT_SHIFT 24 - -#define LOWER8BIT_OF16_SHIFT 0 -#define UPPER8BIT_OF16_SHIFT 8 - -/* - * Definition: LOWER16BIT_MASK - * - * DESCRIPTION: 16 bit mask used for inclusion of lower 16 bits i.e. mask out - * the upper 16 bits - */ -#define LOWER16BIT_MASK0x - -/* - * Definition: LOWER8BIT_MASK - * - * DESCRIPTION: 8 bit masks used for inclusion of 8 bits i.e. mask out - * the upper 16 bits - */ -#define LOWER8BIT_MASK0x00FF - -/* - * Definition: RETURN32BITS_FROM16LOWER_AND16UPPER(lower16Bits, upper16Bits) - * - * DESCRIPTION: Returns a 32 bit value given a 16 bit lower value and a 16 - * bit upper value - */ -#define RETURN32BITS_FROM16LOWER_AND16UPPER(lower16Bits, upper16Bits)\ -(u32)lower16Bits) LOWER16BIT_MASK)) | \ - (u32)upper16Bits) LOWER16BIT_MASK) UPPER16BIT_SHIFT))) - -/* - * Definition: RETURN16BITS_FROM8LOWER_AND8UPPER(lower16Bits, upper16Bits) - * - * DESCRIPTION: Returns a 16 bit value given a 8 bit lower value and a 8 - *bit upper value - */ -#define RETURN16BITS_FROM8LOWER_AND8UPPER(lower8Bits, upper8Bits)\ -(u32)lower8Bits) LOWER8BIT_MASK)) | \ - (u32)upper8Bits) LOWER8BIT_MASK) UPPER8BIT_OF16_SHIFT))) - -/* - * Definition: RETURN32BITS_FROM48BIT_VALUES(lower8Bits, lowerMiddle8Bits, - * lowerUpper8Bits, upper8Bits) - * - * DESCRIPTION: Returns a 32 bit value given four 8 bit values - */ -#define RETURN32BITS_FROM48BIT_VALUES(lower8Bits, lowerMiddle8Bits,\ - lowerUpper8Bits, upper8Bits)\ - (u32)lower8Bits) LOWER8BIT_MASK)) | \ - (u32)lowerMiddle8Bits) LOWER8BIT_MASK) \ - LOWER_MIDDLE8BIT_SHIFT)) | \ - (u32)lowerUpper8Bits) LOWER8BIT_MASK) \ - UPPER_MIDDLE8BIT_SHIFT)) | \ - (u32)upper8Bits) LOWER8BIT_MASK) \ - UPPER8BIT_SHIFT))) - -/* - * Definition: READ_LOWER16BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 16 lower bits of 32bit value - */ -#define READ_LOWER16BITS_OF32(value32bits)\ -((u16)((u32)(value32bits) LOWER16BIT_MASK)) - -/* - * Definition: READ_UPPER16BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 16 lower bits of 32bit value - */ -#define READ_UPPER16BITS_OF32(value32bits)\ - (((u16)((u32)(value32bits) UPPER16BIT_SHIFT)) \ - LOWER16BIT_MASK) - -/* - * Definition: READ_LOWER8BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 8 lower bits of 32bit value - */ -#define READ_LOWER8BITS_OF32(value32bits)\ -((u8)((u32)(value32bits) LOWER8BIT_MASK)) - -/* - * Definition: READ_LOWER_MIDDLE8BITS_OF32(value32bits) - * - * DESCRIPTION: Returns a 8 lower middle bits of 32bit value - */ -#define READ_LOWER_MIDDLE8BITS_OF32(value32bits)\ - (((u8)((u32)(value32bits)
[PATCH 09/11] staging: tidspbridge: remove OPTIONAL
OPTIONAL modifier makes no sense in linux kernel
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/chnl_sm.c |2 +-
.../staging/tidspbridge/include/dspbridge/cod.h|2 +-
.../tidspbridge/include/dspbridge/dspchnl.h|4 ++--
.../tidspbridge/include/dspbridge/dspdefs.h|4 ++--
.../staging/tidspbridge/include/dspbridge/node.h | 12 ++--
.../staging/tidspbridge/include/dspbridge/proc.h |2 +-
drivers/staging/tidspbridge/pmgr/cod.c |2 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 12 ++--
drivers/staging/tidspbridge/rmgr/nldr.c|6 +++---
drivers/staging/tidspbridge/rmgr/node.c| 12 ++--
drivers/staging/tidspbridge/rmgr/proc.c|2 +-
11 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c
b/drivers/staging/tidspbridge/core/chnl_sm.c
index 25d2450..2189796 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -91,7 +91,7 @@ static int search_free_channel(struct chnl_mgr *chnl_mgr_obj,
*/
int bridge_chnl_add_io_req(struct chnl_object *chnl_obj, void *pHostBuf,
u32 byte_size, u32 buf_size,
- OPTIONAL u32 dw_dsp_addr, u32 dw_arg)
+ u32 dw_dsp_addr, u32 dw_arg)
{
int status = 0;
struct chnl_object *pchnl = (struct chnl_object *)chnl_obj;
diff --git a/drivers/staging/tidspbridge/include/dspbridge/cod.h
b/drivers/staging/tidspbridge/include/dspbridge/cod.h
index cb9b2c3..25817fc 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/cod.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/cod.h
@@ -93,7 +93,7 @@ extern void cod_close(struct cod_libraryobj *lib);
*/
extern int cod_create(OUT struct cod_manager **phManager,
char *pstrZLFile,
-OPTIONAL const struct cod_attrs *attrs);
+const struct cod_attrs *attrs);
/*
* cod_delete
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dspchnl.h
b/drivers/staging/tidspbridge/include/dspbridge/dspchnl.h
index ee71e9b..8b943cc 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dspchnl.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dspchnl.h
@@ -35,7 +35,7 @@ extern int bridge_chnl_open(OUT struct chnl_object **phChnl,
struct chnl_mgr *hchnl_mgr,
s8 chnl_mode,
u32 uChnlId,
- const OPTIONAL struct chnl_attr
+ const struct chnl_attr
*pattrs);
extern int bridge_chnl_close(struct chnl_object *chnl_obj);
@@ -43,7 +43,7 @@ extern int bridge_chnl_close(struct chnl_object *chnl_obj);
extern int bridge_chnl_add_io_req(struct chnl_object *chnl_obj,
void *pHostBuf,
u32 byte_size, u32 buf_size,
- OPTIONAL u32 dw_dsp_addr, u32 dw_arg);
+ u32 dw_dsp_addr, u32 dw_arg);
extern int bridge_chnl_get_ioc(struct chnl_object *chnl_obj,
u32 dwTimeOut, OUT struct chnl_ioc *pIOC);
diff --git a/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
b/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
index 7c86e7b..467ec8b 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dspdefs.h
@@ -411,7 +411,7 @@ typedef int(*fxn_chnl_open) (OUT struct chnl_object
struct chnl_mgr *hchnl_mgr,
s8 chnl_mode,
u32 uChnlId,
- const OPTIONAL struct
+ const struct
chnl_attr * pattrs);
/*
@@ -474,7 +474,7 @@ typedef int(*fxn_chnl_addioreq) (struct chnl_object
void *pHostBuf,
u32 byte_size,
u32 buf_size,
- OPTIONAL u32 dw_dsp_addr, u32 dw_arg);
+ u32 dw_dsp_addr, u32 dw_arg);
/*
* bridge_chnl_get_ioc
diff --git a/drivers/staging/tidspbridge/include/dspbridge/node.h
b/drivers/staging/tidspbridge/include/dspbridge/node.h
index 7f16f6f..7be6dda 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/node.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/node.h
@@ -57,8 +57,8 @@
*/
extern int node_allocate(struct proc_object *hprocessor,
const struct dsp_uuid
[PATCH 05/11] staging: tidspbridge: remove RET_OK RET_FAIL
RET_OK is 0 and RET_FAIL is a -1, replace these custom returns with
a standard errno
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 10 ++---
drivers/staging/tidspbridge/hw/hw_mmu.c | 53 +
2 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 51e327f..33fcef5 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1506,8 +1506,7 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *hDevContext,
}
paddr += HW_PAGE_SIZE4KB;
}
- if (hw_mmu_pte_clear(pte_addr_l2, va_curr, pte_size)
- == RET_FAIL) {
+ if (hw_mmu_pte_clear(pte_addr_l2, va_curr, pte_size)) {
status = -EPERM;
goto EXIT_LOOP;
}
@@ -1524,9 +1523,8 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *hDevContext,
/*
* Clear the L1 PTE pointing to the L2 PT
*/
- if (hw_mmu_pte_clear(l1_base_va, va_curr_orig,
-HW_MMU_COARSE_PAGE_SIZE) ==
- RET_OK)
+ if (!hw_mmu_pte_clear(l1_base_va, va_curr_orig,
+HW_MMU_COARSE_PAGE_SIZE))
status = 0;
else {
status = -EPERM;
@@ -1571,7 +1569,7 @@ skip_coarse_page:
}
paddr += HW_PAGE_SIZE4KB;
}
- if (hw_mmu_pte_clear(l1_base_va, va_curr, pte_size) == RET_OK) {
+ if (!hw_mmu_pte_clear(l1_base_va, va_curr, pte_size)) {
status = 0;
rem_bytes -= pte_size;
va_curr += pte_size;
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index 4430daf..321b72d 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -22,6 +22,7 @@
#include hw_defs.h
#include hw_mmu.h
#include linux/types.h
+#include linux/err.h
#define MMU_BASE_VAL_MASK 0xFC00
#define MMU_PAGE_MAX3
@@ -59,7 +60,7 @@ enum hw_mmu_page_size_t {
* RETURNS:
*
* Type : hw_status
- * Description : RET_OK -- No errors occured
+ * Description : 0-- No errors occured
* RET_BAD_NULL_PARAM -- A Pointer
* Paramater was set to NULL
*
@@ -102,7 +103,7 @@ static hw_status mmu_flush_entry(const void __iomem
*base_address);
* RETURNS:
*
* Type : hw_status
- * Description : RET_OK -- No errors occured
+ * Description : 0-- No errors occured
* RET_BAD_NULL_PARAM -- A Pointer Paramater
*was set to NULL
* RET_PARAM_OUT_OF_RANGE -- Input Parameter out
@@ -147,7 +148,7 @@ static hw_status mmu_set_cam_entry(const void __iomem
*base_address,
* RETURNS:
*
* Type : hw_status
- * Description : RET_OK -- No errors occured
+ * Description : 0-- No errors occured
* RET_BAD_NULL_PARAM -- A Pointer Paramater
* was set to NULL
* RET_PARAM_OUT_OF_RANGE -- Input Parameter
@@ -167,7 +168,7 @@ static hw_status mmu_set_ram_entry(const void __iomem
*base_address,
hw_status hw_mmu_enable(const void __iomem *base_address)
{
- hw_status status = RET_OK;
+ hw_status status = 0;
MMUMMU_CNTLMMU_ENABLE_WRITE32(base_address, HW_SET);
@@ -176,7 +177,7 @@ hw_status hw_mmu_enable(const void __iomem *base_address)
hw_status hw_mmu_disable(const void __iomem *base_address)
{
- hw_status status = RET_OK;
+ hw_status status = 0;
MMUMMU_CNTLMMU_ENABLE_WRITE32(base_address, HW_CLEAR);
@@ -186,7 +187,7 @@ hw_status hw_mmu_disable(const void __iomem *base_address)
hw_status hw_mmu_num_locked_set(const void __iomem *base_address,
u32 numLockedEntries)
{
- hw_status status = RET_OK;
+ hw_status status = 0;
MMUMMU_LOCK_BASE_VALUE_WRITE32(base_address, numLockedEntries);
@@ -196,7 +197,7 @@ hw_status hw_mmu_num_locked_set(const void __iomem
*base_address,
[PATCH 07/11] staging: tidspbridge: replace CONST with c standard const
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/chnl_sm.c |4 ++--
drivers/staging/tidspbridge/core/io_sm.c |2 +-
drivers/staging/tidspbridge/core/msg_sm.c |2 +-
drivers/staging/tidspbridge/core/tiomap3430.c |2 +-
.../staging/tidspbridge/include/dspbridge/chnl.h |2 +-
.../staging/tidspbridge/include/dspbridge/cmm.h|2 +-
.../staging/tidspbridge/include/dspbridge/cod.h|2 +-
.../staging/tidspbridge/include/dspbridge/dev.h|8
.../staging/tidspbridge/include/dspbridge/disp.h |4 ++--
.../staging/tidspbridge/include/dspbridge/dmm.h|2 +-
.../tidspbridge/include/dspbridge/dspchnl.h|4 ++--
.../tidspbridge/include/dspbridge/dspdefs.h| 10 +-
.../staging/tidspbridge/include/dspbridge/dspio.h |2 +-
.../staging/tidspbridge/include/dspbridge/dspmsg.h |2 +-
drivers/staging/tidspbridge/include/dspbridge/io.h |2 +-
.../staging/tidspbridge/include/dspbridge/nldr.h |4 ++--
.../tidspbridge/include/dspbridge/nldrdefs.h |4 ++--
.../staging/tidspbridge/include/dspbridge/node.h | 10 +-
.../staging/tidspbridge/include/dspbridge/proc.h |6 +++---
.../staging/tidspbridge/include/dspbridge/pwr.h|4 ++--
drivers/staging/tidspbridge/pmgr/chnl.c|2 +-
drivers/staging/tidspbridge/pmgr/cmm.c |2 +-
drivers/staging/tidspbridge/pmgr/cod.c |4 ++--
drivers/staging/tidspbridge/pmgr/dev.c |4 ++--
drivers/staging/tidspbridge/pmgr/dmm.c |2 +-
drivers/staging/tidspbridge/pmgr/dspapi.c |2 +-
drivers/staging/tidspbridge/pmgr/io.c |2 +-
drivers/staging/tidspbridge/rmgr/disp.c|4 ++--
drivers/staging/tidspbridge/rmgr/nldr.c|4 ++--
drivers/staging/tidspbridge/rmgr/node.c| 14 +++---
drivers/staging/tidspbridge/rmgr/proc.c|8
drivers/staging/tidspbridge/rmgr/pwr.c |4 ++--
32 files changed, 65 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c
b/drivers/staging/tidspbridge/core/chnl_sm.c
index b669bc0..25fe1a2 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -383,7 +383,7 @@ func_cont:
*/
int bridge_chnl_create(OUT struct chnl_mgr **phChnlMgr,
struct dev_object *hdev_obj,
- IN CONST struct chnl_mgrattrs *pMgrAttrs)
+ IN const struct chnl_mgrattrs *pMgrAttrs)
{
int status = 0;
struct chnl_mgr *chnl_mgr_obj = NULL;
@@ -777,7 +777,7 @@ int bridge_chnl_idle(struct chnl_object *chnl_obj, u32
dwTimeOut,
*/
int bridge_chnl_open(OUT struct chnl_object **phChnl,
struct chnl_mgr *hchnl_mgr, s8 chnl_mode,
- u32 uChnlId, CONST IN struct chnl_attr *pattrs)
+ u32 uChnlId, const IN struct chnl_attr *pattrs)
{
int status = 0;
struct chnl_mgr *chnl_mgr_obj = hchnl_mgr;
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 280b22d..73ba306 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -163,7 +163,7 @@ static int register_shm_segs(struct io_mgr *hio_mgr,
*/
int bridge_io_create(OUT struct io_mgr **phIOMgr,
struct dev_object *hdev_obj,
- IN CONST struct io_attrs *pMgrAttrs)
+ IN const struct io_attrs *pMgrAttrs)
{
int status = 0;
struct io_mgr *pio_mgr = NULL;
diff --git a/drivers/staging/tidspbridge/core/msg_sm.c
b/drivers/staging/tidspbridge/core/msg_sm.c
index 7b7a4be..576dac0 100644
--- a/drivers/staging/tidspbridge/core/msg_sm.c
+++ b/drivers/staging/tidspbridge/core/msg_sm.c
@@ -383,7 +383,7 @@ func_end:
* Put a message onto a msg_ctrl queue.
*/
int bridge_msg_put(struct msg_queue *msg_queue_obj,
- IN CONST struct dsp_msg *pmsg, u32 utimeout)
+ IN const struct dsp_msg *pmsg, u32 utimeout)
{
struct msg_frame *msg_frame_obj;
struct msg_mgr *hmsg_mgr;
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 33fcef5..0a4b054 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -237,7 +237,7 @@ static void bad_page_dump(u32 pa, struct page *pg)
* Bridge Driver entry point.
*/
void bridge_drv_entry(OUT struct bridge_drv_interface **ppDrvInterface,
- IN CONST char *driver_file_name)
+ IN const char *driver_file_name)
{
DBC_REQUIRE(driver_file_name != NULL);
diff --git
[PATCH] staging: tidspbridge: fix build error for missing variable
Commit:
staging: tidspbridge: gen: simplify and clean up
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Introduced usage of hex_to_bin without defining the temp variable.
this causes the build error:
drivers/staging/tidspbridge/gen/uuidutil.c: In function 'uuid_hex_to_bin':
drivers/staging/tidspbridge/gen/uuidutil.c:63: error: 'value' undeclared (first
use in this function)
drivers/staging/tidspbridge/gen/uuidutil.c:63: error: (Each undeclared
identifier is reported only once
drivers/staging/tidspbridge/gen/uuidutil.c:63: error: for each function it
appears in.)
introduce variable value to fix the error.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/gen/uuidutil.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tidspbridge/gen/uuidutil.c
b/drivers/staging/tidspbridge/gen/uuidutil.c
index eb09bc3..070761b 100644
--- a/drivers/staging/tidspbridge/gen/uuidutil.c
+++ b/drivers/staging/tidspbridge/gen/uuidutil.c
@@ -58,6 +58,7 @@ static s32 uuid_hex_to_bin(char *buf, s32 len)
{
s32 i;
s32 result = 0;
+ int value;
for (i = 0; i len; i++) {
value = hex_to_bin(*buf++);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] staging: tidspbridge: header cleanup series
Series targetted to remove std.h, GlobalTypes.h and dbdefs.h. These introduce custom types and macros which dont make sense for linux kernel Nishanth Menon (11): staging: tidspbridge: remove custom TRUE FALSE staging: tidspbridge: no need for custom NULL staging: tidspbridge: remove std.h staging: tidspbridge: remove custom typedef reg_uword32 staging: tidspbridge: remove RET_OK RET_FAIL staging: tidspbridge: remove GlobalTypes.h staging: tidspbridge: replace CONST with c standard const staging: tidspbridge: remove IN modifier staging: tidspbridge: remove OPTIONAL staging: tidspbridge: remove OUT define staging: tidspbridge: remove dbdefs.h drivers/staging/tidspbridge/core/_tiomap_pwr.h | 14 +- drivers/staging/tidspbridge/core/chnl_sm.c | 23 +- drivers/staging/tidspbridge/core/dsp-clock.c |7 +- drivers/staging/tidspbridge/core/io_sm.c | 28 +- drivers/staging/tidspbridge/core/msg_sm.c |8 +- drivers/staging/tidspbridge/core/tiomap3430.c | 64 ++--- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 140 +++-- drivers/staging/tidspbridge/core/tiomap_io.c |8 +- drivers/staging/tidspbridge/core/tiomap_io.h | 14 +- drivers/staging/tidspbridge/core/wdt.c |2 +- drivers/staging/tidspbridge/dynload/cload.c|2 +- .../staging/tidspbridge/dynload/dload_internal.h |3 - drivers/staging/tidspbridge/dynload/header.h |6 - .../tidspbridge/dynload/tramp_table_c6000.c|2 +- drivers/staging/tidspbridge/gen/gb.c |4 +- drivers/staging/tidspbridge/gen/gh.c |2 +- drivers/staging/tidspbridge/gen/gs.c |2 +- drivers/staging/tidspbridge/gen/uuidutil.c |8 +- drivers/staging/tidspbridge/hw/GlobalTypes.h | 308 drivers/staging/tidspbridge/hw/MMURegAcM.h |1 - drivers/staging/tidspbridge/hw/hw_defs.h |2 - drivers/staging/tidspbridge/hw/hw_mmu.c| 85 ++ .../staging/tidspbridge/include/dspbridge/cfg.h| 28 +- .../staging/tidspbridge/include/dspbridge/chnl.h |4 +- .../staging/tidspbridge/include/dspbridge/clk.h|4 +- .../staging/tidspbridge/include/dspbridge/cmm.h| 14 +- .../staging/tidspbridge/include/dspbridge/cod.h| 20 +- .../staging/tidspbridge/include/dspbridge/dbdcd.h | 74 +++--- .../tidspbridge/include/dspbridge/dbdcddef.h |6 +- .../staging/tidspbridge/include/dspbridge/dbdefs.h |2 - .../staging/tidspbridge/include/dspbridge/dbtype.h | 88 -- .../staging/tidspbridge/include/dspbridge/dev.h| 46 ++-- .../staging/tidspbridge/include/dspbridge/disp.h |8 +- .../staging/tidspbridge/include/dspbridge/dmm.h|6 +- .../staging/tidspbridge/include/dspbridge/drv.h| 16 +- .../tidspbridge/include/dspbridge/dspapi-ioctl.h |2 +- .../tidspbridge/include/dspbridge/dspchnl.h| 16 +- .../tidspbridge/include/dspbridge/dspdefs.h| 44 ++-- .../staging/tidspbridge/include/dspbridge/dspdrv.h |2 +- .../staging/tidspbridge/include/dspbridge/dspio.h |8 +- .../staging/tidspbridge/include/dspbridge/dspmsg.h |6 +- .../tidspbridge/include/dspbridge/host_os.h|1 - drivers/staging/tidspbridge/include/dspbridge/io.h |4 +- .../staging/tidspbridge/include/dspbridge/io_sm.h | 10 +- .../staging/tidspbridge/include/dspbridge/mgr.h| 16 +- .../staging/tidspbridge/include/dspbridge/msg.h|2 +- .../staging/tidspbridge/include/dspbridge/nldr.h | 12 +- .../tidspbridge/include/dspbridge/nldrdefs.h | 10 +- .../staging/tidspbridge/include/dspbridge/node.h | 40 ++-- .../tidspbridge/include/dspbridge/nodepriv.h |2 +- .../staging/tidspbridge/include/dspbridge/proc.h | 18 +- .../staging/tidspbridge/include/dspbridge/pwr.h|8 +- .../tidspbridge/include/dspbridge/rmstypes.h |4 - .../staging/tidspbridge/include/dspbridge/std.h| 94 -- .../staging/tidspbridge/include/dspbridge/strm.h | 22 +- .../tidspbridge/include/dspbridge/uuidutil.h |6 +- drivers/staging/tidspbridge/pmgr/chnl.c|6 +- drivers/staging/tidspbridge/pmgr/cmm.c | 16 +- drivers/staging/tidspbridge/pmgr/cod.c | 21 +- drivers/staging/tidspbridge/pmgr/dbll.c|6 +- drivers/staging/tidspbridge/pmgr/dev.c | 38 ++-- drivers/staging/tidspbridge/pmgr/dmm.c | 10 +- drivers/staging/tidspbridge/pmgr/dspapi.c |6 +- drivers/staging/tidspbridge/pmgr/io.c |6 +- drivers/staging/tidspbridge/pmgr/msg.c |4 +- drivers/staging/tidspbridge/rmgr/dbdcd.c | 94 +++--- drivers/staging/tidspbridge/rmgr/disp.c| 12 +- drivers/staging/tidspbridge/rmgr/drv.c |8 +- drivers/staging/tidspbridge/rmgr/drv_interface.c |2
[PATCH 04/11] staging: tidspbridge: remove custom typedef reg_uword32
use readl, writel to get and set the register instead.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 18 +--
drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 126 ++---
drivers/staging/tidspbridge/core/tiomap_io.c |2 +-
drivers/staging/tidspbridge/rmgr/node.c |4 +-
4 files changed, 44 insertions(+), 106 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index d067de9..51e327f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -555,24 +555,18 @@ static int bridge_brd_start(struct bridge_dev_context
*hDevContext,
dev_context-mbox-rxq-callback = (int (*)(void *))io_mbox_msg;
/*PM_IVA2GRPSEL_PER = 0xC0;*/
- temp = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_pm_base) + 0xA8));
+ temp = readl(resources-dw_per_pm_base + 0xA8);
temp = (temp 0xFF30) | 0xC0;
- *((reg_uword32 *) ((u32) (resources-dw_per_pm_base) + 0xA8)) =
- (u32) temp;
+ writel(temp, resources-dw_per_pm_base + 0xA8);
/*PM_MPUGRPSEL_PER = 0xFF3F; */
- temp = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_pm_base) + 0xA4));
+ temp = readl(resources-dw_per_pm_base + 0xA4);
temp = (temp 0xFF3F);
- *((reg_uword32 *) ((u32) (resources-dw_per_pm_base) + 0xA4)) =
- (u32) temp;
+ writel(temp, resources-dw_per_pm_base + 0xA4);
/*CM_SLEEPDEP_PER |= 0x04; */
- temp = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_base) + 0x44));
+ temp = readl(resources-dw_per_base + 0x44);
temp = (temp 0xFFFB) | 0x04;
- *((reg_uword32 *) ((u32) (resources-dw_per_base) + 0x44)) =
- (u32) temp;
+ writel(temp, resources-dw_per_base + 0x44);
/*CM_CLKSTCTRL_IVA2 = 0x0003 -To Allow automatic transitions */
(*pdata-dsp_cm_write)(OMAP34XX_CLKSTCTRL_ENABLE_AUTO,
diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
index 2b3ce64..384b833 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
@@ -430,12 +430,8 @@ void dsp_clk_wakeup_event_ctrl(u32 clock_id, bool enable)
switch (clock_id) {
case BPWR_GP_TIMER5:
- iva2_grpsel = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_pm_base) +
- 0xA8));
- mpu_grpsel = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_pm_base) +
- 0xA4));
+ iva2_grpsel = readl(resources-dw_per_pm_base + 0xA8);
+ mpu_grpsel = readl(resources-dw_per_pm_base + 0xA4);
if (enable) {
iva2_grpsel |= OMAP3430_GRPSEL_GPT5_MASK;
mpu_grpsel = ~OMAP3430_GRPSEL_GPT5_MASK;
@@ -443,18 +439,12 @@ void dsp_clk_wakeup_event_ctrl(u32 clock_id, bool enable)
mpu_grpsel |= OMAP3430_GRPSEL_GPT5_MASK;
iva2_grpsel = ~OMAP3430_GRPSEL_GPT5_MASK;
}
- *((reg_uword32 *) ((u32) (resources-dw_per_pm_base) + 0xA8))
- = iva2_grpsel;
- *((reg_uword32 *) ((u32) (resources-dw_per_pm_base) + 0xA4))
- = mpu_grpsel;
+ writel(iva2_grpsel, resources-dw_per_pm_base + 0xA8);
+ writel(mpu_grpsel, resources-dw_per_pm_base + 0xA4);
break;
case BPWR_GP_TIMER6:
- iva2_grpsel = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_pm_base) +
- 0xA8));
- mpu_grpsel = (u32) *((reg_uword32 *)
- ((u32) (resources-dw_per_pm_base) +
- 0xA4));
+ iva2_grpsel = readl(resources-dw_per_pm_base + 0xA8);
+ mpu_grpsel = readl(resources-dw_per_pm_base + 0xA4);
if (enable) {
iva2_grpsel |= OMAP3430_GRPSEL_GPT6_MASK;
mpu_grpsel = ~OMAP3430_GRPSEL_GPT6_MASK;
@@ -462,18 +452,12 @@ void dsp_clk_wakeup_event_ctrl(u32 clock_id, bool enable)
mpu_grpsel |= OMAP3430_GRPSEL_GPT6_MASK;
iva2_grpsel = ~OMAP3430_GRPSEL_GPT6_MASK;
}
- *((reg_uword32 *) ((u32) (resources-dw_per_pm_base) + 0xA8))
- = iva2_grpsel;
- *((reg_uword32
[PATCH 11/11] staging: tidspbridge: remove dbdefs.h
Remove yet another custom definition header Signed-off-by: Nishanth Menon n...@ti.com --- .../staging/tidspbridge/include/dspbridge/dbdefs.h |1 - .../staging/tidspbridge/include/dspbridge/dbtype.h | 69 .../tidspbridge/include/dspbridge/host_os.h|1 - 3 files changed, 0 insertions(+), 71 deletions(-) delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbtype.h diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h index b408cad..ff0ba57 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h +++ b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h @@ -21,7 +21,6 @@ #include linux/types.h -#include dspbridge/dbtype.h /* GPP side type definitions */ #include dspbridge/rms_sh.h /* Types shared between GPP and DSP */ #define PG_SIZE4K 4096 diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h b/drivers/staging/tidspbridge/include/dspbridge/dbtype.h deleted file mode 100644 index ca5eaf8..000 --- a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h +++ /dev/null @@ -1,69 +0,0 @@ -/* - * dbtype.h - * - * DSP-BIOS Bridge driver support functions for TI OMAP processors. - * - * This header defines data types for DSP/BIOS Bridge APIs and device - * driver modules. It also defines the Hungarian prefix to use for each - * base type. - * - * Copyright (C) 2008 Texas Instruments, Inc. - * - * This package is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR - * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED - * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. - */ - -#ifndef DBTYPE_ -#define DBTYPE_ - -/*===*/ -/* Argument specification syntax */ -/*===*/ - -#ifndef IN -#define IN /* Following parameter is for input. */ -#endif - -#ifndef OUT -#define OUT/* Following parameter is for output. */ -#endif - -#ifndef OPTIONAL -#define OPTIONAL /* Function may optionally use previous parameter. */ -#endif - -#ifndef CONST -#define CONST const -#endif - -/*===*/ -/* NULL character (normally used for string termination) */ -/*===*/ - -#ifndef NULL_CHAR -#define NULL_CHAR'\0' /* Null character. */ -#endif - -/*===*/ -/* Basic Type definitions (with Prefixes for Hungarian notation) */ -/*===*/ - -#ifndef OMAPBRIDGE_TYPES -#define OMAPBRIDGE_TYPES -typedef volatile unsigned short reg_uword16; -#endif - -#define TEXT(x) x - -#define DLLIMPORT -#define DLLEXPORT - -/* Define DSPAPIDLL correctly in dspapi.h */ -#define _DSPSYSDLL32_ - -#endif /* DBTYPE_ */ diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h index a91c136..6b4feb4 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h +++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h @@ -42,7 +42,6 @@ #include linux/vmalloc.h #include linux/ioport.h #include linux/platform_device.h -#include dspbridge/dbtype.h #include plat/clock.h #include linux/clk.h #include plat/mailbox.h -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] staging: tidspbridge: no need for custom NULL
kernel has it's own NULL define, we dont need to introduce our own custom NULL type! Signed-off-by: Nishanth Menon n...@ti.com --- drivers/staging/tidspbridge/dynload/header.h |4 drivers/staging/tidspbridge/hw/GlobalTypes.h |9 - .../staging/tidspbridge/include/dspbridge/dbtype.h |8 .../staging/tidspbridge/include/dspbridge/std.h|4 4 files changed, 0 insertions(+), 25 deletions(-) diff --git a/drivers/staging/tidspbridge/dynload/header.h b/drivers/staging/tidspbridge/dynload/header.h index 04623f1..5b50a15 100644 --- a/drivers/staging/tidspbridge/dynload/header.h +++ b/drivers/staging/tidspbridge/dynload/header.h @@ -14,10 +14,6 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ -#ifndef NULL -#define NULL 0 -#endif - #include linux/string.h #define DL_STRCMP strcmp diff --git a/drivers/staging/tidspbridge/hw/GlobalTypes.h b/drivers/staging/tidspbridge/hw/GlobalTypes.h index ba045eb..2f8e69b 100644 --- a/drivers/staging/tidspbridge/hw/GlobalTypes.h +++ b/drivers/staging/tidspbridge/hw/GlobalTypes.h @@ -20,15 +20,6 @@ #define _GLOBALTYPES_H /* - * Definition: NULL - * - * DESCRIPTION: Invalid pointer - */ -#ifndef NULL -#define NULL (void *)0 -#endif - -/* * Definition: RET_CODE_BASE * * DESCRIPTION: Base value for return code offsets diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h b/drivers/staging/tidspbridge/include/dspbridge/dbtype.h index 0b2cb93..ca5eaf8 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/dbtype.h +++ b/drivers/staging/tidspbridge/include/dspbridge/dbtype.h @@ -42,14 +42,6 @@ #endif /*===*/ -/* NULL(Definition is language specific) */ -/*===*/ - -#ifndef NULL -#define NULL((void *)0)/* Null pointer. */ -#endif - -/*===*/ /* NULL character (normally used for string termination) */ /*===*/ diff --git a/drivers/staging/tidspbridge/include/dspbridge/std.h b/drivers/staging/tidspbridge/include/dspbridge/std.h index 7e09fec..ca2827d 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/std.h +++ b/drivers/staging/tidspbridge/include/dspbridge/std.h @@ -74,10 +74,6 @@ typedef s32(*fxn) (void); /* generic function type */ -#ifndef NULL -#define NULL 0 -#endif - /* * These macros are used to cast 'Arg' types to 's32' or 'Ptr'. * These macros were added for the 55x since Arg is not the same -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/11] staging: tidspbridge: remove std.h
std.h introduces _TI_ _FLOAT_ _FIXED_ _TARGET_ ARG_TO_INT ARG_TO_PTR which are no longer being used anywhere. we dont really need the custom std.h header. remove it from the repo. where we need types, introduce standard types.h Signed-off-by: Nishanth Menon n...@ti.com --- drivers/staging/tidspbridge/core/chnl_sm.c |3 +- drivers/staging/tidspbridge/core/dsp-clock.c |3 +- drivers/staging/tidspbridge/core/io_sm.c |2 +- drivers/staging/tidspbridge/core/msg_sm.c |2 +- drivers/staging/tidspbridge/core/tiomap3430.c |2 +- drivers/staging/tidspbridge/core/wdt.c |2 +- drivers/staging/tidspbridge/gen/gb.c |2 +- drivers/staging/tidspbridge/gen/gh.c |2 +- drivers/staging/tidspbridge/gen/gs.c |2 +- drivers/staging/tidspbridge/gen/uuidutil.c |2 +- .../staging/tidspbridge/include/dspbridge/dbdefs.h |1 - .../tidspbridge/include/dspbridge/rmstypes.h |4 - .../staging/tidspbridge/include/dspbridge/std.h| 90 drivers/staging/tidspbridge/pmgr/chnl.c|2 +- drivers/staging/tidspbridge/pmgr/cmm.c |2 +- drivers/staging/tidspbridge/pmgr/cod.c |3 +- drivers/staging/tidspbridge/pmgr/dbll.c|2 +- drivers/staging/tidspbridge/pmgr/dev.c |2 +- drivers/staging/tidspbridge/pmgr/dmm.c |2 +- drivers/staging/tidspbridge/pmgr/dspapi.c |2 +- drivers/staging/tidspbridge/pmgr/io.c |2 +- drivers/staging/tidspbridge/pmgr/msg.c |2 +- drivers/staging/tidspbridge/rmgr/dbdcd.c |2 +- drivers/staging/tidspbridge/rmgr/disp.c|2 +- drivers/staging/tidspbridge/rmgr/drv.c |2 +- drivers/staging/tidspbridge/rmgr/drv_interface.c |2 +- drivers/staging/tidspbridge/rmgr/dspdrv.c |2 +- drivers/staging/tidspbridge/rmgr/mgr.c |3 +- drivers/staging/tidspbridge/rmgr/nldr.c|3 +- drivers/staging/tidspbridge/rmgr/node.c|2 +- drivers/staging/tidspbridge/rmgr/proc.c|2 +- drivers/staging/tidspbridge/rmgr/rmm.c |3 +- drivers/staging/tidspbridge/rmgr/strm.c|3 +- drivers/staging/tidspbridge/services/cfg.c |3 +- drivers/staging/tidspbridge/services/services.c|3 +- 35 files changed, 41 insertions(+), 127 deletions(-) delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/std.h diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c b/drivers/staging/tidspbridge/core/chnl_sm.c index 714b6f7..b669bc0 100644 --- a/drivers/staging/tidspbridge/core/chnl_sm.c +++ b/drivers/staging/tidspbridge/core/chnl_sm.c @@ -42,11 +42,12 @@ * !LST_Empty(pchnl-pio_completions) == pchnl-sync_event is set. */ +#include linux/types.h + /* --- OS */ #include dspbridge/host_os.h /* --- DSP/BIOS Bridge */ -#include dspbridge/std.h #include dspbridge/dbdefs.h /* --- Trace Debug */ diff --git a/drivers/staging/tidspbridge/core/dsp-clock.c b/drivers/staging/tidspbridge/core/dsp-clock.c index abaa595..6f9ea05 100644 --- a/drivers/staging/tidspbridge/core/dsp-clock.c +++ b/drivers/staging/tidspbridge/core/dsp-clock.c @@ -16,13 +16,14 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ +#include linux/types.h + /* --- Host OS */ #include dspbridge/host_os.h #include plat/dmtimer.h #include plat/mcbsp.h /* --- DSP/BIOS Bridge */ -#include dspbridge/std.h #include dspbridge/dbdefs.h #include dspbridge/cfg.h #include dspbridge/drv.h diff --git a/drivers/staging/tidspbridge/core/io_sm.c b/drivers/staging/tidspbridge/core/io_sm.c index 1503968..280b22d 100644 --- a/drivers/staging/tidspbridge/core/io_sm.c +++ b/drivers/staging/tidspbridge/core/io_sm.c @@ -23,13 +23,13 @@ * which may cause timeouts and/or failure of the sync_wait_on_event * function. */ +#include linux/types.h /* Host OS */ #include dspbridge/host_os.h #include linux/workqueue.h /* --- DSP/BIOS Bridge */ -#include dspbridge/std.h #include dspbridge/dbdefs.h /* Trace Debug */ diff --git a/drivers/staging/tidspbridge/core/msg_sm.c b/drivers/staging/tidspbridge/core/msg_sm.c index 7c6d6cc..7b7a4be 100644 --- a/drivers/staging/tidspbridge/core/msg_sm.c +++ b/drivers/staging/tidspbridge/core/msg_sm.c @@ -15,9 +15,9 @@ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ +#include linux/types.h /* --- DSP/BIOS Bridge */ -#include dspbridge/std.h #include dspbridge/dbdefs.h /*
Re: ARM defconfig files
On Monday 12 July 2010 11:50:29 Uwe Kleine-König wrote: If it helps the powerpc people I can reduce their defconfigs, too. Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Thanks, David -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: tidspbridge: fix build error for missing variable
Menon, Nishanth had written, on 07/12/2010 05:56 PM, the following:
Commit:
staging: tidspbridge: gen: simplify and clean up
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Introduced usage of hex_to_bin without defining the temp variable.
this causes the build error:
drivers/staging/tidspbridge/gen/uuidutil.c: In function 'uuid_hex_to_bin':
drivers/staging/tidspbridge/gen/uuidutil.c:63: error: 'value' undeclared (first
use in this function)
drivers/staging/tidspbridge/gen/uuidutil.c:63: error: (Each undeclared
identifier is reported only once
drivers/staging/tidspbridge/gen/uuidutil.c:63: error: for each function it
appears in.)
introduce variable value to fix the error.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/gen/uuidutil.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tidspbridge/gen/uuidutil.c
b/drivers/staging/tidspbridge/gen/uuidutil.c
index eb09bc3..070761b 100644
--- a/drivers/staging/tidspbridge/gen/uuidutil.c
+++ b/drivers/staging/tidspbridge/gen/uuidutil.c
@@ -58,6 +58,7 @@ static s32 uuid_hex_to_bin(char *buf, s32 len)
{
s32 i;
s32 result = 0;
+ int value;
for (i = 0; i len; i++) {
value = hex_to_bin(*buf++);
arrgh.. just saw https://patchwork.kernel.org/patch/41/ - please
consider the same and drop this patch. apologies on the noise.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Linus -- 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: ARM defconfig files
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. David -- 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: ARM defconfig files
On Mon, 12 Jul 2010, David Brown wrote: On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. I'm sure that some clever people will come up with a better script eventually. Maybe this could even be generated by scripts/kconfig/conf directly. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] nand prefetch-irq support and ecc layout chanage
The following set of patches applies on top of for-next branch. And is dependent on the following patches 1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30305.html v3: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (4): omap3: nand: prefetch in irq mode support omap: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-flash.c |4 +- arch/arm/mach-omap2/gpmc.c | 15 +- arch/arm/mach-omap2/include/mach/board-flash.h |3 + arch/arm/plat-omap/include/plat/gpmc.h |9 +- arch/arm/plat-omap/include/plat/nand.h |7 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 +--- 7 files changed, 295 insertions(+), 34 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 v3 2/4] omap3: nand: configurable fifo threshold to gain the throughput
Configure the FIFO THREASHOLD value different for read and write to keep busy
both
filling and to drain out of FIFO at reading and writing.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpmc.h |5 -
drivers/mtd/nand/omap2.c | 24 +++-
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c100e4..d10041a 100755
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -58,7 +58,6 @@
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
-#define PREFETCH_FIFOTHRESHOLD (0x40 8)
#define CS_NUM_SHIFT 24
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
@@ -592,15 +591,19 @@ EXPORT_SYMBOL(gpmc_nand_write);
/**
* gpmc_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
* @dma_mode: dma mode enable (1) or disable (0)
* @u32_count: number of bytes to be transferred
* @is_write: prefetch read(0) or write post(1) mode
*/
-int gpmc_prefetch_enable(int cs, int dma_mode,
+int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write)
{
- if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX) {
+ printk(KERN_ERR PREFETCH Fifo Threshold is not supported\n);
+ return -1;
+ } else if (!(gpmc_read_reg(GPMC_PREFETCH_CONTROL))) {
/* Set the amount of bytes to be prefetched */
gpmc_write_reg(GPMC_PREFETCH_CONFIG2, u32_count);
@@ -608,7 +611,7 @@ int gpmc_prefetch_enable(int cs, int dma_mode,
* enable the engine. Set which cs is has requested for.
*/
gpmc_write_reg(GPMC_PREFETCH_CONFIG1, ((cs CS_NUM_SHIFT) |
- PREFETCH_FIFOTHRESHOLD |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) |
ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE) |
(0x1 is_write)));
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 054e704..fb82335 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -83,6 +83,9 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)(val 8)
+
/*
* Note that all values in this struct are in nanoseconds, while
* the register values are in gpmc_fck cycles.
@@ -133,7 +136,7 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern int gpmc_cs_set_reserved(int cs, int reserved);
extern int gpmc_cs_reserved(int cs);
-extern int gpmc_prefetch_enable(int cs, int dma_mode,
+extern int gpmc_prefetch_enable(int cs, int fifo_th, int dma_mode,
unsigned int u32_count, int is_write);
extern int gpmc_prefetch_reset(int cs);
extern void omap3_gpmc_save_context(void);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 6a57743..d5fad84 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -275,7 +275,8 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x0);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -319,7 +320,8 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x0, len, 0x1);
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -373,10 +375,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+
[PATCH v3 1/4] omap3: nand: prefetch in irq mode support
This patch enable prefetch-irq mode for NAND.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/mach-omap2/gpmc.c |4 +
arch/arm/mach-omap2/include/mach/board-flash.h |3 +
arch/arm/plat-omap/include/plat/gpmc.h |4 +
arch/arm/plat-omap/include/plat/nand.h |1 +
drivers/mtd/nand/Kconfig | 14 ++-
drivers/mtd/nand/omap2.c | 196 +++-
7 files changed, 217 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ac834aa..c6a07dd 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -133,6 +133,7 @@ static struct omap_nand_platform_data board_nand_data = {
.nand_setup = NULL,
.gpmc_t = nand_timings,
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .gpmc_irq = GPMC_IRQ_NUMBER,
.dev_ready = NULL,
.devsize= 0,/* '0' for 8-bit, '1' for 16-bit device */
};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e301e7e..2c100e4 100755
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -487,6 +487,10 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
u32 regval = 0;
switch (cmd) {
+ case GPMC_ENABLE_IRQ:
+ gpmc_write_reg(GPMC_IRQENABLE, wval);
+ break;
+
case GPMC_SET_IRQ_STATUS:
gpmc_write_reg(GPMC_IRQSTATUS, wval);
break;
diff --git a/arch/arm/mach-omap2/include/mach/board-flash.h
b/arch/arm/mach-omap2/include/mach/board-flash.h
index b2242ae..37567a7 100644
--- a/arch/arm/mach-omap2/include/mach/board-flash.h
+++ b/arch/arm/mach-omap2/include/mach/board-flash.h
@@ -19,6 +19,9 @@
#define PDC_ONENAND3
#define DBG_MPDB 4
+/* Interrupt number to the MPU Subsystem for GPMC */
+#define GPMC_IRQ_NUMBER20
+
struct flash_partitions {
struct mtd_partition *parts;
int nr_parts;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 9fd99b9..054e704 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -41,6 +41,8 @@
#define GPMC_NAND_ADDRESS 0x000b
#define GPMC_NAND_DATA 0x000c
+#define GPMC_ENABLE_IRQ0x000d
+
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
@@ -78,6 +80,8 @@
#define WR_RD_PIN_MONITORING 0x0060
#define GPMC_PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
#define GPMC_PREFETCH_STATUS_COUNT(val)(val 0x3fff)
+#define GPMC_IRQ_FIFOEVENTENABLE 0x01
+#define GPMC_IRQ_COUNT_EVENT 0x02
/*
* Note that all values in this struct are in nanoseconds, while
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 6562cd0..5e69463 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -20,6 +20,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ int gpmc_irq;
unsigned long phys_base;
int devsize;
};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index ffc3720..46361ef 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -112,6 +112,9 @@ config MTD_NAND_OMAP_PREFETCH
help
The NAND device can be accessed for Read/Write using GPMC PREFETCH
engine
to improve the performance.
+GPMC PREFETCH can be configured eigther in MPU interrupt mode or in DMA
+interrupt mode. If not selected any of them prefetch will be used in
+polling mode.
config MTD_NAND_OMAP_PREFETCH_DMA
depends on MTD_NAND_OMAP_PREFETCH
@@ -120,7 +123,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA
help
The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
or in DMA interrupt mode.
-Say y for DMA mode or MPU mode will be used
+Say y for DMA mode
+
+config MTD_NAND_OMAP_PREFETCH_IRQ
+ depends on MTD_NAND_OMAP_PREFETCH !MTD_NAND_OMAP_PREFETCH_DMA
+ bool IRQ mode
+ default n
+ help
+The GPMC PREFETCH engine can be configured eigther in MPU interrupt
mode
+or in DMA interrupt mode.
+Say y for IRQ mode
config MTD_NAND_IDS
tristate
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 133d515..6a57743 100644
---
[PATCH v3 3/4] omap: nand: ecc layout select from board file
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-flash.c |3 ++-
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 29 +
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index c6a07dd..ab31e7f 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -143,7 +143,8 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
- board_nand_data.nr_parts= nr_parts;
+ board_nand_data.nr_parts= nr_parts;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
gpmc_nand_init(board_nand_data);
}
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 5e69463..2e026e4 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -23,6 +23,12 @@ struct omap_nand_platform_data {
int gpmc_irq;
unsigned long phys_base;
int devsize;
+ enum {
+ OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT = 0,
+ /* 1-bit s/w ecc and layout different from romcode */
+ OMAP_ECC_HAMMING_CODE_HW,/* 1-bit ecc, romcode layout */
+ OMAP_ECC_HAMMING_CODE_SW,/* 1-bit ecc, romcode layout */
+ } ecc_opt;
};
/* minimum size for IO mapping */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d5fad84..0464a19 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -7,7 +7,6 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#define CONFIG_MTD_NAND_OMAP_HWECC
#include linux/platform_device.h
#include linux/dma-mapping.h
@@ -658,8 +657,6 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
return 0;
}
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
-
/**
* gen_true_ecc - This function will generate true ECC value
* @ecc_buf: buffer to store ecc code
@@ -879,8 +876,6 @@ static void omap_enable_hwecc(struct mtd_info *mtd, int
mode)
gpmc_enable_hwecc(info-gpmc_cs, mode, dev_width, info-nand.ecc.size);
}
-#endif
-
/**
* omap_wait - wait until the command is done
* @mtd: MTD device structure
@@ -1059,17 +1054,19 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
info-nand.verify_buf = omap_verify_buf;
-#ifdef CONFIG_MTD_NAND_OMAP_HWECC
- info-nand.ecc.bytes= 3;
- info-nand.ecc.size = 512;
- info-nand.ecc.calculate= omap_calculate_ecc;
- info-nand.ecc.hwctl= omap_enable_hwecc;
- info-nand.ecc.correct = omap_correct_data;
- info-nand.ecc.mode = NAND_ECC_HW;
-
-#else
- info-nand.ecc.mode = NAND_ECC_SOFT;
-#endif
+ /* selsect the ecc type */
+ if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) ||
+ (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW)) {
+ info-nand.ecc.bytes= 3;
+ info-nand.ecc.size = 512;
+ info-nand.ecc.calculate= omap_calculate_ecc;
+ info-nand.ecc.hwctl= omap_enable_hwecc;
+ info-nand.ecc.correct = omap_correct_data;
+ info-nand.ecc.mode = NAND_ECC_HW;
+
+ } else if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_SW) {
+ info-nand.ecc.mode = NAND_ECC_SOFT;
+ }
/* DIP switches on some boards change between 8 and 16 bit
* bus widths for flash. Try the other width if the first try fails.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] omap: nand: making ecc layout as compatible with romcode ecc
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-laod, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
This enables to flash x-load, u-boot, kernel, FS images from kernel itself
and compatiable with other tools.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-flash.c |2 +-
drivers/mtd/nand/omap2.c | 34 ++
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index ab31e7f..a15aab6 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -144,7 +144,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs)
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT;
+ board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW;
gpmc_nand_init(board_nand_data);
}
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0464a19..09b26d7 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -128,6 +128,20 @@ const int use_dma;
const int use_interrupt;
#endif
+/* oob info generated runtime depending on ecc algorithm and layout selected */
+static struct nand_ecclayout omap_oobinfo;
+/* Define some generic bad / good block scan pattern which are used
+ * while scanning a device for factory marked good / bad blocks
+ */
+static uint8_t scan_ff_pattern[] = { 0xff };
+static struct nand_bbt_descr bb_descrip_flashbased = {
+ .options = NAND_BBT_SCANEMPTY | NAND_BBT_SCANALLPAGES,
+ .offs = 0,
+ .len = 1,
+ .pattern = scan_ff_pattern,
+};
+
+
struct omap_nand_info {
struct nand_hw_control controller;
struct omap_nand_platform_data *pdata;
@@ -945,6 +959,7 @@ static int __devinit omap_nand_probe(struct platform_device
*pdev)
struct omap_nand_info *info;
struct omap_nand_platform_data *pdata;
int err;
+ int i, offset;
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1079,6 +1094,25 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
}
}
+ /* rom code layout */
+ if (pdata-ecc_opt != OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT) {
+ offset = (info-nand.options NAND_BUSWIDTH_16) ? 2 : 1;
+ if (info-mtd.oobsize == 16) {
+ info-nand.badblock_pattern = bb_descrip_flashbased;
+ omap_oobinfo.eccbytes = 3;
+ } else
+ omap_oobinfo.eccbytes = 3 * 4;
+
+ for (i = 0; i omap_oobinfo.eccbytes; i++)
+ omap_oobinfo.eccpos[i] = i+offset;
+
+ omap_oobinfo.oobfree-offset = offset + omap_oobinfo.eccbytes;
+ omap_oobinfo.oobfree-length = info-mtd.oobsize -
+ (offset + omap_oobinfo.eccbytes);
+
+ info-nand.ecc.layout = omap_oobinfo;
+ }
+
#ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err 0)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Joerg Roedel wrote: On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote: Hari Kanigeri wrote: He demonstrated the usage of his code in one of the emails he sent out initially. Did you go over that, and what (or how many) step would you use with the current code to do the same thing? -- So is this patch set adding layers and abstractions to help the User ? If the idea is to share some memory across multiple devices, I guess you can achieve the same by calling the map function provided by iommu module and sharing the mapped address to the 10's or 100's of devices to access the buffers. You would only need a dedicated virtual pool per IOMMU device to manage its virtual memory allocations. Yeah, you can do that. My idea is to get away from explicit addressing and encapsulate the device address to physical address link into a mapping. The DMA-API already does this with the help of IOMMUs if they are present. What is the benefit of your approach over that? The grist to the DMA-API mill is the opaque scatterlist. Each scatterlist element brings together a physical address and a bus address that may be different. The set of scatterlist elements constitute both the set of physical buffers and the mappings to those buffers. My approach separates these two things into a struct physmem which contains the set of physical buffers and a struct reservation which contains the set of bus addresses (or device addresses). Each element in the struct physmem may be of various lengths (without resorting to chaining). A map call maps the one set to the other. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Joerg Roedel wrote: On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote: Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs [...] Thats not true. Multiple IOMMUs are completly handled by the IOMMU drivers. In the case of the IOMMU-API backend drivers this also includes the ability to use page-tables on multiple IOMMUs. Yeah. I see that now. Since the particular topology is run-time configurable all of these use-cases and more can be expressed without pushing the topology into the low-level IOMMU driver. The IOMMU driver has to know about the topology anyway because it needs to know which IOMMU it needs to program for a particular device. Perhaps, but why not create a VCM which can be shared across all mappers in the system? Why bury it in a device driver and make all IOMMU device drivers managed their own virtual spaces? Practically this would entail a minor refactor to the fledging IOMMU interface; adding associate and activate ops. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). I partially agree here. All the IOMMU implementations in the Linux kernel have a lot of functionality in common where code could be shared. Work to share code has been done in the past by Fujita Tomonori but there are more places to work on. I am just not sure if a new front-end API is the right way to do this. I don't really think its a new front end API. Its just an API that allows easier mapping manipulation than the current APIs. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Joerg Roedel wrote: On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote: Daniel Walker wrote: So if we include this code which map implementations could you collapse into this implementations ? Generally , what currently existing code can VCMM help to eliminate? In theory, it can eliminate all code the interoperates between IOMMU, CPU and non-IOMMU based devices and all the mapping code, alignment, mapping attribute and special block size support that's been implemented. Thats a very abstract statement. Can you point to particular code files and give a rough sketch how it could be improved using VCMM? I can. Not to single out a particular subsystem, but the video4linux code contains interoperation code to abstract the difference between sg buffers, vmalloc buffers and physically contiguous buffers. The VCMM is an attempt to provide a framework where these and all the other buffer types can be unified. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-OPP][PATCH 0/4] OMAP: Clean up series for generic opp layer.
This patch series does some clean up of the opp layer including removal of compilation warnings, avoiding wrong inclusioin of header files, correcting some srror checks and removing the dependency of opp layer on cpu freq layer. Apart from all these there is still one more concern i have in this generic opp layer. This is regarding the separate PMIC opp file opp_twl_tps.c which today caters to only twl4030 and twl5030 pmic. What is the approach to be taken if the PMIC changes? I am already facing this issue with OMAP4 where the PMIC is twl6030 and the formulas for converting vsel into voltage and vice versa are different. I am against adding another file for twl6030. The approach is not scalable. We need to keep these vsel to uV and vice versa convertion in one place or make them functions pointers. Thara Gopinath (4): OMAP: Fix the compilation warning in the opp layer OMAP: Correct the return value check after call into find_device_opp OMAP: Remove inclusion of PMIC specific header file in generic opp layer. OMAP: Remove dependency of generic opp layer on cpufreq. arch/arm/plat-omap/Makefile |4 ++-- arch/arm/plat-omap/include/plat/opp.h |4 ++-- arch/arm/plat-omap/opp.c |7 +++ 3 files changed, 7 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-OPP][PATCH 2/4] OMAP: Correct the return value check after call into find_device_opp
Earlier we were checking on !dev_opp where as find_device_opp returns
a error pointer in case of error. So correcting the check as in the earlier
code even if find_device_opp returns an error opp_init_cpufreq_table
was not exiting.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index a06b88d..d88a2e0 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -457,8 +457,10 @@ void opp_init_cpufreq_table(struct device *dev,
int i = 0;
dev_opp = find_device_opp(dev);
- if (WARN_ON(!dev_opp))
+ if (IS_ERR(dev_opp)) {
+ WARN_ON(1);
return;
+ }
freq_table = kzalloc(sizeof(struct cpufreq_frequency_table) *
(dev_opp-enabled_opp_count + 1), GFP_ATOMIC);
--
1.7.0.rc1.33.g07cf0f
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-OPP][PATCH 4/4] OMAP: Remove dependency of generic opp layer on cpufreq.
This patch removes the dependency of the opp layer on cpufreq layer.
OPP layer is now enabled to compile and exist in the system
irrespective of whether cpu freq layer is enabled or not.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/Makefile |4 ++--
arch/arm/plat-omap/include/plat/opp.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index faf831d..852fa33 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -13,7 +13,7 @@ obj- :=
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# OPP support in (OMAP3+ only at the moment)
-ifdef CONFIG_CPU_FREQ
+ifdef CONFIG_PM
obj-$(CONFIG_ARCH_OMAP3) += opp.o
obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o
endif
@@ -37,4 +37,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
\ No newline at end of file
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 29e3d03..7d3e0ef 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -60,7 +60,7 @@ struct omap_opp_def {
struct omap_opp;
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_PM
unsigned long opp_get_voltage(const struct omap_opp *opp);
@@ -155,5 +155,5 @@ void opp_init_cpufreq_table(struct omap_opp *opps,
{
}
-#endif /* CONFIG_CPU_FREQ */
+#endif /* CONFIG_PM */
#endif /* __ASM_ARM_OMAP_OPP_H */
--
1.7.0.rc1.33.g07cf0f
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-OPP][PATCH 3/4] OMAP: Remove inclusion of PMIC specific header file in generic opp layer.
This patch removes the inclusion of plat/opp_twl_tps.h in opp.c. This header file is included unnecessarily and creats unwanted dependency between the generic opp layer and TWL4030/5030 PMIC dependent code. Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/plat-omap/opp.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c index d88a2e0..1aea69e 100644 --- a/arch/arm/plat-omap/opp.c +++ b/arch/arm/plat-omap/opp.c @@ -19,7 +19,6 @@ #include linux/err.h #include linux/list.h -#include plat/opp_twl_tps.h #include plat/opp.h #include plat/omap_device.h -- 1.7.0.rc1.33.g07cf0f -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-OPP][PATCH 1/4] OMAP: Fix the compilation warning in the opp layer
Fix the following warning from the opp layer during
compilation.
arch/arm/plat-omap/opp.c: In function 'opp_enable':
arch/arm/plat-omap/opp.c:405: warning: unused variable 'dev_opp'
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 0273497..a06b88d 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -402,8 +402,6 @@ int opp_add(const struct omap_opp_def *opp_def)
*/
int opp_enable(struct omap_opp *opp)
{
- struct device_opp *dev_opp;
-
if (unlikely(!opp || IS_ERR(opp))) {
pr_err(%s: Invalid parameters being passed\n, __func__);
return -EINVAL;
--
1.7.0.rc1.33.g07cf0f
--
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 3/3] mm: iommu: The Virtual Contiguous Memory Manager
Joerg Roedel wrote: On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote: Andi Kleen wrote: Hmm? dma_map_* does not change any CPU mappings. It only sets up DMA mapping(s). Sure, but I was saying that iommu_map() doesn't just set up the IOMMU mappings, its sets up both the iommu and kernel buffer mappings. What do you mean by kernel buffer mappings? In-kernel mappings whose addresses can be dereferenced. That assumes that all the IOMMUs on the system support the same page table format, right? Actually no. Since the VCMM abstracts a page-table as a Virtual Contiguous Region (VCM) a VCM can be associated with any device, regardless of their individual page table format. The IOMMU-API abstracts a page-table as a domain which can also be associated with any device (behind an iommu). It does, but only by convention. The domain member is just a big catchall void *. It would be more useful to factor out a VCM abstraction, with associated ops. As it stands all IOMMU device driver writters have to re-invent IOMMU virtual address management. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management
FUJITA Tomonori wrote: On Thu, 08 Jul 2010 16:59:52 -0700 Zach Pfeffer zpfef...@codeaurora.org wrote: The problem I'm trying to solve boils down to this: map a set of contiguous physical buffers to an aligned IOMMU address. I need to allocate the set of physical buffers in a particular way: use 1 MB contiguous physical memory, then 64 KB, then 4 KB, etc. and I need to align the IOMMU address in a particular way. Sounds like the DMA API already supports what you want. You can set segment_boundary_mask in struct device_dma_parameters if you want to align the IOMMU address. See IOMMU implementations that support dma_get_seg_boundary() properly. That function takes the wrong argument in a VCM world: unsigned long dma_get_seg_boundary(struct device *dev); The boundary should be an attribute of the device side mapping, independent of the device. This would allow better code reuse. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
