sible remaining issue.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ef2ac3c..48095be 100644
--- a/drivers/gpu/dr
powerpc use the same implementation as ia64 and arm
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 ---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 ++---
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b
What the code does is equivalent to the x86 code, so let's use
it as well
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_vm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 24e045c..ed02563 1
for non x86 architecture.
Signed-off-by: J?r?me Glisse
Signed-off-by: Benjamin Herrenschmidt
---
[Minor compile fixes on top of Jerome original v3]
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu
Move the MMIO mangling to a separate routine and actually
disable the DVO output when using pure analog.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_dp501.c | 49 ++---
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a
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/gpu/dr
-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
If the PIO resources haven't been assigned, then we have no choice
but try to use the MMIO version. This is the case for example on
POWER8 which doesn't support PIO at all.
Chips rev 0x20 or later have MMIO decoding enabled by default.
Signed-off-by: Benjamin Herrenschmidt
---
drive
On Wed, 2014-09-03 at 22:36 -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
>
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> So in the meantime the attached patch should work, it just silently ignore
> the caching attribute request on non x86 instead of pretending that things
> are setup as expected and then latter the radeon ou nouveau hw unsetting
> the snoop b
On Wed, 2014-09-03 at 21:55 -0400, Jerome Glisse wrote:
> So i think we need to get a platform flags and or set_pages_array_wc|uc
> needs to fail and this would fallback to cached mapping if the fallback
> code still works. So if your arch properly return and error for those
> cache changing functi
Hi folks !
I've been tracking down some problems with the recent DRI on powerpc and
stumbled upon something that doesn't look right, and not necessarily
only for us.
Now it's possible that I haven't fully understood the code here and I
also don't know to what extent some of that behaviour is nece
On Sat, 2014-08-30 at 23:38 +0100, Tony Vroon wrote:
> On 30/08/14 22:56, Benjamin Herrenschmidt wrote:
> > This is weird. The above means it crashed very early, such as in
> > prom_init. I fail to see how the above commit can possibly relate
> > to that in any way...
>
On Sat, 2014-08-30 at 18:37 +0100, Tony Vroon wrote:
> Please consider reverting commit 3e22920fbd0005927bc41f71daeb056a0f4def82 by
> title of:
> drm/radeon: consolidate vga and dvi get_modes functions (v2)
>
> I have bisected this as the culprit for my PowerMac 7,3 crashing back into
> OpenFirm
On Wed, 2014-06-18 at 11:05 +1000, Dave Airlie wrote:
>
> I don't think we ever ioremap GART, it should kmap GART pages, ioremap
> should only happen for VRAM areas AFAIK,
>
> This isn't some 32-bit vs 36-bit BAR or something, I seem to remember BenH
> mentioning something like that before.
Yes,
latforms that don't support IO.
Also, about the 0x380 difference in offset between IO and MMIO, is that
always like that ? The documentation doesn't mention this at all...
Cheers,
Ben.
> Regards,
>
> Y.C. Chen
>
> -Original Message-
> From: Benjamin Herrenschmi
On Sat, 2014-06-07 at 09:20 +1000, Benjamin Herrenschmidt wrote:
> IE. Is there a reason why bASTIsVGAEnabled() and vASTEnableVGAMMIO
> use the IO ports ? The latter reads 0x43 and writes 0x43 and 0x42,
> can it be made to always use MMIO 0x3c3 and write 0x3c3 and 0x3c2 ?
>
> O
On Fri, 2014-06-06 at 21:31 +1000, Benjamin Herrenschmidt wrote:
> The spec is pretty tricky to read but seems to indicate that the above
> offset should also work for PIO if needed, however, it seems like the
> X driver is pretty happy to use MMIO unconditionally for them.
>
> A
Hi Dave !
So your AST KMS driver in -next is blowing up on my power8 box :-)
There are several issues that I want to discuss here (YC Chen on CC
might also have some valuable input here) before I send you patches
to fix it :-)
* First, accessors. The first obvious cause for blowing up for me is
Hi Dave !
So your AST driver in -next is blowing up on my power8 box :-)
There are several issues that I want to discuss here (YC Chen on CC
might also have some valuable input here).
* First, accessors. The first obvious cause for blowing up for me is
that you are using the "old style" PIO offs
On Thu, 2013-12-05 at 11:29 +0900, Michel D?nzer wrote:
> On Don, 2013-12-05 at 12:39 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2013-12-04 at 19:05 -0500, Alex Deucher wrote:
> >
> > > > Setting CP_RB_CNTL.BUF_SWAP causes the CP to use the selected byte
>
On Wed, 2013-12-04 at 19:05 -0500, Alex Deucher wrote:
> > Setting CP_RB_CNTL.BUF_SWAP causes the CP to use the selected byte
> > swapping for just about everything accessed by the CP (rptr writeback,
> > indirect buffers, etc.). Looks like the DMA ring supports and enables
> > rptr writeback as
On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote:
> > Additionally the current code is broken in that the upper layer in
> > vm/base.c doesn't increment "pte" by the right amount.
> >
> > Now, if those two assertions can be made always true:
> >
> > - Those two functions (map_sg and map_sg_tab
On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
> >
> >> Weird. I wonder if there is an issue with cache snoops on PPC. We
> >>
On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
> Weird. I wonder if there is an issue with cache snoops on PPC. We
> currently use the gart in cached mode (GPU snoops CPU cache) with
> cached pages. I wonder if we need to use uncached pages on PPC.
There is no such issue and no known b
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
> > +++ b/drivers/gpu/drm/
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 patc
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,
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 cou
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 en
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
> > +++ b/drivers/gpu/drm/
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 patc
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,
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 cou
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 en
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 ho
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 ho
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
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
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 detec
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 detec
set the default mode and depth.
Signed-off-by: Benjamin Herrenschmidt
---
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 a/drivers/gpu/drm/cirrus
).
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
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 28
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
---
drivers/gpu/drm/cirrus/cirrus_mode.c |5 +++--
1 file changed, 3 insertions(
5th 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
--
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_fb_helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f546d1e..da6873c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/dr
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
---
drivers/gpu/drm/cirrus/cirrus_mode.c |8 +++-
drivers/gpu/drm/drm_crt
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
---
drivers/gpu/drm/cirrus/cirrus_mode.c |8 +++-
drivers/gpu/drm/drm_crt
set the default mode and depth.
Signed-off-by: Benjamin Herrenschmidt
---
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 a/drivers/gpu/drm/cirrus
).
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
---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 28
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/drm_fb_helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f546d1e..da6873c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/dr
5th 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
--
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
---
drivers/gpu/drm/cirrus/cirrus_mode.c |5 +++--
1 file changed, 3 insertions(
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.
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.
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.
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 `.powe
ising "best"). Fix that as well.
Signed-off-by: Benjamin Herrenschmidt
---
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
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).
This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.
Signed-off-by: Benjamin Herrenschmidt
---
Please send to Linus asap
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
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.
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 `.powe
ising "best"). Fix that as well.
Signed-off-by: Benjamin Herrenschmidt
---
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
>From b15b244d6e6e20964bd4b85306722cb60c3c0809 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt
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).
This causes nouv
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
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
Tested-by: Benjamin Herrenschmidt
> thanks,
>
> Dave
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
Tested-by: Benjamin Herrenschmidt
> thanks,
>
> Dave
__
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 ca
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 li
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
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 ca
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 li
On Wed, 2012-02-15 at 03:23 +0100, acrux wrote:
> On Sun, 12 Feb 2012 11:00:43 +0100
> Michel D?nzer 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 to boo
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
On Wed, 2012-02-15 at 03:23 +0100, acrux wrote:
> On Sun, 12 Feb 2012 11:00:43 +0100
> Michel Dänzer 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 to boo
On Fri, 2011-07-15 at 04:19 +, Matt Turner wrote:
> On Wed, Jul 13, 2011 at 6:28 AM, Benjamin Herrenschmidt
> 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
> > ensur
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.
> >
> >
On Fri, 2011-07-15 at 04:19 +, Matt Turner wrote:
> On Wed, Jul 13, 2011 at 6:28 AM, Benjamin Herrenschmidt
> 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
> > ensur
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.
> >
> >
On Wed, 2011-07-13 at 10:48 -0400, Alex Deucher wrote:
> On Wed, Jul 13, 2011 at 10:43 AM, Alex Deucher
> wrote:
> > On Wed, Jul 13, 2011 at 2:28 AM, Benjamin Herrenschmidt
> > wrote:
> >> We should have a read memory barrier between reading the WPTR from
> >
On Wed, 2011-07-13 at 10:42 -0400, Alex Deucher wrote:
> On Wed, Jul 13, 2011 at 2:28 AM, 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.
> >
>
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.ulDispEngClkFre
(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
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/radeon_reg.h |2 +-
1 files
evice and the system.
Signed-off-by: Benjamin Herrenschmidt
---
(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/radeon/r600.c
an explicit one just
in case.
Signed-off-by: Benjamin Herrenschmidt
---
(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/drivers/gpu/drm/radeon/r600
stent with the surrounding code.
Signed-off-by: Benjamin Herrenschmidt
---
(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 +
& shifts.
Signed-off-by: Benjamin Herrenschmidt
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/atombios_crtc.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/ra
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
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/
On Wed, 2011-07-13 at 10:48 -0400, Alex Deucher wrote:
> On Wed, Jul 13, 2011 at 10:43 AM, Alex Deucher wrote:
> > On Wed, Jul 13, 2011 at 2:28 AM, Benjamin Herrenschmidt
> > wrote:
> >> We should have a read memory barrier between reading the WPTR from
> >> memo
On Wed, 2011-07-13 at 10:42 -0400, Alex Deucher wrote:
> On Wed, Jul 13, 2011 at 2:28 AM, 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.
> >
>
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.ulDispEngClkFre
stent with the surrounding code.
Signed-off-by: Benjamin Herrenschmidt
---
(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 +
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
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/
evice and the system.
Signed-off-by: Benjamin Herrenschmidt
---
(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/radeon/r600.c
an explicit one just
in case.
Signed-off-by: Benjamin Herrenschmidt
---
(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/drivers/gpu/drm/radeon/r600
(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
---
(resent adding dri-devel to the CC list to hit patchwork)
drivers/gpu/drm/radeon/radeon_reg.h |2 +-
1 files
hitting these lockups, so here we are...
>
> Signed-off-by: Michel D?nzer
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
Thanks !
Cheers,
hitting these lockups, so here we are...
>
> Signed-off-by: Michel Dänzer
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
Thanks !
Cheers,
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
101 - 200 of 209 matches
Mail list logo
