Xilinx git tree at source.mvista.com

Xilinx git tree at source.mvista.com

[Andrei Konovalov]

Hello,

My Xilinx Virtex Development tree is now alive again.

Please use the dev branch (master is just the ko copy):
http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
Currently it has a patch to enable the framebuffer
on ML403 and ML300 plus TEMAC driver that uses
the PHY lib (FIFO mode support only).
The TEMAC driver is work in progress.
In the queue are SGDMA TEMAC support, and SPI driver
(master only).

My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
The comments / opinions on how to get this driver (not the current incomplete
version of course) accepted into the ko tree are very welcomed.

I am not quite satisfied with how the current git repository
is structured, and may rework it completely later.

Thanks,
Andrei

Re: Xilinx git tree at source.mvista.com

[David H. Lynch Jr.]

Andrei Konovalov wrote:
> Hello,
>
> My Xilinx Virtex Development tree is now alive again.
>
> Please use the dev branch (master is just the ko copy):
> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
> Currently it has a patch to enable the framebuffer
> on ML403 and ML300 plus TEMAC driver that uses
> the PHY lib (FIFO mode support only).
> The TEMAC driver is work in progress.
> In the queue are SGDMA TEMAC support, and SPI driver
> (master only).
>
> My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
> The comments / opinions on how to get this driver (not the current incomplete
> version of course) accepted into the ko tree are very welcomed.
>   
I have an almost working FIFO TEMAC driver. It is similarly based.
it started out based on the Trek webserver sample
I spent probably 3-4 days de-EDKing it into something that fit into a
single source and was closer to ko norms.
It is based on approximately the EDK 8.1 stuff. You are welcome to it,
if it could be helpful in anyway.
I am all for getting an acceptable driver into the ko tree.




> I am not quite satisfied with how the current git repository
> is structured, and may rework it completely later.
>
> Thanks,
> Andrei
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>   


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: Xilinx git tree at source.mvista.com

[Andrei Konovalov]

Hi David,

David H. Lynch Jr. wrote:
> Andrei Konovalov wrote:
>> Hello,
>>
>> My Xilinx Virtex Development tree is now alive again.
>>
>> Please use the dev branch (master is just the ko copy):
>> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
>> Currently it has a patch to enable the framebuffer
>> on ML403 and ML300 plus TEMAC driver that uses
>> the PHY lib (FIFO mode support only).
>> The TEMAC driver is work in progress.
>> In the queue are SGDMA TEMAC support, and SPI driver
>> (master only).
>>
>> My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
>> The comments / opinions on how to get this driver (not the current incomplete
>> version of course) accepted into the ko tree are very welcomed.
>>   
> I have an almost working FIFO TEMAC driver. It is similarly based.
> it started out based on the Trek webserver sample

Is this a reference design by Xilinx? Linux based or standalone?

> I spent probably 3-4 days de-EDKing it into something that fit into a
> single source and was closer to ko norms.
> It is based on approximately the EDK 8.1 stuff. You are welcome to it,
> if it could be helpful in anyway.
> I am all for getting an acceptable driver into the ko tree.

You could post your driver to the list when you think it is in good enough shape.
If your driver is based on the linux TEMAC driver from EDK, it shouldn't
be very different from my version (my added value is mostly replacing the
custom PHY code with the PHY lib stuff). Then we could merge our drivers (or
whatever would make sense).

I would be interested to have a look at your current code just to see
how much has it cost to "de-EDK" the FIFO part. You could email me
your (even not quite working) driver privately if you want.


Thanks,
Andrei

Re: Xilinx git tree at source.mvista.com

[Wolfgang Reissnegger]

Hi Andrei, David,

It's great to hear that Andrei's git tree is active again.

As you might have heard, Xilinx is in the process of setting up a git
tree as well. Right now we are waiting for the new hosting machines to
be installed. We should get those machines up and running shortly
(within a couple weeks).

Currently the tree is based on mainline and adds support for MicroBlaze.
I also intent to merge Grant Likely's virtex-dev branch, the framebuffer
patch and the various other contributions that are out there.

We are also in the process of changing our internal coding guidelines to
match the common Linux style (e.g. u32, u16 types, 8 char wide (tab)
indentation, curly brace location etc) to make it easier to integrate
code into the kernel and push it upstream.

I'll send an update once we have the server up and running.

Thanks,
   Wolfgang

Andrei Konovalov wrote:
> Hi David,
> 
> David H. Lynch Jr. wrote:
>> Andrei Konovalov wrote:
>>> Hello,
>>>
>>> My Xilinx Virtex Development tree is now alive again.
>>>
>>> Please use the dev branch (master is just the ko copy):
>>> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
>>> Currently it has a patch to enable the framebuffer
>>> on ML403 and ML300 plus TEMAC driver that uses
>>> the PHY lib (FIFO mode support only).
>>> The TEMAC driver is work in progress.
>>> In the queue are SGDMA TEMAC support, and SPI driver
>>> (master only).
>>>
>>> My concern is that the TEMAC driver uses the "level 1 drivers" from EDK 9.1.
>>> The comments / opinions on how to get this driver (not the current incomplete
>>> version of course) accepted into the ko tree are very welcomed.
>>>   
>> I have an almost working FIFO TEMAC driver. It is similarly based.
>> it started out based on the Trek webserver sample
> 
> Is this a reference design by Xilinx? Linux based or standalone?
> 
>> I spent probably 3-4 days de-EDKing it into something that fit into a
>> single source and was closer to ko norms.
>> It is based on approximately the EDK 8.1 stuff. You are welcome to it,
>> if it could be helpful in anyway.
>> I am all for getting an acceptable driver into the ko tree.
> 
> You could post your driver to the list when you think it is in good enough shape.
> If your driver is based on the linux TEMAC driver from EDK, it shouldn't
> be very different from my version (my added value is mostly replacing the
> custom PHY code with the PHY lib stuff). Then we could merge our drivers (or
> whatever would make sense).
> 
> I would be interested to have a look at your current code just to see
> how much has it cost to "de-EDK" the FIFO part. You could email me
> your (even not quite working) driver privately if you want.
> 
> 
> Thanks,
> Andrei
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

Re: Xilinx git tree at source.mvista.com

[David H. Lynch Jr.]

Andrei Konovalov wrote:
> Hi David,
>
> David H. Lynch Jr. wrote:
>>>   
>> I have an almost working FIFO TEMAC driver. It is similarly based.
>> it started out based on the Trek webserver sample
>
> Is this a reference design by Xilinx? Linux based or standalone?
    I did a Local Link hard TEMAC driver - that I eventually got
working. However, I could not find anyway to
    enable interrupts in the Local Link TEMAC so the driver was strictly
polled and between that and other
    issues, perfomances was abysmal almost 50% of all inbound packets
were dropped, we switched to the
    PLB FIFO TEMAC I stripped out all the SG and DMA stuff (as it is not
in our hardware) and converted it to
    a fairly normal Linux ethernet driver. It sends, it receives, but I
beleive it is not properly confirming to Linux
    that packets were successfully sent.

    In the interim I have been using the posted driver that uses the EDK.
    Until more recently that has lacked features like
    autonegotiation.

    I beleive its current flaw is primarily massive violations of kernel
code style guidelines.


>
>> I spent probably 3-4 days de-EDKing it into something that fit into a
>> single source and was closer to ko norms.
>> It is based on approximately the EDK 8.1 stuff. You are welcome to it,
>> if it could be helpful in anyway.
>> I am all for getting an acceptable driver into the ko tree.
>
> You could post your driver to the list when you think it is in good
> enough shape.
> If your driver is based on the linux TEMAC driver from EDK, it shouldn't
> be very different from my version (my added value is mostly replacing the
> custom PHY code with the PHY lib stuff). Then we could merge our
> drivers (or
> whatever would make sense).
>
> I would be interested to have a look at your current code just to see
> how much has it cost to "de-EDK" the FIFO part. You could email me
> your (even not quite working) driver privately if you want.

    I will email you a copy separately. I do not care what you choose to
