On Sun, 13 May 2007 16:24:55 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
> > On Sun, 13 May 2007 15:34:51 +0200
> > Pierre Ossman <[EMAIL PROTECTED]> wrote:
> >
> >> Does that sound like something that would work for you? From my point of
> >> view
> >> it's a much
Haavard Skinnemoen wrote:
> On Sun, 13 May 2007 15:34:51 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>> Does that sound like something that would work for you? From my point of view
>> it's a much cleaner solution that has the benefit of not being tied into a
>> certain subsystem (i.e. this
On Sun, 13 May 2007 15:34:51 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > I'm not sure how many embedded people actually know how to build an
> > initrd for a custom board.
> >
>
> All the ones I have on my desk right now use initrd. ;)
Ok, I guess we'll just have to look into that, the
Haavard Skinnemoen wrote:
>
> You're right about my assumptions. Are there any existing drivers that
> break them? Are there even any usb-based controllers around? I though
> most usb-mmc controllers used the USB Mass Storage class and thus
> don't use the mmc subsystem at all.
>
Yes, but they m
On Thu, 10 May 2007 21:41:22 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> You're assuming two things:
>
> 1. The bus the host controller reside on is synchronous both in adding devices
> and drivers. This is true for most buses, but not all. As we can see, the MMC
> bus is an example of one t
On Thu, 10 May 2007 10:51:50 -0700
"Matt Reimer" <[EMAIL PROTECTED]> wrote:
> On 5/10/07, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> > Btw, how can I wait for the scanning to complete from early userspace?
>
> A workaround is to pass the kernel argument rootdelay=5 or something
> like that (
Haavard Skinnemoen wrote:
> On Thu, 10 May 2007 17:58:27 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> Is there any way this can happen? Host controller drivers register
> themselves from module_init(), their probe() function gets called,
> which calls mmc_add_host(), which schedules the in
On 5/10/07, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
Btw, how can I wait for the scanning to complete from early userspace?
A workaround is to pass the kernel argument rootdelay=5 or something
like that (the value specifies seconds).
Matt
-
To unsubscribe from this list: send the line "un
On Thu, 10 May 2007 17:58:27 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
> >
> > Ok, is there any better way to achieve the same this? As far as I
> > can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
> > same purpose -- it ensures that scans that
Haavard Skinnemoen wrote:
>
> Ok, is there any better way to achieve the same this? As far as I
> can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
> same purpose -- it ensures that scans that have already been started
> will have completed before the function continues.
>
Not
On Thu, 10 May 2007 15:45:54 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
> >
> > What exactly makes this unreliable? This is done almost exactly the
> > same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
> >
>
> I am not against the function of waiting for an i
Haavard Skinnemoen wrote:
>
> What exactly makes this unreliable? This is done almost exactly the
> same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
>
I am not against the function of waiting for an initial scan, what I oppose is
using side effects to achieve that function. I do not want to
On Thu, 10 May 2007 14:04:25 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote:
> > At some point before 2.6.20, the mmc subsystem moved the card
> > detection code to its own workqueue. One consequence of this change
> > is that when using an mmc card as a root device, the
Haavard Skinnemoen wrote:
> At some point before 2.6.20, the mmc subsystem moved the card
> detection code to its own workqueue. One consequence of this change
> is that when using an mmc card as a root device, the card may get
> detected after the init task attempts to mount the root filesystem,
>
At some point before 2.6.20, the mmc subsystem moved the card
detection code to its own workqueue. One consequence of this change
is that when using an mmc card as a root device, the card may get
detected after the init task attempts to mount the root filesystem,
causing a kernel panic because the
15 matches
Mail list logo
