Re: [Nouveau] [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM
On Mon, Mar 30, 2020 at 01:54:33PM +, Deucher, Alexander wrote: > > -Original Message- > > From: Bjorn Helgaas > > Sent: Saturday, March 28, 2020 4:19 PM > > To: Mikel Rychliski > > Cc: amd-...@lists.freedesktop.org; linux-...@vger.kernel.org; > > nouveau@lists.freedesktop.org; Deucher, Alexander > > ; Koenig, Christian > > ; Zhou, David(ChunMing) > > ; Matthew Garrett > > ; Ben Skeggs ; > > Christoph Hellwig > > Subject: Re: [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform > > ROM > > > > On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > > > On some EFI systems, the video BIOS is provided by the EFI firmware. > > > The boot stub code stores the physical address of the ROM image in pdev- > > >rom. > > > Currently we attempt to access this pointer using phys_to_virt(), > > > which doesn't work with CONFIG_HIGHMEM. > > > > > > On these systems, attempting to load the radeon module on a x86_32 > > > kernel can result in the following: > > > > > > BUG: unable to handle page fault for address: 3e8ed03c > > > #PF: supervisor read access in kernel mode > > > #PF: error_code(0x) - not-present page > > > *pde = > > > Oops: [#1] PREEMPT SMP > > > CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next- > > 20200228 #2 > > > Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS > > MP11.88Z.005C.B08.0707021221 07/02/07 > > > EIP: radeon_get_bios+0x5ed/0xe50 [radeon] > > > Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b > > > 47 08 8b > > 55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 > > 78 01 > > aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06 > > > EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001 > > > ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0 > > > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206 > > > CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0 > > > Call Trace: > > > ? register_client+0x34/0xe0 > > > ? register_client+0xab/0xe0 > > > r520_init+0x26/0x240 [radeon] > > > radeon_device_init+0x533/0xa50 [radeon] > > > radeon_driver_load_kms+0x80/0x220 [radeon] > > > drm_dev_register+0xa7/0x180 [drm] > > > radeon_pci_probe+0x10f/0x1a0 [radeon] > > > pci_device_probe+0xd4/0x140 > > > really_probe+0x13d/0x3b0 > > > driver_probe_device+0x56/0xd0 > > > device_driver_attach+0x49/0x50 > > > __driver_attach+0x79/0x130 > > > ? device_driver_attach+0x50/0x50 > > > bus_for_each_dev+0x5b/0xa0 > > > driver_attach+0x19/0x20 > > > ? device_driver_attach+0x50/0x50 > > > bus_add_driver+0x117/0x1d0 > > > ? pci_bus_num_vf+0x20/0x20 > > > driver_register+0x66/0xb0 > > > ? 0xf80f4000 > > > __pci_register_driver+0x3d/0x40 > > > radeon_init+0x82/0x1000 [radeon] > > > do_one_initcall+0x42/0x200 > > > ? kvfree+0x25/0x30 > > > ? __vunmap+0x206/0x230 > > > ? kmem_cache_alloc_trace+0x16f/0x220 > > > ? do_init_module+0x21/0x220 > > > do_init_module+0x50/0x220 > > > load_module+0x1f26/0x2200 > > > sys_init_module+0x12d/0x160 > > > do_fast_syscall_32+0x82/0x250 > > > entry_SYSENTER_32+0xa5/0xf8 > > > > > > Fix the issue by updating all drivers which can access a platform > > > provided ROM. Instead of calling the helper function > > > pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on > > the pdev->rom. > > > > > > radeon_read_platform_bios() previously directly accessed an __iomem > > > pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). > > > > > > pci_platform_rom() now has no remaining callers, so remove it. > > > > > > Signed-off-by: Mikel Rychliski > > > > I applied this to pci/resource for v5.7. I would feel better if some of the > > graphics guys chimed in, or even applied it via the DRM tree since most of > > the > > changes are actually in drivers/gpu. > > Feel free to take it through the PCI tree. These areas of radeon and amdgpu > don't really change much at all so, I'm not too concerned about a conflict. > > Acked-by: Alex Deucher Thanks, I added your ack, and this is queued up for v5.7. > > Feel free to add my > > > > Acked-by: Bjorn Helgaas > > > > and let me know if you do that. > > > > > --- > > > > > > Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. > > > > > > Changes in v3: > > > - Inline pci_platform_rom() > > > > > > Changes in v2: > > > - Add iounmap() call in nouveau > > > - Update function comment for pci_platform_rom() > > > - Minor changes to commit messages > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 31 > > +- > > > .../gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 17 ++- > > - > > > drivers/gpu/drm/radeon/radeon_bios.c | 30 > > > +--- > > - > > > drivers/pci/rom.c
Re: [Nouveau] [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform ROM
[AMD Public Use] > -Original Message- > From: Bjorn Helgaas > Sent: Saturday, March 28, 2020 4:19 PM > To: Mikel Rychliski > Cc: amd-...@lists.freedesktop.org; linux-...@vger.kernel.org; > nouveau@lists.freedesktop.org; Deucher, Alexander > ; Koenig, Christian > ; Zhou, David(ChunMing) > ; Matthew Garrett > ; Ben Skeggs ; > Christoph Hellwig > Subject: Re: [PATCH v3] PCI: Use ioremap(), not phys_to_virt() for platform > ROM > > On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > > On some EFI systems, the video BIOS is provided by the EFI firmware. > > The boot stub code stores the physical address of the ROM image in pdev- > >rom. > > Currently we attempt to access this pointer using phys_to_virt(), > > which doesn't work with CONFIG_HIGHMEM. > > > > On these systems, attempting to load the radeon module on a x86_32 > > kernel can result in the following: > > > > BUG: unable to handle page fault for address: 3e8ed03c > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x) - not-present page > > *pde = > > Oops: [#1] PREEMPT SMP > > CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next- > 20200228 #2 > > Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS > MP11.88Z.005C.B08.0707021221 07/02/07 > > EIP: radeon_get_bios+0x5ed/0xe50 [radeon] > > Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 > > 08 8b > 55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 > 01 > aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06 > > EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001 > > ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0 > > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206 > > CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0 > > Call Trace: > > ? register_client+0x34/0xe0 > > ? register_client+0xab/0xe0 > > r520_init+0x26/0x240 [radeon] > > radeon_device_init+0x533/0xa50 [radeon] > > radeon_driver_load_kms+0x80/0x220 [radeon] > > drm_dev_register+0xa7/0x180 [drm] > > radeon_pci_probe+0x10f/0x1a0 [radeon] > > pci_device_probe+0xd4/0x140 > > really_probe+0x13d/0x3b0 > > driver_probe_device+0x56/0xd0 > > device_driver_attach+0x49/0x50 > > __driver_attach+0x79/0x130 > > ? device_driver_attach+0x50/0x50 > > bus_for_each_dev+0x5b/0xa0 > > driver_attach+0x19/0x20 > > ? device_driver_attach+0x50/0x50 > > bus_add_driver+0x117/0x1d0 > > ? pci_bus_num_vf+0x20/0x20 > > driver_register+0x66/0xb0 > > ? 0xf80f4000 > > __pci_register_driver+0x3d/0x40 > > radeon_init+0x82/0x1000 [radeon] > > do_one_initcall+0x42/0x200 > > ? kvfree+0x25/0x30 > > ? __vunmap+0x206/0x230 > > ? kmem_cache_alloc_trace+0x16f/0x220 > > ? do_init_module+0x21/0x220 > > do_init_module+0x50/0x220 > > load_module+0x1f26/0x2200 > > sys_init_module+0x12d/0x160 > > do_fast_syscall_32+0x82/0x250 > > entry_SYSENTER_32+0xa5/0xf8 > > > > Fix the issue by updating all drivers which can access a platform > > provided ROM. Instead of calling the helper function > > pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on > the pdev->rom. > > > > radeon_read_platform_bios() previously directly accessed an __iomem > > pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). > > > > pci_platform_rom() now has no remaining callers, so remove it. > > > > Signed-off-by: Mikel Rychliski > > I applied this to pci/resource for v5.7. I would feel better if some of the > graphics guys chimed in, or even applied it via the DRM tree since most of the > changes are actually in drivers/gpu. Feel free to take it through the PCI tree. These areas of radeon and amdgpu don't really change much at all so, I'm not too concerned about a conflict. Acked-by: Alex Deucher > > Feel free to add my > > Acked-by: Bjorn Helgaas > > and let me know if you do that. > > > --- > > > > Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. > > > > Changes in v3: > > - Inline pci_platform_rom() > > > > Changes in v2: > > - Add iounmap() call in nouveau > > - Update function comment for pci_platform_rom() > > - Minor changes to commit messages > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 31 > +- > > .../gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 17 ++- > - > > drivers/gpu/drm/radeon/radeon_bios.c | 30 > > +--- > - > > drivers/pci/rom.c | 17 > > include/linux/pci.h| 1 - > > 5 files changed, 52 insertions(+), 44 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c > > index 50dff69a0f6e..b1172d93c99c 100644 > > ---
Re: [Nouveau] Status of GF108GLM [NVS 5200M]
Yes, GF108 is Fermi (F = Fermi). Reclocking is currently not available for that generation, unfortunately. You should be able to otherwise use your GPU just fine, but I'm guessing it'll come up in the "07" state when it powers on (in the state as-is it appears powered off, which it will do automatically when not in use), which as you can see is a fraction of the total GPU available perf. For example `DRI_PRIME=1 glxinfo` should show you that it's using nouveau. There's a very experimental branch that does enable reclocking for Fermi at https://github.com/skeggsb/nouveau/commits/devel-clk . However I believe it was only tested with a single GPU, and my testing with an identical such GPU was negative. On the other hand, you don't have a display hanging off the card, which greatly increases chances of success. Feel free to join #nouveau on irc.freenode.net if you plan on exploring this. Cheers, -ilia On Mon, Mar 30, 2020 at 3:22 AM Jesús J. Guerrero Botella wrote: > > Hello. > > I am not subscribed to the list, so, please, if I do anything wrong > just let me know politely and I'll try to improve :) > > I just want to know if there's any branch of nouveau version that will > work with this chip. lspci lists it as: > > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS > 5200M] (rev a1) > > I think it's Fermi, but I am not sure. When I try to change pstate it says: > > # LC_ALL=C echo '0f' > /sys/kernel/debug/dri/1/pstate > bash: echo: write error: Function not implemented > # LC_ALL=C cat /sys/kernel/debug/dri/1/pstate > 03: core 50 MHz memory 135 MHz > 07: core 202 MHz memory 324 MHz > 0f: core 672 MHz memory 1569 MHz > AC: core 0 MHz memory 0 MHz > > It's worth noting that's a secondary gpu. I just use the intel chip > for everyday's work, but I have some free days and I am trying to get > the secondary one working and put it to good use, if possible. > > Thanks for any help you can provide. Please, CC me, as said, I am not > subscribed to the list even though I'll try to keep an eye on this. > > > -- > Jesús Guerrero Botella > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v4 02/22] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
On Thu, Jan 23, 2020 at 2:59 PM Thomas Zimmermann wrote:
>
> The new callback get_scanout_position() reads the current location
> of the scanout process. The operation is currently located in struct
> drm_driver, but really belongs to the CRTC. Drivers will be converted
> in separate patches.
>
> To help with the conversion, the timestamp calculation has been
> moved from drm_calc_vbltimestamp_from_scanoutpos() to
> drm_crtc_vblank_helper_get_vblank_timestamp_internal(). The helper
> function supports the new and old interface of get_scanout_position().
> drm_calc_vbltimestamp_from_scanoutpos() remains as a wrapper around
> the new function.
>
> Callback functions return the scanout position from the CRTC. The
> legacy version of the interface receives the device and pipe index,
> the modern version receives a pointer to the CRTC. We keep the
> legacy version until all drivers have been converted.
>
> v4:
> * 80-character line fixes
> v3:
> * refactor drm_calc_vbltimestamp_from_scanoutpos() to minimize
> code duplication
> * define types for get_scanout_position() callbacks
> v2:
> * fix logical op in drm_calc_vbltimestamp_from_scanoutpos()
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: Yannick Fertré
> Reviewed-by: Ville Syrjälä
This patch causes new kerneldoc build warnings:
./drivers/gpu/drm/drm_vblank.c:623: warning: Excess function parameter
'dev' description in
'drm_crtc_vblank_helper_get_vblank_timestamp_internal'
./drivers/gpu/drm/drm_vblank.c:623: warning: Excess function parameter
'pipe' description in
'drm_crtc_vblank_helper_get_vblank_timestamp_internal'
./drivers/gpu/drm/drm_vblank.c:624: warning: Function parameter or
member 'crtc' not described in
'drm_crtc_vblank_helper_get_vblank_timestamp_internal'
./drivers/gpu/drm/drm_vblank.c:624: warning: Excess function parameter
'dev' description in
'drm_crtc_vblank_helper_get_vblank_timestamp_internal'
./drivers/gpu/drm/drm_vblank.c:624: warning: Excess function parameter
'pipe' description in
'drm_crtc_vblank_helper_get_vblank_timestamp_internal'
Please fix.
-Daniel
> ---
> drivers/gpu/drm/drm_vblank.c | 101 +++
> include/drm/drm_drv.h| 7 +-
> include/drm/drm_modeset_helper_vtables.h | 47 +++
> include/drm/drm_vblank.h | 25 ++
> 4 files changed, 157 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 326db52f2ad8..7e962c29780c 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -577,7 +578,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
> * Implements calculation of exact vblank timestamps from given
> drm_display_mode
> * timings and current video scanout position of a CRTC. This can be directly
> * used as the _driver.get_vblank_timestamp implementation of a kms
> driver
> - * if _driver.get_scanout_position is implemented.
> + * if _crtc_helper_funcs.get_scanout_position is implemented.
> *
> * The current implementation only handles standard video modes. For double
> scan
> * and interlaced modes the driver is supposed to adjust the hardware mode
> @@ -599,28 +600,85 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct
> drm_device *dev,
>ktime_t *vblank_time,
>bool in_vblank_irq)
> {
> - struct timespec64 ts_etime, ts_vblank_time;
> - ktime_t stime, etime;
> - bool vbl_status;
> struct drm_crtc *crtc;
> - const struct drm_display_mode *mode;
> - struct drm_vblank_crtc *vblank = >vblank[pipe];
> - int vpos, hpos, i;
> - int delta_ns, duration_ns;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return false;
>
> crtc = drm_crtc_from_index(dev, pipe);
> + if (!crtc)
> + return false;
>
> - if (pipe >= dev->num_crtcs || !crtc) {
> + return drm_crtc_vblank_helper_get_vblank_timestamp_internal(crtc,
> + max_error,
> +
> vblank_time,
> +
> in_vblank_irq,
> +
> crtc->helper_private->get_scanout_position,
> +
> dev->driver->get_scanout_position);
> +}
> +EXPORT_SYMBOL(drm_calc_vbltimestamp_from_scanoutpos);
> +
> +/**
> + * drm_crtc_vblank_helper_get_vblank_timestamp_internal - precise vblank
> + *timestamp helper
> + * @dev: DRM device
> + * @pipe: index of CRTC whose vblank timestamp to retrieve
> + *
Re: [Nouveau] [igt-dev] [PATCH i-g-t 1/4] lib/igt_core: Add igt_require_fd()
On Tue, Mar 17, 2020 at 09:00:44PM -0400, Lyude wrote:
> From: Lyude Paul
>
> Like igt_assert_fd(), but using igt_require() instead
>
> Signed-off-by: Lyude Paul
> ---
> lib/igt_core.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/lib/igt_core.h b/lib/igt_core.h
> index fae5f59e..b66336cf 100644
> --- a/lib/igt_core.h
> +++ b/lib/igt_core.h
> @@ -1008,6 +1008,18 @@ void igt_describe_f(const char *fmt, ...);
> else igt_debug("Test requirement passed: %s\n", #expr); \
> } while (0)
>
> +/**
> + * igt_require_fd:
> + * @fd: file descriptor
> + *
> + * Skips (sub-) test if the given file descriptor is invalid.
> + *
> + * Like igt_require(), but displays the values being compared on failure
> instead
> + * of simply printing the stringified expression..
igt_assert_fd has this documentation comment, but that's mistakenly
copypasted from igt_assert_eq and pals. Let's not propagate the
copypaste error further.
--
Petri Latvala
> + */
> +#define igt_require_fd(fd) \
> + igt_require_f(fd >= 0, "file descriptor " #fd " failed\n");
> +
> /**
> * igt_skip_on_f:
> * @expr: condition to test
> --
> 2.24.1
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [igt-dev] [PATCH i-g-t 4/4] tests: Add nouveau-crc tests
On Tue, Mar 17, 2020 at 09:00:47PM -0400, Lyude wrote:
> From: Lyude Paul
>
> We're finally getting CRC support in nouveau, so let's start testing
> this in igt as well! While the normal CRC capture tests are nice,
> there's a number of Nvidia-specific hardware characteristics that we
> need to test as well.
>
> The most important one is known as a "notifier context flip". Basically,
> Nvidia GPUs store generated CRCs in an allocated memory region, referred
> to as the notifier context, that the driver programs itself. Strangely,
> this region can only hold a limited number of CRC entries, and once it
> runs out of available entries the hardware simply sets an overrun bit
> and stops writing any new CRC entries.
>
> Since igt-gpu-tools doesn't really have an expectation of only being
> able to grab a limited number of CRCs, we work around this in nouveau by
> allocating two separate CRC notifier regions each time we start
> capturing CRCs, and then flip between them whenever we get close to
> filling our currently programmed notifier context. While this keeps the
> number of CRC entries we lose to an absolute minimum, we are guaranteed
> to lose exactly one CRC entry between context flips. Thus, we add some
> tests to ensure that nouveau handles these flips correctly
> (pipe-[A-F]-ctx-flip-detection), and that igt itself is also able to
> handle them correctly (pipe-[A-F]-ctx-flip-skip-current-frame). Since
> these tests use a debugfs interface to manually control the notifier
> context flip threshold, we also add one test to ensure that any flip
> thresholds we set are cleared after a single CRC capture
> (ctx-flip-threshold-reset-after-capture).
>
> In addition, we also add some simple tests to test Nvidia-specific CRC
> sources.
>
> Signed-off-by: Lyude Paul
> ---
> lib/drmtest.c | 10 ++
> lib/drmtest.h | 2 +
> tests/meson.build | 1 +
> tests/nouveau_crc.c | 396
> 4 files changed, 409 insertions(+)
> create mode 100644 tests/nouveau_crc.c
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 1fc39925..53c01754 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -112,6 +112,11 @@ bool is_i915_device(int fd)
> return __is_device(fd, "i915");
> }
>
> +bool is_nouveau_device(int fd)
> +{
> + return __is_device(fd, "nouveau");
> +}
> +
> bool is_vc4_device(int fd)
> {
> return __is_device(fd, "vc4");
> @@ -537,6 +542,11 @@ void igt_require_intel(int fd)
> igt_require(is_i915_device(fd) && has_known_intel_chipset(fd));
> }
>
> +void igt_require_nouveau(int fd)
> +{
> + igt_require(is_nouveau_device(fd));
> +}
> +
> void igt_require_vc4(int fd)
> {
> igt_require(is_vc4_device(fd));
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 632c616b..4937e9d2 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -97,10 +97,12 @@ void gem_quiescent_gpu(int fd);
>
> void igt_require_amdgpu(int fd);
> void igt_require_intel(int fd);
> +void igt_require_nouveau(int fd);
> void igt_require_vc4(int fd);
>
> bool is_amdgpu_device(int fd);
> bool is_i915_device(int fd);
> +bool is_nouveau_device(int fd);
> bool is_vc4_device(int fd);
>
> /**
> diff --git a/tests/meson.build b/tests/meson.build
> index 7629afde..9ff74cc6 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -70,6 +70,7 @@ test_progs = [
> 'kms_vblank',
> 'kms_vrr',
> 'meta_test',
> + 'nouveau_crc',
> 'panfrost_get_param',
> 'panfrost_gem_new',
> 'panfrost_prime',
> diff --git a/tests/nouveau_crc.c b/tests/nouveau_crc.c
> new file mode 100644
> index ..09e17a6f
> --- /dev/null
> +++ b/tests/nouveau_crc.c
> @@ -0,0 +1,396 @@
> +/*
> + * Copyright © 2019 Red Hat Inc.
Verify that the authoring year is correct.
--
Petri Latvala
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
Krzysztof Kozlowski writes:
> diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
> index 5ac84efc6ede..9fe4fb3b08aa 100644
> --- a/arch/powerpc/kernel/iomap.c
> +++ b/arch/powerpc/kernel/iomap.c
> @@ -15,23 +15,23 @@
> * Here comes the ppc64 implementation of the IOMAP
> * interfaces.
> */
> -unsigned int ioread8(void __iomem *addr)
> +unsigned int ioread8(const void __iomem *addr)
> {
> return readb(addr);
> }
> -unsigned int ioread16(void __iomem *addr)
> +unsigned int ioread16(const void __iomem *addr)
> {
> return readw(addr);
> }
> -unsigned int ioread16be(void __iomem *addr)
> +unsigned int ioread16be(const void __iomem *addr)
> {
> return readw_be(addr);
> }
> -unsigned int ioread32(void __iomem *addr)
> +unsigned int ioread32(const void __iomem *addr)
> {
> return readl(addr);
> }
> -unsigned int ioread32be(void __iomem *addr)
> +unsigned int ioread32be(const void __iomem *addr)
> {
> return readl_be(addr);
> }
> @@ -41,27 +41,27 @@ EXPORT_SYMBOL(ioread16be);
> EXPORT_SYMBOL(ioread32);
> EXPORT_SYMBOL(ioread32be);
> #ifdef __powerpc64__
> -u64 ioread64(void __iomem *addr)
> +u64 ioread64(const void __iomem *addr)
> {
> return readq(addr);
> }
> -u64 ioread64_lo_hi(void __iomem *addr)
> +u64 ioread64_lo_hi(const void __iomem *addr)
> {
> return readq(addr);
> }
> -u64 ioread64_hi_lo(void __iomem *addr)
> +u64 ioread64_hi_lo(const void __iomem *addr)
> {
> return readq(addr);
> }
> -u64 ioread64be(void __iomem *addr)
> +u64 ioread64be(const void __iomem *addr)
> {
> return readq_be(addr);
> }
> -u64 ioread64be_lo_hi(void __iomem *addr)
> +u64 ioread64be_lo_hi(const void __iomem *addr)
> {
> return readq_be(addr);
> }
> -u64 ioread64be_hi_lo(void __iomem *addr)
> +u64 ioread64be_hi_lo(const void __iomem *addr)
> {
> return readq_be(addr);
> }
> @@ -139,15 +139,15 @@ EXPORT_SYMBOL(iowrite64be_hi_lo);
> * FIXME! We could make these do EEH handling if we really
> * wanted. Not clear if we do.
> */
> -void ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
> +void ioread8_rep(const void __iomem *addr, void *dst, unsigned long count)
> {
> readsb(addr, dst, count);
> }
> -void ioread16_rep(void __iomem *addr, void *dst, unsigned long count)
> +void ioread16_rep(const void __iomem *addr, void *dst, unsigned long count)
> {
> readsw(addr, dst, count);
> }
> -void ioread32_rep(void __iomem *addr, void *dst, unsigned long count)
> +void ioread32_rep(const void __iomem *addr, void *dst, unsigned long count)
> {
> readsl(addr, dst, count);
> }
This looks OK to me.
Acked-by: Michael Ellerman (powerpc)
cheers
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
On Thu, Mar 12, 2020 at 11:49:05AM +0100, Thomas Zimmermann wrote: > Hi Krzysztof, > > I just received a resend email from 3 weeks ago :/ > > Do you want me to merge the mgag200 patch into drm-misc-next? Thanks but it depends on the first patch in the series so either it could go with your ack through other tree or I will send it later (once 1st patch gets to mainline). Best regards, Krzysztof ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 1/2] drm/radeon: Stop directly referencing iomem
pci_platform_rom() returns an __iomem pointer which should not be
accessed directly. Change radeon_read_platform_bios() to use
memcpy_fromio() instead of calling kmemdup() on the __iomem pointer.
Signed-off-by: Mikel Rychliski
---
drivers/gpu/drm/radeon/radeon_bios.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index c42f73fad3e3..c3ae4c92a115 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -118,11 +118,14 @@ static bool radeon_read_platform_bios(struct
radeon_device *rdev)
return false;
}
- if (size == 0 || bios[0] != 0x55 || bios[1] != 0xaa) {
+ rdev->bios = kzalloc(size, GFP_KERNEL);
+ if (!rdev->bios)
return false;
- }
- rdev->bios = kmemdup(bios, size, GFP_KERNEL);
- if (rdev->bios == NULL) {
+
+ memcpy_fromio(rdev->bios, bios, size);
+
+ if (size == 0 || rdev->bios[0] != 0x55 || rdev->bios[1] != 0xaa) {
+ kfree(rdev->bios);
return false;
}
--
2.13.7
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 0/6] gpu: convert to use new I2C API
We are deprecating calls which return NULL in favor of new variants which return an ERR_PTR. Only build tested. Wolfram Sang (6): drm/amdgpu: convert to use i2c_new_client_device() drm/gma500: convert to use i2c_new_client_device() drm/i2c/sil164: convert to use i2c_new_client_device() drm/i2c/tda998x: convert to use i2c_new_client_device() drm/nouveau/therm: convert to use i2c_new_client_device() drm/radeon: convert to use i2c_new_client_device() drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 2 +- drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 8 drivers/gpu/drm/i2c/sil164_drv.c | 7 +-- drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++--- drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++-- drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++-- drivers/gpu/drm/radeon/radeon_combios.c| 4 ++-- 7 files changed, 19 insertions(+), 16 deletions(-) -- 2.20.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 0/9] drm/nouveau: Introduce CRC support for gf119+
Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrjälä came up with: vblank works. Basically, this is just a generic DRM interface that allows for scheduling high-priority workers that start on a given vblank interrupt. Note that while we're currently only using this in nouveau, Intel has plans to use this for i915 as well (hence why they came up with it!). Anyway-welcome to the future! :) Lyude Paul (8): drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create() drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit drm/nouveau/kms/nv50-: Fix disabling dithering drm/nouveau/kms/nv50-: s/harm/armh/g drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h drm/nouveau/kms/nv50-: Move hard-coded object handles into header drm/nouveau/kms/nvd9-: Add CRC support Ville Syrjälä (1): drm/vblank: Add vblank works drivers/gpu/drm/drm_vblank.c| 322 + drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 21 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 716 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 65 +- drivers/gpu/drm/nouveau/dispnv50/disp.h | 24 + drivers/gpu/drm/nouveau/dispnv50/handles.h | 16 + drivers/gpu/drm/nouveau/dispnv50/head.c | 142 +++- drivers/gpu/drm/nouveau/dispnv50/head.h | 13 +- drivers/gpu/drm/nouveau/dispnv50/head907d.c | 14 +- drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 27 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 20 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 15 +- drivers/gpu/drm/nouveau/nouveau_display.c | 60 +- include/drm/drm_vblank.h| 34 + 24 files changed, 1821 insertions(+), 130 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.h create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc907d.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h -- 2.24.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/2] mm/thp: Rename pmd_mknotpresent() as pmd_mknotvalid()
pmd_present() is expected to test positive after pmdp_mknotpresent() as the
PMD entry still points to a valid huge page in memory. pmdp_mknotpresent()
implies that given PMD entry is just invalidated from MMU perspective while
still holding on to pmd_page() referred valid huge page thus also clearing
pmd_present() test. This creates the following situation which is counter
intuitive.
[pmd_present(pmd_mknotpresent(pmd)) = true]
This renames pmd_mknotpresent() as pmd_mknotvalid() reflecting the helper's
functionality more accurately while changing the above mentioned situation
as follows. This does not create any functional change.
[pmd_present(pmd_mknotvalid(pmd)) = true]
This is not applicable for platforms that define own pmdp_invalidate() via
__HAVE_ARCH_PMDP_INVALIDATE. Suggestion for renaming came during a previous
discussion here.
https://patchwork.kernel.org/patch/11019637/
Cc: Vineet Gupta
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas Bogendoerfer
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Steven Rostedt
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: nouveau@lists.freedesktop.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Suggested-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arc/include/asm/hugepage.h | 2 +-
arch/arm/include/asm/pgtable-3level.h | 2 +-
arch/arm64/include/asm/pgtable.h | 2 +-
arch/mips/include/asm/pgtable.h | 2 +-
arch/x86/include/asm/pgtable.h| 2 +-
arch/x86/mm/kmmio.c | 2 +-
mm/pgtable-generic.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arc/include/asm/hugepage.h b/arch/arc/include/asm/hugepage.h
index 30ac40fed2c5..98d56267050f 100644
--- a/arch/arc/include/asm/hugepage.h
+++ b/arch/arc/include/asm/hugepage.h
@@ -26,7 +26,7 @@ static inline pmd_t pte_pmd(pte_t pte)
#define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
#define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd)))
#define pmd_mkhuge(pmd)pte_pmd(pte_mkhuge(pmd_pte(pmd)))
-#define pmd_mknotpresent(pmd) pte_pmd(pte_mknotpresent(pmd_pte(pmd)))
+#define pmd_mknotvalid(pmd)pte_pmd(pte_mknotpresent(pmd_pte(pmd)))
#define pmd_mkclean(pmd) pte_pmd(pte_mkclean(pmd_pte(pmd)))
#define pmd_write(pmd) pte_write(pmd_pte(pmd))
diff --git a/arch/arm/include/asm/pgtable-3level.h
b/arch/arm/include/asm/pgtable-3level.h
index ad55ab068dbf..2943cdf2828b 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -241,7 +241,7 @@ PMD_BIT_FUNC(mkyoung, |= PMD_SECT_AF);
#define pmdp_establish generic_pmdp_establish
/* represent a notpresent pmd by faulting entry, this is used by
pmdp_invalidate */
-static inline pmd_t pmd_mknotpresent(pmd_t pmd)
+static inline pmd_t pmd_mknotvalid(pmd_t pmd)
{
return __pmd(pmd_val(pmd) & ~L_PMD_SECT_VALID);
}
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 538c85e62f86..28cdd97578a5 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -366,7 +366,7 @@ static inline int pmd_protnone(pmd_t pmd)
#define pmd_mkclean(pmd) pte_pmd(pte_mkclean(pmd_pte(pmd)))
#define pmd_mkdirty(pmd) pte_pmd(pte_mkdirty(pmd_pte(pmd)))
#define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd)))
-#define pmd_mknotpresent(pmd) (__pmd(pmd_val(pmd) & ~PMD_SECT_VALID))
+#define pmd_mknotvalid(pmd)(__pmd(pmd_val(pmd) & ~PMD_SECT_VALID))
#define pmd_thp_or_huge(pmd) (pmd_huge(pmd) || pmd_trans_huge(pmd))
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index aef5378f909c..2a66dee3a9b8 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -615,7 +615,7 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
return pmd;
}
-static inline pmd_t pmd_mknotpresent(pmd_t pmd)
+static inline pmd_t pmd_mknotvalid(pmd_t pmd)
{
pmd_val(pmd) &= ~(_PAGE_PRESENT | _PAGE_VALID | _PAGE_DIRTY);
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 7e118660bbd9..6279668d430f 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -589,7 +589,7 @@ static inline pud_t pfn_pud(unsigned long page_nr, pgprot_t
pgprot)
return __pud(pfn | check_pgprot(pgprot));
}
-static inline pmd_t pmd_mknotpresent(pmd_t pmd)
+static inline pmd_t pmd_mknotvalid(pmd_t pmd)
{
return pfn_pmd(pmd_pfn(pmd),
__pgprot(pmd_flags(pmd) &
~(_PAGE_PRESENT|_PAGE_PROTNONE)));
diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
index 49d7814b59a9..f9f61b934475 100644
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@
Re: [Nouveau] [RESEND PATCH v2 8/9] media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation)
On 2/19/20 6:50 PM, Krzysztof Kozlowski wrote: > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Hans Verkuil Regards, Hans > --- > drivers/media/platform/fsl-viu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/fsl-viu.c > b/drivers/media/platform/fsl-viu.c > index 81a8faedbba6..991d9dc82749 100644 > --- a/drivers/media/platform/fsl-viu.c > +++ b/drivers/media/platform/fsl-viu.c > @@ -34,7 +34,7 @@ > /* Allow building this driver with COMPILE_TEST */ > #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) > #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) > -#define in_be32(a) ioread32be((void __iomem *)a) > +#define in_be32(a) ioread32be((const void __iomem *)a) > #endif > > #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
Hi Am 14.03.20 um 11:59 schrieb Krzysztof Kozlowski: > On Thu, Mar 12, 2020 at 11:49:05AM +0100, Thomas Zimmermann wrote: >> Hi Krzysztof, >> >> I just received a resend email from 3 weeks ago :/ >> >> Do you want me to merge the mgag200 patch into drm-misc-next? > > Thanks but it depends on the first patch in the series so either it > could go with your ack through other tree or I will send it later (once > 1st patch gets to mainline). Ok. You're welcome to send it through any tree that works best for you. mgag200 sees only little change. I wouldn't expect major merge conflicts, if any. Best regards Thomas > > > Best regards, > Krzysztof > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 0/2] Fix loading of platform ROM from 32-bit EFI
This patch series fixes an oops when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use ioremap(), not phys_to_virt() for platform ROM drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 11 ++- drivers/gpu/drm/radeon/radeon_bios.c | 12 drivers/pci/rom.c| 9 ++--- 4 files changed, 25 insertions(+), 8 deletions(-) -- 2.13.7 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RESEND PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
On Wed, Feb 19, 2020 at 06:49:59PM +0100, Krzysztof Kozlowski wrote: > The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On > some architectures void *__iomem address argument is a pointer to const, > on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Suggested-by: Geert Uytterhoeven > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Geert Uytterhoeven > Reviewed-by: Arnd Bergmann Hi Arnd, This patch touches multipel file systems so no one is brave enough to pick it up. However you are mentioned as maintainer of generic asm headers so maybe you could apply it to arm-soc? Best regards, Krzysztof > > --- > > Changes since v1: > 1. Constify also ioreadX_rep() and mmio_insX(), > 2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability, > 3. Add Geert's review. > 4. Add Arnd's review. > --- > arch/alpha/include/asm/core_apecs.h | 6 +-- > arch/alpha/include/asm/core_cia.h | 6 +-- > arch/alpha/include/asm/core_lca.h | 6 +-- > arch/alpha/include/asm/core_marvel.h | 4 +- > arch/alpha/include/asm/core_mcpcia.h | 6 +-- > arch/alpha/include/asm/core_t2.h | 2 +- > arch/alpha/include/asm/io.h | 12 ++--- > arch/alpha/include/asm/io_trivial.h | 16 +++--- > arch/alpha/include/asm/jensen.h | 2 +- > arch/alpha/include/asm/machvec.h | 6 +-- > arch/alpha/kernel/core_marvel.c | 2 +- > arch/alpha/kernel/io.c| 12 ++--- > arch/parisc/include/asm/io.h | 4 +- > arch/parisc/lib/iomap.c | 72 +-- > arch/powerpc/kernel/iomap.c | 28 +-- > arch/sh/kernel/iomap.c| 22 > include/asm-generic/iomap.h | 28 +-- > include/linux/io-64-nonatomic-hi-lo.h | 4 +- > include/linux/io-64-nonatomic-lo-hi.h | 4 +- > lib/iomap.c | 30 +-- > 20 files changed, 136 insertions(+), 136 deletions(-) > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v2 2/2] PCI: Use ioremap(), not phys_to_virt() for platform ROM
On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the radeon module on a x86_32 kernel
can result in the following:
BUG: unable to handle page fault for address: 3e8ed03c
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
*pde =
Oops: [#1] PREEMPT SMP
CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2
Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS
MP11.88Z.005C.B08.0707021221 07/02/07
EIP: radeon_get_bios+0x5ed/0xe50 [radeon]
Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08
8b 55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78
01 aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06
EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001
ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206
CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0
Call Trace:
? register_client+0x34/0xe0
? register_client+0xab/0xe0
r520_init+0x26/0x240 [radeon]
radeon_device_init+0x533/0xa50 [radeon]
radeon_driver_load_kms+0x80/0x220 [radeon]
drm_dev_register+0xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
really_probe+0x13d/0x3b0
driver_probe_device+0x56/0xd0
device_driver_attach+0x49/0x50
__driver_attach+0x79/0x130
? device_driver_attach+0x50/0x50
bus_for_each_dev+0x5b/0xa0
driver_attach+0x19/0x20
? device_driver_attach+0x50/0x50
bus_add_driver+0x117/0x1d0
? pci_bus_num_vf+0x20/0x20
driver_register+0x66/0xb0
? 0xf80f4000
__pci_register_driver+0x3d/0x40
radeon_init+0x82/0x1000 [radeon]
do_one_initcall+0x42/0x200
? kvfree+0x25/0x30
? __vunmap+0x206/0x230
? kmem_cache_alloc_trace+0x16f/0x220
? do_init_module+0x21/0x220
do_init_module+0x50/0x220
load_module+0x1f26/0x2200
sys_init_module+0x12d/0x160
do_fast_syscall_32+0x82/0x250
entry_SYSENTER_32+0xa5/0xf8
Fix the issue by using ioremap() instead of phys_to_virt() in
pci_platform_rom().
Now that pci_platform_rom() creates a new mapping to access the ROM
image, update all callers to remove this mapping after extracting the
BIOS.
Signed-off-by: Mikel Rychliski
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 11 ++-
drivers/gpu/drm/radeon/radeon_bios.c | 1 +
drivers/pci/rom.c| 9 ++---
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 50dff69a0f6e..ea6a1fa98ad9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -207,6 +207,7 @@ static bool amdgpu_read_platform_bios(struct amdgpu_device
*adev)
return false;
memcpy_fromio(adev->bios, bios, size);
+ iounmap(bios);
if (!check_atom_bios(adev->bios, size)) {
kfree(adev->bios);
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da09dc5f..8a60a0db7b14 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -111,11 +111,20 @@ platform_init(struct nvkm_bios *bios, const char *name)
return ERR_PTR(ret);
}
+static void
+platform_fini(void *data)
+{
+ struct priv *priv = data;
+
+ iounmap(priv->rom);
+ kfree(priv);
+}
+
const struct nvbios_source
nvbios_platform = {
.name = "PLATFORM",
.init = platform_init,
- .fini = (void(*)(void *))kfree,
+ .fini = platform_fini,
.read = pcirom_read,
.rw = true,
};
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios.c
index c3ae4c92a115..712b88d88957 100644
--- a/drivers/gpu/drm/radeon/radeon_bios.c
+++ b/drivers/gpu/drm/radeon/radeon_bios.c
@@ -123,6 +123,7 @@ static bool radeon_read_platform_bios(struct radeon_device
*rdev)
return false;
memcpy_fromio(rdev->bios, bios, size);
+ iounmap(bios);
if (size == 0 || rdev->bios[0] != 0x55 || rdev->bios[1] != 0xaa) {
kfree(rdev->bios);
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 137bf0cee897..b38257d23e6e 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -197,16 +197,19 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem
*rom)
EXPORT_SYMBOL(pci_unmap_rom);
/**
- *
Re: [Nouveau] [RESEND PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof, I just received a resend email from 3 weeks ago :/ Do you want me to merge the mgag200 patch into drm-misc-next? Best regards Thomas Am 19.02.20 um 18:50 schrieb Krzysztof Kozlowski: > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Thomas Zimmermann > > --- > > Changes since v1: > 1. Add Thomas' review. > --- > drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h > b/drivers/gpu/drm/mgag200/mgag200_drv.h > index aa32aad222c2..6512b3af4fb7 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h > @@ -34,9 +34,9 @@ > > #define MGAG200FB_CONN_LIMIT 1 > > -#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg)) > +#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg)) > #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg)) > -#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg)) > +#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg)) > #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg)) > > #define ATTR_INDEX 0x1fc0 > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 5/6] drm/nouveau/therm: convert to use i2c_new_client_device()
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
index 03b355dabab3..abf3eda683f0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
@@ -36,8 +36,8 @@ probe_monitoring_device(struct nvkm_i2c_bus *bus,
request_module("%s%s", I2C_MODULE_PREFIX, info->type);
- client = i2c_new_device(>i2c, info);
- if (!client)
+ client = i2c_new_client_device(>i2c, info);
+ if (IS_ERR(client))
return false;
if (!client->dev.driver ||
--
2.20.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 0/2] mm/thp: Rename pmd_mknotpresent() as pmd_mknotvalid()
On 03/20/2020 10:24 AM, Anshuman Khandual wrote: > This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it > drops an existing pmd_mknotpresent() definition from powerpc platform which > was never required as it defines it's pmdp_invalidate() through subscribing > __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. > > This rename was suggested by Catalin during a previous discussion while we > were trying to change the THP helpers on arm64 platform for migration. > > https://patchwork.kernel.org/patch/11019637/ > > This series is based on v5.6-rc6. > > Boot tested on arm64 and x86 platforms. > Built tested on many other platforms including the ones changed here. Gentle ping, any updates regarding this ? ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 0/2] mm/thp: Rename pmd_mknotpresent() as pmd_mknotvalid()
This series renames pmd_mknotpresent() as pmd_mknotvalid(). Before that it drops an existing pmd_mknotpresent() definition from powerpc platform which was never required as it defines it's pmdp_invalidate() through subscribing __HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change. This rename was suggested by Catalin during a previous discussion while we were trying to change the THP helpers on arm64 platform for migration. https://patchwork.kernel.org/patch/11019637/ This series is based on v5.6-rc6. Boot tested on arm64 and x86 platforms. Built tested on many other platforms including the ones changed here. Cc: Benjamin Herrenschmidt Cc: Michael Ellerman Cc: Paul Mackerras Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Steven Rostedt Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Andrew Morton Cc: nouveau@lists.freedesktop.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-snps-...@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-m...@vger.kernel.org Cc: x...@kernel.org Cc: linux...@kvack.org Cc: linux-ker...@vger.kernel.org Anshuman Khandual (2): powerpc/mm: Drop platform defined pmd_mknotpresent() mm/thp: Rename pmd_mknotpresent() as pmd_mknotvalid() arch/arc/include/asm/hugepage.h | 2 +- arch/arm/include/asm/pgtable-3level.h| 2 +- arch/arm64/include/asm/pgtable.h | 2 +- arch/mips/include/asm/pgtable.h | 2 +- arch/powerpc/include/asm/book3s/64/pgtable.h | 4 arch/x86/include/asm/pgtable.h | 2 +- arch/x86/mm/kmmio.c | 2 +- mm/pgtable-generic.c | 2 +- 8 files changed, 7 insertions(+), 11 deletions(-) -- 2.20.1 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH -next 000/491] treewide: use fallthrough;
There is a new fallthrough pseudo-keyword macro that can be used
to replace the various /* fallthrough */ style comments that are
used to indicate a case label code block is intended to fallthrough
to the next case label block.
See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough'
pseudo keyword for switch/case use")
These patches are intended to allow clang to detect missing
switch/case fallthrough uses.
Do a depth-first pass on the MAINTAINERS file and find the various
F: pattern files and convert the fallthrough comments to fallthrough;
for all files matched by all F: patterns in in each section.
Done via the perl script below and the previously posted
cvt_fallthrough.pl script.
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
These patches are based on next-20200310 and are available in
git://repo.or.cz/linux-2.6/trivial-mods.git in branch 20200310_fallthrough_2
$ cat commit_fallthrough.pl
#!/usr/bin/env perl
use sort 'stable';
#
# Reorder a sorted array so file entries are before directory entries
# depends on a trailing / for directories
# so:
# foo/
# foo/bar.c
# becomes
# foo/bar.c
# foo/
#
sub file_before_directory {
my ($array_ref) = (@_);
my $count = scalar(@$array_ref);
for (my $i = 1; $i < $count; $i++) {
if (substr(@$array_ref[$i - 1], -1) eq '/' &&
substr(@$array_ref[$i], 0, length(@$array_ref[$i - 1])) eq
@$array_ref[$i - 1]) {
my $string = @$array_ref[$i - 1];
@$array_ref[$i - 1] = @$array_ref[$i];
@$array_ref[$i] = $string;
}
}
}
sub uniq {
my (@parms) = @_;
my %saw;
@parms = grep(!$saw{$_}++, @parms);
return @parms;
}
# Get all the F: file patterns in MAINTAINERS that could be a .[ch] file
my $maintainer_patterns = `grep -P '^F:\\s+' MAINTAINERS`;
my @patterns = split('\n', $maintainer_patterns);
s/^F:\s*// for @patterns;
@patterns = grep(!/^(?:Documentation|tools|scripts)\//, @patterns);
@patterns = grep(!/\.(?:dtsi?|rst|config)$/, @patterns);
@patterns = sort @patterns;
@patterns = sort { $b =~ tr/\//\// cmp $a =~ tr/\//\// } @patterns;
file_before_directory(\@patterns);
my %sections_done;
foreach my $pattern (@patterns) {
# Find the files the pattern matches
my $pattern_files = `git ls-files -- $pattern`;
my @new_patterns = split('\n', $pattern_files);
$pattern_files = join(' ', @new_patterns);
next if ($pattern_files =~ /^\s*$/);
# Find the section the first file matches
my $pattern_file = @new_patterns[0];
my $section_output = `./scripts/get_maintainer.pl --nogit --nogit-fallback
--sections --pattern-depth=1 $pattern_file`;
my @section = split('\n', $section_output);
my $section_header = @section[0];
print("Section: <$section_header>\n");
# Skip the section if it's already done
print("Already done '$section_header'\n") if
($sections_done{$section_header});
next if ($sections_done{$section_header}++);
# Find all the .[ch] files in all F: lines in that section
my @new_section;
foreach my $line (@section) {
last if ($line =~ /^\s*$/);
push(@new_section, $line);
}
@section = grep(/^F:/, @new_section);
s/^F:\s*// for @section;
@section = grep(!/^(?:Documentation|tools|scripts)\//, @section);
@section = grep(!/\.(?:dtsi?|rst|config)$/, @section);
@section = sort @section;
@section = uniq(@section);
my $section_files = join(' ', @section);
print("section_files: <$section_files>\n");
next if ($section_files =~ /^\s*$/);
my $cvt_files = `git ls-files -- $section_files`;
my @files = split('\n', $cvt_files);
@files = grep(!/^(?:Documentation|tools|scripts)\//, @files);
@files = grep(!/\.(?:dtsi?|rst|config)$/, @files);
@files = grep(/\.[ch]$/, @files);
@files = sort @files;
@files = uniq(@files);
$cvt_files = join(' ', @files);
print("files: <$cvt_files>\n");
next if (scalar(@files) < 1);
# Convert fallthroughs for all [.ch] files in the section
print("doing cvt_fallthrough.pl -- $cvt_files\n");
`cvt_fallthrough.pl -- $cvt_files`;
# If nothing changed, nothing to commit
`git diff-index --quiet HEAD --`;
next if (!$?);
# Commit the changes
my $fh;
open($fh, "+>", "cvt_fallthrough.commit_msg") or die "$0: can't create
temporary file: $!\n";
print $fh
[Nouveau] Status of GF108GLM [NVS 5200M]
Hello. I am not subscribed to the list, so, please, if I do anything wrong just let me know politely and I'll try to improve :) I just want to know if there's any branch of nouveau version that will work with this chip. lspci lists it as: 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1) I think it's Fermi, but I am not sure. When I try to change pstate it says: # LC_ALL=C echo '0f' > /sys/kernel/debug/dri/1/pstate bash: echo: write error: Function not implemented # LC_ALL=C cat /sys/kernel/debug/dri/1/pstate 03: core 50 MHz memory 135 MHz 07: core 202 MHz memory 324 MHz 0f: core 672 MHz memory 1569 MHz AC: core 0 MHz memory 0 MHz It's worth noting that's a secondary gpu. I just use the intel chip for everyday's work, but I have some free days and I am trying to get the secondary one working and put it to good use, if possible. Thanks for any help you can provide. Please, CC me, as said, I am not subscribed to the list even though I'll try to keep an eye on this. -- Jesús Guerrero Botella ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
