Re: [PATCH v5 3/5] driver core: handle -EPROBE_DEFER from bus_type.match()

On Wed, Dec 23, 2015 at 11:59:26AM +0100, Marek Szyprowski wrote: > From: Tomeu Vizoso > > Allow implementations of the match() callback in struct bus_type to > return errors and if it's -EPROBE_DEFER then queue the device for > deferred probing. > > This is useful

Re: [PATCH v5 2/5] ARM: sa1111: ensure no negative value gets returned on positive match

On Wed, Dec 23, 2015 at 11:59:25AM +0100, Marek Szyprowski wrote: > This patch ensures that existing bus match callbacks don't return > negative values (which might be interpreted as potential errors in the > future) in case of positive match. This actually can't return a negative number - only

Re: [PATCH v3 2/3] ARM: amba: Move reading of periphid to amba_match()

On Tue, Dec 01, 2015 at 02:34:25PM +0100, Marek Szyprowski wrote: > From: Tomeu Vizoso > > Reading the periphid when the Primecell device is registered means that > the apb pclk must be available by then or the device won't be registered > at all. > > By reading the

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

On Thu, Nov 26, 2015 at 11:24:50AM +0100, Ulf Hansson wrote: > On 26 November 2015 at 09:39, Marek Szyprowski <m.szyprow...@samsung.com> > wrote: > > Hello, > > > > On 2015-11-25 19:09, Russell King - ARM Linux wrote: > >> > >> On Wed, Nov

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

On Wed, Nov 25, 2015 at 02:56:10PM +0100, Ulf Hansson wrote: > On 25 November 2015 at 14:34, Marek Szyprowski > wrote: > > Is ignoring dev_pm_domain_attach() return value a solution for you? > > That's probably better than nothing, but I wonder if it in practice > will

Re: [PATCH 1/2] drivers: amba: properly handle devices with power domains

On Wed, Nov 25, 2015 at 01:58:09PM +0100, Marek Szyprowski wrote: > To read pid/cid registers, the probed device need to be properly turned on. > When it is inside a power domain, the bus code should ensure that the > given power domain is enabled before trying to access device's registers. > >

Re: [PATCH] ARM: use "depends on" for SoC configs instead of "if" after prompt

On Mon, Nov 16, 2015 at 10:32:51AM +, yamada.masah...@socionext.com wrote: > Hi Arnd, > > > > On Monday 16 November 2015 12:06:10 Masahiro Yamada wrote: > > > Many ARM sub-architectures use prompts followed by "if" conditional, > > > but it is wrong. > > > > > > Please notice the difference

Re: [RFC PATCH] ARM: exynos_defconfig: Increase CONFIG_BLK_DEV_RAM_SIZE to 64K

On Mon, Oct 19, 2015 at 01:48:13PM +0200, Javier Martinez Canillas wrote: > Hello Alim, > > On 10/19/2015 12:48 PM, Alim Akhtar wrote: > > CONFIG_BLK_DEV_RAM_SIZE is currently set to 8K, which is a bit on the > > smaller side, lets bump it up to 64K so that a bigger RAM_DISK can > > be used with

Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling

On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote: > > Yet the rc-cec is a module in the filesystem, but it doesn't seem to > > be loaded automatically - even after the system has booted, the module > > hasn't been loaded. > > > > It looks like it _should_ be loaded, but this plainly

Re: [PATCHv9 07/15] cec: add HDMI CEC framework

On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote: > On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote: > > Surely you aren't proposing that drivers should write directly to > > adap->phys_addr without calling some notification function that the > > phys

Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling

On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote: > On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote: > > On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote: > >> From: Kamil Debski <ka...@wypas.org> > >> > >> Add handling of

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

On Mon, Oct 12, 2015 at 02:39:42PM +0200, Hans Verkuil wrote: > On 10/12/2015 02:33 PM, Kamil Debski wrote: > > The possible status values that are implemented in the CEC framework > > are following: > > > > +/* cec status field */ > > +#define CEC_TX_STATUS_OK (0) > > +#define

