* Re: commit 432dc821 breaks machines
From: David Woodhouse @ 2010-10-27 8:31 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-mtd, H Hartley Sweeten, linux-embedded
In-Reply-To: <Pine.LNX.4.64.1010270842580.7190@axis700.grange>
On Wed, 27 Oct 2010, Guennadi Liakhovetski wrote:
> Hi
>
> commit 432dc821c90114f9b0e00f6752a700e937516ade
> Author: H Hartley Sweeten <hartleys@visionengravers.com>
> Date: Thu Aug 19 18:18:21 2010 -0700
>
> mtd: cleanup Kconfig dependencies
>
> breaks machines by undefining macros like CONFIG_MTD_MAP_BANK_WIDTH_*.
Thanks. This should be fixed in today's linux-next.
--
dwmw2
^ permalink raw reply
* commit 432dc821 breaks machines
From: Guennadi Liakhovetski @ 2010-10-27 6:52 UTC (permalink / raw)
To: linux-mtd; +Cc: H Hartley Sweeten, linux-embedded
Hi
commit 432dc821c90114f9b0e00f6752a700e937516ade
Author: H Hartley Sweeten <hartleys@visionengravers.com>
Date: Thu Aug 19 18:18:21 2010 -0700
mtd: cleanup Kconfig dependencies
breaks machines by undefining macros like CONFIG_MTD_MAP_BANK_WIDTH_*.
Previously the Kconfig entries like
config MTD_MAP_BANK_WIDTH_1
bool "Support 8-bit buswidth" if MTD_CFI_GEOMETRY
default y
meant, that if MTD_CFI_GEOMETRY is not selected, this config entry is not
_displayed_, and default selections are used. Now, with that "if" removed
and all these Kconfig entries put under a common
if MTD_CFI_GEOMETRY
none of these options get selected by default. Please, revert or otherwise
fix this part.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: How to spin down the SATA hard drive on ARM target (Open-RD)?
From: Pawel Suchanecki @ 2010-10-25 16:35 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <AANLkTinzVGgsCRuqdShJbCLO-CGFGd_Pt-jeYMZV1+sh@mail.gmail.com>
> How can this happen that hdparm replies with IO error when the device
> is there (and serving a working filesystem) ?
Guys,
I had a feeling to test hdparm -t/-T but it confuses me even more:
hdparm -t /dev/sda <and> hdparm -T /dev/sda
seem to work, providing reasonable stats.
Here is the output from the latter one:
root@XXXX:~# hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 436 MB in 2.01 seconds = 217.11 MB/sec
Any clues?
--
Robotics engineer * GNU generation member
Linux reg. user # 145057 * Open BSD secured
Perl programmer * C coder * Firmware engineer
^ permalink raw reply
* Re: How to spin down the SATA hard drive on ARM target (Open-RD)?
From: Pawel Suchanecki @ 2010-10-25 16:24 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <AANLkTim6xmfWSF92GzenqfYOgzjj73TF6wS7QM06T=Ps@mail.gmail.com>
Hello again,
I post an update below the original.
2010/10/25 Pawel Suchanecki <subdcc@gmail.com>:
> Dear list,
>
> I am trying to achieve the HDD _simple_ power saving function on
> Open-RD Client device, running Linux 2.6.22 / 2.6.36.
>
> The simplification is that I just need to spin the disk down and then
> sit quietly waiting for IC2 port expander's IRQ (button press) to
> reboot the system.
>
> Is the `sg_stat --stop' command from sg3_utils package capable of
> performing the disk spin down for SATA device (WD) on this armish
> platform?
> If not, please direct me to proper solution.
>
> Is it feasible running full power saving mode (i.e. using spindown
> daemon [1]) to be able to wake the hard disk and resume normal system
> operation?
I forgot to mention that the standard approach (i.e. hdparm -y / -Y )
does not work for me:
root@XXXX:~# df -h | grep -E "Filesystem|sda"
Filesystem Size Used Avail
Use% Mounted on
/dev/sda1 344G 26G 305G
8% /mnt/disk
root@XXXX:~# hdparm -y /dev/sda1
/dev/sda1:
issuing standby command
HDIO_DRIVE_CMD(standby) failed: Input/Output error
root@XXXX:~# hdparm -Y /dev/sda1
/dev/sda1:
issuing sleep command
HDIO_DRIVE_CMD(sleep) failed: Input/Output error
root@XXXX:~# hdparm -I /dev/sda1
/dev/sda:
HDIO_DRIVE_CMD(indentify) failed: Input/Output error
Using sdparm I get the device model instead of the command executed as
in this request:
root@XXXX:~# sdparm -C stop /dev/sg0
/dev/sg0: WDC WD3000BLFS-01YBU 04.0
Also as you already may noticed, the hard drive itself is WDC VelociRaptor.
Is it possible that the VelociRaptor -- due to being targeted at the
enterprise market -- does not support power saving functions?
How can this happen that hdparm replies with IO error when the device
is there (and serving a working filesystem) ?
Thanks,
Pawel.
^ permalink raw reply
* How to spin down the SATA hard drive on ARM target (Open-RD)?
From: Pawel Suchanecki @ 2010-10-25 10:47 UTC (permalink / raw)
To: linux-embedded
Dear list,
I am trying to achieve the HDD _simple_ power saving function on
Open-RD Client device, running Linux 2.6.22 / 2.6.36.
The simplification is that I just need to spin the disk down and then
sit quietly waiting for IC2 port expander's IRQ (button press) to
reboot the system.
Is the `sg_stat --stop' command from sg3_utils package capable of
performing the disk spin down for SATA device (WD) on this armish
platform?
If not, please direct me to proper solution.
Is it feasible running full power saving mode (i.e. using spindown
daemon [1]) to be able to wake the hard disk and resume normal system
operation?
Thank you in advance,
Pawel.
[1] http://code.google.com/p/spindown/
--
Robotics engineer * GNU generation member
Linux reg. user # 145057 * Open BSD secured
Perl programmer * C coder * Firmware engineer
^ permalink raw reply
* Re: Embedded Linux Boot Time Poll
From: Andrew Murray @ 2010-10-24 16:01 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <AANLkTi=YBzPDG6nOmQfegGOT+8nXm_6EKJE_L2uswxeu@mail.gmail.com>
Hi,
Thanks all for your very valuable input. This seems to be an
interesting topic that generates a lot of interest!
I've updated my statement - does this reflect your views?
"Given an unoptimised system based on embedded Linux with a clearly
defined purpose - The amount of boot time it takes to reach that
required state of functionality can be reduced by specialising the
software stack to those needs. Specialisation may involve
removing/deferring unrequired functionality/support and optimising
required functionality."
I've emphasised the focus of the statement to refer to a Linux based
system and so by doing this optimisation then refers to the system as
a whole including bootloaders, choice of filesystems, user space
initialisation, etc.
I've also defined boot time as the amount of time required to reach a
useful state of functionality - in other words meeting only the needs
of the application which provides the products purpose.
By remove functionality/support - I mean removing support for device
drivers not required and also removing unused functionality (which may
be things like removing kallsyms, ipautoconfig, printk support, etc).
And by 'optimise required functionality' - I think this can have a
broad meaning and include system design decisions such as how
userspace is initialised - e.g. the app could be the init process,
optimising flash timings, using a more optimal filesystem, removing
probes (if you know the hardware will always been there), etc.
And I've tried to use relative terms rather than absolute terms - so
the comparison is against an unoptimised system (e.g. perhaps a
customer has a pre-provided BSP and they have little knowledge of how
to optimise it and remove things via KConfig etc).
Thanks,
Andrew Murray
On 22 October 2010 00:20, Andrew Murray <amurray@mpcdata.com> wrote:
> Hello,
>
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] takes so long in the first place for an unoptimised system:
>
> "Linux is general purpose, convenient and flexible. As it's general
> purpose it's likely to contain un-required functionality which results
> in more initialisation and a larger image size. As it's convenient and
> flexible it will spent time discovering devices and verifying their
> existence."
>
> Do you largely agree or disagree?
> Also do you believe that boot time isn't the highest priority when it
> comes to improving the kernel?
>
> Thanks,
>
> Andrew Murray
>
--
Andrew Murray, Embedded Linux Group
MPC Data Limited
e-mail: amurray@mpc-data.co.uk web: www.mpc-data.co.uk
tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601
ddi: +44 (0) 1225 710665
MPC Data Limited is a company registered in England and Wales with
company number 05507446
Registered Address: County Gate, County Way, Trowbridge, Wiltshire, BA14 7FJ
VAT no: 850625238
The information in this email and in the attached documents is
confidential and may be
legally privileged. Any unauthorized review, copying, disclosure or
distribution is
prohibited and may be unlawful. It is intended solely for the
addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, please
contact the sender by reply email and destroy all copies of the
original message. When
addressed to our clients any opinions or advice contained in this
email is subject to
the terms and conditions expressed in the governing contract.
^ permalink raw reply
* Re: Embedded Linux Boot Time Poll
From: Robert Schwebel @ 2010-10-24 10:17 UTC (permalink / raw)
To: Andrew Murray; +Cc: linux-embedded
In-Reply-To: <AANLkTi=YBzPDG6nOmQfegGOT+8nXm_6EKJE_L2uswxeu@mail.gmail.com>
Hello Andrew,
On Fri, Oct 22, 2010 at 12:20:50AM +0100, Andrew Murray wrote:
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] takes so long in the first place for an unoptimised system:
>
> "Linux is general purpose, convenient and flexible. As it's general
> purpose it's likely to contain un-required functionality which results
> in more initialisation and a larger image size. As it's convenient and
> flexible it will spent time discovering devices and verifying their
> existence."
>
> Do you largely agree or disagree? Also do you believe that boot time
> isn't the highest priority when it comes to improving the kernel?
I second what the others have already written. With a resonably tuned
system it is possible to gain boot times of < 0.5 s into the Linux
userspace on a 532 MHz MX35 (ARM1136).
What highly matters if the use case, which in turn influences what can
be done to decrease the boot time.
- If a distribution is tuned to "run everywhere", it has to do a lot of
probing, which needs time (i.e. a general purpose distribution on an
ARM or PowerPC). In turn, you can easily install almost everything on
such a system
- If a system can be optimized for a special scenario (i.e. a machine
operator terminal), you can configure away almost all unrequired
functionality. In turn, it may be difficult to install random software
parts on such a system.
It's more a matter of paradigms.
I assume we'll have nice boot time discussons at ELC-E, I also have a
talk there concering this topic :-)
rsc
--
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-5555 |
^ permalink raw reply
* Re: Linux Plumbers Embedded microconference
From: Grant Likely @ 2010-10-23 1:03 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, Jeremy Kerr, Tim Bird, Scott Wood, linux-embedded,
Liam Girdwood, Loïc Minier, John Linn, Becky Bruce,
Kumar Gala, Paul Walmsley, Ohad Ben-Cohen, Magnus Damm
In-Reply-To: <20101016035058.GD21170@angua.secretlab.ca>
Hi all,
Here is a very early draft of the agenda for the embedded track at the
Linux Plumbers Conference on Nov 3-5th. Don't make any decisions
based on this, and I'll be talking to some of you individually about
the details, but this gives you an idea of what I'm thinking.
http://wiki.linuxplumbersconf.org/2010:embedded_topics
Cheers,
g.
On Fri, Oct 15, 2010 at 9:50 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Oct 15, 2010 at 09:20:28AM -0700, Kevin Hilman wrote:
>> Hi Grant,
>>
>> Do you have a draft agenda yet for the microconf? Specifically, I'd
>> like to get a better feel for how much time we'll dedicate to each
>> topic, and therefore be better prepared for the discussions.
>
> Working on it. RealSoonNow.
>
>> Also, some TI folks are asking me if I know whether the AMP topic is
>> going to be discussed. TI is actively working on this and would like to
>> participate in any discussions. Their 1st generation code for this is
>> in staging (tidspbridge) while the 2nd generation is under active
>> deveopment with some of the lead developers planning to be at LPC.
>
> Yes, AMP is absolutely on the agenda. It seems to be a big topic for
> a lot of folks.
>
> g.
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Embedded Linux Boot Time Poll
From: Chris Simmonds @ 2010-10-22 15:33 UTC (permalink / raw)
To: Andrew Murray; +Cc: linux-embedded
In-Reply-To: <AANLkTi=YBzPDG6nOmQfegGOT+8nXm_6EKJE_L2uswxeu@mail.gmail.com>
On 22/10/10 00:20, Andrew Murray wrote:
> Hello,
>
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] takes so long in the first place for an unoptimised system:
>
> "Linux is general purpose, convenient and flexible. As it's general
> purpose it's likely to contain un-required functionality which results
> in more initialisation and a larger image size. As it's convenient and
> flexible it will spent time discovering devices and verifying their
> existence."
>
> Do you largely agree or disagree?
> Also do you believe that boot time isn't the highest priority when it
> comes to improving the kernel?
>
> Thanks,
>
> Andrew Murray
From my experience, your statements are broadly correct. As has been
pointed out, there are techniques to optimise the boot time in a system,
but they are not very well known to the majority of engineers working on
embedded Linux devices. The situation is not helped by the poor choices
made by many board and chip level vendors who bundle a Linux tool chain
and rootfs with their hardware. So, I believe that it is mostly a
problem of education, starting with the chip- and board- vendors.
Bye for now
Chris Simmonds
^ permalink raw reply
* Re: Embedded Linux Boot Time Poll
From: alucero @ 2010-10-22 15:01 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <AANLkTi=YBzPDG6nOmQfegGOT+8nXm_6EKJE_L2uswxeu@mail.gmail.com>
Hi Andy,
Talking about boot time with Linux needs to cover how user space
initialization is done. I'm talking about init runlevels and all of
this inherited functionality from System V. This is a software issue
and although it worked fine for years in servers and desktop systems,
it is not the right option for embedded systems dedicated to final
users like mobile phones, cameras, minilaptos, tablets, ... .
As you probably know, there are people working in this specific part
trying to improve the way Linux is doing this things like avoiding
shell scripts as much as possible and doing things in parallel when
dependencies do not exist.
By other hand, some embedded systems, those gaining main attention,
are clearly closer to generic purpose Linux systems as we know them
and it will be even more difuse in the close future. But generic
purpose and boot time reduction should not be incompatible.
Andrew Murray <amurray@mpcdata.com> ha escrito:
> Hello,
>
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] takes so long in the first place for an unoptimised system:
>
> "Linux is general purpose, convenient and flexible. As it's general
> purpose it's likely to contain un-required functionality which results
> in more initialisation and a larger image size. As it's convenient and
> flexible it will spent time discovering devices and verifying their
> existence."
>
> Do you largely agree or disagree?
> Also do you believe that boot time isn't the highest priority when it
> comes to improving the kernel?
>
> Thanks,
>
> Andrew Murray
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Embedded Linux Boot Time Poll
From: Steven J. Magnani @ 2010-10-22 14:24 UTC (permalink / raw)
To: Andrew Murray, linux-embedded
In-Reply-To: <AANLkTi=YBzPDG6nOmQfegGOT+8nXm_6EKJE_L2uswxeu@mail.gmail.com>
Andrew Murray <amurray@mpcdata.com> wrote:
> Hello,
>
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] takes so long in the first place for an unoptimised system:
>
> "Linux is general purpose, convenient and flexible. As it's general
> purpose it's likely to contain un-required functionality which
> results in more initialisation and a larger image size.
I think if you are going to use "more" and "larger" you need to define
your point of comparison. i.e., vs. bare metal? eCos? WinCE? An
incandescent light bulb? :)
Kconfig goes a long way towards allowing developers to prune extraneous
code from the kernel. Also great pains have been taken to optimize away
calls that aren't needed in certain configurations (i.e. spinlocks on
uniprocessor systems).
> As it's convenient and flexible it will spent time discovering devices
> and verifying their existence."
>
> Do you largely agree or disagree?
I largely disagree mainly because I don't think anyone would use an
"unoptimised" kernel in an embedded device. Kernels can be built to look
for only the subset of devices the system supports (platform bus, device
tree, etc.).
> Also do you believe that boot time isn't the highest priority when it
> comes to improving the kernel?
There was some discussion of this at ELC 2009. Andre Puschmann gave a
presentation which you can find here:
http://tree.celinuxforum.org/CelfPubWiki/ELC2009Presentations?action=AttachFile&do=view&target=ELC09_boottime_reduction.pdf
Different classes of embedded devices may have different priorities. In
some cases there are regulatory requirements; David Woodhouse pointed
out that for mobile phones, it must be possible to make an emergency
call within X seconds. In other cases the question is one of "user
experience"; for devices like an iTouch, users can become accustomed to
a relatively 'long' boot. In other cases users expect a device to behave
like an incandescent light and be usable more or less immediately, and
have a frustration level that increases exponentially with
time-until-usability.
It might help the discussion to consider some alternative priorities.
Many of these have a userland dimension.
* Stability (i.e. MTBF for long-running systems)
* Power management
* Robustness against sudden removal of power
* Shutdown time
* Solid-state storage
* Security
* Field failure analysis (i.e. crash dumps)
* Others?
For the product I'm involved with, robustness is probably the top
concern, with boot time a close second.
Regards,
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply
* Reading the temperature from another module
From: Matthias Dunda @ 2010-10-22 8:02 UTC (permalink / raw)
To: linux-embedded
Hi everybody,
I wrote some drivers for an embedded box. In one of these drivers I need the current system temperature.
My system works with the jc42.c driver and I can read the temperature perfectly via the proc filesystem in user space.
How do I query the temperature from another kernel driver?
First of all I added a new function and exported the symbol
int jc42_get_temperature()
{
int temp;
// TODO get the correct temp
temp = jc42_read_value(my_local_client, JC42_REG_TEMP);
return temp;
}
EXPORT_SYMBOL(jc42_get_temperature);
BUT: how do I get the temp? Most of the internal functions require a struct device or a struct i2c_client, which - I assume - are perfectly provided by the kernel when going the way over the proc file system.
I tried to statically save such a struct during the probing process (this is the above my_local_client), but this works neither. When I use the saved struct to call jc42_read_value, I always get a temperature value which is not correct at all.
Kernel is 2.6.29.6-rt24 (yes, jc42 is originally not included there - we ported it from a newer kernel release.)
Thanks for any help!
Matthias
^ permalink raw reply
* Re: Embedded Linux Boot Time Poll
From: Nicolas Pitre @ 2010-10-22 1:57 UTC (permalink / raw)
To: Andrew Murray; +Cc: linux-embedded
In-Reply-To: <AANLkTi=YBzPDG6nOmQfegGOT+8nXm_6EKJE_L2uswxeu@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2903 bytes --]
On Fri, 22 Oct 2010, Andrew Murray wrote:
> Hello,
>
> I'm performing some research [for a CELF presentation] into reducing
> boot time on embedded systems and would like to see if the embedded
> community agree with the following statement as to why Linux
> [arguably] takes so long in the first place for an unoptimised system:
>
> "Linux is general purpose, convenient and flexible. As it's general
> purpose it's likely to contain un-required functionality which results
> in more initialisation and a larger image size. As it's convenient and
> flexible it will spent time discovering devices and verifying their
> existence."
>
> Do you largely agree or disagree?
I agree with the above, as long as the "unoptimized" keyword is also
included in that statement. By nature, embedded systems are normally
well defined and the kernel build configuration options are sufficiently
detailed so that a highly optimized kernel with only the
required functionalities can be easily produced.
> Also do you believe that boot time isn't the highest priority when it
> comes to improving the kernel?
Well, I don't think the kernel itself needs to be much improved for boot
time. This is more a system design issue nowadays i.e. optimizing the
kernel configuration, proper partitioning of drivers between modules and
built-in, selection of a storage media for the kernel image to boot,
bootloader optimizations, user space optimizations, etc. It is well
possible to achieve a short kernel boot to start interaction with the
user quickly, and postpone the probing of peripherals such as USB
devices in the background only when user space is started.
That also depends on what your definition of "boot time" is. Is it the
time from power up to the moment when user space starts executing? Or
is it the time before the system is fully operational? And what is the
meaning of "fully operational"? Is it when the display is working and
user input is possible, or is it when network connectivity is fully
established? And even then, does "network connectivity fully
established" mean that the link is up with an IP address, or does this
mean that you are connected to a specific application server or a
particular web site with the required data downloaded? This is not as
straight forward as it may seem.
If boot time is only the time required for user space to start
executing, then on some embedded system this can be made to work in less
than a second. Is this criterion (from power up to user space) useful?
That depends on the application.
Nicolas
>
> Thanks,
>
> Andrew Murray
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Embedded Linux Boot Time Poll
From: Andrew Murray @ 2010-10-21 23:20 UTC (permalink / raw)
To: linux-embedded
Hello,
I'm performing some research [for a CELF presentation] into reducing
boot time on embedded systems and would like to see if the embedded
community agree with the following statement as to why Linux
[arguably] takes so long in the first place for an unoptimised system:
"Linux is general purpose, convenient and flexible. As it's general
purpose it's likely to contain un-required functionality which results
in more initialisation and a larger image size. As it's convenient and
flexible it will spent time discovering devices and verifying their
existence."
Do you largely agree or disagree?
Also do you believe that boot time isn't the highest priority when it
comes to improving the kernel?
Thanks,
Andrew Murray
^ permalink raw reply
* Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-10-21 13:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-embedded
In-Reply-To: <AANLkTik-stsHoEcpJkuszFxyrVPjvEy3iMNkovX_kzXe@mail.gmail.com>
Grant:
On Wed, Oct 20, 2010 at 2:32 PM, Bill Gatliff <bgat@billgatliff.com> wrote:
>> Yeah, by changing to using class attributes, a lot of this could end
>> up going away.
>
> Looking at that now, in fact.
Going to class device attributes did the trick. Thanks for pointing
me in the right direction!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Generic PWM git tree rebased; please resend me your patches
From: Bill Gatliff @ 2010-10-21 13:14 UTC (permalink / raw)
To: linux-embedded, Arun Murthy, sugumar
Guys:
I have a public git tree of my generic PWM framework code here:
git://git.billgatliff.com/pwm.git
I have rebased my series against linux-2.6.36, and also cleaned up a
bunch of stuff based on reviewer feedback. I think I have also make
things such that the existing PWM kernel code can coexist with my
framework, giving us less breakage and more time to migrate things to
the new API.
Many of you have been sending me code against the patch series I
posted here a few weeks ago, and I really do appreciate that. Please
rebase your patches against the above repository and resend (or send
me a pull request). I'm trying to get all of your patches merged, but
many of them aren't going in without conflicts. Sorry for the extra
work.
Thanks very much!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 01/16] pramfs: documentation
From: Marco Stornelli @ 2010-10-21 10:51 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird
In-Reply-To: <20101020125459.c183c286.randy.dunlap@oracle.com>
2010/10/20 Randy Dunlap <randy.dunlap@oracle.com>:
> On Sun, 10 Oct 2010 18:27:34 +0200 Marco Stornelli wrote:
>
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> Documentation for PRAMFS.
>>
>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>> ---
Ack for all the remarks, thank for the review.
Regards,
Marco
^ permalink raw reply
* Re: [PATCH 01/16] pramfs: documentation
From: Randy Dunlap @ 2010-10-20 19:54 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux Kernel, Linux Embedded, Linux FS Devel, Tim Bird
In-Reply-To: <4CB1E976.7080607@gmail.com>
On Sun, 10 Oct 2010 18:27:34 +0200 Marco Stornelli wrote:
> From: Marco Stornelli <marco.stornelli@gmail.com>
>
> Documentation for PRAMFS.
>
> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
> ---
> diff -Nurp linux-2.6.36-orig/Documentation/filesystems/pramfs.txt linux-2.6.36/Documentation/filesystems/pramfs.txt
> --- linux-2.6.36-orig/Documentation/filesystems/pramfs.txt 1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.36/Documentation/filesystems/pramfs.txt 2010-09-25 15:10:41.000000000 +0200
> @@ -0,0 +1,295 @@
> +
> +PRAMFS Overview
> +===============
> +
> +Many embedded systems have a block of non-volatile RAM seperate from
separate
> +normal system memory, i.e. of which the kernel maintains no memory page
> +descriptors. For such systems it would be beneficial to mount a
> +fast read/write filesystem over this "I/O memory", for storing frequently
> +accessed data that must survive system reboots and power cycles. An
> +example usage might be system logs under /var/log, or a user address
> +book in a cell phone or PDA.
> +
> +Linux traditionally had no support for a persistent, non-volatile RAM-based
> +filesystem, persistent meaning the filesystem survives a system reboot
> +or power cycle intact. The RAM-based filesystems such as tmpfs and ramfs
> +have no actual backing store but exist entirely in the page and buffer
> +caches, hence the filesystem disappears after a system reboot or
> +power cycle.
> +
> +A relatively straight-forward solution is to write a simple block driver
straightforward
> +for the non-volatile RAM, and mount over it any disk-based filesystem such
> +as ext2, ext3, ext4, etc.
> +
> +But the disk-based fs over non-volatile RAM block driver approach has
> +some drawbacks:
> +
> +1. Complexity of disk-based fs: disk-based filesystems such as ext2/ext3/ext4
> + were designed for optimum performance on spinning disk media, so they
> + implement features such as block groups, which attempts to group inode data
> + into a contiguous set of data blocks to minimize disk seeking when accessing
> + files. For RAM there is no such concern; a file's data blocks can be
> + scattered throughout the media with no access speed penalty at all. So block
> + groups in a filesystem mounted over RAM just adds unnecessary
> + complexity. A better approach is to use a filesystem specifically
> + tailored to RAM media which does away with these disk-based features.
> + This increases the efficient use of space on the media, i.e. more
> + space is dedicated to actual file data storage and less to meta-data
> + needed to maintain that file data.
> +
> +2. Different problems between disks and RAM: Because PRAMFS attempts to avoid
> + filesystem corruption caused by kernel bugs, dirty pages in the page cache
> + are not allowed to be written back to the backing-store RAM. This way, an
> + errant write into the page cache will not get written back to the filesystem.
> + However, if the backing-store RAM is comparable in access speed to system
> + memory, the penalty of not using caching is minimal. With this consideration
> + better to move file data directly between the user buffers and the backing
it is better (?)
> + store RAM, i.e. use direct I/O. This prevents the unnecessary populating of
> + the page cache with dirty pages. However direct I/O has to be enabled at
> + every file open. To enable direct I/O at all times for all regular files
> + requires either that applications be modified to include the O_DIRECT flag on
> + all file opens, or that the filesystem used performs direct I/O by default.
> +
> +The Persistent/Protected RAM Special Filesystem (PRAMFS) is a read/write
> +filesystem that has been designed to address these issues. PRAMFS is targeted
> +to fast I/O memory, and if the memory is non-volatile, the filesystem will be
> +persistent.
> +
> +In PRAMFS, direct I/O is enabled across all files in the filesystem, in other
> +words the O_DIRECT flag is forced on every open of a PRAMFS file. Also, file
> +I/O in the PRAMFS is always synchronous. There is no need to block the current
> +process while the transfer to/from the PRAMFS is in progress, since one of
> +the requirements of the PRAMFS is that the filesystem exist in fast RAM. So
exists
> +file I/O in PRAMFS is always direct, synchronous, and never blocks.
> +
> +The data organization in PRAMFS can be thought of as an extremely simplified
> +version of ext2, such that the ratio of data to meta-data is very high.
> +
> +PRAMFS supports the execute-in-place. With Xip, instead of keeping data in the
supports execute-in-place. With XIP,
> +page cache, the need to have a page cache copy is eliminated completely.
> +Read&write type operations are performed directly from/to the memory. For file
Read & write
> +mappings, the RAM itself is mapped directly into userspace. Xip, in addition,
XIP,
> +speed-up the applications start-up time because it removes the needs of any
speeds up
> +copies.
> +
> +PRAMFS is write protected. The page table entries that map the backing-store
> +RAM are normally marked read-only. Write operations into the filesystem
> +temporarily mark the affected pages as writeable, the write operation is
> +carried out with locks held, and then the pte is marked read-only again.
s/pte/page table entry/
> +This feature provides protection against filesystem corruption caused by errant
> +writes into the RAM due to kernel bugs for instance. In case there are systems
> +where the write protection is not possible (for instance the RAM cannot be
> +mapped with page tables), this feature can be disabled via
via the
> +CONFIG_PRAMFS_WRITE_PROTECT config option.
> +
> +PRAMFS supports extended attributes, ACLs and security labels.
> +
> +In summary, PRAMFS is a light-weight, space-efficient special filesystem that
> +is ideal for systems with a block of fast non-volatile RAM that need to access
> +data on it using a standard filesytem interface.
> +
> +Supported mount options
> +=======================
> +
> +The PRAMFS currently requires one mount option, and there are several
> +optional mount options:
> +
> +physaddr= Required. It tells PRAMFS the physical address of the
> + start of the RAM that makes up the filesystem. The
> + physical address must be located on a page boundary.
> +
> +init= Optional. It is used to initialize the memory to an
> + empty filesystem. Any data in an existing filesystem
> + will be lost if this option is given. The parameter to
> + "init=" is the RAM in kilo/mega/giga bytes.
> +
> +bs= Optional. It is used to specify a block size. It is
> + ignored if the "init=" option is not specified, since
> + otherwise the block size is read from the PRAMFS
> + super-block. The default blocksize is 2048 bytes,
> + and the allowed block sizes are 512, 1024, 2048, and
> + 4096.
> +
> +bpi= Optional. It is used to specify the bytes per inode
> + ratio, i.e. For every N bytes in the filesystem, an
for
> + inode will be created. This behaves the same as the "-i"
> + option to mke2fs. It is ignored if the "init=" option is
> + not specified.
> +
> +N= Optional. It is used to specify the number of inodes to
> + allocate in the inode table. If the option is not
> + specified, the bytes-per-inode ratio is used the
is used to
> + calculate the number of inodes. If neither the "N=" or
> + "bpi=" options are specified, the default behavior is to
> + reserve 5% of the total space in the filesystem for the
> + inode table. This option behaves the same as the "-N"
> + option to mke2fs. It is ignored if the "init=" option is
> + not specified.
> +
> +Examples:
> +
> +mount -t pramfs -o physaddr=0x20000000,init=1M,bs=1k none /mnt/pram
> +
> +This example locates the filesystem at physical address 0x20000000, and
> +also requests an empty filesystem be initialized, of total size of one
> +megabytes and blocksize of one kilobytes. The mount point is /mnt/pram.
I would use "megabyte" and "kilobyte" since there is only "one" of each of them.
> +
> +mount -t pramfs -o physaddr=0x20000000 none /mnt/pram
> +
> +This example locates the filesystem at physical address 0x20000000 as in
> +the first example, but uses the intact filesystem that already exists.
> +
> +Current Limitations
> +===================
> +
> +- The RAM used for PRAMFS must be directly addressable.
> +
> +- PRAMFS does not support hard links.
> +
> +- PRAMFS supports only private memory mappings. This allows most
> + executables to run, but programs that attempt shared memory
> + mappings, such as X apps that use X shared memory, will fail.
> +
> +- PRAMFS does not support quota settings.
> +
> +Further Documentation
> +=====================
> +
> +If you are interested in the internal design of PRAMFS, there is
> +documentation available at the Sourceforge PRAMFS home page at
> +http://pramfs.sourceforge.net/.
> +
> +Please send bug reports/comments/feedback to the pramfs development
> +list at sourceforge: pramfs-devel@lists.sourceforge.net.
> +
> +
> +ChangeLog
> +=========
[snip]
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-10-20 19:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-embedded
In-Reply-To: <20101020183435.GA12480@angua.secretlab.ca>
Grant:
> Identify by name tends to be a horrible interface in my opinion. The
> lesson has been learned in the network and block layers that names
> change over time and trying to lock them down to something that a user
> finds 'sane' ends up in a mess of workarounds and bad assumptions in
> the code.
The reason it doesn't work for network and block devices is because
the names of those devices aren't relevant; it's only the IP address
assigned and mount point that are of interest. Furthermore, you
rarely talk directly to an ethernet controller: you just route packets
through it. And the kernel decides which packets are going to go
where based solely on IP and related information, and never the name
of the device. So pretending that the name matters is a recipe for
trouble.
PWM devices are different, I think, in that the name of the device
uniquely identifies a physical peripheral in the part, and the channel
number is often mapped to a specific pin on the chip package by the
platform integrator. If you have a hope of driving your PWM signal to
the right place each time the system builds and boots, you have to be
able to specify things to that level of detail.
And then there's the laziness factor. :) I don't like having to
figure out over and over again that "pwm-1:2" is really mapped to the
PWMC peripheral's channel two; and I definitely don't like worrying
that channel enumerations will change just because I plugged in a new
i2c GPIO chip or LED driver. I want to be able to tell the system
that I want to talk to a specific pin, regardless of when it shows up
relative to all the other pins in the system.
> In userspace, the correct solution is to expose real information about
> the device (how the instance is connected to the system plus any other
> identifying data) in the sysfs tree and let udev (or a trivial
> replacement) decode to a stable user-friendly name.
That's precisely what I'm doing.
I don't anticipate that device authors will use names like
"panel_backlight". Rather, they should use names like "pwmc:2:3",
which means "PWMC peripheral 2 channel number 3". Then they can look
at a schematic to verify that PWMC2 indeed goes to the panel
backlight.
> Essentially, identifying by name attempts to expose real information
> about which device it is, but the process of encoding a name is lossy
> and so it fails to be robust in the long term.
In the case of semi-transparent devices like ethernet controllers and
block devices, I agree. But the information for a PWM signal doesn't
merely pass through a PWM controller: it tells the controller what to
do. Subtle but important difference compared to an ethernet
controller that makes it compelling to use actual names in my case.
> Yeah, by changing to using class attributes, a lot of this could end
> up going away.
Looking at that now, in fact.
> My experience has been there are very few things that cannot be
> deferred to module_initcall() time if the device model is handled
> well. Typically the things that fall outside of that model are core
> infrastructure things like irq controllers which need to be ready to
> go before many of the subsystems are initialized.
The one situation that comes to mind is i2c GPIO expanders on powerpc.
Since everything in that world is bound only after the DTS file gets
parsed, finding and registering things can be tricky. Or maybe it was
the onboard GPIO controllers in the MPC5200. IIRC, I found a case
where something could call pwm_register() before the PWM framework
itself had even been established. That caused sysfs to complain, to
say the least.
Of course, the problem could actually be that I'm not using sysfs
quite right yet. Hmm...
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
From: Grant Likely @ 2010-10-20 18:34 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <AANLkTikLnoAiZpZpA-aUPa3kSW7ZO=542wLgzFUqiL_4@mail.gmail.com>
On Wed, Oct 20, 2010 at 01:13:34PM -0500, Bill Gatliff wrote:
> Grant:
>
> > I'm not hugely keen on the naming approach, and I'd rather see the
> > pwm core be responsible for the namespace.
>
> The problem with that, as I see it, is that then the channel
> identifiers become dependent on the order of device initialization.
Correct, just like on all other subsystems.
> By allowing driver authors to assign names, however, users are capable
> of pinning their channel requests to specific devices and channels
> with confidence that those names will remain valid regardless of the
> sequence they compile their kernel in.
Identify by name tends to be a horrible interface in my opinion. The
lesson has been learned in the network and block layers that names
change over time and trying to lock them down to something that a user
finds 'sane' ends up in a mess of workarounds and bad assumptions in
the code.
For in-kernel users, either platform_data or notifier hooks can be used
by one device to have explicit knowledge about the device. No need to
muck about with name encoding.
In userspace, the correct solution is to expose real information about
the device (how the instance is connected to the system plus any other
identifying data) in the sysfs tree and let udev (or a trivial
replacement) decode to a stable user-friendly name.
Essentially, identifying by name attempts to expose real information
about which device it is, but the process of encoding a name is lossy
and so it fails to be robust in the long term.
>
> > Nitpick: putting the filename into the file itself I find tends to be
> > useless
>
> Agreed. Those tend to sneak in during my early development, and then
> I get so used to seeing them that I forget to take them out.
:-)
>
> >> +static int __pwm_create_sysfs(struct pwm_device *pwm);
> >
> > If you order the functions in this file correct, the forward
> > declaration should not be necessary.
>
> In theory, I agree completely with you. In this specific instance,
> however, I haven't been able to structure things in a way that
> eliminates at least one forward declaration.
Fair enough, sometimes that is necessary. I didn't look that closely.
> One possibility would be to move all the sysfs-related stuff out to a
> separate file altogether. Depending on what the class attribute
> rework ends up doing to the code, I just might do that. Of course,
> that wouldn't eliminate the forward declaration--- it would just move
> it. :)
Yeah, by changing to using class attributes, a lot of this could end
up going away.
>
> >> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
> >> + dev = class_find_device(&pwm_class, NULL,
> >> + &pwm->channels[wchan],
> >> + __match_device);
> >
> > If the pwm_channel structure carried a pointer to its device
> > structure, then this lookup wouldn't be needed.
>
> This comment, combined with your other one on the class attributes
> (below) convince me that the device model isn't quite right yet. I
> will rework this until seems correct.
:-)
>
> > The above 8 functions are so tiny that they should probably be static
> > inlines in the header file.
>
> Agreed.
>
> > Rather than open coding the registration of sysfs files, I believe the
> > right thing to do is to use class attributes so that the files get
> > automatically registered for you and are immediately advertised to
> > userspace (very important for correct interaction with udev).
>
> I think I'm either still a little weak on my device model
> understanding, or things have been changing there lately and I haven't
> had the time to notice. Regardless, this code always seemed a little
> awkward--- you seem to agree, so I'll do some research and come back
> with something better.
>
> > Also, sysfs_create_group() should not be called directly when working
> > with devices.
>
> Probably necessary because I'm not doing something right elsewhere. :)
>
> >> + /* TODO: how to deal with devices that register very early? */
> >
> > Same thing we always do for bootstrapping. If it *must* be early,
> > then we do a simple direct access to get things running in platform
> > code, and then take over in the driver when it finally gets probed.
> > The driver model helps with many things, but really early stuff isn't
> > one of them.
>
> I _think_ you and I are saying the same thing: that the device model
> only works well with late-registering devices. I'm not sure I
> understand your suggestion for how to deal with must-be-early devices.
My experience has been there are very few things that cannot be
deferred to module_initcall() time if the device model is handled
well. Typically the things that fall outside of that model are core
infrastructure things like irq controllers which need to be ready to
go before many of the subsystems are initialized.
Basically I'm saying that for things that *really do* need to be setup
before the initcalls, you either don't use the device model at all, or
you figure out how to hand off control from early bootstrap code once
the driver model is set up. Kind of like the early console code.
Scary stuff.
g.
^ permalink raw reply
* Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
From: Bill Gatliff @ 2010-10-20 18:13 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-embedded
In-Reply-To: <20101016074240.GC653@angua.secretlab.ca>
Grant:
> I'm not hugely keen on the naming approach, and I'd rather see the
> pwm core be responsible for the namespace.
The problem with that, as I see it, is that then the channel
identifiers become dependent on the order of device initialization.
By allowing driver authors to assign names, however, users are capable
of pinning their channel requests to specific devices and channels
with confidence that those names will remain valid regardless of the
sequence they compile their kernel in.
> Nitpick: putting the filename into the file itself I find tends to be
> useless
Agreed. Those tend to sneak in during my early development, and then
I get so used to seeing them that I forget to take them out.
>> +static int __pwm_create_sysfs(struct pwm_device *pwm);
>
> If you order the functions in this file correct, the forward
> declaration should not be necessary.
In theory, I agree completely with you. In this specific instance,
however, I haven't been able to structure things in a way that
eliminates at least one forward declaration.
One possibility would be to move all the sysfs-related stuff out to a
separate file altogether. Depending on what the class attribute
rework ends up doing to the code, I just might do that. Of course,
that wouldn't eliminate the forward declaration--- it would just move
it. :)
>> + for (wchan = 0; wchan < pwm->nchan; wchan++) {
>> + dev = class_find_device(&pwm_class, NULL,
>> + &pwm->channels[wchan],
>> + __match_device);
>
> If the pwm_channel structure carried a pointer to its device
> structure, then this lookup wouldn't be needed.
This comment, combined with your other one on the class attributes
(below) convince me that the device model isn't quite right yet. I
will rework this until seems correct.
> The above 8 functions are so tiny that they should probably be static
> inlines in the header file.
Agreed.
> Rather than open coding the registration of sysfs files, I believe the
> right thing to do is to use class attributes so that the files get
> automatically registered for you and are immediately advertised to
> userspace (very important for correct interaction with udev).
I think I'm either still a little weak on my device model
understanding, or things have been changing there lately and I haven't
had the time to notice. Regardless, this code always seemed a little
awkward--- you seem to agree, so I'll do some research and come back
with something better.
> Also, sysfs_create_group() should not be called directly when working
> with devices.
Probably necessary because I'm not doing something right elsewhere. :)
>> + /* TODO: how to deal with devices that register very early? */
>
> Same thing we always do for bootstrapping. If it *must* be early,
> then we do a simple direct access to get things running in platform
> code, and then take over in the driver when it finally gets probed.
> The driver model helps with many things, but really early stuff isn't
> one of them.
I _think_ you and I are saying the same thing: that the device model
only works well with late-registering devices. I'm not sure I
understand your suggestion for how to deal with must-be-early devices.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Greenbeard Removal Confirmation
From: The Greenbeard Labs Team @ 2010-10-19 20:33 UTC (permalink / raw)
To: linux-embedded
You have been removed from our mailing list. To re-subscribe, please go to
http://relay.greenbeardlabs.com/lists/?p=subscribe and follow the steps.
Thank you
^ permalink raw reply
* Re: [PWM 06/10] Incorporate PWM API code into KBuild
From: Bill Gatliff @ 2010-10-19 2:17 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-embedded
In-Reply-To: <20101016080207.GG653@angua.secretlab.ca>
>
> Hmmm... is this patch series bisectable?
Ooh, that's something I hadn't thought about. Probably not.
In addition to incorporating your feedback (thanks!), I'll rejigger
things in the next revision so that they are bisectable.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: usb-skeleton.c - generates warning
From: Mike Frysinger @ 2010-10-16 16:58 UTC (permalink / raw)
To: Andrew Worsley; +Cc: linux-embedded
In-Reply-To: <AANLkTimsXLsZ1deY+eJreb3js5d8y3sCEFgDS1q0A2Uc@mail.gmail.com>
On Sat, Oct 16, 2010 at 07:00, Andrew Worsley wrote:
> Sorry if this is the wrong mailing list for this - I am writing a USB
> driver  (for an embedded system) modeled on the
> drivers/usb/usb-skeleton.c
you can find the correct list here:
http://vger.kernel.org/vger-lists.html#linux-usb
-mike
^ permalink raw reply
* usb-skeleton.c - generates warning
From: Andrew Worsley @ 2010-10-16 11:00 UTC (permalink / raw)
To: linux-embedded
Sorry if this is the wrong mailing list for this - I am writing a USB
driver (for an embedded system) modeled on the
drivers/usb/usb-skeleton.c
version 2.6.30 but it gets the following warning.
It looks like it is a generic issue, perhaps the skeleton is not
maintained any more?
If so is there a reference explain the right way? I couldn't find
anything on google.
Looking at other drivers it appears this isn't done anymore? If so
perhaps this should be updated?
Suggestions appreciated.
Thanks
Andrew
...
usb 1-5: jtag_release()
usb 1-5: jtag_open()
usb 1-5: jtag_read(file=ded6e3c0, buf=092f8440, count=512,..)
usb 1-5: jtag_flush()
usb 1-5: jtag_release()
usb 1-5: jtag_open()
usb 1-5: jtag_write(file=df0ebe40, buf=093783f0, count=2506,..)
usb 1-5: jtag_flush()
usb 1-5: jtag_release()
------------[ cut here ]------------
WARNING: at /tmp/9789a690-d005-11df-8a73-00241dc62196/voyage-linux-2.6.30/arch/x86/include/asm/dma-mapping.h:294
hcd_buffer_free+0x85/0xb9 [usbcore]()
Hardware name: POULSBO
Modules linked in: ctam_ftdi ipv6 tun e1000e ata_piix usb_storage
ff_memless intel_agp agpgart loop hwmon_vid hostap_pci hostap lib80211
natsemi serio_raw p
cspkr asix pl2303 usbnet ftdi_sio usbserial usbhid i2c_isch hid evdev
ext3 jbd mbcache sd_mod pata_sch ata_generic libata uhci_hcd ehci_hcd
scsi_mod ide_pci
_generic r8169 mii usbcore amd74xx lm90 led_class ide_generic ide_core
[last unloaded: ctam_ftdi]
Pid: 2234, comm: loadFPGA Tainted: G W 2.6.30.10-robin-z5xx #1
Call Trace:
[<c0126a04>] ? warn_slowpath_common+0x5e/0x8a
[<c0126a3a>] ? warn_slowpath_null+0xa/0xc
[<dff512d1>] ? hcd_buffer_free+0x85/0xb9 [usbcore]
[<e043b328>] ? jtag_write_bulk_callback+0x55/0x61 [ctam_ftdi]
[<dff4c1e2>] ? usb_hcd_giveback_urb+0x60/0x8f [usbcore]
[<dfffde94>] ? ehci_urb_done+0x9d/0xa9 [ehci_hcd]
[<dffff42d>] ? qh_completions+0x359/0x3e9 [ehci_hcd]
[<dffff552>] ? ehci_work+0x95/0x782 [ehci_hcd]
[<e016f5c1>] ? serial_write+0x72/0x7d [usbserial]
[<c0175aa5>] ? handle_mm_fault+0x293/0x5f4
[<e00024f9>] ? ehci_irq+0x171/0x1c4 [ehci_hcd]
[<dff4beca>] ? usb_hcd_irq+0x2f/0x6c [usbcore]
[<c0156287>] ? handle_IRQ_event+0x4e/0x101
[<c0157510>] ? handle_fasteoi_irq+0x66/0x97
[<c0104def>] ? handle_irq+0x17/0x1b
[<c010485d>] ? do_IRQ+0x38/0x76
[<c0103569>] ? common_interrupt+0x29/0x30
---[ end trace 7b48bc9372419b94 ]---
usb 1-5: jtag_open()
usb 1-5: jtag_flush()
usb 1-5: jtag_read(file=de7748c0, buf=09a63000, count=512,..)
usb 1-5: jtag_flush()
usb 1-5: jtag_release()
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox