[PATCH] drm/radeon: Add early unregister of firmware fb's

Without this, we attempt the handover too late, the firmware fb might be accessing the chip simultaneously to us re-initializing various parts of it, which might frighten babies or cause all sort of nasty psychologic trauma to kitten. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org

Re: [PATCH] drm/radeon: Add early unregister of firmware fb's

On Mon, 2010-08-16 at 09:00 +0200, Rafał Miłecki wrote: 2010/8/10 Benjamin Herrenschmidt b...@kernel.crashing.org: +#ifdef CONFIG_X86 + primary = dev-pdev-resource[PCI_ROM_RESOURCE].flags IORESOURCE_ROM_SHADOW; +#endif It won't compile for CONFIG_X86, no dev. Ah right, I've done

Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?

On Wed, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote: Well, X is dead, or rather in an infinite ioctl loop as described above. IIRC, the display enters a power-down mode and there is nothing to see. So basically the card crashed. There's about an infinite amount of reasons why radeons

Re: [PATCH] Big Endian support for RV730 (Mesa r600)

On Tue, 2011-04-12 at 10:01 +0200, Cédric Cano wrote: Hi Here you are a patch that adds big endian support for rv730 in r600 classic mesa driver. The BE modifications are almost the same as the DRM / DDX driver modifications

Re: [PATCH] Big Endian support for RV730 (Mesa r600)

On Wed, 2011-04-13 at 22:05 +1000, Benjamin Herrenschmidt wrote: On Tue, 2011-04-12 at 10:01 +0200, Cédric Cano wrote: Hi Here you are a patch that adds big endian support for rv730 in r600 classic mesa driver. The BE modifications are almost the same as the DRM / DDX driver

Re: [PATCH] agp/uninorth: Fix lockups with radeon KMS and 1x.

daen...@vmware.com Oops. I do have a pile of patches, but I never got something stable enough and got distracted by more important stuff. Dave, please merge this for now. Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org Thanks ! Cheers, Ben. --- drivers/char/agp/uninorth-agp.c |2

[PATCH 6/6] drm/radeon: Fix the definition of RADEON_BUF_SWAP_32BIT

(Note that this is duplicated under various other names such as R600_BUF_SWAP_32BIT etc...). At least now all the definitions agree. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- (resent adding dri-devel to the CC list to hit patchwork) drivers/gpu/drm/radeon/radeon_reg.h

[PATCH 4/6] drm/radeon: Add a rmb() in IH processing

an explicit one just in case. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- (resent adding dri-devel to the CC list to hit patchwork) drivers/gpu/drm/radeon/r600.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600.c b

[PATCH 5/6] drm/radeon: Do an MMIO read on interrupts when not uisng MSIs

and the system. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- (resent adding dri-devel to the CC list to hit patchwork) drivers/gpu/drm/radeon/r600.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm

[PATCH 1/6] drm/radeon: Remove a bunch of useless _iomem casts

