Where is place of arch independed companion chips?

Where is place of arch independed companion chips?

[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.

-- 
Regards
Andrey Volkov

Re: [Linux-fbdev-devel] Where is place of arch independed companion chips?

[Antonino A. Daplas]

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

Re: [Linux-fbdev-devel] Where is place of arch independed companion chips?

[Andrey Volkov]

Hi Tony,

Antonino A. Daplas wrote:
> 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.
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

Re: Where is place of arch independed companion chips?

[Jamey Hicks]

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)?
>
>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

Re: Where is place of arch independed companion chips?

[Greg KH]

On Mon, Aug 01, 2005 at 08:29:35AM -0400, Jamey Hicks wrote:
> 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)?
> >
> >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

Re: Where is place of arch independed companion chips?

[Richard Purdie]

On Mon, 2005-08-01 at 11:13 -0700, Greg KH wrote:
> > 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

Re: Re: Where is place of arch independed companion chips?

[Andrey Volkov]

Richard Purdie wrote:
> On Mon, 2005-08-01 at 11:13 -0700, Greg KH wrote:
> 
>>>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

Re: Where is place of arch independed companion chips?

[Mark Underwood]

--- Richard Purdie <rpurdie@rpsys.net> wrote:

> On Mon, 2005-08-01 at 11:13 -0700, Greg KH wrote:
> > > 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...

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


> 
> Richard
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 



		
___________________________________________________________ 
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

Re: Where is place of arch independed companion chips?

[Pavel Machek]

Hi!

> > >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