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

Re: Where is place of arch independed companion chips?

[Andrey Volkov]

Greg KH wrote:
> 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.

May be better drivers/chipset?
Because "platform" imply only platform_device drivers,
but, SM501 as ex., could be connected through PCI too.

-- 
Regards
Andrey Volkov

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

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.

Re: [Linux-fbdev-devel] 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)

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