On Sat, Aug 03, 2013 at 12:43:21PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 31, 2013 at 08:18:06AM +0200, Jean-Francois Moine wrote:
> > To avoid the declaration of a 'kirkwood-pcm-audio' device in the DT,
> > this patch merges the kirkwood-i2c and kirk
On Wed, Jul 31, 2013 at 08:17:39AM +0200, Jean-Francois Moine wrote:
> @@ -519,30 +532,17 @@ static int kirkwood_i2s_dev_probe(struct
> platform_device *pdev)
>
> err = snd_soc_register_component(&pdev->dev, &kirkwood_i2s_component,
>soc_dai, 1);
> -
On Wed, Jul 31, 2013 at 08:17:39AM +0200, Jean-Francois Moine wrote:
> The function kirkwood_i2s_dev_remove() may be used when probe fails.
Looking at this deeper, I'm not happy with this.
> +static int kirkwood_i2s_dev_remove(struct platform_device *pdev)
> +{
> + struct kirkwood_dma_data *p
On Wed, Jul 31, 2013 at 08:18:58AM +0200, Jean-Francois Moine wrote:
> diff --git a/sound/soc/kirkwood/kirkwood-i2s.c
> b/sound/soc/kirkwood/kirkwood-i2s.c
> index 9844010..4f817a2 100644
> --- a/sound/soc/kirkwood/kirkwood-i2s.c
> +++ b/sound/soc/kirkwood/kirkwood-i2s.c
> @@ -25,7 +25,7 @@
>
>
On Wed, Jul 31, 2013 at 08:18:32AM +0200, Jean-Francois Moine wrote:
> The kirkwood audio driver is used without DT in the Kirkwood machine.
> This patch adds a DT compatible definition for use in other Marvell
> machines such as the Armada 88AP510 (Dove).
>
> Signed-off-by: Jean-Francois Moine
>
On Sat, Aug 03, 2013 at 05:55:13PM +0200, Jean-Francois Moine wrote:
> On Sat, 3 Aug 2013 13:39:54 +0100
> Russell King - ARM Linux wrote:
>
> > This doesn't apply to mainline as there's a clk_put() there.
>
> Right, it applies to linux-next:
>
> On Fri, 2
On Wed, Jul 31, 2013 at 08:18:06AM +0200, Jean-Francois Moine wrote:
> To avoid the declaration of a 'kirkwood-pcm-audio' device in the DT,
> this patch merges the kirkwood-i2c and kirkwood-dma drivers into one
> module associated with 'kirkwood-i2s'.
I suggest holding off on this stuff at the mo
On Sat, Aug 03, 2013 at 01:07:31AM +0100, Russell King - ARM Linux wrote:
> I'll look into that. Obviously, I never build nommu because it isn't
> part of the build system and the nommu platform I do have - OKI67001 -
> doesn't have mainline kernel support. (And if it d
On Sun, Aug 04, 2013 at 11:20:21AM -0700, Olof Johansson wrote:
> On Sun, Aug 4, 2013 at 5:53 AM, Russell King - ARM Linux
> wrote:
> > On Sat, Aug 03, 2013 at 01:07:31AM +0100, Russell King - ARM Linux wrote:
> >> I'll look into that. Obviously, I never build nommu bec
On Sun, Aug 04, 2013 at 11:47:04AM -0700, Olof Johansson wrote:
> On Sun, Aug 4, 2013 at 11:37 AM, Russell King - ARM Linux
> wrote:
> > On Sun, Aug 04, 2013 at 11:20:21AM -0700, Olof Johansson wrote:
> >> On Sun, Aug 4, 2013 at 5:53 AM, Russell King - ARM Linux
> >>
On Tue, Aug 20, 2013 at 11:20:06AM +0200, Sebastian Hesselbarth wrote:
> Yeah, I am having troubles with linux-arm-kernel rejecting my mails
> because of a suspicious header. I have no clue, what has changed lately
> with my mails sent by git send-email to make them get stuck.
I believe David feel
On Tue, Aug 20, 2013 at 12:37:18PM +0200, Sebastian Hesselbarth wrote:
> I already guessed it has something to do with the In-reply-to line, as
> only the patches but not the cover letter gets stuck. Thanks for
> pointing me at the missing PATCH prefix and sorry for the noise on
> the moderators sc
On Tue, Aug 20, 2013 at 07:34:20PM +0200, Sylwester Nawrocki wrote:
> +int __clk_get(struct clk *clk)
> +{
> + if (WARN_ON((!clk)))
> + return 0;
This changes the behaviour of clk_get()
> +
> + if (!try_module_get(clk->owner))
> + return 0;
If you want this to be
On Tue, Aug 20, 2013 at 07:34:23PM +0200, Sylwester Nawrocki wrote:
> There is currently a race condition in the device tree part of clk_get()
> function, since the pointer returned from of_clk_get_by_name() may become
> invalid before __clk_get() call. I.e. due to the clock provider driver
> remov
On Tue, Aug 20, 2013 at 07:34:22PM +0200, Sylwester Nawrocki wrote:
> Add helper functions for the of_clk_providers list locking and
> an unlocked variant of of_clk_get_from_provider().
> These functions are intended to be used in the clkdev to avoid
> race condition in the device tree based clock
On Tue, Aug 20, 2013 at 03:50:08PM -0700, Kamal Mostafa wrote:
> On Mon, 2013-08-19 at 17:07 +0100, Russell King - ARM Linux wrote:
> > On Mon, Aug 19, 2013 at 09:02:23AM -0700, Kamal Mostafa wrote:
> > > Thanks Aaro. I'll apply "2ba85e7 ARM: Fix FIQ code on VI
On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> > > To use ARM as an example, the bugs I've seen have mostly b
On Wed, Aug 21, 2013 at 11:43:55AM -0400, Dave Jones wrote:
> On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
> > I've been running several iterations of it for a while (== up to 10 minutes
> > run time - which is normally about how long it takes t
On Wed, Aug 21, 2013 at 08:26:46PM +0200, Jean-Francois Moine wrote:
> On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
> > From: Russell King
> >
> > The video-input-port (VIP) is highly configurable. This prepares
> > current driver to allow to configure VIP configuration, as some
On Wed, Aug 21, 2013 at 08:33:55PM +0200, Jean-Francois Moine wrote:
> On Wed Aug 14 12:43:30 PDT 2013, Sebastian Hesselbarth wrote:
> > +static void
> > +reg_write_range(struct drm_encoder *encoder, uint16_t reg, uint8_t *p, int
> > cnt)
> > +{
> > + struct i2c_client *client = drm_i2c_encoder_
On Thu, Aug 22, 2013 at 08:53:13AM +0200, Jean-Francois Moine wrote:
> On Wed, 21 Aug 2013 23:36:05 +0100
> Russell King - ARM Linux wrote:
>
> > > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is
> > > no need to set t
On Thu, Aug 22, 2013 at 07:33:43AM -0400, Rob Clark wrote:
> On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine wrote:
> > On Wed, 21 Aug 2013 23:36:05 +0100
> > Russell King - ARM Linux wrote:
> >
> >> > AFAIK, the TI boards have no "pin-swapped", no
I'm not sure why you're sending this to ARM people as I don't believe we
are the ones responsible for this breakage, neither have we had any
visibility of this breakage coming up.
>From what I can see, the mainline state is that we reference user_exit
when CONTEXT_TRACKING is enabled, and kernel/c
On Fri, Aug 23, 2013 at 12:51:59AM -0400, Nicolas Pitre wrote:
> Blah. OK then, just send it to Thomas.
>
> Initially this code was written and committed by RMK which is why I
> suggested you send him the fix.
It _should_, because the author of the file presumably knows how the
driver is suppos
On Fri, Aug 23, 2013 at 05:03:45PM +0200, Sylwester Nawrocki wrote:
> This patch adds common __clk_get(), __clk_put() clkdev helpers which
> replace their platform specific counterparts when the common clock
> API is enabled.
>
> The owner module pointer field is added to struct clk so a reference
On Mon, Aug 05, 2013 at 05:43:47PM -0500, Rob Herring wrote:
> On Thu, Aug 1, 2013 at 5:20 PM, Russell King
> wrote:
> > We need to start treating DMA masks as something which is specific to
> > the bus that the device resides on, otherwise we're going to hit all
> > sorts of nasty issues with LPA
On Mon, Aug 05, 2013 at 10:15:11PM -0500, Rob Herring wrote:
> On Thu, Aug 1, 2013 at 5:25 PM, Santosh Shilimkar
> wrote:
> > +/* The ARM override for dma_max_pfn() */
> > +static inline unsigned long dma_max_pfn(struct device *dev)
> > +{
> > + return PHYS_PFN_OFFSET + dma_to_pfn(dev, *dev-
On Tue, Aug 06, 2013 at 06:15:27PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote:
> > What would it take to move all this into driver core?
>
> What specifically would you move into there?
A variable to hold the streaming dma_mask, so that it
On Wed, Aug 07, 2013 at 03:47:40PM +0800, Bo Shen wrote:
> correct the comparison parameter of MHz from 4,000,000 to 1,000,000
You're assuming this wasn't intentional. As the division by 100
ends up losing the fractional rate, I decided to leave 1-4MHz as kHz,
so something like 1.832MHz would
On Wed, Aug 07, 2013 at 02:57:00PM +0900, Greg Kroah-Hartman wrote:
> On Tue, Aug 06, 2013 at 11:19:14AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Aug 06, 2013 at 06:15:27PM +0800, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pante
On Tue, Aug 06, 2013 at 11:34:35PM +0200, Mathias Krause wrote:
> Commit a5463cd3 "ARM: make vectors page inaccessible from userspace"
> introduced a typo making arch_vma_name() always return "[vectors]".
> Fix up that regression (of the hush-hush security fix).
And if you search the list archives
On Thu, Jul 18, 2013 at 05:15:21PM +0100, Julien Grall wrote:
> On 17 July 2013 14:25, Stefano Stabellini
> wrote:
> > On Mon, 15 Jul 2013, Julien Grall wrote:
> >> Even if uncompress debug is disabled, some board will continue to print
> >> information during uncompress step.
> >
> > Are you talk
On Thu, Jul 18, 2013 at 05:43:37PM +0100, Julien Grall wrote:
> When Xen will boot, it will use one UART, given by the user, to be able
> to log its information. Xen will not map the UART region and the IRQ to
> dom0. Of course it will not be present in the device tree either. So if
> Linux tries t
On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_
On Fri, Jul 19, 2013 at 10:20:19AM -0400, Nicolas Pitre wrote:
> On Fri, 19 Jul 2013, Will Deacon wrote:
>
> > Looks good to me. The current scheme would be very fiddly to extend to
> > 64-bit values on 32-bit architectures without cheap atomic doubleword
> > accesses.
>
> You should have a look
On Fri, Jul 19, 2013 at 02:58:41PM +0100, Lee Jones wrote:
> Cc: Kukjin Kim
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 2 +-
One question. What have all these files got to do with ux500 ?
--
To unsubscribe from this list: send
On Mon, Jul 22, 2013 at 11:58:47AM -0700, Stephen Boyd wrote:
> On 07/22/13 11:45, Stephen Boyd wrote:
> > Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
> > sched_clock_register() also causes the same crash.
>
> Yes that seems to be the problem. The vexpress board is settin
On Tue, Jul 23, 2013 at 10:23:20AM +0200, Jean-Francois Moine wrote:
> This patch enables S/PDIF.
>
> Signed-off-by: Jean-Francois Moine
I'm not submitting my patch to do this because:
(a) we don't know what effect this has on other hardware.
(b) Mark suggested that we use the slave PCM stuff t
On Tue, Jul 23, 2013 at 10:46:15AM +0200, Jean-Francois Moine wrote:
> The kirkwood i2s driver is used without DT in the Kirkwood machine.
> This patch adds a DT compatible definition for use in other Marvell
> machines as the Armada 88AP510 (Dove).
Yet again, this illustrates why converting to DT
On Tue, Jul 23, 2013 at 11:08:20AM +0200, Sascha Hauer wrote:
> On Tue, Jul 23, 2013 at 09:53:46AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 23, 2013 at 10:46:15AM +0200, Jean-Francois Moine wrote:
> > > The kirkwood i2s driver is used without DT in the Kirkwood m
On Tue, Jul 23, 2013 at 12:00:30PM +0930, Rusty Russell wrote:
> Michal Simek writes:
> > Let me take some code from virtio_rpmsg_bus.c to show that problematic part.
> >
> > bufs_va = dma_alloc_coherent(vdev->dev.parent->parent,
> > RPMSG_TOTAL_BUF_SPACE,
> >
On Tue, Jul 23, 2013 at 02:06:22PM +0100, Mark Brown wrote:
> On Tue, Jul 23, 2013 at 09:43:47AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Jul 23, 2013 at 10:23:20AM +0200, Jean-Francois Moine wrote:
> > > This patch enables S/PDIF.
>
> > > Signed-off-by: J
On Tue, Jul 23, 2013 at 01:57:56PM +0100, Mark Brown wrote:
> On Tue, Jul 23, 2013 at 10:46:41AM +0200, Jean-Francois Moine wrote:
>
> > +- compatible: "marvell,mvebu-pcm-audio"
> > +
> > +Example:
> > +
> > +pcm: pcm {
> > + compatible = "marvell,mvebu-pcm-audio";
> > +};
>
> This device has n
On Tue, Jul 23, 2013 at 03:12:56PM +0200, Sebastian Hesselbarth wrote:
> On 07/23/13 15:06, Mark Brown wrote:
>> On Tue, Jul 23, 2013 at 09:43:47AM +0100, Russell King - ARM Linux wrote:
>>> On Tue, Jul 23, 2013 at 10:23:20AM +0200, Jean-Francois Moine wrote:
>>>
On Tue, Jul 23, 2013 at 03:30:57PM +0200, Sebastian Hesselbarth wrote:
> On 07/23/13 15:20, Mark Brown wrote:
>>> again, we mentioned to merge kirkwood-i2s.c and kirkwood-dma.c into
>>> a single file, didn't we?
>>
>> That's been discussed several times but nobody's actually done it.
>
> Correct, t
On Tue, Jul 23, 2013 at 04:01:50PM +0100, Mark Brown wrote:
> On Tue, Jul 23, 2013 at 03:30:57PM +0200, Sebastian Hesselbarth wrote:
> > On 07/23/13 15:20, Mark Brown wrote:
>
> > >Why would this be required? The driver is already asking for multiple
> > >clocks...
>
> > The driver is asking for
On Wed, Jul 24, 2013 at 11:56:18AM -0700, Stephen Boyd wrote:
> On 07/09, Stephen Boyd wrote:
> > If one process calls sys_reboot and that process then stops other
> > CPUs while those CPUs are within a spin_lock() region we can
> > potentially encounter a deadlock scenario like below.
> >
> > CPU
On Thu, Jul 25, 2013 at 11:13:14AM +0200, Jean-Francois Moine wrote:
> In the kirkwood pcm/dma driver, the private stream related data pointer
> was hold in the platform drvdata.
> As this pointer may be used by other parts of the audio subsystem,
> this patch uses the substream runtime private dat
On Thu, Jul 25, 2013 at 08:16:04PM +0100, Mark Brown wrote:
> On Thu, Jul 25, 2013 at 11:14:28AM +0200, Jean-Francois Moine wrote:
> > To avoid the declaration of a 'kirkwood-pcm-audio' device in the DT,
> > this patch merges the kirkwood-i2c and kirkwood-dma drivers into one
> > module.
>
> This
On Thu, Jul 25, 2013 at 08:19:05PM +0100, Mark Brown wrote:
> On Thu, Jul 25, 2013 at 11:14:59AM +0200, Jean-Francois Moine wrote:
>
> > + if (np) {
> > + priv->burst = 128; /* might be 32 or 128 */
> > + } else if (data) {
>
> When you posted this before I queried how
On Thu, Jul 25, 2013 at 03:31:35PM -0400, Jason Cooper wrote:
> On Thu, Jul 25, 2013 at 02:11:31PM -0500, Rob Herring wrote:
> > On Thu, Jul 25, 2013 at 11:09 AM, Olof Johansson wrote:
>
> > > One problem that needs to be solved is obviously how a binding
> > > graduates from tentative to locked.
On Fri, Jul 26, 2013 at 11:09:13AM +0200, Jean-Francois Moine wrote:
> The A510 documentation uses the names "DCO PLL" for the internal clock
> and "AU_EXTCLK" for the external clock. So, what about "dcopll" and
> "extclk"?
Stop naming them according to their source. Their _consumer_ names
not _s
On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
> > On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
> > > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
> > > >
> > > > We use DT has a k
On Fri, Jul 26, 2013 at 09:27:09AM -0400, Jason Cooper wrote:
> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
> > Unless I totally misunderstood, the thread is talking about letting
> > established bindings change with each new kernel version. I am
> > opposed to that.
> >
> >
On Fri, Jul 26, 2013 at 10:14:32AM -0400, jonsm...@gmail.com wrote:
> Yes, yes - that's why the schema should be written down and used as a
> validation input to dtc. Then dtc can spit out errors for non-standard
> items. There would be two versions - the standard one and a legacy one
> that includ
On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote:
> The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
> on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
> PFNs but that breaks the dma_mask for few block layer drivers since
> ARM start of p
ayback. There are those which
have I2S capture and playback, and SPDIF playback. There are those which
have both I2S and SPDIF for both capture and playback. The only one I
haven't yet seen is SPDIF capture without playback.
> On Fri, 26 Jul 2013 10:21:56 +0100 Russell King - ARM Linux
&
On Fri, Aug 09, 2013 at 11:12:36AM +0200, Krzysztof Hałasa wrote:
> Hi,
>
> I'm trying to understand why the struct device contains a pointer to
> dma_mask and not the actual dma_mask:
>
> struct device {
> ...
>
> u64 *dma_mask; /* dma mask (if dma'able device)
On Fri, Aug 09, 2013 at 11:34:30AM +0200, Sebastian Hesselbarth wrote:
> Mark,
>
> I do understand there may be SoCs requiring sophisticated extra audio
> nodes, but Marvell SoCs don't. I prefer having a single node for the
> i2s controller *and* exploit the audio subsystem properties from that.
>
On Fri, Aug 09, 2013 at 12:34:11PM +0200, Krzysztof Hałasa wrote:
> Russell King - ARM Linux writes:
>
> >> struct device {
> >> ...
> >>
> >> u64 *dma_
On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
> So extend Morimoto-san's work on the simple card for this - that's what
> it's there for, it's doing exactly this job for non-DT systems but it
> just didn't get DT support added yet. All the trivial cards should end
> up using this.
I
On Fri, Aug 09, 2013 at 07:00:58PM +0100, Mark Brown wrote:
> On Fri, Aug 09, 2013 at 02:09:32PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 09, 2013 at 12:39:40PM +0100, Mark Brown wrote:
>
> > > So extend Morimoto-san's work on the simple card for this - th
On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
> If someone wants to it should also be possible to convert the existing
> platforms without S/PDIF support over to DT, providing you don't mind
> changing the code once the DPCM and S/PDIF support is added and a bit of
> thought is put in
On Sat, Aug 10, 2013 at 12:42:09AM +0100, Mark Brown wrote:
> On Fri, Aug 09, 2013 at 09:38:47PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 09, 2013 at 08:44:34PM +0100, Mark Brown wrote:
>
> > > If someone wants to it should also be possible to convert the exi
On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote:
> Hi,
>
> trying to boot arm versatile images with qemu results in the following error
> if I try to boot with a disk image.
>
> sym0: <895a> rev 0x0 at pci :00:0d.0 irq 92
> sym0: SCSI BUS has been reset.
> scsi0 : s
On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote:
> On 12 August 2013 01:40, Guenter Roeck wrote:
> > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote:
> >> It could be that it's qemu's PCI routing is wrong - it's not the first
> >&
On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote:
> /* Slot to IRQ mapping for RealView EB and PB1176 backplane
> * nameslotIntAIntBIntCIntD
> * A 31 IRQ50 IRQ51 IRQ48 IRQ49
> * B 30 IRQ49 IRQ50 IRQ51
On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote:
> On 12 August 2013 21:06, Russell King - ARM Linux
> wrote:
> > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote:
> >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane
> >>
On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote:
> On this point, yes. Equivalent bit from the PB926 TRM:
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html
>
> (There are differences between the PCI controllers on
> the different boards. Differences I know of
On Tue, Aug 13, 2013 at 03:37:31AM -0500, Rob Landley wrote:
> Because working with old and new qemu, like it used to before everybody
> fiddled with it to not actually match hardware nobody _has_, is
> definitely not an interesting goal.
It appears that people *do* have the hardware.
What is
On Tue, Aug 13, 2013 at 09:42:27PM +0300, Pantelis Antoniou wrote:
> But creation just crashes.
>
> > root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c >bind
> >
> > [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual
> > address 0001
> > [ 145.
On Tue, Aug 13, 2013 at 09:59:03PM +0300, Pantelis Antoniou wrote:
> Hi Greg,
>
> Just to make sure we're on the same page this is with my platform device
> removal patchset applied.
>
> Without it you get the original crash I've posted in the pdevtest patch with
> the unbind method.
Yes, congra
On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> Hacked diff is below. Can I write that up as clean patch and submit it,
> or do we need a test on real hardware ?
Well, if we want to ensure that it is really correct, the sensible thing
to do is to try it on real hardware, otherwise
On Thu, Aug 01, 2013 at 10:34:20PM +0100, Russell King - ARM Linux wrote:
> So, this patch set is a preview of the DMA mask changes which I currently
> have in my tree.
Looking at the comments which this patch set has received, I see very
little in the way of feedback. So I think it
On Tue, Aug 06, 2013 at 12:20:12AM +0200, Sebastian Hesselbarth wrote:
> switch (mode) {
> case DRM_MODE_DPMS_ON:
> + /* Write the default value MUX register */
> + reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
This looks like an old version of my patch. I ende
On Tue, Aug 06, 2013 at 12:20:11AM +0200, Sebastian Hesselbarth wrote:
> From: Russell King
>
> TDA19988 devices need their RAM enabled in order to read EDID
> information. Add support for this.
>
> Signed-off-by: Russell King
> Tested-by: Sebastian Hesselbarth
There was some debate about wh
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> - also calculate CTS
This is wrong...
> + /*
> + * HDMI 1.3a, 7.2.2 CTS parameter:
> + * (avg cts) = (fTMDS * N) / (128 * fS)
> + */
> + cts = n * mode->clock / p->audio_sample_rate;
> + cts *= 10
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
> + hs_pix_e = hs_pix_s + mode->hsync_end - mode->hsync_s
Last nights automated ARM build found the following errors with randconfig.
All information as usual at http://www.arm.linux.org.uk/developer/build/
Versatile randconfig:
ERROR: "irq_domain_add_simple" [drivers/gpio/gpio-em.ko] undefined!
OMAP4430 randconfig:
drivers/gpu/drm/tilcdc/tilcdc_sla
On Mon, Mar 04, 2013 at 04:39:16PM +0800, Andrew Cooks wrote:
> diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
> index 1879a59..1f706c4 100644
> --- a/drivers/dma/ioat/dma.c
> +++ b/drivers/dma/ioat/dma.c
> @@ -832,7 +832,18 @@ int ioat_dma_self_test(struct ioatdma_device *device)
>
On Tue, Mar 05, 2013 at 12:52:41PM +0800, Viresh Kumar wrote:
> +static void put_cluster_clk_and_freq_table(u32 cluster)
> +{
> + if (!atomic_dec_return(&cluster_usage[cluster])) {
> + clk_put(clk[cluster]);
> + clk[cluster] = NULL;
What's the point in setting the clk t
On Wed, May 08, 2013 at 09:36:13AM -0700, Greg KH wrote:
> On Wed, May 08, 2013 at 06:31:48PM +0200, Arnd Bergmann wrote:
> > On Wednesday 08 May 2013, Greg KH wrote:
> > > > just mention there is not hardware reason to not use the generic ttySx
> > > > in place of ttyAS as we have only one IP that
On Sat, May 11, 2013 at 06:57:26AM -0500, Robin Holt wrote:
> diff --git a/arch/arm/mach-ixp4xx/include/mach/timex.h
> b/arch/arm/mach-ixp4xx/include/mach/timex.h
> index c9e930f..729b2db 100644
> --- a/arch/arm/mach-ixp4xx/include/mach/timex.h
> +++ b/arch/arm/mach-ixp4xx/include/mach/timex.h
> @
On Sat, May 11, 2013 at 06:57:24AM -0500, Robin Holt wrote:
> These restart_mode fields are not used at all. Remove them to make
> moving the reboot= cmdline options to the general kernel easier.
Acked-by: Russell King
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sat, May 11, 2013 at 06:57:27AM -0500, Robin Holt wrote:
> Merge together the unicore32, arm, and x86 reboot= command line
> parameter handling.
>
> Signed-off-by: Robin Holt
> To: Andrew Morton
> Cc: H. Peter Anvin
> Cc: Russell King
> Cc: Guan Xuetao
> Cc: Russ Anderson
> Cc: Robin Holt
On Sat, May 11, 2013 at 06:57:16AM -0500, Robin Holt wrote:
> We recently noticed that reboot of a 1024 cpu machine takes approx 16
> minutes of just stopping the cpus. The slowdown was tracked to commit
> f96972f.
...
> Cc: Russell King
Looks good now. Acks supplied for relevant patches to ARM
On Sat, May 11, 2013 at 06:57:25AM -0500, Robin Holt wrote:
> This patch prepares for the moving the parsing of reboot= to the generic
> kernel code by making reboot_mode into a more generic form.
>
> Signed-off-by: Robin Holt
> To: Andrew Morton
> To: Russell King
> Cc: Russ Anderson
> Cc: Ro
Please, stop this idiotic incomprehensible jargon.
On Sat, May 11, 2013 at 08:47:28AM -0700, H. Peter Anvin wrote:
> By the way, do we really need Yoda programming here?
>
> Russell King - ARM Linux wrote:
>
> >On Sat, May 11, 2013 at 06:57:25AM -0500, Robin Holt wrot
On Sun, May 12, 2013 at 02:22:56PM +1000, Daniel Tang wrote:
> diff --git a/arch/arm/mach-nspire/clcd.c b/arch/arm/mach-nspire/clcd.c
> new file mode 100644
> index 000..a4b9f06
> --- /dev/null
> +++ b/arch/arm/mach-nspire/clcd.c
> @@ -0,0 +1,117 @@
> +/*
> + * linux/arch/arm/mach-nspire/clcd
On Tue, May 14, 2013 at 03:03:14PM -0600, Stephen Warren wrote:
> On 05/14/2013 01:15 AM, Jongsung Kim wrote:
> > Stephen Warren :
> >> For reference, the AMBA periphid of the UART device there is 0x00341011.
> >> The nibble "3" is the revision being tested in:
> >
> > The UART device has periphi
On Tue, May 14, 2013 at 10:59:58PM -0600, Stephen Warren wrote:
> Well, that certainly isn't true in practice. I think we should revert
> this commit until we can determine what the problem is.
>
> I validated that the periphid register in HW contains the r1p5 revision
> (3), and the pcellid regis
On Wed, May 15, 2013 at 03:16:52PM +0200, Arnd Bergmann wrote:
> > +static void moxart_idle(void)
> > +{
> > + /*
> > +* Because of broken hardware we have to enable interrupts or the CPU
> > +* will never wakeup... Acctualy it is not very good to enable
> > +* interrupts first since
On Thu, May 16, 2013 at 12:54:20AM +0200, Arnd Bergmann wrote:
> Ah, I see. I also read the mach-gemini version of the idle code,
> which is apparently the same thing as the code that was commented
> out here, so that has the wakeup race.
>
> Since it seems that WFI is broken on all fa526 cores, o
On Mon, Apr 08, 2013 at 09:11:04AM +0200, Peter Ujfalusi wrote:
> Russell,
>
> On 04/03/2013 01:17 PM, Peter Ujfalusi wrote:
> > cyclic DMA is only used by audio which needs DMA to be started without a
> > delay.
> > If the DMA for audio is started using the tasklet we experience random
> > channe
On Fri, Apr 05, 2013 at 06:45:33PM +0530, Sourav Poddar wrote:
> With dt boot, uart wakeup after suspend is non functional while using
> "no_console_suspend" in the bootargs. With "no_console_suspend" used, we
> should prevent the runtime suspend of the uart port which is getting used
> as an conso
On Mon, Mar 25, 2013 at 03:02:39PM +0100, Thomas Gleixner wrote:
> On Mon, 25 Mar 2013, Russell King - ARM Linux wrote:
>
> > On Mon, Mar 25, 2013 at 12:31:20PM +0100, Thomas Gleixner wrote:
> > > On Fri, 22 Mar 2013, Kevin Hilman wrote:
> > >
> > > > H
On Tue, Apr 09, 2013 at 11:20:31AM +0200, Thomas Gleixner wrote:
> On Mon, 8 Apr 2013, Russell King - ARM Linux wrote:
> > On Mon, Mar 25, 2013 at 03:02:39PM +0100, Thomas Gleixner wrote:
> > So, how can I review these changes when all there is is a git URL, and
> > I *do*
On Tue, Apr 09, 2013 at 11:21:24AM +0200, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Stephen Rothwell wrote:
> > After merging the final tree, today's linux-next build (arm defconfig)
> > produced these warnings:
> >
> > arch/arm/mach-cns3xxx/Kconfig:2:warning: choice value used outside its
On Tue, Apr 09, 2013 at 01:01:56PM +0100, Pawel Moll wrote:
> So I have PL111 code almost working here, however today it depends on
> not-yet-upstream (to my knowledge) generic/common panel/display
> framework. If I'm not disturbed again I may get something done this
> week, hopefully removing the
On Tue, Apr 09, 2013 at 09:21:40AM +0200, Peter Ujfalusi wrote:
> Russell,
>
> On 04/09/2013 09:19 AM, Peter Ujfalusi wrote:
> > On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
> >> Now that I'm back from a short 4 day break, then yes, and the answer i
501 - 600 of 4247 matches
Mail list logo
