* Re: [patch] spi: atmel: fix indenting in atmel_spi_gpio_cs()
From: Nicolas Ferre @ 2016-11-14 14:49 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Mark Brown, linux-spi, kernel-janitors
In-Reply-To: <20161114142644.GA6179@mwanda>
Le 14/11/2016 à 15:26, Dan Carpenter a écrit :
> These lines were indented one extra tab.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Oh yes: sorry for that:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks, Dan. Best regards,
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index d3affa6..b293149 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1510,15 +1510,15 @@ static int atmel_spi_gpio_cs(struct platform_device *pdev)
> int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> "cs-gpios", i);
>
> - if (cs_gpio = -EPROBE_DEFER)
> - return cs_gpio;
> -
> - if (gpio_is_valid(cs_gpio)) {
> - ret = devm_gpio_request(&pdev->dev, cs_gpio,
> - dev_name(&pdev->dev));
> - if (ret)
> - return ret;
> - }
> + if (cs_gpio = -EPROBE_DEFER)
> + return cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + return ret;
> + }
> }
>
> return 0;
>
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch] spi: atmel: fix indenting in atmel_spi_gpio_cs()
From: Nicolas Ferre @ 2016-11-14 14:49 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Mark Brown, linux-spi, kernel-janitors
In-Reply-To: <20161114142644.GA6179@mwanda>
Le 14/11/2016 à 15:26, Dan Carpenter a écrit :
> These lines were indented one extra tab.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Oh yes: sorry for that:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks, Dan. Best regards,
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index d3affa6..b293149 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1510,15 +1510,15 @@ static int atmel_spi_gpio_cs(struct platform_device *pdev)
> int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> "cs-gpios", i);
>
> - if (cs_gpio == -EPROBE_DEFER)
> - return cs_gpio;
> -
> - if (gpio_is_valid(cs_gpio)) {
> - ret = devm_gpio_request(&pdev->dev, cs_gpio,
> - dev_name(&pdev->dev));
> - if (ret)
> - return ret;
> - }
> + if (cs_gpio == -EPROBE_DEFER)
> + return cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + return ret;
> + }
> }
>
> return 0;
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] staging: rtl8192e: Fix checkpatch warnings
From: Greg KH @ 2016-11-14 14:50 UTC (permalink / raw)
To: Yamanappagouda Patil; +Cc: devel, linux-kernel
In-Reply-To: <1478797292-11687-1-git-send-email-goudapatilk@gmail.com>
On Thu, Nov 10, 2016 at 10:31:32PM +0530, Yamanappagouda Patil wrote:
> Fixed checkpatch.pl warning on Block comments.
>
> Signed-off-by: Yamanappagouda Patil <goudapatilk@gmail.com>
> ---
Both of your patches did different things, yet you had the same subject
line :(
Please fix them up and resend with unique subjects (hint, adding ".pl"
doesn't make it unique...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Staging: i4l: act2000: capi: Removing necessary variable
From: Greg KH @ 2016-11-14 14:50 UTC (permalink / raw)
To: Nadim Almas; +Cc: bankarsandhya512, linux-kernel
In-Reply-To: <20161111095821.GA4754@gmail.com>
On Fri, Nov 11, 2016 at 03:28:21PM +0530, Nadim Almas wrote:
> Removing struct sk_buff *skb from capi.c
>
> The Coccinelle semantic patch used to make this change is as follows:
> @@
> type T;
> identifier D;
> @@
> - T D;
> ...when != D
>
> Signed-off-by: Nadim Almas <nadim.902@gmail.com>
> ---
> drivers/staging/i4l/act2000/capi.c | 13 -------------
> 1 file changed, 13 deletions(-)
Why didn't you test build your patch :(
Please ALWAYS do so...
greg k-h
^ permalink raw reply
* Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support
From: Luis R. Rodriguez @ 2016-11-14 14:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Laurent Pinchart, Luis R. Rodriguez, Rafael J. Wysocki,
Lukas Wunner, Rafael J. Wysocki, Linux PM list, Alan Stern,
Linux Kernel Mailing List, Tomeu Vizoso, Mark Brown,
Marek Szyprowski, Kevin Hilman, Ulf Hansson, Geert Uytterhoeven,
Lars-Peter Clausen, Grant Likely, Mauro Carvalho Chehab,
Dmitry Torokhov
In-Reply-To: <20161113105942.GE8388@kroah.com>
On Sun, Nov 13, 2016 at 11:59:42AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 11, 2016 at 02:08:35AM +0200, Laurent Pinchart wrote:
> > Hi Greg,
> >
> > On Thursday 10 Nov 2016 23:40:54 Greg Kroah-Hartman wrote:
> > > On Thu, Nov 10, 2016 at 11:04:07PM +0100, Luis R. Rodriguez wrote:
> > > > This is more forward looking, but -- if we had an annotation in
> > > > Kconfig/turned to a mod info section, or to start off with just a driver
> > > > MODULE_SUGGESTS() macro to start off with it might suffice for the driver
> > > > core to request_module() annotated dependencies, such requests could be
> > > > explicitly suggested as synchronous so init + probe do run together
> > > > (as-is today), after which it could know that all possible drivers that
> > > > needed to be loaded should now be loaded. If this sounds plausible to
> > > > help, do we have drivers where we can test this on? For instance, since
> > > > the functional dependency framework annotates functional dependencies for
> > > > consumers/providers for suspend/resume and un time PM could such
> > > > MODULE_SUGGESTS() annotations be considered on the consumers to suggest
> > > > the provider drivers so their own probe yields to their providers to try
> > > > first ?
> > >
> > > No.
> > >
> > > Stop.
> > >
> > > First off, the "driver core" NEVER can "know" if "all possible drivers
> > > that should be loaded, are loaded. That way lies madness and
> > > impossibility.
At first I had discarded the generic driver problem as a slightly unrelated
topic however its clear now its not. In terms of functional dependencies I
agree that not providing strict order is *sometimes* desirable to help with
simplicity. The generic driver problem can be described graph-wise: on a DAG,
we're considering a topology with where nodes have optional superior
alternatives, and what you seem to be advocating is a transition to an
alternative is better and much simpler than forcing order from the start. That
can only work so long as some intermediary dependencies are (for lack of a
better term) soft-nodes -- where transitions to better alternatives are
possible and can such transitions can be handled in software. You may have
(again for lack of a better term) hard-nodes though where an entry in the DAG
is required as a hard requirement immediately prior to letting another entry
proceed. An example here is the x86 IOMMU drivers and dependent GPU DRM
drivers, currently only link order asserts proper order given we have run out
of semantics in between to ensure proper order is correct.
> > > Secondly, yet-another-section isn't going to help anything here, we
> > > alredy "suggest" to userspace a bunch of stuff, so we get the needed
> > > modules loaded, at sometime in the future, if they are around, and
> > > userspace feels like it. That's the best we can ever do.
For some cases this is sufficient, for hard-nodes (term used above) though
if you get the incorrect order you may in the worst case oops.
> > > Don't try to make this more difficult than it is please. DEFER works
> > > today really really well, and it's really really simple.
It seems many disagree. What is clear is its simplicity outweighs the
complexity by alternatives which have been historically considered. This is
reasonable. Part of the reason probe ordering, as an optimization
consideration, came up while function dependencies for runtime PM and suspend
are being discussed is as we've determined this is a related problem and
at least for hard-nodes this is critical to resolve. For now we have enough
tools to work around problems for hard-nodes, but it would be silly for us
not to start thinking about ways to improve upon this for the future.
> > > Inter-dependancy of modules and devices connected to each other are two
> > > different things, be careful about this.
This is a *very* fair warning :)
> > One issue we don't address today is handling of optional dependencies. A
> > simple example is an SPI controller that can use a DMA engine or work in PIO
> > mode. At probe time the driver will request a DMA channel if the platform
> > (ACPI, DT, platform data) specifies that DMA is available. This can fail for
> > various reasons, one of them being that the DMA engine driver hasn't probed
> > the DMA device yet. In that case the SPI controller driver will continue in
> > PIO mode, ignoring the DMA engine that will later be probed. We can't defer
> > probing of the SPI controller as the DMA engine driver might never get loaded,
> > which would result in the SPI controller probe being deferred forever.
> >
> > One solution for this type of dependency issue would be to notify the SPI
> > controller driver after probe that the DMA channel is now available. I'd like
> > to avoid that though, as it would drastically increase the complexity of lots
> > of drivers and create lots of race conditions.
> >
> > There are certain configurations that we could possibly consider as invalid.
> > For instance if the SPI controller driver is built-in and the DMA engine
> > driver built as a module, the user clearly shot themselves in the foot and the
> > kernel can't be blamed.
> >
> > For resources that can't be built as a module (IOMMUs for instance) we thus
> > only have to consider the case where both drivers are built-in, as the
> > resource built-in and consumer as a module should work properly from an
> > ordering point of view (at least as long as we don't allow asynchronous
> > probing of built-in drivers to be delayed enough for modules to be loaded...).
> > In this case, if the resource driver isn't available when the consumer is
> > probed, if will never be available at the consumer can safely proceed in a
> > degraded mode. We would thus only need to solve the probe ordering issue.
> >
> > I'm not sure how far these simple(r) solutions that consider certain cases as
> > invalid would scale though, and whether we won't need a more generic solution
> > at some point anyway.
>
> I would love to see a generic solution that works for all of these
> complex cases, as I agree with you, it's complex :)
>
> But I have yet to see any such patches that implement this.
The generic driver topic is related but it certainly only part of the
picture. It seems there were enough folks interested in that topic though
so perhaps patches will be eventually produced for it.
> As always,
> I am very glad to review anything that people create, but I don't have
> the time to work on such a solution myself at the moment.
Part of what we tried to discuss during the complex dependencies topics at
Plumbers was evaluating if some of the existing solutions for run time PM and
suspend could help with probe ordering, it seems we had agreement on it, what
we found though was that for many cases the use of struct device for link
association is too late. Alternatives mechanisms will be considered in the
future, and it seems that one path forward will be to consider expanding upon
this simple functional device dependency framework.
So let's see more patches!
Luis
^ permalink raw reply
* [PATCH] drm/amd/amdgpu: port of DCE v6 to new headers
From: Tom St Denis @ 2016-11-14 14:51 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Tom St Denis
Port of SI DCE v6 over to new AMDGPU headers. Tested on a
Tahiti with GNOME through various hot plugs/rotations/sizes/fullscreen/windowed and
staging drm/xf86-video-amdgpu.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 441 +++++++++++----------
drivers/gpu/drm/amd/amdgpu/si_enums.h | 319 +++++++++------
.../gpu/drm/amd/include/asic_reg/dce/dce_6_0_d.h | 21 +
3 files changed, 447 insertions(+), 334 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index b0fdc291bf43..960e8f64864d 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -30,8 +30,19 @@
#include "atombios_encoders.h"
#include "amdgpu_pll.h"
#include "amdgpu_connectors.h"
-#include "si/si_reg.h"
-#include "si/sid.h"
+
+#include "bif/bif_3_0_d.h"
+#include "bif/bif_3_0_sh_mask.h"
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+#include "gca/gfx_6_0_d.h"
+#include "gca/gfx_6_0_sh_mask.h"
+#include "gmc/gmc_6_0_d.h"
+#include "gmc/gmc_6_0_sh_mask.h"
+#include "dce/dce_6_0_d.h"
+#include "dce/dce_6_0_sh_mask.h"
+#include "gca/gfx_7_2_enum.h"
+#include "si_enums.h"
static void dce_v6_0_set_display_funcs(struct amdgpu_device *adev);
static void dce_v6_0_set_irq_funcs(struct amdgpu_device *adev);
@@ -48,12 +59,12 @@ static const u32 crtc_offsets[6] =
static const u32 hpd_offsets[] =
{
- DC_HPD1_INT_STATUS - DC_HPD1_INT_STATUS,
- DC_HPD2_INT_STATUS - DC_HPD1_INT_STATUS,
- DC_HPD3_INT_STATUS - DC_HPD1_INT_STATUS,
- DC_HPD4_INT_STATUS - DC_HPD1_INT_STATUS,
- DC_HPD5_INT_STATUS - DC_HPD1_INT_STATUS,
- DC_HPD6_INT_STATUS - DC_HPD1_INT_STATUS,
+ mmDC_HPD1_INT_STATUS - mmDC_HPD1_INT_STATUS,
+ mmDC_HPD2_INT_STATUS - mmDC_HPD1_INT_STATUS,
+ mmDC_HPD3_INT_STATUS - mmDC_HPD1_INT_STATUS,
+ mmDC_HPD4_INT_STATUS - mmDC_HPD1_INT_STATUS,
+ mmDC_HPD5_INT_STATUS - mmDC_HPD1_INT_STATUS,
+ mmDC_HPD6_INT_STATUS - mmDC_HPD1_INT_STATUS,
};
static const uint32_t dig_offsets[] = {
@@ -73,32 +84,32 @@ static const struct {
uint32_t hpd;
} interrupt_status_offsets[6] = { {
- .reg = DISP_INTERRUPT_STATUS,
+ .reg = mmDISP_INTERRUPT_STATUS,
.vblank = DISP_INTERRUPT_STATUS__LB_D1_VBLANK_INTERRUPT_MASK,
.vline = DISP_INTERRUPT_STATUS__LB_D1_VLINE_INTERRUPT_MASK,
.hpd = DISP_INTERRUPT_STATUS__DC_HPD1_INTERRUPT_MASK
}, {
- .reg = DISP_INTERRUPT_STATUS_CONTINUE,
+ .reg = mmDISP_INTERRUPT_STATUS_CONTINUE,
.vblank = DISP_INTERRUPT_STATUS_CONTINUE__LB_D2_VBLANK_INTERRUPT_MASK,
.vline = DISP_INTERRUPT_STATUS_CONTINUE__LB_D2_VLINE_INTERRUPT_MASK,
.hpd = DISP_INTERRUPT_STATUS_CONTINUE__DC_HPD2_INTERRUPT_MASK
}, {
- .reg = DISP_INTERRUPT_STATUS_CONTINUE2,
+ .reg = mmDISP_INTERRUPT_STATUS_CONTINUE2,
.vblank = DISP_INTERRUPT_STATUS_CONTINUE2__LB_D3_VBLANK_INTERRUPT_MASK,
.vline = DISP_INTERRUPT_STATUS_CONTINUE2__LB_D3_VLINE_INTERRUPT_MASK,
.hpd = DISP_INTERRUPT_STATUS_CONTINUE2__DC_HPD3_INTERRUPT_MASK
}, {
- .reg = DISP_INTERRUPT_STATUS_CONTINUE3,
+ .reg = mmDISP_INTERRUPT_STATUS_CONTINUE3,
.vblank = DISP_INTERRUPT_STATUS_CONTINUE3__LB_D4_VBLANK_INTERRUPT_MASK,
.vline = DISP_INTERRUPT_STATUS_CONTINUE3__LB_D4_VLINE_INTERRUPT_MASK,
.hpd = DISP_INTERRUPT_STATUS_CONTINUE3__DC_HPD4_INTERRUPT_MASK
}, {
- .reg = DISP_INTERRUPT_STATUS_CONTINUE4,
+ .reg = mmDISP_INTERRUPT_STATUS_CONTINUE4,
.vblank = DISP_INTERRUPT_STATUS_CONTINUE4__LB_D5_VBLANK_INTERRUPT_MASK,
.vline = DISP_INTERRUPT_STATUS_CONTINUE4__LB_D5_VLINE_INTERRUPT_MASK,
.hpd = DISP_INTERRUPT_STATUS_CONTINUE4__DC_HPD5_INTERRUPT_MASK
}, {
- .reg = DISP_INTERRUPT_STATUS_CONTINUE5,
+ .reg = mmDISP_INTERRUPT_STATUS_CONTINUE5,
.vblank = DISP_INTERRUPT_STATUS_CONTINUE5__LB_D6_VBLANK_INTERRUPT_MASK,
.vline = DISP_INTERRUPT_STATUS_CONTINUE5__LB_D6_VLINE_INTERRUPT_MASK,
.hpd = DISP_INTERRUPT_STATUS_CONTINUE5__DC_HPD6_INTERRUPT_MASK
@@ -119,7 +130,7 @@ static void dce_v6_0_audio_endpt_wreg(struct amdgpu_device *adev,
static bool dce_v6_0_is_in_vblank(struct amdgpu_device *adev, int crtc)
{
- if (RREG32(EVERGREEN_CRTC_STATUS + crtc_offsets[crtc]) & EVERGREEN_CRTC_V_BLANK)
+ if (RREG32(mmCRTC_STATUS + crtc_offsets[crtc]) & CRTC_STATUS__CRTC_V_BLANK_MASK)
return true;
else
return false;
@@ -129,8 +140,8 @@ static bool dce_v6_0_is_counter_moving(struct amdgpu_device *adev, int crtc)
{
u32 pos1, pos2;
- pos1 = RREG32(EVERGREEN_CRTC_STATUS_POSITION + crtc_offsets[crtc]);
- pos2 = RREG32(EVERGREEN_CRTC_STATUS_POSITION + crtc_offsets[crtc]);
+ pos1 = RREG32(mmCRTC_STATUS_POSITION + crtc_offsets[crtc]);
+ pos2 = RREG32(mmCRTC_STATUS_POSITION + crtc_offsets[crtc]);
if (pos1 != pos2)
return true;
@@ -152,7 +163,7 @@ static void dce_v6_0_vblank_wait(struct amdgpu_device *adev, int crtc)
if (crtc >= adev->mode_info.num_crtc)
return;
- if (!(RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[crtc]) & EVERGREEN_CRTC_MASTER_EN))
+ if (!(RREG32(mmCRTC_CONTROL + crtc_offsets[crtc]) & CRTC_CONTROL__CRTC_MASTER_EN_MASK))
return;
/* depending on when we hit vblank, we may be close to active; if so,
@@ -180,7 +191,7 @@ static u32 dce_v6_0_vblank_get_counter(struct amdgpu_device *adev, int crtc)
if (crtc >= adev->mode_info.num_crtc)
return 0;
else
- return RREG32(CRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
+ return RREG32(mmCRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
}
static void dce_v6_0_pageflip_interrupt_init(struct amdgpu_device *adev)
@@ -220,16 +231,16 @@ static void dce_v6_0_page_flip(struct amdgpu_device *adev,
struct amdgpu_crtc *amdgpu_crtc = adev->mode_info.crtcs[crtc_id];
/* flip at hsync for async, default is vsync */
- WREG32(EVERGREEN_GRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset, async ?
- EVERGREEN_GRPH_SURFACE_UPDATE_H_RETRACE_EN : 0);
+ WREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset, async ?
+ GRPH_FLIP_CONTROL__GRPH_SURFACE_UPDATE_H_RETRACE_EN_MASK : 0);
/* update the scanout addresses */
- WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
+ WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(crtc_base));
- WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
+ WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
(u32)crtc_base);
/* post the write */
- RREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset);
+ RREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset);
}
static int dce_v6_0_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
@@ -237,8 +248,8 @@ static int dce_v6_0_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
{
if ((crtc < 0) || (crtc >= adev->mode_info.num_crtc))
return -EINVAL;
- *vbl = RREG32(EVERGREEN_CRTC_V_BLANK_START_END + crtc_offsets[crtc]);
- *position = RREG32(EVERGREEN_CRTC_STATUS_POSITION + crtc_offsets[crtc]);
+ *vbl = RREG32(mmCRTC_V_BLANK_START_END + crtc_offsets[crtc]);
+ *position = RREG32(mmCRTC_STATUS_POSITION + crtc_offsets[crtc]);
return 0;
@@ -261,7 +272,7 @@ static bool dce_v6_0_hpd_sense(struct amdgpu_device *adev,
if (hpd >= adev->mode_info.num_hpd)
return connected;
- if (RREG32(DC_HPD1_INT_STATUS + hpd_offsets[hpd]) & DC_HPDx_SENSE)
+ if (RREG32(mmDC_HPD1_INT_STATUS + hpd_offsets[hpd]) & DC_HPD1_INT_STATUS__DC_HPD1_SENSE_MASK)
connected = true;
return connected;
@@ -284,12 +295,12 @@ static void dce_v6_0_hpd_set_polarity(struct amdgpu_device *adev,
if (hpd >= adev->mode_info.num_hpd)
return;
- tmp = RREG32(DC_HPD1_INT_CONTROL + hpd_offsets[hpd]);
+ tmp = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd]);
if (connected)
- tmp &= ~DC_HPDx_INT_POLARITY;
+ tmp &= ~DC_HPD1_INT_CONTROL__DC_HPD1_INT_POLARITY_MASK;
else
- tmp |= DC_HPDx_INT_POLARITY;
- WREG32(DC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp);
+ tmp |= DC_HPD1_INT_CONTROL__DC_HPD1_INT_POLARITY_MASK;
+ WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp);
}
/**
@@ -312,9 +323,9 @@ static void dce_v6_0_hpd_init(struct amdgpu_device *adev)
if (amdgpu_connector->hpd.hpd >= adev->mode_info.num_hpd)
continue;
- tmp = RREG32(DC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd]);
- tmp |= DC_HPDx_EN;
- WREG32(DC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
+ tmp = RREG32(mmDC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd]);
+ tmp |= DC_HPD1_CONTROL__DC_HPD1_EN_MASK;
+ WREG32(mmDC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
connector->connector_type == DRM_MODE_CONNECTOR_LVDS) {
@@ -323,9 +334,9 @@ static void dce_v6_0_hpd_init(struct amdgpu_device *adev)
* https://bugzilla.redhat.com/show_bug.cgi?id=726143
* also avoid interrupt storms during dpms.
*/
- tmp = RREG32(DC_HPD1_INT_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd]);
- tmp &= ~DC_HPDx_INT_EN;
- WREG32(DC_HPD1_INT_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
+ tmp = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd]);
+ tmp &= ~DC_HPD1_INT_CONTROL__DC_HPD1_INT_EN_MASK;
+ WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd], tmp);
continue;
}
@@ -355,9 +366,9 @@ static void dce_v6_0_hpd_fini(struct amdgpu_device *adev)
if (amdgpu_connector->hpd.hpd >= adev->mode_info.num_hpd)
continue;
- tmp = RREG32(DC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd]);
- tmp &= ~DC_HPDx_EN;
- WREG32(DC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd], 0);
+ tmp = RREG32(mmDC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd]);
+ tmp &= ~DC_HPD1_CONTROL__DC_HPD1_EN_MASK;
+ WREG32(mmDC_HPD1_CONTROL + hpd_offsets[amdgpu_connector->hpd.hpd], 0);
amdgpu_irq_put(adev, &adev->hpd_irq, amdgpu_connector->hpd.hpd);
}
@@ -365,7 +376,7 @@ static void dce_v6_0_hpd_fini(struct amdgpu_device *adev)
static u32 dce_v6_0_hpd_get_gpio_reg(struct amdgpu_device *adev)
{
- return SI_DC_GPIO_HPD_A;
+ return mmDC_GPIO_HPD_A;
}
static bool dce_v6_0_is_display_hung(struct amdgpu_device *adev)
@@ -380,7 +391,7 @@ static u32 evergreen_get_vblank_counter(struct amdgpu_device* adev, int crtc)
if (crtc >= adev->mode_info.num_crtc)
return 0;
else
- return RREG32(CRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
+ return RREG32(mmCRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
}
static void dce_v6_0_stop_mc_access(struct amdgpu_device *adev,
@@ -389,25 +400,25 @@ static void dce_v6_0_stop_mc_access(struct amdgpu_device *adev,
u32 crtc_enabled, tmp, frame_count;
int i, j;
- save->vga_render_control = RREG32(VGA_RENDER_CONTROL);
- save->vga_hdp_control = RREG32(VGA_HDP_CONTROL);
+ save->vga_render_control = RREG32(mmVGA_RENDER_CONTROL);
+ save->vga_hdp_control = RREG32(mmVGA_HDP_CONTROL);
/* disable VGA render */
- WREG32(VGA_RENDER_CONTROL, 0);
+ WREG32(mmVGA_RENDER_CONTROL, 0);
/* blank the display controllers */
for (i = 0; i < adev->mode_info.num_crtc; i++) {
- crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]) & EVERGREEN_CRTC_MASTER_EN;
+ crtc_enabled = RREG32(mmCRTC_CONTROL + crtc_offsets[i]) & CRTC_CONTROL__CRTC_MASTER_EN_MASK;
if (crtc_enabled) {
save->crtc_enabled[i] = true;
- tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i]);
+ tmp = RREG32(mmCRTC_BLANK_CONTROL + crtc_offsets[i]);
- if (!(tmp & EVERGREEN_CRTC_BLANK_DATA_EN)) {
+ if (!(tmp & CRTC_BLANK_CONTROL__CRTC_BLANK_DATA_EN_MASK)) {
dce_v6_0_vblank_wait(adev, i);
- WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
- tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
- WREG32(EVERGREEN_CRTC_BLANK_CONTROL + crtc_offsets[i], tmp);
- WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
+ WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 1);
+ tmp |= CRTC_BLANK_CONTROL__CRTC_BLANK_DATA_EN_MASK;
+ WREG32(mmCRTC_BLANK_CONTROL + crtc_offsets[i], tmp);
+ WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 0);
}
/* wait for the next frame */
frame_count = evergreen_get_vblank_counter(adev, i);
@@ -418,11 +429,11 @@ static void dce_v6_0_stop_mc_access(struct amdgpu_device *adev,
}
/* XXX this is a hack to avoid strange behavior with EFI on certain systems */
- WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
- tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
- tmp &= ~EVERGREEN_CRTC_MASTER_EN;
- WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
- WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
+ WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 1);
+ tmp = RREG32(mmCRTC_CONTROL + crtc_offsets[i]);
+ tmp &= ~CRTC_CONTROL__CRTC_MASTER_EN_MASK;
+ WREG32(mmCRTC_CONTROL + crtc_offsets[i], tmp);
+ WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 0);
save->crtc_enabled[i] = false;
/* ***** */
} else {
@@ -439,41 +450,41 @@ static void dce_v6_0_resume_mc_access(struct amdgpu_device *adev,
/* update crtc base addresses */
for (i = 0; i < adev->mode_info.num_crtc; i++) {
- WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
+ WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
upper_32_bits(adev->mc.vram_start));
- WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
+ WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
upper_32_bits(adev->mc.vram_start));
- WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + crtc_offsets[i],
+ WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + crtc_offsets[i],
(u32)adev->mc.vram_start);
- WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + crtc_offsets[i],
+ WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS + crtc_offsets[i],
(u32)adev->mc.vram_start);
}
- WREG32(EVERGREEN_VGA_MEMORY_BASE_ADDRESS_HIGH, upper_32_bits(adev->mc.vram_start));
- WREG32(EVERGREEN_VGA_MEMORY_BASE_ADDRESS, (u32)adev->mc.vram_start);
+ WREG32(mmEVERGREEN_VGA_MEMORY_BASE_ADDRESS_HIGH, upper_32_bits(adev->mc.vram_start));
+ WREG32(mmEVERGREEN_VGA_MEMORY_BASE_ADDRESS, (u32)adev->mc.vram_start);
/* unlock regs and wait for update */
for (i = 0; i < adev->mode_info.num_crtc; i++) {
if (save->crtc_enabled[i]) {
- tmp = RREG32(EVERGREEN_MASTER_UPDATE_MODE + crtc_offsets[i]);
+ tmp = RREG32(mmMASTER_UPDATE_MODE + crtc_offsets[i]);
if ((tmp & 0x7) != 3) {
tmp &= ~0x7;
tmp |= 0x3;
- WREG32(EVERGREEN_MASTER_UPDATE_MODE + crtc_offsets[i], tmp);
+ WREG32(mmMASTER_UPDATE_MODE + crtc_offsets[i], tmp);
}
- tmp = RREG32(EVERGREEN_GRPH_UPDATE + crtc_offsets[i]);
- if (tmp & EVERGREEN_GRPH_UPDATE_LOCK) {
- tmp &= ~EVERGREEN_GRPH_UPDATE_LOCK;
- WREG32(EVERGREEN_GRPH_UPDATE + crtc_offsets[i], tmp);
+ tmp = RREG32(mmGRPH_UPDATE + crtc_offsets[i]);
+ if (tmp & GRPH_UPDATE__GRPH_UPDATE_LOCK_MASK) {
+ tmp &= ~GRPH_UPDATE__GRPH_UPDATE_LOCK_MASK;
+ WREG32(mmGRPH_UPDATE + crtc_offsets[i], tmp);
}
- tmp = RREG32(EVERGREEN_MASTER_UPDATE_LOCK + crtc_offsets[i]);
+ tmp = RREG32(mmMASTER_UPDATE_LOCK + crtc_offsets[i]);
if (tmp & 1) {
tmp &= ~1;
- WREG32(EVERGREEN_MASTER_UPDATE_LOCK + crtc_offsets[i], tmp);
+ WREG32(mmMASTER_UPDATE_LOCK + crtc_offsets[i], tmp);
}
for (j = 0; j < adev->usec_timeout; j++) {
- tmp = RREG32(EVERGREEN_GRPH_UPDATE + crtc_offsets[i]);
- if ((tmp & EVERGREEN_GRPH_SURFACE_UPDATE_PENDING) == 0)
+ tmp = RREG32(mmGRPH_UPDATE + crtc_offsets[i]);
+ if ((tmp & GRPH_UPDATE__GRPH_SURFACE_UPDATE_PENDING_MASK) == 0)
break;
udelay(1);
}
@@ -481,9 +492,9 @@ static void dce_v6_0_resume_mc_access(struct amdgpu_device *adev,
}
/* Unlock vga access */
- WREG32(VGA_HDP_CONTROL, save->vga_hdp_control);
+ WREG32(mmVGA_HDP_CONTROL, save->vga_hdp_control);
mdelay(1);
- WREG32(VGA_RENDER_CONTROL, save->vga_render_control);
+ WREG32(mmVGA_RENDER_CONTROL, save->vga_render_control);
}
@@ -491,8 +502,8 @@ static void dce_v6_0_set_vga_render_state(struct amdgpu_device *adev,
bool render)
{
if (!render)
- WREG32(R_000300_VGA_RENDER_CONTROL,
- RREG32(R_000300_VGA_RENDER_CONTROL) & C_000300_VGA_VSTATUS_CNTL);
+ WREG32(mmR_000300_VGA_RENDER_CONTROL,
+ RREG32(mmR_000300_VGA_RENDER_CONTROL) & C_000300_VGA_VSTATUS_CNTL);
}
@@ -526,14 +537,14 @@ void dce_v6_0_disable_dce(struct amdgpu_device *adev)
/*Disable crtc*/
for (i = 0; i < dce_v6_0_get_num_crtc(adev); i++) {
- crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]) &
- EVERGREEN_CRTC_MASTER_EN;
+ crtc_enabled = RREG32(mmCRTC_CONTROL + crtc_offsets[i]) &
+ CRTC_CONTROL__CRTC_MASTER_EN_MASK;
if (crtc_enabled) {
- WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 1);
- tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
- tmp &= ~EVERGREEN_CRTC_MASTER_EN;
- WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
- WREG32(EVERGREEN_CRTC_UPDATE_LOCK + crtc_offsets[i], 0);
+ WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 1);
+ tmp = RREG32(mmCRTC_CONTROL + crtc_offsets[i]);
+ tmp &= ~CRTC_CONTROL__CRTC_MASTER_EN_MASK;
+ WREG32(mmCRTC_CONTROL + crtc_offsets[i], tmp);
+ WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 0);
}
}
}
@@ -569,19 +580,23 @@ static void dce_v6_0_program_fmt(struct drm_encoder *encoder)
case 6:
if (dither == AMDGPU_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
- tmp |= (FMT_FRAME_RANDOM_ENABLE | FMT_HIGHPASS_RANDOM_ENABLE |
- FMT_SPATIAL_DITHER_EN);
+ tmp |= (FMT_BIT_DEPTH_CONTROL__FMT_FRAME_RANDOM_ENABLE_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_HIGHPASS_RANDOM_ENABLE_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_SPATIAL_DITHER_EN_MASK);
else
- tmp |= FMT_TRUNCATE_EN;
+ tmp |= FMT_BIT_DEPTH_CONTROL__FMT_TRUNCATE_EN_MASK;
break;
case 8:
if (dither == AMDGPU_FMT_DITHER_ENABLE)
/* XXX sort out optimal dither settings */
- tmp |= (FMT_FRAME_RANDOM_ENABLE | FMT_HIGHPASS_RANDOM_ENABLE |
- FMT_RGB_RANDOM_ENABLE |
- FMT_SPATIAL_DITHER_EN | FMT_SPATIAL_DITHER_DEPTH);
+ tmp |= (FMT_BIT_DEPTH_CONTROL__FMT_FRAME_RANDOM_ENABLE_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_HIGHPASS_RANDOM_ENABLE_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_RGB_RANDOM_ENABLE_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_SPATIAL_DITHER_EN_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_SPATIAL_DITHER_DEPTH_MASK);
else
- tmp |= (FMT_TRUNCATE_EN | FMT_TRUNCATE_DEPTH);
+ tmp |= (FMT_BIT_DEPTH_CONTROL__FMT_TRUNCATE_EN_MASK |
+ FMT_BIT_DEPTH_CONTROL__FMT_TRUNCATE_DEPTH_MASK);
break;
case 10:
default:
@@ -589,7 +604,7 @@ static void dce_v6_0_program_fmt(struct drm_encoder *encoder)
break;
}
- WREG32(FMT_BIT_DEPTH_CONTROL + amdgpu_crtc->crtc_offset, tmp);
+ WREG32(mmFMT_BIT_DEPTH_CONTROL + amdgpu_crtc->crtc_offset, tmp);
}
/**
@@ -603,7 +618,7 @@ static void dce_v6_0_program_fmt(struct drm_encoder *encoder)
*/
static u32 si_get_number_of_dram_channels(struct amdgpu_device *adev)
{
- u32 tmp = RREG32(MC_SHARED_CHMAP);
+ u32 tmp = RREG32(mmMC_SHARED_CHMAP);
switch ((tmp & MC_SHARED_CHMAP__NOOFCHAN_MASK) >> MC_SHARED_CHMAP__NOOFCHAN__SHIFT) {
case 0:
@@ -1100,28 +1115,28 @@ static void dce_v6_0_program_watermarks(struct amdgpu_device *adev,
}
/* select wm A */
- arb_control3 = RREG32(DPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset);
+ arb_control3 = RREG32(mmDPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset);
tmp = arb_control3;
tmp &= ~LATENCY_WATERMARK_MASK(3);
tmp |= LATENCY_WATERMARK_MASK(1);
- WREG32(DPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset, tmp);
- WREG32(DPG_PIPE_LATENCY_CONTROL + amdgpu_crtc->crtc_offset,
- (LATENCY_LOW_WATERMARK(latency_watermark_a) |
- LATENCY_HIGH_WATERMARK(line_time)));
+ WREG32(mmDPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset, tmp);
+ WREG32(mmDPG_PIPE_URGENCY_CONTROL + amdgpu_crtc->crtc_offset,
+ ((latency_watermark_a << DPG_PIPE_URGENCY_CONTROL__URGENCY_LOW_WATERMARK__SHIFT) |
+ (line_time << DPG_PIPE_URGENCY_CONTROL__URGENCY_HIGH_WATERMARK__SHIFT)));
/* select wm B */
- tmp = RREG32(DPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset);
+ tmp = RREG32(mmDPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset);
tmp &= ~LATENCY_WATERMARK_MASK(3);
tmp |= LATENCY_WATERMARK_MASK(2);
- WREG32(DPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset, tmp);
- WREG32(DPG_PIPE_LATENCY_CONTROL + amdgpu_crtc->crtc_offset,
- (LATENCY_LOW_WATERMARK(latency_watermark_b) |
- LATENCY_HIGH_WATERMARK(line_time)));
+ WREG32(mmDPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset, tmp);
+ WREG32(mmDPG_PIPE_URGENCY_CONTROL + amdgpu_crtc->crtc_offset,
+ ((latency_watermark_b << DPG_PIPE_URGENCY_CONTROL__URGENCY_LOW_WATERMARK__SHIFT) |
+ (line_time << DPG_PIPE_URGENCY_CONTROL__URGENCY_HIGH_WATERMARK__SHIFT)));
/* restore original selection */
- WREG32(DPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset, arb_control3);
+ WREG32(mmDPG_PIPE_ARBITRATION_CONTROL3 + amdgpu_crtc->crtc_offset, arb_control3);
/* write the priority marks */
- WREG32(PRIORITY_A_CNT + amdgpu_crtc->crtc_offset, priority_a_cnt);
- WREG32(PRIORITY_B_CNT + amdgpu_crtc->crtc_offset, priority_b_cnt);
+ WREG32(mmPRIORITY_A_CNT + amdgpu_crtc->crtc_offset, priority_a_cnt);
+ WREG32(mmPRIORITY_B_CNT + amdgpu_crtc->crtc_offset, priority_b_cnt);
/* save values for DPM */
amdgpu_crtc->line_time = line_time;
@@ -1139,7 +1154,7 @@ static u32 dce_v6_0_line_buffer_adjust(struct amdgpu_device *adev,
/*
* Line Buffer Setup
* There are 3 line buffers, each one shared by 2 display controllers.
- * DC_LB_MEMORY_SPLIT controls how that line buffer is shared between
+ * mmDC_LB_MEMORY_SPLIT controls how that line buffer is shared between
* the display controllers. The paritioning is done via one of four
* preset allocations specified in bits 21:20:
* 0 - half lb
@@ -1162,14 +1177,14 @@ static u32 dce_v6_0_line_buffer_adjust(struct amdgpu_device *adev,
buffer_alloc = 0;
}
- WREG32(DC_LB_MEMORY_SPLIT + amdgpu_crtc->crtc_offset,
+ WREG32(mmDC_LB_MEMORY_SPLIT + amdgpu_crtc->crtc_offset,
DC_LB_MEMORY_CONFIG(tmp));
- WREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
- DMIF_BUFFERS_ALLOCATED(buffer_alloc));
+ WREG32(mmPIPE0_DMIF_BUFFER_CONTROL + pipe_offset,
+ (buffer_alloc << PIPE0_DMIF_BUFFER_CONTROL__DMIF_BUFFERS_ALLOCATED__SHIFT));
for (i = 0; i < adev->usec_timeout; i++) {
- if (RREG32(PIPE0_DMIF_BUFFER_CONTROL + pipe_offset) &
- DMIF_BUFFERS_ALLOCATED_COMPLETED)
+ if (RREG32(mmPIPE0_DMIF_BUFFER_CONTROL + pipe_offset) &
+ PIPE0_DMIF_BUFFER_CONTROL__DMIF_BUFFERS_ALLOCATION_COMPLETED_MASK)
break;
udelay(1);
}
@@ -1411,12 +1426,12 @@ static void dce_v6_0_afmt_fini(struct amdgpu_device *adev)
static const u32 vga_control_regs[6] =
{
- AVIVO_D1VGA_CONTROL,
- AVIVO_D2VGA_CONTROL,
- EVERGREEN_D3VGA_CONTROL,
- EVERGREEN_D4VGA_CONTROL,
- EVERGREEN_D5VGA_CONTROL,
- EVERGREEN_D6VGA_CONTROL,
+ mmAVIVO_D1VGA_CONTROL,
+ mmAVIVO_D2VGA_CONTROL,
+ mmEVERGREEN_D3VGA_CONTROL,
+ mmEVERGREEN_D4VGA_CONTROL,
+ mmEVERGREEN_D5VGA_CONTROL,
+ mmEVERGREEN_D6VGA_CONTROL,
};
static void dce_v6_0_vga_enable(struct drm_crtc *crtc, bool enable)
@@ -1436,7 +1451,7 @@ static void dce_v6_0_grph_enable(struct drm_crtc *crtc, bool enable)
struct drm_device *dev = crtc->dev;
struct amdgpu_device *adev = dev->dev_private;
- WREG32(EVERGREEN_GRPH_ENABLE + amdgpu_crtc->crtc_offset, enable ? 1 : 0);
+ WREG32(mmGRPH_ENABLE + amdgpu_crtc->crtc_offset, enable ? 1 : 0);
}
static int dce_v6_0_crtc_do_set_base(struct drm_crtc *crtc,
@@ -1590,57 +1605,57 @@ static int dce_v6_0_crtc_do_set_base(struct drm_crtc *crtc,
/* Make sure surface address is updated at vertical blank rather than
* horizontal blank
*/
- WREG32(EVERGREEN_GRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
+ WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(fb_location));
- WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
+ WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(fb_location));
- WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
- (u32)fb_location & EVERGREEN_GRPH_SURFACE_ADDRESS_MASK);
- WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
- (u32) fb_location & EVERGREEN_GRPH_SURFACE_ADDRESS_MASK);
- WREG32(EVERGREEN_GRPH_CONTROL + amdgpu_crtc->crtc_offset, fb_format);
- WREG32(EVERGREEN_GRPH_SWAP_CONTROL + amdgpu_crtc->crtc_offset, fb_swap);
+ WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
+ (u32)fb_location & GRPH_PRIMARY_SURFACE_ADDRESS__GRPH_PRIMARY_SURFACE_ADDRESS_MASK);
+ WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
+ (u32) fb_location & GRPH_PRIMARY_SURFACE_ADDRESS__GRPH_PRIMARY_SURFACE_ADDRESS_MASK);
+ WREG32(mmGRPH_CONTROL + amdgpu_crtc->crtc_offset, fb_format);
+ WREG32(mmGRPH_SWAP_CNTL + amdgpu_crtc->crtc_offset, fb_swap);
/*
* The LUT only has 256 slots for indexing by a 8 bpc fb. Bypass the LUT
* for > 8 bpc scanout to avoid truncation of fb indices to 8 msb's, to
* retain the full precision throughout the pipeline.
*/
- WREG32_P(EVERGREEN_GRPH_LUT_10BIT_BYPASS_CONTROL + amdgpu_crtc->crtc_offset,
- (bypass_lut ? EVERGREEN_LUT_10BIT_BYPASS_EN : 0),
- ~EVERGREEN_LUT_10BIT_BYPASS_EN);
+ WREG32_P(mmGRPH_LUT_10BIT_BYPASS + amdgpu_crtc->crtc_offset,
+ (bypass_lut ? GRPH_LUT_10BIT_BYPASS__GRPH_LUT_10BIT_BYPASS_EN_MASK : 0),
+ ~GRPH_LUT_10BIT_BYPASS__GRPH_LUT_10BIT_BYPASS_EN_MASK);
if (bypass_lut)
DRM_DEBUG_KMS("Bypassing hardware LUT due to 10 bit fb scanout.\n");
- WREG32(EVERGREEN_GRPH_SURFACE_OFFSET_X + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_GRPH_SURFACE_OFFSET_Y + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_GRPH_X_START + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_GRPH_Y_START + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_GRPH_X_END + amdgpu_crtc->crtc_offset, target_fb->width);
- WREG32(EVERGREEN_GRPH_Y_END + amdgpu_crtc->crtc_offset, target_fb->height);
+ WREG32(mmGRPH_SURFACE_OFFSET_X + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmGRPH_SURFACE_OFFSET_Y + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmGRPH_X_START + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmGRPH_Y_START + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmGRPH_X_END + amdgpu_crtc->crtc_offset, target_fb->width);
+ WREG32(mmGRPH_Y_END + amdgpu_crtc->crtc_offset, target_fb->height);
fb_pitch_pixels = target_fb->pitches[0] / (target_fb->bits_per_pixel / 8);
- WREG32(EVERGREEN_GRPH_PITCH + amdgpu_crtc->crtc_offset, fb_pitch_pixels);
+ WREG32(mmGRPH_PITCH + amdgpu_crtc->crtc_offset, fb_pitch_pixels);
dce_v6_0_grph_enable(crtc, true);
- WREG32(EVERGREEN_DESKTOP_HEIGHT + amdgpu_crtc->crtc_offset,
+ WREG32(mmEVERGREEN_DESKTOP_HEIGHT + amdgpu_crtc->crtc_offset,
target_fb->height);
x &= ~3;
y &= ~1;
- WREG32(EVERGREEN_VIEWPORT_START + amdgpu_crtc->crtc_offset,
+ WREG32(mmVIEWPORT_START + amdgpu_crtc->crtc_offset,
(x << 16) | y);
viewport_w = crtc->mode.hdisplay;
viewport_h = (crtc->mode.vdisplay + 1) & ~1;
- WREG32(EVERGREEN_VIEWPORT_SIZE + amdgpu_crtc->crtc_offset,
+ WREG32(mmVIEWPORT_SIZE + amdgpu_crtc->crtc_offset,
(viewport_w << 16) | viewport_h);
/* set pageflip to happen only at start of vblank interval (front porch) */
- WREG32(EVERGREEN_MASTER_UPDATE_MODE + amdgpu_crtc->crtc_offset, 3);
+ WREG32(mmMASTER_UPDATE_MODE + amdgpu_crtc->crtc_offset, 3);
if (!atomic && fb && fb != crtc->primary->fb) {
amdgpu_fb = to_amdgpu_framebuffer(fb);
@@ -1667,10 +1682,10 @@ static void dce_v6_0_set_interleave(struct drm_crtc *crtc,
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
- WREG32(EVERGREEN_DATA_FORMAT + amdgpu_crtc->crtc_offset,
+ WREG32(mmEVERGREEN_DATA_FORMAT + amdgpu_crtc->crtc_offset,
EVERGREEN_INTERLEAVE_EN);
else
- WREG32(EVERGREEN_DATA_FORMAT + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmEVERGREEN_DATA_FORMAT + amdgpu_crtc->crtc_offset, 0);
}
static void dce_v6_0_crtc_load_lut(struct drm_crtc *crtc)
@@ -1683,54 +1698,52 @@ static void dce_v6_0_crtc_load_lut(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%d\n", amdgpu_crtc->crtc_id);
- WREG32(NI_INPUT_CSC_CONTROL + amdgpu_crtc->crtc_offset,
- (NI_INPUT_CSC_GRPH_MODE(NI_INPUT_CSC_BYPASS) |
- NI_INPUT_CSC_OVL_MODE(NI_INPUT_CSC_BYPASS)));
- WREG32(NI_PRESCALE_GRPH_CONTROL + amdgpu_crtc->crtc_offset,
- NI_GRPH_PRESCALE_BYPASS);
- WREG32(NI_PRESCALE_OVL_CONTROL + amdgpu_crtc->crtc_offset,
- NI_OVL_PRESCALE_BYPASS);
- WREG32(NI_INPUT_GAMMA_CONTROL + amdgpu_crtc->crtc_offset,
- (NI_GRPH_INPUT_GAMMA_MODE(NI_INPUT_GAMMA_USE_LUT) |
- NI_OVL_INPUT_GAMMA_MODE(NI_INPUT_GAMMA_USE_LUT)));
-
-
+ WREG32(mmINPUT_CSC_CONTROL + amdgpu_crtc->crtc_offset,
+ ((0 << INPUT_CSC_CONTROL__INPUT_CSC_GRPH_MODE__SHIFT) |
+ (0 << INPUT_CSC_CONTROL__INPUT_CSC_OVL_MODE__SHIFT)));
+ WREG32(mmPRESCALE_GRPH_CONTROL + amdgpu_crtc->crtc_offset,
+ PRESCALE_GRPH_CONTROL__GRPH_PRESCALE_BYPASS_MASK);
+ WREG32(mmPRESCALE_OVL_CONTROL + amdgpu_crtc->crtc_offset,
+ PRESCALE_OVL_CONTROL__OVL_PRESCALE_BYPASS_MASK);
+ WREG32(mmINPUT_GAMMA_CONTROL + amdgpu_crtc->crtc_offset,
+ ((0 << INPUT_GAMMA_CONTROL__GRPH_INPUT_GAMMA_MODE__SHIFT) |
+ (0 << INPUT_GAMMA_CONTROL__OVL_INPUT_GAMMA_MODE__SHIFT)));
- WREG32(EVERGREEN_DC_LUT_CONTROL + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmDC_LUT_CONTROL + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_DC_LUT_BLACK_OFFSET_BLUE + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_DC_LUT_BLACK_OFFSET_GREEN + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_DC_LUT_BLACK_OFFSET_RED + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmDC_LUT_BLACK_OFFSET_BLUE + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmDC_LUT_BLACK_OFFSET_GREEN + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmDC_LUT_BLACK_OFFSET_RED + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_BLUE + amdgpu_crtc->crtc_offset, 0xffff);
- WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_GREEN + amdgpu_crtc->crtc_offset, 0xffff);
- WREG32(EVERGREEN_DC_LUT_WHITE_OFFSET_RED + amdgpu_crtc->crtc_offset, 0xffff);
+ WREG32(mmDC_LUT_WHITE_OFFSET_BLUE + amdgpu_crtc->crtc_offset, 0xffff);
+ WREG32(mmDC_LUT_WHITE_OFFSET_GREEN + amdgpu_crtc->crtc_offset, 0xffff);
+ WREG32(mmDC_LUT_WHITE_OFFSET_RED + amdgpu_crtc->crtc_offset, 0xffff);
- WREG32(EVERGREEN_DC_LUT_RW_MODE + amdgpu_crtc->crtc_offset, 0);
- WREG32(EVERGREEN_DC_LUT_WRITE_EN_MASK + amdgpu_crtc->crtc_offset, 0x00000007);
+ WREG32(mmDC_LUT_RW_MODE + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmDC_LUT_WRITE_EN_MASK + amdgpu_crtc->crtc_offset, 0x00000007);
- WREG32(EVERGREEN_DC_LUT_RW_INDEX + amdgpu_crtc->crtc_offset, 0);
+ WREG32(mmDC_LUT_RW_INDEX + amdgpu_crtc->crtc_offset, 0);
for (i = 0; i < 256; i++) {
- WREG32(EVERGREEN_DC_LUT_30_COLOR + amdgpu_crtc->crtc_offset,
+ WREG32(mmDC_LUT_30_COLOR + amdgpu_crtc->crtc_offset,
(amdgpu_crtc->lut_r[i] << 20) |
(amdgpu_crtc->lut_g[i] << 10) |
(amdgpu_crtc->lut_b[i] << 0));
}
- WREG32(NI_DEGAMMA_CONTROL + amdgpu_crtc->crtc_offset,
- (NI_GRPH_DEGAMMA_MODE(NI_DEGAMMA_BYPASS) |
- NI_OVL_DEGAMMA_MODE(NI_DEGAMMA_BYPASS) |
- NI_ICON_DEGAMMA_MODE(NI_DEGAMMA_BYPASS) |
- NI_CURSOR_DEGAMMA_MODE(NI_DEGAMMA_BYPASS)));
- WREG32(NI_GAMUT_REMAP_CONTROL + amdgpu_crtc->crtc_offset,
- (NI_GRPH_GAMUT_REMAP_MODE(NI_GAMUT_REMAP_BYPASS) |
- NI_OVL_GAMUT_REMAP_MODE(NI_GAMUT_REMAP_BYPASS)));
- WREG32(NI_REGAMMA_CONTROL + amdgpu_crtc->crtc_offset,
- (NI_GRPH_REGAMMA_MODE(NI_REGAMMA_BYPASS) |
- NI_OVL_REGAMMA_MODE(NI_REGAMMA_BYPASS)));
- WREG32(NI_OUTPUT_CSC_CONTROL + amdgpu_crtc->crtc_offset,
- (NI_OUTPUT_CSC_GRPH_MODE(0) |
- NI_OUTPUT_CSC_OVL_MODE(NI_OUTPUT_CSC_BYPASS)));
+ WREG32(mmDEGAMMA_CONTROL + amdgpu_crtc->crtc_offset,
+ ((0 << DEGAMMA_CONTROL__GRPH_DEGAMMA_MODE__SHIFT) |
+ (0 << DEGAMMA_CONTROL__OVL_DEGAMMA_MODE__SHIFT) |
+ NI_ICON_DEGAMMA_MODE(0) |
+ (0 << DEGAMMA_CONTROL__CURSOR_DEGAMMA_MODE__SHIFT)));
+ WREG32(mmGAMUT_REMAP_CONTROL + amdgpu_crtc->crtc_offset,
+ ((0 << GAMUT_REMAP_CONTROL__GRPH_GAMUT_REMAP_MODE__SHIFT) |
+ (0 << GAMUT_REMAP_CONTROL__OVL_GAMUT_REMAP_MODE__SHIFT)));
+ WREG32(mmREGAMMA_CONTROL + amdgpu_crtc->crtc_offset,
+ ((0 << REGAMMA_CONTROL__GRPH_REGAMMA_MODE__SHIFT) |
+ (0 << REGAMMA_CONTROL__OVL_REGAMMA_MODE__SHIFT)));
+ WREG32(mmOUTPUT_CSC_CONTROL + amdgpu_crtc->crtc_offset,
+ ((0 << OUTPUT_CSC_CONTROL__OUTPUT_CSC_GRPH_MODE__SHIFT) |
+ (0 << OUTPUT_CSC_CONTROL__OUTPUT_CSC_OVL_MODE__SHIFT)));
/* XXX match this to the depth of the crtc fmt block, move to modeset? */
WREG32(0x1a50 + amdgpu_crtc->crtc_offset, 0);
@@ -1809,12 +1822,12 @@ static void dce_v6_0_lock_cursor(struct drm_crtc *crtc, bool lock)
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
uint32_t cur_lock;
- cur_lock = RREG32(EVERGREEN_CUR_UPDATE + amdgpu_crtc->crtc_offset);
+ cur_lock = RREG32(mmCUR_UPDATE + amdgpu_crtc->crtc_offset);
if (lock)
- cur_lock |= EVERGREEN_CURSOR_UPDATE_LOCK;
+ cur_lock |= CUR_UPDATE__CURSOR_UPDATE_LOCK_MASK;
else
- cur_lock &= ~EVERGREEN_CURSOR_UPDATE_LOCK;
- WREG32(EVERGREEN_CUR_UPDATE + amdgpu_crtc->crtc_offset, cur_lock);
+ cur_lock &= ~CUR_UPDATE__CURSOR_UPDATE_LOCK_MASK;
+ WREG32(mmCUR_UPDATE + amdgpu_crtc->crtc_offset, cur_lock);
}
static void dce_v6_0_hide_cursor(struct drm_crtc *crtc)
@@ -1822,9 +1835,9 @@ static void dce_v6_0_hide_cursor(struct drm_crtc *crtc)
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_device *adev = crtc->dev->dev_private;
- WREG32_IDX(EVERGREEN_CUR_CONTROL + amdgpu_crtc->crtc_offset,
- EVERGREEN_CURSOR_MODE(EVERGREEN_CURSOR_24_8_PRE_MULT) |
- EVERGREEN_CURSOR_URGENT_CONTROL(EVERGREEN_CURSOR_URGENT_1_2));
+ WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset,
+ (EVERGREEN_CURSOR_24_8_PRE_MULT << CUR_CONTROL__CURSOR_MODE__SHIFT) |
+ (EVERGREEN_CURSOR_URGENT_1_2 << CUR_CONTROL__CURSOR_URGENT_CONTROL__SHIFT));
}
@@ -1834,15 +1847,15 @@ static void dce_v6_0_show_cursor(struct drm_crtc *crtc)
struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
struct amdgpu_device *adev = crtc->dev->dev_private;
- WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
+ WREG32(mmCUR_SURFACE_ADDRESS_HIGH + amdgpu_crtc->crtc_offset,
upper_32_bits(amdgpu_crtc->cursor_addr));
- WREG32(EVERGREEN_CUR_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
+ WREG32(mmCUR_SURFACE_ADDRESS + amdgpu_crtc->crtc_offset,
lower_32_bits(amdgpu_crtc->cursor_addr));
- WREG32_IDX(EVERGREEN_CUR_CONTROL + amdgpu_crtc->crtc_offset,
- EVERGREEN_CURSOR_EN |
- EVERGREEN_CURSOR_MODE(EVERGREEN_CURSOR_24_8_PRE_MULT) |
- EVERGREEN_CURSOR_URGENT_CONTROL(EVERGREEN_CURSOR_URGENT_1_2));
+ WREG32_IDX(mmCUR_CONTROL + amdgpu_crtc->crtc_offset,
+ CUR_CONTROL__CURSOR_EN_MASK |
+ (EVERGREEN_CURSOR_24_8_PRE_MULT << CUR_CONTROL__CURSOR_MODE__SHIFT) |
+ (EVERGREEN_CURSOR_URGENT_1_2 << CUR_CONTROL__CURSOR_URGENT_CONTROL__SHIFT));
}
@@ -1869,9 +1882,9 @@ static int dce_v6_0_cursor_move_locked(struct drm_crtc *crtc,
y = 0;
}
- WREG32(EVERGREEN_CUR_POSITION + amdgpu_crtc->crtc_offset, (x << 16) | y);
- WREG32(EVERGREEN_CUR_HOT_SPOT + amdgpu_crtc->crtc_offset, (xorigin << 16) | yorigin);
- WREG32(EVERGREEN_CUR_SIZE + amdgpu_crtc->crtc_offset,
+ WREG32(mmCUR_POSITION + amdgpu_crtc->crtc_offset, (x << 16) | y);
+ WREG32(mmCUR_HOT_SPOT + amdgpu_crtc->crtc_offset, (xorigin << 16) | yorigin);
+ WREG32(mmCUR_SIZE + amdgpu_crtc->crtc_offset,
((w - 1) << 16) | (amdgpu_crtc->cursor_height - 1));
amdgpu_crtc->cursor_x = x;
@@ -2475,14 +2488,14 @@ static void dce_v6_0_set_crtc_vblank_interrupt_state(struct amdgpu_device *adev,
switch (state) {
case AMDGPU_IRQ_STATE_DISABLE:
- interrupt_mask = RREG32(INT_MASK + reg_block);
+ interrupt_mask = RREG32(mmINT_MASK + reg_block);
interrupt_mask &= ~VBLANK_INT_MASK;
- WREG32(INT_MASK + reg_block, interrupt_mask);
+ WREG32(mmINT_MASK + reg_block, interrupt_mask);
break;
case AMDGPU_IRQ_STATE_ENABLE:
- interrupt_mask = RREG32(INT_MASK + reg_block);
+ interrupt_mask = RREG32(mmINT_MASK + reg_block);
interrupt_mask |= VBLANK_INT_MASK;
- WREG32(INT_MASK + reg_block, interrupt_mask);
+ WREG32(mmINT_MASK + reg_block, interrupt_mask);
break;
default:
break;
@@ -2510,14 +2523,14 @@ static int dce_v6_0_set_hpd_interrupt_state(struct amdgpu_device *adev,
switch (state) {
case AMDGPU_IRQ_STATE_DISABLE:
- dc_hpd_int_cntl = RREG32(DC_HPD1_INT_CONTROL + hpd_offsets[type]);
+ dc_hpd_int_cntl = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[type]);
dc_hpd_int_cntl &= ~DC_HPDx_INT_EN;
- WREG32(DC_HPD1_INT_CONTROL + hpd_offsets[type], dc_hpd_int_cntl);
+ WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[type], dc_hpd_int_cntl);
break;
case AMDGPU_IRQ_STATE_ENABLE:
- dc_hpd_int_cntl = RREG32(DC_HPD1_INT_CONTROL + hpd_offsets[type]);
+ dc_hpd_int_cntl = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[type]);
dc_hpd_int_cntl |= DC_HPDx_INT_EN;
- WREG32(DC_HPD1_INT_CONTROL + hpd_offsets[type], dc_hpd_int_cntl);
+ WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[type], dc_hpd_int_cntl);
break;
default:
break;
@@ -2585,7 +2598,7 @@ static int dce_v6_0_crtc_irq(struct amdgpu_device *adev,
switch (entry->src_data) {
case 0: /* vblank */
if (disp_int & interrupt_status_offsets[crtc].vblank)
- WREG32(VBLANK_STATUS + crtc_offsets[crtc], VBLANK_ACK);
+ WREG32(mmVBLANK_STATUS + crtc_offsets[crtc], VBLANK_ACK);
else
DRM_DEBUG("IH: IH event w/o asserted irq bit?\n");
@@ -2596,7 +2609,7 @@ static int dce_v6_0_crtc_irq(struct amdgpu_device *adev,
break;
case 1: /* vline */
if (disp_int & interrupt_status_offsets[crtc].vline)
- WREG32(VLINE_STATUS + crtc_offsets[crtc], VLINE_ACK);
+ WREG32(mmVLINE_STATUS + crtc_offsets[crtc], VLINE_ACK);
else
DRM_DEBUG("IH: IH event w/o asserted irq bit?\n");
@@ -2622,12 +2635,12 @@ static int dce_v6_0_set_pageflip_interrupt_state(struct amdgpu_device *adev,
return -EINVAL;
}
- reg = RREG32(GRPH_INT_CONTROL + crtc_offsets[type]);
+ reg = RREG32(mmGRPH_INTERRUPT_CONTROL + crtc_offsets[type]);
if (state == AMDGPU_IRQ_STATE_DISABLE)
- WREG32(GRPH_INT_CONTROL + crtc_offsets[type],
+ WREG32(mmGRPH_INTERRUPT_CONTROL + crtc_offsets[type],
reg & ~GRPH_INTERRUPT_CONTROL__GRPH_PFLIP_INT_MASK_MASK);
else
- WREG32(GRPH_INT_CONTROL + crtc_offsets[type],
+ WREG32(mmGRPH_INTERRUPT_CONTROL + crtc_offsets[type],
reg | GRPH_INTERRUPT_CONTROL__GRPH_PFLIP_INT_MASK_MASK);
return 0;
@@ -2650,9 +2663,9 @@ static int dce_v6_0_pageflip_irq(struct amdgpu_device *adev,
return -EINVAL;
}
- if (RREG32(GRPH_INT_STATUS + crtc_offsets[crtc_id]) &
+ if (RREG32(mmGRPH_INTERRUPT_STATUS + crtc_offsets[crtc_id]) &
GRPH_INTERRUPT_STATUS__GRPH_PFLIP_INT_OCCURRED_MASK)
- WREG32(GRPH_INT_STATUS + crtc_offsets[crtc_id],
+ WREG32(mmGRPH_INTERRUPT_STATUS + crtc_offsets[crtc_id],
GRPH_INTERRUPT_STATUS__GRPH_PFLIP_INT_CLEAR_MASK);
/* IRQ could occur when in initial stage */
@@ -2703,9 +2716,9 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev,
mask = interrupt_status_offsets[hpd].hpd;
if (disp_int & mask) {
- tmp = RREG32(DC_HPD1_INT_CONTROL + hpd_offsets[hpd]);
+ tmp = RREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd]);
tmp |= DC_HPD1_INT_CONTROL__DC_HPD1_INT_ACK_MASK;
- WREG32(DC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp);
+ WREG32(mmDC_HPD1_INT_CONTROL + hpd_offsets[hpd], tmp);
schedule_work(&adev->hotplug_work);
DRM_INFO("IH: HPD%d\n", hpd + 1);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/si_enums.h b/drivers/gpu/drm/amd/amdgpu/si_enums.h
index 3ecd36f30e2a..a57054fcb448 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_enums.h
+++ b/drivers/gpu/drm/amd/amdgpu/si_enums.h
@@ -23,6 +23,84 @@
#ifndef SI_ENUMS_H
#define SI_ENUMS_H
+#define VBLANK_INT_MASK (1 << 0)
+#define DC_HPDx_INT_EN (1 << 16)
+#define VBLANK_ACK (1 << 4)
+#define VLINE_ACK (1 << 4)
+
+#define CURSOR_WIDTH 64
+#define CURSOR_HEIGHT 64
+
+#define C_000300_VGA_VSTATUS_CNTL 0xFFFCFFFF
+#define PRIORITY_MARK_MASK 0x7fff
+#define PRIORITY_OFF (1 << 16)
+#define PRIORITY_ALWAYS_ON (1 << 20)
+#define EVERGREEN_INTERLEAVE_EN (1 << 0)
+
+#define LATENCY_WATERMARK_MASK(x) ((x) << 16)
+#define DC_LB_MEMORY_CONFIG(x) ((x) << 20)
+#define NI_ICON_DEGAMMA_MODE(x) (((x) & 0x3) << 8)
+
+#define EVERGREEN_GRPH_ENDIAN_SWAP(x) (((x) & 0x3) << 0)
+#define EVERGREEN_GRPH_ENDIAN_NONE 0
+#define EVERGREEN_GRPH_ENDIAN_8IN16 1
+#define EVERGREEN_GRPH_ENDIAN_8IN32 2
+#define EVERGREEN_GRPH_ENDIAN_8IN64 3
+
+#define EVERGREEN_GRPH_DEPTH(x) (((x) & 0x3) << 0)
+#define EVERGREEN_GRPH_DEPTH_8BPP 0
+#define EVERGREEN_GRPH_DEPTH_16BPP 1
+#define EVERGREEN_GRPH_DEPTH_32BPP 2
+
+#define EVERGREEN_GRPH_FORMAT(x) (((x) & 0x7) << 8)
+#define EVERGREEN_GRPH_FORMAT_INDEXED 0
+#define EVERGREEN_GRPH_FORMAT_ARGB1555 0
+#define EVERGREEN_GRPH_FORMAT_ARGB565 1
+#define EVERGREEN_GRPH_FORMAT_ARGB4444 2
+#define EVERGREEN_GRPH_FORMAT_AI88 3
+#define EVERGREEN_GRPH_FORMAT_MONO16 4
+#define EVERGREEN_GRPH_FORMAT_BGRA5551 5
+#define EVERGREEN_GRPH_FORMAT_ARGB8888 0
+#define EVERGREEN_GRPH_FORMAT_ARGB2101010 1
+#define EVERGREEN_GRPH_FORMAT_32BPP_DIG 2
+#define EVERGREEN_GRPH_FORMAT_8B_ARGB2101010 3
+#define EVERGREEN_GRPH_FORMAT_BGRA1010102 4
+#define EVERGREEN_GRPH_FORMAT_8B_BGRA1010102 5
+#define EVERGREEN_GRPH_FORMAT_RGB111110 6
+#define EVERGREEN_GRPH_FORMAT_BGR101111 7
+
+#define EVERGREEN_GRPH_NUM_BANKS(x) (((x) & 0x3) << 2)
+#define EVERGREEN_GRPH_ARRAY_MODE(x) (((x) & 0x7) << 20)
+#define EVERGREEN_GRPH_ARRAY_LINEAR_GENERAL 0
+#define EVERGREEN_GRPH_ARRAY_LINEAR_ALIGNED 1
+#define EVERGREEN_GRPH_ARRAY_1D_TILED_THIN1 2
+#define EVERGREEN_GRPH_ARRAY_2D_TILED_THIN1 4
+#define EVERGREEN_GRPH_TILE_SPLIT(x) (((x) & 0x7) << 13)
+#define EVERGREEN_GRPH_BANK_WIDTH(x) (((x) & 0x3) << 6)
+#define EVERGREEN_GRPH_BANK_HEIGHT(x) (((x) & 0x3) << 11)
+#define EVERGREEN_GRPH_MACRO_TILE_ASPECT(x) (((x) & 0x3) << 18)
+#define EVERGREEN_GRPH_ARRAY_MODE(x) (((x) & 0x7) << 20)
+#define SI_GRPH_PIPE_CONFIG(x) (((x) & 0x1f) << 24)
+
+#define EVERGREEN_CURSOR_EN (1 << 0)
+#define EVERGREEN_CURSOR_MODE(x) (((x) & 0x3) << 8)
+#define EVERGREEN_CURSOR_MONO 0
+#define EVERGREEN_CURSOR_24_1 1
+#define EVERGREEN_CURSOR_24_8_PRE_MULT 2
+#define EVERGREEN_CURSOR_24_8_UNPRE_MULT 3
+#define EVERGREEN_CURSOR_2X_MAGNIFY (1 << 16)
+#define EVERGREEN_CURSOR_FORCE_MC_ON (1 << 20)
+#define EVERGREEN_CURSOR_URGENT_CONTROL(x) (((x) & 0x7) << 24)
+#define EVERGREEN_CURSOR_URGENT_ALWAYS 0
+#define EVERGREEN_CURSOR_URGENT_1_8 1
+#define EVERGREEN_CURSOR_URGENT_1_4 2
+#define EVERGREEN_CURSOR_URGENT_3_8 3
+#define EVERGREEN_CURSOR_URGENT_1_2 4
+#define EVERGREEN_CURSOR_UPDATE_PENDING (1 << 0)
+#define EVERGREEN_CURSOR_UPDATE_TAKEN (1 << 1)
+#define EVERGREEN_CURSOR_UPDATE_LOCK (1 << 16)
+#define EVERGREEN_CURSOR_DISABLE_MULTIPLE_UPDATE (1 << 24)
+
#define AMDGPU_NUM_OF_VMIDS 8
#define SI_CRTC0_REGISTER_OFFSET 0
#define SI_CRTC1_REGISTER_OFFSET 0x300
@@ -68,127 +146,128 @@
#define VERDE_GB_ADDR_CONFIG_GOLDEN 0x12010002
#define HAINAN_GB_ADDR_CONFIG_GOLDEN 0x02010001
-#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) | \
- (((op) & 0xFF) << 8) | \
+#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) | \
+ (((op) & 0xFF) << 8) | \
((n) & 0x3FFF) << 16)
+
#define PACKET3_COMPUTE(op, n) (PACKET3(op, n) | 1 << 1)
-#define PACKET3_NOP 0x10
-#define PACKET3_SET_BASE 0x11
-#define PACKET3_BASE_INDEX(x) ((x) << 0)
-#define PACKET3_CLEAR_STATE 0x12
-#define PACKET3_INDEX_BUFFER_SIZE 0x13
-#define PACKET3_DISPATCH_DIRECT 0x15
-#define PACKET3_DISPATCH_INDIRECT 0x16
-#define PACKET3_ALLOC_GDS 0x1B
-#define PACKET3_WRITE_GDS_RAM 0x1C
-#define PACKET3_ATOMIC_GDS 0x1D
-#define PACKET3_ATOMIC 0x1E
-#define PACKET3_OCCLUSION_QUERY 0x1F
-#define PACKET3_SET_PREDICATION 0x20
-#define PACKET3_REG_RMW 0x21
-#define PACKET3_COND_EXEC 0x22
-#define PACKET3_PRED_EXEC 0x23
-#define PACKET3_DRAW_INDIRECT 0x24
-#define PACKET3_DRAW_INDEX_INDIRECT 0x25
-#define PACKET3_INDEX_BASE 0x26
-#define PACKET3_DRAW_INDEX_2 0x27
-#define PACKET3_CONTEXT_CONTROL 0x28
-#define PACKET3_INDEX_TYPE 0x2A
-#define PACKET3_DRAW_INDIRECT_MULTI 0x2C
-#define PACKET3_DRAW_INDEX_AUTO 0x2D
-#define PACKET3_DRAW_INDEX_IMMD 0x2E
-#define PACKET3_NUM_INSTANCES 0x2F
-#define PACKET3_DRAW_INDEX_MULTI_AUTO 0x30
-#define PACKET3_INDIRECT_BUFFER_CONST 0x31
-#define PACKET3_INDIRECT_BUFFER 0x3F
-#define PACKET3_STRMOUT_BUFFER_UPDATE 0x34
-#define PACKET3_DRAW_INDEX_OFFSET_2 0x35
-#define PACKET3_DRAW_INDEX_MULTI_ELEMENT 0x36
-#define PACKET3_WRITE_DATA 0x37
-#define PACKET3_DRAW_INDEX_INDIRECT_MULTI 0x38
-#define PACKET3_MEM_SEMAPHORE 0x39
-#define PACKET3_MPEG_INDEX 0x3A
-#define PACKET3_COPY_DW 0x3B
-#define PACKET3_WAIT_REG_MEM 0x3C
-#define PACKET3_MEM_WRITE 0x3D
-#define PACKET3_COPY_DATA 0x40
-#define PACKET3_CP_DMA 0x41
-# define PACKET3_CP_DMA_DST_SEL(x) ((x) << 20)
-# define PACKET3_CP_DMA_ENGINE(x) ((x) << 27)
-# define PACKET3_CP_DMA_SRC_SEL(x) ((x) << 29)
-# define PACKET3_CP_DMA_CP_SYNC (1 << 31)
-# define PACKET3_CP_DMA_DIS_WC (1 << 21)
-# define PACKET3_CP_DMA_CMD_SRC_SWAP(x) ((x) << 22)
-# define PACKET3_CP_DMA_CMD_DST_SWAP(x) ((x) << 24)
-# define PACKET3_CP_DMA_CMD_SAS (1 << 26)
-# define PACKET3_CP_DMA_CMD_DAS (1 << 27)
-# define PACKET3_CP_DMA_CMD_SAIC (1 << 28)
-# define PACKET3_CP_DMA_CMD_DAIC (1 << 29)
-# define PACKET3_CP_DMA_CMD_RAW_WAIT (1 << 30)
-#define PACKET3_PFP_SYNC_ME 0x42
-#define PACKET3_SURFACE_SYNC 0x43
-# define PACKET3_DEST_BASE_0_ENA (1 << 0)
-# define PACKET3_DEST_BASE_1_ENA (1 << 1)
-# define PACKET3_CB0_DEST_BASE_ENA (1 << 6)
-# define PACKET3_CB1_DEST_BASE_ENA (1 << 7)
-# define PACKET3_CB2_DEST_BASE_ENA (1 << 8)
-# define PACKET3_CB3_DEST_BASE_ENA (1 << 9)
-# define PACKET3_CB4_DEST_BASE_ENA (1 << 10)
-# define PACKET3_CB5_DEST_BASE_ENA (1 << 11)
-# define PACKET3_CB6_DEST_BASE_ENA (1 << 12)
-# define PACKET3_CB7_DEST_BASE_ENA (1 << 13)
-# define PACKET3_DB_DEST_BASE_ENA (1 << 14)
-# define PACKET3_DEST_BASE_2_ENA (1 << 19)
-# define PACKET3_DEST_BASE_3_ENA (1 << 21)
-# define PACKET3_TCL1_ACTION_ENA (1 << 22)
-# define PACKET3_TC_ACTION_ENA (1 << 23)
-# define PACKET3_CB_ACTION_ENA (1 << 25)
-# define PACKET3_DB_ACTION_ENA (1 << 26)
-# define PACKET3_SH_KCACHE_ACTION_ENA (1 << 27)
-# define PACKET3_SH_ICACHE_ACTION_ENA (1 << 29)
-#define PACKET3_ME_INITIALIZE 0x44
-#define PACKET3_ME_INITIALIZE_DEVICE_ID(x) ((x) << 16)
-#define PACKET3_COND_WRITE 0x45
-#define PACKET3_EVENT_WRITE 0x46
-#define PACKET3_EVENT_WRITE_EOP 0x47
-#define PACKET3_EVENT_WRITE_EOS 0x48
-#define PACKET3_PREAMBLE_CNTL 0x4A
-# define PACKET3_PREAMBLE_BEGIN_CLEAR_STATE (2 << 28)
-# define PACKET3_PREAMBLE_END_CLEAR_STATE (3 << 28)
-#define PACKET3_ONE_REG_WRITE 0x57
-#define PACKET3_LOAD_CONFIG_REG 0x5F
-#define PACKET3_LOAD_CONTEXT_REG 0x60
-#define PACKET3_LOAD_SH_REG 0x61
-#define PACKET3_SET_CONFIG_REG 0x68
-#define PACKET3_SET_CONFIG_REG_START 0x00002000
-#define PACKET3_SET_CONFIG_REG_END 0x00002c00
-#define PACKET3_SET_CONTEXT_REG 0x69
-#define PACKET3_SET_CONTEXT_REG_START 0x000a000
-#define PACKET3_SET_CONTEXT_REG_END 0x000a400
-#define PACKET3_SET_CONTEXT_REG_INDIRECT 0x73
-#define PACKET3_SET_RESOURCE_INDIRECT 0x74
-#define PACKET3_SET_SH_REG 0x76
-#define PACKET3_SET_SH_REG_START 0x00002c00
-#define PACKET3_SET_SH_REG_END 0x00003000
-#define PACKET3_SET_SH_REG_OFFSET 0x77
-#define PACKET3_ME_WRITE 0x7A
-#define PACKET3_SCRATCH_RAM_WRITE 0x7D
-#define PACKET3_SCRATCH_RAM_READ 0x7E
-#define PACKET3_CE_WRITE 0x7F
-#define PACKET3_LOAD_CONST_RAM 0x80
-#define PACKET3_WRITE_CONST_RAM 0x81
-#define PACKET3_WRITE_CONST_RAM_OFFSET 0x82
-#define PACKET3_DUMP_CONST_RAM 0x83
-#define PACKET3_INCREMENT_CE_COUNTER 0x84
-#define PACKET3_INCREMENT_DE_COUNTER 0x85
-#define PACKET3_WAIT_ON_CE_COUNTER 0x86
-#define PACKET3_WAIT_ON_DE_COUNTER 0x87
-#define PACKET3_WAIT_ON_DE_COUNTER_DIFF 0x88
-#define PACKET3_SET_CE_DE_COUNTERS 0x89
-#define PACKET3_WAIT_ON_AVAIL_BUFFER 0x8A
-#define PACKET3_SWITCH_BUFFER 0x8B
-#define PACKET3_SEM_WAIT_ON_SIGNAL (0x1 << 12)
-#define PACKET3_SEM_SEL_SIGNAL (0x6 << 29)
-#define PACKET3_SEM_SEL_WAIT (0x7 << 29)
+#define PACKET3_NOP 0x10
+#define PACKET3_SET_BASE 0x11
+#define PACKET3_BASE_INDEX(x) ((x) << 0)
+#define PACKET3_CLEAR_STATE 0x12
+#define PACKET3_INDEX_BUFFER_SIZE 0x13
+#define PACKET3_DISPATCH_DIRECT 0x15
+#define PACKET3_DISPATCH_INDIRECT 0x16
+#define PACKET3_ALLOC_GDS 0x1B
+#define PACKET3_WRITE_GDS_RAM 0x1C
+#define PACKET3_ATOMIC_GDS 0x1D
+#define PACKET3_ATOMIC 0x1E
+#define PACKET3_OCCLUSION_QUERY 0x1F
+#define PACKET3_SET_PREDICATION 0x20
+#define PACKET3_REG_RMW 0x21
+#define PACKET3_COND_EXEC 0x22
+#define PACKET3_PRED_EXEC 0x23
+#define PACKET3_DRAW_INDIRECT 0x24
+#define PACKET3_DRAW_INDEX_INDIRECT 0x25
+#define PACKET3_INDEX_BASE 0x26
+#define PACKET3_DRAW_INDEX_2 0x27
+#define PACKET3_CONTEXT_CONTROL 0x28
+#define PACKET3_INDEX_TYPE 0x2A
+#define PACKET3_DRAW_INDIRECT_MULTI 0x2C
+#define PACKET3_DRAW_INDEX_AUTO 0x2D
+#define PACKET3_DRAW_INDEX_IMMD 0x2E
+#define PACKET3_NUM_INSTANCES 0x2F
+#define PACKET3_DRAW_INDEX_MULTI_AUTO 0x30
+#define PACKET3_INDIRECT_BUFFER_CONST 0x31
+#define PACKET3_INDIRECT_BUFFER 0x3F
+#define PACKET3_STRMOUT_BUFFER_UPDATE 0x34
+#define PACKET3_DRAW_INDEX_OFFSET_2 0x35
+#define PACKET3_DRAW_INDEX_MULTI_ELEMENT 0x36
+#define PACKET3_WRITE_DATA 0x37
+#define PACKET3_DRAW_INDEX_INDIRECT_MULTI 0x38
+#define PACKET3_MEM_SEMAPHORE 0x39
+#define PACKET3_MPEG_INDEX 0x3A
+#define PACKET3_COPY_DW 0x3B
+#define PACKET3_WAIT_REG_MEM 0x3C
+#define PACKET3_MEM_WRITE 0x3D
+#define PACKET3_COPY_DATA 0x40
+#define PACKET3_CP_DMA 0x41
+#define PACKET3_CP_DMA_DST_SEL(x) ((x) << 20)
+#define PACKET3_CP_DMA_ENGINE(x) ((x) << 27)
+#define PACKET3_CP_DMA_SRC_SEL(x) ((x) << 29)
+#define PACKET3_CP_DMA_CP_SYNC (1 << 31)
+#define PACKET3_CP_DMA_DIS_WC (1 << 21)
+#define PACKET3_CP_DMA_CMD_SRC_SWAP(x) ((x) << 22)
+#define PACKET3_CP_DMA_CMD_DST_SWAP(x) ((x) << 24)
+#define PACKET3_CP_DMA_CMD_SAS (1 << 26)
+#define PACKET3_CP_DMA_CMD_DAS (1 << 27)
+#define PACKET3_CP_DMA_CMD_SAIC (1 << 28)
+#define PACKET3_CP_DMA_CMD_DAIC (1 << 29)
+#define PACKET3_CP_DMA_CMD_RAW_WAIT (1 << 30)
+#define PACKET3_PFP_SYNC_ME 0x42
+#define PACKET3_SURFACE_SYNC 0x43
+#define PACKET3_DEST_BASE_0_ENA (1 << 0)
+#define PACKET3_DEST_BASE_1_ENA (1 << 1)
+#define PACKET3_CB0_DEST_BASE_ENA (1 << 6)
+#define PACKET3_CB1_DEST_BASE_ENA (1 << 7)
+#define PACKET3_CB2_DEST_BASE_ENA (1 << 8)
+#define PACKET3_CB3_DEST_BASE_ENA (1 << 9)
+#define PACKET3_CB4_DEST_BASE_ENA (1 << 10)
+#define PACKET3_CB5_DEST_BASE_ENA (1 << 11)
+#define PACKET3_CB6_DEST_BASE_ENA (1 << 12)
+#define PACKET3_CB7_DEST_BASE_ENA (1 << 13)
+#define PACKET3_DB_DEST_BASE_ENA (1 << 14)
+#define PACKET3_DEST_BASE_2_ENA (1 << 19)
+#define PACKET3_DEST_BASE_3_ENA (1 << 21)
+#define PACKET3_TCL1_ACTION_ENA (1 << 22)
+#define PACKET3_TC_ACTION_ENA (1 << 23)
+#define PACKET3_CB_ACTION_ENA (1 << 25)
+#define PACKET3_DB_ACTION_ENA (1 << 26)
+#define PACKET3_SH_KCACHE_ACTION_ENA (1 << 27)
+#define PACKET3_SH_ICACHE_ACTION_ENA (1 << 29)
+#define PACKET3_ME_INITIALIZE 0x44
+#define PACKET3_ME_INITIALIZE_DEVICE_ID(x) ((x) << 16)
+#define PACKET3_COND_WRITE 0x45
+#define PACKET3_EVENT_WRITE 0x46
+#define PACKET3_EVENT_WRITE_EOP 0x47
+#define PACKET3_EVENT_WRITE_EOS 0x48
+#define PACKET3_PREAMBLE_CNTL 0x4A
+#define PACKET3_PREAMBLE_BEGIN_CLEAR_STATE (2 << 28)
+#define PACKET3_PREAMBLE_END_CLEAR_STATE (3 << 28)
+#define PACKET3_ONE_REG_WRITE 0x57
+#define PACKET3_LOAD_CONFIG_REG 0x5F
+#define PACKET3_LOAD_CONTEXT_REG 0x60
+#define PACKET3_LOAD_SH_REG 0x61
+#define PACKET3_SET_CONFIG_REG 0x68
+#define PACKET3_SET_CONFIG_REG_START 0x00002000
+#define PACKET3_SET_CONFIG_REG_END 0x00002c00
+#define PACKET3_SET_CONTEXT_REG 0x69
+#define PACKET3_SET_CONTEXT_REG_START 0x000a000
+#define PACKET3_SET_CONTEXT_REG_END 0x000a400
+#define PACKET3_SET_CONTEXT_REG_INDIRECT 0x73
+#define PACKET3_SET_RESOURCE_INDIRECT 0x74
+#define PACKET3_SET_SH_REG 0x76
+#define PACKET3_SET_SH_REG_START 0x00002c00
+#define PACKET3_SET_SH_REG_END 0x00003000
+#define PACKET3_SET_SH_REG_OFFSET 0x77
+#define PACKET3_ME_WRITE 0x7A
+#define PACKET3_SCRATCH_RAM_WRITE 0x7D
+#define PACKET3_SCRATCH_RAM_READ 0x7E
+#define PACKET3_CE_WRITE 0x7F
+#define PACKET3_LOAD_CONST_RAM 0x80
+#define PACKET3_WRITE_CONST_RAM 0x81
+#define PACKET3_WRITE_CONST_RAM_OFFSET 0x82
+#define PACKET3_DUMP_CONST_RAM 0x83
+#define PACKET3_INCREMENT_CE_COUNTER 0x84
+#define PACKET3_INCREMENT_DE_COUNTER 0x85
+#define PACKET3_WAIT_ON_CE_COUNTER 0x86
+#define PACKET3_WAIT_ON_DE_COUNTER 0x87
+#define PACKET3_WAIT_ON_DE_COUNTER_DIFF 0x88
+#define PACKET3_SET_CE_DE_COUNTERS 0x89
+#define PACKET3_WAIT_ON_AVAIL_BUFFER 0x8A
+#define PACKET3_SWITCH_BUFFER 0x8B
+#define PACKET3_SEM_WAIT_ON_SIGNAL (0x1 << 12)
+#define PACKET3_SEM_SEL_SIGNAL (0x6 << 29)
+#define PACKET3_SEM_SEL_WAIT (0x7 << 29)
#endif
diff --git a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_6_0_d.h b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_6_0_d.h
index a17973bb63a6..3e8f576d2a14 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/dce/dce_6_0_d.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/dce/dce_6_0_d.h
@@ -4442,4 +4442,25 @@
#define mmXDMA_TEST_DEBUG_DATA 0x041D
#define mmXDMA_TEST_DEBUG_INDEX 0x041C
+/* Registers that spilled out of sid.h */
+#define mmAVIVO_D1VGA_CONTROL 0xcc
+#define mmAVIVO_D2VGA_CONTROL 0xce
+#define mmEVERGREEN_VGA_MEMORY_BASE_ADDRESS_HIGH 0xc9
+#define mmEVERGREEN_VGA_MEMORY_BASE_ADDRESS 0xc4
+#define mmR_000300_VGA_RENDER_CONTROL 0xc0
+#define mmEVERGREEN_D3VGA_CONTROL 0xf8
+#define mmEVERGREEN_D4VGA_CONTROL 0xf9
+#define mmEVERGREEN_D5VGA_CONTROL 0xfa
+#define mmEVERGREEN_D6VGA_CONTROL 0xfb
+#define mmEVERGREEN_DATA_FORMAT 0x1AC0
+#define mmEVERGREEN_DESKTOP_HEIGHT 0x1AC1
+#define mmDC_LB_MEMORY_SPLIT 0x1AC3
+#define mmPRIORITY_A_CNT 0x1AC6
+#define mmPRIORITY_B_CNT 0x1AC7
+#define mmDPG_PIPE_ARBITRATION_CONTROL3 0x1B32
+#define mmINT_MASK 0x1AD0
+#define mmVLINE_STATUS 0x1AEE
+#define mmVBLANK_STATUS 0x1AEF
+
+
#endif
--
2.10.0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support
From: Luis R. Rodriguez @ 2016-11-14 14:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Laurent Pinchart, Luis R. Rodriguez, Rafael J. Wysocki,
Lukas Wunner, Rafael J. Wysocki, Linux PM list, Alan Stern,
Linux Kernel Mailing List, Tomeu Vizoso, Mark Brown,
Marek Szyprowski, Kevin Hilman, Ulf Hansson, Geert Uytterhoeven,
Lars-Peter Clausen, Grant Likely, Mauro Carvalho Chehab,
Dmitry Torokhov, Andrzej Hajda, Christoph Hellwig, Arnd Bergmann,
Jiri Kosina, Joerg Roedel, Olof Johansson, Jan Kara, Takashi Iwai
In-Reply-To: <20161113105942.GE8388@kroah.com>
On Sun, Nov 13, 2016 at 11:59:42AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 11, 2016 at 02:08:35AM +0200, Laurent Pinchart wrote:
> > Hi Greg,
> >
> > On Thursday 10 Nov 2016 23:40:54 Greg Kroah-Hartman wrote:
> > > On Thu, Nov 10, 2016 at 11:04:07PM +0100, Luis R. Rodriguez wrote:
> > > > This is more forward looking, but -- if we had an annotation in
> > > > Kconfig/turned to a mod info section, or to start off with just a driver
> > > > MODULE_SUGGESTS() macro to start off with it might suffice for the driver
> > > > core to request_module() annotated dependencies, such requests could be
> > > > explicitly suggested as synchronous so init + probe do run together
> > > > (as-is today), after which it could know that all possible drivers that
> > > > needed to be loaded should now be loaded. If this sounds plausible to
> > > > help, do we have drivers where we can test this on? For instance, since
> > > > the functional dependency framework annotates functional dependencies for
> > > > consumers/providers for suspend/resume and un time PM could such
> > > > MODULE_SUGGESTS() annotations be considered on the consumers to suggest
> > > > the provider drivers so their own probe yields to their providers to try
> > > > first ?
> > >
> > > No.
> > >
> > > Stop.
> > >
> > > First off, the "driver core" NEVER can "know" if "all possible drivers
> > > that should be loaded, are loaded. That way lies madness and
> > > impossibility.
At first I had discarded the generic driver problem as a slightly unrelated
topic however its clear now its not. In terms of functional dependencies I
agree that not providing strict order is *sometimes* desirable to help with
simplicity. The generic driver problem can be described graph-wise: on a DAG,
we're considering a topology with where nodes have optional superior
alternatives, and what you seem to be advocating is a transition to an
alternative is better and much simpler than forcing order from the start. That
can only work so long as some intermediary dependencies are (for lack of a
better term) soft-nodes -- where transitions to better alternatives are
possible and can such transitions can be handled in software. You may have
(again for lack of a better term) hard-nodes though where an entry in the DAG
is required as a hard requirement immediately prior to letting another entry
proceed. An example here is the x86 IOMMU drivers and dependent GPU DRM
drivers, currently only link order asserts proper order given we have run out
of semantics in between to ensure proper order is correct.
> > > Secondly, yet-another-section isn't going to help anything here, we
> > > alredy "suggest" to userspace a bunch of stuff, so we get the needed
> > > modules loaded, at sometime in the future, if they are around, and
> > > userspace feels like it. That's the best we can ever do.
For some cases this is sufficient, for hard-nodes (term used above) though
if you get the incorrect order you may in the worst case oops.
> > > Don't try to make this more difficult than it is please. DEFER works
> > > today really really well, and it's really really simple.
It seems many disagree. What is clear is its simplicity outweighs the
complexity by alternatives which have been historically considered. This is
reasonable. Part of the reason probe ordering, as an optimization
consideration, came up while function dependencies for runtime PM and suspend
are being discussed is as we've determined this is a related problem and
at least for hard-nodes this is critical to resolve. For now we have enough
tools to work around problems for hard-nodes, but it would be silly for us
not to start thinking about ways to improve upon this for the future.
> > > Inter-dependancy of modules and devices connected to each other are two
> > > different things, be careful about this.
This is a *very* fair warning :)
> > One issue we don't address today is handling of optional dependencies. A
> > simple example is an SPI controller that can use a DMA engine or work in PIO
> > mode. At probe time the driver will request a DMA channel if the platform
> > (ACPI, DT, platform data) specifies that DMA is available. This can fail for
> > various reasons, one of them being that the DMA engine driver hasn't probed
> > the DMA device yet. In that case the SPI controller driver will continue in
> > PIO mode, ignoring the DMA engine that will later be probed. We can't defer
> > probing of the SPI controller as the DMA engine driver might never get loaded,
> > which would result in the SPI controller probe being deferred forever.
> >
> > One solution for this type of dependency issue would be to notify the SPI
> > controller driver after probe that the DMA channel is now available. I'd like
> > to avoid that though, as it would drastically increase the complexity of lots
> > of drivers and create lots of race conditions.
> >
> > There are certain configurations that we could possibly consider as invalid.
> > For instance if the SPI controller driver is built-in and the DMA engine
> > driver built as a module, the user clearly shot themselves in the foot and the
> > kernel can't be blamed.
> >
> > For resources that can't be built as a module (IOMMUs for instance) we thus
> > only have to consider the case where both drivers are built-in, as the
> > resource built-in and consumer as a module should work properly from an
> > ordering point of view (at least as long as we don't allow asynchronous
> > probing of built-in drivers to be delayed enough for modules to be loaded...).
> > In this case, if the resource driver isn't available when the consumer is
> > probed, if will never be available at the consumer can safely proceed in a
> > degraded mode. We would thus only need to solve the probe ordering issue.
> >
> > I'm not sure how far these simple(r) solutions that consider certain cases as
> > invalid would scale though, and whether we won't need a more generic solution
> > at some point anyway.
>
> I would love to see a generic solution that works for all of these
> complex cases, as I agree with you, it's complex :)
>
> But I have yet to see any such patches that implement this.
The generic driver topic is related but it certainly only part of the
picture. It seems there were enough folks interested in that topic though
so perhaps patches will be eventually produced for it.
> As always,
> I am very glad to review anything that people create, but I don't have
> the time to work on such a solution myself at the moment.
Part of what we tried to discuss during the complex dependencies topics at
Plumbers was evaluating if some of the existing solutions for run time PM and
suspend could help with probe ordering, it seems we had agreement on it, what
we found though was that for many cases the use of struct device for link
association is too late. Alternatives mechanisms will be considered in the
future, and it seems that one path forward will be to consider expanding upon
this simple functional device dependency framework.
So let's see more patches!
Luis
^ permalink raw reply
* Re: [PATCH RFC] ARM: dts: add support for Turris Omnia
From: tomas.hlavacek @ 2016-11-14 14:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: Uwe Kleine-König, Mark Rutland, Jason Cooper,
Martin Strba??ka, devicetree, Rob Herring, Gregory Clement,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161114131010.GC26710@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]
Hi Andrew!
On Mon, Nov 14, 2016 at 2:10 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Actually SFP is connected to SGMII interface of eth1, which is
>> routed through SERDES 5.
>
> You say eth1 here. Yet lower down you say got eth0 and eth1 are
> connected to the switch?
Oh sorry, this was a NIC name based on probing order derived from base
address of NIC registers:
eth1: ethernet@30000 - probes as eth0
eth2: ethernet@34000 - probes as eth1
eth0: ethernet@70000 - probes as eth2
It is a bit confusing. I meant eth2 in DTS. Sorry.
>
>
>> We have our proprietary support hacked onto mvneta driver for
>> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
>> ignore SFP in this DTS altogether and let's wait till "phylink based
>> SFP module support" or something alike hits upstream, so we can base
>> the SFP support on solid code;
>
> It would be great if you could work on getting the phylink patches
> into mainline. It is something i have wanted to do for a long time,
> but it is too low down on my priority list to get to. The code is high
> quality, so i don't think there will be too many issues. It probably
> just needs splitting up into smaller batches, submitting, and working
> on any comments.
That is exactly what I thought when I saw the patches for the first
time. I will try to merge the patches to the current kernel and see
what happens. I still need to learn a lot about PHY subsystem.
>
>
>> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
>> switch. The problem is that from what I have read so far the switch
>> can not operate in DSA mode with two CPU ports.
>
> Again, this is something i wanted to do, and i did have a prototype at
> one point. But again, not enough time. If you have resources to work
> on this, i can find my code, explain my ideas, and let you complete
> it.
I am definitely interested, though I didn't have time to read and
absorb DSA yet, but I definitely want to try to hack 88E6176 support. I
would be really grateful if you can provide some pointers and/or code
to start from.
Thanks,
Tomas
[-- Attachment #2: Type: text/html, Size: 2787 bytes --]
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 14:50 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <62d634ab-70ad-4be7-1622-f2e3a9d865fe@redhat.com>
On Mon, Nov 14, 2016 at 03:22:02PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 15:00, Marcelo Tosatti wrote:
> > On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/11/2016 13:36, Marcelo Tosatti wrote:
> >>> + /* local (running VM) restore */
> >>> + if (s->clock_valid) {
> >>> + /*
> >>> + * if host does not support reliable KVM_GET_CLOCK,
> >>> + * read kvmclock value from memory
> >>> + */
> >>> + if (!kvm_has_adjust_clock_stable()) {
> >>> + time_at_migration = kvmclock_current_nsec(s);
> >>
> >> Just assign to s->clock here...
> >
> > If kvmclock is not enabled, you want to use s->clock,
> > rather than 0.
> >
> >>> + }
> >>> + /* migration/savevm/init restore */
> >>> + } else {
> >>> + /*
> >>> + * use s->clock in case machine uses reliable
> >>> + * get clock and host where vm was executing
> >>> + * supported reliable get clock
> >>> + */
> >>> + if (!s->mach_use_reliable_get_clock ||
> >>> + !s->src_use_reliable_get_clock) {
> >>> + time_at_migration = kvmclock_current_nsec(s);
> >>
> >> ... and here, so that time_at_migration is not needed anymore.
> >
> > Same as above.
>
> You're right.
>
> >> Also here it's enough to look at s->src_user_reliable_get_clock, because
> >> if s->mach_use_reliable_get_clock is false,
> >> s->src_use_reliable_get_clock will be false as well.
> >
> > Yes, but i like the code annotation.
>
> Ah, I think we're looking at it differently.
Well, i didnt want to mix the meaning of the variables:
+ /* whether machine supports reliable KVM_GET_CLOCK */
+ bool mach_use_reliable_get_clock;
+
+ /* whether source host supported reliable KVM_GET_CLOCK */
+ bool src_use_reliable_get_clock;
See the comments on top (later if you look at the variable,
then have to think: well it has one name, but its disabled
by that other path as well, so its more than its
name,etc...).
> I'm thinking "mach_use_reliable_get_clock is just for migration,
Thats whether the machine supports it. New machines have it enabled,
olders don't.
> src_use_reliable_get_clock is the state".
Thats whether the migration source supported it.
> Perhaps you're thinking of
> enabling/disabling the whole new code for old machines?
source destination behaviour
supports supports on migration use s->clock,
on stop/cont as well
supports ~supports
on migration use s->clock,
on stop/cont read from guest mem
~support supports on migration read from guest,
on stop/cont use
kvm_get_clock/kvm_set_clock
~support ~support always read from guest memory
Thats what should happen (and thats what the patch should implement).
"support" means host supports your new KVM_GET_CLOCK/KVM_SET_CLOCK.
> What is the
> advantage?
Well its necessary to use the correct thing, otherwise
you see a time backwards event.
>
> >>> + }
> >>> + }
> >>>
> >>> - /* We can't rely on the migrated clock value, just discard it */
> >>> + /* We can't rely on the saved clock value, just discard it */
> >>> if (time_at_migration) {
> >>> s->clock = time_at_migration;
> >>
> >> [...]
> >>
> >>>
> >>> +static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> >>> +{
> >>> + KVMClockState *s = opaque;
> >>> +
> >>> + /*
> >>> + * On machine types that support reliable KVM_GET_CLOCK,
> >>> + * if host kernel does provide reliable KVM_GET_CLOCK,
> >>> + * set src_use_reliable_get_clock=true so that destination
> >>> + * avoids reading kvmclock from memory.
> >>> + */
> >>> + if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable()) {
> >>> + s->src_use_reliable_get_clock = true;
> >>> + }
> >>> +
> >>> + return s->src_use_reliable_get_clock;
> >>> +}
> >>
> >> Here you can just return s->mach_use_reliable_get_clock.
> >
> > mach_use_reliable_get_clock can be true but host might not support it.
>
> Yes, but the "needed" function is only required to avoid breaking
> pc-i440fx-2.7 and earlier.
"needed" is required so that the migration between:
SRC DEST BEHAVIOUR
~support supports on migration read from guest,
on stop/cont use
kvm_get_clock/kvm_set_clock
Destination does not use KVM_GET_CLOCK value (which is
broken and should not be used).
> If you return true here, you can still
> migrate a "false" value for src_use_reliable_get_clock.
But the source only uses a reliable KVM_GET_CLOCK if
both conditions are true.
And the subsection is only needed if the source
uses a reliable KVM_GET_CLOCK.
> >> To set
> >> s->src_use_reliable_get_clock, after issuing KVM_GET_CLOCK you can look
> >> at the KVM_CLOCK_TSC_STABLE bit in the kvm_clock struct's flags.
> >
> > KVM_CLOCK_TSC_STABLE bit in the kvmclock structure !=
> > KVM_GET_CLOCK returns reliable value, right?
>
> It is the same as "is using masterclock", which is actually a stricter
> condition than the KVM_CHECK_EXTENSION return value. The right check to
> use is whether masterclock is in use,
Actually its "has a reliable KVM_GET_CLOCK" (which returns
get_kernel_clock() + (rdtsc() - tsc_timestamp),
"broken KVM_GET_CLOCK" = get_kernel_clock()
> and then the idea is to treat
> clock,src_use_reliable_get_clock as one tuple that is updated atomically.
>
> Paolo
Hum, not sure i get this...
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 14:50 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <62d634ab-70ad-4be7-1622-f2e3a9d865fe@redhat.com>
On Mon, Nov 14, 2016 at 03:22:02PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 15:00, Marcelo Tosatti wrote:
> > On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/11/2016 13:36, Marcelo Tosatti wrote:
> >>> + /* local (running VM) restore */
> >>> + if (s->clock_valid) {
> >>> + /*
> >>> + * if host does not support reliable KVM_GET_CLOCK,
> >>> + * read kvmclock value from memory
> >>> + */
> >>> + if (!kvm_has_adjust_clock_stable()) {
> >>> + time_at_migration = kvmclock_current_nsec(s);
> >>
> >> Just assign to s->clock here...
> >
> > If kvmclock is not enabled, you want to use s->clock,
> > rather than 0.
> >
> >>> + }
> >>> + /* migration/savevm/init restore */
> >>> + } else {
> >>> + /*
> >>> + * use s->clock in case machine uses reliable
> >>> + * get clock and host where vm was executing
> >>> + * supported reliable get clock
> >>> + */
> >>> + if (!s->mach_use_reliable_get_clock ||
> >>> + !s->src_use_reliable_get_clock) {
> >>> + time_at_migration = kvmclock_current_nsec(s);
> >>
> >> ... and here, so that time_at_migration is not needed anymore.
> >
> > Same as above.
>
> You're right.
>
> >> Also here it's enough to look at s->src_user_reliable_get_clock, because
> >> if s->mach_use_reliable_get_clock is false,
> >> s->src_use_reliable_get_clock will be false as well.
> >
> > Yes, but i like the code annotation.
>
> Ah, I think we're looking at it differently.
Well, i didnt want to mix the meaning of the variables:
+ /* whether machine supports reliable KVM_GET_CLOCK */
+ bool mach_use_reliable_get_clock;
+
+ /* whether source host supported reliable KVM_GET_CLOCK */
+ bool src_use_reliable_get_clock;
See the comments on top (later if you look at the variable,
then have to think: well it has one name, but its disabled
by that other path as well, so its more than its
name,etc...).
> I'm thinking "mach_use_reliable_get_clock is just for migration,
Thats whether the machine supports it. New machines have it enabled,
olders don't.
> src_use_reliable_get_clock is the state".
Thats whether the migration source supported it.
> Perhaps you're thinking of
> enabling/disabling the whole new code for old machines?
source destination behaviour
supports supports on migration use s->clock,
on stop/cont as well
supports ~supports
on migration use s->clock,
on stop/cont read from guest mem
~support supports on migration read from guest,
on stop/cont use
kvm_get_clock/kvm_set_clock
~support ~support always read from guest memory
Thats what should happen (and thats what the patch should implement).
"support" means host supports your new KVM_GET_CLOCK/KVM_SET_CLOCK.
> What is the
> advantage?
Well its necessary to use the correct thing, otherwise
you see a time backwards event.
>
> >>> + }
> >>> + }
> >>>
> >>> - /* We can't rely on the migrated clock value, just discard it */
> >>> + /* We can't rely on the saved clock value, just discard it */
> >>> if (time_at_migration) {
> >>> s->clock = time_at_migration;
> >>
> >> [...]
> >>
> >>>
> >>> +static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> >>> +{
> >>> + KVMClockState *s = opaque;
> >>> +
> >>> + /*
> >>> + * On machine types that support reliable KVM_GET_CLOCK,
> >>> + * if host kernel does provide reliable KVM_GET_CLOCK,
> >>> + * set src_use_reliable_get_clock=true so that destination
> >>> + * avoids reading kvmclock from memory.
> >>> + */
> >>> + if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable()) {
> >>> + s->src_use_reliable_get_clock = true;
> >>> + }
> >>> +
> >>> + return s->src_use_reliable_get_clock;
> >>> +}
> >>
> >> Here you can just return s->mach_use_reliable_get_clock.
> >
> > mach_use_reliable_get_clock can be true but host might not support it.
>
> Yes, but the "needed" function is only required to avoid breaking
> pc-i440fx-2.7 and earlier.
"needed" is required so that the migration between:
SRC DEST BEHAVIOUR
~support supports on migration read from guest,
on stop/cont use
kvm_get_clock/kvm_set_clock
Destination does not use KVM_GET_CLOCK value (which is
broken and should not be used).
> If you return true here, you can still
> migrate a "false" value for src_use_reliable_get_clock.
But the source only uses a reliable KVM_GET_CLOCK if
both conditions are true.
And the subsection is only needed if the source
uses a reliable KVM_GET_CLOCK.
> >> To set
> >> s->src_use_reliable_get_clock, after issuing KVM_GET_CLOCK you can look
> >> at the KVM_CLOCK_TSC_STABLE bit in the kvm_clock struct's flags.
> >
> > KVM_CLOCK_TSC_STABLE bit in the kvmclock structure !=
> > KVM_GET_CLOCK returns reliable value, right?
>
> It is the same as "is using masterclock", which is actually a stricter
> condition than the KVM_CHECK_EXTENSION return value. The right check to
> use is whether masterclock is in use,
Actually its "has a reliable KVM_GET_CLOCK" (which returns
get_kernel_clock() + (rdtsc() - tsc_timestamp),
"broken KVM_GET_CLOCK" = get_kernel_clock()
> and then the idea is to treat
> clock,src_use_reliable_get_clock as one tuple that is updated atomically.
>
> Paolo
Hum, not sure i get this...
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Christian Borntraeger @ 2016-11-14 14:51 UTC (permalink / raw)
To: Stefan Hajnoczi, qemu-devel; +Cc: Paolo Bonzini, Fam Zheng, Karl Rister
In-Reply-To: <1478711602-12620-1-git-send-email-stefanha@redhat.com>
On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> Recent performance investigation work done by Karl Rister shows that the
> guest->host notification takes around 20 us. This is more than the "overhead"
> of QEMU itself (e.g. block layer).
>
> One way to avoid the costly exit is to use polling instead of notification.
> The main drawback of polling is that it consumes CPU resources. In order to
> benefit performance the host must have extra CPU cycles available on physical
> CPUs that aren't used by the guest.
>
> This is an experimental AioContext polling implementation. It adds a polling
> callback into the event loop. Polling functions are implemented for virtio-blk
> virtqueue guest->host kick and Linux AIO completion.
>
> The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds to
> poll before entering the usual blocking poll(2) syscall. Try setting this
> variable to the time from old request completion to new virtqueue kick.
>
> By default no polling is done. The QEMU_AIO_POLL_MAX_NS must be set to get any
> polling!
>
> Karl: I hope you can try this patch series with several QEMU_AIO_POLL_MAX_NS
> values. If you don't find a good value we should double-check the tracing data
> to see if this experimental code can be improved.
>
> Stefan Hajnoczi (3):
> aio-posix: add aio_set_poll_handler()
> virtio: poll virtqueues for new buffers
> linux-aio: poll ring for completions
>
> aio-posix.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> block/linux-aio.c | 17 +++++++
> hw/virtio/virtio.c | 19 ++++++++
> include/block/aio.h | 16 +++++++
> 4 files changed, 185 insertions(+)
Hmm, I see all affected threads using more CPU power, but the performance numbers are
somewhat inconclusive on s390. I have no proper test setup (only a shared LPAR), but
all numbers are in the same ballpark of 3-5Gbyte/sec for 5 disks for 4k random reads
with iodepth=8.
What I find interesting is that the guest still does a huge amount of exits for the
guest->host notifications. I think if we could combine this with some notification
suppression, then things could be even more interesting.
Christian
^ permalink raw reply
* Catching invoking a new process by the audit subsyetm
From: Kevin Wilson @ 2016-11-14 14:51 UTC (permalink / raw)
To: kernelnewbies
Hi,
Is it possible to catch invoking a new process by the audit subsyetm?
Regards,
Kevin
^ permalink raw reply
* Possible to prevent dom0 accessing guest memory?
From: Andy Smith @ 2016-11-14 14:51 UTC (permalink / raw)
To: xen-devel
Hello,
Please forgive me if this is a naive question but I do not know this
low-level stuff very well.
If the ability of the toolstack to dump a guest's memory (e.g. xl
dump-core) were disabled on the hypervisor side, would there be any
other way to do so from dom0 without rebooting the machine into a
hypervisor that had the capability re-enabled?
I understand dom0 has privileges to map devices to guests; does that
give it a way to read arbitrary memory without need of toolstack
support?
The purpose of my question is in seeing if disk encryption in VMs
can be made slightly more useful. If there were no way for root in
dom0 to read guest memory without rebooting into a different
hypervisor then I think that would be a useful step.
Cheers,
Andy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Russell King - ARM Linux @ 2016-11-14 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6787744.7DRFf7p3US@wuerfel>
On Mon, Nov 14, 2016 at 03:37:44PM +0100, Arnd Bergmann wrote:
> On Monday, November 14, 2016 1:50:18 PM CET Russell King - ARM Linux wrote:
> > On Mon, Nov 14, 2016 at 01:03:09PM +0100, Arnd Bergmann wrote:
> > > On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> > > > >> + scu_base = of_iomap(np, 0);
> > > > >> + of_node_put(np);
> > > > >> + if (!scu_base) {
> > > > >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> > > > >
> > > > > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > > > > what does it mean, but it may confuse normal users. In current version,
> > > > > berlin doesn't complain like this for non-ca9 SoCs
> > > > >
> > > >
> > > > OK, let me see other reviewer's comment on this. Then we will decide if
> > > > this error message is required or can be omitted.
> > >
> > > We need to look at all callers here, to see if the function ever gets
> > > called for a CPU that doesn't have an SCU. I'd say we should warn if
> > > we know there is an SCU but we cannot map it, but never warn on
> > > any of the CPU cores that don't support an SCU.
> >
> > Maybe there should be two helpers:
> >
> > of_scu_enable() which _only_ looks up the SCU address in DT and enables
> > it if it finds it, otherwise returning failure.
> >
> > a9_scu_enable() which tries to use the A9 provided SCU address and
> > enables it if it finds it, otherwise returning failure.
> >
> > Then callers can decide which of these to call, and what error messages
> > to print on their failures.
>
> Splitting the function in two is probably simpler overall, but
> we may still have to look at all the callers: Any platform that
> currently tries to map it on any CPU and doesn't warn about the
> absence of the device node (or about scu_a9_has_base() == false)
> should really continue not to warn about that.
Did you miss the bit where none of of_scu_enable() or a9_scu_enable()
should produce any warnings or errors to be printed. It's up to the
caller to report the failure, otherwise doing this doesn't make sense:
if (of_scu_enable() < 0 && a9_scu_enable() < 0)
pr_err("Failed to map and enable the SCU\n");
because if of_scu_enable() prints a warning/error, then it's patently
misleading.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] staging: wlang-ng: Fix block comments style warnings in prism2sta.h
From: Greg KH @ 2016-11-14 14:52 UTC (permalink / raw)
To: Timo Schmid; +Cc: devel, linux-kernel
In-Reply-To: <1478869986-3822-1-git-send-email-timo.schmid@gmail.com>
On Fri, Nov 11, 2016 at 02:13:06PM +0100, Timo Schmid wrote:
> This patch fixes the following checkpatch.pl warning in prism2sta.h:
> WARNING: Block comments should align the * on each line
>
> No more warnings block comments warnings for this file.
>
> Signed-off-by: Timo Schmid <timo.schmid@gmail.com>
> ---
> drivers/staging/wlan-ng/prism2sta.c | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
This patch doesn't apply at all to my tree, are you sure you made it
against linux-next?
thanks,
greg k-h
^ permalink raw reply
* Re: [RFT][PATCH] systemd: Upgrade to 232
From: Dmitry Rozhkov @ 2016-11-14 14:52 UTC (permalink / raw)
To: Khem Raj, openembedded-core
In-Reply-To: <20161110061149.20570-1-raj.khem@gmail.com>
On Wed, 2016-11-09 at 22:11 -0800, Khem Raj wrote:
> * Drop support for rcS.d SysV init scripts.
> These are prone to cause dependency loops, and almost all packages
> with
> rcS scripts now ship a native systemd service.
>
> * Drop mount propagation patch, it only happens with libseccomp, OE
> doesnt
> enable it
>
> * kdbus option has disappeared from configure
>
> * Ignore dev-so for PN now since systemd introduced private .so see
> https://github.com/systemd/systemd/issues/3810
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
I've "smoke"-tested systemd-resolved's new functionality: seems to work
as expected and I haven't noticed regressions so far in the rest of
SystemD.
BR,
Dmitry
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Karl Rister @ 2016-11-14 14:52 UTC (permalink / raw)
To: Fam Zheng; +Cc: Stefan Hajnoczi, qemu-devel, Paolo Bonzini, Andrew Theurer
In-Reply-To: <20161114135317.GB2373@lemon>
On 11/14/2016 07:53 AM, Fam Zheng wrote:
> On Fri, 11/11 13:59, Karl Rister wrote:
>>
>> Stefan
>>
>> I ran some quick tests with your patches and got some pretty good gains,
>> but also some seemingly odd behavior.
>>
>> These results are for a 5 minute test doing sequential 4KB requests from
>> fio using O_DIRECT, libaio, and IO depth of 1. The requests are
>> performed directly against the virtio-blk device (no filesystem) which
>> is backed by a 400GB NVme card.
>>
>> QEMU_AIO_POLL_MAX_NS IOPs
>> unset 31,383
>> 1 46,860
>> 2 46,440
>> 4 35,246
>> 8 34,973
>> 16 46,794
>> 32 46,729
>> 64 35,520
>> 128 45,902
>
> For sequential read with ioq=1, each request takes >20000ns under 45,000 IOPs.
> Isn't a poll time of 128ns a mismatching order of magnitude? Have you tried
> larger values? Not criticizing, just trying to understand how it workd.
Not yet, I was just trying to get something out as quick as I could
(while juggling this with some other stuff...). Frankly I was a bit
surprised that the low values made such an impact and then got
distracted by the behaviors of 4, 8, and 64.
>
> Also, do you happen to have numbers for unpatched QEMU (just to confirm that
> "unset" case doesn't cause regression) and baremetal for comparison?
I didn't run this exact test on the same qemu.git master changeset
unpatched. I did however previously try it against the v2.7.0 tag and
got somewhere around 27.5K IOPs. My original intention was to apply the
patches to v2.7.0 but it wouldn't build.
We have done a lot of testing and tracing on the qemu-rhev package and
27K IOPs is about what we see there (with tracing disabled).
Given the patch discussions I saw I was mainly trying to get a sniff
test out and then do a more complete workup with whatever updates are made.
I should probably note that there are a lot of pinning optimizations
made here to assist in our tracing efforts which also result in improved
performance. Ultimately, in a proper evaluation of these patches most
of that will be removed so the behavior may change somewhat.
>
> Fam
>
--
Karl Rister <krister@redhat.com>
^ permalink raw reply
* Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Russell King - ARM Linux @ 2016-11-14 14:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Andrew Lunn, Heiko Stuebner, geert+renesas,
Linus Walleij, Liviu Dudau, Patrice Chotard, Wei Xu,
Jisheng Zhang, pankaj.dubey, magnus.damm, Michal Simek, krzk,
thomas.ab, cpgs ., Stephen Warren, Ray Jui, horms, Jun Nie,
shiraz.linux.kernel, linux-kernel, vireshk, Dinh Nguyen,
Shawn Guo
In-Reply-To: <6787744.7DRFf7p3US@wuerfel>
On Mon, Nov 14, 2016 at 03:37:44PM +0100, Arnd Bergmann wrote:
> On Monday, November 14, 2016 1:50:18 PM CET Russell King - ARM Linux wrote:
> > On Mon, Nov 14, 2016 at 01:03:09PM +0100, Arnd Bergmann wrote:
> > > On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> > > > >> + scu_base = of_iomap(np, 0);
> > > > >> + of_node_put(np);
> > > > >> + if (!scu_base) {
> > > > >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> > > > >
> > > > > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > > > > what does it mean, but it may confuse normal users. In current version,
> > > > > berlin doesn't complain like this for non-ca9 SoCs
> > > > >
> > > >
> > > > OK, let me see other reviewer's comment on this. Then we will decide if
> > > > this error message is required or can be omitted.
> > >
> > > We need to look at all callers here, to see if the function ever gets
> > > called for a CPU that doesn't have an SCU. I'd say we should warn if
> > > we know there is an SCU but we cannot map it, but never warn on
> > > any of the CPU cores that don't support an SCU.
> >
> > Maybe there should be two helpers:
> >
> > of_scu_enable() which _only_ looks up the SCU address in DT and enables
> > it if it finds it, otherwise returning failure.
> >
> > a9_scu_enable() which tries to use the A9 provided SCU address and
> > enables it if it finds it, otherwise returning failure.
> >
> > Then callers can decide which of these to call, and what error messages
> > to print on their failures.
>
> Splitting the function in two is probably simpler overall, but
> we may still have to look at all the callers: Any platform that
> currently tries to map it on any CPU and doesn't warn about the
> absence of the device node (or about scu_a9_has_base() == false)
> should really continue not to warn about that.
Did you miss the bit where none of of_scu_enable() or a9_scu_enable()
should produce any warnings or errors to be printed. It's up to the
caller to report the failure, otherwise doing this doesn't make sense:
if (of_scu_enable() < 0 && a9_scu_enable() < 0)
pr_err("Failed to map and enable the SCU\n");
because if of_scu_enable() prints a warning/error, then it's patently
misleading.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC updates for 4.10
From: Neil Armstrong @ 2016-11-14 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b12c093-4be4-8f1c-2b46-ffaa54c5520b@baylibre.com>
On 11/08/2016 12:21 PM, Neil Armstrong wrote:
> On 11/07/2016 10:26 PM, Olof Johansson wrote:
>> On Mon, Oct 31, 2016 at 10:52:53AM +0100, Neil Armstrong wrote:
[...]
>> Hi Neil,
> Hi Olof,
>
>>
>> Sorry for being picky here, please be patient with us. :-)
> Seems legit !
>
>>
>> Overall comments on this patch set:
>>
>> 1) Copyrights seem to be a bit varied. All 3 new source files have
>> different copyright holders. Only one has yours, one is from 2003, one
>> is also from 2013. Is this expected? Seems like it's worth mentioning
>> in commit messages at least.
>
> Yes, the files comes from various places :
> - hotplug.c was taken from versatile by Ma Haijun and left verbatim, so I left the original header
> - headsmp.S was taken from the versatile code and adapted by Ma Haijun
> - platsmp.c is a mix from versatile code, Ma Haijun code and my code for DT
>
> The two first file were only modified in order to build and pass checkpatch actually.
>
> I tried to find the *real* copyright holders, but it was not easy...
>
>>
>> 2) Please remove the linux/arch/... lines from the top of the files. It's
>> something we've been trying to remove for a while and don't want to
>> introduce more occurrances of.
>>
>> I'd say (2) is fine to do incremental, but please provide clarification on (1).
>> I could just add that to the merge commit message so don't respin the branch
>> yet, depending on what we hear back!
>>
>
> Ok, please tell me if/when I need to send a new pull for the (2) fix.
>
>>> arch/arm/Makefile | 1 +
>>> arch/arm/mach-oxnas/Kconfig | 30 +++++++++++++++++++---------
>>> arch/arm/mach-oxnas/Makefile | 2 ++
>>> arch/arm/mach-oxnas/headsmp.S | 28 ++++++++++++++++++++++++++
>>> arch/arm/mach-oxnas/hotplug.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> arch/arm/mach-oxnas/platsmp.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Git tip: If you redirect the output to a file (or pipe through cat), the
>> diffstat will be limited to 80 characters and look better in email.
>>
>>
>> Thanks,
>>
>> -Olof
>>
>
> Thanks,
> Neil
>
Hi Olof,
Is a new pull request needed finally ?
Best regards,
Neil
^ permalink raw reply
* Re: [PATCH] KVM: x86: do not go through vcpu in __get_kvmclock_ns
From: Radim Krčmář @ 2016-11-14 14:52 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: linux-kernel, kvm, mtosatti
In-Reply-To: <1478859141-25146-1-git-send-email-pbonzini@redhat.com>
2016-11-11 11:12+0100, Paolo Bonzini:
> Going through the first VCPU is wrong if you follow a KVM_SET_CLOCK with
> a KVM_GET_CLOCK immediately after, without letting the VCPU run and
> call kvm_guest_time_update.
>
> This is easily fixed however, because kvm_get_time_and_clockread provides
> the information we want.
>
> Reported-by: Marcelo Tosatti <mtosatti@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/kvm/x86.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 1ba08278a9a9..1c16c6d7df7a 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1620,6 +1620,11 @@ static bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now)
>
> return do_monotonic_boot(kernel_ns, cycle_now) == VCLOCK_TSC;
> }
> +#else
> +static inline bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now)
> +{
> + return false;
> +}
> #endif
>
> /*
> @@ -1724,18 +1729,15 @@ static void kvm_gen_update_masterclock(struct kvm *kvm)
>
> static u64 __get_kvmclock_ns(struct kvm *kvm)
> {
> - struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, 0);
> struct kvm_arch *ka = &kvm->arch;
> + cycle_t cycle_now;
> s64 ns;
>
> - if (vcpu->arch.hv_clock.flags & PVCLOCK_TSC_STABLE_BIT) {
> - u64 tsc = kvm_read_l1_tsc(vcpu, rdtsc());
> - ns = __pvclock_read_cycles(&vcpu->arch.hv_clock, tsc);
This patch regresses the behavior as well, because the assumption that
kvm_get_time_and_clockread() and __pvclock_read_cycles() count the same
time doesn't hold. See the end of the message for a quick test.
kvm_get_time_and_clockread() is actually the same as ktime_get_boot_ns()
(if it works), so we'd be just obfucating the code. :)
I think that making kvmclock count as ktime_get_boot_ns() would be the
best solution, but not possible this late in 4.9 ...
As a quick hack, I think it would be better to duplicate the update that
would happen when running the VCPU before calling
__pvclock_read_cycles(), i.e. paste something like this:
if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, vcpu))
kvm_guest_time_update(vcpu);
> - } else {
> - ns = ktime_get_boot_ns() + ka->kvmclock_offset;
> - }
> + if (!ka->use_master_clock ||
> + !kvm_get_time_and_clockread(&ns, &cycle_now))
> + ns = ktime_get_boot_ns();
>
> - return ns;
> + return ns + ka->kvmclock_offset;
> }
The hunk below should return the same value in pvclock_ns and kernel_ns
if they can be used interchangeably. boot_ns is expected to be a bit
delayed, because it is read late. boot_ns shows a bounded offset from
kernel_ns, unlike the drifting pvclock_ns.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 83990ad3710e..30d4d3d02ac7 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6653,6 +6653,17 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
goto cancel_injection;
}
+ if (vcpu->kvm->arch.use_master_clock) {
+ s64 kernel_ns;
+ cycle_t tsc_now, pvclock_ns, boot_ns;
+
+ kvm_get_time_and_clockread(&kernel_ns, &tsc_now);
+ pvclock_ns = __pvclock_read_cycles(&vcpu->arch.hv_clock, kvm_read_l1_tsc(vcpu, tsc_now)) - vcpu->kvm->arch.kvmclock_offset;
+ boot_ns = ktime_get_boot_ns();
+
+ printk("ns diff: %lld %lld\n", pvclock_ns - kernel_ns, boot_ns - kernel_ns);
+ }
+
preempt_disable();
kvm_x86_ops->prepare_guest_switch(vcpu);
and a sample output:
[ 2386.172552] ns diff: -1 270
[ 2386.175695] ns diff: 14 246
[ 2386.178831] ns diff: 28 157
[ 2386.181962] ns diff: 43 176
[ 2386.185089] ns diff: 57 146
[ 2386.188228] ns diff: 71 170
[ 2386.191364] ns diff: 85 142
[ 2386.194494] ns diff: 100 138
[ 2386.197717] ns diff: 115 129
[ 2386.200935] ns diff: 128 190
[ 2386.204156] ns diff: 144 125
[ 2386.207797] ns diff: 161 145
[ 2386.211018] ns diff: 175 120
[ 2386.214239] ns diff: 189 176
[ 2386.217460] ns diff: 203 149
[ 2386.220677] ns diff: 219 110
[ 2386.223900] ns diff: 234 124
[ 2386.227125] ns diff: 248 303
[ 2386.230345] ns diff: 262 111
[ 2386.233565] ns diff: 278 107
[ 2386.236783] ns diff: 292 107
[ 2386.240001] ns diff: 306 170
[ 2386.243228] ns diff: 321 140
[ 2386.246447] ns diff: 336 101
[ 2386.249667] ns diff: 351 96
[ 2386.252787] ns diff: 365 145
[ 2386.256008] ns diff: 379 107
[ 2386.259225] ns diff: 394 99
[ 2386.262346] ns diff: 409 95
[ 2386.265467] ns diff: 423 95
[ 2386.268588] ns diff: 437 97
[ 2386.271708] ns diff: 451 165
[ 2386.274925] ns diff: 467 97
[ 2386.278047] ns diff: 480 95
[ 2386.281176] ns diff: 494 120
[ 2386.284398] ns diff: 509 408
[ 2386.287616] ns diff: 524 88
[ 2386.290736] ns diff: 538 87
[ 2386.293858] ns diff: 552 89
[...]
[ 2403.966262] ns diff: 81022 68
[ 2403.969567] ns diff: 81037 68
[ 2403.972878] ns diff: 81052 68
[ 2403.976189] ns diff: 81067 66
[ 2403.979504] ns diff: 81082 69
[ 2403.982815] ns diff: 81097 67
[ 2403.986127] ns diff: 81113 67
[ 2403.989439] ns diff: 81127 69
[ 2403.992752] ns diff: 81143 70
[ 2403.996065] ns diff: 81158 70
[...]
[ 2753.756071] ns diff: 1686562 65
[ 2753.759567] ns diff: 1686578 65
[ 2753.763073] ns diff: 1686596 65
[ 2753.766570] ns diff: 1686611 66
[ 2753.770075] ns diff: 1686627 67
[ 2753.773580] ns diff: 1686643 67
[ 2753.777086] ns diff: 1686658 66
[ 2753.780584] ns diff: 1686674 65
[ 2753.784093] ns diff: 1686690 69
[ 2753.787589] ns diff: 1686706 66
^ permalink raw reply related
* Re: [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Heiko Stuebner @ 2016-11-14 14:53 UTC (permalink / raw)
To: Caesar Wang
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Frank Wang,
Catalin Marinas, Shawn Lin, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Masahiro Yamada, Rob Herring, eddie.cai-TNX95d0MmH7DzftRWevZcw,
Roger Chen, Yakir Yang, Jianqun Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-6-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 9. November 2016, 21:21:57 CET schrieb Caesar Wang:
> From: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Add backlight node for evb board, perpare for panel device node.
>
> Signed-off-by: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
applied to my dts64 branch
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Heiko Stuebner @ 2016-11-14 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478697721-2323-6-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:57 CET schrieb Caesar Wang:
> From: Yakir Yang <ykk@rock-chips.com>
>
> Add backlight node for evb board, perpare for panel device node.
>
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
applied to my dts64 branch
Thanks
Heiko
^ permalink raw reply
* Re: CLOSE/OPEN race
From: Benjamin Coddington @ 2016-11-14 14:53 UTC (permalink / raw)
To: Trond Myklebust; +Cc: jlayton@redhat.com, linux-nfs@vger.kernel.org
In-Reply-To: <1479048471.3146.10.camel@primarydata.com>
On 13 Nov 2016, at 9:47, Trond Myklebust wrote:
> On Sat, 2016-11-12 at 21:56 -0500, Jeff Layton wrote:
>> On Sat, 2016-11-12 at 16:16 -0500, Jeff Layton wrote:
>>>
>>> On Sat, 2016-11-12 at 13:03 -0500, Benjamin Coddington wrote:
>>>>
>>>>
>>>> On 12 Nov 2016, at 11:52, Jeff Layton wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, 2016-11-12 at 10:31 -0500, Benjamin Coddington wrote:
>>>>>>
>>>>>>
>>>>>> On 12 Nov 2016, at 7:54, Jeff Layton wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, 2016-11-12 at 06:08 -0500, Benjamin Coddington
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I've been seeing the following on a modified version of
>>>>>>>> generic/089
>>>>>>>> that gets the client stuck sending LOCK with
>>>>>>>> NFS4ERR_OLD_STATEID.
>>>>>>>>
>>>>>>>> 1. Client has open stateid A, sends a CLOSE
>>>>>>>> 2. Client sends OPEN with same owner
>>>>>>>> 3. Client sends another OPEN with same owner
>>>>>>>> 4. Client gets a reply to OPEN in 3, stateid is B.2
>>>>>>>> (stateid B
>>>>>>>> sequence 2)
>>>>>>>> 5. Client does LOCK,LOCKU,FREE_STATEID from B.2
>>>>>>>> 6. Client gets a reply to CLOSE in 1
>>>>>>>> 7. Client gets reply to OPEN in 2, stateid is B.1
>>>>>>>> 8. Client sends LOCK with B.1 - OLD_STATEID, now stuck in
>>>>>>>> a loop
>>>>>>>>
>>>>>>>> The CLOSE response in 6 causes us to clear
>>>>>>>> NFS_OPEN_STATE, so that
>>>>>>>> the OPEN
>>>>>>>> response in 7 is able to update the open_stateid even
>>>>>>>> though it has a
>>>>>>>> lower
>>>>>>>> sequence number.
>>>>>>>>
>>>>>>>> I think this case could be handled by never updating the
>>>>>>>> open_stateid
>>>>>>>> if the
>>>>>>>> stateids match but the sequence number of the new state
>>>>>>>> is less than
>>>>>>>> the
>>>>>>>> current open_state.
>>>>>>>>
>>>>>>>
>>>>>>> What kernel is this on?
>>>>>>
>>>>>> On v4.9-rc2 with a couple fixups. Without them, I can't test
>>>>>> long
>>>>>> enough to
>>>>>> reproduce this race. I don't think any of those are involved
>>>>>> in this
>>>>>> problem, though.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, that seems wrong. The client should be picking B.2 for
>>>>>>> the open
>>>>>>> stateid to use. I think that decision of whether to take a
>>>>>>> seqid is
>>>>>>> made
>>>>>>> in nfs_need_update_open_stateid. The logic in there looks
>>>>>>> correct to
>>>>>>> me
>>>>>>> at first glance though.
>>>>>>
>>>>>> nfs_need_update_open_stateid() will return true if
>>>>>> NFS_OPEN_STATE is
>>>>>> unset.
>>>>>> That's the precondition set up by steps 1-6. Perhaps it
>>>>>> should not
>>>>>> update
>>>>>> the stateid if they match but the sequence number is less,
>>>>>> and still set
>>>>>> NFS_OPEN_STATE once more. That will fix _this_ case. Are
>>>>>> there other
>>>>>> cases
>>>>>> where that would be a problem?
>>>>>>
>>>>>> Ben
>>>>>
>>>>> That seems wrong.
>>>>
>>>> I'm not sure what you mean: what seems wrong?
>>>>
>>>
>>> Sorry, it seems wrong that the client would issue the LOCK with B.1
>>> there.
>>>
>>>>
>>>>>
>>>>>
>>>>> The only close was sent in step 1, and that was for a
>>>>> completely different stateid (A rather than B). It seems likely
>>>>> that
>>>>> that is where the bug is.
>>>>
>>>> I'm still not sure what point you're trying to make..
>>>>
>>>> Even though the close was sent in step 1, the response wasn't
>>>> processed
>>>> until step 6..
>>>
>>> Not really a point per-se, I was just saying where I think the bug
>>> might
>>> be...
>>>
>>> When you issue a CLOSE, you issue it vs. a particular stateid
>>> (stateid
>>> "A" in this case). Once the open stateid has been superseded by
>>> "B", the
>>> closing of "A" should have no effect.
>>>
>>> Perhaps nfs_clear_open_stateid needs to check and see whether the
>>> open
>>> stateid has been superseded before doing its thing?
>>>
>>
>> Ok, I see something that might be a problem in this call in
>> nfs4_close_done:
>>
>> nfs_clear_open_stateid(state, &calldata->arg.stateid,
>> res_stateid,
>> calldata->arg.fmode);
>>
>> Note that we pass two nfs4_stateids to this call. The first is the
>> stateid that got sent in the CLOSE call, and the second is the
>> stateid
>> that came back in the CLOSE response.
>>
>> RFC5661 and RFC7530 both indicate that the stateid in a CLOSE
>> response
>> should be ignored.
>>
>> So, I think a patch like this may be in order. As to whether it will
>> fix this bug, I sort of doubt it, but it might not hurt to test it
>> out?
>>
>> ----------------------8<--------------------------
>>
>> [RFC PATCH] nfs: properly ignore the stateid in a CLOSE response
>>
>> Signed-off-by: Jeff Layton
>> ---
>> fs/nfs/nfs4proc.c | 14 +++-----------
>> 1 file changed, 3 insertions(+), 11 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 7897826d7c51..58413bd0aae2 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -1451,7 +1451,6 @@ static void
>> nfs_resync_open_stateid_locked(struct nfs4_state *state)
>> }
>>
>> static void nfs_clear_open_stateid_locked(struct nfs4_state *state,
>> - nfs4_stateid *arg_stateid,
>> nfs4_stateid *stateid, fmode_t fmode)
>> {
>> clear_bit(NFS_O_RDWR_STATE, &state->flags);
>> @@ -1467,12 +1466,8 @@ static void
>> nfs_clear_open_stateid_locked(struct nfs4_state *state,
>> clear_bit(NFS_O_WRONLY_STATE, &state->flags);
>> clear_bit(NFS_OPEN_STATE, &state->flags);
>> }
>> - if (stateid == NULL)
>> - return;
>> /* Handle races with OPEN */
>> - if (!nfs4_stateid_match_other(arg_stateid, &state-
>>> open_stateid) ||
>> - (nfs4_stateid_match_other(stateid, &state->open_stateid)
>> &&
>> - !nfs4_stateid_is_newer(stateid, &state->open_stateid)))
>> {
>> + if (!nfs4_stateid_match_other(stateid, &state-
>>> open_stateid)) {
>
> No. I think what we should be doing here is
>
> 1) if (nfs4_stateid_match_other(arg_stateid, &state->open_stateid)
> then
You must mean (!nfs4_stateid_match_other(arg_stateid,
&state->open_stateid)
> just ignore the result and return immediately, because it applies to a
> completely different stateid.
>
> 2) if (nfs4_stateid_match_other(stateid, &state->open_stateid)
> && !nfs4_stateid_is_newer(stateid, &state->open_stateid))) then
> resync,
> because this was likely an OPEN_DOWNGRADE that has raced with one or
> more OPEN calls.
OK, but these do not help the originally reported race because at the
time
that the CLOSE response handling does a resync - I presume
nfs_resync_open_stateid_locked() - all the state counters are zero,
which
bypasses resetting NFS_OPEN_STATE, which, if unset, allows any stateid
to
update the open_stateid.
I need something like:
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index a230764b7d07..c9aa166c45aa 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -1425,8 +1425,13 @@ static void
nfs_test_and_clear_all_open_stateid(struct nfs4_state *state)
static bool nfs_need_update_open_stateid(struct nfs4_state *state,
const nfs4_stateid *stateid, nfs4_stateid *freeme)
{
- if (test_and_set_bit(NFS_OPEN_STATE, &state->flags) == 0)
+ if (test_and_set_bit(NFS_OPEN_STATE, &state->flags) == 0) {
+ if (nfs4_stateid_match_other(stateid,
&state->open_stateid) &&
+ !nfs4_stateid_is_newer(stateid,
&state->open_stateid))
+ return false;
return true;
+ }
+
if (!nfs4_stateid_match_other(stateid, &state->open_stateid)) {
nfs4_stateid_copy(freeme, &state->open_stateid);
nfs_test_and_clear_all_open_stateid(state);
I've got that in testing, and I'll let it run for a day or so.
Another way to simplify CLOSE/OPEN races might be to never reuse an
openowner if we send a close. Any opens after a close would have to use
a
new mutated openowner, so the state always proceeds from open to close
and
never back again. Any reason not to do that?
Ben
^ permalink raw reply related
* Re: [PATCH v2 5/9] arm64: dts: rockchip: add backlight support for rk3399 evb board
From: Heiko Stuebner @ 2016-11-14 14:53 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai, tfiga, Yakir Yang, devicetree, Arnd Bergmann,
Jianqun Xu, Masahiro Yamada, linux-rockchip, linux-kernel,
Shawn Lin, Rob Herring, linux-arm-kernel, Will Deacon, Frank Wang,
Mark Rutland, Catalin Marinas, Roger Chen
In-Reply-To: <1478697721-2323-6-git-send-email-wxt@rock-chips.com>
Am Mittwoch, 9. November 2016, 21:21:57 CET schrieb Caesar Wang:
> From: Yakir Yang <ykk@rock-chips.com>
>
> Add backlight node for evb board, perpare for panel device node.
>
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
applied to my dts64 branch
Thanks
Heiko
^ permalink raw reply
* [PATCH RFC nvme-cli 1/2] debain: generate hostnqn file on install and remove on uninstall
From: Gabriel Krisman Bertazi @ 2016-11-14 14:55 UTC (permalink / raw)
In-Reply-To: <67cdf4dd-3638-8faf-7512-0ef39ca464a3@grimberg.me>
Sagi Grimberg <sagi at grimberg.me> writes:
>> I think the subject should read "debian" :)
>
> Probably :)
>
>>> diff --git a/debian/prerm b/debian/prerm
>>> new file mode 100644
>>> index 000000000000..40c6fea42284
>>> --- /dev/null
>>> +++ b/debian/prerm
>>> @@ -0,0 +1,5 @@
>>> +#!/bin/sh
>>> +
>>> +if [ "$1" = "remove" ]; then
>>> + rm -rf /etc/nvme
>>> +fi
>>
>> Shouldn't we only do that for a purge?
>
> I haven't given it much thought, it really was a 15 minute
> thing that I thought I'd through out here so people can
> tell suggest how to do it better...
>
I think you need to use postrm and only do it for purge.
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact
https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html#sE.2
--
Gabriel Krisman Bertazi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.