* Re: [PATCH] drm/i915: Mask the ring->head offset using the ring->size
From: Chris Wilson @ 2012-01-17 11:14 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx, stable
In-Reply-To: <20120117105927.GI4093@phenom.ffwll.local>
On Tue, 17 Jan 2012 11:59:27 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 08, 2011 at 11:13:12PM +0000, Chris Wilson wrote:
> > Rather than relying on the hardware to do this correctly, we can
> > trivially do it ourselves.
> >
> > This fixes a very reliable crash on d-i-n with all bits enabled during a
> > cairo-trace replay. The symptoms of the crash is that we continue to
> > write commands into the render ring buffer past the active head
> > position, leading to undefined operations.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: stable@kernel.org
>
> I guess this is just the usual "snb doesn't like being pushed to hard bug"
> resulting in random crashes with confusing error_states. So I think I'll
> drop this. Correct?
I could find no other reason for this to have any effect other than the
hw not playing fair so don't apply it until some one else starts
experiencing random hangs on their SNB and can confirm whether this
patch helps.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* RE: [PATCH] omap3 towards thumb2 support
From: Premi, Sanjeev @ 2012-01-17 11:14 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox@lists.infradead.org
In-Reply-To: <E28AAFD00EFAA646AE3DF9B89CD24A89317FB2B7@DBDE01.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]
> -----Original Message-----
> From: barebox-bounces@lists.infradead.org
> [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> Premi, Sanjeev
> Sent: Monday, January 16, 2012 9:47 PM
> To: Sascha Hauer
> Cc: barebox@lists.infradead.org
> Subject: RE: [PATCH] omap3 towards thumb2 support
>
> (responding via webmail. Won't be able to quote properly)
> ________________________________________
> From: Sascha Hauer [s.hauer@pengutronix.de]
> Sent: Monday, January 16, 2012 9:16 PM
> To: Premi, Sanjeev
> Cc: barebox@lists.infradead.org
> Subject: Re: [PATCH] omap3 towards thumb2 support
>
> On Mon, Jan 16, 2012 at 12:42:36PM +0000, Premi, Sanjeev wrote:
> >
> > > -----Original Message-----
> > > From: barebox-bounces@lists.infradead.org
> > > [mailto:barebox-bounces@lists.infradead.org] On Behalf Of
> > > Premi, Sanjeev
> > > Sent: Monday, January 16, 2012 5:32 PM
> > > To: Sascha Hauer
> > > Cc: barebox@lists.infradead.org
> > > Subject: RE: [PATCH] omap3 towards thumb2 support
> > >
> >
> > [snip]
> >
> > > > >
> > > > > I was able to pull in your branch and encountered a minor
> > > > > issue - fixed by the patch at end of this mail.
> > > > >
> > > > > How can I enable thumb2? Didn't find aything obvious in
> > > > > omap3530_beagle_xload_defconfig.
> > > >
> > > > Did you merge the work/thumb2 branch into your branch? Then
> > > you should
> > > > find THUMB2_BAREBOX in menuconfig.
> > >
> > > Found it. I was searching in a "cached" version of the
> file already
> > > in my editor. Will try immediately.
> > >
> >
> > I discarded the patches that I had manually merged last week and
> > pulled work/thumb2 instead.
> >
> > The size of MLO dropped from 47604 to 35052 bytes. However,
> it didn't
> > boot successfully on the board. The MLO generated after removing
> > CONFIG_THUMB2_BAREBOX came up fine.
>
> Please check that CONFIG_STACK_BASE really is 0x4020F000. It
> may be set
> differently if you started from an older config.
>
> [sp} Already did this.
>
> Also, the resulting binary should also be startable as a second stage
> loader in which case you might get some stack trace if you
> have enabled
> this in the first stage.
>
> [sp] Okay, this could be the issue. I was always building as
> first stage
> bootloader only - as i was looking for the banner to appear.
>
> Will try using emulator tomorrow to debug further.
>
> >
> > BTW, I while merging this patch, I saw a warning that could be fixed
> > before merging the patch into master.
> > 8917ac1 : Applying: ARM: move exception vectors away from
> start of binary
> >
> > /home/premi/barebox/.git/rebase-apply/patch:236: new blank
> line at EOF.
> > +
> > warning: 1 line adds whitespace errors.
>
> Ok, will fix.
>
> I attached my binary MLO file. Could you check if it works for you? I
> just checked this binary and it comes up with:
>
> [sp] I will try tomorrow morning.
Sascha,
Your MLO boots fine. But I couldn't make repeat success on either
beagle or the omap3evem on my side.
Each time there is an exception on entry of setup_auxcr() on both
boards. See attached image.
I noticed that the size of the generated MLO for beagle were different
for us - 35224(yours) vs. 35572(mine).
I am building with CodeSourcery 2011.03-41.
~sanjeev
[-- Attachment #2: barebox_err.jpg --]
[-- Type: image/jpeg, Size: 140279 bytes --]
[-- Attachment #3: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH v3] drm/i915: Fix recursive calls to unmap
From: Daniel Vetter @ 2012-01-17 11:15 UTC (permalink / raw)
To: Ben Widawsky; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20111103152339.46fe6ce8@bwidawsk.net>
On Thu, Nov 03, 2011 at 03:23:39PM -0700, Ben Widawsky wrote:
> On Thu, 3 Nov 2011 20:19:23 +0000
> Dave Airlie <airlied@gmail.com> wrote:
>
> > >> >
> > >> > The solution here is to add a new flag to the call chain which gives the
> > >> > routines the information they need to possibly defer actions which may
> > >> > cause us to recurse. A macro has been defined to replace i915_gpu_idle
> > >> > which defaults to the old behavior.
> > >> >
> > >> > Kudos to Chris for tracking this one down.
> > >>
> > >> So this fixes the non-VTd case, the VT-d case still hits a recursion
> > >> here, for posterity its below.
> >
> > Okay I take that back, I got my EL6 kernel rock stable with the
> > correct blend of backported bits.
> >
> > So ignore that backtrace, however I did get another IOMMU hang on my
> > upstream kernel with gem_linear_blits,
> >
> > so this should be fine to merge but I'm guessing we have more
> > debugging to do on the VT-d cases.
> >
> > Dave.
>
> Does it pass your original failing case?
Hi Ben,
Is v3 of this patch the right one to merge or do we still have some
outstanding issues on this? Also, have you looked at the recent ilk dmar
fallout, I think strict dmar iotlb flushing doesn't sit too well with our
gpus. My snb dies almost immediately with that (even when I do not enable
rc6 nor semaphores).
Cheers, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [patch v2, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP
From: Eric Dumazet @ 2012-01-17 11:15 UTC (permalink / raw)
To: Štefan Gula
Cc: Alexey Kuznetsov, David S. Miller, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CAGsizz+WG=NEc7kj7WoZP0Z-KgGwwiJS7kycHW6cxPeo9h88zA@mail.gmail.com>
Le mardi 17 janvier 2012 à 12:00 +0100, Štefan Gula a écrit :
> >
> looks good... I am just wondering whether my previous question about
> the placement of calls for ipgre_tap_bridge_init and
> ipgre_tap_bridge_fini? Would it be also possible to have this
> done/fixed when I migrate those inside the ipgre_init and ipgre_fini ?
> I would like to have much rather identical parts of code with standard
> bridge code just in case somebody would start doing generalization of
> bridge code which can be then reused anywhere inside the kernel space
> - simpler migration process later.
Could you please stop claiming this is the same than bridge ?
There is _one_ exit function per module (ipgre_fini in ip_gre)
You wanted to destroy your kmem_cache only from this __exit function,
not from the pernet exit function (ipgre_exit_net)
^ permalink raw reply
* Re: [PATCH] drm/i915:: Disable FBC on SandyBridge
From: Chris Wilson @ 2012-01-17 11:16 UTC (permalink / raw)
To: Daniel Vetter, Eugeni Dodonov; +Cc: intel-gfx
In-Reply-To: <20120117105705.GH4093@phenom.ffwll.local>
On Tue, 17 Jan 2012 11:57:05 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 08, 2011 at 11:17:34PM +0000, Chris Wilson wrote:
> > Enabling FBC is causing the BLT ring to run between 10-100x slower than
> > normal and frequently lockup. The interim solution is disable FBC once
> > more until we know why.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> Iirc fbc isn't really worth it power-wise on snb and we don't implement it on
> ivb. So shouldn't we just disable it completely? Eugeni, any opinions - I
> think you're most up to speed on power saving figures for snb?
Also note that I've had a couple of people confirm this bug and tested
the patch on IRC. Doesn't help explain precisely what is wrong nor if
there is a better workaround amidst the chicken bits that we've missed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCHv2 1 of 2] Move IOMMU faults handling into softirq for VT-d.
From: Keir Fraser @ 2012-01-17 11:17 UTC (permalink / raw)
To: Dario Faggioli, xen-devel
Cc: Wei Wang2, allen.m.kay@intel.com, Tim Deegan, Jan Beulich
In-Reply-To: <1325777149.2728.9.camel@Solace>
On 05/01/2012 15:25, "Dario Faggioli" <raistlin@linux.it> wrote:
> Dealing with interrupts from VT-d IOMMU(s) is deferred to a softirq-tasklet,
> raised by the actual IRQ handler. Since a new interrupt is not generated,
> even if further faults occur, until we cleared all the pending ones,
> there's no need of disabling IRQs, as the hardware does it by its own.
> Notice that this may cause the log to overflow, but none of the existing
> entry will be overwritten.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Applied, thanks.
-- Keir
> diff -r efaa28639a71 xen/drivers/passthrough/vtd/iommu.c
> --- a/xen/drivers/passthrough/vtd/iommu.c Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Jan 05 15:17:47 2012 +0100
> @@ -53,6 +53,8 @@ bool_t __read_mostly untrusted_msi;
>
> int nr_iommus;
>
> +static struct tasklet vtd_fault_tasklet;
> +
> static void setup_dom0_device(struct pci_dev *);
> static void setup_dom0_rmrr(struct domain *d);
>
> @@ -918,10 +920,8 @@ static void iommu_fault_status(u32 fault
> }
>
> #define PRIMARY_FAULT_REG_LEN (16)
> -static void iommu_page_fault(int irq, void *dev_id,
> - struct cpu_user_regs *regs)
> +static void __do_iommu_page_fault(struct iommu *iommu)
> {
> - struct iommu *iommu = dev_id;
> int reg, fault_index;
> u32 fault_status;
> unsigned long flags;
> @@ -996,6 +996,37 @@ clear_overflow:
> }
> }
>
> +static void do_iommu_page_fault(unsigned long data)
> +{
> + struct acpi_drhd_unit *drhd;
> +
> + if ( list_empty(&acpi_drhd_units) )
> + {
> + INTEL_IOMMU_DEBUG("no device found, something must be very wrong!\n");
> + return;
> + }
> +
> + /*
> + * No matter from whom the interrupt came from, check all the
> + * IOMMUs present in the system. This allows for having just one
> + * tasklet (instead of one per each IOMMUs) and should be more than
> + * fine, considering how rare the event of a fault should be.
> + */
> + for_each_drhd_unit ( drhd )
> + __do_iommu_page_fault(drhd->iommu);
> +}
> +
> +static void iommu_page_fault(int irq, void *dev_id,
> + struct cpu_user_regs *regs)
> +{
> + /*
> + * Just flag the tasklet as runnable. This is fine, according to VT-d
> + * specs since a new interrupt won't be generated until we clear all
> + * the faults that caused this one to happen.
> + */
> + tasklet_schedule(&vtd_fault_tasklet);
> +}
> +
> static void dma_msi_unmask(struct irq_desc *desc)
> {
> struct iommu *iommu = desc->action->dev_id;
> @@ -2144,6 +2175,8 @@ int __init intel_vtd_setup(void)
> iommu->irq = ret;
> }
>
> + softirq_tasklet_init(&vtd_fault_tasklet, do_iommu_page_fault, 0);
> +
> if ( !iommu_qinval && iommu_intremap )
> {
> iommu_intremap = 0;
^ permalink raw reply
* Re: [PATCHv2 2 of 2] Move IOMMU faults handling into softirq for AMD-Vi.
From: Keir Fraser @ 2012-01-17 11:17 UTC (permalink / raw)
To: Dario Faggioli, xen-devel
Cc: Wei Wang2, allen.m.kay@intel.com, Tim Deegan, Jan Beulich
In-Reply-To: <1325777220.2728.11.camel@Solace>
On 05/01/2012 15:27, "Dario Faggioli" <raistlin@linux.it> wrote:
> Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-tasklet,
> raised by the actual IRQ handler. To avoid more interrupts being generated
> (because of further faults), they must be masked in the IOMMU within the low
> level IRQ handler and enabled back in the tasklet body. Notice that this may
> cause the log to overflow, but none of the existing entry will be overwritten.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
This patch needs fixing to apply to xen-unstable tip. Please do that and
resubmit.
-- Keir
> diff -r 3cb587bb34d0 xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c Thu Jan 05 15:12:35 2012 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_init.c Thu Jan 05 15:14:03 2012 +0100
> @@ -32,6 +32,8 @@
>
> static int __initdata nr_amd_iommus;
>
> +static struct tasklet amd_iommu_fault_tasklet;
> +
> unsigned short ivrs_bdf_entries;
> static struct radix_tree_root ivrs_maps;
> struct list_head amd_iommu_head;
> @@ -522,12 +524,10 @@ static void parse_event_log_entry(struct
> }
> }
>
> -static void amd_iommu_page_fault(int irq, void *dev_id,
> - struct cpu_user_regs *regs)
> +static void __do_amd_iommu_page_fault(struct amd_iommu *iommu)
> {
> u32 entry;
> unsigned long flags;
> - struct amd_iommu *iommu = dev_id;
>
> spin_lock_irqsave(&iommu->lock, flags);
> amd_iommu_read_event_log(iommu);
> @@ -546,6 +546,45 @@ static void amd_iommu_page_fault(int irq
> spin_unlock_irqrestore(&iommu->lock, flags);
> }
>
> +static void do_amd_iommu_page_fault(unsigned long data)
> +{
> + struct amd_iommu *iommu;
> +
> + if ( !iommu_found() )
> + {
> + AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n");
> + return;
> + }
> +
> + /*
> + * No matter from whom the interrupt came from, check all the
> + * IOMMUs present in the system. This allows for having just one
> + * tasklet (instead of one per each IOMMUs) and should be more than
> + * fine, considering how rare the event of a fault should be.
> + */
> + for_each_amd_iommu ( iommu )
> + __do_amd_iommu_page_fault(iommu);
> +}
> +
> +static void amd_iommu_page_fault(int irq, void *dev_id,
> + struct cpu_user_regs *regs)
> +{
> + u32 entry;
> + unsigned long flags;
> + struct amd_iommu *iommu = dev_id;
> +
> + /* silence interrupts. The tasklet will enable them back */
> + spin_lock_irqsave(&iommu->lock, flags);
> + entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> + iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
> + writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
> + spin_unlock_irqrestore(&iommu->lock, flags);
> +
> + /* Flag the tasklet as runnable so that it can execute, clear
> + * the log and re-enable interrupts. */
> + tasklet_schedule(&amd_iommu_fault_tasklet);
> +}
> +
> static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
> {
> int irq, ret;
> @@ -884,6 +923,8 @@ int __init amd_iommu_init(void)
> if ( amd_iommu_init_one(iommu) != 0 )
> goto error_out;
>
> + softirq_tasklet_init(&amd_iommu_fault_tasklet, do_amd_iommu_page_fault,
> 0);
> +
> return 0;
>
> error_out:
^ permalink raw reply
* Re: Optimal XFS formatting options?
From: Emmanuel Florac @ 2012-01-17 11:17 UTC (permalink / raw)
To: xfs
In-Reply-To: <201201171019.58714@zmi.at>
[-- Attachment #1.1: Type: text/plain, Size: 854 bytes --]
Le Tue, 17 Jan 2012 10:19:55 +0100
Michael Monnerie <michael.monnerie@is.it-management.at> écrivait:
> - expand array by factors of two. So if you have 10 data drives, add
> 10 data drives. But that creates other problems (probability of
> single drive failure + time to recover a single broken disk)
From my experience 20 drives is OK for RAID-6. And rebuild time doesn't
change much with array size, anyway.
Misaligned partitions, on the other hand, can easily halve array
throughput from my own measurements.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [U-Boot] [PATCH] imx6: mx6qarm2: updated
From: Stefano Babic @ 2012-01-17 11:18 UTC (permalink / raw)
To: u-boot
Commit 314284b1567f1ce29c19060641e7f213146f7ab8 has
changed board_mmc_getcd() function prototype, while
mx6qarm2 has still the old one.
Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Jason Liu <jason.hui@linaro.org>
---
board/freescale/mx6qarm2/mx6qarm2.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx6qarm2/mx6qarm2.c b/board/freescale/mx6qarm2/mx6qarm2.c
index 9894245..9724c16 100644
--- a/board/freescale/mx6qarm2/mx6qarm2.c
+++ b/board/freescale/mx6qarm2/mx6qarm2.c
@@ -120,17 +120,18 @@ struct fsl_esdhc_cfg usdhc_cfg[2] = {
{USDHC4_BASE_ADDR, 1},
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
+ int ret;
if (cfg->esdhc_base == USDHC3_BASE_ADDR) {
gpio_direction_input(171); /*GPIO6_11*/
- *cd = gpio_get_value(171);
+ ret = !gpio_get_value(171);
} else /* Don't have the CD GPIO pin on board */
- *cd = 0;
+ ret = 0;
- return 0;
+ return ret;
}
int board_mmc_init(bd_t *bis)
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v3 0/6] NAND BBM + BBT updates
From: Angus CLARK @ 2012-01-17 11:19 UTC (permalink / raw)
To: dedekind1
Cc: Dan Carpenter, Kulikov Vasiliy, Sebastian Andrzej Siewior,
Nicolas Ferre, Dominik Brodowski, Peter Wippich, Gabor Juhos,
linux-mtd, Jonas Gorski, Jamie Iles, Ivan Djelic, Robert Jarzmik,
David Woodhouse, Maxim Levitsky, Dmitry Eremin-Solenikov,
Kevin Cernekee, Barry Song, Jim Quinlan, Andres Salomon, Axel Lin,
Anatolij Gustschin, Mike Frysinger, Arnd Bergmann, Lei Wen,
Sascha Hauer, Artem Bityutskiy, Florian Fainelli, Adrian Hunter,
Matthieu CASTET, Kyungmin Park, Shmulik Ladkani, Wolfram Sang,
Chuanxiao Dong, Joe Perches, Guillaume LECERF, Brian Norris,
Roman Tereshonkov
In-Reply-To: <1326494218.2258.36.camel@koala>
On 01/13/2012 10:36 PM, Artem Bityutskiy wrote:
> On Thu, 2012-01-12 at 10:09 +0100, Sebastian Andrzej Siewior wrote:
>>
>> so the OOB array is by design more reliable than the data area?
>
> I think so, because it is distributed, and it is historically the way
> blocks had been marked as bad, and I thing vendors make sure this
> mechanism works.
>
Is this really true? I was under the impression that the OOB area was the same
as the data area, as far as reliability is concerned, and is subject to the same
ECC requirements.
As far as I am aware, NAND manufacturers only guarantee that the
factory-programmed OOB BB markers are valid. Nothing is mentioned in the
datasheets about using OOB BB markers to track worn blocks - they all tend to
recommend BBTs.
Cheers,
Angus
^ permalink raw reply
* booting hangs after enabling CONFIG_EARLY_PRINTK
From: shabbir @ 2012-01-17 11:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russel
I have ported linux 3.0 kernel to ARM board,it is successfully booting,but when
i enabled the CONFIG_EARLY_PRINTK in kernel hacking->kernel debugging->kernel
low level debugging from make menuconfig,kernel booting hangs after
Uncompressing linux...done,booting the kernel.But the same thing when i have
tested with ARM versatile PB board everything works fine,i dont know what's
wrong with my board.Please help me in this isssue
Thanks
Regards
Shabbir
^ permalink raw reply
* Re: [PATCH] Enable FBC on IVB architecture.
From: Daniel Vetter @ 2012-01-17 11:22 UTC (permalink / raw)
To: Eugeni Dodonov; +Cc: intel-gfx
In-Reply-To: <1319130909-6497-1-git-send-email-eugeni.dodonov@intel.com>
On Thu, Oct 20, 2011 at 03:15:09PM -0200, Eugeni Dodonov wrote:
> This is mostly similar to Ironlake, with some register changes and
> additional tricks.
>
> Jesse mentioned that it would make more sense to move those bits into
> ivb-specific functions instead of making this work within ironlake ones,
> so I added the corresponding functions and setup their pointers
> accordingly.
>
> v2: Now the correct patch.
>
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Anyone got an opinion on whether this is worth it power-consumption wise?
fbc has been a bit of a disaster and we have it disabled almost everywhere
...
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 14 ++++++
> drivers/gpu/drm/i915/intel_display.c | 83 ++++++++++++++++++++++++++++++++-
> 3 files changed, 95 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f07e425..a4300b7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -233,7 +233,7 @@ static const struct intel_device_info intel_ivybridge_d_info = {
> static const struct intel_device_info intel_ivybridge_m_info = {
> .is_ivybridge = 1, .gen = 7, .is_mobile = 1,
> .need_gfx_hws = 1, .has_hotplug = 1,
> - .has_fbc = 0, /* FBC is not enabled on Ivybridge mobile yet */
> + .has_fbc = 1, /* Attempt at enabling FBC on IvyBridge mobile */
> .has_bsd_ring = 1,
> .has_blt_ring = 1,
> };
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 542453f..4d1ce26 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -627,6 +627,7 @@
> #define ILK_DISPLAY_CHICKEN1 0x42000
> #define ILK_FBCQ_DIS (1<<22)
> #define ILK_PABSTRETCH_DIS (1<<21)
> +#define IVB_DPR_VS_FBCQ_DIS (1<<22)
>
>
> /*
> @@ -638,6 +639,19 @@
> #define SNB_CPU_FENCE_ENABLE (1<<29)
> #define DPFC_CPU_FENCE_OFFSET 0x100104
>
> +/*
> + * Framebuffer compression for IVB
> + *
> + * Mostly similar to ILK with some changes
> + */
> +
> +#define IVB_RESERVED (0x0FFFFF00)
> +
> +/* Controlled via ILK_DPFC_CONTROL */
> +#define IVB_FBC_CTL_PLANEA (0<<29)
> +#define IVB_FBC_CTL_PLANEB (1<<29)
> +#define IVB_FBC_CTL_PLANEC (2<<29)
> +#define IVB_FBC_CPU_FENCE_ENABLE (1<<28)
>
> /*
> * GPIO regs
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 04411ad..de77249 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1657,6 +1657,77 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
> return I915_READ(ILK_DPFC_CONTROL) & DPFC_CTL_EN;
> }
>
> +static void ivb_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_framebuffer *fb = crtc->fb;
> + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + unsigned long stall_watermark = 200;
> + u32 dpfc_ctl;
> +
> + dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
> + dpfc_ctl &= IVB_RESERVED;
> + /* Workarounds */
> + I915_WRITE(ILK_DISPLAY_CHICKEN1,
> + I915_READ(ILK_DISPLAY_CHICKEN1) |
> + IVB_DPR_VS_FBCQ_DIS);
> + I915_WRITE(ILK_DSPCLK_GATE,
> + I915_READ(ILK_DSPCLK_GATE) |
> + ILK_DPFC_DIS2 |
> + ILK_CLK_FBC);
> + /* IVL has 3 pipes */
> + switch (intel_crtc->plane) {
> + case 0:
> + dpfc_ctl |= IVB_FBC_CTL_PLANEA;
> + break;
> + case 1:
> + dpfc_ctl |= IVB_FBC_CTL_PLANEB;
> + break;
> + case 2:
> + dpfc_ctl |= IVB_FBC_CTL_PLANEC;
> + break;
> + }
> + /* fence enablement */
> + dpfc_ctl |= (IVB_FBC_CPU_FENCE_ENABLE | obj->fence_reg);
> + dpfc_ctl |= DPFC_CTL_LIMIT_1X;
> + I915_WRITE(ILK_DPFC_CHICKEN, DPFC_HT_MODIFY);
> +
> + I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
> + (stall_watermark << DPFC_RECOMP_STALL_WM_SHIFT) |
> + (interval << DPFC_RECOMP_TIMER_COUNT_SHIFT));
> + I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc->y);
> + I915_WRITE(ILK_FBC_RT_BASE, obj->gtt_offset | ILK_FBC_RT_VALID);
> + /* enable it... */
> + I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
> +
> + DRM_DEBUG_KMS("enabled fbc on plane %d\n", intel_crtc->plane);
> +}
> +
> +static void ivb_disable_fbc(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 dpfc_ctl;
> +
> + /* Disable compression */
> + dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
> + if (dpfc_ctl & DPFC_CTL_EN) {
> + dpfc_ctl &= ~DPFC_CTL_EN;
> + I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
> +
> + DRM_DEBUG_KMS("disabled FBC\n");
> + }
> +}
> +
> +static bool ivb_fbc_enabled(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + return I915_READ(ILK_DPFC_CONTROL) & DPFC_CTL_EN;
> +}
> +
> bool intel_fbc_enabled(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -8138,9 +8209,15 @@ static void intel_init_display(struct drm_device *dev)
>
> if (I915_HAS_FBC(dev)) {
> if (HAS_PCH_SPLIT(dev)) {
> - dev_priv->display.fbc_enabled = ironlake_fbc_enabled;
> - dev_priv->display.enable_fbc = ironlake_enable_fbc;
> - dev_priv->display.disable_fbc = ironlake_disable_fbc;
> + if (IS_GEN7(dev)) {
> + dev_priv->display.fbc_enabled = ivb_fbc_enabled;
> + dev_priv->display.enable_fbc = ivb_enable_fbc;
> + dev_priv->display.disable_fbc = ivb_disable_fbc;
> + } else {
> + dev_priv->display.fbc_enabled = ironlake_fbc_enabled;
> + dev_priv->display.enable_fbc = ironlake_enable_fbc;
> + dev_priv->display.disable_fbc = ironlake_disable_fbc;
> + }
> } else if (IS_GM45(dev)) {
> dev_priv->display.fbc_enabled = g4x_fbc_enabled;
> dev_priv->display.enable_fbc = g4x_enable_fbc;
> --
> 1.7.6.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface
From: Ingo Molnar @ 2012-01-17 11:22 UTC (permalink / raw)
To: Srikar Dronamraju, Paul E. McKenney
Cc: Jiri Olsa, Arnaldo Carvalho de Melo, Peter Zijlstra,
Linus Torvalds, Oleg Nesterov, Andrew Morton, LKML, Linux-mm,
Andi Kleen, Christoph Hellwig, Steven Rostedt, Roland McGrath,
Thomas Gleixner, Masami Hiramatsu, Arnaldo Carvalho de Melo,
Anton Arapov, Ananth N Mavinakayanahalli, Jim Keniston,
Stephen Rothwell
In-Reply-To: <20120117102231.GB15447@linux.vnet.ibm.com>
Srikar, rebased commits like this one:
c5af743: rcu: Introduce raw SRCU read-side primitives
are absolutely inacceptable:
commit c5af7439f322db86e347991e184b95dd80676967
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Sun Oct 9 15:13:11 2011 -0700
rcu: Introduce raw SRCU read-side primitives
...
Requested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
If you pull a commit from Paul into your tree then you must
never rebase it. If you applied Paul's commit out of email then
you should add a Signed-off-by, not a Tested-by tag at the end.
Also, please test whether it works when merged to latest -tip,
there's been various RCU changes in this area. AFAICS these
read-side primitives are already upstream via:
0c53dd8b3140: rcu: Introduce raw SRCU read-side primitives
so pulling your tree would break the build.
Thanks,
Ingo
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v9 3.2 7/9] tracing: uprobes trace_event interface
From: Ingo Molnar @ 2012-01-17 11:22 UTC (permalink / raw)
To: Srikar Dronamraju, Paul E. McKenney
Cc: Jiri Olsa, Arnaldo Carvalho de Melo, Peter Zijlstra,
Linus Torvalds, Oleg Nesterov, Andrew Morton, LKML, Linux-mm,
Andi Kleen, Christoph Hellwig, Steven Rostedt, Roland McGrath,
Thomas Gleixner, Masami Hiramatsu, Arnaldo Carvalho de Melo,
Anton Arapov, Ananth N Mavinakayanahalli, Jim Keniston,
Stephen Rothwell
In-Reply-To: <20120117102231.GB15447@linux.vnet.ibm.com>
Srikar, rebased commits like this one:
c5af743: rcu: Introduce raw SRCU read-side primitives
are absolutely inacceptable:
commit c5af7439f322db86e347991e184b95dd80676967
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Sun Oct 9 15:13:11 2011 -0700
rcu: Introduce raw SRCU read-side primitives
...
Requested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
If you pull a commit from Paul into your tree then you must
never rebase it. If you applied Paul's commit out of email then
you should add a Signed-off-by, not a Tested-by tag at the end.
Also, please test whether it works when merged to latest -tip,
there's been various RCU changes in this area. AFAICS these
read-side primitives are already upstream via:
0c53dd8b3140: rcu: Introduce raw SRCU read-side primitives
so pulling your tree would break the build.
Thanks,
Ingo
^ permalink raw reply
* RAID6, failed device, unresponsive system?
From: Mathias Burén @ 2012-01-17 11:25 UTC (permalink / raw)
To: Linux-RAID
Hi list,
This is the setup:
8x 2TB HDDs partitioned 2048 sectors in, then almost filled (left 2GB
or so at the end), so md0 consists of /dev/s[b-h]1 , 64KB chunk size.
I got an email from mdadm saying that sdb1 has failed, so I SSH in.
The array is in "checking" state (guessing it's my weekly cron job
that kicked in), but it's at 38KB/s so I attempt to "echo idle >
md0/sync_action", but that hangs. I decide to check the SMART details
of sdb, and it is indeed very broken, RMA is now in progress. So this
is where I'm at. I've stopped all services relating to the mount point
of md0, and trying to unmount but it doesn't work, it just sits there.
I can't even cat /proc/mdstat , that hangs as well. I'll leave this
for a few hours before I get home. If it's not responsive by the time
I get home (cat /proc/mdstat for example) then I'll just disconnect
the bad HDD and boot to single user mode to check the array status.
Why is the system unresponsive, shouldn't it still be OK after a drive failure?
Best regards,
Mathias
^ permalink raw reply
* Re: [PATCH 1/5] ACPI processor: Do not export acpi_idle_driver in processor.h
From: Len Brown @ 2012-01-17 11:25 UTC (permalink / raw)
To: Thomas Renninger; +Cc: linux-acpi
In-Reply-To: <1321569421-46220-2-git-send-email-trenn@suse.de>
On 11/17/2011 05:36 PM, Thomas Renninger wrote:
> Instead move its declaration from processor_idle.c to processor_driver.c
> and declare it static as it's the only file using this struct.
>
> Cleanup only, no functional change.
>
> Signed-off-by: Thomas Renninger <trenn@suse.de>
> CC: Len Brown <lenb@kernel.org>
> CC: linux-acpi@vger.kernel.org
> ---
> drivers/acpi/processor_driver.c | 5 +++++
> drivers/acpi/processor_idle.c | 5 -----
> include/acpi/processor.h | 1 -
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
drivers/acpi/processor_idle.c: In function ‘acpi_processor_setup_cpuidle_states’:
drivers/acpi/processor_idle.c:1032:32: error: ‘acpi_idle_driver’ undeclared (first use in this function)
drivers/acpi/processor_idle.c:1032:32: note: each undeclared identifier is reported only once for each function it appears in
drivers/acpi/processor_idle.c: In function ‘acpi_processor_cst_has_changed’:
drivers/acpi/processor_idle.c:1158:29: error: ‘acpi_idle_driver’ undeclared (first use in this function)
drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_init’:
drivers/acpi/processor_idle.c:1239:38: error: ‘acpi_idle_driver’ undeclared (first use in this function)
drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_exit’:
drivers/acpi/processor_idle.c:1270:31: error: ‘acpi_idle_driver’ undeclared (first use in this function)
eh?
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index a4e0f1b..3a4fc0c 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -106,6 +106,11 @@ static struct acpi_driver acpi_processor_driver = {
> },
> };
>
> +static struct cpuidle_driver acpi_idle_driver = {
> + .name = "acpi_idle",
> + .owner = THIS_MODULE,
> +};
> +
> #define INSTALL_NOTIFY_HANDLER 1
> #define UNINSTALL_NOTIFY_HANDLER 2
>
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 9b88f98..7fed4f3 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -968,11 +968,6 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev,
> return idle_time;
> }
>
> -struct cpuidle_driver acpi_idle_driver = {
> - .name = "acpi_idle",
> - .owner = THIS_MODULE,
> -};
> -
> /**
> * acpi_processor_setup_cpuidle - prepares and configures CPUIDLE
> * @pr: the ACPI processor
> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> index 67055f1..5b27bc3 100644
> --- a/include/acpi/processor.h
> +++ b/include/acpi/processor.h
> @@ -333,7 +333,6 @@ int acpi_processor_power_exit(struct acpi_processor *pr,
> struct acpi_device *device);
> int acpi_processor_suspend(struct acpi_device * device, pm_message_t state);
> int acpi_processor_resume(struct acpi_device * device);
> -extern struct cpuidle_driver acpi_idle_driver;
>
> /* in processor_thermal.c */
> int acpi_processor_get_limit_info(struct acpi_processor *pr);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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] [RFC] drm/i915: Warning when reads or writes are dropped
From: Chris Wilson @ 2012-01-17 11:26 UTC (permalink / raw)
To: Daniel Vetter, Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <20120117110857.GJ4093@phenom.ffwll.local>
On Tue, 17 Jan 2012 12:08:57 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote:
> > The GTFIFODBG register gives us 3 error types when the fifo is accessed
> > and full. Whenever we do a forcewake_put we can check this register to
> > see if any of the CPU related errors occurred.
> >
> > Of more interest is perhaps the bit I am not checking which tells when
> > some other part of the chip makes a request and the FIFO is full. I
> > couldn't really decide on a good place to put that check.
> >
> > This patch seems to have value to me, but I'm not sure it's worth the
> > cost of the extra MMIO read`. (I've yet to see this occur, but I haven't
> > actually been running with it for very long).
> >
>
> This looks like a nice little patch here. Care to update it for
> spinlocked and multithreaded forcewake and maybe also check the other
> errors? And also add it to the error_state output (just base it on top of
> danvet/my-next to avoid conflicts with the oustanding error_state
> cleanup).
The advantage of placing the warning in _put is that we could identify
the sequence of register writes that trigger the error, so a stack trace
would be more useful i.e. a WARN instead.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH 29 of 32 RFC] libxl: add named enum for timer mode
From: Ian Campbell @ 2012-01-17 11:26 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <20244.20465.336196.143853@mariner.uk.xensource.com>
On Mon, 2012-01-16 at 16:27 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer mode"):
> > I'm happy to take either approach to be honest. I imagine most _init
> > functions will turn into just a memset anyway at which point maybe we
> > should just ditch them.
> >
> > I'd rather either all data types had an init or none is my only real
> > feeling on the matter.
>
> I absolutely agree. (The init function could be autogenerated.)
OK, I shall arrange that each type libxl_FOO has a libxl_FOO_init which
cannot fail and which is (normally) generated from the IDL. Likewise I
will arrange for a libxl_FOO_setdefaults which can fail.
This gives us the freedom to have non-zero representation for the
default on a per-type or per-field exceptional basis.
This will however make this series even larger...
> > > we could decree that all-bits-set means "use default value".
> >
> > Do you mean in genral or just this specific field?
>
> In general.
>
> Ian.
^ permalink raw reply
* [PATCH 1/2] mach-ux500: cache operations are atomic on PL310
From: Srinidhi KASAGAR @ 2012-01-17 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120117103023.GB9230@mudshark.cambridge.arm.com>
On Tue, Jan 17, 2012 at 11:30:23 +0100, Will Deacon wrote:
> Hi Srinidhi,
>
> On Tue, Jan 17, 2012 at 06:22:26AM +0000, Srinidhi KASAGAR wrote:
> > On Mon, Jan 16, 2012 at 15:50:08 +0100, Will Deacon wrote:
> > > The lock needs to stay. Besides, the problem isn't with inv_all, the problem
> > > is with not being able to disable the outer cache. So can't you just do
> > > something nasty like:
> > >
> > > outer_cache.disable = NULL;
> > >
> > > after your call to l2x0_init?
> >
> > hmm..patch below
>
> Thanks. Comments inline.
>
> > >
> > > Also, if you can't disable the L2 from non-secure, does that mean that you
> > > boot Linux with the L2 enabled?
> >
> > Yes, we boot with L2 enabled.
>
> Interesting. I'm surprised you don't have problems with stale data on the
> D-side after the decompressor. Maybe you're lucky with the mappings being no
> write allocate.
Actually the pre bootloader makes sure that L2 is clean before relinquishing
the control to kernel decompressor.
>
> > From 46fdbda7d2d9a9f4df0933341bcc467b3bdd03d6 Mon Sep 17 00:00:00 2001
> > From: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> > Date: Tue, 17 Jan 2012 11:29:39 +0530
> > Subject: [PATCH] mach-ux500: Do not override outer.inv_all
> >
> > outer.inv_all is currently being used only in kexec path.
> > Invalidating outer cache without disabling it is a big
> > nono, and so, remove the machine specific outer.inv_all
> > assuming that kexec does not call inv_all in its path.
>
> Please change this comment. Kexec doesn't do this anymore.
Done, patch below.
>From a8cf7e2f7b58c3ef860be58fa72cd0c51e2be487 Mon Sep 17 00:00:00 2001
From: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
Date: Tue, 17 Jan 2012 11:29:39 +0530
Subject: [PATCH] mach-ux500: Do not override outer.inv_all
Invalidating outer cache without disabling it is a big
nono, and so, remove the machine specific outer.inv_all
And at the same time it does not prevent us overriding
outer.disable as we do not have any such secure SMI to
handle the same while kexec disables the outer cache.
Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
---
arch/arm/mach-ux500/cache-l2x0.c | 48 +++++--------------------------------
1 files changed, 7 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-ux500/cache-l2x0.c b/arch/arm/mach-ux500/cache-l2x0.c
index 122ddde..45111c8 100644
--- a/arch/arm/mach-ux500/cache-l2x0.c
+++ b/arch/arm/mach-ux500/cache-l2x0.c
@@ -12,44 +12,6 @@
static void __iomem *l2x0_base;
-static inline void ux500_cache_wait(void __iomem *reg, unsigned long mask)
-{
- /* wait for the operation to complete */
- while (readl_relaxed(reg) & mask)
- cpu_relax();
-}
-
-static inline void ux500_cache_sync(void)
-{
- writel_relaxed(0, l2x0_base + L2X0_CACHE_SYNC);
- ux500_cache_wait(l2x0_base + L2X0_CACHE_SYNC, 1);
-}
-
-/*
- * The L2 cache cannot be turned off in the non-secure world.
- * Dummy until a secure service is in place.
- */
-static void ux500_l2x0_disable(void)
-{
-}
-
-/*
- * This is only called when doing a kexec, just after turning off the L2
- * and L1 cache, and it is surrounded by a spinlock in the generic version.
- * However, we're not really turning off the L2 cache right now and the
- * PL310 does not support exclusive accesses (used to implement the spinlock).
- * So, the invalidation needs to be done without the spinlock.
- */
-static void ux500_l2x0_inv_all(void)
-{
- uint32_t l2x0_way_mask = (1<<16) - 1; /* Bitmask of active ways */
-
- /* invalidate all ways */
- writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_INV_WAY);
- ux500_cache_wait(l2x0_base + L2X0_INV_WAY, l2x0_way_mask);
- ux500_cache_sync();
-}
-
static int __init ux500_l2x0_unlock(void)
{
int i;
@@ -85,9 +47,13 @@ static int __init ux500_l2x0_init(void)
/* 64KB way size, 8 way associativity, force WA */
l2x0_init(l2x0_base, 0x3e060000, 0xc0000fff);
- /* Override invalidate function */
- outer_cache.disable = ux500_l2x0_disable;
- outer_cache.inv_all = ux500_l2x0_inv_all;
+ /*
+ * We can't disable l2 as we are in non secure mode, currently
+ * this seems being called only during kexec path. So let's
+ * override outer.disable with nasty assignment until we have
+ * some SMI service available.
+ */
+ outer_cache.disable = NULL;
return 0;
}
--
1.7.4.3
^ permalink raw reply related
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Paul Mackerras @ 2012-01-17 11:31 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <6D049B19-8A91-445A-9FBB-E4851D4F586E@suse.de>
On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
> The thing I was getting at was not the map during the lifetime, but
> the map during registration. Currently we have:
>
> 1) Set VPA to x
> 2) Assign feature y to VPA
> 3) Use VPA
>
> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to
> be fast. 1 and 2 don't matter that much wrt performance.
>
> You are currently mapping the VPA at /, which gets you into this
> map/unmap mess trying to free the previous mapping. If you moved the
> map to step 2 and only stored the GPA at step 1, all map+unmap
> operations except for final unmaps would be in one spot, so you
> wouldn't need to construct this big complex state machine.
That might simplify things - I'll try it and see. The worry with
doing the map/pin at 2 is that if anything goes wrong we no longer
have the opportunity to return an error for the H_REGISTER_VPA call,
so I'll have to at least do some checking in 1, leading to possibly
more code overall.
Paul.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: PPC: Book3S HV: Make virtual processor area registration more robust
From: Paul Mackerras @ 2012-01-17 11:31 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev@ozlabs.org, kvm-ppc@vger.kernel.org
In-Reply-To: <6D049B19-8A91-445A-9FBB-E4851D4F586E@suse.de>
On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
> The thing I was getting at was not the map during the lifetime, but
> the map during registration. Currently we have:
>
> 1) Set VPA to x
> 2) Assign feature y to VPA
> 3) Use VPA
>
> 1 and 2 are the slow path, 3 occurs more frequently. So we want 3 to
> be fast. 1 and 2 don't matter that much wrt performance.
>
> You are currently mapping the VPA at /, which gets you into this
> map/unmap mess trying to free the previous mapping. If you moved the
> map to step 2 and only stored the GPA at step 1, all map+unmap
> operations except for final unmaps would be in one spot, so you
> wouldn't need to construct this big complex state machine.
That might simplify things - I'll try it and see. The worry with
doing the map/pin at 2 is that if anything goes wrong we no longer
have the opportunity to return an error for the H_REGISTER_VPA call,
so I'll have to at least do some checking in 1, leading to possibly
more code overall.
Paul.
^ permalink raw reply
* [RFC PATCH] ARM: new architecture for Energy Micro's EFM32 Cortex-M3 SoCs
From: Catalin Marinas @ 2012-01-17 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120116190637.GE32049@n2100.arm.linux.org.uk>
On Mon, Jan 16, 2012 at 07:06:37PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 16, 2012 at 06:10:02PM +0000, Catalin Marinas wrote:
> > On Mon, Jan 16, 2012 at 05:40:39PM +0000, Russell King - ARM Linux wrote:
> > > The VFP stuff - adding 'clean' which is kernel state to the _user_
> > > _exported_ VFP hardware structure is a bad idea. So this needlessly
> > > causes a variation in the kernels userspace API. Please find somewhere
> > > else to keep kernel internal state. (As that patch comes from Catalin,
> > > then that comment is directed to Catalin.)
> >
> > Are you sure we export vfp_hard_struct to user? That's a kernel-only
> > structure (and it's not by any means stable, given the number of
> > #ifdef's it has). I would also argue that 'clean' is a hardware state
> > (inferred from the exception return value).
>
> Actually, looking at arch/arm/kernel/ptrace.c, we only export the
> fpregs and fpscr, so this should be fine.
>
> Still, I don't see why we need this 'clean' state, when normal VFP
> doesn't need it. Maybe you could explain why it's necessary?
The FP support on the M profile is a bit different (in terms of control
registers) from the A/R profiles. The M profile has built-in knowledge
of the AAPCS for automatically preservation of certain registers during
exceptions and it can also do lazy saving of the S0-S15 FP registers.
In general the M processors are meant to be simpler to use without a
complex OS (especially if thread switching is done synchronously at SVC
time rather than during interrupts).
For example, when user space gets an exception, the M core saves R0-R3,
R12, LR, PC, xPSR on the user stack automatically. It also preserves
space for S0-S15 and FPSCR but does not save them (it remembers the
address though for lazy saving if new thread uses the FP). If another
thread tries to use the FP for the first time, it saves the old FP state
and initialises a new one for the current thread automatically. But once
a thread touched the FP, its state is no longer 'clean' and it is
automatically loaded (non-lazily) from the stack when switching to such
thread while saving the old one on the previous stack. When switching
between two threads that have never used the FP, the processor does not
do any FP state switching.
However, it does not save S16-S31 as the AAPCS specifies that they are
caller-saved. Linux needs to do this and it uses the 'clean' state to
detect whether a thread used the FP or not. The disadvantage is that if
a thread ever used FP, its state is always saved/restored at context
switch.
Of course, we can change all this and disable the hardware automatic
saving while implementing a pure software lazy switching solution using
the CPACR (there is no FPEXC). But at the time this was the simplest
implementation, given that Cortex-M3 doesn't even have an FP unit (it
came with Cortex-M4) and most M3 software around didn't touch the FP at
all.
BTW, if you are fine with trying to get the M support into mainline, I'm
happy to revisit the code (probably with Uwe's help given that I don't
have much time available).
--
Catalin
^ permalink raw reply
* Re: [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Srivatsa Vaddagiri @ 2012-01-17 11:33 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Jeremy Fitzhardinge, Raghavendra K T, linux-doc, Peter Zijlstra,
Jan Kiszka, Virtualization, Paul Mackerras, H. Peter Anvin,
Stefano Stabellini, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Avi Kivity, Rik van Riel, Konrad Rzeszutek Wilk,
Sasha Levin, Sedat Dilek, Thomas Gleixner, Greg Kroah-Hartman,
LKML
In-Reply-To: <20120117110210.GA17420@amt.cnet>
* Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 09:02:11]:
> > +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> > +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> > +{
> > + int cpu;
> > + int apicid;
> > +
> > + add_stats(RELEASED_SLOW, 1);
> > +
> > + for_each_cpu(cpu, &waiting_cpus) {
> > + const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
> > + if (ACCESS_ONCE(w->lock) == lock &&
> > + ACCESS_ONCE(w->want) == ticket) {
> > + add_stats(RELEASED_SLOW_KICKED, 1);
> > + apicid = per_cpu(x86_cpu_to_apicid, cpu);
> > + kvm_kick_cpu(apicid);
> > + break;
> > + }
> > + }
>
> What prevents a kick from being lost here, if say, the waiter is at
> local_irq_save in kvm_lock_spinning, before the lock/want assignments?
The waiter does check for lock becoming available before actually
sleeping:
+ /*
+ * check again make sure it didn't become free while
+ * we weren't looking.
+ */
+ if (ACCESS_ONCE(lock->tickets.head) == want) {
+ add_stats(TAKEN_SLOW_PICKUP, 1);
+ goto out;
+ }
- vatsa
^ permalink raw reply
* Re: [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Srivatsa Vaddagiri @ 2012-01-17 11:33 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Jeremy Fitzhardinge, Raghavendra K T, linux-doc, Peter Zijlstra,
Jan Kiszka, Virtualization, Paul Mackerras, H. Peter Anvin,
Stefano Stabellini, Xen, Dave Jiang, KVM, Glauber Costa, X86,
Ingo Molnar, Avi Kivity, Rik van Riel, Konrad Rzeszutek Wilk,
Sasha Levin, Sedat Dilek, Thomas Gleixner, Greg Kroah-Hartman,
LKML, Dave Hansen <dav
In-Reply-To: <20120117110210.GA17420@amt.cnet>
* Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 09:02:11]:
> > +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> > +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> > +{
> > + int cpu;
> > + int apicid;
> > +
> > + add_stats(RELEASED_SLOW, 1);
> > +
> > + for_each_cpu(cpu, &waiting_cpus) {
> > + const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
> > + if (ACCESS_ONCE(w->lock) == lock &&
> > + ACCESS_ONCE(w->want) == ticket) {
> > + add_stats(RELEASED_SLOW_KICKED, 1);
> > + apicid = per_cpu(x86_cpu_to_apicid, cpu);
> > + kvm_kick_cpu(apicid);
> > + break;
> > + }
> > + }
>
> What prevents a kick from being lost here, if say, the waiter is at
> local_irq_save in kvm_lock_spinning, before the lock/want assignments?
The waiter does check for lock becoming available before actually
sleeping:
+ /*
+ * check again make sure it didn't become free while
+ * we weren't looking.
+ */
+ if (ACCESS_ONCE(lock->tickets.head) == want) {
+ add_stats(TAKEN_SLOW_PICKUP, 1);
+ goto out;
+ }
- vatsa
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/6] qtest: add C version of test infrastructure
From: Stefan Hajnoczi @ 2012-01-17 11:33 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Kevin Wolf, Paolo Bonzini, qemu-devel, Stefan Hajnoczi
In-Reply-To: <1326479558-3016-3-git-send-email-aliguori@us.ibm.com>
On Fri, Jan 13, 2012 at 6:32 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> + pid = fork();
> + if (pid == 0) {
> + command = g_strdup_printf("%s "
> + "-qtest unix:%s,server,nowait "
> + "-qtest-log /dev/null "
> + "-pidfile %s "
> + "-machine accel=qtest "
> + "%s", qemu_binary, socket_path,
> + pid_file,
> + extra_args ?: "");
> +
> + ret = system(command);
qtest_init() launches qemu with a pidfile so that we can send SIGTERM
later. But we never get around to doing that if g_assert() fails - it
calls abort(3). The result is a run-away qemu process. I find the
qemu process consumes 100% in send_all() trying to write to the closed
qtest socket and SIGTERM no longer works since we're stuck in a tight
loop that never runs the event loop.
A simple solution is to handle SIGABRT in tests/libqtest.c and sent
SIGTERM to qemu when the test aborts. The downside is that this only
covers the abort(3) case - a segfault or other abnormal termination
would still leave the run-away qemu process.
I was wondering about a qemu-side solution where a closed qtest socket
means we need to shut down, but am not sure if the chardev code lets
us do that. (Really we want POLLHUP but we only seem to have
POLLIN/POLLOUT handlers.)
Thoughts?
Stefan
^ 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.