I see these warnings on 32 bit ARM systems:
CC kernel/time.o
kernel/time.c: In function 'msecs_to_jiffies':
kernel/time.c:472: warning: integer constant is too large for 'long' type
kernel/time.c: In function 'usecs_to_jiffies':
kernel/time.c:487: warning: integer constant is too large for
On Tuesday 26 February 2008, Peter Zijlstra wrote:
>
> On Mon, 2008-02-25 at 14:33 -0800, David Brownell wrote:
>
> > > +#ifdef CONFIG_LOCKDEP
> > > +
> > > +/* tell lockdep that this IRQ's locks and its parent's locks are in
> > >
On Tuesday 26 February 2008, Haavard Skinnemoen wrote:
> > Another way to address that rm9200 issue would be to just rate
> > the TC clockevent source lower than the one based on the system
> > timer, so it's set up but never enabled ... and remember "t2_clk",
> > calling clk_enable() only when tha
On Tuesday 26 February 2008, Haavard Skinnemoen wrote:
> Ok. Let's drop the clock references...
>
> > > and it will always need a pointer through which to access the
> > > registers, so the mid-layer might as well do those things.
> >
> > True about doing the ioremap.
>
> ...and keep the reg
On Tuesday 26 February 2008, David Newall wrote:
>
> Hardware can be inserted and removed while we're in a suspend state; and
> there's nothing that we can do about it until we resume. Is it fair to
> say, then, that having started suspend, we could reasonably ignore any
> device insertion and re
This "flaw" isn't a new thing, of course. I remember pointing out the rather
annoying proclivity of the PM framework to deadlock when suspend() tried to
remove USB devices ... back around 2.6.10 or so. Things have shuffled around
a bit, and gotten better in some cases, but not fundamentally chang
> So I'm think that the reason this only _changes_ the false
> recursion notification ...
Whoops, it's because of the following typo:
> --- a/arch/arm/plat-omap/gpio.c 2008-02-24 19:02:32.0 -0800
> +++ b/arch/arm/plat-omap/gpio.c 2008-02-25 10:54:29.0 -0800
> @@ -1332,
> > I thought the way to use the *_nested() calls was "consistently"!
>
> Very much depends on your view of consistent :-)
>
> > That is, if one instance of a lock access uses it, they all should,
> > since that's the only way lockdep learns about equivalence classes.
> > Also, locks shouldn't move
> > > Which reminds me...you were talking about a patch that adds oneshot
> > > support for the count/compare clocksource and more cleanups, but I
> > > don't think I've seen it...?
> >
> > I avoid sending non-working patches, and hadn't made time to
> > work on that issue recently.
>
> I was thin
> > > > +static cycle_t tc_get_cycles(void)
> > > > +{
> > > > + unsigned long flags;
> > > > + u32 lower, upper;
> > > > +
> > > > + raw_local_irq_save(flags);
> > >
> > > Why do you need to use the raw version?
> >
> > This is part of the system timer code, and it
> > > > > ==> LOCKDEP feature is evidently missing:
> > > > > spin_lock_irq_nested(lock_ptr, lock_class)
> > > >
> > > > This rant is more lines than adding the API :-/ the reason for it not
> > > > being there is simple, it wasn't needed up until now.
> > >
> > > I suspected that
On Thursday 21 February 2008, Alan Stern wrote:
> > = CUT HERE
> > Modify EHCI irq handling on the theory that at least some of the
> > "lost" IRQs are caused by goofage between multiple lowlevel IRQ
> > acking mechanisms: try rescanning before we exit the handler, in
> > case the EHCI-int
that lockdep can work with the
code which uses spin_*_irq() calls that don't save/restore flags.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Against 2.6.25-rc3
include/linux/spinlock.h |6 ++
include/linux/spinlock_api_smp.h |2 ++
kernel/spinlock.c
> > > > Note that this won't be usable until the AT91 and AT32 platforms
> > > > incorporate patches to configure the relevant platform devices.
> > > > Those changes are probably 2.6.26 material.
> >
> > More specifically (and all those patches are available now):
> >
> > - AT91 needs clocksour
e invoking handlers.)
> On Fri, 22 Feb 2008 17:28:37 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > +static cycle_t tc_get_cycles(void)
> > +{
> > + unsigned long flags;
> > + u32 lower, upper;
> > +
> > + raw_local_ir
On Sun, 24 Feb 2008 18:45:54 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> On Fri, 22 Feb 2008 17:23:23 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Create based on and the
> > at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32
On Saturday 23 February 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 17:08:53 + Liam Girdwood <[EMAIL PROTECTED]> wrote:
> > +#define mV_to_uV(mV) (mV * 1000)
> > +#define uV_to_mV(uV) (uV / 1000)
> > +#define V_to_uV(V) (mV_to_uV(V * 1000))
> > +#define uV_to_V(uV)(uV_t
> > > David, do you think writing 0 bytes is a valid use of this API?
> >
> > Just a zero byte transfer ... no, though it depends what you mean
> > by "valid". (I'm not sure I'd expect all controller drivers to
> > reject such requests.) That has no effect on bits-on-the-wire,
> > and would make
On Friday 22 February 2008, Ned Forrester wrote:
>
> So, what I think you said is that it would be better for pxa2xx_spi to
> silently ignore a zero-length message, passing it back with the rest of
> the message when all is complete, than to reject the message.
Yes. Remember that the reason to _
evant patches for
tclib support (always) and clockevents (or else this will only look
like a higher precision clocksource). It's an updated and modularized
version of an AT91-only patch that has circulated for some time now.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
As with the
as somewhat quirky sixteen-bit timers.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Note that this won't be usable until the AT91 and AT32 platforms
incorporate patches to configure the relevant platform devices.
Those changes are probably 2.6.26 material.
drivers/m
;t require them. One example of such a
driver is NAND driver for various FreeScale chips. On platforms update
with GPIO support, they can be used instead of a worst-case delay to
verify that the BUSY signal is off.
(Also includes a couple minor unrelated doc updates.)
Signed-off-by: David Brownell &l
On Friday 22 February 2008, Anton Vorontsov wrote:
> > +static inline int gpio_request(unsigned gpio, const char *label)
> > +{
> > + return -EINVAL;
>
> Could we return -ENOSYS instead, so drivers will able to distinguish
> between "something really failed" and "there is no gpio support,
> fa
> > For those PMIC that covers additional features, like
> > - usb vbus detection (or pull-up/pull-down)
> > - audio codec
> > - touch screen
> > - battery monitor/ fuel gauge
> > - battery charger
> > - possible many others
Certainly many others ... like MMC transceivers, high speed U
> > If the driver could not handle zero length transfer, then the driver
> > should reject it (just like unsupported transfer mode). Then the
> > behavior will be 'assert chip select and wait some time' or 'rejected
> > by the driver'.
>
> This would be OK. It would not be hard to fix pxa2xx_spi,
> >> David, do you think writing 0 bytes is a valid use of this API?
> >
> > Just a zero byte transfer ... no, though it depends what you mean
> > by "valid". (I'm not sure I'd expect all controller drivers to
> > reject such requests.) That has no effect on bits-on-the-wire,
> > and would make t
Quoth Atsushi Nemoto on Fri, 22 Feb 2008:
> On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat <[EMAIL PROTECTED]> wrote:
> > > > David, do you think writing 0 bytes is a valid use of this API?
> > >
> > > Just a zero byte transfer ... no, though it depends what you mean
> > > by "valid". (I'm not s
> libata uses it under the assumption that "other parts" of the system are
> aware of this variable.
>
> May I assume that the API has changed such that this is no longer necessary?
Yes. The original motivation for dev->power.power_state was to let
the writes to /sys/devices/.../power/state supp
> David, do you think writing 0 bytes is a valid use of this API?
Just a zero byte transfer ... no, though it depends what you mean
by "valid". (I'm not sure I'd expect all controller drivers to
reject such requests.) That has no effect on bits-on-the-wire,
and would make trouble for various DMA
On Wednesday 20 February 2008, Haavard Skinnemoen wrote:
> >
> > Unfortunately it did not work. The clock state did not change by
> > writing MR register.
>
> Ok, thanks for testing.
>
> In that case, I think the best fix is to let NPCS0 stay selected
> permanently in MR and overwrite CSR0 with
On Wednesday 20 February 2008, Atsushi Nemoto wrote:
> > David, do you want me to pass on the patch with my signoff or just ask
> > Andrew to add my Acked-by to the patch already in mm?
>
> The patch in mm also lacks my Signed-off line. I had thought Andrew
> never take a patch without Signed-off
On Wednesday 20 February 2008, Andre Tomt wrote:
> David Brownell wrote:
> > On Wednesday 20 February 2008, Andre Tomt wrote:
> >> It has not crashed yet with the patch though.
> >
> > It seems that one of the tweks in this patch made the watchdog
> > act b
On Wednesday 20 February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, David Brownell wrote:
>
> > On Wednesday 20 February 2008, Alan Stern wrote:
> > > > ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> > >
> > > lines in t
On Wednesday 20 February 2008, Alan Stern wrote:
> > ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
>
> lines in the log brings up some ideas that have been percolating in my
> mind for a while. They have to do with the possibility of a race
> between the watchdog routine
On Wednesday 20 February 2008, Andre Tomt wrote:
> ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> ehci_hcd :00:1d.7: IAA watchdog
On Tuesday 19 February 2008, Andre Tomt wrote:
>
> > Can you try this diagnostic patch, to see if it reports any messages
> > about IAA and/or IAAD oddities? There's surely a quick workaround
> > for this, but I'd rather understand the root cause before patching.
>
> Doesn't seem to have trigger
On Tuesday 19 February 2008, David Miller wrote:
> From: Andre Tomt <[EMAIL PROTECTED]>
> Date: Tue, 19 Feb 2008 16:19:08 +0100
>
> > Got this on a serial console today, using 2.6.25-rc2-git1. Machine was
> > not doing anything interesting at the time, but has its / and kernel on
> > a usb-stora
On Tuesday 19 February 2008, Ingo Molnar wrote:
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > Thing is, this will catch not just regressions ... but cases where
> > > STR never worked in the first place. Video problems, etc. Also
> > > various system startup races, as in the PCMCIA and M
On Tuesday 19 February 2008, Andre Tomt wrote:
> Got this on a serial console today, using 2.6.25-rc2-git1. Machine was
> not doing anything interesting at the time, but has its / and kernel on
> a usb-storage device (usb pen drive).
Can you try this diagnostic patch, to see if it reports any me
> dislike this behavior...).
>
> Signed-off-by: Benedikt Spranger <[EMAIL PROTECTED]>
> Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
> drivers/usb/gadget/ether.c |1 +
> 1 file changed, 1 insertion(
t;
> (Makefile changes are in a separate patch for all of Documentation/.)
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
> Documentation/spi/spidev | 168 ---
> Documentatio
On Monday 18 February 2008, Ingo Molnar wrote:
>
> * David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > - Includes a command line parameter, which needs work yet ... it
> > > > currently turns this test off, but it should also let the target
> &g
On Monday 18 February 2008, Atsushi Nemoto wrote:
>IIRC the clock state follows
> CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the patch from Haavard is likely
the right change.
> Like this (previous transfe
On Monday 18 February 2008, Pavel Machek wrote:
> > How to fix ... how about: instead of just warning folk
> > off such legacy RTC drivers [1] we just wrap them with
> > an "if RTC_LIB != n" so this mistake won't be possible.
>
> Yes, disabling bad configs in Kconfig seems like way to go.
Proble
> > - Includes a command line parameter, which needs work yet ... it
> > currently turns this test off, but it should also let the target
> > state be specified (and maybe even default to "no test").
I think "no test" should be the default; STR working sanely on
x86 is unfortunately too
On Saturday 16 February 2008, Atsushi Nemoto wrote:
> Hi. Is it legal to use zero for 'len' field of struct spi_transfer?
> I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
Yes that should work ... it's uncommon, but not illegal. Some
controller drivers may even handle that right!
If the dela
On Thursday 14 February 2008, David Newall wrote:
> RS232 is (normally) so much slower than USB that, on an extended
> transmission, the buffer internal to the local hardware can fill well
> before the remote device has demanded that transmission stop. In fact,
> now that you've mentioned it, I ca
On Thursday 14 February 2008, Uwe Kleine-König wrote:
> If you have GPIO_LIB gpio_cansleep oopses on an invalid
> gpio. So better gpio_request your pin first.
>
> Signed-off-by: Uwe Kleine-König <[EMAIL PROTECTED]>
> Cc: David Brownell <[EMAIL PROTECTED]>
Acked
he arch-specific interface glue otherwise.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
include/linux/gpio.h | 93 +++
1 file changed, 93 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/include/linux/gpio.h
On Wednesday 13 February 2008, Andrew Morton wrote:
> Someone please fix.
This is what I was using purely for test builds ... most x86 hardware
actually has no GPIOs, and I sure don't have any of the "unusual" x86
platforms here, so I'd not want to see this version merge. Someone
more clued in on
On Wednesday 13 February 2008, Felipe Balbi wrote:
> On Tue, Feb 12, 2008 at 12:32:34PM -0800, David Brownell wrote:
> >
> > Your proposal is to strike the "is_b_host" check. In terms of the
> > OTG (1.3) state machine, that removes a b_host --> b_peripheral
>
> > > > > Some devices claim
> > > > > to be b_host even though they have an a_connector attached to it.
> > > >
> > > > Why not just fix that bug? Remember that's Linux code.
> > >
> > > The device claiming to be b_host is not linux based.
> >
> > Wrong ... the meaning of that flag is: *THIS*
On Tuesday 12 February 2008, Pavel Machek wrote:
> I'm getting this during bootup:
>
> PM: Adding info for No Bus:event6
> PM: Adding info for No Bus:uinput
> PM: Adding info for No Bus:rtc0
> proc_dir_entry 'rtc' already registered
> Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #125
> ... deleti
On Tuesday 12 February 2008, Felipe Balbi wrote:
> On Tue, Feb 12, 2008 at 02:28:53AM -0800, David Brownell wrote:
> > On Tuesday 12 February 2008, Felipe Balbi wrote:
> > > Some devices claim
> > > to be b_host even though they have an a_connector attached to it.
>
On Tuesday 12 February 2008, Felipe Balbi wrote:
> Some devices claim
> to be b_host even though they have an a_connector attached to it.
Why not just fix that bug? Remember that's Linux code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
es need docs ]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Documentation/gpio.txt | 10 ++
drivers/gpio/gpiolib.c | 14 +++---
include/asm-generic/gpio.h | 12
3 files changed, 29 insertions(+), 7 deletions(-)
--- g26.orig/Documentation/gpio.
add mcp23s08 and pcf857x ]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/mcp23s08.c |1 +
drivers/gpio/pca953x.c |1 +
drivers/gpio/pcf857x.c |1 +
3 files changed, 3 insertions(+)
--- g26.orig/drivers/gpio/mcp23s08.c2008-02-10 16:06:30.0 -0800
++
nnadi Liakhovetski <[EMAIL PROTECTED]>
[ gpio_ensure_requested() needs to update module usecounts too ]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/gpiolib.c | 15 ---
include/asm-generic/gpio.h |2 ++
2 files changed, 14 insertions(+), 3 d
Fix section warning for parport_ECP_supported(); it's called from a
routine exported to modules, so it can't be removed with __devinit
section pruning.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/parport/parport_pc.c |4 ++--
1 file changed, 2 insertions
of Kconfig, add a comment
warning people off these (seven) legacy RTC drivers when
the generic framework is in use.
People can still use the legacy drivers if they want (or need) to.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
This doesn't fix the broken dependencies
I like this, but can't resist making the "Andrew Comment":
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -16,6 +16,8 @@
> #define ARCH_NR_GPIOS256
> #endif
>
> +#define is_valid_gpio(gpio) ((unsigned int)(gpio) < ARCH_NR_GPIOS)
Please make this an
On Monday 04 February 2008, Jiri Slaby wrote:
> Hi,
>
> I have this in dmesg:
> DMAR:[DMA Write] Request device [00:02.0] fault addr ee1512000
> DMAR:[fault reason 05] PTE Write access is not set
> PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> DMAR:[DMA Read] Request device [00:1d
On Saturday 09 February 2008, Guennadi Liakhovetski wrote:
> On Fri, 8 Feb 2008, David Brownell wrote:
>
> > Actually I thought that what you needed was an is_valid_gpio();
> > your motivation was that you needed a predicate.
> >
> > The problem I have with a #de
> > > As long as one or more GPIOs on a gpio chip are used its driver should
> > > not
> > > be unloaded.
> >
> > The mechanism currently in place is to have gpiochip_remove() fail
> > if the platform's teardown() logic doesn't reject it. (It may be
> > practical to have the teardown code get r
On Friday 08 February 2008, Guennadi Liakhovetski wrote:
> As long as one or more GPIOs on a gpio chip are used its driver should not
> be unloaded.
The mechanism currently in place is to have gpiochip_remove() fail
if the platform's teardown() logic doesn't reject it. (It may be
practical to ha
On Thursday 31 January 2008, Guennadi Liakhovetski wrote:
> As discussed on i2c mailing list with David Brownell, and number
> outside of the 0...MAX_INT range is invalid as a GPIO number.
> Define a macro, similar to NO_IRQ, to be used as a deliberate
> invalid GPIO, rather tha
On Tuesday 05 February 2008, Marc Pignat wrote:
> Hi all!
>
> > /*
> > @@ -946,9 +986,10 @@ static int __exit at91_mci_remove(struct
> > host = mmc_priv(mmc);
> >
> > if (host->board->det_pin) {
> > + if (device_can_wakeup(&pdev->dev))
> > + free_irq(gpio_to_
> > > The changes look good to me.
> >
> > They feel unfinished to me though. :)
> >
> > Like using "jiffies" instead of a clocksource, which makes trouble
> > since the timing covers periods with IRQs disabled. And the test
> > mode parameter needs work.
>
> Well, I'd say that timing has bigge
> > See the appended; it includes more of Ingo's suggestions.
> >
> > Since this is increasingly unrelated to the "sleepy linux" concept
> > (a version of what systems like OLPC, N700, and N800 are doing), I
> > got rid of the "sleepy.c" file.
>
> The changes look good to me.
They feel unfinished
> > > +config PM_WAKEALARM_TEST
> > > + bool "Test suspend/resume and wakealarm during bootup"
> > > + depends on SUSPEND && PM_DEBUG && RTC_LIB
>
> I guess it also should depend on CONFIG_RTC_DRV_CMOS (not being a module)
> and !CONFIG_RTC.
No -- we need a *generic* test, not one that
On Saturday 02 February 2008, Sam Ravnborg wrote:
> > --- g26.orig/drivers/char/Kconfig
> > +++ g26/drivers/char/Kconfig
> > @@ -715,9 +715,12 @@ config NVRAM
> > To compile this driver as a module, choose M here: the
> > module will be called nvram.
> >
> > +comment "You are using th
00 -0800
+++ g26/kernel/power/Makefile 2008-02-02 22:37:18.0 -0800
@@ -5,7 +5,7 @@ endif
obj-y := main.o
obj-$(CONFIG_PM_LEGACY)+= pm.o
-obj-$(CONFIG_PM_SLEEP) += process.o console.o
+obj-$(CONFIG_PM_SLEEP) += process.o con
On Saturday 02 February 2008, Ingo Molnar wrote:
> > [ 23.509562] Calling initcall 0xc0c49e00: be_sleepy+0x0/0x170()
> > [ 23.515837] PM: no wakelarm-capable RTC
> > [ 23.517562] initcall 0xc0c49e00: be_sleepy+0x0/0x170() returned 0.
Because CONFIG_RTC_DRV_CMOS was not configured, though
you
-$(CONFIG_MAGIC_SYSRQ) += poweroff.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ sam9/kernel/power/sleepy.c 2008-02-02 18:26:40.0 -0800
@@ -0,0 +1,113 @@
+/*
+ * Copyright (c) 2007 Pavel Machek <[EMAIL PROTECTED]>
+ * Copyright (c) 2008 David Brownell
+ *
+ * This fi
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> * David Brownell <[EMAIL PROTECTED]> wrote:
>
> > On Saturday 02 February 2008, Ingo Molnar wrote:
> > >
> > > i'd really love to have a /dev/rtc device compatibility APIs, both
> > > insi
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> > > Yep, you are right, but that is the easy issue to fix.
> >
> > Which is why I was puzzled that you didn't start out doing it the
> > "right" way ... even just hard-wiring the dubious assumption that
> > "rtc0" is the right RTC to use. :)
On Saturday 02 February 2008, David Brownell wrote:
> static char *find_wake_rtc(void)
> {
> char *pony = NULL;
>
> dev = class_find_device(rtc_class, &rtc, has_wakealarm);
&a
On Saturday 02 February 2008, Ingo Molnar wrote:
>
> i'd really love to have a /dev/rtc device compatibility APIs, both
> inside and outside the kernel.
Unfortunately the /dev/rtc code became a legacy API for good reasons.
Like not recognizing that all the world's not a PC, with a single RTC
th
On Saturday 02 February 2008, Pavel Machek wrote:
> Hi!
>
> > > --- a/drivers/rtc/rtc-cmos.c
> > > +++ b/drivers/rtc/rtc-cmos.c
> > > @@ -78,7 +78,7 @@ static inline int is_intr(u8 rtc_intr)
> > >
> > > /**/
> > >
> > > -static i
On Friday 01 February 2008, Alan Stern wrote:
>
> I can look at the USB and SCSI stuff. It shouldn't be all that bad.
> The userspace interface has been gone for quite some time now, and most
> of the remaining uses of that field are write-only.
It's that "most" which can make trouble. :)
-
On Thursday 31 January 2008, David Brownell wrote:
> Quoth Harvey Harrison:
>
> > Ping?
> > What: dev->power.power_state
> > When: July 2007
>
> ... there are still quite a few users left, and a new one was (sigh)
> recently added.
>
>
Remove some more references to dev->power.power_state. That field
is overdue for removal, but we can't do that while it's still
referenced in the kernel. The only reason to update it was to make
the /sys/devices/.../power/state files (now removed) work better.
Signed-off-by: D
Remove some more references to dev->power.power_state. That field
is overdue for removal, but we can't do that while it's still
referenced in the kernel. The only reason to update it was to make
the /sys/devices/.../power/state files (now removed) work better.
Signed-off-by: D
7;t support interrupt and reset capabilities, those size
issues are the only software-visible differences between these parts.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
driver
ennadi Liakhovetski <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 11 ++--
drivers/gpio/Makefile |2
drivers/gpio/pca953x.c | 110 ++--
include/linux/i2c/pca953x.h |2
4
PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Makefile |2
drivers/gpio/pca9539.c | 271
drivers/gpio/pca953x.c | 271
include/linux/i2c/pca9539.h
Quoth Harvey Harrison:
> Ping?
> What: dev->power.power_state
> When: July 2007
> Why: Broken design for runtime control over driver power states, confusing
> driver-internal runtime power management with: mechanisms to support
> system-wide sleep state transitions; event codes that
On Wednesday 30 January 2008, Pavel Machek wrote:
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -78,7 +78,7 @@ static inline int is_intr(u8 rtc_intr)
>
> /**/
>
> -static int cmos_read_time(struct device *dev
I've forwarded these to Andrew, with my signoff and updated comments.
You still need to work on having your patch descriptions match up
to what the patches actually do...
Patches 3-5 in this series seem to have a common thread: waiting
until BIT_STAT_SPIF is set before moving to the next step of
On Thursday 31 January 2008, Paul Mundt wrote:
> On Thu, Jan 31, 2008 at 12:27:24AM -0800, David Brownell wrote:
> > On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > > So basically, you're asking for maximum flexibility with minimum
> > > overhead.
&
On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > > > Example: USB tends to use one packet per "frame" and have the DMA
> > > > request signal mean "give me the next frame". It's sometimes been
> > > > very important to use use the tuning options to avoid some on-chip
> > > > race condi
On Wednesday 30 January 2008, Kumar Gala wrote:
> Was wondering if anyone was looking at the cause of this warning in
> top of linus's tree (8af03e782cae1e0a0f530ddd22301cdd12cf9dc0)
>
> drivers/spi/Kconfig:156:warning: 'select' used by config symbol
> 'SPI_PXA2XX' refers to undefined symbol '
On Wednesday 30 January 2008, Bryan Wu wrote:
> When got some gpio conflict, it is easy to know which SPI device driver not
> just got "bfin-spi"
>
> Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> ---
> drivers/spi/spi_bfin5xx.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> d
On Wednesday 30 January 2008, Dan Williams wrote:
> On Jan 30, 2008 3:52 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> > > Descriptor-based vs. register-based transfers sounds like something the
> > > DM
On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> On Tue, 29 Jan 2008 19:44:53 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > On Monday 28 January 2008, Haavard Skinnemoen wrote:
> > >
> > > > What will AVR32 (AP7) need t
On Wednesday 30 January 2008, Haavard Skinnemoen wrote:
> Ok, I didn't bother to check the specs, as I think your main argument
> is that these options vary from controller to controller, so we need to
> make this extensible.
>
> Not all options are specific to DMA slave transfers either, although
On Tuesday 29 January 2008, Haavard Skinnemoen wrote:
> @@ -297,6 +356,13 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan);
>
> + struct dma_slave_descriptor *(*device_prep_slave)(
> + struc
On Tuesday 29 January 2008, Haavard Skinnemoen wrote:
>
> Btw, there's one issue I forgot to mention: I believe the DMA Engine
> framework is currently misusing the DMA mapping API, and this patchset
> makes things worse.
>
> Currently, the async_tx bits of the API do the required calls to
> dma_m
On Monday 28 January 2008, Haavard Skinnemoen wrote:
>
> > What will AVR32 (AP7) need to do, when it supports system sleep states?
>
> Not sure. The PIOs seem to require a clock in order to detect a pin
> change, so I don't think we can enter very deep sleep states if we want
> to be woken up by
On Monday 28 January 2008, Haavard Skinnemoen wrote:
> On Mon, 28 Jan 2008 12:15:00 +0100
> michael <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> > I implement a little patch (ndr just for a try) for the atmel serial
> > driver atmel_serial.c to wakeup the system when it is in suspend-ram state.
> > I r
1 - 100 of 860 matches
Mail list logo