Just defining rdev-rmmio properly in the first place should do the trick. In some cases, the cast were also complete dups as the original variable was already of the right type. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- (resent adding dri-devel to the CC list to hit

[PATCH 3/6] drm/radeon: Writeback endian fixes

with the surrounding code. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- (resent adding dri-devel to the CC list to hit patchwork) drivers/gpu/drm/radeon/evergreen.c |3 --- drivers/gpu/drm/radeon/r600.c |7 --- drivers/gpu/drm/radeon/r600_cp.c | 23

Re: [PATCH 2/6] drm/radeon: ATOM Endian fix for atombios_crtc_program_pll()

On Wed, 2011-07-13 at 10:38 -0400, Alex Deucher wrote: case 6: - args.v6.ulCrtcPclkFreq.ucCRTC = crtc_id; - args.v6.ulCrtcPclkFreq.ulPixelClock = cpu_to_le32(clock / 10); + args.v6.ulDispEngClkFreq =

Re: [PATCH 3/6] drm/radeon: Writeback endian fixes

On Wed, 2011-07-13 at 10:42 -0400, Alex Deucher wrote: On Wed, Jul 13, 2011 at 2:28 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: The writeback ring pointer and IH ring pointer are read using le32_to_cpu so we do not want the chip to byteswap them on big-endian. We still

Re: [PATCH 4/6] drm/radeon: Add a rmb() in IH processing

On Wed, 2011-07-13 at 10:48 -0400, Alex Deucher wrote: On Wed, Jul 13, 2011 at 10:43 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jul 13, 2011 at 2:28 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: We should have a read memory barrier between reading the WPTR from

Re: [PATCH 3/6] drm/radeon: Writeback endian fixes

On Thu, 2011-07-14 at 17:19 +0200, Michel Dänzer wrote: On Mit, 2011-07-13 at 16:28 +1000, Benjamin Herrenschmidt wrote: The writeback ring pointer and IH ring pointer are read using le32_to_cpu so we do not want the chip to byteswap them on big-endian. We still want to byteswap the ring

Re: [PATCH 4/6] drm/radeon: Add a rmb() in IH processing

On Fri, 2011-07-15 at 04:19 +, Matt Turner wrote: On Wed, Jul 13, 2011 at 6:28 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: We should have a read memory barrier between reading the WPTR from memory and reading ring entries based on that value (ie, we need to ensure both

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

On Wed, 2012-02-15 at 03:23 +0100, acrux wrote: On Sun, 12 Feb 2012 11:00:43 +0100 Michel Dänzer mic...@daenzer.net wrote: On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: Just a curiosity, i've only two powerpc machines[1] equipped with PCIE videocards and both them are not able

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote: Btw, to sum up the list of Power Architecture machines with PCIE that aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last two, on present

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

On Thu, 2012-02-16 at 08:50 +0100, Michel Dänzer wrote: The second case with no firmware is a bit more surprising, looks like something bad happened on the PCI express bus or the kernel tried to access something that the card rejected (target abort or PCIe equivalent most likely), thus

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

On Thu, 2012-02-16 at 09:26 +0100, Michel Dänzer wrote: For that one, I'd try adding some more debugging output to radeon_get_bios() to find out which method it ends up using to retrieve the ROM contents, and why it doesn't look like it's an ATOM BIOS. Is it an Apple card or an x86

Re: WARNING: at drivers/gpu/drm/radeon/radeon_object.c:236

On Tue, 2012-03-27 at 20:21 -0400, Dave Jones wrote: Stops the warning, and there are no additional side-effects, so looks all good here. Same. Tested-by: Dave Jones da...@redhat.com Tested-by: Benjamin Herrenschmidt b...@kernel.crashing.org thanks, Dave

broken nouveau dependency on power supply

Hi folks ! With CONFIG_POWER_SUPPLY=m nouveau built-in we get a build failure: drivers/built-in.o: In function `.nouveau_pm_trigger': (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied' nouveau probably needs to depends on CONFIG_POWER_SUPPLY to force a module build with

[PATCH] nouveau: Fix crash when pci_ram_rom() returns a size of 0

From b15b244d6e6e20964bd4b85306722cb60c3c0809 Mon Sep 17 00:00:00 2001 From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Mon, 2 Apr 2012 13:28:18 +1000 Subject: Under some circumstances, pci_map_rom() can return a valid mapping but a size of 0 (if it cannot find an image in the header

[PATCH] nouveau/bios: Fix tracking of BIOS image data

-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- This was found by code inspection while chasing a different bug, I do not hit the problem path on my machine. drivers/gpu/drm/nouveau/nouveau_bios.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm

Re: broken nouveau dependency on power supply

On Mon, 2012-04-02 at 11:06 +1000, Benjamin Herrenschmidt wrote: Hi folks ! With CONFIG_POWER_SUPPLY=m nouveau built-in we get a build failure: drivers/built-in.o: In function `.nouveau_pm_trigger': (.text+0xa56e8): undefined reference to `.power_supply_is_system_supplied' nouveau

Re: broken nouveau dependency on power supply

On Mon, 2012-04-02 at 05:00 -0400, David Airlie wrote: - Better: Just make the bloody thing a bool :-) The power supply framework itself is small enough, just make it a boolean option and avoid the problem entirely. The actual power supply sub drivers can remain modular of course. We

Re: Oops with Radeon/Uninorth on Maple

On Thu, 2012-05-24 at 10:18 +0400, Dmitry Eremin-Solenikov wrote: Hello, colleagues, I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX board, with CPC925 (U3H) north bridge). For now I'm stuck with a problem: I use radeon card, drm-radeon driver with KMS. If

