search for: bitfields

...the NVFXTCL_ approach is worthwhile. If consensus develops against this notion, it is easy to change the Python script that generated the unification patch and rerun it. Luca Barbieri (5): renouveau: completely describe POINT_SPRITE on nv30 and nv40 renouveau/nv40: describe CLEAR_VALUE_COLOR bitfields renouveau/nv40: set NV40TCL_LINE_STIPPLE_PATTERN to hexa like nv30 renouveau/nv30: remove clip planes #6 and #7 renouveau: unify nv30 and nv40 as NVFXTCL nvfx.py | 207 +++++++++++++ nvfx.sed | 340 ++++++++++++++++++++++ renouveau.xml | 891 ++++++++++++++++++++++-------------...

NV10TCL defines the vertex buffer registers both as arrays and as individual named registers. This causes duplicate register definitions and the individual registers are not used either by the DDX or by the Mesa driver. Francisco Jerez said to remove them all. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- renouveau.xml | 49

Hi, This is my work in documenting EVO. I did some RE to fill missing gaps. Best regards, Maxim Levitsky

--- rnndb/display/nv3_pramdac.xml | 67 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/rnndb/display/nv3_pramdac.xml b/rnndb/display/nv3_pramdac.xml index 13b6a7b..e236921 100644 --- a/rnndb/display/nv3_pramdac.xml +++ b/rnndb/display/nv3_pramdac.xml @@ -79,12 +79,79 @@ <bitfield pos="28" name="VCLK_DB2"/> <bitfield

...++++++++++--- > 1 file changed, 34 insertions(+), 3 deletions(-) > > diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml > index 500cea9..e006dbe 100644 > --- a/rnndb/memory/nvc0_pbfb.xml > +++ b/rnndb/memory/nvc0_pbfb.xml > @@ -49,23 +49,54 @@ > Most bitfields are unknown. > </doc> > <bitfield high="7" low="0" name="RP"> > - <doc> RAS# precharge. </doc> > + <doc> RAS# Precharge. </doc> > </bitfield> > <bitfield high="15" low="8...

Hi, I've just tried to run the test-suite, for the first time in ages. It stops rather abruptly with: $ make TEST=nightly report report.html /home/jay/llvm/local/bin/llvm-gcc -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests -I/home/jay/svn/llvm-project/test-suite/trunk/SingleSource/UnitTests -I/home/jay/git/llvm/projects/test-suite/include -I../../include

Apologies for the long post. I'm trying to include what I hope are the relevant bits (output of lsusb -v and usbhid-ups) Long term goal: I've got a DIY UPS that I would like to get working with my QNAP NAS (which uses Linux and NUT underneath the hood) Immediate short-term problem: I can't get past running usbhid-ups on Ubuntu 23.10 with an Arduino Leonardo. I have an Arduino Micro

...c0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml index 500cea9..e006dbe 100644 --- a/rnndb/memory/nvc0_pbfb.xml +++ b/rnndb/memory/nvc0_pbfb.xml @@ -49,23 +49,54 @@ Most bitfields are unknown. </doc> <bitfield high="7" low="0" name="RP"> - <doc> RAS# precharge. </doc> + <doc> RAS# Precharge. </doc> </bitfield> <bitfield high="15" low="8" name="RAS"> -...

On 6 May 2011 09:29, Jay Foad <jay.foad at gmail.com> wrote: > I've just tried to run the test-suite, for the first time in ages. It > stops rather abruptly with: > > $ make TEST=nightly report report.html > > /home/jay/llvm/local/bin/llvm-gcc > -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests >

