; macro so that the code becomes something like:
> >
> > SDIO_FBR_BASE(func->num) + SDIO_FBR_STD_IF
>
> I think this is less readable than SDIO_FBR_STD_IF(func->num).
>
It's subjective. But the longer version is more understandable for
someone who doesn
example. I have here a Marvell wifi card which needs a
firmware upload. And it seems to be rather picky about parameters
during that upload.
I'm still experimenting with a clean way to do things for this card.
I'll get back to you. :)
Rgds
--
-- Pierre Ossman
Linux kerne
gt; If a card is fussy about the block size I don't think there's anything
> cleaner than specifying directly in the driver.
>
Well, the driver has to specify the information somehow. As to how,
there are a number of options. My proposed sdio_force_block_size() will
work her
This is essentially what I mean.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 8f9fca61fbacd15d1be4215584ed00aa1119d87f
Author
e 512 to 1024
> range, this would set the block size on every transfer.
>
Quite right. I had no doubts that thing had room for improvement. But I
agree that we might as well select a fixed block size and stick with it
for the general case.
Rgds
--
-- Pierre Ossman
Linux kernel,
(func, block_size);
> + if (ret)
> + goto fail;
> +
> card->sdio_func[fn - 1] = func;
>
> return 0;
This is probably better done in the sdio_enable_func().
We also need to check that the card actually supports block io.
--
-- Pierre Ossman
support for block transfers here as well.
Also, the parameter fn is redundant.
> @@ -109,18 +109,22 @@
> cmd.opcode = SD_IO_RW_EXTENDED;
> cmd.arg = write ? 0x8000 : 0x;
> cmd.arg |= fn << 28;
> - cmd.arg |= bang ? 0x : 0x0400;
>
> Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
I'm not sure about this. I've seen several hosts which lack a
mechanical detect switch.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http:
this. In sdhci this
is hidden completely in hardware, but wbsd has to do some funky logic
to handle the problem.
> App Note on card detection goes into the use of this resistor in more
> detail but I don't believe this document is publicly available :(.
>
SD is a wonderful world. :
On Tue, 07 Aug 2007 18:20:26 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
> Pierre Ossman wrote:
> > On Tue, 07 Aug 2007 13:54:32 +0100
> > David Vrabel <[EMAIL PROTECTED]> wrote:
> >
> >>
k size */
+ unsigned short forced_blksz; /* driver forced block size */
unsigned intstate; /* function state */
#define SDIO_STATE_PRESENT (1<<0) /* present in sysfs */
@@ -136,5 +138,7 @@ extern int sdio_memcpy_toio(struct sdio_func
On Wed, 08 Aug 2007 10:46:24 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
> Pierre Ossman wrote:
> >
> >> A driver might enable/disable a function multiple
> >> times but there's no need to set the block size every time.
> >
> > Why would
ith testing the included patch first. Just
load the module and insert a card. WARNING! It will eat your data, so
do it on a test card. And remember to remove it once you're done.
Rgds
Pierre
commit e966ae990cd2ef3be48ece8cde0f97f04a0d6024
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date
ing
> performance by 50%! This scenario could be a WiFi chip doing VoIP.
Provided block size < 128. Otherwise it'll jump straight to the byte
transfer.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaud
On Wed, 08 Aug 2007 16:45:02 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
>
> Pierre,
>
> I am a little confused : the probe function does not seem to get
> called... (I tried both module an in-kernel form / inserting sd or
> mmc cards).
>
> The modules is correctly inserted : mmc_register_d
o specify the difference between "I want this data
transferred" and "I want this data transferred with an exact block size
of 32 bytes".
> My latest (and hopefully final) patch set follows.
>
These looks good. The only part I'm really attached to is the blksz ==
0 case,
ivers/mmc/host/mmci.c:
> In function
> 'mmci_request':
> /home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm2/drivers/mmc/host/mmci.c:398:
> error: implicit declaration of function 'mmc_end_request' make[4]:
> *** [drivers/mmc/host/mmci.o] Error 1
>
Thanks. That w
d_free_mmc (between 'wbsd_init'
> and 'wbsd_probe')
>
> ...
>
> Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>
> Cc: Pierre Ossman <[EMAIL PROTECTED]>
> Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
>
Thanks, applied.
Rgds
Pierre
signature.asc
Description: PGP signature
On Wed, 08 Aug 2007 12:01:44 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
> Some cleanup with whitespace/tab at the end of lines.
>
> Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]>
> ---
Patch applied, thanks.
Rgds
Pierre
signature.asc
Description: PGP signature
On Thu, 09 Aug 2007 16:09:19 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
>
> Ok thank you : it was the point.
>
> Results : in brief :
> - there is work to be done ;-)
> - multiwrite test result is : OK
>
I'm starting to get the feeling that writing this test driver was a
good idea. :)
> I
changed, 16 insertions(+), 16 deletions(-)
Gabriel C (1):
wbsd: fix section mismatch warnings
Nicolas Ferre (1):
mmc: at91_mci: remove whitespace at the end of lines
Pierre Ossman (1):
mmc: reorganize bounce buffer init
--
-- Pierre Ossman
Linux kernel, MMC maintainer
, 253 insertions(+), 176 deletions(-)
Adrian Bunk (1):
drivers/mmc/core/: make 3 functions static
Leandro Dorileo (1):
sdhci: add support to ENE-CB714
Pierre Ossman (9):
mmc: check error bits before command completion
mmc: update header file paths
mmc: update kerneldoc
hen stops
> after 100 times. In sd_ops.c the code checks for a bit to get set.
> My question is, what exactly is this bit supposed to indicate?
>
That the card has initialized. Try extending the time that loop runs and see if
the card powers up.
--
-- Pierre Ossman
Linux kern
On Sun, 29 Jul 2007 16:58:09 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.22-rc6-mm1:
> >...
> > git-mmc.patch
> >...
> > git trees
> >...
>
> sdio_dev_attrs[] can become static.
>
> Signed-off-by: Ad
On Fri, 10 Aug 2007 13:28:55 +0100
David Vrabel <[EMAIL PROTECTED]> wrote:
> sdio: add CSR vendor/device IDs
>
> Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
Same thing here. Send it with the driver.
--
-- Pierre Ossman
Linux kernel, MMC maintainer
assing. Thanks for spotting it.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubsc
;s for registers common to many devices spread
all over the kernel tree, then I suppose it's acceptable.
I'm not going to apply this just yet though as it isn't used. Include
it with the first driver that needs it.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
r.
>
> Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
Thanks. Applied.
I find it rather amusing that this is for a controller from a vendor
that brags about its conformance testing kits. Go figure.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel
ers (0xF0 - 0xFF) are not permitted.
>
> Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
Nice. Especially the touch with restricting it to vendor specific
regs. :)
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core develop
>
Nice. The way things are going right now, the sdio stack should be
merged first thing during the next merge window. So you should be able
to push this in as well.
(Not that you should stop testing and reviewing the code though ;))
Rgds
--
-- Pierre Ossman
Linux kernel, MMC m
ork properly. One doesn't respond to SPI
commands at all, and two hang on a second CMD0 and return ILLEGAL_COMMAND on a
second run of CMD1. All of this is of course wildly out of spec. SPI seems to
be a bonus, not a given. :/
As for your card, could you send me a dump as I'm unable t
On Fri, 12 Oct 2007 14:18:26 +0200
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
>
> I see the same here. MMC needs a dependency on LEDS_TRIGGERS, I guess.
>
I'd rather not, and I thought I avoided it. I must have missed
ifdef:ing some references.
--
-- Pier
hould
be peachy.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Fri, 12 Oct 2007 16:05:38 -0400 (EDT)
Nicolas Pitre <[EMAIL PROTECTED]> wrote:
>
> It is too late for a repull. Linus' main branch already contains
> your previous incarnation, so you must publish a fix separately to go
> on top.
>
*gnnn*
--
-- Pierre O
Ok, let's see if we can finally sort this out.
Please pull/cherry-pick from:
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
to receive the following update:
drivers/mmc/core/host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Pierre Ossm
On Fri, 12 Oct 2007 22:29:29 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> Patch doesn't apply cleanly due to spaces instead of tabs.
> Copy-and-paste ?
>
Yeah, gnome-terminal damage. But you need to git it from the repo to
get the full commit info anyway.
Rgds
--
1.0 failed with error -31
Ideas? This platform worked fine with 2.6.23-rc*
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubs
On Sat, 13 Oct 2007 12:27:20 -0400
Florin Malita <[EMAIL PROTECTED]> wrote:
> The exception path associated with an invalid ext_csd_struct returns
> without freeing ext_csd.
>
> Coverity CID 1909.
>
> Signed-off-by: Florin Malita
Quite right. Applied.
Rgds
--
-
On Wed, 17 Oct 2007 11:53:40 +0200
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
> From: Andrew Victor <[EMAIL PROTECTED]>
>
> A small MMC driver cleanup.
>
> Use the defined AT91_MCI_ERRORS in at91_mci_completed_command()
> instead of specifying all the error bits individually.
>
> Signed-off-by: A
rownell <[EMAIL PROTECTED]>
>
I think I'll have to NAK this as I believe it breaks MMC 4.2. I'll check
and get back to you.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio
):
mmc: possible leak in mmc_read_ext_csd
Pierre Ossman (1):
net: libertas sdio driver
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
n invalid pointer
(the oops in the first dmesg).
Can you reproduce this? To help you I need to see the errors given by the MMC
layer. You should also try reproducing it without a tainted kernel (i.e. don't
load ndiswrapper).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maint
's no guarantee against bugs.
(But since my code is bug free, that shouldn't be an issue. ;))
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer htt
s not supported by ath5k yet, and the choice is
> between ndiswrapper or Vista.). Should I enable some debugging option
> for the MMC layer?
Not at this point no. The debugging tends to be quite noise so it easily drowns
out any temporary problems.
Rgds
--
-- Pierre Ossman
Linux k
>
Since there was no error from the mmc level there, I wouldn't be so sure. Could
you try a complete fsck of the card to check that the camera is constructing a
proper FAT?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudi
280 MB).
Did you partition and format this card in the camera or in Linux?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To un
On Mon, 05 Nov 2007 14:51:45 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
> > On Mon, 05 Nov 2007 11:51:26 +0100
> > Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> Ah, I forgot: I have a dump
On Mon, 05 Nov 2007 14:46:33 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
> > Did you partition and format this card in the camera or in Linux?
>
> In the camera. It happened both with a Kodak and a Panas
On Tue, 6 Nov 2007 22:15:37 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 2 Nov 2007 06:23:48 -0700 (PDT) Alex Dubov <[EMAIL PROTECTED]>
> > wrote:
> >
> > I also wonder, where do I send the patches if nobody currently maintains
> > this thing?
> >
>
> Me, Pierre, lkml?
I'm not
Cc: Jens Axboe <[EMAIL PROTECTED]>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Ouch! Well that was obviously a bug. I wonder how the hell it only explodes for
Romano. I've been shuffling loads of data using -rc1 without an incident.
Rgds
--
-- Pierre Ossman
L
s though. :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-k
m confused. Didn't the previous fix solve your problems?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from t
_QUIRK_BROKEN_DMA) &&
(host->flags & SDHCI_USE_DMA)) {
- DBG("Disabling DMA as it is marked broken");
+ DBG("Disabling DMA as it is marked broken\n");
host->flags &= ~SDHCI_USE_DMA;
}
--
-
support the general sentiment)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubsc
n the MMC init sequence.
I guess what we lose by not supporting these is 8 bit data bus, but as
we do not currently have a controller for that I think the point is moot.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer h
ags &
(MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY|MMC_RSP_OPCODE))
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To uns
rivers have released
control of the card. At that point there is no one else accessing the
device. If you see something else, then we have a bug somewhere.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://
e a problem, please try to figure out who it is
accessing the device.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe fro
Manuel Lauss wrote:
> Hi,
>
> here's a trivial patch which adds R6 reponse support to the au1xmmc
> driver. Fixes SD card detection / operation.
>
NAK. MMC_RSP_R1 and MMC_RSP_R6 have the same value so this will break
the switch.
Rgds
--
-- Pierre Ossman
Linux ke
stops with CMD7 returning error.
>
Can I see a dump with MMC_DEBUG enabled?
On a related note... Would you, or anyone else you know, be willing to
sign up as official maintainer of this driver? Otherwise I'll have to
mark it as unmaintained.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC
turn result;
}
I'm not particularly proud of the second chunk though. Ideas on how to
handle when we actually get a transmission problem and not just getting
killed by a signal?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudi
server would answer, but would gave you bogus answer.
>
This sounds promising though. In that case it wouldn't be necessary to
store the entire request, just the sequence number, right?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Puls
orks now on the previously
> thought-to-be-broken HW.
>
So in order to detect any similar problems in the future, I'd like a
patch that adds a "default:" to that switch statement.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Puls
taining it? I have source for this
> driver which also implements SDIO, also from AMD. It's a bit dated (for
> 2.6.11). But I'm willing to look into problems, as long as I have access
> to the hardware.
>
I have not heard anything from Raza, so I wouldn't even know who to
c
ult;
+
+ ncp_req_put(req);
+
+ return result;
}
/*
@@ -751,11 +781,6 @@ static int ncp_do_request(struct ncp_server
*server, int size,
DDPRINTK("do_ncp_rpc_call returned %d\n", result);
- if (result < 0) {
- /* There was a problem with I/O, so the connect
Christopher "Monty" Montgomery wrote:
> This patch was generated against 2.6.20-rc5; it fixes a bug that
> cropped up in a late 2.6.19-mm kernel.
>
> When ALSA's sysfs device creation was converted from using
> class_device_create() to device_create(), the fourth param from
> class_device_create()
Christopher "Monty" Montgomery wrote:
>
> My machines and the fedora rawhide machines using the 2.6.20-rcX
> releases look nothing like what you pasted. If they did, hald would
> be working... (I'll note that bugs have also been logged against
> Pulse and HAL by users having trouble, so it's not
Christopher "Monty" Montgomery wrote:
>
> Interesting to know. Looking more closely, it looks like machines
> here are split between the messed up output I forwarded previously and
> the output that is expected. All of my personal boxes are messed up.
>
There is some option about deprecated sy
Anderson Briglia wrote:
> Ok. I will fix the code and send another version of this patch on the V9
> series e-mail thread.
>
Have you found the time to fix this?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core
ng lock, and doesn't contain a fix for it.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send th
ooks fine, so send away.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubsc
lease add a "--" after the signed-off-by lines so that git can
parse the email.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdeskto
T|MMC_RSP_CRC)
> +#define MMC_RSP_R7 (MMC_RSP_PRESENT|MMC_RSP_CRC)
>
> #define mmc_resp_type(cmd) ((cmd)->flags &
> (MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY|MMC_RSP_OPCODE))
>
>
Wrong. R7 is defined as MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE.
(So is R
he MMC layer).
- Could you change the patch so that it covers all ENE controllers and send it
out for testing on sdhci-devel? That way we could see if there are any more ENE
controllers that will benefit from this
quirk. Just remember to ask people for a lspci.
Again, very good work.
Rgds
--
;t even need our own data structure to contain the
> + * mtd_info.
> + */
> +static int mmc_mtd_probe(struct mmc_card *card)
> +{
> + struct mtd_info *mtd;
> + int ret;
> +
> + if (!(card->csd.cmdclass & CCC_ERASE))
> + return -ENODEV;
>
trip
out my own email from the list, so a "Reply All" includes myself in the to list.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdeskto
version of the protocol, a version where
addressing is done on a sector (512 byte) basis instead of bytes.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer ht
> Done. I thought we needed it before both SD_APP_SEND_OP_COND calls but
> it's only needed before the second one so I've moved it inline into
> mmc_setup.
>
>
The spec says we need it at both (even though it might not be so in
practice). We should follow the spec f
{
> mmc_send_op_cond(host, host->ocr, NULL);
> + }
>
> mmc_discover_cards(host);
>
>
Nah... I think a mmc_send_if_cond() would be cleaner. The setup routine
should contain the sequence of events needed, while we abstract the
really low level grunt w
I would
suggest trying without ndiswrapper loaded.
As this is now a tifm_sd related issue, I would recommend that Alex
Dubov takes over and the list of choice being the kernel mailing list
(both cc:d).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Pul
ver works is unsafe.
>
>
Amen to that. All hw vendors that implement this particular form of
brain damage should be dragged out and shot.
I'll fix a patch for this later on.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Pul
Philip Langdale wrote:
> Pierre Ossman wrote:
>
>> Amen to that. All hw vendors that implement this particular form of
>> brain damage should be dragged out and shot.
>>
>> I'll fix a patch for this later on.
>>
>
> See my updated Take 3 patch
cting
one size and sticking with it.
As the newer cards only support a block size of 512 bytes, the most future
proof would be to use that.
>
> I tried to do multiple block access at first, but then took it out again.
> If it turns out valuable to have these, I'll implement it
ugh and will be more fine grained in a final
version, but the end result should be the same. So I'd like to get as much
input as possible from anyone who has the
time to review it. There are lots of changes, so I'm bound to have made
mistakes in a few places.
Rgds
--
-- Pierre Os
final suggested solution was to serialize all the
block subsystems so that only one was present on the stack at any given
time.
I was constantly hitting this problem a few years ago when I was running
md+xfs+nfs. The fix was in -mm back then as well. ;)
Rgds
--
-- Pierre Ossman
Linux kernel
uency. With tickless idle.. that's not what you
> want.
>
So with a local apic, and acpi_pm as clocksource, I shouldn't be getting timer
interrupts? Yet I do. Which I assume means that the kernel will still get woken
up very often.
Rgds
--
-- Pierre Ossman
Linux kernel, MM
Arjan van de Ven wrote:
> On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
>
>>
>> So with a local apic, and acpi_pm as clocksource, I shouldn't be getting
>> timer
>> interrupts?
>>
>
> timer interrupts as in "irq0"?
>
T even if it is not enabled by the
> BIOS. This will still end up on IRQ#0, but will give way longer idle
> sleeps than the PIT.
>
>
So then the next two questions are; is it possible to disable C3 and is
it a net power gain to get rid of the wakeups in favor of having C3.
Rgds
contains the following patches against 2.6.21-rc1:
>>
>
> Possible build fix for
>
> drivers/built-in.o: In function `mmc_queue_thread':
> /mnt/md0/devel/linux-work5/drivers/mmc/card/queue.c:76: undefined reference
> to `blk_queue_plugged'
> make: *** [.tmp_
permanently screwed, or just temporarily.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send t
Arjan van de Ven wrote:
> if it's something built in the last year or two you have the hw.
>
>
I have an ICH4-M, and from Intel's datasheets it looks like I got the
short straw..
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
on though. I'd
guess it is present for non-highmem so that things behave somewhat
similar for both the highmem and non-highmem cases.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesk
d the final
response copy if the process has gone belly up.
Now my next question in that case is, what is the purpose of
server->packet. Couldn't this buffer be provided by the caller like the
response buffer?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://
7;d prefer vendors who either
can provide samples or where the hardware is cheap and freely available
so I can just go out and by one.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core
Salt (1):
mmc: Power quirk for ENE controllers
Manuel Lauss (2):
mmc: au1xmmc: implement proper ro switch detection
mmc: au1xmmc: return errors for unknown response types
Philip Langdale (1):
mmc: Add support for SDHC cards
Pierre Ossman (13):
mmc: replace host
terrupts, is it safe to try and share an
> interrupt with this chip anyway?
>
This is all perfectly valid. The wbsd hw and driver can handle sharing the
interrupt line, while the floppy cannot. If you want to avoid this, then don't
load the floppy driver or assign another irq for wbsd.
g this with SD?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
i 17548 0
> tifm_core 7960 2 tifm_sd,tifm_7xx1
> mmc_core 24096 3 mmc_block,tifm_sd,sdhci
>
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
r
e crash if it is).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linu
neral mmc
> problem.
> The problem is described here:
> http://lists.freedesktop.org/archives/hal/2007-January/006960.html
>
Odd. This might be the whole sysfs restructuring thing causing problems. Can you
check if that user has CONFIG_SYSFS_DEPRECATED on?
Rgds
--
-- Pierre Ossman
201 - 300 of 486 matches
Mail list logo