[PATCH 4/6] drm/cirrus: Proper support for depth 15 and 16

We were configuring SR7 very strangely for 16bpp and didn't properly differenciate between depth 15 and 16. This fixes it (and both appear to work at least on ppc) Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- drivers/gpu/drm/cirrus/cirrus_mode.c |5 +++-- 1 file changed

[PATCH 3/6] drm/cirrus: Workaround for HDR access

is initialized in such a way that it overflows if you start doing the 4-reads sequence right after reset, and thus fails to pickup the subsequent write. We work around this by doing a write before the 4 reads, which resets the counter properly. Signed-off-by: Benjamin Herrenschmidt b

[PATCH 2/6] drm/fb: Fix depth 15 support in drm_fb_helper.c

fbset can pass var-bits_per_pixel = 15 when doing fbset -depth 15, so we need to correct that to bpp 16 / depth 15. Additionally, we make it possible to pass 15 as an argument to drm_fb_helper_single_fb_probe() which will similarily select a bpp of 15 and a depth of 15. Signed-off-by: Benjamin

[PATCH 5/6] drm/cirrus: Check for pitch limits rather than bpp limits

). Additionally, we make the fbdev code try reducing the bpp if it hits the pitch limit in order to improve the chances of displaying a console at boot if the default or requested mode is too large to fit. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- drivers/gpu/drm/cirrus

[PATCH 6/6] drm/cirrus: Retrieve default mode from the device-tree if any

it to set the default mode and depth. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- drivers/gpu/drm/cirrus/cirrus_fbdev.c |3 +-- drivers/gpu/drm/cirrus/cirrus_mode.c | 37 + 2 files changed, 34 insertions(+), 6 deletions(-) diff --git

[PATCH 1/6] drm/fb: Enable choosing a preferred noedid mode

This adds a preferred argument to drm_add_modes_noedid() which allow drivers such as cirrusdrmfb to select a preferred mode based on firmware configuration Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- drivers/gpu/drm/cirrus/cirrus_mode.c |8 +++- drivers/gpu/drm

Re: [PATCHv2 3/3] ppc64: implemented pcibios_get_speed_cap_mask

On Wed, 2013-03-20 at 02:24 -0300, Lucas Kannebley Tavares wrote: Implementation of a architecture-specific pcibios_get_speed_cap_mask. This implementation detects bus capabilities based on OF ibm,pcie-link-speed-stats property. The problem with your approach is that it's not a runtime

