On Tue, 2013-04-02 at 12:13 +0200, Ulf Hansson wrote:
> Consider a platform having two eMMCs and one SD-card. Each eMMC card
> will take around 400 ms to initialize and the SD-card 700 ms. The card
> initialization times are real examples from eMMCs and SD-cards,
> moreover those are typical values
On Tue, 2013-04-02 at 16:36 +0300, Adrian Hunter wrote:
> On my system it is significant:
>
> Before the patch:
>
> [1.625623] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
>
> After the patch:
>
> [1.935851] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
On Tue, 2013-04-02 at 19:45 +0200, Ulf Hansson wrote:
> On 2 April 2013 12:35, Sergey Yanovich wrote:
> > If the system is booted using initrd and root is not on an mmc card,
> > then mmc modules can be omitted from initrd. The probing will happen
> > only after root is mo
On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
> No, I am booting from eMMC.
Well, in this case you should be aware, that your system is not
concurrency-safe without the patch. It may or may not boot each time
depending on the large number of factors.
> > Maybe introduce mmc_is_hosting_
On Thu, 2013-04-04 at 14:35 +0300, Adrian Hunter wrote:
> On 04/04/13 13:59, Sergey Yanovich wrote:
> > On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
> >> No, I am booting from eMMC.
> >
> > Well, in this case you should be aware, that your system is no
, PXA ports could be configured with different
name and device numbers.
Signed-off-by: Sergey Yanovich
---
drivers/tty/serial/Kconfig | 14 ++
drivers/tty/serial/pxa.c | 22 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial
3.8.2 ARM kernel panics on boot. BUG() log:
[ cut here ]
Kernel BUG at c0226bf4 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0Not tainted (3.8.2+ #2)
PC is at pxa2xx_flash_probe+0x150/0x1a8
LR is at __arm_iore
16384 mtdblock4 mmcblk0: mmc0:b368 USD 3.72 GiB
(driver?)
mmcblk0: p1
b300 3910656 mmcblk0 driver: mmcblk
b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8<---
Signed-off-by: Sergey Yanovich
---
driv
16384 mtdblock4 mmcblk0: mmc0:b368 USD 3.72 GiB
(driver?)
mmcblk0: p1
b300 3910656 mmcblk0 driver: mmcblk
b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8<---
Signed-off-by: Sergey Yanovich
---
changes for
On 14/03/13 06:47, Greg Kroah-Hartman wrote:
On Thu, Mar 14, 2013 at 05:06:23AM +0400, Sergey Yanovich wrote:
/* wait for the known devices to complete their probing */
-
wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
You didn't need to change this fil
On 14/03/13 08:08, Namjae Jeon wrote:> 2013/3/14, Sergey Yanovich
:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Have you ever tried to use rootwait or rootdelay on command line ?
If no, You can use them.
Those options work. However, they introduce a de
On Wed, 2013-05-29 at 15:53 -0700, Andrew Morton wrote:
> On Tue, 21 May 2013 03:21:30 +0400 Sergey Yanovich wrote:
> @@ -321,6 +326,7 @@ static int ds1302_rtc_remove(struct platform_device *pdev)
> > {
> > struct rtc_device *rtc = platform_get_drvdata(pdev);
> >
>From f1cd048a066b249082752a96abce7d33a0cd4ea3 Mon Sep 17 00:00:00 2001
From: Sergey Yanovich
Date: Tue, 21 May 2013 03:06:31 +0400
Subject: [PATCH] rtc-ds1302: handle write protection
This chip has a control register and can prevent altering saved clock.
Without this patch we could have:
--
ystem.
Signed-off-by: Sergey Yanovich
---
drivers/w1/Kconfig |7 ++
drivers/w1/Makefile |3 +-
drivers/w1/notify.c | 76
drivers/w1/w1.c |2 +
drivers/w1/w1.h | 160 --
drivers/w1/w1_int.c |
On Wed, 2013-03-27 at 07:57 -0400, Chris Ball wrote:
> If the delay's significant, I agree with you and will revert this patch.
The patch was reverted. The problem is back. Filed bug:
https://bugzilla.kernel.org/show_bug.cgi?id=56561
A possible solution is to make card a separate device (now only
On Sat, 2013-04-13 at 13:56 +0200, Ulf Hansson wrote:
>
> Den 13 apr 2013 12:49 skrev "Sergey Yanovich" :
> > A possible solution is to make card a separate device (now only the
> host
> > is a device). In this case, the probing could be done asynchronously
> &g
t.d/hwclock.sh stop
[info] Saving the system clock.
[info] Hardware Clock updated to Tue May 21 03:09:01 MSK 2013.
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:14:15 2013 -0.624272 seconds
8<
Signed-off-by: Sergey Yanovich
---
drivers/rtc/rtc-ds1302.c |6 ++
1 file c
e people. Please also report any issues with this driver to
http://bugzilla.kernel.org/show_bug.cgi?id=8352 so that valuable info is
not lost.
Best regards,
Sergey Yanovich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
Hi,
Arnd Bergmann wrote:
As very general comments, you should have the maintainer of the subsystem
(Pierre in this case) on Cc when posting a driver, and you should include
the patch inline in your mail, see Documentation/SubmittingPatches.
I have cc'ed both Pierre and Alex, but my first mes
Hi,
> Have you looked at the last version (0.8)? It fixed all outstanding
issues (as far as I know).
>
Seconded. I've been running Alex's latest driver since its release. I
routinely suspend/resume
60-100 times between boots to S3 and disk, I've suspended with cards
in the socket and I've te
Hi,
> Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
It would be nice i
o, we ship a udev script.
OK, me bad for using the present tense. But you had a single module
in Oct 2006, didn't you? And maybe, you would like to post the script.
--
Sergey Yanovich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
erent that [tifm_7xx1], you would also need a
completely new modules for slots (sd, ms, etc).
--
Sergey Yanovich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
em like 'SMP' selected by default for 686+ CPUs. And
this is far more overhead that a single check of card type on
insert.
To allow customization, boolean module options that disable certain
card type may suffice.
And again, you are doing a great work with the driver.
--
Sergey Yanovich
-
To u
Signed-off-by: Sergey Yanovich <[EMAIL PROTECTED]>
---
drivers/mmc/tifm.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 5410e66..30cab30 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich <[EMAIL PROTECTED]>
---
drivers/mmc/tifm.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 5410e66..30cab30 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/
Alex Dubov wrote:
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step him. Drivers are rarely complex enough to warrant, or even have room for, a
rewrite. And judging from your code it look
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
problems with it, I'll be glad to fix them.
The version in question was recently committed into the -mm tree. Otherwise,
it's available from
the project's website for a couple of months now:
It se
Alex Dubov wrote:
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree - too many
changes are committed into it. The -mm version obviously fits its tree.
I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
After [tifm_sd] is loaded. My smoke test scri
What is "modprobe tifm"?
tifm is the name of the "monolithic blob" that I test :).
What modules have you loaded when it hangs?
I believe is the relevant part:
~$ lsmod | grep "mmc\|tifm"
tifm_sd11272 0
mmc_core 25812 1 tifm_sd
tifm_7xx1 6848 0
Can you successfully run this test with -mm tree? I that case
the fault may be hardware related.
I have uploaded an updated version to bugzilla:
http://bugzilla.kernel.org/attachment.cgi?id=11308&action=view
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Alex Dubov wrote:
I prepared a tarball with 2.6.21 compatible driver (tifm-0.8e on berlios).
This is "good enough" to withdraw my patch. I have filed it to
http://bugzilla.kernel.org/attachment.cgi?id=11312&action=view
in bug 8052
http://bugzilla.kernel.org/show_bug.cgi?id=8052
which seems to
35 matches
Mail list logo
