* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
To: Mark Brown
Cc: Grant Likely, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
>
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> > BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> >
> > /* find device_node and attach it */
> > - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > + regulator_desc->name);
> >
>
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?
Based on my understanding, 1:1 is just a special case of N:1. I
failed to see any problem having it work with registering each
regulator as a separate device.
> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
>
It should also work, but it will also change the API slightly for
non-dt users. I'm not sure it's something we want.
--
Regards,
Shawn
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Michael S. Tsirkin @ 2011-10-24 14:40 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <4EA56B99.2030201@siemens.com>
On Mon, Oct 24, 2011 at 03:43:53PM +0200, Jan Kiszka wrote:
> On 2011-10-24 15:11, Jan Kiszka wrote:
> > On 2011-10-24 14:43, Michael S. Tsirkin wrote:
> >> On Mon, Oct 24, 2011 at 02:06:08PM +0200, Jan Kiszka wrote:
> >>> On 2011-10-24 13:09, Avi Kivity wrote:
> >>>> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
> >>>>>>
> >>>>>> With the new feature it may be worthwhile, but I'd like to see the whole
> >>>>>> thing, with numbers attached.
> >>>>>
> >>>>> It's not a performance issue, it's a resource limitation issue: With the
> >>>>> new API we can stop worrying about user space device models consuming
> >>>>> limited IRQ routes of the KVM subsystem.
> >>>>>
> >>>>
> >>>> Only if those devices are in the same process (or have access to the
> >>>> vmfd). Interrupt routing together with irqfd allows you to disaggregate
> >>>> the device model. Instead of providing a competing implementation with
> >>>> new limitations, we need to remove the limitations of the old
> >>>> implementation.
> >>>
> >>> That depends on where we do the cut. Currently we let the IRQ source
> >>> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
> >>> cannot build correct MSI-X on top of the current irqfd model as we lack
> >>> the level information (for PBA emulation). *)
> >>
> >>
> >> I don't agree here. IMO PBA emulation would need to
> >> clear pending bits on interrupt status register read.
> >> So clearing pending bits could be done by ioctl from qemu
> >> while setting them would be done from irqfd.
> >
> > How should QEMU know if the reason for "pending" has been cleared at
> > device level if the device is outside the scope of QEMU? This model only
> > works for PV devices when you agree that spurious IRQs are OK.
> >
> >>
> >>> So we either need to
> >>> extend the existing model anyway -- or push per-vector masking back to
> >>> the IRQ source. In the latter case, it would be a very good chance to
> >>> give up on limited pseudo GSIs with static routes and do MSI messaging
> >>> from external IRQ sources to KVM directly.
> >>> But all those considerations affect different APIs than what I'm
> >>> proposing here. We will always need a way to inject MSIs in the context
> >>> of the VM as there will always be scenarios where devices are better run
> >>> in that very same context, for performance or simplicity or whatever
> >>> reasons. E.g., I could imagine that one would like to execute an
> >>> emulated IRQ remapper rather in the hypervisor context than
> >>> "over-microkernelized" in a separate process.
> >>>
> >>> Jan
> >>>
> >>> *) Realized this while trying to generalize the proposed MSI-X MMIO
> >>> acceleration for assigned devices to arbitrary device models, vhost-net,
> >>
> >> I'm actually working on a qemu patch to get pba emulation working correctly.
> >> I think it's doable with existing irqfd.
> >
> > irqfd has no notion of level. You can only communicate a rising edge and
> > then need a side channel for the state of the edge reason.
> >
> >>
> >>> and specifically vfio.
> >>
> >> Interesting. How would you clear the pseudo interrupt level?
> >
> > Ideally: not at all (for MSI). If we manage the mask at device level, we
> > only need to send the message if there is actually something to deliver
> > to the interrupt controller and masked input events would be lost on
> > real HW as well.
>
> This wouldn't work out nicely as well. We rather need a combined model:
>
> Devices need to maintain the PBA actively, i.e. set & clear them
> themselves and do not rely on the core here (with the core being either
> QEMU user space or an in-kernel MSI-X MMIO accelerator). The core only
> checks the PBA if it is about to deliver some message and refrains from
> doing so if the bit became 0 in the meantime (specifically during the
> masked period).
>
> For QEMU device models, that means no additional IOCTLs,
> just memory sharing of the PBA which is required anyway.
Sorry, I don't understand the above two paragraphs. Maybe I am
confused by terminology here. We really only need to check PBA when it's
read. Whether the message is delivered only depends on the mask bit.
>
> But that means QEMU-external device models need to gain at least basic
> MSI-X knowledge. And if they gain this awareness, they could also use it
> to send full-blown messages directly (e.g. device-id/vector tuples)
> instead of encoding them into finite GSI numbers. But that's an add-on
> topic.
>
> Moreover, we still need a corresponding side channel for line-base
> interrupts.
>
> Jan
Agree on all points with the above.
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
^ permalink raw reply
* cpufreq for at91? device tree files
From: Robert Schwebel @ 2011-10-24 14:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Albin,
I've seen here [1] that you have worked on cpufreq for AT91 back in
2009, but until now it doesn't seem to have hit mainline. Did you
experience problems with the cpufreq code at that time, or didn't you
simplay have the time to continue?
We may have an opportunity to help soon, but I'd like to make sure that
you didn't experience fundamental issues yet :)
rsc
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2009-August/000145.html
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: problem with intel 5300
From: Guy, Wey-Yi @ 2011-10-24 13:45 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <alpine.DEB.2.00.1110240746530.11931@uplift.swm.pp.se>
On Sun, 2011-10-23 at 22:48 -0700, Mikael Abrahamsson wrote:
> On Tue, 20 Sep 2011, Mikael Abrahamsson wrote:
>
> Hi,
>
> just wanted to say that I have now upgraded to ubuntu 11.10 with its 3.0.x
> kernel, and I'm now running it with .11n enabled and it's been ok for 20
> hours. So whatever problem there was in 2.6.38, it seems to have been
> fixed in 3.0.x, or at least it's working much better.
>
very happy to hear that, thank you very much for reporting
Wey
^ permalink raw reply
* [PATCH v2] ARM: gic: fix irq_alloc_descs handling for sparse irq
From: Rob Herring @ 2011-10-24 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319314808-27007-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Commit "ARM: gic: add irq_domain support" (2071a2a4b8ed5292) broke SPARSE_IRQ
on platforms with GIC. When SPARSE_IRQ is enabled, all NR_IRQS or
mach_desc->nr_irqs will be allocated by arch_probe_nr_irqs(). This caused
irq_alloc_descs to allocate irq_descs after the pre-allocated space.
Make irq_alloc_descs search for an exact irq range and assume it has
been pre-allocated on failure. For DT probing dynamic allocation is used.
DT enabled platforms should set their nr_irqs to NR_IRQ_LEGACY and have all
irq_chips allocate their irq_descs with irq_alloc_descs if SPARSE_IRQ is
enabled.
gic_init irq_start param is changed to be signed with negative meaning do
dynamic Linux irq assigment.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
v2:
- make irq_start signed
arch/arm/common/gic.c | 15 +++++++++++----
arch/arm/include/asm/hardware/gic.h | 2 +-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 65cf39d..e9debd4 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -24,6 +24,7 @@
*/
#include <linux/init.h>
#include <linux/kernel.h>
+#include <linux/err.h>
#include <linux/list.h>
#include <linux/smp.h>
#include <linux/cpu_pm.h>
@@ -550,7 +551,7 @@ const struct irq_domain_ops gic_irq_domain_ops = {
#endif
};
-void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
+void __init gic_init(unsigned int gic_nr, int irq_start,
void __iomem *dist_base, void __iomem *cpu_base)
{
struct gic_chip_data *gic;
@@ -571,7 +572,8 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
if (gic_nr == 0) {
gic_cpu_base_addr = cpu_base;
domain->hwirq_base = 16;
- irq_start = (irq_start & ~31) + 16;
+ if (irq_start > 0)
+ irq_start = (irq_start & ~31) + 16;
} else
domain->hwirq_base = 32;
@@ -586,8 +588,13 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
gic->gic_irqs = gic_irqs;
domain->nr_irq = gic_irqs - domain->hwirq_base;
- domain->irq_base = irq_alloc_descs(-1, irq_start, domain->nr_irq,
+ domain->irq_base = irq_alloc_descs(irq_start, 16, domain->nr_irq,
numa_node_id());
+ if (IS_ERR_VALUE(domain->irq_base)) {
+ WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+ irq_start);
+ domain->irq_base = irq_start;
+ }
domain->priv = gic;
domain->ops = &gic_irq_domain_ops;
irq_domain_add(domain);
@@ -657,7 +664,7 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
domain->of_node = of_node_get(node);
- gic_init(gic_cnt, 16, dist_base, cpu_base);
+ gic_init(gic_cnt, -1, dist_base, cpu_base);
if (parent) {
irq = irq_of_parse_and_map(node, 0);
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 1a776a1..0ea4122 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -38,7 +38,7 @@
extern void __iomem *gic_cpu_base_addr;
extern struct irq_chip gic_arch_extn;
-void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+void gic_init(unsigned int, int, void __iomem *, void __iomem *);
int gic_of_init(struct device_node *node, struct device_node *parent);
void gic_secondary_init(unsigned int);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Grant Likely @ 2011-10-24 14:34 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Rob Herring, devicetree-discuss, Jean-Christophe PLAGNIOL-VILLARD,
linux-kernel, linux-arm-kernel
In-Reply-To: <4E9D4FD5.8080802@atmel.com>
On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
> On 10/07/2011 02:56 PM, Nicolas Ferre :
> > On 10/05/2011 03:00 PM, Rob Herring :
> >> Nicolas,
> >>
> >> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
> >>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> >>> The Evaluation Kit at91sam9m10g45ek includes it.
> >>> This first basic support will be populated as drivers and boards will be
> >>> converted to device tree.
> >>> Contains serial, dma and interrupt controllers.
> >>>
> >>> The generic board file still takes advantage of platform data for early serial
> >>> init. As we need a storage media and the NAND flash driver is not converted to
> >>> DT yet, we keep old initialization for it.
> >>>
> >>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> [..]
>
> >>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
> >>> new file mode 100644
> >>> index 0000000..7bcb9a9
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-at91/board-dt.c
> >>> @@ -0,0 +1,122 @@
> >>> +/*
> >>> + * Setup code for AT91SAM Evaluation Kits with Device Tree support
> >>> + *
> >>> + * Covers: * AT91SAM9G45-EKES board
> >>> + * * AT91SAM9M10-EKES board
> >>> + * * AT91SAM9M10G45-EK board
> >>> + *
> >>> + * Copyright (C) 2011 Atmel,
> >>> + * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
> >>> + *
> >>> + * Licensed under GPLv2 or later.
> >>> + */
> >>> +
> >>> +#include <linux/types.h>
> >>> +#include <linux/init.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/irqdomain.h>
> >>> +#include <linux/of_irq.h>
> >>> +#include <linux/of_platform.h>
> >>> +
> >>> +#include <mach/hardware.h>
> >>> +#include <mach/board.h>
> >>> +#include <mach/gpio.h>
> >>> +#include <mach/system_rev.h>
> >>> +#include <mach/at91sam9_smc.h>
> >>> +
> >>> +#include <asm/setup.h>
> >>> +#include <asm/irq.h>
> >>> +#include <asm/mach/arch.h>
> >>> +#include <asm/mach/map.h>
> >>> +#include <asm/mach/irq.h>
> >>> +
> >>> +#include "sam9_smc.h"
> >>> +#include "generic.h"
>
> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>
> +/*
> + * Lookup table for attaching a specific name and platform_data pointer to
> + * devices as they get created by of_platform_populate(). Ideally this table
> + * would not exist, but the current clock implementation depends on some devices
> + * having a specific name.
> + /
> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
> + / at91sam9260/ at91sam9g20 /
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
> + / at91sam9g45*/
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
> + { /* sentinel */ }
> +};
>
> With a change here:
> of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>
> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
yes.
g.
^ permalink raw reply
* [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Grant Likely @ 2011-10-24 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E9D4FD5.8080802@atmel.com>
On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
> On 10/07/2011 02:56 PM, Nicolas Ferre :
> > On 10/05/2011 03:00 PM, Rob Herring :
> >> Nicolas,
> >>
> >> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
> >>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> >>> The Evaluation Kit at91sam9m10g45ek includes it.
> >>> This first basic support will be populated as drivers and boards will be
> >>> converted to device tree.
> >>> Contains serial, dma and interrupt controllers.
> >>>
> >>> The generic board file still takes advantage of platform data for early serial
> >>> init. As we need a storage media and the NAND flash driver is not converted to
> >>> DT yet, we keep old initialization for it.
> >>>
> >>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> [..]
>
> >>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
> >>> new file mode 100644
> >>> index 0000000..7bcb9a9
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-at91/board-dt.c
> >>> @@ -0,0 +1,122 @@
> >>> +/*
> >>> + * Setup code for AT91SAM Evaluation Kits with Device Tree support
> >>> + *
> >>> + * Covers: * AT91SAM9G45-EKES board
> >>> + * * AT91SAM9M10-EKES board
> >>> + * * AT91SAM9M10G45-EK board
> >>> + *
> >>> + * Copyright (C) 2011 Atmel,
> >>> + * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
> >>> + *
> >>> + * Licensed under GPLv2 or later.
> >>> + */
> >>> +
> >>> +#include <linux/types.h>
> >>> +#include <linux/init.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/irqdomain.h>
> >>> +#include <linux/of_irq.h>
> >>> +#include <linux/of_platform.h>
> >>> +
> >>> +#include <mach/hardware.h>
> >>> +#include <mach/board.h>
> >>> +#include <mach/gpio.h>
> >>> +#include <mach/system_rev.h>
> >>> +#include <mach/at91sam9_smc.h>
> >>> +
> >>> +#include <asm/setup.h>
> >>> +#include <asm/irq.h>
> >>> +#include <asm/mach/arch.h>
> >>> +#include <asm/mach/map.h>
> >>> +#include <asm/mach/irq.h>
> >>> +
> >>> +#include "sam9_smc.h"
> >>> +#include "generic.h"
>
> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>
> +/*
> + * Lookup table for attaching a specific name and platform_data pointer to
> + * devices as they get created by of_platform_populate(). Ideally this table
> + * would not exist, but the current clock implementation depends on some devices
> + * having a specific name.
> + /
> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
> + / at91sam9260/ at91sam9g20 /
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
> + / at91sam9g45*/
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
> + { /* sentinel */ }
> +};
>
> With a change here:
> of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>
> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
yes.
g.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 09/10] Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
From: Anthony PERARD @ 2011-10-24 14:33 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201146210.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 12:01, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> + /* disable MSI/MSI-X and MSI-INTx translation */
>> + if (s->msi) {
>> + pt_msi_disable(s);
>> + }
>> + if (s->msix) {
>> + pt_msix_disable(s);
>> + }
>
> these msi functions are not implemented yet
Ok, I will remove all msi related call and define, and move them to
the next patch.
--
Anthony PERARD
^ permalink raw reply
* Re: [PATCH V2 09/10] Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
From: Anthony PERARD @ 2011-10-24 14:33 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201146210.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 12:01, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> + /* disable MSI/MSI-X and MSI-INTx translation */
>> + if (s->msi) {
>> + pt_msi_disable(s);
>> + }
>> + if (s->msix) {
>> + pt_msix_disable(s);
>> + }
>
> these msi functions are not implemented yet
Ok, I will remove all msi related call and define, and move them to
the next patch.
--
Anthony PERARD
^ permalink raw reply
* Re: [PATCH] TTY: pty, fix pty counting
From: Ilya Zykov @ 2011-10-24 14:33 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Greg Kroah-Hartman, Alan Cox, linux-kernel, ilya
In-Reply-To: <4EA563E6.3040205@suse.cz>
Jiri Slaby wrote:
> On 10/23/2011 11:01 PM, Ilya Zykov wrote:
>> New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
>
> Although it will work, as ptms are not allowed to be reopen, it doesn't
> look correct. We should decrement the count in ->remove, because we are
> incrementing in install.
>
> Now, when I understand ptm+devpts layer a bit more, instead of the
> current hackish approach introduced by 24d406a6b (TTY: pty, fix pty
> counting), I think we may introduce a ->remove hook specific to ptms. In
> that one we could decrement the count and don't bother with the
> pty_count macros anymore. Right?
>
> BTW you cannot remove ->remove hook of pty layer. It would cause an OOPS
> because driver->ttys is not allocated for ptys.
>
>> diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
>> --- a/drivers/tty/pty.c 2011-05-19 08:06:34.000000000 +0400
>> +++ b/drivers/tty/pty.c 2011-10-23 18:01:20.000000000 +0400
>> @@ -36,13 +36,15 @@
>> static struct tty_driver *ptm_driver;
>> static struct tty_driver *pts_driver;
>> #endif
>> +static int pty_count;
>>
>> static void pty_close(struct tty_struct *tty, struct file *filp)
>> {
>> BUG_ON(!tty);
>> - if (tty->driver->subtype == PTY_TYPE_MASTER)
>> + if (tty->driver->subtype == PTY_TYPE_MASTER) {
>> WARN_ON(tty->count > 1);
>> - else {
>> + pty_count--;
>> + } else {
>> if (tty->count > 2)
>> return;
>> }
>> @@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
>> int pty_limit = NR_UNIX98_PTY_DEFAULT;
>> static int pty_limit_min;
>> static int pty_limit_max = NR_UNIX98_PTY_MAX;
>> -static int pty_count;
>>
>> static struct cdev ptmx_cdev;
>>
>> @@ -599,15 +600,9 @@ free_mem_out:
>> return -ENOMEM;
>> }
>>
>> -static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
>> -{
>> - pty_count--;
>> -}
>> -
>> static const struct tty_operations ptm_unix98_ops = {
>> .lookup = ptm_unix98_lookup,
>> .install = pty_unix98_install,
>> - .remove = pty_unix98_remove,
>> .open = pty_open,
>> .close = pty_close,
>> .write = pty_write,
>> @@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
>> static const struct tty_operations pty_unix98_ops = {
>> .lookup = pts_unix98_lookup,
>> .install = pty_unix98_install,
>> - .remove = pty_unix98_remove,
>> .open = pty_open,
>> .close = pty_close,
>> .write = pty_write,
>
> thanks,
We can increment pty_count in open()
About BTW(->remove) You say in 24d406a6b:
However tty_shutdown() is called from queue_release_one_tty() only if
tty_operations->shutdown is NULL. But for pty, it is not.
pty_unix98_shutdown() is used there as ->shutdown.
So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never
called. This results in invalid pty_count. I.e. what can be seen in
/proc/sys/kernel/pty/nr.
^ permalink raw reply
* [PATCH 2/2] mmc: mmci: add constraints on alignment for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel
Cc: Russell King, Ulf Hansson, Lee Jones, Per Forlin,
Stefan Nilsson XK
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>
From: Per Forlin <per.forlin@stericsson.com>
Buffers must be 4 bytes aligned due to restrictions that
the PL18x FIFO accesses must be done in a 4-byte aligned manner.
Enable DMA_REQCTL for SDIO to support write of not 32 bytes aligned
sg element lengths. In PIO mode any buffer length can be handled
as long as the buffer address is 4 byte aligned.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
drivers/mmc/host/mmci.c | 55 +++++++++++++++++++++++++++++++++++++++-------
drivers/mmc/host/mmci.h | 7 ++++++
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a6387b5..1a46084 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -45,6 +45,7 @@ static unsigned int fmax = 515633;
* struct variant_data - MMCI variant-specific quirks
* @clkreg: default value for MCICLOCK register
* @clkreg_enable: enable value for MMCICLOCK register
+ * @dma_sdio_req_ctrl: enable value for DMAREQCTL register for SDIO write
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
@@ -58,6 +59,7 @@ static unsigned int fmax = 515633;
struct variant_data {
unsigned int clkreg;
unsigned int clkreg_enable;
+ unsigned int dma_sdio_req_ctrl;
unsigned int datalength_bits;
unsigned int fifosize;
unsigned int fifohalfsize;
@@ -92,6 +94,7 @@ static struct variant_data variant_ux500 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .dma_sdio_req_ctrl = MCI_ST_DPSM_DMAREQCTL,
.datalength_bits = 24,
.sdio = true,
.st_clkdiv = true,
@@ -102,6 +105,7 @@ static struct variant_data variant_ux500v2 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .dma_sdio_req_ctrl = MCI_ST_DPSM_DMAREQCTL,
.datalength_bits = 24,
.sdio = true,
.st_clkdiv = true,
@@ -110,6 +114,31 @@ static struct variant_data variant_ux500v2 = {
};
/*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ if (!host->variant->non_power_of_2_blksize &&
+ !is_power_of_2(data->blksz)) {
+ dev_err(mmc_dev(host->mmc),
+ "unsupported block size (%d bytes)\n", data->blksz);
+ return -EINVAL;
+ }
+
+ if (data->sg->offset & 3) {
+ dev_err(mmc_dev(host->mmc),
+ "unsupported alginment (0x%x)\n", data->sg->offset);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
* This must be called with host->lock held
*/
static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
@@ -401,8 +430,12 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
if (!chan)
return -EINVAL;
- /* If less than or equal to the fifo size, don't bother with DMA */
- if (data->blksz * data->blocks <= variant->fifosize)
+ /*
+ * If less than or equal to the fifo size, don't bother with DMA
+ * SDIO transfers may not be 4 bytes aligned, fall back to PIO
+ */
+ if (data->blksz * data->blocks <= variant->fifosize ||
+ (data->blksz * data->blocks) & 3)
return -EINVAL;
device = chan->device;
@@ -437,6 +470,7 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
{
int ret;
struct mmc_data *data = host->data;
+ struct variant_data *variant = host->variant;
ret = mmci_dma_prep_data(host, host->data, NULL);
if (ret)
@@ -451,6 +485,11 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
datactrl |= MCI_DPSM_DMAENABLE;
+ /* Some hardware versions need special flags for SDIO DMA write */
+ if (variant->sdio && host->mmc->card && mmc_card_sdio(host->mmc->card)
+ && (data->flags & MMC_DATA_WRITE))
+ datactrl |= variant->dma_sdio_req_ctrl;
+
/* Trigger the DMA transfer */
writel(datactrl, host->base + MMCIDATACTRL);
@@ -495,6 +534,9 @@ static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
if (!data)
return;
+ if (mmci_validate_data(host, mrq->data))
+ return;
+
if (data->host_cookie) {
data->host_cookie = 0;
return;
@@ -976,17 +1018,12 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct mmci_host *host = mmc_priv(mmc);
- struct variant_data *variant = host->variant;
unsigned long flags;
WARN_ON(host->mrq != NULL);
- if (mrq->data &&
- !variant->non_power_of_2_blksize &&
- !is_power_of_2(mrq->data->blksz)) {
- dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
- mrq->data->blksz);
- mrq->cmd->error = -EINVAL;
+ mrq->cmd->error = mmci_validate_data(host, mrq->data);
+ if (mrq->cmd->error) {
mmc_request_done(mmc, mrq);
return;
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 79e4143..d2737f0 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -70,6 +70,13 @@
#define MCI_ST_DPSM_RWMOD (1 << 10)
#define MCI_ST_DPSM_SDIOEN (1 << 11)
/* Control register extensions in the ST Micro Ux500 versions */
+/*
+ * DMA request control is required for write
+ * if transfer size is not 32 byte aligned.
+ * DMA request control is also needed if the total
+ * transfer size is 32 byte aligned but any of the
+ * sg element lengths are not aligned with 32 byte.
+ */
#define MCI_ST_DPSM_DMAREQCTL (1 << 12)
#define MCI_ST_DPSM_DBOOTMODEEN (1 << 13)
#define MCI_ST_DPSM_BUSYMODE (1 << 14)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-mmc, linux-arm-kernel
Cc: Russell King, Ulf Hansson, Lee Jones, Stefan Nilsson XK
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>
From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
For the ux500v2 variant of the PL18x block, non power of two block
sizes are supported. This will make it possible to decrease data
overhead for SDIO transfers.
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
---
drivers/mmc/host/mmci.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 50b5f99..a6387b5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -53,6 +53,7 @@ static unsigned int fmax = 515633;
* @sdio: variant supports SDIO
* @st_clkdiv: true if using a ST-specific clock divider algorithm
* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl register
+ * @non_power_of_2_blksize: true if block sizes can be other than power of two
*/
struct variant_data {
unsigned int clkreg;
@@ -63,6 +64,7 @@ struct variant_data {
bool sdio;
bool st_clkdiv;
bool blksz_datactrl16;
+ bool non_power_of_2_blksize;
};
static struct variant_data variant_arm = {
@@ -104,6 +106,7 @@ static struct variant_data variant_ux500v2 = {
.sdio = true,
.st_clkdiv = true,
.blksz_datactrl16 = true,
+ .non_power_of_2_blksize = true,
};
/*
@@ -594,7 +597,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
writel(host->size, base + MMCIDATALENGTH);
blksz_bits = ffs(data->blksz) - 1;
- BUG_ON(1 << blksz_bits != data->blksz);
if (variant->blksz_datactrl16)
datactrl = MCI_DPSM_ENABLE | (data->blksz << 16);
@@ -974,11 +976,14 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct mmci_host *host = mmc_priv(mmc);
+ struct variant_data *variant = host->variant;
unsigned long flags;
WARN_ON(host->mrq != NULL);
- if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
+ if (mrq->data &&
+ !variant->non_power_of_2_blksize &&
+ !is_power_of_2(mrq->data->blksz)) {
dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
mrq->data->blksz);
mrq->cmd->error = -EINVAL;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] bnx2x: Adding FW 7.0.29.0
From: David Woodhouse @ 2011-10-24 14:33 UTC (permalink / raw)
To: dmitry; +Cc: ben@decadent.org.uk, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <1319464676.6155.3.camel@lb-tlvb-dmitry>
[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]
On Mon, 2011-10-24 at 15:57 +0200, Dmitry Kravkov wrote:
> On Mon, 2011-10-17 at 09:12 -0700, Dmitry Kravkov wrote:
> > On Mon, 2011-10-17 at 07:00 -0700, Dmitry Kravkov wrote:
> > > Includes fixes for the following issues:
> > > 1. (iSCSI) Arrival of un-solicited ASYNC message causes
> > > firmware to abort the connection with RST.
> > > 2. (FCoE) There is a probability that truncated FCoE packet on
> > > RX path won't get detected which might lead to FW assert.
> > > 3. (iSCSI) Arrival of target-initiated NOP-IN during intense
> > > ISCSI traffic might lead to FW assert.
> > > 4. (iSCSI) Chip hangs when in case of retransmission not aligned
> > > to 4-bytes from the beginning of iSCSI PDU.
> > > 5. (FCoE) Arrival of packets beyond task IO size can lead to crash.
> > >
>
> David, do you have estimation to handle the request? We have pending
> patch for net-next. Thanks.
Pushed to git.infradead.org; thanks. I'll work on getting the tree back
onto git.kernel.org now I'm sitting at a table with the admin...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
* [PATCH 2/2] mmc: mmci: add constraints on alignment for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>
From: Per Forlin <per.forlin@stericsson.com>
Buffers must be 4 bytes aligned due to restrictions that
the PL18x FIFO accesses must be done in a 4-byte aligned manner.
Enable DMA_REQCTL for SDIO to support write of not 32 bytes aligned
sg element lengths. In PIO mode any buffer length can be handled
as long as the buffer address is 4 byte aligned.
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
drivers/mmc/host/mmci.c | 55 +++++++++++++++++++++++++++++++++++++++-------
drivers/mmc/host/mmci.h | 7 ++++++
2 files changed, 53 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a6387b5..1a46084 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -45,6 +45,7 @@ static unsigned int fmax = 515633;
* struct variant_data - MMCI variant-specific quirks
* @clkreg: default value for MCICLOCK register
* @clkreg_enable: enable value for MMCICLOCK register
+ * @dma_sdio_req_ctrl: enable value for DMAREQCTL register for SDIO write
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
@@ -58,6 +59,7 @@ static unsigned int fmax = 515633;
struct variant_data {
unsigned int clkreg;
unsigned int clkreg_enable;
+ unsigned int dma_sdio_req_ctrl;
unsigned int datalength_bits;
unsigned int fifosize;
unsigned int fifohalfsize;
@@ -92,6 +94,7 @@ static struct variant_data variant_ux500 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .dma_sdio_req_ctrl = MCI_ST_DPSM_DMAREQCTL,
.datalength_bits = 24,
.sdio = true,
.st_clkdiv = true,
@@ -102,6 +105,7 @@ static struct variant_data variant_ux500v2 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .dma_sdio_req_ctrl = MCI_ST_DPSM_DMAREQCTL,
.datalength_bits = 24,
.sdio = true,
.st_clkdiv = true,
@@ -110,6 +114,31 @@ static struct variant_data variant_ux500v2 = {
};
/*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ if (!host->variant->non_power_of_2_blksize &&
+ !is_power_of_2(data->blksz)) {
+ dev_err(mmc_dev(host->mmc),
+ "unsupported block size (%d bytes)\n", data->blksz);
+ return -EINVAL;
+ }
+
+ if (data->sg->offset & 3) {
+ dev_err(mmc_dev(host->mmc),
+ "unsupported alginment (0x%x)\n", data->sg->offset);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/*
* This must be called with host->lock held
*/
static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
@@ -401,8 +430,12 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
if (!chan)
return -EINVAL;
- /* If less than or equal to the fifo size, don't bother with DMA */
- if (data->blksz * data->blocks <= variant->fifosize)
+ /*
+ * If less than or equal to the fifo size, don't bother with DMA
+ * SDIO transfers may not be 4 bytes aligned, fall back to PIO
+ */
+ if (data->blksz * data->blocks <= variant->fifosize ||
+ (data->blksz * data->blocks) & 3)
return -EINVAL;
device = chan->device;
@@ -437,6 +470,7 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
{
int ret;
struct mmc_data *data = host->data;
+ struct variant_data *variant = host->variant;
ret = mmci_dma_prep_data(host, host->data, NULL);
if (ret)
@@ -451,6 +485,11 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
datactrl |= MCI_DPSM_DMAENABLE;
+ /* Some hardware versions need special flags for SDIO DMA write */
+ if (variant->sdio && host->mmc->card && mmc_card_sdio(host->mmc->card)
+ && (data->flags & MMC_DATA_WRITE))
+ datactrl |= variant->dma_sdio_req_ctrl;
+
/* Trigger the DMA transfer */
writel(datactrl, host->base + MMCIDATACTRL);
@@ -495,6 +534,9 @@ static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
if (!data)
return;
+ if (mmci_validate_data(host, mrq->data))
+ return;
+
if (data->host_cookie) {
data->host_cookie = 0;
return;
@@ -976,17 +1018,12 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct mmci_host *host = mmc_priv(mmc);
- struct variant_data *variant = host->variant;
unsigned long flags;
WARN_ON(host->mrq != NULL);
- if (mrq->data &&
- !variant->non_power_of_2_blksize &&
- !is_power_of_2(mrq->data->blksz)) {
- dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
- mrq->data->blksz);
- mrq->cmd->error = -EINVAL;
+ mrq->cmd->error = mmci_validate_data(host, mrq->data);
+ if (mrq->cmd->error) {
mmc_request_done(mmc, mrq);
return;
}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 79e4143..d2737f0 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -70,6 +70,13 @@
#define MCI_ST_DPSM_RWMOD (1 << 10)
#define MCI_ST_DPSM_SDIOEN (1 << 11)
/* Control register extensions in the ST Micro Ux500 versions */
+/*
+ * DMA request control is required for write
+ * if transfer size is not 32 byte aligned.
+ * DMA request control is also needed if the total
+ * transfer size is 32 byte aligned but any of the
+ * sg element lengths are not aligned with 32 byte.
+ */
#define MCI_ST_DPSM_DMAREQCTL (1 << 12)
#define MCI_ST_DPSM_DBOOTMODEEN (1 << 13)
#define MCI_ST_DPSM_BUSYMODE (1 << 14)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>
From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
For the ux500v2 variant of the PL18x block, non power of two block
sizes are supported. This will make it possible to decrease data
overhead for SDIO transfers.
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
---
drivers/mmc/host/mmci.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 50b5f99..a6387b5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -53,6 +53,7 @@ static unsigned int fmax = 515633;
* @sdio: variant supports SDIO
* @st_clkdiv: true if using a ST-specific clock divider algorithm
* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl register
+ * @non_power_of_2_blksize: true if block sizes can be other than power of two
*/
struct variant_data {
unsigned int clkreg;
@@ -63,6 +64,7 @@ struct variant_data {
bool sdio;
bool st_clkdiv;
bool blksz_datactrl16;
+ bool non_power_of_2_blksize;
};
static struct variant_data variant_arm = {
@@ -104,6 +106,7 @@ static struct variant_data variant_ux500v2 = {
.sdio = true,
.st_clkdiv = true,
.blksz_datactrl16 = true,
+ .non_power_of_2_blksize = true,
};
/*
@@ -594,7 +597,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
writel(host->size, base + MMCIDATALENGTH);
blksz_bits = ffs(data->blksz) - 1;
- BUG_ON(1 << blksz_bits != data->blksz);
if (variant->blksz_datactrl16)
datactrl = MCI_DPSM_ENABLE | (data->blksz << 16);
@@ -974,11 +976,14 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct mmci_host *host = mmc_priv(mmc);
+ struct variant_data *variant = host->variant;
unsigned long flags;
WARN_ON(host->mrq != NULL);
- if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
+ if (mrq->data &&
+ !variant->non_power_of_2_blksize &&
+ !is_power_of_2(mrq->data->blksz)) {
dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
mrq->data->blksz);
mrq->cmd->error = -EINVAL;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] mmc: mmci: Improvements for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-arm-kernel
For the ux500v2 variant of the PL18x block, non power of two block
sizes are now supported.
In addition constraints on buffer alignments is needed since access to the
PL18x FIFO must be done on a 4-byte aligned manner. Moreover to be able to
use DMA for buffers with not 32 bytes aligned sg element lengths, DMAREQCTL
must enabled.
Per Forlin (1):
mmc: mmci: add constraints on alignment for SDIO
Stefan Nilsson XK (1):
mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
drivers/mmc/host/mmci.c | 56 +++++++++++++++++++++++++++++++++++++++++------
drivers/mmc/host/mmci.h | 7 ++++++
2 files changed, 56 insertions(+), 7 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH] Shrink thread_info a bit
From: Tim Bird @ 2011-10-24 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024124818.GA17693@n2100.arm.linux.org.uk>
On 10/24/2011 5:48 AM, Russell King - ARM Linux wrote:
> Thread info comes in on Versatile Express at 752 bytes in size, which
> is quite large. Of this, the crunch state is 184 bytes, which is only
> used on Cirrus Logic devices.
>
> It is wasteful to have this in every kernel when Cirrus Logic CPUs
> are not that widely used. So make this conditional.
>
> Signed-off-by: Russell King<rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/include/asm/thread_info.h | 2 ++
> arch/arm/kernel/asm-offsets.c | 2 ++
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 7b5cc8d..a030be7 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -59,7 +59,9 @@ struct thread_info {
> __u32 syscall; /* syscall number */
> __u8 used_cp[16]; /* thread used copro */
> unsigned long tp_value;
> +#ifdef CONFIG_CRUNCH
> struct crunch_state crunchstate;
> +#endif
> union fp_state fpstate __attribute__((aligned(8)));
> union vfp_state vfpstate;
> #ifdef CONFIG_ARM_THUMBEE
>
>
Since the asm-offsets.h code already has the offset definitions under
#ifdef CONFIG_CRUNCH, this qualifies as a code consistency cleanup,
as well as a memory savings.
I looked at this, and can find no code outside of #ifdef CONFIG_CRUNCH
that references this - so FWIW
Reviewed-by Tim Bird <tim.bird@am.sony.com>
-- Tim
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
To: Baruch Siach
Cc: robherring2, grant.likely, devicetree-discuss, plagnioj,
linux-kernel, linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>
On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
>
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>
> [snip]
>
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
>
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
> appropriate name?
For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.
>> + /* Maintainer: Atmel */
>> + .timer = &at91sam926x_timer,
>> + .map_io = at91_map_io,
>> + .init_early = ek_init_early,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91_dt_board_compat,
>> +MACHINE_END
>
> baruch
Thanks for your review,
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 2/2] i2c/nomadik: runtime PM support
From: Magnus Damm @ 2011-10-24 14:32 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonas Aaberg, Linus Walleij, Ben Dooks,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Rafael J. Wysocki,
Russell King - ARM Linux
In-Reply-To: <CACRpkdZmifrV3o59JrWx2Z6DAqHO80W4d=7NJ6OipAOrbazgXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 21, 2011 at 8:19 PM, Linus Walleij <linus.walleij-QSEj5FYQhm5QFI55V6+gNQ@public.gmane.orgg> wrote:
> On Thu, Oct 20, 2011 at 6:44 PM, Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Oct 21, 2011 at 1:23 AM, Linus Walleij
>> <linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org> wrote:
>>> From: Jonas Aaberg <jonas.aberg-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> ...
>>> +static int nmk_i2c_runtime_suspend(struct device *dev)
>>> +{
>>> + clk_disable(nmk_i2c->clk);
> (...)
>>> +}
>>> +
>>> +static int nmk_i2c_runtime_resume(struct device *dev)
>>> +{
> (...)
>>> + clk_enable(nmk_i2c->clk);
>>> + return 0;
>>> +}
>>> +
>>
>> Hm, on SH-Mobile ARM we never control any clocks from the driver
>> runtime pm callbacks.
>
> OK so you're using pm_clk_add_notifier() and the standard
> implementation from drivers/base/power/clock_ops.c?
We are using the standard implementation together with
pm_clk_add_notifier() to point out our platform_bus_notifier in
arch/arm/mach-shmobile/pm_runtime.c. My intention with the comment
above was not to so focused on the notifier, more that soc-specific
code can use pm_clk_add() to add multiple clocks to a certain struct
device.
>> (...) In our case the runtime suspend callbacks are only invoked
>> when all the devices in the power domain happen to have a zero runtime
>> pm use count. So if you control your clocks from those callbacks then
>> they will be mostly left on which may not be what you want.
>
> We have power domains implemented as well, but currently these
> handle power domain regulators and pin control only,
> not clocking.
>
> They are registered to the platform and amba bus using
> bus_register_notifier() rather than pm_*() notifiers though,
> but we listen to the same events
> BUS_NOTIFY_[BIND|UNBOUND]_DRIVER
I probably mentioned this earlier, but on SH-Mobile ARM drivers we
control both clocks and power domains using the same
pm_runtime_get()/put() functions. The clocks are turned off
immediately, but the power domains will only be turned off when all
included devices are idle according to Runtime PM. At this
all-devices-in-one-power-domain-are-idle time we actually invoke the
->runtime_suspend() callbacks. This is handled by generic code and can
easily be used by anyone.
> So your suggestion is to move clock control for all
> platform devices to the overarching platform code where
> we also handle the power domain regulators and pin
> control?
No, I wouldn't go that far to suggest that. =) I'm just saying that
using Runtime PM for clock and power domain control on a per-device
granularity in the driver is working well for us. Especially since we
can let the soc-code associate multiple clocks to each struct device
with pm_clk_add().
I'm soon going to hack on trying to tie in voltage control in the
soc-specific Runtime PM code. Right now the voltage is static but we
gate off various parts of the SoC. After prototyping with the voltage
control code then perhaps it would be easier for me to recommend you
something. =)
The reason why I replied to the email initially was to point out that
your way of using Runtime PM seems quite different from our way. It
looked like this driver wanted to have the ->runtime_suspend()
callback executed as soon as possible to control the clock. So if you
intend to execute the ->runtime_suspend() callbacks directly then it
may become difficult for you to use the common pm domain code base
that Rafael has been working on.
> Currently we have something similar for the AMBA
> bus here, since it actually has code in place to grab
> the block clock on probe() and its own runtime PM
> callbacks. Since the bus driver holds the actual reference
> to the clock, we have to call down into the bus callbacks
> from the platform runtime PM implementation since our
> implementation takes precedence. I guess this is expected
> way of doing it?
I'm not sure actually. We should sit down together and discuss this
over an afternoon - hopefully together with Rafael. I could probably
find time during next week in Orlando if you're around.
> I see three possible paradigms here:
>
> (A) dev_power_domain implementation in
> platform/board code handle silicon clocks and regulators.
>
> (B) Bus (as AMBA) driver handle silicon clocks and
> regulators
>
> (C) Devices handle clocks and regulators in their runtime
> PM callbacks themselves
>
> So now ARM SHmobile does (A), PrimeCell drivers do
> (B) and this patch attempted to do (C).
>
> And our way of handling AMBA is a mixture calling
> the bus callbacks from the platform like (A)+(B)
>
> I guess (A) and (C) won't mix very well since both
> handle platform devices and things will screw up if
> say our platform and SHmobile would use the same
> driver.
Exactly my point.
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
To: Baruch Siach
Cc: devicetree-discuss, linux-kernel, grant.likely, plagnioj,
linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>
On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
>
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>
> [snip]
>
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
>
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
> appropriate name?
For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.
>> + /* Maintainer: Atmel */
>> + .timer = &at91sam926x_timer,
>> + .map_io = at91_map_io,
>> + .init_early = ek_init_early,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91_dt_board_compat,
>> +MACHINE_END
>
> baruch
Thanks for your review,
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>
On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
>
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>
> [snip]
>
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
>
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
> appropriate name?
For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.
>> + /* Maintainer: Atmel */
>> + .timer = &at91sam926x_timer,
>> + .map_io = at91_map_io,
>> + .init_early = ek_init_early,
>> + .init_irq = at91_dt_init_irq,
>> + .init_machine = at91_dt_device_init,
>> + .dt_compat = at91_dt_board_compat,
>> +MACHINE_END
>
> baruch
Thanks for your review,
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [CONSOLIDATED PULL 11/27] pulseaudio-0.9.23: inherit perlnative to work around build on host without XML/Parser.pm
From: Martin Jansa @ 2011-10-24 14:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319465707.25011.21.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
On Mon, Oct 24, 2011 at 03:15:07PM +0100, Richard Purdie wrote:
> On Mon, 2011-10-24 at 15:19 +0200, Koen Kooi wrote:
> > Op 24 okt. 2011, om 15:15 heeft Richard Purdie het volgende geschreven:
> >
> > > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> > >> From: Martin Jansa <Martin.Jansa@gmail.com>
> > >>
> > >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > >> ---
> > >> .../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
> > >> 1 files changed, 1 insertions(+), 1 deletions(-)
> > >>
> > >> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > >> index 33f5e15..4ac2418 100644
> > >> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > >> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > >> @@ -4,7 +4,7 @@ PR = "r5"
> > >>
> > >> DEPENDS += "gdbm speex"
> > >>
> > >> -inherit gettext
> > >> +inherit gettext perlnative
> > >
> > > This doesn't look right. If we need xmlparser, we should state that in
> > > DEPENDS. If that is added to DEPENDS, I'm not sure we still need the
> > > inherit of perlnative?
> >
> > If you need xmlparser during the build you almost always need the
> > perlnative wrapper as well :(
>
> I was under the impression that we'd fixed most of those issues :/. It
> could well be a valid dependency in this case so I'll take the patch
> with the added DEPENDS.
Those were imho transitive deps from intltool, that's why this is a bit
different.
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Richard Purdie @ 2011-10-24 14:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <C0347AB9-9B51-4127-AEB7-AA1F0BE53BD6@dominion.thruhere.net>
On Mon, 2011-10-24 at 16:18 +0200, Koen Kooi wrote:
> Op 24 okt. 2011, om 16:10 heeft Richard Purdie het volgende geschreven:
>
> > On Mon, 2011-10-24 at 15:37 +0200, Koen Kooi wrote:
> >> Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
> >>
> >>> On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> >>>> From: Khem Raj <raj.khem@gmail.com>
> >>>>
> >>>> Adjust prefix.patch and delete resolve-sysroot.patch
> >>>> since its already applied upstream
> >>>>
> >>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >>>> ---
> >>>> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
> >>>> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
> >>>> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
> >>>> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
> >>>> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
> >>>> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
> >>>> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
> >>>> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
> >>>> 8 files changed, 47 insertions(+), 88 deletions(-)
> >>>> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
> >>>> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
> >>>> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
> >>>> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
> >>>> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
> >>>> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
> >>>> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
> >>>>
> >>>> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >>>> similarity index 57%
> >>>> rename from meta/recipes-devtools/libtool/libtool.inc
> >>>> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >>>> index ef9095b..1f652ef 100644
> >>>> --- a/meta/recipes-devtools/libtool/libtool.inc
> >>>> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >>>> @@ -1,4 +1,3 @@
> >>>> -SUMMARY = "Generic library support script"
> >>>
> >>> Why drop the SUMMARY field?
> >>
> >> What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
> >
> > SUMMARY is a one line 74? character summary of the package, DESCRIPTION
> > is a multiple line stream of text containing a more verbose description.
> > What happens to the data is package backend specific, I know RPM has
> > uses for both. There was definitely discussion about this on the mailing
> > list at the time, I'm not sure what if anything made it into the manuals
> > but if its not there it should be added.
>
>
> It seems to get OR'd:
>
> meta/classes/package_deb.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
> package_deb.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
>
> meta/classes/package_ipk.bbclass: summary = bb.data.getVar('SUMMARY', localdata, True) or bb.data.getVar('DESCRIPTION', localdata, True) or "."
> package_ipk.bbclass: description = bb.data.getVar('DESCRIPTION', localdata, True) or "."
>
> meta/classes/package_rpm.bbclass: srcsummary = (bb.data.getVar('SUMMARY', d, True) or bb.data.getVar('DESCRIPTION', d, True) or ".")
> package_rpm.bbclass: srcdescription = bb.data.getVar('DESCRIPTION', d, True) or "."
So the summary is SUMMARY if set, or DESCRIPTION if set else "."
The description is DESCRIPTION if set else "."
which was done to fall back to the case where recipes just set
DESCRIPTION.
Cheers,
Richard
^ permalink raw reply
* Re: [GIT] Security subsystem updates for 3.2
From: James Morris @ 2011-10-24 14:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <20111025012003.43d3847ec1284f68e79f9948@canb.auug.org.au>
On Tue, 25 Oct 2011, Stephen Rothwell wrote:
> > So this is reverted in linux-next. I don't know why, but it's a bad
> > sign. Doesn't compile?
>
> Yeah, this:
>
> security/smack/smack_lsm.c: In function 'smack_bprm_set_creds':
> security/smack/smack_lsm.c:473:21: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
>
> Caused by commit 84088ba23929 ("Smack: domain transition protections
> (v3)"). PER_CLEAR_ON_SETID is defined in linux/personality.h which is not
> directly included by the above file.
>
> It appears to have been fixed in the current version of the tree by this:
>
> Smack: compilation fix
Yep, that's the fix for it.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 08/10] Introduce Xen PCI Passthrough, qdevice (1/3)
From: Anthony PERARD @ 2011-10-24 14:29 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201141280.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:59, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> + if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
>> + qemu_mod_timer(s->pm_state->pm_timer,
>> + qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
>> + }
>
> where is this allocated?
The allocation is in the next patch, the long file that handle the config space.
--
Anthony PERARD
^ 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.