renesas/drm.git - libdrm, cloned from git://anongit.freedesktop.org/mesa/drm

diff options

author	Max Lingua <sunmax@users.sourceforge.net>	2002-06-25 11:20:36 +0000
committer	Max Lingua <sunmax@users.sourceforge.net>	2002-06-25 11:20:36 +0000
commit	688082d6564644f2f64a44105c872cc57476a1f6 (patch)
tree	23486f5a816719f72e227d378f20d4eec4e16592 /bsd/r128/Makefile
parent	978136f2f4dd12d1828ab41db5343ce5fccd52a9 (diff)

file s3v_drv.h was initially added on branch s3virge-0-0-1-branch.

Diffstat (limited to 'bsd/r128/Makefile')

0 files changed, 0 insertions, 0 deletions

Core-chat-meeting-2017-10-05 09:48 < geertu> Welcome to today's core group meeting. 09:48 < kbingham> and various people leave the room :D 09:48 * pinchartl has to go for one hour 09:48 * kbingham hides 09:48 < geertu> Given the small amount of time left, OK if I just summarize the copy-and-paste received status reports? 09:49 < geertu> A) What have I done since last time: 09:49 < geertu> 09:49 < geertu> Geert: 09:49 < geertu> - Sent patch to fix new unwind warnings with CONFIG_DEBUG_LOCK_ALLOC=y, 09:49 < geertu> - Sent v1 of sh-pfc suspend/resume, 09:49 < geertu> - Sent first pull requests for clk and pfc for v4.15, 09:49 < geertu> Jacopo: 09:49 < geertu> - Some small patches for Gr-Peach 09:49 < geertu> Marek (U-Boot): 09:49 < geertu> - Got more patches applied to u-boot-sh/rmobile, PR pending 09:49 < geertu> http://git.denx.de/?p=u-boot/u-boot-sh.git;a=shortlog;h=refs/heads/rmobile 09:49 < geertu> - Worked on the SDIF SDR104/HS200 support based on out-of-tree 09:49 < geertu> patchset (for now): 09:49 < geertu> - added support for the SDR104/HS200 calibration to the uniphier-sd 09:49 < geertu> driver 09:49 < geertu> - added support for pin voltage switching to PFC driver (POCCTRL) 09:49 < geertu> - added proper regulator handling to uniphier-sd 09:49 < geertu> - Worked on HS400, but that's still not ready 09:49 < geertu> Morimoto: 09:49 < geertu> - V3M/D3 shipping paper work 09:49 < geertu> Shimoda: 09:49 < geertu> - Submitted the following patches: 09:49 < geertu> * Add PWM entries of PFC for r8a77995. 09:49 < geertu> * Add USB3.0 entries of PFC for r8a7795{-es1} and merged. 09:49 < geertu> * Fix avb_pins for salvator-common, ulcb and draak. 09:49 < geertu> Remarks: "*" means merged into the subsystem repo. 09:49 < geertu> - I obtained a R-Car M3-N SiP, but I don't got bootloader yet. 09:49 < geertu> Simon: 09:49 < geertu> - Continued addressing review of CPUFreq patches 09:50 < geertu> B) What I plan to do till next time 09:50 < geertu> Geert: 09:50 < geertu> - v3 of cpg-mssr suspend/resume, 09:50 < geertu> - Fix genpd for wake-up devices. 09:50 < geertu> Marek (U-Boot): 09:50 < geertu> - Finish HS400 support 09:50 < geertu> - Finish sorting up remaining PCIe patches from the BSP (mostly 09:50 < geertu> suspend/resume support) 09:50 < geertu> Morimoto: 09:50 < geertu> - continue V3M/D3 paper work 09:50 < geertu> Niklas: 09:50 < geertu> - Send v2 of 'rcar_gen3_thermal: fix initialization sequence for H3 ES2.0' 09:50 < geertu> Shimoda: 09:50 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi after the usb3 peri 09:50 < geertu> supported a generic phy. 09:50 < geertu> - Prepare M3-N Salvator-X board for remote access if I obtain the 09:50 < geertu> bootloader. 09:50 < geertu> Simon: 09:50 < geertu> - Finalise addressing review of CPUFreq patches and repost 09:50 < geertu> C) Problems I have currently 09:50 < geertu> [Here I'll add breaks, in case people want to discuss] 09:51 < geertu> Jacopo: 09:51 < geertu> - Not really an issue to discuss with the whole group, but I keep seeing 09:51 < geertu> the GR-Peach hanging on sleeps longer than 1ms. I suspect this is also 09:51 < geertu> why ETHER is not working, and I had to substitute all sleep functions in 09:51 < geertu> the image sensor driver I am currently using to develop CEU with for 09:51 < geertu> loops of udelay(10). I blame XIP for this, but I'm currently not sure. 09:51 < geertu> Suggestions on how to debug and prove this are welcome :) 09:51 < geertu> jacopo: ? 09:51 < dammsan> use migo-r =) 09:51 < geertu> Does it work on Genmai? 09:51 < dammsan> (i don't dislike gr-peach support though) 09:52 < jmondi> geertu: here I am 09:52 < jmondi> never seen anything like this on genmai 09:52 < jmondi> but seems like sleeps longer than 1ms hang the board 09:53 < dammsan> which timer do you use? 09:53 < geertu> Peach doesn't have rtc_x1_clk in the DTS? 09:53 < jmondi> dammsan: as system clock? 09:53 < jmondi> geertu: no, no RTC 09:54 < geertu> The dmesg should tell you (compare genmai and peach) 09:54 < jmondi> not just in dts, not RTC at all on the board 09:54 < dammsan> rtc != clockevent != clocksource 09:55 < wsa_> marex-cloud: the PCIE patches you mentioned, are these for U-Boot or Linux? 09:55 < jmondi> let me look through dmesg 09:55 < dammsan> a single clockevent used to be enough to run the kernel 09:55 < Marex> wsa_: Linux, mostly suspend support 09:55 < dammsan> but the twd on CA9 used to exist only in case of multi-core 09:55 < dammsan> so instead of local timer i'm not sure what is used 09:56 < geertu> rskrza1 and genmai enable mtu2, peach doesn't 09:56 < dammsan> there you go 09:56 < wsa_> Marex: nice! did you send out patches already? I don't see any on the renesas-soc list. 09:56 < Marex> wsa_: I have them rebased to -next since a few days ago, I need to understand what some of them are doing 09:56 < geertu> rskrza1 enables ostm[01], peach and genmai don't 09:56 < wsa_> Marex: I can imagine :) 09:57 < geertu> Ok, issue assumed fixed until proven otherwise soon :-) 09:57 < Marex> wsa_: there's one which digs in the PCIe core , but not much details in the commit message 09:57 < geertu> Marek: 09:57 < geertu> - HS400 calibration doesn't pass on Salvator-XS for me in U-Boot, 09:57 < geertu> but that's because I'm doing something wrong, it works in Linux 09:57 < jmondi> geertu: dammsan: I lost you two 09:57 < jmondi> I'm so ignorant on this 09:57 < geertu> Marex: if you want to discuss this, I think I/O is more appropriate 09:58 < dammsan> jmondi: your timer configuration on 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)


context:
space:
mode: