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; Deuche
[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)
>
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 automati
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.
>
>
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
> ind
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 t
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
> *
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 t
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 cha
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()
dr
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 add
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 cleari
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
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
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 platfo
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
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 rad
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 addres
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
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_
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.
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'
pse
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 GF1
23 matches
Mail list logo