From: Pratik Patel
This driver manages CoreSight TMC (Trace Memory Controller) which
can act as a link or a sink depending upon its configuration. It
can present itself as an ETF (Embedded Trace FIFO) or ETR
(Embedded Trace Router).
ETF when configured in circular buffer mode acts as a trace
From: Pratik Patel
This driver manages CoreSight Funnel which acts as a link.
Funnels have multiple input ports (typically 8) each of which
represents an input trace data stream. These multiple input trace
data streams are interleaved into a single output stream coming
out of the Funnel.
From: Pratik Patel
This driver manages CoreSight TPIU (Trace Port Interface Unit)
which acts as a sink. TPIU is typically connected to some offchip
hardware hosting a storage buffer.
Signed-off-by: Pratik Patel
Signed-off-by: Panchaxari Prasannamurthy
Signed-off-by: Mathieu Poirier
---
From: Pratik Patel
CoreSight components are compliant with the ARM CoreSight
architecture specification and can be connected in various
topologies to suite a particular SoCs tracing needs. These trace
components can generally be classified as sources, links and
sinks. Trace data produced by one
From: Mathieu Poirier
Support for the 2 PTMs, 3 ETMs, funnel, TPIU and replicator
connected to the ETB are included. Proper handling of the
ITM and the replicator linked to it along with the CTIs
and SWO are not included.
Signed-off-by: Mathieu Poirier
---
From: Pratik Patel
This driver manages CoreSight ETB (Embedded Trace Buffer) which
acts as a circular buffer sink collecting generated trace data.
Signed-off-by: Pratik Patel
Signed-off-by: Panchaxari Prasannamurthy
Signed-off-by: Mathieu Poirier
---
drivers/coresight/Makefile| 3
I was thinking of removing it in Linux 3.17. I'm not even sure it
compiles right now, hasn't seen any action in years, and all open-source
userspace code to use it has been dead for years.
If you disagree, please speak up loudly in the next month.
Paolo
--
To unsubscribe from this list: send
From: Mathieu Poirier
Currently supporting ETM and ETB. Support for TPIU
and SDTI are yet to be added.
Signed-off-by: Mathieu Poirier
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git
From: Mathieu Poirier
Removing minimal support for etb/etm to favour an implentation
that is more flexible, extensible and capable of handling more
platforms.
Also removing the only client of the old driver. That code can
easily be replaced by entries for etb/etm in the device tree.
From: Mathieu Poirier
This RFC is rescucitating the work submitted by Pratik Patel in
2012 [1].
This set is addressing comments gathered from the initial RFC
and enhance the framework in a few areas. More specifically:
. Sysfs entries have been moved to debugfs.
. The removal of the "bus"
From: Panchaxari Prasannamurthy
Added support for coresight device in dts for Beagle Board, by adding
blocks of coresight, ETM, ETB blocks.
Signed-off-by: Panchaxari Prasannamurthy
---
arch/arm/boot/dts/omap3-beagle.dts | 30 ++
1 file changed, 30 insertions(+)
From: Pratik Patel
This driver manages CoreSight Replicator that takes single input
trace data stream and replicates it to produce two identical
trace data output streams. Replicators are typically used to
route single interleaved trace data stream to two or more sinks.
Signed-off-by: Pratik
Linus,
please pull from the tag "firewire-fixes" at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git
firewire-fixes
to receive a regression fix for the IEEE 1394 subsystem:
Re-enable IRQ-based asynchronous request reception at addresses below 128 TB.
Stefan Richter
To be future-proof and for better readability the time comparisons are
modified to use time_before() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling
---
drivers/misc/sgi-gru/grumain.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Thu, May 29, 2014 at 05:26:51PM +0200, Frederic Weisbecker wrote:
> From: Jacob Shin
>
> Currently bp_len is given a default value of 4. Allow user to override it:
>
> $ perf stat -e mem:0x1000/8
> ^
> bp_len
>
> If no value is
> > Currently the I2C framework insists on devices supplying an I2C ID
> > table. Many of the devices which do so unnecessarily adding quite a
> > few wasted lines to kernel code. This patch allows drivers a means
> > to 'not' supply the aforementioned table and match on either DT
> > and/or
Hi Jacob, Suravee,
On Thu, May 29, 2014 at 05:26:50PM +0200, Frederic Weisbecker wrote:
> From: Jacob Shin
>
> Implement hardware breakpoint address mask for AMD Family 16h and
> above processors. CPUID feature bit indicates hardware support for
> DRn_ADDR_MASK MSRs. These masks further qualify
Add a scrollback buffers for each VGA console. The benefit is that
the scrollback history is not flushed when switching between consoles
but is persistent.
The buffers are allocated on demand when a new console is opened.
Signed-off-by: Manuel Schölling
---
drivers/video/console/Kconfig |6
On 23/05/14 16:53, Vincent Guittot wrote:
> If the CPU is used for handling lot of IRQs, trig a load balance to check if
> it's worth moving its tasks on another CPU that has more capacity
>
> Signed-off-by: Vincent Guittot
> ---
> kernel/sched/fair.c | 13 +
> 1 file changed, 13
On 05/29/2014 11:47 PM, Mike Turquette wrote:
> Quoting Nishanth Menon (2014-05-29 16:22:45)
>> On 05/26/2014 08:07 AM, Thierry Reding wrote:
>>> On Wed, May 14, 2014 at 12:35:18PM -0700, Mike Turquette wrote:
Quoting Thierry Reding (2014-05-14 07:27:40)
>>> [...]
> As for shared clocks
ttps://github.com/nmenon/kernel-test-logs/blob/next-20140530/omap2plus_defconfig/dra7.txt#L151
as an indication of the warning.
Tony,
Would you prefer a patch on top of omap-for-v3.16/dt-v2 branch?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsu
On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
>
On Thu, May 29, 2014 at 04:54:00PM -0700, David Rientjes wrote:
> On Thu, 29 May 2014, Marcelo Tosatti wrote:
>
> > diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> > index 3d54c41..3bbc23f 100644
> > --- a/kernel/cpuset.c
> > +++ b/kernel/cpuset.c
> > @@ -2374,6 +2374,7 @@ static struct cpuset
On Thu, May 29, 2014 at 07:52:00PM +0200, Stephen Warren wrote:
> On 05/28/2014 10:51 AM, Peter De Schrijver wrote:
> > This patch set introduces the 'regs' debugfs entry which shows the
> > contents of all registers related to a clock.
>
> Would it be better to create a regmap object for the
Hi all,
I sometime see lockups when booting my KVM guest with the latest -next kernel,
it basically hangs right when it should start 'init', and after a while I get
the following spew:
[ 30.790833] BUG: spinlock lockup suspected on CPU#1, swapper/1/0
[ 30.770667] BUG: spinlock lockup
On Thu, May 29, 2014 at 05:26:49PM +0200, Frederic Weisbecker wrote:
> Hi,
>
> I've made it wait too much so I'm posting that for review now. This
> implements range breakpoints on some AMD machine by extending the length
> field.
>
> Any comment?
hi,
perf tools patches look ok to me.. let me
On Fri, May 30, 2014 at 11:20:10AM +0800, Dave Young wrote:
>
> For ioremapped efi memory aka old_map the virt addresses are not persistant
> across kexec reboot. kexec-tools will read the runtime maps from sysfs then
> pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause
>
Hi Sachin,
On 29/05/14 08:30, Sachin Kamat wrote:
> PTR_ERR_OR_ZERO simplifies the code.
>
> Signed-off-by: Sachin Kamat
> Cc: Sylwester Nawrocki
> ---
> drivers/phy/phy-exynos-mipi-video.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git
Not on my prespective. Its says "~20 ms actual sleep for any value
given in the 1~20ms range", so from my point of view it will sleep for
20ms, so I will save between 5 to 10ms. But maybe I'm seeing it the
wrong way.
Regards
2014-05-30 13:35 GMT+01:00 Pavel Machek :
> Hi!
>
>> So the
On 30.05.2014 14:46, Krzysztof Kozlowski wrote:
> On pią, 2014-05-30 at 13:50 +0200, Tomasz Figa wrote:
>> Hi Krzysztof,
>>
>> On 13.05.2014 16:12, Krzysztof Kozlowski wrote:
>>> On Exynos4212 USE_DELAYED_RESET_ASSERTION must be set in
>>> ARM_CORE1_OPTION register during CPU power down. This is
On Fri, 30 May 2014, Wolfram Sang wrote:
> On Fri, May 30, 2014 at 01:26:36PM +0100, Lee Jones wrote:
> > Currently the I2C framework insists on devices supplying an I2C ID
> > table. Many of the devices which do so unnecessarily adding quite a
> > few wasted lines to kernel code. This patch
Ever since rtl8192u was added as a staging driver in v2.6.33 it contained
checks for CONFIG_IEEE80211_CRYPT_TKIP. But the Kconfig symbol
IEEE80211_CRYPT_TKIP was renamed to LIB80211_CRYPT_TKIP in v2.6.29. So
these checks have always evaluated to false. And these checks were rather
odd to begin
Christoph Hellwig wrote:
: On Fri, May 16, 2014 at 02:06:42PM +0200, Jan Kasprzak wrote:
: > any news with this patch? Will it be acked by you and submitted upstream?
: > Thanks!
:
: Give me an Acked-by and I'll pull it in.
Acked-By: Jan "Yenya" Kasprzak
Not sure whether I should ack my own
On pią, 2014-05-30 at 13:50 +0200, Tomasz Figa wrote:
> Hi Krzysztof,
>
> On 13.05.2014 16:12, Krzysztof Kozlowski wrote:
> > On Exynos4212 USE_DELAYED_RESET_ASSERTION must be set in
> > ARM_CORE1_OPTION register during CPU power down. This is the proper way
> > of powering down CPU. Additionally
On Fri, May 30, 2014 at 06:49:03PM +0900, Chanwoo Choi wrote:
> Hi Charles,
>
> OK, Let me know about test result.
>
> Thanks,
> Chanwoo Choi
Yeah that seems to work fine here. For the Arizona bit you can
add:
Tested-by: Charles Keepax
Thanks,
Charles
--
To unsubscribe from this list: send
On 05/30/2014 08:10 PM, Wolfram Sang wrote:
Hi Wolfram:
Since this version resolved all comments, it's ok for you?
Sorry, I misunderstood. I thought a V4 was needed, but it isn't. I'll
try to have a look this weekend.
OK. Thanks.
--
To unsubscribe from this list: send the line
On Fri, May 30, 2014 at 01:26:36PM +0100, Lee Jones wrote:
> Currently the I2C framework insists on devices supplying an I2C ID
> table. Many of the devices which do so unnecessarily adding quite a
> few wasted lines to kernel code. This patch allows drivers a means
> to 'not' supply the
Hi!
> So the /Documentation/timers/timers-howto.txt stats:
>
> SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
> * Use usleep_range
>
> - Why not msleep for (1ms - 20ms)?
> Explained originally here:
> http://lkml.org/lkml/2007/8/3/250
> msleep(1~20) may not do what the caller intends, and
>
Hi!
> >> Creating this patch for the Eudyptula Challenge.
> >> Replaced msleep() for a delay < 20ms with a usleep_range() between 1us
> >> and 15000us.
> >> Also inserted a blank line after adeclaration.
> >
> > So you are changing timings without testing. Plus, burning CPU power
> >
Hi Wolfram,
Here we have two patches which achieve exactly the same aim. I
wasn't sure with method you'd prefer, so I thought I'd submit
both and you can make a choice.
Kind regards,
Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Currently the I2C framework insists on devices supplying an I2C ID
table. Many of the devices which do so unnecessarily adding quite a
few wasted lines to kernel code. This patch allows drivers a means
to 'not' supply the aforementioned table and match on either DT
and/or ACPI match tables
Currently the I2C framework insists on devices supplying an I2C ID
table. Many of the devices which do so unnecessarily adding quite a
few wasted lines to kernel code. This patch allows drivers a means
to 'not' supply the aforementioned table and match on either DT
and/or ACPI match tables
The higher levels of impedance have a higher minimum value than the
first level. As the same value was used for all levels, higher impedances
were reported with a very low level of accuracy. This patch applies the
approriate lower threshold for each level, whilst we are changing things
add a
On Fri, May 30, 2014 at 06:38:10AM -0500, Trond Myklebust wrote:
> On Fri, 2014-05-30 at 11:06 +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic())
> > deprecated the
From: Zhang Rui
Because of the growing demand for enumerating ACPI devices to
platform bus, change the code to enumerate ACPI device objects to
platform bus by default. Namely, create platform devices for the
ACPI device objects that
1. Have pnp.type.platform_id set (device objects with _HID
From: Rafael J. Wysocki
Prevent platform devices from being created for ACPI LPSS devices
if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan
handler's callbacks only in that case and still compiling its device
ID list in and registering the scan handler in either case.
This change
So the /Documentation/timers/timers-howto.txt stats:
SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
* Use usleep_range
- Why not msleep for (1ms - 20ms)?
Explained originally here:
http://lkml.org/lkml/2007/8/3/250
msleep(1~20) may not do what the caller intends, and
will often sleep longer
On Thursday, May 29, 2014 07:27:34 PM Greg Kroah-Hartman wrote:
> On Wed, May 28, 2014 at 09:59:45AM +0200, Johan Hovold wrote:
> > [ +CC: Greg, Doug, Stratos, Yuyang ]
> >
> > On Wed, May 21, 2014 at 11:00:51AM +0200, Johan Hovold wrote:
> > > On Wed, May 07, 2014 at 07:10:49AM -0700, Dirk
On Fri, May 09, 2014 at 10:41:27AM -0600, Jens Axboe wrote:
> On 05/09/2014 08:12 AM, Jens Axboe wrote:
> > On 05/09/2014 03:17 AM, Matias Bjørling wrote:
> >> With multi-million IOPS and multi-node workloads, the atomic_t in_flight
> >> tracking becomes a bottleneck. Change the in-flight
> > Hi Wolfram:
> > Since this version resolved all comments, it's ok for you?
Sorry, I misunderstood. I thought a V4 was needed, but it isn't. I'll
try to have a look this weekend.
signature.asc
Description: Digital signature
On Thu, May 29, 2014 at 04:09:48PM -0700, Andrew Morton wrote:
> On Fri, 9 May 2014 18:36:52 +0200 Johan Hovold wrote:
>
> > On Thu, May 08, 2014 at 07:28:04PM +0200, Boris BREZILLON wrote:
> >
> > > > You should also keep the flush (read of IMR) regardless (to make sure
> > > > the write has
On Friday, May 30, 2014 02:00:39 PM Lan Tianyu wrote:
> On 05/20/2014 08:59 PM, Lan Tianyu wrote:
> > ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation
> > region. It allows ACPI aml code able to access such kind of devices to
> > implement some ACPI standard method.
> >
On Friday, May 30, 2014 12:03:08 PM Sachin Kamat wrote:
> Hi Viresh,
>
> On 27 May 2014 17:20, Viresh Kumar wrote:
> > All callers of of_init_opp_table() are required to take reference of
> > dev->of_node, by initiating calls to of_node_{get|put}(), before and after
> > calling
On Fri, May 23, 2014 at 07:16:33PM +0100, Morten Rasmussen wrote:
> +static struct capacity_state cap_states_cluster_a7[] = {
> + /* Cluster only power */
> + { .cap = 358, .power = 2967, }, /* 350 MHz */
> + { .cap = 410, .power = 2792, }, /* 400 MHz */
> + { .cap = 512,
On Fri, 30 May 2014, Naoya Horiguchi wrote:
> We already have a function named hugepage_supported(), and the similar
hugepages_supported()
> name hugepage_migration_support() is a bit unconfortable, so let's rename
> it hugepage_migration_supported().
>
> Signed-off-by: Naoya Horiguchi
On Fri, 30 May 2014, Naoya Horiguchi wrote:
> Curretly hugepage migration is available for all archs which support pmd-level
> hugepage, but testing is done only for x86_64 and there're bugs for other
> archs.
> So to avoid breaking such archs, this patch limits the availability strictly
> to
>
On Friday, May 30, 2014 11:33:25 AM Mika Westerberg wrote:
> On Fri, May 30, 2014 at 04:20:41AM +0200, Rafael J. Wysocki wrote:
> > On Friday, May 23, 2014 02:02:22 AM Zhang Rui wrote:
> > > Hi, all,
> > >
> > > Currently, PNP bus is used as the default bus for for enumerating ACPI
> > > devices
Hi Vikas, Pankaj,
On 27.05.2014 13:26, Vikas Sajjan wrote:
> Hi,
>
> Any comments on this series?
>
I still have this series on my to-review list, but it's quite complex
and I didn't have needed amount of time yet, sorry. At the moment I'm on
vacation, so I don't want to spend too much time on
On 05/30/2014 08:52 PM, Tomasz Figa wrote:
> On 26.05.2014 08:29, Chanwoo Choi wrote:
>> This patch add pmusysreg node for Exynos3250 to access PMU (Power Management
>> Unit)
>> register in a centralized way using syscon driver.
>>
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Kyungmin Park
>>
On 26.05.2014 08:29, Chanwoo Choi wrote:
> This patch add pmusysreg node for Exynos3250 to access PMU (Power Management
> Unit)
> register in a centralized way using syscon driver.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
>
Hi Pavel,
>> Creating this patch for the Eudyptula Challenge.
>> Replaced msleep() for a delay < 20ms with a usleep_range() between 1us
>> and 15000us.
>> Also inserted a blank line after adeclaration.
>
> So you are changing timings without testing. Plus, burning CPU power
> instead of
Hi Krzysztof,
On 13.05.2014 16:12, Krzysztof Kozlowski wrote:
> On Exynos4212 USE_DELAYED_RESET_ASSERTION must be set in
> ARM_CORE1_OPTION register during CPU power down. This is the proper way
> of powering down CPU. Additionally without this the CPU clock down won't
> work after powering down
Ping,
Could you review this patch?
Thanks,
Chanwoo Choi
On 05/26/2014 03:29 PM, Chanwoo Choi wrote:
> This patch add pmusysreg node for Exynos3250 to access PMU (Power Management
> Unit)
> register in a centralized way using syscon driver.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin
On 29/05/14 19:55, Bjørn Mork wrote:
> Jim Baxter writes:
>
>> The NDP was ignoring the wNextNdpIndex in the NDP which
>> means that NTBs containing multiple NDPs would have missed
>> frames.
>
> Well, just for the record: I believe this field was meant to be reserved
> and always 0 in the CDC
Hi Krzysztof,
On 15.05.2014 13:18, Krzysztof Kozlowski wrote:
> Without software reset the secondary CPU does not power up and
> exynos_boot_secondary() ends with pen_release equal to 1. This can be
> observed in dmesg:
> CPU1: failed to come online
> Brought up 1 CPUs
> SMP:
Hi Ulf,
On 30/05/14 12:27, Ulf Hansson wrote:
On 28 May 2014 15:48, wrote:
...
.f_max = 20800,
.explicit_mclk_control = true,
+ .qcom_fifo = true,
};
static int mmci_card_busy(struct mmc_host *mmc)
@@ -1006,6 +1009,40 @@
For x86 boxes, smp_num_siblings is set to a value read in a CPUID call in
detect_ht(). This value is the *factory defined* value in all cases; even
if HT is disabled in BIOS the value still returns 2 if the CPU supports
HT. AMD also reports the factory defined value in all cases.
That is, even
Paulo, this is what I'm going to send upstream tomorrow. FYI.
P.
8<---
I have a system on which I have disabled threading in the BIOS, and I am booting
the kernel with the option "idle=poll".
The kernel displays
process: WARNING: polling idle and HT enabled, performance may degrade
I have a system on which I have disabled threading in the BIOS, and I am booting
the kernel with the option "idle=poll".
The kernel displays
process: WARNING: polling idle and HT enabled, performance may degrade
which is incorrect -- I've already disabled HT.
This warning is issued here:
void
On Fri, May 30, 2014 at 1:30 PM, abdoulaye berthe wrote:
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
> *gpiochip);
> *
> * A gpio_chip with any GPIOs still requested may not be removed.
> */
>
On Fri, 2014-05-30 at 11:06 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Commit febdbfe8a91c (arch: Prepare for smp_mb__{before,after}_atomic())
> deprecated the smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}*()
> functions in favour of the unified
This avoids handling gpiochip remove error in device
remove handler.
Signed-off-by: abdoulaye berthe
---
drivers/gpio/gpiolib.c | 24 +++-
include/linux/gpio/driver.h | 2 +-
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib.c
> Well... I'll try to come up with something better. Even though I only
> forward ported an existing patch to address a memory allocation failure.
How about the patch below then?
>From 52a050f85256d7586933365da1b98c6227651449 Mon Sep 17 00:00:00 2001
From: KAMEZAWA Hiroyuki
Date: Tue, 27 May
On Thu, May 29, 2014 at 09:04:33PM +0200, Stephen Warren wrote:
> On 05/28/2014 06:54 AM, Peter De Schrijver wrote:
> > Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
>
> > diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
> >
Hi,
On Tuesday 06 May 2014 10:22 PM, Tony Lindgren wrote:
> * Sourav Poddar [140506 04:08]:
>> These add device tree entry for qspi controller driver on dra7-evm.
> Thanks applying into omap-for-v3.16/dt.
There is a problem with this. The qspi node defines crossbar number
as its interrupt
On Thursday 29 May 2014 06:38:35 H. Peter Anvin wrote:
> On 05/29/2014 02:26 AM, Arnd Bergmann wrote:
> > On Wednesday 28 May 2014 14:41:52 H. Peter Anvin wrote:
> >> On 05/19/2014 05:36 AM, Arnd Bergmann wrote:
> >>>
> >>> My feeling is that all devices we can think of fall into at least one
>
On Fri 2014-05-30 11:27:13, Miguel Oliveira wrote:
> Creating this patch for the Eudyptula Challenge.
> Replaced msleep() for a delay < 20ms with a usleep_range() between 1us
> and 15000us.
> Also inserted a blank line after adeclaration.
So you are changing timings without testing. Plus,
This avoids handling gpiochip remove error in device
remove handler.
Signed-off-by: abdoulaye berthe
---
drivers/gpio/gpiolib.c | 24 +++-
include/linux/gpio/driver.h | 2 +-
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib.c
On wto, 2014-05-13 at 16:12 +0200, Krzysztof Kozlowski wrote:
> On Exynos4212 USE_DELAYED_RESET_ASSERTION must be set in
> ARM_CORE1_OPTION register during CPU power down. This is the proper way
> of powering down CPU. Additionally without this the CPU clock down won't
> work after powering down
On czw, 2014-05-15 at 13:18 +0200, Krzysztof Kozlowski wrote:
> Without software reset the secondary CPU does not power up and
> exynos_boot_secondary() ends with pen_release equal to 1. This can be
> observed in dmesg:
> CPU1: failed to come online
> Brought up 1 CPUs
> SMP:
On 28 May 2014 15:48, wrote:
> From: Srinivas Kandagatla
>
> MCIFIFOCNT register behaviour on Qcom chips is very different than the other
> pl180 integrations. MCIFIFOCNT register contains the number of
> words that are still waiting to be transferred through the FIFO. It keeps
> decrementing
On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> > On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > This commit introduces a generic device tree binding for IOMMU devices.
> > >
On 29/05/14 20:04, Eric Dumazet wrote:
> On Thu, 2014-05-29 at 18:12 +0100, Jim Baxter wrote:
>> This fixes a problem with dropped packets over 16k CDC-NCM
>> when the connection is being heavily used.
>>
>> The issue was that the skb truesize for the unpacked NCM
>> packets was too high after
On Fri, May 23, 2014 at 10:36:35PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra
On 05/29/2014 10:28 PM, Stefan Kristiansson wrote:
> On Tue, May 27, 2014 at 08:47:36AM +0200, Jonas Bonn wrote:
>> On 05/26/2014 10:52 PM, Geert Uytterhoeven wrote:
>>> CC devicetree for the bindings
>>>
>>> On Mon, May 26, 2014 at 10:31 PM, Stefan Kristiansson
>>> wrote:
+++
The directories for objdump is created by the code
a few lines below:
[ ! -d "$OBJDIFFD/$dn" ] && mkdir -p "$OBJDIFFD/$dn"
Signed-off-by: Masahiro Yamada
Cc: Jason Cooper
---
scripts/objdiff | 2 --
1 file changed, 2 deletions(-)
diff --git a/scripts/objdiff b/scripts/objdiff
index
On Thu, 8 May 2014, Namjae Jeon wrote:
> Date: Thu, 08 May 2014 19:23:19 +0900
> From: Namjae Jeon
> To: Dave Chinner , Theodore Ts'o
> Cc: linux-ext4 , x...@oss.sgi.com,
> linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
> Ashish Sangwan
> Subject: [PATCH v2 0/10] fs:
On Fri, May 30, 2014 at 12:08:08PM +0200, Stephan Mueller wrote:
>> > We already have a user-space interface to change priorities.
>
> Great -- if I may ask, which interface is that?
Take a look at crypto/crypto_user.c
Cheers,
--
Email: Herbert Xu
Home Page:
Hi Joonsoo,
I think you will be loosing the benefit of below patch with your changes.
I am no expert here so please bear with me. I tried explaining in the
inline comments, let me know if I am wrong.
commit 026b08147923142e925a7d0aaa39038055ae0156
Author: Tomasz Stanislawski
Date: Wed Jun 12
Thanks Ulf for reviewing.
On 30/05/14 11:25, Ulf Hansson wrote:
On 28 May 2014 15:47, wrote:
From: Srinivas Kandagatla
On Controllers like Qcom SD card controller where cclk is mclk and mclk should
be directly controlled by the driver.
This patch adds support to control mclk directly in
On Fri, 2014-05-30 at 03:06 -0400, Jérôme Carretero wrote:
> On Thu, 27 Mar 2014 17:57:37 +1100
> Benjamin Herrenschmidt wrote:
>
> > I've been trying a 9230 on a power box here (a 9235 on the same
> > machine works fine) and it blows up with an IOMMU violation early
> > during init.
>
> Hi,
>
Hi Krzysztof,
On 05/30/2014 05:23 PM, Krzysztof Kozlowski wrote:
> On pią, 2014-05-30 at 09:25 +0900, Chanwoo Choi wrote:
>> This patch add S2MPU02 regulator device to existing S2MPS11 device driver
>> because of little difference between S2MPS1x and S2MPU02. The S2MPU02
>> regulator device
Dear Lee Jones and Mark Brown,
The patch[1] has dependency on both mfd.git and regulator.git.
[1] regulator: s2mps11: Add support S2MPU02 regulator device
The mfd.git(for-mfd-next branch) has only following patchset[2] without
patchset[3] about drivers/mfd/sec-core.c.
The regulaotr.git
Thanks Ulf,
On 30/05/14 11:28, Ulf Hansson wrote:
*/
>- if (host->mclk > 1) {
>- ret = clk_set_rate(host->clk, 1);
>+ if (host->mclk > host->variant->f_max) {
You can use the local variant pointer directly, instead of host->variant.
yes,
On 28 May 2014 15:47, wrote:
> From: Srinivas Kandagatla
>
> Some of the controller have maximum supported frequency, This patch adds
> support in variant data structure to specify such restrictions. This
> gives more flexibility in calculating the f_max before passing it to
> mmc-core.
>
>
On 28 May 2014 15:47, wrote:
> From: Srinivas Kandagatla
>
> On Controllers like Qcom SD card controller where cclk is mclk and mclk should
> be directly controlled by the driver.
>
> This patch adds support to control mclk directly in the driver, and also
> adds explicit_mclk_control flag in
kzalloc can fail. Add a null check to avoid null pointer
dereference error while accessing the pointer later.
Signed-off-by: Sachin Kamat
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
On Fri, May 30, 2014 at 09:27:20AM +, Wang, Jiada (ESD) wrote:
> Hi Shijie
>
> After apply this patch into our kernel,
> We are facing data hang issue when sending big size file (2M used in test) to
> uart port
> Note: Rx port is also keep receiving data.
>
> After read the implementation
On Fri, 30 May 2014, Jan Kara wrote:
> > Documentation/kernel-parameters.txt | 19 +-
> > kernel/printk/printk.c | 1218
> > +--
> > 2 files changed, 878 insertions(+), 359 deletions(-)
> >
> >
> > Your patches look clean and pretty nice
Am Freitag, 30. Mai 2014, 17:05:48 schrieb Herbert Xu:
Hi Herbert,
> On Mon, May 26, 2014 at 07:42:57AM +0200, Stephan Mueller wrote:
> > A second aspect is the implementation of the stdrng. Currently, the
> > offered
> > patch does not include the stdrng selection. I am currently working on the
501 - 600 of 1446 matches
Mail list logo