Hi Guillaume, Thanks for the RFC. I'm generally +1 on the concept. Making bit field manipulation easier seems like a good overall goal given its prevalence in LLVM. As for the syntax, I tend to prefer that we don't pollute the namespace. Have you considered pushing the methods into the Bitfield class? Maybe something like: ``` uint8_t Storage = 0; using Amount =

On May 6, 2011, at 1:29 AM, Jay Foad wrote: > Hi, > > I've just tried to run the test-suite, for the first time in ages. It > stops rather abruptly with: > > $ make TEST=nightly report report.html This is a test that Fariborz has been working on with Clang. It is possible that llvm-gcc is expected to fail it, if this is so, the test can be put in an #ifdef __clang__.

First some data errors I get with both nv20 exa and nv20 dri/mesa. 1. RT_FORMAT LINEAR + X8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000105 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000105 LINEAR + A8R8G8B8 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x01000100:0x00000108 Ch 1/5 Class 0x0597 Mthd 0x0208 Data 0x00800080:0x00000108 The only value I found in renouveau dump

Hi Charles. I patched, reconfigured, remake'd, remake install'd - but no change. however, some more likely helpful information below for you. Thank you On Mon, Jun 8, 2015 at 12:34 PM, Greg Hersch <hersch.greg at gmail.com> wrote: > > > On Sun, 7 Jun 2015, Charles Lepple wrote: > >> [please use reply-all to include the list, as the list does not override >>

...on. As Eli notes, Clang has lowered the function to LLVM IR >> >> containing consistent i16 operations. Despite that being a different >> >> choice from GCC, it should still be correct and consistent. >> >> >> > I suspect that this is more prevalent with bitfields as they're more >> > likely to have the load / bitwise op / store operations done on them, >> > resulting in an access type that can be shortened. But yes, it's not >> > specific to just bitfields. >> > >> > I'm more interested in consistency...

Greetings, Any suggestions? I think I'm close but I can't quite get tripplite_usb to talk to my OMNI1000LCD. I'm new to NUT and couldn't find an answer using Google. With any luck, I've simply missed the obvious. The system I'm using, kaylee, is a debian stable system with some debian testing installed and a 2.6.15.4 kernel. I downloaded NUT 2.0.3 and built it from

...seems to be a >> distraction. As Eli notes, Clang has lowered the function to LLVM IR >> containing consistent i16 operations. Despite that being a different >> choice from GCC, it should still be correct and consistent. >> > I suspect that this is more prevalent with bitfields as they're more > likely to have the load / bitwise op / store operations done on them, > resulting in an access type that can be shortened. But yes, it's not > specific to just bitfields. > > I'm more interested in consistency, to be honest. If the loads and > stores...

We're running into an interesting issue with the Linux kernel, and wanted advice on how to proceed. Example of what we're talking about: https://godbolt.org/z/ABGySq The issue is that when working with a bitfield a load may happen quickly after a store. For instance: struct napi_gro_cb { void *frag; unsigned int frag_len; u16 flush; u16 flush_id; u16 count; u16

On 15 June 2011 09:37, Jay Foad <jay.foad at gmail.com> wrote: > On 6 May 2011 09:29, Jay Foad <jay.foad at gmail.com> wrote: >> I've just tried to run the test-suite, for the first time in ages. It >> stops rather abruptly with: >> >> $ make TEST=nightly report report.html >> >> /home/jay/llvm/local/bin/llvm-gcc >>

On 03/09/2017 12:57 PM, Krzysztof Parzyszek wrote: > On 3/9/2017 12:47 PM, Hal Finkel wrote: >> >> On 03/09/2017 12:28 PM, Krzysztof Parzyszek via llvm-dev wrote: >>> We could add intrinsics to extract/insert a bitfield, which would >>> simplify a lot of that bitwise logic. >> >> But then you need to teach a bunch of places about how to simply them,

...> > > > The solution in clang (in Decl.h) is not ideal (as you have said > yourself). The solution I offer, is using a union of fields of class > BitField (this is a new class that implements a bitfield of a specific type > requested). With this, the definition, of the required bitfields in the > subclass data, remains in the hands of the actual class needing them. And > these are all restricted hierarchically by the superclasses of that class. > > I spent some time packing various bits of data into bit-fields in clang. > My experience > is that the solution in cl...