Merge of Luca and Ben's sysfs work for Radeon

Merge of Luca and Ben's sysfs work for Radeon

[Jon Smirl]

Here is a sample of what sysfs looks like with the new radeon driver. I have an
Intel 875 chipset so there are three buses: 0 - system, 1 - AGP, 2 - PCI. Note
that the EDID block is available.

I was thinking about adding these attributes to the fb device: geometry,
timings, interlaced, hsync, vsync. and then writing a new fbset command.

[jonsmirl@smirl sys]$ ls
block  bus  cdev  class  devices  firmware  power
[jonsmirl@smirl sys]$ ls bus/pci/devices
0000:00:00.0  0000:00:1d.1  0000:00:1d.7  0000:00:1f.1  0000:00:1f.5 
0000:02:01.0
0000:00:01.0  0000:00:1d.2  0000:00:1e.0  0000:00:1f.2  0000:01:00.0 
0000:02:02.0
0000:00:1d.0  0000:00:1d.3  0000:00:1f.0  0000:00:1f.3  0000:01:00.1 
0000:02:0c.0
[jonsmirl@smirl sys]$ ls bus/pci/drivers
agpgart-intel  Intel ICH           parport_pc  radeonfb    uhci-hcd
e1000          Intel ICH Joystick  PCI IDE     RZ1000 IDE
ehci_hcd       ohci1394            PIIX IDE    serial
[jonsmirl@smirl sys]$ ls bus/pci/drivers/radeonfb
0000:01:00.0  0000:01:00.1  new_id
[jonsmirl@smirl sys]$ ls class
graphics  i2c-adapter  input  net  scsi_device  scsi_host  tty  usb  usb_host
[jonsmirl@smirl sys]$ ls class/graphics
fb0
[jonsmirl@smirl sys]$ ls class/graphics/fb0
dev  device  driver
[jonsmirl@smirl sys]$  ls class/graphics/fb0/device
class   detach_state  edid1  i2c-1  i2c-3  power     subsystem_device  vendor
config  device        i2c-0  i2c-2  irq    resource  subsystem_vendor
[jonsmirl@smirl sys]$ ls class/graphics/fb0/driver
0000:01:00.0  0000:01:00.1  new_id
[jonsmirl@smirl sys]$




=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Wed, Sep 24, 2003 at 11:05:24PM -0700, Jon Smirl wrote:
> Here is a sample of what sysfs looks like with the new radeon driver. I have an
> Intel 875 chipset so there are three buses: 0 - system, 1 - AGP, 2 - PCI. Note
> that the EDID block is available.

This is so cool!

> I was thinking about adding these attributes to the fb device: geometry,
> timings, interlaced, hsync, vsync. and then writing a new fbset command.

Plz add that too as is useful info, and has the potential to remove a lot
of ioctls in userspace code.

Where can i grab these changes?, are these radeon specific? what about r128?

Thanks in advance.

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Kronos]

Il Thu, Sep 25, 2003 at 01:21:16PM -0600, Otto Solares ha scritto: 
> On Wed, Sep 24, 2003 at 11:05:24PM -0700, Jon Smirl wrote:
> > Here is a sample of what sysfs looks like with the new radeon driver. I have an
> > Intel 875 chipset so there are three buses: 0 - system, 1 - AGP, 2 - PCI. Note
> > that the EDID block is available.
> 
> This is so cool!
> 
> > I was thinking about adding these attributes to the fb device: geometry,
> > timings, interlaced, hsync, vsync. and then writing a new fbset command.
> 
> Plz add that too as is useful info, and has the potential to remove a lot
> of ioctls in userspace code.
> 
> Where can i grab these changes?, are these radeon specific? what about r128?

EDID stuff is radeon specific, sysfs and class_device no. James Simmons
is merging sysfs & class_dev code. I'm working on it here:

bk://mesa3d.bkbits.net/fbdev-2.5

You can find new radeon driver here:

bk://ppc.bkbits.net/linuxppc-2.5-benh

Once core changes are in we can start exporting other attributes.

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Dicono che  il cane sia  il miglior  amico dell'uomo. Secondo me  non e`
vero. Quanti dei vostri amici avete fatto castrare, recentemente?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Thu, Sep 25, 2003 at 10:01:55PM +0200, Kronos wrote:
> Il Thu, Sep 25, 2003 at 01:21:16PM -0600, Otto Solares ha scritto: 
> > On Wed, Sep 24, 2003 at 11:05:24PM -0700, Jon Smirl wrote:
> > > Here is a sample of what sysfs looks like with the new radeon driver. I have an
> > > Intel 875 chipset so there are three buses: 0 - system, 1 - AGP, 2 - PCI. Note
> > > that the EDID block is available.
> > 
> > This is so cool!
> > 
> > > I was thinking about adding these attributes to the fb device: geometry,
> > > timings, interlaced, hsync, vsync. and then writing a new fbset command.
> > 
> > Plz add that too as is useful info, and has the potential to remove a lot
> > of ioctls in userspace code.
> > 
> > Where can i grab these changes?, are these radeon specific? what about r128?
> 
> EDID stuff is radeon specific, sysfs and class_device no. James Simmons
> is merging sysfs & class_dev code. I'm working on it here:
> 
> bk://mesa3d.bkbits.net/fbdev-2.5
> 
> You can find new radeon driver here:
> 
> bk://ppc.bkbits.net/linuxppc-2.5-benh
> 
> Once core changes are in we can start exporting other attributes.

Good! is somewhere a plain diff as i don't know how to use bk?

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Jon Smirl]

--- Otto Solares <solca@guug.org> wrote:
> Good! is somewhere a plain diff as i don't know how to use bk?
> 
> -solca

If you are going to track this you need to use bitkeeper.
Go here and download it: http://www.bitkeeper.com/Products.Downloads.html
Don't worry about registering an email, they haven't sent out any email in two
years.

To get luca's code
bk clone bk://mesa3d.bkbits.net/fbdev-2.5 local_name
To get updates:
cd in to local_name, bk pull

benh's code is at:
bk://ppc.bkbits.net/linuxppc-2.5-benh

I just put a merged driver (luca+benh) up at:
bk://mesa3d.bkbits.net/radeon-2.5

You can browse these repositories via
http://www.bkbits.net/
http://mesa3d.bkbits.net/

If you want to work on an updated Rage128 driver I can make you a repository at
mesa3d.bkbits.net.

To edit a file:
bk edit file_name
To commit locally:
bk citool
To publish changes:
bk push


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Thu, Sep 25, 2003 at 05:10:53PM -0700, Jon Smirl wrote:
> --- Otto Solares <solca@guug.org> wrote:
> > Good! is somewhere a plain diff as i don't know how to use bk?
> > 
> > -solca
> 
> If you are going to track this you need to use bitkeeper.
> Go here and download it: http://www.bitkeeper.com/Products.Downloads.html
> Don't worry about registering an email, they haven't sent out any email in two
> years.
> 
> To get luca's code
> bk clone bk://mesa3d.bkbits.net/fbdev-2.5 local_name
> To get updates:
> cd in to local_name, bk pull
> 
> benh's code is at:
> bk://ppc.bkbits.net/linuxppc-2.5-benh
> 
> I just put a merged driver (luca+benh) up at:
> bk://mesa3d.bkbits.net/radeon-2.5
> 
> You can browse these repositories via
> http://www.bkbits.net/
> http://mesa3d.bkbits.net/
> 
> If you want to work on an updated Rage128 driver I can make you a repository at
> mesa3d.bkbits.net.
> 
> To edit a file:
> bk edit file_name
> To commit locally:
> bk citool
> To publish changes:
> bk push

Ok, i have your merged tree now.  How can i generate a normal
patch so i can patch the latest Linus kernel?

I don't think i'll work on r128 driver as i am not that good
on driver devel, i am interested in fbdev/dri & fbdev/sysfs
for mach64/r128/radeon but from userspace perspective.

Thanks.

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Jon Smirl]

The merged tree is a copy of everything in Linus' tree plus our fbdev work.
Just treat it like a normal kernel tree.

make proper
copy your config
make oldconfig
make

The tree contains all of:
test5
fbdev work
hundreds of patches in the Linus tree past test5

