* Driver core support for early platform devices
@ 2011-12-22 17:15 Moffett, Kyle D
2011-12-22 17:45 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Moffett, Kyle D @ 2011-12-22 17:15 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, Greg KH, Grant Likely, Rob Herring,
Benjamin Herrenschmidt
Hi,
I'm tinkering with some improvements to the way that OpenPIC/MPIC are
detected and loaded on PowerPC platforms, and it seems like I am trying
to use the driver model before it is fully initialized.
In particular, it seems like it should be possible to simply declare an
OpenPIC in the device-tree and have it automatically bound to a platform
driver declaring the right OpenFirmware match strings.
Unfortunately, it needs to be bound by init_IRQ() time, while the driver
model does not get initialized until much later (after the scheduler is
up and running).
As far as I can tell, there seem to be 2 possible approaches to making
that possible:
(1) Split the driver-model initialization into "early" and "late" phases
so that drivers can be registered and devices probed very early on
and then replay the necessary scheduler-dependent things after the
system is mostly started up (IE: devtmpfs, etc).
(2) Create a separate mini-platform-driver-model which can create and
probe platform devices early on and then automatically register them
properly on the platform_bus once the driver model comes up.
Do you think this is the right approach? Is there any existing work
being done to support either model?
Thanks for your help!
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Driver core support for early platform devices
2011-12-22 17:15 Driver core support for early platform devices Moffett, Kyle D
@ 2011-12-22 17:45 ` Greg KH
2011-12-22 17:55 ` Moffett, Kyle D
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2011-12-22 17:45 UTC (permalink / raw)
To: Moffett, Kyle D
Cc: linux-kernel@vger.kernel.org, Grant Likely, Rob Herring,
Benjamin Herrenschmidt
On Thu, Dec 22, 2011 at 11:15:06AM -0600, Moffett, Kyle D wrote:
> Hi,
>
> I'm tinkering with some improvements to the way that OpenPIC/MPIC are
> detected and loaded on PowerPC platforms, and it seems like I am trying
> to use the driver model before it is fully initialized.
>
> In particular, it seems like it should be possible to simply declare an
> OpenPIC in the device-tree and have it automatically bound to a platform
> driver declaring the right OpenFirmware match strings.
>
> Unfortunately, it needs to be bound by init_IRQ() time, while the driver
> model does not get initialized until much later (after the scheduler is
> up and running).
>
> As far as I can tell, there seem to be 2 possible approaches to making
> that possible:
>
> (1) Split the driver-model initialization into "early" and "late" phases
> so that drivers can be registered and devices probed very early on
> and then replay the necessary scheduler-dependent things after the
> system is mostly started up (IE: devtmpfs, etc).
We already have that today with the "early_platform*" functions, right?
Will those work for you, or do you need this for a bus you are creating
and not using the platform bus?
If the later, why not just duplicate the logic of the early_platform*
code for your bus? Will that work?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Driver core support for early platform devices
2011-12-22 17:45 ` Greg KH
@ 2011-12-22 17:55 ` Moffett, Kyle D
2011-12-22 18:10 ` Greg KH
2011-12-22 20:45 ` Rob Herring
0 siblings, 2 replies; 6+ messages in thread
From: Moffett, Kyle D @ 2011-12-22 17:55 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, Grant Likely, Rob Herring,
Benjamin Herrenschmidt
On Dec 22, 2011, at 12:45, Greg KH wrote:
> On Thu, Dec 22, 2011 at 11:15:06AM -0600, Moffett, Kyle D wrote:
>> Hi,
>>
>> I'm tinkering with some improvements to the way that OpenPIC/MPIC are
>> detected and loaded on PowerPC platforms, and it seems like I am trying
>> to use the driver model before it is fully initialized.
>>
>> In particular, it seems like it should be possible to simply declare an
>> OpenPIC in the device-tree and have it automatically bound to a platform
>> driver declaring the right OpenFirmware match strings.
>>
>> Unfortunately, it needs to be bound by init_IRQ() time, while the driver
>> model does not get initialized until much later (after the scheduler is
>> up and running).
>>
>> As far as I can tell, there seem to be 2 possible approaches to making
>> that possible:
>>
>> (1) Split the driver-model initialization into "early" and "late" phases
>> so that drivers can be registered and devices probed very early on
>> and then replay the necessary scheduler-dependent things after the
>> system is mostly started up (IE: devtmpfs, etc).
>
> We already have that today with the "early_platform*" functions, right?
> Will those work for you, or do you need this for a bus you are creating
> and not using the platform bus?
Well, I can't figure out how "early_platform" is actually supposed to
integrate with the platform bus itself. It seems designed mostly for
drivers like "earlyprintk" et. al. for which loading is controlled by
a kernel parameter.
Specifically, I don't see any "early_platform" logic to match devices in
the OF device-tree based on the driver "of_match" parameters, just based
on text strings in early_param().
Furthermore, if I register an "early_platform" device, it seems to get
unregistered when the normal driver model is brought up, instead of
being sucked in and promoted to a normal platform_device. That code is
pretty poorly documented and only used in a couple places right now,
though, so it's possible I am misreading it.
Cheers,
Kyle Moffett
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Driver core support for early platform devices
2011-12-22 17:55 ` Moffett, Kyle D
@ 2011-12-22 18:10 ` Greg KH
2011-12-22 20:45 ` Rob Herring
1 sibling, 0 replies; 6+ messages in thread
From: Greg KH @ 2011-12-22 18:10 UTC (permalink / raw)
To: Moffett, Kyle D, Magnus Damm
Cc: linux-kernel@vger.kernel.org, Grant Likely, Rob Herring,
Benjamin Herrenschmidt
On Thu, Dec 22, 2011 at 11:55:56AM -0600, Moffett, Kyle D wrote:
> On Dec 22, 2011, at 12:45, Greg KH wrote:
> > On Thu, Dec 22, 2011 at 11:15:06AM -0600, Moffett, Kyle D wrote:
> >> Hi,
> >>
> >> I'm tinkering with some improvements to the way that OpenPIC/MPIC are
> >> detected and loaded on PowerPC platforms, and it seems like I am trying
> >> to use the driver model before it is fully initialized.
> >>
> >> In particular, it seems like it should be possible to simply declare an
> >> OpenPIC in the device-tree and have it automatically bound to a platform
> >> driver declaring the right OpenFirmware match strings.
> >>
> >> Unfortunately, it needs to be bound by init_IRQ() time, while the driver
> >> model does not get initialized until much later (after the scheduler is
> >> up and running).
> >>
> >> As far as I can tell, there seem to be 2 possible approaches to making
> >> that possible:
> >>
> >> (1) Split the driver-model initialization into "early" and "late" phases
> >> so that drivers can be registered and devices probed very early on
> >> and then replay the necessary scheduler-dependent things after the
> >> system is mostly started up (IE: devtmpfs, etc).
> >
> > We already have that today with the "early_platform*" functions, right?
> > Will those work for you, or do you need this for a bus you are creating
> > and not using the platform bus?
>
> Well, I can't figure out how "early_platform" is actually supposed to
> integrate with the platform bus itself. It seems designed mostly for
> drivers like "earlyprintk" et. al. for which loading is controlled by
> a kernel parameter.
>
> Specifically, I don't see any "early_platform" logic to match devices in
> the OF device-tree based on the driver "of_match" parameters, just based
> on text strings in early_param().
>
> Furthermore, if I register an "early_platform" device, it seems to get
> unregistered when the normal driver model is brought up, instead of
> being sucked in and promoted to a normal platform_device. That code is
> pretty poorly documented and only used in a couple places right now,
> though, so it's possible I am misreading it.
I think Magnus wrote this code, as he was having the same issues you
were, so he should be able to answer these questions better than I, as I
do not know this code at all, sorry.
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Driver core support for early platform devices
2011-12-22 17:55 ` Moffett, Kyle D
2011-12-22 18:10 ` Greg KH
@ 2011-12-22 20:45 ` Rob Herring
2012-01-05 18:41 ` Grant Likely
1 sibling, 1 reply; 6+ messages in thread
From: Rob Herring @ 2011-12-22 20:45 UTC (permalink / raw)
To: Moffett, Kyle D
Cc: Greg KH, linux-kernel@vger.kernel.org, Grant Likely,
Benjamin Herrenschmidt
On 12/22/2011 11:55 AM, Moffett, Kyle D wrote:
> On Dec 22, 2011, at 12:45, Greg KH wrote:
>> On Thu, Dec 22, 2011 at 11:15:06AM -0600, Moffett, Kyle D wrote:
>>> Hi,
>>>
>>> I'm tinkering with some improvements to the way that OpenPIC/MPIC are
>>> detected and loaded on PowerPC platforms, and it seems like I am trying
>>> to use the driver model before it is fully initialized.
>>>
>>> In particular, it seems like it should be possible to simply declare an
>>> OpenPIC in the device-tree and have it automatically bound to a platform
>>> driver declaring the right OpenFirmware match strings.
>>>
>>> Unfortunately, it needs to be bound by init_IRQ() time, while the driver
>>> model does not get initialized until much later (after the scheduler is
>>> up and running).
>>>
>>> As far as I can tell, there seem to be 2 possible approaches to making
>>> that possible:
>>>
>>> (1) Split the driver-model initialization into "early" and "late" phases
>>> so that drivers can be registered and devices probed very early on
>>> and then replay the necessary scheduler-dependent things after the
>>> system is mostly started up (IE: devtmpfs, etc).
>>
>> We already have that today with the "early_platform*" functions, right?
>> Will those work for you, or do you need this for a bus you are creating
>> and not using the platform bus?
>
> Well, I can't figure out how "early_platform" is actually supposed to
> integrate with the platform bus itself. It seems designed mostly for
> drivers like "earlyprintk" et. al. for which loading is controlled by
> a kernel parameter.
>
> Specifically, I don't see any "early_platform" logic to match devices in
> the OF device-tree based on the driver "of_match" parameters, just based
> on text strings in early_param().
>
> Furthermore, if I register an "early_platform" device, it seems to get
> unregistered when the normal driver model is brought up, instead of
> being sucked in and promoted to a normal platform_device. That code is
> pretty poorly documented and only used in a couple places right now,
> though, so it's possible I am misreading it.
>
> Cheers,
> Kyle Moffett
There was a proposal for DT support of early platform devices here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/054529.html
Rob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Driver core support for early platform devices
2011-12-22 20:45 ` Rob Herring
@ 2012-01-05 18:41 ` Grant Likely
0 siblings, 0 replies; 6+ messages in thread
From: Grant Likely @ 2012-01-05 18:41 UTC (permalink / raw)
To: Rob Herring
Cc: Moffett, Kyle D, Greg KH, linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt
On Thu, Dec 22, 2011 at 02:45:01PM -0600, Rob Herring wrote:
> On 12/22/2011 11:55 AM, Moffett, Kyle D wrote:
> > On Dec 22, 2011, at 12:45, Greg KH wrote:
> >> On Thu, Dec 22, 2011 at 11:15:06AM -0600, Moffett, Kyle D wrote:
> >>> Hi,
> >>>
> >>> I'm tinkering with some improvements to the way that OpenPIC/MPIC are
> >>> detected and loaded on PowerPC platforms, and it seems like I am trying
> >>> to use the driver model before it is fully initialized.
> >>>
> >>> In particular, it seems like it should be possible to simply declare an
> >>> OpenPIC in the device-tree and have it automatically bound to a platform
> >>> driver declaring the right OpenFirmware match strings.
> >>>
> >>> Unfortunately, it needs to be bound by init_IRQ() time, while the driver
> >>> model does not get initialized until much later (after the scheduler is
> >>> up and running).
> >>>
> >>> As far as I can tell, there seem to be 2 possible approaches to making
> >>> that possible:
> >>>
> >>> (1) Split the driver-model initialization into "early" and "late" phases
> >>> so that drivers can be registered and devices probed very early on
> >>> and then replay the necessary scheduler-dependent things after the
> >>> system is mostly started up (IE: devtmpfs, etc).
> >>
> >> We already have that today with the "early_platform*" functions, right?
> >> Will those work for you, or do you need this for a bus you are creating
> >> and not using the platform bus?
> >
> > Well, I can't figure out how "early_platform" is actually supposed to
> > integrate with the platform bus itself. It seems designed mostly for
> > drivers like "earlyprintk" et. al. for which loading is controlled by
> > a kernel parameter.
> >
> > Specifically, I don't see any "early_platform" logic to match devices in
> > the OF device-tree based on the driver "of_match" parameters, just based
> > on text strings in early_param().
> >
> > Furthermore, if I register an "early_platform" device, it seems to get
> > unregistered when the normal driver model is brought up, instead of
> > being sucked in and promoted to a normal platform_device. That code is
> > pretty poorly documented and only used in a couple places right now,
> > though, so it's possible I am misreading it.
> >
> > Cheers,
> > Kyle Moffett
>
> There was a proposal for DT support of early platform devices here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/054529.html
I'm not a fan of early platform devices, and as Kyle points out, it
doesn't really solve his problem.
Kyle, I wouldn't get too tied up with thinking about the device model.
There are always some critical core devices, like root interrupt
controllers, that just have to be set up way earlier than any of the
initcalls. So, yes, it would be nice if the kernel automagically
picked up the root irq controller from the device tree, and if it was
wired into the driver model. However, in practical terms it doesn't
buy us much. You can get almost the same behaviour by the SoC support
code providing a table of the irq controllers that need to be set up
at boot time and using a helper function to initialize them in the
correct order.
Have a look at of_irq_init(). It might do what you need.
g.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-05 18:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-22 17:15 Driver core support for early platform devices Moffett, Kyle D
2011-12-22 17:45 ` Greg KH
2011-12-22 17:55 ` Moffett, Kyle D
2011-12-22 18:10 ` Greg KH
2011-12-22 20:45 ` Rob Herring
2012-01-05 18:41 ` Grant Likely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).