re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm
>> Defer i915drm_attach_framebuffer until interrupts are running. >> >> The i915 code initialization relies on counting hardclock ticks for a >> delay (ugh). >> >> Not an issue for modules, but it will matter when we build drm2 into >> the kernel proper. > >not sure why this is a problem generally. there have been >defer for interrupts primatives in our kernel for almost >2 deacdes now. > > Yes, that is exactly what I used: > > - i915drm_attach_framebuffer(self); > + /* Attach a framebuffer, but not until interrupts work. */ > + config_interrupts(self, &i915drm_attach_framebuffer); > > What is the problem you're referring to? i mean your comment about builtin driver. ah, i see. you've fixed the problem, now. good :-)
Re: CVS commit: [riastradh-drm2] src/sys
Date: Thu, 30 Jan 2014 15:29:31 +1100 from: matthew green > The drm2 `drm' device is now called `drmkms' (likewise `i915drmkms', > &c.) so that it can coexist with the old drm code to reduce diffs > from HEAD. (Can't call a device `drm2'.) there's probably a way to do this -- see how the current drm code used to co-exist with the previous drm code (from sys/dev/drm). you couldn't build them into the same kernel, but they were able to share the name 'drm' and the major number. Good point. I didn't realize that the device-major names are totally unrelated to the autoconf names. I don't think there's any harm in calling the new autoconf device drmkmsN, though, which will help to distinguish it from the old regime, both in the config files and in dmesg output. I will shortly commit some changes to reuse the drm major number and get rid of the drmkms one. I think while I'm shuffling this around I'd also like to take the opportunity to split off the PCI support properly to make it easier to bring in non-PCI drivers (e.g., omap or exynos).
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm
Date: Thu, 30 Jan 2014 15:28:00 +1100 from: matthew green > Defer i915drm_attach_framebuffer until interrupts are running. > > The i915 code initialization relies on counting hardclock ticks for a > delay (ugh). > > Not an issue for modules, but it will matter when we build drm2 into > the kernel proper. not sure why this is a problem generally. there have been defer for interrupts primatives in our kernel for almost 2 deacdes now. Yes, that is exactly what I used: - i915drm_attach_framebuffer(self); + /* Attach a framebuffer, but not until interrupts work. */ + config_interrupts(self, &i915drm_attach_framebuffer); What is the problem you're referring to?
re: CVS commit: [riastradh-drm2] src/sys
> Module Name: src > Committed By: riastradh > Date: Wed Jan 29 19:47:38 UTC 2014 > > Modified Files: > src/sys/conf [riastradh-drm2]: files > src/sys/dev/pci [riastradh-drm2]: files.pci > src/sys/dev/wsfb [riastradh-drm2]: files.wsfb > src/sys/external/bsd/drm2/conf [riastradh-drm2]: files.drm2 > src/sys/external/bsd/drm2/drm [riastradh-drm2]: drm_drv.c drm_module.c > drm_vm.c > src/sys/external/bsd/drm2/i915drm [riastradh-drm2]: i915_module.c > i915_pci.c > src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: kgdb.h > src/sys/modules/drm2 [riastradh-drm2]: Makefile drm.ioconf > src/sys/modules/i915drm2 [riastradh-drm2]: Makefile i915drm.ioconf > > Log Message: > First draft of in-kernel drm2 attachment. > > The drm2 `drm' device is now called `drmkms' (likewise `i915drmkms', > &c.) so that it can coexist with the old drm code to reduce diffs > from HEAD. (Can't call a device `drm2'.) there's probably a way to do this -- see how the current drm code used to co-exist with the previous drm code (from sys/dev/drm). you couldn't build them into the same kernel, but they were able to share the name 'drm' and the major number. .mrg.
re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/i915drm
> Module Name: src > Committed By: riastradh > Date: Wed Jan 29 19:47:09 UTC 2014 > > Modified Files: > src/sys/external/bsd/drm2/i915drm [riastradh-drm2]: i915_pci.c > > Log Message: > Defer i915drm_attach_framebuffer until interrupts are running. > > The i915 code initialization relies on counting hardclock ticks for a > delay (ugh). > > Not an issue for modules, but it will matter when we build drm2 into > the kernel proper. not sure why this is a problem generally. there have been defer for interrupts primatives in our kernel for almost 2 deacdes now. .mrg.
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
On Wed, 24 Jul 2013, Taylor R Campbell wrote:
Modified Files:
src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: kernel.h
Log Message:
Implement bogus max_t in .
+/* XXX These will multiply evaluate their arguments. */
+#definemax_t(T, X, Y) MAX(X, Y)
#define min_t(T, X, Y) MIN(X, Y)
If we are willing to use the non-standard ({ ... }) syntax, then
these can be written to evaluate their arguments only once, like
this:
#define max_t(T, X, Y) ({ T _x = (X), _y = (Y); (_x > _y ? _x : _y); })
#define min_t(T, X, Y) ({ T _x = (X), _y = (Y); (_x < _y ? _x : _y); })
--apb (Alan Barrett)
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/dist/drm/i915
On Wed, 24 Jul 2013, Taylor R Campbell wrote:
Modified Files:
src/sys/external/bsd/drm2/dist/drm/i915 [riastradh-drm2]: intel_dp.c
Log Message:
Avoid {0} struct initializer in intel_dp_init_connector.
The usual way we deal with this in NetBSD is to write
typename varname = {.membername = 0};
where membername is any valid member of the struct.
I wish gcc -Wmissing-field-initializers would recognise that {0} is
a special case that does nto deserve a warning, so we could write the
natural and well-defined code
typename varname = {0};
--apb (Alan Barrett)
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/dist/drm/i915
Date: Wed, 24 Jul 2013 08:48:29 +0100 From: David Laight On Wed, Jul 24, 2013 at 03:47:07AM +, Taylor R Campbell wrote: > Kludge around max as a local variable in intel_panel.c. Possibly adding a #define for max/min before/after including the netbsd header that defines these as a function/define would solve this in the wrapper headers? I'd be worried about identifying all cases of this everywhere the header file gets included. Another way would be to use -Wno-shadow for this file (and the others). I'll deal with this better when I do a pass over the external code to remove needless provisional #ifdefs (of which there are far too many already, oops).
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
Date: Wed, 24 Jul 2013 07:34:25 +0100 From: Nick Hudson Can't we please put these compat stubs somewhere common, e.g. sys/external/bsd/compat/linux No objection here (although I think we should probably add a new top-level sys directory, say sys/shims or something, for other-OS source compatibility shims). I'd like to keep my work mostly under sys/external/bsd/drm2 for now until the branch gets merged, though. Also, some of this stuff is specific to drm2 (e.g., ), and much of it I plan to eliminate in favour of drm-flavoured shims (e.g., drm_waitqueue), so we need to go through it piece by piece to decide whether it's actually appropriate for general purposes.
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
Date: Wed, 24 Jul 2013 08:05:11 +0100 From: David Laight On Wed, Jul 24, 2013 at 02:12:29AM +, Taylor R Campbell wrote: > Add __le16, __le32, and __le64 to . > > As far as I'm aware, these aliases are correct, and the type doesn't > actually have any effect on the byte order of reads and writes. Correct - they are for the static analysis tools. OK, thanks!
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
On Wed, 24 Jul 2013, Taylor R Campbell wrote: Module Name:src Committed By: riastradh Date: Wed Jul 24 01:54:19 UTC 2013 Modified Files: src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: types.h Log Message: Define cycles_t to be unsigned long long for now in . Could we use a fixed-size type? Perhaps uint64_t? If this type is never exposed to userland then it doesn't matter, but if it is exposed to userland then a fixed-size type makes it easier to provide compatibility between 32-bit and 64-bit versions of related platforms. i386 and amd64 both have 64-bit long long, so it doesn't affect them, but other pairs of related platforms (perhaps in the future) might be different. --apb (Alan Barrett)
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/dist/drm/i915
On Wed, Jul 24, 2013 at 03:47:07AM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Wed Jul 24 03:47:07 UTC 2013 > > Modified Files: > src/sys/external/bsd/drm2/dist/drm/i915 [riastradh-drm2]: intel_panel.c > > Log Message: > Kludge around max as a local variable in intel_panel.c. Possibly adding a #define for max/min before/after including the netbsd header that defines these as a function/define would solve this in the wrapper headers? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
On Wed, Jul 24, 2013 at 02:12:29AM +, Taylor R Campbell wrote: > Module Name: src > Committed By: riastradh > Date: Wed Jul 24 02:12:29 UTC 2013 > > Modified Files: > src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: types.h > > Log Message: > Add __le16, __le32, and __le64 to . > > As far as I'm aware, these aliases are correct, and the type doesn't > actually have any effect on the byte order of reads and writes. Correct - they are for the static analysis tools. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: [riastradh-drm2] src/sys/external/bsd/drm2/include/linux
On 07/24/13 01:49, Taylor R Campbell wrote: Module Name:src Committed By: riastradh Date: Wed Jul 24 00:49:48 UTC 2013 Modified Files: src/sys/external/bsd/drm2/include/linux [riastradh-drm2]: list.h Log Message: Add initial draft of Linux list and hlist to . Implemented in terms of TAILQ and LIST, respectively. Not yet tested. Can't we please put these compat stubs somewhere common, e.g. sys/external/bsd/compat/linux ?
