Multimedia-chat-meeting-2017-04-26

<pinchartl> good morning/afternoon  [15:55]
<uli___> morning
<morimoto> hi
<neg> morning
<jmondi> hello everyone  [15:56]
<pinchartl> everybody is in the room
<pinchartl> but are kbingham and dammsan awake ?
* kbingham is definitely asleep
<pinchartl> :-)  [15:57]
<pinchartl> Morimoto-san mentioned that he has a Renesas internal meeting at
	    17:00, so let's get started and try to be quick
<pinchartl> topics for the day
<pinchartl> Topic 1. Status check for the multimedia tasks
<pinchartl> Topic 2. Requests from the BSP team
<pinchartl> (from Morimoto-san's e-mail)
<pinchartl> Topic 3. OSS Japan trip
<pinchartl> Topic 4. Next meeting
<pinchartl> anything else ?  [15:58]
<pinchartl> I'll take that as a no
<pinchartl> jmondi: wanna start ?  [15:59]
<jmondi> yeah sure
<jmondi> status update, as reported in the email
<jmondi> A)
<jmondi> - RFC patches to move CEU driver away from soc-camera
<jmondi> - studied hw platform to test it with a real camera, and possibily
	 not from remote  [16:00]
<jmondi> B)
<jmondi> - Add OF support to that driver and add support to RZ device tree for
	 CEU driver
<jmondi> - That would maybe require cooking up a device tree for GR-Peach, if
	 that will ever run mainline  [16:01]
<jmondi> C = D = Null
<jmondi> -- eot --
<pinchartl> thank you
<pinchartl> a device tree for GR-Peach would be cool
<pinchartl> let's see what will happen
<jmondi> yeah, -would be-  [16:02]
<pinchartl> I've seen your ceu RFC, I'll review that
<jmondi> please bear with me :)
<pinchartl> :-)
<pinchartl> what do you mean by "possibly not from remote" ?  [16:03]
<pinchartl> will you get a Migo-R board ?
<jmondi> I don't think so
*** horms (~horms@217.111.208.18) has joined channel #periperi
<pinchartl> what do you mean then ? :-)
<jmondi> I want to use a GR-Peach, as it's the only RZ board I have with VIO
	 signal routed to connectors to test the driver
<jmondi> otherwise, I will have to test it from remote, on Migo-R, in MAgnus'
	 board farm  [16:04]
<pinchartl> ok  [16:05]
<pinchartl> next, kbingham
<kbingham> So I have mostly been working on ADV7482 with neg.  [16:06]
<kbingham> The driver is now split into two subdevices (as a staging process)
	   for HDMI and AIN/CVBS...
<kbingham> These are registered and linked by rcar-vin using the device and an
	   extra 'port' specifier to determine which one is which from the
	   single DT node.  [16:07]
<kbingham> Niklas has also been looking at incremental registrations, and I
	   plan to follow his work to further split into more subdev's - such
	   that the rcar vin registers the TXA/TXB subdevs, and they in turn
	   then register links to both the AIN/HDMI  [16:08]
<kbingham> I've also started work on getting my older patchsets up to date for
	   ML, and I hope to get those posted in the next couple of weekes.
								        [16:09]
<kbingham> FInally - I have successfully commenced a local fork() which is due
	   for completion around Late October, and thus I predict I will not
	   be able to attend ELCE this year
<pinchartl> congratulations for that project ! you'll realize that, like
	    software development, it will keep you awake at night :-)
								        [16:10]
<kbingham> I work better at night :)  [16:11]
<dammsan> congrats!!
<jmondi> kbingham: if I got this right, congrats!
<kbingham> Thanks :)
<pinchartl> you mentioned in your e-mail report a minor bugfix to rcar-vin
								        [16:12]
<pinchartl> has it been posted ?
<kbingham> Yes, it was posted.
<kbingham> It is *very* minor really :)
<pinchartl> with a Fixes: tag ?
<kbingham> Indeed - with a Fixes: tag, and it should have a -renesas in the
	   authorship - so any automated tools should be able to pick it up if
	   they hvae been developed.  [16:13]
<pinchartl> thank you
<kbingham> Althoguh - as a trick to test the tooling ...
<pinchartl> :-)  [16:14]
<kbingham> it has been sent from git-send-mail which defaulted to from:
	   kbingham@kernel.org - however the Patch authorship is certainly
	   From: kieran.bingham+renesas@
<pinchartl> next, me  [16:15]
<pinchartl> I've worked on the MAX9286+MAX9271+OV10635 camera support
<pinchartl> the first step is to get it working with the BSP kernel
<pinchartl> status: done
<pinchartl> the next step is to port it to mainline, using the BSP code for
	    the rcar-vin driver
<pinchartl> status: done  [16:16]
<pinchartl> the next step is to move it from the legacy soc_camera rcar-vin
	    driver to the new rcar-vin driver
<pinchartl> status: http://www.ideasonboard.org/frame-000008.jpg
<dammsan> nice!!  [16:17]
<uli___> impressive
<pinchartl> the code is available from git://linuxtv.org/pinchartl/media.git
	    vin/gmsl
<uli___> is that a famiclone? :)
<pinchartl> I'll add my kernel config, my buildroot config and instructions to
	    capture images on the wiki
<dammsan> yeah, providing vin analogue for one of the boards  [16:18]
<pinchartl> I've also cleaned up the MAX9286+MAX9271+OV10635 code
<pinchartl> it's split in two drivers, one for the max9286 and one for the
	    max9271+ov10635 camera (called rdacm20, after the name of the
	    camera)
<pinchartl> they're both horrible
<pinchartl> but we'll hopefully be able to fix that later
<pinchartl> I've sent a list of hacks performed by the drivers at the I2C
	    level to Niklas to give him and Wolfram material for their work on
	    the topic  [16:19]
<pinchartl> for the next two weeks, I plan to clean up the code a bit more,
	    and concentrate on my base contract to address smaller VSP and DU
	    tasks (including requests from the BSP team for which Porimoto-san
	    sent a nice reminder)  [16:20]
<pinchartl> s/Porimoto-san/Morimoto-san/
<pinchartl> (P and M are next to each other on Belgian keyboards)
<pinchartl> dammsan: would it be possible to install a small lamp in front of
	    the cameras ? it could even be something LED-based connected to
	    the camera power, so it would be off by default  [16:21]
<pinchartl> otherwise it's difficult to perform tests during most of the day
	    here :-)
<dammsan> i'll see what i can do
<kbingham> pinchartl: You just need to improve the contrast response for dark
	   images :)  [16:22]
<pinchartl> thank you  [16:23]
<pinchartl> I forgot to mention that the tests have only been performed with a
	    single camera
<pinchartl> next, dammsan  [16:25]
<pinchartl> or maybe not  [16:26]
<pinchartl> maybe Magnus is now trying to find a lamp
<pinchartl> in the meantime, next, morimoto
<morimoto> A) What have I done since last time
<morimoto> - OF-graph update, but nothing happen
<morimoto> - OV camera datasheet export paper work (Officially, you are not
	   yet received OV camera datasheet)
<morimoto> - kicked IMI guy for camera board question (you could received
	   information from them)  [16:27]
<morimoto> - fixed sound noise issue which is reported from BSP team. I posted
	   fixup patch to ML and it was accepted
<morimoto> - I had meeting with BSP team. I and BSP team will have this
	   meeting once per month. we can talk it in Topic 2
<morimoto> B) What I plan to do till next time
<morimoto> - continue OF-graph posting. Japan will have long holiday from 28th
	   April to 7th May. So I will repost before holiday
<morimoto> C) Problems I have currently
<morimoto> D) Posted/Accepted bugfix patch
<morimoto> No, Sir
<morimoto> --EOT--
<pinchartl> thank you
<pinchartl> next, neg  [16:28]
<neg> A)  [16:29]
<neg>     - Patch to support to V4L2 for incremental async subdevice binding
<neg>     - Adapted VIN and CSI-2 patches to make use of incremental async,
<neg>       the code is cleaner and it will support arbitrary pipeline
<neg>       lengths, that is both on-board use-case (ADV7482) and 8 channel
<neg>       prototype.
<neg>     - Started to plan 8 channel i2c prototype meeting with Wolfram in
<neg>       Stockholm. Due to take place Monday 8th of May. If anyone have any
<neg>       concerns about this topic please send them to Wolfram and me.
<neg>       Laurent have already provided lots of nice feedback from his work
<neg>       with the existing code.
<neg>         - Passthru mode of i2c traffic
<neg>           The two max9286 are connected to the same I2C bus and by
<neg>           default they seems to broacast I2C messages to the other side
<neg>           over the GSML bus. The devices on the other side of the
<neg>           max9286 have same i2c addresses so special care is needed
<neg>           here.
<neg>         - Shared power supplies for all cameras
<neg>           There is a delay needed when powering on the cameras, in the
								        [16:30]
<neg>           prototype code it's set to wait 8 secondes, per camera.
<neg>         - I2C address translation
<neg>           The max9286 support address translation which is both
<neg>           problematic but could be used to solve the i2c passthru issue
<neg>           if handled with care.
<neg>     - Had discussions with Kieran to hand over the ADV7482 prototype.
<neg> B)
<neg>     - Post patches for incremental async subdevice
<neg>     - See if it's feasible to add a new V4L2 operation to help map a DT
<neg>       port/endpoint to a media controller pad. If so post patches for
<neg>       this and make use of it in the CSI-2 driver.
<neg>     - Post new versions of Gen3 VIN and CSI-2 series to incorporate bug
<neg>       fixes and reports from Kieran and Laurent and the incremental
<neg>       async subdevice changes to create a better base for the 8 channel
<neg>       prototype work.
<neg> C)
<neg>     None
<neg> D)
<neg>     None
<neg> --eot--
<pinchartl> thank you  [16:31]
<pinchartl> regarding B.2, I think it should be a media controller operation,
	    not a V4L2 operation
<pinchartl> next, uli___  [16:32]
<neg> thanks, will start my work as a  media controller operation then :-)
								        [16:33]
<uli___> > A) What have I done since last time
<uli___> Researched with Magnus on what we can hook up to the V2H board to get
	 a
<uli___> working camera setup.  (We drew a blank.  While the MAX
<uli___> serializer/deserializer chips are claimed to be compatible between
	 families
<uli___> for basic operation, they do not all support the same physical
	 interfaces.
<uli___> The existing Renesas camera hardware is coax, but the MAX9260 on the
	 V2H
<uli___> board only supports STP...)
<uli___> > B) What I plan to do till next time
<uli___> Prototype for multiplexing the V2H board's four MAX9260s to one SCIF
	 using
<uli___> the board's GPIO-based switch.
<uli___> > C) Problems I have currently
<uli___> None.
<uli___> > D) Posted/Accepted bugfix patch
<uli___> None.
<uli___> (did that work? i'm having cut-and-paste problems here...)
<uli___> anyway, EOT
<pinchartl> it's definitely readable :-)  [16:34]
<pinchartl> thank you
<pinchartl> Topic 2. Requests from BSP team  [16:35]
<pinchartl> morimoto: would you like to drive this, and explain about the
	    monthly meeting ?
<morimoto> OK  [16:36]
<morimoto> I and BSP team talk about remaining request
<morimoto> some of them is new
<morimoto> some of them are already requested to you guys, but nothing happen
	   today  [16:37]
<morimoto> * DU fence has missing feature
<morimoto> This is new
<morimoto> Can you read my email for detail ?
<morimoto> Maybe this is for Laurent (?)
<morimoto> * confirm DMA ATTR SKIP CPU patch
<morimoto> This is forgotten request  [16:38]
<morimoto> Oops.
<morimoto> no
<morimoto> this is new one
<morimoto> I think Laurent or Kieran can handle it ?
<morimoto> Subject: VSP1 driver cache flush
<morimoto> Date: Mon, 17 Apr 2017 16:25:42 +0900
<pinchartl> I'll handle the DU/VSP IOMMU support as part of my base contract,
	    yes
<morimoto> Thanks
<pinchartl> it will include the patch you mentioned
<morimoto> * confirm DU/VSPD initial sequence
<morimoto> This was requested long time ago  [16:39]
<morimoto> Subject: Re: DU/VSPD initial sequence
<morimoto> Date: Wed, 11 Jan 2017 11:07:48 +0900
<pinchartl> I'll work on that with Kieran, depending on who finds time first
<morimoto> OK
<morimoto> BSP team want to get it until 7/M if possible
<morimoto> Is it possible ?
<pinchartl> I think so, yes
<morimoto> Thanks
<morimoto> * confirm V4L2_FIELD_SEQ_TB/TB status
<morimoto> This is maybe for Niklas 
<morimoto> 
<pinchartl> we might create an additional task for the second part of Q2 for
	    the DU/VSP initial sequence  [16:40]
<morimoto> Subject: [periperi] Question about V4L2_FIELD_SEQ_TB/TB on VIN
<morimoto> Date: Tue, 7 Mar 2017 10:34:16 +0900
<pinchartl> yes, that's for Niklas I think
<pinchartl> neg: what do you think ?
<morimoto> pinchartl: thanks
<neg> Yes, it's for me and I think it could be possible to add
      V4L2_FIELD_SEQ_TB/TB
<morimoto> neg: nice to know
<neg> But I really hope at least the Gen2 cleanup sereis needs to be picked up
      first since I made some mistakes in the oringal code regarding scaling
      which would interfere with this  [16:41]
<pinchartl> neg: you can organize the branches any way you like, feel free to
	    develop on top of the Gen2 cleanup series
<morimoto> neg: no stress. I can explain it to BSP team  [16:42]
<morimoto> pinchartl: do you have any commnets/idea for [1/5] ?
<pinchartl> morimoto: regaring "DU fence has missing feature", you mentioned
	    in your e-mail
<pinchartl> "Then, they created and tried gem_prime_res_obj.patch (I
	    attached)."
<pinchartl> but you haven't attached anything :-)
<morimoto> Oops
<morimoto> I will
<neg> ofc, I just don't want to add more to the already 50+ pile out of tree
      patches of VIN :-) And from the initial discussion this was a low prio
      thing, if that changes I will ofc work ontop of the out of tree patches
<pinchartl> thank you  [16:44]
<pinchartl> I think this closes this topic, unless you have something to add
<pinchartl> I'll check the DU patch when I'll get it and reply by e-mail
* morimoto I posted mail which has mising patch/log  [16:45]
<pinchartl> thank you  [16:46]
<pinchartl> Topic 3. OSS Japan trip
<pinchartl> first question, have you all booked your flights and hotels ?
<kbingham> I have booked flights - and *partial* hotel.
<jmondi> both booked  [16:47]
* morimoto time to go to Renesas meeting
<kbingham> I have booked in the hilton from the 28th to the 3rd of june.
<pinchartl> morimoto: have fun :-)
<pinchartl> thank you for joining
<kbingham> but the hilton on the day I arrive (27th) and on the Saturday (4th)
	   are towards the end of 'prohibitively expensive' in my opinion
<neg> I have both flight and hotell booked  [16:48]
<kbingham> I have booked the days that were available at the LF rate, or
	   similar.
<pinchartl> kbingham: you have told me a few days ago that the hilton LF room
	    block seemed to have been fully booked. did you get any feedback
	    from the LF ?
<kbingham> The feedback was that the block had been fully booked on the
	   sunday, and that I could book from the monday ...
<pinchartl> lovely  [16:49]
<kbingham> I was then able to book the 'sunday night' at a rate *less* than
	   the LF rate - by booking that night separately.
<pinchartl> :-)
<kbingham> The *saturday* night - is still Y 52,250
<kbingham> And the Saturday night *after* is Y 45,000
<pinchartl> I'm afraid you'll likely have to consider a different hotel
<kbingham> So I have *not* booked for either of those nights.
<pinchartl> I can recommend a much better hotel than the Hilton for that kind
	    of price :-)  [16:50]
<kbingham> hehe indeed - unless anyone has a twin room and would let me crash
	   in their spare bed for the night :)
<pinchartl> I'll arrive on Sunday morning so I'm afraid I can't help you :-)
<neg> kbingham: what was the total for your hilton booking? I think I got the
      LF rates for all nights and my total was Y 211.300  [16:51]
<pinchartl> neg: what are the dates ?
<neg> 28 May to 04 Jun  [16:52]
<kbingham> For arrival I'll find something central and cheap that I can book
	   for the night before I arrive (at my own cost) so that I have a bed
	   to check into immediately on arrival if needed.
<kbingham> (I arrive at 7am, and I'd rather have a room I can dump my stuff in
	   - and get a shower)
<jmondi> kbingham: let me check my dates and what kind of room I have booked
<pinchartl> neg: for the same dates I got ¥142,247 + taxes + service charge =
	    ¥174,998
<kbingham> 29th to the 3rd, I got a total at 124,999 Y  [16:53]
<pinchartl> (whatever the service charge is...)
<jmondi> kbingham: I arrive the 27th as well
<neg> pinchartl: ohh that was inc taxes and serivce, without Y 172 000
<pinchartl> neg: I don't think you got all the nights at the LF rate then
								        [16:54]
<neg> pinchartl: thanks, just wanted to make sure they did not try to fool me
      :-)  [16:55]
<pinchartl> neg: I'll let you see with Magnus what can be reasonably expensed
	    :-)
<jmondi> why is my rate so different from yours????  [16:56]
<kbingham> jmondi: What was your rate?
<pinchartl> jmondi: what are your dates and rate ?  [16:57]
<jmondi> May 28th - Jun 2ns ~30K
<neg> pinchartl: more expensive rooms just meens we need to bring larger
      bottels of booze as gifts, right?
<jmondi> s/ns/nd/
<jmondi> may 27th  57.500
<jmondi> Jun 2ns - June 4th 31.500
<kbingham> jmondi:  Ouch :)
<pinchartl> jmondi: I assume because you booked late and didn't get the LF
	    room block rate  [16:58]
<jmondi> I assumed that was the LF rate
<kbingham> jmondi: Convert 57500 Yen to EUR :)
<pinchartl> I don't think you can expense ¥57.500 for one night :-)
<pinchartl> even ¥31.500 is quite high
<dammsan> [5~for domestic travel renesas usually limits to 10.000 jpy per
	  night  [16:59]
<dammsan> some exception can be made for you guys, but 50.000 is way off
<jmondi> WHAAAAT?
<kbingham> jmondi: hahah
<pinchartl> jmondi: I see you have converted :-)
<kbingham> jmondi: And now you've realised why I chose not to book that night
	   :)
<pinchartl> dammsan: I assumed that the LF room rate would be acceptable, but
	    above that, it seems too high to me
<jmondi> I booked them in block assuming it was the LF rate  [17:00]
<jmondi> I will cancel my reservation for the first night
<pinchartl> luckily it's cancellable, yes
<kbingham> jmondi: Indeed - that's what I tried to do as well.. .... Where I
	   went wrong was checking to see what the breakdown of costs was :)
<jmondi> dammsan: ~30K Y is ok?
<pinchartl> jmondi: if you try to book 29th to 3rd separately now you might
	    still be able to get the LF rate  [17:01]
<pinchartl> and possibly a good rate if you book the 28th separately too, as
	    Kieran did
<pinchartl> anyway, I'll let you sort that out with Magnus  [17:02]
<kbingham> pinchartl: jmondi: Sorry - small correction on the '28th being
	   cheaper'
<jmondi> from 28th to 2nd June I have 29500
<dammsan> i think you should follow pinchartl
<kbingham> pinchartl: They tricked me  - - They displayed the rate without
	   taxes, - it came through at 24K JPY
<pinchartl> kbingham: ok
<pinchartl> kbingham: I believe that's the LF rate
<pinchartl> ¥25K / night  [17:03]
<pinchartl> that's roughly 200€
<kbingham> jmondi: We should collaborate on our arrival hotel - and what ever
	   we get - get the same.
<dammsan> i think roughly 200 EUR is acceptable
<pinchartl> dammsan: thank you for the confirmation
<pinchartl> the other point I wanted to discuss  [17:04]
<pinchartl> is our plans for Saturday the 3rd
<pinchartl> I propose spending the whole day together
<neg> yea Y 24 500 / night is what I also have + taxes and services
<pinchartl> and while we can certainly visit Tokyo, several of us have done so
	    already  [17:05]
<jmondi> kbingham: we should, let's sync offline
<pinchartl> so another option is to spend the day outside town, doing
	    something a bit different
<jmondi> neg: I assume 24.500 + tax and services is roughly the 29.500 I have
	 for the 28th->2nd
<pinchartl> for instance, a day trip to mount Fuji  [17:06]
<pinchartl> proposals are welcome
<kbingham> pinchartl: I would be very keen on a mount-fuji trip  [17:07]
<pinchartl> could you all have a look and tell me if there's anything you'd
	    like to see/do around Tokyo ?
<neg> pinchartl: I will reread Tokyo Vice and get back to you.. ;-)
<pinchartl> dammsan: it's very likely less exotic for you, but recommendations
	    are welcome :-)
<neg> mount Fuji sounds fun, is it a valid trip during the rain seasson?
								        [17:09]
<pinchartl> neg: that's where I'd like recommendations from our locals :-)
								        [17:10]
<neg> The biggest lesson I learnt last time was to next time bring more
      t-shirts :-)
<pinchartl> hehe  [17:11]
<pinchartl> Topic 4. Next meeting
<pinchartl> I propose two weeks from now, on 2017-05-10, 08:00 GMT / 09:00
	    CEST / 10:00 EEST / 16:00 JST  [17:12]
<kbingham> http://zoomingjapan.com/travel/day-trips-from-tokyo/
<kbingham> pinchartl: Ack on 10th May.  [17:13]
<neg> 10th of May works for me
<pinchartl> let's go for the 10th of May then  [17:15]
<pinchartl> it nobody has anything to add, I propose adjourning this
	    meeting. does anyone second ?
<neg> seconded
<dammsan> pinchart: i moved the cameras to let you look at the board leds
<pinchartl> dammsan: thank you  [17:16]
<dammsan> hopefully it is better
<pinchartl> thank you all for attending
hl kwb">unsigned int</span> texture_clr_cmp_msk_c<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> fog_color_c<span class="hl opt">;</span>

	<span class="hl com">/* Texture state */</span>
	<span class="hl kwb">unsigned int</span> tex_size_pitch_c<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> constant_color_c<span class="hl opt">;</span>

	<span class="hl com">/* Setup state */</span>
	<span class="hl kwb">unsigned int</span> pm4_vc_fpu_setup<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> setup_cntl<span class="hl opt">;</span>

	<span class="hl com">/* Mask state */</span>
	<span class="hl kwb">unsigned int</span> dp_write_mask<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> sten_ref_mask_c<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> plane_3d_mask_c<span class="hl opt">;</span>

	<span class="hl com">/* Window state */</span>
	<span class="hl kwb">unsigned int</span> window_xy_offset<span class="hl opt">;</span>

	<span class="hl com">/* Core state */</span>
	<span class="hl kwb">unsigned int</span> scale_3d_cntl<span class="hl opt">;</span>
<span class="hl opt">}</span> drm_r128_context_regs_t<span class="hl opt">;</span>

<span class="hl com">/* Setup registers for each texture unit</span>
<span class="hl com"> */</span>
<span class="hl kwc">typedef</span> <span class="hl kwb">struct</span> <span class="hl opt">{</span>
	<span class="hl kwb">unsigned int</span> tex_cntl<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> tex_combine_cntl<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> tex_size_pitch<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> tex_offset<span class="hl opt">[</span>R128_MAX_TEXTURE_LEVELS<span class="hl opt">];</span>
	<span class="hl kwb">unsigned int</span> tex_border_color<span class="hl opt">;</span>
<span class="hl opt">}</span> drm_r128_texture_regs_t<span class="hl opt">;</span>

<span class="hl kwc">typedef</span> <span class="hl kwb">struct</span> drm_r128_sarea <span class="hl opt">{</span>
	<span class="hl com">/* The channel for communication of state information to the kernel</span>
<span class="hl com">	 * on firing a vertex buffer.</span>
<span class="hl com">	 */</span>
	drm_r128_context_regs_t context_state<span class="hl opt">;</span>
	drm_r128_texture_regs_t tex_state<span class="hl opt">[</span>R128_MAX_TEXTURE_UNITS<span class="hl opt">];</span>
	<span class="hl kwb">unsigned int</span> dirty<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> vertsize<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> vc_format<span class="hl opt">;</span>

	<span class="hl com">/* The current cliprects, or a subset thereof.</span>
<span class="hl com">	 */</span>
	drm_clip_rect_t boxes<span class="hl opt">[</span>R128_NR_SAREA_CLIPRECTS<span class="hl opt">];</span>
	<span class="hl kwb">unsigned int</span> nbox<span class="hl opt">;</span>

	<span class="hl com">/* Counters for client-side throttling of rendering clients.</span>
<span class="hl com">	 */</span>
	<span class="hl kwb">unsigned int</span> last_frame<span class="hl opt">;</span>
	<span class="hl kwb">unsigned int</span> last_dispatch<span class="hl opt">;</span>

	drm_tex_region_t tex_list<span class="hl opt">[</span>R128_NR_TEX_HEAPS<span class="hl opt">][</span>R128_NR_TEX_REGIONS <span class="hl opt">+</span> <span class="hl num">1</span><span class="hl opt">];</span>
	<span class="hl kwb">unsigned int</span> tex_age<span class="hl opt">[</span>R128_NR_TEX_HEAPS<span class="hl opt">];</span>
	<span class="hl kwb">int</span> ctx_owner<span class="hl opt">;</span>
	<span class="hl kwb">int</span> pfAllowPageFlip<span class="hl opt">;</span>	<span class="hl com">/* number of 3d windows (0,1,2 or more) */</span>
	<span class="hl kwb">int</span> pfCurrentPage<span class="hl opt">;</span>	<span class="hl com">/* which buffer is being displayed? */</span>
<span class="hl opt">}</span> drm_r128_sarea_t<span class="hl opt">;</span>

<span class="hl com">/* WARNING: If you change any of these defines, make sure to change the</span>
<span class="hl com"> * defines in the Xserver file (xf86drmR128.h)</span>
<span class="hl com"> */</span>

<span class="hl com">/* Rage 128 specific ioctls</span>
<span class="hl com"> * The device specific ioctl range is 0x40 to 0x79.</span>
<span class="hl com"> */</span>
<span class="hl ppc">#define DRM_R128_INIT       0x00</span>
<span class="hl ppc">#define DRM_R128_CCE_START  0x01</span>
<span class="hl ppc">#define DRM_R128_CCE_STOP   0x02</span>
<span class="hl ppc">#define DRM_R128_CCE_RESET  0x03</span>
<span class="hl ppc">#define DRM_R128_CCE_IDLE   0x04</span>
<span class="hl com">/* 0x05 not used */</span>
<span class="hl ppc">#define DRM_R128_RESET      0x06</span>
<span class="hl ppc">#define DRM_R128_SWAP       0x07</span>
<span class="hl ppc">#define DRM_R128_CLEAR      0x08</span>
<span class="hl ppc">#define DRM_R128_VERTEX     0x09</span>
<span class="hl ppc">#define DRM_R128_INDICES    0x0a</span>
<span class="hl ppc">#define DRM_R128_BLIT       0x0b</span>
<span class="hl ppc">#define DRM_R128_DEPTH      0x0c</span>
<span class="hl ppc">#define DRM_R128_STIPPLE    0x0d