Re: [v2 1/2] usb: musb: omap2+: fix context api's
On Sun, Oct 9, 2011 at 11:08 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Sep 07, 2011 at 09:19:23AM -0700, Vikram Pandita wrote: From: Vikram Pandita vikram.pand...@ti.com RxFifoSz, TxFifoSz, RxFifoAddr, TxFifoAddr are all indexed registers. So before doing a context save or restore, INDEX register should be set, then only one gets to the right register offset. Signed-off-by: Vikram Pandita vikram.pand...@ti.com Signed-off-by: Anand Gadiyar gadi...@ti.com applied, thanks thanks. (sorry for the long delay) Late is better than never :-) -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Thu, Sep 8, 2011 at 3:41 PM, Mark Salter msal...@redhat.com wrote: On Wed, 2011-08-31 at 20:35 +0100, Will Deacon wrote: On Wed, Aug 31, 2011 at 07:19:33PM +0100, Rob Herring wrote: On 08/31/2011 12:51 PM, Will Deacon wrote: Another thing that Marc and I tried on OMAP4 was not bringing up the secondary CPU during boot (by commenting out most of smp_init). In this case, I/O performance was good until we tried to online the secondary CPU. The online failed but after that the I/O performance was certainly degraded. Was the SCU enabled at that point? One diff between nosmp boot and offlining the 2nd core would be that the SCU remains enabled in the latter case. I think the SCU does not get enabled for nosmp. Our rudimentary test (printing out the SCU control register during boot) showed that it *was* enabled for nosmp. I think this is due to the secure world having to do that on OMAP so it's probably not true for other platforms. I've done a little test and found that turning on the MMU of the second core causes the problem to show up. I patched head.S so I stopped the second core in an infinite loop just before turning on the MMU. The system continues booting on core#0 and I see ~20MB/s with hdparm -t to an attached usb disk. Same setup but with second core being stopped with infinite loop just after MMU is enabled shows ~5MB/s. So whatever is going wrong, its not because of anything the second core is doing beyond turning on its MMU and doing an empty loop. what was the final take on the optimization? Excuse if i could not follow the whole thread - could someone summarize for the benefit of many. Thanks --Mark ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev-prepare()
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2011 3:50 AM, Deepthi Dharwar wrote: The cpuidle_device-prepare() mechanism causes updates to the cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE to tell the governor not to chose a state on a per-cpu basis at run-time. State demotion is now handled by the driver and it returns the actual state entered. Hence, this mechanism is not required. Also this removes per-cpu flags from cpuidle_state enabling it to be made global. having worked on some newer platforms this one is really still needed. doing this inside the actual states does not work, because if the deepest 3 states are invalid, the same (somewhat expensive) test would have to be done 3 times, and each of the states would have to fail before the 4th one gets chosen. that's just not going to work (in the state handler you can't know what other state to fall back to, and especially not how to enter such a fallback state) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0= =FL6o -END PGP SIGNATURE- Hi Arjan, Thanks for the review. We retain the dev-prepare() routine and CPUIDLE_FLAG_IGNORE but still allow the dev-enter() to return index ? So by retaining it, transition to the idle states would be much quicker in case one more states are invalid. Also to note is that in the newer design, we have split the cpuidle_state structure. One global struct, cpuidle_states[] that contains all the state related information including flags, and the other cpuidle_device that contain statistics and other data that are per-cpu basis. So the flags are not per cpu per state basis but maintained globally as per state basis. So if we have to enable CPUIDLE_FLAG_IGNORE flag in this current new design, then I am thinking if we needed to have this on a per-cpu basis. If so, then flags have to be moved into cpuidle_device struct rather than cpuidle_state struct. Is it a good idea to retain these flags as global (part of cpuidle_states) or make it per-cpu basis ? -Thanks Deepthi -- 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] Change ECC algorithm from userspace
On Fri, 28 Oct 2011, Jon Povey wrote: linux-mtd-boun...@lists.infradead.org wrote: I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. Slightly off-topic, but in the 355/365 (etc) case it's possible to modify the Linux driver so it uses the RBL ECC layout. For us, it seemed the easiest thing to do, as having different ECC layouts in different parts of the flash proved to be a pain. If you need different ECC algorithms in different parts of the flash this wouldn't work of course. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 -- 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 17/51] ARM: OMAP: convert reset to use arm_arch_reset (fwd)
Hello Paul, hello Will,
On Fri, Oct 28, 2011 at 5:47 PM, Paul Walmsley p...@pwsan.com wrote:
fyi
- Paul
-- Forwarded message --
Date: Fri, 28 Oct 2011 15:43:45 +0100
From: Will Deacon will.dea...@arm.com
To: linux-arm-ker...@lists.infradead.org
Cc: Paul Walmsley p...@pwsan.com, Will Deacon will.dea...@arm.com
Subject: [PATCH 17/51] ARM: OMAP: convert reset to use arm_arch_reset
From: Paul Walmsley p...@pwsan.com
Align the OMAP reset code with Will Deacon's ARM: reset: introduce
arm_arch_reset function pointer cleanup patch.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm/mach-omap1/board-voiceblue.c | 2 +-
arch/arm/mach-omap1/io.c | 4
arch/arm/mach-omap1/reset.c | 2 --
arch/arm/mach-omap2/io.c | 7 ++-
arch/arm/mach-omap2/prcm.c | 4 +---
arch/arm/plat-omap/include/plat/system.h | 6 +-
6 files changed, 17 insertions(+), 8 deletions(-)
snip
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 2e40a5c..ad3ac5c 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -58,7 +58,7 @@ u32 omap_prcm_get_reset_sources(void)
EXPORT_SYMBOL(omap_prcm_get_reset_sources);
/* Resets clock rates and reboots the system. Only called from system.h */
I think it is no longer called from system.h only, isn't?
-static void omap_prcm_arch_reset(char mode, const char *cmd)
+void omap_prcm_arch_reset(char mode, const char *cmd)
{
s16 prcm_offs = 0;
Thomas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Change ECC algorithm from userspace
Hi, On Friday 28 October 2011 12:30:51 Matthieu CASTET wrote: Hi, Javier Martinez Canillas a écrit : Hello, I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? We use raw programming and compute the ecc in software. We are doing something similar here as well. Our bootloader also requires the data to be layed out differently (data + ecc interleaved inside a page + oob). What is the best approach to store data in a NAND device using different ECC techniques? I've think of two approaches: 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change the ECC technique used. But this won't work if there is concurrent acess to mtd. One program may want 1 bit ecc other want 4 bits ecc. 2- Use a platform data field to notify the omap2 nand driver that the ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write and read the first 4 sectors but a 4-bit ECC for the rest. This may be better. Would not it better to add infrastructure for allowing per-partition ECC scheme? This should allow the kernel to also be able to properly handle the bootloader partitions (bad-block scanning ...). Matthieu PS : note that some OMAP ROM support a better protection than Hamming (but the details are not public AFAIK) From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version : Pages can contain errors caused by memory alteration. To correct these errors, the ROM code uses ECC, based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri, Hocquenghem) code for multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in the spare area of the corresponding page. If there are uncorrectable errors, the ROM code returns with FAIL. -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v4] net/smsc911x: Add regulator support
Add some basic regulator support for the power pins, as needed
by the ST-Ericsson Snowball platform that powers up the SMSC911
chip using an external regulator.
Platforms that use regulators and the smsc911x and have no defined
regulator for the smsc911x and claim complete regulator
constraints with no dummy regulators will need to provide it, for
example using a fixed voltage regulator. It appears that this may
affect (apart from Ux500 Snowball) possibly these archs/machines
that from some grep:s appear to define both CONFIG_SMSC911X and
CONFIG_REGULATOR:
- ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines
- Blackfin
- Super-H
Cc: Paul Mundt let...@linux-sh.org
Cc: linux...@vger.kernel.org
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Tony Lindgren t...@atomide.com
Cc: linux-omap@vger.kernel.org
Cc: Mike Frysinger vap...@gentoo.org
Cc: uclinux-dist-de...@blackfin.uclinux.org
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
Signed-off-by: Robert Marklund robert.markl...@stericsson.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v3-v4:
- Remove dual prints and old comment on Mike's request.
- Split the request_free fucntion on Mike and Sascha request.
ChangeLog v2-v3:
- Use bulk regulators on Mark's request.
- Add Cc-fileds to some possibly affected platforms.
ChangeLog v1-v2:
- Don't check for NULL regulators and error out properly if the
regulators can't be found. All platforms using the smsc911x
and the regulator framework simultaneously need to provide some
kind of regulator for it.
---
drivers/net/ethernet/smsc/smsc911x.c | 103 ++
1 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 8843071..9a2e792 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -44,6 +44,7 @@
#include linux/module.h
#include linux/netdevice.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/sched.h
#include linux/timer.h
#include linux/bug.h
@@ -88,6 +89,8 @@ struct smsc911x_ops {
unsigned int *buf, unsigned int wordcount);
};
+#define SMSC911X_NUM_SUPPLIES 2
+
struct smsc911x_data {
void __iomem *ioaddr;
@@ -138,6 +141,9 @@ struct smsc911x_data {
/* register access functions */
const struct smsc911x_ops *ops;
+
+ /* regulators */
+ struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
};
/* Easy access to information */
@@ -362,6 +368,68 @@ out:
spin_unlock_irqrestore(pdata-dev_lock, flags);
}
+/*
+ * Enable or disable resources, currently just regulators.
+ */
+static int smsc911x_enable_disable_resources(struct platform_device *pdev,
+bool enable)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* enable/disable regulators */
+ if (enable) {
+ ret = regulator_bulk_enable(ARRAY_SIZE(pdata-supplies),
+ pdata-supplies);
+ if (ret)
+ netdev_err(ndev, failed to enable regulators %d\n,
+ ret);
+ } else
+ ret = regulator_bulk_disable(ARRAY_SIZE(pdata-supplies),
+ pdata-supplies);
+ return ret;
+}
+
+/*
+ * Request resources, currently just regulators.
+ *
+ * The SMSC911x has two power pins: vddvario and vdd33a, in designs where
+ * these are not always-on we need to request regulators to be turned on
+ * before we can try to access the device registers.
+ */
+static int smsc911x_request_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* Request regulators */
+ pdata-supplies[0].supply = vdd33a;
+ pdata-supplies[1].supply = vddvario;
+ ret = regulator_bulk_get(pdev-dev,
+ ARRAY_SIZE(pdata-supplies),
+ pdata-supplies);
+ if (ret)
+ netdev_err(ndev, couldn't get regulators %d\n,
+ ret);
+ return ret;
+}
+
+/*
+ * Free resources, currently just regulators.
+ *
+ */
+static void smsc911x_free_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+
+ /* Free regulators */
+ regulator_bulk_free(ARRAY_SIZE(pdata-supplies),
+ pdata-supplies);
+}
+
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
* and smsc911x_mac_write, so assumes mac_lock is held */
static int smsc911x_mac_complete(struct smsc911x_data *pdata)
@@ -2092,6 +2160,9 @@ static
Re: [PATCH v3] usb: ehci: report Data Buffer Error in debug mode
On Sun, 30 Oct 2011, Vikram Pandita wrote:
From: Vikram Pandita vikram.pand...@ti.com
Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.
This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.
This is a good error to flag allowing system level corrections.
An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Reviewed-by: Marek Vasut marek.va...@gmail.com
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
v1: original patch
v2: fix review comments from Alan Stern
* use usb_endpoint_num, usb_endpoint_dir_in
v3: More comments from Alan Stern
* indent, use qh
drivers/usb/host/ehci-q.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 4e4066c..f136f7f1 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -373,6 +373,17 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh
*qh)
retry_xacterr:
if ((token QTD_STS_ACTIVE) == 0) {
+ /* Report Data Buffer Error: non-fatal but useful */
+ if (token QTD_STS_DBE)
+ ehci_dbg(ehci,
+ detected DataBufferErr for urb %p
ep%d%s len %d, qtd %p [qh %p]\n,
+ urb,
+ usb_endpoint_num(urb-ep-desc),
+ usb_endpoint_dir_in(urb-ep-desc) ?
in : out,
+ urb-transfer_buffer_length,
+ qtd,
+ qh);
+
/* on STALL, error, and short reads this urb must
* complete and all its qtds must be recycled.
*/
Signed-off-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP2+: DMA: fix src/dst position reporting
Hello, If the user asks for the sDMA current position before the first data has been transmitted (before the first DMA request has been generated), the reported position is not valid: src position: CSAC is uninitialized dst position: CDAC is 0 The return values in both case considered invalid. This sitation can be identified by checking if the CDAC register is 0 (it is initialized to 0 in omap_dam_start call). In this case return the programmed source/destination address. The affected omap_get_dma_src_pos/omap_get_dma_dst_pos functions are used by the audio stack mainly for checking the current position of the audio stream. Regards, Peter --- Peter Ujfalusi (2): OMAP2+: DMA: Workaround for invalid source position OMAP2+: DMA: Workaround for invalid destination position arch/arm/plat-omap/dma.c | 25 ++--- 1 files changed, 22 insertions(+), 3 deletions(-) -- 1.7.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 2/2] OMAP2+: DMA: Workaround for invalid destination position
If the DMA destination position has been asked before the
first actual data transfer has been done, the CDAC
register still contains 0 (it is initialized to 0 at
omsp_dma_start).
If CDAC == 0, return the programmed start address.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 38b0d44..9186491 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1066,8 +1066,16 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
if (cpu_is_omap15xx())
offset = p-dma_read(CPC, lch);
- else
+ else {
offset = p-dma_read(CDAC, lch);
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed destination start address in this case.
+*/
+ if (unlikely(!offset))
+ offset = p-dma_read(CDSA, lch);
+ }
/*
* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
--
1.7.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 1/2] OMAP2+: DMA: Workaround for invalid source position
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/dma.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..38b0d44 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1024,12 +1024,23 @@ EXPORT_SYMBOL(omap_set_dma_callback);
*/
dma_addr_t omap_get_dma_src_pos(int lch)
{
+ u32 cdac;
dma_addr_t offset = 0;
if (cpu_is_omap15xx())
offset = p-dma_read(CPC, lch);
- else
- offset = p-dma_read(CSAC, lch);
+ else {
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed source start address in this case.
+*/
+ cdac = p-dma_read(CDAC, lch);
+ if (likely(cdac))
+ offset = p-dma_read(CSAC, lch);
+ else
+ offset = p-dma_read(CSSA, lch);
+ }
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) offset == 0)
offset = p-dma_read(CSAC, lch);
--
1.7.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/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 28 Oct 2011 15:03:36 +0300, Tero Kristo said: Hi Again, I created a new version of the patch which should be better than this hack, I'll send it as an RFC to the l-o list in a bit. On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote: On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo t-kri...@ti.com wrote: On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote: On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote: On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote: Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. Kotipaikka: Helsinki Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: 0115040-6. Domicile: Helsinki Moral: Just leave current street addresses out of it. :) And can we *please* trim irrelevant stuff? You top-posted a 2 line reply, followed by the entire note, which a bunch of kernel developers got to scroll through and wonder if they missed an in-line comment. *Especially* after the top part had one line that it wasn't clear if it was a top-posted sig line gone wrong, or 3 attempts to get an address right for inclusion in a patch. pgpPuwI7FKr6i.pgp Description: PGP signature
Re: [PATCH 2/2 v4] net/smsc911x: Add regulator support
On Monday 31 October 2011 08:38:39 Robert Marklund wrote: ChangeLog v3-v4: - Remove dual prints and old comment on Mike's request. - Split the request_free fucntion on Mike and Sascha request. would be nice if the enable/disable were split as well ... iounmap(pdata-ioaddr); + (void)smsc911x_enable_disable_resources(pdev, false); i don't think the (void) cast is necessary otherwise looks fine -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH v5 2/7] arm: pmu: allow platform specific irq enable/disable handling
Hi,
Attach the patch [PATCH v5 2/7] which is rebased on 3.1 -next.
BTW: The [PATCH v5 3/7] should be dropped as commented before, other patches
are OK against 3.1 -next.
thanks,
--
Ming Lei
--
From 6125bef1aeee84ef22efdf743077f27f5274b6da Mon Sep 17 00:00:00 2001
From: Ming Lei ming@canonical.com
Date: Wed, 2 Mar 2011 15:00:08 +0800
Subject: [PATCH v6 2/6] arm: pmu: allow platform specific irq enable/disable
handling
This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.
This patch is for support of pmu irq routed from CTI on omap4.
Acked-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Will Deacon will.dea...@arm.com
Signed-off-by: Ming Lei ming@canonical.com
---
arch/arm/include/asm/pmu.h | 15 ---
arch/arm/kernel/perf_event.c | 10 --
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 71d99b8..46a96a8 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -27,13 +27,22 @@ enum arm_pmu_type {
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ * interrupt and passed the address of the low level handler,
+ * and can be used to implement any platform specific handling
+ * before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ * request_irq and be used to handle some platform specific
+ * irq enablement
+ * @disable_irq: an optional handler which will be called before
+ * free_irq and be used to handle some platform specific
+ * irq disablement
*/
struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
+ void (*enable_irq)(int irq);
+ void (*disable_irq)(int irq);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index e6e5d7c..4c4aa83 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -374,6 +374,8 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu-plat_device;
+ struct arm_pmu_platdata *plat =
+ dev_get_platdata(pmu_device-dev);
irqs = min(pmu_device-num_resources, num_possible_cpus());
@@ -381,8 +383,11 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
if (!cpumask_test_and_clear_cpu(i, armpmu-active_irqs))
continue;
irq = platform_get_irq(pmu_device, i);
- if (irq = 0)
+ if (irq = 0) {
+ if (plat plat-disable_irq)
+ plat-disable_irq(irq);
free_irq(irq, armpmu);
+ }
}
release_pmu(armpmu-type);
@@ -439,7 +444,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
irq);
armpmu_release_hardware(armpmu);
return err;
- }
+ } else if (plat plat-enable_irq)
+ plat-enable_irq(irq);
cpumask_set_cpu(i, armpmu-active_irqs);
}
--
1.7.5.4
--
Ming Lei
--
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
DaVinci NAND writing utility release, was: RE: [RFC] Change ECC algorithm from userspace
Adding davinci linux open source ML to CC as folk there might find this utility useful. Javier Martinez Canillas wrote: On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey jon.po...@racelogic.co.uk wrote: linux-mtd-boun...@lists.infradead.org wrote: DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. What I have done is write a utility that calculates ECC and writes to the mtd device in RAW mode. So to rewrite the bootloader I take care of the ECC and layout at application level without changing the kernel. Is your utility publicly available? It would be great if I can use it as an starting point. Management have given the thumbs-up, this is now released under GPL v2 at https://github.com/jonpovey/flashtool Supports DM355 and DM365 RBL layouts, ECC generation, UBI image writing, and various bad block / range handling. Enjoy! -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network -- 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
