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
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
---
MDaemon has detected restricted attachments within an email message
---
>From : linux-kernel@vger.kernel.org
To: dinh_ch...@orangefashionvt.com
Subject
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
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? */
>
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
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
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
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
於 三，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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 +
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,
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
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
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
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
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
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
---
- 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,
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ++--
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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 +-
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
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
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
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
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
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;
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
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
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.
>
>
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
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
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
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
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
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
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
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
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:
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.
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
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:
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:
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
(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
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
>>
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
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
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?
> >
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?
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
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
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
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,
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
>>>
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
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
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
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
1 - 100 of 1454 matches
Mail list logo