do with it.
    At the moment I have no time to take it further - something about
asses, alligators
    and clearing swamps.

    Mostly I would just like to see a Linux friendly driver make its way
into the kernel.

    I have almost exactly the same code working as a GHS integrity driver.
    In fact I sort of ported a mini shim layer to GHS to implement Linux
SKB's under GHS.
    I did trip over something with GHS. If I was able to 64bit align the
data part of the skb
    the send/receive code code be vastly simplified.
    I have not but I have not done that yet.






>
>
> Thanks,
> Andrei
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: Xilinx git tree at source.mvista.com

[David H. Lynch Jr.]

Wolfgang Reissnegger wrote:
> Hi Andrei, David,
>
> It's great to hear that Andrei's git tree is active again.
>
> As you might have heard, Xilinx is in the process of setting up a git
> tree as well. Right now we are waiting for the new hosting machines to
> be installed. We should get those machines up and running shortly
> (within a couple weeks).
>   
Absolutely fantastic - however I think kernel.org would be happy to host
your git tree for you
as well as a few other places. Those are locations people would look for
public git trees.
I beleive you can still excecise some control. I beleive they are free -
though I suspect kernel.org would not
mind contributions from xilinx.
>  
> Currently the tree is based on mainline and adds support for MicroBlaze.
> I also intent to merge Grant Likely's virtex-dev branch, the framebuffer
> patch and the various other contributions that are out there. 
>   
You might want to look at the Microbalze-uClinux mailing list as well as
petalogix.
They are not using git yet, but they are puching the microblaze towards
kernel org
inclusion.


> We are also in the process of changing our internal coding guidelines to
> match the common Linux style (e.g. u32, u16 types, 8 char wide (tab)
> indentation, curly brace location etc) to make it easier to integrate
> code into the kernel and push it upstream.
>   

For me the most significant issue is the bazillion layers of nested
macro's and includes.

The kernel style guides atleast to me are primarily about the
readability and understandability of the code.
not where the curly brackets are.

> I'll send an update once we have the server up and running.
>
> Thanks,
>    Wolfgang
-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: Xilinx git tree at source.mvista.com

[Wolfgang Reissnegger]

David H. Lynch Jr. wrote:
> Wolfgang Reissnegger wrote:
>> Hi Andrei, David,
>>
>> It's great to hear that Andrei's git tree is active again.
>>
>> As you might have heard, Xilinx is in the process of setting up a git
>> tree as well. Right now we are waiting for the new hosting machines to
>> be installed. We should get those machines up and running shortly
>> (within a couple weeks).
>>   
> Absolutely fantastic - however I think kernel.org would be happy to host
> your git tree for you
> as well as a few other places. Those are locations people would look for
> public git trees.
> I beleive you can still excecise some control. I beleive they are free -
> though I suspect kernel.org would not
> mind contributions from xilinx.

I agree, and I already requested kernel.org site hosting a while back,
but I did not get a response yet.

[snip]

> For me the most significant issue is the bazillion layers of nested
> macro's and includes.

I don't see the macros as an issue, just look at the implementation of,
for example, spin_lock_irq() and Xilinx's macros seem like child's play :-)
As for includes, yes, there are a few too many header files. But, as
time progresses and the need arises they can be merged into fewer files.

> The kernel style guides atleast to me are primarily about the
> readability and understandability of the code.
> not where the curly brackets are.
> 
>> I'll send an update once we have the server up and running.
>>
>> Thanks,
>>    Wolfgang

Re: Xilinx git tree at source.mvista.com

[John Williams]

Hi Wolfgang,

Wolfgang Reissnegger wrote:
> David H. Lynch Jr. wrote:
> 
>>For me the most significant issue is the bazillion layers of nested
>>macro's and includes.
> 
> 
> I don't see the macros as an issue, just look at the implementation of,
> for example, spin_lock_irq() and Xilinx's macros seem like child's play :-)
> As for includes, yes, there are a few too many header files. But, as
> time progresses and the need arises they can be merged into fewer files.

It seems the kernel.org decision has been made re: the style issue. 
None of the *_i.[ch], *_g.[ch] + adapter.c drivers will make it to 
mainline.

I understand why Xilinx did it this way, but to be honest never agreed 
with it myself either.  Style issues aside, three levels of function 
calls in an interrupt handler might be portable, but it still isn't a 
good thing!

The effort to refactor these drivers is not huge, but it is an effort. 
If Xilinx is committed to good quality Linux support for their silicon, 
it will require tangible investment in the form of labour or resources. 
I know you understand this, but Xilinx as an company still needs a good 
hard shove in this direction.

Alternatively, drivers will trickle into kernel.org as the community 
gets around to it, witness the uartlite and system ace drivers.

Same old story, if you want it "some day", then it will be free, if you 
want it now, you've got to pay!

Cheers,

John

Re: Xilinx git tree at source.mvista.com

[Andrei Konovalov]

John Williams wrote:
> Hi Wolfgang,
> 
> Wolfgang Reissnegger wrote:
>> David H. Lynch Jr. wrote:
>>
>>> For me the most significant issue is the bazillion layers of nested
>>> macro's and includes.
>>
>>
>> I don't see the macros as an issue, just look at the implementation of,
>> for example, spin_lock_irq() and Xilinx's macros seem like child's 
>> play :-)
>> As for includes, yes, there are a few too many header files. But, as
>> time progresses and the need arises they can be merged into fewer files.
> 
> It seems the kernel.org decision has been made re: the style issue. None 
> of the *_i.[ch], *_g.[ch] + adapter.c drivers will make it to mainline.

BTW, all the current drivers I am aware of have been moved to platform bus,
and do not use *_g.[ch] already.

> I understand why Xilinx did it this way, but to be honest never agreed 
> with it myself either.  Style issues aside, three levels of function 
> calls in an interrupt handler might be portable, but it still isn't a 
> good thing!

Another thing we've encountered while moving our current spi driver to the spi
framework is that sometimes there is too much "policy" in the level 1 drivers.
The level 1 spi driver controls the chip select on its own. For this reason
we were not able to use the spi_bitbang stuff. And even then we have to copy
the buffers into a single one to avoid CS toggling in the middle of the EEPROM
write sequence. The latter could probably be worked around, and could be due
to us not making the most of the level 1 driver, but at least this is not
trivial.

Yet another thing is that if one wants just FIFO mode for the TEMAC, he has
to include a bit of SGDMA code too as e.g. XTemac_Start() references
XDmaV3_SgStart() et al. IMHO wider usage of "virtual functions" would
help here (see e.g. how the System ACE driver by Grant L. handles different
bus widths).

Personally and in general, I like the idea of reusable OS independent code.
But it is hard to implement the way everyone would be happy with ;)

Thanks,
Andrei

Re: Xilinx git tree at source.mvista.com

[Esben Nielsen]

On Thu, 24 May 2007, Andrei Konovalov wrote:

> Hello,
>
> My Xilinx Virtex Development tree is now alive again.
>
> Please use the dev branch (master is just the ko copy):
> http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev

I can not access the git-tree there: No such project :-(

Is that git-tree still alive? Or should I use another?
Any news on Xilinx's own git-tree?

Regards,
Esben

Re: Xilinx git tree at source.mvista.com

[Dale Farnsworth]

In article <Pine.LNX.4.64.0706121228350.9045@frodo.shire> you write:
> On Thu, 24 May 2007, Andrei Konovalov wrote:
> 
> > Hello,
> >
> > My Xilinx Virtex Development tree is now alive again.
> >
> > Please use the dev branch (master is just the ko copy):
> > http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev
> 
> I can not access the git-tree there: No such project :-(

Oops.  I misconfigured gitweb while updating it.  I've fixed it, so
please try again.

-Dale