On Fri, Oct 19, 2012 at 10:26:20AM +, Bedia, Vaibhav wrote:
> Hi Matt,
>
> On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote:
> > 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
On Fri 19-10-12 17:33:18, Li Zefan wrote:
> On 2012/10/17 21:30, Michal Hocko wrote:
> > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > safely move on and forbit all the callbacks to fail. The last missing
> > piece is moving cgroup_call_pre_destroy after
Move the check for populated_zone() to the control statement of the
'for' loop and get rid of the odd looking if/else block.
Signed-off-by: Srivatsa S. Bhat
---
include/linux/mmzone.h |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/linux/mmzone.h
+ linux-omap and Daniel
On Fri, Oct 19, 2012 at 16:20:21, Mohammed, Afzal wrote:
> add am33xx rtc node.
>
> Signed-off-by: Afzal Mohammed
> ---
>
> Based on v3.7-rc1,
> Dependent on series "rtc: omap dt support (for am33xx)",
> (https://lkml.org/lkml/2012/10/19/163)
> Tested on Beagle Bone.
>
The Tegra driver tries to do the work of irq_domain_add_linear()
by reserving a bunch of descriptors somewhere and keeping track
of the base offset, then calling irq_domain_add_legacy(). Let's
stop doing that and simply use the linear IRQ domain.
For this to work: use irq_create_mapping() in the
The MVEBU driver probably just wants a few IRQs. Using the simple
domain has the upside of allocating IRQ descriptors if need be,
especially in a SPARSE_IRQ environment.
Cc: Rob Herring
Cc: Grant Likely
Cc: Thomas Petazzoni
Cc: Sebastian Hesselbarth
Cc: Andrew Lunn
Signed-off-by: Linus
The code in the em driver seems to want to try to do the job of
the linear IRQ domain (allocate descriptors and grab a virtual
range). So why not just use the linear IRQ domain? The code is
now cut down so we don't need isolated functions for this.
Also note that we use irq_create_mapping() to
The special checks for whether we have a base IRQ offset or not
is surplus if we use the simple IRQ domain. The IRQ offset
zero will be interpreted as a linear domain case.
Plus this makes sure we allocate descriptors where need be, or
warn if they are preallocated with SPARSE_IRQ.
Cc: Grant
add am33xx rtc node.
Signed-off-by: Afzal Mohammed
---
Based on v3.7-rc1,
Dependent on series "rtc: omap dt support (for am33xx)",
(https://lkml.org/lkml/2012/10/19/163)
Tested on Beagle Bone.
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
On Fri, 2012-10-19 at 13:38 +0400, Stanislav Kinsbursky wrote:
> 19.10.2012 11:56, Eric Dumazet пишет:
> > I wonder if some applications relied on our idr, assuming they would get
> > low values for their timer id.
> > (We could imagine some applications use a table indexed by the timer id)
>
>
Add a binding document describing the PWM controller found
on arch-vt8500 supported SoCs.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
In order to support USB PHY drivers on these SoCs, existing
PHY driver is split into SoC agnostic common USB PHY driver
and Tegra20-specific USB phy driver. This will facilitate
easy addition and deletion of phy drivers for Tegra SoCs.
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
Signed-off-by: Tony Prisk
---
drivers/pwm/pwm-vt8500.c | 79 ++
1 file changed, 51 insertions(+), 28 deletions(-)
diff --git
At 10/06/2012 03:27 AM, KOSAKI Motohiro Wrote:
> On Thu, Oct 4, 2012 at 10:25 PM, Yasuaki Ishimatsu
> wrote:
>> When calling remove_memory(), the memory should be offline. If the function
>> is used to online memory, kernel panic may occur.
>>
>> So the patch checks whether memory is offline or
This patch adds pwm support to arch-vt8500 board files, and adds
the use-case of pwm-backlight.
Signed-off-by: Tony Prisk
---
arch/arm/boot/dts/vt8500-bv07.dts |8
arch/arm/boot/dts/vt8500.dtsi | 29 +
arch/arm/boot/dts/wm8505-ref.dts |8
On 09/28/2012 07:03 PM, Glauber Costa wrote:
> Hi,
>
> This patch moves on with the slab caches commonization, by moving
> the slabinfo processing to common code in slab_common.c. It only touches
> slub and slab, since slob doesn't create that file, which is protected
> by a Kconfig switch.
>
>
Hi,
On Fri, Oct 19, 2012 at 04:03:26PM +0530, Venu Byravarasu wrote:
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
> PHY driver is split into SoC agnostic common USB PHY driver
> and Tegra20-specific USB phy driver.
On Thu, Oct 18, 2012 at 12:07 PM, Roland Stigge wrote:
> On 10/17/2012 09:05 PM, Greg KH wrote:
>>>
>>> +if (value != exported) {
>>> +if (value)
>>> +status = gpio_block_value_export(block);
>>> +else
>>> +status =
At 10/19/2012 06:19 PM, Yasuaki Ishimatsu Wrote:
> CCing Rafael, because he become ACPI Maintainer.
>
> Hi Wen,
>
> If you update the patch-set, please CCing Rafael from the next time.
OK.
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
> 2012/10/19 19:03, we...@cn.fujitsu.com wrote:
NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
In order to support USB PHY drivers on these SoCs, existing
PHY driver is split into SoC agnostic common USB PHY driver
and Tegra20-specific USB phy driver. This will facilitate
easy addition and deletion of phy drivers for Tegra SoCs.
On Thu, Oct 18, 2012 at 6:38 AM, Daniel Glöckner wrote:
> On Mon, Oct 15, 2012 at 10:30:15PM +0200, Linus Walleij wrote:
>>
>> Another patch that is circulating concerns edge triggers and similar,
>> and it appear that some parts of the GPIO sysfs is for example
>> redefining and exporting
(trimmed over long cc list from original 00/21 post)
On Fri, 2012-10-19 at 09:04 +0200, Eric Dumazet wrote:
> On Thu, 2012-10-18 at 20:55 -0700, Joe Perches wrote:
> > ethernet, ipv4, and ipv6 address testing uses 3 different api naming styles.
> >
> > ethernet uses: is__ether_addr
> > ipv4
Hi Matt,
On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote:
> 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
>
On Thu, Oct 18, 2012 at 8:22 AM, Shawn Guo wrote:
>> /* gpio-mxs can be a generic irq chip */
>> mxs_gpio_init_gc(port, irq_base);
>
>
> So I know this one is not compile-tested.
No, which defconfig shall I use for this driver?
> This is
CCing Rafael, because he become ACPI Maintainer.
Hi Wen,
If you update the patch-set, please CCing Rafael from the next time.
Thanks,
Yasuaki Ishimatsu
2012/10/19 19:03, we...@cn.fujitsu.com wrote:
> From: Wen Congyang
>
> The patch-set implements a framework for hot removing memory.
>
>
On Wed, Oct 17, 2012 at 8:32 PM, Stephen Warren wrote:
> On 10/16/2012 04:33 PM, Stephen Warren wrote:
>> On 10/16/2012 01:23 PM, Linus Walleij wrote:
>>> The MXS driver tries to do the work of irq_domain_add_linear()
>>> by reserving a bunch of descriptors somewhere and keeping track
>>> of the
Add support for PWM chips present on SPEAr platforms. These PWM
chips support 4 channel output with programmable duty cycle and
frequency.
More details on these PWM chips can be obtained from relevant
chapter of reference manual, present at following[1] location.
1.
From: Wen Congyang
Current mem boot option only can work for non efi environment. If the user
specifies add_efi_memmap, it cannot work for efi environment. In
the efi environment, we call e820_add_region() to add the memory map. So
we can modify __e820_add_region() and the mem boot option can
From: Wen Congyang
Current mem= implementation seems buggy because specification and
implementation doesn't match. Current mem= has been working
for many years and it's not buggy, it works as expected. So
we should update the specification.
Signed-off-by: Wen Congyang
From: Wen Congyang
The documentation and implementation of 'mem=' option doesn't match, and the
option can't work for efi platform. This patchset updates the documentation
and make the option to work for efi platform.
I resend it again because HPA asked me to resend it some days after merge
On Wed, Oct 17, 2012 at 9:26 AM, Mika Westerberg
wrote:
> On Tue, Oct 16, 2012 at 09:23:23PM +0200, Linus Walleij wrote:
>> Switch from creating the IRQ domain mapping to finding it. In this
>> case we know very well that the driver has created the apropriate
>> mapping, we just need to locate
At 10/19/2012 05:39 PM, Yasuaki Ishimatsu Wrote:
> 2012/10/19 17:45, Wen Congyang wrote:
>> At 10/19/2012 04:19 PM, Yasuaki Ishimatsu Wrote:
>>> 2012/10/19 17:06, Yasuaki Ishimatsu wrote:
Hi Wen,
Some bug fix patches have been merged into linux-next.
So the patches confuse me.
On Wed, Oct 17, 2012 at 3:52 AM, Jingoo Han wrote:
> This patch uses pr_* instead of printk. Also, gpio_dbg
> is replaced with pr_debug.
>
> Signed-off-by: Jingoo Han
> Reviewed-by: Linus Walleij <- NAK
Please consult Documentation/SubmittingPatches as to the conditions that
apply when you
On 10/19/2012 01:59 AM, David Rientjes wrote:
> On Thu, 18 Oct 2012, Glauber Costa wrote:
>
@@ -2630,6 +2634,171 @@ static void __mem_cgroup_commit_charge(struct
mem_cgroup *memcg,
memcg_check_events(memcg, page);
}
+#ifdef CONFIG_MEMCG_KMEM
+static
On 19 October 2012 15:31, Shiraz Hashim wrote:
> On Fri, Oct 19, 2012 at 11:29:43AM +0530, Shiraz HASHIM wrote:
>> On Thu, Oct 18, 2012 at 11:11:06PM +0530, viresh kumar wrote:
>> > On Thu, Oct 18, 2012 at 4:58 PM, Shiraz Hashim
>> > wrote:
>> > > + pc->mmio_base =
On Wed, Oct 17, 2012 at 1:41 AM, Ryan Mallon wrote:
> The gpio_export function uses nested if statements and the status
> variable to handle the failure cases. This makes the function logic
> difficult to follow. Refactor the code to abort immediately on failure
> using goto. This makes the code
On Fri, Oct 19, 2012 at 13:54:15, Cousson, Benoit wrote:
> Hi Avinash,
>
> This look good to me except the: status = "disabled".
status = "disabled" in soc .dtsi file to make sure that IP driver
won't loaded unless if IP used.
So from board .dts file status = "okay" should be set if IP being
On Fri, Oct 19, 2012 at 11:29:43AM +0530, Shiraz HASHIM wrote:
> On Thu, Oct 18, 2012 at 11:11:06PM +0530, viresh kumar wrote:
> > On Thu, Oct 18, 2012 at 4:58 PM, Shiraz Hashim wrote:
> > > + pc->mmio_base = devm_request_and_ioremap(>dev, r);
> > > + if (!pc->mmio_base)
> > > +
rtc-omap driver is now capable of handling kicker mechanism,
hence remove kicker handling at platform level, instead
provide proper device name so that driver can handle kicker
mechanism by itself
Signed-off-by: Afzal Mohammed
Acked-by: Sekhar Nori
---
v2:
Use device name da830-rtc instead of
Hi Andrew,
This series enhances rtc-omap driver so as to be usable on
am33xx SoC by adding DT support (Beagle Bone uses am33xx).
This is a revised version of series that was posted on
27th July 2012 with the subject,
"omap-am33xx rtc dt support".
It seems rtc maintainer in inactive and hence
From: Vaibhav Hiremath
OMAP1 RTC driver is used in multiple devices like,
OMAPL138 and AM33XX. Driver currently doesn't handle any clocks,
which may be right for OMAP1 architecture but in case of AM33XX,
the clock/module needs to be enabled in order to access the registers.
So covert this
On 10/19/2012 01:31 PM, David Rientjes wrote:
> On Fri, 19 Oct 2012, Glauber Costa wrote:
>
> Do we actually need to test PF_KTHREAD when current->mm == NULL?
> Perhaps because of aio threads whcih temporarily adopt a userspace mm?
I believe so. I remember I discussed this in
enhance rtc-omap driver with DT capability
Signed-off-by: Afzal Mohammed
Acked-by: Sekhar Nori
---
v4:
Proper devicetree documentation
v2:
Use compatible as ti,da830-rtc instead of ti,am1808-rtc
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 17 +
rtc-omap driver can be reused for AM33xx RTC.
Provide dependency in Kconfig.
Signed-off-by: Afzal Mohammed
Acked-by: Sekhar Nori
---
v2:
Modify Kconfig help, resolve checkpatch warning
drivers/rtc/Kconfig | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
OMAP RTC IP can have kicker feature. This prevents spurious
writes to register. To write to registers kicker lock has to
be released. Procedure to do it as follows,
1. write to kick0 register, 0x83e70b13
2. write to kick1 register, 0x95a4f1e0
Writing value other than 0x83e70b13 to kick0 enables
From: Wen Congyang
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
This 2 events may happen at the same time, so we may touch
acpi_memory_device.res_list at the same time. This patch
introduce a lock to protect this list.
From: Wen Congyang
The memory device has been ejected and powoffed, so we can call
acpi_bus_trim() to remove the memory device from acpi bus.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew
From: Yasuaki Ishimatsu
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case, acpi_memory_device_remove() will be called.
From: Wen Congyang
The patch-set implements a framework for hot removing memory.
The memory device can be removed by 2 ways:
1. send eject request by SCI
2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
In the 1st case, acpi_memory_disable_device() will be called.
In the 2nd case,
On 10/18/2012 11:21 PM, Andrew Morton wrote:
> On Thu, 18 Oct 2012 20:51:05 +0400
> Glauber Costa wrote:
>
>> On 10/18/2012 02:11 AM, Andrew Morton wrote:
>>> On Tue, 16 Oct 2012 14:16:37 +0400
>>> Glauber Costa wrote:
>>>
...
A general explanation of what this is all about
On Fri 19-10-12 12:11:52, Sha Zhengju wrote:
> On 10/18/2012 11:32 PM, Michal Hocko wrote:
> >On Thu 18-10-12 21:51:57, Sha Zhengju wrote:
> >>On 10/18/2012 07:56 PM, Michal Hocko wrote:
> >>>On Wed 17-10-12 01:14:48, Sha Zhengju wrote:
> On Tuesday, October 16, 2012, Michal Hocko wrote:
>
On Fri, 19 Oct 2012 10:45:07 +0200
Florian Fainelli wrote:
> From: Maxime Bizon
>
> The current CE4100 and 8250_pci code have both a limitation preventing the
> registration and usage of CE4100's second UART. This patch changes the
> platform code fixing up the UART port to work on a relative
On Fri, Oct 19, 2012 at 01:28:35AM +0400, Cyrill Gorcunov wrote:
> >
> > A common way in which we do this future-proofing is to display the info
> > in name:value tuples (eg, /proc/meminfo). So userspace parses for the
> > "name" rather than looking into a fixed position in the /proc output.
> >
On 19 October 2012 15:13, Shiraz Hashim wrote:
> It may not be required as pwms which are not enabled do not have
> their clocks enabled. Hence, perhaps we can do following,
>
> 8<---
> static int spear_pwm_remove(struct platform_device *pdev)
> {
> struct
On 10/19/2012 01:41 AM, Marcos Paulo de Souza wrote:
> With this we can remove a lot of checks.
>
> Signed-off-by: Marcos Paulo de Souza
This one is a bit more tricky and the driver currently gets it (partially
wrong). The issue is that since the power supply is referenced in the
interrupt
Hi Viresh,
On Fri, Oct 19, 2012 at 12:23:08PM +0530, viresh kumar wrote:
> On Fri, Oct 19, 2012 at 11:29 AM, Shiraz Hashim wrote:
> > On Thu, Oct 18, 2012 at 11:11:06PM +0530, viresh kumar wrote:
> >> On Thu, Oct 18, 2012 at 4:58 PM, Shiraz Hashim
> >> wrote:
>
> >> > +static int __devexit
2012/10/19 17:45, Wen Congyang wrote:
> At 10/19/2012 04:19 PM, Yasuaki Ishimatsu Wrote:
>> 2012/10/19 17:06, Yasuaki Ishimatsu wrote:
>>> Hi Wen,
>>>
>>> Some bug fix patches have been merged into linux-next.
>>> So the patches confuse me.
>
> Sorry, I don't check linux-next tree.
>
>>
>> The
19.10.2012 11:56, Eric Dumazet пишет:
I wonder if some applications relied on our idr, assuming they would get
low values for their timer id.
(We could imagine some applications use a table indexed by the timer id)
Hmm.
Probably, this particular case can be optimised by tuning min_id to id of
On 2012/10/17 21:30, Michal Hocko wrote:
> Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> safely move on and forbit all the callbacks to fail. The last missing
> piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
> that css_tryget fails so no new charges
On Fri, 19 Oct 2012, Glauber Costa wrote:
> >>> Do we actually need to test PF_KTHREAD when current->mm == NULL?
> >>> Perhaps because of aio threads whcih temporarily adopt a userspace mm?
> >>
> >> I believe so. I remember I discussed this in the past with David
> >> Rientjes and he advised me
On Friday 19 October 2012 17:20:36 Tony Prisk wrote:
> On Fri, 2012-10-19 at 18:06 +0900, Alexandre Courbot wrote:
> > +static void pwm_backlight_on(struct backlight_device *bl)
> > +{
> > + struct pwm_bl_data *pb = dev_get_drvdata(>dev);
> > + int ret;
> > +
> > + if (pb->enabled)
> >
On Fri, 19 Oct 2012, Kamezawa Hiroyuki wrote:
> From c5849c9034abeec3f26bf30dadccd393b0c5c25e Mon Sep 17 00:00:00 2001
> From: KAMEZAWA Hiroyuki
> Date: Fri, 19 Oct 2012 17:00:55 +0900
> Subject: [PATCH] hold task->mempolicy while numa_maps scans.
>
> /proc//numa_maps scans vma and show
On Fri, Oct 19, 2012 at 09:25:48AM +0100, James Hogan wrote:
> On 17/10/12 16:45, Will Deacon wrote:
> > The {read,write}s{b,w,l} operations are not defined by all architectures
> > and are being removed from the asm-generic/io.h interface.
> >
> > This patch replaces the usage of these string
On 10/19/2012 01:41 AM, Marcos Paulo de Souza wrote:
> This don't change the rationale, just a cleanup.
>
> Signed-off-by: Marcos Paulo de Souza
Patch is ok in general, but it would be even better if you'd use
devm_request_and_ioremap. It does both the devm_request_mem_region and
On Fri, 2012-10-19 at 18:06 +0900, Alexandre Courbot wrote:
> Make use of the power sequences specified in the device tree or platform
> data to control how the backlight is powered on and off.
>
> Signed-off-by: Alexandre Courbot
> ---
> .../bindings/video/backlight/pwm-backlight.txt | 72
On Thu, 18 Oct 2012 17:39:11 +0400 Vyacheslav Dubeyko
wrote:
> [snip]
> > >
> > > And Would you share ppt or document of f2fs if Korea Linux Forum is
> > > finished ?
> > >
> >
> > Here I attached the slides, and LF will also share the slides.
> > Thanks,
> >
>
> I had hope that slides
On 10/19/2012 01:41 AM, Marcos Paulo de Souza wrote:
> This does not chnange the rationale, just a cleanup
>
> Signed-off-by: Marcos Paulo de Souza
Thanks,
Acked-by: Lars-Peter Clausen ---
> drivers/power/jz4740-battery.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
On Fri, Oct 19, 2012 at 07:19:27AM +0100, Alexander Holler wrote:
> Hello,
>
> Am 18.10.2012 14:16, schrieb Thomas Meyer:
>
> > ERROR: "read_current_timer" [drivers/gpu/drm/udl/udl.ko] undefined!
> > ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
>
> There is already a long thread
On Friday 19 October 2012 04:13 AM, Stephen Warren wrote:
The patch subject isn't entirely accurate here; this patch isn't just
about fixing clock entries.
OK, then will break in two patches.
+ OF_DEV_AUXDATA("nvidia,tegra20-slink", TEGRA_SLINK1_BASE,
"spi-tegra-slink.0", NULL),
Andi Kleen writes:
> [Updated version for the latest master tree and various fixes.
> See end for details. This should be ready for merging now I hope.]
This is also now available at
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git hsw/pmu3
-Andi
--
a...@linux.intel.com --
On Friday 19 October 2012 04:11 AM, Stephen Warren wrote:
On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
Add slink controller details in the dts file of
Tegra20 and Tegra30.
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
+ slink@7000d400 {
+
On 10/19/2012 02:06 AM, David Rientjes wrote:
> On Thu, 18 Oct 2012, Glauber Costa wrote:
>
>>> Do we actually need to test PF_KTHREAD when current->mm == NULL?
>>> Perhaps because of aio threads whcih temporarily adopt a userspace mm?
>>
>> I believe so. I remember I discussed this in the past
On Thu, Oct 18, 2012 at 11:05:02PM +0100, Andrew Morton wrote:
> On Wed, 17 Oct 2012 16:54:02 +0100
> Will Deacon wrote:
>
> > On x86 memory accesses to pages without the ACCESSED flag set result in the
> > ACCESSED flag being set automatically. With the ARM architecture a page
> > access
> >
> > In one use case, the administrator then needs the ability to configure
> > devices easily, for example to be much more restrictive on non-MMC
> > devices. It must be done with the same tools it uses for other
> > aspects of the policy---which will be a combination of DAC (Unix
> > permissions
On Friday 19 October 2012 04:09 AM, Stephen Warren wrote:
On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
Add base address of all slink controller of Tegra20
and tegra30.
Lets not add anything to iomap.h; we're trying to remove it. Instead,
just put the raw address in the AUXDATA; I assume
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra20-ventana.dts | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm/boot/dts/tegra20-ventana.dts
index bec8bb2..877a1bb 100644
---
Make use of the power sequences specified in the device tree or platform
data to control how the backlight is powered on and off.
Signed-off-by: Alexandre Courbot
---
.../bindings/video/backlight/pwm-backlight.txt | 72 -
drivers/video/backlight/Kconfig| 1 +
Some device drivers (e.g. panel backlights ) need to follow precise
sequences for powering on and off, involving GPIOs, regulators, PWMs
with a precise powering order and delays to respect between each steps.
These sequences are device-specific, and do not belong to a particular
driver - therefore
Quite a big redesign of the feature - both structures and code have been
simplified and should be easier to read and understand, data duplication is
avoided, and much less memory allocations take place at runtime. Usage
interface is also simpler and IMHO more logical.
What happened is that
At 10/19/2012 03:44 AM, KOSAKI Motohiro Wrote:
>> + if (type == ACPI_BUS_REMOVAL_EJECT) {
>> + /*
>> +* offline and remove memory only when the memory device
>> is
>> +* ejected.
>> +*/
>
> This
The patch is based on a patch submitted by Hans Rosenfeld.
See http://marc.info/?l=linux-kernel=133908777200931
Note that CPUID Fn8000_001D_EAX slightly differs to Intel's CPUID function 4.
Bits 14-25 contain NumSharingCache. Actual number of cores sharing
this cache. SW to add
Rely on CPUID 0x801d for cache information when AMD CPUID topology
extensions are available.
Signed-off-by: Andreas Herrmann
---
arch/x86/kernel/cpu/intel_cacheinfo.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c
CPUID 0x801d works quite similar to Intels' CPUID function 4.
Use it to determine number of cache leafs.
Signed-off-by: Andreas Herrmann
---
arch/x86/include/asm/processor.h |2 +-
arch/x86/kernel/cpu/amd.c |7 +--
arch/x86/kernel/cpu/intel_cacheinfo.c | 28
On Thu, 2012-10-18 at 20:59 +0200, Yann E. MORIN wrote:
> On Thursday 18 October 2012 Yaakov (Cygwin/X) wrote:
> > Tested-by: Yaakov Selkowitz
>
> Out of curiosity: did you test on Cygwin?
Yes, of course.
Yaakov
Cygwin Ports
--
To unsubscribe from this list: send the line "unsubscribe
Introduce cpu_has_topoext to check for AMD's CPUID topology extensions
support. It indicates support for
CPUID Fn8000_001D_EAX_x[N:0]-CPUID Fn8000_001E_EDX
See AMD's CPUID Specification, Publication # 25481
(as of Rev. 2.34 September 2010)
Signed-off-by: Andreas Herrmann
---
Hi,
Following patches modify cachinfo code to make use of AMD's topology
extension CPUID functions. Thus (hopefully) we can avoid CPU specific
modifications whenever cache topology changes.
Please apply.
Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe
From: Maxime Bizon
The current CE4100 and 8250_pci code have both a limitation preventing the
registration and usage of CE4100's second UART. This patch changes the
platform code fixing up the UART port to work on a relative UART port
base address, as well as the 8250_pci code to make it
On 2012/10/19 8:58, Tejun Heo wrote:
> Hello, again.
>
> On Thu, Oct 18, 2012 at 05:38:35PM -0700, Tejun Heo wrote:
>> Even if there isn't an actual race, the comment is dead wrong. I'm
>> reverting the following three patches. Let's try again later.
>>
>> 7e381b0eb1 ("cgroup: Drop
On 10/18/2012 12:28 AM, Yinghai Lu wrote:
On Wed, Oct 17, 2012 at 12:39 AM, Tang Chen wrote:
On 10/17/2012 01:18 PM, Yinghai Lu wrote:
And also, I have another 2 questions, maybe you can help me.
1) Do we need to put PNP0A08 into acpi_pci_roots ?
looks like we need to unify those two ids.
On Fri, Oct 19, 2012 at 10:27:35AM +0200, Stephane Eranian wrote:
> Jiri,
>
> When I run perf list, I see:
>
> $ perf list
> ..
> rNNN [Raw hardware
> event descriptor]
> cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware
> event
From: Al Viro
Signed-off-by: Al Viro
Acked-and-Tested-by: Guan Xuetao
---
arch/unicore32/Kconfig |2 +
arch/unicore32/include/asm/processor.h |5 ---
arch/unicore32/kernel/entry.S | 15
arch/unicore32/kernel/process.c| 58
> Generally this looks good. Obviously you'll need to update any users of
> this driver as well. It might make sense to include those changes in
> this patch to avoid interim build failures.
Thanks for your review.
So far no usages for this driver in the mainline.
I've tested it in my own
From: Al Viro
Signed-off-by: Al Viro
Acked-and-Tested-by: Guan Xuetao
---
arch/unicore32/include/uapi/asm/unistd.h |1 +
arch/unicore32/kernel/entry.S|5 -
arch/unicore32/kernel/sys.c | 21 -
3 files changed, 1 insertions(+), 26
At 10/19/2012 04:19 PM, Yasuaki Ishimatsu Wrote:
> 2012/10/19 17:06, Yasuaki Ishimatsu wrote:
>> Hi Wen,
>>
>> Some bug fix patches have been merged into linux-next.
>> So the patches confuse me.
Sorry, I don't check linux-next tree.
>
> The following patches have been already merged into
At 10/19/2012 03:41 PM, KOSAKI Motohiro Wrote:
> On Fri, Oct 19, 2012 at 2:46 AM, wrote:
>> From: Wen Congyang
>>
>> NR_FREE_PAGES will be wrong after offlining pages. We add/dec NR_FREE_PAGES
>> like this now:
>> 1. mova all pages in buddy system to MIGRATE_ISOLATE, and dec NR_FREE_PAGES
>
>
(2012/10/19 5:03), David Rientjes wrote:
On Thu, 18 Oct 2012, Kamezawa Hiroyuki wrote:
@@ -132,7 +162,7 @@ static void *m_start(struct seq_file *m, loff_t *pos)
tail_vma = get_gate_vma(priv->task->mm);
priv->tail_vma = tail_vma;
-
+ hold_task_mempolicy(priv);
/*
There's a regression from commit 800d4d30, in autogroup_move_group()
p->signal->autogroup = autogroup_kref_get(ag);
if (!ACCESS_ONCE(sysctl_sched_autogroup_enabled))
goto out;
...
out:
autogroup_kref_put(prev);
So kernel changed p's autogroup
On Wed, Oct 17, 2012 at 10:54:27PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> arch_write_trylock() should return 'ret' instead of always
> return 1.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
I've taken this into the CRIS-tree, thanks!
>
On 10/15/2012 08:04 PM, Andrew Theurer wrote:
On Mon, 2012-10-15 at 17:40 +0530, Raghavendra K T wrote:
On 10/11/2012 01:06 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 23:24 +0530, Raghavendra K T wrote:
On 10/10/2012 08:29 AM, Andrew Theurer wrote:
On Wed, 2012-10-10 at 00:21 +0530,
On Tue, Oct 16, 2012 at 4:42 AM, Dave Chinner wrote:
> On Wed, Oct 10, 2012 at 06:07:22PM +0800, zwu.ker...@gmail.com wrote:
>> From: Zhi Yong Wu
>>
>> NOTE:
>>
>> The patchset is currently post out mainly to make sure
>> it is going in the correct direction and hope to get some
>> helpful
401 - 500 of 1116 matches
Mail list logo
