Marvell D2Plug

[saeed bishara]

On Mon, May 16, 2011 at 7:34 PM, Belisko Marek <marek.belisko at gmail.com> wrote:
> On Mon, May 16, 2011 at 6:28 PM, saeed bishara <saeed.bishara at gmail.com> wrote:
>> On Mon, May 16, 2011 at 6:46 PM, Greg KH <greg at kroah.com> wrote:
>>> On Mon, May 16, 2011 at 11:20:59AM +0300, saeed bishara wrote:
>>>> On Sun, May 15, 2011 at 7:28 PM, Greg KH <greg at kroah.com> wrote:
>>>> > On Sun, May 15, 2011 at 03:11:21PM +0300, saeed bishara wrote:
>>>> >> On Sun, May 15, 2011 at 10:57 AM, saeed bishara <saeed.bishara at gmail.com> wrote:
>>>> >> > Hi all,
>>>> >> >    Marvell is looking to improve the mainline support of its new plug
>>>> >> > (http://www.globalscaletechnologies.com/c-8-d2plug.aspx)
>>>> >> >  this plug is based on the ARMADA 510 SoC
>>>> >> > (http://www.marvell.com/products/processors/applications/armada_500/Marvell_Armada510_SoC.pdf),
>>>> >> > we have added basic support to this SoC into mainline kernel (under
>>>> >> > arch/arm/mach-dove), but there still a lot of features/drivers
>>>> >> > missing, and we would like to work with community developers on this.
>>>> >> >   Right now Marvell is working on disclosed version of the spec of
>>>> >> > this SoC, and will provide need information for developers. and we are
>>>> >> > ready to send - for free - some D2plugs for active developers those
>>>> >> > willing to contribute.
>>>> >> >   as I said, the mainline have basic support for this SoC (aka dove),
>>>> >> > but there are a lot of drivers/features that missing: lcd driver,
>>>> >> > power management, nand driver, etc. so if you are interested in
>>>> >> > pushing those features to mainline, please let me know.
>>>> >> >
>>>> >> > saeed
>>>> >> >
>>>> >> please note that Marvell provides Linux kernel (based on 2.6.32) for
>>>> >> this device, but this kernel is not written according to kernel coding
>>>> >> style, but can be very useful as reference. here is a link to git tree
>>>> >> http://kernel.ubuntu.com/git?p=ycmiao/ubuntu-maverick.git;a=tree;h=refs/heads/mvl-dove;hb=refs/heads/mvl-dove
>>>> >
>>>> > Is that the tree with the drivers as well?
>>>> yes, it includes all the drivers/features.
>>>
>>> Great.
>>>
>>>> > Do you want us to pick things out here, or go off of a more recent tree
>>>> > given the above mention of merging the arch-specific stuff to mainline?
>>>> a lot of stuff need to be re-written according to new APIs and linux
>>>> coding style, so I don't thinks it can be merge to staging tree,
>>>
>>> Well the rewrite for new apis would happen first, then the code can be
>>> merged into the staging tree, then we can do the "real" cleanup
>>> afterward, with everyone helping out.
>>>
>>>> > Oh, and do you also need help with the arch-specific code as well, given
>>>> > the recent changes in how the ARM developers are working with the rest
>>>> > of the kernel community?  If so, we (well, at least I) can help out
>>>> > there.
>>>> yes, sure. the current mainline already includes basic support for the
>>>> dove soc. but a lot of features. still missing, for example, the
>>>> support for the D2plug board, clock management etc. I was planning to
>>>> add this support by myself, but, as you mentioned, this will not be
>>>> easy to do as it used to be. so maybe we have to do it using
>>>> devicetree. so it will be great if somebody can help with that.
>>>
>>> I think you need to lay out exactly what you want/need done here, as it
>>> sounds like both a lot of different things, and pretty vague.
>>>
>>> Do you want to go through the above tree and look at the diff and pick
>>> the different pieces out, or do you want me to do that and ask you about
>>> all of them?
>> Greg, it very big list, our patch touches ~1000 files.
>> I think I should prepare a list of the following:
>> 1. new drives that need to be written from scratch
>> 2. missing features for the existing drivers
>> 3. arch-specific missing features.
>>
>> the tree above will be used by developers as a reference only. I don't
>> think it's practical to rebase it to recent kernels or to do direct
>> work on it. does that answers your question?
>>
>>>
>>> Also, how can I get a sample device to test that I don't break anything?
>> sure, we will send you one.
> Could I get also one? I can contribute aswell. When there will be a
> list it would be very good.
sure.

saeed