Re: [PATCH] drm/omap: use omapdss low level API
On 2012-11-16 14:19, Greg KH wrote: On Thu, Nov 15, 2012 at 06:00:58PM -0600, Rob Clark wrote: This patch changes the omapdrm KMS to bypass the omapdss compat layer and use the core omapdss API directly. This solves some layering issues that would cause unpin confusion vs GO bit status, because we would not know whether a particular pageflip or overlay update has hit the screen or not. Now instead we explicitly manage the GO bits in dispc and handle the vblank/framedone interrupts ourself so that we always know which buffers are being scanned out at any given time, and so on. As an added bonus, we no longer leave the last overlay buffer pinned when the display is disabled, and have been able to add the previously missing vblank event handling. Signed-off-by: Rob Clark robdcl...@gmail.com --- Note: this patch applies on top of staging-next plus the OMAPDSS: create compat layer patch series: http://comments.gmane.org/gmane.linux.ports.arm.omap/89435 Hm, I can't take that patch set in staging-next, so how should this go in? I wonder, could the omapdrm part go in for -rc2? It's only a driver in staging. I think that would be the easiest way. Perhaps it'd be even possible to split the patch into two, of which the first half would not depend on omapdss, but would prepare omapdrm for the change, thus making the patch for -rc2 smaller. Otherwise it's more tricky... Either wait for 3.9, or get omapdss, omapfb and omapdrm merged via the same tree. But which that would be? omapdss and omapfb usually go through fbdev tree. I don't know what its maintainer thinks of merging drm driver. And if the omapdrm depends on new drm changes, I guess fbdev is out of the question. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] OMAPDSS: OMAPFB: Fix possible null pointer dereferencing
On 2012-11-19 07:10, Tushar Behera wrote:
If display is NULL, display-output would lead to kernel panic.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 55a39be..532a31b 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -787,7 +787,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
case OMAPFB_WAITFORVSYNC:
DBG(ioctl WAITFORVSYNC\n);
- if (!display !display-output !display-output-manager) {
+ if (!display || !display-output || !display-output-manager) {
r = -EINVAL;
break;
}
Thanks, good catch. However, the patch description is not very good.
If you agree with the change, I'll apply the patch with the description:
OMAPFB: Fix possible null pointer dereferencing
Commit 952cbaaa9b8beacc425f9aedf370468cbb737a2c (OMAPFB: Change
dssdev-manager references) added checks for OMAPFB_WAITFORVSYNC ioctl
to verify that the display, output and overlay manager exist. However,
the code erroneously uses for each part, which means that
OMAPFB_WAITFORVSYNC may crash the kernel if no display, output or
manager is associated with the framebuffer.
This patch fixes the issue by using ||.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
Hi Linus, On 11/17/2012 09:16 PM, Linus Walleij wrote: On Tue, Nov 13, 2012 at 10:35 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: Avoid using the TWL4030_MODULE_PWMA/B as module ID. The LEDEN, PWMA ON/OFF and PWMB ON/OFF registers are in a continuous range starting from LED base. This is going to be helpful for further cleanup in the twl stack. No functional changes. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com OK if you say so. Patch applied! Thanks, I was actually tempted to remove the whole LED (PWM) thing from the gpio-twl4030 driver. It was a big surprise to me to see something like this in there. It turns out that on BeagleBoard the USB host enable signal is connected to LEDA (PWMA) of twl4030... It is an enable signal. Seriously. So what we do here is either configure the PWMs as full on, or turn it off. I'm not sure how common is this practice (PWM to drive enable signal) but if we have more than one board out there with this type of connection we might be better to add a 'gpio-pwm.c' driver to handle them. Either way this is wrong IMHO to handle the LEDA/B via the gpio-twl4030 driver. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/4] i2c: introduce i2c-cbus-gpio driver
On Sun, Nov 18, 2012 at 06:36:19PM +0200, Aaro Koskinen wrote: Add i2c driver to enable access to devices behind CBUS on Nokia Internet Tablets. The patch also adds CBUS I2C configuration for N8x0 which is one of the users of this driver. Cc: linux-...@vger.kernel.org Acked-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Applied to for-next, thanks! -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: tfp410 and i2c_bus_num
hi, On Mon, Nov 19, 2012 at 08:38:21AM +0200, Tomi Valkeinen wrote: (dropping Tony and stable) On 2012-11-18 13:34, Felipe Balbi wrote: how are you toggling the gpio ? You said tfp410 isn't controlled at all except for the power down gpio. Who provides the gpio ? It's a normal OMAP GPIO, going to TFP410. I use gpio_set_value() to set/unset it. ok, fair enough. Well, it's not that simple. TFP410 manages hot plug detection of the HDMI cable (although not implemented currently), so the we'd need to convey that information to the i2c-edid somehow. Which, of course, is doable, but increases complexity. I'd say it would decrease it since you would have a single copy of i2c-edid.c for DRM or DSS or any other panel/display framework. Well. Reading EDID via i2c is one or two i2c reads. There's nothing else to it. still avoids duplication :-) If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. that should all be doable, just look at how v4l2 handles pipelining the video data (all in userland though) and you'll see it's definitely possible. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. until you have e.g. tfp999, tfp534, tfp678 (hypothetical device numbers, they probably don't exist) which are all SW incompatible and you have to duplicate i2c reads in all of them. Whereas if you had a dedicated i2c-edid.c driver, you would only have to tell them where to get EDID structure from. Also, if you have systems with different panel interfaces, they will use the same i2c-edid.c and just instantiate that class multiple times. Another thing is that even if in this case the i2c and EDID reading are separate from the actual video path, that may not be the case for other display solutions. We could have a DSI panel which reports its resolution via DSI bus, or we could have an external DSI-to-HDMI chip, which reads the EDID via i2c from the monitor, but reports them back to the SoC via DSI bus. In this last case we would see just the DSI, not the I2C bus, so it's like I2C bus doesn't exist, so in fact we would have two possibilities: a) read EDID via I2C bus (standard HDMI) b) read EDID via DSI. Right. And currently reading edid is done via read_edid call with omapdss, and the caller doesn't care if read_edid uses i2c or DSI, so it should just work. b) doesn't exist today so we need to care about it until something like what you say shows up in the market. Until then, we care for EDID over I2C IMHO. There are chips such as I described, although not supported in the mainline. fair enough. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. yes, but that can't be done in another way right ? Try something like having a EDID provider and an EDID consumer. The provider will be i2c-edid.c or dvi-edid.c and the consumer will a generic layer which tfp410 would use to request certain attributes from the EDID structure. I think that would look a lot nicer as the underlying implementation for requesting EDID would be completely encapsulated from its users. way for that case you wanna cope with other methods for reading EDID, then you need a generic layer which doesn't care if it's I2C or DSI. Currently implementation is hardcoded to I2C anyway. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. it's not very well designed, then, if tfp410 still needs to fetch the i2c adapter. It still has to know about the underlying bus for reading EDID. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read EDID via DSI. TFP410 is a parallel RGB to DVI chip. It's not related to DSI. The DSI case would be with some other chip. it doesn't change what I said, however. Another chip will need to be
Re: [PATCH] OMAPDSS: OMAPFB: Fix possible null pointer dereferencing
On 11/19/2012 02:14 PM, Tomi Valkeinen wrote:
On 2012-11-19 07:10, Tushar Behera wrote:
If display is NULL, display-output would lead to kernel panic.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 55a39be..532a31b 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -787,7 +787,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
case OMAPFB_WAITFORVSYNC:
DBG(ioctl WAITFORVSYNC\n);
-if (!display !display-output !display-output-manager) {
+if (!display || !display-output || !display-output-manager) {
r = -EINVAL;
break;
}
Thanks, good catch. However, the patch description is not very good.
I agree.
If you agree with the change, I'll apply the patch with the description:
Please go ahead with the description that you have written here.
OMAPFB: Fix possible null pointer dereferencing
Commit 952cbaaa9b8beacc425f9aedf370468cbb737a2c (OMAPFB: Change
dssdev-manager references) added checks for OMAPFB_WAITFORVSYNC ioctl
to verify that the display, output and overlay manager exist. However,
the code erroneously uses for each part, which means that
OMAPFB_WAITFORVSYNC may crash the kernel if no display, output or
manager is associated with the framebuffer.
This patch fixes the issue by using ||.
Tomi
Thanks.
--
Tushar Behera
--
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] dmaengine: omap-dma: Allow DMA controller to prefetch data
On 11/17/2012 12:31 PM, Russell King - ARM Linux wrote: On Fri, Oct 19, 2012 at 02:45:55PM +0200, Péter Ujfalusi wrote: Hi, On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote: I'm merely pointing out here that we need their feedback here before deciding if there's anything further that needs to happen. Thanks Russell, I'll take a look at the implication of the prefetch for audio. Péter, any news? Sorry, I was carried away with other things... I did some testing with and without the dma prefetch for audio (on BeagleBoard with mplayer: -ao alsa/pulse). When we have prefetch enabled we tend to resume after pause from a slightly off place than when the prefetch is disabled. I also remember that in n9 we have had some issue with the DMA prefetch. So I would for sure enable the prefetch for non cyclic DMA. For the cyclic I would not enable it for now. I need to dig a bit deeper in DMA/McBSP to have better view on the issue. I have one comment to the patch itself as well. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
Hi,
On 10/19/2012 12:20 AM, Mark A. Greer wrote:
Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
flag whenever there is a destination synchronized DMA transfer.
Prefetching is not allowed on source synchronized DMA transfers.
Enabling prefetch significantly improves DMA performance.
For example, running 'modprobe tcrypt sec=2 mode=403' which
exercises the omap-sham driver on an am37x EVM yeilds the
following results:
drivers/dma/omap-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..aadddb2 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_slave_sg(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
This should be:
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC_PREFETCH;
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
@@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
We should not enable the prefetch for cyclic right now. We will investigate it
more.
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] OMAP USB Host cleanup
Kevin, On 11/16/2012 10:08 PM, Kevin Hilman wrote: Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( oh that's bad. But this series wasn't meant to fix that ;). I could take a look at it once I get hold of the serial cable to connect to the beagle. regards, -roger -- 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] spi: omap2-mcspi: Fix the redifine warning
Shubhrajyoti == Shubhrajyoti D shubhrajy...@ti.com writes: Shubhrajyoti Fix the below warning Shubhrajyoti drivers/spi/spi-omap2-mcspi.c:336:34: warning: symbol Shubhrajyoti 'tx' shadows an earlier one Shubhrajyoti drivers/spi/spi-omap2-mcspi.c:327:12: originally declared Shubhrajyoti here Shubhrajyoti So delete the u8 tx as it is assigned and not Shubhrajyoti used(resigned afterwards). Shubhrajyoti Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Acked-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard -- 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] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
On Mon, Nov 19, 2012 at 9:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: I was actually tempted to remove the whole LED (PWM) thing from the gpio-twl4030 driver. It was a big surprise to me to see something like this in there. It looks wrong. In theory I think this should be ripped out and moved to drivers/leds/leds-twl4030.c. But that would only be in case it was *always* exclusively used for a LED and as you say: It turns out that on BeagleBoard the USB host enable signal is connected to LEDA (PWMA) of twl4030... It is an enable signal. Seriously. So what we do here is either configure the PWMs as full on, or turn it off. Sounds like some hardware engineer has been having fun or was just out of GPIOs to use... So this LED PWM is also used as a GPIO. I think this part of the driver should be moved to drivers/pwm/pwm-twl4030.c and modeled as a PWM. If some platform need to use the PWM as if it was a GPIO then that's just a special usecase. (Setting duty cycles to something like INT_MAX and just switching polarity to toggle it...) If it needs to be used by a LED there needs to be some generic LED type just using a standard pwm_request() to get some specific PWM, such as leds/leds-pwm.c or so. This way the PWM can be used for LEDs if need be or other things... Sounds correct, Sascha? Either way this is wrong IMHO to handle the LEDA/B via the gpio-twl4030 driver. It's confusing indeed. So what we're dealing with is: a LED-specific PWM, being used as a PWM with eternal dutycycle and then being used as GPIO. Well, we get to deal with it ... :-/ Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Sunday 18 November 2012 08:36 PM, Igor Grinberg wrote: CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER setting. To remove the dependancy, several conversions/additions had to be done: 1) Timer initialization functions are named by the platform name and the clock source in use. This also makes it possible to define and use the GPTIMER as the clock source instead of the 32K timer on platforms that do not have the 32K timer ip block or the 32K timer is not wired on the board. Cirrently, the the timer is chosen in the machine_desc structure on per board basis. Later, DT should be used to choose the timer. 2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults and those under !CONFIG_OMAP_32K_TIMER are removed. This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code. 3) Since we have all the timers defined inside machine_desc structure and we no longer need the fallback to gp_timer clock source in case 32k_timer clock source is unavailable (namely on AM33xx), we no longer need the #ifdef around __omap2_sync32k_clocksource_init() function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the __omap2_sync32k_clocksource_init() function. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Cc: Jon Hunter jon-hun...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Vaibhav Hiremath hvaib...@ti.com --- nice clean-up Igor. Patch looks good to my eyes. Feel free to add , Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
AnilKumar == AnilKumar Ch anilku...@ti.com writes: s/shutdowm/shutdown/ in the subject. AnilKumar From: Colin Foe-Parker colin.foepar...@logicpd.com AnilKumar Set tps65217 PMIC status to OFF if power enable toggle is AnilKumar supported. Also adds platform data flag, which should be AnilKumar passed from board init data. You're adding dt binding, not platform data. AnilKumar Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com AnilKumar [anilku...@ti.com: move the additions to tps65217 MFD driver] AnilKumar Signed-off-by: AnilKumar Ch anilku...@ti.com AnilKumar --- AnilKumar .../devicetree/bindings/regulator/tps65217.txt |4 AnilKumar drivers/mfd/tps65217.c | 12 AnilKumar 2 files changed, 16 insertions(+) AnilKumar diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt AnilKumar index d316fb8..4f05d20 100644 AnilKumar --- a/Documentation/devicetree/bindings/regulator/tps65217.txt AnilKumar +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt AnilKumar @@ -11,6 +11,9 @@ Required properties: AnilKumarusing the standard binding for regulators found at AnilKumarDocumentation/devicetree/bindings/regulator/regulator.txt. AnilKumar +Optional properties: AnilKumar +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle. Ehh, I don't know the tps65217 particular well, but according to the datasheet the REG_STATUS_OFF bit enables/disables the PB_IN pin, not PWR_EN. It's also not only about powering down but also powering up again. I don't feel this property name is very clear. Perhaps something about power button or push button monitor as it is called in the datasheet? -- Bye, Peter Korsgaard -- 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] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
On Mon, Nov 19, 2012 at 11:40:30AM +0100, Linus Walleij wrote: On Mon, Nov 19, 2012 at 9:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: I was actually tempted to remove the whole LED (PWM) thing from the gpio-twl4030 driver. It was a big surprise to me to see something like this in there. It looks wrong. In theory I think this should be ripped out and moved to drivers/leds/leds-twl4030.c. But that would only be in case it was *always* exclusively used for a LED and as you say: It turns out that on BeagleBoard the USB host enable signal is connected to LEDA (PWMA) of twl4030... It is an enable signal. Seriously. So what we do here is either configure the PWMs as full on, or turn it off. Sounds like some hardware engineer has been having fun or was just out of GPIOs to use... So this LED PWM is also used as a GPIO. I think this part of the driver should be moved to drivers/pwm/pwm-twl4030.c and modeled as a PWM. If some platform need to use the PWM as if it was a GPIO then that's just a special usecase. (Setting duty cycles to something like INT_MAX and just switching polarity to toggle it...) If it needs to be used by a LED there needs to be some generic LED type just using a standard pwm_request() to get some specific PWM, such as leds/leds-pwm.c or so. This way the PWM can be used for LEDs if need be or other things... Either I'm misinterpreting you or you didn't have a look in the tree. Actually drivers/leds/leds-pwm.c already exists. Sounds correct, Sascha? Yes, the twl4030 pwm should go to drivers/pwm/pwm-twl4030.c. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: tfp410 and i2c_bus_num
On 2012-11-19 11:27, Felipe Balbi wrote: If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. that should all be doable, just look at how v4l2 handles pipelining the video data (all in userland though) and you'll see it's definitely possible. Afaik, v4l2 handles only the pipeline for video. This i2c-edid would not be part of the video pipeline, so I don't see a connection to v4l2. And I'm not saying it's not possible, or that the current way is good or correct. I'm saying it's not easy, and definitely more complex than the current tfp410 implementation. The amount of code related to this feature would multiply. If we had 10 different tfp410 like drivers, then obviously there'd be more pressing reason to clean this up. But currently we have only one place where this code is used. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. until you have e.g. tfp999, tfp534, tfp678 (hypothetical device numbers, they probably don't exist) which are all SW incompatible and you have to duplicate i2c reads in all of them. Whereas if you had a dedicated i2c-edid.c driver, you would only have to tell them where to get EDID structure from. Also, if you have systems with different panel interfaces, they will use the same i2c-edid.c and just instantiate that class multiple times. Yep. Althought the same could be done with a common edid library, without an i2c-edid driver. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. yes, but that can't be done in another way right ? Try something like having a EDID provider and an EDID consumer. The provider will be i2c-edid.c or dvi-edid.c and the consumer will a generic layer which tfp410 would use to request certain attributes from the EDID structure. TFP410 doesn't need the EDID for anything, it just provides it as raw data. Parsing the EDID is done in other layers. But as you said, instead of tfp410 fetching the EDID and providing it, tfp410 could get the EDID from the i2c-edid driver and pass it forward. I think that would look a lot nicer as the underlying implementation for requesting EDID would be completely encapsulated from its users. If with users you mean, for example, tfp410, then true. But tfp410 doesn't use EDID for anything, it just provides it. For the actual users of the EDID data reading the EDID is encapsulated already. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. it's not very well designed, then, if tfp410 still needs to fetch the i2c adapter. It still has to know about the underlying bus for reading EDID. Well, yes. TFP410 is a RGB to DVI chip. It knows that the underlying bus is DVI, and that there are i2c lines to read the EDID. There are no other option what the busses could be. So I don't see any problem with knowing the underlying bus. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read EDID via DSI. TFP410 is a parallel RGB to DVI chip. It's not related to DSI. The DSI case would be with some other chip. it doesn't change what I said, however. Another chip will need to be passed in a DVI handle. I'm sorry, but I don't understand what you're saying above... If we have a DSI-2-DVI chip, then reading the EDID would be done by sending a DSI command to the chip, which would return the EDID data. Which would be passed forward when someone requests it. There would not be anything in common with tfp410 and i2c implementation. We could have a library with the code that does the one or two i2c reads. And while I think it'd be good, we're talking about one or two i2c reads. It wouldn't be a huge improvement. fair enough... it looks like this is going nowhere, so best we come back to this later. No reason to block your patch. Well, the patch is a fix for stable
Re: [PATCH] omap2/ompafb/omapfb-main.c: Delete if evaluating constant.
On 2012-11-16 19:51, Matthias Brugger wrote:
Variable r is never set to any value different to zero.
Delete the if statement as it will never executed.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/video/omap2/omapfb/omapfb-main.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 16db158..85f9de0 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2411,7 +2411,6 @@ static int __init omapfb_probe(struct platform_device
*pdev)
fbdev-dev = pdev-dev;
platform_set_drvdata(pdev, fbdev);
- r = 0;
fbdev-num_displays = 0;
dssdev = NULL;
for_each_dss_dev(dssdev) {
@@ -2434,9 +2433,6 @@ static int __init omapfb_probe(struct platform_device
*pdev)
d-update_mode = OMAPFB_AUTO_UPDATE;
}
- if (r)
- goto cleanup;
-
if (fbdev-num_displays == 0) {
dev_err(pdev-dev, no displays\n);
r = -EINVAL;
Thanks, I'll apply to omapdss tree.
Tomi
signature.asc
Description: OpenPGP digital signature
RE: [PATCH v2 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
On Mon, Nov 19, 2012 at 16:20:27, Peter Korsgaard wrote: AnilKumar == AnilKumar Ch anilku...@ti.com writes: s/shutdowm/shutdown/ in the subject. I will change AnilKumar From: Colin Foe-Parker colin.foepar...@logicpd.com AnilKumar Set tps65217 PMIC status to OFF if power enable toggle is AnilKumar supported. Also adds platform data flag, which should be AnilKumar passed from board init data. You're adding dt binding, not platform data. I will change AnilKumar Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com AnilKumar [anilku...@ti.com: move the additions to tps65217 MFD driver] AnilKumar Signed-off-by: AnilKumar Ch anilku...@ti.com AnilKumar --- AnilKumar .../devicetree/bindings/regulator/tps65217.txt |4 AnilKumar drivers/mfd/tps65217.c | 12 AnilKumar 2 files changed, 16 insertions(+) AnilKumar diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt AnilKumar index d316fb8..4f05d20 100644 AnilKumar --- a/Documentation/devicetree/bindings/regulator/tps65217.txt AnilKumar +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt AnilKumar @@ -11,6 +11,9 @@ Required properties: AnilKumarusing the standard binding for regulators found at AnilKumarDocumentation/devicetree/bindings/regulator/regulator.txt. AnilKumar +Optional properties: AnilKumar +- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle. Ehh, I don't know the tps65217 particular well, but according to the datasheet the REG_STATUS_OFF bit enables/disables the PB_IN pin, not PWR_EN. It's also not only about powering down but also powering up again. I don't feel this property name is very clear. Perhaps something about power button or push button monitor as it is called in the datasheet? Here I am writing TPS65217_STATUS_OFF to status register, BIT(7). Description of this bit field: OFF bit. Set this bit to 1 to enter OFF state when PWR_EN pin is pulled low. Bit is automatically reset to 0. PWR_EN pin pull-down is doing by RTC module. Regards AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP2+: enable TPS65217 support in omap2plus_defconfig
TPS65217 is described in arch/arm/boot/dts/am335x-bone.dts but doesn't enabled in arch/arm/configs/omap2plus_defconfig. Enable TPS65217 support in omap2plus_defconfig. Signed-off-by: Igor Mazanov i.maza...@gmail.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..00f2ce3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -240,3 +240,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_MFD_CORE=y +CONFIG_MFD_TPS65217=y +CONFIG_REGULATOR_TPS65217=y -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omapdss fixes for 3.7-rc
Hi Florian, I have an additional crash bug fix for omapdss. I don't think you've pulled the original request below yet, so here's an updated one: Tomi The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7-rc7 for you to fetch changes up to c415187b689842e8bb85135c070c822c2505f805: OMAPFB: Fix possible null pointer dereferencing (2012-11-19 10:41:50 +0200) omapdss fixes for 3.7-rc7 omapdss fixes for three crash bugs and one missing mutex unlock. Laurent Pinchart (1): omapdss: dss: Fix clocks on OMAP363x Tomi Valkeinen (1): OMAPDSS: DSI: fix dsi_get_dsidev_from_id() Tushar Behera (1): OMAPFB: Fix possible null pointer dereferencing Wei Yongjun (1): OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs() drivers/video/omap2/dss/dsi.c | 13 +++-- drivers/video/omap2/dss/dss.c |4 ++-- drivers/video/omap2/dss/hdmi.c|4 +++- drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +- 4 files changed, 17 insertions(+), 6 deletions(-) On 2012-11-05 11:52, Tomi Valkeinen wrote: Hi Florian, Here are a few omapdss fixes, two fixing crasher bugs and the third fixes a missing unlock. These are based on 3.7-rc1. I can rebase on top of something else if you prefer that. Tomi The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7-rc5 for you to fetch changes up to dffc70ade1d13edd186f542718c4d78a31d92fb8: OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs() (2012-10-26 08:45:43 +0300) omapdss fixes for 3.7-rc5 omapdss fixes for two crashes bugs and one missing mutex unlock. Laurent Pinchart (1): omapdss: dss: Fix clocks on OMAP363x Tomi Valkeinen (1): OMAPDSS: DSI: fix dsi_get_dsidev_from_id() Wei Yongjun (1): OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs() drivers/video/omap2/dss/dsi.c | 13 +++-- drivers/video/omap2/dss/dss.c |4 ++-- drivers/video/omap2/dss/hdmi.c |4 +++- 3 files changed, 16 insertions(+), 5 deletions(-) signature.asc Description: OpenPGP digital signature
Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
On Mon, Nov 19, 2012 at 11:00:15AM +0100, Peter Ujfalusi wrote: When we have prefetch enabled we tend to resume after pause from a slightly off place than when the prefetch is disabled. That is exactly what I was expecting would happen having read how the DMA works. With memory-device transfers, if you stop them (there is no pause), the DMA hardware discards its buffers. So if you allow it to prefetch data, you're going to throw more data away when you stop it. For device-memory transfers, at least it will write the contents back to memory before stopping. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
A == AnilKumar, Chimata anilku...@ti.com writes: Hi, I don't feel this property name is very clear. Perhaps something about power button or push button monitor as it is called in the datasheet? A Here I am writing TPS65217_STATUS_OFF to status register, BIT(7). A Description of this bit field: OFF bit. Set this bit to 1 to enter A OFF state when PWR_EN pin is pulled low. Bit is automatically reset A to 0. A PWR_EN pin pull-down is doing by RTC module. Ahh yes, sorry -ENOCOFFEE. I somehow misread the datasheet and looked at bit 0 instead. -- Bye, Peter Korsgaard -- 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] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
Hi Linus, On 11/19/2012 11:40 AM, Linus Walleij wrote: On Mon, Nov 19, 2012 at 9:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote: I was actually tempted to remove the whole LED (PWM) thing from the gpio-twl4030 driver. It was a big surprise to me to see something like this in there. It looks wrong. In theory I think this should be ripped out and moved to drivers/leds/leds-twl4030.c. But that would only be in case it was *always* exclusively used for a LED and as you say: It turns out that on BeagleBoard the USB host enable signal is connected to LEDA (PWMA) of twl4030... It is an enable signal. Seriously. So what we do here is either configure the PWMs as full on, or turn it off. Sounds like some hardware engineer has been having fun or was just out of GPIOs to use... So this LED PWM is also used as a GPIO. My guess it was out of fun. On BealgeBoard GPIO13 from twl4030 is free (LEDSYNC/GPIO.13) so it could have been used for this, or GPIO16/17 as well. I think this part of the driver should be moved to drivers/pwm/pwm-twl4030.c and modeled as a PWM. If some platform need to use the PWM as if it was a GPIO then that's just a special usecase. (Setting duty cycles to something like INT_MAX and just switching polarity to toggle it...) If it needs to be used by a LED there needs to be some generic LED type just using a standard pwm_request() to get some specific PWM, such as leds/leds-pwm.c or so. This way the PWM can be used for LEDs if need be or other things... I have already sent a series to support the PWMs in twl4030/6030: https://lkml.org/lkml/2012/11/8/219 It adds support for both type of PWMs (the one named as PWM and the ones named as LED since they are just PWMs). We already have leds/leds-pwm driver in upstream so we are going to use that if there is a led connected to one of them: https://lkml.org/lkml/2012/11/12/222 We can use the backlight-pwm if the LCD backlight has been hooked to one of the PWM (as it is done on SDP4430). This is why I was thinking of adding gpio/gpio-pwm driver. With that we can use the PWM as GPO line. Sounds correct, Sascha? Either way this is wrong IMHO to handle the LEDA/B via the gpio-twl4030 driver. It's confusing indeed. So what we're dealing with is: a LED-specific PWM, being used as a PWM with eternal dutycycle and then being used as GPIO. Well, we get to deal with it ... :-/ gpio/gpio-pwm driver? -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tfp410 and i2c_bus_num
Hi, On Mon, Nov 19, 2012 at 01:09:42PM +0200, Tomi Valkeinen wrote: On 2012-11-19 11:27, Felipe Balbi wrote: If we had a separate, independent i2c-edid driver, we'd have to somehow link the i2c-edid driver and tfp410 (or whatever driver would handle the video link in that particular case) so that the i2c-edid driver would know about hotplug events. We would also need to link the drivers so that the edid can be associated with the video pipeline the tfp410 chip is part of, and to the particular slot in the pipeline where the tfp410 is. that should all be doable, just look at how v4l2 handles pipelining the video data (all in userland though) and you'll see it's definitely possible. Afaik, v4l2 handles only the pipeline for video. This i2c-edid would not be part of the video pipeline, so I don't see a connection to v4l2. hehe, I was using an example of building a pipeline and adding whatever devices you wanted to the pipeline ;-) And I'm not saying it's not possible, or that the current way is good or correct. I'm saying it's not easy, and definitely more complex than the current tfp410 implementation. The amount of code related to this feature would multiply. If we had 10 different tfp410 like drivers, then obviously there'd be more pressing reason to clean this up. But currently we have only one place where this code is used. fair enough, but I'd say there are two places: DSS and DRM. I haven't tried writing such a driver, but it sounds much more complex to me than doing one or two i2c reads in the tfp410 driver. until you have e.g. tfp999, tfp534, tfp678 (hypothetical device numbers, they probably don't exist) which are all SW incompatible and you have to duplicate i2c reads in all of them. Whereas if you had a dedicated i2c-edid.c driver, you would only have to tell them where to get EDID structure from. Also, if you have systems with different panel interfaces, they will use the same i2c-edid.c and just instantiate that class multiple times. Yep. Althought the same could be done with a common edid library, without an i2c-edid driver. correct. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. But the I2C bus isn't part of the video path anyway. It's a completely separate path which is dedicated to reading EDID. If you need a generic While reading EDID is totally separate from the video data itself, it is not separate from the hotplug status of the cable. And the EDID needs to be associated with the video path in question, of course. yes, but that can't be done in another way right ? Try something like having a EDID provider and an EDID consumer. The provider will be i2c-edid.c or dvi-edid.c and the consumer will a generic layer which tfp410 would use to request certain attributes from the EDID structure. TFP410 doesn't need the EDID for anything, it just provides it as raw data. Parsing the EDID is done in other layers. But as you said, instead of tfp410 fetching the EDID and providing it, tfp410 could get the EDID from the i2c-edid driver and pass it forward. Or whatever layer needs EDID would fetch it directly instead of going through tfp410. I think that would look a lot nicer as the underlying implementation for requesting EDID would be completely encapsulated from its users. If with users you mean, for example, tfp410, then true. But tfp410 doesn't use EDID for anything, it just provides it. For the actual users of the EDID data reading the EDID is encapsulated already. fair enough. No, reading edid is done via generic read_edid call. TFP410 uses i2c to read edid, but it could do it in any way it wants. it's not very well designed, then, if tfp410 still needs to fetch the i2c adapter. It still has to know about the underlying bus for reading EDID. Well, yes. TFP410 is a RGB to DVI chip. It knows that the underlying bus is DVI, and that there are i2c lines to read the EDID. There are no other option what the busses could be. So I don't see any problem with knowing the underlying bus. passing i2c_bus_num should be an indicator that something is wrong with your design. Note that not only TFP410 knows that it has an underlying i2c bus, it needs to know exactly which bus it needs to use. Also keep in mind that i2c bus numbers are assigned by the kernel and could be anything. Any changes to the order of adding i2c buses, might break your i2c_bus_num parameter. Of course this is all hypothetical, but it shows that current design is fragile, IMHO. In fact current implementation is far worse than having an extra i2c-edid.c driver because it doesn't encapsulate EDID implementation from tfp410. Then moment you need to read EDID via DSI, you will likely have to pass a DSI handle to e.g. TFP410 so it can read
Re: [PATCH] gpio: twl4030: Use only TWL4030_MODULE_LED for LED configuration
Hi Sascha, On 11/19/2012 11:57 AM, Sascha Hauer wrote: Either I'm misinterpreting you or you didn't have a look in the tree. Actually drivers/leds/leds-pwm.c already exists. Sounds correct, Sascha? Yes, the twl4030 pwm should go to drivers/pwm/pwm-twl4030.c. I have already done the generic PWM drivers for the two type of PWMs (named PWM, and the LED PWMs): https://lkml.org/lkml/2012/11/8/219 They are happily using leds-pwm and backlight-pwm on my working tree. I also sent cleanup and DT support for leds-pwm: https://lkml.org/lkml/2012/11/12/222 -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On 2012-11-16 20:05, Ricardo Neri wrote: I hope the explanation above provides more clarity to you. I think HDMI does not fit seamlessly into the ASoC driver model, as we don't have a real codec and no machine driver seems to be needed. This is the best I could get. :/ :) Ok. I can't say I fully grasp everything about the audio architecture, but this clarified it anyway. So I'm fine with the three audio related devices. But I still have the following points: The name of the codec platform_device is hdmi-audio-codec. Isn't that too generic name? Shouldn't it be omap-hdmi-audio-codec? Then again, you said in this case it represents the tv-set. If so, should it be a generic codec driver, without any reference to omap? I still don't understand why the codec and machine drivers need to be created in the board file. That just forces us to replicate the same code for all OMAP boards that have OMAP HDMI output. Why not create the devices in some common code, for example arch/arm/mach-omap2/display.c? With DT this should be similar: OMAP's hdmi devices should be presented in the omap4.dtsi file, not in each individual board dts. Although the DT data should represent the hardware, and if the code and machine devices are not really there in the HW, then... I don't know =). And something that confuses me: sound/soc/codecs/omap-hdmi.c contains a codec and dai drivers, but sound/soc/omap/omap-hdmi.c also contains a dai driver. The latter actually contains two dai drivers, the other a platform driver and the other a snd_soc_dai_driver. But I guess this is asoc details, and not relevant to this disuccsion =). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote: On Thursday 15 November 2012, Rob Clark wrote: I still haven't heard a conclusive argument why we need to use get_user() rather than copy_from_user() in the DRM code. Is this about a fast path where you want to shave off a few cycles for each call, or does this simplify the code structure, or something else? well, it is mostly because it seemed like a good idea to first try to solve the root issue, rather than having to fix things up in each driver when someone from x86-world introduces a 64b get_user().. As pointed out by hpa earlier, x86-32 doesn't have a 64b get_user either. I don't think we have a lot of drivers that are used only on 64-bit x86 and on 32-bit ARM but not on 32-bit x86. Ouch. I didn't realize that x86-32 doesn't have it. All the systems where I've run the new code are 64bit so I never noticed the problem. I see there was a patch [1] posted a long time ago to implement 64bit get_user() on x86-32. I wonder what happened to it? [1] https://lkml.org/lkml/2004/4/20/96 -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Mon, Nov 19, 2012 at 04:32:36PM +0200, Ville Syrjälä wrote: On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote: On Thursday 15 November 2012, Rob Clark wrote: I still haven't heard a conclusive argument why we need to use get_user() rather than copy_from_user() in the DRM code. Is this about a fast path where you want to shave off a few cycles for each call, or does this simplify the code structure, or something else? well, it is mostly because it seemed like a good idea to first try to solve the root issue, rather than having to fix things up in each driver when someone from x86-world introduces a 64b get_user().. As pointed out by hpa earlier, x86-32 doesn't have a 64b get_user either. I don't think we have a lot of drivers that are used only on 64-bit x86 and on 32-bit ARM but not on 32-bit x86. Ouch. I didn't realize that x86-32 doesn't have it. All the systems where I've run the new code are 64bit so I never noticed the problem. I see there was a patch [1] posted a long time ago to implement 64bit get_user() on x86-32. I wonder what happened to it? [1] https://lkml.org/lkml/2004/4/20/96 Wonderful lkml.org after four Negotiating SSL connection... messages gives me under elinks... Unable to retrieve https://lkml.org/lkml/2004/4/20/96: Error reading from socket and with wget: $ wget https://lkml.org/lkml/2004/4/20/96 --2012-11-19 14:47:16-- https://lkml.org/lkml/2004/4/20/96 Resolving lkml.org... 87.253.128.182 Connecting to lkml.org|87.253.128.182|:443... connected. HTTP request sent, awaiting response... No data received. Retrying. --2012-11-19 14:47:19-- (try: 2) https://lkml.org/lkml/2004/4/20/96 Connecting to lkml.org|87.253.128.182|:443... connected. HTTP request sent, awaiting response... No data received. Retrying. --2012-11-19 14:47:22-- (try: 3) https://lkml.org/lkml/2004/4/20/96 Connecting to lkml.org|87.253.128.182|:443... connected. HTTP request sent, awaiting response... No data received. Retrying. --2012-11-19 14:47:26-- (try: 4) https://lkml.org/lkml/2004/4/20/96 Connecting to lkml.org|87.253.128.182|:443... connected. HTTP request sent, awaiting response... No data received. Retrying. ... what a wonderful site... please choose another LKML archive, preferably one which works. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Mon, Nov 19, 2012 at 02:48:06PM +, Russell King - ARM Linux wrote: On Mon, Nov 19, 2012 at 04:32:36PM +0200, Ville Syrjälä wrote: On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote: On Thursday 15 November 2012, Rob Clark wrote: I still haven't heard a conclusive argument why we need to use get_user() rather than copy_from_user() in the DRM code. Is this about a fast path where you want to shave off a few cycles for each call, or does this simplify the code structure, or something else? well, it is mostly because it seemed like a good idea to first try to solve the root issue, rather than having to fix things up in each driver when someone from x86-world introduces a 64b get_user().. As pointed out by hpa earlier, x86-32 doesn't have a 64b get_user either. I don't think we have a lot of drivers that are used only on 64-bit x86 and on 32-bit ARM but not on 32-bit x86. Ouch. I didn't realize that x86-32 doesn't have it. All the systems where I've run the new code are 64bit so I never noticed the problem. I see there was a patch [1] posted a long time ago to implement 64bit get_user() on x86-32. I wonder what happened to it? [1] https://lkml.org/lkml/2004/4/20/96 Wonderful lkml.org after four Negotiating SSL connection... messages gives me under elinks... snip what a wonderful site... please choose another LKML archive, preferably one which works. Thanks. This one look like the same thing: http://article.gmane.org/gmane.linux.kernel/198823 -- Ville Syrjälä Intel OTC -- 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 v4 0/3] OMAP GPMC DT bindings
This is a series of patches to support GPMC peripherals on OMAP boards. Depends on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) The only supported peripheral for now is NAND, but other types would be easy to add. Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed and Rob Herring: - add reg and ti,hwmod properties to Documentation - use generic of_mtd functions and the property names defined by them, namely nand-bus-width and nand-ecc-mode - reduce the default register space size in the Documentation to 8K, as found in the hwmod code - switch to a DT layout based on ranges and address translation. Although this property is not currently looked at as long as the handling code still uses the runtime calculation methods, we now have these values in the bindings, eventually allowing us to switch the implementation with less pain. Version 3 includes fixes pointed out by Jon Hunter: - better documentation of the 'ranges' property to describe the fact that it's representing the CS lines - GPMC_CS_CONFIGx - GPMC_CONFIGx in comments - drop interrupt-parent from example bindings - add of_node_put() at the end of the child iteration Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more details from Jon Hunter and Avinash, Philip: - Add num-cs and num-waitpins properties, which will eventually be used to get rid of GPMC_CS_NUM - Better description of generic nand DT properties - Dropped patch 3/4 as an equivalent fix was already merged - Added ti,nand-ecc-use-elm property Daniel Mack (3): mtd: omap-nand: pass device_node in platform data ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND .../devicetree/bindings/mtd/gpmc-nand.txt | 84 ++ arch/arm/mach-omap2/gpmc-nand.c| 9 +- arch/arm/mach-omap2/gpmc.c | 170 + drivers/mtd/nand/omap2.c | 4 +- include/linux/platform_data/mtd-nand-omap2.h | 2 + 5 files changed, 264 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt -- 1.7.11.7 -- 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 v4 1/3] mtd: omap-nand: pass device_node in platform data
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/mtd/nand/omap2.c | 4 +++-
include/linux/platform_data/mtd-nand-omap2.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5c8978e..1e1d6ef 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1333,6 +1333,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1558,7 +1559,8 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
goto out_release_mem_region;
}
- mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
+ ppdata.of_node = pdata-of_node;
+ mtd_device_parse_register(info-mtd, NULL, ppdata, pdata-parts,
pdata-nr_parts);
platform_set_drvdata(pdev, info-mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..5217d6e 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.11.7
--
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 v4 2/3] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..e23d561 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,17 +92,18 @@ static int omap2_nand_gpmc_retime(
static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
- if (!cpu_is_omap34xx()) {
+ if (!cpu_is_omap34xx() !soc_is_am33xx()) {
pr_err(BCH ecc is not supported on this CPU\n);
return 0;
}
/*
-* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1.
-* Other chips may be added if confirmed to work.
+* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
+* and AM33xx derivates. Other chips may be added if confirmed to work.
*/
if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW)
- (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
+ (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))
+ (!soc_is_am33xx())) {
pr_err(BCH 4-bit mode is not supported on this CPU\n);
return 0;
}
--
1.7.11.7
--
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 v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 84 ++
arch/arm/mach-omap2/gpmc.c | 170 +
2 files changed, 254 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000..20aa5b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,84 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of nand.
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional properties:
+
+ - nand-bus-width: Set this numeric value to 16 if the hardware
+ is wired that way. If not specified, a bus
+ width of 8 is assumed.
+ - ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
+
+ Layouts for 1-bit ecc: stored at end of spare area:
+
+ software Software method (default)
+ hwHardware method (let gpmc do the error
detection)
+
+ Layouts for 1-bit ecc: stored at beginning of spare area as romcode:
+
+ hw-romcodegpmc method romcode layout
+ bch4 4-bit BCH ecc code
+ bch8 8-bit BCH ecc code
+
+ - ti,nand-ecc-use-elm:Property without value to specify that
the
+ hardware error correction mode should be used.
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ num-cs = 8;
+ num-waitpins = 8;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x1000; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+ ti,nand-ecc-opt = none;
+ ti,nand-ecc-use-elm;
+
+ gpmc,sync-clk = 0;
+ gpmc,cs-on = 0;
+ gpmc,cs-rd-off = 44;
+ gpmc,cs-wr-off = 44;
+ gpmc,adv-on = 6;
+ gpmc,adv-rd-off = 34;
+ gpmc,adv-wr-off = 44;
+ gpmc,we-off = 40;
+ gpmc,oe-off = 54;
+ gpmc,access = 64;
+ gpmc,rd-cycle = 82;
+ gpmc,wr-cycle = 82;
+ gpmc,wr-access = 40;
+ gpmc,wr-data-mux-bus = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ /* partitions go here */
+ };
+ };
+
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 7660a56..971a2bf 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -25,6 +25,10 @@
#include linux/module.h
#include linux/interrupt.h
#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_mtd.h
+#include linux/of_device.h
+#include linux/mtd/nand.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -34,6 +38,7 @@
#include common.h
#include omap_device.h
#include gpmc.h
+#include gpmc-nand.h
#defineDEVICE_NAME omap-gpmc
@@ -748,6 +753,162 @@ static int __devinit gpmc_mem_init(void)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id gpmc_dt_ids[] = {
+ { .compatible = ti,gpmc },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+
+static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
+ struct gpmc_timings *gpmc_t)
+{
+ u32 val;
+
+ memset(gpmc_t, 0, sizeof(*gpmc_t));
+
+
[PATCH 0/2] ARM: OMAP: ads7846: fix pendown debounce setting
Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the pendown GPIO debounce time setting by the below sequence: gpio_request_one() gpio_set_debounce() gpio_free() It also revealed a bug in the OMAP GPIO handling code which prevented the GPIO debounce clock to be disabled and CORE transition to low power states. Commit c9c55d9 (gpio/omap: fix off-mode bug: clear debounce settings on free/reset) fixes the OMAP GPIO handling code by making sure that the GPIO debounce clock gets disabled if no GPIO is requested from current bank. While fixing the OMAP GPIO handling code (in the right way), the above commit makes the gpio_request-set_debounce-free sequence invalid as after freeing the GPIO, the debounce settings are lost. This patch set: 1) Adds the pendown GPIO debounce time setting to the platform data structure of the ads7846 driver. 2) Fixes the OMAP platform code to pass the debounce time value to the driver instead of handling it by itself. Igor Grinberg (2): ads7846: enable pendown GPIO debounce time setting ARM: OMAP: ads7846: fix pendown debounce setting arch/arm/mach-omap2/common-board-devices.c | 34 --- drivers/input/touchscreen/ads7846.c|6 - include/linux/spi/ads7846.h|5 ++- 3 files changed, 28 insertions(+), 17 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ads7846: enable pendown GPIO debounce time setting
Some platforms need the pendown GPIO debounce time setting programmed.
Since the pendown GPIO is handled by the driver, the debounce time
should also be handled along with the pendown GPIO request.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
drivers/input/touchscreen/ads7846.c |6 +-
include/linux/spi/ads7846.h |5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..78e5d9a 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -955,7 +955,8 @@ static int ads7846_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ads7846_pm, ads7846_suspend, ads7846_resume);
-static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct
ads7846 *ts)
+static int __devinit ads7846_setup_pendown(struct spi_device *spi,
+ struct ads7846 *ts)
{
struct ads7846_platform_data *pdata = spi-dev.platform_data;
int err;
@@ -981,6 +982,9 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
ts-gpio_pendown = pdata-gpio_pendown;
+ if (pdata-gpio_pendown_debounce)
+ gpio_set_debounce(pdata-gpio_pendown,
+ pdata-gpio_pendown_debounce);
} else {
dev_err(spi-dev, no get_pendown_state nor gpio_pendown?\n);
return -EINVAL;
diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h
index c64de9d..2e94187 100644
--- a/include/linux/spi/ads7846.h
+++ b/include/linux/spi/ads7846.h
@@ -46,8 +46,9 @@ struct ads7846_platform_data {
u16 debounce_rep; /* additional consecutive good readings
* required after the first two */
int gpio_pendown; /* the GPIO used to decide the pendown
-* state if get_pendown_state == NULL
-*/
+* state if get_pendown_state == NULL */
+ int gpio_pendown_debounce; /* platform specific debounce time for
+ the gpio_pendown */
int (*get_pendown_state)(void);
int (*filter_init) (const struct ads7846_platform_data *pdata,
void **filter_data);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AM33XX: Clock: Fix JTAG disconnect during kernel boot
On 11/16/2012 08:44 PM, Joel A Fernandes wrote:
Hi Jon,
On Fri, Nov 16, 2012 at 6:12 PM, Jon Hunter jon-hun...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Does this mean this clock will always be enabled, even when not using
JTAG? If so, is that what you want?
Yes, the clock will always be on, because some times we connect JTAG
on a running Linux system without powering it down. I can't comment
without doing measurements if keeping the clock on has significant
impact on power, but I see what you mean. Definitely low power is a
parameter and folks who want lowest possible power might need to turn
off the clock and not have JTAG in production, but that depends on the
user's requirement. I personally don't care about power as much as I
care about not being able to JTAG, and I think there are other folks
who suffer from the same JTAG problem who wouldn't necessarily want
lowest power.
I can't say I am that familiar with the AM33xx architecture, but I know
that on OMAP this would keep on the debugss clock and power domain.
Do you need this change to connect JTAG after the kernel has booted or
just to maintain JTAG during kernel boot?
I am wondering if you should implement a new flag such as
DONT_DISABLE_ON_INIT so if the clock is on it is not disabled, but if
it is not enabled, you don't enabled it. Then that would be the best of
both worlds.
I was not sure if you are concerned about power at all. Or if having
that always enabled can inhibit low power states for suspend/idle etc.
Maybe, suspend/resume code can turn off clock on suspend and enable it
on resume.
Yes, but not ideal for a product assuming they are power sensitive.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
On Mon, Nov 19, 2012 at 11:01:44AM +0100, Peter Ujfalusi wrote:
Hi,
On 10/19/2012 12:20 AM, Mark A. Greer wrote:
Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
flag whenever there is a destination synchronized DMA transfer.
Prefetching is not allowed on source synchronized DMA transfers.
Enabling prefetch significantly improves DMA performance.
For example, running 'modprobe tcrypt sec=2 mode=403' which
exercises the omap-sham driver on an am37x EVM yeilds the
following results:
drivers/dma/omap-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..aadddb2 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_slave_sg(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
This should be:
-sync_type = OMAP_DMA_DST_SYNC;
+sync_type = OMAP_DMA_DST_SYNC_PREFETCH;
Ah, right. I will fix.
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
@@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
We should not enable the prefetch for cyclic right now. We will investigate it
more.
OK. I'll send a patch in a few minutes.
Mark
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/18/2012 09:06 AM, Igor Grinberg wrote: CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER setting. To remove the dependancy, several conversions/additions had to be done: 1) Timer initialization functions are named by the platform name and the clock source in use. This also makes it possible to define and use the GPTIMER as the clock source instead of the 32K timer on platforms that do not have the 32K timer ip block or the 32K timer is not wired on the board. Cirrently, the the timer is chosen in the machine_desc structure on Nit ... s/Cirrently/Currently Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Thanks for updating this! Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] mmc: omap_hsmmc: Few patches for omap_hsmmc
On Sun, Nov 18, 2012 at 6:39 AM, Chris Ball c...@laptop.org wrote: Hi Venkat, On Tue, Nov 06 2012, Venkatraman S wrote: Hi Chris, Please review and merge the below patches. The first one is a bug fix that would be required to be sent for 3.7-rcX, others are intended for 3.8. There have been some changes requested to these -- could you resend your 3.8 queue to me, please? Yes - I am sending you now a series of 7 patches that has updated / cleaned up revisions of the previous patches. Also, it includes Balaji's mini bug fix series, which is a better version of my own fix. Thanks, Venkat. -- 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/7] mmc: omap_hsmmc: Fix Oops in case of data errors
From: Balaji T K balaj...@ti.com
commit ae4bf788ee9bf7c2d51b0309117d1fcccbdd50a2
mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ
sets both end_cmd and end_trans to 1.
Setting end_cmd to 1 for Data Timeout/CRC leads to NULL pointer dereference of
host-cmd as the command complete has previously been handled.
Set end_cmd only in case of command Timeout/CRC.
Moreover host-cmd-error should not be updated on data error case, only
host-data-error needs to be updated.
Signed-off-by: Balaji T K balaj...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5434fd8..0fcf792 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -969,10 +969,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
__func__);
}
-static void hsmmc_command_incomplete(struct omap_hsmmc_host *host, int err)
+static void hsmmc_command_incomplete(struct omap_hsmmc_host *host,
+ int err, int end_cmd)
{
omap_hsmmc_reset_controller_fsm(host, SRC);
- host-cmd-error = err;
+ if (end_cmd) {
+ if (host-cmd)
+ host-cmd-error = err;
+ }
if (host-data) {
omap_hsmmc_reset_controller_fsm(host, SRD);
@@ -991,14 +995,16 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
if (status ERR) {
omap_hsmmc_dbg_report_irq(host, status);
+
+ if (status (CMD_TIMEOUT | CMD_CRC))
+ end_cmd = 1;
if (status (CMD_TIMEOUT | DATA_TIMEOUT))
- hsmmc_command_incomplete(host, -ETIMEDOUT);
+ hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
else if (status (CMD_CRC | DATA_CRC))
- hsmmc_command_incomplete(host, -EILSEQ);
+ hsmmc_command_incomplete(host, -EILSEQ, end_cmd);
- end_cmd = 1;
if (host-data || host-response_busy) {
- end_trans = 1;
+ end_trans = !end_cmd;
host-response_busy = 0;
}
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] mmc: omap_hsmmc: no reset of cmd state machine for DCRC
From: Balaji T K balaj...@ti.com
Avoid soft reset of command internal state machine on data errors.
Signed-off-by: Balaji T K balaj...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0fcf792..2d90da8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -972,8 +972,8 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
static void hsmmc_command_incomplete(struct omap_hsmmc_host *host,
int err, int end_cmd)
{
- omap_hsmmc_reset_controller_fsm(host, SRC);
if (end_cmd) {
+ omap_hsmmc_reset_controller_fsm(host, SRC);
if (host-cmd)
host-cmd-error = err;
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] mmc: omap_hsmmc: update error code for response_busy cmd
From: Balaji T K balaj...@ti.com
update error code to cmd-error for commands with response_busy and no data
Signed-off-by: Balaji T K balaj...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2d90da8..571cd80 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -981,8 +981,8 @@ static void hsmmc_command_incomplete(struct omap_hsmmc_host
*host,
if (host-data) {
omap_hsmmc_reset_controller_fsm(host, SRD);
omap_hsmmc_dma_cleanup(host, err);
- }
-
+ } else if (host-mrq host-mrq-cmd)
+ host-mrq-cmd-error = err;
}
static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host, int status)
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
From: Hebbar, Gururaja gururaja.heb...@ti.com
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 1 +
arch/arm/plat-omap/include/plat/mmc.h | 1 +
drivers/mmc/host/omap_hsmmc.c | 30 +-
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 571cd80..18d3f19 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -90,6 +91,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -495,6 +497,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -502,7 +505,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -513,6 +517,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ(host-base, CAPA) HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host-base, HCTL);
+ if (clkdiv (clk_get_rate(host-fclk)/clkdiv) 2500)
+ regval |= HSPE;
+ else
+ regval = ~HSPE;
+
+ OMAP_HSMMC_WRITE(host-base, HCTL, regval);
+ }
+
[PATCH 6/7] mmc: omap_hsmmc: convert critical failure reports to dev_err
Fatal errors for the driver are not reported when just error
debug is enabled. Convert selected dev_dbg to dev_err for
accurate error reporting.
Reported-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fad9250..9de0b9e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -305,7 +305,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
- dev_dbg(host-dev, vmmc regulator missing\n);
+ dev_err(host-dev, vmmc regulator missing\n);
return PTR_ERR(reg);
} else {
mmc_slot(host).set_power = omap_hsmmc_set_power;
@@ -1133,7 +1133,7 @@ static int omap_hsmmc_switch_opcond(struct
omap_hsmmc_host *host, int vdd)
return 0;
err:
- dev_dbg(mmc_dev(host-mmc), Unable to switch operating voltage\n);
+ dev_err(mmc_dev(host-mmc), Unable to switch operating voltage\n);
return ret;
}
@@ -1392,7 +1392,7 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host,
struct mmc_request *req)
if (host-use_dma) {
ret = omap_hsmmc_start_dma_transfer(host, req);
if (ret != 0) {
- dev_dbg(mmc_dev(host-mmc), MMC start dma failure\n);
+ dev_err(mmc_dev(host-mmc), MMC start dma failure\n);
return ret;
}
}
@@ -1927,13 +1927,13 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
ret = request_irq(host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
- dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
+ dev_err(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
goto err_irq;
}
if (pdata-init != NULL) {
if (pdata-init(pdev-dev) != 0) {
- dev_dbg(mmc_dev(host-mmc),
+ dev_err(mmc_dev(host-mmc),
Unable to configure MMC IRQs\n);
goto err_irq_cd_init;
}
@@ -1956,7 +1956,7 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
mmc_hostname(mmc), host);
if (ret) {
- dev_dbg(mmc_dev(host-mmc),
+ dev_err(mmc_dev(host-mmc),
Unable to grab MMC CD IRQ\n);
goto err_irq_cd;
}
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] mmc: omap_hsmmc: Cleanup up bitmap definitions of Interrupt Register
Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).
Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled by default.
No functional changes.
Signed-off-by: Venkatraman S svenk...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
v1-v2:
Balaji's comments to not set ERR_EN for INT_EN_MASK is now
handled.
drivers/mmc/host/omap_hsmmc.c | 56 ---
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9de0b9e..d0a912f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -80,29 +80,17 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
-#define INT_EN_MASK0x307F0033
-#define BWR_ENABLE (1 4)
-#define BRR_ENABLE (1 5)
-#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
-#define DMA_EN 0x1
+#define DMAE 0x1
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
-#define CC 0x1
-#define TC 0x02
#define OD 0x1
-#define ERR(1 15)
-#define CMD_TIMEOUT(1 16)
-#define DATA_TIMEOUT (1 20)
-#define CMD_CRC(1 17)
-#define DATA_CRC (1 21)
-#define CARD_ERR (1 28)
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD0x
#define DUAL_VOLT_OCR_BIT 7
@@ -111,6 +99,26 @@
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+/* Interrupt masks for IE and ISE register */
+#define CC_EN (1 0)
+#define TC_EN (1 1)
+#define BWR_EN (1 4)
+#define BRR_EN (1 5)
+#define ERR_EN (1 15)
+#define CTO_EN (1 16)
+#define CCRC_EN(1 17)
+#define CEB_EN (1 18)
+#define CIE_EN (1 19)
+#define DTO_EN (1 20)
+#define DCRC_EN(1 21)
+#define DEB_EN (1 22)
+#define CERR_EN(1 28)
+#define BADA_EN(1 29)
+
+#define INT_EN_MASK(BADA_EN | CERR_EN | DEB_EN | DCRC_EN |\
+ DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | \
+ BRR_EN | BWR_EN | TC_EN | CC_EN)
+
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 40
@@ -458,13 +466,13 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
unsigned int irq_mask;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE);
+ irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
else
irq_mask = INT_EN_MASK;
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
- irq_mask = ~DTO_ENABLE;
+ irq_mask = ~DTO_EN;
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
@@ -702,8 +710,8 @@ static void send_init_stream(struct omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host-base, CMD, INIT_STREAM_CMD);
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((reg != CC) time_before(jiffies, timeout))
- reg = OMAP_HSMMC_READ(host-base, STAT) CC;
+ while ((reg != CC_EN) time_before(jiffies, timeout))
+ reg = OMAP_HSMMC_READ(host-base, STAT) CC_EN;
OMAP_HSMMC_WRITE(host-base, CON,
OMAP_HSMMC_READ(host-base, CON) ~INIT_STREAM);
@@ -794,7 +802,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
}
if (host-use_dma)
- cmdreg |= DMA_EN;
+ cmdreg |= DMAE;
host-req_in_progress = 1;
@@ -1018,14 +1026,14 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
data = host-data;
dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
- if (status ERR) {
+ if (status ERR_EN) {
omap_hsmmc_dbg_report_irq(host, status);
- if (status (CMD_TIMEOUT | CMD_CRC))
+ if (status (CTO_EN | CCRC_EN))
end_cmd = 1;
- if (status (CMD_TIMEOUT | DATA_TIMEOUT))
+ if (status (CTO_EN | DTO_EN))
hsmmc_command_incomplete(host, -ETIMEDOUT, end_cmd);
-
[PATCH] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Mark A. Greer mgr...@animalcreek.com
Enable DMA prefetching for non-cyclic DMAs by setting the
'OMAP_DMA_DST_SYNC_PREFETCH' flag when there is a destination
synchronized DMA transfer. Prefetching is not allowed on
source synchronized DMA transfers. It is not allowed on
cyclic DMAs either since that can cause issues with some
users (e.g., suspending/resuming audio).
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Péter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/dma/omap-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..3932eab 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_slave_sg(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC_PREFETCH;
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] OMAP GPMC DT bindings
On 11/19/2012 09:29 AM, Daniel Mack wrote: This is a series of patches to support GPMC peripherals on OMAP boards. Depends on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) The only supported peripheral for now is NAND, but other types would be easy to add. Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed and Rob Herring: - add reg and ti,hwmod properties to Documentation - use generic of_mtd functions and the property names defined by them, namely nand-bus-width and nand-ecc-mode - reduce the default register space size in the Documentation to 8K, as found in the hwmod code - switch to a DT layout based on ranges and address translation. Although this property is not currently looked at as long as the handling code still uses the runtime calculation methods, we now have these values in the bindings, eventually allowing us to switch the implementation with less pain. Version 3 includes fixes pointed out by Jon Hunter: - better documentation of the 'ranges' property to describe the fact that it's representing the CS lines - GPMC_CS_CONFIGx - GPMC_CONFIGx in comments - drop interrupt-parent from example bindings - add of_node_put() at the end of the child iteration Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more details from Jon Hunter and Avinash, Philip: - Add num-cs and num-waitpins properties, which will eventually be used to get rid of GPMC_CS_NUM - Better description of generic nand DT properties - Dropped patch 3/4 as an equivalent fix was already merged - Added ti,nand-ecc-use-elm property Daniel Mack (3): mtd: omap-nand: pass device_node in platform data ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND .../devicetree/bindings/mtd/gpmc-nand.txt | 84 ++ arch/arm/mach-omap2/gpmc-nand.c| 9 +- arch/arm/mach-omap2/gpmc.c | 170 + drivers/mtd/nand/omap2.c | 4 +- include/linux/platform_data/mtd-nand-omap2.h | 2 + 5 files changed, 264 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt Thanks for sending out the update. Am I missing something or did you drop the gpmc.txt binding documentation? Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
On Mon, Nov 19, 2012 at 09:19:15AM -0700, Mark A. Greer wrote:
On Mon, Nov 19, 2012 at 11:01:44AM +0100, Peter Ujfalusi wrote:
Hi,
On 10/19/2012 12:20 AM, Mark A. Greer wrote:
Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
flag whenever there is a destination synchronized DMA transfer.
Prefetching is not allowed on source synchronized DMA transfers.
Enabling prefetch significantly improves DMA performance.
For example, running 'modprobe tcrypt sec=2 mode=403' which
exercises the omap-sham driver on an am37x EVM yeilds the
following results:
drivers/dma/omap-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..aadddb2 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_slave_sg(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
This should be:
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC_PREFETCH;
Ah, right. I will fix.
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
@@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_dma_cyclic(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
We should not enable the prefetch for cyclic right now. We will investigate
it
more.
OK. I'll send a patch in a few minutes.
https://patchwork.kernel.org/patch/1765941/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ads7846: enable pendown GPIO debounce time setting
Some platforms need the pendown GPIO debounce time setting programmed.
Since the pendown GPIO is handled by the driver, the debounce time
should also be handled along with the pendown GPIO request.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
v2: fix the comment style
drivers/input/touchscreen/ads7846.c |6 +-
include/linux/spi/ads7846.h |5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..78e5d9a 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -955,7 +955,8 @@ static int ads7846_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ads7846_pm, ads7846_suspend, ads7846_resume);
-static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct
ads7846 *ts)
+static int __devinit ads7846_setup_pendown(struct spi_device *spi,
+ struct ads7846 *ts)
{
struct ads7846_platform_data *pdata = spi-dev.platform_data;
int err;
@@ -981,6 +982,9 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
ts-gpio_pendown = pdata-gpio_pendown;
+ if (pdata-gpio_pendown_debounce)
+ gpio_set_debounce(pdata-gpio_pendown,
+ pdata-gpio_pendown_debounce);
} else {
dev_err(spi-dev, no get_pendown_state nor gpio_pendown?\n);
return -EINVAL;
diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h
index c64de9d..2f694f3 100644
--- a/include/linux/spi/ads7846.h
+++ b/include/linux/spi/ads7846.h
@@ -46,8 +46,9 @@ struct ads7846_platform_data {
u16 debounce_rep; /* additional consecutive good readings
* required after the first two */
int gpio_pendown; /* the GPIO used to decide the pendown
-* state if get_pendown_state == NULL
-*/
+* state if get_pendown_state == NULL */
+ int gpio_pendown_debounce; /* platform specific debounce time for
+* the gpio_pendown */
int (*get_pendown_state)(void);
int (*filter_init) (const struct ads7846_platform_data *pdata,
void **filter_data);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] New Nokia RX-51 power supply battery driver
On Mon, Nov 19, 2012 at 01:18:29PM +0100, Pali Rohár wrote:
[...]
Ok. Here is missing patch which register this driver in Nokia N900 board
code. Without it driver is not loaded.
Cc'ing OMAP folks.
From 0b60efd06a71668439bcb761c6572dd7df91dc17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pali=20Roh=C3=A1r?= pali.ro...@gmail.com
Date: Mon, 19 Nov 2012 09:05:24 +0100
Subject: [PATCH 1/3] ARM: OMAP: rx51: Register platform device for
rx51_battery driver
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 020e03c..fe1ac7e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -271,11 +271,17 @@ static struct platform_device rx51_charger_device = {
},
};
+static struct platform_device rx51_battery_device = {
+ .name = rx51-battery,
+ .id = -1,
+};
+
static void __init rx51_charger_init(void)
{
WARN_ON(gpio_request_one(RX51_USB_TRANSCEIVER_RST_GPIO,
GPIOF_OUT_INIT_HIGH, isp1704_reset));
+ platform_device_register(rx51_battery_device);
platform_device_register(rx51_charger_device);
}
--
1.7.10.4
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 404/493] i2c: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jean Delvare kh...@linux-fr.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Rudolf Marek r.ma...@assembler.cz
Cc: Jochen Friedrich joc...@scram.de
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Tony Lindgren t...@atomide.com
Cc: Olof Johansson o...@lixom.net
Cc: Vitaly Wool vitalyw...@gmail.com
Cc: Guan Xuetao g...@mprc.pku.edu.cn
Cc: Barry Song baohua.s...@csr.com
Cc: Mark M. Hoffman mhoff...@lightlink.com
Cc: linux-...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/i2c/busses/i2c-ali1535.c| 2 +-
drivers/i2c/busses/i2c-ali1563.c| 2 +-
drivers/i2c/busses/i2c-ali15x3.c| 2 +-
drivers/i2c/busses/i2c-amd756.c | 2 +-
drivers/i2c/busses/i2c-amd8111.c| 2 +-
drivers/i2c/busses/i2c-at91.c | 2 +-
drivers/i2c/busses/i2c-au1550.c | 2 +-
drivers/i2c/busses/i2c-cpm.c| 2 +-
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
drivers/i2c/busses/i2c-eg20t.c | 2 +-
drivers/i2c/busses/i2c-elektor.c| 2 +-
drivers/i2c/busses/i2c-gpio.c | 2 +-
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-hydra.c | 2 +-
drivers/i2c/busses/i2c-i801.c | 4 ++--
drivers/i2c/busses/i2c-ibm_iic.c| 2 +-
drivers/i2c/busses/i2c-intel-mid.c | 2 +-
drivers/i2c/busses/i2c-isch.c | 2 +-
drivers/i2c/busses/i2c-mpc.c| 2 +-
drivers/i2c/busses/i2c-mv64xxx.c| 2 +-
drivers/i2c/busses/i2c-mxs.c| 2 +-
drivers/i2c/busses/i2c-nforce2.c| 2 +-
drivers/i2c/busses/i2c-nuc900.c | 2 +-
drivers/i2c/busses/i2c-ocores.c | 2 +-
drivers/i2c/busses/i2c-octeon.c | 2 +-
drivers/i2c/busses/i2c-omap.c | 2 +-
drivers/i2c/busses/i2c-parport-light.c | 2 +-
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-pca-isa.c| 2 +-
drivers/i2c/busses/i2c-pca-platform.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 4 ++--
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/i2c/busses/i2c-pnx.c| 2 +-
drivers/i2c/busses/i2c-powermac.c | 2 +-
drivers/i2c/busses/i2c-puv3.c | 2 +-
drivers/i2c/busses/i2c-pxa-pci.c| 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-s6000.c | 2 +-
drivers/i2c/busses/i2c-sh7760.c | 2 +-
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-sis630.c | 2 +-
drivers/i2c/busses/i2c-sis96x.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-via.c| 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/busses/i2c-xlr.c| 2 +-
drivers/i2c/busses/scx200_acb.c | 4 ++--
drivers/i2c/muxes/i2c-mux-gpio.c| 2 +-
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
50 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali1535.c b/drivers/i2c/busses/i2c-ali1535.c
index 9ee96f0..3f49181 100644
--- a/drivers/i2c/busses/i2c-ali1535.c
+++ b/drivers/i2c/busses/i2c-ali1535.c
@@ -518,7 +518,7 @@ static int ali1535_probe(struct pci_dev *dev, const struct
pci_device_id *id)
return i2c_add_adapter(ali1535_adapter);
}
-static void __devexit ali1535_remove(struct pci_dev *dev)
+static void ali1535_remove(struct pci_dev *dev)
{
i2c_del_adapter(ali1535_adapter);
release_region(ali1535_smba, ALI1535_SMB_IOSIZE);
diff --git a/drivers/i2c/busses/i2c-ali1563.c b/drivers/i2c/busses/i2c-ali1563.c
index 55c27b9..5b17c9f 100644
--- a/drivers/i2c/busses/i2c-ali1563.c
+++ b/drivers/i2c/busses/i2c-ali1563.c
@@ -411,7 +411,7 @@ exit:
return error;
}
-static void __devexit ali1563_remove(struct pci_dev * dev)
+static void ali1563_remove(struct pci_dev * dev)
{
i2c_del_adapter(ali1563_adapter);
ali1563_shutdown(dev);
diff --git a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
index 2d32690..26bcc61 100644
--- a/drivers/i2c/busses/i2c-ali15x3.c
+++ b/drivers/i2c/busses/i2c-ali15x3.c
@@ -500,7 +500,7 @@ static int ali15x3_probe(struct pci_dev *dev, const struct
pci_device_id *id)
return i2c_add_adapter(ali15x3_adapter);
}
-static void __devexit ali15x3_remove(struct pci_dev *dev)
+static void ali15x3_remove(struct pci_dev *dev)
{
i2c_del_adapter(ali15x3_adapter);
release_region(ali15x3_smba, ALI15X3_SMB_IOSIZE);
diff --git a/drivers/i2c/busses/i2c-amd756.c b/drivers/i2c/busses/i2c-amd756.c
[PATCH 403/493] hwspinlock: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/hwspinlock/omap_hwspinlock.c | 2 +-
drivers/hwspinlock/u8500_hsem.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index f21b2ed..292869c 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -142,7 +142,7 @@ iounmap_base:
return ret;
}
-static int __devexit omap_hwspinlock_remove(struct platform_device *pdev)
+static int omap_hwspinlock_remove(struct platform_device *pdev)
{
struct hwspinlock_device *bank = platform_get_drvdata(pdev);
void __iomem *io_base = bank-lock[0].priv - LOCK_BASE_OFFSET;
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 5a5b3f2..401c33b 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -148,7 +148,7 @@ iounmap_base:
return ret;
}
-static int __devexit u8500_hsem_remove(struct platform_device *pdev)
+static int u8500_hsem_remove(struct platform_device *pdev)
{
struct hwspinlock_device *bank = platform_get_drvdata(pdev);
void __iomem *io_base = bank-lock[0].priv - HSEM_REGISTER_OFFSET;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 431/493] usb: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Alexander Shishkin alexander.shish...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
Cc: Li Yang le...@freescale.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Wan ZongShun mcuos@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
drivers/usb/c67x00/c67x00-drv.c | 2 +-
drivers/usb/chipidea/ci13xxx_imx.c | 2 +-
drivers/usb/chipidea/ci13xxx_msm.c | 2 +-
drivers/usb/chipidea/ci13xxx_pci.c | 2 +-
drivers/usb/chipidea/core.c | 2 +-
drivers/usb/chipidea/usbmisc_imx6q.c | 2 +-
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/dwc3/debugfs.c | 2 +-
drivers/usb/dwc3/dwc3-exynos.c | 2 +-
drivers/usb/dwc3/dwc3-omap.c | 2 +-
drivers/usb/dwc3/dwc3-pci.c | 2 +-
drivers/usb/gadget/bcm63xx_udc.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c | 2 +-
drivers/usb/gadget/hid.c | 2 +-
drivers/usb/gadget/lpc32xx_udc.c | 2 +-
drivers/usb/gadget/mv_u3d_core.c | 2 +-
drivers/usb/gadget/mv_udc_core.c | 2 +-
drivers/usb/gadget/net2272.c | 10 +-
drivers/usb/gadget/omap_udc.c| 2 +-
drivers/usb/gadget/s3c-hsotg.c | 4 ++--
drivers/usb/host/bcma-hcd.c | 2 +-
drivers/usb/host/ehci-atmel.c| 2 +-
drivers/usb/host/ehci-msm.c | 2 +-
drivers/usb/host/ehci-platform.c | 2 +-
drivers/usb/host/ehci-s5p.c | 2 +-
drivers/usb/host/ehci-w90x900.c | 2 +-
drivers/usb/host/fhci-hcd.c | 4 ++--
drivers/usb/host/fsl-mph-dr-of.c | 4 ++--
drivers/usb/host/isp1362-hcd.c | 2 +-
drivers/usb/host/isp1760-if.c| 2 +-
drivers/usb/host/ohci-at91.c | 6 +++---
drivers/usb/host/ohci-exynos.c | 2 +-
drivers/usb/host/ohci-jz4740.c | 2 +-
drivers/usb/host/ohci-omap3.c| 2 +-
drivers/usb/host/ohci-platform.c | 2 +-
drivers/usb/host/ohci-s3c2410.c | 2 +-
drivers/usb/host/ohci-tmio.c | 2 +-
drivers/usb/host/r8a66597-hcd.c | 2 +-
drivers/usb/host/sl811-hcd.c | 2 +-
drivers/usb/host/ssb-hcd.c | 4 ++--
drivers/usb/host/u132-hcd.c | 2 +-
drivers/usb/musb/am35x.c | 2 +-
drivers/usb/musb/blackfin.c | 2 +-
drivers/usb/musb/da8xx.c | 2 +-
drivers/usb/musb/davinci.c | 2 +-
drivers/usb/musb/musb_core.c | 2 +-
drivers/usb/musb/musb_dsps.c | 2 +-
drivers/usb/musb/omap2430.c | 2 +-
drivers/usb/musb/tusb6010.c | 2 +-
drivers/usb/musb/ux500.c | 2 +-
drivers/usb/otg/ab8500-usb.c | 2 +-
drivers/usb/otg/fsl_otg.c| 2 +-
drivers/usb/otg/msm_otg.c| 2 +-
drivers/usb/otg/mxs-phy.c| 2 +-
drivers/usb/otg/nop-usb-xceiv.c | 2 +-
drivers/usb/phy/omap-usb2.c | 2 +-
drivers/usb/phy/rcar-phy.c | 2 +-
drivers/usb/renesas_usbhs/common.c | 2 +-
58 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c
index 21913dfe..fe815ec 100644
--- a/drivers/usb/c67x00/c67x00-drv.c
+++ b/drivers/usb/c67x00/c67x00-drv.c
@@ -191,7 +191,7 @@ static int c67x00_drv_probe(struct platform_device *pdev)
return ret;
}
-static int __devexit c67x00_drv_remove(struct platform_device *pdev)
+static int c67x00_drv_remove(struct platform_device *pdev)
{
struct c67x00_device *c67x00 = platform_get_drvdata(pdev);
struct resource *res;
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 1269780..8c29122 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -220,7 +220,7 @@ put_np:
return ret;
}
-static int __devexit ci13xxx_imx_remove(struct platform_device *pdev)
+static int ci13xxx_imx_remove(struct platform_device *pdev)
{
struct ci13xxx_imx_data *data = platform_get_drvdata(pdev);
diff --git a/drivers/usb/chipidea/ci13xxx_msm.c
b/drivers/usb/chipidea/ci13xxx_msm.c
index e8a8ba3..7d16681 100644
--- a/drivers/usb/chipidea/ci13xxx_msm.c
+++ b/drivers/usb/chipidea/ci13xxx_msm.c
@@ -77,7 +77,7 @@ static int ci13xxx_msm_probe(struct platform_device *pdev)
return 0;
}
-static int __devexit ci13xxx_msm_remove(struct platform_device *pdev)
+static int ci13xxx_msm_remove(struct platform_device *pdev)
{
struct platform_device *plat_ci = platform_get_drvdata(pdev);
diff --git a/drivers/usb/chipidea/ci13xxx_pci.c
b/drivers/usb/chipidea/ci13xxx_pci.c
index cb7eb3e..9b227e3 100644
---
[PATCH 484/493] arm: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Russell King li...@arm.linux.org.uk
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Tony Lindgren t...@atomide.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
---
arch/arm/common/scoop.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/cdce949.c | 2 +-
arch/arm/mach-mmp/sram.c | 2 +-
arch/arm/mach-omap1/mailbox.c| 2 +-
arch/arm/mach-omap2/gpmc.c | 6 +++---
arch/arm/mach-omap2/mailbox.c| 2 +-
arch/arm/mach-pxa/tosa-bt.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
arch/arm/mach-sa1100/neponset.c | 2 +-
arch/arm/mach-u300/dummyspichip.c| 2 +-
arch/arm/plat-omap/dma.c | 2 +-
arch/arm/plat-omap/dmtimer.c | 2 +-
arch/arm/plat-pxa/ssp.c | 2 +-
arch/arm/plat-samsung/adc.c | 2 +-
15 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index 2b62571..a5c3dc3 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -243,7 +243,7 @@ err_ioremap:
return ret;
}
-static int __devexit scoop_remove(struct platform_device *pdev)
+static int scoop_remove(struct platform_device *pdev)
{
struct scoop_dev *sdev = platform_get_drvdata(pdev);
int ret;
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 9211e88..6e2f163 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -358,7 +358,7 @@ static int cpld_video_probe(struct i2c_client *client,
return 0;
}
-static int __devexit cpld_video_remove(struct i2c_client *client)
+static int cpld_video_remove(struct i2c_client *client)
{
cpld_client = NULL;
return 0;
diff --git a/arch/arm/mach-davinci/cdce949.c b/arch/arm/mach-davinci/cdce949.c
index 5086cbc..abafb92 100644
--- a/arch/arm/mach-davinci/cdce949.c
+++ b/arch/arm/mach-davinci/cdce949.c
@@ -256,7 +256,7 @@ static int cdce_probe(struct i2c_client *client,
return 0;
}
-static int __devexit cdce_remove(struct i2c_client *client)
+static int cdce_remove(struct i2c_client *client)
{
cdce_i2c_client = NULL;
return 0;
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index 7e5765b..bf5e649 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -125,7 +125,7 @@ out:
return ret;
}
-static int __devexit sram_remove(struct platform_device *pdev)
+static int sram_remove(struct platform_device *pdev)
{
struct sram_bank_info *info;
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index f2109dd..efc8f20 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -165,7 +165,7 @@ static int omap1_mbox_probe(struct platform_device *pdev)
return 0;
}
-static int __devexit omap1_mbox_remove(struct platform_device *pdev)
+static int omap1_mbox_remove(struct platform_device *pdev)
{
omap_mbox_unregister();
iounmap(mbox_base);
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2fc3dd4..e0d7982 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -684,7 +684,7 @@ static int gpmc_setup_irq(void)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
}
-static __devexit int gpmc_free_irq(void)
+static int gpmc_free_irq(void)
{
int i;
@@ -702,7 +702,7 @@ static __devexit int gpmc_free_irq(void)
return 0;
}
-static void __devexit gpmc_mem_exit(void)
+static void gpmc_mem_exit(void)
{
int cs;
@@ -804,7 +804,7 @@ static int gpmc_probe(struct platform_device *pdev)
return 0;
}
-static __devexit int gpmc_remove(struct platform_device *pdev)
+static int gpmc_remove(struct platform_device *pdev)
{
gpmc_free_irq();
gpmc_mem_exit();
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 1e48d5e..0b08026 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -395,7 +395,7 @@ static int omap2_mbox_probe(struct platform_device *pdev)
return 0;
}
-static int __devexit omap2_mbox_remove(struct platform_device *pdev)
+static int omap2_mbox_remove(struct platform_device *pdev)
{
omap_mbox_unregister();
iounmap(mbox_base);
diff --git a/arch/arm/mach-pxa/tosa-bt.c b/arch/arm/mach-pxa/tosa-bt.c
index 968f284..fc3646c 100644
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -102,7 +102,7 @@
[PATCH 446/493] video: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Jaya Kumar jay...@intworks.biz Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Paul Mackerras pau...@samba.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Russell King li...@arm.linux.org.uk Cc: Jingoo Han jg1@samsung.com Cc: Inki Dae inki@samsung.com Cc: Donghwa Lee dh09@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Ferenc Bakonyi f...@drama.obuda.kando.hu Cc: Sascha Hauer ker...@pengutronix.de Cc: Maik Broemme mbroe...@plusserver.de Cc: Antonino Daplas adap...@gmail.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Thomas Winischhofer tho...@winischhofer.net Cc: Michal Januszewski sp...@gentoo.org Cc: Tony Prisk li...@prisktech.co.nz Cc: linux-fb...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ge...@lists.infradead.org Cc: linux-nvi...@lists.surfsouth.com Cc: linux-omap@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org --- drivers/video/arcfb.c | 2 +- drivers/video/arkfb.c | 2 +- drivers/video/asiliantfb.c | 2 +- drivers/video/aty/aty128fb.c| 2 +- drivers/video/aty/atyfb_base.c | 4 ++-- drivers/video/aty/radeon_base.c | 2 +- drivers/video/au1200fb.c| 2 +- drivers/video/auo_k1900fb.c | 2 +- drivers/video/auo_k1901fb.c | 2 +- drivers/video/auo_k190x.c | 2 +- drivers/video/bf537-lq035.c | 4 ++-- drivers/video/bf54x-lq043fb.c | 2 +- drivers/video/bfin-lq035q1-fb.c | 2 +- drivers/video/bfin-t350mcqb-fb.c| 2 +- drivers/video/bfin_adv7393fb.c | 2 +- drivers/video/broadsheetfb.c| 2 +- drivers/video/bw2.c | 2 +- drivers/video/carminefb.c | 2 +- drivers/video/cg14.c| 2 +- drivers/video/cg3.c | 2 +- drivers/video/cg6.c | 2 +- drivers/video/chipsfb.c | 2 +- drivers/video/cirrusfb.c| 6 +++--- drivers/video/cobalt_lcdfb.c| 2 +- drivers/video/console/sticore.c | 2 +- drivers/video/cyber2000fb.c | 4 ++-- drivers/video/da8xx-fb.c| 2 +- drivers/video/ep93xx-fb.c | 2 +- drivers/video/exynos/exynos_dp_core.c | 2 +- drivers/video/exynos/exynos_mipi_dsi.c | 2 +- drivers/video/ffb.c | 2 +- drivers/video/gbefb.c | 4 ++-- drivers/video/geode/gx1fb_core.c| 4 ++-- drivers/video/geode/gxfb_core.c | 2 +- drivers/video/geode/lxfb_core.c | 2 +- drivers/video/grvga.c | 2 +- drivers/video/gxt4500.c | 2 +- drivers/video/hecubafb.c| 2 +- drivers/video/hgafb.c | 2 +- drivers/video/hitfb.c | 2 +- drivers/video/hpfb.c| 2 +- drivers/video/i740fb.c | 2 +- drivers/video/imsttfb.c | 2 +- drivers/video/imxfb.c | 2 +- drivers/video/intelfb/intelfbdrv.c | 4 ++-- drivers/video/jz4740_fb.c | 2 +- drivers/video/kyro/fbdev.c | 2 +- drivers/video/leo.c | 2 +- drivers/video/mb862xx/mb862xxfbdrv.c| 4 ++-- drivers/video/mbx/mbxdebugfs.c | 2 +- drivers/video/mbx/mbxfb.c | 2 +- drivers/video/metronomefb.c | 2 +- drivers/video/mxsfb.c | 4 ++-- drivers/video/neofb.c | 2 +- drivers/video/nvidia/nvidia.c | 2 +- drivers/video/omap2/displays/panel-lgphilips-lb035q02.c | 2 +- drivers/video/omap2/displays/panel-tpo-td043mtea1.c | 2 +- drivers/video/p9100.c | 2 +- drivers/video/platinumfb.c | 2 +-
[PATCH 414/493] mmc: remove use of __devexit
CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Manuel Lauss manuel.la...@gmail.com
Cc: Chris Ball c...@laptop.org
Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
Cc: Venkatraman S svenk...@ti.com
Cc: Viresh Kumar viresh.li...@gmail.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Ian Molton i...@mnementh.co.uk
Cc: Bruce Chang brucech...@via.com.tw
Cc: Harald Welte haraldwe...@viatech.com
Cc: Pierre Ossman pie...@ossman.eu
Cc: linux-...@vger.kernel.org
Cc: uclinux-dist-de...@blackfin.uclinux.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: spear-de...@list.st.com
---
drivers/mmc/host/au1xmmc.c | 2 +-
drivers/mmc/host/bfin_sdh.c| 2 +-
drivers/mmc/host/cb710-mmc.c | 2 +-
drivers/mmc/host/dw_mmc-pci.c | 2 +-
drivers/mmc/host/dw_mmc-pltfm.c| 2 +-
drivers/mmc/host/dw_mmc-pltfm.h| 2 +-
drivers/mmc/host/jz4740_mmc.c | 2 +-
drivers/mmc/host/mmc_spi.c | 2 +-
drivers/mmc/host/mmci.c| 4 ++--
drivers/mmc/host/omap.c| 2 +-
drivers/mmc/host/omap_hsmmc.c | 2 +-
drivers/mmc/host/s3cmci.c | 2 +-
drivers/mmc/host/sdhci-cns3xxx.c | 2 +-
drivers/mmc/host/sdhci-dove.c | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
drivers/mmc/host/sdhci-of-esdhc.c | 2 +-
drivers/mmc/host/sdhci-of-hlwd.c | 2 +-
drivers/mmc/host/sdhci-pci.c | 4 ++--
drivers/mmc/host/sdhci-pxav2.c | 2 +-
drivers/mmc/host/sdhci-pxav3.c | 2 +-
drivers/mmc/host/sdhci-s3c.c | 2 +-
drivers/mmc/host/sdhci-spear.c | 2 +-
drivers/mmc/host/sdhci-tegra.c | 2 +-
drivers/mmc/host/sh_mmcif.c| 2 +-
drivers/mmc/host/tmio_mmc.c| 2 +-
drivers/mmc/host/via-sdmmc.c | 2 +-
drivers/mmc/host/wbsd.c| 6 +++---
27 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c
index 606c16a..127a8fa 100644
--- a/drivers/mmc/host/au1xmmc.c
+++ b/drivers/mmc/host/au1xmmc.c
@@ -1114,7 +1114,7 @@ out0:
return ret;
}
-static int __devexit au1xmmc_remove(struct platform_device *pdev)
+static int au1xmmc_remove(struct platform_device *pdev)
{
struct au1xmmc_host *host = platform_get_drvdata(pdev);
diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c
index 4ef3901..fb4348c 100644
--- a/drivers/mmc/host/bfin_sdh.c
+++ b/drivers/mmc/host/bfin_sdh.c
@@ -617,7 +617,7 @@ out1:
return ret;
}
-static int __devexit sdh_remove(struct platform_device *pdev)
+static int sdh_remove(struct platform_device *pdev)
{
struct mmc_host *mmc = platform_get_drvdata(pdev);
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c
index c12a561..777ca20 100644
--- a/drivers/mmc/host/cb710-mmc.c
+++ b/drivers/mmc/host/cb710-mmc.c
@@ -746,7 +746,7 @@ err_free_mmc:
return err;
}
-static int __devexit cb710_mmc_exit(struct platform_device *pdev)
+static int cb710_mmc_exit(struct platform_device *pdev)
{
struct cb710_slot *slot = cb710_pdev_to_slot(pdev);
struct mmc_host *mmc = cb710_slot_to_mmc(slot);
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 324c8bf..083fcd2 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -85,7 +85,7 @@ err_disable_dev:
return ret;
}
-static void __devexit dw_mci_pci_remove(struct pci_dev *pdev)
+static void dw_mci_pci_remove(struct pci_dev *pdev)
{
struct dw_mci *host = pci_get_drvdata(pdev);
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index ff73a87..5e1fb1d 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -67,7 +67,7 @@ static int dw_mci_pltfm_probe(struct platform_device *pdev)
return dw_mci_pltfm_register(pdev, NULL);
}
-static int __devexit dw_mci_pltfm_remove(struct platform_device *pdev)
+static int dw_mci_pltfm_remove(struct platform_device *pdev)
{
struct dw_mci *host = platform_get_drvdata(pdev);
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
index 2ac37b8..68e7fd2 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.h
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -14,7 +14,7 @@
extern int dw_mci_pltfm_register(struct platform_device *pdev,
const struct dw_mci_drv_data *drv_data);
-extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
+extern int dw_mci_pltfm_remove(struct platform_device *pdev);
extern const struct dev_pm_ops dw_mci_pltfm_pmops;
#endif /* _DW_MMC_PLTFM_H_ */
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index 81826be..2391c6b 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -938,7 +938,7 @@ err_free_host:
return ret;
}
-static int
[PATCH 270/493] arm: remove use of __devinit
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Russell King li...@arm.linux.org.uk
Cc: Will Deacon will.dea...@arm.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Bryan Huntsman bry...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Barry Song baohua.s...@csr.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: patc...@opensource.wolfsonmicro.com
Cc: linux-te...@vger.kernel.org
---
arch/arm/common/sa.c | 5 ++---
arch/arm/common/scoop.c | 2 +-
arch/arm/kernel/bios32.c | 16
arch/arm/kernel/etm.c| 4 ++--
arch/arm/kernel/perf_event_cpu.c | 6 +++---
arch/arm/kernel/perf_event_v6.c | 4 ++--
arch/arm/kernel/perf_event_v7.c | 12 ++--
arch/arm/kernel/perf_event_xscale.c | 4 ++--
arch/arm/mach-dove/pcie.c| 2 +-
arch/arm/mach-imx/cpufreq.c | 2 +-
arch/arm/mach-imx/mmdc.c | 2 +-
arch/arm/mach-iop13xx/pci.c | 2 +-
arch/arm/mach-kirkwood/pcie.c| 2 +-
arch/arm/mach-ks8695/board-acs5k.c | 2 +-
arch/arm/mach-mmp/sram.c | 2 +-
arch/arm/mach-msm/proc_comm.c| 2 +-
arch/arm/mach-msm/smd.c | 2 +-
arch/arm/mach-mv78xx0/pcie.c | 2 +-
arch/arm/mach-omap1/mailbox.c| 2 +-
arch/arm/mach-omap2/gpmc.c | 4 ++--
arch/arm/mach-omap2/mailbox.c| 2 +-
arch/arm/mach-orion5x/pci.c | 2 +-
arch/arm/mach-prima2/pm.c| 2 +-
arch/arm/mach-prima2/rtciobrg.c | 2 +-
arch/arm/mach-pxa/corgi_pm.c | 2 +-
arch/arm/mach-pxa/sharpsl_pm.c | 4 ++--
arch/arm/mach-pxa/spitz_pm.c | 2 +-
arch/arm/mach-s3c24xx/h1940-bluetooth.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +-
arch/arm/mach-sa1100/jornada720_ssp.c| 2 +-
arch/arm/mach-sa1100/neponset.c | 2 +-
arch/arm/mach-tegra/pcie.c | 6 +++---
arch/arm/mach-tegra/tegra2_emc.c | 4 ++--
arch/arm/mach-u300/dummyspichip.c| 2 +-
arch/arm/plat-omap/dma.c | 2 +-
arch/arm/plat-omap/dmtimer.c | 2 +-
arch/arm/plat-pxa/ssp.c | 2 +-
38 files changed, 61 insertions(+), 62 deletions(-)
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 9173d11..e57d7e5 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -686,8 +686,7 @@ sa_init_one_child(struct sa *sachip, struct
resource *parent,
* %-EINVALno platform data passed
* %0 successful.
*/
-static int __devinit
-__sa_probe(struct device *me, struct resource *mem, int irq)
+static int __sa_probe(struct device *me, struct resource *mem, int irq)
{
struct sa_platform_data *pd = me-platform_data;
struct sa *sachip;
@@ -1011,7 +1010,7 @@ static int sa_resume(struct platform_device *dev)
#define sa_resume NULL
#endif
-static int __devinit sa_probe(struct platform_device *pdev)
+static int sa_probe(struct platform_device *pdev)
{
struct resource *mem;
int irq;
diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index 7cac8dd..2b62571 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -176,7 +176,7 @@ static int scoop_resume(struct platform_device *dev)
#define scoop_resume NULL
#endif
-static int __devinit scoop_probe(struct platform_device *pdev)
+static int scoop_probe(struct platform_device *pdev)
{
struct scoop_dev *devptr;
struct scoop_config *inf;
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index f136307..7e25c18 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -78,7 +78,7 @@ void pcibios_report_status(u_int status_mask, int warn)
* Bug 3 is responsible for the sound DMA grinding to a halt. We now
* live with bug 2.
*/
-static void __devinit pci_fixup_83c553(struct pci_dev *dev)
+static void pci_fixup_83c553(struct pci_dev *dev)
{
/*
* Set memory region to start at address 0, and enable IO
@@ -130,7 +130,7 @@ static void __devinit pci_fixup_83c553(struct
[PATCH 032/493] arm: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
---
arch/arm/common/scoop.c | 2 +-
arch/arm/mach-davinci/cdce949.c | 2 +-
arch/arm/mach-omap1/mailbox.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 2 +-
arch/arm/mach-omap2/mailbox.c | 2 +-
arch/arm/mach-pxa/tosa-bt.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
arch/arm/mach-sa1100/neponset.c | 2 +-
arch/arm/mach-u300/dummyspichip.c | 2 +-
arch/arm/plat-omap/dma.c| 2 +-
arch/arm/plat-omap/dmtimer.c| 2 +-
arch/arm/plat-pxa/ssp.c | 2 +-
arch/arm/plat-samsung/adc.c | 2 +-
13 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index 0c616d5..7cac8dd 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -268,7 +268,7 @@ static int __devexit scoop_remove(struct platform_device
*pdev)
static struct platform_driver scoop_driver = {
.probe = scoop_probe,
- .remove = __devexit_p(scoop_remove),
+ .remove = scoop_remove,
.suspend= scoop_suspend,
.resume = scoop_resume,
.driver = {
diff --git a/arch/arm/mach-davinci/cdce949.c b/arch/arm/mach-davinci/cdce949.c
index f2232ca..5086cbc 100644
--- a/arch/arm/mach-davinci/cdce949.c
+++ b/arch/arm/mach-davinci/cdce949.c
@@ -274,7 +274,7 @@ static struct i2c_driver cdce_driver = {
.name = cdce949,
},
.probe = cdce_probe,
- .remove = __devexit_p(cdce_remove),
+ .remove = cdce_remove,
.id_table = cdce_id,
};
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index e962926..e7e1f2a 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -174,7 +174,7 @@ static int __devexit omap1_mbox_remove(struct
platform_device *pdev)
static struct platform_driver omap1_mbox_driver = {
.probe = omap1_mbox_probe,
- .remove = __devexit_p(omap1_mbox_remove),
+ .remove = omap1_mbox_remove,
.driver = {
.name = omap-mailbox,
},
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bf6117c..b4226a4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -814,7 +814,7 @@ static __devexit int gpmc_remove(struct platform_device
*pdev)
static struct platform_driver gpmc_driver = {
.probe = gpmc_probe,
- .remove = __devexit_p(gpmc_remove),
+ .remove = gpmc_remove,
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..64308f4 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -404,7 +404,7 @@ static int __devexit omap2_mbox_remove(struct
platform_device *pdev)
static struct platform_driver omap2_mbox_driver = {
.probe = omap2_mbox_probe,
- .remove = __devexit_p(omap2_mbox_remove),
+ .remove = omap2_mbox_remove,
.driver = {
.name = omap-mailbox,
},
diff --git a/arch/arm/mach-pxa/tosa-bt.c b/arch/arm/mach-pxa/tosa-bt.c
index b9b1e5c..968f284 100644
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -125,7 +125,7 @@ static int __devexit tosa_bt_remove(struct platform_device
*dev)
static struct platform_driver tosa_bt_driver = {
.probe = tosa_bt_probe,
- .remove = __devexit_p(tosa_bt_remove),
+ .remove = tosa_bt_remove,
.driver = {
.name = tosa-bt,
diff --git a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
index 5876c6b..b7b712b 100644
--- a/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
+++ b/arch/arm/mach-s3c24xx/mach-osiris-dvs.c
@@ -167,7 +167,7 @@ static const struct dev_pm_ops osiris_dvs_pm = {
static struct platform_driver osiris_dvs_driver = {
.probe = osiris_dvs_probe,
- .remove = __devexit_p(osiris_dvs_remove),
+ .remove = osiris_dvs_remove,
.driver = {
.name = osiris-dvs,
.owner = THIS_MODULE,
diff --git a/arch/arm/mach-sa1100/neponset.c b/arch/arm/mach-sa1100/neponset.c
index 266db87..c408b8b 100644
--- a/arch/arm/mach-sa1100/neponset.c
+++
[PATCH 121/493] video: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Jaya Kumar jay...@intworks.biz Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Paul Mackerras pau...@samba.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Russell King li...@arm.linux.org.uk Cc: Jingoo Han jg1@samsung.com Cc: Inki Dae inki@samsung.com Cc: Donghwa Lee dh09@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Ferenc Bakonyi f...@drama.obuda.kando.hu Cc: Sascha Hauer ker...@pengutronix.de Cc: Maik Broemme mbroe...@plusserver.de Cc: Antonino Daplas adap...@gmail.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: Thomas Winischhofer tho...@winischhofer.net Cc: Tony Prisk li...@prisktech.co.nz Cc: linux-fb...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ge...@lists.infradead.org Cc: linux-nvi...@lists.surfsouth.com Cc: linux-omap@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org --- drivers/video/arcfb.c | 2 +- drivers/video/arkfb.c | 2 +- drivers/video/asiliantfb.c | 2 +- drivers/video/aty/aty128fb.c| 2 +- drivers/video/aty/atyfb_base.c | 2 +- drivers/video/aty/radeon_base.c | 2 +- drivers/video/au1200fb.c| 2 +- drivers/video/auo_k1900fb.c | 2 +- drivers/video/auo_k1901fb.c | 2 +- drivers/video/bf537-lq035.c | 4 ++-- drivers/video/bf54x-lq043fb.c | 2 +- drivers/video/bfin-lq035q1-fb.c | 4 ++-- drivers/video/bfin-t350mcqb-fb.c| 2 +- drivers/video/bfin_adv7393fb.c | 2 +- drivers/video/broadsheetfb.c| 2 +- drivers/video/bw2.c | 2 +- drivers/video/carminefb.c | 2 +- drivers/video/cg14.c| 2 +- drivers/video/cg3.c | 2 +- drivers/video/cg6.c | 2 +- drivers/video/chipsfb.c | 2 +- drivers/video/cirrusfb.c| 4 ++-- drivers/video/cobalt_lcdfb.c| 2 +- drivers/video/cyber2000fb.c | 2 +- drivers/video/da8xx-fb.c| 2 +- drivers/video/ep93xx-fb.c | 2 +- drivers/video/exynos/exynos_dp_core.c | 2 +- drivers/video/exynos/exynos_mipi_dsi.c | 2 +- drivers/video/ffb.c | 2 +- drivers/video/gbefb.c | 2 +- drivers/video/geode/gx1fb_core.c| 2 +- drivers/video/grvga.c | 2 +- drivers/video/gxt4500.c | 2 +- drivers/video/hecubafb.c| 2 +- drivers/video/hgafb.c | 2 +- drivers/video/hitfb.c | 2 +- drivers/video/i740fb.c | 2 +- drivers/video/imsttfb.c | 2 +- drivers/video/imxfb.c | 2 +- drivers/video/intelfb/intelfbdrv.c | 2 +- drivers/video/jz4740_fb.c | 2 +- drivers/video/kyro/fbdev.c | 2 +- drivers/video/leo.c | 2 +- drivers/video/mb862xx/mb862xxfbdrv.c| 4 ++-- drivers/video/mbx/mbxfb.c | 2 +- drivers/video/metronomefb.c | 2 +- drivers/video/mxsfb.c | 2 +- drivers/video/neofb.c | 2 +- drivers/video/nvidia/nvidia.c | 2 +- drivers/video/omap/lcd_mipid.c | 2 +- drivers/video/omap2/displays/panel-acx565akm.c | 2 +- drivers/video/omap2/displays/panel-lgphilips-lb035q02.c | 2 +- drivers/video/omap2/displays/panel-n8x0.c | 2 +- drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c | 2 +- drivers/video/omap2/displays/panel-tpo-td043mtea1.c | 2 +- drivers/video/p9100.c | 2 +- drivers/video/platinumfb.c | 2 +- drivers/video/pm2fb.c | 2 +- drivers/video/pm3fb.c | 2 +- drivers/video/pvr2fb.c | 2 +- drivers/video/pxa168fb.c
[PATCH 077/493] mmc: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Chris Ball c...@laptop.org
Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
Cc: Venkatraman S svenk...@ti.com
Cc: Viresh Kumar viresh.li...@gmail.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Ian Molton i...@mnementh.co.uk
Cc: Bruce Chang brucech...@via.com.tw
Cc: Harald Welte haraldwe...@viatech.com
Cc: Pierre Ossman pie...@ossman.eu
Cc: uclinux-dist-de...@blackfin.uclinux.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: spear-de...@list.st.com
---
drivers/mmc/host/bfin_sdh.c| 2 +-
drivers/mmc/host/cb710-mmc.c | 2 +-
drivers/mmc/host/dw_mmc-pci.c | 2 +-
drivers/mmc/host/dw_mmc-pltfm.c| 2 +-
drivers/mmc/host/jz4740_mmc.c | 2 +-
drivers/mmc/host/mmc_spi.c | 2 +-
drivers/mmc/host/mmci.c| 2 +-
drivers/mmc/host/omap.c| 2 +-
drivers/mmc/host/omap_hsmmc.c | 2 +-
drivers/mmc/host/s3cmci.c | 2 +-
drivers/mmc/host/sdhci-cns3xxx.c | 2 +-
drivers/mmc/host/sdhci-dove.c | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 2 +-
drivers/mmc/host/sdhci-of-esdhc.c | 2 +-
drivers/mmc/host/sdhci-of-hlwd.c | 2 +-
drivers/mmc/host/sdhci-pci.c | 2 +-
drivers/mmc/host/sdhci-pxav2.c | 2 +-
drivers/mmc/host/sdhci-pxav3.c | 2 +-
drivers/mmc/host/sdhci-s3c.c | 2 +-
drivers/mmc/host/sdhci-spear.c | 2 +-
drivers/mmc/host/sdhci-tegra.c | 2 +-
drivers/mmc/host/sh_mobile_sdhi.c | 2 +-
drivers/mmc/host/tmio_mmc.c| 2 +-
drivers/mmc/host/via-sdmmc.c | 2 +-
drivers/mmc/host/wbsd.c| 4 ++--
25 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c
index b9b463e..156ebe7 100644
--- a/drivers/mmc/host/bfin_sdh.c
+++ b/drivers/mmc/host/bfin_sdh.c
@@ -680,7 +680,7 @@ static int sdh_resume(struct platform_device *dev)
static struct platform_driver sdh_driver = {
.probe = sdh_probe,
- .remove = __devexit_p(sdh_remove),
+ .remove = sdh_remove,
.suspend = sdh_suspend,
.resume = sdh_resume,
.driver = {
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c
index 83693fd..39280b5 100644
--- a/drivers/mmc/host/cb710-mmc.c
+++ b/drivers/mmc/host/cb710-mmc.c
@@ -773,7 +773,7 @@ static int __devexit cb710_mmc_exit(struct platform_device
*pdev)
static struct platform_driver cb710_mmc_driver = {
.driver.name = cb710-mmc,
.probe = cb710_mmc_init,
- .remove = __devexit_p(cb710_mmc_exit),
+ .remove = cb710_mmc_exit,
#ifdef CONFIG_PM
.suspend = cb710_mmc_suspend,
.resume = cb710_mmc_resume,
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index 53a09cb..edb37e9 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -134,7 +134,7 @@ static struct pci_driver dw_mci_pci_driver = {
.name = dw_mmc_pci,
.id_table = dw_mci_pci_id,
.probe = dw_mci_pci_probe,
- .remove = __devexit_p(dw_mci_pci_remove),
+ .remove = dw_mci_pci_remove,
.driver = {
.pm = dw_mci_pci_pmops
},
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 4e13370..4c1b1df 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -120,7 +120,7 @@ MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
static struct platform_driver dw_mci_pltfm_driver = {
.probe = dw_mci_pltfm_probe,
- .remove = __devexit_p(dw_mci_pltfm_remove),
+ .remove = dw_mci_pltfm_remove,
.driver = {
.name = dw_mmc,
.of_match_table = of_match_ptr(dw_mci_pltfm_match),
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c
index c8852a8..31cf20f 100644
--- a/drivers/mmc/host/jz4740_mmc.c
+++ b/drivers/mmc/host/jz4740_mmc.c
@@ -1004,7 +1004,7 @@ const struct dev_pm_ops jz4740_mmc_pm_ops = {
static struct platform_driver jz4740_mmc_driver = {
.probe = jz4740_mmc_probe,
- .remove = __devexit_p(jz4740_mmc_remove),
+ .remove = jz4740_mmc_remove,
.driver = {
.name = jz4740-mmc,
.owner = THIS_MODULE,
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index a600eab..f7df798 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1529,7 +1529,7 @@ static struct spi_driver mmc_spi_driver = {
.of_match_table = mmc_spi_of_match_table,
},
.probe =mmc_spi_probe,
- .remove = __devexit_p(mmc_spi_remove),
+ .remove = mmc_spi_remove,
};
[PATCH 119/493] usb: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Alexander Shishkin alexander.shish...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
Cc: Li Yang le...@freescale.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Wan ZongShun mcuos@gmail.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
drivers/usb/c67x00/c67x00-drv.c | 2 +-
drivers/usb/chipidea/ci13xxx_imx.c | 2 +-
drivers/usb/chipidea/ci13xxx_msm.c | 2 +-
drivers/usb/chipidea/ci13xxx_pci.c | 2 +-
drivers/usb/chipidea/core.c | 2 +-
drivers/usb/chipidea/usbmisc_imx6q.c | 2 +-
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/dwc3/dwc3-exynos.c | 2 +-
drivers/usb/dwc3/dwc3-omap.c | 2 +-
drivers/usb/dwc3/dwc3-pci.c | 2 +-
drivers/usb/gadget/bcm63xx_udc.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c | 2 +-
drivers/usb/gadget/hid.c | 2 +-
drivers/usb/gadget/lpc32xx_udc.c | 2 +-
drivers/usb/gadget/net2272.c | 4 ++--
drivers/usb/gadget/omap_udc.c| 2 +-
drivers/usb/gadget/s3c-hsotg.c | 2 +-
drivers/usb/host/bcma-hcd.c | 2 +-
drivers/usb/host/ehci-atmel.c| 2 +-
drivers/usb/host/ehci-msm.c | 2 +-
drivers/usb/host/ehci-platform.c | 2 +-
drivers/usb/host/ehci-s5p.c | 2 +-
drivers/usb/host/ehci-w90x900.c | 2 +-
drivers/usb/host/fhci-hcd.c | 2 +-
drivers/usb/host/fsl-mph-dr-of.c | 2 +-
drivers/usb/host/isp1362-hcd.c | 2 +-
drivers/usb/host/isp1760-if.c| 2 +-
drivers/usb/host/ohci-at91.c | 2 +-
drivers/usb/host/ohci-exynos.c | 2 +-
drivers/usb/host/ohci-jz4740.c | 2 +-
drivers/usb/host/ohci-omap3.c| 2 +-
drivers/usb/host/ohci-platform.c | 2 +-
drivers/usb/host/ohci-s3c2410.c | 2 +-
drivers/usb/host/ohci-tmio.c | 2 +-
drivers/usb/host/r8a66597-hcd.c | 2 +-
drivers/usb/host/sl811-hcd.c | 2 +-
drivers/usb/host/ssb-hcd.c | 2 +-
drivers/usb/host/u132-hcd.c | 2 +-
drivers/usb/musb/am35x.c | 2 +-
drivers/usb/musb/da8xx.c | 2 +-
drivers/usb/musb/davinci.c | 2 +-
drivers/usb/musb/musb_core.c | 2 +-
drivers/usb/musb/musb_dsps.c | 2 +-
drivers/usb/musb/omap2430.c | 2 +-
drivers/usb/musb/tusb6010.c | 2 +-
drivers/usb/musb/ux500.c | 2 +-
drivers/usb/otg/ab8500-usb.c | 2 +-
drivers/usb/otg/fsl_otg.c| 2 +-
drivers/usb/otg/msm_otg.c| 2 +-
drivers/usb/otg/mxs-phy.c| 2 +-
drivers/usb/otg/nop-usb-xceiv.c | 2 +-
drivers/usb/phy/mv_u3d_phy.c | 2 +-
drivers/usb/phy/omap-usb2.c | 2 +-
drivers/usb/phy/rcar-phy.c | 2 +-
drivers/usb/renesas_usbhs/common.c | 2 +-
55 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x00/c67x00-drv.c
index 6f3b6e2..855d538 100644
--- a/drivers/usb/c67x00/c67x00-drv.c
+++ b/drivers/usb/c67x00/c67x00-drv.c
@@ -219,7 +219,7 @@ static int __devexit c67x00_drv_remove(struct
platform_device *pdev)
static struct platform_driver c67x00_driver = {
.probe = c67x00_drv_probe,
- .remove = __devexit_p(c67x00_drv_remove),
+ .remove = c67x00_drv_remove,
.driver = {
.owner = THIS_MODULE,
.name = c67x00,
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 0f5ca4b..5659730 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -252,7 +252,7 @@ MODULE_DEVICE_TABLE(of, ci13xxx_imx_dt_ids);
static struct platform_driver ci13xxx_imx_driver = {
.probe = ci13xxx_imx_probe,
- .remove = __devexit_p(ci13xxx_imx_remove),
+ .remove = ci13xxx_imx_remove,
.driver = {
.name = imx_usb,
.owner = THIS_MODULE,
diff --git a/drivers/usb/chipidea/ci13xxx_msm.c
b/drivers/usb/chipidea/ci13xxx_msm.c
index b01feb3..406c5af 100644
--- a/drivers/usb/chipidea/ci13xxx_msm.c
+++ b/drivers/usb/chipidea/ci13xxx_msm.c
@@ -89,7 +89,7 @@ static int __devexit ci13xxx_msm_remove(struct
platform_device *pdev)
static struct platform_driver ci13xxx_msm_driver = {
.probe = ci13xxx_msm_probe,
- .remove = __devexit_p(ci13xxx_msm_remove),
+ .remove = ci13xxx_msm_remove,
.driver = { .name = msm_hsusb, },
};
diff --git a/drivers/usb/chipidea/ci13xxx_pci.c
b/drivers/usb/chipidea/ci13xxx_pci.c
index 918e149..e1cb2fb 100644
--- a/drivers/usb/chipidea/ci13xxx_pci.c
+++ b/drivers/usb/chipidea/ci13xxx_pci.c
@@ -147,7 +147,7 @@ static struct pci_driver
[PATCH 064/493] hwspinlock: remove use of __devexit_p
CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/hwspinlock/omap_hwspinlock.c | 2 +-
drivers/hwspinlock/u8500_hsem.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 887d34e..28640b8 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -163,7 +163,7 @@ static int __devexit omap_hwspinlock_remove(struct
platform_device *pdev)
static struct platform_driver omap_hwspinlock_driver = {
.probe = omap_hwspinlock_probe,
- .remove = __devexit_p(omap_hwspinlock_remove),
+ .remove = omap_hwspinlock_remove,
.driver = {
.name = omap_hwspinlock,
.owner = THIS_MODULE,
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 86980fe..4039810 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -172,7 +172,7 @@ static int __devexit u8500_hsem_remove(struct
platform_device *pdev)
static struct platform_driver u8500_hsem_driver = {
.probe = u8500_hsem_probe,
- .remove = __devexit_p(u8500_hsem_remove),
+ .remove = u8500_hsem_remove,
.driver = {
.name = u8500_hsem,
.owner = THIS_MODULE,
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 253/493] hwspinlock: remove use of __devinit
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/hwspinlock/omap_hwspinlock.c | 2 +-
drivers/hwspinlock/u8500_hsem.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 28640b8..f21b2ed 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -78,7 +78,7 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
.relax = omap_hwspinlock_relax,
};
-static int __devinit omap_hwspinlock_probe(struct platform_device *pdev)
+static int omap_hwspinlock_probe(struct platform_device *pdev)
{
struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
struct hwspinlock_device *bank;
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 4039810..5a5b3f2 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -91,7 +91,7 @@ static const struct hwspinlock_ops u8500_hwspinlock_ops = {
.relax = u8500_hsem_relax,
};
-static int __devinit u8500_hsem_probe(struct platform_device *pdev)
+static int u8500_hsem_probe(struct platform_device *pdev)
{
struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
struct hwspinlock_device *bank;
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 205/493] gpio: remove use of __devinit
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Peter Tyser pty...@xes-inc.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: device-drivers-de...@blackfin.uclinux.org
Cc: patc...@opensource.wolfsonmicro.com
Cc: linux-omap@vger.kernel.org
---
drivers/gpio/gpio-74x164.c | 2 +-
drivers/gpio/gpio-ab8500.c | 2 +-
drivers/gpio/gpio-adnp.c | 2 +-
drivers/gpio/gpio-adp5520.c| 2 +-
drivers/gpio/gpio-adp5588.c| 2 +-
drivers/gpio/gpio-arizona.c| 2 +-
drivers/gpio/gpio-cs5535.c | 2 +-
drivers/gpio/gpio-da9052.c | 2 +-
drivers/gpio/gpio-da9055.c | 2 +-
drivers/gpio/gpio-em.c | 2 +-
drivers/gpio/gpio-ep93xx.c | 2 +-
drivers/gpio/gpio-generic.c| 2 +-
drivers/gpio/gpio-ich.c| 6 +++---
drivers/gpio/gpio-janz-ttl.c | 6 +++---
drivers/gpio/gpio-langwell.c | 4 ++--
drivers/gpio/gpio-lpc32xx.c| 2 +-
drivers/gpio/gpio-max7300.c| 2 +-
drivers/gpio/gpio-max7301.c| 2 +-
drivers/gpio/gpio-max730x.c| 2 +-
drivers/gpio/gpio-max732x.c| 4 ++--
drivers/gpio/gpio-mc33880.c| 2 +-
drivers/gpio/gpio-mcp23s08.c | 2 +-
drivers/gpio/gpio-ml-ioh.c | 4 ++--
drivers/gpio/gpio-mpc5200.c| 4 ++--
drivers/gpio/gpio-msic.c | 2 +-
drivers/gpio/gpio-msm-v2.c | 2 +-
drivers/gpio/gpio-mvebu.c | 2 +-
drivers/gpio/gpio-mxc.c| 4 ++--
drivers/gpio/gpio-mxs.c| 2 +-
drivers/gpio/gpio-omap.c | 6 +++---
drivers/gpio/gpio-pca953x.c| 6 +++---
drivers/gpio/gpio-pch.c| 4 ++--
drivers/gpio/gpio-pxa.c| 6 +++---
drivers/gpio/gpio-rc5t583.c| 2 +-
drivers/gpio/gpio-rdc321x.c| 2 +-
drivers/gpio/gpio-sch.c| 2 +-
drivers/gpio/gpio-sodaville.c | 4 ++--
drivers/gpio/gpio-sta2x11.c| 4 ++--
drivers/gpio/gpio-stmpe.c | 4 ++--
drivers/gpio/gpio-stp-xway.c | 2 +-
drivers/gpio/gpio-sx150x.c | 2 +-
drivers/gpio/gpio-tc3589x.c| 2 +-
drivers/gpio/gpio-tegra.c | 2 +-
drivers/gpio/gpio-timberdale.c | 2 +-
drivers/gpio/gpio-tps6586x.c | 2 +-
drivers/gpio/gpio-tps65910.c | 2 +-
drivers/gpio/gpio-tps65912.c | 2 +-
drivers/gpio/gpio-twl4030.c| 6 +++---
drivers/gpio/gpio-twl6040.c| 2 +-
drivers/gpio/gpio-vr41xx.c | 2 +-
drivers/gpio/gpio-vt8500.c | 2 +-
drivers/gpio/gpio-vx855.c | 2 +-
drivers/gpio/gpio-wm831x.c | 2 +-
drivers/gpio/gpio-wm8350.c | 2 +-
drivers/gpio/gpio-wm8994.c | 2 +-
drivers/gpio/gpio-xilinx.c | 2 +-
56 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c
index ee1cb30..2e6df41 100644
--- a/drivers/gpio/gpio-74x164.c
+++ b/drivers/gpio/gpio-74x164.c
@@ -105,7 +105,7 @@ static int gen_74x164_direction_output(struct gpio_chip *gc,
return 0;
}
-static int __devinit gen_74x164_probe(struct spi_device *spi)
+static int gen_74x164_probe(struct spi_device *spi)
{
struct gen_74x164_chip *chip;
struct gen_74x164_chip_platform_data *pdata;
diff --git a/drivers/gpio/gpio-ab8500.c b/drivers/gpio/gpio-ab8500.c
index 48c3bab..0a636de 100644
--- a/drivers/gpio/gpio-ab8500.c
+++ b/drivers/gpio/gpio-ab8500.c
@@ -402,7 +402,7 @@ static void ab8500_gpio_irq_remove(struct ab8500_gpio
*ab8500_gpio)
}
}
-static int __devinit ab8500_gpio_probe(struct platform_device *pdev)
+static int ab8500_gpio_probe(struct platform_device *pdev)
{
struct ab8500_platform_data *ab8500_pdata =
dev_get_platdata(pdev-dev.parent);
diff --git a/drivers/gpio/gpio-adnp.c b/drivers/gpio/gpio-adnp.c
index 9796b9c..9f23684 100644
--- a/drivers/gpio/gpio-adnp.c
+++ b/drivers/gpio/gpio-adnp.c
@@ -516,7 +516,7 @@ static void adnp_irq_teardown(struct adnp *adnp)
irq_domain_remove(adnp-domain);
}
-static __devinit int adnp_i2c_probe(struct i2c_client *client,
+static int adnp_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct device_node *np = client-dev.of_node;
diff --git a/drivers/gpio/gpio-adp5520.c b/drivers/gpio/gpio-adp5520.c
index fc01e6d..b9fac75 100644
--- a/drivers/gpio/gpio-adp5520.c
+++ b/drivers/gpio/gpio-adp5520.c
@@ -87,7 +87,7 @@ static int adp5520_gpio_direction_output(struct gpio_chip
*chip,
return ret;
}
-static int __devinit adp5520_gpio_probe(struct platform_device *pdev)
+static int adp5520_gpio_probe(struct platform_device *pdev)
{
struct adp5520_gpio_platform_data *pdata = pdev-dev.platform_data;
struct adp5520_gpio *dev;
diff --git a/drivers/gpio/gpio-adp5588.c b/drivers/gpio/gpio-adp5588.c
index f762269..27001ec 100644
--- a/drivers/gpio/gpio-adp5588.c
+++ b/drivers/gpio/gpio-adp5588.c
@@ -346,7 +346,7 @@ static void adp5588_irq_teardown(struct
[PATCH 207/493] i2c: remove use of __devinit
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Jean Delvare kh...@linux-fr.org
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Rudolf Marek r.ma...@assembler.cz
Cc: Jochen Friedrich joc...@scram.de
Cc: Peter Korsgaard jac...@sunsite.dk
Cc: Tony Lindgren t...@atomide.com
Cc: Olof Johansson o...@lixom.net
Cc: Vitaly Wool vitalyw...@gmail.com
Cc: Guan Xuetao g...@mprc.pku.edu.cn
Cc: Barry Song baohua.s...@csr.com
Cc: Mark M. Hoffman mhoff...@lightlink.com
Cc: linux-...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/i2c/busses/i2c-ali1535.c| 4 ++--
drivers/i2c/busses/i2c-ali1563.c| 4 ++--
drivers/i2c/busses/i2c-ali15x3.c| 4 ++--
drivers/i2c/busses/i2c-amd756.c | 2 +-
drivers/i2c/busses/i2c-amd8111.c| 2 +-
drivers/i2c/busses/i2c-at91.c | 6 +++---
drivers/i2c/busses/i2c-au1550.c | 2 +-
drivers/i2c/busses/i2c-cpm.c| 4 ++--
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
drivers/i2c/busses/i2c-eg20t.c | 2 +-
drivers/i2c/busses/i2c-elektor.c| 4 ++--
drivers/i2c/busses/i2c-gpio.c | 4 ++--
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-hydra.c | 2 +-
drivers/i2c/busses/i2c-i801.c | 14 +++---
drivers/i2c/busses/i2c-ibm_iic.c| 4 ++--
drivers/i2c/busses/i2c-intel-mid.c | 2 +-
drivers/i2c/busses/i2c-isch.c | 2 +-
drivers/i2c/busses/i2c-mpc.c| 20 ++--
drivers/i2c/busses/i2c-mv64xxx.c| 12 ++--
drivers/i2c/busses/i2c-mxs.c| 2 +-
drivers/i2c/busses/i2c-nforce2.c| 4 ++--
drivers/i2c/busses/i2c-nuc900.c | 2 +-
drivers/i2c/busses/i2c-ocores.c | 2 +-
drivers/i2c/busses/i2c-octeon.c | 6 +++---
drivers/i2c/busses/i2c-omap.c | 2 +-
drivers/i2c/busses/i2c-parport-light.c | 2 +-
drivers/i2c/busses/i2c-pasemi.c | 2 +-
drivers/i2c/busses/i2c-pca-isa.c| 4 ++--
drivers/i2c/busses/i2c-pca-platform.c | 2 +-
drivers/i2c/busses/i2c-piix4.c | 10 +-
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/i2c/busses/i2c-pnx.c| 2 +-
drivers/i2c/busses/i2c-powermac.c | 12 ++--
drivers/i2c/busses/i2c-puv3.c | 2 +-
drivers/i2c/busses/i2c-pxa-pci.c| 2 +-
drivers/i2c/busses/i2c-rcar.c | 2 +-
drivers/i2c/busses/i2c-s6000.c | 4 ++--
drivers/i2c/busses/i2c-sh7760.c | 4 ++--
drivers/i2c/busses/i2c-sirf.c | 2 +-
drivers/i2c/busses/i2c-sis5595.c| 4 ++--
drivers/i2c/busses/i2c-sis630.c | 4 ++--
drivers/i2c/busses/i2c-sis96x.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
drivers/i2c/busses/i2c-via.c| 2 +-
drivers/i2c/busses/i2c-viapro.c | 2 +-
drivers/i2c/busses/i2c-xiic.c | 2 +-
drivers/i2c/busses/i2c-xlr.c| 2 +-
drivers/i2c/busses/scx200_acb.c | 10 +-
drivers/i2c/muxes/i2c-mux-gpio.c| 4 ++--
drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +-
52 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ali1535.c b/drivers/i2c/busses/i2c-ali1535.c
index cb30432..9ee96f0 100644
--- a/drivers/i2c/busses/i2c-ali1535.c
+++ b/drivers/i2c/busses/i2c-ali1535.c
@@ -139,7 +139,7 @@ static unsigned short ali1535_offset;
Note the differences between kernels with the old PCI BIOS interface and
newer kernels with the real PCI interface. In compat.h some things are
defined to make the transition easier. */
-static int __devinit ali1535_setup(struct pci_dev *dev)
+static int ali1535_setup(struct pci_dev *dev)
{
int retval;
unsigned char temp;
@@ -502,7 +502,7 @@ static DEFINE_PCI_DEVICE_TABLE(ali1535_ids) = {
MODULE_DEVICE_TABLE(pci, ali1535_ids);
-static int __devinit ali1535_probe(struct pci_dev *dev, const struct
pci_device_id *id)
+static int ali1535_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
if (ali1535_setup(dev)) {
dev_warn(dev-dev,
diff --git a/drivers/i2c/busses/i2c-ali1563.c b/drivers/i2c/busses/i2c-ali1563.c
index 547a96f..55c27b9 100644
--- a/drivers/i2c/busses/i2c-ali1563.c
+++ b/drivers/i2c/busses/i2c-ali1563.c
@@ -326,7 +326,7 @@ static u32 ali1563_func(struct i2c_adapter * a)
}
-static int __devinit ali1563_setup(struct pci_dev * dev)
+static int ali1563_setup(struct pci_dev * dev)
{
u16 ctrl;
@@ -390,7
[PATCH 237/493] mmc: remove use of __devinit
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton wf...@virginia.edu
Cc: Ludovic Desroches ludovic.desroc...@atmel.com
Cc: Chris Ball c...@laptop.org
Cc: Manuel Lauss manuel.la...@gmail.com
Cc: Michał Mirosław mirq-li...@rere.qmqm.pl
Cc: Jarkko Lavinen jarkko.lavi...@nokia.com
Cc: Venkatraman S svenk...@ti.com
Cc: Viresh Kumar viresh.li...@gmail.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Ian Molton i...@mnementh.co.uk
Cc: Bruce Chang brucech...@via.com.tw
Cc: Harald Welte haraldwe...@viatech.com
Cc: Pierre Ossman pie...@ossman.eu
Cc: linux-...@vger.kernel.org
Cc: uclinux-dist-de...@blackfin.uclinux.org
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: spear-de...@list.st.com
---
drivers/mmc/host/atmel-mci.c | 2 +-
drivers/mmc/host/au1xmmc.c | 2 +-
drivers/mmc/host/bfin_sdh.c| 2 +-
drivers/mmc/host/cb710-mmc.c | 2 +-
drivers/mmc/host/dw_mmc-pci.c | 2 +-
drivers/mmc/host/dw_mmc-pltfm.c| 2 +-
drivers/mmc/host/jz4740_mmc.c | 8
drivers/mmc/host/mmci.c| 6 +++---
drivers/mmc/host/omap.c| 4 ++--
drivers/mmc/host/omap_hsmmc.c | 2 +-
drivers/mmc/host/pxamci.c | 4 ++--
drivers/mmc/host/s3cmci.c | 2 +-
drivers/mmc/host/sdhci-cns3xxx.c | 2 +-
drivers/mmc/host/sdhci-dove.c | 2 +-
drivers/mmc/host/sdhci-esdhc-imx.c | 4 ++--
drivers/mmc/host/sdhci-of-esdhc.c | 2 +-
drivers/mmc/host/sdhci-of-hlwd.c | 2 +-
drivers/mmc/host/sdhci-pci.c | 6 +++---
drivers/mmc/host/sdhci-pxav2.c | 2 +-
drivers/mmc/host/sdhci-pxav3.c | 2 +-
drivers/mmc/host/sdhci-s3c.c | 6 +++---
drivers/mmc/host/sdhci-spear.c | 8 +++-
drivers/mmc/host/sdhci-tegra.c | 4 ++--
drivers/mmc/host/sh_mmcif.c| 2 +-
drivers/mmc/host/sh_mobile_sdhi.c | 2 +-
drivers/mmc/host/tmio_mmc.c| 2 +-
drivers/mmc/host/tmio_mmc_pio.c| 2 +-
drivers/mmc/host/via-sdmmc.c | 2 +-
drivers/mmc/host/wbsd.c| 18 +-
29 files changed, 52 insertions(+), 54 deletions(-)
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 8689989..722af1d 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -511,7 +511,7 @@ static const struct of_device_id atmci_dt_ids[] = {
MODULE_DEVICE_TABLE(of, atmci_dt_ids);
-static struct mci_platform_data __devinit*
+static struct mci_platform_data*
atmci_of_init(struct platform_device *pdev)
{
struct device_node *np = pdev-dev.of_node;
diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c
index dbd0c8a..606c16a 100644
--- a/drivers/mmc/host/au1xmmc.c
+++ b/drivers/mmc/host/au1xmmc.c
@@ -943,7 +943,7 @@ static const struct mmc_host_ops au1xmmc_ops = {
.enable_sdio_irq = au1xmmc_enable_sdio_irq,
};
-static int __devinit au1xmmc_probe(struct platform_device *pdev)
+static int au1xmmc_probe(struct platform_device *pdev)
{
struct mmc_host *mmc;
struct au1xmmc_host *host;
diff --git a/drivers/mmc/host/bfin_sdh.c b/drivers/mmc/host/bfin_sdh.c
index 156ebe7..4ef3901 100644
--- a/drivers/mmc/host/bfin_sdh.c
+++ b/drivers/mmc/host/bfin_sdh.c
@@ -522,7 +522,7 @@ static void sdh_reset(void)
SSYNC();
}
-static int __devinit sdh_probe(struct platform_device *pdev)
+static int sdh_probe(struct platform_device *pdev)
{
struct mmc_host *mmc;
struct sdh_host *host;
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c
index 39280b5..c12a561 100644
--- a/drivers/mmc/host/cb710-mmc.c
+++ b/drivers/mmc/host/cb710-mmc.c
@@ -690,7 +690,7 @@ static int cb710_mmc_resume(struct platform_device *pdev)
#endif /* CONFIG_PM */
-static int __devinit cb710_mmc_init(struct platform_device *pdev)
+static int cb710_mmc_init(struct platform_device *pdev)
{
struct cb710_slot *slot = cb710_pdev_to_slot(pdev);
struct cb710_chip *chip = cb710_slot_to_chip(slot);
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index edb37e9..324c8bf 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -37,7 +37,7 @@ static struct dw_mci_board pci_board_data = {
.fifo_depth = 32,
};
-static int __devinit dw_mci_pci_probe(struct pci_dev *pdev,
+static int dw_mci_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *entries)
{
struct dw_mci *host;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 4c1b1df..ff73a87 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -62,7 +62,7 @@ int dw_mci_pltfm_register(struct platform_device *pdev,
}
EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
-static int __devinit dw_mci_pltfm_probe(struct platform_device *pdev)
+static int dw_mci_pltfm_probe(struct
[PATCH v4 2/8] ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module
From: Mark A. Greer mgr...@animalcreek.com
The current OMAP2 SHAM support doesn't enable DMA
so add that support so it can use DMA just like OMAP3.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index bb314c5..4b4fd5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
@@ -405,5 +405,5 @@ struct omap_hwmod_ocp_if omap2xxx_l4_core__sham = {
.slave = omap2xxx_sham_hwmod,
.clk= sha_ick,
.addr = omap2xxx_sham_addrs,
- .user = OCP_USER_MPU,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index a041670..703b269 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -873,9 +873,15 @@ struct omap_hwmod_irq_info omap2_sham_mpu_irqs[] = {
{ .irq = -1 }
};
+struct omap_hwmod_dma_info omap2_sham_sdma_chs[] = {
+ { .name = rx, .dma_req = OMAP24XX_DMA_SHA1MD5_RX },
+ { .dma_req = -1 }
+};
+
struct omap_hwmod omap2xxx_sham_hwmod = {
.name = sham,
.mpu_irqs = omap2_sham_mpu_irqs,
+ .sdma_reqs = omap2_sham_sdma_chs,
.main_clk = l4_ck,
.prcm = {
.omap2 = {
--
1.7.12
--
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 v4 1/8] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Mark A. Greer mgr...@animalcreek.com
Convert the device data for the OMAP2 SHAM crypto IP from
explicit platform_data to hwmod.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clock2430_data.c | 1 +
arch/arm/mach-omap2/devices.c | 34
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 +
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 37 ++
arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 ++
7 files changed, 73 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 22404fe..4d52ec6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1993,6 +1993,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, sdrc_ick, sdrc_ick, CK_243X),
CLK(NULL, des_ick, des_ick, CK_243X),
CLK(omap-sham,ick, sha_ick, CK_243X),
+ CLK(NULL, sha_ick, sha_ick, CK_242X),
CLK(omap_rng, ick, rng_ick, CK_243X),
CLK(NULL, rng_ick, rng_ick, CK_243X),
CLK(omap-aes, ick, aes_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c72b5a7..9d95654 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -35,6 +35,8 @@
#include mux.h
#include control.h
#include devices.h
+#include cm2xxx_3xxx.h
+#include cm-regbits-24xx.h
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
@@ -454,24 +456,6 @@ static void omap_init_rng(void)
#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_sham_resources[] = {
- {
- .start = OMAP24XX_SEC_SHA1MD5_BASE,
- .end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = 51 + OMAP_INTC_START,
- .flags = IORESOURCE_IRQ,
- }
-};
-static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
-#else
-#define omap2_sham_resources NULL
-#define omap2_sham_resources_sz0
-#endif
-
#ifdef CONFIG_ARCH_OMAP3
static struct resource omap3_sham_resources[] = {
{
@@ -502,16 +486,24 @@ static struct platform_device sham_device = {
static void omap_init_sham(void)
{
if (cpu_is_omap24xx()) {
- sham_device.resource = omap2_sham_resources;
- sham_device.num_resources = omap2_sham_resources_sz;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+
+ oh = omap_hwmod_lookup(sham);
+ if (!oh)
+ return;
+
+ pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
+0, 0);
+ WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
} else if (cpu_is_omap34xx()) {
sham_device.resource = omap3_sham_resources;
sham_device.num_resources = omap3_sham_resources_sz;
+ platform_device_register(sham_device);
} else {
pr_err(%s: platform not supported\n, __func__);
return;
}
- platform_device_register(sham_device);
}
#else
static inline void omap_init_sham(void) { }
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b5db600..b102a53 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -603,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__mcbsp2,
omap2420_l4_core__msdi1,
omap2xxx_l4_core__rng,
+ omap2xxx_l4_core__sham,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
omap2420_l3__gpmc,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c455e41..b1ce7b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -963,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2xxx_l4_core__rng,
+ omap2xxx_l4_core__sham,
omap2430_l4_wkup__counter_32k,
omap2430_l3__gpmc,
NULL,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index 1a1287d..bb314c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++
[PATCH v4 4/8] ARM: OMAP2+: Remove unnecessary message when no SHA IP is present
From: Mark A. Greer mgr...@animalcreek.com
Remove the error message that prints when there is no SHA IP
present to make it consistent with all the other IPs.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/devices.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 015c259..7ecce5e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -457,20 +457,15 @@ static void omap_init_rng(void)
static void __init omap_init_sham(void)
{
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- struct omap_hwmod *oh;
- struct platform_device *pdev;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
- oh = omap_hwmod_lookup(sham);
- if (!oh)
- return;
+ oh = omap_hwmod_lookup(sham);
+ if (!oh)
+ return;
- pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
-0, 0);
- WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
- } else {
- pr_err(%s: platform not supported\n, __func__);
- }
+ pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
}
#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
--
1.7.12
--
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 v4 0/8] crypto: omap-sham updates
From: Mark A. Greer mgr...@animalcreek.com Changes since v3: - Added hwmod support for SIDLEMODE. This requires adding a specific omap_hwmod_sysc_fields structure since there are not generic ones that have the correct offsets. - Added patch to remove the cpu check from the omap-sham driver. This can likely be ignored since there is a patch that already does this in Tony's branch. I added it to make it easier for others to test while Tony's patch makes its way to the k.o. Changes since v2: - Reworked pm_runtime calls to match where original clk_* calls were so provide better PM (as per Kevin Hilman's comments). Changes since v1: - Removed the check of CM_IDLEST to see if the module exists and instead add the hwmod data for all omap2's and omap3 GP's. - Placed new sha_ick clk entries after the 'omap-sham' entry in the clockxxx_data.c files - Removed cpu_is_xxx() checks in arch/arm/mach-omap2/devices.c:omap_init_sham() - Rebased on the latest k.o. kernel This series updates the crypto omap-sham driver and supporting infrastructure. Notes: a) Based on 3587b1b (fanotify: fix FAN_Q_OVERFLOW case of fanotify_read()). b) Since these patches will likely go though the OMAP tree (and not through the crypto tree), it would be nice if the crypto guy(s) would ACK or NACK patches 5-7 which modify the drivers/crypto/omap-sham.c driver. c) These have only been tested on an omap2420 h4 and an am37x evm. If you have different hardware available and a few minutes, please test them. A quick and easy test is to enable tcrypt as a module (CONFIG_CRYPTO_TEST=m), boot, then run 'modprobe tcrypt sec=2 mode=403'. 'CONFIG_CRYPTO_SHA1' and 'CONFIG_CRYPTO_DEV_OMAP_SHAM' also have to be enabled. A quick 'grep omap-sham /proc/interrupts' will tell you if the omap-sham driver was really used. d) To test these patches, you will likely need... i) The patch included here: http://marc.info/?l=kernel-janitorsm=134910841909057w=2 ii) This patch from linux-omap/master: 27615a9 (ARM: OMAP: Trivial driver changes to remove include plat/cpu.h) iii) This patch from Paul Walmsley: http://www.spinics.net/lists/linux-omap/msg79436.html e) If you prefer, a version you can test is available at g...@github.com:mgreeraz/linux-mag.git wip/crypto/sham-v3+test f) There is a reduction in DMA performance after switching to dmaengine (see http://www.spinics.net/lists/linux-omap/msg79855.html) g) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (8): ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no SHA IP is present crypto: omap-sham: Remove cpu_is/omap_type check from driver crypto: omap-sham: Convert to use pm_runtime API crypto: omap-sham: Add code to use dmaengine API crypto: omap_sham: Remove usage of private DMA API arch/arm/mach-omap2/clock2430_data.c | 1 + arch/arm/mach-omap2/clock3xxx_data.c | 1 + arch/arm/mach-omap2/devices.c | 73 ++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 43 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 +++ arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + drivers/crypto/omap-sham.c | 202 +++-- 10 files changed, 251 insertions(+), 157 deletions(-) -- 1.7.12 -- 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 v4 5/8] crypto: omap-sham: Remove cpu_is/omap_type check from driver
From: Mark A. Greer mgr...@animalcreek.com
The omap-sham driver should not check the CPU class or the
type of OMAP device its on. The platform code should do
that instead.
CC: Paul Walmsley p...@pwsan.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a3fd6fc..f50387c 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -37,7 +37,6 @@
#include crypto/hash.h
#include crypto/internal/hash.h
-#include plat/cpu.h
#include plat/dma.h
#include mach/irqs.h
@@ -1289,13 +1288,6 @@ static int __init omap_sham_mod_init(void)
{
pr_info(loading %s driver\n, omap-sham);
- if (!cpu_class_is_omap2() ||
- (omap_type() != OMAP2_DEVICE_TYPE_SEC
- omap_type() != OMAP2_DEVICE_TYPE_EMU)) {
- pr_err(Unsupported cpu\n);
- return -ENODEV;
- }
-
return platform_driver_register(omap_sham_driver);
}
--
1.7.12
--
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 v4 7/8] crypto: omap-sham: Add code to use dmaengine API
From: Mark A. Greer mgr...@animalcreek.com
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 150 +++--
1 file changed, 145 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 42989ed..ba59bbe 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -13,6 +13,8 @@
* Some ideas are from old omap-sha1-md5.c driver.
*/
+#define OMAP_SHAM_DMA_PRIVATE
+
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -27,6 +29,10 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#ifndef OMAP_SHAM_DMA_PRIVATE
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#endif
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
@@ -37,8 +43,10 @@
#include crypto/hash.h
#include crypto/internal/hash.h
+#ifdef OMAP_SHAM_DMA_PRIVATE
#include plat/dma.h
#include mach/irqs.h
+#endif
#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
@@ -46,6 +54,8 @@
#define SHA1_MD5_BLOCK_SIZESHA1_BLOCK_SIZE
#define MD5_DIGEST_SIZE16
+#defineDST_MAXBURST16 /* Really element number
(en) */
+
#define SHA_REG_DIGCNT 0x14
#define SHA_REG_CTRL 0x18
@@ -109,6 +119,9 @@ struct omap_sham_reqctx {
/* walk state */
struct scatterlist *sg;
+#ifndef OMAP_SHAM_DMA_PRIVATE
+ struct scatterlist sgl;
+#endif
unsigned intoffset; /* offset in current sg */
unsigned inttotal; /* total request */
@@ -142,8 +155,12 @@ struct omap_sham_dev {
int irq;
spinlock_t lock;
int err;
+#ifdef OMAP_SHAM_DMA_PRIVATE
int dma;
int dma_lch;
+#else
+ struct dma_chan *dma_lch;
+#endif
struct tasklet_struct done_task;
unsigned long flags;
@@ -313,15 +330,32 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd,
const u8 *buf,
return -EINPROGRESS;
}
+#ifndef OMAP_SHAM_DMA_PRIVATE
+static void omap_sham_dma_callback(void *param)
+{
+ struct omap_sham_dev *dd = param;
+
+ set_bit(FLAGS_DMA_READY, dd-flags);
+ tasklet_schedule(dd-done_task);
+}
+#endif
+
static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
- size_t length, int final)
+ size_t length, int final, int is_sg)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
+#ifdef OMAP_SHAM_DMA_PRIVATE
int len32;
+#else
+ struct dma_async_tx_descriptor *tx;
+ struct dma_slave_config cfg;
+ int ret;
+#endif
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
+#ifdef OMAP_SHAM_DMA_PRIVATE
len32 = DIV_ROUND_UP(length, sizeof(u32));
omap_set_dma_transfer_params(dd-dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
@@ -331,6 +365,48 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
omap_set_dma_src_params(dd-dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
dma_addr, 0, 0);
+#else
+ memset(cfg, 0, sizeof(cfg));
+
+ cfg.dst_addr = dd-phys_base + SHA_REG_DIN(0);
+ cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.dst_maxburst = DST_MAXBURST;
+
+ ret = dmaengine_slave_config(dd-dma_lch, cfg);
+ if (ret) {
+ pr_err(omap-sham: can't configure dmaengine slave: %d\n, ret);
+ return ret;
+ }
+
+ if (is_sg) {
+ /*
+* The SG entry passed in may not have the 'length' member
+* set correctly so use a local SG entry (sgl) with the
+* proper value for 'length' instead. If this is not done,
+* the dmaengine may try to DMA the incorrect amount of data.
+*/
+ sg_init_table(ctx-sgl, 1);
+ ctx-sgl.page_link = ctx-sg-page_link;
+ ctx-sgl.offset = ctx-sg-offset;
+ sg_dma_len(ctx-sgl) = length;
+ sg_dma_address(ctx-sgl) = sg_dma_address(ctx-sg);
+
+ tx = dmaengine_prep_slave_sg(dd-dma_lch, ctx-sgl, 1,
+ DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ } else {
+ tx = dmaengine_prep_slave_single(dd-dma_lch,
[PATCH v4 6/8] crypto: omap-sham: Convert to use pm_runtime API
From: Mark A. Greer mgr...@animalcreek.com
Convert the omap-sham crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Paul Walmsley p...@pwsan.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index f50387c..42989ed 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -22,12 +22,12 @@
#include linux/errno.h
#include linux/interrupt.h
#include linux/kernel.h
-#include linux/clk.h
#include linux/irq.h
#include linux/io.h
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
#include linux/cryptohash.h
@@ -140,7 +140,6 @@ struct omap_sham_dev {
struct device *dev;
void __iomem*io_base;
int irq;
- struct clk *iclk;
spinlock_t lock;
int err;
int dma;
@@ -237,7 +236,7 @@ static void omap_sham_copy_ready_hash(struct ahash_request
*req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- clk_enable(dd-iclk);
+ pm_runtime_get_sync(dd-dev);
if (!test_bit(FLAGS_INIT, dd-flags)) {
omap_sham_write_mask(dd, SHA_REG_MASK,
@@ -652,7 +651,8 @@ static void omap_sham_finish_req(struct ahash_request *req,
int err)
/* atomic operation is not needed here */
dd-flags = ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(dd-dev);
if (req-base.complete)
req-base.complete(req-base, err);
@@ -1197,14 +1197,6 @@ static int __devinit omap_sham_probe(struct
platform_device *pdev)
if (err)
goto dma_err;
- /* Initializing the clock */
- dd-iclk = clk_get(dev, ick);
- if (IS_ERR(dd-iclk)) {
- dev_err(dev, clock intialization failed.\n);
- err = PTR_ERR(dd-iclk);
- goto clk_err;
- }
-
dd-io_base = ioremap(dd-phys_base, SZ_4K);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
@@ -1212,11 +1204,14 @@ static int __devinit omap_sham_probe(struct
platform_device *pdev)
goto io_err;
}
- clk_enable(dd-iclk);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
dev_info(dev, hw accel on OMAP rev %u.%u\n,
(omap_sham_read(dd, SHA_REG_REV) SHA_REG_REV_MAJOR) 4,
omap_sham_read(dd, SHA_REG_REV) SHA_REG_REV_MINOR);
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(pdev-dev);
spin_lock(sham.lock);
list_add_tail(dd-list, sham.dev_list);
@@ -1234,9 +1229,8 @@ err_algs:
for (j = 0; j i; j++)
crypto_unregister_ahash(algs[j]);
iounmap(dd-io_base);
+ pm_runtime_disable(dev);
io_err:
- clk_put(dd-iclk);
-clk_err:
omap_sham_dma_cleanup(dd);
dma_err:
if (dd-irq = 0)
@@ -1265,7 +1259,7 @@ static int __devexit omap_sham_remove(struct
platform_device *pdev)
crypto_unregister_ahash(algs[i]);
tasklet_kill(dd-done_task);
iounmap(dd-io_base);
- clk_put(dd-iclk);
+ pm_runtime_disable(pdev-dev);
omap_sham_dma_cleanup(dd);
if (dd-irq = 0)
free_irq(dd-irq, dd);
--
1.7.12
--
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 v4 8/8] crypto: omap_sham: Remove usage of private DMA API
From: Mark A. Greer mgr...@animalcreek.com
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-sham.c | 116 -
1 file changed, 116 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index ba59bbe..14db042 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -13,8 +13,6 @@
* Some ideas are from old omap-sha1-md5.c driver.
*/
-#define OMAP_SHAM_DMA_PRIVATE
-
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -29,10 +27,8 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
-#ifndef OMAP_SHAM_DMA_PRIVATE
#include linux/dmaengine.h
#include linux/omap-dma.h
-#endif
#include linux/pm_runtime.h
#include linux/delay.h
#include linux/crypto.h
@@ -43,11 +39,6 @@
#include crypto/hash.h
#include crypto/internal/hash.h
-#ifdef OMAP_SHAM_DMA_PRIVATE
-#include plat/dma.h
-#include mach/irqs.h
-#endif
-
#define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
#define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
@@ -119,9 +110,7 @@ struct omap_sham_reqctx {
/* walk state */
struct scatterlist *sg;
-#ifndef OMAP_SHAM_DMA_PRIVATE
struct scatterlist sgl;
-#endif
unsigned intoffset; /* offset in current sg */
unsigned inttotal; /* total request */
@@ -155,12 +144,7 @@ struct omap_sham_dev {
int irq;
spinlock_t lock;
int err;
-#ifdef OMAP_SHAM_DMA_PRIVATE
- int dma;
- int dma_lch;
-#else
struct dma_chan *dma_lch;
-#endif
struct tasklet_struct done_task;
unsigned long flags;
@@ -330,7 +314,6 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd,
const u8 *buf,
return -EINPROGRESS;
}
-#ifndef OMAP_SHAM_DMA_PRIVATE
static void omap_sham_dma_callback(void *param)
{
struct omap_sham_dev *dd = param;
@@ -338,34 +321,18 @@ static void omap_sham_dma_callback(void *param)
set_bit(FLAGS_DMA_READY, dd-flags);
tasklet_schedule(dd-done_task);
}
-#endif
static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
size_t length, int final, int is_sg)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- int len32;
-#else
struct dma_async_tx_descriptor *tx;
struct dma_slave_config cfg;
int ret;
-#endif
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- len32 = DIV_ROUND_UP(length, sizeof(u32));
-
- omap_set_dma_transfer_params(dd-dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
- 1, OMAP_DMA_SYNC_PACKET, dd-dma,
- OMAP_DMA_DST_SYNC_PREFETCH);
-
- omap_set_dma_src_params(dd-dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
- dma_addr, 0, 0);
-
-#else
memset(cfg, 0, sizeof(cfg));
cfg.dst_addr = dd-phys_base + SHA_REG_DIN(0);
@@ -405,7 +372,6 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
tx-callback = omap_sham_dma_callback;
tx-callback_param = dd;
-#endif
omap_sham_write_ctrl(dd, length, final, 1);
@@ -416,12 +382,8 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd,
dma_addr_t dma_addr,
set_bit(FLAGS_DMA_ACTIVE, dd-flags);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- omap_start_dma(dd-dma_lch);
-#else
dmaengine_submit(tx);
dma_async_issue_pending(dd-dma_lch);
-#endif
return -EINPROGRESS;
}
@@ -527,7 +489,6 @@ static int omap_sham_update_dma_start(struct omap_sham_dev
*dd)
if (ctx-bufcnt || ctx-offset)
return omap_sham_update_dma_slow(dd);
-#ifndef OMAP_SHAM_DMA_PRIVATE
/*
* Don't use the sg interface when the transfer size is less
* than the number of elements in a DMA frame. Otherwise,
@@ -536,7 +497,6 @@ static int omap_sham_update_dma_start(struct omap_sham_dev
*dd)
*/
if (ctx-total (DST_MAXBURST * sizeof(u32)))
return omap_sham_update_dma_slow(dd);
-#endif
dev_dbg(dd-dev, fast: digcnt: %d, bufcnt: %u, total: %u\n,
ctx-digcnt, ctx-bufcnt, ctx-total);
@@ -598,11 +558,7 @@ static int omap_sham_update_dma_stop(struct omap_sham_dev
*dd)
{
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
-#ifdef OMAP_SHAM_DMA_PRIVATE
- omap_stop_dma(dd-dma_lch);
-#else
[PATCH v4 3/8] ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Mark A. Greer mgr...@animalcreek.com
Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 1 +
arch/arm/mach-omap2/devices.c | 42 ++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 ++
3 files changed, 70 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 1f42c9d..6f14d9b 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3342,6 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
CLK(omap-sham,ick, sha12_ick, CK_34XX | CK_36XX),
+ CLK(NULL, sha12_ick,sha12_ick, CK_34XX | CK_36XX),
CLK(NULL, des2_ick, des2_ick, CK_34XX | CK_36XX),
CLK(omap_hsmmc.1, ick, mmchs2_ick,CK_3XXX),
CLK(omap_hsmmc.0, ick, mmchs1_ick,CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9d95654..015c259 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -37,6 +37,7 @@
#include devices.h
#include cm2xxx_3xxx.h
#include cm-regbits-24xx.h
+#include cm-regbits-34xx.h
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
@@ -454,38 +455,9 @@ static void omap_init_rng(void)
WARN(IS_ERR(pdev), Can't build omap_device for omap_rng\n);
}
-#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_sham_resources[] = {
- {
- .start = OMAP34XX_SEC_SHA1MD5_BASE,
- .end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = 49 + OMAP_INTC_START,
- .flags = IORESOURCE_IRQ,
- },
- {
- .start = OMAP34XX_DMA_SHA1MD5_RX,
- .flags = IORESOURCE_DMA,
- }
-};
-static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
-#else
-#define omap3_sham_resources NULL
-#define omap3_sham_resources_sz0
-#endif
-
-static struct platform_device sham_device = {
- .name = omap-sham,
- .id = -1,
-};
-
-static void omap_init_sham(void)
+static void __init omap_init_sham(void)
{
- if (cpu_is_omap24xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -496,18 +468,10 @@ static void omap_init_sham(void)
pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
0, 0);
WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
- } else if (cpu_is_omap34xx()) {
- sham_device.resource = omap3_sham_resources;
- sham_device.num_resources = omap3_sham_resources_sz;
- platform_device_register(sham_device);
} else {
pr_err(%s: platform not supported\n, __func__);
- return;
}
}
-#else
-static inline void omap_init_sham(void) { }
-#endif
#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..a65972b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3543,6 +3543,71 @@ static struct omap_hwmod_ocp_if omap3xxx_l3_main__gpmc =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_core - SHAM2 (SHA1/MD5) (similar to omap24xx) */
+static struct omap_hwmod_sysc_fields omap3_sham_sysc_fields = {
+ .sidle_shift= 4,
+ .srst_shift = 1,
+ .autoidle_shift = 0,
+};
+
+static struct omap_hwmod_class_sysconfig omap3_sham_sysc = {
+ .rev_offs = 0x5c,
+ .sysc_offs = 0x60,
+ .syss_offs = 0x64,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .sysc_fields= omap3_sham_sysc_fields,
+};
+
+static struct omap_hwmod_class omap3xxx_sham_class = {
+ .name = sham,
+ .sysc = omap3_sham_sysc,
+};
+
+struct omap_hwmod_irq_info omap3_sham_mpu_irqs[] = {
+ { .irq = 49 + OMAP_INTC_START, },
+ { .irq = -1 }
+};
+
+struct omap_hwmod_dma_info omap3_sham_sdma_reqs[] = {
+ { .name = rx, .dma_req = OMAP34XX_DMA_SHA1MD5_RX, },
+ { .dma_req = -1 }
+};
+
+struct omap_hwmod omap3xxx_sham_hwmod = {
+ .name =
[PATCH 0/7] crypto: omap-aes updates
From: Mark A. Greer mgr...@animalcreek.com This series updates the crypto omap-aes driver and supporting infrastructure. Notes: a) Based on omap-sham patches recently submitted, XXX b) Since these patches will likely go though the OMAP tree (and not through the crypto tree), it would be nice if the crypto guy(s) would ACK or NACK patches 4-7 which modify the drivers/crypto/omap-sham.c driver. c) These have only been tested on an omap2420 h4 and an am37x evm. d) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (7): ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no AES IP is present crypto: omap-aes: Remove cpu_is/omap_type check from driver crypto: omap-aes: Convert to use pm_runtime API crypto: omap-aes: Add code to use dmaengine API crypto: omap-aes: Remove usage of private DMA API arch/arm/mach-omap2/clock2430_data.c | 1 + arch/arm/mach-omap2/clock3xxx_data.c | 1 + arch/arm/mach-omap2/devices.c | 75 +--- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 38 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 +++ arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + drivers/crypto/omap-aes.c | 202 - 10 files changed, 251 insertions(+), 150 deletions(-) -- 1.7.12 -- 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/7] ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod
From: Mark A. Greer mgr...@animalcreek.com
Convert the device data for the OMAP2 AES crypto IP from
explicit platform_data to hwmod.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clock2430_data.c | 1 +
arch/arm/mach-omap2/devices.c | 36 +++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 +
.../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 38 ++
arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 ++
7 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 4d52ec6..2259356 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1997,6 +1997,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_243X),
CLK(NULL, rng_ick, rng_ick, CK_243X),
CLK(omap-aes, ick, aes_ick, CK_243X),
+ CLK(NULL, aes_ick, aes_ick, CK_243X),
CLK(NULL, pka_ick, pka_ick, CK_243X),
CLK(NULL, usb_fck, usb_fck, CK_243X),
CLK(musb-omap2430,ick, usbhs_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7ecce5e..58831e5 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -470,28 +470,6 @@ static void __init omap_init_sham(void)
#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_aes_resources[] = {
- {
- .start = OMAP24XX_SEC_AES_BASE,
- .end= OMAP24XX_SEC_AES_BASE + 0x4C,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP24XX_DMA_AES_TX,
- .flags = IORESOURCE_DMA,
- },
- {
- .start = OMAP24XX_DMA_AES_RX,
- .flags = IORESOURCE_DMA,
- }
-};
-static int omap2_aes_resources_sz = ARRAY_SIZE(omap2_aes_resources);
-#else
-#define omap2_aes_resourcesNULL
-#define omap2_aes_resources_sz 0
-#endif
-
#ifdef CONFIG_ARCH_OMAP3
static struct resource omap3_aes_resources[] = {
{
@@ -522,16 +500,24 @@ static struct platform_device aes_device = {
static void omap_init_aes(void)
{
if (cpu_is_omap24xx()) {
- aes_device.resource = omap2_aes_resources;
- aes_device.num_resources = omap2_aes_resources_sz;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+
+ oh = omap_hwmod_lookup(aes);
+ if (!oh)
+ return;
+
+ pdev = omap_device_build(omap-aes, -1, oh, NULL, 0, NULL,
+0, 0);
+ WARN(IS_ERR(pdev), Can't build omap_device for omap-aes\n);
} else if (cpu_is_omap34xx()) {
aes_device.resource = omap3_aes_resources;
aes_device.num_resources = omap3_aes_resources_sz;
+ platform_device_register(aes_device);
} else {
pr_err(%s: platform not supported\n, __func__);
return;
}
- platform_device_register(aes_device);
}
#else
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b102a53..613f862 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -604,6 +604,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__msdi1,
omap2xxx_l4_core__rng,
omap2xxx_l4_core__sham,
+ omap2xxx_l4_core__aes,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
omap2420_l3__gpmc,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index b1ce7b0..0db06a5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -964,6 +964,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__hdq1w,
omap2xxx_l4_core__rng,
omap2xxx_l4_core__sham,
+ omap2xxx_l4_core__aes,
omap2430_l4_wkup__counter_32k,
omap2430_l3__gpmc,
NULL,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index 4b4fd5f..96ba272 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
@@ -147,6 +147,15 @@ struct omap_hwmod_addr_space omap2xxx_sham_addrs[] = {
{ }
};
[PATCH 4/7] crypto: omap-aes: Remove cpu_is/omap_type check from driver
From: Mark A. Greer mgr...@animalcreek.com
The omap-aes driver should not check the CPU class or the
type of OMAP device its on. The platform code should do
that instead.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 093a8af..628c3cc 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -941,11 +941,6 @@ static int __init omap_aes_mod_init(void)
{
pr_info(loading %s driver\n, omap-aes);
- if (!cpu_class_is_omap2() || omap_type() != OMAP2_DEVICE_TYPE_SEC) {
- pr_err(Unsupported cpu\n);
- return -ENODEV;
- }
-
return platform_driver_register(omap_aes_driver);
}
--
1.7.12
--
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 5/7] crypto: omap-aes: Convert to use pm_runtime API
From: Mark A. Greer mgr...@animalcreek.com
Convert the omap-aes crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Paul Walmsley p...@pwsan.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 628c3cc..75b842d 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -19,10 +19,10 @@
#include linux/init.h
#include linux/errno.h
#include linux/kernel.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#include linux/pm_runtime.h
#include linux/io.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -97,7 +97,6 @@ struct omap_aes_dev {
struct list_headlist;
unsigned long phys_base;
void __iomem*io_base;
- struct clk *iclk;
struct omap_aes_ctx *ctx;
struct device *dev;
unsigned long flags;
@@ -181,7 +180,7 @@ static int omap_aes_hw_init(struct omap_aes_dev *dd)
* It may be long delays between requests.
* Device might go to off mode to save power.
*/
- clk_enable(dd-iclk);
+ pm_runtime_get_sync(dd-dev);
if (!(dd-flags FLAGS_INIT)) {
/* is it necessary to reset before every operation? */
@@ -546,7 +545,7 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd,
int err)
pr_debug(err: %d\n, err);
- clk_disable(dd-iclk);
+ pm_runtime_put_sync(dd-dev);
dd-flags = ~FLAGS_BUSY;
req-base.complete(req-base, err);
@@ -841,26 +840,21 @@ static int omap_aes_probe(struct platform_device *pdev)
else
dd-dma_in = res-start;
- /* Initializing the clock */
- dd-iclk = clk_get(dev, ick);
- if (IS_ERR(dd-iclk)) {
- dev_err(dev, clock intialization failed.\n);
- err = PTR_ERR(dd-iclk);
- goto err_res;
- }
-
dd-io_base = ioremap(dd-phys_base, SZ_4K);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
err = -ENOMEM;
- goto err_io;
+ goto err_res;
}
- clk_enable(dd-iclk);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
reg = omap_aes_read(dd, AES_REG_REV);
dev_info(dev, OMAP AES hw accel rev: %u.%u\n,
(reg AES_REG_REV_MAJOR) 4, reg AES_REG_REV_MINOR);
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(dev);
tasklet_init(dd-done_task, omap_aes_done_task, (unsigned long)dd);
tasklet_init(dd-queue_task, omap_aes_queue_task, (unsigned long)dd);
@@ -892,8 +886,7 @@ err_dma:
tasklet_kill(dd-done_task);
tasklet_kill(dd-queue_task);
iounmap(dd-io_base);
-err_io:
- clk_put(dd-iclk);
+ pm_runtime_disable(dev);
err_res:
kfree(dd);
dd = NULL;
@@ -921,7 +914,7 @@ static int omap_aes_remove(struct platform_device *pdev)
tasklet_kill(dd-queue_task);
omap_aes_dma_cleanup(dd);
iounmap(dd-io_base);
- clk_put(dd-iclk);
+ pm_runtime_disable(dd-dev);
kfree(dd);
dd = NULL;
--
1.7.12
--
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/7] ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod
From: Mark A. Greer mgr...@animalcreek.com
Convert the device data for the OMAP3 AES crypto IP
from explicit platform_data to hwmod.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 1 +
arch/arm/mach-omap2/devices.c | 42 +---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 ++
3 files changed, 65 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 6f14d9b..ceb4153 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3341,6 +3341,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, mmchs3_ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
+ CLK(NULL, aes2_ick, aes2_ick, CK_34XX | CK_36XX),
CLK(omap-sham,ick, sha12_ick, CK_34XX | CK_36XX),
CLK(NULL, sha12_ick,sha12_ick, CK_34XX | CK_36XX),
CLK(NULL, des2_ick, des2_ick, CK_34XX | CK_36XX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 58831e5..6a9152a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -468,38 +468,9 @@ static void __init omap_init_sham(void)
WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
}
-#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_aes_resources[] = {
- {
- .start = OMAP34XX_SEC_AES_BASE,
- .end= OMAP34XX_SEC_AES_BASE + 0x4C,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP34XX_DMA_AES2_TX,
- .flags = IORESOURCE_DMA,
- },
- {
- .start = OMAP34XX_DMA_AES2_RX,
- .flags = IORESOURCE_DMA,
- }
-};
-static int omap3_aes_resources_sz = ARRAY_SIZE(omap3_aes_resources);
-#else
-#define omap3_aes_resourcesNULL
-#define omap3_aes_resources_sz 0
-#endif
-
-static struct platform_device aes_device = {
- .name = omap-aes,
- .id = -1,
-};
-
-static void omap_init_aes(void)
+static void __init omap_init_aes(void)
{
- if (cpu_is_omap24xx()) {
+ if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -510,20 +481,11 @@ static void omap_init_aes(void)
pdev = omap_device_build(omap-aes, -1, oh, NULL, 0, NULL,
0, 0);
WARN(IS_ERR(pdev), Can't build omap_device for omap-aes\n);
- } else if (cpu_is_omap34xx()) {
- aes_device.resource = omap3_aes_resources;
- aes_device.num_resources = omap3_aes_resources_sz;
- platform_device_register(aes_device);
} else {
pr_err(%s: platform not supported\n, __func__);
- return;
}
}
-#else
-static inline void omap_init_aes(void) { }
-#endif
-
/*-*/
#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index a65972b..3b82304 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3608,6 +3608,67 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__sham =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_core - AES */
+static struct omap_hwmod_sysc_fields omap3xxx_aes_sysc_fields = {
+ .sidle_shift= 6,
+ .srst_shift = 1,
+ .autoidle_shift = 0,
+};
+
+static struct omap_hwmod_class_sysconfig omap3_aes_sysc = {
+ .rev_offs = 0x44,
+ .sysc_offs = 0x48,
+ .syss_offs = 0x4c,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap3xxx_aes_sysc_fields,
+};
+
+static struct omap_hwmod_class omap3xxx_aes_class = {
+ .name = aes,
+ .sysc = omap3_aes_sysc,
+};
+
+struct omap_hwmod_dma_info omap3_aes_sdma_reqs[] = {
+ { .name = tx, .dma_req = OMAP34XX_DMA_AES2_TX, },
+ { .name = rx, .dma_req = OMAP34XX_DMA_AES2_RX, },
+ { .dma_req = -1 }
+};
+
+struct omap_hwmod omap3xxx_aes_hwmod = {
+ .name = aes,
+ .sdma_reqs = omap3_aes_sdma_reqs,
+ .main_clk = aes2_ick,
+ .prcm = {
+ .omap2 = {
+
[PATCH 3/7] ARM: OMAP2+: Remove unnecessary message when no AES IP is present
From: Mark A. Greer mgr...@animalcreek.com
Remove the error message that prints when there is no AES IP
present to make it consistent with all the other IPs.
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/devices.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 6a9152a..03c1b3a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -470,20 +470,15 @@ static void __init omap_init_sham(void)
static void __init omap_init_aes(void)
{
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- struct omap_hwmod *oh;
- struct platform_device *pdev;
-
- oh = omap_hwmod_lookup(aes);
- if (!oh)
- return;
-
- pdev = omap_device_build(omap-aes, -1, oh, NULL, 0, NULL,
-0, 0);
- WARN(IS_ERR(pdev), Can't build omap_device for omap-aes\n);
- } else {
- pr_err(%s: platform not supported\n, __func__);
- }
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+
+ oh = omap_hwmod_lookup(aes);
+ if (!oh)
+ return;
+
+ pdev = omap_device_build(omap-aes, -1, oh, NULL, 0, NULL, 0, 0);
+ WARN(IS_ERR(pdev), Can't build omap_device for omap-aes\n);
}
/*-*/
--
1.7.12
--
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 7/7] crypto: omap-aes: Remove usage of private DMA API
From: Mark A. Greer mgr...@animalcreek.com
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 140 --
1 file changed, 140 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index c0a84b2..1fbfd2e 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -12,8 +12,6 @@
*
*/
-#define OMAP_AES_DMA_PRIVATE
-
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -24,10 +22,8 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
-#ifndef OMAP_AES_DMA_PRIVATE
#include linux/dmaengine.h
#include linux/omap-dma.h
-#endif
#include linux/pm_runtime.h
#include linux/io.h
#include linux/crypto.h
@@ -35,11 +31,6 @@
#include crypto/scatterwalk.h
#include crypto/aes.h
-#ifdef OMAP_AES_DMA_PRIVATE
-#include plat/cpu.h
-#include plat/dma.h
-#endif
-
#define DST_MAXBURST 4 /* Really element number (en) */
/* OMAP TRM gives bitfields as start:end, where start is the higher bit
@@ -121,33 +112,21 @@ struct omap_aes_dev {
struct ablkcipher_request *req;
size_t total;
struct scatterlist *in_sg;
-#ifndef OMAP_AES_DMA_PRIVATE
struct scatterlist in_sgl;
-#endif
size_t in_offset;
struct scatterlist *out_sg;
-#ifndef OMAP_AES_DMA_PRIVATE
struct scatterlist out_sgl;
-#endif
size_t out_offset;
size_t buflen;
void*buf_in;
size_t dma_size;
int dma_in;
-#ifdef OMAP_AES_DMA_PRIVATE
- int dma_lch_in;
-#else
struct dma_chan *dma_lch_in;
-#endif
dma_addr_t dma_addr_in;
void*buf_out;
int dma_out;
-#ifdef OMAP_AES_DMA_PRIVATE
- int dma_lch_out;
-#else
struct dma_chan *dma_lch_out;
-#endif
dma_addr_t dma_addr_out;
};
@@ -239,17 +218,10 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
return err;
val = 0;
-#ifdef OMAP_AES_DMA_PRIVATE
- if (dd-dma_lch_out = 0)
- val |= AES_REG_MASK_DMA_OUT_EN;
- if (dd-dma_lch_in = 0)
- val |= AES_REG_MASK_DMA_IN_EN;
-#else
if (dd-dma_lch_out != NULL)
val |= AES_REG_MASK_DMA_OUT_EN;
if (dd-dma_lch_in != NULL)
val |= AES_REG_MASK_DMA_IN_EN;
-#endif
mask = AES_REG_MASK_DMA_IN_EN | AES_REG_MASK_DMA_OUT_EN;
@@ -277,22 +249,6 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
omap_aes_write_mask(dd, AES_REG_CTRL, val, mask);
-#ifdef OMAP_AES_DMA_PRIVATE
- /* IN */
- omap_set_dma_dest_params(dd-dma_lch_in, 0, OMAP_DMA_AMODE_CONSTANT,
-dd-phys_base + AES_REG_DATA, 0, 4);
-
- omap_set_dma_dest_burst_mode(dd-dma_lch_in, OMAP_DMA_DATA_BURST_4);
- omap_set_dma_src_burst_mode(dd-dma_lch_in, OMAP_DMA_DATA_BURST_4);
-
- /* OUT */
- omap_set_dma_src_params(dd-dma_lch_out, 0, OMAP_DMA_AMODE_CONSTANT,
- dd-phys_base + AES_REG_DATA, 0, 4);
-
- omap_set_dma_src_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
- omap_set_dma_dest_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
-#endif
-
return 0;
}
@@ -317,23 +273,6 @@ static struct omap_aes_dev *omap_aes_find_dev(struct
omap_aes_ctx *ctx)
return dd;
}
-#ifdef OMAP_AES_DMA_PRIVATE
-static void omap_aes_dma_callback(int lch, u16 ch_status, void *data)
-{
- struct omap_aes_dev *dd = data;
-
- if (ch_status != OMAP_DMA_BLOCK_IRQ) {
- pr_err(omap-aes DMA error status: 0x%hx\n, ch_status);
- dd-err = -EIO;
- dd-flags = ~FLAGS_INIT; /* request to re-initialize */
- } else if (lch == dd-dma_lch_in) {
- return;
- }
-
- /* dma_lch_out - completed */
- tasklet_schedule(dd-done_task);
-}
-#else
static void omap_aes_dma_out_callback(void *data)
{
struct omap_aes_dev *dd = data;
@@ -341,22 +280,14 @@ static void omap_aes_dma_out_callback(void *data)
/* dma_lch_out - completed */
tasklet_schedule(dd-done_task);
}
-#endif
static int omap_aes_dma_init(struct omap_aes_dev *dd)
{
int err = -ENOMEM;
-#ifndef OMAP_AES_DMA_PRIVATE
dma_cap_mask_t mask;
-#endif
-#ifdef OMAP_AES_DMA_PRIVATE
- dd-dma_lch_out = -1;
- dd-dma_lch_in = -1;
-#else
dd-dma_lch_out = NULL;
dd-dma_lch_in = NULL;
[PATCH 6/7] crypto: omap-aes: Add code to use dmaengine API
From: Mark A. Greer mgr...@animalcreek.com
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_AES_DMA_PRIVATE'.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 186 ++
1 file changed, 186 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 75b842d..c0a84b2 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -12,6 +12,8 @@
*
*/
+#define OMAP_AES_DMA_PRIVATE
+
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -22,6 +24,10 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#ifndef OMAP_AES_DMA_PRIVATE
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#endif
#include linux/pm_runtime.h
#include linux/io.h
#include linux/crypto.h
@@ -29,8 +35,12 @@
#include crypto/scatterwalk.h
#include crypto/aes.h
+#ifdef OMAP_AES_DMA_PRIVATE
#include plat/cpu.h
#include plat/dma.h
+#endif
+
+#define DST_MAXBURST 4 /* Really element number (en) */
/* OMAP TRM gives bitfields as start:end, where start is the higher bit
number. For example 7:0 */
@@ -111,19 +121,33 @@ struct omap_aes_dev {
struct ablkcipher_request *req;
size_t total;
struct scatterlist *in_sg;
+#ifndef OMAP_AES_DMA_PRIVATE
+ struct scatterlist in_sgl;
+#endif
size_t in_offset;
struct scatterlist *out_sg;
+#ifndef OMAP_AES_DMA_PRIVATE
+ struct scatterlist out_sgl;
+#endif
size_t out_offset;
size_t buflen;
void*buf_in;
size_t dma_size;
int dma_in;
+#ifdef OMAP_AES_DMA_PRIVATE
int dma_lch_in;
+#else
+ struct dma_chan *dma_lch_in;
+#endif
dma_addr_t dma_addr_in;
void*buf_out;
int dma_out;
+#ifdef OMAP_AES_DMA_PRIVATE
int dma_lch_out;
+#else
+ struct dma_chan *dma_lch_out;
+#endif
dma_addr_t dma_addr_out;
};
@@ -215,10 +239,17 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
return err;
val = 0;
+#ifdef OMAP_AES_DMA_PRIVATE
if (dd-dma_lch_out = 0)
val |= AES_REG_MASK_DMA_OUT_EN;
if (dd-dma_lch_in = 0)
val |= AES_REG_MASK_DMA_IN_EN;
+#else
+ if (dd-dma_lch_out != NULL)
+ val |= AES_REG_MASK_DMA_OUT_EN;
+ if (dd-dma_lch_in != NULL)
+ val |= AES_REG_MASK_DMA_IN_EN;
+#endif
mask = AES_REG_MASK_DMA_IN_EN | AES_REG_MASK_DMA_OUT_EN;
@@ -246,6 +277,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
omap_aes_write_mask(dd, AES_REG_CTRL, val, mask);
+#ifdef OMAP_AES_DMA_PRIVATE
/* IN */
omap_set_dma_dest_params(dd-dma_lch_in, 0, OMAP_DMA_AMODE_CONSTANT,
dd-phys_base + AES_REG_DATA, 0, 4);
@@ -259,6 +291,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
omap_set_dma_src_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
omap_set_dma_dest_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
+#endif
return 0;
}
@@ -284,6 +317,7 @@ static struct omap_aes_dev *omap_aes_find_dev(struct
omap_aes_ctx *ctx)
return dd;
}
+#ifdef OMAP_AES_DMA_PRIVATE
static void omap_aes_dma_callback(int lch, u16 ch_status, void *data)
{
struct omap_aes_dev *dd = data;
@@ -299,13 +333,30 @@ static void omap_aes_dma_callback(int lch, u16 ch_status,
void *data)
/* dma_lch_out - completed */
tasklet_schedule(dd-done_task);
}
+#else
+static void omap_aes_dma_out_callback(void *data)
+{
+ struct omap_aes_dev *dd = data;
+
+ /* dma_lch_out - completed */
+ tasklet_schedule(dd-done_task);
+}
+#endif
static int omap_aes_dma_init(struct omap_aes_dev *dd)
{
int err = -ENOMEM;
+#ifndef OMAP_AES_DMA_PRIVATE
+ dma_cap_mask_t mask;
+#endif
+#ifdef OMAP_AES_DMA_PRIVATE
dd-dma_lch_out = -1;
dd-dma_lch_in = -1;
+#else
+ dd-dma_lch_out = NULL;
+ dd-dma_lch_in = NULL;
+#endif
dd-buf_in = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
dd-buf_out = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
@@ -334,6 +385,7 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
goto err_map_out;
}
+#ifdef OMAP_AES_DMA_PRIVATE
err = omap_request_dma(dd-dma_in, omap-aes-rx,
Re: [PATCH 119/493] usb: remove use of __devexit_p
Hi, On Mon, Nov 19, 2012 at 01:21:08PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Peter Korsgaard jac...@sunsite.dk Cc: Alexander Shishkin alexander.shish...@linux.intel.com Cc: Felipe Balbi ba...@ti.com Cc: Li Yang le...@freescale.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Wan ZongShun mcuos@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org --- drivers/usb/c67x00/c67x00-drv.c | 2 +- drivers/usb/chipidea/ci13xxx_imx.c | 2 +- drivers/usb/chipidea/ci13xxx_msm.c | 2 +- drivers/usb/chipidea/ci13xxx_pci.c | 2 +- drivers/usb/chipidea/core.c | 2 +- drivers/usb/chipidea/usbmisc_imx6q.c | 2 +- drivers/usb/dwc3/core.c | 2 +- drivers/usb/dwc3/dwc3-exynos.c | 2 +- drivers/usb/dwc3/dwc3-omap.c | 2 +- drivers/usb/dwc3/dwc3-pci.c | 2 +- drivers/usb/gadget/bcm63xx_udc.c | 2 +- drivers/usb/gadget/fsl_qe_udc.c | 2 +- drivers/usb/gadget/hid.c | 2 +- drivers/usb/gadget/lpc32xx_udc.c | 2 +- drivers/usb/gadget/net2272.c | 4 ++-- drivers/usb/gadget/omap_udc.c| 2 +- drivers/usb/gadget/s3c-hsotg.c | 2 +- drivers/usb/host/bcma-hcd.c | 2 +- drivers/usb/host/ehci-atmel.c| 2 +- drivers/usb/host/ehci-msm.c | 2 +- drivers/usb/host/ehci-platform.c | 2 +- drivers/usb/host/ehci-s5p.c | 2 +- drivers/usb/host/ehci-w90x900.c | 2 +- drivers/usb/host/fhci-hcd.c | 2 +- drivers/usb/host/fsl-mph-dr-of.c | 2 +- drivers/usb/host/isp1362-hcd.c | 2 +- drivers/usb/host/isp1760-if.c| 2 +- drivers/usb/host/ohci-at91.c | 2 +- drivers/usb/host/ohci-exynos.c | 2 +- drivers/usb/host/ohci-jz4740.c | 2 +- drivers/usb/host/ohci-omap3.c| 2 +- drivers/usb/host/ohci-platform.c | 2 +- drivers/usb/host/ohci-s3c2410.c | 2 +- drivers/usb/host/ohci-tmio.c | 2 +- drivers/usb/host/r8a66597-hcd.c | 2 +- drivers/usb/host/sl811-hcd.c | 2 +- drivers/usb/host/ssb-hcd.c | 2 +- drivers/usb/host/u132-hcd.c | 2 +- drivers/usb/musb/am35x.c | 2 +- drivers/usb/musb/da8xx.c | 2 +- drivers/usb/musb/davinci.c | 2 +- drivers/usb/musb/musb_core.c | 2 +- drivers/usb/musb/musb_dsps.c | 2 +- drivers/usb/musb/omap2430.c | 2 +- drivers/usb/musb/tusb6010.c | 2 +- drivers/usb/musb/ux500.c | 2 +- drivers/usb/otg/ab8500-usb.c | 2 +- drivers/usb/otg/fsl_otg.c| 2 +- drivers/usb/otg/msm_otg.c| 2 +- drivers/usb/otg/mxs-phy.c| 2 +- drivers/usb/otg/nop-usb-xceiv.c | 2 +- drivers/usb/phy/mv_u3d_phy.c | 2 +- drivers/usb/phy/omap-usb2.c | 2 +- drivers/usb/phy/rcar-phy.c | 2 +- drivers/usb/renesas_usbhs/common.c | 2 +- 55 files changed, 56 insertions(+), 56 deletions(-) For drivers/usb/gadget, drivers/usb/dwc3/, drivers/usb/musb/, drivers/usb/otg/, drivers/usb/phy, and drivers/usb/renesas_usbhs: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH 159/493] usb: remove use of __devinit
Hi, On Mon, Nov 19, 2012 at 01:21:48PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Peter Korsgaard jac...@sunsite.dk Cc: Alexander Shishkin alexander.shish...@linux.intel.com Cc: Felipe Balbi ba...@ti.com Cc: Li Yang le...@freescale.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Geoff Levand ge...@infradead.org Cc: Wan ZongShun mcuos@gmail.com Cc: Olav Kongas o...@artecdesign.ee Cc: Lennert Buytenhek ker...@wantstofly.org Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: cbe-oss-...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org --- drivers/usb/c67x00/c67x00-drv.c | 2 +- drivers/usb/chipidea/ci13xxx_imx.c | 2 +- drivers/usb/chipidea/ci13xxx_msm.c | 2 +- drivers/usb/chipidea/ci13xxx_pci.c | 2 +- drivers/usb/chipidea/core.c | 2 +- drivers/usb/chipidea/usbmisc_imx6q.c | 2 +- drivers/usb/dwc3/core.c | 11 +-- drivers/usb/dwc3/debugfs.c | 2 +- drivers/usb/dwc3/dwc3-exynos.c | 4 ++-- drivers/usb/dwc3/dwc3-omap.c | 4 ++-- drivers/usb/dwc3/dwc3-pci.c | 4 ++-- drivers/usb/dwc3/gadget.c| 4 ++-- drivers/usb/gadget/at91_udc.c| 4 ++-- drivers/usb/gadget/bcm63xx_udc.c | 2 +- drivers/usb/gadget/f_uac2.c | 2 +- drivers/usb/gadget/fsl_qe_udc.c | 8 drivers/usb/gadget/mv_udc_core.c | 2 +- drivers/usb/gadget/net2272.c | 13 ++--- drivers/usb/gadget/omap_udc.c| 6 +++--- drivers/usb/gadget/s3c-hsotg.c | 6 +++--- drivers/usb/gadget/s3c-hsudc.c | 2 +- drivers/usb/host/bcma-hcd.c | 9 - drivers/usb/host/ehci-atmel.c| 2 +- drivers/usb/host/ehci-grlib.c| 2 +- drivers/usb/host/ehci-orion.c| 4 ++-- drivers/usb/host/ehci-platform.c | 2 +- drivers/usb/host/ehci-ppc-of.c | 4 ++-- drivers/usb/host/ehci-ps3.c | 2 +- drivers/usb/host/ehci-s5p.c | 2 +- drivers/usb/host/ehci-w90x900.c | 4 ++-- drivers/usb/host/ehci-xilinx-of.c| 2 +- drivers/usb/host/fhci-hcd.c | 2 +- drivers/usb/host/fsl-mph-dr-of.c | 8 drivers/usb/host/imx21-hcd.c | 2 +- drivers/usb/host/isp116x-hcd.c | 2 +- drivers/usb/host/isp1362-hcd.c | 2 +- drivers/usb/host/isp1760-if.c| 4 ++-- drivers/usb/host/ohci-at91.c | 12 ++-- drivers/usb/host/ohci-ep93xx.c | 2 +- drivers/usb/host/ohci-exynos.c | 2 +- drivers/usb/host/ohci-jz4740.c | 2 +- drivers/usb/host/ohci-nxp.c | 4 ++-- drivers/usb/host/ohci-octeon.c | 2 +- drivers/usb/host/ohci-omap3.c| 2 +- drivers/usb/host/ohci-pci.c | 2 +- drivers/usb/host/ohci-platform.c | 2 +- drivers/usb/host/ohci-ppc-of.c | 4 ++-- drivers/usb/host/ohci-ps3.c | 4 ++-- drivers/usb/host/ohci-pxa27x.c | 6 +++--- drivers/usb/host/ohci-s3c2410.c | 2 +- drivers/usb/host/ohci-sa.c | 2 +- drivers/usb/host/ohci-spear.c| 2 +- drivers/usb/host/ohci-tmio.c | 2 +- drivers/usb/host/pci-quirks.c| 14 +++--- drivers/usb/host/r8a66597-hcd.c | 2 +- drivers/usb/host/sl811-hcd.c | 2 +- drivers/usb/host/ssb-hcd.c | 11 +-- drivers/usb/host/u132-hcd.c | 2 +- drivers/usb/host/uhci-grlib.c| 2 +- drivers/usb/host/uhci-platform.c | 2 +- drivers/usb/musb/am35x.c | 2 +- drivers/usb/musb/blackfin.c | 2 +- drivers/usb/musb/cppi_dma.c | 3 +-- drivers/usb/musb/da8xx.c | 2 +- drivers/usb/musb/davinci.c | 2 +- drivers/usb/musb/musb_core.c | 15 +++ drivers/usb/musb/musb_debugfs.c | 2 +- drivers/usb/musb/musb_dma.h | 3 +-- drivers/usb/musb/musb_dsps.c | 4 ++-- drivers/usb/musb/musb_gadget.c | 6 +++--- drivers/usb/musb/musbhsdma.c | 3 +-- drivers/usb/musb/omap2430.c | 2 +- drivers/usb/musb/tusb6010.c | 2 +- drivers/usb/musb/tusb6010_omap.c | 3 +-- drivers/usb/musb/ux500.c | 2 +- drivers/usb/musb/ux500_dma.c | 3 +-- drivers/usb/otg/ab8500-usb.c | 2 +- drivers/usb/otg/fsl_otg.c| 2 +- drivers/usb/otg/isp1301_omap.c | 2 +- drivers/usb/otg/nop-usb-xceiv.c | 2 +- drivers/usb/otg/twl4030-usb.c| 2 +- drivers/usb/otg/twl6030-usb.c| 2 +- drivers/usb/phy/mv_u3d_phy.c | 2 +- drivers/usb/phy/omap-usb2.c | 2 +- drivers/usb/phy/rcar-phy.c | 2 +- 85
Re: [PATCH 431/493] usb: remove use of __devexit
Hi, On Mon, Nov 19, 2012 at 01:26:20PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Peter Korsgaard jac...@sunsite.dk Cc: Alexander Shishkin alexander.shish...@linux.intel.com Cc: Felipe Balbi ba...@ti.com Cc: Li Yang le...@freescale.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Wan ZongShun mcuos@gmail.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org --- drivers/usb/c67x00/c67x00-drv.c | 2 +- drivers/usb/chipidea/ci13xxx_imx.c | 2 +- drivers/usb/chipidea/ci13xxx_msm.c | 2 +- drivers/usb/chipidea/ci13xxx_pci.c | 2 +- drivers/usb/chipidea/core.c | 2 +- drivers/usb/chipidea/usbmisc_imx6q.c | 2 +- drivers/usb/dwc3/core.c | 2 +- drivers/usb/dwc3/debugfs.c | 2 +- drivers/usb/dwc3/dwc3-exynos.c | 2 +- drivers/usb/dwc3/dwc3-omap.c | 2 +- drivers/usb/dwc3/dwc3-pci.c | 2 +- drivers/usb/gadget/bcm63xx_udc.c | 2 +- drivers/usb/gadget/fsl_qe_udc.c | 2 +- drivers/usb/gadget/hid.c | 2 +- drivers/usb/gadget/lpc32xx_udc.c | 2 +- drivers/usb/gadget/mv_u3d_core.c | 2 +- drivers/usb/gadget/mv_udc_core.c | 2 +- drivers/usb/gadget/net2272.c | 10 +- drivers/usb/gadget/omap_udc.c| 2 +- drivers/usb/gadget/s3c-hsotg.c | 4 ++-- drivers/usb/host/bcma-hcd.c | 2 +- drivers/usb/host/ehci-atmel.c| 2 +- drivers/usb/host/ehci-msm.c | 2 +- drivers/usb/host/ehci-platform.c | 2 +- drivers/usb/host/ehci-s5p.c | 2 +- drivers/usb/host/ehci-w90x900.c | 2 +- drivers/usb/host/fhci-hcd.c | 4 ++-- drivers/usb/host/fsl-mph-dr-of.c | 4 ++-- drivers/usb/host/isp1362-hcd.c | 2 +- drivers/usb/host/isp1760-if.c| 2 +- drivers/usb/host/ohci-at91.c | 6 +++--- drivers/usb/host/ohci-exynos.c | 2 +- drivers/usb/host/ohci-jz4740.c | 2 +- drivers/usb/host/ohci-omap3.c| 2 +- drivers/usb/host/ohci-platform.c | 2 +- drivers/usb/host/ohci-s3c2410.c | 2 +- drivers/usb/host/ohci-tmio.c | 2 +- drivers/usb/host/r8a66597-hcd.c | 2 +- drivers/usb/host/sl811-hcd.c | 2 +- drivers/usb/host/ssb-hcd.c | 4 ++-- drivers/usb/host/u132-hcd.c | 2 +- drivers/usb/musb/am35x.c | 2 +- drivers/usb/musb/blackfin.c | 2 +- drivers/usb/musb/da8xx.c | 2 +- drivers/usb/musb/davinci.c | 2 +- drivers/usb/musb/musb_core.c | 2 +- drivers/usb/musb/musb_dsps.c | 2 +- drivers/usb/musb/omap2430.c | 2 +- drivers/usb/musb/tusb6010.c | 2 +- drivers/usb/musb/ux500.c | 2 +- drivers/usb/otg/ab8500-usb.c | 2 +- drivers/usb/otg/fsl_otg.c| 2 +- drivers/usb/otg/msm_otg.c| 2 +- drivers/usb/otg/mxs-phy.c| 2 +- drivers/usb/otg/nop-usb-xceiv.c | 2 +- drivers/usb/phy/omap-usb2.c | 2 +- drivers/usb/phy/rcar-phy.c | 2 +- drivers/usb/renesas_usbhs/common.c | 2 +- For drivers/usb/gadget, drivers/usb/dwc3/, drivers/usb/musb/, drivers/usb/otg/, drivers/usb/phy, and drivers/usb/renesas_usbhs: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH V5 7/7] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
M == Mugunthan V N mugunthan...@ti.com writes:
M Add CPSW and MDIO related device tree data for AM33XX.
M Also enable them into board/evm dts files by providing
M respective phy-id.
M Signed-off-by: Mugunthan V N mugunthan...@ti.com
M Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
M Cc: Benoit Cousson b-cous...@ti.com
M Acked-by: Peter Korsgaard jac...@sunsite.dk
M Acked-by: Richard Cochran richardcoch...@gmail.com
M +++ b/arch/arm/boot/dts/am335x-bone.dts
M @@ -78,3 +78,11 @@
M };
M };
M };
M +
M +cpsw_emac0 {
M + phy_id = davinci_mdio, 0;
M +};
M +
M +cpsw_emac1 {
M + phy_id = davinci_mdio, 1;
M +};
I already acked this and the problem isn't caused by this patch itself,
but it isn't really nice that you have to add a dummy emac1 even though
only the first port is used on the bone.
It would imho be nicer to get rid of the 'slaves' property in cpsw (just
let the driver count available slave children), mark both slaves in
am33xx.dtsi with status = 'disabled' and only loop over the available
slaves in cpsw_probe_dt(), similar to E.G. how the uarts/i2c are handled.
Then am335x-bone.dts would just need to add:
cpsw_emac0 {
status = 'ok';
phy_id = davinci_mdio, 0;
};
I'll send a patch shortly to implement this.
M diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
M index bb31bff..a4615b4 100644
M --- a/arch/arm/boot/dts/am33xx.dtsi
M +++ b/arch/arm/boot/dts/am33xx.dtsi
M @@ -210,5 +210,53 @@
M interrupt-parent = intc;
M interrupts = 91;
M };
M +
M + mac: ethernet@4a10 {
M + compatible = ti,cpsw;
M + ti,hwmods = cpgmac0;
M + cpdma_channels = 8;
M + ale_entries = 1024;
M + bd_ram_size = 0x2000;
M + no_bd_ram = 0;
M + rx_descs = 64;
M + mac_control = 0x20;
M + slaves = 2;
M + cpts_active_slave = 0;
M + cpts_clock_mult = 0x8000;
M + cpts_clock_shift = 29;
M + reg = 0x4a10 0x800
M + 0x4a101200 0x100;
M + #address-cells = 1;
M + #size-cells = 1;
M + interrupt-parent = intc;
M + /*
M +* c0_rx_thresh_pend
M +* c0_rx_pend
M +* c0_tx_pend
M +* c0_misc_pend
M +*/
M + interrupts = 40 41 42 43;
M + ranges;
M +
M + davinci_mdio: mdio@4a101000 {
M + compatible = ti,davinci_mdio;
M + #address-cells = 1;
M + #size-cells = 0;
M + ti,hwmods = davinci_mdio;
M + bus_freq = 100;
M + reg = 0x4a101000 0x100;
M + };
M +
M + cpsw_emac0: slave@4a100200 {
M + /* Filled in by U-Boot */
M + mac-address = [ 00 00 00 00 00 00 ];
M + };
M +
M + cpsw_emac1: slave@4a100300 {
M + /* Filled in by U-Boot */
M + mac-address = [ 00 00 00 00 00 00 ];
M + };
M +
M + };
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
D == Daniel Mack zon...@gmail.com writes: Hi, D This patch adds basic DT bindings for OMAP GPMC. D The actual peripherals are instanciated from child nodes within the GPMC s/instanciated/instantiated/ D node, and the only type of device that is currently supported is NAND. D Code was added to parse the generic GPMC timing parameters and some D documentation with examples on how to use them. D Successfully tested on an AM33xx board. D Signed-off-by: Daniel Mack zon...@gmail.com D --- D .../devicetree/bindings/mtd/gpmc-nand.txt | 84 ++ D arch/arm/mach-omap2/gpmc.c | 170 + D 2 files changed, 254 insertions(+) D create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt D diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt D new file mode 100644 D index 000..20aa5b9 D --- /dev/null D +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt D @@ -0,0 +1,84 @@ D +Device tree bindings for GPMC connected NANDs D + D +GPMC connected NAND (found on OMAP boards) are represented as child nodes of D +the GPMC controller with a name of nand. D + D +All timing relevant properties as well as generic gpmc child properties are D +explained in a separate documents - please refer to D +Documentation/devicetree/bindings/bus/ti-gpmc.txt Which this patch seems to be missing? D + D +For NAND specific properties such as ECC modes or bus width, please refer to D +Documentation/devicetree/bindings/mtd/nand.txt D + D + D +Required properties: D + D + - reg:The CS line the peripheral is connected to D + D +Optional properties: D + D + - nand-bus-width: Set this numeric value to 16 if the hardware D + is wired that way. If not specified, a bus D + width of 8 is assumed. D + - ti,nand-ecc-opt:A string setting the ECC layout to use. One of: D + D + Layouts for 1-bit ecc: stored at end of spare area: D + D + software Software method (default) D + hwHardware method (let gpmc do the error detection) Nit: why are you spelling out 'software' when everything else is shortened? D + D + Layouts for 1-bit ecc: stored at beginning of spare area as romcode: D + D + hw-romcodegpmc method romcode layout D + bch4 4-bit BCH ecc code D + bch8 8-bit BCH ecc code D + These are not 1-bit - Well, romcode might be depending on SoC. Looking at omap2.c it seems to be an alias for hw, so that isn't really helpful on E.G. am33xx where you should select bch8 to have something compatible with the romcode. D + - ti,nand-ecc-use-elm:Property without value to specify that the D + hardware error correction mode should be used. It's called the error location module. Like you pointed out yourself, this property isn't really nice. I haven't looked at the elm bindings in detail, but couldn't the nand driver automatically use the elm if the device tree provides a node for it? Perhaps the elm should be a subnode of the nand one? -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
* Tomi Valkeinen tomi.valkei...@ti.com [121116 01:08]: Hi Tony, On 2012-11-13 00:50, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [121112 02:27]: Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3? Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also? Yes if that's now needed for DSS. I have to say I don't know the details of the dma allocation, but afaik there are no drawbacks with CMA. Although it is still marked EXPERIMENTAL in the kconfig... I guess that's still fine as that's what we're supposed to use :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] crypto: omap-aes updates
On Mon, Nov 19, 2012 at 12:03:45PM -0700, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com This series updates the crypto omap-aes driver and supporting infrastructure. Notes: a) Based on omap-sham patches recently submitted, XXX ^^^ That was supposed to say that the series is based on the recently submitted omap-sham updates: http://permalink.gmane.org/gmane.linux.ports.arm.omap/89689 -- 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 00/16] OMAP USB Host cleanup
Roger Quadros rog...@ti.com writes: Kevin, On 11/16/2012 10:08 PM, Kevin Hilman wrote: Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( oh that's bad. But this series wasn't meant to fix that ;). Oh, sorry. Yeah, I didn't mean this as a nak. Just an opportunity to complain to the maintainers that a long-standing issue needs to be addressed. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/5] iommu/omap: keep mmu enabled when requested
The purpose of the mmu is to handle the memory accesses requested by its users. Typically, the mmu is bundled with the processing unit in a single IP block, which makes them to share the same clock to be functional. Currently, iommu code assumes that its user will be indirectly clocking it, but being a separate mmu driver, it should handle its own clocks, so as long as the mmu is requested it will be powered ON and once detached it will be powered OFF. The remaining clock handling out of iommu_enable and iommu_disable corresponds to paths that can be accessed through debugfs, some of them doesn't work if the module is not enabled first, but in future if the mmu is idled withouth freeing, these are needed to debug. Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org --- drivers/iommu/omap-iommu.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 6b1288c..f8082da 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -154,7 +154,6 @@ static int iommu_enable(struct omap_iommu *obj) err = arch_iommu-enable(obj); - clk_disable(obj-clk); return err; } @@ -163,8 +162,6 @@ static void iommu_disable(struct omap_iommu *obj) if (!obj) return; - clk_enable(obj-clk); - arch_iommu-disable(obj); clk_disable(obj-clk); -- 1.7.4.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 v5 3/5] iommu/omap: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/omap-iommu.c | 168 +++---
drivers/iommu/omap-iommu.c | 23 +++-
drivers/iommu/omap-iommu2.c | 19
include/linux/platform_data/iommu-omap.h |8 ++-
5 files changed, 64 insertions(+), 156 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1002ff8..28d73c0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index a6a4ff8..02726a6 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,61 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include linux/platform_data/iommu-omap.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
-#include soc.h
-#include common.h
-
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
- {
- .base = OMAP4_MMU2_BASE,
- .irq = 28 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = tesla,
- .nr_tlb_entries = 32,
- .clk_name = dsp_fck,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-};
-#define NR_OMAP4_IOMMU_DEVICES ARRAY_SIZE(omap4_devices)
-static struct platform_device *omap4_iommu_pdev[NR_OMAP4_IOMMU_DEVICES];
-#else
-#define omap4_devices NULL
-#define NR_OMAP4_IOMMU_DEVICES 0
-#define omap4_iommu_pdev NULL
-#endif
-
-static struct platform_device **omap_iommu_pdev;
-
-static int __init omap_iommu_init(void)
+static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused)
{
- int i, err;
- struct resource res[] = {
- { .flags = IORESOURCE_MEM },
- { .flags = IORESOURCE_IRQ },
- };
+ struct platform_device *pdev;
+ struct iommu_platform_data *pdata;
+ struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+ static int i;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata-name = oh-name;
+ pdata-clk_name = oh-main_clk;
+ pdata-nr_tlb_entries = a-nr_tlb_entries;
+ pdata-da_start = a-da_start;
+ pdata-da_end = a-da_end;
+
+ if (oh-rst_lines_cnt == 1) {
[PATCH v5 5/5] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk-enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.
According to comments received[1] for related patches the idea is
to get rid of leaf clocks in future. So remove these two while at it.
[1] http://lkml.org/lkml/2012/8/20/226
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/clock44xx_data.c | 22 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 ++--
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..067c486 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1316,16 +1316,6 @@ static struct clk dmic_fck = {
.clkdm_name = abe_clkdm,
};
-static struct clk dsp_fck = {
- .name = dsp_fck,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_TESLA_TESLA_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = tesla_clkdm,
- .parent = dpll_iva_m4x2_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk dss_sys_clk = {
.name = dss_sys_clk,
.ops= clkops_omap2_dflt,
@@ -1696,16 +1686,6 @@ static struct clk i2c4_fck = {
.recalc = followparent_recalc,
};
-static struct clk ipu_fck = {
- .name = ipu_fck,
- .ops= clkops_omap2_dflt,
- .enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
- .enable_bit = OMAP4430_MODULEMODE_HWCTRL,
- .clkdm_name = ducati_clkdm,
- .parent = ducati_clk_mux_ck,
- .recalc = followparent_recalc,
-};
-
static struct clk iss_ctrlclk = {
.name = iss_ctrlclk,
.ops= clkops_omap2_dflt,
@@ -3151,7 +3131,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, div_ts_ck,div_ts_ck,
CK_446X),
CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck,
CK_443X),
CLK(NULL, dmic_fck, dmic_fck,
CK_443X),
- CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
CLK(NULL, dss_sys_clk, dss_sys_clk,
CK_443X),
CLK(NULL, dss_tv_clk, dss_tv_clk,
CK_443X),
CLK(NULL, dss_48mhz_clk,dss_48mhz_clk,
CK_443X),
@@ -3183,7 +3162,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, i2c2_fck, i2c2_fck,
CK_443X),
CLK(NULL, i2c3_fck, i2c3_fck,
CK_443X),
CLK(NULL, i2c4_fck, i2c4_fck,
CK_443X),
- CLK(NULL, ipu_fck, ipu_fck,
CK_443X),
CLK(NULL, iss_ctrlclk, iss_ctrlclk,
CK_443X),
CLK(NULL, iss_fck, iss_fck,
CK_443X),
CLK(NULL, iva_fck, iva_fck,
CK_443X),
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index aab5c12..1f61093 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -650,7 +650,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.mpu_irqs = omap44xx_dsp_irqs,
.rst_lines = omap44xx_dsp_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
- .main_clk = dsp_fck,
+ .main_clk = dpll_iva_m4x2_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_TESLA_TESLA_CLKCTRL_OFFSET,
@@ -1677,7 +1677,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
.mpu_irqs = omap44xx_ipu_irqs,
.rst_lines = omap44xx_ipu_resets,
.rst_lines_cnt = ARRAY_SIZE(omap44xx_ipu_resets),
- .main_clk = ipu_fck,
+ .main_clk = ducati_clk_mux_ck,
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
--
1.7.4.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 v5 4/5] iommu/omap: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Due to reset sequence, pm_runtime_[get|put]_sync must be used, to
avoid possible operations with the module under reset. Because of
this and given that the driver uses spin_locks to protect their
critical sections, we must use pm_runtime_irq_safe in order for the
runtime ops to be happy, otherwise might_sleep_if checks in runtime
framework will complain.
The remaining pm_runtime out of iommu_enable and iommu_disable
corresponds to paths that can be accessed through debugfs, some of
them doesn't work if the module is not enabled first, but in future
if the mmu is idled withouth freeing, these are needed to debug.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/omap-iommu.c |1 -
drivers/iommu/omap-iommu.c | 40 ++---
drivers/iommu/omap-iommu.h |3 --
drivers/iommu/omap-iommu2.c | 17
include/linux/platform_data/iommu-omap.h |1 -
5 files changed, 19 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 02726a6..7642fc4 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -31,7 +31,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index af9b4f3..18108c14 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,13 +16,13 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/omap-iommu.h
#include linux/mutex.h
#include linux/spinlock.h
#include linux/io.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -160,7 +160,7 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
@@ -177,7 +177,7 @@ static void iommu_disable(struct omap_iommu *obj)
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
@@ -303,7 +303,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
if (!obj || !obj-nr_tlb_entries || !e)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
iotlb_lock_get(obj, l);
if (l.base == obj-nr_tlb_entries) {
@@ -333,7 +333,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
cr = iotlb_alloc_cr(obj, e);
if (IS_ERR(cr)) {
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return PTR_ERR(cr);
}
@@ -347,7 +347,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, struct
iotlb_entry *e)
l.vict = l.base;
iotlb_lock_set(obj, l);
out:
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
return err;
}
@@ -377,7 +377,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
int i;
struct cr_regs cr;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
for_each_iotlb_cr(obj, obj-nr_tlb_entries, i, cr) {
u32 start;
@@ -396,7 +396,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
}
}
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if (i == obj-nr_tlb_entries)
dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
@@ -410,7 +410,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
{
struct iotlb_lock l;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
l.base = 0;
l.vict = 0;
@@ -418,7 +418,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
iommu_write_reg(obj, 1, MMU_GFLUSH);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
}
#if defined(CONFIG_OMAP_IOMMU_DEBUG) || defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
@@ -428,11 +428,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char
*buf, ssize_t bytes)
if (!obj || !buf)
return -EINVAL;
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
bytes = arch_iommu-dump_ctx(obj, buf, bytes);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
[PATCH v5 0/5] OMAP: iommu: hwmod, reset handling and runtime PM
These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. A couple of patches were added (first two) to be clearer on the reasons for such changes, they were previosuly bundled as part of runtime PM changes. The last patch corresponds to a change in the leaf clocks used and it depends on this series to work properly. Due to single Image support, I rebased these on top of k3.7-rc5 and DEPEND on: [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu http://thread.gmane.org/gmane.linux.kernel/1387788 Minor rebasing might be needed if these are included on top of linux-omap, since they are affected by changes on headers being moved to include/linux/platform_data and arch/arm/mach-omap2. Omar Ramirez Luna (5): iommu/omap: remove redundant clock handling on ISR iommu/omap: keep mmu enabled when requested iommu/omap: migrate to hwmod framework iommu/omap: adapt to runtime pm ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks arch/arm/mach-omap2/clock44xx_data.c | 22 arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/omap-iommu.c | 167 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +- drivers/iommu/omap-iommu.c | 68 ++- drivers/iommu/omap-iommu.h |3 - drivers/iommu/omap-iommu2.c| 36 -- include/linux/platform_data/iommu-omap.h |9 +- 8 files changed, 84 insertions(+), 227 deletions(-) -- 1.7.4.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 v5 1/5] iommu/omap: remove redundant clock handling on ISR
For the interrupt to be generated, the mmu clock should be already enabled while translating a virtual address, so, this call to clock handling is just increasing/decreasing the counter. This works now, because its users need the same clock and they indirectly power the mmu, in this interrupt context the handling of clocks inside the ISR doesn't seem to be needed nor helping. Next patch should also correct the dependency on clients to handle iommu clocks. Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org --- drivers/iommu/omap-iommu.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index badc17c..6b1288c 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -807,9 +807,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!obj-refcount) return IRQ_NONE; - clk_enable(obj-clk); errs = iommu_report_fault(obj, da); - clk_disable(obj-clk); if (errs == 0) return IRQ_HANDLED; -- 1.7.4.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 v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On Mon, Nov 19, 2012 at 02:58:41PM +0200, Tomi Valkeinen wrote: I still don't understand why the codec and machine drivers need to be created in the board file. That just forces us to replicate the same code for all OMAP boards that have OMAP HDMI output. Why not create the devices in some common code, for example arch/arm/mach-omap2/display.c? Yes, this would be more sensible if there's no board specifics involved. With DT this should be similar: OMAP's hdmi devices should be presented in the omap4.dtsi file, not in each individual board dts. Although the DT data should represent the hardware, and if the code and machine devices are not really there in the HW, then... I don't know =). Well, in a case like this where the sound card is essentially autoprobed based on the detection of the hardware at runtime the sound card probably shouldn't appear in the device tree at all - you'll probably want something to say there's a physical HDMI port it's worth looking at there but everything else should be figured out at runtime. And something that confuses me: sound/soc/codecs/omap-hdmi.c contains a codec and dai drivers, but sound/soc/omap/omap-hdmi.c also contains a dai driver. The latter actually contains two dai drivers, the other a platform driver and the other a snd_soc_dai_driver. But I guess this is asoc details, and not relevant to this disuccsion =). There's an interaface on each end of the link, they're wired together to communicate between the two devices. signature.asc Description: Digital signature
Re: [PATCH 205/493] gpio: remove use of __devinit
On Mon, Nov 19, 2012 at 01:22:34PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH 077/493] mmc: remove use of __devexit_p
On Mon, Nov 19, 2012 at 11:50 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Chris Ball c...@laptop.org Cc: Michał Mirosław mirq-li...@rere.qmqm.pl Cc: Jarkko Lavinen jarkko.lavi...@nokia.com Cc: Venkatraman S svenk...@ti.com Cc: Viresh Kumar viresh.li...@gmail.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Ian Molton i...@mnementh.co.uk Cc: Bruce Chang brucech...@via.com.tw Cc: Harald Welte haraldwe...@viatech.com Cc: Pierre Ossman pie...@ossman.eu Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: spear-de...@list.st.com --- drivers/mmc/host/sdhci-spear.c | 2 +- Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 237/493] mmc: remove use of __devinit
On Mon, Nov 19, 2012 at 11:53 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Ludovic Desroches ludovic.desroc...@atmel.com Cc: Chris Ball c...@laptop.org Cc: Manuel Lauss manuel.la...@gmail.com Cc: Michał Mirosław mirq-li...@rere.qmqm.pl Cc: Jarkko Lavinen jarkko.lavi...@nokia.com Cc: Venkatraman S svenk...@ti.com Cc: Viresh Kumar viresh.li...@gmail.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Ian Molton i...@mnementh.co.uk Cc: Bruce Chang brucech...@via.com.tw Cc: Harald Welte haraldwe...@viatech.com Cc: Pierre Ossman pie...@ossman.eu Cc: linux-...@vger.kernel.org Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: spear-de...@list.st.com --- drivers/mmc/host/sdhci-spear.c | 8 +++- Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
