Re: [PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers

On Thu, 2022-10-13 at 09:39 +0200, Javier Martinez Canillas wrote: > > In absence of such test results I think the most reasonable thing is to > > keep the logic that nobody complained about for 10+ years. > > > > I agree with Michal and Thomas on this. I don't see a strong reason to not > use

Re: [PATCH v2 10/10] drm/ofdrm: Support color management

On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote: > +#if !defined(CONFIG_PPC) > +static inline void out_8(void __iomem *addr, int val) > +{ } > +static inline void out_le32(void __iomem *addr, int val) > +{ } > +static inline unsigned int in_le32(const void __iomem *addr) > +{ > +

Re: [PATCH v2 09/10] drm/ofdrm: Add per-model device function

On Tue, 2022-07-26 at 16:40 +0200, Michal Suchánek wrote: > Hello, > > On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote: > > On 7/20/22 16:27, Thomas Zimmermann wrote: > > > Add a per-model device-function structure in preparation of adding > > > color-management support.

Re: [PATCH v2 10/10] drm/ofdrm: Support color management

On Wed, 2022-07-27 at 10:41 +0200, Thomas Zimmermann wrote: > > > > +static void __iomem *ofdrm_mach64_cmap_ioremap(struct ofdrm_device *odev, > > > +struct device_node *of_node, > > > +u64 fb_base) > > > +{ > > > +

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote: > I don't mind adding DRM support for BootX displays, but getting the > necessary test HW with a suitable Linux seems to be laborious. Would > a G4 Powerbook work? Probably not unfortunately... it's going to be tricky. I might sitll

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

On Wed, 2022-05-25 at 18:45 +0200, Thomas Zimmermann wrote: > > > The palette handling is useful when using a real Open Firmware > > implementation which tends to boot in 8-bit mode, so without palette > > things will look ... bad. > > > > It's not necessary when using 16/32 bpp framebuffers

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

On Sun, 2022-05-22 at 21:35 +0200, Thomas Zimmermann wrote: > > Interesting. Did you find some formats that were not supported ? > > We still don't support XRGB1555. If the native buffer uses this format, > we'd have no conversion helper. In this case, we rely on userspace/fbcon > to use the

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

On Thu, 2022-05-19 at 09:27 +0200, Thomas Zimmermann wrote: > to build without PCI to see what happens. If you bring any of the "heuristic" and palette support code in, you need PCI. I don't see any reason to take it out. > Those old Macs use BootX, right? BootX is not supported ATM, as I don't

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

On Thu, 2022-05-19 at 09:11 +0200, Geert Uytterhoeven wrote: > Hi Michal, > > > > On Wed, May 18, 2022 at 8:54 PM Michal Suchánek > wrote: > > > On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote: > > > --- a/drivers/gpu/drm/tiny/Kconfig > > > +++ b/drivers/gpu/drm/tiny/Kconfig

Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.

On Mon, 2020-09-07 at 09:55 +0200, Daniel Vetter wrote: > On Thu, Aug 06, 2020 at 12:52:54PM +0530, Vaibhav Gupta wrote: > > Linux Kernel Mentee: Remove Legacy Power Management. > > > > The original goal of the patch series is to upgrade the power > > management > > framework of radeonfb fbdev

Re: [PATCH 5/6] drm/ast: Initialize DRAM type before posting GPU

I no longer have access to the relevant test POWER systems, however the patch looks good to me. > Signed-off-by: Thomas Zimmermann > Fixes: bad09da6deab ("drm/ast: Fixed vram size incorrect issue on > POWER") > Cc: Joel Stanley > Cc: Y.C. Chen Acked-by: Benjamin Herrenschm

Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau

On Mon, 2020-05-18 at 12:19 +0100, Emil Velikov wrote: > > - attempted out-of-bound attempts to read the vbios So on these things, the actual ROM doesn't contain what you want, but the device-tree has a property "NVDA,BMP" that contains some kind of mini-BIOS (around 2.4KB) which should contain

Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau

On Mon, 2020-05-18 at 12:00 +0100, Emil Velikov wrote: > I believe you reported issues due to different page size for the CPU/GPU. > Have you tried nouveau recently, there has been a handful of patches > on the topic since your report. > > Alternatively, it would make sense you rebase, cleanup

Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau

.@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Emil Velikov > Acked-by: Daniel Vetter (v1) > --- > Hi all unless, there are objections I would

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote: > Now if these boxes didn't ever have agp then I think we can get away > with deleting this, since we've already deleted the legacy radeon > driver. And that one used vmalloc for everything. The new kms one does > use the dma-api if the gpu

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote: > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote: > > If this code was broken for non-coherent caches a crude powerpc hack > > isn't going to help anyone else. Remove the hack as it is the last > > user of __vmalloc

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: > Benjamin Herrenschmidt writes: > > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: > > > I have no attachment to 40x, and I'd certainly be happy to have > > > less > > > code in the tree,

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: > I have no attachment to 40x, and I'd certainly be happy to have less > code in the tree, we struggle to keep even the modern platforms well > maintained. > > At the same time I don't want to render anyone's hardware obsolete >

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Wed, 2019-01-16 at 08:47 +0100, Ard Biesheuvel wrote: > > As far as I know on x86 it doesn't, so when you have an un-cached page > > you can still access it with a snooping DMA read/write operation and > > don't cause trouble. > > > > I think it is the other way around. The question is, on an

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Wed, 2019-01-16 at 07:35 +, Koenig, Christian wrote: > No, but you answer the wrong question. > > See we don't want to have different mappings of cached and non-cached on > the CPU, but rather want to know if a snooped DMA from the PCIe counts > as cached access as well. > > As far as I

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote: > > > As far as I know Power doesn't really supports un-cached memory at all, > > > except for a very very old and odd configuration with AGP. > > > > Hopefully Michael/Ben can elaborate here, but I was under the (possibly > > mistaken)

Re: [PATCH] drm/ast: Fixed reboot test may cause system hanged

On Wed, 2018-04-11 at 09:27 +0800, Y.C. Chen wrote: > index dac3558..82a2687 100644 > --- a/drivers/gpu/drm/ast/ast_main.c > +++ b/drivers/gpu/drm/ast/ast_main.c > @@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool > *need_post) > > > /* Enable extended

Re: [PATCH] drm/ast: Fixed reboot test may cause system hanged

On Wed, 2018-04-11 at 09:27 +0800, Y.C. Chen wrote: > From: "Y.C. Chen" > > There is another thread still access standard VGA I/O while loading drm > driver. > Disable standard VGA I/O decode to avoid this issue. Jeremy, Joel, can we regression test that on our systems

Re: [PATCH] drm/ast: Fixed reboot test may cause system hanged

to avoid this issue. Thanks. Pending testing on our systems to make sure it doesn't break anything (it shouldn't .. hopefully) Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Regards, > > Y.C. Chen > > -Original Message- > From: Benjamin Herren

Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter

On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote: > So if ARM64 doesn't have these PCI legacy resources, does that mean an > ARM64 host bridge cannot generate these legacy addresses on PCI? That > is, there's no host bridge window that maps to those PCI addresses? > That seems like a

Re: clean up and modularize arch dma_mapping interface V2

On Sat, 2017-06-24 at 09:18 +0200, Christoph Hellwig wrote: > On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote: > > Thanks for doing this. > > So archs can still have their own definition for dma_set_mask() if > > HAVE_ARCH_DMA_SET_MASK is y? > > (and similarly for dma_set_coherent_mask()

Re: [PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

On Sun, 2017-06-18 at 00:13 -0700, Christoph Hellwig wrote: > On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote: > > What is your rationale here ? (I have missed patch 0 it seems). > > Less code duplication, more modular dma_map_ops insteance. >

Re: [PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

On Fri, 2017-06-16 at 20:10 +0200, Christoph Hellwig wrote: > Besides removing the last instance of the set_dma_mask method this also > reduced the code duplication. What is your rationale here ? (I have missed patch 0 it seems). dma_supported() was supposed to be pretty much a "const" function

[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

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

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. >

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 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

[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,

[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 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

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

[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 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 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

[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 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 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 +++-

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: > 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 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 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

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 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

[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 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 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

[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

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 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: 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 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; > > +   

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: > 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: > 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: > 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 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

[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

[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 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 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 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 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 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 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 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 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

[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

ongoing writecombine on ppc

On Fri, 2015-10-02 at 14:53 +1000, Dave Airlie wrote: > On 2 October 2015 at 14:45, Benjamin Herrenschmidt > wrote: > > On Fri, 2015-10-02 at 14:42 +1000, Dave Airlie wrote: > > > I don't think we resolved this the last time we talked about it, > > > > > >

ongoing writecombine on ppc

On Fri, 2015-10-02 at 14:47 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2015-10-02 at 14:45 +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2015-10-02 at 14:42 +1000, Dave Airlie wrote: > > > I don't think we resolved this the last time we talked about it, > > > &g

ongoing writecombine on ppc

On Fri, 2015-10-02 at 14:45 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2015-10-02 at 14:42 +1000, Dave Airlie wrote: > > I don't think we resolved this the last time we talked about it, > > > > but radeon writecombine maps fail hard on ppc, I think all the > > fix

ongoing writecombine on ppc

On Fri, 2015-10-02 at 14:42 +1000, Dave Airlie wrote: > I don't think we resolved this the last time we talked about it, > > but radeon writecombine maps fail hard on ppc, I think all the fixes > either did something bad to AGP systems or weren't liked. > > My patch attached just fixes radeon,

[PATCH] drm/ast: Fix HW cursor image

The translation from the X driver to the KMS one typo'ed a couple of array indices, causing the HW cursor to look weird (blocky with leaking edge colors). This fixes it. Signed-off-by: Benjamin Herrenschmidt --- diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index

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

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote: > On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote: > > Last time I tested, (and it seems like Michel is on the same track), > > writing with the CPU to write-combined memory was substantially faster > > than writing to cached

[PATCH 9/9] drm/ttm: Sanity check mapping attributes on powerpc in ttm_io_prot()

On Thu, 2014-09-04 at 16:52 +0900, Michel D?nzer wrote: > > #endif > > +#if defined(__powerpc__) && !defined(CONFIG_NOT_COHERENT_CACHE) > > + /* > > + * Using a non-cachable mapping of system memory on > > + * cache coherent powerpc's can be fatal, let's make > > + * sure this

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 16:59 +0900, Michel D?nzer wrote: > > Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm > not alone, at least with AGP 1x it seems to work quite well for most > people. So I don't see the justification for intentionally breaking it > completely for

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote: > > This will, from what I can tell, try to use the same caching mode as the > > original object: > > > > if ((cur_placement & caching) != 0) > > result |= (cur_placement & caching); > > > > And cur_placement comes from

TTM placement & caching issue/questions

On Thu, 2014-09-04 at 16:19 +0900, Michel D?nzer wrote: > > +#else /* CONFIG_X86 */ > > +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t > *placement) > > +{ > > + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) { > > + ttm->caching_state = tt_cached; > > +

[PATCH 4/9] drm/ast: Don't assume DVO enabled means SIL164 on uninitialized chips

-by: Benjamin Herrenschmidt --- drivers/gpu/drm/ast/ast_main.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c index 556d065..48998b2 100644 --- a/drivers/gpu/drm/ast/ast_main.c +++ b/drivers/gpu/drm

[PATCH 3/9] drm/ast: Properly initialize P2A base before using it in ast_init_3rdtx()

64k window in the second half of the PCIe MMIO BAR) Signed-off-by: Benjamin Herrenschmidt --- drivers/gpu/drm/ast/ast_dp501.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c index 5da4b62..7e2ddde 100644

[PATCH 2/9] drm/ast: POST chip at probe time if VGA not enabled

-off-by: Benjamin Herrenschmidt --- drivers/gpu/drm/ast/ast_drv.h | 3 +++ drivers/gpu/drm/ast/ast_main.c | 47 -- drivers/gpu/drm/ast/ast_post.c | 23 + 3 files changed, 62 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm

  1   2   3   >