Re: Handling of modular boards
On Fri, May 4, 2012 at 9:34 PM, Arnd Bergmann a...@arndb.de wrote: Thanks for getting the discussion started. I've seen the same issue come up for arch/arm/mach-ux500/board-mop500*uib.c and for the beaglebone. I'm sure there are many more, but we should make sure that everyone of these can live with whatever we come up with. The same issue sort of comes up with any system that uses the idiom to have a few GPIO lines indicate in a binary code what version of the board we're dealing with and what devices are thus on it, right? We have this issue for the U9540 reference design and potentially on the Snowball as well. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling of modular boards
On Fri, May 4, 2012 at 10:44 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote: b) Doesn't integrate well with hotplug; the DT for the board configuration is static at boot. What if a board can be unplugged and another plugged in; a reboot or similar would be needed to adjust the kernel to this. This is another issue - a similar set of problems does apply to some PCI type cards where the PCI device is essentially a bridge to a typical embedded system - though practically speaking it's much less severe. I think Alessandro is working on a board like that right now, so looping in Ale to this discussion to get his attention... Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] RFC: AMBA bus discardable probe() function
[Russell] which gives a total of 5188 bytes for all the above probe functions. However, in order to free this, we're adding 184 bytes of code and literal pool to achieve this: (...) The overall kernel size is 3877020 bytes, which means we're potentially allowing for 0.13% of the kernel to be freed at run time - which may equate to one or at most two additional pages. We have the PL022 as well, and the PL08x is being added but it will likely stay in that ballpark figure. But overall that does not seem to be worth it, so let's drop it for the time being. CC:ing the linux-embedded folks that often worry about footprint size to see if someone oppose. Also CC Viresh who works on a platform for e.g. set-top boxes using these PrimeCells which I think may be memory-constrained. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] RFC: AMBA bus discardable probe() function
[Greg] [Me] + spin_lock(amba_bustype.p-klist_drivers.k_lock); Ick, nope, you can't do this, sorry. That's a private structure for a reason. Yeah I get it, but in the platform bus case what's that traversal of the klists actually for? I didn't get it, and was guessing that it was considering the case where devices spawn new devices. So what's the real driving force here, just saving a few hundred bytes after booting? Or something else? A few thousand actually according to Russells measurements. And no I don't think it's worth it unless someone else challenge this... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
2010/4/21 Roger Quadros roger.quad...@nokia.com: [MTP device with PTP class and MTP extension code] On Linux (Ubuntu 9.04) it works as PTP device. If you have libmtp 1.0.1 or later it should work as MTP with some client program like Rhythmbox or Amarok or Banshee, unless some PTP handler hogs it first. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
2010/4/20 Roger Quadros roger.quad...@nokia.com: http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284 Do you know if these older Windows OSes request the OS descriptor when the device uses a standard USB class code? I haven't tested, but I think Windows will attempt to always use the OS descriptor first and foremost. AFAIK the MTP device device should use PTP Class, Subclass and protocol codes (i.e. 6:1:1). In this case Windows XP treats it as a PTP device (even if the device implements OS descriptors). I'm sure all MTP devices in the market that implement OS descriptors use Vendor Specific class (i.e. 0xff:0:0) which is not the right thing to do after MTP has been standardized by usb.if. Yes they should, but still very few devices, if any, use the PTP class code. The reason behind, and the reason to why they use the OS descriptor at all, if I understood correctly, was that Microsoft actually *wanted* to use the PTP class for MTP devices, but to do that the MTP extensions had to pass through the USB IF standardization process which took some three years or so. In the meantime USB IF forbade them to use the PTP class code for something that was not officially a PTP extension. So these devices all are class 0xff vendor specific or 0x00 defined at interface level. (One device mistakedly use class code 111 decimal!) I haven't however looked at what they're using as bInterfaceClass really, perhaps there are MTP devices out there that define themselves as PTP, I've never heard of one, other than the experimental device that was used to implement the proper detection algorithm in libmtp. I think Windows only knows they are MTP devices by either probing the OS descriptor or having a built-in table of MTP-compliant vendor/device ID pairs. Probably both, because some of the very earliest PMC (Portable Media Center) models didn't even have OS descriptors. I guess Felipe may have first-hand experience with using the PTP class code only? Maybe this works in the latest Windowses, post-USB IF standardization? No idea. Maybe tagging a device with the PTP class and subclass 0x01 will make it always fall back to PTP mode only under Windows, MTP features disabled, this would not surprise me one bit. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
2010/4/19 Felipe Balbi felipe.ba...@nokia.com: 2010/4/18 Linus Walleij linus.ml.wall...@gmail.com: Further comments: there is apparently a driver floating around this list for supporting PTP through the gadgetfs. How does this work relate to that, and why can't you use gadgetfs? dude, can't you read ? gadgetfs prevents us from combining into a composite gadget. We went throught that already. Please follow the thread before commenting. Yeah sorry, I'm trying to catch up and miss some pieces here and there. I'm mainly reading it from the MTP side of things. Second: after looking at this, I think that atleast the part of functionality called OS descriptor should be in the kernel and not in userspace, is the OS descriptor the reason to why you want to expose EP0 to userspace, or are you using this for other things in the MTP stack? OS descriptor is MS specific crap, it's not on the USB-IF mtp spec and most like MS has some patent on that. ...so I read you like it's not going to be supported with the proposed solution? I think that if you want you gadget to work with older Windowses, you simply have to support this. Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
2010/4/19 Steve Calfee stevecal...@gmail.com:
For 6 months, a while ago, I was working on virtual USB stuff for a
company. I did analyser traces of many devices including many MS
devices (mice, webcam, keyboard, joystick), and never found any device
from MS or anyone that supported that command. All devices that I saw
just replied (properly) with a STALL - and Winxp would just continue
on and handle the device.
I don't think they add it to that kind of devices. Only MTP players
for what I've seen. Maybe some weirdo RNDIS stuff use it too?
But as you see Windows issues this command to absolutely everything
you plug in, I've been thinking about how we could emulate the same
behaviour in Linux but actually I think it's a bit insane and only take
extra time to send that command to whatever you plug in.
Still it would be nice to know directly from userspace if a device that
was plugged in was MTP or not, especially we need this for udev
rules (or HAL, DeviceKit etc, whatever) that want to make the device
read/writable for the console user when it's plugged in.
When you say older windowses, which one; the only earlier ones with
USB was 98 and descendants and somewhat 95.
Especially the Win98 and Win2000 stuff that comes with the Windows
Media Player has to respond to it.
Actually Windows probably has some internal list of devices and
specific quirks it has to use for them to work properly, but I'm not
sure. (I asked them about it I think, but didn't get any replies.)
Also have you found a device that actually responds to the get
osdescriptor request?
Almost all MTP devices out there does, check the logs here:
http://libmtp.cvs.sourceforge.net/viewvc/libmtp/libmtp/logs/
If the device responds with something sane for command 0xee
the MTP stack will go on to issue special commands, you can find
our code for this here:
http://libmtp.cvs.sourceforge.net/viewvc/*checkout*/libmtp/libmtp/src/libusb-glue.c?revision=1.284
Basically it's a simple libusb command we issue:
/* Read the special descriptor */
ret = usb_get_descriptor(devh, 0x03, 0xee, buf, sizeof(buf));
// Dump it, if requested
if (dumpfile != NULL ret 0) {
fprintf(dumpfile, Microsoft device descriptor 0xee:\n);
data_dump_ascii(dumpfile, buf, ret, 16);
}
It typically looks like this:
Microsoft device descriptor 0xee:
: 1203 4d00 5300 4600 5400 3100 3000 3000 ..M.S.F.T.1.0.0.
0010: 1c00 ..
Microsoft device response to control message 1, CMD 0x1c:
: 2800 0001 0400 0100 (...
0010: 0001 4d54 5000 3030 ..MTP.00
0020:
Potential MTP Device with VendorID:22b8 and ProductID:6415 responded
to control message 2 with a response that was too short. Problems may
arrise but continuing
Device info:
But Ziilabs Egg actually reply properly to the second control message:
Microsoft device descriptor 0xee:
: 1203 4d00 5300 4600 5400 3100 3000 3000 ..M.S.F.T.1.0.0.
0010: 0100 ..
Microsoft device response to control message 1, CMD 0x01:
: 2800 0001 0400 0100 (...
0010: 0001 4d54 5000 ..MTP...
0020:
Microsoft device response to control message 2, CMD 0x01:
: 0c00 0001 0500
A special oddity is devices that *require* you to probe the
device descriptor and won't even work if you don't:
ZiiLabs Egg, several SanDisk Sansas, and some LGE phones
display this behaviour.
Since the devices are only ever tested with Windows nobody notice
that they don't work properly without the probing...
There are some more generic USB misbehaviour displayed by these
devices I can list if you're interested.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Project Proposal: add sleeping spinlocks to mainline kernel
2009/12/16 Tim Bird tim.b...@am.sony.com: Summary: add sleeping spinlocks to the mainline kernel If realtime performance overall is a big deal for CELF I would suggest adding Kill-the-BKL to the suggested projects. There are still some RTOS people using the BKL as an argument to flak the Linux kernel, c.f. http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf (section 5.2) Another item could be to go through some common embedded arch drivers and switch them from request_irq() to request_threaded_irq() just based on the observation that almost nobody actually use that in the mainline kernel, though I'm sure they should, if realtime is a desired feature. (The wm8350-core driver is an excellent example of a situation where it is used properly.) NB: I'm not a member of the CE Linux Forum and nor is my company so I'm just talking freely here. (linux-embedded is public, hehe.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [POWER] battery calibration parameters from sysfs
Thanks for all the great attention Mark! [Mark wrote] On Sat, Dec 05, 2009 at 02:08:11PM +0100, Linus Walleij wrote: (...) That's an easy solution of course, but then the sysfs files specified by the power subsystem, i.e. all charge_*, energy_*, capacity and time_to_* loose their meaning and must be ignored by userspace. These files should only be present if we have data for them. Userspace can't be reliant on them at present since relatively few systems seem to implement them, for example none of my laptops have time_to, energy_ or capacity attributes. Well, yeah, we're not exactly in the laptop business. (But my HP laptop nc2400 has the charge_* attributes, 499 uAh in charge_now and this corresponds to what is shown in g-p-m converted over to Wh, but I don't know exactly where it's getting it from...) One of the things we're facing is Android, which has its userspace in plain Java JNI at the end of this link: http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34 1faa094c71922946fdab;hb=HEAD If you browse down to line 275 you can see it parse the sysfs attribute capacity, then this propagates up to the battery status indicator on *all* Android phones out there. So if you want to run Android unmodified, this is what you need to provide. They are effectively using the power sysfs as their hardware abstraction layer in this case. Note: I'm not claiming that Android is doing it right or that we can't modify this code or so, it's just that this is the way a few million Android devices out there are actually doing it. We have other odd code. Actually we have full software- controlled CC/CV charging in our driver, and that would *definately* go in such a library if it was to end up in kernelspace. We have actually pushed that to userspace, while I still tend to think that the kernel (with right parameters) should be able to charge a battery. But, well. As was previously discussed (in another thread) I do think there needs to be at least some in kernel part to charger code like this in order to ensure that we're robust against userspace failure and cope well with suspend and resume. There's the potential for serious hardware damage if the battery is mistreated. You're right of course. In our case we have a hardware watchdog protecting against overcharging etc, and charging will halt when the watchdog is not periodically fed. So actually we're on the safe side here. (I think!) There's other kernel filesystems that might be more approprite for this sort of stuff, trying to fit this into sysfs really does feel like far too much pain to be right. You're right GKH already pointed me to configfs so that's where it's going to sit if we do this thing. We'd better write up some code to show how this would work instead so I'll be back with that sooner or later. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [POWER] battery calibration parameters from sysfs
Thanks Mark, prompt answers as always.
[Mark Brown]
[Linus Walleij]
In our code we have a number of (x,y) pair tables like this:
/* Vbat mV to Battery capacity % */
struct voltage_vs_capacity {
int voltage;
int capacity;
};
Isn't the standard thing here to handle this voltage to
capacity mapping in userspace if we're just extrapolating
from experimental results?
That's an easy solution of course, but then the sysfs files
specified by the power subsystem, i.e. all charge_*,
energy_*, capacity and time_to_* loose their meaning
and must be ignored by userspace.
Also this was just an example, we have similar calibration
for the temperature sensor, and thus the temp sysfs file
also loose its meaning.
Since there is a plethora of userspace apps that just
interface these files directly (gnome-power-manager and
the Android stack come to mind) all these will have to
be patches to accept a calibrated value from somewhere
else if we shall use them with our hardware.
But as you say:
Even with the smart batteries in PCs there are some
accuracy concerns and obviously the performance of the
battery will change over time.
...
Actually, one further thing here - if this functionality
is implemented in kernel then shouldn't it be a generic
feature rather than part of the driver? The idea of
mapping battery voltages to capacity percentages isn't
specific to a given charger and will apply to all
batteries using the same technology.
Surely, we'd be happy to do it that way if desired.
What about drivers/power/battery_lib.c?
(And getting algorithms in place for gradually
adjusting the capacity levels as compared to factory
settings for PC batteries would perhaps end up in the
same place then.)
We have other odd code. Actually we have full software-
controlled CC/CV charging in our driver, and that
would *definately* go in such a library if it was
to end up in kernelspace. We have actually
pushed that to userspace, while I still tend to think
that the kernel (with right parameters) should be able
to charge a battery. But, well.
As for the calibration format, after reading up on the
latest sysfs doc I saw:
Documentation/filesystems/sysfs.txt:
Attributes should be ASCII text files, preferably with
only one value per file. It is noted that it may not be
efficient to contain only one value per file, so it is
socially acceptable to express an array of values of the
same type.
This is close to that, an array of two types (x,y)(x,y)
voltage,capacity,voltage,capacity etc. Pushing them in
two files
/sys/.../v_vs_cap_v
/sys/.../v_vs_cap_cap
and then make sure we write as many values to each array
is uglier IMHO.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[POWER] battery calibration parameters from sysfs
Hi,
we're working on battery charging support for ST-Ericsson MFD ASICs
like AB3100 and later series. I have this issue about battery
calibration
parameters that I need advice on, and more specifically on how to use
sysfs to get that data in.
Most devices of this kind does not need the stuff we're doing so we're
the odd bird here. Other batteries are smart (contain factory
calibration inside of them) or get calibration from some BIOS or such.
In our code we have a number of (x,y) pair tables like this:
/* Vbat mV to Battery capacity % */
struct voltage_vs_capacity {
int voltage;
int capacity;
};
/*
* Default calibration table for voltage vs battery capacity.
* Voltage in millivolts, capacity given in permil.
*/
struct voltage_vs_capacity voltage_to_battery_capacity_init[] = {
{ 4177, 1000 },
{ 4070, 900 },
{ 3988, 800 },
{ 3834, 570 },
{ 3797, 470 },
{ 3768, 320 },
{ 3721, 190 },
{ 3633, 60 },
{ 3523, 30 },
{ 3200,0 },
};
We then interpolate between two subsequent (xn,yn),(xn+1,yn+1)
pairs to get a calibrated capacity value from the voltage
level measured.
This is all good as long as you compile the calibration into the kernel
like this.
However we want to override the default table with one fed in
though e.g. sysfs, so calibration data for the battery can reside
in the file system. NOTE: this table is NOT of fixed length, i.e.
we don't know how many (x,y) pairs will be passed in.
Whereas the rule for sysfs is one value per file, creating an arbitrary
large hirarchy like this:
/sys/.../v_vs_cap/x0
/sys/.../v_vs_cap/y0
/sys/.../v_vs_cap/x1
/sys/.../v_vs_cap/y2
...
/sys/.../v_vs_cap/xN
/sys/.../v_vs_cap/yN
Is probably not very elegant. (Or is it?) Would it be permissible to
pass in a table like:
cat /sys/.../v_vs_cap EOF
x0,y0
x1,y1
x2,y2
EOF
And have the kernel parse x,y pairs up to EOF?
Or would it be preferable to do this thing by creating some
misc device node like /dev/battery0 and a custom ioctl()?
Or is there some other way I haven't thought of?
Yours,
Linus Walleij
ST-Ericsson
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New fast(?)-boot results on ARM
2009/8/14 Robert Schwebel r.schwe...@pengutronix.de: On Fri, Aug 14, 2009 at 12:19:48PM -0600, Zan Lynx wrote: That's factor 70 away from the 110 ms boot time Tim has talked about some days ago (and he measured on an ARM cpu which had almost half the speed of this one), and I'm wondering what we can do to improve the boot time. 2.4s in uncompression? That seems like an obvious target for improvement. Indeed, we'll check that. We got rid of uncompression on a flash-based system vastly improving boot time. The reason is that compressed kernels are faster only when the throughput to the persistent storage is lower than the decompression throughput, and on typical embedded systems with DMA the throughput to memory outperforms the CPU-based decompression. Of course it depends on a lot of stuff like performance of flash controller, kernel storage filesystem performance, DMA controller performance, cache architecture etc so it's individual per-system. Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MMC Agressive clocking framework v4
2009/6/21 Linus Walleij linus.wall...@stericsson.com: This patch modified the MMC core code to optionally call the set_ios() operation on the driver with the clock frequency set to 0 Ping on this. It's soon been a month since the last version and I know we're in vacation times but... Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MMC Agressive clocking framework v4
2009/7/14 Linus Walleij linus.ml.wall...@gmail.com: 2009/6/21 Linus Walleij linus.wall...@stericsson.com: This patch modified the MMC core code to optionally call the set_ios() operation on the driver with the clock frequency set to 0 Ping on this. It's soon been a month since the last version and I know we're in vacation times but... Aw sorry now I saw you mail about being unable to continue doing MMC maintenance. I will proceed to send the patch to Andrew if noone picks up the rôle, OK. Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] transcendent memory for Linux
2009/6/20 Dan Magenheimer dan.magenhei...@oracle.com: We call this latter class transcendent memory and it provides an interesting opportunity to more efficiently utilize RAM in a virtualized environment. However this memory but not really memory may also have applications in NON-virtualized environments, such as hotplug-memory deletion, SSDs, and page cache compression. Others have suggested ideas such as allowing use of highmem memory without a highmem kernel, or use of spare video memory. Here is what I consider may be a use case from the embedded world: we have to save power as much as possible, so we need to shut off entire banks of memory. Currently people do things like put memory into self-refresh and then sleep, but for long lapses of time you would want to compress memory towards lower addresses and turn as many banks as possible off. So we have something like 4x16MB banks of RAM = 64MB RAM, and the most necessary stuff easily fits in one of them. If we can shut down 3x16MB we save 3 x power supply of the RAMs. However in embedded we don't have any swap, so we'd need some call that would attempt to remove a memory by paging out code and data that has been demand-paged in from the FS but no dirty pages, these should instead be moved down to memory which will be retained, and the call should fail if we didn't succeed to migrate all dirty pages. Would this be possible with transcendent memory? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MMC Agressive clocking framework v3
2009/6/18 Linus Walleij linus.wall...@stericsson.com: diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig (...) + Of unsure, say N. However the rest of the patch is as I intended. I'll send a V4 pronto if you want that for the current merge window. Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v4
This adds a few clk_enable()/clk_disable() calls to the MMCI
driver so as to handle an set_ios() request with clock
frequency set to 0 as an instruction to gate the block clock.
This also breaks out the clock setting code into its own
function to simplify the set_ios() function a bit.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/host/mmci.c | 78 ++
1 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 36875dc..d9f5c9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -37,8 +37,34 @@
static unsigned int fmax = 515633;
+/*
+ * This must be called with host-lock held
+ */
+static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ u32 clk = 0;
+
+ if (desired) {
+ if (desired = host-mclk) {
+ clk = MCI_CLK_BYPASS;
+ host-cclk = host-mclk;
+ DBG(host, MMCI: bypass clock divider, cclk = %u Hz\n,
host-cclk);
+ } else {
+ clk = host-mclk / (2 * desired) - 1;
+ if (clk = 256)
+ clk = 255;
+ host-cclk = host-mclk / (2 * (clk + 1));
+ DBG(host, MMCI: divide cclk to %u Hz (divide %u by
%u)\n, host-cclk, host-mclk, clk);
+ }
+ if (host-hw_designer == 0x80)
+ clk |= MCI_FCEN; /* Bug fix in ST IP block */
+ clk |= MCI_CLK_ENABLE;
+ }
+ writel(clk, host-base + MMCICLOCK);
+}
+
static void
-mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
+ mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
writel(0, host-base + MMCICOMMAND);
@@ -418,22 +444,7 @@ static void mmci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mmci_host *host = mmc_priv(mmc);
- u32 clk = 0, pwr = 0;
-
- if (ios-clock) {
- if (ios-clock = host-mclk) {
- clk = MCI_CLK_BYPASS;
- host-cclk = host-mclk;
- } else {
- clk = host-mclk / (2 * ios-clock) - 1;
- if (clk = 256)
- clk = 255;
- host-cclk = host-mclk / (2 * (clk + 1));
- }
- if (host-hw_designer == 0x80)
- clk |= MCI_FCEN; /* Bug fix in ST IP block */
- clk |= MCI_CLK_ENABLE;
- }
+ u32 pwr = 0;
if (host-plat-translate_vdd)
pwr |= host-plat-translate_vdd(mmc_dev(mmc), ios-vdd);
@@ -464,12 +475,23 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
}
}
- writel(clk, host-base + MMCICLOCK);
+ spin_lock(host-lock);
+
+ if (ios-clock == 0) {
+ clk_disable(host-clk);
+ } else {
+ clk_enable(host-clk);
+ mmci_set_clkreg(host, ios-clock);
+ }
if (host-pwr != pwr) {
host-pwr = pwr;
+ clk_enable(host-clk);
writel(pwr, host-base + MMCIPOWER);
+ clk_disable(host-clk);
}
+
+ spin_unlock(host-lock);
}
static const struct mmc_host_ops mmci_ops = {
@@ -615,6 +637,8 @@ static int __devinit mmci_probe(struct amba_device *dev,
void *id)
host-timer.expires = jiffies + HZ;
add_timer(host-timer);
+ /* The first IOS will turn the clock on again */
+ clk_disable(host-clk);
return 0;
irq0_free:
@@ -646,17 +670,22 @@ static int __devexit mmci_remove(struct amba_device *dev)
mmc_remove_host(mmc);
+ /* framework may have gated the block clock */
+ clk_enable(host-clk);
+
writel(0, host-base + MMCIMASK0);
writel(0, host-base + MMCIMASK1);
writel(0, host-base + MMCICOMMAND);
writel(0, host-base + MMCIDATACTRL);
+ clk_disable(host-clk);
+
free_irq(dev-irq[0], host);
free_irq(dev-irq[1], host);
iounmap(host-base);
- clk_disable(host-clk);
+
clk_put(host-clk);
mmc_free_host(mmc);
@@ -677,8 +706,11 @@ static int mmci_suspend(struct amba_device *dev,
pm_message_t state)
struct mmci_host *host = mmc_priv(mmc);
ret = mmc_suspend_host(mmc, state);
- if (ret == 0)
+ if (ret == 0) {
+ clk_enable(host-clk);
writel(0, host-base + MMCIMASK0);
+ clk_disable(host-clk);
+ }
}
return ret;
@@ -692,7 +724,11 @@ static int
[PATCH 1/2] MMC Agressive clocking framework v4
This patch modified the MMC core code to optionally call the
set_ios() operation on the driver with the clock frequency set
to 0 to gate the hardware block clock (and thus the MCI clock)
for an MMC host controller after a grace period of at least 8
MCLK cycles. It is inspired by existing clock gating code found
in the OMAP and Atmel drivers and brings this up to the host
abstraction. Gating is performed before and after any MMC
request.
It exemplifies by implementing this for the MMCI/PL180 MMC/SD
host controller, but it should be simple to switch OMAP and
Atmel over to using this instead.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
ChangeLog v3-v4:
Fixed a single spelling error.
---
drivers/mmc/core/Kconfig | 11 +++
drivers/mmc/core/core.c| 35 +
drivers/mmc/core/core.h|2 +
drivers/mmc/core/debugfs.c | 10 ++-
drivers/mmc/core/host.c| 165 +++-
drivers/mmc/core/host.h|3 +
include/linux/mmc/host.h |9 +++
7 files changed, 232 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index ab37a6d..5372fc9 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
+config MMC_CLKGATE
+ bool MMC host clock gaing (EXPERIMENTAL)
+ depends on EXPERIMENTAL
+ help
+ This will attempt to agressively gate the clock to the MMC host,
+ which typically also will gate the MCI clock to the card. This
+ is done to save power due to gating off the logic and bus noise
+ when MMC is not in use. Your host driver has to support this in
+ order for it to be of any use.
+
+ If unsure, say N.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2649117..e9093b6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -113,6 +113,8 @@ void mmc_request_done(struct mmc_host *host, struct
mmc_request *mrq)
if (mrq-done)
mrq-done(mrq);
+
+ mmc_clk_disable(host);
}
}
@@ -173,6 +175,7 @@ mmc_start_request(struct mmc_host *host, struct mmc_request
*mrq)
mrq-stop-mrq = mrq;
}
}
+ mmc_clk_enable(host);
host-ops-request(host, mrq);
}
@@ -447,6 +450,38 @@ void mmc_set_clock(struct mmc_host *host, unsigned int hz)
mmc_set_ios(host);
}
+#ifdef CONFIG_MMC_CLKGATE
+/*
+ * This gates the clock by setting it to 0 Hz.
+ */
+void mmc_gate_clock(struct mmc_host *host)
+{
+ host-clk_old = host-ios.clock;
+ host-ios.clock = 0;
+ mmc_set_ios(host);
+}
+
+/*
+ * This restores the clock from gating by using the cached
+ * clock value.
+ */
+void mmc_ungate_clock(struct mmc_host *host)
+{
+ /*
+* We should previously have gated the clock, so the clock
+* shall be 0 here!
+* The clock may however be 0 during intialization,
+* when some request operations are performed before setting
+* the frequency. When ungate is requested in that situation
+* we just ignore the call.
+*/
+ if (host-clk_old) {
+ BUG_ON(host-ios.clock);
+ mmc_set_clock(host, host-clk_old);
+ }
+}
+#endif
+
/*
* Change the bus mode (open drain/push-pull) of a host.
*/
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index c819eff..ee27f81 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -27,6 +27,8 @@ void mmc_detach_bus(struct mmc_host *host);
void mmc_set_chip_select(struct mmc_host *host, int mode);
void mmc_set_clock(struct mmc_host *host, unsigned int hz);
+void mmc_gate_clock(struct mmc_host *host);
+void mmc_ungate_clock(struct mmc_host *host);
void mmc_set_bus_mode(struct mmc_host *host, unsigned int mode);
void mmc_set_bus_width(struct mmc_host *host, unsigned int width);
u32 mmc_select_voltage(struct mmc_host *host, u32 ocr);
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 610dbd1..1a969bd 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -149,11 +149,17 @@ void mmc_add_host_debugfs(struct mmc_host *host)
host-debugfs_root = root;
if (!debugfs_create_file(ios, S_IRUSR, root, host, mmc_ios_fops))
- goto err_ios;
+ goto err_remove_files;
+
+#ifdef CONFIG_MMC_CLKGATE
+ if (!debugfs_create_u32(clk_delay, (S_IRUSR | S_IWUSR),
+ root, host-clk_delay))
+ goto err_remove_files;
+#endif
return;
-err_ios:
+err_remove_files:
debugfs_remove_recursive(root);
host-debugfs_root = NULL;
err_root:
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 5e945e6..792bbfe
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v3
This adds a few clk_enable()/clk_disable() calls to the MMCI
driver so as to handle an set_ios() request with clock
frequency set to 0 as an instruction to gate the block clock.
This also breaks out the clock setting code into its own
function to simplify the set_ios() function a bit.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/host/mmci.c | 78 ++
1 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 36875dc..d9f5c9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -37,8 +37,34 @@
static unsigned int fmax = 515633;
+/*
+ * This must be called with host-lock held
+ */
+static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ u32 clk = 0;
+
+ if (desired) {
+ if (desired = host-mclk) {
+ clk = MCI_CLK_BYPASS;
+ host-cclk = host-mclk;
+ DBG(host, MMCI: bypass clock divider, cclk = %u Hz\n,
host-cclk);
+ } else {
+ clk = host-mclk / (2 * desired) - 1;
+ if (clk = 256)
+ clk = 255;
+ host-cclk = host-mclk / (2 * (clk + 1));
+ DBG(host, MMCI: divide cclk to %u Hz (divide %u by
%u)\n, host-cclk, host-mclk, clk);
+ }
+ if (host-hw_designer == 0x80)
+ clk |= MCI_FCEN; /* Bug fix in ST IP block */
+ clk |= MCI_CLK_ENABLE;
+ }
+ writel(clk, host-base + MMCICLOCK);
+}
+
static void
-mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
+ mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
writel(0, host-base + MMCICOMMAND);
@@ -418,22 +444,7 @@ static void mmci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mmci_host *host = mmc_priv(mmc);
- u32 clk = 0, pwr = 0;
-
- if (ios-clock) {
- if (ios-clock = host-mclk) {
- clk = MCI_CLK_BYPASS;
- host-cclk = host-mclk;
- } else {
- clk = host-mclk / (2 * ios-clock) - 1;
- if (clk = 256)
- clk = 255;
- host-cclk = host-mclk / (2 * (clk + 1));
- }
- if (host-hw_designer == 0x80)
- clk |= MCI_FCEN; /* Bug fix in ST IP block */
- clk |= MCI_CLK_ENABLE;
- }
+ u32 pwr = 0;
if (host-plat-translate_vdd)
pwr |= host-plat-translate_vdd(mmc_dev(mmc), ios-vdd);
@@ -464,12 +475,23 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
}
}
- writel(clk, host-base + MMCICLOCK);
+ spin_lock(host-lock);
+
+ if (ios-clock == 0) {
+ clk_disable(host-clk);
+ } else {
+ clk_enable(host-clk);
+ mmci_set_clkreg(host, ios-clock);
+ }
if (host-pwr != pwr) {
host-pwr = pwr;
+ clk_enable(host-clk);
writel(pwr, host-base + MMCIPOWER);
+ clk_disable(host-clk);
}
+
+ spin_unlock(host-lock);
}
static const struct mmc_host_ops mmci_ops = {
@@ -615,6 +637,8 @@ static int __devinit mmci_probe(struct amba_device *dev,
void *id)
host-timer.expires = jiffies + HZ;
add_timer(host-timer);
+ /* The first IOS will turn the clock on again */
+ clk_disable(host-clk);
return 0;
irq0_free:
@@ -646,17 +670,22 @@ static int __devexit mmci_remove(struct amba_device *dev)
mmc_remove_host(mmc);
+ /* framework may have gated the block clock */
+ clk_enable(host-clk);
+
writel(0, host-base + MMCIMASK0);
writel(0, host-base + MMCIMASK1);
writel(0, host-base + MMCICOMMAND);
writel(0, host-base + MMCIDATACTRL);
+ clk_disable(host-clk);
+
free_irq(dev-irq[0], host);
free_irq(dev-irq[1], host);
iounmap(host-base);
- clk_disable(host-clk);
+
clk_put(host-clk);
mmc_free_host(mmc);
@@ -677,8 +706,11 @@ static int mmci_suspend(struct amba_device *dev,
pm_message_t state)
struct mmci_host *host = mmc_priv(mmc);
ret = mmc_suspend_host(mmc, state);
- if (ret == 0)
+ if (ret == 0) {
+ clk_enable(host-clk);
writel(0, host-base + MMCIMASK0);
+ clk_disable(host-clk);
+ }
}
return ret;
@@ -692,7 +724,11 @@ static int
[PATCH 0/2] MMC Agressive clocking framework v2
ChangeLog v1-v2: * Switch the gating mechanism from using an additional callback to setting the clock field in the ios structure to 0 and storing away the current value to ungate the clock later on. * Remove the mmc_clk_enable/disable around the ios() operations as a result, if you use clock gating you have to take the gating into account in your set_ios() code. * Keep the nesting code (use count) this is used so that quick bursts of requests can be handled properly while the disable work is idling in the background and appears quite solid. Tried my best to clarify why this code look as it does. * Removed unnecessary depend on MMC!=n in the Kconfig, explicit (EXPERIMENTAL) in option description. * Updates MMCI reference implementation to reflect the new use of the clock field. * Remove unnecessary #include clk.h * Added a debugfs file appearing in /mmcN/clk_delay that can be used to trim the delay cycle count to test what happens with different values. * Works fine on my system. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded 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] MMC Agressive clocking framework v2
This patch modified the MMC core code to optionally call the
set_ios() operation on the driver with the clock frequency set
to 0 to gate the hardware block clock (and thus the MCI clock)
for an MMC host controller after a grace period of at least 8
MCLK cycles. It is inspired by existing clock gating code found
in the OMAP and Atmel drivers and brings this up to the host
abstraction. Gating is performed before and after any MMC request
or IOS operation, the other optional host operations will not
ungate/gate the clock since they do not necessary touch the
actual host controller hardware.
It exemplifies by implementing this for the MMCI/PL180 MMC/SD
host controller, but it should be simple to switch OMAP and
Atmel over to using this instead.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/core/Kconfig | 11 +++
drivers/mmc/core/core.c| 38 +++
drivers/mmc/core/core.h|2 +
drivers/mmc/core/debugfs.c | 10 ++-
drivers/mmc/core/host.c| 160 +++-
drivers/mmc/core/host.h|3 +
include/linux/mmc/host.h |9 +++
7 files changed, 230 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index ab37a6d..6ae2156 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
+config MMC_CLKGATE
+ bool MMC host clock gaing (EXPERIMENTAL)
+ depends on EXPERIMENTAL
+ help
+ This will attempt to agressively gate the clock to the MMC host,
+ which typically also will gate the MCI clock to the card. This
+ is done to save power due to gating off the logic and bus noise
+ when MMC is not in use. Your host driver has to support this in
+ order for it to be of any use.
+
+ Of unsure, say N.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2649117..c64dfe2 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -113,6 +113,8 @@ void mmc_request_done(struct mmc_host *host,
struct mmc_request *mrq)
if (mrq-done)
mrq-done(mrq);
+
+ mmc_clk_disable(host);
}
}
@@ -173,6 +175,7 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
mrq-stop-mrq = mrq;
}
}
+ mmc_clk_enable(host);
host-ops-request(host, mrq);
}
@@ -447,6 +450,39 @@ void mmc_set_clock(struct mmc_host *host, unsigned int hz)
mmc_set_ios(host);
}
+#ifdef CONFIG_MMC_CLKGATE
+/*
+ * This gates the clock by setting it to 0 Hz.
+ */
+void mmc_gate_clock(struct mmc_host *host)
+{
+ host-clk_old = host-ios.clock;
+ host-ios.clock = 0;
+ mmc_set_ios(host);
+}
+
+/*
+ * This restores the clock from gating by using the cached
+ * clock value.
+ */
+void mmc_ungate_clock(struct mmc_host *host)
+{
+ /*
+* We have gated previously so the clock
+* shall be 0 here!
+*/
+ BUG_ON(host-ios.clock);
+ /*
+* The clock may however be 0 during intialization,
+* when some request operations are performed before setting
+* the frequency. When ungate is requested in that situation
+* we just ignore the call.
+*/
+ if (host-clk_old)
+ mmc_set_clock(host, host-clk_old);
+}
+#endif
+
/*
* Change the bus mode (open drain/push-pull) of a host.
*/
@@ -861,6 +897,7 @@ void mmc_rescan(struct work_struct *work)
* release the lock here.
*/
mmc_bus_put(host);
+ mmc_clk_enable(host);
if (host-ops-get_cd host-ops-get_cd(host) == 0)
goto out;
@@ -911,6 +948,7 @@ void mmc_rescan(struct work_struct *work)
mmc_bus_put(host);
}
out:
+ mmc_clk_disable(host);
if (host-caps MMC_CAP_NEEDS_POLL)
mmc_schedule_delayed_work(host-detect, HZ);
}
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index c819eff..ee27f81 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -27,6 +27,8 @@ void mmc_detach_bus(struct mmc_host *host);
void mmc_set_chip_select(struct mmc_host *host, int mode);
void mmc_set_clock(struct mmc_host *host, unsigned int hz);
+void mmc_gate_clock(struct mmc_host *host);
+void mmc_ungate_clock(struct mmc_host *host);
void mmc_set_bus_mode(struct mmc_host *host, unsigned int mode);
void mmc_set_bus_width(struct mmc_host *host, unsigned int width);
u32 mmc_select_voltage(struct mmc_host *host, u32 ocr);
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 610dbd1..1a969bd 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -149,11 +149,17 @@ void
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v2
This adds a few clk_enable()/clk_disable() calls to the MMCI
driver so as to handle an set_ios() request with clock
frequency set to 0 as an instruction to gate the block clock.
This also breaks out the clock setting code into its own
function to simplify the set_ios() function a bit.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/host/mmci.c | 78 ++
1 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 36875dc..d9f5c9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -37,8 +37,34 @@
static unsigned int fmax = 515633;
+/*
+ * This must be called with host-lock held
+ */
+static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ u32 clk = 0;
+
+ if (desired) {
+ if (desired = host-mclk) {
+ clk = MCI_CLK_BYPASS;
+ host-cclk = host-mclk;
+ DBG(host, MMCI: bypass clock divider, cclk = %u Hz\n,
host-cclk);
+ } else {
+ clk = host-mclk / (2 * desired) - 1;
+ if (clk = 256)
+ clk = 255;
+ host-cclk = host-mclk / (2 * (clk + 1));
+ DBG(host, MMCI: divide cclk to %u Hz (divide %u by
%u)\n,
host-cclk, host-mclk, clk);
+ }
+ if (host-hw_designer == 0x80)
+ clk |= MCI_FCEN; /* Bug fix in ST IP block */
+ clk |= MCI_CLK_ENABLE;
+ }
+ writel(clk, host-base + MMCICLOCK);
+}
+
static void
-mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
+ mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
writel(0, host-base + MMCICOMMAND);
@@ -418,22 +444,7 @@ static void mmci_request(struct mmc_host *mmc,
struct mmc_request *mrq)
static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mmci_host *host = mmc_priv(mmc);
- u32 clk = 0, pwr = 0;
-
- if (ios-clock) {
- if (ios-clock = host-mclk) {
- clk = MCI_CLK_BYPASS;
- host-cclk = host-mclk;
- } else {
- clk = host-mclk / (2 * ios-clock) - 1;
- if (clk = 256)
- clk = 255;
- host-cclk = host-mclk / (2 * (clk + 1));
- }
- if (host-hw_designer == 0x80)
- clk |= MCI_FCEN; /* Bug fix in ST IP block */
- clk |= MCI_CLK_ENABLE;
- }
+ u32 pwr = 0;
if (host-plat-translate_vdd)
pwr |= host-plat-translate_vdd(mmc_dev(mmc), ios-vdd);
@@ -464,12 +475,23 @@ static void mmci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
}
}
- writel(clk, host-base + MMCICLOCK);
+ spin_lock(host-lock);
+
+ if (ios-clock == 0) {
+ clk_disable(host-clk);
+ } else {
+ clk_enable(host-clk);
+ mmci_set_clkreg(host, ios-clock);
+ }
if (host-pwr != pwr) {
host-pwr = pwr;
+ clk_enable(host-clk);
writel(pwr, host-base + MMCIPOWER);
+ clk_disable(host-clk);
}
+
+ spin_unlock(host-lock);
}
static const struct mmc_host_ops mmci_ops = {
@@ -615,6 +637,8 @@ static int __devinit mmci_probe(struct amba_device
*dev, void *id)
host-timer.expires = jiffies + HZ;
add_timer(host-timer);
+ /* The first IOS will turn the clock on again */
+ clk_disable(host-clk);
return 0;
irq0_free:
@@ -646,17 +670,22 @@ static int __devexit mmci_remove(struct amba_device *dev)
mmc_remove_host(mmc);
+ /* framework may have gated the block clock */
+ clk_enable(host-clk);
+
writel(0, host-base + MMCIMASK0);
writel(0, host-base + MMCIMASK1);
writel(0, host-base + MMCICOMMAND);
writel(0, host-base + MMCIDATACTRL);
+ clk_disable(host-clk);
+
free_irq(dev-irq[0], host);
free_irq(dev-irq[1], host);
iounmap(host-base);
- clk_disable(host-clk);
+
clk_put(host-clk);
mmc_free_host(mmc);
@@ -677,8 +706,11 @@ static int mmci_suspend(struct amba_device *dev,
pm_message_t state)
struct mmci_host *host = mmc_priv(mmc);
ret = mmc_suspend_host(mmc, state);
- if (ret == 0)
+ if (ret == 0) {
+ clk_enable(host-clk);
writel(0, host-base + MMCIMASK0);
+ clk_disable(host-clk);
+ }
}
return ret;
@@ -692,7 +724,11 @@ static int mmci_resume(struct
Re: conceptual map of the kernel source (Interactive Linux kernel map)
2008/7/31 Constantine Shulyupin [EMAIL PROTECTED]: I am updating the kernel map: http://www.makelinux.net/kernel_map It is conceptual map consisting of more than 200 most important kernel functions. I was very impressed once I saw this map first, which was through your (?) contributions to the Linux entries in Wikipedia. Keep up the good work! Could you please have a look and suggest fixes and updates. The embedded systems will be interested in most things not asm-i386 and arch-i386. For example you show a lot of PCI and such things in the lowest layers, I wonder if it'd be worth the effort to make arch-specific views of the lowermost parts (but probably not). Another this is that flash drivers MTD, doesn't fit into the picture, instead harddisk is uses as example. Linus -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: building Rootfs
2008/7/8 Wolfgang Denk [EMAIL PROTECTED]: 3. Getting files into the filesystem when the development system does not allow root access. 3. is a non-issue for most common file systems. The only one thing I ever ran into trouble with was device nodes, these cannot be reproduced any way, not even with fakeroot environments, just in scratchbox, which in turn needs you to be root. initramfs etc can handle it with special description files. But if you want to cook up say a .tar file of your rootfs, you're pretty much lost AFAIK. The good thing is that you don't need the device nodes if you have udev, I think the kernel wants /dev/console and a few more at boot but actually it survives just fine without them. The rest is possible to create with fakeroot and clever scripting if I'm not mistaken. If you know some way of sneaking a device node into a .tar file created ENTIRELY running as a regular user, tell me! Linus -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: building Rootfs
2008/7/7 Robert Schwebel [EMAIL PROTECTED]: On Mon, Jul 07, 2008 at 10:34:11PM +0200, Linus Walleij wrote: Robert, can you brief us of how ptxdist fits together with OpenEmbedded? What does these two projects actually share? Where do they do similar things in parallel for example? They are both build systems for userlands, or whole embedded linux systems. I cannot speak for OE as I don't really know it in detail. Anyone have experience with both? I'd really like to have them contrasted and, well you know, cross-firtualized. The idea behind ptxdist is executable documentation. I really like ptxdist, especially it is beautiful that you have based it around just bash and make plus some crosscompiler of choice. I just have some trouble getting it to do what I want. I'll hopefully get there. This is not meant as any generic complaining. I'm trying to figure out if ptxdist or openembedded is the best starting point. I have a situation where the build system would be on top of some SCM like git, CVS or whatever and packages being checked out and worked on by several people daily. This seems to clash with ptxdist design goals, for example: ptxdist seems * hardcoded to run in a users home directory with projects in $HOME/foo (stopped me right now, perhaps it can easily be fixed or is already part of ptxdist 2?) * assume only one person builds rootfs. So it doesn't really want the project tree to be used or modified by more than one person at the time. (Same as first more or less.) * not store source code, patches and config plus my local additions in one place. For most other package systems e.g. RPM there is /foo/foo.spec /foo/foo-1.0.tar.gz /foo/foo-patch1.diff /foo/foo-patch2.diff /foo/my-foo-config.file In ptxdist these seem to be spread out, some in the installation of ptxdist itself in say /usr/lib/ptxdist/patches, /usr/lib/ptxdist/... then in my project space $HOME/project/... etc. I believe at archivicing time everything including ptxdist itself is zipped up and archived on one storage media. But I need to keep all files relating to a package in one place while developing, and living like that for a long time. Since /usr/lib/ptxdist isn't even being backed up normally, only NFS mounts like /home, I then need to move the entire ptxdist into the SCM, which it clearly doesn't like without a lot of hacking, plus, how would I upgrade it? OK this is a bit picky. And perhaps I can fix it all and merge back. Just trying to decide. Linus -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: building Rootfs
OK Robert wrote this on ARM-Linux mailinglist but the discussion belongs on linux-embedded, so I'm moving it there, the suggested ptxdist ML seems inapropriate for the entire embedded community. 2008/7/7 Robert Schwebel [EMAIL PROTECTED]: On Mon, Jul 07, 2008 at 06:01:51PM +0800, Eric Miao wrote: or start from buildroot, scratchbox and openembedded as a tool, you've really got a lot to learn :-) Or ptxdist, or course :-) Robert, can you brief us of how ptxdist fits together with OpenEmbedded? What does these two projects actually share? Where do they do similar things in parallel for example? I'm trying - real hard - to get an idea of how people out there prefer to build their root filesystems in cross-compiled environments. Rob Landley recently wrote up a small blurb on why native compilation is the way to go, and a small roadmap on how he intended to get there using e.g. Qemu and Firmware Linux, c.f: http://www.landley.net/code/firmware/about.html which finally won me over to that line of thinking. Debian and friends obviously go this way now. However, when it comes to the widespread and much fragmented ways of cross-compiling a rootfs, including the stuff put together by MontaVista, WR and all those animals in the forest, obviously based on RPM (build systems I haven't put my hands inside, since they are proprietary) there seems to be very little consensus. ptxdist stands out but do you get a lot of outside contributions for it? As it looks it seems you're running it yourself. (Beware: I haven't looked close.) What else is there out there for rootfs, really? A hack from every embedded company there is? I'm more after what people actually *use* and what is community driven here, not so much opinions on what is best (which will probably be the unwanted side effect of this mail anyway...) Linus -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
modules.dep and depmod.pl
Hi, what are other embedded developers experience with using the script depmod.pl from BusyBox to create installdir/lib/modules/version/modules.dep during compile-time? (It's this beast: http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/examples/depmod.pl?rev=20447view=markup I tried this thing to be able to modprobe off a read-only flash rootfilesystem and it sort of works, actually. However there is no way you will pass this to the kernel DEPMOD parameter, I only ever get this to work when doing it after compilation, as a separate step. Is there anyone beside me who would like to see this integrated into scripts/ in the kernel to get some default modules.dep for a read-only rootfs also when doing cross compilation, or am I totally going down the wrong lane here? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
