Re: [PATCH] pwm-backlight: handle BL_CORE_FBBLANK state
On Wed, Jan 30, 2013 at 03:19:15PM +0900, Alexandre Courbot wrote: > According to include/linux/backlight.h, the fb_blank field is to be > removed and blank status should preferably be set by setting the > BL_CORE_FBBLANK bit of the state field. This patch ensures this > condition is also taken into account when updating the backlight state. > > Signed-off-by: Alexandre Courbot > --- > drivers/video/backlight/pwm_bl.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Applied, thanks. Thierry pgpyWSTJaxPYP.pgp Description: PGP signature
Re: [PATCH] nl80211: avoid "wdev_id may be used uninitialized"
On Tue, 2013-01-29 at 17:11 -0700, Stephen Warren wrote: > From: Stephen Warren > > Silence the following: > net/wireless/nl80211.c: In function '__cfg80211_wdev_from_attrs.clone.119': > net/wireless/nl80211.c:57:6: warning: 'wdev_id' may be used uninitialized in > this function > > ... by always initializing wdev_id to zero. I assume that wiphy_idx and > ifidx are set to -1 for similar reasons, so this change simply propagates > the same workaround. > > In practice, this warning is false, since wdev_id is both set and used > under the condition if (have_wdev_id). However, at least my compiler > can't be coerced into realizing this; almost any code between the if > blocks that set and use the variable causes this warning. I don't see this warning? What compiler are you using? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MDaemon Notification -- Attachment Removed
--- MDaemon has detected restricted attachments within an email message --- >From : linux-kernel@vger.kernel.org To: dinh_ch...@orangefashionvt.com Subject : Kblhufftvn Message-ID: - Attachment(s) removed - dinh_ch...@orangefashionvt.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH Bug fix] acpi, movablemem_map: node0 should always be unhotpluggable when using SRAT.
When using movablemem_map=acpi, always set node0 as unhotpluggable, otherwise
if all the memory is hotpluggable, the kernel will fail to boot.
When using movablemem_map=nn[KMG]@ss[KMG], we don't stop users specifying
node0 as hotpluggable, and ignore all the info in SRAT, so that this option
can be used as a workaround of firmware bugs.
Reported-by: H. Peter Anvin
Signed-off-by: Tang Chen
---
Documentation/kernel-parameters.txt |6 ++
arch/x86/mm/srat.c | 10 --
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 7d1b6fc..81b6f15 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1645,6 +1645,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
in flags from SRAT from ACPI BIOS to determine which
memory devices could be hotplugged. The corresponding
memory ranges will be set as ZONE_MOVABLE.
+ NOTE: node0 should always be unhotpluggable, otherwise
+ the kernel will fail to boot.
movablemem_map=nn[KMG]@ss[KMG]
[KNL,X86,IA-64,PPC] This parameter is similar to
@@ -1666,6 +1668,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
satisfied. So the administrator should be careful that
the amount of movablemem_map areas are not too large.
Otherwise kernel won't have enough memory to start.
+ NOTE: We don't stop users specifying node0 as
+ hotpluggable, and ingore all the info in SRAT so
+ that this option can be used as a workaround of
+ firmware bugs.
MTD_Partition= [MTD]
Format: ,,,
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index b20b5b7..a85d2b7 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -161,9 +161,13 @@ handle_movablemem(int node, u64 start, u64 end, u32
hotpluggable)
*
* Using movablemem_map, we can prevent memblock from allocating memory
* on ZONE_MOVABLE at boot time.
+*
+* NOTE: node0 shoule always be unhotpluggable, otherwise, if all the
+* memory is hotpluggable, there will be no memory kernel can use.
*/
if (hotpluggable && movablemem_map.acpi) {
- insert_movablemem_map(start_pfn, end_pfn);
+ if (node != 0)
+ insert_movablemem_map(start_pfn, end_pfn);
goto out;
}
@@ -178,7 +182,9 @@ handle_movablemem(int node, u64 start, u64 end, u32
hotpluggable)
* Using movablemem_map, we can prevent memblock from allocating memory
* on ZONE_MOVABLE at boot time.
*
-* NOTE: In this case, SRAT info will be ingored.
+* NOTE: We don't stop users specifying node0 as hotpluggable, and
+* ignore all the info in SRAT, so that this option can be used
+* as a workaround of firmware bugs.
*/
overlap = movablemem_map_overlap(start_pfn, end_pfn);
if (overlap >= 0) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On Wed, Jan 30, 2013 at 04:27:11PM +0900, Alex Courbot wrote:
> On 01/30/2013 04:20 PM, Mark Zhang wrote:
[...]
> >>+static int panel_claa101_get_modes(struct display_entity *entity,
> >>+ const struct videomode **modes)
> >>+{
> >>+ /* TODO get modes from EDID? */
> >
> >Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
> >case, you can get EDID here. I know drm has some helpers to fetch EDID
> >but I recall there are some other functions which has no drm
> >dependencies which may be suitable for you.
>
> I explained this in the cover letter - I'm not sure we want to have
> a dependency on DRM here, as CDF entities could also be connected to
> other subsystems. That's something we need to figure out. But yes,
> ultimately this should be the place where EDID is retrieved.
I already said this in another thread. I think we should only be using
the CDF .get_modes() for static modes that cannot be obtained from EDID.
Thinking about it, I'm not quite sure why EDID would be needed for this
kind of panel anyway. Ventana probably has it because it keeps us from
having to hardcode things, but if we provide drivers for the panel
anyway, we can just as well hard-code the supported mode(s) in those
drivers.
What I'm trying to say is that the existence of EDID is board-specific,
so boards other than Ventana may not have an EDID EEPROM. Or perhaps
this particular display has the EEPROM integrated? Even in that case,
some boards may use this panel and simply not connect the EEPROM to an
I2C controller.
Thierry
pgpA1cD7gXtqO.pgp
Description: PGP signature
Re: [RFC 3/4] drm: tegra: use the Common Display Framework
On 01/30/2013 03:01 PM, Alex Courbot wrote: > On 01/30/2013 03:50 PM, Mark Zhang wrote: [...] > >>> +/* register display notifier */ >>> +output->display_notifier.dev = NULL; >> >> Set "display_notifier.dev" to NULL makes we have to compare with every >> display entity, just like what you do in "display_notify_callback": >> >> entity->dev && entity->dev->of_node == pnode >> >> So can we get the "struct device *" of panel here? Seems currently the >> "of" framework doesn't allow "device_node -> device". > > Nope. AFAICT the device might not be instanciated at this point. We > become aware of it for the first time in the callback function. We also > don't want to defer probing until the panel is parsed first, since the > panel might also depend on resources of the display device. > Agree. > Thanks, > Alex. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
On Wed, Jan 30, 2013 at 11:22 AM, Santosh Shilimkar wrote: > On Wednesday 30 January 2013 04:42 AM, Ruslan Bilovol wrote: >> >> Hi, >> >> On Tue, Jan 29, 2013 at 6:08 PM, Russell King - ARM Linux >> wrote: >>> >>> On Tue, Jan 29, 2013 at 05:54:24PM +0200, Ruslan Bilovol wrote: CPU implementer : 0x41 CPU name: OMAP4470 ES1.0 HS >>> >>> >>> Sigh. No. Look at what you're doing - look carefully at the above. >>> >>> "CPU implementer" - 0x41. That's A. For ARM Ltd. ARM Ltd implemented Wouldn't it be nice to display the name rather than hex?I think this would have definitely occurred to Russell but it is still done this way.I think there would be a valid reason for this and it would be nice to know that. If not then I can cook up a patch. >>> this CPU. Did ARM Ltd really implement OMAP4470 ? I think TI would be >>> very upset if that were to be the case. >> >> >> Yes, it would be very surprisingly :) >> >>> >>> So no, OMAP4470 is _NOT_ a CPU. It is a SoC. The CPU inside the SoC is >>> a collection of ARM Ltd Cortex A9 _CPUs_. >>> >>> See? Please, learn what a CPU is as opposed to a SoC. >> >> >> Completely agree with you. I will fix this >> > Thank god you agreed to drop your current approach. Please elaborate > what you are going to fix and also state what user-space features > changes from OMAP4460 to OMAP4470. > > Regards, > Santosh > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 03/14] ARM: edma: add AM33XX support to the private EDMA API
On Wed, Jan 30, 2013 at 8:41 AM, Matt Porter wrote:
> On Mon, Jan 28, 2013 at 09:27:24PM +0200, Andy Shevchenko wrote:
>> On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter wrote:
>> > Adds support for parsing the TI EDMA DT data into the required
>> > EDMA private API platform data. Enables runtime PM support to
>> > initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
>> > support.
>> >
>> > Signed-off-by: Matt Porter
>> > ---
>> > arch/arm/common/edma.c | 314
>> > ++--
>> > include/linux/platform_data/edma.h |1 +
>> > 2 files changed, 306 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> > index 2dce245..beeb1d2 100644
>> > --- a/arch/arm/common/edma.c
>> > +++ b/arch/arm/common/edma.c
>> > @@ -24,6 +24,13 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> >
>> > #include
>> >
>> > @@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
>> > */
>> > int edma_alloc_slot(unsigned ctlr, int slot)
>> > {
>> > + if (!edma_cc[ctlr])
>> > + return -EINVAL;
>> > +
>> > if (slot >= 0)
>> > slot = EDMA_CHAN_SLOT(slot);
>> >
>> > @@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
>> > EXPORT_SYMBOL(edma_clear_event);
>> >
>> >
>> > /*---*/
>> > +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
>> > +const char *propname, s8
>> > *out_values,
>> > +size_t sz)
>>
>> I'm sorry I didn't get why you couldn't use of_property_read_u8_array() ?
>> The similar comment to u16 and so on.
>
> There's some manipulation of the legacy Davinci platform data
> structures going on here. The driving reason was to not change any of
> the davinci platforms pdata which uses s8/s16 tables of mapping values
> with signed values as terminators. These versions below add the
> convert to the signed value and terminate the array as needed by the
> existing driver. This will all go away when the driver is rewritten and
> merged into drivers/dma/edma.c. At that point I want to throwaway all
> these legacy data structures. First, there's some more drivers to
> convert to dmaengine api.
>
I mean instead of custom functions you could use existing ones.
And sign here will be implicitly applied.
So, what I propose is to do something like this
static int edma_of_read_u32_to_s8_array(const struct device_node *np,
const char *propname, s8 *out_values,
size_t sz)
{
int ret;
ret = of_property_read_u8_array(np, propname, out_values, sz);
if (ret)
return ret;
/* Terminate it */
*out_values++ = -1;
*out_values++ = -1;
}
> -Matt
>>
>> > +{
>> > + struct property *prop = of_find_property(np, propname, NULL);
>> > + const __be32 *val;
>> > +
>> > + if (!prop)
>> > + return -EINVAL;
>> > + if (!prop->value)
>> > + return -ENODATA;
>> > + if ((sz * sizeof(u32)) > prop->length)
>> > + return -EOVERFLOW;
>> > +
>> > + val = prop->value;
>> > +
>> > + while (sz--)
>> > + *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
>> > +
>> > + /* Terminate it */
>> > + *out_values++ = -1;
>> > + *out_values++ = -1;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
>> > +const char *propname, s16
>> > *out_values,
>> > +size_t sz)
>> > +{
>> > + struct property *prop = of_find_property(np, propname, NULL);
>> > + const __be32 *val;
>> > +
>> > + if (!prop)
>> > + return -EINVAL;
>> > + if (!prop->value)
>> > + return -ENODATA;
>> > + if ((sz * sizeof(u32)) > prop->length)
>> > + return -EOVERFLOW;
>> > +
>> > + val = prop->value;
>> > +
>> > + while (sz--)
>> > + *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
>> > +
>> > + /* Terminate it */
>> > + *out_values++ = -1;
>> > + *out_values++ = -1;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static int edma_xbar_event_map(struct device *dev,
>> > + struct device_node *node,
>> > + struct edma_soc_info *pdata, int len)
>> > +{
>> > + int ret = 0;
>> > + int i;
>> > + struct resource res;
>> > + void *xbar;
>> > + const s16 (*xbar_chans)[2];
>> > + u32 shift, offset, mux;
>> > +
>> > + xbar_chans = devm_kzalloc(dev,
>> > + len/sizeof(s16) +
Re: [RFC 0/4] Use the Common Display Framework in tegra-drm
On Wed, Jan 30, 2013 at 12:02:15PM +0900, Alexandre Courbot wrote: > This series leverages the (still work-in-progress) Common Display Framework to > add panel support to the tegra-drm driver. It also adds a driver for the > CLAA101WA01A panel used on the Ventana board. > > The CDF is a moving target but Tegra needs some sort of display framework and > even in its current state the CDF seems to be the best candidate. Besides, by > using the CDF from now on we hope to provide useful feedback to Laurent and > the > other CDF designers. > > The changes to tegra-drm are rather minimal. Panels are referenced from Tegra > DC > output nodes through the "nvidia,panel" property. This property is looked up > when a display connect notification is received in order to see if it points > to > the connected display entity. If it does, the entity is then used for output. > > The DPMS states are then propagated to the output entity, which is then > supposed > to call back into the set_stream() hook in order to enable/disable the output > stream as needed. Thanks *a lot* for taking care of this Alexandre! From a quick look at the patches they seem generally fine. I'll go over them in a bit more detail though. > Although the overall design seems to work ok, a few specific issues need to be > addressed: > > 1) The CDF has a get_modes() hook, but this is already implemented by > tegra_connector_get_modes(). Ideally everything should be moved to the CDF > hook, > but Tegra's implementation uses DRM functions to retrieve the EDID and CDF > should, AFAIK, remain DRM-agnostic. Maybe a good option would be to just not implement get_modes() if the same information can be retrieved via EDID. That is, the DRM driver could just go and fetch EDID when the nvidia,ddc-i2c-bus is available (or parse the nvidia,edid blob) and only rely on CDF otherwise. So for Ventana the only reason why we need CDF is basically the power sequencing, right? > 2) There is currently no panel/backlight interaction, e.g. backlight status is > controlled through FB events, independantly from the panel state. It could > make > sense to have the panel DT node reference the backlight and control it as part > of its own power on/off sequence. Right now however, a backlight device cannot > ignore FB events. I definitely think that we should aim for correct panel and backlight interaction. Perhaps this could work by looking up the real backlight via it's phandle and have the CDF driver use the backlight API to disable or enable the backlight as part of the power sequencing. I'm not sure what you mean by "cannot ignore FB events"? Can you provide a concrete problematic use-case? > 3) Probably related to 2), now the backlight's power controls are part of the > panel driver, because the pwm-backlight driver cannot control the power > regulator and enable GPIO. This means that the backlight power is not turned > off > when its brightness is set to 0 through sysfs. Once again this speaks in favor > of having stronger panel/backlight interaction: for instance, the panel driver > could reference the backlight and hijack its update_status() op to replace it > by > one that does the correct power sequencing before calling the original > function. > This would require some extra infrastructure though. Another possibility would > be to have a dedicated backlight driver for each panel, with its own > "compatible" string. Hijacking .update_status() sounds a bit risky. But perhaps you could wrap the real backlight in a CDF backlight to receive notifications. Obviously you'd get two backlight devices in sysfs, but that turn out not to be a problem. Thierry pgpGHtgPU8a5Y.pgp Description: PGP signature
Re: [PATCH] ata: Fix DVD not dectected at some Haswell platforms
於 三，2013-01-30 於 12:19 -0500，Youquan Song 提到：
> There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d fix the 4
> ports
> IDE controller 32bit PIO mode.
> Recently, the problem was showed at Haswell platform which includes 2 ports
> IDE controller.
>
> So introduce a qurik patch to disable 32bit PIO at this IDE controller.
>
> Signed-off-by: Youquan Song
Patch works to me for avoid DVD detection on Intel Shark Bay development
machine.
Tested-by: Lee, Chun-Yi
Thanks a lot!
Joey Lee
> ---
> drivers/ata/ata_piix.c | 14 +-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
> index ef773e1..1993e52 100644
> --- a/drivers/ata/ata_piix.c
> +++ b/drivers/ata/ata_piix.c
> @@ -150,6 +150,7 @@ enum piix_controller_ids {
> tolapai_sata,
> piix_pata_vmw, /* PIIX4 for VMware, spurious DMA_ERR */
> ich8_sata_snb,
> + ich8_2port_sata_snb,
> };
>
> struct piix_map_db {
> @@ -326,7 +327,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
> /* SATA Controller IDE (Lynx Point) */
> { 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
> /* SATA Controller IDE (Lynx Point) */
> - { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
> + { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
> /* SATA Controller IDE (Lynx Point) */
> { 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
> /* SATA Controller IDE (Lynx Point-LP) */
> @@ -502,6 +503,7 @@ static const struct piix_map_db *piix_map_db_table[] = {
> [ich8m_apple_sata] = _apple_map_db,
> [tolapai_sata] = _map_db,
> [ich8_sata_snb] = _map_db,
> + [ich8_2port_sata_snb] = _2port_map_db,
> };
>
> static struct ata_port_info piix_port_info[] = {
> @@ -643,6 +645,16 @@ static struct ata_port_info piix_port_info[] = {
> .port_ops = _sata_ops,
> },
>
> + [ich8_2port_sata_snb] =
> + {
> + .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SIDPR |
> PIIX_FLAG_PIO16,
> + .pio_mask = ATA_PIO4,
> + .mwdma_mask = ATA_MWDMA2,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = _sata_ops,
> + },
> +
> +
> };
>
> static struct pci_bits piix_enable_bits[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] ARM: static_vm: introduce an infrastructure for static mapped area
Hello, Nicolas.
On Tue, Jan 29, 2013 at 07:05:32PM -0500, Nicolas Pitre wrote:
> On Thu, 24 Jan 2013, Joonsoo Kim wrote:
>
> > From: Joonsoo Kim
> >
> > In current implementation, we used ARM-specific flag, that is,
> > VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
> > The purpose of static mapped area is to re-use static mapped area when
> > entire physical address range of the ioremap request can be covered
> > by this area.
> >
> > This implementation causes needless overhead for some cases.
> > For example, assume that there is only one static mapped area and
> > vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
> > deciding whether it is matched or not. Moreover, even if there is
> > no static mapped area and vmlist has 300 areas, every time we call
> > ioremap, we check 300 areas in now.
> >
> > If we construct a extra list for static mapped area, we can eliminate
> > above mentioned overhead.
> > With a extra list, if there is one static mapped area,
> > we just check only one area and proceed next operation quickly.
> >
> > In fact, it is not a critical problem, because ioremap is not frequently
> > used. But reducing overhead is better idea.
> >
> > Another reason for doing this work is for removing architecture dependency
> > on vmalloc layer. I think that vmlist and vmlist_lock is internal data
> > structure for vmalloc layer. Some codes for debugging and stat inevitably
> > use vmlist and vmlist_lock. But it is preferable that they are used
> > as least as possible in outside of vmalloc.c
> >
> > Now, I introduce an ARM-specific infrastructure for static mapped area. In
> > the following patch, we will use this and resolve above mentioned problem.
> >
> > Signed-off-by: Joonsoo Kim
> > Signed-off-by: Joonsoo Kim
>
> First of all, I don't think you really need a new file with a global
> scope header file. Given that this code is meant to be used only for
> ioremap optimization on ARM, it is probably a better idea to simply put
> it all into arch/arm/mm/ioremap.c instead. The only function that needs
> to be exported out of ioremap.c is insert_static_vm(), and only for the
> benefit of arch/arm/mm/mmu.c, therefore this function prototype may as
> well just be added to arch/arm/mm/mm.h.
I agree with your all opinions.
I will re-work and will re-send v4 as soon as possible.
Thanks for review.
> More comments below.
>
> > diff --git a/arch/arm/include/asm/mach/static_vm.h
> > b/arch/arm/include/asm/mach/static_vm.h
> > new file mode 100644
> > index 000..72c8339
> > --- /dev/null
> > +++ b/arch/arm/include/asm/mach/static_vm.h
> > @@ -0,0 +1,45 @@
> > +/*
> > + * arch/arm/include/asm/mach/static_vm.h
> > + *
> > + * Copyright (C) 2012 LG Electronics, Joonsoo Kim
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> > + */
> > +
> > +#ifndef _ASM_MACH_STATIC_VM_H
> > +#define _ASM_MACH_STATIC_VM_H
> > +
> > +#include
> > +#include
> > +
> > +struct static_vm {
> > + struct static_vm*next;
> > + void*vaddr;
> > + unsigned long size;
> > + unsigned long flags;
> > + phys_addr_t paddr;
> > + const void *caller;
> > +};
>
> Here you're duplicating most of the vm_struct content for no obvious
> reasons. Patch #3 even allocates both a vm_struct and a static_vm
> instance in parallel for each mapping. Instead, you should consider
> something like this:
>
> struct static_vm {
> struct static_vm *next;
> struct vm_struct vm;
> };
>
> This way, you only need to allocate one structure:
>
> struct static_vm *svm = early_alloc(...);
> ...
> svm->vm.addr = addr;
> ...
> vm_area_add_early(>vm);
> insert_static_vm(svm);
Yes!
It's good idea.
> And then, it would make sense for the insert_static_vm() to do the
> vm_area_add_early() call itself as well.
Okay.
> Maybe rename insert_static_vm() to static_vm_area_add_early() to better
> identify its purpose as well. It shouldn't be used for any other
> purpose anyway.
Okay.
> > +
> > +extern struct static_vm *static_vmlist;
> > +extern spinlock_t static_vmlist_lock;
>
> Your patch is providing the proper accessors to manipulate those. They
> therefore should not be exported globally.
Re: [PATCH 1/4] pwm_backlight: Fix PWM levels support in non DT case
On 01/29/2013 01:30 PM, Thierry Reding wrote: >> Right. Now I know the background. >> However I do not agree with the conclusion. Probably it is fine in some cases >> to limit the number of configurable duty cycles to have only distinct steps. >> To not go too far, on my laptop I have: >> # cat /sys/class/backlight/acpi_video0/max_brightness >> 15 >> # cat /sys/class/backlight/intel_backlight/max_brightness >> 93 > > FWIW, I have hardware with an Intel chipset that has max_brightness > 13666. That doesn't mean all of these are necessarily valid or useful. For sure this range is overkill, but if you reduce it to let's say 15 would it be better? I don't think. It is up to the userspace to decide how to use it. User should have full control over the HW in hand. In this particular case I would expect userspace to give you around 20 steps to change brightness and when you change it would step between those so you will have nice, smooth changes and not big jumps. > That's not true. The duty-cycle merely defines a percentage of how long > the PWM signal will be high. You can choose an arbitrary number of > subdivisions. Sure all HW has limitation. The HW I have either have 127 or 255 time slots. Probably the best thing way to deal with the backlight is to have a range of 0 - 100% Nothing else. We should have an API to PWMs so user drivers could get the duty cycle from the HW drivers. In this way backlight would only expose percentage and the backlight driver would get the number of time slots from the PWM core to calculate the actual value for the selected percentage. > Since the brightness of a display isn't linearly proportional to the > duty cycle of the PWM driving it, representing that brightness by a > linear range is misleading. Furthermore some panels have regions where > the backlight isn't lit at all or where changes in the PWM duty-cycle > don't make any difference. and all of this also depend on the surrounding light conditions as well. If the same device is used in low light condition you care about the lower light ranges more compared to when the same device is used in bright environment. In these case the user space has to be adopted to the conditions and one should not need to recompile the kernel/dtb just because the device is used in different environment. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: adjust slave_id accordingly to request line base
On Tue, 2013-01-29 at 20:57 +0530, Viresh Kumar wrote: > On Tue, Jan 29, 2013 at 10:52 AM, Mika Westerberg > wrote: > > We had a discusssion about this with Andy as well. The thing is that there > > is no way in current resource to pass DMA request line numbers supported by > > the controller to the driver in a generic way. We on the other hand have to > > deal this somehow as we have a shared DMA controller on Lynxpoint where the > > offset will start from 16 (but it might be something else as well). > > > > Is there something which limits the usage of IORESOUCE_DMA to be only > > usable for ISA DMA channels? > > Andy, > > Why do we need this request_line_base? Why not program the actual value > directly into the slave structure (base + offset)? Slave device exactly has knowledge about this number slave_id = (base +offset). However... > In case it is required, add it in platform data field or can add DT > binding for it. We get a device from the ACPI CSRT table. During enumeration we don't know what kind of the device it is. From the enumeration point of view each device enumerated from CSRT is a platform device (see drivers/acpi/csrt.c for the details). That's why we have to pass this info somehow to the DMAC driver. And like Mika already mentioned we have no other generic way except IORESOURCE_DMA. If you have something better in mind, please share. We could adopt our code then. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 08/15] memory-hotplug: Common APIs to support page tables hot-remove
On Wed, 2013-01-30 at 13:55 +0800, Tang Chen wrote:
> On 01/30/2013 11:27 AM, Simon Jeons wrote:
> > On Wed, 2013-01-30 at 10:16 +0800, Tang Chen wrote:
> >> On 01/29/2013 09:04 PM, Simon Jeons wrote:
> >>> Hi Tang,
> >>> On Wed, 2013-01-09 at 17:32 +0800, Tang Chen wrote:
> From: Wen Congyang
>
> When memory is removed, the corresponding pagetables should alse be
> removed.
> This patch introduces some common APIs to support vmemmap pagetable and
> x86_64
> architecture pagetable removing.
> >>>
> >>> Why don't need to build_all_zonelists like online_pages does during
> >>> hot-add path(add_memory)?
> >>
> >> Hi Simon,
> >>
> >> As you said, build_all_zonelists is done by online_pages. When the
> >> memory device
> >> is hot-added, we cannot use it. we can only use is when we online the
> >> pages on it.
> >
> > Why?
> >
> > If a node has just one memory device and memory is small, some zone will
> > not present like zone_highmem, then hot-add another memory device and
> > zone_highmem appear, if you should build_all_zonelists this time?
>
> Hi Simon,
>
> We built zone list when the first memory on the node is hot-added.
>
> add_memory()
> |-->if (!node_online(nid)) hotadd_new_pgdat()
> |-->free_area_init_node()
> |-->build_all_zonelists()
>
> All the zones on the new node will be initialized as empty. So here, we
> build zone list.
>
> But actually we did nothing because no page is online, and zones are empty.
> In build_zonelists_node(), populated_zone(zone) will always be false.
>
> The real work of building zone list is when pages are online. :)
>
>
> And in your question, you said some small memory is there, and
> zone_normal is present.
> OK, when these pages are onlined (not added), the zone list has been
> rebuilt.
> But pages in zone_highmem is not added, which means not onlined, so we
> don't need to
> build zone list for it. And later, the zone_highmem pages are added, we
> still don't
> rebuild the zone list because the real rebuilding work is when the pages
> are onlined.
>
> I think this is the current logic. :)
Thanks for you clarify. Actually, I miss "Even if the memory is
hot-added, it is not at ready-to-use state. For using newly added
memory, you have to 'online' the memory section" in the doc. :)
>
> Thanks. :)
>
> >
> >>
> >> But we can online the pages as different types, kernel or movable (which
> >> belongs to
> >> different zones), and we can online part of the memory, not all of them.
> >> So each time we online some pages, we should check if we need to update
> >> the zone list.
> >>
> >> So I think that is why we do build_all_zonelists when online_pages.
> >> (just my opinion)
> >>
> >> Thanks. :)
> >>
> >>>
>
> All pages of virtual mapping in removed memory cannot be freedi if some
> pages
> used as PGD/PUD includes not only removed memory but also other memory.
> So the
> patch uses the following way to check whether page can be freed or not.
>
> 1. When removing memory, the page structs of the revmoved memory are
> filled
> with 0FD.
> 2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be
> cleared.
> In this case, the page used as PT/PMD can be freed.
>
> Signed-off-by: Yasuaki Ishimatsu
> Signed-off-by: Jianguo Wu
> Signed-off-by: Wen Congyang
> Signed-off-by: Tang Chen
> ---
> arch/x86/include/asm/pgtable_types.h |1 +
> arch/x86/mm/init_64.c| 299
> ++
> arch/x86/mm/pageattr.c | 47 +++---
> include/linux/bootmem.h |1 +
> 4 files changed, 326 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/include/asm/pgtable_types.h
> b/arch/x86/include/asm/pgtable_types.h
> index 3c32db8..4b6fd2a 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -352,6 +352,7 @@ static inline void update_page_count(int level,
> unsigned long pages) { }
> * as a pte too.
> */
> extern pte_t *lookup_address(unsigned long address, unsigned int
> *level);
> +extern int __split_large_page(pte_t *kpte, unsigned long address, pte_t
> *pbase);
>
> #endif/* !__ASSEMBLY__ */
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 9ac1723..fe01116 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -682,6 +682,305 @@ int arch_add_memory(int nid, u64 start, u64 size)
> }
> EXPORT_SYMBOL_GPL(arch_add_memory);
>
> +#define PAGE_INUSE 0xFD
> +
> +static void __meminit free_pagetable(struct page *page, int order)
> +{
> +struct zone *zone;
> +bool bootmem
Re: [RFC 3/4] drm: tegra: use the Common Display Framework
On 01/30/2013 04:24 PM, Thierry Reding wrote: Could you pick up a somewhat meaningful name? You know, there are too many variables with name "drm/connector/output/encoder"... :) Well, it's supposed to be abstract. From the CDF point of view it could be anything besides a panel. I know this makes it an output of an output, but I can't think of anything better right now. How about renaming "this" to stream to match with what the output is in CDF speak. Good idea. And the output's output is the panel, right? Why not just call it that? Even if it isn't directly connected to a panel entity but has indeed a whole pipeline in between, for tegra-drm it is still a panel. Makes sense indeed. Besides the DT refer it as "panel" already. Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On 01/30/2013 04:20 PM, Mark Zhang wrote:
+ /* OFF and STANDBY are equivalent to us */
+ if (state == DISPLAY_ENTITY_STATE_STANDBY)
+ state = DISPLAY_ENTITY_STATE_OFF;
Do we need this? The "switch" below handles the same thing already.
Indeed, I have rewritten this part actually.
+static int panel_claa101_get_modes(struct display_entity *entity,
+ const struct videomode **modes)
+{
+ /* TODO get modes from EDID? */
Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
case, you can get EDID here. I know drm has some helpers to fetch EDID
but I recall there are some other functions which has no drm
dependencies which may be suitable for you.
I explained this in the cover letter - I'm not sure we want to have a
dependency on DRM here, as CDF entities could also be connected to other
subsystems. That's something we need to figure out. But yes, ultimately
this should be the place where EDID is retrieved.
+static struct of_device_id panel_claa101_of_match[] = {
+ { .compatible = "chunghwa,claa101wa01a", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, pwm_backlight_of_match);
What does this mean? Why we need this?
Well, now you know where I copy my code from. :)
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] drm: tegra: use the Common Display Framework
On Wed, Jan 30, 2013 at 04:01:48PM +0900, Alex Courbot wrote:
> On 01/30/2013 03:50 PM, Mark Zhang wrote:
> >>@@ -147,6 +148,9 @@ struct tegra_output {
> >>
> >>struct drm_encoder encoder;
> >>struct drm_connector connector;
> >>+ struct display_entity this;
> >>+ struct display_entity *output;
> >
> >Could you pick up a somewhat meaningful name? You know, there are too
> >many variables with name "drm/connector/output/encoder"... :)
>
> Well, it's supposed to be abstract. From the CDF point of view it
> could be anything besides a panel. I know this makes it an output of
> an output, but I can't think of anything better right now.
How about renaming "this" to stream to match with what the output is in
CDF speak. And the output's output is the panel, right? Why not just
call it that? Even if it isn't directly connected to a panel entity but
has indeed a whole pipeline in between, for tegra-drm it is still a
panel.
Thierry
pgp35gn2eKf6Y.pgp
Description: PGP signature
Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
On 01/30/2013 11:02 AM, Alexandre Courbot wrote:
> Add support for the Chunghwa CLAA101WA01A display panel.
>
> Signed-off-by: Alexandre Courbot
> ---
[...]
> +
> +#include
> +
> +#define CLAA101WA01A_WIDTH 223
> +#define CLAA101WA01A_HEIGHT 125
If I remember correct, the physical size of the panel can be fetched in
EDID. If this is correct, we don't have to hard-code here.
> +
> +struct panel_claa101 {
> + struct display_entity entity;
> + struct regulator *vdd_pnl;
> + struct regulator *vdd_bl;
> + /* Enable GPIOs */
> + int pnl_enable;
> + int bl_enable;
> +};
> +
> +#define to_panel_claa101(p) container_of(p, struct panel_claa101, entity)
> +
> +static int panel_claa101_set_state(struct display_entity *entity,
> +enum display_entity_state state)
> +{
> + struct panel_claa101 *panel = to_panel_claa101(entity);
> +
> + /* OFF and STANDBY are equivalent to us */
> + if (state == DISPLAY_ENTITY_STATE_STANDBY)
> + state = DISPLAY_ENTITY_STATE_OFF;
Do we need this? The "switch" below handles the same thing already.
> +
> + switch (state) {
> + case DISPLAY_ENTITY_STATE_OFF:
> + case DISPLAY_ENTITY_STATE_STANDBY:
> + if (entity->source)
> + display_entity_set_stream(entity->source,
> + DISPLAY_ENTITY_STREAM_STOPPED);
> +
> + /* TODO error checking? */
> + gpio_set_value_cansleep(panel->bl_enable, 0);
> + usleep_range(1, 1);
> + regulator_disable(panel->vdd_bl);
> + usleep_range(20, 20);
> + gpio_set_value_cansleep(panel->pnl_enable, 0);
> + regulator_disable(panel->vdd_pnl);
> + break;
> +
> + case DISPLAY_ENTITY_STATE_ON:
> + regulator_enable(panel->vdd_pnl);
> + gpio_set_value_cansleep(panel->pnl_enable, 1);
> + usleep_range(20, 20);
> + regulator_enable(panel->vdd_bl);
> + usleep_range(1, 1);
> + gpio_set_value_cansleep(panel->bl_enable, 1);
> +
> + if (entity->source)
> + display_entity_set_stream(entity->source,
> + DISPLAY_ENTITY_STREAM_CONTINUOUS);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int panel_claa101_get_modes(struct display_entity *entity,
> +const struct videomode **modes)
> +{
> + /* TODO get modes from EDID? */
Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
case, you can get EDID here. I know drm has some helpers to fetch EDID
but I recall there are some other functions which has no drm
dependencies which may be suitable for you.
> + return 0;
> +}
[...]
> +
> +static int __exit panel_claa101_remove(struct platform_device *pdev)
> +{
> + struct panel_claa101 *panel = platform_get_drvdata(pdev);
> +
> + display_entity_unregister(>entity);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
We don't need this kind of "ifdef" in upstream kernel.
> +static struct of_device_id panel_claa101_of_match[] = {
> + { .compatible = "chunghwa,claa101wa01a", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, pwm_backlight_of_match);
What does this mean? Why we need this?
> +#else
> +#endif
> +
> +static const struct dev_pm_ops panel_claa101_dev_pm_ops = {
> +};
> +
> +static struct platform_driver panel_claa101_driver = {
> + .probe = panel_claa101_probe,
> + .remove = panel_claa101_remove,
> + .driver = {
> + .name = "panel_claa101wa01a",
> + .owner = THIS_MODULE,
> +#ifdef CONFIG_PM
> + .pm = _claa101_dev_pm_ops,
If you haven't implemented this in this patch set, I suggest removing this.
> +#endif
> +#ifdef CONFIG_OF
> + .of_match_table = of_match_ptr(panel_claa101_of_match),
> +#endif
> + },
> +};
> +
> +module_platform_driver(panel_claa101_driver);
> +
> +MODULE_AUTHOR("Alexandre Courbot ");
> +MODULE_DESCRIPTION("Chunghwa CLAA101WA01A Display Panel");
> +MODULE_LICENSE("GPL");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] firmware: Refactoring for splitting user-mode helper code
At Wed, 30 Jan 2013 11:37:30 +0800,
Ming Lei wrote:
>
> On Tue, Jan 29, 2013 at 10:46 PM, Takashi Iwai wrote:
> > Since 3.7 kernel, the firmware loader can read the firmware files
> > directly, and the traditional user-mode helper is invoked only as a
> > fallback. This seems working pretty well, and the next step would be
> > to reduce the redundant user-mode helper stuff in future.
> >
> > This patch is a preparation for that: refactor the code for splitting
> > user-mode helper stuff more easily. No functional change.
> >
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/base/firmware_class.c | 290
> > +++---
> > 1 file changed, 157 insertions(+), 133 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index b392b35..27f2c7c 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -319,7 +319,8 @@ static bool fw_read_file_contents(struct file *file,
> > struct firmware_buf *fw_buf
> > return true;
> > }
> >
> > -static bool fw_get_filesystem_firmware(struct firmware_buf *buf)
> > +static bool fw_get_filesystem_firmware(struct device *device,
> > + struct firmware_buf *buf)
> > {
> > int i;
> > bool success = false;
> > @@ -343,6 +344,16 @@ static bool fw_get_filesystem_firmware(struct
> > firmware_buf *buf)
> > break;
> > }
> > __putname(path);
> > +
> > + if (success) {
> > + dev_dbg(device, "firmware: direct-loading firmware %s\n",
> > + buf->fw_id);
> > + mutex_lock(_lock);
> > + set_bit(FW_STATUS_DONE, >status);
> > + complete_all(>completion);
> > + mutex_unlock(_lock);
> > + }
> > +
> > return success;
> > }
> >
> > @@ -796,99 +807,112 @@ static int fw_add_devm_name(struct device *dev,
> > const char *name)
> > }
> > #endif
> >
> > -static void _request_firmware_cleanup(const struct firmware **firmware_p)
> > +/* wait until the shared firmware_buf becomes ready (or error) */
> > +static int sync_cached_firmware_buf(struct firmware_buf *buf)
> > {
> > - release_firmware(*firmware_p);
> > - *firmware_p = NULL;
> > + int ret = 0;
> > +
> > + mutex_lock(_lock);
> > + while (!test_bit(FW_STATUS_DONE, >status)) {
> > + if (test_bit(FW_STATUS_ABORT, >status)) {
> > + ret = -ENOENT;
> > + break;
> > + }
> > + mutex_unlock(_lock);
> > + wait_for_completion(>completion);
> > + mutex_lock(_lock);
> > + }
> > + mutex_unlock(_lock);
> > + return ret;
> > }
> >
> > -static struct firmware_priv *
> > -_request_firmware_prepare(const struct firmware **firmware_p, const char
> > *name,
> > - struct device *device, bool uevent, bool nowait)
> > +/* prepare firmware and firmware_buf structs;
> > + * return 0 if a firmware is already assigned, 1 if need to load one,
> > + * or a negative error code
> > + */
> > +static int
> > +_request_firmware_prepare(struct firmware **firmware_p, const char *name,
> > + struct device *device)
> > {
> > struct firmware *firmware;
> > - struct firmware_priv *fw_priv = NULL;
> > struct firmware_buf *buf;
> > int ret;
> >
> > - if (!firmware_p)
> > - return ERR_PTR(-EINVAL);
> > -
> > *firmware_p = firmware = kzalloc(sizeof(*firmware), GFP_KERNEL);
> > if (!firmware) {
> > dev_err(device, "%s: kmalloc(struct firmware) failed\n",
> > __func__);
> > - return ERR_PTR(-ENOMEM);
> > + return -ENOMEM;
> > }
> >
> > if (fw_get_builtin_firmware(firmware, name)) {
> > dev_dbg(device, "firmware: using built-in firmware %s\n",
> > name);
> > - return NULL;
> > + return 0; /* assigned */
> > }
> >
> > ret = fw_lookup_and_allocate_buf(name, _cache, );
> > - if (!ret)
> > - fw_priv = fw_create_instance(firmware, name, device,
> > - uevent, nowait);
> >
> > - if (IS_ERR(fw_priv) || ret < 0) {
> > - kfree(firmware);
> > - *firmware_p = NULL;
> > - return ERR_PTR(-ENOMEM);
> > - } else if (fw_priv) {
> > - fw_priv->buf = buf;
> > + /*
> > +* bind with 'buf' now to avoid warning in failure path
> > +* of requesting firmware.
> > +*/
> > + firmware->priv = buf;
> >
> > - /*
> > -* bind with 'buf' now to avoid warning in failure path
> > -* of requesting firmware.
> > -*/
> > - firmware->priv = buf;
> > -
Re: [PATCH 1/1] USB: option: add support for Telit LE920
Hello, 2013/1/29 Bjørn Mork : > Dan Williams writes: >> On Mon, 2013-01-28 at 16:47 +0100, Daniele Palmas wrote: >>> From: danielepa >>> >>> Add PID and special handling for Telit LE920 >> >> Any idea what interfaces 1 and 5 are? Is one perhaps a pseudo-ethernet >> interface that could be used instead of PPP? What's the lsusb -v output >> for the device? > > Daniele has already posted a patch adding intf #5 to qmi_wwan, so I > assume that is verified to be a QMI/rmnet interface. > > But I was wondering about #1 too, if that indeed is a vendor specific > interface providing a non-serial, non-rmnet function. What could that > be? > > > Bjørn The output of lsusb for interface #1 is the following: Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 66 bInterfaceProtocol 1 iInterface 0 It should be an adb device, so probably it is not needed to blacklist it. Should I resend a new patch with only interface #5 reserved? Thanks, Daniele -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] cpufreq: handle SW coordinated CPUs
I am starting to follow cpufreq patches religiously now and so have to come
back to this old thread due to some crash we got :)
Its still not pushed upstream, so better to get it resolved before 3.9.
On Thu, Dec 27, 2012 at 8:25 PM, Fabio Baltieri
wrote:
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> static inline void dbs_timer_init(struct dbs_data *dbs_data,
> - struct cpu_dbs_common_info *cdbs, unsigned int sampling_rate)
> + struct cpu_dbs_common_info *cdbs,
> + unsigned int sampling_rate,
> + int cpu)
> {
> int delay = delay_for_sampling_rate(sampling_rate);
> + struct cpu_dbs_common_info *cdbs_local = dbs_data->get_cpu_cdbs(cpu);
I couldn't understand the real need for this, as it should really give
back the same
pointer pointed out by: cdbs and hence no need of cpu in params too..
I may be wrong here :)
>
> - INIT_DEFERRABLE_WORK(>work, dbs_data->gov_dbs_timer);
> - schedule_delayed_work_on(cdbs->cpu, >work, delay);
> + schedule_delayed_work_on(cpu, _local->work, delay);
> }
>
> static inline void dbs_timer_exit(struct cpu_dbs_common_info *cdbs)
> @@ -217,6 +227,10 @@ int cpufreq_governor_dbs(struct dbs_data *dbs_data,
> if (ignore_nice)
> j_cdbs->prev_cpu_nice =
> kcpustat_cpu(j).cpustat[CPUTIME_NICE];
> +
> + mutex_init(_cdbs->timer_mutex);
> + INIT_DEFERRABLE_WORK(_cdbs->work,
> +dbs_data->gov_dbs_timer);
> }
>
> /*
> @@ -275,15 +289,33 @@ second_time:
> }
> mutex_unlock(_data->mutex);
>
> - mutex_init(_cdbs->timer_mutex);
> - dbs_timer_init(dbs_data, cpu_cdbs, *sampling_rate);
> + if (dbs_sw_coordinated_cpus(cpu_cdbs)) {
> + for_each_cpu(j, policy->cpus) {
> + struct cpu_dbs_common_info *j_cdbs;
> +
> + j_cdbs = dbs_data->get_cpu_cdbs(j);
> + dbs_timer_init(dbs_data, j_cdbs,
> + *sampling_rate, j);
> + }
> + } else {
> + dbs_timer_init(dbs_data, cpu_cdbs, *sampling_rate,
> cpu);
> + }
do you really need this else part? In case of uniprocessor systems also, the if
block should be enough. Isn't it?
> break;
>
> case CPUFREQ_GOV_STOP:
> if (dbs_data->governor == GOV_CONSERVATIVE)
> cs_dbs_info->enable = 0;
>
> - dbs_timer_exit(cpu_cdbs);
> + if (dbs_sw_coordinated_cpus(cpu_cdbs)) {
> + for_each_cpu(j, policy->cpus) {
> + struct cpu_dbs_common_info *j_cdbs;
> +
> + j_cdbs = dbs_data->get_cpu_cdbs(j);
> + dbs_timer_exit(j_cdbs);
> + }
> + } else {
> + dbs_timer_exit(cpu_cdbs);
> + }
ditto.
> mutex_lock(_data->mutex);
> mutex_destroy(_cdbs->timer_mutex);
> diff --git a/drivers/cpufreq/cpufreq_governor.h
> b/drivers/cpufreq/cpufreq_governor.h
> index f661654..5bf6fb8 100644
> --- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -171,6 +171,7 @@ static inline int delay_for_sampling_rate(unsigned int
> sampling_rate)
>
> u64 get_cpu_idle_time(unsigned int cpu, u64 *wall);
> void dbs_check_cpu(struct dbs_data *dbs_data, int cpu);
> +bool dbs_sw_coordinated_cpus(struct cpu_dbs_common_info *cdbs);
> int cpufreq_governor_dbs(struct dbs_data *dbs_data,
> struct cpufreq_policy *policy, unsigned int event);
> #endif /* _CPUFREQ_GOVERNER_H */
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c
> b/drivers/cpufreq/cpufreq_ondemand.c
> index 7731f7c..93bb56d 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -243,7 +243,8 @@ static void od_dbs_timer(struct work_struct *work)
> }
> }
>
> - schedule_delayed_work_on(cpu, _info->cdbs.work, delay);
> + schedule_delayed_work_on(smp_processor_id(), _info->cdbs.work,
> + delay);
> mutex_unlock(_info->cdbs.timer_mutex);
> }
>
> --
> 1.7.12.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe cpufreq" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data. Enables runtime PM support to
initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
support.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 314 ++--
arch/arm/plat-omap/Kconfig |1 +
include/linux/platform_data/edma.h |1 +
3 files changed, 307 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2dce245..beeb1d2 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, );
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size());
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-xbar-event-map",
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] >> 2;
+ offset <<= 2;
+ mux = readl((void *)((u32)xbar + offset));
+ mux &= ~(0xff << shift);
+ mux |= xbar_chans[i][0] << shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata->xbar_chans = xbar_chans;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ const s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, "dma-channels", );
+ if (ret < 0)
+ return ret;
+ pdata->n_channel = value;
+
+ ret = of_property_read_u32(node, "ti,edma-regions", );
+ if (ret < 0)
+ return ret;
+ pdata->n_region = value;
+
+ ret = of_property_read_u32(node,
[PATCH v6 04/10] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 0b408bb..239020b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -220,7 +220,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 05/10] dmaengine: edma: Add TI EDMA device tree binding
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = <0x4900 0x1>;
+ interrupt-parent = <>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+14 2
+26 6
+48 4
+56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 06/10] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 01/10] ARM: davinci: move private EDMA API to arm/common
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} |4 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|6 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
.../mach => include/linux/platform_data}/edma.h| 89 +---
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |7 +-
23 files changed, 35 insertions(+), 106 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
rename {arch/arm/mach-davinci/include/mach =>
include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..be3c04a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include
#include
-#include
+#include
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
@@ -1387,7 +1387,7 @@ EXPORT_SYMBOL(edma_clear_event);
/*---*/
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
const s8(*queue_priority_mapping)[2];
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o psc.o \
- dma.o usb.o common.o sram.o aemif.o
+ usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include
#include
#include
+#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c
b/arch/arm/mach-davinci/devices-tnetv107x.c
index 773ab07..ba37760 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++
Re: [RFC 3/4] drm: tegra: use the Common Display Framework
On 01/30/2013 03:50 PM, Mark Zhang wrote:
@@ -147,6 +148,9 @@ struct tegra_output {
struct drm_encoder encoder;
struct drm_connector connector;
+ struct display_entity this;
+ struct display_entity *output;
Could you pick up a somewhat meaningful name? You know, there are too
many variables with name "drm/connector/output/encoder"... :)
Well, it's supposed to be abstract. From the CDF point of view it could
be anything besides a panel. I know this makes it an output of an
output, but I can't think of anything better right now.
+ if (entity->dev && entity->dev->of_node == pnode) {
+ dev_dbg(output->dev, "connecting panel\n");
+ output->output = display_entity_get(entity);
+ display_entity_connect(>this, output->output);
+ }
+ of_node_put(pnode);
+
+ break;
+
+ case DISPLAY_ENTITY_NOTIFIER_DISCONNECT:
+ if (!output->output || output->output != entity)
+ break;
+
+ dev_dbg(output->dev, "disconnecting panel\n");
+ display_entity_disconnect(>this, output->output);
+ output->output = NULL;
+ display_entity_put(>this);
No "display_entity_get" for "output->this", so I don't think we need
"display_entity_put" here. If you register this entity with "release"
callback and you wanna release "output->this", call the "release"
function manually.
Oh, this was supposed to be called on output->output actually, to
balance the display_entity_get() of the connect event. Thanks for
catching this.
+ /* register display entity */
+ memset(>this, 0, sizeof(output->this));
+ output->this.dev = drm->dev;
Use "output->dev" here. Actually the device you wanna register it to
display entity is the "encoder"(in drm terms), not "drm->dev". If we use
"drm->dev" here, we will have all same device for all encoders(HDMI,
DSI...).
Yes, that's absolutely right.
+ /* register display notifier */
+ output->display_notifier.dev = NULL;
Set "display_notifier.dev" to NULL makes we have to compare with every
display entity, just like what you do in "display_notify_callback":
entity->dev && entity->dev->of_node == pnode
So can we get the "struct device *" of panel here? Seems currently the
"of" framework doesn't allow "device_node -> device".
Nope. AFAICT the device might not be instanciated at this point. We
become aware of it for the first time in the callback function. We also
don't want to defer probing until the panel is parsed first, since the
panel might also depend on resources of the display device.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 08/10] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b610f52..2c02c02 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -822,14 +825,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, );
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+, >dev,
+mcspi_dma->dma_rx_ch_name);
+
if (!mcspi_dma->dma_rx) {
dev_err(>dev, "no RX DMA engine channel for McSPI\n");
return -EAGAIN;
}
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, );
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+, >dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dev_err(>dev, "no TX DMA engine channel for McSPI\n");
dma_release_channel(mcspi_dma->dma_rx);
@@ -1223,29 +1235,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(>dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(>dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(>dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(>dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+ mcspi->dma_channels[i].dma_tx_sync_dev =
+ dma_res->start;
+ }
}
if (status < 0)
--
1.7.9.5
--
[PATCH v6 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..68cb28e 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = < 42
+43
+44
+45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 00/10] DMA Engine support for AM33XX
Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support
Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
removed some unneeded definitions
- Fixed parsing of optional properties
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.8-rc5 and the following patches:
- dmaengine DT support and edma dmaengine driver fix from
the git://git.infradead.org/users/vkoul/slave-dma.git next
branch
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
With this series both BeagleBone and the AM335x EVM have working
SPI DMA support (and MMC support with the separate MMC series).
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v6
has the complete series, dependencies, and some test
drivers/defconfigs. Note that MMC can only be tested with a
separate MMC dmaengine/DT series applied.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (10):
ARM: davinci: move private EDMA API to arm/common
ARM: edma: remove unused transfer controller handlers
ARM: edma: add AM33XX support to the private EDMA API
dmaengine: edma: enable build for AM33XX
dmaengine: edma: Add TI EDMA device tree binding
ARM: dts: add AM33XX EDMA support
dmaengine: add dma_request_slave_channel_compat()
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
spi: omap2-mcspi: add generic DMA request support to the DT binding
ARM: dts: add AM33XX SPI DMA support
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +-
arch/arm/Kconfig |1 +
arch/arm/boot/dts/am33xx.dtsi | 30 ++
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} | 355 +---
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c
[PATCH v6 02/10] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be3c04a..2dce245 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", >dev);
- if (status < 0) {
- dev_dbg(>dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", >dev);
- if (status < 0) {
- dev_dbg(>dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 07/10] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren
Signed-off-by: Matt Porter
Acked-by: Tony Lindgren
---
include/linux/dmaengine.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..17d8ffd 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
+
+static inline struct dma_chan
+*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 10/10] ARM: dts: add AM33XX SPI DMA support
Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index e711ffb..ddf702a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -328,6 +328,11 @@ interrupt = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; + dmas = < 16 +17 +18 +19>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; @@ -339,6 +344,11 @@ interrupt = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; + dmas = < 42 +43 +44 +45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oom caused disk corruption on 3.7.1
- Original Message - > From: "CAI Qian" > To: "linux-mm" kvack.org> > Cc: sta...@vger.kernel.org, "linux-kernel" vger.kernel.org> > Sent: Wednesday, January 9, 2013 5:50:53 PM > Subject: oom caused disk corruption on 3.7.1 > > While doing oom testing on a power7 system with swapping, > it was swallowed a panic on v3.7.1 below. Without a swap device, > it is running fine. v3.0 has the same problem. This is weird that if turned on those options, CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y it turns out to be fine except some warnings which looks like better than a panic. INFO: task (tmpfiles):5456 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. (tmpfiles) D 3fff877fb508 0 5456 1 0x0080 Call Trace: [c0001cf76a30] [c10a2180] jiffies+0x0/0x80 (unreliable) [c0001cf76c00] [c0014960] .__switch_to+0x110/0x240 [c0001cf76cb0] [c06b1cc0] .__schedule+0x3c0/0x8b0 [c0001cf76f30] [c06affb4] .schedule_timeout+0x1e4/0x2d0 [c0001cf77030] [c06b23fc] .wait_for_common+0x18c/0x200 [c0001cf77110] [c02863a8] .xfs_buf_iowait+0x88/0x150 [c0001cf771a0] [c0286700] .xfs_buf_read_map+0xd0/0x170 [c0001cf77240] [c02f4074] .xfs_trans_read_buf_map+0x204/0x570 [c0001cf77300] [c02c5940] .xfs_da_read_buf+0x100/0x250 [c0001cf773f0] [c02c7098] .xfs_da_node_lookup_int+0xc8/0x440 [c0001cf774c0] [c02d0c60] .xfs_dir2_node_lookup+0x70/0x1d0 [c0001cf77570] [c02c8fe4] .xfs_dir_lookup+0x214/0x230 [c0001cf776a0] [c029f068] .xfs_lookup+0xb8/0x1a0 [c0001cf77760] [c0293f50] .xfs_vn_lookup+0x60/0xd0 [c0001cf77800] [c01db454] .lookup_real+0x44/0xa0 [c0001cf77890] [c01e16e8] .do_last+0xad8/0xe00 [c0001cf779c0] [c01e1afc] .path_openat+0xec/0x5f0 [c0001cf77ae0] [c01e2450] .do_filp_open+0x40/0xb0 [c0001cf77c10] [c01d6308] .open_exec+0x48/0x170 [c0001cf77cc0] [c01d7ae0] .do_execve_common.isra.19+0x240/0x4e0 [c0001cf77da0] [c01d8100] .SyS_execve+0x50/0x90 [c0001cf77e30] [c00097d4] syscall_exit+0x0/0x94 > > Test case is here, > http://tinyurl.com/bzzmrb8 > > ... > [ 763.781571] Write-error on swap-device (253:0:7545984) > [ 763.781573] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781574] Write-error on swap-device (253:0:7546240) > [ 763.781576] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781577] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > [ 763.781578] Write-error on swap-device (253:0:7546496) > [ 763.781579] Call Trace: > [ 763.781580] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781590] [c002eac83870] [c0015884] > .show_stack+0x74/0x1b0 (unreliable) > [ 763.781595] [c002eac83920] [c0721d28] > .panic+0xe4/0x264 > [ 763.781598] [c002eac839c0] [c00886e4] > .do_exit+0x954/0x960 > [ 763.781601] [c002eac83ac0] [c00889d4] > .do_group_exit+0x54/0xf0 > [ 763.781604] [c002eac83b50] [c009be28] > .get_signal_to_deliver+0x1f8/0x730 > [ 763.781606] [c002eac83c60] [c0017924] > .do_signal+0x54/0x320 > [ 763.781608] [c002eac83da0] [c0017d74] > .do_notify_resume+0xb4/0xd0 > [ 763.781611] [c002eac83e30] [c0009e1c] > .ret_from_except_lite+0x48/0x4c > [ 763.781612] Write-error on swap-device (253:0:7546752) > [ 763.781613] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781615] Write-error on swap-device (253:0:7547008) > [ 763.781616] Sending IPI to other CPUs > [ 763.781616] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781618] Write-error on swap-device (253:0:7547392) > [ 763.781619] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781620] Write-error on swap-device (253:0:7547648) > [ 763.781622] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781623] Write-error on swap-device (253:0:7547904) > [ 763.781625] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781627] Write-error on swap-device (253:0:7548160) > [ 763.781628] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781630] Write-error on swap-device (253:0:7548416) > [ 763.781631] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781632] Write-error on swap-device (253:0:7548672) > [ 763.781634] sd 0:0:1:0: rejecting I/O to offline device > [ 763.781635] Write-error on swap-device (253:0:7548928) > [ 773.781972] ERROR: 1 cpu(s) not responding > > KERNEL: /boot/vmlinux-3.7.1+ > DUMPFILE: /var/crash/127.0.0.1-2013.01.09-19:12:02/vmcore > CPUS: 28 > DATE: Tue Jan 8 23:11:35 2013 > UPTIME: 00:12:43 > LOAD AVERAGE: 5.88, 4.82, 2.51 >TASKS: 278 > RELEASE: 3.7.1+ > VERSION: #0 SMP Tue Jan 8 06:59:49 EST 2013 > MACHINE: ppc64 (3550 Mhz) > MEMORY: 12 GB >PANIC: "Kernel panic - not syncing: Attempted to
RE: [PATCH v4 3/4] ARM: Exynos5250: Add clock information for dwc3-exynos
Vivek Gautam wrote: > > Hi Tomasz, > > > On Wed, Jan 16, 2013 at 8:35 PM, Vivek Gautam > wrote: > > Hi Tomasz, > > > > > > On Wed, Jan 16, 2013 at 1:19 PM, Tomasz Figa > wrote: > >> Hi Vivek, > >> > >> Don't you need also some clkdev lookup entry to make the clock available > >> in the driver? > >> > > > > This clock source we added with a motive of completion, however it's > > not being used as of now. > > As far as i could see the lookup structure contains clocks for devices > > having multiple instances. > > Do you feel that i should be adding an entry in clk_lookup structure ? > > May be i am missing here something. Can you please elaborate on the > > use-case of clk_lookup > > entries. > > > > Any suggestions on this please ? > Just note, I think you can do it based on Samsung common clock is for all of exynos stuff which will be done in a couple of days. Sorry for late it, because there were some problems. Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/4] drm: tegra: use the Common Display Framework
On 01/30/2013 11:02 AM, Alexandre Courbot wrote:
> Make the tegra-drm driver use the Common Display Framework, letting it
> control the panel state according to the DPMS status.
>
> A "nvidia,panel" property is added to the output node of the Tegra DC
> that references the panel connected to a given output.
>
> Signed-off-by: Alexandre Courbot
> ---
[...]
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 741b5dc..5e63c56 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> struct tegra_framebuffer {
> struct drm_framebuffer base;
> @@ -147,6 +148,9 @@ struct tegra_output {
>
> struct drm_encoder encoder;
> struct drm_connector connector;
> + struct display_entity this;
> + struct display_entity *output;
Could you pick up a somewhat meaningful name? You know, there are too
many variables with name "drm/connector/output/encoder"... :)
> + struct display_entity_notifier display_notifier;
> };
>
[...]
> +static int display_notify_callback(struct display_entity_notifier *notifier,
> +struct display_entity *entity, int event)
> +{
> + struct tegra_output *output = display_notifier_to_output(notifier);
> + struct device_node *pnode;
> +
> + switch (event) {
> + case DISPLAY_ENTITY_NOTIFIER_CONNECT:
> + if (output->output)
> + break;
> +
> + pnode = of_parse_phandle(output->of_node, "nvidia,panel", 0);
> + if (!pnode)
> + break;
> +
> + if (entity->dev && entity->dev->of_node == pnode) {
> + dev_dbg(output->dev, "connecting panel\n");
> + output->output = display_entity_get(entity);
> + display_entity_connect(>this, output->output);
> + }
> + of_node_put(pnode);
> +
> + break;
> +
> + case DISPLAY_ENTITY_NOTIFIER_DISCONNECT:
> + if (!output->output || output->output != entity)
> + break;
> +
> + dev_dbg(output->dev, "disconnecting panel\n");
> + display_entity_disconnect(>this, output->output);
> + output->output = NULL;
> + display_entity_put(>this);
No "display_entity_get" for "output->this", so I don't think we need
"display_entity_put" here. If you register this entity with "release"
callback and you wanna release "output->this", call the "release"
function manually.
Only when you have "display_entity_get", use "display_entity_put" to
release.
> +
> + break;
> +
> + default:
> + dev_dbg(output->dev, "unhandled display event\n");
> + break;
> + }
> +
> + return 0;
> +}
> +
[...]
> int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
> {
> int connector, encoder, err;
> @@ -250,6 +341,23 @@ int tegra_output_init(struct drm_device *drm, struct
> tegra_output *output)
>
> output->encoder.possible_crtcs = 0x3;
>
> + /* register display entity */
> + memset(>this, 0, sizeof(output->this));
> + output->this.dev = drm->dev;
Use "output->dev" here. Actually the device you wanna register it to
display entity is the "encoder"(in drm terms), not "drm->dev". If we use
"drm->dev" here, we will have all same device for all encoders(HDMI,
DSI...).
> + output->this.ops.video = _output_video_ops;
> + err = display_entity_register(>this);
> + if (err) {
> + dev_err(output->dev, "cannot register display entity\n");
> + return err;
> + }
> +
> + /* register display notifier */
> + output->display_notifier.dev = NULL;
Set "display_notifier.dev" to NULL makes we have to compare with every
display entity, just like what you do in "display_notify_callback":
entity->dev && entity->dev->of_node == pnode
So can we get the "struct device *" of panel here? Seems currently the
"of" framework doesn't allow "device_node -> device".
> + output->display_notifier.notify = display_notify_callback;
> + err = display_entity_register_notifier(>display_notifier);
> + if (err)
> + return err;
> +
> return 0;
>
> free_hpd:
> @@ -260,6 +368,12 @@ free_hpd:
>
> int tegra_output_exit(struct tegra_output *output)
> {
> + if (output->output)
> + display_entity_put(output->output);
> +
> + display_entity_unregister_notifier(>display_notifier);
> + display_entity_unregister(>this);
> +
> if (gpio_is_valid(output->hpd_gpio)) {
> free_irq(output->hpd_irq, output);
> gpio_free(output->hpd_gpio);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH v5 03/14] ARM: edma: add AM33XX support to the private EDMA API
On Mon, Jan 28, 2013 at 09:27:24PM +0200, Andy Shevchenko wrote:
> On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter wrote:
> > Adds support for parsing the TI EDMA DT data into the required
> > EDMA private API platform data. Enables runtime PM support to
> > initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
> > support.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/common/edma.c | 314
> > ++--
> > include/linux/platform_data/edma.h |1 +
> > 2 files changed, 306 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> > index 2dce245..beeb1d2 100644
> > --- a/arch/arm/common/edma.c
> > +++ b/arch/arm/common/edma.c
> > @@ -24,6 +24,13 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > #include
> >
> > @@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
> > */
> > int edma_alloc_slot(unsigned ctlr, int slot)
> > {
> > + if (!edma_cc[ctlr])
> > + return -EINVAL;
> > +
> > if (slot >= 0)
> > slot = EDMA_CHAN_SLOT(slot);
> >
> > @@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
> > EXPORT_SYMBOL(edma_clear_event);
> >
> > /*---*/
> > +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> > +const char *propname, s8
> > *out_values,
> > +size_t sz)
>
> I'm sorry I didn't get why you couldn't use of_property_read_u8_array() ?
> The similar comment to u16 and so on.
There's some manipulation of the legacy Davinci platform data
structures going on here. The driving reason was to not change any of
the davinci platforms pdata which uses s8/s16 tables of mapping values
with signed values as terminators. These versions below add the
convert to the signed value and terminate the array as needed by the
existing driver. This will all go away when the driver is rewritten and
merged into drivers/dma/edma.c. At that point I want to throwaway all
these legacy data structures. First, there's some more drivers to
convert to dmaengine api.
-Matt
>
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
> > +const char *propname, s16
> > *out_values,
> > +size_t sz)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_xbar_event_map(struct device *dev,
> > + struct device_node *node,
> > + struct edma_soc_info *pdata, int len)
> > +{
> > + int ret = 0;
> > + int i;
> > + struct resource res;
> > + void *xbar;
> > + const s16 (*xbar_chans)[2];
> > + u32 shift, offset, mux;
> > +
> > + xbar_chans = devm_kzalloc(dev,
> > + len/sizeof(s16) + 2*sizeof(s16),
> > + GFP_KERNEL);
> > + if (!xbar_chans)
> > + return -ENOMEM;
> > +
> > + ret = of_address_to_resource(node, 1, );
> > + if (IS_ERR_VALUE(ret))
> > + return -EIO;
> > +
> > + xbar = devm_ioremap(dev, res.start, resource_size());
> > + if (!xbar)
> > + return -ENOMEM;
> > +
> > + ret = edma_of_read_u32_to_s16_array(node,
> > + "ti,edma-xbar-event-map",
> > + (s16 *)xbar_chans,
> > + len/sizeof(u32));
> > + if (IS_ERR_VALUE(ret))
> > + return -EIO;
> > +
> > +
Re: [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
Hi Luciano, On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote: Hi Sourav, On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote: Booting 3.8-rc4 om omap 4430sdp results in the following error omap_i2c 4807.i2c: did not get pins for i2c error: -19 [1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz [1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 [1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz [1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19 [1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz [1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19 [1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz This happens because omap4 dts file is not adapted to use i2c through pinctrl framework. Populating i2c pinctrl data to get rid of the error. Tested on omap4430 sdp with 3.8-rc4 kernel. Signed-off-by: Sourav Poddar Reported-by: Santosh Shilimkar --- Could you do the same thing for panda? I'm getting the same kind of errors with it: Sure, I will do that. [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [...] [2.884826] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 [2.890686] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz [2.892028] omap_i2c 4806.i2c: did not get pins for i2c error: -19 [2.899047] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz [2.906677] omap_i2c 4835.i2c: did not get pins for i2c error: -19 [2.912872] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz -- Cheers, Luca. Thanks, Sourav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Add 4 tracepoint events for vfs
From: chenggang@gmail.com If the engineers want to analyze the file access behavior of some applications without source code, perf tools with some appropriate tracepoints events in the VFS subsystem are excellent choice. The system engineers or developers of server software require to know what files are accessed by the target processes with in a period of time. Then they can find the hot applications and the hot files. For this requirements, we added 2 tracepoint events at the begin of generic_file_aio_read() and generic_file_aio_write(). Many database systems use their own page cache subsystems and use the direct IO to access the disks. Sometimes, the system engineers want to know the misses rate of the database system's page cache. This requirements can be satisfied by recording the database's file access behavior through the way of direct IO. So, we added 2 tracepoint events at the direct IO branch in generic_file_aio_read() and generic_file_aio_write(). Then, we will extend the perf's function by python script to use these new tracepoint events. The 4 new tracepoint events are: 1) generic_file_aio_read Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:__data_loc char[] fname; offset:32; size:4; signed:1; 2) generic_file_aio_write Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:__data_loc char[] fname; offset:32; size:4; signed:1; 3) direct_io_read Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; 4) direct_io_write Format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:int common_padding; offset:8; size:4; signed:1; field:long long pos;offset:16; size:8; signed:1; field:unsigned long bytes; offset:24; size:8; signed:0; field:unsigned char fname[100]; offset:32; size:100; signed:0; Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: David Ahern Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Arjan van de Ven Cc: Namhyung Kim Cc: Yanmin Zhang Cc: Wu Fengguang Cc: Mike Galbraith Cc: Andrew Morton Signed-off-by: Chenggang Qin --- include/trace/events/vfs.h | 62 mm/filemap.c | 18 + 2 files changed, 80 insertions(+) create mode 100644 include/trace/events/vfs.h diff --git a/include/trace/events/vfs.h b/include/trace/events/vfs.h new file mode 100644 index 000..384ff29 --- /dev/null +++ b/include/trace/events/vfs.h @@ -0,0 +1,62 @@ +#undef TRACE_SYSTEM +#define TRACE_SYSTEM vfs +#define TRACE_INCLUDE_FILE vfs + +#if !defined(_TRACE_EVENTS_VFS_H) || defined(TRACE_HEADER_MULTI_READ) +#define _TRACE_EVENTS_VFS_H + +#include + +#include + +DECLARE_EVENT_CLASS(vfs_filerw_template, + + TP_PROTO(long long pos, unsigned long bytes, unsigned char *fname), + + TP_ARGS(pos, bytes, fname), + + TP_STRUCT__entry( + __field(long long, pos ) + __field(unsigned long, bytes ) + __string( fname, fname
Re: [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Wed, Jan 23, 2013 at 10:28:46PM +, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Matt Porter wrote:
> > Adds a dma_request_slave_channel_compat() wrapper which accepts
> > both the arguments from dma_request_channel() and
> > dma_request_slave_channel(). Based on whether the driver is
> > instantiated via DT, the appropriate channel request call will be
> > made.
> >
> > This allows for a much cleaner migration of drivers to the
> > dmaengine DT API as platforms continue to be mixed between those
> > that boot using DT and those that do not.
>
> I noticed today some drivers in linux-next that rely on this patch,
> but the patch itself still missing from -next.
>
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
> > dma_async_tx_descriptor *tx);
> > struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> > struct dma_chan *net_dma_find_channel(void);
> > #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x,
> > y)
> > +static inline struct dma_chan
> > +*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
> > + void *fn_param, struct device *dev,
> > + char *name)
> > +{
> > + if (dev->of_node)
> > + return dma_request_slave_channel(dev, name);
> > + else
> > + return dma_request_channel(mask, fn, fn_param);
> > +}
>
> Hmm, dma_request_channel is actually a macro that passes mask by reference,
> presumably because it can get modified by the filter function. Also, there
> may be cases where we do have an of_node but don't use the dma binding
> yet, or where dma_request_slave_channel doesn't actually use DT information
> but rather one of the other methods that Vinod was talking about adding.
>
> I think what it should look like instead is the below.
Yes, looks correct now, thanks. I've incorporated it into v6.
-Matt
>
> Arnd
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bfcdecb..b6ffd7d 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -993,6 +993,19 @@ static inline void dma_release_channel(struct dma_chan
> *chan)
> }
> #endif
>
> +static inline struct dma_chan
> *__dma_request_slave_channel_compat(dma_cap_mask_t *mask,
> + dma_filter_fn fn, void *fn_param, struct device
> *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
> +
> /* --- DMA device --- */
>
> int dma_async_device_register(struct dma_device *device);
> @@ -1001,6 +1014,8 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
>
> /* --- Helper iov-locking functions --- */
>
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 40/71] ARC: OProfile support
On Tuesday 29 January 2013 10:35 PM, James Hogan wrote: > Hi Vineet, > > You don't appear to define CONFIG_HW_PERF_EVENTS, so > include/linux/oprofile.h will presumably define oprofile_perf_init as > just a pr_info(...); return -ENODEV; > > Similarly drivers/oprofile/oprofile_perf.o doesn't seem to be being built. > > I'm probably missing something somewhere? Not much :-) oprofile_arch_init() failure causes oprofile to fall back to timer based PC only sampling - for coarse grained profiling. I'll soon be starting on integratign the hardware counter support to both oprofile/perf. FWIW, I just re-verified that latest upstream OProfile works fine with 3.8 kernel. [ARCLinux]$ uname -a Linux ARCLinux 3.8.0-rc4+ #2 Wed Jan 30 11:13:21 IST 2013 arc GNU/Linux [ARCLinux]$ ./opcontrol -v opcontrol: oprofile 0.9.9git compiled on Jan 30 2013 11:40:15 [ARCLinux]$ ./opcontrol --dump [ARCLinux]$ ./opreport -l /mnt/arc/next-linux/vmlinux Using /var/lib/oprofile/samples/ for samples directory. CPU: CPU with timer interrupt Profiling through timer interrupt samples %symbol name 856 69.3679 cpu_idle 614.9433 arch_local_irq_enable Thx for taking a look and if you are content - a Reviewed-by please (and for DeviceTree patch as well if that looks sane now). I'll start doing the same for metag patches after this one bug I'm debugging right now. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] perf, x86: Save/resotre LBR stack during context switch
From: "Yan, Zheng"
When the LBR call stack is enabled, it is necessary to save/restore
the stack on context switch. The solution is saving/restoring the
stack to/from task's perf event context. If task has no perf event
context, just flush the stack on context switch.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 18 +++--
arch/x86/kernel/cpu/perf_event.h | 13 +++-
arch/x86/kernel/cpu/perf_event_intel.c | 13 ++--
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 108 ++---
include/linux/perf_event.h | 6 +-
kernel/events/core.c | 64 ++---
6 files changed, 168 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 7981230..8fd8894 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1742,6 +1742,13 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void x86_pmu_branch_stack_sched(struct perf_event_context *ctx,
+ bool sched_in)
+{
+ if (x86_pmu.branch_stack_sched)
+ x86_pmu.branch_stack_sched(ctx, sched_in);
+}
+
static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
@@ -1750,6 +1757,9 @@ static void *x86_pmu_event_context_alloc(struct
perf_event_context *parent_ctx)
if (!ctx)
return ERR_PTR(-ENOMEM);
+ if (parent_ctx)
+ intel_pmu_lbr_init_context(ctx, parent_ctx);
+
return ctx;
}
@@ -1807,12 +1817,6 @@ static const struct attribute_group
*x86_pmu_attr_groups[] = {
NULL,
};
-static void x86_pmu_flush_branch_stack(void)
-{
- if (x86_pmu.flush_branch_stack)
- x86_pmu.flush_branch_stack();
-}
-
void perf_check_microcode(void)
{
if (x86_pmu.check_microcode)
@@ -1839,7 +1843,7 @@ static struct pmu pmu = {
.commit_txn = x86_pmu_commit_txn,
.event_idx = x86_pmu_event_idx,
- .flush_branch_stack = x86_pmu_flush_branch_stack,
+ .branch_stack_sched = x86_pmu_branch_stack_sched,
.event_context_alloc= x86_pmu_event_context_alloc,
};
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 3080e10..a6547f3 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -371,7 +371,6 @@ struct x86_pmu {
void(*cpu_dead)(int cpu);
void(*check_microcode)(void);
- void(*flush_branch_stack)(void);
/*
* Intel Arch Perfmon v2+
@@ -401,6 +400,8 @@ struct x86_pmu {
int lbr_nr;/* hardware stack size */
u64 lbr_sel_mask; /* LBR_SELECT valid bits */
const int *lbr_sel_map; /* lbr_select mappings */
+ void(*branch_stack_sched)(struct perf_event_context *ctx,
+ bool sched_in);
/*
* Extra registers for events
@@ -423,6 +424,12 @@ enum {
struct x86_perf_event_context {
struct perf_event_context ctx;
+
+ u64 lbr_from[MAX_LBR_ENTRIES];
+ u64 lbr_to[MAX_LBR_ENTRIES];
+ u64 lbr_stack_gen;
+ int lbr_callstack_users;
+ bool lbr_stack_saved;
};
#define x86_add_quirk(func_) \
@@ -650,8 +657,12 @@ void intel_pmu_pebs_disable_all(void);
void intel_ds_init(void);
+void intel_pmu_lbr_init_context(struct perf_event_context *child_ctx,
+ struct perf_event_context *parent_ctx);
void intel_pmu_lbr_reset(void);
+void intel_pmu_lbr_sched(struct perf_event_context *ctx, bool sched_in);
+
void intel_pmu_lbr_enable(struct perf_event *event);
void intel_pmu_lbr_disable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index fbb977e..61c5c17 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1807,16 +1807,11 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
}
-static void intel_pmu_flush_branch_stack(void)
+static void intel_pmu_branch_stack_sched(struct perf_event_context *ctx,
+bool sched_in)
{
- /*
-* Intel LBR does not tag entries with the
-* PID of the current task, then we need to
-* flush it on ctxsw
-* For now, we simply reset it
-*/
if (x86_pmu.lbr_nr)
- intel_pmu_lbr_reset();
+ intel_pmu_lbr_sched(ctx, sched_in);
}
PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
@@ -1882,7 +1877,7 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_starting =
[PATCH 2/7] perf, x86: Basic Haswell LBR call stack support
From: "Yan, Zheng"
The new HSW call stack feature provides a facility such that
unfiltered call data will be collected as normal, but as return
instructions are executed the last captured branch record is
popped from the LBR stack. Thus, branch information relative to
leaf functions will not be captured, while preserving the call
stack information of the main line execution path.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 7 ++-
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 89 ++
include/uapi/linux/perf_event.h| 2 +-
4 files changed, 75 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 71e87e0..ed1e822 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -415,7 +415,10 @@ struct x86_pmu {
};
enum {
- PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE,
+
+ PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
#define x86_add_quirk(func_) \
@@ -663,6 +666,8 @@ void intel_pmu_lbr_init_atom(void);
void intel_pmu_lbr_init_snb(void);
+void intel_pmu_lbr_init_hsw(void);
+
int intel_pmu_setup_lbr_filter(struct perf_event *event);
int p4_pmu_init(void);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index fa20a19..fbb977e 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2263,7 +2263,7 @@ __init int intel_pmu_init(void)
memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
- intel_pmu_lbr_init_nhm();
+ intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_hsw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 2bac8ac..88367a2 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -31,6 +31,7 @@ enum {
#define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
#define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
#define LBR_FAR_BIT8 /* do not capture far branches */
+#define LBR_CALL_STACK_BIT 9 /* enable call stack */
#define LBR_KERNEL (1 << LBR_KERNEL_BIT)
#define LBR_USER (1 << LBR_USER_BIT)
@@ -41,6 +42,7 @@ enum {
#define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
#define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
#define LBR_FAR(1 << LBR_FAR_BIT)
+#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
#define LBR_PLM (LBR_KERNEL | LBR_USER)
@@ -66,24 +68,25 @@ enum {
* x86control flow changes include branches, interrupts, traps, faults
*/
enum {
- X86_BR_NONE = 0, /* unknown */
-
- X86_BR_USER = 1 << 0, /* branch target is user */
- X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
-
- X86_BR_CALL = 1 << 2, /* call */
- X86_BR_RET = 1 << 3, /* return */
- X86_BR_SYSCALL = 1 << 4, /* syscall */
- X86_BR_SYSRET = 1 << 5, /* syscall return */
- X86_BR_INT = 1 << 6, /* sw interrupt */
- X86_BR_IRET = 1 << 7, /* return from interrupt */
- X86_BR_JCC = 1 << 8, /* conditional */
- X86_BR_JMP = 1 << 9, /* jump */
- X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
- X86_BR_IND_CALL = 1 << 11,/* indirect calls */
- X86_BR_ABORT= 1 << 12,/* transaction abort */
- X86_BR_INTX = 1 << 13,/* in transaction */
- X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_NONE = 0, /* unknown */
+
+ X86_BR_USER = 1 << 0, /* branch target is user */
+ X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
+
+ X86_BR_CALL = 1 << 2, /* call */
+ X86_BR_RET = 1 << 3, /* return */
+ X86_BR_SYSCALL = 1 << 4, /* syscall */
+ X86_BR_SYSRET = 1 << 5, /* syscall return */
+ X86_BR_INT = 1 << 6, /* sw interrupt */
+ X86_BR_IRET = 1 << 7, /* return from interrupt */
+ X86_BR_JCC = 1 << 8, /* conditional */
+ X86_BR_JMP = 1 << 9, /* jump */
+ X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
+ X86_BR_IND_CALL = 1 << 11,/* indirect calls */
+ X86_BR_ABORT= 1 << 12,/* transaction abort */
+ X86_BR_INTX = 1 << 13,/* in transaction */
+
[PATCH V9 13/13] MIPS: Loongson: Add a Loongson-3 default config file
Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan --- arch/mips/configs/loongson3_defconfig | 330 + 1 files changed, 330 insertions(+), 0 deletions(-) create mode 100644 arch/mips/configs/loongson3_defconfig diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig new file mode 100644 index 000..3b76056 --- /dev/null +++ b/arch/mips/configs/loongson3_defconfig @@ -0,0 +1,329 @@ +CONFIG_MACH_LOONGSON=y +CONFIG_LEMOTE_MACH3A=y +CONFIG_LOONGSON_BIGMEM=y +CONFIG_CPU_LOONGSON3=y +CONFIG_64BIT=y +CONFIG_PAGE_SIZE_16KB=y +CONFIG_SPARSEMEM_MANUAL=y +CONFIG_KSM=y +CONFIG_SMP=y +CONFIG_NR_CPUS=4 +CONFIG_HZ_256=y +CONFIG_PREEMPT=y +CONFIG_KEXEC=y +CONFIG_EXPERIMENTAL=y +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_KERNEL_LZMA=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_AUDIT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_CPUSETS=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_MEMCG=y +CONFIG_MEMCG_SWAP=y +CONFIG_BLK_CGROUP=y +CONFIG_SCHED_AUTOGROUP=y +CONFIG_SYSFS_DEPRECATED=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_EMBEDDED=y +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_BLK_DEV_INTEGRITY=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_IOSCHED_DEADLINE=m +CONFIG_CFQ_GROUP_IOSCHED=y +CONFIG_PCI=y +CONFIG_HT_PCI=y +CONFIG_PCIEPORTBUS=y +CONFIG_HOTPLUG_PCI_PCIE=m +# CONFIG_PCIEAER is not set +CONFIG_PCIEASPM_PERFORMANCE=y +CONFIG_HOTPLUG_PCI=y +CONFIG_HOTPLUG_PCI_SHPC=m +CONFIG_BINFMT_MISC=m +CONFIG_MIPS32_COMPAT=y +CONFIG_MIPS32_O32=y +CONFIG_MIPS32_N32=y +CONFIG_PM_RUNTIME=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_XFRM_USER=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_NETFILTER=y +CONFIG_NETFILTER_NETLINK_LOG=m +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m +CONFIG_NETFILTER_XT_TARGET_MARK=m +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m +CONFIG_NETFILTER_XT_MATCH_COMMENT=m +CONFIG_NETFILTER_XT_MATCH_DCCP=m +CONFIG_NETFILTER_XT_MATCH_ESP=m +CONFIG_NETFILTER_XT_MATCH_LENGTH=m +CONFIG_NETFILTER_XT_MATCH_LIMIT=m +CONFIG_NETFILTER_XT_MATCH_MAC=m +CONFIG_NETFILTER_XT_MATCH_MARK=m +CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m +CONFIG_NETFILTER_XT_MATCH_QUOTA=m +CONFIG_NETFILTER_XT_MATCH_REALM=m +CONFIG_NETFILTER_XT_MATCH_STATISTIC=m +CONFIG_NETFILTER_XT_MATCH_STRING=m +CONFIG_NETFILTER_XT_MATCH_TCPMSS=m +CONFIG_IP_VS=m +CONFIG_IP_NF_QUEUE=m +CONFIG_IP_NF_IPTABLES=m +CONFIG_IP_NF_MATCH_AH=m +CONFIG_IP_NF_MATCH_ECN=m +CONFIG_IP_NF_MATCH_TTL=m +CONFIG_IP_NF_FILTER=m +CONFIG_IP_NF_TARGET_REJECT=m +CONFIG_IP_NF_TARGET_ULOG=m +CONFIG_IP_NF_MANGLE=m +CONFIG_IP_NF_TARGET_ECN=m +CONFIG_IP_NF_TARGET_TTL=m +CONFIG_IP_NF_RAW=m +CONFIG_IP_NF_ARPTABLES=m +CONFIG_IP_NF_ARPFILTER=m +CONFIG_IP_NF_ARP_MANGLE=m +CONFIG_IP_SCTP=m +CONFIG_L2TP=m +CONFIG_CFG80211=m +CONFIG_CFG80211_WEXT=y +CONFIG_MAC80211=m +CONFIG_RFKILL=m +CONFIG_RFKILL_INPUT=y +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_MTD=m +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_CRYPTOLOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=8192 +CONFIG_RAID_ATTRS=m +CONFIG_SCSI_TGT=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR=y +CONFIG_CHR_DEV_SG=y +CONFIG_CHR_DEV_SCH=m +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_CONSTANTS=y +CONFIG_SCSI_LOGGING=y +CONFIG_SCSI_SPI_ATTRS=m +CONFIG_SCSI_FC_ATTRS=m +CONFIG_SCSI_ISCSI_ATTRS=m +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_PATA_ATIIXP=y +CONFIG_MD=y +CONFIG_BLK_DEV_DM=m +CONFIG_DM_CRYPT=m +CONFIG_DM_SNAPSHOT=m +CONFIG_DM_MIRROR=m +CONFIG_DM_ZERO=m +CONFIG_NETDEVICES=y +CONFIG_TUN=m +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_NET_VENDOR_ADAPTEC is not set +# CONFIG_NET_VENDOR_ALTEON is not set +# CONFIG_NET_VENDOR_AMD is not set +# CONFIG_NET_VENDOR_ATHEROS is not set +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_BROCADE is not set +# CONFIG_NET_VENDOR_CHELSIO is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_CISCO is not set +# CONFIG_NET_VENDOR_DEC is not set +# CONFIG_NET_VENDOR_DLINK is not set +# CONFIG_NET_VENDOR_EMULEX is not set +# CONFIG_NET_VENDOR_EXAR is not set +# CONFIG_NET_VENDOR_FUJITSU is not set +# CONFIG_NET_VENDOR_HP is not set +CONFIG_E1000=y +CONFIG_E1000E=y +CONFIG_IGB=y +# CONFIG_NET_VENDOR_I825XX is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MELLANOX is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MYRI is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_NVIDIA is not set +# CONFIG_NET_VENDOR_OKI is not set +# CONFIG_NET_PACKET_ENGINE is
[PATCH 1/7] perf, x86: Reduce lbr_sel_map size
From: "Yan, Zheng"
The index of lbr_sel_map is bit value of perf branch_sample_type.
By using bit shift as index, we can reduce lbr_sel_map size.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 4 +++
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 50 ++
include/uapi/linux/perf_event.h| 42 +
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index ba5d043..71e87e0 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -414,6 +414,10 @@ struct x86_pmu {
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
};
+enum {
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 5455a00..2bac8ac 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -61,10 +61,6 @@ enum {
#define LBR_FROM_FLAG_INTX (1ULL << 62)
#define LBR_FROM_FLAG_ABORT(1ULL << 61)
-#define for_each_branch_sample_type(x) \
- for ((x) = PERF_SAMPLE_BRANCH_USER; \
-(x) < PERF_SAMPLE_BRANCH_MAX; (x) <<= 1)
-
/*
* x86control flow change classification
* x86control flow changes include branches, interrupts, traps, faults
@@ -378,14 +374,14 @@ static int intel_pmu_setup_hw_lbr_filter(struct
perf_event *event)
{
struct hw_perf_event_extra *reg;
u64 br_type = event->attr.branch_sample_type;
- u64 mask = 0, m;
- u64 v;
+ u64 mask = 0, v;
+ int i;
- for_each_branch_sample_type(m) {
- if (!(br_type & m))
+ for (i = 0; i < PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE; i++) {
+ if (!(br_type & (1U << i)))
continue;
- v = x86_pmu.lbr_sel_map[m];
+ v = x86_pmu.lbr_sel_map[i];
if (v == LBR_NOT_SUPP)
return -EOPNOTSUPP;
@@ -631,33 +627,33 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
/*
* Map interface branch filters onto LBR filters
*/
-static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_REL_JMP
- | LBR_IND_JMP | LBR_FAR,
+static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_REL_JMP
+ | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include REL_JMP+IND_JMP to get CALL branches
*/
- [PERF_SAMPLE_BRANCH_ANY_CALL] =
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] =
LBR_REL_CALL | LBR_IND_CALL | LBR_REL_JMP | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include IND_JMP to capture IND_CALL
*/
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL | LBR_IND_JMP,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL | LBR_IND_JMP,
};
-static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_FAR,
- [PERF_SAMPLE_BRANCH_ANY_CALL] = LBR_REL_CALL | LBR_IND_CALL
- | LBR_FAR,
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL,
+static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] = LBR_REL_CALL | LBR_IND_CALL
+ | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL,
};
/* core */
diff --git a/include/uapi/linux/perf_event.h
[PATCH V9 12/13] MIPS: Loongson 3: Add CPU hotplug support
Tips of Loongson's CPU hotplug:
1, To fully shutdown a core in Loongson 3, the target core should go to
CKSEG1 and flush all L1 cache entries at first. Then, another core
(usually Core 0) can safely disable the clock of the target core. So
play_dead() call loongson3_play_dead() via CKSEG1 (both uncached and
unmmaped).
2, The default clocksource of Loongson is MIPS. Since clock source is a
global device, timekeeping need the CP0' Count registers of each core
be synchronous. Thus, when a core is up, we use a SMP_ASK_C0COUNT IPI
to ask Core-0's Count.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/Kconfig |1 +
arch/mips/include/asm/mach-loongson/loongson.h |6 +-
arch/mips/include/asm/smp.h|1 +
arch/mips/loongson/loongson-3/irq.c| 10 ++
arch/mips/loongson/loongson-3/smp.c| 178 +++-
5 files changed, 190 insertions(+), 6 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index bddf029..6f65cfb 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -269,6 +269,7 @@ config LASAT
config MACH_LOONGSON
bool "Loongson family of machines"
select SYS_SUPPORTS_ZBOOT
+ select SYS_SUPPORTS_HOTPLUG_CPU
help
This enables the support of Loongson family of machines.
diff --git a/arch/mips/include/asm/mach-loongson/loongson.h
b/arch/mips/include/asm/mach-loongson/loongson.h
index f573e47..573eed8 100644
--- a/arch/mips/include/asm/mach-loongson/loongson.h
+++ b/arch/mips/include/asm/mach-loongson/loongson.h
@@ -247,6 +247,9 @@ static inline void do_perfcnt_IRQ(void)
#define LOONGSON_PXARB_CFG LOONGSON_REG(LOONGSON_REGBASE + 0x68)
#define LOONGSON_PXARB_STATUS LOONGSON_REG(LOONGSON_REGBASE + 0x6c)
+/* Chip Config */
+#define LOONGSON_CHIPCFG0 LOONGSON_REG(LOONGSON_REGBASE + 0x80)
+
/* pcimap */
#define LOONGSON_PCIMAP_PCIMAP_LO0 0x003f
@@ -262,9 +265,6 @@ static inline void do_perfcnt_IRQ(void)
#ifdef CONFIG_CPU_SUPPORTS_CPUFREQ
#include
extern struct cpufreq_frequency_table loongson2_clockmod_table[];
-
-/* Chip Config */
-#define LOONGSON_CHIPCFG0 LOONGSON_REG(LOONGSON_REGBASE + 0x80)
#endif
/*
diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp.h
index f33b5fd..4527a41 100644
--- a/arch/mips/include/asm/smp.h
+++ b/arch/mips/include/asm/smp.h
@@ -42,6 +42,7 @@ extern int __cpu_logical_map[NR_CPUS];
#define SMP_ICACHE_FLUSH 0x4
/* Used by kexec crashdump to save all cpu's state */
#define SMP_DUMP 0x8
+#define SMP_ASK_C0COUNT0x10
extern volatile cpumask_t cpu_callin_map;
diff --git a/arch/mips/loongson/loongson-3/irq.c
b/arch/mips/loongson/loongson-3/irq.c
index 27aef31..83f84e6 100644
--- a/arch/mips/loongson/loongson-3/irq.c
+++ b/arch/mips/loongson/loongson-3/irq.c
@@ -85,3 +85,13 @@ void __init mach_init_irq(void)
set_c0_status(STATUSF_IP2 | STATUSF_IP6);
}
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+void fixup_irqs(void)
+{
+ irq_cpu_offline();
+ clear_c0_status(ST0_IM);
+}
+
+#endif
diff --git a/arch/mips/loongson/loongson-3/smp.c
b/arch/mips/loongson/loongson-3/smp.c
index cb996d5..7327cb2 100644
--- a/arch/mips/loongson/loongson-3/smp.c
+++ b/arch/mips/loongson/loongson-3/smp.c
@@ -30,6 +30,9 @@
#include "smp.h"
+DEFINE_PER_CPU(int, cpu_state);
+DEFINE_PER_CPU(uint32_t, core0_c0count);
+
/* read a 64bit value from ipi register */
uint64_t loongson3_ipi_read64(void * addr)
{
@@ -169,8 +172,8 @@ static void loongson3_send_ipi_mask(const struct cpumask
*mask, unsigned int act
void loongson3_ipi_interrupt(struct pt_regs *regs)
{
- int cpu = smp_processor_id();
- unsigned int action;
+ int i, cpu = smp_processor_id();
+ unsigned int action, c0count;
/* Load the ipi register to figure out what we're supposed to do */
action = loongson3_ipi_read32(ipi_status0_regs[cpu]);
@@ -185,14 +188,24 @@ void loongson3_ipi_interrupt(struct pt_regs *regs)
if (action & SMP_CALL_FUNCTION) {
smp_call_function_interrupt();
}
+
+ if (action & SMP_ASK_C0COUNT) {
+ BUG_ON(cpu != 0);
+ c0count = read_c0_count();
+ for (i=1; i < nr_cpus_loongson; i++)
+ per_cpu(core0_c0count, i) = c0count;
+ }
}
+#define MAX_LOOPS 1200
/*
* SMP init and finish on secondary CPUs
*/
void __cpuinit loongson3_init_secondary(void)
{
int i;
+ uint32_t initcount;
+ unsigned int cpu = smp_processor_id();
unsigned int imask = STATUSF_IP7 | STATUSF_IP6 |
STATUSF_IP3 | STATUSF_IP2;
@@ -202,11 +215,24 @@ void __cpuinit loongson3_init_secondary(void)
for (i = 0; i < nr_cpus_loongson; i++) {
loongson3_ipi_write32(0x, ipi_en0_regs[i]);
[PATCH 0/7] perf, x86: Haswell LBR call stack support
From: "Yan, Zheng" Haswell has a new feature that utilizes the existing Last Branch Record facility to record call chains. When the feature is enabled, function call will be collected as normal, but as return instructions are executed the last captured branch record is popped from the on-chip LBR registers. The LBR call stack facility can help perf to get call chains of progam without frame pointer. When perf tool requests PERF_SAMPLE_CALLCHAIN + PERF_SAMPLE_BRANCH_USER, this feature is dynamically enabled by default. This feature can be disabled/enabled through an attribute file in the cpu pmu sysfs directory. The LBR call stack has following known limitations 1. Zero length calls are not filtered out by hardware 2. Exception handing such as setjmp/longjmp will have calls/returns not match 3. Pushing different return address onto the stack will have calls/returns not match The patch series depends on Andi's "Basic perf PMU support for Haswell v1" Available from https://github.com/ukernel/linux.git hws/pmu4 Regards Yan, Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] perf, core: Pass perf_sample_data to perf_callchain()
From: "Yan, Zheng"
New Intel CPU can record call chains by using existing last branch
record facility. perf_callchain_user() can make use of the call
chains recorded by hardware in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/arm/kernel/perf_event.c | 4 ++--
arch/powerpc/perf/callchain.c| 4 ++--
arch/sparc/kernel/perf_event.c | 4 ++--
arch/x86/kernel/cpu/perf_event.c | 4 ++--
include/linux/perf_event.h | 3 ++-
kernel/events/callchain.c| 8 +---
kernel/events/core.c | 2 +-
kernel/events/internal.h | 3 ++-
8 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index f9e8657..5b0c49f 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -566,8 +566,8 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp - 1;
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct frame_tail __user *tail;
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 74d1e78..b379ebc 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -482,8 +482,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
}
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
if (current_is_64bit())
perf_callchain_user_64(entry, regs);
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index b5c38fa..cba0306 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -1785,8 +1785,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
} while (entry->nr < PERF_MAX_STACK_DEPTH);
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
perf_callchain_store(entry, regs->tpc);
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 8fd8894..19e7e99 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1973,8 +1973,8 @@ perf_callchain_user32(struct pt_regs *regs, struct
perf_callchain_entry *entry)
}
#endif
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct stack_frame frame;
const void __user *fp;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f130c6c..fdf0019 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -706,7 +706,8 @@ extern void perf_event_fork(struct task_struct *tsk);
/* Callchains */
DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
-extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs);
+extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs,
+ struct perf_sample_data *data);
extern void perf_callchain_kernel(struct perf_callchain_entry *entry, struct
pt_regs *regs);
static inline void perf_callchain_store(struct perf_callchain_entry *entry,
u64 ip)
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c772061..bd7138a 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -30,7 +30,8 @@ __weak void perf_callchain_kernel(struct perf_callchain_entry
*entry,
}
__weak void perf_callchain_user(struct perf_callchain_entry *entry,
- struct pt_regs *regs)
+ struct pt_regs *regs,
+ struct perf_sample_data *data)
{
}
@@ -154,7 +155,8 @@ put_callchain_entry(int rctx)
}
struct perf_callchain_entry *
-perf_callchain(struct perf_event *event, struct pt_regs *regs)
+perf_callchain(struct perf_event *event, struct pt_regs *regs,
+ struct perf_sample_data *data)
{
int rctx;
struct perf_callchain_entry *entry;
@@ -195,7 +197,7 @@ perf_callchain(struct perf_event *event, struct pt_regs
*regs)
goto exit_put;
perf_callchain_store(entry, PERF_CONTEXT_USER);
- perf_callchain_user(entry, regs);
+ perf_callchain_user(entry, regs, data);
}
}
diff --git a/kernel/events/core.c
[PATCH V9 06/13] MIPS: Loongson 3: Add HT-linked PCI support
Loongson family machines use Hyper-Transport bus for inter-core
connection and device connection. The PCI bus is a subordinate
linked at HT1.
With UEFI-like firmware interface, We don't need fixup for PCI irq
routing.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/include/asm/mach-loongson/loongson.h |7 ++
arch/mips/include/asm/mach-loongson/pci.h |5 +
arch/mips/pci/Makefile |1 +
arch/mips/pci/fixup-loongson3.c| 65 +++
arch/mips/pci/ops-loongson3.c | 104
5 files changed, 182 insertions(+), 0 deletions(-)
create mode 100644 arch/mips/pci/fixup-loongson3.c
create mode 100644 arch/mips/pci/ops-loongson3.c
diff --git a/arch/mips/include/asm/mach-loongson/loongson.h
b/arch/mips/include/asm/mach-loongson/loongson.h
index 6a1bcf3..960811a 100644
--- a/arch/mips/include/asm/mach-loongson/loongson.h
+++ b/arch/mips/include/asm/mach-loongson/loongson.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
/* loongson internal northbridge initialization */
extern void bonito_irq_init(void);
@@ -101,7 +102,13 @@ static inline void do_perfcnt_IRQ(void)
#define LOONGSON_PCICFG_BASE 0x1fe8
#define LOONGSON_PCICFG_SIZE 0x0800 /* 2K */
#define LOONGSON_PCICFG_TOP(LOONGSON_PCICFG_BASE+LOONGSON_PCICFG_SIZE-1)
+
+#if defined(CONFIG_HT_PCI)
+#define LOONGSON_PCIIO_BASEloongson_pciio_base
+#else
#define LOONGSON_PCIIO_BASE0x1fd0
+#endif
+
#define LOONGSON_PCIIO_SIZE0x0010 /* 1M */
#define LOONGSON_PCIIO_TOP (LOONGSON_PCIIO_BASE+LOONGSON_PCIIO_SIZE-1)
diff --git a/arch/mips/include/asm/mach-loongson/pci.h
b/arch/mips/include/asm/mach-loongson/pci.h
index bc99dab..1212774 100644
--- a/arch/mips/include/asm/mach-loongson/pci.h
+++ b/arch/mips/include/asm/mach-loongson/pci.h
@@ -40,8 +40,13 @@ extern struct pci_ops loongson_pci_ops;
#else /* loongson2f/32bit & loongson2e */
/* this pci memory space is mapped by pcimap in pci.c */
+#ifdef CONFIG_CPU_LOONGSON3
+#define LOONGSON_PCI_MEM_START 0x4000UL
+#define LOONGSON_PCI_MEM_END 0x7effUL
+#else
#define LOONGSON_PCI_MEM_START LOONGSON_PCILO1_BASE
#define LOONGSON_PCI_MEM_END (LOONGSON_PCILO1_BASE + 0x0400 * 2)
+#endif
/* this is an offset from mips_io_port_base */
#define LOONGSON_PCI_IO_START 0x4000UL
diff --git a/arch/mips/pci/Makefile b/arch/mips/pci/Makefile
index ce995d3..22ab517 100644
--- a/arch/mips/pci/Makefile
+++ b/arch/mips/pci/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_MIPS_COBALT) += fixup-cobalt.o
obj-$(CONFIG_SOC_PNX8550) += fixup-pnx8550.o ops-pnx8550.o
obj-$(CONFIG_LEMOTE_FULOONG2E) += fixup-fuloong2e.o ops-loongson2.o
obj-$(CONFIG_LEMOTE_MACH2F)+= fixup-lemote2f.o ops-loongson2.o
+obj-$(CONFIG_LEMOTE_MACH3A)+= fixup-loongson3.o ops-loongson3.o
obj-$(CONFIG_MIPS_MALTA) += fixup-malta.o
obj-$(CONFIG_PMC_MSP7120_GW) += fixup-pmcmsp.o ops-pmcmsp.o
obj-$(CONFIG_PMC_MSP7120_EVAL) += fixup-pmcmsp.o ops-pmcmsp.o
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
new file mode 100644
index 000..e73a906
--- /dev/null
+++ b/arch/mips/pci/fixup-loongson3.c
@@ -0,0 +1,65 @@
+/*
+ * fixup-loongson3.c
+ *
+ * Copyright (C) 2012 Lemote, Inc.
+ * Author: Xiang Yu, xia...@lemote.com
+ * Chen Huacai, che...@lemote.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include
+#include
+
+static void print_fixup_info(const struct pci_dev * pdev)
+{
+ dev_info(>dev, "Device %x:%x, irq %d\n",
+ pdev->vendor, pdev->device, pdev->irq);
+}
+
+int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+ print_fixup_info(dev);
+
Re: [RFC 1/1] ima: digital signature verification using asymmetric keys
On Tue, Jan 29, 2013 at 11:58:53AM -0500, Vivek Goyal wrote: > On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote: > > The assumption has always been that the initramfs would be measured, for > > trusted boot, and appraised, for secure boot, before being executed. > > Hi Mimi, > > Ok. So for trusted boot, if initramfs is changed it will be detected. For > secureboot, atleast right now initramfs is not signed and appraised. But > I guess it could be added. > > But initramfs is generated by installer and installer does not have > private keys to sign it. So distributions could not sign initramfs. Right, there's a whole range of problems here. The first is that the initramfs has to contain the full set of drivers required to boot a given piece of hardware, and the precise set required varies between machines. Building a truly generic initramfs would result in significantly larger images. There's also an existing expectation that it be possible to break into initramfs execution for debugging purposes. Even ignoring that, most initramfs implementations aren't expected to be hardened against a user inserting shell control characters into the kernel command line. It would require significant engineering work to ensure that there's no way for an attacker to cause code execution before the key store has been locked. Shipping prebuilt initramfses is also difficult from a release engineering perspective. You'd need to keep track of the software versions that were included in the initramfs and ensure that the initramfs is rebuilt if any of those pieces of software are updated between the initramfs being generated and the software being shipped. Version skew could cause subtle bugs and also makes license compliance difficult. Finally, portions of the userspace in initramfs may be under licenses that require it to be possible for the end user to replace components. This isn't a problem as long as the keys in MOK can be used. There's additional small problems, like the initramfs containing the bootsplash theme and users expecting to be able to change that without having to generate crypto keys, but that's probably not a showstopper. But realistically, the first three problems make it unlikely that most distributions will be willing to depend on or ship pre-built initramfs images. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V9 11/13] MIPS: Loongson 3: Add Loongson-3 SMP support
IPI registers of Loongson-3 include IPI_SET, IPI_CLEAR, IPI_STATUS,
IPI_EN and IPI_MAILBOX_BUF. Each bit of IPI_STATUS indicate a type of
IPI and IPI_EN indicate whether the IPI is enabled. The sender write 1
to IPI_SET bits generate IPIs in IPI_STATUS, and receiver write 1 to
bits of IPI_CLEAR to clear IPIs. IPI_MAILBOX_BUF are used to deliver
more information about IPIs.
Why we change code in arch/mips/loongson/common/setup.c?
If without this change, when SMP configured, system cannot boot since
it hang at printk() in cgroup_init_early(). The root cause is:
console_trylock()
\-->down_trylock(_sem)
\-->raw_spin_unlock_irqrestore(>lock, flags)
\-->_raw_spin_unlock_irqrestore()(SMP/UP have different versions)
\-->__raw_spin_unlock_irqrestore() (following is the SMP case)
\-->do_raw_spin_unlock()
\-->arch_spin_unlock()
\-->nudge_writes()
\-->mb()
\-->wbflush()
\-->__wbflush()
In previous code __wbflush() is initialized in plat_mem_setup(), but
cgroup_init_early() is called before plat_mem_setup(). Therefore, In
this patch we make changes to avoid boot failure.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/loongson/common/init.c |5 +
arch/mips/loongson/common/setup.c |8 +-
arch/mips/loongson/loongson-3/Makefile |2 +
arch/mips/loongson/loongson-3/smp.c| 280
arch/mips/loongson/loongson-3/smp.h| 24 +++
5 files changed, 314 insertions(+), 5 deletions(-)
create mode 100644 arch/mips/loongson/loongson-3/smp.c
create mode 100644 arch/mips/loongson/loongson-3/smp.h
diff --git a/arch/mips/loongson/common/init.c b/arch/mips/loongson/common/init.c
index 1c29b19..30d20ad 100644
--- a/arch/mips/loongson/common/init.c
+++ b/arch/mips/loongson/common/init.c
@@ -12,6 +12,8 @@
#include
+extern struct plat_smp_ops loongson3_smp_ops;
+
/* Loongson CPU address windows config space base address */
unsigned long __maybe_unused _loongson_addrwincfg_base;
@@ -33,6 +35,9 @@ void __init prom_init(void)
/*init the uart base address */
prom_init_uart_base();
+#if defined(CONFIG_SMP)
+ register_smp_ops(_smp_ops);
+#endif
}
void __init prom_free_prom_memory(void)
diff --git a/arch/mips/loongson/common/setup.c
b/arch/mips/loongson/common/setup.c
index 27d826b..464cc5a 100644
--- a/arch/mips/loongson/common/setup.c
+++ b/arch/mips/loongson/common/setup.c
@@ -18,9 +18,6 @@
#include
#endif
-void (*__wbflush)(void);
-EXPORT_SYMBOL(__wbflush);
-
static void wbflush_loongson(void)
{
asm(".set\tpush\n\t"
@@ -32,10 +29,11 @@ static void wbflush_loongson(void)
".set mips0\n\t");
}
+void (*__wbflush)(void) = wbflush_loongson;
+EXPORT_SYMBOL(__wbflush);
+
void __init plat_mem_setup(void)
{
- __wbflush = wbflush_loongson;
-
#ifdef CONFIG_VT
#if defined(CONFIG_VGA_CONSOLE)
conswitchp = _con;
diff --git a/arch/mips/loongson/loongson-3/Makefile
b/arch/mips/loongson/loongson-3/Makefile
index b9968cd..70152b2 100644
--- a/arch/mips/loongson/loongson-3/Makefile
+++ b/arch/mips/loongson/loongson-3/Makefile
@@ -2,3 +2,5 @@
# Makefile for Loongson-3 family machines
#
obj-y += irq.o
+
+obj-$(CONFIG_SMP) += smp.o
diff --git a/arch/mips/loongson/loongson-3/smp.c
b/arch/mips/loongson/loongson-3/smp.c
new file mode 100644
index 000..cb996d5
--- /dev/null
+++ b/arch/mips/loongson/loongson-3/smp.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright (C) 2010, 2011, 2012, Lemote, Inc.
+ * Author: Chen Huacai, che...@lemote.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smp.h"
+
+/* read a 64bit value from ipi register */
+uint64_t loongson3_ipi_read64(void * addr)
+{
+ return *((volatile uint64_t *)addr);
+};
+
+/* write a 64bit value to ipi register */
+void loongson3_ipi_write64(uint64_t action, void * addr)
+{
+ *((volatile uint64_t *)addr) = action;
+ __wbflush();
+};
+
+/* read a 32bit value from ipi register */
+uint32_t loongson3_ipi_read32(void * addr)
+{
+ return *((volatile uint32_t *)addr);
[PATCH V9 10/13] MIPS: Loongson: Add Loongson-3 Kconfig options
Added Kconfig options include: Loongson-3 CPU and machine definition, CPU cache features, UEFI-like firmware interface, HT-linked PCI, and big memory support. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan --- arch/mips/Kconfig | 28 +++ arch/mips/loongson/Kconfig | 52 2 files changed, 80 insertions(+), 0 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index b129ca0..bddf029 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1557,6 +1557,18 @@ config CPU_LOONGSON2 select CPU_SUPPORTS_HIGHMEM select CPU_SUPPORTS_HUGEPAGES +config CPU_LOONGSON3 + bool "Loongson 3 CPU" + depends on SYS_HAS_CPU_LOONGSON3 + select CPU_SUPPORTS_32BIT_KERNEL + select CPU_SUPPORTS_64BIT_KERNEL + select CPU_SUPPORTS_HIGHMEM + select WEAK_ORDERING + select WEAK_REORDERING_BEYOND_LLSC + help + The Loongson 3 processor implements the MIPS III instruction set + with many extensions. + config CPU_LOONGSON1 bool select CPU_MIPS32 @@ -1583,6 +1595,11 @@ config SYS_HAS_CPU_LOONGSON2F select CPU_SUPPORTS_ADDRWINCFG if 64BIT select CPU_SUPPORTS_UNCACHED_ACCELERATED +config SYS_HAS_CPU_LOONGSON3 + bool + select CPU_SUPPORTS_CPUFREQ + select CPU_SUPPORTS_COHERENT_CACHE + config SYS_HAS_CPU_LOONGSON1B bool @@ -1717,6 +1734,8 @@ config CPU_SUPPORTS_HUGEPAGES bool config CPU_SUPPORTS_UNCACHED_ACCELERATED bool +config CPU_SUPPORTS_COHERENT_CACHE + bool config MIPS_PGD_C0_CONTEXT bool default y if 64BIT && CPU_MIPSR2 && !CPU_XLP @@ -2407,6 +2426,15 @@ config PCI your box. Other bus systems are ISA, EISA, or VESA. If you have PCI, say Y, otherwise N. +config HT_PCI + bool "Support for HT-linked PCI" + select PCI_DOMAINS + help + Loongson family machines use Hyper-Transport bus for inter-core + connection and device connection. The PCI bus is a subordinate + linked at HT. Choose Y unless you are using Loongson 2E/2F based + machines. + config PCI_DOMAINS bool diff --git a/arch/mips/loongson/Kconfig b/arch/mips/loongson/Kconfig index 263beb9..dd951b8 100644 --- a/arch/mips/loongson/Kconfig +++ b/arch/mips/loongson/Kconfig @@ -59,6 +59,33 @@ config LEMOTE_MACH2F These family machines include fuloong2f mini PC, yeeloong2f notebook, LingLoong allinone PC and so forth. + +config LEMOTE_MACH3A + bool "Lemote Loongson 3A family machines" + select ARCH_SPARSEMEM_ENABLE + select GENERIC_ISA_DMA_SUPPORT_BROKEN + select GENERIC_HARDIRQS_NO__DO_IRQ + select BOOT_ELF32 + select BOARD_SCACHE + select CSRC_R4K + select CEVT_R4K + select CPU_HAS_WB + select HW_HAS_PCI + select ISA + select I8259 + select IRQ_CPU + select SYS_HAS_CPU_LOONGSON3 + select SYS_HAS_EARLY_PRINTK + select SYS_SUPPORTS_SMP + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_HIGHMEM + select SYS_SUPPORTS_LITTLE_ENDIAN + select LOONGSON_MC146818 + select UEFI_FIRMWARE_INTERFACE + help + Lemote Loongson 3A family machines utilize the 3A revision of + Loongson processor and RS780/SBX00 chipset. endchoice config CS5536 @@ -86,8 +113,33 @@ config LOONGSON_UART_BASE default y depends on EARLY_PRINTK || SERIAL_8250 +config LOONGSON_BIGMEM + bool "Soft IOMMU Support for Big Memory (>4GB)" + depends on CPU_LOONGSON3 + select SWIOTLB + select ZONE_DMA32 + +config IOMMU_HELPER + bool + +config NEED_SG_DMA_LENGTH + bool + +config SWIOTLB + bool + select IOMMU_HELPER + select NEED_SG_DMA_LENGTH + select NEED_DMA_MAP_STATE + config LOONGSON_MC146818 bool default n +config ARCH_SPARSEMEM_ENABLE + bool + select SPARSEMEM_STATIC + +config UEFI_FIRMWARE_INTERFACE + bool + endif # MACH_LOONGSON -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] perf, x86: Discard zero length call entries in LBR call stack
From: "Yan, Zheng"
"Zero length call" uses the attribute of the call instruction to push
the immediate instruction pointer on to the stack and then pops off
that address into a register. This is accomplished without any matching
return instruction. It confuses the hardware and make the recorded call
stack incorrect. Try fixing the call stack by discarding zero length
call entries.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 910200b..0546689 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -86,7 +86,8 @@ enum {
X86_BR_ABORT= 1 << 12,/* transaction abort */
X86_BR_INTX = 1 << 13,/* in transaction */
X86_BR_NOTX = 1 << 14,/* not in transaction */
- X86_BR_CALL_STACK = 1 << 15,/* call stack */
+ X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
+ X86_BR_CALL_STACK = 1 << 16,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -103,13 +104,15 @@ enum {
X86_BR_JMP |\
X86_BR_IRQ |\
X86_BR_ABORT|\
-X86_BR_IND_CALL)
+X86_BR_IND_CALL |\
+X86_BR_ZERO_CALL)
#define X86_BR_ALL (X86_BR_PLM | X86_BR_ANY)
#define X86_BR_ANY_CALL \
(X86_BR_CALL|\
X86_BR_IND_CALL|\
+X86_BR_ZERO_CALL |\
X86_BR_SYSCALL |\
X86_BR_IRQ |\
X86_BR_INT)
@@ -625,6 +628,12 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
+ insn_get_immediate();
+ if (insn.immediate1.value == 0) {
+ /* zero length call */
+ ret = X86_BR_ZERO_CALL;
+ break;
+ }
case 0x9a: /* call far absolute */
ret = X86_BR_CALL;
break;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V9 09/13] MIPS: Loongson: Add swiotlb to support big memory (>4GB)
This is probably a workaround because Loongson doesn't support DMA
address above 4GB. If memory is more than 4GB, CONFIG_SWIOTLB and
ZONE_DMA32 should be selected. In this way, DMA pages are allocated
below 4GB preferably.
However, CONFIG_SWIOTLB+ZONE_DMA32 is not enough, so, we provide a
platform-specific dma_map_ops::set_dma_mask() to make sure each
driver's dma_mask and coherent_dma_mask is below 32-bit.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/include/asm/dma-mapping.h|5 +
.../mips/include/asm/mach-loongson/dma-coherence.h | 23 +++
arch/mips/loongson/common/Makefile |5 +
arch/mips/loongson/common/dma-swiotlb.c| 163
4 files changed, 196 insertions(+), 0 deletions(-)
create mode 100644 arch/mips/loongson/common/dma-swiotlb.c
diff --git a/arch/mips/include/asm/dma-mapping.h
b/arch/mips/include/asm/dma-mapping.h
index 006b43e..65fbf4c 100644
--- a/arch/mips/include/asm/dma-mapping.h
+++ b/arch/mips/include/asm/dma-mapping.h
@@ -48,9 +48,14 @@ static inline int dma_mapping_error(struct device *dev, u64
mask)
static inline int
dma_set_mask(struct device *dev, u64 mask)
{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
if(!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
+ if (ops->set_dma_mask)
+ return ops->set_dma_mask(dev, mask);
+
*dev->dma_mask = mask;
return 0;
diff --git a/arch/mips/include/asm/mach-loongson/dma-coherence.h
b/arch/mips/include/asm/mach-loongson/dma-coherence.h
index e143305..3d752e8 100644
--- a/arch/mips/include/asm/mach-loongson/dma-coherence.h
+++ b/arch/mips/include/asm/mach-loongson/dma-coherence.h
@@ -11,18 +11,34 @@
#ifndef __ASM_MACH_LOONGSON_DMA_COHERENCE_H
#define __ASM_MACH_LOONGSON_DMA_COHERENCE_H
+#ifdef CONFIG_SWIOTLB
+#include
+#endif
+
struct device;
+extern dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr);
+extern phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr);
static inline dma_addr_t plat_map_dma_mem(struct device *dev, void *addr,
size_t size)
{
+#ifdef CONFIG_CPU_LOONGSON3
+ return virt_to_phys(addr) < 0x1000 ?
+ (virt_to_phys(addr) | 0x8000) :
virt_to_phys(addr);
+#else
return virt_to_phys(addr) | 0x8000;
+#endif
}
static inline dma_addr_t plat_map_dma_mem_page(struct device *dev,
struct page *page)
{
+#ifdef CONFIG_CPU_LOONGSON3
+ return page_to_phys(page) < 0x1000 ?
+ (page_to_phys(page) | 0x8000) :
page_to_phys(page);
+#else
return page_to_phys(page) | 0x8000;
+#endif
}
static inline unsigned long plat_dma_addr_to_phys(struct device *dev,
@@ -30,6 +46,9 @@ static inline unsigned long plat_dma_addr_to_phys(struct
device *dev,
{
#if defined(CONFIG_CPU_LOONGSON2F) && defined(CONFIG_64BIT)
return (dma_addr > 0x8fff) ? dma_addr : (dma_addr & 0x0fff);
+#elif defined(CONFIG_CPU_LOONGSON3) && defined(CONFIG_64BIT)
+ return (dma_addr < 0x9000 && dma_addr >= 0x8000) ?
+ (dma_addr & 0x0fff) : dma_addr;
#else
return dma_addr & 0x7fff;
#endif
@@ -65,7 +84,11 @@ static inline int plat_dma_mapping_error(struct device *dev,
static inline int plat_device_is_coherent(struct device *dev)
{
+#ifdef CONFIG_DMA_NONCOHERENT
return 0;
+#else
+ return 1;
+#endif /* CONFIG_DMA_NONCOHERENT */
}
#endif /* __ASM_MACH_LOONGSON_DMA_COHERENCE_H */
diff --git a/arch/mips/loongson/common/Makefile
b/arch/mips/loongson/common/Makefile
index e526488..3a26109 100644
--- a/arch/mips/loongson/common/Makefile
+++ b/arch/mips/loongson/common/Makefile
@@ -25,3 +25,8 @@ obj-$(CONFIG_CS5536) += cs5536/
#
obj-$(CONFIG_LOONGSON_SUSPEND) += pm.o
+
+#
+# Big Memory Support
+#
+obj-$(CONFIG_LOONGSON_BIGMEM) += dma-swiotlb.o
diff --git a/arch/mips/loongson/common/dma-swiotlb.c
b/arch/mips/loongson/common/dma-swiotlb.c
new file mode 100644
index 000..6741f1b
--- /dev/null
+++ b/arch/mips/loongson/common/dma-swiotlb.c
@@ -0,0 +1,163 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static void *loongson_dma_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp, struct
dma_attrs *attrs)
+{
+ void *ret;
+
+ if (dma_alloc_from_coherent(dev, size, dma_handle, ))
+ return ret;
+
+ /* ignore region specifiers */
+ gfp &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
+
+#ifdef CONFIG_ZONE_DMA
+ if (dev == NULL)
+ gfp |= __GFP_DMA;
+ else if (dev->coherent_dma_mask <= DMA_BIT_MASK(24))
+ gfp |= __GFP_DMA;
+ else
+#endif
+#ifdef CONFIG_ZONE_DMA32
+ if (dev ==
[PATCH 3/7] perf, x86: Introduce x86 special perf event context
From: "Yan, Zheng"
The x86 special perf event context is named x86_perf_event_context,
We can enlarge it later to store PMU special data.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 12
arch/x86/kernel/cpu/perf_event.h | 4
include/linux/perf_event.h | 5 +
kernel/events/core.c | 28 ++--
4 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 375498a..7981230 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1742,6 +1742,17 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
+{
+ struct perf_event_context *ctx;
+
+ ctx = kzalloc(sizeof(struct x86_perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+
+ return ctx;
+}
+
static ssize_t get_attr_rdpmc(struct device *cdev,
struct device_attribute *attr,
char *buf)
@@ -1829,6 +1840,7 @@ static struct pmu pmu = {
.event_idx = x86_pmu_event_idx,
.flush_branch_stack = x86_pmu_flush_branch_stack,
+ .event_context_alloc= x86_pmu_event_context_alloc,
};
void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index ed1e822..3080e10 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -421,6 +421,10 @@ enum {
PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
+struct x86_perf_event_context {
+ struct perf_event_context ctx;
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index c32fba3..6122b2f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -264,6 +264,11 @@ struct pmu {
* flush branch stack on context-switches (needed in cpu-wide mode)
*/
void (*flush_branch_stack) (void);
+
+ /*
+* Allocate PMU special perf event context
+*/
+ void *(*event_context_alloc)(struct perf_event_context *parent_ctx);
};
/**
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b4078a0..908f2ad 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2721,13 +2721,20 @@ static void __perf_event_init_context(struct
perf_event_context *ctx)
}
static struct perf_event_context *
-alloc_perf_context(struct pmu *pmu, struct task_struct *task)
+alloc_perf_context(struct pmu *pmu, struct task_struct *task,
+ struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
- ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
- if (!ctx)
- return NULL;
+ if (pmu->event_context_alloc) {
+ ctx = pmu->event_context_alloc(parent_ctx);
+ if (IS_ERR(ctx))
+ return ctx;
+ } else {
+ ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+ }
__perf_event_init_context(ctx);
if (task) {
@@ -2813,10 +2820,11 @@ retry:
++ctx->pin_count;
raw_spin_unlock_irqrestore(>lock, flags);
} else {
- ctx = alloc_perf_context(pmu, task);
- err = -ENOMEM;
- if (!ctx)
+ ctx = alloc_perf_context(pmu, task, NULL);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
goto errout;
+ }
err = 0;
mutex_lock(>perf_event_mutex);
@@ -7132,9 +7140,9 @@ inherit_task_group(struct perf_event *event, struct
task_struct *parent,
* child.
*/
- child_ctx = alloc_perf_context(event->pmu, child);
- if (!child_ctx)
- return -ENOMEM;
+ child_ctx = alloc_perf_context(event->pmu, child, parent_ctx);
+ if (IS_ERR(child_ctx))
+ return PTR_ERR(child_ctx);
child->perf_event_ctxp[ctxn] = child_ctx;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V9 08/13] MIPS: Loongson 3: Add serial port support
Loongson family machines has three types of serial port: PCI UART, LPC
UART and CPU internal UART. Loongson-2E and parts of Loongson-2F based
machines use PCI UART; most Loongson-2F based machines use LPC UART;
Loongson-2G/3A has both LPC and CPU UART but usually use CPU UART.
Port address of UARTs:
CPU UART: REG_BASE + OFFSET;
LPC UART: LIO1_BASE + OFFSET;
PCI UART: PCIIO_BASE + OFFSET.
Since LPC UART are linked in "Local Bus", both CPU UART and LPC UART
are called "CPU provided serial port".
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/loongson/common/serial.c| 26 +++---
arch/mips/loongson/common/uart_base.c |9 -
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/mips/loongson/common/serial.c
b/arch/mips/loongson/common/serial.c
index 7580873..59c76b5 100644
--- a/arch/mips/loongson/common/serial.c
+++ b/arch/mips/loongson/common/serial.c
@@ -19,19 +19,19 @@
#include
#include
-#define PORT(int) \
+#define PORT(int, clk) \
{ \
.irq= int, \
- .uartclk= 1843200, \
+ .uartclk= clk, \
.iotype = UPIO_PORT,\
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,\
.regshift = 0,\
}
-#define PORT_M(int)\
+#define PORT_M(int, clk) \
{ \
.irq= MIPS_CPU_IRQ_BASE + (int),\
- .uartclk= 3686400, \
+ .uartclk= clk, \
.iotype = UPIO_MEM, \
.membase= (void __iomem *)NULL, \
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,\
@@ -40,13 +40,17 @@
static struct plat_serial8250_port uart8250_data[][2] = {
[MACH_LOONGSON_UNKNOWN] {},
- [MACH_LEMOTE_FL2E] {PORT(4), {} },
- [MACH_LEMOTE_FL2F] {PORT(3), {} },
- [MACH_LEMOTE_ML2F7] {PORT_M(3), {} },
- [MACH_LEMOTE_YL2F89]{PORT_M(3), {} },
- [MACH_DEXXON_GDIUM2F10] {PORT_M(3), {} },
- [MACH_LEMOTE_NAS] {PORT_M(3), {} },
- [MACH_LEMOTE_LL2F] {PORT(3), {} },
+ [MACH_LEMOTE_FL2E] {PORT(4, 1843200), {} },
+ [MACH_LEMOTE_FL2F] {PORT(3, 1843200), {} },
+ [MACH_LEMOTE_ML2F7] {PORT_M(3, 3686400), {} },
+ [MACH_LEMOTE_YL2F89]{PORT_M(3, 3686400), {} },
+ [MACH_DEXXON_GDIUM2F10] {PORT_M(3, 3686400), {} },
+ [MACH_LEMOTE_NAS] {PORT_M(3, 3686400), {} },
+ [MACH_LEMOTE_LL2F] {PORT(3, 1843200), {} },
+ [MACH_LEMOTE_A1004] {PORT_M(2, 33177600), {} },
+ [MACH_LEMOTE_A1101] {PORT_M(2, 2500), {} },
+ [MACH_LEMOTE_A1201] {PORT_M(2, 2500), {} },
+ [MACH_LEMOTE_A1205] {PORT_M(2, 2500), {} },
[MACH_LOONGSON_END] {},
};
diff --git a/arch/mips/loongson/common/uart_base.c
b/arch/mips/loongson/common/uart_base.c
index d69ea54..ea8b501 100644
--- a/arch/mips/loongson/common/uart_base.c
+++ b/arch/mips/loongson/common/uart_base.c
@@ -35,9 +35,16 @@ void prom_init_loongson_uart_base(void)
case MACH_DEXXON_GDIUM2F10:
case MACH_LEMOTE_NAS:
default:
- /* The CPU provided serial port */
+ /* The CPU provided serial port (LPC) */
loongson_uart_base = LOONGSON_LIO1_BASE + 0x3f8;
break;
+ case MACH_LEMOTE_A1004:
+ case MACH_LEMOTE_A1101:
+ case MACH_LEMOTE_A1201:
+ case MACH_LEMOTE_A1205:
+ /* The CPU provided serial port (CPU) */
+ loongson_uart_base = LOONGSON_REG_BASE + 0x1e0;
+ break;
}
_loongson_uart_base =
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V9 07/13] MIPS: Loongson 3: Add IRQ init and dispatch support
IRQ routing path of Loongson-3: Devices(most) --> I8259 --> HT Controller --> IRQ Routing Table --> CPU ^ | Device(legacy devices such as UART) --> Bonito ---| IRQ Routing Table route 32 INTs to CPU's INT0~INT3(IP2~IP5 of CP0), 32 INTs include 16 HT INTs(mostly), 4 PCI INTs, 1 LPC INT, etc. IP6 is used for IPI and IP7 is used for internal MIPS timer. LOONGSON_INT_ROUTER_* are IRQ Routing Table registers. I8259 IRQs are 1:1 mapped to HT1 INTs. LOONGSON_HT1_* are configuration registers of HT1 controller. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan --- arch/mips/include/asm/mach-loongson/irq.h | 24 +++ arch/mips/include/asm/mach-loongson/loongson.h |9 +++ arch/mips/loongson/Makefile|6 ++ arch/mips/loongson/loongson-3/Makefile |4 + arch/mips/loongson/loongson-3/irq.c| 87 5 files changed, 130 insertions(+), 0 deletions(-) create mode 100644 arch/mips/include/asm/mach-loongson/irq.h create mode 100644 arch/mips/loongson/loongson-3/Makefile create mode 100644 arch/mips/loongson/loongson-3/irq.c diff --git a/arch/mips/include/asm/mach-loongson/irq.h b/arch/mips/include/asm/mach-loongson/irq.h new file mode 100644 index 000..4787cd0 --- /dev/null +++ b/arch/mips/include/asm/mach-loongson/irq.h @@ -0,0 +1,24 @@ +#ifndef __ASM_MACH_LOONGSON_IRQ_H_ +#define __ASM_MACH_LOONGSON_IRQ_H_ + +#include + +/* cpu core interrupt numbers */ +#define MIPS_CPU_IRQ_BASE 56 + +#ifdef CONFIG_CPU_LOONGSON3 + +#define LOONGSON_UART_IRQ (MIPS_CPU_IRQ_BASE + 2) /* uart */ +#define LOONGSON_I8259_IRQ (MIPS_CPU_IRQ_BASE + 3) /* i8259 */ +#define LOONGSON_TIMER_IRQ (MIPS_CPU_IRQ_BASE + 7) /* cpu timer */ + +#define LOONGSON_HT1_CFG_BASE ht_control_base +#define LOONGSON_HT1_INT_VECTOR_BASE LOONGSON_HT1_CFG_BASE + 0x80 +#define LOONGSON_HT1_INT_EN_BASE LOONGSON_HT1_CFG_BASE + 0xa0 +#define LOONGSON_HT1_INT_VECTOR(n) LOONGSON3_REG32(LOONGSON_HT1_INT_VECTOR_BASE, 4 * n) +#define LOONGSON_HT1_INTN_EN(n) LOONGSON3_REG32(LOONGSON_HT1_INT_EN_BASE, 4 * n) + +#endif + +#include_next +#endif /* __ASM_MACH_LOONGSON_IRQ_H_ */ diff --git a/arch/mips/include/asm/mach-loongson/loongson.h b/arch/mips/include/asm/mach-loongson/loongson.h index 960811a..f573e47 100644 --- a/arch/mips/include/asm/mach-loongson/loongson.h +++ b/arch/mips/include/asm/mach-loongson/loongson.h @@ -62,6 +62,12 @@ extern int mach_i8259_irq(void); #define LOONGSON_REG(x) \ (*(volatile u32 *)((char *)CKSEG1ADDR(LOONGSON_REG_BASE) + (x))) +#define LOONGSON3_REG8(base, x) \ + (*(volatile u8 *)((char *)TO_UNCAC(base) + (x))) + +#define LOONGSON3_REG32(base, x) \ + (*(volatile u32 *)((char *)TO_UNCAC(base) + (x))) + #define LOONGSON_IRQ_BASE 32 #define LOONGSON2_PERFCNT_IRQ (MIPS_CPU_IRQ_BASE + 6) /* cpu perf counter */ @@ -87,6 +93,9 @@ static inline void do_perfcnt_IRQ(void) #define LOONGSON_REG_BASE 0x1fe0 #define LOONGSON_REG_SIZE 0x0010 /* 256Bytes + 256Bytes + ??? */ #define LOONGSON_REG_TOP (LOONGSON_REG_BASE+LOONGSON_REG_SIZE-1) +#define LOONGSON3_REG_BASE 0x3ff0 +#define LOONGSON3_REG_SIZE 0x0010 /* 256Bytes + 256Bytes + ??? */ +#define LOONGSON3_REG_TOP (LOONGSON3_REG_BASE+LOONGSON3_REG_SIZE-1) #define LOONGSON_LIO1_BASE 0x1ff0 #define LOONGSON_LIO1_SIZE 0x0010 /* 1M */ diff --git a/arch/mips/loongson/Makefile b/arch/mips/loongson/Makefile index 2b76cb0..b1e4f05 100644 --- a/arch/mips/loongson/Makefile +++ b/arch/mips/loongson/Makefile @@ -15,3 +15,9 @@ obj-$(CONFIG_LEMOTE_FULOONG2E) += fuloong-2e/ # obj-$(CONFIG_LEMOTE_MACH2F) += lemote-2f/ + +# +# All Loongson-3 family machines +# + +obj-$(CONFIG_CPU_LOONGSON3) += loongson-3/ diff --git a/arch/mips/loongson/loongson-3/Makefile b/arch/mips/loongson/loongson-3/Makefile new file mode 100644 index 000..b9968cd --- /dev/null +++ b/arch/mips/loongson/loongson-3/Makefile @@ -0,0 +1,4 @@ +# +# Makefile for Loongson-3 family machines +# +obj-y += irq.o diff --git a/arch/mips/loongson/loongson-3/irq.c b/arch/mips/loongson/loongson-3/irq.c new file mode 100644 index 000..27aef31 --- /dev/null +++ b/arch/mips/loongson/loongson-3/irq.c @@ -0,0 +1,87 @@ +#include +#include +#include +#include + +#include +#include +#include + +#define LOONGSON_INT_ROUTER_OFFSET 0x1400 +#define LOONGSON_INT_ROUTER_INTEN LOONGSON3_REG32(LOONGSON3_REG_BASE, LOONGSON_INT_ROUTER_OFFSET + 0x24) +#define LOONGSON_INT_ROUTER_INTENSET LOONGSON3_REG32(LOONGSON3_REG_BASE, LOONGSON_INT_ROUTER_OFFSET + 0x28) +#define LOONGSON_INT_ROUTER_INTENCLR LOONGSON3_REG32(LOONGSON3_REG_BASE, LOONGSON_INT_ROUTER_OFFSET + 0x2c) +#define LOONGSON_INT_ROUTER_ENTRY(n) LOONGSON3_REG8(LOONGSON3_REG_BASE,
[PATCH 6/7] perf, x86: Use LBR call stack to get user callchain
From: "Yan, Zheng"
Try enabling the LBR call stack feature if event request recording
callchain. Try utilizing the LBR call stack to get user callchain
in case of there is no frame pointer.
This patch also adds a cpu pmu attribute to enable/disable this
feature.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 127 +
arch/x86/kernel/cpu/perf_event.h | 7 ++
arch/x86/kernel/cpu/perf_event_intel.c | 20 ++---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 3 +
include/linux/perf_event.h | 6 ++
kernel/events/core.c | 11 ++-
6 files changed, 126 insertions(+), 48 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 19e7e99..71ace4f 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -393,36 +393,49 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip > precise)
return -EOPNOTSUPP;
+ }
+ /*
+* check that PEBS LBR correction does not conflict with
+* whatever the user is asking with attr->branch_sample_type
+*/
+ if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format < 2) {
+ u64 *br_type = >attr.branch_sample_type;
+
+ if (has_branch_stack(event)) {
+ if (!precise_br_compat(event))
+ return -EOPNOTSUPP;
+
+ /* branch_sample_type is compatible */
+
+ } else {
+ /*
+* user did not specify branch_sample_type
+*
+* For PEBS fixups, we capture all
+* the branches at the priv level of the
+* event.
+*/
+ *br_type = PERF_SAMPLE_BRANCH_ANY;
+
+ if (!event->attr.exclude_user)
+ *br_type |= PERF_SAMPLE_BRANCH_USER;
+
+ if (!event->attr.exclude_kernel)
+ *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
+ }
+ } else if ((event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) &&
+ !has_branch_stack(event) &&
+ x86_pmu.attr_lbr_callstack &&
+ !event->attr.exclude_user &&
+ (event->attach_state & PERF_ATTACH_TASK)) {
/*
-* check that PEBS LBR correction does not conflict with
-* whatever the user is asking with attr->branch_sample_type
+* user did not specify branch_sample_type,
+* try using the LBR call stack facility to
+* record call chains of user program.
*/
- if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format
< 2) {
- u64 *br_type = >attr.branch_sample_type;
-
- if (has_branch_stack(event)) {
- if (!precise_br_compat(event))
- return -EOPNOTSUPP;
-
- /* branch_sample_type is compatible */
-
- } else {
- /*
-* user did not specify branch_sample_type
-*
-* For PEBS fixups, we capture all
-* the branches at the priv level of the
-* event.
-*/
- *br_type = PERF_SAMPLE_BRANCH_ANY;
-
- if (!event->attr.exclude_user)
- *br_type |= PERF_SAMPLE_BRANCH_USER;
-
- if (!event->attr.exclude_kernel)
- *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
- }
- }
+ event->attr.branch_sample_type =
+ PERF_SAMPLE_BRANCH_USER |
+ PERF_SAMPLE_BRANCH_CALL_STACK;
}
/*
@@ -1799,10 +1812,34 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
return count;
}
+static ssize_t get_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, 40, "%d\n", x86_pmu.attr_lbr_callstack);
+}
+
+static ssize_t set_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long val = simple_strtoul(buf, NULL, 0);
+
+ if (x86_pmu.attr_lbr_callstack != !!val) {
+ if (val && !x86_pmu_has_lbr_callstack())
+ return
[PATCH V9 05/13] MIPS: Loongson: Add UEFI-like firmware interface support
The new UEFI-like firmware interface has 3 advantages:
1, Firmware export a physical memory map which is similar to X86's
E820 map, so prom_init_memory() will be more elegant that #ifdef
clauses can be removed.
2, Firmware export a pci irq routing table, we no longer need pci
irq routing fixup in kernel's code.
3, Firmware has a built-in vga bios, and its address is exported,
the linux kernel no longer need an embedded blob.
With the new interface, Loongson-3A/2G and all their successors can use
a unified kernel. All Loongson-based machines support this new interface
except 2E/2F series.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/include/asm/mach-loongson/boot_param.h | 151 ++
arch/mips/include/asm/mach-loongson/loongson.h |4 +-
arch/mips/loongson/common/env.c | 67 --
arch/mips/loongson/common/init.c |9 +-
arch/mips/loongson/common/mem.c | 42 ++
arch/mips/loongson/common/pci.c |6 +-
arch/mips/loongson/common/reset.c| 16 +++
7 files changed, 275 insertions(+), 20 deletions(-)
create mode 100644 arch/mips/include/asm/mach-loongson/boot_param.h
diff --git a/arch/mips/include/asm/mach-loongson/boot_param.h
b/arch/mips/include/asm/mach-loongson/boot_param.h
new file mode 100644
index 000..4c5a1ba
--- /dev/null
+++ b/arch/mips/include/asm/mach-loongson/boot_param.h
@@ -0,0 +1,151 @@
+#ifndef __ASM_MACH_LOONGSON_BOOT_PARAM_H_
+#define __ASM_MACH_LOONGSON_BOOT_PARAM_H_
+
+#define SYSTEM_RAM_LOW 1
+#define SYSTEM_RAM_HIGH2
+#define MEM_RESERVED 3
+#define PCI_IO 4
+#define PCI_MEM5
+#define LOONGSON_CFG_REG 6
+#define VIDEO_ROM 7
+#define ADAPTER_ROM8
+#define ACPI_TABLE 9
+#define MAX_MEMORY_TYPE10
+
+#define LOONGSON3_BOOT_MEM_MAP_MAX 128
+struct efi_memory_map_loongson{
+ u16 vers; /* version of efi_memory_map */
+ u32 nr_map; /* number of memory_maps */
+ u32 mem_freq; /* memory frequence */
+ struct mem_map{
+ u32 node_id;/* node_id which memory attached to */
+ u32 mem_type; /* system memory, pci memory, pci io, etc. */
+ u64 mem_start; /* memory map start address */
+ u32 mem_size; /* each memory_map size, not the total size */
+ }map[LOONGSON3_BOOT_MEM_MAP_MAX];
+}__attribute__((packed));
+
+enum loongson_cpu_type
+{
+ Loongson_2E,
+ Loongson_2F,
+ Loongson_3A,
+ Loongson_3B,
+ Loongson_1A,
+ Loongson_1B
+};
+
+/*
+ * Capability and feature descriptor structure for MIPS CPU
+ */
+struct efi_cpuinfo_loongson {
+ u16 vers; /* version of efi_cpuinfo_loongson */
+ u32 processor_id; /* PRID, e.g. 6305, 6306 */
+ enum loongson_cpu_type cputype; /* 3A, 3B, etc. */
+ u32 total_node; /* num of total numa nodes */
+ u32 cpu_startup_core_id; /* Core id */
+ u32 cpu_clock_freq; /* cpu_clock */
+ u32 nr_cpus;
+}__attribute__((packed));
+
+struct system_loongson{
+ u16 vers; /* version of system_loongson */
+ u32 ccnuma_smp; /* 0: no numa; 1: has numa */
+ u32 sing_double_channel; /* 1:single; 2:double */
+}__attribute__((packed));
+
+struct irq_source_routing_table {
+ u16 vers;
+ u16 size;
+ u16 rtr_bus;
+ u16 rtr_devfn;
+ u32 vendor;
+ u32 device;
+ u32 PIC_type; /* conform use HT or PCI to route to CPU-PIC */
+ u64 ht_int_bit; /* 3A: 1<<24; 3B: 1<<16 */
+ u64 ht_enable; /* irqs used in this PIC */
+ u32 node_id;/* node id: 0x0-0; 0x1-1; 0x10-2; 0x11-3 */
+ u64 pci_mem_start_addr;
+ u64 pci_mem_end_addr;
+ u64 pci_io_start_addr;
+ u64 pci_io_end_addr;
+ u64 pci_config_addr;
+}__attribute__((packed));
+
+struct interface_info{
+ u16 vers; /* version of the specificition */
+ u16 size;
+ u8 flag;
+ char description[64];
+}__attribute__((packed));
+
+#define MAX_RESOURCE_NUMBER 128
+struct resource_loongson {
+ u64 start; /* resource start address */
+ u64 end; /* resource end address */
+ char name[64];
+ u32 flags;
+};
+
+struct archdev_data {}; /* arch specific additions */
+
+struct board_devices{
+ char name[64];/* hold the device name */
+ u32 num_resources; /* number of device_resource */
+ struct resource_loongson resource[MAX_RESOURCE_NUMBER]; /* for each
device's resource */
+ /* arch specific additions */
+ struct archdev_data archdata;
+};
+
+struct loongson_special_attribute{
+ u16 vers; /* version of this special */
+ char special_name[64]; /* special_atribute_name */
+ u32 loongson_special_type; /* type of special device */
+ struct
[PATCH V9 04/13] MIPS: Loongson 3: Add Lemote-3A machtypes definition
Add four Loongson-3 based machine types:
MACH_LEMOTE_A1004/MACH_LEMOTE_A1201 are laptops;
MACH_LEMOTE_A1101 is mini-itx;
MACH_LEMOTE_A1205 is all-in-one machine.
The most significant differrent between A1004/A1201 and A1101/A1205 is
the laptops have EC but others don't.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/include/asm/bootinfo.h | 24 +++-
arch/mips/include/asm/mach-loongson/machine.h |6 ++
arch/mips/loongson/common/machtype.c | 20
3 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/arch/mips/include/asm/bootinfo.h b/arch/mips/include/asm/bootinfo.h
index 7a51d87..118f525 100644
--- a/arch/mips/include/asm/bootinfo.h
+++ b/arch/mips/include/asm/bootinfo.h
@@ -61,15 +61,21 @@
/*
* Valid machtype for Loongson family
*/
-#define MACH_LOONGSON_UNKNOWN 0
-#define MACH_LEMOTE_FL2E 1
-#define MACH_LEMOTE_FL2F 2
-#define MACH_LEMOTE_ML2F7 3
-#define MACH_LEMOTE_YL2F89 4
-#define MACH_DEXXON_GDIUM2F10 5
-#define MACH_LEMOTE_NAS6
-#define MACH_LEMOTE_LL2F 7
-#define MACH_LOONGSON_END 8
+enum loongson_machine_type {
+ MACH_LOONGSON_UNKNOWN,
+ MACH_LEMOTE_FL2E,
+ MACH_LEMOTE_FL2F,
+ MACH_LEMOTE_ML2F7,
+ MACH_LEMOTE_YL2F89,
+ MACH_DEXXON_GDIUM2F10,
+ MACH_LEMOTE_NAS,
+ MACH_LEMOTE_LL2F,
+ MACH_LEMOTE_A1004,
+ MACH_LEMOTE_A1101,
+ MACH_LEMOTE_A1201,
+ MACH_LEMOTE_A1205,
+ MACH_LOONGSON_END
+};
/*
* Valid machtype for group INGENIC
diff --git a/arch/mips/include/asm/mach-loongson/machine.h
b/arch/mips/include/asm/mach-loongson/machine.h
index 4321338..89f6b9a5 100644
--- a/arch/mips/include/asm/mach-loongson/machine.h
+++ b/arch/mips/include/asm/mach-loongson/machine.h
@@ -24,4 +24,10 @@
#endif
+#ifdef CONFIG_LEMOTE_MACH3A
+
+#define LOONGSON_MACHTYPE MACH_LEMOTE_A1101
+
+#endif /* CONFIG_LEMOTE_MACH3A */
+
#endif /* __ASM_MACH_LOONGSON_MACHINE_H */
diff --git a/arch/mips/loongson/common/machtype.c
b/arch/mips/loongson/common/machtype.c
index 2efd5d9..e13e13d 100644
--- a/arch/mips/loongson/common/machtype.c
+++ b/arch/mips/loongson/common/machtype.c
@@ -19,15 +19,19 @@
#define MACHTYPE_LEN 50
static const char *system_types[] = {
- [MACH_LOONGSON_UNKNOWN] "unknown loongson machine",
- [MACH_LEMOTE_FL2E] "lemote-fuloong-2e-box",
- [MACH_LEMOTE_FL2F] "lemote-fuloong-2f-box",
- [MACH_LEMOTE_ML2F7] "lemote-mengloong-2f-7inches",
- [MACH_LEMOTE_YL2F89]"lemote-yeeloong-2f-8.9inches",
- [MACH_DEXXON_GDIUM2F10] "dexxon-gdium-2f",
+ [MACH_LOONGSON_UNKNOWN] "unknown loongson machine",
+ [MACH_LEMOTE_FL2E] "lemote-fuloong-2e-box",
+ [MACH_LEMOTE_FL2F] "lemote-fuloong-2f-box",
+ [MACH_LEMOTE_ML2F7] "lemote-mengloong-2f-7inches",
+ [MACH_LEMOTE_YL2F89]"lemote-yeeloong-2f-8.9inches",
+ [MACH_DEXXON_GDIUM2F10] "dexxon-gdium-2f",
[MACH_LEMOTE_NAS] "lemote-nas-2f",
- [MACH_LEMOTE_LL2F] "lemote-lynloong-2f",
- [MACH_LOONGSON_END] NULL,
+ [MACH_LEMOTE_LL2F] "lemote-lynloong-2f",
+ [MACH_LEMOTE_A1004] "lemote-3a-notebook-a1004",
+ [MACH_LEMOTE_A1101] "lemote-3a-itx-a1101",
+ [MACH_LEMOTE_A1201] "lemote-2gq-notebook-a1201",
+ [MACH_LEMOTE_A1205] "lemote-2gq-aio-a1205",
+ [MACH_LOONGSON_END] NULL,
};
const char *get_system_type(void)
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V9 03/13] MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature
Loongson-3 maintains cache coherency by hardware. So we introduce a cpu
feature named cpu_has_coherent_cache and use it to modify MIPS's cache
flushing functions.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/include/asm/cacheflush.h |6 +
arch/mips/include/asm/cpu-features.h |3 ++
.../asm/mach-loongson/cpu-feature-overrides.h |6 +
arch/mips/mm/c-r4k.c | 21 ++-
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/cacheflush.h
b/arch/mips/include/asm/cacheflush.h
index 69468de..8c4fa0d 100644
--- a/arch/mips/include/asm/cacheflush.h
+++ b/arch/mips/include/asm/cacheflush.h
@@ -70,6 +70,9 @@ extern void (*__flush_cache_vmap)(void);
static inline void flush_cache_vmap(unsigned long start, unsigned long end)
{
+ if (cpu_has_coherent_cache)
+ return;
+
if (cpu_has_dc_aliases)
__flush_cache_vmap();
}
@@ -78,6 +81,9 @@ extern void (*__flush_cache_vunmap)(void);
static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
{
+ if (cpu_has_coherent_cache)
+ return;
+
if (cpu_has_dc_aliases)
__flush_cache_vunmap();
}
diff --git a/arch/mips/include/asm/cpu-features.h
b/arch/mips/include/asm/cpu-features.h
index c507b93..55213ca 100644
--- a/arch/mips/include/asm/cpu-features.h
+++ b/arch/mips/include/asm/cpu-features.h
@@ -110,6 +110,9 @@
#ifndef cpu_has_pindexed_dcache
#define cpu_has_pindexed_dcache(cpu_data[0].dcache.flags &
MIPS_CACHE_PINDEX)
#endif
+#ifndef cpu_has_coherent_cache
+#define cpu_has_coherent_cache 0
+#endif
/*
* I-Cache snoops remote store. This only matters on SMP. Some
multiprocessors
diff --git a/arch/mips/include/asm/mach-loongson/cpu-feature-overrides.h
b/arch/mips/include/asm/mach-loongson/cpu-feature-overrides.h
index 1a05d85..f72b6be 100644
--- a/arch/mips/include/asm/mach-loongson/cpu-feature-overrides.h
+++ b/arch/mips/include/asm/mach-loongson/cpu-feature-overrides.h
@@ -57,5 +57,11 @@
#define cpu_has_vint 0
#define cpu_has_vtag_icache0
#define cpu_has_watch 1
+#ifdef CONFIG_CPU_SUPPORTS_COHERENT_CACHE
+#define cpu_has_coherent_cache 1
+#else
+#define cpu_has_coherent_cache 0
+#endif
+
#endif /* __ASM_MACH_LOONGSON_CPU_FEATURE_OVERRIDES_H */
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index d1b9da3..5f9171d 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -345,6 +345,10 @@ static inline void local_r4k___flush_cache_all(void * args)
r4k_blast_scache();
return;
#endif
+
+ if (cpu_has_coherent_cache)
+ return;
+
r4k_blast_dcache();
r4k_blast_icache();
@@ -406,8 +410,12 @@ static inline void local_r4k_flush_cache_range(void * args)
static void r4k_flush_cache_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
- int exec = vma->vm_flags & VM_EXEC;
+ int exec __maybe_unused;
+
+ if (cpu_has_coherent_cache)
+ return;
+ exec = vma->vm_flags & VM_EXEC;
if (cpu_has_dc_aliases || (exec && !cpu_has_ic_fills_f_dc))
r4k_on_each_cpu(local_r4k_flush_cache_range, vma);
}
@@ -527,7 +535,10 @@ static inline void local_r4k_flush_cache_page(void *args)
static void r4k_flush_cache_page(struct vm_area_struct *vma,
unsigned long addr, unsigned long pfn)
{
- struct flush_cache_page_args args;
+ struct flush_cache_page_args args __maybe_unused;
+
+ if (cpu_has_coherent_cache)
+ return;
args.vma = vma;
args.addr = addr;
@@ -543,6 +554,9 @@ static inline void local_r4k_flush_data_cache_page(void *
addr)
static void r4k_flush_data_cache_page(unsigned long addr)
{
+ if (cpu_has_coherent_cache)
+ return;
+
if (in_atomic())
local_r4k_flush_data_cache_page((void *)addr);
else
@@ -701,6 +715,9 @@ static void local_r4k_flush_cache_sigtramp(void * arg)
static void r4k_flush_cache_sigtramp(unsigned long addr)
{
+ if (cpu_has_coherent_cache)
+ return;
+
r4k_on_each_cpu(local_r4k_flush_cache_sigtramp, (void *) addr);
}
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V9 02/13] MIPS: Loongson: Add basic Loongson-3 CPU support
Basic Loongson-3 CPU support include CPU probing and TLB/cache
initializing.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/kernel/cpu-probe.c | 14 +++---
arch/mips/mm/c-r4k.c | 62 +-
arch/mips/mm/tlb-r4k.c |2 +-
arch/mips/mm/tlbex.c |1 +
4 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 9f31334..23ee426 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -773,17 +773,23 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips
*c, unsigned int cpu)
MIPS_CPU_LLSC;
c->tlbsize = 64;
break;
- case PRID_IMP_LOONGSON2:
- c->cputype = CPU_LOONGSON2;
- __cpu_name[cpu] = "ICT Loongson-2";
-
+ case PRID_IMP_LOONGSON2: /* Loongson-2/3 have the same PRID_IMP field */
switch (c->processor_id & PRID_REV_MASK) {
case PRID_REV_LOONGSON2E:
+ c->cputype = CPU_LOONGSON2;
+ __cpu_name[cpu] = "ICT Loongson-2E";
set_elf_platform(cpu, "loongson2e");
break;
case PRID_REV_LOONGSON2F:
+ c->cputype = CPU_LOONGSON2;
+ __cpu_name[cpu] = "ICT Loongson-2F";
set_elf_platform(cpu, "loongson2f");
break;
+ case PRID_REV_LOONGSON3A:
+ c->cputype = CPU_LOONGSON3;
+ __cpu_name[cpu] = "ICT Loongson-3A";
+ set_elf_platform(cpu, "loongson3a");
+ break;
}
c->isa_level = MIPS_CPU_ISA_III;
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 0f7d788..d1b9da3 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -968,6 +968,31 @@ static void __cpuinit probe_pcache(void)
c->dcache.waybit = 0;
break;
+ case CPU_LOONGSON3:
+ config1 = read_c0_config1();
+ if ((lsize = ((config1 >> 19) & 7)))
+ c->icache.linesz = 2 << lsize;
+ else
+ c->icache.linesz = lsize;
+ c->icache.sets = 64 << ((config1 >> 22) & 7);
+ c->icache.ways = 1 + ((config1 >> 16) & 7);
+ icache_size = c->icache.sets *
+ c->icache.ways *
+ c->icache.linesz;
+ c->icache.waybit = 0;
+
+ if ((lsize = ((config1 >> 10) & 7)))
+ c->dcache.linesz = 2 << lsize;
+ else
+ c->dcache.linesz = lsize;
+ c->dcache.sets = 64 << ((config1 >> 13) & 7);
+ c->dcache.ways = 1 + ((config1 >> 7) & 7);
+ dcache_size = c->dcache.sets *
+ c->dcache.ways *
+ c->dcache.linesz;
+ c->dcache.waybit = 0;
+ break;
+
default:
if (!(config & MIPS_CONF_M))
panic("Don't know how to probe P-caches on this cpu.");
@@ -1188,6 +1213,34 @@ static void __init loongson2_sc_init(void)
}
#endif
+#if defined(CONFIG_CPU_LOONGSON3)
+static void __init loongson3_sc_init(void)
+{
+ struct cpuinfo_mips *c = _cpu_data;
+ unsigned int config2, lsize;
+
+ config2 = read_c0_config2();
+ if ((lsize = ((config2 >> 4) & 15)))
+ c->scache.linesz = 2 << lsize;
+ else
+ c->scache.linesz = lsize;
+ c->scache.sets = 64 << ((config2 >> 8) & 15);
+ c->scache.ways = 1 + (config2 & 15);
+
+ scache_size = c->scache.sets *
+ c->scache.ways *
+ c->scache.linesz;
+ /* Loongson-3 has 4 cores, 1MB scache for each. scaches are shared */
+ scache_size *= 4;
+ c->scache.waybit = 0;
+ pr_info("Unified secondary cache %ldkB %s, linesize %d bytes.\n",
+ scache_size >> 10, way_string[c->scache.ways], c->scache.linesz);
+ if (scache_size)
+ c->options |= MIPS_CPU_INCLUSIVE_CACHES;
+ return;
+}
+#endif
+
extern int r5k_sc_init(void);
extern int rm7k_sc_init(void);
extern int mips_sc_init(void);
@@ -1236,11 +1289,18 @@ static void __cpuinit setup_scache(void)
#endif
return;
-#if defined(CONFIG_CPU_LOONGSON2)
case CPU_LOONGSON2:
+#if defined(CONFIG_CPU_LOONGSON2)
loongson2_sc_init();
+#endif
return;
+
+ case CPU_LOONGSON3:
+#if defined(CONFIG_CPU_LOONGSON3)
+ loongson3_sc_init();
#endif
+ return;
+
case CPU_XLP:
[PATCH V9 01/13] MIPS: Loongson: Add basic Loongson-3 definition
Loongson-3 is a multi-core MIPS family CPU, it support MIPS64 fully.
Loongson-3 has the same IMP field (0x6300) as Loongson-2.
Loongson-3 has a hardware-maintained cache, system software doesn't
need to maintain coherency.
Loongson-3A is the first revision of Loongson-3, and it is the quad-
core version of Loongson-2G. Loongson-3A has a simplified version named
Loongson-2Gq, the main difference between Loongson-3A/2Gq is 3A has two
HyperTransport controller but 2Gq has only one. HT0 is used for cross-
chip interconnection and HT1 is used to link PCI bus. Therefore, 2Gq
cannot support NUMA but 3A can. For software, Loongson-2Gq is simply
identified as Loongson-3A.
Exsisting Loongson family CPUs:
Loongson-1: Loongson-1A, Loongson-1B, they are 32-bit MIPS CPUs.
Loongson-2: Loongson-2E, Loongson-2F, Loongson-2G, they are 64-bit
single-core MIPS CPUs.
Loongson-3: Loongson-3A(including so-called Loongson-2Gq), they are
64-bit multi-core MIPS CPUs.
Signed-off-by: Huacai Chen
Signed-off-by: Hongliang Tao
Signed-off-by: Hua Yan
---
arch/mips/include/asm/addrspace.h|6 ++
arch/mips/include/asm/cpu.h |5 +++--
arch/mips/include/asm/mach-loongson/spaces.h | 15 +++
arch/mips/include/asm/module.h |2 ++
arch/mips/include/asm/pgtable-bits.h |7 +++
arch/mips/loongson/Platform |1 +
6 files changed, 34 insertions(+), 2 deletions(-)
create mode 100644 arch/mips/include/asm/mach-loongson/spaces.h
diff --git a/arch/mips/include/asm/addrspace.h
b/arch/mips/include/asm/addrspace.h
index 569f80a..cf62bfb 100644
--- a/arch/mips/include/asm/addrspace.h
+++ b/arch/mips/include/asm/addrspace.h
@@ -116,7 +116,13 @@
#define K_CALG_UNCACHED2
#define K_CALG_NONCOHERENT 3
#define K_CALG_COH_EXCL4
+
+#ifdef CONFIG_CPU_LOONGSON3
+#define K_CALG_COH_SHAREABLE 3
+#else
#define K_CALG_COH_SHAREABLE 5
+#endif
+
#define K_CALG_NOTUSED 6
#define K_CALG_UNCACHED_ACCEL 7
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index 90112ad..a455903 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -201,6 +201,7 @@
#define PRID_REV_LOONGSON1B0x0020
#define PRID_REV_LOONGSON2E0x0002
#define PRID_REV_LOONGSON2F0x0003
+#define PRID_REV_LOONGSON3A0x0005
/*
* Older processors used to encode processor version and revision in two
@@ -269,8 +270,8 @@ enum cpu_type_enum {
* MIPS64 class processors
*/
CPU_5KC, CPU_5KE, CPU_20KC, CPU_25KF, CPU_SB1, CPU_SB1A, CPU_LOONGSON2,
- CPU_CAVIUM_OCTEON, CPU_CAVIUM_OCTEON_PLUS, CPU_CAVIUM_OCTEON2,
- CPU_XLR, CPU_XLP,
+ CPU_LOONGSON3, CPU_CAVIUM_OCTEON, CPU_CAVIUM_OCTEON_PLUS,
+ CPU_CAVIUM_OCTEON2, CPU_XLR, CPU_XLP,
CPU_LAST
};
diff --git a/arch/mips/include/asm/mach-loongson/spaces.h
b/arch/mips/include/asm/mach-loongson/spaces.h
new file mode 100644
index 000..1e82804
--- /dev/null
+++ b/arch/mips/include/asm/mach-loongson/spaces.h
@@ -0,0 +1,15 @@
+#ifndef __ASM_MACH_LOONGSON_SPACES_H_
+#define __ASM_MACH_LOONGSON_SPACES_H_
+
+#ifndef CAC_BASE
+#if defined(CONFIG_64BIT)
+#if defined(CONFIG_DMA_NONCOHERENT) || defined(CONFIG_CPU_LOONGSON3)
+#define CAC_BASE_AC(0x9800, UL)
+#else
+#define CAC_BASE_AC(0xa800, UL)
+#endif /* CONFIG_DMA_NONCOHERENT || CONFIG_CPU_LOONGSON3 */
+#endif /* CONFIG_64BIT */
+#endif /* CONFIG_CAC_BASE */
+
+#include
+#endif
diff --git a/arch/mips/include/asm/module.h b/arch/mips/include/asm/module.h
index 44b705d..c2edae3 100644
--- a/arch/mips/include/asm/module.h
+++ b/arch/mips/include/asm/module.h
@@ -126,6 +126,8 @@ search_module_dbetables(unsigned long addr)
#define MODULE_PROC_FAMILY "LOONGSON1 "
#elif defined CONFIG_CPU_LOONGSON2
#define MODULE_PROC_FAMILY "LOONGSON2 "
+#elif defined CONFIG_CPU_LOONGSON3
+#define MODULE_PROC_FAMILY "LOONGSON3 "
#elif defined CONFIG_CPU_CAVIUM_OCTEON
#define MODULE_PROC_FAMILY "OCTEON "
#elif defined CONFIG_CPU_XLR
diff --git a/arch/mips/include/asm/pgtable-bits.h
b/arch/mips/include/asm/pgtable-bits.h
index f6a0439..b486dd5 100644
--- a/arch/mips/include/asm/pgtable-bits.h
+++ b/arch/mips/include/asm/pgtable-bits.h
@@ -235,6 +235,13 @@ static inline uint64_t pte_to_entrylo(unsigned long
pte_val)
#define _CACHE_CACHABLE_NONCOHERENT (5<<_CACHE_SHIFT)
#define _CACHE_UNCACHED_ACCELERATED (7<<_CACHE_SHIFT)
+#elif defined(CONFIG_CPU_LOONGSON3)
+
+#define _CACHE_UNCACHED (2<<_CACHE_SHIFT) /* LOONGSON */
+#define _CACHE_CACHABLE_NONCOHERENT (3<<_CACHE_SHIFT) /* LOONGSON */
+#define _CACHE_CACHABLE_COHERENT(3<<_CACHE_SHIFT) /* LOONGSON-3 */
+#define _CACHE_UNCACHED_ACCELERATED (7<<_CACHE_SHIFT) /* LOONGSON */
+
#else
#define _CACHE_CACHABLE_NO_WA (0<<_CACHE_SHIFT) /* R4600 only */
diff --git a/arch/mips/loongson/Platform
[PATCH V9 00/13] MIPS: Add Loongson-3 based machines support
This patchset is for git repository git://git.linux-mips.org/pub/scm/ ralf/linux. Loongson-3 is a multi-core MIPS family CPU, it is MIPS64 compatible and has the same IMP field (0x6300) as Loongson-2. These patches make Linux kernel support Loongson-3 CPU and Loongson-3 based computers (including Laptop, Mini-ITX, All-In-One PC, etc.) V1 -> V2: 1, Split the first patch to two patches, one is constant definition and the other is CPU probing, cache initializing, etc. 2, Remove Kconfig options in the first 9 patches and put all of them in the 10th patch. 3, Use "make savedefconfig" to generate the new default config file. 4, Rework serial port support to use PORT and PORT_M macros. 5, Fix some compile warnings. V2 -> V3: 1, Improve cache flushing code (use cpu_has_coherent_cache macro and remove #ifdef clauses). 2, Improve platform-specific code to correctly set driver's dma_mask/ coherent_dma_mask so no longer need workarounds for each driver ( SATA, graphics card, sound card, etc.) 3, Use PCI quirk to provide vgabios and loongson3_read_bios() go away. 4, Improve CPU hotplug code and split the poweroff failure related code to another patch (this issue affect all MIPS CPU, not only Loongson). 5, Some other small fixes. V3 -> V4: 1, Include swiotlb.h in radeon_ttm.c if SWIOTLB configured. 2, Remove "Reviewed-by" in patches which are added by mistake. 3, Sync the code to upstream. V4 -> V5: 1, Split the drm patch to three patches. 2, Use platform-specific pincfgs to replace old alsa quirks. V5 -> V6: 1, For better management, two non-Loongson-specific patches are sent independently. 2, Introduce cpu_has_coherent_cache feature and split cache flushing changes to a separate patch. 3, Remove PRID_IMP_LOONGSON3 and use PRID_IMP_LOONGSON2 since they are the same. 4, Don't define RTC_ALWAYS_BCD for Loongson-3 since BCD format can be checked by RTC_CONTROL at runtime. 5, Don't modify dma-default.c for Loongson since it is unnecessary. 6, Don't define SAREA_MAX since it is useless. 7, Increase the default boost of internal mic for Lemote A1004. 8, Fix a #ifdef issue in dma-coherence.h. 9, Some other small fixes. V6 -> V7: 1, Fix boot failure when NR_CPUS is more than present cpus. 2, Fix error messages after poweroff & reboot. 3, Update the default config file. 4, Sync the code to upstream. V7 -> V8: 1, Add WEAK_ORDERING/WEAK_REORDERING_BEYOND_LLSC for Loongson-3. 2, Fix a deadlock of cpu-hotplug. 3, Include swiotlb.h in arch-specific code to avoid driver modification. 4, Remove the patch "drm: Handle io prot correctly for MIPS" since it is already in upstream code. 5, Remove the patch "ALSA: HDA: Make hda sound card usable for Loongson" since it is already in upstream code. 6, Use LZMA compression and do some adjustment of config file to reduce kernel size. V8 -> V9: 1, Fix spurious IPI interrupt. 2, remove __dev* attributes since CONFIG_HOTPLUG is going away as an option. 3, Use dev_info() to print messages in fixup-loongson3.c. 4, Update the default config file. 5, Sync the code to upstream. Huacai Chen(13): MIPS: Loongson: Add basic Loongson-3 definition. MIPS: Loongson: Add basic Loongson-3 CPU support. MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature. MIPS: Loongson 3: Add Lemote-3A machtypes definition. MIPS: Loongson: Add UEFI-like firmware interface support. MIPS: Loongson 3: Add HT-linked PCI support. MIPS: Loongson 3: Add IRQ init and dispatch support. MIPS: Loongson 3: Add serial port support. MIPS: Loongson: Add swiotlb to support big memory (>4GB). MIPS: Loongson: Add Loongson-3 Kconfig options. MIPS: Loongson 3: Add Loongson-3 SMP support. MIPS: Loongson 3: Add CPU hotplug support. MIPS: Loongson: Add a Loongson-3 default config file. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan --- arch/mips/Kconfig | 29 ++ arch/mips/configs/loongson3_defconfig | 329 ++ arch/mips/include/asm/addrspace.h |6 + arch/mips/include/asm/bootinfo.h | 24 +- arch/mips/include/asm/cacheflush.h |6 + arch/mips/include/asm/cpu-features.h |3 + arch/mips/include/asm/cpu.h|5 +- arch/mips/include/asm/dma-mapping.h|5 + arch/mips/include/asm/mach-loongson/boot_param.h | 151 +++ .../asm/mach-loongson/cpu-feature-overrides.h |6 + .../mips/include/asm/mach-loongson/dma-coherence.h | 23 + arch/mips/include/asm/mach-loongson/irq.h | 24 + arch/mips/include/asm/mach-loongson/loongson.h | 26 +- arch/mips/include/asm/mach-loongson/machine.h |6 + arch/mips/include/asm/mach-loongson/pci.h |5 + arch/mips/include/asm/mach-loongson/spaces.h | 15 + arch/mips/include/asm/module.h |2 + arch/mips/include/asm/pgtable-bits.h |7 +
Re: [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
Hi Sourav, On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote: > Booting 3.8-rc4 om omap 4430sdp results in the following error > > omap_i2c 4807.i2c: did not get pins for i2c error: -19 > [1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz > [1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 > [1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz > [1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19 > [1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz > [1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19 > [1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz > > This happens because omap4 dts file is not adapted to use i2c through pinctrl > framework. Populating i2c pinctrl data to get rid of the error. > > Tested on omap4430 sdp with 3.8-rc4 kernel. > > Signed-off-by: Sourav Poddar > Reported-by: Santosh Shilimkar > --- Could you do the same thing for panda? I'm getting the same kind of errors with it: [0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard [...] [2.884826] omap_i2c 48072000.i2c: did not get pins for i2c error: -19 [2.890686] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz [2.892028] omap_i2c 4806.i2c: did not get pins for i2c error: -19 [2.899047] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz [2.906677] omap_i2c 4835.i2c: did not get pins for i2c error: -19 [2.912872] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] suspend: enable freeze timeout configuration through sys
At present, the timeout value for freezing tasks is fixed as 20s,
which is too long for handheld device usage, especially for mobile
phone.
In order to improve user experience, we enable freeze timeout
configuration through sys, so that we can tune the value easily
for concrete usage, such as smaller value for handheld device such
as mobile phone.
Signed-off-by: Liu Chuansheng
Signed-off-by: Li Fei
---
Documentation/power/freezing-of-tasks.txt |5 +
include/linux/freezer.h |5 +
kernel/power/main.c | 27 +++
kernel/power/process.c|4 ++--
4 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/Documentation/power/freezing-of-tasks.txt
b/Documentation/power/freezing-of-tasks.txt
index 6ec291e..85894d8 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task,
since it is anyway
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(_mutex). That would prevent freezing failures.
+
+V. Miscellaneous
+/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
+all user space processes or all freezable kernel threads, in unit of
millisecond.
+The default value is 2, with range of unsigned integer.
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index e4238ce..5a24a33 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -13,6 +13,11 @@ extern bool pm_freezing; /* PM freezing in
effect */
extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
/*
+ * Timeout for stopping processes
+ */
+extern unsigned int sys_freeze_process_timeout_msecs;
+
+/*
* Check if a process has been frozen
*/
static inline bool frozen(struct task_struct *p)
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1c16f91..453ead1 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -553,6 +553,30 @@ power_attr(pm_trace_dev_match);
#endif /* CONFIG_PM_TRACE */
+#ifdef CONFIG_FREEZER
+static ssize_t pm_freeze_timeout_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%u\n", sys_freeze_process_timeout_msecs);
+}
+
+static ssize_t pm_freeze_timeout_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t n)
+{
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, ))
+ return -EINVAL;
+
+ sys_freeze_process_timeout_msecs = val;
+ return n;
+}
+
+power_attr(pm_freeze_timeout);
+
+#endif /* CONFIG_FREEZER*/
+
static struct attribute * g[] = {
_attr.attr,
#ifdef CONFIG_PM_TRACE
@@ -576,6 +600,9 @@ static struct attribute * g[] = {
_print_times_attr.attr,
#endif
#endif
+#ifdef CONFIG_FREEZER
+ _freeze_timeout_attr.attr,
+#endif
NULL,
};
diff --git a/kernel/power/process.c b/kernel/power/process.c
index d5a258b..ba45a26 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -21,7 +21,7 @@
/*
* Timeout for stopping processes
*/
-#define TIMEOUT(20 * HZ)
+unsigned int __read_mostly sys_freeze_process_timeout_msecs = 2;
static int try_to_freeze_tasks(bool user_only)
{
@@ -36,7 +36,7 @@ static int try_to_freeze_tasks(bool user_only)
do_gettimeofday();
- end_time = jiffies + TIMEOUT;
+ end_time = jiffies + msecs_to_jiffies(sys_freeze_process_timeout_msecs);
if (!user_only)
freeze_workqueues_begin();
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] suspend: enable freeze timeout configuration through sysctl
Hello Andrew, Thanks for your feedback. Your suggestion are all accepted, and will be updated in V2 as below: 1> The newly added attribute will be /sys/power/pm_freeze_timeout; 2> Documentation/power/freezing-of-tasks.txt will be updated to record such attribute; 3> Unit of millisecond will be used for the attribute. Best Regards, Li Fei -Original Message- From: Andrew Morton [mailto:a...@linux-foundation.org] Sent: Wednesday, January 30, 2013 8:37 AM To: Li, Fei Cc: r...@sisk.pl; linux-kernel@vger.kernel.org; linux...@vger.kernel.org; Liu, Chuansheng Subject: Re: [PATCH] suspend: enable freeze timeout configuration through sysctl On Tue, 29 Jan 2013 10:58:20 +0800 fli24 wrote: > At present, the timeout value for freezing tasks is fixed as 20s, > which is too long for handheld device usage, especially for mobile > phone. > > In order to improve user experience, we enable freeze timeout > configuration through sysctl, so that we can tune the value easily > for concrete usage, such as smaller value for handheld device such > as mobile phone. > > ... > The patch looks nice - it does everything right in places where things are frequently done wrongly. Except.. It forgot to document the sysctl. Documentation/sysctl/kernel.txt, I guess. Is /proc/sys/kernel the most appropriate place for this? Perhaps a PM-specific place would be better. Maybe not. > --- a/include/linux/freezer.h > +++ b/include/linux/freezer.h > @@ -13,6 +13,11 @@ extern bool pm_freezing; /* PM freezing in > effect */ > extern bool pm_nosig_freezing; /* PM nosig freezing in effect > */ > > /* > + * Timeout for stopping processes > + */ > +extern unsigned int sysctl_freeze_process_timeout_secs; I suggest the use of milliseconds here. Someone might want a half-second timeout and it's pretty pointless to design the interface in a way which rules that out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] suspend: enable freeze timeout configuration through sysctl
Hello Rafael,
Thanks for your feedback, and my understanding is interleaved in your email
as below.
Best Regards,
Li Fei
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Tuesday, January 29, 2013 7:42 PM
> To: Li, Fei
> Cc: a...@linux-foundation.org; linux-kernel@vger.kernel.org;
> linux...@vger.kernel.org; Liu, Chuansheng
> Subject: Re: [PATCH] suspend: enable freeze timeout configuration through
> sysctl
>
> On Tuesday, January 29, 2013 10:58:20 AM fli24 wrote:
> >
> > At present, the timeout value for freezing tasks is fixed as 20s,
> > which is too long for handheld device usage, especially for mobile
> > phone.
> >
> > In order to improve user experience, we enable freeze timeout
> > configuration through sysctl, so that we can tune the value easily
> > for concrete usage, such as smaller value for handheld device such
> > as mobile phone.
>
> Well, I'd argue that you shouldn't see freeze problems on such systems.
> If you're seeing them, it's better to fix them than to try to hide them
> from users (they are problems after all).
[Li, Fei]
Thanks for your opinion.
Indeed, I see such freeze problems on mobile phone system using fuse file
system.
The scenario is as below:
Thread A with i_mutex held is frozen during waiting for feedback from fuse
daemon;
Thread B is trying to lock i_mutex and can't be frozen.
In the case above, 20s waiting is needless, as freezing will fail unavoidably.
I agree with you that we'd better fix them from the root, which may need
solution of long term.
I also saw some related discussion on Linux community as below, without final
conclusion:
http://lists.linux-foundation.org/pipermail/linux-pm/2008-October/018774.html
So I think if we can enable freezing timeout configuration, it will improve
such issue.
> Do you have a specific example in which that new knob will be useful?
[Li, Fei]
As the scenario stated above, if we can configure the value of timeout to 10s
or other small value,
this time of freezing will be aborted in earlier time, and after i_mutex is
released during thread A restarting,
the next time of suspend/freeze may succeed in relatively earlier time.
> Why do you want to do that through sysctl and not sysfs?
[Li, Fei]
Thanks for your suggestion, sysfs is more suitable, and I'll use sysfs in patch
V2.
> Rafael
>
>
> > Signed-off-by: Liu Chuansheng
> > Signed-off-by: Li Fei
> > ---
> > include/linux/freezer.h |5 +
> > kernel/power/process.c |4 ++--
> > kernel/sysctl.c | 12
> > 3 files changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> > index e4238ce..f37b3be 100644
> > --- a/include/linux/freezer.h
> > +++ b/include/linux/freezer.h
> > @@ -13,6 +13,11 @@ extern bool pm_freezing; /* PM freezing in effect
> */
> > extern bool pm_nosig_freezing; /* PM nosig freezing in effect
> > */
> >
> > /*
> > + * Timeout for stopping processes
> > + */
> > +extern unsigned int sysctl_freeze_process_timeout_secs;
> > +
> > +/*
> > * Check if a process has been frozen
> > */
> > static inline bool frozen(struct task_struct *p)
> > diff --git a/kernel/power/process.c b/kernel/power/process.c
> > index d5a258b..f7eb7c9 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/process.c
> > @@ -21,7 +21,7 @@
> > /*
> > * Timeout for stopping processes
> > */
> > -#define TIMEOUT(20 * HZ)
> > +unsigned int __read_mostly sysctl_freeze_process_timeout_secs = 20;
> >
> > static int try_to_freeze_tasks(bool user_only)
> > {
> > @@ -36,7 +36,7 @@ static int try_to_freeze_tasks(bool user_only)
> >
> > do_gettimeofday();
> >
> > - end_time = jiffies + TIMEOUT;
> > + end_time = jiffies + sysctl_freeze_process_timeout_secs * HZ;
> >
> > if (!user_only)
> > freeze_workqueues_begin();
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index c88878d..f88bcb9 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -90,6 +90,9 @@
> > #include
> > #endif
> >
> > +#ifdef CONFIG_FREEZER
> > +#include
> > +#endif
> >
> > #if defined(CONFIG_SYSCTL)
> >
> > @@ -1047,6 +1050,15 @@ static struct ctl_table kern_table[] = {
> > .proc_handler = proc_dointvec,
> > },
> > #endif
> > +#ifdef CONFIG_FREEZER
> > + {
> > + .procname = "freeze_process_timeout_secs",
> > + .data = _freeze_process_timeout_secs,
> > + .maxlen = sizeof(unsigned int),
> > + .mode = 0644,
> > + .proc_handler = proc_dointvec,
> > + },
> > +#endif
> > { }
> > };
> >
> >
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
[PATCH] pwm-backlight: handle BL_CORE_FBBLANK state
According to include/linux/backlight.h, the fb_blank field is to be removed and blank status should preferably be set by setting the BL_CORE_FBBLANK bit of the state field. This patch ensures this condition is also taken into account when updating the backlight state. Signed-off-by: Alexandre Courbot --- drivers/video/backlight/pwm_bl.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index 069983c..4af6d13 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -41,10 +41,9 @@ static int pwm_backlight_update_status(struct backlight_device *bl) int brightness = bl->props.brightness; int max = bl->props.max_brightness; - if (bl->props.power != FB_BLANK_UNBLANK) - brightness = 0; - - if (bl->props.fb_blank != FB_BLANK_UNBLANK) + if (bl->props.power != FB_BLANK_UNBLANK || + bl->props.fb_blank != FB_BLANK_UNBLANK || + bl->props.state & BL_CORE_FBBLANK) brightness = 0; if (pb->notify) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: adc: add exynos5 adc driver under iio framwork
On 26 January 2013 16:27, Jonathan Cameron wrote:
> On 01/24/2013 04:58 AM, Naveen Krishna Chatradhi wrote:
>> This patch adds driver for ADC IP found on EXYNOS5250 and EXYNOS5410
>> from Samsung. Also adds the Documentation for device tree bindings.
>>
>> Signed-off-by: Naveen Krishna Chatradhi
> Just a quick general comment on patch formatting. For later versions give
> a title of
> [PATCH V5]...
> to the email as then it's easy for those of us who have been sitting
> back and quitely not reading the thread to figure out which the latest
> patch is.
>
> Thanks
>
> Jonathan
Sure Jonathan (I was assuming using message id would be enough), i
will correct it.
>
>> ---
>> Changes since v1:
>>
>> 1. Fixed comments from Lars
>> 2. Added support for ADC on EXYNOS5410
>>
>> Changes since v2:
>>
>> 1. Changed the instance name for (struct iio_dev *) to indio_dev
>> 2. Changed devm_request_irq to request_irq
>>
>> Few doubts regarding the mappings and child device handling.
>> Kindly, suggest me better methods.
>>
>> Changes since v3:
>>
>> 1. Added clk_prepare_disable and regulator_disable calls in _remove()
>> 2. Moved init_completion before irq_request
>> 3. Added NULL pointer check for devm_request_and_ioremap() return value.
>> 4. Use number of channels as per the ADC version
>> 5. Change the define ADC_V1_CHANNEL to ADC_CHANNEL
>> 6. Update the Documentation to include EXYNOS5410 compatible
>>
>> Doug, i've used
>> chan = iio_channel_get(dev_name(>dev), "adc3");
>> in ntc thermistor driver during probe and
>> iio_read_channel_raw(chan, );
>> for read.
>>
>> But, then the drivers become kind of coupled. Right.
>>
>> Lars, Is there an other way.
>>
>> Thanks for the comments
>>
>> .../bindings/arm/samsung/exynos5-adc.txt | 38 ++
>> drivers/iio/adc/Kconfig|7 +
>> drivers/iio/adc/Makefile |1 +
>> drivers/iio/adc/exynos5_adc.c | 475
>>
>> 4 files changed, 521 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> create mode 100644 drivers/iio/adc/exynos5_adc.c
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> new file mode 100644
>> index 000..0f281d9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos5-adc.txt
>> @@ -0,0 +1,38 @@
>> +Samsung Exynos5 Analog to Digital Converter bindings
>> +
>> +Required properties:
>> +- compatible:Must be "samsung,exynos5250-adc" for
>> exynos5250 controllers.
>> + Must be "samsung,exynos5410-adc" for exynos5410
>> controllers.
>> +- reg: Contains ADC register address range (base
>> address and
>> + length).
>> +- interrupts:Contains the interrupt information for the
>> timer. The
>> + format is being dependent on which interrupt controller
>> + the Samsung device uses.
>> +
>> +Note: child nodes can be added for auto probing from device tree.
>> +
>> +Example: adding device info in dtsi file
>> +
>> +adc@12D1 {
>> + compatible = "samsung,exynos5250-adc";
>> + reg = <0x12D1 0x100>;
>> + interrupts = <0 106 0>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +};
>> +
>> +
>> +Example: Adding child nodes in dts file
>> +
>> +adc@12D1 {
>> +
>> + /* NTC thermistor is a hwmon device */
>> + ncp15wb473@0 {
>> + compatible = "ntc,ncp15wb473";
>> + reg = <0x0>;
>> + pullup-uV = <180>;
>> + pullup-ohm = <47000>;
>> + pulldown-ohm = <0>;
>> + };
>> +};
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index fe822a1..33ceabf 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -91,6 +91,13 @@ config AT91_ADC
>> help
>> Say yes here to build support for Atmel AT91 ADC.
>>
>> +config EXYNOS5_ADC
>> + bool "Exynos5 ADC driver support"
>> + help
>> + Core support for the ADC block found in the Samsung EXYNOS5 series
>> + of SoCs for drivers such as the touchscreen and hwmon to use to share
>> + this resource.
>> +
>> config LP8788_ADC
>> bool "LP8788 ADC driver"
>> depends on MFD_LP8788
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index 2d5f100..5b4a4f6 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_AD7791) += ad7791.o
>> obj-$(CONFIG_AD7793) += ad7793.o
>> obj-$(CONFIG_AD7887) += ad7887.o
>> obj-$(CONFIG_AT91_ADC) += at91_adc.o
>> +obj-$(CONFIG_EXYNOS5_ADC) += exynos5_adc.o
>> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>> obj-$(CONFIG_MAX1363) += max1363.o
>> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>> diff --git
Re: [PATCH 0/2] PM / OPP : export symbol consolidation
On Mon, Jan 28, 2013 at 12:26:14PM -0600, Nishanth Menon wrote: > Hi, > This is a consolidation of Rafael's request for usage of EXPORT_SYMBOL_GPL > and requirement for cpufreq helpers to be exported to be used by cpufreq > drivers which may be modules. > > https://patchwork.kernel.org/patch/1847261/ is patch #2 in this series. > > Mark Langsdorf (1): > PM / OPP: Export more symbols for module usage > > Nishanth Menon (1): > PM / OPP: switch exported symbols to GPL variant > The series is needed by cpufreq-cpu0 and imx6q-cpufreq module build. So, for both patches, Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller
Vivek Gautam wrote:
>
> Adding PHY driver support for USB 3.0 controller for Samsung's
> SoCs.
>
> Signed-off-by: Vivek Gautam
> ---
>
> Changes from v3:
> - Making SAMSUNG_USB3PHY dependent on SAMSUNG_USBPHY.
> - Adding USB_DWC3 to dependencies of SAMSUNG_USB2PHY since
>dwc3 controller also looks for USB2 type PHY.
>
> drivers/usb/phy/Kconfig | 11 +-
> drivers/usb/phy/Makefile |1 +
> drivers/usb/phy/samsung-usb3.c | 349
> ++
> drivers/usb/phy/samsung-usbphy.h | 81 +
> 4 files changed, 441 insertions(+), 1 deletions(-)
> create mode 100644 drivers/usb/phy/samsung-usb3.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index cc0d230..9325a95 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -52,14 +52,23 @@ config SAMSUNG_USBPHY
> help
> Enable this to support Samsung USB phy controllers for Samsung
> SoCs.
> + Further enable USB 2.0 type PHY or USB 3.0 type PHY as required
> + for USB controllers in use.
>
> if SAMSUNG_USBPHY
>
> config SAMSUNG_USB2PHY
> bool "Samsung USB 2.0 PHY controller Driver"
> - depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
> USB_OHCI_EXYNOS
> + depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
> USB_OHCI_EXYNOS || USB_DWC3
> help
> Enable this to support Samsung USB 2.0 (High Speed) phy controller
> for Samsung SoCs.
>
> +config SAMSUNG_USB3PHY
> + bool "Samsung USB 3.0 PHY controller Driver"
> + depends on USB_DWC3
> + help
> + Enable this to support Samsung USB 3.0 (Super Speed) phy
> controller
> + for samsung SoCs.
> +
> endif
It mean, when USB_DWC3 is selected, we can select only one USB2PHY or
USB3PHY?
[...]
> +#ifdef CONFIG_OF
> +static const struct of_device_id samsung_usbphy_dt_match[] = {
> + {
> + .compatible = "samsung,exynos5250-usb3-phy",
> + .data = _phy_exynos5
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, samsung_usbphy_dt_match);
> +#endif
> +
> +static struct platform_device_id samsung_usbphy_driver_ids[] = {
> + {
> + .name = "exynos5250-usb3-phy",
According to the name of file, exynos5250-usb3phy? Just it is imho...
> + .driver_data= (unsigned long)_phy_exynos5,
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(platform, samsung_usbphy_driver_ids);
> +
> +static struct platform_driver samsung_usb3_phy_driver = {
> + .probe = samsung_usb3_phy_probe,
> + .remove = samsung_usb3_phy_remove,
> + .id_table = samsung_usbphy_driver_ids,
> + .driver = {
> + .name = "samsung-usb3-phy",
> + .owner = THIS_MODULE,
> + .of_match_table =
> of_match_ptr(samsung_usbphy_dt_match),
> + },
> +};
> +
> +module_platform_driver(samsung_usb3_phy_driver);
> +
> +MODULE_DESCRIPTION("Samsung USB 3.0 phy controller");
> +MODULE_AUTHOR("Vivek Gautam ");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:samsung-usb3-phy");
I want you to use same naming rule.
Thanks.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 0/2] ARM: update cpuinfo to print SoC model name
On Wednesday 30 January 2013 06:08 AM, Ruslan Bilovol wrote: The following patches update cpuinfo to print SoC model name for ARM. The first patch exactly makes needed changes for ARM architecture and adds a common approach to show SoC name. Second patch uses this approach for OMAP4 SoCs (as live example). Looks like there were few attempts to do similar changes to cpuinfo without any luck (had stuck on review) so this functionality is still not in the kernel yet. In this patch series the update to cpuinfo is very short (10 lines) and easy. Comments are welcome as usual As most of the people already commented, your purpose behind the series isn't clear so please give examples where and why you need device type information from user-space. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lockup in barely-patched 3.7.5, maybe wifi/ath9k or i2c related
On 01/29/2013 06:18 PM, Ben Greear wrote: I've been seeing strange lockups since 3.7.4. Not so easily reproducible most of the time. Previous lockups looked to be rcu/rtnl based, but the one below has a bunch of i2c stuff in it. Patches applied are a few wifi patches from upstream and one hack to make ath9k able to over-ride the eeprom regdomain. I *think* the decodes are proper, I had to switch back to this patch set and re-compile I saw another lockup, in a similar spot (but no i2c stuff this time). I had also recompiled so that it would not panic on lockup, and by the time I noticed the problem, it seems the lockup resolved itself and the system was stable. So, maybe a false positive on the lockup detector, or maybe it really was locked for a while but then recovered... Thanks, Ben [ 157.985459] sta3: associated [ 274.864154] [sched_delayed] sched: RT throttling activated [ 400.110028] BUG: soft lockup - CPU#1 stuck for 22s! [kworker/1:2:1140] [ 400.110028] Modules linked in: iptable_raw xt_CT nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge veth ip_gre ] [ 400.110028] irq event stamp: 9992689 [ 400.110028] hardirqs last enabled at (9992688): [] __free_pages_ok+0x8f/0xd0 [ 400.110028] hardirqs last disabled at (9992689): [] apic_timer_interrupt+0x32/0x40 [ 400.110028] softirqs last enabled at (4914834): [] __do_softirq+0x10b/0x170 [ 400.110028] softirqs last disabled at (4914915): [] do_softirq+0x9d/0xf0 [ 400.110028] Pid: 1140, comm: kworker/1:2 Tainted: G C 3.7.5+ #39 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled. [ 400.110028] EIP: 0060:[] EFLAGS: 0202 CPU: 1 [ 400.110028] EIP is at __free_pages_ok+0x93/0xd0 [ 400.110028] EAX: 0202 EBX: f6847900 ECX: 0002 EDX: f5ebba74 [ 400.110028] ESI: 0003 EDI: 0202 EBP: f5cc1c34 ESP: f5cc1c24 [ 400.110028] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 400.110028] CR0: 8005003b CR2: 09f2f468 CR3: 00c83000 CR4: 07e0 [ 400.110028] DR0: DR1: DR2: DR3: [ 400.110028] DR6: 0ff0 DR7: 0400 [ 400.110028] Process kworker/1:2 (pid: 1140, ti=f5cc task=f5ebb540 task.ti=f75d2000) [ 400.110028] Stack: [ 400.110028] f6847900 eff25480 f13cfa00 f5cc1c3c c04ea624 f5cc1c48 c04ef6f0 [ 400.110028] f6847900 f5cc1c5c c04ef7df eff25480 eff25480 f13cfa00 f5cc1c64 c04efd4c [ 400.110028] f5cc1c6c c0854d0f f5cc1c7c c0855a3c eff25480 f09b4000 f5cc1c88 c0855a72 [ 400.110028] Call Trace: [ 400.110028] [] free_compound_page+0x14/0x20 [ 400.110028] [] __put_compound_page+0x10/0x20 [ 400.110028] [] put_compound_page+0x4f/0x190 [ 400.110028] [] put_page+0x2c/0x40 [ 400.110028] [] skb_free_head+0x2f/0x50 [ 400.110028] [] skb_release_data+0x8c/0xb0 [ 400.110028] [] __kfree_skb+0x12/0x90 [ 400.110028] [] kfree_skb+0x17/0x40 [ 400.110028] [] pfifo_fast_enqueue+0x65/0x80 [ 400.110028] [] dev_queue_xmit+0x1e0/0x6e0 [ 400.110028] [] ? ptype_seq_start+0xa0/0xa0 [ 400.110028] [] ieee80211_deliver_skb+0xb1/0x1a0 [mac80211] [ 400.110028] [] ieee80211_rx_handlers+0xd28/0x1940 [mac80211] [ 400.110028] [] ? trace_hardirqs_on_caller+0xa1/0x180 [ 400.110028] [] ? trace_hardirqs_on+0xb/0x10 [ 400.110028] [] ? _raw_spin_unlock_irqrestore+0x3f/0x80 [ 400.110028] [] ieee80211_prepare_and_rx_handle+0x2de/0xaf0 [mac80211] [ 400.110028] [] ieee80211_rx+0x35b/0xa80 [mac80211] [ 400.110028] [] ? ieee80211_rx+0xb1/0xa80 [mac80211] [ 400.110028] [] ath_rx_tasklet+0xde8/0x1340 [ath9k] [ 400.110028] [] ? mark_held_locks+0x64/0xf0 [ 400.110028] [] ath9k_tasklet+0xdf/0x130 [ath9k] [ 400.110028] [] tasklet_action+0xbc/0xd0 [ 400.110028] [] __do_softirq+0xa0/0x170 [ 400.110028] [] ? irq_enter+0x70/0x70 [ 400.110028] [] ? irq_enter+0x70/0x70 [ 400.110028] [ 400.110028] [] ? irq_exit+0xbd/0xe0 [ 400.110028] [] ? do_IRQ+0x46/0xb0 [ 400.110028] [] ? common_interrupt+0x38/0x40 [ 400.110028] [] ? cpufreq_frequency_table_target+0xf2/0x1c0 [ 400.110028] [] ? mark_held_locks+0x64/0xf0 [ 400.110028] [] ? acpi_cpufreq_target+0x6f/0x3b0 [ 400.110028] [] ? smp_call_function_single+0x9c/0x180 [ 400.110028] [] ? mark_held_locks+0x64/0xf0 [ 400.110028] [] ? cpufreq_get_measured_perf+0xd0/0xd0 [ 400.110028] [] ? cpufreq_get_measured_perf+0xba/0xd0 [ 400.110028] [] ? do_drv_read+0x50/0x50 [ 400.110028] [] ? __cpufreq_driver_target+0x48/0xa0 [ 400.110028] [] ? cpufreq_cpu_put+0x17/0x20 [ 400.110028] [] ? __cpufreq_driver_getavg+0x3d/0x70 [ 400.110028] [] ? dbs_check_cpu+0x2d8/0x370 [ 400.110028] [] ? do_dbs_timer+0x35/0xe0 [ 400.110028] [] ? do_dbs_timer+0x87/0xe0 [ 400.110028] [] ? process_one_work+0x1a6/0x3d0 [ 400.110028] [] ? process_one_work+0x139/0x3d0 [ 400.110028] [] ? worker_thread+0x198/0x380 [ 400.110028] [] ? store_ignore_nice_load+0x1c0/0x1c0 [ 400.110028] [] ? worker_thread+0x102/0x380 [ 400.110028] [] ? trace_hardirqs_on+0xb/0x10 [ 400.110028] [] ?
RE: [PATCH v4 1/2] usb: phy: samsung: Common out the generic stuff
Vivek Gautam wrote:
>
> Moving register and structure definitions to header file,
> and keeping the generic functions to be used across
> multiple PHYs in common file "samsung-usbphy.c".
> Also renaming the usb 2.0 phy driver to "samsung-usb2.c"
Just in my opinion, Samsung-usb2phy is more clear?...In addition, I looked
at using SAMSUNG_USB2PHY as a statement.
>
> Signed-off-by: Vivek Gautam
> ---
>
> Changes from v3:
> - Using separate config SAMSUNG_USB2PHY dependent on
>SAMSUNG_USBPHY for samsung-usb2 type PHY controller.
>
> drivers/usb/phy/Kconfig | 14 +-
> drivers/usb/phy/Makefile |1 +
> drivers/usb/phy/samsung-usb2.c | 511 +++
> drivers/usb/phy/samsung-usbphy.c | 714
+-
> drivers/usb/phy/samsung-usbphy.h | 247 +
> 5 files changed, 778 insertions(+), 709 deletions(-)
> create mode 100644 drivers/usb/phy/samsung-usb2.c
> create mode 100644 drivers/usb/phy/samsung-usbphy.h
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index fae4d08..cc0d230 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -48,8 +48,18 @@ config USB_RCAR_PHY
>
> config SAMSUNG_USBPHY
> bool "Samsung USB PHY controller Driver"
> - depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
> USB_OHCI_EXYNOS
So this can be selected without any dependency?
> select USB_OTG_UTILS
> help
> - Enable this to support Samsung USB phy controller for samsung
> + Enable this to support Samsung USB phy controllers for Samsung
> SoCs.
Hmm, according to above comments, this should be enabled under Samsung SoC?
> +
> +if SAMSUNG_USBPHY
Why is this needed here?
> +
> +config SAMSUNG_USB2PHY
> + bool "Samsung USB 2.0 PHY controller Driver"
> + depends on USB_S3C_HSOTG || USB_EHCI_S5P ||
> USB_OHCI_EXYNOS
> + help
> + Enable this to support Samsung USB 2.0 (High Speed) phy controller
> + for Samsung SoCs.
> +
> +endif
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index ec304f6..7ba9862 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_MV_U3D_PHY)+=
> mv_u3d_phy.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
> obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
> +obj-$(CONFIG_SAMSUNG_USB2PHY)+= samsung-usb2.o
> diff --git a/drivers/usb/phy/samsung-usb2.c b/drivers/usb/phy/samsung-
> usb2.c
> new file mode 100644
> index 000..9a9d1d0
> --- /dev/null
> +++ b/drivers/usb/phy/samsung-usb2.c
> @@ -0,0 +1,511 @@
> +/* linux/drivers/usb/phy/samsung-usb2.c
> + *
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Author: Praveen Paneri
> + *
> + * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller,
EHCI-S5P
> and
> + * OHCI-EXYNOS controllers.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "samsung-usbphy.h"
> +
> +int samsung_usbphy_set_host(struct usb_otg *otg, struct usb_bus *host)
For naming, if you want to support usb 2.0 phy here, the name of fuction
should be changed to more clear name such as usb2phy or whatever.
As I'm understanding, the samsung-usbphy.c can be used for common stuff and
this is for only usb 2.0 phy.
[...]
> +#ifdef CONFIG_OF
> +static const struct of_device_id samsung_usbphy_dt_match[] = {
> + {
> + .compatible = "samsung,s3c64xx-usbphy",
> + .data = _s3c64xx,
> + }, {
> + .compatible = "samsung,exynos4210-usbphy",
> + .data = _exynos4,
> + }, {
> + .compatible = "samsung,exynos5250-usbphy",
> + .data = _exynos5
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, samsung_usbphy_dt_match);
> +#endif
> +
> +static struct platform_device_id samsung_usbphy_driver_ids[] = {
> + {
> + .name = "s3c64xx-usbphy",
> + .driver_data= (unsigned long)_s3c64xx,
> + }, {
> + .name = "exynos4210-usbphy",
> + .driver_data= (unsigned long)_exynos4,
> + }, {
> + .name = "exynos5250-usbphy",
> + .driver_data= (unsigned long)_exynos5,
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(platform,
Re: [PATCH v6 08/15] memory-hotplug: Common APIs to support page tables hot-remove
On 01/30/2013 11:27 AM, Simon Jeons wrote:
On Wed, 2013-01-30 at 10:16 +0800, Tang Chen wrote:
On 01/29/2013 09:04 PM, Simon Jeons wrote:
Hi Tang,
On Wed, 2013-01-09 at 17:32 +0800, Tang Chen wrote:
From: Wen Congyang
When memory is removed, the corresponding pagetables should alse be removed.
This patch introduces some common APIs to support vmemmap pagetable and x86_64
architecture pagetable removing.
Why don't need to build_all_zonelists like online_pages does during
hot-add path(add_memory)?
Hi Simon,
As you said, build_all_zonelists is done by online_pages. When the
memory device
is hot-added, we cannot use it. we can only use is when we online the
pages on it.
Why?
If a node has just one memory device and memory is small, some zone will
not present like zone_highmem, then hot-add another memory device and
zone_highmem appear, if you should build_all_zonelists this time?
Hi Simon,
We built zone list when the first memory on the node is hot-added.
add_memory()
|-->if (!node_online(nid)) hotadd_new_pgdat()
|-->free_area_init_node()
|-->build_all_zonelists()
All the zones on the new node will be initialized as empty. So here, we
build zone list.
But actually we did nothing because no page is online, and zones are empty.
In build_zonelists_node(), populated_zone(zone) will always be false.
The real work of building zone list is when pages are online. :)
And in your question, you said some small memory is there, and
zone_normal is present.
OK, when these pages are onlined (not added), the zone list has been
rebuilt.
But pages in zone_highmem is not added, which means not onlined, so we
don't need to
build zone list for it. And later, the zone_highmem pages are added, we
still don't
rebuild the zone list because the real rebuilding work is when the pages
are onlined.
I think this is the current logic. :)
Thanks. :)
But we can online the pages as different types, kernel or movable (which
belongs to
different zones), and we can online part of the memory, not all of them.
So each time we online some pages, we should check if we need to update
the zone list.
So I think that is why we do build_all_zonelists when online_pages.
(just my opinion)
Thanks. :)
All pages of virtual mapping in removed memory cannot be freedi if some pages
used as PGD/PUD includes not only removed memory but also other memory. So the
patch uses the following way to check whether page can be freed or not.
1. When removing memory, the page structs of the revmoved memory are filled
with 0FD.
2. All page structs are filled with 0xFD on PT/PMD, PT/PMD can be cleared.
In this case, the page used as PT/PMD can be freed.
Signed-off-by: Yasuaki Ishimatsu
Signed-off-by: Jianguo Wu
Signed-off-by: Wen Congyang
Signed-off-by: Tang Chen
---
arch/x86/include/asm/pgtable_types.h |1 +
arch/x86/mm/init_64.c| 299
++
arch/x86/mm/pageattr.c | 47 +++---
include/linux/bootmem.h |1 +
4 files changed, 326 insertions(+), 22 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_types.h
b/arch/x86/include/asm/pgtable_types.h
index 3c32db8..4b6fd2a 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -352,6 +352,7 @@ static inline void update_page_count(int level, unsigned
long pages) { }
* as a pte too.
*/
extern pte_t *lookup_address(unsigned long address, unsigned int *level);
+extern int __split_large_page(pte_t *kpte, unsigned long address, pte_t
*pbase);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 9ac1723..fe01116 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -682,6 +682,305 @@ int arch_add_memory(int nid, u64 start, u64 size)
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+#define PAGE_INUSE 0xFD
+
+static void __meminit free_pagetable(struct page *page, int order)
+{
+ struct zone *zone;
+ bool bootmem = false;
+ unsigned long magic;
+ unsigned int nr_pages = 1<< order;
+
+ /* bootmem page has reserved flag */
+ if (PageReserved(page)) {
+ __ClearPageReserved(page);
+ bootmem = true;
+
+ magic = (unsigned long)page->lru.next;
+ if (magic == SECTION_INFO || magic == MIX_SECTION_INFO) {
+ while (nr_pages--)
+ put_page_bootmem(page++);
+ } else
+ __free_pages_bootmem(page, order);
+ } else
+ free_pages((unsigned long)page_address(page), order);
+
+ /*
+* SECTION_INFO pages and MIX_SECTION_INFO pages
+* are all allocated by bootmem.
+*/
+ if (bootmem) {
+ zone = page_zone(page);
+ zone_span_writelock(zone);
+ zone->present_pages +=
Re: [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
On Wednesday 30 January 2013 04:42 AM, Ruslan Bilovol wrote: Hi, On Tue, Jan 29, 2013 at 6:08 PM, Russell King - ARM Linux wrote: On Tue, Jan 29, 2013 at 05:54:24PM +0200, Ruslan Bilovol wrote: CPU implementer : 0x41 CPU name: OMAP4470 ES1.0 HS Sigh. No. Look at what you're doing - look carefully at the above. "CPU implementer" - 0x41. That's A. For ARM Ltd. ARM Ltd implemented this CPU. Did ARM Ltd really implement OMAP4470 ? I think TI would be very upset if that were to be the case. Yes, it would be very surprisingly :) So no, OMAP4470 is _NOT_ a CPU. It is a SoC. The CPU inside the SoC is a collection of ARM Ltd Cortex A9 _CPUs_. See? Please, learn what a CPU is as opposed to a SoC. Completely agree with you. I will fix this Thank god you agreed to drop your current approach. Please elaborate what you are going to fix and also state what user-space features changes from OMAP4460 to OMAP4470. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] cpufreq: star/stop cpufreq timers on cpu hotplug
On Wed, 2013-01-30 at 12:52 +0800, Viresh Kumar wrote:
> Hi Fabio,
>
> Sorry for waking up very late :)
>
> The reason why i am starting this thread again is due to problem
> reported by Joseph,
> with latest linux-next/master branch (which contains few big patches
> from me :) ):
>
After Viresh point me out what patch may cause the issue that I met
below, I also try to just revert this patch on linux-next. Then
everything that may trigger to disable_nonboot_cpus or hotplug back to
normal. So just reverting this patch also fix the issues I saw.
FYI.
Thanks,
Joseph
> Reboot is giving following to him:
>
> * Will now halt
> [ 193.756068] Disabling non-boot CPUs...
> [ 193.760088] BUG: scheduling while atomic: halt/780/0x0002
> [ 193.765845] Modules linked in: brcmfmac brcmutil
> [ 193.770613] [] (unwind_backtrace+0x0/0xf8) from []
> (__schedule_bug+0x44/0x5c)
> [ 193.779548] [] (__schedule_bug+0x44/0x5c) from []
> (__schedule+0x688/0x6ec)
> [ 193.788206] [] (__schedule+0x688/0x6ec) from []
> (schedule_preempt_disabled+0x24/0x34)
> [ 193.797811] [] (schedule_preempt_disabled+0x24/0x34) from
> [] (__mutex_lock_slowpath+0x170/0x34c)
> [ 193.808367] [] (__mutex_lock_slowpath+0x170/0x34c) from
> [] (mutex_lock+0xc/0x24)
> [ 193.817554] [] (mutex_lock+0xc/0x24) from []
> (unregister_cpu_notifier+0xc/0x24)
> [ 193.826640] [] (unregister_cpu_notifier+0xc/0x24) from
> [] (cpufreq_governor_dbs+0x118/0x614)
> [ 193.836866] [] (cpufreq_governor_dbs+0x118/0x614) from
> [] (__cpufreq_governor+0x58/0xc0)
> [ 193.846737] [] (__cpufreq_governor+0x58/0xc0) from
> [] (__cpufreq_remove_dev.clone.7+0x58/0x320)
> [ 193.857207] [] (__cpufreq_remove_dev.clone.7+0x58/0x320)
> from [] (cpufreq_cpu_callback+0x8c/0x9c)
> [ 193.867850] [] (cpufreq_cpu_callback+0x8c/0x9c) from
> [] (notifier_call_chain+0x44/0x84)
> [ 193.877623] [] (notifier_call_chain+0x44/0x84) from
> [] (__cpu_notify+0x2c/0x48)
> [ 193.886704] [] (__cpu_notify+0x2c/0x48) from []
> (_cpu_down+0xb0/0x23c)
> [ 193.895004] [] (_cpu_down+0xb0/0x23c) from []
> (disable_nonboot_cpus+0x68/0x104)
> [ 193.904089] [] (disable_nonboot_cpus+0x68/0x104) from
> [] (kernel_power_off+0x24/0x48)
> [ 193.913688] [] (kernel_power_off+0x24/0x48) from
> [] (sys_reboot+0x104/0x1e0)
> [ 193.922517] [] (sys_reboot+0x104/0x1e0) from []
> (ret_fast_syscall+0x0/0x30)
>
>
> And the crash log show this patch of yours somewhere :)
>
> First question: Is this patch still required? Because following patch from me
> is
> sending a STOP/START to governors on cpu hot-[un]plug ?
>
> commit dbcb63407c095af73f3464767e00902cdee55e8b
> Author: Viresh Kumar
> Date: Sat Jan 12 05:14:39 2013 +
>
> cpufreq: Notify governors when cpus are hot-[un]plugged
>
>
> For me, the answer is NO.
>
> Over that, i tried these patches on ARM bigLITTLE TC2 (3 A7's and 2 A15's)
> and
> my system wasn't booting at all for ondemand governor. Reverting your patch
> does
> fix the issue:
>
> [2.613573] arm_big_little: bL_cpufreq_init: Initialized, cpu: 0, cluster 0
> [2.635436] arm_big_little: bL_cpufreq_init: Initialized, cpu: 2, cluster 1
> [ 23.650184] INFO: rcu_sched self-detected stall on CPU { 0}
> (t=2100 jiffies g=4294967088 c=4294967087 q=10)
> [ 23.679664] Backtrace for cpu 0 (current):
> [ 23.680239] INFO: rcu_sched detected stalls on CPUs/tasks: { 0}
> (detected by 2, t=2103 jiffies, g=4294967088, c=4294967087, q=10)
> [ 23.726839] [] (unwind_backtrace+0x0/0xf8) from
> [] (smp_send_all_cpu_backtrace+0x60/0xcc)
> [ 23.756545] [] (smp_send_all_cpu_backtrace+0x60/0xcc)
> from [] (rcu_pending+0x2c8/0x63c)
> [ 23.785731] [] (rcu_pending+0x2c8/0x63c) from
> [] (rcu_check_callbacks+0x7c/0x148)
> [ 23.813358] [] (rcu_check_callbacks+0x7c/0x148) from
> [] (update_process_times+0x38/0x68)
> [ 23.842808] [] (update_process_times+0x38/0x68) from
> [] (tick_sched_handle+0x48/0x54)
> [ 23.871472] [] (tick_sched_handle+0x48/0x54) from
> [] (tick_sched_timer+0x44/0x74)
> [ 23.899098] [] (tick_sched_timer+0x44/0x74) from
> [] (__run_hrtimer+0x84/0x1b4)
> [ 23.925940] [] (__run_hrtimer+0x84/0x1b4) from
> [] (hrtimer_interrupt+0x108/0x2d4)
> [ 23.953563] [] (hrtimer_interrupt+0x108/0x2d4) from
> [] (arch_timer_handler_virt+0x30/0x38)
> [ 23.983530] [] (arch_timer_handler_virt+0x30/0x38) from
> [] (handle_percpu_devid_irq+0x74/0x110)
> [ 24.014799] [] (handle_percpu_devid_irq+0x74/0x110) from
> [] (generic_handle_irq+0x20/0x30)
> [ 24.044765] [] (generic_handle_irq+0x20/0x30) from
> [] (handle_IRQ+0x38/0x94)
> [ 24.071085] [] (handle_IRQ+0x38/0x94) from []
> (gic_handle_irq+0x28/0x5c)
> [ 24.096362] [] (gic_handle_irq+0x28/0x5c) from
> [] (__irq_svc+0x40/0x50)
> [ 24.121374] Exception stack(0xef047ec0 to 0xef047f08)
> [ 24.136492] 7ec0: c0591780 c0591798 c0591780
> c05d5d60 c0593280
> [ 24.160986] 7ee0: c0552c98 c02b1df4 ef046000 c059179c
> ef047f08 c03b5f84 c0043698
> [ 24.185477] 7f00: a113
> [
Re: [RFC PATCH v2 1/2] ARM: kernel: update cpuinfo to print SoC model name
On Tue, Jan 29, 2013 at 6:38 PM, Ruslan Bilovol wrote: > > SoC name: OMAP4470 ES1.0 HS I am sorry, but I have to NAK for specifically reasons explained in http://marc.info/?l=linux-omap=135950276616961=2 I just dont think SoC information belongs in /proc/cpuinfo. nor is SoC name "OMAP4470 ES1.0 HS" -> it is just OMAP4470. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] SUNRPC: protect transport processing with rw sem
30.01.2013 02:57, J. Bruce Fields пишет: On Tue, Jan 29, 2013 at 02:03:30PM +0300, Stanislav Kinsbursky wrote: There could be a service transport, which is processed by service thread and racing in the same time with per-net service shutdown like listed below: CPU#0:CPU#1: svc_recvsvc_close_net svc_get_next_xprt (list_del_init(xpt_ready)) svc_close_list (set XPT_BUSY and XPT_CLOSE) svc_clear_pools(xprt was gained on CPU#0 already) svc_delete_xprt (set XPT_DEAD) svc_handle_xprt (is XPT_CLOSE => svc_delete_xprt() BUG() There could be different solutions of the problem. Probably, the patch doesn't implement the best one, but I hope the simple one. IOW, it protects critical section (dequeuing of pending transport and enqueuing it back to the pool) by per-service rw semaphore, It's actually per-thread (per-struct svc_rqst) here. Yes, sure. taken for read. On per-net transports shutdown, this semaphore have to be taken for write. There's no down_write in this patch. Did you forget this part? See "fs/nfs/callback.c" part The server rpc code goes to some care not to write to any global structure, to prevent server threads running on multiple cores from bouncing cache lines between them. This is just an idea. I.e. I wasn't trying to polish the patch - just to share the vision. But my understanding is that even down_read() does modify the semaphore. So we might want something like the percpu semaphore describe in Documentation/percpu-rw-semaphore.txt. Sure, I'll have a look. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf 3.8-rc build failure: undefined reference to `strlcpy'
On Wed, Jan 30, 2013 at 01:56:34PM +0900, Namhyung Kim wrote: > That's because the toplevel Makefile resets MAKEFLAGS in the middle: That was me: ea01fa9f63aef > > Makefile:1330 > # Clear a bunch of variables before executing the submake and I added this because there was a problem AFAICR. And why I added it, is not documented in the patch commit message, crap. > tools/: FORCE > $(Q)mkdir -p $(objtree)/tools > $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C > $(src)/tools/ > > tools/%: FORCE > $(Q)mkdir -p $(objtree)/tools > $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C > $(src)/tools/ $* > > So why should it be reset in the first place? Oh yeah, it was some interaction with the toplevel Makefile that caused issues. Here's one, if you remove MAKEFLAGS= above and dump it in the target, here's what you get: $ make -j9 tools/perf_clean MAKEFLAGS: --no-print-directory -Rr --jobserver-fds=5,7 -j -I /w/kernel/linux-2.6 DESCEND perf make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. SUBDIR ../lib/traceevent/ *.o *~ libtraceevent.a libtraceevent.so *.a *.so ep_version.h .*.d /bin/sh: 1: *.o: not found make[4]: *** [clean] Error 127 make[3]: *** [sub-make] Error 2 make[2]: *** [/w/kernel/linux-2.6/tools/perf/libtraceevent.a-clean] Error 2 make[1]: *** [perf_clean] Error 2 make: *** [tools/perf_clean] Error 2 The "rm -f" is missing at the beginning of the line because kbuild does remove build files differently. If you leave it in, it works fine: DESCEND perf SUBDIR ../lib/traceevent/ rm -f *.o *~ libtraceevent.a libtraceevent.so *.a *.so ep_version.h .*.d ... > > Oh, and one more thing, there's tools/scripts/Makefile.include which > > looks at -s already and perf/Makefile includes it so you probably want > > to put your change there so that all tools use it. > > Are you suggesting that moving "try-cc" to the Makefile.include? Forget it, I got confused with the QUIET_* thingies in Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 2/2] ARM: Exynos5250: Enabling samsung-usb3-phy driver
Vivek Gautam wrote:
>
> Adding usb3.0 phy node for Exynos5250 along with the
> necessary device data to be parsed.
>
> Signed-off-by: Vivek Gautam
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 610e338..018a70d 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -275,6 +275,19 @@
> #size-cells = <0>;
> };
>
> + usbphy@1210 {
> + compatible = "samsung,exynos5250-usb3-phy";
> + reg = <0x1210 0x100>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usbphy-sys {
> + /* USB device and host PHY_CONTROL registers
*/
> + reg = <0x10040704 0x8>;
> + };
> + };
> +
> usbphy@1213 {
> compatible = "samsung,exynos5250-usbphy";
> reg = <0x1213 0x100>;
> --
> 1.7.6.5
Same as previous comments.
Thanks.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ata: Fix DVD not dectected at some Haswell platforms
There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d fix the 4 ports
IDE controller 32bit PIO mode.
Recently, the problem was showed at Haswell platform which includes 2 ports
IDE controller.
So introduce a qurik patch to disable 32bit PIO at this IDE controller.
Signed-off-by: Youquan Song
---
drivers/ata/ata_piix.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index ef773e1..1993e52 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -150,6 +150,7 @@ enum piix_controller_ids {
tolapai_sata,
piix_pata_vmw, /* PIIX4 for VMware, spurious DMA_ERR */
ich8_sata_snb,
+ ich8_2port_sata_snb,
};
struct piix_map_db {
@@ -326,7 +327,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
/* SATA Controller IDE (Lynx Point) */
- { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Lynx Point-LP) */
@@ -502,6 +503,7 @@ static const struct piix_map_db *piix_map_db_table[] = {
[ich8m_apple_sata] = _apple_map_db,
[tolapai_sata] = _map_db,
[ich8_sata_snb] = _map_db,
+ [ich8_2port_sata_snb] = _2port_map_db,
};
static struct ata_port_info piix_port_info[] = {
@@ -643,6 +645,16 @@ static struct ata_port_info piix_port_info[] = {
.port_ops = _sata_ops,
},
+ [ich8_2port_sata_snb] =
+ {
+ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SIDPR |
PIIX_FLAG_PIO16,
+ .pio_mask = ATA_PIO4,
+ .mwdma_mask = ATA_MWDMA2,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _sata_ops,
+ },
+
+
};
static struct pci_bits piix_enable_bits[] = {
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ata: Fix DVD not dectected at some Haswell platforms
There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d fix the 4 ports
IDE controller 32bit PIO mode.
Recently, the problem was showed at Haswell platform which includes 2 ports
IDE controller.
So introduce a qurik patch to disable 32bit PIO at this IDE controller.
Signed-off-by: Youquan Song
---
drivers/ata/ata_piix.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index ef773e1..1993e52 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -150,6 +150,7 @@ enum piix_controller_ids {
tolapai_sata,
piix_pata_vmw, /* PIIX4 for VMware, spurious DMA_ERR */
ich8_sata_snb,
+ ich8_2port_sata_snb,
};
struct piix_map_db {
@@ -326,7 +327,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
/* SATA Controller IDE (Lynx Point) */
- { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Lynx Point-LP) */
@@ -502,6 +503,7 @@ static const struct piix_map_db *piix_map_db_table[] = {
[ich8m_apple_sata] = _apple_map_db,
[tolapai_sata] = _map_db,
[ich8_sata_snb] = _map_db,
+ [ich8_2port_sata_snb] = _2port_map_db,
};
static struct ata_port_info piix_port_info[] = {
@@ -643,6 +645,16 @@ static struct ata_port_info piix_port_info[] = {
.port_ops = _sata_ops,
},
+ [ich8_2port_sata_snb] =
+ {
+ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SIDPR |
PIIX_FLAG_PIO16,
+ .pio_mask = ATA_PIO4,
+ .mwdma_mask = ATA_MWDMA2,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _sata_ops,
+ },
+
+
};
static struct pci_bits piix_enable_bits[] = {
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/2] ARM: Exynos5250: Enabling samsung-usbphy driver
Vivek Gautam wrote:
>
> Adding usbphy node for Exynos5250 along with the
> necessary device data to be parsed.
>
> Signed-off-by: Vivek Gautam
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 30485de..610e338 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -275,6 +275,21 @@
> #size-cells = <0>;
> };
>
> + usbphy@1213 {
Please put above node by order of address.
> + compatible = "samsung,exynos5250-usbphy";
> + reg = <0x1213 0x100>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usbphy-sys {
> + /* USB device and host PHY_CONTROL registers
*/
Please add the binding documentation instead of comment here.
> + reg = <0x10040704 0x8>,
> + /* USB2.0 PHY configuration register */
> + <0x10050230 0x4>;
> + };
> + };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <1>;
> --
> 1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 0/5] Reset PCIe devices to address DMA problem on kdump with iommu
(2013/01/29 10:14), Thomas Renninger wrote: > On Thursday, January 24, 2013 09:23:14 AM Takao Indoh wrote: >> (2013/01/23 9:47), Thomas Renninger wrote: >>> On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote: (2013/01/08 4:09), Thomas Renninger wrote: >>> ... >>> > I tried the provided patches first on 2.6.32, then I verfied with > 3.8-rc2 > and in both cases the disk is not detected anymore in > reset_devices (kexec'ed/kdump) case (but things work fine without these > patches). So the problem that the disk is not detected was caused by exactmap problem you guys are discussing? Or still not detected even if exactmap problem is fixed? >>> >>> This problem is related to the 5 PCI resetting patches. >>> Dumping worked with a 2.6.32 and a 3.8-rc2 kernel, adding the PCI >>> resetting >>> patches broke both. I first tried 2.6.32 and verified with 3.8-rc2 to make >>> sure I didn't mess up the backport adjustings of the patches to 2.6.32. >> If you have a chance please try again the patches with the latest >> firmware. > Not sure I can update the firmware as this is a reference platform used > exactly > like this in production. Anyway it seems that resetting device makes the disks disappear from your system. I'm wondering if this reset mechanism should be disabled by default and be enabled by boot parameter like reset_devices_on_dmar_fault to prevent a regression like your case. Thanks, Takao Indoh > > I also cannot see how this could help. > > Thomas > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf 3.8-rc build failure: undefined reference to `strlcpy'
On Wed, 30 Jan 2013 04:28:31 +0100, Borislav Petkov wrote: > On Wed, Jan 30, 2013 at 11:15:55AM +0900, Namhyung Kim wrote: >> Please see my reply on another post from Thomas: >> >> https://lkml.org/lkml/2013/1/29/32 >> >> It's not like a build failure of perf tools, it's just a result of >> feature test so should not affect the build of perf itself, right? > > Doh, I see it. It is the -DHAVE_STRLCPY test, of course. And it happens > only with a V=1 build, so actually there's not a build problem. > >> Why it confuses us is that we don't show any compile message if -s >> option is given to make, so I posted a patch to hide CHK and above >> failure message when -s option is specified. > > Hm, trying your patch ontop of acme's perf/core still shows CHK stuff > > $ make -s tools/perf > DESCEND perf > CHK -fstack-protector-all > CHK -Wstack-protector > CHK -Wvolatile-register-var > CHK bionic > CHK libelf > CHK libdw > ... > > > and that's because I'm doing the build from the toplevel repo and not in > perf/. If I switch to perf first, it is silent: > > $ make -s > Makefile:809: No bfd.h/libbfd found, install binutils-dev[el]/zlib-static to > gain symbol demangling > Makefile:846: No numa.h found, disables 'perf bench numa mem' benchmark, > please install numa-libs-devel or libnuma-dev > $ That's because the toplevel Makefile resets MAKEFLAGS in the middle: Makefile:1330 # Clear a bunch of variables before executing the submake tools/: FORCE $(Q)mkdir -p $(objtree)/tools $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/ tools/%: FORCE $(Q)mkdir -p $(objtree)/tools $(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/ $* So why should it be reset in the first place? > > Oh, and one more thing, there's tools/scripts/Makefile.include which > looks at -s already and perf/Makefile includes it so you probably want > to put your change there so that all tools use it. Are you suggesting that moving "try-cc" to the Makefile.include? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] cpufreq: star/stop cpufreq timers on cpu hotplug
Hi Fabio,
Sorry for waking up very late :)
The reason why i am starting this thread again is due to problem
reported by Joseph,
with latest linux-next/master branch (which contains few big patches
from me :) ):
Reboot is giving following to him:
* Will now halt
[ 193.756068] Disabling non-boot CPUs...
[ 193.760088] BUG: scheduling while atomic: halt/780/0x0002
[ 193.765845] Modules linked in: brcmfmac brcmutil
[ 193.770613] [] (unwind_backtrace+0x0/0xf8) from []
(__schedule_bug+0x44/0x5c)
[ 193.779548] [] (__schedule_bug+0x44/0x5c) from []
(__schedule+0x688/0x6ec)
[ 193.788206] [] (__schedule+0x688/0x6ec) from []
(schedule_preempt_disabled+0x24/0x34)
[ 193.797811] [] (schedule_preempt_disabled+0x24/0x34) from
[] (__mutex_lock_slowpath+0x170/0x34c)
[ 193.808367] [] (__mutex_lock_slowpath+0x170/0x34c) from
[] (mutex_lock+0xc/0x24)
[ 193.817554] [] (mutex_lock+0xc/0x24) from []
(unregister_cpu_notifier+0xc/0x24)
[ 193.826640] [] (unregister_cpu_notifier+0xc/0x24) from
[] (cpufreq_governor_dbs+0x118/0x614)
[ 193.836866] [] (cpufreq_governor_dbs+0x118/0x614) from
[] (__cpufreq_governor+0x58/0xc0)
[ 193.846737] [] (__cpufreq_governor+0x58/0xc0) from
[] (__cpufreq_remove_dev.clone.7+0x58/0x320)
[ 193.857207] [] (__cpufreq_remove_dev.clone.7+0x58/0x320)
from [] (cpufreq_cpu_callback+0x8c/0x9c)
[ 193.867850] [] (cpufreq_cpu_callback+0x8c/0x9c) from
[] (notifier_call_chain+0x44/0x84)
[ 193.877623] [] (notifier_call_chain+0x44/0x84) from
[] (__cpu_notify+0x2c/0x48)
[ 193.886704] [] (__cpu_notify+0x2c/0x48) from []
(_cpu_down+0xb0/0x23c)
[ 193.895004] [] (_cpu_down+0xb0/0x23c) from []
(disable_nonboot_cpus+0x68/0x104)
[ 193.904089] [] (disable_nonboot_cpus+0x68/0x104) from
[] (kernel_power_off+0x24/0x48)
[ 193.913688] [] (kernel_power_off+0x24/0x48) from
[] (sys_reboot+0x104/0x1e0)
[ 193.922517] [] (sys_reboot+0x104/0x1e0) from []
(ret_fast_syscall+0x0/0x30)
And the crash log show this patch of yours somewhere :)
First question: Is this patch still required? Because following patch from me is
sending a STOP/START to governors on cpu hot-[un]plug ?
commit dbcb63407c095af73f3464767e00902cdee55e8b
Author: Viresh Kumar
Date: Sat Jan 12 05:14:39 2013 +
cpufreq: Notify governors when cpus are hot-[un]plugged
For me, the answer is NO.
Over that, i tried these patches on ARM bigLITTLE TC2 (3 A7's and 2 A15's) and
my system wasn't booting at all for ondemand governor. Reverting your patch does
fix the issue:
[2.613573] arm_big_little: bL_cpufreq_init: Initialized, cpu: 0, cluster 0
[2.635436] arm_big_little: bL_cpufreq_init: Initialized, cpu: 2, cluster 1
[ 23.650184] INFO: rcu_sched self-detected stall on CPU { 0}
(t=2100 jiffies g=4294967088 c=4294967087 q=10)
[ 23.679664] Backtrace for cpu 0 (current):
[ 23.680239] INFO: rcu_sched detected stalls on CPUs/tasks: { 0}
(detected by 2, t=2103 jiffies, g=4294967088, c=4294967087, q=10)
[ 23.726839] [] (unwind_backtrace+0x0/0xf8) from
[] (smp_send_all_cpu_backtrace+0x60/0xcc)
[ 23.756545] [] (smp_send_all_cpu_backtrace+0x60/0xcc)
from [] (rcu_pending+0x2c8/0x63c)
[ 23.785731] [] (rcu_pending+0x2c8/0x63c) from
[] (rcu_check_callbacks+0x7c/0x148)
[ 23.813358] [] (rcu_check_callbacks+0x7c/0x148) from
[] (update_process_times+0x38/0x68)
[ 23.842808] [] (update_process_times+0x38/0x68) from
[] (tick_sched_handle+0x48/0x54)
[ 23.871472] [] (tick_sched_handle+0x48/0x54) from
[] (tick_sched_timer+0x44/0x74)
[ 23.899098] [] (tick_sched_timer+0x44/0x74) from
[] (__run_hrtimer+0x84/0x1b4)
[ 23.925940] [] (__run_hrtimer+0x84/0x1b4) from
[] (hrtimer_interrupt+0x108/0x2d4)
[ 23.953563] [] (hrtimer_interrupt+0x108/0x2d4) from
[] (arch_timer_handler_virt+0x30/0x38)
[ 23.983530] [] (arch_timer_handler_virt+0x30/0x38) from
[] (handle_percpu_devid_irq+0x74/0x110)
[ 24.014799] [] (handle_percpu_devid_irq+0x74/0x110) from
[] (generic_handle_irq+0x20/0x30)
[ 24.044765] [] (generic_handle_irq+0x20/0x30) from
[] (handle_IRQ+0x38/0x94)
[ 24.071085] [] (handle_IRQ+0x38/0x94) from []
(gic_handle_irq+0x28/0x5c)
[ 24.096362] [] (gic_handle_irq+0x28/0x5c) from
[] (__irq_svc+0x40/0x50)
[ 24.121374] Exception stack(0xef047ec0 to 0xef047f08)
[ 24.136492] 7ec0: c0591780 c0591798 c0591780
c05d5d60 c0593280
[ 24.160986] 7ee0: c0552c98 c02b1df4 ef046000 c059179c
ef047f08 c03b5f84 c0043698
[ 24.185477] 7f00: a113
[ 24.195910] [] (__irq_svc+0x40/0x50) from []
(raw_notifier_chain_register+0x24/0x54)
[ 24.224314] [] (raw_notifier_chain_register+0x24/0x54)
from [] (register_cpu_notifier+0x18/0x2c)
[ 24.255843] [] (register_cpu_notifier+0x18/0x2c) from
[] (cpufreq_register_driver+0x134/0x190)
[ 24.286852] [] (cpufreq_register_driver+0x134/0x190) from
[] (bL_cpufreq_register+0x68/0xd4)
[ 24.317337] [] (bL_cpufreq_register+0x68/0xd4) from
[] (do_one_initcall+0x110/0x178)
[ 24.345738] [] (do_one_initcall+0x110/0x178) from
[] (kernel_init+0x194/0x330)
[ 24.372577] []
Re: [PATCHv3 5/6] zswap: add to mm/
On Tue, Jan 29, 2013 at 11:26:48AM -0600, Seth Jennings wrote: > On 01/29/2013 12:27 AM, Minchan Kim wrote: > > First feeling is it's simple and nice approach. > > Although we have some problems to decide policy, it could solve by later > > patch > > so I hope we make basic infrasture more solid by lots of comment. > > Thanks very much for the review! > > > > > There are two things to review hard. > > > > 1. data structure life - when any data structure is died by whom? > >Please write down it in changelog or header of zswap.c > > > > 2. Flush routine - I hope it would be nice to separate it as another > >incremental patches if it is possible. If it's impossible, let's add > >lots of words. > > It seems like it would be difficult to break the flushing > functionality into it's own patch, but I can start the process and > see. As long as people keep in mind that some of the design rationale > in the version without the flush code is dictated by the addition of > the flush code. > > But yes, more comments. > > > On Mon, Jan 28, 2013 at 03:49:26PM -0600, Seth Jennings wrote: > >> zswap is a thin compression backend for frontswap. It receives > >> pages from frontswap and attempts to store them in a compressed > >> memory pool, resulting in an effective partial memory reclaim and > >> dramatically reduced swap device I/O. > >> > >> Additional, in most cases, pages can be retrieved from this > >> compressed store much more quickly than reading from tradition > >> swap devices resulting in faster performance for many workloads. > >> > >> This patch adds the zswap driver to mm/ > >> > >> Signed-off-by: Seth Jennings > >> --- > >> mm/Kconfig | 15 + > >> mm/Makefile |1 + > >> mm/zswap.c | 1073 > >> +++ > >> 3 files changed, 1089 insertions(+) > >> create mode 100644 mm/zswap.c > >> > >> diff --git a/mm/Kconfig b/mm/Kconfig > >> index 278e3ab..14b9acb 100644 > >> --- a/mm/Kconfig > >> +++ b/mm/Kconfig > >> @@ -446,3 +446,18 @@ config FRONTSWAP > >> and swap data is stored as normal on the matching swap device. > >> > >> If unsure, say Y to enable frontswap. > >> + > >> +config ZSWAP > >> + bool "In-kernel swap page compression" > >> + depends on FRONTSWAP && CRYPTO > > > > Couldn't we support CRYPTO optionally? > > No. zswap depends on the cryptographic API for access to the > compression modules. I meant I don't want to enable CONFIG_CRYPTO for just using zswap. In case of zram, we didn't need it. Is there any reason we must use encryption for using zswap? > > > > >> + select CRYPTO_LZO > >> + select ZSMALLOC > >> + default n > >> + help > >> +Zswap is a backend for the frontswap mechanism in the VMM. > >> +It receives pages from frontswap and attempts to store them > >> +in a compressed memory pool, resulting in an effective > >> +partial memory reclaim. In addition, pages and be retrieved > >> +from this compressed store much faster than most tradition > >> +swap devices resulting in reduced I/O and faster performance > >> +for many workloads. > >> index 3a46287..1b1ed5c 100644 > >> --- a/mm/Makefile > >> +++ b/mm/Makefile > >> @@ -32,6 +32,7 @@ obj-$(CONFIG_HAVE_MEMBLOCK) += memblock.o > >> obj-$(CONFIG_BOUNCE) += bounce.o > >> obj-$(CONFIG_SWAP)+= page_io.o swap_state.o swapfile.o > >> obj-$(CONFIG_FRONTSWAP) += frontswap.o > >> +obj-$(CONFIG_ZSWAP) += zswap.o > >> obj-$(CONFIG_HAS_DMA) += dmapool.o > >> obj-$(CONFIG_HUGETLBFS) += hugetlb.o > >> obj-$(CONFIG_NUMA)+= mempolicy.o > >> diff --git a/mm/zswap.c b/mm/zswap.c > >> new file mode 100644 > >> index 000..050b6db > >> --- /dev/null > >> +++ b/mm/zswap.c > >> @@ -0,0 +1,1073 @@ > >> +/* > >> + * zswap-drv.c - zswap driver file > >> + * > >> + * zswap is a backend for frontswap that takes pages that are in the > >> + * process of being swapped out and attempts to compress them and store > >> + * them in a RAM-based memory pool. This results in a significant I/O > >> + * reduction on the real swap device and, in the case of a slow swap > >> + * device, can also improve workload performance. > >> + * > >> + * Copyright (C) 2012 Seth Jennings > >> + * > >> + * This program is free software; you can redistribute it and/or > >> + * modify it under the terms of the GNU General Public License > >> + * as published by the Free Software Foundation; either version 2 > >> + * of the License, or (at your option) any later version. > >> + * > >> + * This program is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> + * GNU General Public License for more details. > >> +*/ > >> + > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include
Re: [PATCHv4 0/7] zswap: compressed swap caching
On Tue, Jan 29, 2013 at 04:49:04PM -0600, Seth Jennings wrote: > On 01/29/2013 04:14 PM, Joe Perches wrote: > > On Tue, 2013-01-29 at 15:40 -0600, Seth Jennings wrote: > >> The code required for the flushing is in a separate patch now > >> as requested. > > > > What tree does this apply to? > > Both -next and linus fail to compile. > > Link to build instruction in the cover letter: > > >> NOTE: To build, read this: > >> http://lkml.org/lkml/2013/1/28/586 > > The complexity is due to a conflict with a zsmalloc patch in Greg's > staging tree that has yet to make its way upstream. > > Sorry for the inconvenience. Seth, Please don't ignore previous review if you didn't convince reviewer. I don't want to consume time with arguing trivial things. Copy and Paste from previous discussion from zsmalloc pathset > > > On Fri, Jan 25, 2013 at 11:46:14AM -0600, Seth Jennings wrote: > > >> These patches are the first 4 patches of the zswap patchset I > > >> sent out previously. Some recent commits to zsmalloc and > > >> zcache in staging-next forced a rebase. While I was at it, Nitin > > >> (zsmalloc maintainer) requested I break these 4 patches out from > > >> the zswap patchset, since they stand on their own. > > > > > > [2/4] and [4/4] is okay to merge current zsmalloc in staging but > > > [1/4] and [3/4] is dependent on zswap so it should be part of > > > zswap patchset. > > > > Just to clarify, patches 1 and 3 are _not_ dependent on zswap. They > > just introduce changes that are only needed by zswap. > > I don't think so. If zswap might be not merged, we don't need [1, 3] > at the moment. You could argue that [1, 3] make zsmalloc more flexible > and I agree. BUT I want it when we have needs. It would be not too late. > So [1,3] should be part of zswap patchset. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] kvm: IOMMU read-only mapping support
On Wed, 30 Jan 2013 12:06:32 +0800 Xiao Guangrong wrote: > So, i guess we can do the simple fix first. > > >>> By simple fix you mean calling kvm_arch_flush_shadow_all() on READONLY > >>> flag change? > >> > >> Simply disallow READONLY flag changing. > > Ok, can somebody craft a patch? > > Takuya, will you? ;) I will. Thank you for pointing out the problem. We can revisit the API later to determine what kind of changes should be allowed. Takuya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: shmobile: armadillo800eva: set clock rates before timer init
On Fri, Jan 18, 2013 at 02:02:05PM +0900, Hideki EIRAKU wrote: > Previously clock rates were set after initialization of timer. > Therefore the timer used the default extal1 clock rate (25MHz) > instead of the correct rate for this board (24MHz). > > Signed-off-by: Hideki EIRAKU Thanks, I have applied this to the boards2 branch and will merge it into the next branch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Failure due to missing (Exynos related) pinctrl patch
On 30 January 2013 09:38, Kukjin Kim wrote: > Sachin Kamat wrote: >> >> >> This patch is required along with the >> >> patch "gpio: samsung: fix pinctrl condition for exynos and exynos5440" >> >> (mainline commit Id: e4a5da51) which has already made it into >> >> mainline. Without the missing patch we get the following boot up >> >> warnings and subsequent failures with dt boot on 4412 based board: >> > >> > Hm I didn't realize there was a dependency between these >> > patches, oh well, better get the pull for the pinctrl tree finished >> > off then... >> >> Ideally those 2 patches should have been squashed together. >> > Err, Sachin, what are you talking about? As you said, one patch has been > merged into the mainline, so how does it can be squashed? In this case, just > applying the other patch into pinctrl-fixes is enough. Yes you are right. It cannot be squashed now. I was referring to the time of generation of these patches. > > Thanks. > > - Kukjin > -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Failure due to missing (Exynos related) pinctrl patch
Sachin Kamat wrote: > > >> This patch is required along with the > >> patch "gpio: samsung: fix pinctrl condition for exynos and exynos5440" > >> (mainline commit Id: e4a5da51) which has already made it into > >> mainline. Without the missing patch we get the following boot up > >> warnings and subsequent failures with dt boot on 4412 based board: > > > > Hm I didn't realize there was a dependency between these > > patches, oh well, better get the pull for the pinctrl tree finished > > off then... > > Ideally those 2 patches should have been squashed together. > Err, Sachin, what are you talking about? As you said, one patch has been merged into the mainline, so how does it can be squashed? In this case, just applying the other patch into pinctrl-fixes is enough. Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] kvm: IOMMU read-only mapping support
On 01/29/2013 03:48 PM, Gleb Natapov wrote: > On Tue, Jan 29, 2013 at 03:37:23PM +0800, Xiao Guangrong wrote: >> On 01/29/2013 02:50 PM, Gleb Natapov wrote: >>> On Tue, Jan 29, 2013 at 11:06:43AM +0800, Xiao Guangrong wrote: On 01/28/2013 06:59 PM, Gleb Natapov wrote: > On Fri, Jan 25, 2013 at 11:28:40AM +0800, Xiao Guangrong wrote: >> On 01/25/2013 09:17 AM, Takuya Yoshikawa wrote: >>> On Thu, 24 Jan 2013 15:03:57 -0700 >>> Alex Williamson wrote: >>> A couple patches to make KVM IOMMU support honor read-only mappings. This causes an un-map, re-map when the read-only flag changes and makes use of it when setting IOMMU attributes. Thanks, >>> >>> Looks good to me. >>> >>> I think I can naturally update my patch after this gets merged. >>> >> >> Please wait. >> >> The commit c972f3b1 changed the write-protect behaviour - it does >> wirte-protection only when dirty flag is set. >> [ I did not see this commit when we discussed the problem before. ] >> >> Further more, i notice that write-protect is not enough, when do sync >> shadow page: >> >> FNAME(sync_page): >> >> host_writable = sp->spt[i] & SPTE_HOST_WRITEABLE; >> >> set_spte(vcpu, >spt[i], pte_access, >> PT_PAGE_TABLE_LEVEL, gfn, >> spte_to_pfn(sp->spt[i]), true, false, >> host_writable); >> >> It sets spte based on the old value that means the readonly flag check >> is missed. We need to call kvm_arch_flush_shadow_all under this case. > Why not just disallow changing memory region KVM_MEM_READONLY flag > without deleting the region? It will introduce some restriction when VM-sharing-mem is being implemented, but we need to do some optimization for it, at least, properly write-protect readonly pages (fix sync_page()) instead of zap_all_page. >>> What is VM-sharing-mem? >> >> Sharing memory between different guests. >> > That much I can figure out for the name itself. My question is how this > sharing will work? Why KVM_MEM_READONLY is needed for it? Why ability to > change KVM_MEM_READONLY flag without destroying memory region will be > important. What's wrong with nahanni, shared memory device we have today? I'm not clear now or maybe my memory is wrong, i need to find the origin discussion... > >>> So, i guess we can do the simple fix first. >>> By simple fix you mean calling kvm_arch_flush_shadow_all() on READONLY >>> flag change? >> >> Simply disallow READONLY flag changing. > Ok, can somebody craft a patch? Takuya, will you? ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] ARM: DT: tegra114: add APB DMA controller DT entry
On 01/29/2013 08:54 PM, Laxman Dewangan wrote: > On Tuesday 29 January 2013 11:12 PM, Stephen Warren wrote: >> On 01/29/2013 05:56 AM, Laxman Dewangan wrote: >>> NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for >>> APB DMA controllers and make it compatible with >>> "nvidia,tegra114-apbdma". >> The APB DMA controller node needs a clocks property. The same goes for >> I2C and KBC. I'd like to avoid merging those 3 patches until the >> Tegra114 clock patches are present, since the nodes won't be useful >> until then anyway. I expect the clock patches will be merged in 3.10. > > I think clock patches can be posted on top of this as Peter is working. > Although, the driver will fail in clk_get() but still I think this can > be apply to populate the dts file with controller specific information. While it would be physically possible for me to apply these patches now and rely on Peter to add the clocks properties later, there's no point in doing so, since as you say the drivers won't work with just these patches. There will be less churn if we simply wait for the Tegra114 clock driver first, and then apply patches to add complete and working DT nodes for all the devices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm2] x86: Don' t panic if can not alloc buffer for swiotlb
Commit-ID: ac2cbab21f318e19bc176a7f38a120cec835220f
Gitweb: http://git.kernel.org/tip/ac2cbab21f318e19bc176a7f38a120cec835220f
Author: Yinghai Lu
AuthorDate: Thu, 24 Jan 2013 12:20:16 -0800
Committer: H. Peter Anvin
CommitDate: Tue, 29 Jan 2013 19:36:53 -0800
x86: Don't panic if can not alloc buffer for swiotlb
Normal boot path on system with iommu support:
swiotlb buffer will be allocated early at first and then try to initialize
iommu, if iommu for intel or AMD could setup properly, swiotlb buffer
will be freed.
The early allocating is with bootmem, and could panic when we try to use
kdump with buffer above 4G only, or with memmap to limit mem under 4G.
for example: memmap=4095M$1M to remove memory under 4G.
According to Eric, add _nopanic version and no_iotlb_memory to fail
map single later if swiotlb is still needed.
-v2: don't pass nopanic, and use -ENOMEM return value according to Eric.
panic early instead of using swiotlb_full to panic...according to
Eric/Konrad.
-v3: make swiotlb_init to be notpanic, but will affect:
arm64, ia64, powerpc, tile, unicore32, x86.
-v4: cleanup swiotlb_init by removing swiotlb_init_with_default_size.
Suggested-by: Eric W. Biederman
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1359058816-7615-36-git-send-email-ying...@kernel.org
Reviewed-and-tested-by: Konrad Rzeszutek Wilk
Cc: Joerg Roedel
Cc: Ralf Baechle
Cc: Jeremy Fitzhardinge
Cc: Kyungmin Park
Cc: Marek Szyprowski
Cc: Arnd Bergmann
Cc: Andrzej Pietrasiewicz
Cc: linux-m...@linux-mips.org
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: Shuah Khan
Signed-off-by: H. Peter Anvin
---
arch/mips/cavium-octeon/dma-octeon.c | 3 ++-
drivers/xen/swiotlb-xen.c| 4 ++-
include/linux/swiotlb.h | 2 +-
lib/swiotlb.c| 47 ++--
4 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/arch/mips/cavium-octeon/dma-octeon.c
b/arch/mips/cavium-octeon/dma-octeon.c
index 41dd0088..02f2444 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -317,7 +317,8 @@ void __init plat_swiotlb_setup(void)
octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
- swiotlb_init_with_tbl(octeon_swiotlb, swiotlb_nslabs, 1);
+ if (swiotlb_init_with_tbl(octeon_swiotlb, swiotlb_nslabs, 1) == -ENOMEM)
+ panic("Cannot allocate SWIOTLB buffer");
mips_dma_map_ops = _linear_dma_map_ops.dma_map_ops;
}
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index af47e75..1d94316 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -231,7 +231,9 @@ retry:
}
start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
if (early) {
- swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
verbose);
+ if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
+verbose))
+ panic("Cannot allocate SWIOTLB buffer");
rc = 0;
} else
rc = swiotlb_late_init_with_tbl(xen_io_tlb_start,
xen_io_tlb_nslabs);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 071d62c..2de42f9 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -23,7 +23,7 @@ extern int swiotlb_force;
#define IO_TLB_SHIFT 11
extern void swiotlb_init(int verbose);
-extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
verbose);
+int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
extern unsigned long swiotlb_nr_tbl(void);
extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 196b069..bfe02b8 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -122,11 +122,18 @@ static dma_addr_t swiotlb_virt_to_bus(struct device
*hwdev,
return phys_to_dma(hwdev, virt_to_phys(address));
}
+static bool no_iotlb_memory;
+
void swiotlb_print_info(void)
{
unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
unsigned char *vstart, *vend;
+ if (no_iotlb_memory) {
+ pr_warn("software IO TLB: No low mem\n");
+ return;
+ }
+
vstart = phys_to_virt(io_tlb_start);
vend = phys_to_virt(io_tlb_end);
@@ -136,7 +143,7 @@ void swiotlb_print_info(void)
bytes >> 20, vstart, vend - 1);
}
-void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
{
void *v_overflow_buffer;
unsigned long i, bytes;
@@ -150,9 +157,10 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
/*
* Get the overflow emergency buffer
*/
- v_overflow_buffer =
alloc_bootmem_low_pages(PAGE_ALIGN(io_tlb_overflow));
+
[tip:x86/mm2] mm: Add alloc_bootmem_low_pages_nopanic()
Commit-ID: 38fa4175e60d98fb1c9815fb14f8057576dade73
Gitweb: http://git.kernel.org/tip/38fa4175e60d98fb1c9815fb14f8057576dade73
Author: Yinghai Lu
AuthorDate: Thu, 24 Jan 2013 12:20:15 -0800
Committer: H. Peter Anvin
CommitDate: Tue, 29 Jan 2013 19:32:59 -0800
mm: Add alloc_bootmem_low_pages_nopanic()
We don't need to panic in some case, like for swiotlb preallocating.
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1359058816-7615-35-git-send-email-ying...@kernel.org
Signed-off-by: H. Peter Anvin
---
include/linux/bootmem.h | 5 +
mm/bootmem.c| 8
mm/nobootmem.c | 8
3 files changed, 21 insertions(+)
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 3f778c2..3cd16ba 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -99,6 +99,9 @@ void *___alloc_bootmem_node_nopanic(pg_data_t *pgdat,
extern void *__alloc_bootmem_low(unsigned long size,
unsigned long align,
unsigned long goal);
+void *__alloc_bootmem_low_nopanic(unsigned long size,
+unsigned long align,
+unsigned long goal);
extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
unsigned long size,
unsigned long align,
@@ -132,6 +135,8 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
#define alloc_bootmem_low(x) \
__alloc_bootmem_low(x, SMP_CACHE_BYTES, 0)
+#define alloc_bootmem_low_pages_nopanic(x) \
+ __alloc_bootmem_low_nopanic(x, PAGE_SIZE, 0)
#define alloc_bootmem_low_pages(x) \
__alloc_bootmem_low(x, PAGE_SIZE, 0)
#define alloc_bootmem_low_pages_node(pgdat, x) \
diff --git a/mm/bootmem.c b/mm/bootmem.c
index b93376c..2b0bcb0 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -833,6 +833,14 @@ void * __init __alloc_bootmem_low(unsigned long size,
unsigned long align,
return ___alloc_bootmem(size, align, goal, ARCH_LOW_ADDRESS_LIMIT);
}
+void * __init __alloc_bootmem_low_nopanic(unsigned long size,
+ unsigned long align,
+ unsigned long goal)
+{
+ return ___alloc_bootmem_nopanic(size, align, goal,
+ ARCH_LOW_ADDRESS_LIMIT);
+}
+
/**
* __alloc_bootmem_low_node - allocate low boot memory from a specific node
* @pgdat: node to allocate from
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index 03d152a..5e07d36 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -391,6 +391,14 @@ void * __init __alloc_bootmem_low(unsigned long size,
unsigned long align,
return ___alloc_bootmem(size, align, goal, ARCH_LOW_ADDRESS_LIMIT);
}
+void * __init __alloc_bootmem_low_nopanic(unsigned long size,
+ unsigned long align,
+ unsigned long goal)
+{
+ return ___alloc_bootmem_nopanic(size, align, goal,
+ ARCH_LOW_ADDRESS_LIMIT);
+}
+
/**
* __alloc_bootmem_low_node - allocate low boot memory from a specific node
* @pgdat: node to allocate from
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] ARM: DT: tegra114: add APB DMA controller DT entry
On Tuesday 29 January 2013 11:12 PM, Stephen Warren wrote: On 01/29/2013 05:56 AM, Laxman Dewangan wrote: NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for APB DMA controllers and make it compatible with "nvidia,tegra114-apbdma". The APB DMA controller node needs a clocks property. The same goes for I2C and KBC. I'd like to avoid merging those 3 patches until the Tegra114 clock patches are present, since the nodes won't be useful until then anyway. I expect the clock patches will be merged in 3.10. I think clock patches can be posted on top of this as Peter is working. Although, the driver will fail in clk_get() but still I think this can be apply to populate the dts file with controller specific information. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm2] x86, 64bit, mm: hibernate use generic mapping_init
Commit-ID: 8b78c21d72d9dbcb7230e97423a2cd8d8402c20c
Gitweb: http://git.kernel.org/tip/8b78c21d72d9dbcb7230e97423a2cd8d8402c20c
Author: Yinghai Lu
AuthorDate: Thu, 24 Jan 2013 12:20:14 -0800
Committer: H. Peter Anvin
CommitDate: Tue, 29 Jan 2013 19:32:59 -0800
x86, 64bit, mm: hibernate use generic mapping_init
We should set mappings only for usable memory ranges under max_pfn
Otherwise causes same problem that is fixed by
x86, mm: Only direct map addresses that are marked as E820_RAM
Make it only map range in pfn_mapped array.
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/1359058816-7615-34-git-send-email-ying...@kernel.org
Cc: Pavel Machek
Cc: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
Signed-off-by: H. Peter Anvin
---
arch/x86/power/hibernate_64.c | 66 +++
1 file changed, 22 insertions(+), 44 deletions(-)
diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index 460f314..a0fde91 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -11,6 +11,8 @@
#include
#include
#include
+
+#include
#include
#include
#include
@@ -39,41 +41,21 @@ pgd_t *temp_level4_pgt;
void *relocated_restore_code;
-static int res_phys_pud_init(pud_t *pud, unsigned long address, unsigned long
end)
+static void *alloc_pgt_page(void *context)
{
- long i, j;
-
- i = pud_index(address);
- pud = pud + i;
- for (; i < PTRS_PER_PUD; pud++, i++) {
- unsigned long paddr;
- pmd_t *pmd;
-
- paddr = address + i*PUD_SIZE;
- if (paddr >= end)
- break;
-
- pmd = (pmd_t *)get_safe_page(GFP_ATOMIC);
- if (!pmd)
- return -ENOMEM;
- set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
- for (j = 0; j < PTRS_PER_PMD; pmd++, j++, paddr += PMD_SIZE) {
- unsigned long pe;
-
- if (paddr >= end)
- break;
- pe = __PAGE_KERNEL_LARGE_EXEC | paddr;
- pe &= __supported_pte_mask;
- set_pmd(pmd, __pmd(pe));
- }
- }
- return 0;
+ return (void *)get_safe_page(GFP_ATOMIC);
}
static int set_up_temporary_mappings(void)
{
- unsigned long start, end, next;
- int error;
+ struct x86_mapping_info info = {
+ .alloc_pgt_page = alloc_pgt_page,
+ .pmd_flag = __PAGE_KERNEL_LARGE_EXEC,
+ .kernel_mapping = true,
+ };
+ unsigned long mstart, mend;
+ int result;
+ int i;
temp_level4_pgt = (pgd_t *)get_safe_page(GFP_ATOMIC);
if (!temp_level4_pgt)
@@ -84,21 +66,17 @@ static int set_up_temporary_mappings(void)
init_level4_pgt[pgd_index(__START_KERNEL_map)]);
/* Set up the direct mapping from scratch */
- start = (unsigned long)pfn_to_kaddr(0);
- end = (unsigned long)pfn_to_kaddr(max_pfn);
-
- for (; start < end; start = next) {
- pud_t *pud = (pud_t *)get_safe_page(GFP_ATOMIC);
- if (!pud)
- return -ENOMEM;
- next = start + PGDIR_SIZE;
- if (next > end)
- next = end;
- if ((error = res_phys_pud_init(pud, __pa(start), __pa(next
- return error;
- set_pgd(temp_level4_pgt + pgd_index(start),
- mk_kernel_pgd(__pa(pud)));
+ for (i = 0; i < nr_pfn_mapped; i++) {
+ mstart = pfn_mapped[i].start << PAGE_SHIFT;
+ mend = pfn_mapped[i].end << PAGE_SHIFT;
+
+ result = kernel_ident_mapping_init(, temp_level4_pgt,
+ mstart, mend);
+
+ if (result)
+ return result;
}
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