Re: [PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: But we also know pdev is a PCIe device, and I think a PCIe device on a root bus must be a Root Complex Integrated Endpoint (PCIe spec sec 1.3.2.3). Such a device does not have a link at all, so there's no point in fiddling with its link

Re: [PATCHv5 0/2] Speed Cap fixes for ppc64

On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: This patch series does: 1. max_bus_speed is used to set the device to gen2 speeds 2. on power there's no longer a conflict between the pseries call and other architectures, because the overwrite is done via a ppc_md hook

Fixing nouveau for 4k PAGE_SIZE

Hi folks ! So I've been trying to figure out what it would take to make nouveau work properly on architectures where PAGE_SIZE isn't 4k such as most ppc64's. An initial patch from Dave fixed a bogon in nv41.c nv41_vm_map_sg() which was trying to handle the case at that low level, but this isn't

Re: Fixing nouveau for 4k PAGE_SIZE

On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: Now, to do that, I need a better understanding of the various things in there since I'm not familiar with nouveau at all. What I think I've figured out is with a few questions, it would be awesome if you could answer them so I

Re: Fixing nouveau for 4k PAGE_SIZE

On Sun, 2013-08-11 at 08:17 +0200, Maarten Lankhorst wrote: So I'm still a bit confused :-) The fun has been doubled because TTM expects PAGE units, so some of the PAGE_SHIFT's are genuine. Some may be a result of PAGE_SHIFT == 12, so honestly I don't know the specific ones. Right, and

Re: Fixing nouveau for 4k PAGE_SIZE

On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: I think I found at least two cases where 12 was used where it should have been PAGE_SHIFT (basically ttm_mem_reg-num_pages). This is only the tip of the iceberg, so this isn't a formal patch submission, but I would appreciate

Re: Fixing nouveau for 4k PAGE_SIZE

On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c index 5c7433d..c314a5f 100644 --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c +++

Re: [PATCH 2/2] drm/ast: Support AST2500

On Sat, 2017-02-18 at 15:43 +, Emil Velikov wrote: > > Out of curiosity - can you try testing with and w/o the ddr_test_2500 > bug fix(?). > Would be interesting to see if any of the omitted code [in > ast_dram_init_2500] has noticeable effect. Afaik, the original ddr_test_2500 from aspeed

Re: [PATCH 6/9] drm/ast: Factor mmc_test code in POST code

On Sat, 2017-02-18 at 15:28 +, Emil Velikov wrote: > Original code does the following data flexing only for the mmc_*test2 > code, while this patch adds it to both test and test2. > >    data = ast_mindwm(...); >    data = (data | (data >> 16)) & 0x; > //   ast_moutdwm(...); >

Re: [PATCH 2/2] drm/ast: Support AST2500

On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote: > > Heh ok. I don't want to change that POST code too much as I'm not > > equipped to test it, but I'll have a look later today. > > > > Not sure why you opted for splitting each suggestion in separate > email, but it seems to have lead to a

Re: [PATCH] drm/ast: Support AST2500

On Thu, 2017-02-16 at 14:24 +1000, Dave Airlie wrote: > On 11 January 2017 at 12:57, Y.C. Chen > wrote: > > From: "Y.C. Chen" > > Please run checkpatch over this patch, it's got a lot of bad > whitespace issues > (4 space and 2 space indents,

Re: [PATCH] drm/ast: Fixed system hanged if disable P2A

On Thu, 2017-01-26 at 09:45 +0800, Y.C. Chen wrote: > From: "Y.C. Chen" > > The original ast driver will access some BMC configuration through > P2A bridge > that can be disabled since AST2300 and after. > It will cause system hanged if P2A bridge is disabled. > Here is

Re: [PATCH] drm/ast: Fixed system hanged if disable P2A

isableP2A = true; > Else if the value of 0xf00x is not 0x_ then ast->DisableP2A = > false; Cheers, Ben. > Regards, > > Y.C. Chen > > -Original Message- > From: Benjamin Herrenschmidt [mailto:b...@au1.ibm.com]  > Sent: Thursday, February

Re: [PATCH] drm/ast: Support AST2500

On Wed, 2017-01-11 at 10:57 +0800, Y.C. Chen wrote: > From: "Y.C. Chen" > > Signed-off-by: Y.C. Chen > --- >  drivers/gpu/drm/ast/ast_drv.h|   2 + >  drivers/gpu/drm/ast/ast_main.c   |  27 ++- >  drivers/gpu/drm/ast/ast_mode.c   |  25 +- >  

Re: [PATCH 2/2] drm/ast: Support AST2500

On Fri, 2017-02-17 at 21:27 +, Emil Velikov wrote: > Hi Ben, .../... > Not sure why you opted for splitting each suggestion in separate > email, but it seems to have lead to a [serious] bugfix to go > unnoticed. Many thanks for your reviews. I've put a tentative new series there

Re: [PATCH 1/9] drm/ast: Handle configuration without P2A bridge

On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote: Make this From: Russell Currey <rus...@russell.cc> Git ate it when I amended (citool bug) and I forgot to fix it up. > The ast driver configures a window to enable access into BMC > memory space in order

[PATCH 7/9] drm/ast: Rename ast_init_dram_2300 to ast_post_chip_2300

The function does more than initializing the DRAM and in turns calls other functions to do the actual init. This will keeping things more consistent with the upcoming AST2500 POST code. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_post

[PATCH 2/9] drm/ast: const'ify mode setting tables

And fix some comment alignment & space/tabs while at it Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_drv.h| 4 +- drivers/gpu/drm/ast/ast_mode.c | 8 +-- drivers/gpu/drm/ast/ast_tables.h | 106 +++-

[PATCH 1/9] drm/ast: Handle configuration without P2A bridge

available from the device-tree, some sane defaults are used. Those defaults are hopefully sufficient for standard video modes used on a server. Signed-off-by: Russell Currey <rus...@russell.cc> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> -- v2. [BenH] - Rew

[PATCH 6/9] drm/ast: Factor mmc_test code in POST code

There's a lot of duplication for what's essentially N copies of the same loop, so factor it. The upcoming AST2500 POST code adds more of this. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_post.c | 76 ---

[PATCH 5/9] drm/ast: Base support for AST2500

ff-by: Y.C. Chen <yc_c...@aspeedtech.com> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- --- drivers/gpu/drm/ast/ast_drv.h| 2 ++ drivers/gpu/drm/ast/ast_main.c | 27 +-- drivers/gpu/drm/ast/ast_mode.c | 30 - drivers/g

[PATCH 8/9] drm/ast: POST code for the new AST2500

eedtech.com> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_dram_tables.h | 62 + drivers/gpu/drm/ast/ast_post.c| 410 +- 2 files changed, 470 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/

[PATCH 4/9] drm/ast: Fix calculation of MCLK

a bit more meaningful Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_main.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c index b593a53..eb6ba3e

Re: [PATCH 02/12] drm/ast: Handle configuration without P2A bridge

On Fri, 2017-02-24 at 12:51 +1030, Joel Stanley wrote: > > Are these properties supposed to repeat the prefix "ast,ast"? > > We've chosen aspeed as the vendor prefix for Aspeed stuff. Sent my reply too early ... so yes, I can change that, our FW hasn't merge the FW side yet. I'll respin now. >

[PATCH v5 2/12] drm/ast: Handle configuration without P2A bridge

available from the device-tree, some sane defaults are used. Those defaults are hopefully sufficient for standard video modes used on a server. Signed-off-by: Russell Currey <rus...@russell.cc> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> -- v2. [BenH] - Rew

[PATCH 09/12] drm/ast: Rename ast_init_dram_2300 to ast_post_chip_2300

The function does more than initializing the DRAM and in turns calls other functions to do the actual init. This will keeping things more consistent with the upcoming AST2500 POST code. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_post

[PATCH 11/12] drm/ast: Fix test for VGA enabled

From: "Y.C. Chen" <yc_c...@aspeedtech.com> (Get better description from Aspeed) Signed-off-by: Y.C. Chen <yc_c...@aspeedtech.com> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_post.c | 8 ++-- 1 file changed,

Re: [PATCH 02/12] drm/ast: Handle configuration without P2A bridge

On Fri, 2017-02-24 at 12:51 +1030, Joel Stanley wrote: > Are these properties supposed to repeat the prefix "ast,ast"? > > We've chosen aspeed as the vendor prefix for Aspeed stuff. Argh no, that's a typo... must have worked in my tests bcs the defaults are fine. I'll update. Cheers, Ben.

Re: [PATCH 05/12] drm/ast: Fix calculation of MCLK

On Fri, 2017-02-24 at 12:54 +1030, Joel Stanley wrote: > On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > Some braces were missing causing an incorrect calculation. > > > > Y.C. Chen from Aspeed provided me with the ri

[PATCH 10/12] drm/ast: POST code for the new AST2500

eedtech.com> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> -- v2. - Fix bug in ddr_test_2500 reported by Emil Velikov - Rebase on updated mmc_test factoring patch - Fix missing else statement in 2500 POST code --- drivers/gpu/drm/ast/ast_dram_tables.h | 6

[PATCH 01/12] drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS

From: "Y.C. Chen" <yc_c...@aspeedtech.com> The current POST code for the AST2300/2400 family doesn't work properly if the chip hasn't been initialized previously by either the BMC own FW or the VBIOS. This fixes it. Signed-off-by: Y.C. Chen <yc_c...@aspeedtech.com> S

[PATCH 03/12] drm/ast: const'ify mode setting tables

And fix some comment alignment & space/tabs while at it Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_drv.h| 4 +- drivers/gpu/drm/ast/ast_mode.c | 8 +-- drivers/gpu/drm/ast/ast_tables.h | 106 +++-

[PATCH 02/12] drm/ast: Handle configuration without P2A bridge

. If the window is closed and the configuration isn't available from the device-tree, some sane defaults are used. Those defaults are hopefully sufficient for standard video modes used on a server. Signed-off-by: Russell Currey <rus...@russell.cc> Signed-off-by: Benjamin Herrenschmidt <b...@ke

[PATCH 04/12] drm/ast: Remove spurrious include

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c index 36932a3..718c15b 100644 --- a/drivers/gpu/drm/ast/ast_main.c +++ b/d

[PATCH 12/12] drm/ast: Call open_key before enable_mmio in POST code

From: "Y.C. Chen" <yc_c...@aspeedtech.com> open_key enables access the registers used by enable_mmio Signed-off-by: Y.C. Chen <yc_c...@aspeedtech.com> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_post.c | 2 +- 1 fil

[PATCH 06/12] drm/ast: Base support for AST2500

ff-by: Y.C. Chen <yc_c...@aspeedtech.com> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- v2. Add 800Mhz default mclk for AST2500 --- drivers/gpu/drm/ast/ast_drv.h| 2 ++ drivers/gpu/drm/ast/ast_main.c | 32 +++--- drivers/g

[PATCH 08/12] drm/ast: Factor mmc_test code in POST code

There's a some duplication for what's essentially copies of two loops, so factor it. The upcoming AST2500 POST code adds more of them. Also cleanup return types for the test functions, most of them return a boolean, some return a u32. Signed-off-by: Benjamin Herrenschmidt &l

[PATCH 07/12] drm/ast: Fixed vram size incorrect issue on POWER

From: "Y.C. Chen" The default value of VGA scratch may incorrect. Should initial h/w before get vram info. Signed-off-by: Y.C. Chen --- drivers/gpu/drm/ast/ast_main.c | 6 +++--- drivers/gpu/drm/ast/ast_post.c | 2 +- 2 files changed, 4

[PATCH 05/12] drm/ast: Fix calculation of MCLK

a bit more meaningful Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_main.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c index 718c15b..d194af3

Re: [PATCH 01/12] drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS

Note: The whole series with the fixed cset comment for patch 11 can be also found there: https://github.com/ozbenh/linux-ast/commits/master Cheers, Ben. ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [PATCH 11/12] drm/ast: Fix test for VGA enabled

On Fri, 2017-02-24 at 09:53 +1100, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" <yc_c...@aspeedtech.com> > > (Get better description from Aspeed) And this should have been: << The test to see if VGA was already enabled is doing an unnecessary second test

Re: [PATCH 2/2] drm/ast: Support AST2500

On Thu, 2017-02-16 at 20:09 +1100, Benjamin Herrenschmidt wrote: > From: "Y.C. Chen" <yc_c...@aspeedtech.com> > > Add detection and POST code for AST2500 generation chip, > code originally from Aspeed and slightly reworked for > coding style mostly by Ben. I jus

[PATCH 2/2] drm/ast: Support AST2500

From: "Y.C. Chen" <yc_c...@aspeedtech.com> Add detection and POST code for AST2500 generation chip, code originally from Aspeed and slightly reworked for coding style mostly by Ben. Signed-off-by: Y.C. Chen <yc_c...@aspeedtech.com> Signed-off-by: Benjamin Herrenschmidt <

[PATCH 1/2] drm/ast: Support reading configuration values

ng DT properties are available. If not, the driver defaults to the existing test which i cleaned up a little bit. Signed-off-by: Russell Currey <rus...@russell.cc> Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> -- v2. [BenH] - Reworked on top of Aspeed P2A patch - C

[PATCH] drm/ast: Fix mclk calculation

The very large values observed were the result of a bug in the calculation. Y.C. Chen gave me the right formula so here is a patch fixing it. Thankfully nothing seem to use that unless you try to POST the chip. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> -- diff

Re: [PATCH 2/2] drm/ast: Support AST2500

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote: > On 16 February 2017 at 09:09, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > From: "Y.C. Chen" <yc_c...@aspeedtech.com> > > > > Add detection and POST code for AST2500 ge

Re: [PATCH 2/2] drm/ast: Support AST2500

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote: > The above seems like a _lot_ of unrelated rework. Keep the > refactoring > separate ? > New code seems to assume that only(?) -1 is returned on error, yet we > do < 0. > This will come to bite you/others as the tests are extended/reworked.

Re: [PATCH 2/2] drm/ast: Support AST2500

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote: > I realise that there's likely no documentation, yet repeating the > same > magic numbers multiple times is a bit meh. This is all Aspeed original code. I merely fixed the coding style ;-) The other POST functions for the other chip gens

Re: [PATCH 2/2] drm/ast: Support AST2500

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote: > "Water is wet" type of comment. Worth mentioning why it's so large - > mentioned in the documentation, experimental result, other ? > Same suggestion goes for the other mdelay(100) instances. Ah I removed most of those useless comments, I

Re: [PATCH 2/2] drm/ast: Support AST2500

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote: > > +static bool ast_dram_init_2500(struct ast_private *ast) > > +{ > > +   u32 data; > > +   u32 max_tries = 5; > > + > > +   do { > > +   if (max_tries-- == 0) > > +   return false; > > +   

[PATCH 3/9] drm/ast: Remove spurrious include

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/gpu/drm/ast/ast_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c index 823c68f..b593a53 100644 --- a/drivers/gpu/drm/ast/ast_main.c +++ b/d

[PATCH 9/9] drm/ast: Fixed vram size incorrect issue on POWER

From: "Y.C. Chen" The default value of VGA scratch may incorrect. Should initial h/w before get vram info. Signed-off-by: Y.C. Chen --- drivers/gpu/drm/ast/ast_main.c | 6 +++--- drivers/gpu/drm/ast/ast_post.c | 2 +- 2 files changed, 4

Re: [PATCH 1/9] drm/ast: Handle configuration without P2A bridge

On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote: > The ast driver configures a window to enable access into BMC > memory space in order to read some configuration registers. Aspeed suggested a couple of refinements for some chipsets, so I'll respin either this week-end or

[RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they

[RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote: > > > DRM drivers don't strike me as suitable for small/slow cores with dumb > > framebuffers or simple 2D only accel, such as the one found in the ASpeed > > BMCs. > > Then the DRM framework should be improved to be suitable. Dave ? :-)

[RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote: > Yeah, small drivers like these we have piles now, things exploded a lot > after atomic landed two years ago. And they seem to shrink with every > release a bit more (since lots more drivers gives you lots more insight > into what other

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote: > > From memory, David claimed you cannot directly work on the fb with a > > "proper" > > DRM driver. Maybe I misunderstood but then the DRM shines by its complete > absence of useful documentation

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote: > As I mentioned earlier, probably 1 or 2 years ago, Dave made the > argument that shadowing through memory was necessary and precluded 2D > accel, though I don't fully remember the root of the argument. If that &g

[RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote: > > With drmfb you basically have to shadow everything into memory & copy > > over everything, and locks you out of simple 2D accel. For a simple text > > console the result is orders of magnitude slower and memory hungry than > > a simple

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote: > What are people using fbcon for that needs acceleration, this is where I get > a bit lost. > > It's a console, if you aren't sshing into the machine. > > It's main purpose should just be for gathering oopses and you've a lot better > chance

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote: > Yeah if you have discrete vram then your dumb display driver isn't all > that pretty. We essentially just have the few drivers Dave hacked up to be > able to boot some servers. And there's definitely lots of room for more > shared code for

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > And since I failed to make this clear: There's not really a > fundamental > reason ast and cirrus use the dirty tracking for fbdev. It's just that > doing it that way was the fastest way to get those servers booting, and > ever since no

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote: > Despite all of this I still see no reason why a driver could not > expose the static, real frambuffers via private ioctls. You can get > all your fancy acceleration that way. Then fix user-space to use this > API. If enough drivers end up

[RFC PATCH 0/3] staging: remove fbdev drivers

On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote: > > As for multi userspace client, well, swapping an mmap between HW and > > memory backing store is a somewhat solved problem already. > > Hm, I didn't know that, but then all existing drm drivers have fairly > simplistic fbdev mmap

[PATCH] drm: Fix broken use of _PAGE_NO_CACHE on powerpc

That constant isn't meant to be used outside of arch mm code Signed-off-by: Benjamin Herrenschmidt --- drivers/gpu/drm/drm_memory.c | 2 +- drivers/gpu/drm/drm_scatter.c | 2 +- drivers/gpu/drm/drm_vm.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu

Stupid NVIDIA 3D vgaarb.c patch

On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote: > Adding proper people and mailing lists.. > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is > appropriate, but hopefully somebody does. The fact that it makes

  1   2   3   >