Bug 94473

Created attachment 122191 [details]
UMX Xorg log

Attached latest UMS git driver Xorg log

Created attachment 122193 [details]
KMS Xorg log

Attached latest KMS driver Xorg log

Comment on attachment 122191 [details]
UMX Xorg log

UMX->UMS

Comment on attachment 122190 [details]
VX900 drm driver bootup log

This is the dmesg log for KMS driver

(In reply to HuangRan from comment #0)

Hi Frank,

> Created attachment 122190 [details]
> VX900 drm driver bootup log
> 
> I have a board ID-PDM9W which is based on VIA's C7 + VX900 platform. The
> board has a "HDMI+VGA" ports and with a serial port on the board.
> Then I install Ubuntu 12.04 OS and see UMS driver xf86-video-openchrome is
> working fine on VGA port. Then I am trying to get latest git openchrome
> driver and build it and see the latest UMS code can work on VGA port. That
> is good.
> And I preferred to make KMS driver work on OpenChrome, so I tried latest
> code on https://cgit.freedesktop.org/openchrome/drm-openchrome/ and build
> the kernel. After the kernel is built and reboot, I get the log with dmesg
> information as below:
> [    9.042371] [drm:via_driver_load [via]] *ERROR* Failed acquiring AGP
> device.
> [    9.049488] [drm:via_driver_load [via]] *ERROR* Failed to allocate AGP
> 
> Thanks,
> Frank

Congratulations for getting Linux kernel compiled for KMS.
I have not gotten that far so far, so you are way ahead of me. (^_^)
Anyway, it appears that via_driver_load function is inside via_drv.c is causing problems.

https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/via/via_drv.c

_____________________________________________________________
static int
via_driver_load(struct drm_device *dev, unsigned long chipset)
{
. . .
#if __OS_HAS_AGP
	if ((dev_priv->engine_type > VIA_ENG_H2) ||
	    (dev->agp && drm_pci_device_is_agp(dev))) {
		ret = via_detect_agp(dev);
		if (!ret)
			via_agp_engine_init(dev_priv);
		else
			DRM_ERROR("Failed to allocate AGP\n");
	}
. . .
_____________________________________________________________

via_detect_agp function is where the error occurs.

_____________________________________________________________
static int
via_detect_agp(struct drm_device *dev)
{
	struct drm_via_private *dev_priv = dev->dev_private;
	struct drm_agp_info agp_info;
	struct drm_agp_mode mode;
	int ret = 0;

	ret = drm_agp_acquire(dev);
	if (ret) {
		DRM_ERROR("Failed acquiring AGP device.\n");
		return ret;
	}

	ret = drm_agp_info(dev, &agp_info);
. . .
_____________________________________________________________


I must say that James Simmons wrote far clearer code than the original OpenChrome developers.
I guess the question now is what does this drm_agp_acquire DRM API call do?
Why is it failing at that point?

Hi Frank,

More resources regarding this drm_agp_acquire DRM API.

http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_agpsupport.c?v=3.2#L99

Who acquired the AGP device?
It appears that DRM is not able to claim the AGP device.

Hi Frank,

I forgot to ask.
Does OpenChrome with KMS work at all?
What I mean is, do you see anything on the monitor screen?
At least, it appears that the code is not getting into kernel panic.
I am glad your system at least has VGA as a backup.
My Zotac ZBOX nano VD01 does not have VGA or DVI, so at this point, I need the KMS code to work since that is the only configuration where HDMI works with OpenChrome.
I do not own an HDMI capable monitor at this point, so I will likely use an HDMI to VGA adapter for now.

(In reply to Kevin Brace from comment #7)
> Hi Frank,
> 
> I forgot to ask.
> Does OpenChrome with KMS work at all?
> What I mean is, do you see anything on the monitor screen?
> At least, it appears that the code is not getting into kernel panic.
> I am glad your system at least has VGA as a backup.
> My Zotac ZBOX nano VD01 does not have VGA or DVI, so at this point, I need
> the KMS code to work since that is the only configuration where HDMI works
> with OpenChrome.
> I do not own an HDMI capable monitor at this point, so I will likely use an
> HDMI to VGA adapter for now.

Hi Kevin,

  Yup, as far as I observed, current KMS driver code in kernel does not bring any crash on my Ubuntu 12.04 OS with VGA port except the error I met. So at least James Simmons' code is pretty good although it has not been verified for quite a long time. We are so lucky to work based on previous James' previous great work.
  So let me verify if HDMI is working for my board. If that can work, you may not need an HDMI->VGA converter.

Thanks,
Frank

(In reply to Kevin Brace from comment #6)
> Hi Frank,
> 
> More resources regarding this drm_agp_acquire DRM API.
> 
> http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_agpsupport.c?v=3.
> 2#L99
> 
> Who acquired the AGP device?
> It appears that DRM is not able to claim the AGP device.

I will create a kernel debug env to see what happens and which kernel module call it(I guess it should be drm calling it)...

Thanks,
Frank

The screen shows fine with no error and I can see the desktop shows up.
Then I can log in and everything seems working all right. 
Furthermore, I see the console window's mode setting is done by KMS driver(where the text shows in higher resolution and it is more clear). That proves CRTC code in DRM via module is working.

Thanks,
Frank

With my initial analysis, via_driver_load() is called by DRM .load function and via_driver_load() will do GPU initialization work including VRAM/TTM, mmmio, HW engine,vblank and so on.
So the function via_detect_agp() is called. And an DRM function drm_agp_acquire() then is called by via.ko which return negative value causing this error happen.
And drm_agp_acquire() is defined in DRM file drm_agpsupport.c which we need debug to see why negative value(-ENODEV/-EBUSY) is returned.
By contrast, The UMS driver VIADRIAgpInit() will trigger a AGP function call drmAgpAcquire() which will call libDRM function with DRM_IOCTL_AGP_ACQUIRE, then into DRM kernel function drm_agp_acquire_ioctl(), and finally call the same function drm_agp_acquire() which does not cause any error!
So I believe this is something missing to do in current KMS driver I need follow debubgging to get the root cause.

Thanks,
Frank

(In reply to Kevin Brace from comment #5)
> I must say that James Simmons wrote far clearer code than the original
> OpenChrome developers.

Just a note: most of the code comes originally from VIA, from their engineers.  It was open-sourced probably somewhere in 2003.  Early in 2004 the Unichrome project picked it up and fixed many bugs, mainly done by Luc Verhaegen and Thomas Hellström.  That commit history was not preserved when things moved to openchrome in 2005.  Since then some code was written by Ivor Hewitt, Jon Nettleton, Bartosz Kosiorek, and James Simmons.  But to blame any of these openchrome developers for the state of the code would be... unfair.

(Just a note, just to put things a bit in perspective.)

(In reply to Benno Schulenberg from comment #12)
> (In reply to Kevin Brace from comment #5)
> > I must say that James Simmons wrote far clearer code than the original
> > OpenChrome developers.
> 
> Just a note: most of the code comes originally from VIA, from their
> engineers.  It was open-sourced probably somewhere in 2003.  Early in 2004
> the Unichrome project picked it up and fixed many bugs, mainly done by Luc
> Verhaegen and Thomas Hellström.  That commit history was not preserved when
> things moved to openchrome in 2005.  Since then some code was written by
> Ivor Hewitt, Jon Nettleton, Bartosz Kosiorek, and James Simmons.  But to
> blame any of these openchrome developers for the state of the code would
> be... unfair.
> 
> (Just a note, just to put things a bit in perspective.)

Benno, I am be happy to know the history of OpenChrome. So can I understand that most of current code is coming from VIA's engineers? And current OGPM is not enough to write current driver?
By the way, I thought Kevin just want to explain James's latest code is pretty good...

Thanks,
Frank

(In reply to HuangRan from comment #13)
> Benno, I am be happy to know the history of OpenChrome. So can I understand
> that most of current code is coming from VIA's engineers?

Yes, from VIA and from S3, as you can also see from the licenses in each file.

> And current OGPM is not enough to write current driver?

What's "OGPM"?

> By the way, I thought Kevin just want to explain James's latest code is
> pretty good...

I know.  But the remark seemed to imply that the rest of the code was written by other openchrome developers.

(In reply to Benno Schulenberg from comment #14)
> (In reply to HuangRan from comment #13)
> > Benno, I am be happy to know the history of OpenChrome. So can I understand
> > that most of current code is coming from VIA's engineers?
> 
> Yes, from VIA and from S3, as you can also see from the licenses in each
> file.

okay, got it. With my analysis, I do think some code is from private document which should be from via/s3.
> 
> > And current OGPM is not enough to write current driver?
> 
> What's "OGPM"?

OGPM=open graphics programming guide. It's provided in www.x.org/docs.
> 
> > By the way, I thought Kevin just want to explain James's latest code is
> > pretty good...
> 
> I know.  But the remark seemed to imply that the rest of the code was
> written by other openchrome developers.

(In reply to Benno Schulenberg from comment #12)

Hi Benno,

> 
> Just a note: most of the code comes originally from VIA, from their
> engineers.  It was open-sourced probably somewhere in 2003.  Early in 2004
> the Unichrome project picked it up and fixed many bugs, mainly done by Luc
> Verhaegen and Thomas Hellström.  That commit history was not preserved when
> things moved to openchrome in 2005.  Since then some code was written by
> Ivor Hewitt, Jon Nettleton, Bartosz Kosiorek, and James Simmons.  But to
> blame any of these openchrome developers for the state of the code would
> be... unfair.
> 
> (Just a note, just to put things a bit in perspective.)

The comment I made about James Simmons' code was meant to be my take on the DRM / KMS code he wrote, and I did not necessarily mean to criticize the previous OpenChrome developers.
That being said, I have been dealing with OpenChrome code since July 2015 or so, and I have not particularly liked the code quality of OpenChrome.
The code maintainability does affect the sustainability of the project, to some extent.
Many of the commits I have done so far mainly deals with cleaning the code and making it easier to understand.
That's all I will say for now.

Hi Frank,

This seems to be the official DRM / TTM / KMS developer documentation.

http://free-electrons.com/kerneldoc//latest/DocBook/gpu/

I hope it is useful to you.

(In reply to Kevin Brace from comment #17)
> Hi Frank,
> 
> This seems to be the official DRM / TTM / KMS developer documentation.
> 
> http://free-electrons.com/kerneldoc//latest/DocBook/gpu/
> 
> I hope it is useful to you.

Hi Kevin,

  It is really good article to tell what KMS is and how it works including memory management(TTM/GEM) and mode setting(CRTC/Encoder/Connector). Definitely it is helpful. When I was in AMD, actually for those parts(including KMS), I have learned them based on RADEON and I hope I can put everything I have learnt in OpenChrome project.
  Right now I have successfully setup the kernel debugging env and I'll see what is happening for this error.

Thanks,
Frank

Hi Kevin,

   I have verified HDMI port of my VX900 board with KMS driver just now. Unfortunately, it can't bootup into desktop with HDMI port(Even text mode can not be entered into if I disable graphics mode). I collected the log and will submit another Bugzilla issue for it.

Thanks,
Frank


> Hi Kevin,
> 
>   Yup, as far as I observed, current KMS driver code in kernel does not
> bring any crash on my Ubuntu 12.04 OS with VGA port except the error I met.
> So at least James Simmons' code is pretty good although it has not been
> verified for quite a long time. We are so lucky to work based on previous
> James' previous great work.
>   So let me verify if HDMI is working for my board. If that can work, you
> may not need an HDMI->VGA converter.
> 
> Thanks,
> Frank

(In reply to HuangRan from comment #19)

Hi Frank,

> Hi Kevin,
> 
>    I have verified HDMI port of my VX900 board with KMS driver just now.
> Unfortunately, it can't bootup into desktop with HDMI port(Even text mode
> can not be entered into if I disable graphics mode). I collected the log and
> will submit another Bugzilla issue for it.
> 
> Thanks,
> Frank
> 
> 

I saw the new bug report you filed regarding the HDMI.
I am thinking that this bug you originally filed for (AGP related issue) probably existed when James wrote the code, and possibly he never bothered to fix it or did not noticed it.
How do you think?

Hi Kevin,


> 
> I saw the new bug report you filed regarding the HDMI.
> I am thinking that this bug you originally filed for (AGP related issue)
> probably existed when James wrote the code, and possibly he never bothered
> to fix it or did not noticed it.
> How do you think?

   I am not sure on this, with my debugging yesterday on the kernel, I found dev->agp is NULL which leads drm_agp_acquire() return NULL.
-------------------------------------
      	if (!dev->agp)
		return -ENODEV;
-------------------------------------
  But for UMS driver, it does not return such error, so I still need investigate how UMS driver deals with that.

Thanks,
Frank

With further kernel debugging, we found that in via_driver_load() function, it has the code as below:
#if __OS_HAS_AGP
	if ((dev_priv->engine_type > VIA_ENG_H2) ||
	    (dev->agp && drm_pci_device_is_agp(dev))) {
		ret = via_detect_agp(dev);
		if (!ret)
			via_agp_engine_init(dev_priv);
		else
			DRM_ERROR("Failed to allocate AGP\n");
	}
#endif

Actually dev->agp is NULL for VX900. But because dev_priv->engine_type value is greater than VIA_ENG_H2, via_detect_agp() is called.
I am not sure what does engine_type mean? Can anybody give some comments? And why is it related to AGP detect?

Thanks,
Frank

(In reply to HuangRan from comment #22)

Hi Frank,


> With further kernel debugging, we found that in via_driver_load() function,
> it has the code as below:
> #if __OS_HAS_AGP
> 	if ((dev_priv->engine_type > VIA_ENG_H2) ||
> 	    (dev->agp && drm_pci_device_is_agp(dev))) {
> 		ret = via_detect_agp(dev);
> 		if (!ret)
> 			via_agp_engine_init(dev_priv);
> 		else
> 			DRM_ERROR("Failed to allocate AGP\n");
> 	}
> #endif
> 
> Actually dev->agp is NULL for VX900. But because dev_priv->engine_type value
> is greater than VIA_ENG_H2, via_detect_agp() is called.
> I am not sure what does engine_type mean? Can anybody give some comments?
> And why is it related to AGP detect?
> 
> Thanks,
> Frank

H2 or H6 appears to be the DMA engine revision.

https://www.freedesktop.org/wiki/Openchrome/DMAEngineNotes/

(In reply to Kevin Brace from comment #23)
> 
> Hi Frank,
> 
> 
> 
> H2 or H6 appears to be the DMA engine revision.
> 
> https://www.freedesktop.org/wiki/Openchrome/DMAEngineNotes/

Actually, this is the better list.

https://www.freedesktop.org/wiki/Openchrome/HardwareCheatSheet/

(In reply to HuangRan from comment #22)

Hi Frank,

> With further kernel debugging, we found that in via_driver_load() function,
> it has the code as below:
> #if __OS_HAS_AGP
> 	if ((dev_priv->engine_type > VIA_ENG_H2) ||
> 	    (dev->agp && drm_pci_device_is_agp(dev))) {
> 		ret = via_detect_agp(dev);
> 		if (!ret)
> 			via_agp_engine_init(dev_priv);
> 		else
> 			DRM_ERROR("Failed to allocate AGP\n");
> 	}
> #endif
> 
> Actually dev->agp is NULL for VX900. But because dev_priv->engine_type value
> is greater than VIA_ENG_H2, via_detect_agp() is called.
> I am not sure what does engine_type mean? Can anybody give some comments?
> And why is it related to AGP detect?
> 
> Thanks,
> Frank

I think (dev_priv->engine_type > VIA_ENG_H2) means K8M890 or later (i.e., The integrated graphics is Chrome 9 or later 3D engine.).
It appears that K8M890 was the first chipset to implement Chrome 9 graphics.
Chrome 9 graphics' 3D engine is rumored to be borrowed from S3 Graphics DeltaChrome.
DeltaChrome is a 130 nm process AGP graphics chip that came out in 2003 / 2004.
A few vendors sold graphics card based on it.
It is very rare to find, but I do own one copy of it (It was made by VIA Technologies itself.).

Hi Frank,

I am just wondering.
Shouldn't DRIVER_MODESET be ORed for driver_features member of drm_driver structure inside via_drv.c?
DRIVER_MODESET identifies the availability of KMS.

_________________________________________________________________________
static struct drm_driver via_driver = {
	.driver_features = DRIVER_USE_AGP | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED    
                           | DRIVER_GEM,
	.load = via_driver_load,
	.unload = via_driver_unload,
	.preclose = via_reclaim_buffers_locked,
	.context_dtor = via_final_context,
	.get_vblank_counter = drm_vblank_count,
	.enable_vblank = via_enable_vblank,
	.disable_vblank = via_disable_vblank,
	.irq_preinstall = via_driver_irq_preinstall,
	.irq_postinstall = via_driver_irq_postinstall,
	.irq_uninstall = via_driver_irq_uninstall,
	.irq_handler = via_driver_irq_handler,
	.dma_quiescent = via_driver_dma_quiescent,
	.lastclose = via_driver_lastclose,
	.set_busid = drm_pci_set_busid,
	.gem_open_object = ttm_gem_open_object,
	.gem_free_object = ttm_gem_free_object,
	.dumb_create = via_dumb_create,
	.dumb_map_offset = via_dumb_mmap,
	.dumb_destroy = gem_dumb_destroy,
	.ioctls = via_ioctls,
	.fops = &via_driver_fops,
	.name = DRIVER_NAME,
	.desc = DRIVER_DESC,
	.date = DRIVER_DATE,
	.major = DRIVER_MAJOR,
	.minor = DRIVER_MINOR,
	.patchlevel = DRIVER_PATCHLEVEL,
};
_________________________________________________________________________


I got this idea from this section of the DRM development guide.

http://free-electrons.com/kerneldoc//latest/DocBook/gpu/drmInternals.html#id-1.3.4.5.4

Hi Frank,

(In reply to HuangRan from comment #22)
> With further kernel debugging, we found that in via_driver_load() function,
> it has the code as below:
> #if __OS_HAS_AGP
> 	if ((dev_priv->engine_type > VIA_ENG_H2) ||
> 	    (dev->agp && drm_pci_device_is_agp(dev))) {
> 		ret = via_detect_agp(dev);
> 		if (!ret)
> 			via_agp_engine_init(dev_priv);
> 		else
> 			DRM_ERROR("Failed to allocate AGP\n");
> 	}
> #endif
> 
> Actually dev->agp is NULL for VX900. But because dev_priv->engine_type value
> is greater than VIA_ENG_H2, via_detect_agp() is called.
> I am not sure what does engine_type mean? Can anybody give some comments?
> And why is it related to AGP detect?
> 
> Thanks,
> Frank

Regarding this if statement in question,

 	if ((dev_priv->engine_type > VIA_ENG_H2) ||
 	    (dev->agp && drm_pci_device_is_agp(dev))) {

Every VIA IGP is considered an AGP device, if I am correct.
This might not be true for Chrome 9, however.
In fact, many IGPs "look" like an AGP device, at least from the OS.
In other words, even the ones without an external AGP slot, at least from the OS, looks like an AGP device.
Since almost every VIA IGPs are AGP devices, perhaps we can rewrite the code like this.

 	if (dev->agp && drm_pci_device_is_agp(dev)) {

Regarding the "> VIA_ENG_H2" part, it appears to mean Chrome 9.
However, these are still considered AGP devices, if I am correct.
Personally, I do not see a compelling reason why this line has to be part of the if statement.

(dev_priv->engine_type > VIA_ENG_H2)

Why not you remove the above line, and see what happens?

(In reply to HuangRan from comment #21)

Hi Frank,

> Hi Kevin,
> 
> 
> > 
> > I saw the new bug report you filed regarding the HDMI.
> > I am thinking that this bug you originally filed for (AGP related issue)
> > probably existed when James wrote the code, and possibly he never bothered
> > to fix it or did not noticed it.
> > How do you think?
> 
>    I am not sure on this, with my debugging yesterday on the kernel, I found
> dev->agp is NULL which leads drm_agp_acquire() return NULL.
> -------------------------------------
>       	if (!dev->agp)
> 		return -ENODEV;
> -------------------------------------
>   But for UMS driver, it does not return such error, so I still need
> investigate how UMS driver deals with that.
> 
> Thanks,
> Frank

I am wondering if a DRM API needs to be called that tests the device to see if it is an AGP device.
At least from PCI configuration space registers, there is a way to tell this.

Hi Frank,

Assuming the IGP is Chrome 9 or is an AGP device, then a function called 
via_agp_engine_init is called.
If you compare the registers being initialized here to OpenChrome DDX's VIAInitialize3DEngine function inside via_ums.c, there are some similarities.

_________________________________________________________________________
static void via_agp_engine_init(struct drm_via_private *dev_priv)
{
	VIA_WRITE(VIA_REG_TRANSET, 0x00100000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x00000000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x00333004);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x60000000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x61000000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x62000000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x63000000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x64000000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x7D000000);

	VIA_WRITE(VIA_REG_TRANSET, 0xfe020000);
	VIA_WRITE(VIA_REG_TRANSPACE, 0x00000000);
}
_________________________________________________________________________


_________________________________________________________________________

static void
VIAInitialize3DEngine(ScrnInfoPtr pScrn)
{
    VIAPtr pVia = VIAPTR(pScrn);
    int i;

    VIASETREG(VIA_REG_TRANSET, 0x00010000);
    for (i = 0; i <= 0x7D; i++)
        VIASETREG(VIA_REG_TRANSPACE, (CARD32) i << 24);

    VIASETREG(VIA_REG_TRANSET, 0x00020000);
    for (i = 0; i <= 0x94; i++)
        VIASETREG(VIA_REG_TRANSPACE, (CARD32) i << 24);
    VIASETREG(VIA_REG_TRANSPACE, 0x82400000);

    VIASETREG(VIA_REG_TRANSET, 0x01020000);
    for (i = 0; i <= 0x94; i++)
        VIASETREG(VIA_REG_TRANSPACE, (CARD32) i << 24);
    VIASETREG(VIA_REG_TRANSPACE, 0x82400000);

    VIASETREG(VIA_REG_TRANSET, 0xfe020000);
    for (i = 0; i <= 0x03; i++)
        VIASETREG(VIA_REG_TRANSPACE, (CARD32) i << 24);

    VIASETREG(VIA_REG_TRANSET, 0x00030000);
    for (i = 0; i <= 0xff; i++)
        VIASETREG(VIA_REG_TRANSPACE, 0);

    VIASETREG(VIA_REG_TRANSET, 0x00100000);
    VIASETREG(VIA_REG_TRANSPACE, 0x00333004);
    VIASETREG(VIA_REG_TRANSPACE, 0x10000002);
    VIASETREG(VIA_REG_TRANSPACE, 0x60000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x61000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x62000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x63000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x64000000);

    VIASETREG(VIA_REG_TRANSET, 0x00fe0000);
    if (pVia->Chipset == VIA_CLE266 && pVia->ChipRev >= 3)
        VIASETREG(VIA_REG_TRANSPACE, 0x40008c0f);
    else
        VIASETREG(VIA_REG_TRANSPACE, 0x4000800f);
    VIASETREG(VIA_REG_TRANSPACE, 0x44000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x45080C04);
    VIASETREG(VIA_REG_TRANSPACE, 0x46800408);
    VIASETREG(VIA_REG_TRANSPACE, 0x50000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x51000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x52000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x53000000);

    VIASETREG(VIA_REG_TRANSET, 0x00fe0000);
    VIASETREG(VIA_REG_TRANSPACE, 0x08000001);
    VIASETREG(VIA_REG_TRANSPACE, 0x0A000183);
    VIASETREG(VIA_REG_TRANSPACE, 0x0B00019F);
    VIASETREG(VIA_REG_TRANSPACE, 0x0C00018B);
    VIASETREG(VIA_REG_TRANSPACE, 0x0D00019B);
    VIASETREG(VIA_REG_TRANSPACE, 0x0E000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x0F000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x10000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x11000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x20000000);
}
_________________________________________________________________________

Hi Frank,

Never mind.
There is a function inside via_ums.c called viaInitAgp.

_________________________________________________________________________
static void
viaInitAgp(VIAPtr pVia)
{
    VIASETREG(VIA_REG_TRANSET, 0x00100000);
    VIASETREG(VIA_REG_TRANSPACE, 0x00000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x00333004);
    VIASETREG(VIA_REG_TRANSPACE, 0x60000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x61000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x62000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x63000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x64000000);
    VIASETREG(VIA_REG_TRANSPACE, 0x7D000000);

    VIASETREG(VIA_REG_TRANSET, 0xfe020000);
    VIASETREG(VIA_REG_TRANSPACE, 0x00000000);
}
_________________________________________________________________________



Also from via_ums.c, it appears that Chrome 9 IGPs are considered PCIe (PCI Express) devices.

_________________________________________________________________________
static void
VIAInitialize2DEngine(ScrnInfoPtr pScrn)
{
    VIAPtr pVia = VIAPTR(pScrn);
    ViaTwodContext *tdc = &pVia->td;
    int i;

. . .

    switch (pVia->Chipset) {
        case VIA_K8M890:
        case VIA_P4M900:
        case VIA_VX800:
        case VIA_VX855:
        case VIA_VX900:
            viaInitPCIe(pVia);
            break;
        default:
            viaInitAgp(pVia);
            break;
    }

. . .

    if (pVia->VQStart != 0) {
        switch (pVia->Chipset) {
            case VIA_K8M890:
            case VIA_P4M900:
            case VIA_VX800:
            case VIA_VX855:
            case VIA_VX900:
                viaEnablePCIeVQ(pVia);
                break;
            default:
                viaEnableAgpVQ(pVia);
                break;
        }
    } else {
        viaDisableVQ(pScrn);
    }

    viaAccelSetMode(pScrn->bitsPerPixel, tdc);
}
_________________________________________________________________________


Why not rewrite the if statement in question.

 	if ((dev_priv->engine_type > VIA_ENG_H2) ||
 	    (dev->agp && drm_pci_device_is_agp(dev))) {

To something like this.

 	if ((dev_priv->engine_type <= VIA_ENG_H2) ||
 	    (dev->agp && drm_pci_device_is_agp(dev))) {

This way, anything older than Chrome 9 go through AGP detection.
This basically means, anything that is UniChrome, UniChrome Pro, and UniChrome Pro II.
Chrome 9 has H5 or H6 DMA engine.

Hi Frank,

I think VX900's IGP is really a PCIe device.
This is why DRM APIs that handles AGP detection fail.
I think what may have happened is that James Simmons did not really test the DRM module with older VIA Technologies IGPs that identifies as an AGP device (i.e., UniChrome family).
    If what I proposed is the fix, you may want to obtain freedesktop.org commit privilege, and do a commit to fix this bug.
I do already have the commit privilege, so I can possibly do it with your name included so that you get the credit for doing a lot of the analysis.
I did obtain the commit privilege recently, and if you are not familiar with the process, I think I can help you out.
Of course, you may already know the process of obtaining commit privilege.
When I did it, I was barely able to figure it out on my own, but I think I can go back and figure out how I did it.

(In reply to Kevin Brace from comment #24)
> (In reply to Kevin Brace from comment #23)
> > 
> > Hi Frank,
> > 
> > 
> > 
> > H2 or H6 appears to be the DMA engine revision.
> > 
> > https://www.freedesktop.org/wiki/Openchrome/DMAEngineNotes/
> 
> Actually, this is the better list.
> 
> https://www.freedesktop.org/wiki/Openchrome/HardwareCheatSheet/

Hi Kevin,

  Okay, got it. I see https://www.freedesktop.org/wiki/Openchrome link and did not found "DMAEngineNotes" and "HardwareCheatSheet" entries. How did you find it?

Thanks,
Frank

(In reply to Kevin Brace from comment #26)
> Hi Frank,
> 
> I am just wondering.
> Shouldn't DRIVER_MODESET be ORed for driver_features member of drm_driver
> structure inside via_drv.c?
> DRIVER_MODESET identifies the availability of KMS.
> 
> _________________________________________________________________________
> static struct drm_driver via_driver = {
> 	.driver_features = DRIVER_USE_AGP | DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED    
>                            | DRIVER_GEM,
> 	.load = via_driver_load,
> 	.unload = via_driver_unload,
> 	.preclose = via_reclaim_buffers_locked,
> 	.context_dtor = via_final_context,
> 	.get_vblank_counter = drm_vblank_count,
> 	.enable_vblank = via_enable_vblank,
> 	.disable_vblank = via_disable_vblank,
> 	.irq_preinstall = via_driver_irq_preinstall,
> 	.irq_postinstall = via_driver_irq_postinstall,
> 	.irq_uninstall = via_driver_irq_uninstall,
> 	.irq_handler = via_driver_irq_handler,
> 	.dma_quiescent = via_driver_dma_quiescent,
> 	.lastclose = via_driver_lastclose,
> 	.set_busid = drm_pci_set_busid,
> 	.gem_open_object = ttm_gem_open_object,
> 	.gem_free_object = ttm_gem_free_object,
> 	.dumb_create = via_dumb_create,
> 	.dumb_map_offset = via_dumb_mmap,
> 	.dumb_destroy = gem_dumb_destroy,
> 	.ioctls = via_ioctls,
> 	.fops = &via_driver_fops,
> 	.name = DRIVER_NAME,
> 	.desc = DRIVER_DESC,
> 	.date = DRIVER_DATE,
> 	.major = DRIVER_MAJOR,
> 	.minor = DRIVER_MINOR,
> 	.patchlevel = DRIVER_PATCHLEVEL,
> };
> _________________________________________________________________________
> 
> 
> I got this idea from this section of the DRM development guide.
> 
> http://free-electrons.com/kerneldoc//latest/DocBook/gpu/drmInternals.html#id-
> 1.3.4.5.4

Hi Kevin, 

  Yup, you are right. So you can see in via_drv.c file, function via_init() will OR this value to make kernel driver to be KMS mode. For general linux kernel, there is no such flag which will make KMS disabled in kernel. And DDX will check this value by drmCheckModesettingSupported() call. you can see /sys/bus/pci/devices/0000:00:01.0, there is an drm/ControlD64 directory which is registered by drm module. If DRIVER_MODESET is ORed by via.ko, DDX will recognize KMS enabled by drmCheckModesettingSupported() call with "ControlD" flag.

Thanks,
Frank

(In reply to HuangRan from comment #32)

Hi Frank,

> 
> Hi Kevin,
> 
>   Okay, got it. I see https://www.freedesktop.org/wiki/Openchrome link and
> did not found "DMAEngineNotes" and "HardwareCheatSheet" entries. How did you
> find it?
> 
> Thanks,
> Frank

I found that information from a search engine.
You are right that the information is hidden or unreachable from the regular OpenChrome freedesktop.org page.

Hi Frank,

I was able to install the Linux kernel that comes with KMS supporting DRM module.
Looking at the dmesg and Xorg.0.log, KMS is working.
Regarding the AGP recognition issue, I tested the fix I proposed using a mainboard with P4M890 chipset (supports external PCIe devices, but the IGP is UniChrome Pro), and it appears that DRM is properly allocating memory for an AGP device.
I also tested the same hard drive using a mainboard with VX800 chipset, and as long as the proposed fix is implemented, it does not appear to cause problems with Chome 9 as well.
In both cases, I only tested VGA, but DRM did the mode setting correctly.
Do you want to commit a fix for this possible bug?

Hi Kevin,

  I looked at your comments from #27 to #30. Your analysis and comparison to current DDX code(xf86-video-openchrome) is correct and I totally agree with that.
  from K8M890, it should be PCIe instead of AGP.
  Let me give a try with your suggestion.

Thanks,
Frank

(In reply to Kevin Brace from comment #30)
> Hi Frank,
> 
> Never mind.
> There is a function inside via_ums.c called viaInitAgp.
> 
> _________________________________________________________________________
> static void
> viaInitAgp(VIAPtr pVia)
> {
>     VIASETREG(VIA_REG_TRANSET, 0x00100000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x00000000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x00333004);
>     VIASETREG(VIA_REG_TRANSPACE, 0x60000000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x61000000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x62000000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x63000000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x64000000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x7D000000);
> 
>     VIASETREG(VIA_REG_TRANSET, 0xfe020000);
>     VIASETREG(VIA_REG_TRANSPACE, 0x00000000);
> }
> _________________________________________________________________________
> 
> 
> 
> Also from via_ums.c, it appears that Chrome 9 IGPs are considered PCIe (PCI
> Express) devices.
> 
> _________________________________________________________________________
> static void
> VIAInitialize2DEngine(ScrnInfoPtr pScrn)
> {
>     VIAPtr pVia = VIAPTR(pScrn);
>     ViaTwodContext *tdc = &pVia->td;
>     int i;
> 
> . . .
> 
>     switch (pVia->Chipset) {
>         case VIA_K8M890:
>         case VIA_P4M900:
>         case VIA_VX800:
>         case VIA_VX855:
>         case VIA_VX900:
>             viaInitPCIe(pVia);
>             break;
>         default:
>             viaInitAgp(pVia);
>             break;
>     }
> 
> . . .
> 
>     if (pVia->VQStart != 0) {
>         switch (pVia->Chipset) {
>             case VIA_K8M890:
>             case VIA_P4M900:
>             case VIA_VX800:
>             case VIA_VX855:
>             case VIA_VX900:
>                 viaEnablePCIeVQ(pVia);
>                 break;
>             default:
>                 viaEnableAgpVQ(pVia);
>                 break;
>         }
>     } else {
>         viaDisableVQ(pScrn);
>     }
> 
>     viaAccelSetMode(pScrn->bitsPerPixel, tdc);
> }
> _________________________________________________________________________
> 
> 
> Why not rewrite the if statement in question.
> 
>  	if ((dev_priv->engine_type > VIA_ENG_H2) ||
>  	    (dev->agp && drm_pci_device_is_agp(dev))) {
> 
> To something like this.
> 
>  	if ((dev_priv->engine_type <= VIA_ENG_H2) ||
>  	    (dev->agp && drm_pci_device_is_agp(dev))) {
> 
> This way, anything older than Chrome 9 go through AGP detection.
> This basically means, anything that is UniChrome, UniChrome Pro, and
> UniChrome Pro II.
> Chrome 9 has H5 or H6 DMA engine.

(In reply to Kevin Brace from comment #35)
> Hi Frank,
> 
> I was able to install the Linux kernel that comes with KMS supporting DRM
> module.
> Looking at the dmesg and Xorg.0.log, KMS is working.
> Regarding the AGP recognition issue, I tested the fix I proposed using a
> mainboard with P4M890 chipset (supports external PCIe devices, but the IGP
> is UniChrome Pro), and it appears that DRM is properly allocating memory for
> an AGP device.
> I also tested the same hard drive using a mainboard with VX800 chipset, and
> as long as the proposed fix is implemented, it does not appear to cause
> problems with Chome 9 as well.
> In both cases, I only tested VGA, but DRM did the mode setting correctly.
> Do you want to commit a fix for this possible bug?

Okay, you are so soon with the test...
Let me give a try and let you know the result.

Thanks,
Frank

Hi Kevin,

   I just gave a try on my VX900 board. The KMS is working fine and Xorg.0.log looks good with your proposal below:
-----------------------------------------------------------
        if ((dev_priv->engine_type <= VIA_ENG_H2) ||
            (dev->agp && drm_pci_device_is_agp(dev))) {
-----------------------------------------------------------
   Now that you have verified old H1/H2 chip and VX800 which is based on H5, I do think we can commit this change to kernel.
   For the first commit, I see your suggestion on comment #31, I think for the first patch, I agree with that you do the commit with my name included. And I prefer to know how to get the commit privilege for next step for future commits in drm/ddx, so can you help me on that? Yup, I have seen some discussion between you and other committer on how to do it, but if you can send me a README for a more regular way to do a commit, it should be great.

Thanks,
Frank

(In reply to Kevin Brace from comment #35)
> Hi Frank,
> 
> I was able to install the Linux kernel that comes with KMS supporting DRM
> module.
> Looking at the dmesg and Xorg.0.log, KMS is working.
> Regarding the AGP recognition issue, I tested the fix I proposed using a
> mainboard with P4M890 chipset (supports external PCIe devices, but the IGP
> is UniChrome Pro), and it appears that DRM is properly allocating memory for
> an AGP device.
> I also tested the same hard drive using a mainboard with VX800 chipset, and
> as long as the proposed fix is implemented, it does not appear to cause
> problems with Chome 9 as well.
> In both cases, I only tested VGA, but DRM did the mode setting correctly.
> Do you want to commit a fix for this possible bug?

(In reply to HuangRan from comment #38)

Hi Frank,

> Hi Kevin,
> 
>    I just gave a try on my VX900 board. The KMS is working fine and
> Xorg.0.log looks good with your proposal below:
> -----------------------------------------------------------
>         if ((dev_priv->engine_type <= VIA_ENG_H2) ||
>             (dev->agp && drm_pci_device_is_agp(dev))) {
> -----------------------------------------------------------
>    Now that you have verified old H1/H2 chip and VX800 which is based on H5,
> I do think we can commit this change to kernel.
>    For the first commit, I see your suggestion on comment #31, I think for
> the first patch, I agree with that you do the commit with my name included.
> And I prefer to know how to get the commit privilege for next step for
> future commits in drm/ddx, so can you help me on that? Yup, I have seen some
> discussion between you and other committer on how to do it, but if you can
> send me a README for a more regular way to do a commit, it should be great.
> 
> Thanks,
> Frank
> 

Frank, do you know how to create a patch using Git?
If you don't, I can give you detailed instructions on how to do it.
You can write a short description on how the patch will fix a bug we found in the code.
After that, you can post the patch on dri-devel mailing list.

https://lists.freedesktop.org/mailman/listinfo/dri-devel

There is a correct way to do this from Git, and again, I can give you instructions on how to do it, if you do not know how to do this.
After that, I can do a commit of the code, assuming that my freedesktop.org commit privilege works in the first place for drm-openchrome repository.
I say this because when I tried to do a commit for a different DDX project (xf86-video-r128) recently, I was not able to do a commit for that project.
I presumably have to obtain an additional commit privilege to do a commit on that project.

Hi Kevin,

> Frank, do you know how to create a patch using Git?
Do I use "git format-patch" to generate the patch?
Or just just "git diff" to generate a patch instead?
Right now I create a branch and do a local commit with current modification.

> If you don't, I can give you detailed instructions on how to do it.
> You can write a short description on how the patch will fix a bug we found
> in the code.
> After that, you can post the patch on dri-devel mailing list.
> 
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Use "git sent-email" to attach the patch to this mail list?

> 
> There is a correct way to do this from Git, and again, I can give you
> instructions on how to do it, if you do not know how to do this.
> After that, I can do a commit of the code, assuming that my freedesktop.org
> commit privilege works in the first place for drm-openchrome repository.
> I say this because when I tried to do a commit for a different DDX project
> (xf86-video-r128) recently, I was not able to do a commit for that project.
> I presumably have to obtain an additional commit privilege to do a commit on
> that project.
How do you have the previlege of commit for xf86-video-openchrome? Somebody else need approve on this?
I think different git repositories need various approvals. It is more reasonable.

Thanks,
Frank

Hi Kevin,

(In reply to HuangRan from comment #40)
> Hi Kevin,
> 
> > Frank, do you know how to create a patch using Git?
> Do I use "git format-patch" to generate the patch?
> Or just just "git diff" to generate a patch instead?
> Right now I create a branch and do a local commit with current modification.
> 
> > If you don't, I can give you detailed instructions on how to do it.
> > You can write a short description on how the patch will fix a bug we found
> > in the code.
> > After that, you can post the patch on dri-devel mailing list.
> > 
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Use "git sent-email" to attach the patch to this mail list?

I have attached a patch which is generated by git format-patch command. But I have not found "git sent-email" command under my bash.

Thanks,
Frank

Created attachment 122474 [details]
Patch to fix drm AGP detection error

(In reply to HuangRan from comment #41)
> I have not found "git sent-email" command under my bash.

It's called 'git send-email'.  Type: git sen<Tab>, and it should show up.  Or... maybe you need install an extra package?  I seem to remember it was so on my system.

(In reply to Benno Schulenberg from comment #43)
> (In reply to HuangRan from comment #41)
> > I have not found "git sent-email" command under my bash.
> 
> It's called 'git send-email'.  Type: git sen<Tab>, and it should show up. 
> Or... maybe you need install an extra package?  I seem to remember it was so
> on my system.

Hi Benno,

  Okay, my typo. After I typed "git send-email -to dri-devel@lists.freedesktop.org 0001-Fix-the-drm...", it goes to next step.
  And when I confirm to send this mail with "yes", it reports:
    "Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=localhost encryption= hello=localhost.localdomain at /usr/lib/git-core/git-send-email line 1110."
  Actually I have changed my smtp setting with /~/.gitconfig file as below:
        smtpEncryption = tls
        smtpserver = smtp.cstnet.cn
        smtpUser = huangran@iscas.ac.cn
        smtpServerPort = 587
  Any suggestion?

Thanks,
Frank

(In reply to HuangRan from comment #44)
>   Actually I have changed my smtp setting with /~/.gitconfig file as below:
>         smtpEncryption = tls
>         smtpserver = smtp.cstnet.cn
>         smtpUser = huangran@iscas.ac.cn
>         smtpServerPort = 587
>   Any suggestion?

I couldn't get that to work either.  So I only have:

    smtpserver = /usr/local/bin/msmtp

And then in ~/.msmtprc I have:

    account Telfort
    host <actual SMTP server of ISP>
    from <my email address>

(In reply to Benno Schulenberg from comment #45)
> (In reply to HuangRan from comment #44)
> >   Actually I have changed my smtp setting with /~/.gitconfig file as below:
> >         smtpEncryption = tls
> >         smtpserver = smtp.cstnet.cn
> >         smtpUser = huangran@iscas.ac.cn
> >         smtpServerPort = 587
> >   Any suggestion?
> 
> I couldn't get that to work either.  So I only have:
> 
>     smtpserver = /usr/local/bin/msmtp
> 
> And then in ~/.msmtprc I have:
> 
>     account Telfort
>     host <actual SMTP server of ISP>
>     from <my email address>

Hi Benno,

  I have successfully commit my patch to dri-devel mail list now.
-------------------------------------------------------------------
limit the AGP detect condition to VIA chips using DMA engine name before Chrome9 to avoid drm error message "[drm:via_driver_load [via]] *ERROR* Failed acquiring AGP device.". Verify this on old H1/H2 chip and VX800/VX900 chips.
---
 drivers/gpu/drm/via/via_drv.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/via/via_drv.c b/drivers/gpu/drm/via/via_drv.c index aee3a0c..f4562d8 100644
--- a/drivers/gpu/drm/via/via_drv.c
+++ b/drivers/gpu/drm/via/via_drv.c
@@ -349,7 +349,7 @@ via_driver_load(struct drm_device *dev, unsigned long chipset)
 	chip_revision_info(dev);
 
 #if __OS_HAS_AGP
-	if ((dev_priv->engine_type > VIA_ENG_H2) ||
+	if ((dev_priv->engine_type <= VIA_ENG_H2) ||
 	    (dev->agp && drm_pci_device_is_agp(dev))) {
 		ret = via_detect_agp(dev);
 		if (!ret)
--
1.7.9.5
--------------------------------------------------------------------
   The reason why I failed to do so is I use "sendmail" instead of "sendemail". Right now with my correct setting as below:
          sendemail.smtpserverport=25
          sendemail.smtpserver=smtp.cstnet.cn
          sendemail.smtpencryption=tls
          sendemail.smtpuser=huangran@iscas.ac.cn
   Everything works fine.

Thanks,
Frank

Hi Kevin,


   Right now I have submitted my patch to dri-devel mail list for review. Can you see it? And what's the next step?


Thanks,
Frank

(In reply to HuangRan from comment #47)

Hi Frank,

> Hi Kevin,
> 
> 
>    Right now I have submitted my patch to dri-devel mail list for review.
> Can you see it? And what's the next step?
> 
> 
> Thanks,
> Frank

Sorry for disappearing for a few days.
I have been spending time setting up drm-openchrome repository on my local development system.
This is to do a commit for the patch you have created and posted on dri-devel mailing list.
    Also, I have been setting up the 2.5" SATA hard drive I will be using for ZOTAC ZBOX nano VD01.
The reason why this is time consuming is due to the fact that ZBOX nano VD01 does not have VGA coming out of it (HDMI / DP only), so I need to use another computer to install, and transfer the hard drive to ZBOX nano.
In the process, I ran into installation issues with Xubuntu 14.04.4 (Warning: Running "sudo apt-get build-dep xserver-xorg-video-openchrome" will erase X server DDXs on Xubuntu 14.04.4!!! I just had to reinstall Xubuntu 14.04.4.), so for now, I will use Lubuntu 12.04 i386 and AMD64 for DRM / KMS validation on the ZBOX nano.
I still need to install the latest OpenChrome on this system and also install the developmental DRM module, in order to test HDMI on my ZBOX nano.
The hard drive has 7 partitions, although for now, I will likely activate only one partition with the new DRM module.
    I will review the patch, and do a commit test on my local development system.
Of course, I will post the actual patch I will be committing here and dri-devel mailing list before I actually do the commit (and, of course, assuming that commit goes through in the first place), so that you can sign off on the patch.
It is my understanding that, Frank, you can apply for your own commit privilege after you get a patch committed.

Created attachment 122512 [details] [review]
Fix VIA Technologies DRM AGP detection error message

Limit AGP detection to VIA Technologies UniChrome IGP to avoid DRM
error message, "[drm:via_driver_load [via]] *ERROR* Failed acquiring
AGP device." Chrome9 IGP will display this error message since it is
a PCI Express device. Verified this fix on P4M890, VX800, and VX900
chipsets.

Signed-off-by: Haung, Ran <huangran@iscas.ac.cn>
Signed-off-by: Kevin Brace <kevinbrace@gmx.com>

Hi Frank,

I reviewed the patch and rewrote the patch comment section somewhat.
I will not do this every time you create a patch.
That being said, I think there is a general guideline somewhere that freedesktop.org wants the characters per line to be capped below 80, and I think about 72 is probably better cosmetically.
It is merely a formatting guideline, so each sentence does not have to be below 72 or 80 characters, obviously.
Another thing is that the H1 / H2 in the original comment is VIA Technologies terms for their DMA engine generation, and other than people who deal with their hardware directly (i.e., VIA Technologies device driver group, you, and I), the other DRM developers will have no idea what H1 or H2 is.
That's why I changed the naming to the actual product name like UniChrome (their IGP) or P4M890 chipset, since those names are more known.
    Regarding your sign off section, I added a comma (",") between Huang and Ran since in eastern Asian culture, surname (last name) is pronounced or written before the given name (first name).
The comma is there to signify that Huang is your surname to those who may not be aware.

Created attachment 122513 [details] [review]
Fix VIA Technologies DRM AGP detection error message

Limit AGP detection to VIA Technologies UniChrome IGP to avoid DRM
error message, "[drm:via_driver_load [via]] *ERROR* Failed acquiring
AGP device." Chrome9 IGP will display this error message since it is
a PCI Express device. Verified this fix on P4M890, VX800, and VX900
chipsets.

Signed-off-by: Huang, Ran <huangran@iscas.ac.cn>
Signed-off-by: Kevin Brace <kevinbrace@gmx.com>

Hi Frank,

I just caught a typo on your last name, so I obsoleted the previous proposed patch I uploaded.
Sorry for that.
I have not e-mailed this patch to dri-devel or commited it to the repository yet.
If you want your signoff section done differently, let me know.

Hi Frank,

I am now working on substituting Linux 3.2 kernel's in the box DRM module with James Simmons' DRM module (drm-openchrome).
I am forced to do this because if I simply try to compile DRM module over at drm-openchrome page, it actually installs Linux 3.19-rc6.
Unfortunately, if I do this, PS/2 or USB mouse no longer works (only PS/2 keyboard works) in Lubuntu 12.04 (i.e., Lubuntu 12.04 with Linux 3.19-rc6 kernel).
Anyway, I am compiling the Linux 3.2 kernel with James Simmons' DRM module right now.
I will let you know how it plays out.
Once I verify that KMS is working, I will install the hard drive into ZOTAC ZBOX nano VD01, so that I can check HDMI and DP.

Hi Kevin,


(In reply to Kevin Brace from comment #48)
> Sorry for disappearing for a few days.
> I have been spending time setting up drm-openchrome repository on my local
> development system.
> This is to do a commit for the patch you have created and posted on
> dri-devel mailing list.
>     Also, I have been setting up the 2.5" SATA hard drive I will be using
> for ZOTAC ZBOX nano VD01.
> The reason why this is time consuming is due to the fact that ZBOX nano VD01
> does not have VGA coming out of it (HDMI / DP only), so I need to use
> another computer to install, and transfer the hard drive to ZBOX nano.
:). Yup, that is also what I have done for my VX900 board although it has VGA port. As I replied you in a separate mail, right now I can't install Ubuntu 12.04 directly on my VX900 board, so I install it on another board(i.e. AMD's) and transfer this hard disk to my VX900 board to use.

> In the process, I ran into installation issues with Xubuntu 14.04.4
> (Warning: Running "sudo apt-get build-dep xserver-xorg-video-openchrome"
> will erase X server DDXs on Xubuntu 14.04.4!!! I just had to reinstall
> Xubuntu 14.04.4.), so for now, I will use Lubuntu 12.04 i386 and AMD64 for
> DRM / KMS validation on the ZBOX nano.
At my side, I have not tried Ubuntu 14.04 or Lubuntu/Xubuntu because even Ubuntu 12.04 installation is failed at my side.So I am now using Ubuntu 12.04 with transferred hard disk. And I met similar degeneration issue when I execute "sudo apt-get build-dep xserver-xorg-video-openchrome", the Xserver is degenerated to 1.11 from previous 1.15. But the good thing is that current UMS driver is working fine with this degenerated Xserver 1.11.
And I also found a very interesting thing which is that the closed VX900 driver can work fine with this old Xserver 1.11 version. But for Xserver 1.15 and latest 1.18, the closed driver is not working.I believe VIA company does not maintain this closed driver for quite a long time.

> I still need to install the latest OpenChrome on this system and also
> install the developmental DRM module, in order to test HDMI on my ZBOX nano.
> The hard drive has 7 partitions, although for now, I will likely activate
> only one partition with the new DRM module.
>     I will review the patch, and do a commit test on my local development
> system.
> Of course, I will post the actual patch I will be committing here and
> dri-devel mailing list before I actually do the commit (and, of course,
> assuming that commit goes through in the first place), so that you can sign
> off on the patch.
> It is my understanding that, Frank, you can apply for your own commit
> privilege after you get a patch committed.
Okay, no hurry for my privilege to commit the patch. Let's focus on this first patch's commit by your privilege.

Thanks,
Frank

Hi Kevin,

(In reply to Kevin Brace from comment #50)
> Hi Frank,
> 
> I reviewed the patch and rewrote the patch comment section somewhat.
> I will not do this every time you create a patch.
Never mind. Actually you helped me a lot on how to generate a formatted patch to Linux community. I remember last time I committed to RADEON drm driver, it is 3-4 years ago...So for some rules, I have forgotten them. Your new patch looks better than mine.

> That being said, I think there is a general guideline somewhere that
> freedesktop.org wants the characters per line to be capped below 80, and I
> think about 72 is probably better cosmetically.
> It is merely a formatting guideline, so each sentence does not have to be
> below 72 or 80 characters, obviously.
I found a link for coding style as below link:
http://www.x.org/wiki/CodingStyle/
But it seems that it does not tell how a patch should look like.

> Another thing is that the H1 / H2 in the original comment is VIA
> Technologies terms for their DMA engine generation, and other than people
> who deal with their hardware directly (i.e., VIA Technologies device driver
> group, you, and I), the other DRM developers will have no idea what H1 or H2
> is.
> That's why I changed the naming to the actual product name like UniChrome
> (their IGP) or P4M890 chipset, since those names are more known.
I do agree with your point here. Let's use P4M890, VX800, and VX900 chipsets instead of H1/H2.

>     Regarding your sign off section, I added a comma (",") between Huang and
> Ran since in eastern Asian culture, surname (last name) is pronounced or
> written before the given name (first name).
> The comma is there to signify that Huang is your surname to those who may
> not be aware.
Yup. Huang is my family name and Ran is my first name. It is okay to use a comma between it.
Actually, in general case, when I replied in my mail, I prefer to use "Frank" for my first name because I usually use it when I am in AMD where I use "Frank" to communicate with western guys.
But for patch, I prefer to use "Huang, Ran".

Thanks,
Frank

Hi Kevin,

(In reply to Kevin Brace from comment #53)
> Hi Frank,
> 
> I am now working on substituting Linux 3.2 kernel's in the box DRM module
> with James Simmons' DRM module (drm-openchrome).
> I am forced to do this because if I simply try to compile DRM module over at
> drm-openchrome page, it actually installs Linux 3.19-rc6.
> Unfortunately, if I do this, PS/2 or USB mouse no longer works (only PS/2
> keyboard works) in Lubuntu 12.04 (i.e., Lubuntu 12.04 with Linux 3.19-rc6
> kernel).
Okay. Do you mean that for kernel 3.19, your PS/2 or USB mouse is not working? Instead, on kernel 3.2 it is working?
There is one thing to consider if you do the back porting from 3.19 to 3.2 for via drm driver. That is DRM header files/c files/functions changed a lot from 3.2 to 3.19 which will make your compilation on 3.2 kernel failed. So you will do some code changes in via drm code to adapt this DRM changes.

> Anyway, I am compiling the Linux 3.2 kernel with James Simmons' DRM module
> right now.
> I will let you know how it plays out.
> Once I verify that KMS is working, I will install the hard drive into ZOTAC
> ZBOX nano VD01, so that I can check HDMI and DP.
Yup, your ZBOX board has a DP port which my VX900 boards/thin clients do not have. That is a very important feature we need activate for VX900. Let me know if DP can work at your side. At my side, I have HDMI,DVI,VGA ports for VX900 platform.

Thanks,
Frank

Hi Frank,

I tried compiling James Simmons' developmental DRM module that supports KMS with Linux 3.2 kernel.
It was a pretty miserable several hours I spent trying this . . .
It appears that James used the latest TTM API, so it cannot practically be compiled with Linux kernel anything older than 3.18 without some rewriting.
Considering that VIA Technologies hardware we are dealing here is not state of the art unlike stuff from NVIDIA, AMD, or Intel (in no particular order), I will be philosophically against using the latest API.
If the older API is adequate, I will be inclined to sticking to it, unless there are technical reasons to using the newer API for newer generation hardware or older the API was obsoleted.
Anyway, just to make it somewhat easier to compile it against older Linux kernels, the newer DRM module should supply its own PCI device IDs, rather than using the ones from DRM header file or Linux PCI device ID header file.
    Due to this compilation issue, I probably will have to use a shorter support period Lubuntu for the newer DRM development like Lubuntu 15.10 for experimenting with my ZOTAC ZBOX nano VD01.

Hi Kevin,

  Actually I didn't recommend you do the back porting work for VIA KMS driver because of this reason...
  I remember one team is doing that when I am in AMD and this team spend several months to finish the back porting and verify it is working fine...
  So for conclusion, I still suggest you use latest Linux distribution OS with new kernel version.

Thanks,
Frank

(In reply to Kevin Brace from comment #57)
> 
> 
> Hi Frank,
> 
> I tried compiling James Simmons' developmental DRM module that supports KMS
> with Linux 3.2 kernel.
> It was a pretty miserable several hours I spent trying this . . .
> It appears that James used the latest TTM API, so it cannot practically be
> compiled with Linux kernel anything older than 3.18 without some rewriting.
> Considering that VIA Technologies hardware we are dealing here is not state
> of the art unlike stuff from NVIDIA, AMD, or Intel (in no particular order),
> I will be philosophically against using the latest API.
> If the older API is adequate, I will be inclined to sticking to it, unless
> there are technical reasons to using the newer API for newer generation
> hardware or older the API was obsoleted.
> Anyway, just to make it somewhat easier to compile it against older Linux
> kernels, the newer DRM module should supply its own PCI device IDs, rather
> than using the ones from DRM header file or Linux PCI device ID header file.
>     Due to this compilation issue, I probably will have to use a shorter
> support period Lubuntu for the newer DRM development like Lubuntu 15.10 for
> experimenting with my ZOTAC ZBOX nano VD01.

(In reply to HuangRan from comment #13)

Hi Frank,

> (In reply to Benno Schulenberg from comment #12)
> > 
> > Just a note: most of the code comes originally from VIA, from their
> > engineers.  It was open-sourced probably somewhere in 2003.  Early in 2004
> > the Unichrome project picked it up and fixed many bugs, mainly done by Luc
> > Verhaegen and Thomas Hellström.  That commit history was not preserved when
> > things moved to openchrome in 2005.  Since then some code was written by
> > Ivor Hewitt, Jon Nettleton, Bartosz Kosiorek, and James Simmons.  But to
> > blame any of these openchrome developers for the state of the code would
> > be... unfair.
> > 
> > (Just a note, just to put things a bit in perspective.)
> 
> Benno, I am be happy to know the history of OpenChrome. So can I understand
> that most of current code is coming from VIA's engineers? And current OGPM
> is not enough to write current driver?
> By the way, I thought Kevin just want to explain James's latest code is
> pretty good...
> 
> Thanks,
> Frank

I was taking a break from my OpenChrome hard work today, but during my slacking off period, I found this public UniChrome / OpenChrome feud thread from 2005.

http://markmail.org/message/vutzfc65va4h554r#query:+page:1+mid:x4bp6vxkd7kmf3sh+state:results

That thread explains the schism the two project had more than 10 years ago, and it served no one's interest, in my opinion.
Apparently, Luc Verhaegen (who is still active in the FOSS graphics scene) and Thomas Hellström (who now works for VMware) had issues.
Read the posts from Luc and Thomas.
It is very interesting.
With the hindsight of 20/20, I think Luc was right that VBE mode setting should have never been in the code, or should have been removed by 2010.
This is why I removed VBE mode setting support a few days ago (10 years later).
I removed it because VBE and "known device table" were causing display detection coding nightmare.
I fix one problem (DVI to VGA adapter problem), and then flat panel of my netbook (non-I2C flat panel) goes wrong.
If I fix that non-I2C flat panel, then DVI to VGA adapter no longer works (you and Eric reported this for Wyse thin client recently).
This is why I wanted to remove the legacy code that causes so many issues, but now I have to put it back for the one last time.
After that VBE mode setting will be gone.
In some ways, Luc is finally vindicated, but 10 years too late.
So Frank, that's the much less than flattering history of OpenChrome.
This schism from 10 years ago still has an impact (on me and others who have seen their screen disappear) even today.

(In reply to Kevin Brace from comment #59)
> http://markmail.org/message/vutzfc65va4h554r#query:+page:1+mid:
> x4bp6vxkd7kmf3sh+state:results
> 
> That thread explains the schism the two project had more than 10 years ago,
> and it served no one's interest, in my opinion.  [...]
> With the hindsight of 20/20, I think Luc was right that VBE mode setting
> should have never been in the code, or should have been removed by 2010.

Luc is always right.  However... the first (quoted) remark in that post from Alan Cox says it all: "So your code causes reversions and loss of support for end users."

Yes, Luc makes better code, but in the process he (temporarily) breaks things for some use cases, and for many people that is a no-no-no.  Yes, it's very annoying to have to 1) keep everything working and 2) improve things.  It's much nicer to throw away all crap and cruft, and build the needed things afresh.  But... until you're done, some users are left out in the cold.

However, since things seem to have degenerated since 0.2.904, please go ahead, do as you see fit.  (But please use git branching, don't revert commits, the master branch can be left perfectly well intact.)

Hi Kevin,

  I have not gotten time to go through this discussion. But in my opinion, I fully support your point to remove legacy code(VBE, device table...) because those modules are also not used anymore in modern Intel/AMD open source driver. Also, using I2C to detect EDID information is the trend which replaces the fixed table method. 
  Making some code in regression in this process is normal. We just need record which commit id is working and let users(like me) to know that or as Benno said, we can use a branch to do that before committing to master. By this way, the users can still get correct working driver which will make them happy to go with the new driver.

Thanks,
Frank

(In reply to Kevin Brace from comment #59)

> I was taking a break from my OpenChrome hard work today, but during my
> slacking off period, I found this public UniChrome / OpenChrome feud thread
> from 2005.
> 
> http://markmail.org/message/vutzfc65va4h554r#query:+page:1+mid:
> x4bp6vxkd7kmf3sh+state:results
> 
> That thread explains the schism the two project had more than 10 years ago,
> and it served no one's interest, in my opinion.
> Apparently, Luc Verhaegen (who is still active in the FOSS graphics scene)
> and Thomas Hellström (who now works for VMware) had issues.
> Read the posts from Luc and Thomas.
> It is very interesting.
> With the hindsight of 20/20, I think Luc was right that VBE mode setting
> should have never been in the code, or should have been removed by 2010.
> This is why I removed VBE mode setting support a few days ago (10 years
> later).
> I removed it because VBE and "known device table" were causing display
> detection coding nightmare.
> I fix one problem (DVI to VGA adapter problem), and then flat panel of my
> netbook (non-I2C flat panel) goes wrong.
> If I fix that non-I2C flat panel, then DVI to VGA adapter no longer works
> (you and Eric reported this for Wyse thin client recently).
> This is why I wanted to remove the legacy code that causes so many issues,
> but now I have to put it back for the one last time.
> After that VBE mode setting will be gone.
> In some ways, Luc is finally vindicated, but 10 years too late.
> So Frank, that's the much less than flattering history of OpenChrome.
> This schism from 10 years ago still has an impact (on me and others who have
> seen their screen disappear) even today.

(In reply to HuangRan from comment #61)
> Hi Kevin,
> 
>   I have not gotten time to go through this discussion. But in my opinion, I
> fully support your point to remove legacy code(VBE, device table...) because
> those modules are also not used anymore in modern Intel/AMD open source
> driver. Also, using I2C to detect EDID information is the trend which
> replaces the fixed table method. 
>   Making some code in regression in this process is normal. We just need
> record which commit id is working and let users(like me) to know that or as
> Benno said, we can use a branch to do that before committing to master. By
> this way, the users can still get correct working driver which will make
> them happy to go with the new driver.
> 
> Thanks,

I went through the discussion and it seems XvMC and VBE are the modules which make unichrome.sf.net and openchrome.org difference at that time and then bring more dicussion about those two projects. And finally openchrome.org wins and be merged into X.org. So that can explain why XvMC and VBE are still there in current OpenChrome DDX code.


Thanks,
Frank

Hi Frank,

I have been working on getting OpenChrome Version 0.4.0 released in a good condition (under the constraints I am under), so pushing the new VIA Technologies DRM commit into the repository got forgotten for a few days.
I will push it into the repository shortly.
If something happens, I will let you know.

Hi Frank,

Good news.
I pushed the commit into the drm-openchrome repository, and it went through without trouble.

https://cgit.freedesktop.org/openchrome/drm-openchrome/commit/?id=5fe39db5a18918b591fcfb822c3dc3e7e4072fdf

I think you can now go apply for your own freedesktop.org commit privilege.
You can refer to this commit when you apply for it.
I will close this bug report shortly.

Hi Frank,

2 e-mails got generated automatically, and was sent to openchrome-devel mailing list.

https://lists.freedesktop.org/archives/openchrome-devel/2016-March/002167.html
https://lists.freedesktop.org/archives/openchrome-devel/2016-March/002168.html

Frank, great job on analyzing what was going on inside the DRM code, and I hope to further develop the new DRM module for VIA Technologies IGP with you.

Hi Kevin,

(In reply to Kevin Brace from comment #64)
> Hi Frank,
> 
> Good news.
> I pushed the commit into the drm-openchrome repository, and it went through
> without trouble.
> 
> https://cgit.freedesktop.org/openchrome/drm-openchrome/commit/
> ?id=5fe39db5a18918b591fcfb822c3dc3e7e4072fdf
> 
> I think you can now go apply for your own freedesktop.org commit privilege.
> You can refer to this commit when you apply for it.
> I will close this bug report shortly.

  Great! Good to see you have successfully commit the patch to drm-openchrome. I'll apply the commit privilege soon.
  

Thanks,
Frank

(In reply to Kevin Brace from comment #65)
> Hi Frank,
> 
> 2 e-mails got generated automatically, and was sent to openchrome-devel
> mailing list.
> 
> https://lists.freedesktop.org/archives/openchrome-devel/2016-March/002167.
> html
> https://lists.freedesktop.org/archives/openchrome-devel/2016-March/002168.
> html
> 
> Frank, great job on analyzing what was going on inside the DRM code, and I
> hope to further develop the new DRM module for VIA Technologies IGP with you.

Hi Kevin,

   Sure, no problem. Right now, I am going through the close driver KMS code to check why HDMI is not working with OpenChrome KMS code. By the way, I found that in current close driver, it has a large part of code to get BIOS/vBIOS information for graphics driver to use. And for this part of code, I didn't see OpenChrome DRM/DDX code have that. 
   Based on my experience for RADEON, I really think this part of code should be useful for OpenChrome DRM code because graphic driver need talk to BIOS(VBIOS) to get enough information to do mode setting.

Thanks,
Frank