Re: [PATCH] sched_clock: add data pointer argument to read callback

On Sat, Oct 10, 2015 at 01:42:47AM +0100, Måns Rullgård wrote: > Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > > > On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote: > >> Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > >

Re: [PATCH] sched_clock: add data pointer argument to read callback

On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote: > This passes a data pointer specified in the sched_clock_register() > call to the read callback allowing simpler implementations thereof. > > In this patch, existing uses of this interface are simply updated > with a null pointer.

Re: [PATCH] sched_clock: add data pointer argument to read callback

On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote: > Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > > > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote: > >> This passes a data pointer specified in the sched_clock_register() >

Re: [PATCHv9 06/15] rc: Add HDMI CEC protocol handling

On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote: > From: Kamil Debski > > Add handling of remote control events coming from the HDMI CEC bus. > This patch includes a new keymap that maps values found in the CEC > messages to the keys pressed and released. Also, a

Re: [PATCHv9 07/15] cec: add HDMI CEC framework

On Mon, Sep 07, 2015 at 03:44:36PM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > The added HDMI CEC framework provides a generic kernel interface for > HDMI CEC devices. > > Signed-off-by: Hans Verkuil > [k.deb...@samsung.com: Merged CEC

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote: > + if (status & CEC_STATUS_TX_DONE) { > + if (status & CEC_STATUS_TX_ERROR) { > + dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n"); > + cec->tx = STATE_ERROR; > + } else

Re: [PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote: > + cec->adap = cec_create_adapter(_cec_adap_ops, cec, > + CEC_NAME, CEC_CAP_STATE | > + CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO | > + CEC_CAP_IS_SOURCE, > + 0, THIS_MODULE,

Re: [PATCH RFT] mach-s3c64xx:Fix error handling for certain calls to s3c_gpio_cfgpin_range in the file dev-audio.c

On Wed, Sep 16, 2015 at 11:00:35PM -0400, Nicholas Krause wrote: > diff --git a/arch/arm/mach-s3c64xx/dev-audio.c > b/arch/arm/mach-s3c64xx/dev-audio.c > index ff780a8..81fabdb 100644 > --- a/arch/arm/mach-s3c64xx/dev-audio.c > +++ b/arch/arm/mach-s3c64xx/dev-audio.c > @@ -27,6 +27,7 @@ > static

Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

On Thu, Sep 03, 2015 at 11:04:40AM +0200, Thierry Reding wrote: > Conversely, if the panel isn't capable of generating an HPD signal, then > I don't think it would be appropriate to make it a DT property. It would > be better to hard-code it in the driver, lest someone forget to set the > property

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

On Tue, Aug 25, 2015 at 04:21:51PM +0200, Thierry Reding wrote: You cited code from dw_hdmi.c earlier, it looks like it might be correct even though it doesn't cite a reference for why this was done. Perhaps someone on this thread, or someone involved with dw_hdmi can answer where that code

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

On Tue, Aug 25, 2015 at 11:12:48AM +0200, Thierry Reding wrote: On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote: It goes beyond bindings IMO. The use of the component framework or not has been at the whim of driver writers as well. It is either used or private APIs are created.

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

On Tue, Aug 25, 2015 at 12:40:01PM +0200, Thierry Reding wrote: On Tue, Aug 25, 2015 at 10:29:39AM +0100, Russell King - ARM Linux wrote: Now, what happens when some other DRM driver wants to use the tda998x driver, and its bindings are not compatible with the component helpers? They're

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: Easiest of all would probably be to get the sub-arch patches into one release, then switch the prototypes and function definitions in the next. If you switch prototypes first you'll get a bunch of warnings, right? Wrong way

Re: [PATCHv8 07/15] cec: add HDMI CEC framework

On Tue, Aug 18, 2015 at 10:26:32AM +0200, Hans Verkuil wrote: + /* Part 2: Initialize and register the character device */ + cdev_init(cecdev-cdev, cec_devnode_fops); + cecdev-cdev.owner = owner; + + ret = cdev_add(cecdev-cdev, MKDEV(MAJOR(cec_dev_t), cecdev-minor), +

Re: [PATCH v2 06/13] irqchip: kill off set_irq_flags usage

On Sun, Jul 12, 2015 at 06:43:56PM +0200, Thomas Gleixner wrote: The probe function was added in the initial implementation of the driver (2006), so it predates device tree. drivers/net/appletalk/ltpc.c drivers/net/arcnet/com20020-isa.c drivers/net/arcnet/com90io.c

Re: [PATCH v2 06/13] irqchip: kill off set_irq_flags usage

On Thu, Jul 16, 2015 at 09:32:20PM +0200, Robert Jarzmik wrote: For PXA I must admit I don't yet know. I know lubbock has an UCB1400, but I don't have it working yet, so I can't foresee the problems yet. The UCB1400 is an AC'97 device which is quite different from its predecessors, and is not

Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h

On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote: Yeah, completely agree with Linus on the visibility problem and that's exactly the reason why we don't include stdint.h in the kernel header and expect userspace to define the ISO types somewhere. But using the types from

Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h

On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote: Using types that differs on 32-bit and 64-bit machines for a kernel interface is indeed a rather bad idea. This not only includes longs, but pointers as well. [cut standard stdint.h types argument which we've heard before] You

Re: [PATCH 05/98] exynos_drm.h: use __u64 from linux/types.h

On Sat, May 30, 2015 at 05:37:57PM +0200, Mikko Rapeli wrote: Fixes userspace compilation error: drm/exynos_drm.h:30:2: error: unknown type name ‘uint64_t’ Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi This is another thing which we need to address. We should not be using unsigned

Re: [PATCH] ARM: fix exynos randconfig build error

On Tue, Mar 03, 2015 at 01:44:34PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, On Tuesday, March 03, 2015 04:40:02 AM Kukjin Kim wrote: On 02/27/15 06:30, Kukjin Kim wrote: On 02/25/15 20:46, Krzysztof Kozlowski wrote: 2015-02-25 12:26 GMT+01:00 Russell King

Re: [PATCH] video: treat signal like timeout as failure

On Tue, Mar 10, 2015 at 01:51:16PM +0100, Nicholas Mc Guire wrote: On Tue, 10 Mar 2015, Tomi Valkeinen wrote: On 20/01/15 07:23, Nicholas Mc Guire wrote: if(!wait_for_completion_interruptible_timeout(...)) only handles the timeout case - this patch adds handling the signal case the

Re: [PATCH] video: treat signal like timeout as failure

On Tue, Mar 10, 2015 at 03:39:28PM +0100, Nicholas Mc Guire wrote: On Tue, 10 Mar 2015, Russell King - ARM Linux wrote: On Tue, Mar 10, 2015 at 01:51:16PM +0100, Nicholas Mc Guire wrote: On Tue, 10 Mar 2015, Tomi Valkeinen wrote: On 20/01/15 07:23, Nicholas Mc Guire wrote

Re: [PATCH] video: treat signal like timeout as failure

On Tue, Mar 10, 2015 at 04:55:56PM +0200, Tomi Valkeinen wrote: On 10/03/15 16:46, Russell King - ARM Linux wrote: In which case, let me propose that the exynos fbdev driver needs to be moved to drivers/staging, and stay there until this stuff gets fixed. drivers/staging is supposed

Re: [PATCH v2 1/2] drm/exynos: fix DMA_ATTR_NO_KERNEL_MAPPING usage

On Wed, Feb 04, 2015 at 11:20:19AM +0100, Marek Szyprowski wrote: diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c b/drivers/gpu/drm/exynos/exynos_drm_buf.c index 9c80884..24994ba 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_buf.c +++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c @@

Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

On Fri, Jan 30, 2015 at 10:37:19AM -0500, Rob Clark wrote: On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote: I'll also need to update the new bridge in the msm edp code.. although that isn't such a big deal if I knew how this was *supposed* to work.. since what is

Re: [PATCH v5 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs

On Wed, Jan 14, 2015 at 04:46:03PM +0100, Alexandre Belloni wrote: Hi, This patch set hasn't moved since while. We actually need patch 4 to properly configure prefetch on sama5d4. What would be needed to come to an agreement ? What do you mean hasn't moved since a while - there has been

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Tue, Dec 23, 2014 at 12:00:00PM +0100, Marek Szyprowski wrote: I hope I did it right: https://lkml.org/lkml/2014/12/23/158 Please test, because I have no access to Omap hardware. Patch 1/8 looks like I'd expect it to. Nishanth, please test with your failing scenario, thanks. -- FTTC

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote: On 2014-12-11 10:29, Russell King - ARM Linux wrote: On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: I assume that now it won't be possible to get l2c patches back to -next, so I will resend them (again

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Mon, Dec 22, 2014 at 11:12:42AM -0600, Nishanth Menon wrote: On Mon, Dec 22, 2014 at 11:04 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: That only leaves the non-DT stuff to worry about this, and from what I understand, that's going to be removed soon. If we're going to keep

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: I assume that now it won't be possible to get l2c patches back to -next, so I will resend them (again...) with the omap related fix. What, you mean you don't know the fundamental rules of kernel development? No one should ever

Re: [RFC 04/15] regulator: add restrack support

On Thu, Dec 11, 2014 at 12:58:37PM +, Mark Brown wrote: I'd expect someone reading the change in the regulator API to have at least some idea how this fits in with the rest of the API and how to use it, and probably more importantly I'd expect to be able to understand why this is DT only.

Re: [RFC 00/15] Resource tracking/allocation framework

On Wed, Dec 10, 2014 at 04:48:18PM +0100, Andrzej Hajda wrote: 3. There are drivers which can work without specific resource, but if the resource becomes available/unavailable it can do some additional stuff. An example of such driver is DRM driver (more precisely drm_connector) - it can

Re: [RFC 00/15] Resource tracking/allocation framework

On Wed, Dec 10, 2014 at 06:23:49PM +0100, A H wrote: 10 gru 2014 17:16 Russell King - ARM Linux li...@arm.linux.org.uk napisał(a): On Wed, Dec 10, 2014 at 04:48:18PM +0100, Andrzej Hajda wrote: 3. There are drivers which can work without specific resource, but if the resource becomes

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have

Re: [PATCH] dmaengine: pl330: Set residue in tx_status callback

On Mon, Dec 08, 2014 at 06:37:27PM +0530, Vinod Koul wrote: I actually like the split model, you can also prepare txn ahead of time and submit them when needed. Actually, you can't - that's not permitted. I have email(s) from Dan explicitly stating that it is permitted for a driver to take a

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Mon, Dec 08, 2014 at 07:54:08AM -0600, Nishanth Menon wrote: On 12/08/2014 06:22 AM, Russell King - ARM Linux wrote: On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: Given where we are in the cycle

Re: [PATCH] dmaengine: pl330: Set residue in tx_status callback

On Wed, Dec 03, 2014 at 01:21:37PM +0530, Jassi Brar wrote: because the reasoning above seems incorrect considering the following documentation... Documentation/crypto/async-tx-api.txt says async-tx-api is not the DMA slave API. Once a

Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)

On Fri, Dec 05, 2014 at 10:13:51AM -0600, Nishanth Menon wrote: On 12/05/2014 10:10 AM, Nishanth Menon wrote: Case #2: Reverting the following allows boot. From next-20141204 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings revert this - boot still fails

Re: [PATCH v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs

On Fri, Nov 28, 2014 at 12:11:38PM +0100, Arnd Bergmann wrote: I'm fine with it either way. Russell, if you like you can merge http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung v3.19-next/pm-samsung-2 It'd be nicer to have a git URL for it. -- FTTC broadband for 0.8mile

Re: [PATCH RFT 2/2] arm: dts: disable CCI on exynos420 based arndale-octa

On Mon, Dec 01, 2014 at 10:03:28AM +0100, Krzysztof Kozlowski wrote: On pią, 2014-11-28 at 21:09 +0530, Abhilash Kesavan wrote: Hello Krzysztof, On Fri, Nov 28, 2014 at 8:49 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On pią, 2014-11-28 at 20:20 +0530, Abhilash Kesavan

Re: [PATCHv3 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

On Fri, Nov 28, 2014 at 10:53:30AM -0400, Eduardo Valentin wrote: diff --git a/drivers/thermal/samsung/exynos_thermal_common.c b/drivers/thermal/samsung/exynos_thermal_common.c index 3f5ad25..d4eaa1b 100644 --- a/drivers/thermal/samsung/exynos_thermal_common.c +++

Re: [PATCH v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs

On Mon, Nov 17, 2014 at 12:48:22PM +0100, Marek Szyprowski wrote: This is an updated patchset, which intends to add support for L2 cache on Exynos4 SoCs on boards running under secure firmware, which requires certain initialization steps to be done with help of firmware, as selected registers

Re: [PATCH v3 2/5] drivers: soc: Add support for Exynos PMU driver

On Thu, Nov 20, 2014 at 11:09:25AM +0530, Amit Daniel Kachhap wrote: diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d..44d220d 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM) += qcom/

Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes

On Mon, Nov 17, 2014 at 04:19:10PM +0100, Ulf Hansson wrote: The amba bus, amba drivers and a vast amount of platform drivers which enables runtime PM, don't invoke a pm_runtime_get_sync() while probing their devices. Instead, once they have turned on their PM resourses during -probe() and

Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes

On Mon, Nov 17, 2014 at 06:54:44PM +0200, Grygorii Strashko wrote: I'd be very appreciated if you would be able to clarify one point to me as I'm not familiar with amba hw? I've found at least 2 AMBA drivers where secondary clock is used to enable/disable device in addition to apb_pclk: -

Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

On Thu, Oct 30, 2014 at 11:01:02AM +0100, Andrzej Hajda wrote: On 10/29/2014 10:14 AM, Thierry Reding wrote: On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote: I think we nee try_get_module for the code and kref on the actual data structures. Agreed, that should do the

Re: [PATCH v6 4/7] ARM: l2c: Add support for overriding prefetch settings

On Mon, Oct 27, 2014 at 12:19:34PM +0100, Marek Szyprowski wrote: Hello, On 2014-10-27 12:14, Russell King - ARM Linux wrote: On Mon, Oct 27, 2014 at 12:05:47PM +0100, Marek Szyprowski wrote: From: Tomasz Figa t.f...@samsung.com Firmware on certain boards (e.g. ODROID-U3) can leave

Re: [PATCH v6 4/7] ARM: l2c: Add support for overriding prefetch settings

On Mon, Oct 27, 2014 at 12:05:47PM +0100, Marek Szyprowski wrote: From: Tomasz Figa t.f...@samsung.com Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch settings configured in registers leading to crashes if L2C is enabled without overriding them. This patch

Re: [PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge

On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote: Looking at the of_drm_find_panel function I actually wonder how that works - the drm_panel doesn't really need to stick around afaics. After all panel_list is global so some other driver can unload. Russell's of support for

Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote: [1.] One line summary of the problem: BUG: sleeping function called from invalid context at mm/slub.c:1250 after CPU hotplug I'm really not surprised. When SoC have MCT_INT_SPI interrupt it is being allocated after hotplugging

Re: [PATCH] drm/exynos: fix vblank handling during dpms off

On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote: But there might be another issue, which is that calls to drm_vblank_get() will return -EINVAL if invoked between drm_blank_off and drm_blank_on. Is this really the desired behavior? Can it at least happen? If so, how are

Re: [PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers

On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote: On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda a.ha...@samsung.com wrote: But this is an issue closely connected with component framework. Component framework separates master component probe and drm device initialization. As a

Re: [PATCH v5 4/7] ARM: l2c: Add support for overriding prefetch settings

On Wed, Sep 24, 2014 at 01:10:51PM +0100, Mark Rutland wrote: On Wed, Sep 24, 2014 at 12:19:45PM +0100, Tomasz Figa wrote: On 24.09.2014 13:14, Mark Rutland wrote: I'm not too keen on tristate properties. Is this level of flexibility really required? I would say that we need a way to

Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings

On Fri, Sep 19, 2014 at 08:30:07PM +0200, Alexandre Belloni wrote: On 19/09/2014 at 17:39:32 +0100, Russell King - ARM Linux wrote : On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : Firmware on certain boards (e.g

Re: [PATCH v4 4/7] ARM: l2c: Add support for overriding prefetch settings

On Fri, Sep 19, 2014 at 11:50:01AM +0200, Alexandre Belloni wrote: On 26/08/2014 at 16:17:57 +0200, Tomasz Figa wrote : Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch settings configured in registers leading to crashes if L2C is enabled without overriding them.

Re: Exynos build failure in -next allmodconfig

On Tue, Sep 16, 2014 at 01:44:44PM +0200, Krzysztof Kozłowski wrote: On 15.09.2014 19:57, Russell King - ARM Linux wrote: On Mon, Sep 15, 2014 at 09:34:58AM -0700, Mark Brown wrote: On Mon, Sep 15, 2014 at 11:57:09AM +0100, Build bot for Mark Brown wrote: Today's -next got a build failure

Re: [PATCH v4 5/7] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310

On Tue, Aug 26, 2014 at 04:17:58PM +0200, Tomasz Figa wrote: Exynos4 SoCs equipped with an L2C-310 cache controller and running under secure firmware require certain registers of aforementioned IP to be accessed only from secure mode. This means that SMC calls are required for certain register

Re: [PATCH v4 6/7] ARM: EXYNOS: Add support for non-secure L2X0 resume

On Tue, Aug 26, 2014 at 04:17:59PM +0200, Tomasz Figa wrote: On Exynos SoCs it is necessary to resume operation of L2C early in assembly code, because otherwise certain systems will crash. This patch adds necessary code to non-secure resume handler. Signed-off-by: Tomasz Figa

Re: Exynos build failure in -next allmodconfig

On Mon, Sep 15, 2014 at 09:34:58AM -0700, Mark Brown wrote: On Mon, Sep 15, 2014 at 11:57:09AM +0100, Build bot for Mark Brown wrote: Today's -next got a build failure in ARM allmodconfig due to platsmp.c: | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in return

Re: [PATCH v11 11/19] irqchip: vic: Add support for FIQ management

On Tue, Sep 02, 2014 at 02:00:45PM +0100, Daniel Thompson wrote: diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index bda5a91..8821160 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -502,13 +502,17 @@ static void __init gic_init_fiq(struct

Re: [PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2

On Mon, Jul 14, 2014 at 04:43:59PM +0200, Bartlomiej Zolnierkiewicz wrote: Fix building of exynos_defconfig with disabled CONFIG_PM_SLEEP by adding checking whether Exynos cpuidle support is enabled before accessing exynos_enter_aftr. The build error message:

Re: [PATCH v3 1/7] ARM: l2c: Refactor the driver to use commit-like interface

On Thu, Jul 17, 2014 at 06:38:56PM +0200, Tomasz Figa wrote: Certain implementations of secure hypervisors (namely the one found on Samsung Exynos-based boards) do not provide access to individual L2C registers. This makes the .write_sec()-based interface insufficient and provoking ugly hacks.

Re: [PATCH] ARM: config: update multi_v7_defconfig

On Fri, Jul 18, 2014 at 12:31:48AM +0200, Javier Martinez Canillas wrote: In the case of the MAX77686, the mfd, regulator and clock drivers use subsys_initcall() instead of module_init() but I wonder which of these really need to be initialized at subsys init call time and which one can just

Re: [PATCH 0/2] cpuidle fixes and cleanup

On Tue, Jul 08, 2014 at 03:56:48PM +0200, Tomasz Figa wrote: On 02.07.2014 05:11, Chander Kashyap wrote: On Tue, Jul 1, 2014 at 8:22 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote: This patch series fixes

Re: ABBA deadlock in Common Clock Framework

On Wed, Jul 02, 2014 at 12:59:04PM +0200, Tomasz Figa wrote: Hi All, While testing linux-next (next-20140625) on Exynos4412-based TRATS2 board, from time to time I hit a deadlock between clk_disable_unused() of Common Clock Framework and parallel clk_prepare() from s3c24xx-i2c driver. This

Re: [PATCH 0/2] cpuidle fixes and cleanup

On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote: This patch series fixes the cpuidle for different states. Also removes arm diagnostic and power register save/restore code as it is made generic. Based on: ARM: save/restore diagnostic register on Cortex-A9 suspend/resume

Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote: Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than

Re: [PATCH v5 05/14] clk: Add generic driver for Maxim PMIC clocks

On Mon, Jun 30, 2014 at 12:58:57PM +0200, Javier Martinez Canillas wrote: + if (!max_gen-lookup) + return ERR_PTR(-ENOMEM); + + max_gen-lookup-con_id = hw-init-name; Also IMO, init-name should be over-written if name is provided in DT, otherwise generic

Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)

On Fri, Jun 27, 2014 at 02:09:58AM -0700, Laura Abbott wrote: On 6/26/2014 8:06 PM, Tushar Behera wrote: arm_add_memory is getting called before this is being set, resulting in none of the memory banks getting added[1]. setup_machine_fdt - early_init_dt_scan - early_init_dt_scan_memory

Re: [PATCH v3 2/4] drm: Constify struct drm_fb_helper_funcs

On Fri, Jun 27, 2014 at 05:19:23PM +0200, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com There's no need for this to be modifiable. Make it const so that it can be put into the .rodata section. Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Thierry Reding

Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs

On Thu, Jun 26, 2014 at 01:24:32PM +0200, Tomasz Figa wrote: Current Samsung UART driver relies on probe order of particular samsung-uart instances, which makes it impossible to get proper initialization of ports when not all ports are available on board, not even saying of deterministic

Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)

On Thu, Jun 26, 2014 at 07:59:19AM -0700, Kevin Hilman wrote: I agree that the u-boot bug needs to be fixed, and FWIW, I updated my u-boot and haven't seen the boot failure yet after several boots with next-20140625. That being said, since it's not always feasible/practical to update

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

On Wed, Jun 25, 2014 at 10:30:46AM +0530, Abhilash Kesavan wrote: I see that you have sent a patch out that ensures both part and implementor number are checked. Currently, my patch has been applied to the fixes branch of the arm-soc tree and I wanted to know how to proceed (without it there

Re: [PATCH 1/1] ARM: Kconfig.debug: Update Samsung UART config options

On Wed, Jun 25, 2014 at 08:41:13PM +0900, Kukjin Kim wrote: Sachin Kamat wrote: + Russell In a multiplatform config, the low level debug option shows several UART port entries. Improve the user visible string so that it becomes clear to the user about Samsung UART ports. While at it

Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs

On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: This series intends to add support for L2 cache on Exynos4 SoCs on boards running under secure firmware, which requires certain initialization steps to be done with help of firmware, as selected registers are writable only from

Re: [PATCH v2 0/6] Enable L2 cache support on Exynos4210/4x12 SoCs

On Wed, Jun 25, 2014 at 04:13:16PM +0200, Tomasz Figa wrote: On 25.06.2014 15:50, Russell King - ARM Linux wrote: On Wed, Jun 25, 2014 at 03:37:25PM +0200, Tomasz Figa wrote: This series intends to add support for L2 cache on Exynos4 SoCs on boards running under secure firmware, which

Re: [PATCH 2/2] ARM: EXYNOS: Add support for firmware-assisted suspend/resume

On Wed, Jun 25, 2014 at 06:18:34PM +0200, Tomasz Figa wrote: +static int exynos_suspend(void) +{ + /* Save Power control and Diagnostic registers */ + asm (mrc p15, 0, %0, c15, c0, 0\n + mrc p15, 0, %1, c15, c0, 1\n + : =r (cp15_power), =r (cp15_diag) : : cc);

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote: Hi Kukjin, On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com wrote: Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Do you have any comments on this patch ? I do. diff --git

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

On Tue, Jun 24, 2014 at 05:11:14PM +0100, Russell King - ARM Linux wrote: Another point: exynos have taken it upon themselves to add code which saves various ARM core registers. This is a bad idea, it brings us back to the days where every platform did their own suspend implementations. CPU

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

On Tue, Jun 24, 2014 at 06:20:56PM +0200, Tomasz Figa wrote: Hi Russell, On 24.06.2014 18:11, Russell King - ARM Linux wrote: On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote: Hi Kukjin, On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com wrote

Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC

On Tue, Jun 24, 2014 at 07:16:47PM +0200, Tomasz Figa wrote: I tend to disagree. The chance of a new Cortex A9 based SoC with different implementor code showing up is so close to zero that I don't see increasing of code complexity by adding yet another check justified. That's your opinion

Re: Problems booting exynos5420 with 1 CPU

On Sun, Jun 08, 2014 at 01:45:30PM +0100, Lorenzo Pieralisi wrote: Olof, it is not puritanism, it is all about upstreaming code. If we keep accepting these hacks and we end up with mach code full of them we have a problem, do you agree ? To see the kind of problem that accepting hacked up code

Re: Problems booting exynos5420 with 1 CPU

On Sun, Jun 08, 2014 at 02:26:43PM -0400, Nicolas Pitre wrote: On Sun, 8 Jun 2014, Russell King - ARM Linux wrote: On Sat, Jun 07, 2014 at 04:53:34PM -0700, Olof Johansson wrote: You do realize that you have absolutely zero leverage over us on this, right? Our product is already shipped

Re: Problems booting exynos5420 with 1 CPU

On Sun, Jun 08, 2014 at 02:55:03PM -0400, Nicolas Pitre wrote: On Sun, 8 Jun 2014, Russell King - ARM Linux wrote: No, I was specifically thinking about the various iPAQ specific things like the additional platform specific ATAGs that they invented with zero reference to mainline

Re: Problems booting exynos5420 with 1 CPU

On Sat, Jun 07, 2014 at 04:53:34PM -0700, Olof Johansson wrote: You do realize that you have absolutely zero leverage over us on this, right? Our product is already shipped with kernel code that fixes this. That is never a justification for forcing /any/ code into the kernel. We've been here

Re: Problems booting exynos5420 with 1 CPU

On Fri, Jun 06, 2014 at 01:49:11PM -0700, Doug Anderson wrote: This works and IMHO is much cleaner because it totally removes the U-Boot dependency. I'll cleanup to not be so insane and post: diff --git a/arch/arm/mach-exynos/mcpm-exynos.c b/arch/arm/mach-exynos/mcpm-exynos.c index

Exynos induced build error with recent arm-soc

Spotted with a randconfig today: arch/arm/mach-exynos/built-in.o: In function `exynos_set_cpu_boot_addr': pm_domains.c:(.text+0x19c): undefined reference to `sysram_ns_base_addr' arch/arm/mach-exynos/built-in.o:(.data+0x94): undefined reference to `exynos_enter_aftr' This should be fixed before

Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote: 2. You replace calls of component_add and component_del with calls to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT, specific_component_ops), or interface_tracker_ifdown. Thats all for components. How does the

  1   2   3   4   5   >