Hi Greg,
While I write driver for SM501 CC (which have graphics controller, USB
MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard),
I bumped with next ambiguity:
Where is a place of this chip's Kconfig/drivers in
kernel config/drivers tree? May be create new node in drivers subtree?
Or put it under graphics node (since it's main function of this CC)?
AFAIK, this is not one such multifunctional monster in the world, so
somebody bumped with this problem again in future.
--
Regards
Andrey Volkov
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-07-31 04:40:51
Andrey Volkov wrote:
Hi Greg,
While I write driver for SM501 CC (which have graphics controller, USB
MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard),
I bumped with next ambiguity:
Where is a place of this chip's Kconfig/drivers in
kernel config/drivers tree? May be create new node in drivers subtree?
Or put it under graphics node (since it's main function of this CC)?
You will have to split your driver (graphics under drivers/video, usb
under drivers/usb, ac97 under sound, video capture under drivers/media,
etc.
Tony
Hi Greg,
While I write driver for SM501 CC (which have graphics controller, USB
MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard),
I bumped with next ambiguity:
Where is a place of this chip's Kconfig/drivers in
kernel config/drivers tree? May be create new node in drivers subtree?
Or put it under graphics node (since it's main function of this CC)?
You will have to split your driver (graphics under drivers/video, usb
under drivers/usb, ac97 under sound, video capture under drivers/media,
etc.
Yes, it was first what I try, BUT - all these drivers have common
code (as bus driver, in my case) and some of private headers.
And problem exactly in this code. This code NOT video/audio....., this
code is abstract bus driver, and doesn't fall under some exist kernel
tree node :(.
--
Regards
Andrey Volkov
Hi Greg,
While I write driver for SM501 CC (which have graphics controller, USB
MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard),
I bumped with next ambiguity:
Where is a place of this chip's Kconfig/drivers in
kernel config/drivers tree? May be create new node in drivers subtree?
Or put it under graphics node (since it's main function of this CC)?
AFAIK, this is not one such multifunctional monster in the world, so
somebody bumped with this problem again in future.
Good question. I was about to submit a patch that created
drivers/platform because the toplevel driver for MQ11xx is a
platform_device driver. Any thoughts on this?
Jamey
On Mon, Aug 01, 2005 at 08:29:35AM -0400, Jamey Hicks wrote:
Andrey Volkov wrote:
quoted
Hi Greg,
While I write driver for SM501 CC (which have graphics controller, USB
MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard),
I bumped with next ambiguity:
Where is a place of this chip's Kconfig/drivers in
kernel config/drivers tree? May be create new node in drivers subtree?
Or put it under graphics node (since it's main function of this CC)?
AFAIK, this is not one such multifunctional monster in the world, so
somebody bumped with this problem again in future.
Good question. I was about to submit a patch that created
drivers/platform because the toplevel driver for MQ11xx is a
platform_device driver. Any thoughts on this?
drivers/platform sounds good to me.
thanks,
greg k-h
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Richard Purdie <hidden> Date: 2005-08-02 21:50:43
On Mon, 2005-08-01 at 11:13 -0700, Greg KH wrote:
quoted
Good question. I was about to submit a patch that created
drivers/platform because the toplevel driver for MQ11xx is a
platform_device driver. Any thoughts on this?
drivers/platform sounds good to me.
In another thread (about the ucb1x00) we came up with the idea of
drivers/mfd (mfd = multi function devices).
The core and platform specific parts would live here with suitable clear
naming and the subsection specific parts that were separable would live
in the appropriate place within the kernel.
Just another idea to add to the mix and removes the dilemma of a
multifunction device with isn't platform based...
Richard
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Pavel Machek <hidden> Date: 2005-08-03 06:19:18
Hi!
quoted
quoted
While I write driver for SM501 CC (which have graphics controller, USB
MASTER/SLAVE, AC97, UART, SPI and VIDEO CAPTURE onboard),
I bumped with next ambiguity:
Where is a place of this chip's Kconfig/drivers in
kernel config/drivers tree? May be create new node in drivers subtree?
Or put it under graphics node (since it's main function of this CC)?
AFAIK, this is not one such multifunctional monster in the world, so
somebody bumped with this problem again in future.
Good question. I was about to submit a patch that created
drivers/platform because the toplevel driver for MQ11xx is a
platform_device driver. Any thoughts on this?
drivers/platform sounds good to me.
We have some problems with ucb1x00 chip on some small systems;
originally we wanted it to go into drivers/misc, but that sounded
wrong. Latest idea was drivers/mfd (multi functional devices)...
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Good question. I was about to submit a patch that created
drivers/platform because the toplevel driver for MQ11xx is a
platform_device driver. Any thoughts on this?
drivers/platform sounds good to me.
In another thread (about the ucb1x00) we came up with the idea of
drivers/mfd (mfd = multi function devices).
The core and platform specific parts would live here with suitable clear
naming and the subsection specific parts that were separable would live
in the appropriate place within the kernel.
Just another idea to add to the mix and removes the dilemma of a
multifunction device with isn't platform based...
drivers/mfd as drivers/mfd, I have not objections. Who will send the
patch first?
--
Regards
Andrey Volkov
P.S. Tony, Greg, may be it will someone from you? (I've in mind sn/ subdir)
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
From: Mark Underwood <hidden> Date: 2005-08-08 21:09:23
--- Richard Purdie <rpurdie@rpsys.net> wrote:
On Mon, 2005-08-01 at 11:13 -0700, Greg KH wrote:
quoted
quoted
Good question. I was about to submit a patch
that created
quoted
quoted
drivers/platform because the toplevel driver for
MQ11xx is a
quoted
quoted
platform_device driver. Any thoughts on this?
drivers/platform sounds good to me.
In another thread (about the ucb1x00) we came up
with the idea of
drivers/mfd (mfd = multi function devices).
The core and platform specific parts would live here
with suitable clear
naming and the subsection specific parts that were
separable would live
in the appropriate place within the kernel.
Just another idea to add to the mix and removes the
dilemma of a
multifunction device with isn't platform based...
This is where my sugguestion on the ucb1x00 comess in
(although it seems to have ot lost as I have had no
reply :-( ). To repeat myself:
I was thinking of something like driver/bus into which
we might also be able to put the I2C and LL3 buses.
The only problem is that this might leave some parts
of the multi function chip homeless (if they can't
find a home in other subsystems).
I need to do more homework ;-), but
I think we need a bus driver (I need to see what the
bus subsystem offers) (IP block specific,
platform and arch independent), a core driver to
register busses and clients, and client drivers.
Mark
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf