summaryrefslogtreecommitdiff
path: root/bsd
AgeCommit message (Collapse)Author
2002-09-23merged r200-0-2-branch to trunkKeith Whitwell
2002-08-30Remove some extra symlinking for kernel module building that hasn't beenEric Anholt
needed since 2000.
2002-08-30Remove this one too: it'll be used from the linux version (if ever)Eric Anholt
2002-08-28Remove i8x0 files from the BSD side. These were not actually ported, andEric Anholt
when they do get ported most of them won't live in these directories.
2002-08-27Remove drm_linux.h, it's no longer used.Eric Anholt
2002-08-27Include non-radeon modules in the build.Eric Anholt
2002-08-26merged r200-0-1-branchKeith Whitwell
2002-08-21Remove drm_linux.h, move the two useful defines into drm_drv.h (the onlyEric Anholt
place they're used). Use fd locking on -current. Actually copy in data from userspace to kernel in the linux-compat ioctl path. Make sure ioctl sizes are as expected in the ioctl handler functions.
2002-07-09Increase the linux-compatibility max ioctl.Eric Anholt
2002-07-06remove obsolete filesAlan Hourihane
2002-07-05remove files missed by mergeAlan Hourihane
2002-07-05merged bsd-3-0-0-branchAlan Hourihane
2002-04-09Merged drmcommand-0-0-1Jens Owen
2002-03-11fixups for *BSDAlan Hourihane
2002-03-08missing fileAlan Hourihane
2002-03-06fixup the radeon driver (not tested)Alan Hourihane
2002-03-06i830 & mga contain minor changes from 4.2.0 for mesa 4.0 bsd mergeAlan Hourihane
2002-03-06first pass at merging mesa 4.0 kernel drivers into new bsd-3-0-0 branch.Alan Hourihane
2002-01-27First pass merge of XFree86 4.2.0 import.David Dawes
2002-01-27Import of XFree86 4.2.0David Dawes
2002-01-27Initial revisionDavid Dawes
2001-05-01Initial merge for XFree86 4.0.99.3 importDavid Dawes
2001-04-10Use the linux version of xf86drm.c.David Dawes
2001-04-09First pass of XFree86 4.0.99.2 merge.David Dawes
2001-04-09Import -f XFree86 4.0.99.2David Dawes
2001-03-19Initial XFree86 4.0.99.1 merge.David Dawes
2000-11-08merge with 4.0.1dDavid Dawes
2000-09-24commit xfree86 4.0.1d-pre updateAlan Hourihane
2000-08-30Added planemask args for color and depthbuffer clears.Keith Whitwell
2000-07-10Import of XFree86 4.0.1Alan Hourihane
2000-06-13Merged bsd-1-0-1Doug Rabson
2000-05-30Merged bsd-1-0-0Doug Rabson
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-13 13:11:24 +0000
us of this large SCIF series? 11:16 < wsa_> needs ping? needs review? already upstream? 11:17 < shimoda> wsa_: about thermal driver, I heard bsp team is developing it. So, I will get information from them later 11:17 < geertu> SCIF DMA is in -next 11:17 < geertu> So it will be in v4.4 11:17 < wsa_> \o/ 11:18 < wsa_> didn't notice from the mails in linux-sh 11:18 < wsa_> so i can remove 11:18 < wsa_> SCIF,4.4,Upstream improved DMA support for R-Car Gen2 11:18 < wsa_> from the todo list 11:18 < wsa_> ? 11:19 < geertu> GregKH's bot didn't CC linux-sh 11:19 < geertu> Yes (assumed in -next == will be in v4.4) 11:19 < wsa_> shimoda: ok, will update the info about thermal driver 11:20 < wsa_> geertu: and you will be working on baudrate generators for 4.5, correct? 11:20 < geertu> that's correct 11:20 < geertu> I'm a bit delayed by the Gen3 CPG rework 11:21 < wsa_> I can imagine 11:22 < wsa_> geertu: anything else you are planned to work on IO wise? 11:22 < morimoto> I asked about SPI slave use case to BSP team 11:22 < wsa_> I have this baudrate generator and random SPI stuff in the list :) 11:23 < geertu> Yeah, I plan to test MSIOF on Gen3, if possible (read: available on EXIO) 11:23 < wsa_> same questions to the others 11:23 < wsa_> shimoda: I assume you will be busy doing USB stuff? 11:24 < wsa_> morimoto: any IO related task you have assigned? (except using I2C for sound ;)) 11:24 < morimoto> Ahh... no I/O I have 11:24 < wsa_> simon: I guess you'll work in improving EtherAVB support? 11:25 < shimoda> wsa_: yes, but bsp team needs USB stuff (expect USB2 host) until end of May 11:25 < shimoda> so, i have some space 11:25 < wsa_> oh, that sounds good 11:25 < morimoto> wsa_: About Thermal driver lacking docs, do you mean 10A.3.1.2 ? 11:25 < horms> EtherAVB is the only i/o related item i'm working on directly 11:25 < shimoda> however, sometimes I have a lot of paper works though :) 11:26 < wsa_> oh, that sounds not good 11:26 < wsa_> :) 11:27 < wsa_> horms: anything specific? I have only PTP support until End of November in the list 11:27 < horms> so my question for shimoda-san is about that 11:27 < horms> is now a good time? 11:28 < wsa_> morimoto: yes, and 10.A.3.1.4 11:30 < shimoda> horms: sorry I don't understand your question 11:30 < shimoda> you are talking about PTP support? 11:31 < horms> my quesion is as follows 11:32 < morimoto> wsa_: OK, according to datasheet team, about 10A.3.1.2, it depends on real measured data. 11:32 < morimoto> but, there is not such data at this point. So, it will be other explanation in next datasheet 11:32 < morimoto> if they still doesn't have it 11:33 < horms> I see some PTP support present in the ravb driver. It looks like it handles timestamps. Is that what is required for r8a7795 by mid-November? 11:33 < wsa_> morimoto: I assumed so. Anyhow, looks like BSP team took this over. They will probably have better access to such data 11:36 < shimoda> horms: thank you for the detail. I will ask bsp team about this 11:36 < horms> shimoda: thanks. if they want to explain things in patches that is fine by me :) 11:37 < wsa_> good 11:38 < wsa_> can we move to SDHI topic? 11:38 < horms> i think so 11:38 < shimoda> i think so 11:39 < wsa_> fine 11:39 < wsa_> It seems that BSP team also wants to do the initial support? 11:39 < wsa_> And then wants to work on DMA support? 11:40 < shimoda> I think they want to work on DMA support if possible 11:40 < wsa_> And they need some assistance from us how to do it 11:41 < shimoda> I think so 11:43 < wsa_> do they have patches for initial support already? 11:43 < shimoda> tmio driver is using dmaengine. but I don't know gen3 SDHI should use it or not 11:44 < shimoda> wsa_: for PIO, yes 11:44 < shimoda> let me check some repositories 11:47 < shimoda> in renesas-bsp.git, 91e3cc719def606e049861d4f9fc02bd90f126be, arm64: dts: salvator-x: Add sdhi-rcar support 11:48 < shimoda> 09a0662a2b6073bb2237b5d28a354a406b4b640b, arm64: dts: r8a7795: Add sdhi-rcar support 11:49 < wsa_> got them 11:50 < wsa_> and some more patches to look at 11:50 < shimoda> about driver side, they are submitted some local patches... 11:50 < horms> wsa_: btw renesas-bsp is on kernel.org 11:52 < wsa_> yes, that's good 11:53 < wsa_> well, the makefile from mmc/hosts says: 11:53 < wsa_> tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI)) += tmio_mmc_dma.o 11:53 < wsa_> so, the DMA module is only compiled in for SDHI? 11:54 < wsa_> ah, sure. the todo list only marks "DMA on Gen3" as a todo 11:55 < shimoda> wsa_: yes, on gen3, DMAC is internal in the SHDI device instead of SYS-DMAC 11:57 < wsa_> is this internal DMAC reused in other IP cores? 11:57 < wsa_> it doesn't look SDHI specific to me 11:58 < shimoda> I don't think this internal DMAC is reused 12:01 < wsa_> ok 12:02 < morimoto> About makefile, tmio_mmc_dma.o is used only from CONFIG_MMC_SDHI is correct 12:02 < morimoto> this is because historical reason 12:02 < morimoto> About Gen3 internal DMAC, this is Gen3 new feature 12:02 < morimoto> Gen3 DMAC != tmio_mmc_dma 12:02 < wsa_> I'd think a new file 'tmio_mmc_dma_gen3.c' or similar would be the way to go, but I need to double check 12:03 < wsa_> I can investigate 12:03 < wsa_> Is it "as soon as possible" or will next week be enough? 12:03 < morimoto> I think it is not "tmio", "sh_mobile_sdhi_dma" is better ? 12:04 < horms> can we rename tmio_mmc_dma while we are at it? 12:04 < wsa_> to? 12:04 < horms> I suspect it doesn't relate to tmio at all 12:04 < horms> but just to sdhi 12:05 < horms> i could be wrong 12:05 < wsa_> i will dig into that and post my findings on the list 12:05 < morimoto> unfortunately, not good idea 12:05 < morimoto> because tmio_mmc_pio calls tmio_mmc_dma function 12:06 < horms> ok 12:06 < morimoto> But, we can create new sub-framework for DMA? 12:06 < morimoto> real TMIO doesn't need DMA (?), we need 2type of DMA 12:07 < morimoto> and tmio_dma naming is not good match now ? 12:07 < horms> probably that will lead to a nice clean result 12:07 < horms> but is gen3 dma on the critical path? 12:08 < horms> If so it would be nice to arrange things so new frameworks come after hw support, imho 12:08 < wsa_> agreed 12:08 < shimoda> horms: on the critical path or not, let us ask BSP team tomorrow :) 12:09 < horms> good plan 12:09 < wsa_> anything more for SDHI? 12:09 < wsa_> otherwise let's move on to watchdog 12:11 < morimoto> ok 12:11 < wsa_> ok, my idea there is to implement the missing SET_TIMEOUT feature and repost as RFC 12:12 < wsa_> we can then test this one on Gen2/3 and see if it works with the reset controllers 12:12 < wsa_> (it obviously doesn't on r8a7790 ES1) 12:12 < wsa_> if all fails, I could try to add r7s72100 support and get at least the driver upstream vis this path 12:13 < wsa_> so we don't have to carry around this one 12:13 < wsa_> OK plan? 12:13 < shimoda> wsa_: if we use not SMP, watchdog should work even if r8a7790 ES1 12:14 < geertu> The watchdog is not limited to R-Car Gen2/3 and RZ 12:15 < wsa_> shimoda: Yes, then it works 12:15 < wsa_> I can confirm that 12:15 < geertu> it's also present on older SH-Mobile and R-Mobile 12:16 < wsa_> geertu: like with r7s or even another register layout? 12:17 < geertu> BTW, the issue with the syscon driver I mentined in "Re: [RFC 4/5] ARM: shmobile: r8a7790: let rst module allow watchdog resets if desired" (http://www.spinics.net/lists/linux-sh/msg39799.html) is gone 12:19 < wsa_> how come? 12:20 < geertu> At that time, you couldn't have both syscon and a regular driver bind to the same device node 12:20 < geertu> that has been fixed 12:20 < geertu> the APE6 RWDT looks the same as Gen2 12:21 < geertu> The RZ one is different 12:22 < geertu> A1/AG5 uses an 8-bit version of APE6/Gen2 12:22 < geertu> So there are 3 versions 12:23 < wsa_> ah, okay, so we still need the "syscon" property somewhen 12:23 < geertu> But "It's slightly more complicated there, as we already have a driver for the 12:23 < geertu> SYSC on R-Mobile (rmobile-reset), and a device node can't be bound 12:23 < geertu> by both the syscon and the rmobile-reset driver. 12:23 < geertu> " is no longer true 12:25 < geertu> From a chat with Magnus a long time ago: " 12:25 < geertu> Looking at datasheets, it seems the RWDT has a long history. 12:25 < geertu> R-Car Gen2: 32-bit registers, using RST 12:25 < geertu> R-Mobile APE6: 32-bit registers, using SYSC (APE6 has no RST block) 12:25 < geertu> SH-Mobile AP4/AG5, R-Mobile A1: 16-bit registers with 8-bit (instead of 16-bit) watchdog counter 12:25 < geertu> But the core is similar. 12:25 < geertu> And of course AP4 and A1 are single-core" 12:25 < geertu> RZ has a different control register layout 12:26 < wsa_> ok, i have datasheets for all of them 12:27 < wsa_> well, then, i'll do as I said before 12:27 < geertu> I can test A1/AG5/APE6 12:27 < wsa_> since there were no complaints ;) 12:27 < geertu> and M2 and H3, of course 12:27 < wsa_> geertu: \o/ 12:28 < wsa_> I ran out of topics 12:28 < shimoda> About H3, as I wrote periperi ML, we can not write RST 12:28 < shimoda> :) 12:28 < wsa_> :) 12:28 < wsa_> anything from your side left? 12:30 < morimoto> nope 12:30 < geertu> nope 12:30 < horms> not here either 12:31 < shimoda> no 12:31 < wsa_> then we are done 12:31 < wsa_> \o/ 12:31 < wsa_> thanks all! 12:31 < horms> thanks! 12:31 < morimoto> thanks 12:31 < shimoda> thank you! 12:31 < wsa_> have a great rest of the day 12:31 < geertu> thx, cu 12:31 < geertu> bye 12:31 < shimoda> bye! --- Log closed Thu Oct 15 12:34:05 2015
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-13 13:11:24 +0000