On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
The main problem with component framework is that componentization
significantly changes every driver and changes it in a way which is not
compatible with traditional drivers, so devices which are intended to
work with
On Mon, Apr 28, 2014 at 11:27:09AM -0600, Stephen Warren wrote:
On 04/28/2014 11:12 AM, Stephen Warren wrote:
On 04/28/2014 10:56 AM, Russell King - ARM Linux wrote:
So, in response to Matt Porter's complaint about breaking prima2, here's
another 16 patches which changes the way the L2
On Tue, Apr 29, 2014 at 09:02:27AM +0900, Simon Horman wrote:
On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote:
Since we now automatically enable early BRESP in core L2C-310 code when
we detect a Cortex-A9, we don't need platforms/SoCs to set this bit
explicitly. Instead, they
On Fri, Apr 25, 2014 at 04:36:01PM +0200, Andrzej Hajda wrote:
On 04/23/2014 07:13 PM, Russell King - ARM Linux wrote:
Let me be absolutely clear *why* I'm very interested in this - and that
is because I'm presently converting TDA998x and Armada DRM to use the
component helpers. If your
On Sat, Apr 26, 2014 at 02:25:03AM +0200, Tomasz Figa wrote:
On 25.04.2014 03:16, Chanwoo Choi wrote:
This patch decide proper lowpower mode of either a15 or a9 according to own
ID
from Main ID register.
Cc: Arnd Bergmann a...@arndb.de
Cc: Marc Zynigier marc.zyng...@arm.com
Signed-off-by:
On Thu, Apr 24, 2014 at 12:24:31PM +0200, Heiko Stübner wrote:
+choice
+ prompt S3C24XX low-level debugging port type
+ depends on DEBUG_LL ARCH_S3C24XX
+
+ config DEBUG_S3C24XX_UART_S3C2440
+ bool S3C2440 uart type
+ help
+ Select this if
On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote:
On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
Yes, I know that you're desperate to play that down, but you can't get
Not true. I only try to find the best solution and the approach with
multiple re-probing just
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
So, maybe you would like to finally address *my* point about TDA998x
and your solution in a way that provides a satisfactory answer. *Show*
how it can be done, or *outline* how it can be done.
Let me be absolutely clear
On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote:
On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote:
On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the device from the device itself
seems to me a good thing. I would
On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote:
Hi Russel,
Thanks for comments.
On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote:
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+out:
+ if (ret != -EPROBE_DEFER)
+ exynos_drm_dev_ready
On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote:
Separation of the interfaces exposed by the device from the device itself
seems to me a good thing. I would even consider it as a biggest
advantage of this solution :)
The problem of re-initialization does not seems to be
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+out:
+ if (ret != -EPROBE_DEFER)
+ exynos_drm_dev_ready(pdev-dev);
So we end up with everyone needing a ready call in each sub-driver
back into the main driver... this makes it impossible to write a
generic
On Thu, Apr 17, 2014 at 01:28:50PM +0200, Andrzej Hajda wrote:
+static int exynos_drm_add_blocker(struct device *dev, void *data)
+{
+ struct device_driver *drv = data;
+
+ if (!platform_bus_type.match(dev, drv))
+ return 0;
+
+ device_lock(dev);
+ if
On Sun, Apr 06, 2014 at 01:21:24PM +0900, Inki Dae wrote:
As you may know, there is exynos chip that has two display
controllers. So it is possible to compose display pipe lines at same
time like below,
fimd0-bridges..--Panel
fimd1-maybe bridges..-CPU Panel
How we can
On Sat, Apr 05, 2014 at 08:31:15PM +0200, Tomasz Figa wrote:
Maybe my words have been misinterpreted, but all I'm suggesting here is
that there is no need to add any new data to DT to solve the same issue
to the same extent as componentized subsystem framework, at least in
Exynos case.
On Fri, Mar 28, 2014 at 09:00:48AM -0700, Tony Lindgren wrote:
* Russell King rmk+ker...@arm.linux.org.uk [140328 08:22]:
We have a mixture of different devices with different register layouts,
but we group all the bits together in an opaque mess. Split them out
into those which are
On Thu, Feb 13, 2014 at 10:27:01AM -0800, Greg KH wrote:
On Thu, Feb 13, 2014 at 06:15:59PM +, Russell King - ARM Linux wrote:
On Thu, Feb 13, 2014 at 10:12:16AM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 10:04:15AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 02
On Thu, Feb 13, 2014 at 03:26:06PM -0800, Greg KH wrote:
On Thu, Feb 13, 2014 at 06:42:49PM +, Russell King - ARM Linux wrote:
We went through this before, and I stated the paths, and no one disagreed
with that.
It /is/ racy.
Ok, I just went and looked at the uart driver register
On Thu, Feb 13, 2014 at 04:14:36PM -0800, Greg KH wrote:
On Fri, Feb 14, 2014 at 12:07:17AM +, Russell King - ARM Linux wrote:
On Thu, Feb 13, 2014 at 03:26:06PM -0800, Greg KH wrote:
On Thu, Feb 13, 2014 at 06:42:49PM +, Russell King - ARM Linux wrote:
We went through
On Sun, Jan 26, 2014 at 11:30:00PM -0500, Nicolas Pitre wrote:
On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
Peter handed it on. Try using git log on Documentation/devices.txt. It
still gets updates.
Perhaps you'd
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
Peter handed it on. Try using git log on Documentation/devices.txt. It
still gets updates.
Perhaps you'd care to stick to reality and fix the tree instead of trying
to excuse the mess ?
Perhaps returning to reality might be
On Tue, Jan 21, 2014 at 09:25:31AM +, One Thousand Gnomes wrote:
static DEFINE_MUTEX(foo_mutex);
static unsigned foo_devices;
static int foo_probe(struct platform_device *pdev)
{
int ret;
mutex_lock(foo_mutex);
if (foo_devices++ == 0)
On Tue, Jan 21, 2014 at 09:03:40AM +, Alan Cox wrote:
On Tue, 21 Jan 2014 00:16:57 +
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
[I did post a reply to this while on my phone but it got rejected]
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
But yes I
On Tue, Jan 21, 2014 at 04:59:35PM +, Mark Brown wrote:
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
They should have followed proper practice and reserved their minors. The
device number belongs to the Altix. The driver should just move.
They should have done that about a
On Mon, Jan 20, 2014 at 02:32:35PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through tty_register_driver call. This should typically happen
during device probe call.
In a multiplatform scenario, it is possible that multiple serial
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through tty_register_driver call. This should typically happen
during device probe call.
In a multiplatform scenario, it is possible that multiple serial
On Mon, Jan 20, 2014 at 05:23:21PM +0530, Tushar Behera wrote:
On 20 January 2014 15:35, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through
On Mon, Jan 20, 2014 at 03:11:41PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 02
On Mon, Jan 20, 2014 at 11:14:57PM +, Mark Brown wrote:
On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
If the hardware isn't present then the driver shouldn't even register
with the tty layer in the first place so it doesn't make any resource
differeneces either for properly
On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
I don't believe the driver model has any locking to prevent a drivers
-probe function running concurrently with it's -remove function for
two (or more) devices
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
But yes I agree about the idiom, but a definite NAK to any attempts to
plaster over this grand screwup by crapping in the tty core. Your turd,
deal with it locally in the ARM code if you can't apply common sense and
just go dynamic.
I
On Mon, Jan 20, 2014 at 04:26:23PM -0800, Greg KH wrote:
On Tue, Jan 21, 2014 at 12:07:06AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
I don't believe the driver
On Wed, Jan 08, 2014 at 08:21:21AM -0800, Doug Anderson wrote:
WIll,
Thanks for your comments!
On Wed, Jan 8, 2014 at 6:35 AM, Will Deacon will.dea...@arm.com wrote:
NAK. Whilst I appreciate that you may not be able to fix your bootloader,
this isn't the right change to make in the
On Wed, Jan 08, 2014 at 11:43:29AM -0800, Doug Anderson wrote:
Olof came up with the idea that you could update the RW firmware
(affects initial boot) and then cache away the value and restore it in
the kernel after resume. That would still require a kernel patch but
perhaps a less
On Sun, Nov 17, 2013 at 03:59:04PM +, Catalin Marinas wrote:
No L2x0 (L210, L220, PL310) cache on ARMv8. And here I strongly
recommend the hardware people to make proper external caches which can
be flushed by standard CPU instructions, not MMIO. Any such caches
must be enabled by firmware
On Mon, Nov 18, 2013 at 10:03:37AM -0700, Stephen Warren wrote:
On 11/18/2013 04:58 AM, Catalin Marinas wrote:
...
Of course, trusted foundations interface could be plugged into cpu_ops
on arm64 but I will NAK it on the grounds of not using the PSCI API, nor
the SMC calling convention (and
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
Hi Russell,
Em Mon, 30 Sep 2013 13:57:47 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On 09/19/2013 11:44 PM, Russell King wrote:
Replace the following sequence:
dma_set_mask(dev, mask);
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
On Thu, 19 Sep 2013, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
[...]
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some
On Tue, Aug 20, 2013 at 06:11:10PM +0200, Tomasz Figa wrote:
Sometimes it is necessary to fix interrupt affinity to an offline CPU,
for example in initialization of local timers. This patch modifies
.set_affinity() operation of irq-gic driver to fall back to any possible
CPU if no online CPU
On Fri, Aug 09, 2013 at 03:35:14PM +0530, Tushar Behera wrote:
When LPAE is enabled, we need to set 64bit DMA mask bits.
*Please* check the list archives. I sent during the last 7 days a patch
series which should address this problem. Unfortunately, it seems almost
no one has looked at it.
--
On Tue, Aug 06, 2013 at 08:37:28PM -0700, Joe Perches wrote:
On Wed, 2013-08-07 at 08:51 +0530, Sachin Kamat wrote:
+CC Joe Perches
On 7 August 2013 01:32, Russell King - ARM Linux li...@arm.linux.org.uk
wrote:
Also note:
On Tue, Aug 06, 2013 at 05:01:13PM +0530, Sachin Kamat
On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
-- compatible : samsung,i2s-v5
+- compatible : should be one of the following.
+ - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
+ has only 8/16bit support.
+ - samsung,s3c6410-i2sv4: for 8/16/24bit
On Fri, Jul 26, 2013 at 04:21:16PM +0200, Tomasz Figa wrote:
Hi Russell,
On Friday 26 of July 2013 15:06:18 Russell King - ARM Linux wrote:
On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
-- compatible : samsung,i2s-v5
+- compatible : should be one of the following
On Fri, Jul 19, 2013 at 02:58:41PM +0100, Lee Jones wrote:
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/boot/dts/exynos5420.dtsi | 2 +-
One question. What have all these files got to do with ux500 ?
--
On Thu, Jun 27, 2013 at 09:17:13AM +0300, Felipe Balbi wrote:
On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
Hi,
On 06/25/2013 05:06 PM, Felipe Balbi wrote:
+static struct platform_driver exynos_video_phy_driver = {
+ .probe = exynos_video_phy_probe,
On Sun, Jun 16, 2013 at 10:54:08PM +0200, Tomasz Figa wrote:
Instead of defining new bool field in vendor_data struct for each quirk,
it is more reasonable to use a single flags field and make each quirk
use single bits.
Please explain why this is better over the existing system, and why it is
On Sun, Jun 16, 2013 at 10:54:15PM +0200, Tomasz Figa wrote:
@@ -561,9 +564,9 @@ static u32 pl08x_getbytes_chan(struct pl08x_dma_chan
*plchan)
bytes += get_bytes_in_cctl(llis_va[index].cctl);
/*
- * A LLI pointer of 0 terminates the LLI
On Wed, Apr 24, 2013 at 12:20:24PM +0800, Chen Gang wrote:
If CONFIG_MMU is disabled, it will let ARM9TDMI and ARM7TDMI visible,
but in fact, only AT91X40 need ARM7TDMI, so need not let them visible.
I'll apply it myself this evening. Can I add:
Tested-by: Chen Gang gang.c...@asianux.com
to
On Wed, Apr 10, 2013 at 06:56:48AM -0700, Doug Anderson wrote:
Thomas,
On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
The call to regulator_enable() is prior to the call to mmc_add_host().
Hence, call to mmc_fre_host is not required in this case. So the
On Thu, Apr 04, 2013 at 07:51:43PM +0900, Kukjin Kim wrote:
+static u64 dma_mask64 = DMA_BIT_MASK(64);
...
+ if (event != BUS_NOTIFY_ADD_DEVICE)
+ return NOTIFY_DONE;
+
+ dev-dma_mask = dma_mask64;
Sharing the dma mask in this way is a potential issue should you have a
On Wed, Apr 17, 2013 at 05:25:34PM +0800, Chen Gang wrote:
CONFIG_CPU_ARM7TDMI=y
CONFIG_CPU_ARM9TDMI=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v4T=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
This is an invalid configuration. A single kernel can not support ARMv7
and ARMv4T simultaneously.
The problem is
On Mon, Apr 08, 2013 at 12:27:34PM +0200, Sylwester Nawrocki wrote:
On 04/08/2013 11:57 AM, Kukjin Kim wrote:
Yes, this looks better. However after posting this patch I noticed linker
errors in some builds due to undefined cpu_arm920_do_suspend,
cpu_arm920_do_resume routines.
It seems it is
On Sat, Mar 30, 2013 at 05:57:38PM +0800, Ning Jiang wrote:
2013/3/30 Stephen Boyd sb...@codeaurora.org:
On 03/29/13 02:24, ning.n.ji...@gmail.com wrote:
From: Ning Jiang ning.n.ji...@gmail.com
Currently there are two problems when we try to stop local timer.
First, it calls set_mode
On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote:
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
Switching to timer-based delay loop
Registered
On Tue, Mar 12, 2013 at 01:42:19AM +0100, Heiko Stübner wrote:
+ clk = clk_register(NULL, pll-hw);
+ if (IS_ERR(clk)) {
+ pr_err(%s: failed to register pll clock %s\n, __func__,
+ name);
+ kfree(pll);
+ }
+
+ if
On Thu, Mar 07, 2013 at 10:14:19AM +0900, Kukjin Kim wrote:
Russell King - ARM Linux wrote:
And deleting entries from it is pointless if they've ever been in the
kernel.
OK, I see and agree.
The issue is that the database system locks an entry into the file as
soon as support is merged
On Thu, Mar 07, 2013 at 04:28:00PM +0100, Sylwester Nawrocki wrote:
On 03/07/2013 05:13 AM, Amit Daniel Kachhap wrote:
+ dvfs_info-cpu_clk = devm_clk_get(dvfs_info-dev, armclk);
+ if (IS_ERR_OR_NULL(dvfs_info-cpu_clk)) {
devm_clk_get() return value needs to be checked with IS_ERR(),
On Thu, Mar 07, 2013 at 09:50:17AM +0900, Kukjin Kim wrote:
Paul Bolle wrote:
On Thu, 2013-03-07 at 09:02 +0900, Kukjin Kim wrote:
BTW, so the machine type can be removed at arch/arm/tools/mach-types as
well.
Well, that file has a big comment on top, containing the line:
On Tue, Feb 26, 2013 at 03:26:53PM +0530, Inderpal Singh wrote:
Only cortex-a9 based samsung platforms have l2x0 cache controller. Hence check
the same before restoring the cache in resume.
Why is this patch soo complicated? Can't you read the CPUs MIDR register
from assembly code?
--
To
On Tue, Feb 26, 2013 at 04:46:01PM +0530, Inderpal Singh wrote:
On 26 February 2013 15:32, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Feb 26, 2013 at 03:26:53PM +0530, Inderpal Singh wrote:
Only cortex-a9 based samsung platforms have l2x0 cache controller. Hence
check
On Sun, Feb 24, 2013 at 12:45:11PM +0100, Julia Lawall wrote:
The function s3c24xx_irq_map in arch/arm/mach-s3c24xx/irq.c contains the
code:
parent_irq_data = parent_intc-irqs[irq_data-parent_irq];
if (!irq_data) {
pr_err(irq-s3c24xx: no
On Tue, Jan 29, 2013 at 03:40:38PM +0530, srinidhi kasagar wrote:
- Added l2x0_quirks to manage the errata in cpu_idle path. Tried to address
Russell's comment on this, but could not completely. Because, neither I can
keep the #ifdef CONFIG_PL310_ERRATA_769419 nor remove it entirely since
On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
Add 'smc' (Secure Monitor Call) identifier to differentiates
the platforms which implements this.
This patch makes no sense.
So, if setting 'smc' in the DT description is supposed to mean that
the platform has a secure monitor
On Tue, Jan 29, 2013 at 05:08:53PM +0530, Srinidhi Kasagar wrote:
On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
Add 'smc' (Secure Monitor Call) identifier to differentiates
the platforms which
On Tue, Jan 29, 2013 at 05:19:27PM +0530, Srinidhi Kasagar wrote:
On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
Add 'smc' (Secure Monitor Call) identifier to differentiates
the platforms which
On Wed, Jan 09, 2013 at 06:24:41PM +0530, Prasanna Kumar wrote:
After Suspend-Resume operation, it is observed that CLK_TOP_SRC3 register
gets modified if the G-Scaler/MFC devices are power gated.
The clock for G-Scaler gets set to XXTI which results in the device
running very slow.This
On Wed, Dec 26, 2012 at 05:58:32PM +0530, Vivek Gautam wrote:
+ if (!ret)
+ sphy-phyctrl_pmureg = ioremap(reg[0], reg[1]);
+
+ of_node_put(usbphy_pmu);
+
+ if (IS_ERR_OR_NULL(sphy-phyctrl_pmureg)) {
No. Learn what the error return values are from functions. Using
On Thu, Dec 20, 2012 at 10:14:26PM +0100, Tomasz Figa wrote:
Hi Olof,
On Thursday 20 of December 2012 11:56:59 Olof Johansson wrote:
Hi,
On Thu, Dec 20, 2012 at 11:03 AM, Kukjin Kim kgene@samsung.com
wrote:
The size of memory bank should be under 256MB, because current
On Mon, Dec 10, 2012 at 03:02:28PM +0530, Giridhar Maruthy wrote:
Hi Russel,
Thanks for review and please find my replies below.
On 7 December 2012 18:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 07, 2012 at 05:33:17PM +0530, Tushar Behera wrote:
On 12/03/2012
On Fri, Dec 07, 2012 at 05:33:17PM +0530, Tushar Behera wrote:
On 12/03/2012 05:46 PM, Giridhar Maruthy wrote:
This patch adds slave support to i2c. The dt entry i2c-mode
decides at probe time if the controller needs to work in
slave mode and the controller is accordingly programmed.
(I
On Mon, Nov 19, 2012 at 01:24:49PM -0500, Bill Pemberton wrote:
arch/arm/mach-sa1100/neponset.c | 2 +-
For this alone,
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to
On Thu, Oct 25, 2012 at 05:22:38PM +0200, Tomasz Figa wrote:
+static int exynos_do_idle(void)
+{
+exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
+return 0;
+}
This looks fine as an API - it has a defined purpose.
+
+static int exynos_cpu_boot(int cpu)
+{
+
On Thu, Oct 25, 2012 at 05:22:40PM +0200, Tomasz Figa wrote:
@@ -47,6 +48,8 @@ static inline void __iomem *cpu_boot_reg(int cpu)
{
void __iomem *boot_reg;
+ if (!call_firmware_op(cpu_boot_reg, cpu, boot_reg))
+ return boot_reg;
boot_reg = cpu_boot_reg_base();
On Mon, Nov 12, 2012 at 04:39:28PM +0900, Kukjin Kim wrote:
(+ Russell King)
I think there's still an amount of work to do here; it's not a generic
interface at the moment because it makes some assumptions about how
things are done (eg, it assumes that there _will_ be a CPU boot register;
that
On Mon, Nov 12, 2012 at 04:12:29PM +0100, Maarten Lankhorst wrote:
Op 08-11-12 21:23, Sasha Levin schreef:
@@ -465,10 +465,8 @@ static void __init combiner_cascade_irq(unsigned int
combiner_nr, unsigned int i
else
max_nr = EXYNOS4_MAX_COMBINER_NR;
- if
On Wed, Oct 17, 2012 at 08:00:00PM +0900, Kukjin Kim wrote:
+static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
+{
+ struct clk *ref_clk;
+ int refclk_freq = 0;
+
+ ref_clk = clk_get(sphy-dev, xusbxti);
+ if (IS_ERR(ref_clk)) {
IS_ERR_OR_NULL(ref_clk)?
People,
This is not aimed at anyone specifically - but it is aimed at everyone
who reviews patches to make them aware of this issue, and to modify their
behaviour.
I'm geting sick and tired of telling people about this. I've just
floated the idea of removing IS_ERR_OR_NULL from the kernel tree
On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote:
So, what to do? It can and has been used sensibly, so I don't think removing
it is the best option.
Well, the first thing that needs to be done is a full review of every user
and fixes applied.
The second thing is that we need eyes
On Thu, May 17, 2012 at 08:40:08PM +0530, Thomas Abraham wrote:
+err_clk:
+ if (!IS_ERR(host-ciu_clk))
+ clk_disable_unprepare(host-ciu_clk);
+ if (!IS_ERR(host-biu_clk))
+ clk_disable_unprepare(host-biu_clk);
+ clk_put(host-ciu_clk);
+
On Tue, May 15, 2012 at 07:13:28PM +0900, Kyoungil Kim wrote:
port-baudclk_rate should be compared to the rate of port-baudclk,
because port-baudclk_rate was assigned as the rate of port-baudclk
previously.
So to check that the current baudclk rate is same as previous rate,
the target of
On Tue, May 15, 2012 at 08:52:39PM +0900, Kyoungil Kim wrote:
Russell King wrote:
On Tue, May 15, 2012 at 07:13:28PM +0900, Kyoungil Kim wrote:
port-baudclk_rate should be compared to the rate of port-baudclk,
because port-baudclk_rate was assigned as the rate of port-baudclk
On Tue, May 15, 2012 at 09:37:16PM +0900, Kyoungil Kim wrote:
port-baudclk_rate should be compared to the rate of port-baudclk,
because port-baudclk_rate was assigned as the rate of port-baudclk
previously.
So to check that the current baudclk rate is same as previous rate,
the target of
On Wed, May 09, 2012 at 01:50:28PM +0100, Sangwook Lee wrote:
struct generic_pm_domain already has a field for name. Use that field
instead of creating another field in struct exynos_pm_domain
Argh. No.
@@ -99,7 +98,7 @@ static __init int exynos_pm_dt_parse_domains(void)
if
On Wed, May 02, 2012 at 03:53:53PM +0100, James Hogan wrote:
Hi
On 2 May 2012 06:07, Thomas Abraham thomas.abra...@linaro.org wrote:
+ if (IS_ERR(host-biu_clk))
+ dev_info(host-dev, biu clock not available\n);
In this case, should it set host-biu_clk to NULL or are
On Tue, May 01, 2012 at 10:07:40PM -0700, Thomas Abraham wrote:
Some platforms allow for clock gating and control of bus interface unit clock
and card interface unit clock. Add support for clock lookup of optional biu
and ciu clocks for clock gating and clock speed determination.
As we're
On Wed, Apr 25, 2012 at 11:21:47AM +, Arnd Bergmann wrote:
Note that the point of the DEFINE_RES_*() macros is really to prevent
people from coming up with new silly macros to do the same thing, as
we've had in the past.
One of the other reaons was to stop the stream of resources with
On Thu, Apr 19, 2012 at 10:25:36AM +0200, Sylwester Nawrocki wrote:
On 04/19/2012 02:12 AM, Kukjin Kim wrote:
--- a/arch/arm/plat-samsung/include/plat/watchdog-reset.h
+++ b/arch/arm/plat-samsung/include/plat/watchdog-reset.h
@@ -25,7 +25,7 @@ static inline void arch_wdt_reset(void)
On Thu, Mar 29, 2012 at 06:55:32PM +0900, Cho KyongHo wrote:
In dma_cache_maint_page(), if offset is larger than PAGE_SIZE,
len becomes PAGE_SIZE - offset. If size is smaller than
PAGE_SIZE - offset, next calcuation of left cause overflow.
It is invalid for offset to be larger than PAGE_SIZE
On Wed, Mar 07, 2012 at 02:36:52AM -0800, Kukjin Kim wrote:
WARNING: arch/arm/mach-s3c24xx/built-in.o(.data+0xf44): Section mismatch in
reference
from the variable s3c2416_irq_interface to the function
.init.text:s3c2416_irq_add()
The variable s3c2416_irq_interface references
the function
On Wed, Feb 29, 2012 at 04:04:22PM +0100, Marek Szyprowski wrote:
+static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct
*vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ struct dma_attrs *attrs)
+{
+ struct arm_vmregion *c;
On Wed, Feb 22, 2012 at 11:11:49AM +0900, Kukjin Kim wrote:
Unfortunately, I couldn't find his name for dma/pl330.c from my side and
if required, he can do it later. Why should I do?
I'm very unhappy with this talking and I think, there is no more useful
talking with you. I'd like to know
On Wed, Feb 22, 2012 at 04:42:08PM +0530, Jassi Brar wrote:
On Wed, Feb 22, 2012 at 3:57 PM, Vinod Koul vinod.k...@intel.com wrote:
Sadly, what a mess!!!
Jassi, you don't own the copyright, your company did, as they employed
you to do the job. So both your and Kukjin are not correct in
On Wed, Feb 22, 2012 at 10:50:29PM +0530, Jassi Brar wrote:
* Based on:
* arch/arm/common/pl330.c, arch/arm/include/asm/hardware/pl330.h
* Copyright (C) 2010 Samsung Electronics Co Ltd.
Doesn't make any sense because arch/arm/common/pl330.c
and
101 - 200 of 496 matches
Mail list logo
