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 th
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)
> +{
> + r
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. D
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)
> > > +{
> > > + st
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
hav
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 whic
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 nat
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
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
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 dr
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
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
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 and
-fb...@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
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 is
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 passing
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
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
> unnecessar
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
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
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) i
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 registe
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 ?
> Signed-off-by: Y.C.
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
> Regards,
>
> Y.C. Chen
>
> -Original Message-
> From: Benjamin Herrenschmidt [mail
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 curious
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() wh
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.
>
>
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
s
tion 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
Signed-off-by: Benjamin Herrenschmidt
--
v2. [BenH]
- Reworked on top of Aspeed P2A patch
- Cleanu
On Fri, 2017-02-24 at 12:54 +1030, Joel Stanley wrote:
> On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt
> wrote:
> > Some braces were missing causing an incorrect calculation.
> >
> > Y.C. Chen from Aspeed provided me with the right formula
> > which I test
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.
>
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.
_
On Fri, 2017-02-24 at 09:53 +1100, Benjamin Herrenschmidt wrote:
> From: "Y.C. Chen"
>
> (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 from a register that may or may
From: "Y.C. Chen"
(Get better description from Aspeed)
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_post.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/
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
---
drivers/gpu/drm/ast/ast_post.c | 6 +++---
1 file changed, 3
From: "Y.C. Chen"
Add detection and mode setting updates for AST2500 generation chip,
code originally from Aspeed and slightly reworked for coding style
mostly by Ben. This doesn't contain the BMC DRAM POST code which
is in a separate patch.
Signed-off-by: Y.C. Chen
Signed-o
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
--
v2.
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
https://lists.freedesktop.org/mailman/li
From: "Y.C. Chen"
open_key enables access the registers used by enable_mmio
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drive
From: "Y.C. Chen"
This is used when the BMC isn't running any code and thus has
to be initialized by the host.
The code originates from Aspeed (Y.C. Chen) and has been cleaned
up for coding style purposes by BenH.
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
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 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
ed value a bit more meaningful
Signed-off-by: Benjamin Herrenschmidt
---
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 100644
--- a/drivers/g
Signed-off-by: Benjamin Herrenschmidt
---
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/drivers/gpu/drm/ast/ast_main.c
ow 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
Signed-off-by: Benjamin Herrenschmidt
--
v2. [BenH]
- Reworked on top of Aspee
From: "Y.C. Chen"
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
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gp
And fix some comment alignment & space/tabs while at it
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_drv.h| 4 +-
drivers/gpu/drm/ast/ast_mode.c | 8 +--
drivers/gpu/drm/ast/ast_tables.h | 106 +++
3 files changed, 59 insert
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 wa
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(...);
>
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
https://gi
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
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-en
On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote:
Make this
From: Russell Currey
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 to read some configuration reg
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
---
drivers/gpu/drm/ast/ast_post.c | 6 +++---
1 file changed, 3
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 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
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
---
drivers/gpu/drm/ast/ast_post.c | 76 --
1 file changed, 22
From: "Y.C. Chen"
Add detection and mode setting updates for AST2500 generation chip,
code originally from Aspeed and slightly reworked for coding style
mostly by Ben. This doesn't contain the BMC DRAM POST code which
is in a separate patch.
Signed-off-by: Y.C. Chen
Signed-o
And fix some comment alignment & space/tabs while at it
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_drv.h| 4 +-
drivers/gpu/drm/ast/ast_mode.c | 8 +--
drivers/gpu/drm/ast/ast_tables.h | 106 +++
3 files changed, 59 insert
tion 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
Signed-off-by: Benjamin Herrenschmidt
--
v2. [BenH]
- Reworked on top of Aspeed P2A patch
- Cleanu
From: "Y.C. Chen"
This is used when the BMC isn't running any code and thus has
to be initialized by the host.
The code originates from Aspeed (Y.C. Chen) and has been cleaned
up for coding style purposes by BenH.
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmid
ed value a bit more meaningful
Signed-off-by: Benjamin Herrenschmidt
---
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 100644
--- a/drivers/g
Signed-off-by: Benjamin Herrenschmidt
---
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/drivers/gpu/drm/ast/ast_main.c
SOC scratch then ast->DisableP2A = 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
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, indent the timing tables , remove start
> of line whi
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 the update to fix it.
Wil
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 +-
> drivers/gpu/drm/ast/ast_post.c | 510
> ++
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;
> > +
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 mu
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 are
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.
N
On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
> On 16 February 2017 at 09:09, Benjamin Herrenschmidt
> wrote:
> > From: "Y.C. Chen"
> >
> > Add detection and POST code for AST2500 generation chip,
> > code originally from Aspeed and slightly rew
On Thu, 2017-02-16 at 20:09 +1100, Benjamin Herrenschmidt wrote:
> From: "Y.C. Chen"
>
> Add detection and POST code for AST2500 generation chip,
> code originally from Aspeed and slightly reworked for
> coding style mostly by Ben.
I just noticed there's sti
From: "Y.C. Chen"
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
Signed-off-by: Benjamin Herrenschmidt
---
v2. [BenH]
- Coding style fixes
- Add timeout to main
re available. If not, the driver defaults
to the existing test which i cleaned up a little bit.
Signed-off-by: Russell Currey
Signed-off-by: Benjamin Herrenschmidt
--
v2. [BenH]
- Reworked on top of Aspeed P2A patch
- Cleanup overall detection via a "config_mode" and log the
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
--
diff --git a/drivers/gpu/drm/ast
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 w
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 implemen
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 o
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 t
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
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
>
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
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 refac
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 fbd
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 ? :-)
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 can't
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/driver
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,
> > >
> >
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,
> > >
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
> >
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, wh
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
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
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
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
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 al
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 bo-
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;
> > +
ff-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/gp
elocatable 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 10
-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 - 100 of 209 matches
Mail list logo