To make sure it is absolutely up to date with Linus, cd into it and:
bk pull bk://linux.bkbits.net/linux-2.5
This will pull the up to the minute changes from Linus' own tree into yours.

To see the diffs from test5 to present:
bk revtool and find last revision number, probably something like 1.1303.
bk export -tpatch -rv2.6.0-test2,1.1303 -h >../patch

There will be a lot of diffs, Linus is about ready to tag test6.

To look at a specific file:
bk revtool file-name

Now that you have a bk tree you don't have to wait for a tagged release. Just
pull the changes fron Linus' tree when you want to update.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Thu, Sep 25, 2003 at 07:57:44PM -0700, Jon Smirl wrote:
> The merged tree is a copy of everything in Linus' tree plus our fbdev work.
> Just treat it like a normal kernel tree.
> 
> make proper
> copy your config
> make oldconfig
> make
> 
> The tree contains all of:
> test5
> fbdev work
> hundreds of patches in the Linus tree past test5
> 
> To make sure it is absolutely up to date with Linus, cd into it and:
> bk pull bk://linux.bkbits.net/linux-2.5
> This will pull the up to the minute changes from Linus' own tree into yours.

done, it finish correctly with:

Consistency check passed, resolve complete.

> To see the diffs from test5 to present:
> bk revtool and find last revision number, probably something like 1.1303.
> bk export -tpatch -rv2.6.0-test2,1.1303 -h >../patch
> 
> There will be a lot of diffs, Linus is about ready to tag test6.
> 
> To look at a specific file:
> bk revtool file-name
> 
> Now that you have a bk tree you don't have to wait for a tagged release. Just
> pull the changes fron Linus' tree when you want to update.

Probably am doing something wrong because there are no
sane files, just s.*.{c,h} binaries in SCCS subdir so i
can't treat it normally:

solca@appsrv:~/devel/radeon$ ls drivers/video/aty/SCCS/
s.aty128fb.c    s.atyfb.h         s.mach64_ct.c      s.mach64_gx.c  s.radeon_base.c  s.radeon_i2c.c      s.radeon_pm.c
s.atyfb_base.c  s.mach64_accel.c  s.mach64_cursor.c  s.Makefile     s.radeonfb.h     s.radeon_monitor.c  s.xlinit.c

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Fri, Sep 26, 2003 at 07:11:44PM +0200, Kronos wrote:
> Il Fri, Sep 26, 2003 at 02:39:46AM -0600, Otto Solares ha scritto: 
> > > To see the diffs from test5 to present:
> > > bk revtool and find last revision number, probably something like 1.1303.
> > > bk export -tpatch -rv2.6.0-test2,1.1303 -h >../patch
> > > 
> > > There will be a lot of diffs, Linus is about ready to tag test6.
> > > 
> > > To look at a specific file:
> > > bk revtool file-name
> > > 
> > > Now that you have a bk tree you don't have to wait for a tagged release. Just
> > > pull the changes fron Linus' tree when you want to update.
> > 
> > Probably am doing something wrong because there are no
> > sane files, just s.*.{c,h} binaries in SCCS subdir so i
> > can't treat it normally:
> > 
> > solca@appsrv:~/devel/radeon$ ls drivers/video/aty/SCCS/
> > s.aty128fb.c    s.atyfb.h         s.mach64_ct.c      s.mach64_gx.c  s.radeon_base.c  s.radeon_i2c.c      s.radeon_pm.c
> > s.atyfb_base.c  s.mach64_accel.c  s.mach64_cursor.c  s.Makefile     s.radeonfb.h     s.radeon_monitor.c  s.xlinit.c
> 
> You must checkout files (make will do it by itself):
> 
> bk get drivers/video/foo.c (readonly)
> bk edit drivers/video/foo.c (rw)
> bk your_favourite_editor drivers/video/foo.c (rw and opens your editor)
> 
> Also:
> 
> bk help commands

ok, i am understanding now, thank you.

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Jon Smirl]

Also, Linus does not have auto get turned on in his tree. 

bk -r get -q
will put a copy of all of the files in to the directory tree.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Thu, Sep 25, 2003 at 08:03:01PM -0700, Jon Smirl wrote:
> Also, Linus does not have auto get turned on in his tree. 
> 
> bk -r get -q
> will put a copy of all of the files in to the directory tree.

