Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Tapani Pälli writes: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? pgpTalPsk5vn8.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani Pälli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ This series looks good to me. Before committing, though, I'd like to see either an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers. -Chad ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/10/2012 08:05 PM, Chad Versace wrote: > On 10/07/2012 10:50 PM, Tapani Pälli wrote: >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) >> >> Haitao Huang (1): >> Android.mk: use LOCAL_COPY_HEADERS to export headers. >> >> Android.mk| 62 >> +++ >> Makefile.am | 9 >> intel/Android.mk | 57 ++ >> intel/Makefile.am | 9 >> intel/sources.mk | 30 +++ >> sources.mk| 30 +++ > > This series looks good to me. Before committing, though, I'd like to see > either > an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > committers. Thanks for checking it out. I've tried out androgenizer as Eric suggested but not really convinced we would like to start using it. > -Chad > -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: > On 10/10/2012 08:05 PM, Chad Versace wrote: >> On 10/07/2012 10:50 PM, Tapani Pälli wrote: >>> Upstreaming old set of patches here to enable Android support in libdrm. >>> Some little rebasing was required for the first one. >>> >>> Chad Versace (2): >>> libdrm,intel: Factor source file lists into sources.mk >>> libdrm,intel: Add Android makefiles (v2) >>> >>> Haitao Huang (1): >>> Android.mk: use LOCAL_COPY_HEADERS to export headers. >>> >>> Android.mk| 62 >>> +++ >>> Makefile.am | 9 >>> intel/Android.mk | 57 ++ >>> intel/Makefile.am | 9 >>> intel/sources.mk | 30 +++ >>> sources.mk| 30 +++ >> >> This series looks good to me. Before committing, though, I'd like to see >> either >> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >> committers. > > Thanks for checking it out. I've tried out androgenizer as Eric > suggested but not really convinced we would like to start using it. To bring an pro-argument for Tapani, this is how it looks to make it work with androgenizer. As you can see, it's not much different from the Android.mk itself, only the variable names changes. diff --git a/Makefile.am b/Makefile.am index 273abf9..b200509 100644 --- a/Makefile.am +++ b/Makefile.am @@ -77,3 +77,23 @@ copy-headers : commit-headers : copy-headers git add include git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.gi + +Android.mk: Makefile.am + androgenizer \ + -:PROJECT testlib \ + -:REL_TOP $(top_srcdir) \ + -:ABS_TOP $(abs_top_srcdir) \ + -:SHARED libdrm \ + -:SOURCES $(LIBDRM_SOURCES) \ + -:LDFLAGS $(libdrm_la_LDFLAGS) \ + -:CPPFLAGS $(libdrm_la_CPPFLAGS) \ + -:TAGS optional\ + -:HEADERS xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h\ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + -:HEADER_TARGET libdrm \ + > $@ -- Regards! http://groleo.wordpress.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Negreanu Marius writes: > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: >> On 10/10/2012 08:05 PM, Chad Versace wrote: >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Haitao Huang (1): Android.mk: use LOCAL_COPY_HEADERS to export headers. Android.mk| 62 +++ Makefile.am | 9 intel/Android.mk | 57 ++ intel/Makefile.am | 9 intel/sources.mk | 30 +++ sources.mk| 30 +++ >>> >>> This series looks good to me. Before committing, though, I'd like to see >>> either >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >>> committers. >> >> Thanks for checking it out. I've tried out androgenizer as Eric >> suggested but not really convinced we would like to start using it. > > To bring an pro-argument for Tapani, this is how it looks to make it > work with androgenizer. > As you can see, it's not much different from the Android.mk itself, > only the variable names changes. If this is all there is to using androgenizer, I suspect it will stay working for longer than the custom Android.mks. Our experience in Mesa has been that basically any time anybody touches the build system for anything but a file addition, android gets broken. By using androgenizer, hopefully we rely on a tool that reflects the upstream build system better in android, and maybe over time that tool can be improved so that android building of upstream projects is less of a burden (seriously, why should you have to manually name the sources and flags variables?). That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable result in complaints from automake? pgp09Q2wEuW9o.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 > ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ > >>> > >>> This series looks good to me. Before committing, though, I'd like to see > >>> either > >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > >>> committers. > >> > >> Thanks for checking it out. I've tried out androgenizer as Eric > >> suggested but not really convinced we would like to start using it. > > > > To bring an pro-argument for Tapani, this is how it looks to make it > > work with androgenizer. > > As you can see, it's not much different from the Android.mk itself, > > only the variable names changes. > > If this is all there is to using androgenizer, I suspect it will stay > working for longer than the custom Android.mks. Our experience in Mesa > has been that basically any time anybody touches the build system for > anything but a file addition, android gets broken. By using > androgenizer, hopefully we rely on a tool that reflects the upstream > build system better in android, and maybe over time that tool can be > improved so that android building of upstream projects is less of a > burden (seriously, why should you have to manually name the sources and > flags variables?). Some of the benefits of androgenizer are, that it filters the contents of the automake variables you pass to it, so you don't have to manually write only slightly different things in Android-specific files. As you saw, some Android specific code is still needed in the build system: - to pass the automake variables to androgenizer, which cannot parse automake files itself. This way we let GNU Make parse the automake files, and androgenizer gets the final values. - a top-level hand-written Android.mk that will execute ./configure and everything related, and cause the androgenizer-generated Android.mk files to be created. We have managed to create such makefiles, that these steps get executed automatically as needed during the full Android system build. Whenever new makefiles are being generated, GNU Make notices that, and automatically restarts the whole build to read them in. (This is not about androgenizer but Android builds in general.) Androgenizer also fixes up all the file paths to be relative to the Android build root dir, so you don't have to mess with generating file lists with different path prefixes for automake vs. Android builds. Or at least that is what androgenizer should do, it may have bugs of course. Androgenizer is no magic tool that automatically makes an autotools project building for Android, but it should help with the most common pains. I have some patches in Androgenizer, and I have androgenized few projects for Collabora. I'd be happy to answer questions about androgenizer. Please, use my work email (cc'd): ppaala...@gmail.com Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Tapani Pälli writes: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? pgpTalPsk5vn8.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani Pälli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ This series looks good to me. Before committing, though, I'd like to see either an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers. -Chad ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/10/2012 08:05 PM, Chad Versace wrote: > On 10/07/2012 10:50 PM, Tapani Pälli wrote: >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) >> >> Haitao Huang (1): >> Android.mk: use LOCAL_COPY_HEADERS to export headers. >> >> Android.mk| 62 >> +++ >> Makefile.am | 9 >> intel/Android.mk | 57 ++ >> intel/Makefile.am | 9 >> intel/sources.mk | 30 +++ >> sources.mk| 30 +++ > > This series looks good to me. Before committing, though, I'd like to see > either > an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > committers. Thanks for checking it out. I've tried out androgenizer as Eric suggested but not really convinced we would like to start using it. > -Chad > -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: > On 10/10/2012 08:05 PM, Chad Versace wrote: >> On 10/07/2012 10:50 PM, Tapani Pälli wrote: >>> Upstreaming old set of patches here to enable Android support in libdrm. >>> Some little rebasing was required for the first one. >>> >>> Chad Versace (2): >>> libdrm,intel: Factor source file lists into sources.mk >>> libdrm,intel: Add Android makefiles (v2) >>> >>> Haitao Huang (1): >>> Android.mk: use LOCAL_COPY_HEADERS to export headers. >>> >>> Android.mk| 62 >>> +++ >>> Makefile.am | 9 >>> intel/Android.mk | 57 ++ >>> intel/Makefile.am | 9 >>> intel/sources.mk | 30 +++ >>> sources.mk| 30 +++ >> >> This series looks good to me. Before committing, though, I'd like to see >> either >> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >> committers. > > Thanks for checking it out. I've tried out androgenizer as Eric > suggested but not really convinced we would like to start using it. To bring an pro-argument for Tapani, this is how it looks to make it work with androgenizer. As you can see, it's not much different from the Android.mk itself, only the variable names changes. diff --git a/Makefile.am b/Makefile.am index 273abf9..b200509 100644 --- a/Makefile.am +++ b/Makefile.am @@ -77,3 +77,23 @@ copy-headers : commit-headers : copy-headers git add include git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.gi + +Android.mk: Makefile.am + androgenizer \ + -:PROJECT testlib \ + -:REL_TOP $(top_srcdir) \ + -:ABS_TOP $(abs_top_srcdir) \ + -:SHARED libdrm \ + -:SOURCES $(LIBDRM_SOURCES) \ + -:LDFLAGS $(libdrm_la_LDFLAGS) \ + -:CPPFLAGS $(libdrm_la_CPPFLAGS) \ + -:TAGS optional\ + -:HEADERS xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h\ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + -:HEADER_TARGET libdrm \ + > $@ -- Regards! http://groleo.wordpress.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Negreanu Marius writes: > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: >> On 10/10/2012 08:05 PM, Chad Versace wrote: >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Haitao Huang (1): Android.mk: use LOCAL_COPY_HEADERS to export headers. Android.mk| 62 +++ Makefile.am | 9 intel/Android.mk | 57 ++ intel/Makefile.am | 9 intel/sources.mk | 30 +++ sources.mk| 30 +++ >>> >>> This series looks good to me. Before committing, though, I'd like to see >>> either >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >>> committers. >> >> Thanks for checking it out. I've tried out androgenizer as Eric >> suggested but not really convinced we would like to start using it. > > To bring an pro-argument for Tapani, this is how it looks to make it > work with androgenizer. > As you can see, it's not much different from the Android.mk itself, > only the variable names changes. If this is all there is to using androgenizer, I suspect it will stay working for longer than the custom Android.mks. Our experience in Mesa has been that basically any time anybody touches the build system for anything but a file addition, android gets broken. By using androgenizer, hopefully we rely on a tool that reflects the upstream build system better in android, and maybe over time that tool can be improved so that android building of upstream projects is less of a burden (seriously, why should you have to manually name the sources and flags variables?). That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable result in complaints from automake? pgp09Q2wEuW9o.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 > ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ > >>> > >>> This series looks good to me. Before committing, though, I'd like to see > >>> either > >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > >>> committers. > >> > >> Thanks for checking it out. I've tried out androgenizer as Eric > >> suggested but not really convinced we would like to start using it. > > > > To bring an pro-argument for Tapani, this is how it looks to make it > > work with androgenizer. > > As you can see, it's not much different from the Android.mk itself, > > only the variable names changes. > > If this is all there is to using androgenizer, I suspect it will stay > working for longer than the custom Android.mks. Our experience in Mesa > has been that basically any time anybody touches the build system for > anything but a file addition, android gets broken. By using > androgenizer, hopefully we rely on a tool that reflects the upstream > build system better in android, and maybe over time that tool can be > improved so that android building of upstream projects is less of a > burden (seriously, why should you have to manually name the sources and > flags variables?). Some of the benefits of androgenizer are, that it filters the contents of the automake variables you pass to it, so you don't have to manually write only slightly different things in Android-specific files. As you saw, some Android specific code is still needed in the build system: - to pass the automake variables to androgenizer, which cannot parse automake files itself. This way we let GNU Make parse the automake files, and androgenizer gets the final values. - a top-level hand-written Android.mk that will execute ./configure and everything related, and cause the androgenizer-generated Android.mk files to be created. We have managed to create such makefiles, that these steps get executed automatically as needed during the full Android system build. Whenever new makefiles are being generated, GNU Make notices that, and automatically restarts the whole build to read them in. (This is not about androgenizer but Android builds in general.) Androgenizer also fixes up all the file paths to be relative to the Android build root dir, so you don't have to mess with generating file lists with different path prefixes for automake vs. Android builds. Or at least that is what androgenizer should do, it may have bugs of course. Androgenizer is no magic tool that automatically makes an autotools project building for Android, but it should help with the most common pains. I have some patches in Androgenizer, and I have androgenized few projects for Collabora. I'd be happy to answer questions about androgenizer. Please, use my work email (cc'd): ppaala...@gmail.com Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Tapani Pälli writes: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? pgpTalPsk5vn8.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani Pälli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ This series looks good to me. Before committing, though, I'd like to see either an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers. -Chad ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/10/2012 08:05 PM, Chad Versace wrote: > On 10/07/2012 10:50 PM, Tapani Pälli wrote: >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) >> >> Haitao Huang (1): >> Android.mk: use LOCAL_COPY_HEADERS to export headers. >> >> Android.mk| 62 >> +++ >> Makefile.am | 9 >> intel/Android.mk | 57 ++ >> intel/Makefile.am | 9 >> intel/sources.mk | 30 +++ >> sources.mk| 30 +++ > > This series looks good to me. Before committing, though, I'd like to see > either > an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > committers. Thanks for checking it out. I've tried out androgenizer as Eric suggested but not really convinced we would like to start using it. > -Chad > -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: > On 10/10/2012 08:05 PM, Chad Versace wrote: >> On 10/07/2012 10:50 PM, Tapani Pälli wrote: >>> Upstreaming old set of patches here to enable Android support in libdrm. >>> Some little rebasing was required for the first one. >>> >>> Chad Versace (2): >>> libdrm,intel: Factor source file lists into sources.mk >>> libdrm,intel: Add Android makefiles (v2) >>> >>> Haitao Huang (1): >>> Android.mk: use LOCAL_COPY_HEADERS to export headers. >>> >>> Android.mk| 62 >>> +++ >>> Makefile.am | 9 >>> intel/Android.mk | 57 ++ >>> intel/Makefile.am | 9 >>> intel/sources.mk | 30 +++ >>> sources.mk| 30 +++ >> >> This series looks good to me. Before committing, though, I'd like to see >> either >> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >> committers. > > Thanks for checking it out. I've tried out androgenizer as Eric > suggested but not really convinced we would like to start using it. To bring an pro-argument for Tapani, this is how it looks to make it work with androgenizer. As you can see, it's not much different from the Android.mk itself, only the variable names changes. diff --git a/Makefile.am b/Makefile.am index 273abf9..b200509 100644 --- a/Makefile.am +++ b/Makefile.am @@ -77,3 +77,23 @@ copy-headers : commit-headers : copy-headers git add include git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.gi + +Android.mk: Makefile.am + androgenizer \ + -:PROJECT testlib \ + -:REL_TOP $(top_srcdir) \ + -:ABS_TOP $(abs_top_srcdir) \ + -:SHARED libdrm \ + -:SOURCES $(LIBDRM_SOURCES) \ + -:LDFLAGS $(libdrm_la_LDFLAGS) \ + -:CPPFLAGS $(libdrm_la_CPPFLAGS) \ + -:TAGS optional\ + -:HEADERS xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h\ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + -:HEADER_TARGET libdrm \ + > $@ -- Regards! http://groleo.wordpress.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Negreanu Marius writes: > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: >> On 10/10/2012 08:05 PM, Chad Versace wrote: >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Haitao Huang (1): Android.mk: use LOCAL_COPY_HEADERS to export headers. Android.mk| 62 +++ Makefile.am | 9 intel/Android.mk | 57 ++ intel/Makefile.am | 9 intel/sources.mk | 30 +++ sources.mk| 30 +++ >>> >>> This series looks good to me. Before committing, though, I'd like to see >>> either >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >>> committers. >> >> Thanks for checking it out. I've tried out androgenizer as Eric >> suggested but not really convinced we would like to start using it. > > To bring an pro-argument for Tapani, this is how it looks to make it > work with androgenizer. > As you can see, it's not much different from the Android.mk itself, > only the variable names changes. If this is all there is to using androgenizer, I suspect it will stay working for longer than the custom Android.mks. Our experience in Mesa has been that basically any time anybody touches the build system for anything but a file addition, android gets broken. By using androgenizer, hopefully we rely on a tool that reflects the upstream build system better in android, and maybe over time that tool can be improved so that android building of upstream projects is less of a burden (seriously, why should you have to manually name the sources and flags variables?). That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable result in complaints from automake? pgp09Q2wEuW9o.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 > ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ > >>> > >>> This series looks good to me. Before committing, though, I'd like to see > >>> either > >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > >>> committers. > >> > >> Thanks for checking it out. I've tried out androgenizer as Eric > >> suggested but not really convinced we would like to start using it. > > > > To bring an pro-argument for Tapani, this is how it looks to make it > > work with androgenizer. > > As you can see, it's not much different from the Android.mk itself, > > only the variable names changes. > > If this is all there is to using androgenizer, I suspect it will stay > working for longer than the custom Android.mks. Our experience in Mesa > has been that basically any time anybody touches the build system for > anything but a file addition, android gets broken. By using > androgenizer, hopefully we rely on a tool that reflects the upstream > build system better in android, and maybe over time that tool can be > improved so that android building of upstream projects is less of a > burden (seriously, why should you have to manually name the sources and > flags variables?). Some of the benefits of androgenizer are, that it filters the contents of the automake variables you pass to it, so you don't have to manually write only slightly different things in Android-specific files. As you saw, some Android specific code is still needed in the build system: - to pass the automake variables to androgenizer, which cannot parse automake files itself. This way we let GNU Make parse the automake files, and androgenizer gets the final values. - a top-level hand-written Android.mk that will execute ./configure and everything related, and cause the androgenizer-generated Android.mk files to be created. We have managed to create such makefiles, that these steps get executed automatically as needed during the full Android system build. Whenever new makefiles are being generated, GNU Make notices that, and automatically restarts the whole build to read them in. (This is not about androgenizer but Android builds in general.) Androgenizer also fixes up all the file paths to be relative to the Android build root dir, so you don't have to mess with generating file lists with different path prefixes for automake vs. Android builds. Or at least that is what androgenizer should do, it may have bugs of course. Androgenizer is no magic tool that automatically makes an autotools project building for Android, but it should help with the most common pains. I have some patches in Androgenizer, and I have androgenized few projects for Collabora. I'd be happy to answer questions about androgenizer. Please, use my work email (cc'd): ppaala...@gmail.com Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Tapani Pälli writes: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? pgpTalPsk5vn8.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani Pälli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ This series looks good to me. Before committing, though, I'd like to see either an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers. -Chad ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/10/2012 08:05 PM, Chad Versace wrote: > On 10/07/2012 10:50 PM, Tapani Pälli wrote: >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) >> >> Haitao Huang (1): >> Android.mk: use LOCAL_COPY_HEADERS to export headers. >> >> Android.mk| 62 >> +++ >> Makefile.am | 9 >> intel/Android.mk | 57 ++ >> intel/Makefile.am | 9 >> intel/sources.mk | 30 +++ >> sources.mk| 30 +++ > > This series looks good to me. Before committing, though, I'd like to see > either > an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > committers. Thanks for checking it out. I've tried out androgenizer as Eric suggested but not really convinced we would like to start using it. > -Chad > -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: > On 10/10/2012 08:05 PM, Chad Versace wrote: >> On 10/07/2012 10:50 PM, Tapani Pälli wrote: >>> Upstreaming old set of patches here to enable Android support in libdrm. >>> Some little rebasing was required for the first one. >>> >>> Chad Versace (2): >>> libdrm,intel: Factor source file lists into sources.mk >>> libdrm,intel: Add Android makefiles (v2) >>> >>> Haitao Huang (1): >>> Android.mk: use LOCAL_COPY_HEADERS to export headers. >>> >>> Android.mk| 62 >>> +++ >>> Makefile.am | 9 >>> intel/Android.mk | 57 ++ >>> intel/Makefile.am | 9 >>> intel/sources.mk | 30 +++ >>> sources.mk| 30 +++ >> >> This series looks good to me. Before committing, though, I'd like to see >> either >> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >> committers. > > Thanks for checking it out. I've tried out androgenizer as Eric > suggested but not really convinced we would like to start using it. To bring an pro-argument for Tapani, this is how it looks to make it work with androgenizer. As you can see, it's not much different from the Android.mk itself, only the variable names changes. diff --git a/Makefile.am b/Makefile.am index 273abf9..b200509 100644 --- a/Makefile.am +++ b/Makefile.am @@ -77,3 +77,23 @@ copy-headers : commit-headers : copy-headers git add include git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.gi + +Android.mk: Makefile.am + androgenizer \ + -:PROJECT testlib \ + -:REL_TOP $(top_srcdir) \ + -:ABS_TOP $(abs_top_srcdir) \ + -:SHARED libdrm \ + -:SOURCES $(LIBDRM_SOURCES) \ + -:LDFLAGS $(libdrm_la_LDFLAGS) \ + -:CPPFLAGS $(libdrm_la_CPPFLAGS) \ + -:TAGS optional\ + -:HEADERS xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h\ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + -:HEADER_TARGET libdrm \ + > $@ -- Regards! http://groleo.wordpress.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Negreanu Marius writes: > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: >> On 10/10/2012 08:05 PM, Chad Versace wrote: >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Haitao Huang (1): Android.mk: use LOCAL_COPY_HEADERS to export headers. Android.mk| 62 +++ Makefile.am | 9 intel/Android.mk | 57 ++ intel/Makefile.am | 9 intel/sources.mk | 30 +++ sources.mk| 30 +++ >>> >>> This series looks good to me. Before committing, though, I'd like to see >>> either >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >>> committers. >> >> Thanks for checking it out. I've tried out androgenizer as Eric >> suggested but not really convinced we would like to start using it. > > To bring an pro-argument for Tapani, this is how it looks to make it > work with androgenizer. > As you can see, it's not much different from the Android.mk itself, > only the variable names changes. If this is all there is to using androgenizer, I suspect it will stay working for longer than the custom Android.mks. Our experience in Mesa has been that basically any time anybody touches the build system for anything but a file addition, android gets broken. By using androgenizer, hopefully we rely on a tool that reflects the upstream build system better in android, and maybe over time that tool can be improved so that android building of upstream projects is less of a burden (seriously, why should you have to manually name the sources and flags variables?). That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable result in complaints from automake? pgp09Q2wEuW9o.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 > ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ > >>> > >>> This series looks good to me. Before committing, though, I'd like to see > >>> either > >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > >>> committers. > >> > >> Thanks for checking it out. I've tried out androgenizer as Eric > >> suggested but not really convinced we would like to start using it. > > > > To bring an pro-argument for Tapani, this is how it looks to make it > > work with androgenizer. > > As you can see, it's not much different from the Android.mk itself, > > only the variable names changes. > > If this is all there is to using androgenizer, I suspect it will stay > working for longer than the custom Android.mks. Our experience in Mesa > has been that basically any time anybody touches the build system for > anything but a file addition, android gets broken. By using > androgenizer, hopefully we rely on a tool that reflects the upstream > build system better in android, and maybe over time that tool can be > improved so that android building of upstream projects is less of a > burden (seriously, why should you have to manually name the sources and > flags variables?). Some of the benefits of androgenizer are, that it filters the contents of the automake variables you pass to it, so you don't have to manually write only slightly different things in Android-specific files. As you saw, some Android specific code is still needed in the build system: - to pass the automake variables to androgenizer, which cannot parse automake files itself. This way we let GNU Make parse the automake files, and androgenizer gets the final values. - a top-level hand-written Android.mk that will execute ./configure and everything related, and cause the androgenizer-generated Android.mk files to be created. We have managed to create such makefiles, that these steps get executed automatically as needed during the full Android system build. Whenever new makefiles are being generated, GNU Make notices that, and automatically restarts the whole build to read them in. (This is not about androgenizer but Android builds in general.) Androgenizer also fixes up all the file paths to be relative to the Android build root dir, so you don't have to mess with generating file lists with different path prefixes for automake vs. Android builds. Or at least that is what androgenizer should do, it may have bugs of course. Androgenizer is no magic tool that automatically makes an autotools project building for Android, but it should help with the most common pains. I have some patches in Androgenizer, and I have androgenized few projects for Collabora. I'd be happy to answer questions about androgenizer. Please, use my work email (cc'd): ppaala...@gmail.com Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Tapani Pälli writes: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? pgpTalPsk5vn8.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani Pälli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ This series looks good to me. Before committing, though, I'd like to see either an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers. -Chad ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/10/2012 08:05 PM, Chad Versace wrote: > On 10/07/2012 10:50 PM, Tapani Pälli wrote: >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) >> >> Haitao Huang (1): >> Android.mk: use LOCAL_COPY_HEADERS to export headers. >> >> Android.mk| 62 >> +++ >> Makefile.am | 9 >> intel/Android.mk | 57 ++ >> intel/Makefile.am | 9 >> intel/sources.mk | 30 +++ >> sources.mk| 30 +++ > > This series looks good to me. Before committing, though, I'd like to see > either > an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > committers. Thanks for checking it out. I've tried out androgenizer as Eric suggested but not really convinced we would like to start using it. > -Chad > -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: > On 10/10/2012 08:05 PM, Chad Versace wrote: >> On 10/07/2012 10:50 PM, Tapani Pälli wrote: >>> Upstreaming old set of patches here to enable Android support in libdrm. >>> Some little rebasing was required for the first one. >>> >>> Chad Versace (2): >>> libdrm,intel: Factor source file lists into sources.mk >>> libdrm,intel: Add Android makefiles (v2) >>> >>> Haitao Huang (1): >>> Android.mk: use LOCAL_COPY_HEADERS to export headers. >>> >>> Android.mk| 62 >>> +++ >>> Makefile.am | 9 >>> intel/Android.mk | 57 ++ >>> intel/Makefile.am | 9 >>> intel/sources.mk | 30 +++ >>> sources.mk| 30 +++ >> >> This series looks good to me. Before committing, though, I'd like to see >> either >> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >> committers. > > Thanks for checking it out. I've tried out androgenizer as Eric > suggested but not really convinced we would like to start using it. To bring an pro-argument for Tapani, this is how it looks to make it work with androgenizer. As you can see, it's not much different from the Android.mk itself, only the variable names changes. diff --git a/Makefile.am b/Makefile.am index 273abf9..b200509 100644 --- a/Makefile.am +++ b/Makefile.am @@ -77,3 +77,23 @@ copy-headers : commit-headers : copy-headers git add include git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.gi + +Android.mk: Makefile.am + androgenizer \ + -:PROJECT testlib \ + -:REL_TOP $(top_srcdir) \ + -:ABS_TOP $(abs_top_srcdir) \ + -:SHARED libdrm \ + -:SOURCES $(LIBDRM_SOURCES) \ + -:LDFLAGS $(libdrm_la_LDFLAGS) \ + -:CPPFLAGS $(libdrm_la_CPPFLAGS) \ + -:TAGS optional\ + -:HEADERS xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h\ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + -:HEADER_TARGET libdrm \ + > $@ -- Regards! http://groleo.wordpress.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Negreanu Marius writes: > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: >> On 10/10/2012 08:05 PM, Chad Versace wrote: >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Haitao Huang (1): Android.mk: use LOCAL_COPY_HEADERS to export headers. Android.mk| 62 +++ Makefile.am | 9 intel/Android.mk | 57 ++ intel/Makefile.am | 9 intel/sources.mk | 30 +++ sources.mk| 30 +++ >>> >>> This series looks good to me. Before committing, though, I'd like to see >>> either >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >>> committers. >> >> Thanks for checking it out. I've tried out androgenizer as Eric >> suggested but not really convinced we would like to start using it. > > To bring an pro-argument for Tapani, this is how it looks to make it > work with androgenizer. > As you can see, it's not much different from the Android.mk itself, > only the variable names changes. If this is all there is to using androgenizer, I suspect it will stay working for longer than the custom Android.mks. Our experience in Mesa has been that basically any time anybody touches the build system for anything but a file addition, android gets broken. By using androgenizer, hopefully we rely on a tool that reflects the upstream build system better in android, and maybe over time that tool can be improved so that android building of upstream projects is less of a burden (seriously, why should you have to manually name the sources and flags variables?). That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable result in complaints from automake? pgp09Q2wEuW9o.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 > ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ > >>> > >>> This series looks good to me. Before committing, though, I'd like to see > >>> either > >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > >>> committers. > >> > >> Thanks for checking it out. I've tried out androgenizer as Eric > >> suggested but not really convinced we would like to start using it. > > > > To bring an pro-argument for Tapani, this is how it looks to make it > > work with androgenizer. > > As you can see, it's not much different from the Android.mk itself, > > only the variable names changes. > > If this is all there is to using androgenizer, I suspect it will stay > working for longer than the custom Android.mks. Our experience in Mesa > has been that basically any time anybody touches the build system for > anything but a file addition, android gets broken. By using > androgenizer, hopefully we rely on a tool that reflects the upstream > build system better in android, and maybe over time that tool can be > improved so that android building of upstream projects is less of a > burden (seriously, why should you have to manually name the sources and > flags variables?). Some of the benefits of androgenizer are, that it filters the contents of the automake variables you pass to it, so you don't have to manually write only slightly different things in Android-specific files. As you saw, some Android specific code is still needed in the build system: - to pass the automake variables to androgenizer, which cannot parse automake files itself. This way we let GNU Make parse the automake files, and androgenizer gets the final values. - a top-level hand-written Android.mk that will execute ./configure and everything related, and cause the androgenizer-generated Android.mk files to be created. We have managed to create such makefiles, that these steps get executed automatically as needed during the full Android system build. Whenever new makefiles are being generated, GNU Make notices that, and automatically restarts the whole build to read them in. (This is not about androgenizer but Android builds in general.) Androgenizer also fixes up all the file paths to be relative to the Android build root dir, so you don't have to mess with generating file lists with different path prefixes for automake vs. Android builds. Or at least that is what androgenizer should do, it may have bugs of course. Androgenizer is no magic tool that automatically makes an autotools project building for Android, but it should help with the most common pains. I have some patches in Androgenizer, and I have androgenized few projects for Collabora. I'd be happy to answer questions about androgenizer. Please, use my work email (cc'd): ppaala...@gmail.com Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Tapani Pälli writes: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) Couldn't this just be done with androgenizer without making a maintenance mess in the upstream code? pgpTalPsk5vn8.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/08/2012 06:37 PM, Eric Anholt wrote: > Tapani Pälli writes: > >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) > > Couldn't this just be done with androgenizer without making a > maintenance mess in the upstream code? > We do not have androgenizer tool in our Android tree but I will check if it can successfully compile libdrm and if we would be able to use it. My main goal here is to get setup where we could use libdrm master as it is without patching it, we have some additional patches on top of these too but I want to make myself more familiar with those before sending them. Thanks; -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ This series looks good to me. Before committing, though, I'd like to see either an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers. -Chad ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On 10/10/2012 08:05 PM, Chad Versace wrote: > On 10/07/2012 10:50 PM, Tapani Pälli wrote: >> Upstreaming old set of patches here to enable Android support in libdrm. >> Some little rebasing was required for the first one. >> >> Chad Versace (2): >> libdrm,intel: Factor source file lists into sources.mk >> libdrm,intel: Add Android makefiles (v2) >> >> Haitao Huang (1): >> Android.mk: use LOCAL_COPY_HEADERS to export headers. >> >> Android.mk| 62 >> +++ >> Makefile.am | 9 >> intel/Android.mk | 57 ++ >> intel/Makefile.am | 9 >> intel/sources.mk | 30 +++ >> sources.mk| 30 +++ > > This series looks good to me. Before committing, though, I'd like to see > either > an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > committers. Thanks for checking it out. I've tried out androgenizer as Eric suggested but not really convinced we would like to start using it. > -Chad > -- // Tapani signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: > On 10/10/2012 08:05 PM, Chad Versace wrote: >> On 10/07/2012 10:50 PM, Tapani Pälli wrote: >>> Upstreaming old set of patches here to enable Android support in libdrm. >>> Some little rebasing was required for the first one. >>> >>> Chad Versace (2): >>> libdrm,intel: Factor source file lists into sources.mk >>> libdrm,intel: Add Android makefiles (v2) >>> >>> Haitao Huang (1): >>> Android.mk: use LOCAL_COPY_HEADERS to export headers. >>> >>> Android.mk| 62 >>> +++ >>> Makefile.am | 9 >>> intel/Android.mk | 57 ++ >>> intel/Makefile.am | 9 >>> intel/sources.mk | 30 +++ >>> sources.mk| 30 +++ >> >> This series looks good to me. Before committing, though, I'd like to see >> either >> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >> committers. > > Thanks for checking it out. I've tried out androgenizer as Eric > suggested but not really convinced we would like to start using it. To bring an pro-argument for Tapani, this is how it looks to make it work with androgenizer. As you can see, it's not much different from the Android.mk itself, only the variable names changes. diff --git a/Makefile.am b/Makefile.am index 273abf9..b200509 100644 --- a/Makefile.am +++ b/Makefile.am @@ -77,3 +77,23 @@ copy-headers : commit-headers : copy-headers git add include git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.gi + +Android.mk: Makefile.am + androgenizer \ + -:PROJECT testlib \ + -:REL_TOP $(top_srcdir) \ + -:ABS_TOP $(abs_top_srcdir) \ + -:SHARED libdrm \ + -:SOURCES $(LIBDRM_SOURCES) \ + -:LDFLAGS $(libdrm_la_LDFLAGS) \ + -:CPPFLAGS $(libdrm_la_CPPFLAGS) \ + -:TAGS optional\ + -:HEADERS xf86drm.h \ + include/drm/drm_fourcc.h \ + include/drm/drm.h\ + include/drm/drm_mode.h \ + include/drm/drm_sarea.h \ + include/drm/i915_drm.h \ + intel/intel_bufmgr.h \ + -:HEADER_TARGET libdrm \ + > $@ -- Regards! http://groleo.wordpress.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
Negreanu Marius writes: > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli wrote: >> On 10/10/2012 08:05 PM, Chad Versace wrote: >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: Upstreaming old set of patches here to enable Android support in libdrm. Some little rebasing was required for the first one. Chad Versace (2): libdrm,intel: Factor source file lists into sources.mk libdrm,intel: Add Android makefiles (v2) Haitao Huang (1): Android.mk: use LOCAL_COPY_HEADERS to export headers. Android.mk| 62 +++ Makefile.am | 9 intel/Android.mk | 57 ++ intel/Makefile.am | 9 intel/sources.mk | 30 +++ sources.mk| 30 +++ >>> >>> This series looks good to me. Before committing, though, I'd like to see >>> either >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel >>> committers. >> >> Thanks for checking it out. I've tried out androgenizer as Eric >> suggested but not really convinced we would like to start using it. > > To bring an pro-argument for Tapani, this is how it looks to make it > work with androgenizer. > As you can see, it's not much different from the Android.mk itself, > only the variable names changes. If this is all there is to using androgenizer, I suspect it will stay working for longer than the custom Android.mks. Our experience in Mesa has been that basically any time anybody touches the build system for anything but a file addition, android gets broken. By using androgenizer, hopefully we rely on a tool that reflects the upstream build system better in android, and maybe over time that tool can be improved so that android building of upstream projects is less of a burden (seriously, why should you have to manually name the sources and flags variables?). That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable result in complaints from automake? pgp09Q2wEuW9o.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Android support
On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt wrote: > Negreanu Marius writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli > > wrote: > >> On 10/10/2012 08:05 PM, Chad Versace wrote: > >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote: > Upstreaming old set of patches here to enable Android support in libdrm. > Some little rebasing was required for the first one. > > Chad Versace (2): > libdrm,intel: Factor source file lists into sources.mk > libdrm,intel: Add Android makefiles (v2) > > Haitao Huang (1): > Android.mk: use LOCAL_COPY_HEADERS to export headers. > > Android.mk| 62 > +++ > Makefile.am | 9 > intel/Android.mk | 57 > ++ > intel/Makefile.am | 9 > intel/sources.mk | 30 +++ > sources.mk| 30 +++ > >>> > >>> This series looks good to me. Before committing, though, I'd like to see > >>> either > >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel > >>> committers. > >> > >> Thanks for checking it out. I've tried out androgenizer as Eric > >> suggested but not really convinced we would like to start using it. > > > > To bring an pro-argument for Tapani, this is how it looks to make it > > work with androgenizer. > > As you can see, it's not much different from the Android.mk itself, > > only the variable names changes. > > If this is all there is to using androgenizer, I suspect it will stay > working for longer than the custom Android.mks. Our experience in Mesa > has been that basically any time anybody touches the build system for > anything but a file addition, android gets broken. By using > androgenizer, hopefully we rely on a tool that reflects the upstream > build system better in android, and maybe over time that tool can be > improved so that android building of upstream projects is less of a > burden (seriously, why should you have to manually name the sources and > flags variables?). Some of the benefits of androgenizer are, that it filters the contents of the automake variables you pass to it, so you don't have to manually write only slightly different things in Android-specific files. As you saw, some Android specific code is still needed in the build system: - to pass the automake variables to androgenizer, which cannot parse automake files itself. This way we let GNU Make parse the automake files, and androgenizer gets the final values. - a top-level hand-written Android.mk that will execute ./configure and everything related, and cause the androgenizer-generated Android.mk files to be created. We have managed to create such makefiles, that these steps get executed automatically as needed during the full Android system build. Whenever new makefiles are being generated, GNU Make notices that, and automatically restarts the whole build to read them in. (This is not about androgenizer but Android builds in general.) Androgenizer also fixes up all the file paths to be relative to the Android build root dir, so you don't have to mess with generating file lists with different path prefixes for automake vs. Android builds. Or at least that is what androgenizer should do, it may have bugs of course. Androgenizer is no magic tool that automatically makes an autotools project building for Android, but it should help with the most common pains. I have some patches in Androgenizer, and I have androgenized few projects for Collabora. I'd be happy to answer questions about androgenizer. Please, use my work email (cc'd): ppaala...@gmail.com Thanks, pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups
On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
On 09/30/2011 08:16 AM, Michel Dänzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Feel free to squash my patch into yours. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
2011/9/30 Michel Dänzer : > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Looks good to me, both your patches and Nicholas' patch are: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
On 09/30/2011 08:16 AM, Michel Dänzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Feel free to squash my patch into yours. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
2011/9/30 Michel Dänzer : > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Looks good to me, both your patches and Nicholas' patch are: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
On 09/30/2011 08:16 AM, Michel Dänzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Feel free to squash my patch into yours. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
2011/9/30 Michel Dänzer : > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Looks good to me, both your patches and Nicholas' patch are: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
On 09/30/2011 08:16 AM, Michel Dänzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Feel free to squash my patch into yours. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
2011/9/30 Michel Dänzer : > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Looks good to me, both your patches and Nicholas' patch are: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
On 09/30/2011 08:16 AM, Michel Dänzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Feel free to squash my patch into yours. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
2011/9/30 Michel Dänzer : > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Looks good to me, both your patches and Nicholas' patch are: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
On 09/30/2011 08:16 AM, Michel Dänzer wrote: > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Feel free to squash my patch into yours. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon cursor patches
2011/9/30 Michel Dänzer : > While reviewing Nicholas Miell's patch 'drm/radeon/kms: fix cursor image > off-by-one error', I noticed at least one other bug (fixed by patch 2, and one > potential bug fixed by patch 3) and opportunities for cleanup. > > Patch 1 is based on Nicholas' patch and can be dropped if he amends his patch > along the same lines. > > [PATCH 1/3] drm/radeon: Simplify cursor x/yorigin calculation. > [PATCH 2/3] drm/radeon: Update AVIVO cursor coordinate origin before > [PATCH 3/3] drm/radeon: Set cursor x/y to 0 when x/yorigin > 0. Looks good to me, both your patches and Nicholas' patch are: Reviewed-by: Alex Deucher > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 12:35 PM, Kristian Høgsberg wrote: > Here's the patch to implement render nodes as discussed in the "DRM2" > talk at XDC: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 > > The core problem is that DRM security is compromised in the face of > VT switching and multiple DRM masters. Any local user can access all > shared buffers from within any X server on the system, even when that > user doesn't have access to any of those X servers. > > The fix for this is to use dmabuf/prime and fd passing for buffer sharing. > That infrastructure is already in place and we need to start using that in > user space. Once we're passing buffers between display servers and clients > in a point-to-point fashion, we no longer need to authenticate clients. We > just need to make sure they can only render and import/export buffers to > fds. That's what this patch does, by creating a new type of drm device > node. Accessing this node doesn't require authentication (and as such > can be used without a master, ie headless), but will only expose the safe, > modern (DRI2ish) rendering ioctls. > > Once userspace is sharing buffers through fd passing, the legacy card0 node > can be locked down by unix permissions, for example in a drm-master group, > so that only setgid binaries (X, weston, other KMS apps) can access it. > I haven't read through your patches yet, but Dave and Ilija already did something similar a while back: http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html Alex > Kristian > > > See also: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security > > https://lwn.net/Articles/517375/ > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, 28 Sep 2012, Alex Deucher wrote: I haven't read through your patches yet, but Dave and Ilija already did something similar a while back: http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html Actually, there is a, a newer series of patches here (applied few comments I got after first series) http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html I have the v3 series (applied more comments I got after v2 series, plus some more cleanup) that I have never sent out, because my perception was that there was low interest in this work. I can send the v3 out, if there is a revived interest in this work. The original work is by Dave and I did some major cleanup and built more on the top of it. Kristian's patches at the first glance (I have not looked them in detail) appear more like prep. work (like which ioctl can a render node use and which can't, etc.), but my impression is that they still require the work cited above (Dave's original work and/or my followup work) to actually be able to create and use the render node. BTW, the third patch in Kristian's series is for Intel only and we'll probably need equivalent patches for radeon and nouveau. -- Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 7:59 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Alex Deucher wrote: >> >> >> I haven't read through your patches yet, but Dave and Ilija already >> did something similar a while back: >> >> http://lists.freedesktop.org/archives/dri-devel/2012-March/020765.html >> > > Actually, there is a, a newer series of patches here (applied few comments I > got after first series) > > http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html > > I have the v3 series (applied more comments I got after v2 series, plus some > more cleanup) that I have never sent out, because my perception was that > there was low interest in this work. I can send the v3 out, if there is a > revived interest in this work. > > The original work is by Dave and I did some major cleanup and built more on > the top of it. > > Kristian's patches at the first glance (I have not looked them in detail) > appear more like prep. work (like which ioctl can a render node use and > which can't, etc.), but my impression is that they still require the work > cited above (Dave's original work and/or my followup work) to actually be > able to create and use the render node. > > BTW, the third patch in Kristian's series is for Intel only and we'll > probably need equivalent patches for radeon and nouveau. On a quick look the rendernode Kristian propose and your work seem to attack slightly different issues. Your/Dave's patch series seems to put large efforts into (dynamically) splitting up the resources of a drm device, including the modeset stuff. Kristians proposal here is much more modest, with just enabling a way for to do the same for render clients. All the modeset (and flink open stuff) would still be only done through the legacy drm node. One thing though that Kristians patches miss is properly splitting out mmap support such that each open file of the rendernode only has access to it's file-private gem object and not all of them. Since linux has the mmap interface at the struct file level, that shouldn't be a big hassle to get off the ground: We just need to add an mmap_offset table to file_prive and then add the offset lookup at the right place (and do the lookup with the right table), depending upon whether it's a legacy or a new render node doing the offset create (or mmap syscall). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, 28 Sep 2012, Daniel Vetter wrote: On a quick look the rendernode Kristian propose and your work seem to attack slightly different issues. Your/Dave's patch series seems to put large efforts into (dynamically) splitting up the resources of a drm device, including the modeset stuff. Correct, the goal is to be able to run multiseat while sharing a GPU. Actually, with my variant of render nodes, I even got multiple desktops residing in different LXC containers to share the GPU, which is kind of cool. Kristians proposal here is much more modest, with just enabling a way for to do the same for render clients. All the modeset (and flink open stuff) would still be only done through the legacy drm node. OK I see. From what I can tell from the second patch, drm_get_pci_dev will create one (and I guess only one, right ?) render node if the underlying driver has DRIVER_RENDER node feature. The third patch (among other things) adds that feature to Intel driver. So if I boot up a system with these patches and with Intel GPU, I will automagically get one more /dev/dri/renderD128 node, right ? The intent is that the render client opens and uses that render node. The /dev/dri/controlDNN node still remains an unused "orphan", right ? So would you entertain the possibility that the render node is created from user space on demand using an ioctl into the control node ? If that's a possiblity for you, then my set of patches is a superset of what Kristian needs. If you just need a render client, you can create a node with no display resources and you would get something quite close to what these 3 patches try to do. unless I am missing something. -- Ilija ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
On Fri, Sep 28, 2012 at 8:42 PM, Ilija Hadzic wrote: > > > On Fri, 28 Sep 2012, Daniel Vetter wrote: > >> On a quick look the rendernode Kristian propose and your work seem to >> attack slightly different issues. Your/Dave's patch series seems to >> put large efforts into (dynamically) splitting up the resources of a >> drm device, including the modeset stuff. > > > Correct, the goal is to be able to run multiseat while sharing a GPU. > Actually, with my variant of render nodes, I even got multiple desktops > residing in different LXC containers to share the GPU, which is kind of > cool. > > >> Kristians proposal here is >> much more modest, with just enabling a way for to do the same for >> render clients. All the modeset (and flink open stuff) would still be >> only done through the legacy drm node. >> > > OK I see. From what I can tell from the second patch, drm_get_pci_dev will > create one (and I guess only one, right ?) render node if the underlying > driver has DRIVER_RENDER node feature. The third patch (among other things) > adds that feature to Intel driver. > > So if I boot up a system with these patches and with Intel GPU, I will > automagically get one more /dev/dri/renderD128 node, right ? The intent is > that the render client opens and uses that render node. The > /dev/dri/controlDNN node still remains an unused "orphan", right ? Yeah, the plan is to just have one single render node and ensure insulation by not allowing any open file of that render node to access any other buffer not associated to the file_prive. Like I've said, the current patches have a little hole wrt mmap handling there ;-) The only way to share buffers is via dma_buf (which is fd based, so we could attach full selinux contexts if required) or flink (but not opening an flink name, that requires master rights on the legacy node). > So would you entertain the possibility that the render node is created from > user space on demand using an ioctl into the control node ? If that's a > possiblity for you, then my set of patches is a superset of what Kristian > needs. If you just need a render client, you can create a node with no > display resources and you would get something quite close to what these 3 > patches try to do. unless I am missing something. Well, dynamically creating render nodes is not required just for insulating different render clients. The goal is very much to allow background/headless usage of the gpu, e.g. for opencl and video encode/decode. So first asking a central deamon to span another render node just to transcode another video isn't that great. Obviously the security separation only works if the gpu actually supports different vm address spaces for each node ... The multi-seat issue is imo orthogonal to that and I don't think we should mangle (like you've noticed, ppl seem to get scared about it and not push those patches too much). And with new stuff like atomic modeset and gpus having a lot of shared resources in the display hw (plls, memory bw, shared links between pipes, ...) I don't think we could even statically split up the modeset resurces, like your patch would allow. Imho a better solution for the mutliseat use-case would be to have a (priviledge) system-compositor that handles the resource sharing between the different seats. Display servers would then simply be yet another render node client (and doing modeset changes through a protocol to the system compositor). The system-compositor could be very well something that would aweful closely resemble wayland ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] [RFC] DRM Render Nodes
Hi Kristian, Could you please update Documentation/DocBook/drm.tmpl with render nodes documentation ? On Friday 28 September 2012 12:35:56 Kristian Høgsberg wrote: > Here's the patch to implement render nodes as discussed in the "DRM2" > talk at XDC: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2 > > The core problem is that DRM security is compromised in the face of > VT switching and multiple DRM masters. Any local user can access all > shared buffers from within any X server on the system, even when that > user doesn't have access to any of those X servers. > > The fix for this is to use dmabuf/prime and fd passing for buffer sharing. > That infrastructure is already in place and we need to start using that in > user space. Once we're passing buffers between display servers and clients > in a point-to-point fashion, we no longer need to authenticate clients. We > just need to make sure they can only render and import/export buffers to > fds. That's what this patch does, by creating a new type of drm device > node. Accessing this node doesn't require authentication (and as such > can be used without a master, ie headless), but will only expose the safe, > modern (DRI2ish) rendering ioctls. > > Once userspace is sharing buffers through fd passing, the legacy card0 node > can be locked down by unix permissions, for example in a drm-master group, > so that only setgid binaries (X, weston, other KMS apps) can access it. > > Kristian > > > See also: > > http://wiki.x.org/wiki/Events/XDC2012/Proceedings#Graphics_stack_security > > https://lwn.net/Articles/517375/ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Additional radeon audio cleanups
Am 18.04.2013 17:35, schrieb alexdeuc...@gmail.com: From: Alex Deucher This set of patches does some additional audio cleanups and switches to per asic callbacks for audio. Alex Deucher (3): drm/radeon: clean up audio supported check drm/radeon: clean up audio dto programming drm/radeon: switch audio handling to use callbacks Looks good to me and is: Reviewed-by: Christian König drivers/gpu/drm/radeon/atombios_encoders.c | 17 ++-- drivers/gpu/drm/radeon/evergreen_hdmi.c| 43 +- drivers/gpu/drm/radeon/r600_audio.c| 64 +- drivers/gpu/drm/radeon/r600_hdmi.c | 135 --- drivers/gpu/drm/radeon/radeon.h| 10 +- drivers/gpu/drm/radeon/radeon_asic.c | 18 drivers/gpu/drm/radeon/radeon_asic.h |5 +- 7 files changed, 138 insertions(+), 154 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon: add pageflip support
On Tue, Oct 26, 2010 at 4:30 AM, Alex Deucher wrote: > This set of patches adds pageflipping support for radeon. > There are two drm patches and one ddx patch required. The > drm patches are against Dave's drm-next branch and the ddx > patch is against git master. So far it's been lightly tested > with openarena on a variety of radeons. Feedback appreciated. > Just a heads up, this doesn't work with tiling enabled on 6xx/7xx/evergreen yet. > Alex > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] radeon: add pageflip support
On Tue, Oct 26, 2010 at 4:55 AM, Alex Deucher wrote: > On Tue, Oct 26, 2010 at 4:30 AM, Alex Deucher wrote: >> This set of patches adds pageflipping support for radeon. >> There are two drm patches and one ddx patch required. The >> drm patches are against Dave's drm-next branch and the ddx >> patch is against git master. So far it's been lightly tested >> with openarena on a variety of radeons. Feedback appreciated. >> > > Just a heads up, this doesn't work with tiling enabled on 6xx/7xx/evergreen > yet. Fixed now with this additional patch: http://people.freedesktop.org/~agd5f/pflip/0002-radeon-kms-allow-tiled-front-buffer-on-6xx-7xx.patch Alex > >> Alex >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] embed drm_gem_object into radeon_bo
Hi, Daniel, My main concerns previously for embedding GEM objects as user-space references for TTM has been twofold and implementation specific. 1) The locking has been using global mutexes where local spin- or RCU locks have been more appropriate. It looks like this has finally been / is finally going to be addressed. 2) The gem object is too specialized for general purpose use: a) The shmem member has no natural use with TTM except possibly as a persistent swap storage, but in an ideal world, TTM would talk to the swap cache directly so in the longer term there is no need for the shmem object at all. b) Implementations may want to use other user-space visible objects than buffer objects: For example fence objects or CPU synchronization objects. The common traits of / operations on these are user-space visibility, inter-process visibility, refcounting and destruction when the relevant file is closed. Hence a class that provides only the user-space handles, naming (flink), refcounting and registering with a file handle would be the best choice of a "base" class. Traditional Gem objects could derive from those and provide any extra *generic* members needed for buffer objects. This doesn't really affect your work though. Just some comments on why vmwgfx don't use GEM objects by default and how they could be made optimal for TTM-aware drivers. Thanks, /Thomas On 11/13/2010 09:57 PM, Daniel Vetter wrote: Hi all, This patch series embeds drm_gem_object into struct radeon_bo and adjusts any references. I've decided against embedding the gem stuff into struct ttm_bo because - vmwgfx doesn't use gem and - ttm is used for implementing the memory management, whereas gem provides the userspace interface (I know, there's some overlap there, but that's not really a new problem). Please review and consider merging for -next. Yours, Daniel Daniel Vetter (3): drm/radeon: embed struct drm_gem_object drm/radeon: introduce gem_to_radeon_bo helper drm/radeon: kill radeon_bo->gobj pointer drivers/gpu/drm/radeon/atombios_crtc.c |8 ++-- drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +- drivers/gpu/drm/radeon/r600.c |2 +- drivers/gpu/drm/radeon/r600_blit_kms.c |2 +- drivers/gpu/drm/radeon/radeon.h |3 +- drivers/gpu/drm/radeon/radeon_benchmark.c |4 +- drivers/gpu/drm/radeon/radeon_cs.c |2 +- drivers/gpu/drm/radeon/radeon_device.c |4 +- drivers/gpu/drm/radeon/radeon_fb.c | 10 +++--- drivers/gpu/drm/radeon/radeon_gart.c|2 +- drivers/gpu/drm/radeon/radeon_gem.c | 43 --- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 +- drivers/gpu/drm/radeon/radeon_object.c | 24 +++ drivers/gpu/drm/radeon/radeon_object.h |2 +- drivers/gpu/drm/radeon/radeon_ring.c|4 +- drivers/gpu/drm/radeon/radeon_test.c|4 +- drivers/gpu/drm/radeon/radeon_ttm.c |2 +- drivers/gpu/drm/radeon/rv770.c |2 +- 18 files changed, 59 insertions(+), 65 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
