On Thu, Sep 10, 2009 at 06:19:52PM +0800, brucech...@via.com.tw wrote:
> Hello Sirs:
> The following patch is based on 2.6.31 mainline kernel for the
>system hang issue caused by 3D scaling + ACPI. Please kindly help to
>integrate into mainline kernel.
>
> Thanks and Best Regards
> =
>
> These patches break both free drivers out there. They not only break the
> API, they also require some of these ioctls to be used correctly for
> correct initialisation. There seems to be no attempt at working with
> these two drivers to fix this specific issue.
I'm looking for the API break b
On Fri, Sep 11, 2009 at 11:58:01AM +1000, Dave Airlie wrote:
> >
> > These patches break both free drivers out there. They not only break the
> > API, they also require some of these ioctls to be used correctly for
> > correct initialisation. There seems to be no attempt at working with
> > these t
>
> As a first answer, without going in depth, as i just returned from my
> thursday constitutional.
>
> Do you have an explanation as to why this commit never made it to the
> kernel?
Because it probably wasn't noticed, feel free to resend it.
I'm not sure why you need a version inside the
On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 11:58:01AM +1000, Dave Airlie wrote:
> > Granted if these ioctls are to be used by *chrome to workaround this
> > bug as well, then
> > it would be good if patches to those driver were made available so as
> >
On Fri, Sep 11, 2009 at 04:26:55AM +0100, Dave Airlie wrote:
>
> >
> > As a first answer, without going in depth, as i just returned from my
> > thursday constitutional.
> >
> > Do you have an explanation as to why this commit never made it to the
> > kernel?
>
> Because it probably wasn't no
On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
> On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> >
> > And why did you suddenly start to care, while you pretty much ignored
> > this dead before? Would that be for technical reasons?
>
> Luc,
> When was the last prod
> >
> > Because it probably wasn't noticed, feel free to resend it.
> >
> > I'm not sure why you need a version inside the via_drm.h but I'm
> > willing to accept that the via driver development process is messed up
> > enough to require it. No other driver has needed it.
>
> How do graphics d
On Fri, Sep 11, 2009 at 05:02:47AM +0100, Dave Airlie wrote:
>
> They shouldn't have to. At build time they just require a certain version,
> you shouldn't be building half the features into the driver because it
> has an old _drm.h file. In an ideal world we would have all this stuff
> hidden at
>
> What should the canonical source of such versioning information be?
>
> * This header file defines the interface, and this versioning included
> in the same headerfile should then niquely identify this interface.
> * driver builds against this header and should then require this version
>
On Fri, Sep 11, 2009 at 05:48:18AM +0200, Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 01:29:21PM +1000, Daniel Stone wrote:
> > On Fri, Sep 11, 2009 at 05:20:06AM +0200, Luc Verhaegen wrote:
> > >
> > > And why did you suddenly start to care, while you pretty much ignored
> > > this dead before
To: Luc Verhaegen
Cc: Bruce Chang; Joseph Chan; dri-devel@lists.sourceforge.net; Benjamin Pan
(Fremont)
Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by
3D scaling+ACPI
>
> These patches break both free drivers out there. They not only break
> the API,
On Fri, Sep 11, 2009 at 05:15:04PM +0800, brucech...@via.com.tw wrote:
> Hello Luc:
> Can I know which chipset should I use if I like to verify the DRM
> driver with UniChrome driver in SLED11? Is CX700M platform OK? Or
> CN700?
>
> Thanks and Best Regards
The three devices currently fully
Cc: airl...@gmail.com; Joseph Chan; dri-devel@lists.sourceforge.net; Benjamin
Pan (Fremont)
Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by
3D scaling+ACPI
On Fri, Sep 11, 2009 at 05:15:04PM +0800, brucech...@via.com.tw wrote:
> Hello Luc:
> Can I know
On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote:
>
> >
> > What should the canonical source of such versioning information be?
> >
> > * This header file defines the interface, and this versioning included
> > in the same headerfile should then niquely identify this interface.
> > *
> >
> > No thats where you got it wrong, a driver should never *require* version
> > of interface at runtime == version of interface at build time. We
> > rarely make incompatible major number changes in the kernel drivers,
> > (radeon kms being the first in my memory). DRM drivers ship in the
> >
Luc Verhaegen wrote:
> On Fri, Sep 11, 2009 at 05:54:34AM +0100, Dave Airlie wrote:
>
>>> What should the canonical source of such versioning information be?
>>>
>>> * This header file defines the interface, and this versioning included
>>> in the same headerfile should then niquely identify th
> Hello Luc and Dave:
> Thank you very much for your comment on the UniChrome DRM. And sorry for
> the trouble I made. Based on your comment, we modify our UniChrome patch as
> below(I would like to call it Ver1.5 because it's for reference not for fomal
> submittion): . The attached Xorg.0.l
:37 AM
To: Bruce Chang
Cc: l...@skynet.be; Joseph Chan; dri-devel@lists.sourceforge.net; Benjamin Pan
(Fremont)
Subject: Re: [Patch 0/2] [VIA UniChrome DRM] Patch system hang issue caused by
3D scaling+ACPI
> Hello Luc and Dave:
> Thank you very much for your comment on the UniChrome DR
On Fri, Sep 11, 2009 at 11:00:27PM +0100, Dave Airlie wrote:
>
> Okay incompatible interfaces are not acceptable unless they are major
> version number changes. Minor or patch version changes should not break
> the kernel interface in any way unless its a major security hole being
> solved, and
> Are you saying "Yes, it is right to carry version information in the
> drm.h file"?
No I'm still in no way convinced of this, the fact Thomas doesn't see it
as a requirement either, and *no* other drm driver does it, is all
pointing towards its unnecessary. You seem to think its obvious but we
On Tue, Sep 15, 2009 at 08:57:28PM +0100, Dave Airlie wrote:
> > Novell did not have to upstream itself, so please stop suggesting that
> > this was Novell doing stuff behind closed doors.
>
> If Greg did this as part of staging I also objected to this on lkml at
> one time.
Huh? I added this c
22 matches
Mail list logo