this is was i looking for, thank you.

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Jon Smirl]

R128 is more a problem. No one has written the code to get EDID info from the
R128.
There is a 2.4 R128 FB driver here: http://www.saftware.de/ that has I2C
support.

A good project would be to take code from that driver plus look at benh's new
radeon driver and try to make a new 2.6 R128 driver that can read EDID. Once
the driver can get to the EDID block it is easy to export it from sysfs.
Radeons are very similar to R128's so benh's EDID code may just work on a R128.

I have a merge between benh and kronos' Radeon work. I'm working on finding a
place to keep it.


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Merge of Luca and Ben's sysfs work for Radeon

[Otto Solares]

On Thu, Sep 25, 2003 at 01:35:35PM -0700, Jon Smirl wrote:
> R128 is more a problem. No one has written the code to get EDID info from the
> R128.
> There is a 2.4 R128 FB driver here: http://www.saftware.de/ that has I2C
> support.
> 
> A good project would be to take code from that driver plus look at benh's new
> radeon driver and try to make a new 2.6 R128 driver that can read EDID. Once
> the driver can get to the EDID block it is easy to export it from sysfs.
> Radeons are very similar to R128's so benh's EDID code may just work on a R128.
> 
> I have a merge between benh and kronos' Radeon work. I'm working on finding a
> place to keep it.

Ok. Thanks a lot.

-solca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

radeonfb work (WAS: Merge of Luca and Ben's sysfs work for Radeon)

[Benjamin Herrenschmidt]

On Thu, 2003-09-25 at 08:05, Jon Smirl wrote:
> Here is a sample of what sysfs looks like with the new radeon driver. I have an
> Intel 875 chipset so there are three buses: 0 - system, 1 - AGP, 2 - PCI. Note
> that the EDID block is available.
> 
> I was thinking about adding these attributes to the fb device: geometry,
> timings, interlaced, hsync, vsync. and then writing a new fbset command.

Note that there are still missing things in this driver. I'm in the
process of reworking more of it, the goal is to make it much closer
to XFree current driver so we have a chance to better deal with
newer cards & some nasty corner cases, and so it becomes easier in
the future to re-integrate XFree originated changes.

James: I'm in bad need of notifying fbcon of resolution changes. For
example, I want to add a switch for mirror on/off that could easily
be tied to the common "mirror" key on laptops (for machines that don't
do that via BIOS horros of course). However, since a bunch of panels
now have resolutions unsuitable for the external CRT, I will probably
change the panel resolution based on the external monitor (using the
scaler) when this key is pressed. For example, titanium powerbooks
with 1152x768 resolutions would switch to 1024x768 when mirroring
to a CRT...
 
I'm not too sure yet in fact about how to deal with this whole API. The
current set_var doesn't seem to bad if we can add a few flags to it,
like indicating a mirrored mode... The best way may be to add such a flag
to the modes in a mode list indicating "mirrorable" modes (fitting both
displays). The user would see that flag when retreiving the mode list
via /sys or whatever and would pass "mirror" flag to set_var when picking
one of these 'mirrored' modes...

I also want to let the user go up in resolutions when disabling the internal
LCD etc... MacOS lets you diable the LCD if have the laptop lid closed when
waking the machine up from sleep (with an external kbd), though I'm not sure
what is the best way to deal with that with radeonfb.

All that means I'll have actions on ioctl and/or sysfs that will trigger
mode changes and we want fbcon to adapt.

However, we also need a way to notify userland client apps (and maybe a
way for those to "lock" changes, but I don't like that much). That must be
done, I think, in a way similar to console switch: First notify of a
pending event, then wait for the userland app to acknowledge the change.
Not doing so would cause a lot of problems with userland apps tapping the
engine.

Any ideas welcome, I'm still trying to figure out what would be the best
API for those things. We can think about it now, just defining new flags,
ioctls and/or /sys entries won't harm compatibility or stability regarding
current 2.6 "code freeze". Since most of these "features" would then be
implemented on a per-driver basis, it will be up to the various driver
maintainers to deal with avoiding regressions (rather easy with radeonfb
seeing how bad the older versions of this driver worked on most recent hw)

Ben.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf