summaryrefslogtreecommitdiff
path: root/shared-core
AgeCommit message (Expand)Author
2006-12-01Unshare drm_drawable.c again for now.Michel Dänzer
2006-11-30Use nouveau_mem.c to allocate RAMIN.Ben Skeggs
2006-11-30Wrap access to objects in RAMIN.Ben Skeggs
2006-11-28For nv10, bit 16 of RAMFC need to be set for 64 bytes fifo context.Matthieu Castet
2006-11-27i915_vblank_tasklet: Try harder to avoid tearing.Michel Dänzer
2006-11-21Merge branch 'nouveau-1' of git+ssh://marcheu@git.freedesktop.org/git/mesa/dr...Stephane Marchesin
2006-11-21Don't spam dmesg if PMC_INTSTAT is 0Ben Skeggs
2006-11-18Only return FIFO number if the FIFO is marked as in use..Ben Skeggs
2006-11-18Check some return vals, fixes a couple of oopses.Ben Skeggs
2006-11-17Dump some useful info when a PGRAPH error occurs.Ben Skeggs
2006-11-16Merge branch 'nouveau-1' of git+ssh://marcheu@git.freedesktop.org/git/mesa/dr...Stephane Marchesin
2006-11-14Completely untested NV10/20/30 FIFO context switching changes.Ben Skeggs
2006-11-14Restructure initialisation a bit.Ben Skeggs
2006-11-14Merge branch 'nouveau-1' of git+ssh://git.freedesktop.org/git/mesa/drm into n...Ben Skeggs
2006-11-14Hack around yet another "X restart borkage without nouveau.ko reload" problem.Ben Skeggs
2006-11-11Merge branch 'master' of git+ssh://marcheu@git.freedesktop.org/git/mesa/drm i...Stephane Marchesin
2006-11-10Fix memory detection on TNT2 M64/TNT2 vanta.Stephane Marchesin
2006-11-07Add drm_u64_t typedef on non-linux to fix libdrm build.Eric Anholt
2006-11-06drm: fixup page alignment on SAREA map on ppc64Dave Airlie
2006-11-06fixup fifo size so it is page alignedDave Airlie
2006-11-06use a uint64_t for this not a pointerDave Airlie
2006-11-06Merge branch 'master' into nouveau-1Dave Airlie
2006-11-06Leave the bottom 64kb of RAMIN untouched.Ben Skeggs
2006-11-05nouveau: add compat ioc32 supportDave Airlie
2006-11-05add powerpc mmio swapper to NV_READ/WRITE macrosDave Airlie
2006-11-04Add some getparams.Stephane Marchesin
2006-11-04Move the context object creation flag handling to the drm.Stephane Marchesin
2006-10-27Reserve the new IOCTLs also for *bsd.Thomas Hellstrom
2006-10-27Last minute changes to support multi-page size buffer offset alignments.Thomas Hellstrom
2006-10-19Merge branch 'master' of git+ssh://git.freedesktop.org/git/mesa/drmThomas Hellstrom
2006-10-18Merging drm-ttm-0-2-branchThomas Hellstrom
2006-10-17Remove max number of locked pages check and call, sinceThomas Hellstrom
2006-10-18Remove hack which delays activation of a additional channel. The previously ...Ben Skeggs
2006-10-18Oops, we have more than 4 subchannels..Ben Skeggs
2006-10-17Useful output on a FIFO error interrupt.Ben Skeggs
2006-10-17typoBen Skeggs
2006-10-17Extend generality for more memory types.Thomas Hellstrom
2006-10-16dev->agp_buffer_map is not initialized for AGP DMA on savagesMichael Karcher
2006-10-17NV40: *Now* fifo ctx switching works for me..Ben Skeggs
2006-10-17NV40: FIFO context switching now WorksForMe(tm)Ben Skeggs
2006-10-17Setup NV40 RAMFC (in wrong location.. but anyway), rearrange the RAMFC setup ...Ben Skeggs
2006-10-17Some info on NV40's RAMFCBen Skeggs
2006-10-15Merge branch 'master' of git://anongit.freedesktop.org/git/mesa/drm into nouv...Stephane Marchesin
2006-10-14Again more work on context switches. They work, sometimes. And when they do t...Stephane Marchesin
2006-10-14remove config.h from build no longer exists kbuild does itDave Airlie
2006-10-14Add the missing breaks.Stephane Marchesin
2006-10-13Fix the fifo context size on nv10, nv20 and nv30.Stephane Marchesin
2006-10-14Fix some randomness in activating a second channel on NV40 (odd GET/PUT vals)...Ben Skeggs
2006-10-12Oops.Stephane Marchesin
2006-10-12Still more work on the context switching code.Stephane Marchesin
n gr-peach is incomplete 09:58 < geertu> jmondi: seacrh for mtu and ostm in the varipus r7s72100 DTS 09:58 < Marex> geertu: ACK, I have feedback from wsa_ , need to check it on real board 09:58 < geertu> Marex: OK 09:58 < geertu> Shimoda: 09:58 < geertu> - I got a request from BSP team about upstreaming of MFIS hwspinlock 09:58 < geertu> feature. 09:58 < geertu> - But, the current implementation is not good for upstreaming, I think. 09:58 < geertu> I have 3 concerns: 09:58 < geertu> 1) The device nodes ("mfis" and "mfis-lock") are duplicated like 09:58 < geertu> below... 09:58 < geertu> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi?h=v4.9/rcar-3.5.8#n875 09:58 < geertu> 2) The BSP team would like to support "MFIS lock register 8" in 09:58 < geertu> the future, but the register area is separated from "MFIS lock 09:58 < geertu> register [0-7]". 09:58 < geertu> 3) The "mfis" driver for rpmsg (Remote Processor Messaging) will 09:58 < geertu> be not upstreaming for now. 09:58 < geertu> - This module has two (or more) features and BSP supports the following 09:58 < geertu> features: 09:58 < geertu> 1) hwspinlock 09:58 < geertu> 2) rpmsg (Remote Processor Messaging) 09:58 < geertu> - My concern point is how to make the device node for it. 09:58 < geertu> - In my opinion, it should be a mfd driver like below: 09:58 < geertu> mfis { 09:58 < geertu> reg = <0 0xe6260000 0 0x1000>; 09:58 < geertu> hwspinlock { 09:58 < geertu> ... 09:58 < geertu> }; 09:58 < geertu> rpmsg { 09:58 < geertu> ... 09:58 < geertu> }; 09:58 < geertu> }; 09:58 < geertu> - But, what do you think? 09:58 < geertu> shimoda: I had a quick look at the DTS patch 09:59 < geertu> mfis-lock covers lock registers 0-7 09:59 < geertu> The mfis node covers all registers in the first 0x200 byts, but the only registers there are the same lock registers? 09:59 < jmondi> dammsan: geert: will do.. in the meantime fyi: https://paste.debian.net/989118/ 10:00 < wsa_> Marex: and don't hesitate to forward questions to the BSP team via Shimoda-san or Morimoto-san 10:00 < shimoda> geertu: the mfis node is for rpmsg 10:00 < geertu> shimoda: Using the same lock registers? Or are there undocumented registers in that block? 10:01 < geertu> You can have multiple register blocks in a single reg property, cfr. the gic nodes 10:01 < Marex> wsa_: will do if anything pops up 10:01 < shimoda> the out of tree driver of mfis driver for rpmsg will not use the same lock registers. Yes, there is undocumented registers for now 10:01 < geertu> You can just have a single one, too (cfr. your "reg = <0 0xe6260000 0 0x1000>") 10:02 < Marex> wsa_: the HS400 was just a quick test bolted on top of HS200 10:02 < geertu> A single driver can be both a hwspinlock and and rpcmsg provider, without using MFD, I think. 10:03 < geertu> Cfr. the CPG/MSSR driver, which is clk provider (for the clocks), genpd provider (for the clock domain), and reset controller (for module resets) 10:05 < shimoda> geertu: but, they make two drivers (hwspinlock and rpmsg) and two device nodes now 10:05 < geertu> shimoda: Two overlapping device nodes is a definite no-go 10:06 < shimoda> geertu: yes, I know. but bsp team doesn't know... 10:06 < geertu> shimoda: So you should tell them, so they know ;-) 10:07 < shimoda> geertu: yes, I should do so :) 10:07 < geertu> jmondi: timer_probe: no matching timers found 10:07 < geertu> jmondi: while my last boot on genmai of v4.9 said: 10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for clock events 10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for periodic clock events 10:08 < jmondi> geertu: yes... If I got this right, without MTU2 all clock events used for wake ups are not generated 10:08 < jmondi> so the only working methof for sleeping is busy waiting, as udelay does 10:09 < shimoda> about this mfis topic, bsp team don't want to make a single driver to support a hwspinlock and rpmsg, especially rpmsg. But, I'll forward this infor and discuss how do we do. Thanks! 10:09 < geertu> shimoda: Do you need any special properties in the hwspinlock and rpmsg nodes from your proposal? 10:09 < jmondi> I'm now testing it, just need to remove my workarounds in sensor driver code 10:10 < dammsan> shimoda: isn't hwspinlock vs rpmsg assignment software policy? 10:11 < shimoda> geertu: I don't need any special properties, I think. But, BSP team concern, M3-W and H3 ES1.x has only 8 locks, but other SoCs has 64 locks 10:11 < shimoda> s/BSP team concern/BSP team has concern/ 10:11 < geertu> That can be handled by the driver based on the renesas,mfis-<soctype> compatible value, right? 10:12 < geertu> (no, "renesas,<soctype>-mfis") 10:12 < shimoda> dammsan: I think so, BSP team wants hwspinlock to go to upstream, but rpmsg is no-go because this is related to undocumented 10:13 < jmondi> geertu: damsan: no more hangs... trying yout ETHER now... thank you both so far :) 10:13 < dammsan> i see. i think mfis has existed even on mobile platforms 10:13 < geertu> dammsan: Indeed, on all SoCs we still support, I think. 10:13 < dammsan> register layout in such case seemed similar to msiof but it was used for mailbox communication between cou coes 10:14 < dammsan> i mean cpu cores 10:14 < shimoda> geertu: i think so. but also need soc_device_match for H3 ES2.0 10:14 < dammsan> but anyway, good with hwspinlock 10:14 < geertu> We're running out of time. Anything else related to this topic? 10:14 < geertu> Simon: 10:14 < geertu> - Correct handling of PLL dividor for CPUFreq 10:15 < geertu> horms: Do you want to discuss this here? 10:15 < horms> I think I should do some more investigation. Perhaps we can chat about it on this channel some time? 10:16 < geertu> OK. 10:16 < dammsan> FYI, i'm adding a silk board for remote access now 10:16 < geertu> Anything I missed in the status reports? 10:16 * Marex steals a bit of time, OK? 10:17 < horms> dammsan: great, can you give me access if its not already oversubscribed? 10:17 < dammsan> sure 10:17 < dammsan> i'll announce the reshuffled boards via email, lets take it from there 10:17 < geertu> Marex: Core related? I should hand over the mic to Wolfram... 10:17 < Marex> shimoda: I sent out the xhci patch I plan to submit to the U-Boot list to the periperi list first, the license grant should be OK, can you double-check please ? 10:18 < Marex> geertu: well it's inbetween, U-Boot is core and xhci is IO 10:18 < shimoda> Marex: sure, I will check it 10:18 < Marex> shimoda: thank you ! 10:18 < Marex> shimoda: it'd be convenient if this worked out, since now I can just type "usb reset" and it works :) 10:19 < Marex> shimoda: it's hassle-free 10:19 < shimoda> Marex: nice! :) 10:20 < wsa_> geertu: don't worry, I am fine 10:20 < Marex> shimoda: btw re HS200/400 and SDR104, I am a bit blocked by the SD/MMC maintainer in U-Boot, sorry about that 10:20 < Marex> shimoda: he's not picking patches as fast as I'd like him to 10:20 < Marex> shimoda: I'm looking for ways to ... uh ... expedite that process 10:21 < shimoda> Marex: i got it. thanks! 10:21 < Marex> shimoda: you're welcome, I'll keep you updated 10:22 < wsa_> Marex: is yamada-san working on this, too? 10:22 < Marex> wsa_: Masahiro Yamada-san ? 10:22 < wsa_> hai 10:22 < Marex> wsa_: he works for socionext, although he did implement the uniphier-sd which I now use on RCar Gen3 10:22 * neg brb 2 min 10:22 < Marex> wsa_: their block doesn't support the HS200/400/SDR104 modes though, that's renesas specific 10:23 < Marex> wsa_: so he just reviews my uniphier-sd patches (which is nice) and makes sure they work on both 10:23 < wsa_> I see 10:24 < Marex> wsa_: the blocker really is the SD/MMC subsystem maintainer, he just doesn't respond much 10:24 < Marex> wsa_: some not long time ago I was really tempted to just replace him and start handling the SDMMC stuff myself 10:25 < Marex> wsa_: but then he came back, at like 5 mins to 12 and rolled out a PR ... 10:25 < wsa_> how about co-maintaining? 10:25 < Marex> wsa_: I feel like I'm hoarding functions ;-) 10:26 < wsa_> I see 10:26 < wsa_> that happens easily, yes 10:26 < Marex> wsa_: right 10:26 * neg back 10:26 < Marex> wsa_: and since U-Boot isn't as prestigeous as linux, maintainers don't really queue up to do it 10:27 < wsa_> okay 10:27 < Marex> wsa_: anyway ... maybe we should continue rather than complain about lack of manpower all over the place ? :) 10:27 < wsa_> ack