* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Russell King - ARM Linux @ 2012-10-25 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025154202.41f3cbba@endymion.delvare>
On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 02:57:48PM +0200, Jean Delvare wrote:
> > > Hi Felipe, Shubhrajyoti,
> > >
> > > On Mon, 22 Oct 2012 12:46:57 +0300, Felipe Balbi wrote:
> > > > From: Shubhrajyoti D <shubhrajyoti@ti.com>
> > > >
> > > > In case of a NACK, it's wise to tell our clients
> > > > drivers about how many bytes were actually transferred.
> > > >
> > > > Support this by adding an extra field to the struct
> > > > i2c_msg which gets incremented the amount of bytes
> > > > actually transferred.
> > > >
> > > > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > > > ---
> > > > include/uapi/linux/i2c.h | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
> > > > index 0e949cb..4b35c9b 100644
> > > > --- a/include/uapi/linux/i2c.h
> > > > +++ b/include/uapi/linux/i2c.h
> > > > @@ -77,6 +77,7 @@ struct i2c_msg {
> > > > #define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */
> > > > #define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */
> > > > __u16 len; /* msg length */
> > > > + __u16 transferred; /* actual bytes transferred */
> > > > __u8 *buf; /* pointer to msg data */
> > > > };
> > >
> > > On the principle I am fine with this, however you also need to define
> > > who should initialize this field, and to what value.
> >
> > You also miss one very very very big point. This will break every I2C
> > using userspace program out there unless it is rebuilt - this change will
> > require the exact right version of those userspace programs for the
> > kernel that they're being used on.
>
> How that? The extra field is added in a hole, so we don't change the
> struct size nor the relative positions of existing fields. Why would
> user-space care?
You know the layout of that struct for certain across all Linux supported
architectures, including some of the more obscure ones which may not
require pointers to be aligned?
^ permalink raw reply
* [PATCH 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Mauro Carvalho Chehab @ 2012-10-25 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025113841.4e06cc3b@redhat.com>
Em Thu, 25 Oct 2012 11:38:41 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:
> Hi F?bio,
>
> Em Fri, 5 Oct 2012 18:53:01 -0300
> Fabio Estevam <fabio.estevam@freescale.com> escreveu:
>
> > During the clock conversion for mx27 the "per4_gate" clock was missed to get
> > registered as a dependency of mx2-camera driver.
> >
> > In the old mx27 clock driver we used to have:
> >
> > DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, &csi_clk1, &per4_clk);
> >
> > ,so does the same in the new clock driver.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> > arch/arm/mach-imx/clk-imx27.c | 1 +
>
> As this patch is for arch/arm, I'm understanding that it will be merged
> via arm tree. So,
>
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Forgot to comment: as patch 2 relies on this change, the better, IMHO, is
to send both via the same tree. If you decide to do so, please get arm
maintainer's ack, instead, and we can merge both via my tree.
>
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> > index 3b6b640..5ef0f08 100644
> > --- a/arch/arm/mach-imx/clk-imx27.c
> > +++ b/arch/arm/mach-imx/clk-imx27.c
> > @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
> > clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx-fb.0");
> > clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx-fb.0");
> > clk_register_clkdev(clk[csi_ahb_gate], "ahb", "mx2-camera.0");
> > + clk_register_clkdev(clk[per4_gate], "per", "mx2-camera.0");
> > clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
> > clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
> > clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
>
>
--
Regards,
Mauro
^ permalink raw reply
* [PATCH 1/2] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Arnd Bergmann @ 2012-10-25 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025134352.16a8ef81@skate>
On Thursday 25 October 2012, Thomas Petazzoni wrote:
> On Thu, 25 Oct 2012 11:27:36 +0000, Arnd Bergmann wrote:
> > On Wednesday 24 October 2012, Gregory CLEMENT wrote:
> > > For Armada 370/XP we have the same problem that for the commit
> > > cb01b63, so we applied the same solution: "The default 256 KiB
> > > coherent pool may be too small for some of the Kirkwood devices, so
> > > increase it to make sure that devices will be able to allocate their
> > > buffers with GFP_ATOMIC flag"
> > >
> > > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> > Do you know why the ATA driver needs this? I find it surprising that
> > it's necessary, so I'd like to make sure we're not just working around
> > a device driver bug here.
>
> The sata_mv driver create dma_pool and allocate objects from them, and
> all the memory allocated for dma_pools is allocated using
> dma_alloc_coherent(), and I guess the driver is using too much of them.
>
> Seems like the driver is too lazy and allocates everything coherent to
> avoid the hassle of doing dma_map/dma_unmap operations when needed, but
> I haven't looked in details at the driver yet to see if it would be
> possible to switch those DMA coherent allocations into non-coherent
> allocations + appropriate calls to the DMA operations.
Using coherent allocations is fine, I was wondering whether they need
to be atomic or not.
> That said, that's for sure a larger task than just enabling SATA on
> Armada 370/XP, so I would advocate to handle this problem separately.
Agreed.
Arnd
^ permalink raw reply
* [PATCH 2/2] i2c: omap: make reset a seperate function
From: Shubhrajyoti @ 2012-10-25 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025105516.GH21217@arwen.pp.htv.fi>
On Thursday 25 October 2012 04:25 PM, Felipe Balbi wrote:
> overflow, underflow
these are data errors personally feel may be removed.
> and arbitration lost)
will investigate.
> and try to make sure if
> actually need to reset the controller all the time. I find it really odd
> that we're always resetting the IP in every error condition without
> actually trying to figure out what's wrong with the driver (if there is
> something wrong with the driver, of course).
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.7-rc3
From: Arnd Bergmann @ 2012-10-25 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088F131.5040600@atmel.com>
On Thursday 25 October 2012, Nicolas Ferre wrote:
> Arnd, Olof,
>
> This is the first Atmel AT91 "fixes" update for the 3.7 kernel.
>
> The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
>
> Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
>
> are available in the git repository at:
>
> git://github.com/at91linux/linux-at91.git tags/at91-fixes
>
Pulled into fixes branch now, thanks!
Arnd
^ permalink raw reply
* [PATCH] arm: mvebu: move irq controller driver in drivers/irqchip/
From: Rob Herring @ 2012-10-25 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351168500-11129-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/25/2012 07:35 AM, Thomas Petazzoni wrote:
> The new support for the ARM BCM2835 SoC has introduced the
> drivers/irqchip/ directory for IRQ controller drivers. So let's
> conform to this good new approach, and move the IRQ controller driver
> for Marvell Armada 370/XP in this directory.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
snip
> diff --git a/include/linux/irqchip/armada-370-xp.h b/include/linux/irqchip/armada-370-xp.h
> new file mode 100644
> index 0000000..78876c2
> --- /dev/null
> +++ b/include/linux/irqchip/armada-370-xp.h
> @@ -0,0 +1,19 @@
> +/*
> + * Copyright (C) 2012 Marvell
> + *
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __LINUX_IRQCHIP_ARMADA_370_XP_H_
> +#define __LINUX_IRQCHIP_ARMADA_370_XP_H_
> +
> +#include <asm/exception.h>
> +
> +void armada_370_xp_init_irq(void);
> +void armada_370_xp_handle_irq(struct pt_regs *regs);
> +
> +#endif
I don't mean to pick on this specific patch, but this is a common
problem of moving various low-level pieces like irqchips, cpuidle,
timers, etc. to drivers/*. If we, just moving the code as is over, we
still need some hooks between arch/arm and drivers. I think if we keep
adding ARM SOC specific headers to include/linux, that will be the next
thing we get yelled at for and will have to clean-up.
For irqchips, the way I see this working is we would have a single call
to of_irq_init with a match list of all irqchips in drivers/irqchips.
This contains the init function within drivers/irqchips. Then all the
machines can just call a generic irqchip_init.
The handle_irq ptr would also need to be plugged in at runtime.
Rob
^ permalink raw reply
* [GIT PULL] ux500 fixes due for v3.7 RCs
From: Arnd Bergmann @ 2012-10-25 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025094147.GA4008@gmail.com>
On Thursday 25 October 2012, Lee Jones wrote:
> The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
>
> Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/ljones/linux-3.0-ux500.git for-rcs-3.7
Pulled into fixes branch, thanks!
Since we're now getting pull requests from both of you, Lee and Linus,
I'd like to understand how you are organized.
Lee, are you just sending bug fixes directly and send future work through
Linus, or are you acting as backup maintainer when he is busy otherwise
in general?
Arnd
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Rob Herring @ 2012-10-25 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025131818.GF18811@titan.lakedaemon.net>
On 10/25/2012 08:18 AM, Jason Cooper wrote:
> On Wed, Oct 24, 2012 at 04:05:45PM +0200, Gregory CLEMENT wrote:
>> On 10/24/2012 04:01 PM, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> Shouldn't you split into one commit adding the SATA definition in
>>> the .dtsi + doing the defconfig change (the "SoC" level modifications),
>>> and then another commit for the .dts change? I don't really care
>>> personally, it's really up to Jason/Andrew on this.
>>>
>>> Another comment below, though.
>>>
>>> On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:
>>>
>>>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>>>> index 94b4b9e..3f08233 100644
>>>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>>>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>>>> @@ -69,6 +69,16 @@
>>>> compatible = "marvell,armada-addr-decoding-controller";
>>>> reg = <0xd0020000 0x258>;
>>>> };
>>>> +
>>>> + sata at d00a0000 {
>>>> + compatible = "marvell,orion-sata";
>>>> + reg = <0xd00a0000 0x2400>;
>>>> + interrupts = <55>;
>>>> + nr-ports = <2>;
>>>> + clocks = <&coreclk 0>;//, <&coreclk 0>;
>>>
>>> Alignment problem + remainings of tests or something like that.
>>
>> True I missed this one.
>>
>> Jason, Andrew, do you want I split this patch as suggested by Thomas or
>> are you fine with having one single patch?
>
> Yes, please make the defconfig changes a separate patch. Also, please
> make sure only the minimum is enabled (eq RAID... isn't needed).
What about updating multi_v7_defconfig instead?
Rob
^ permalink raw reply
* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Jean Delvare @ 2012-10-25 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025134609.GH28061@n2100.arm.linux.org.uk>
On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> > On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > > You also miss one very very very big point. This will break every I2C
> > > using userspace program out there unless it is rebuilt - this change will
> > > require the exact right version of those userspace programs for the
> > > kernel that they're being used on.
> >
> > How that? The extra field is added in a hole, so we don't change the
> > struct size nor the relative positions of existing fields. Why would
> > user-space care?
>
> You know the layout of that struct for certain across all Linux supported
> architectures, including some of the more obscure ones which may not
> require pointers to be aligned?
No I don't, I naively supposed it would be fine. I would expect gcc to
always align pointers even when the architecture doesn't need them to
be, for performance reasons, even when it doesn't have to, as long as
attribute packed isn't used. After all, integers don't _have_ to be
aligned on x86, but gcc aligns them.
The original idea of using the hole in the i2c_msg structure is from
David Brownell, who was apparently familiar with such practice, so I
assumed it was OK. Actually I still assume it is, until someone comes
with an supported architecture where it is not.
--
Jean Delvare
^ permalink raw reply
* [PATCHv2] arm:socfpga: Enable SMP for socfpga
From: Arnd Bergmann @ 2012-10-25 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350581567-17229-1-git-send-email-dinguyen@altera.com>
On Thursday 18 October 2012, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Enable SMP for the SOCFPGA platform.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Applied to new next/smp branch in arm-soc, but please reply to the
comment from Thomas, and send a follow-on patch if necessary.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Rob Herring @ 2012-10-25 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50893FC8.1050503@free-electrons.com>
On 10/25/2012 08:34 AM, Gregory CLEMENT wrote:
> On 10/25/2012 03:21 PM, Thomas Petazzoni wrote:
>> Jason,
>>
>> On Thu, 25 Oct 2012 09:18:18 -0400, Jason Cooper wrote:
>>
>>>> Jason, Andrew, do you want I split this patch as suggested by
>>>> Thomas or are you fine with having one single patch?
>>>
>>> Yes, please make the defconfig changes a separate patch. Also, please
>>> make sure only the minimum is enabled (eq RAID... isn't needed).
>>
>> I haven't looked in details at the driver, but is nr-ports = <foo> the
>> right way of doing things? We may have platforms were port 0 is not
>> used, but port 1 is used, and just a number of ports doesn't allow to
>> express this.
>>
>> Shouldn't the DT property be
>>
>> ports = <0>, <1>
>> ports = <1>
>> ports = <1>, <3>
>>
>> In order to allow to more precisely enabled SATA ports? Or maybe the
>> SATA ports cannot be enabled/disabled on a per-port basis, in which
>> case I'm obviously wrong here.
>
> The actual implementation of mv_sata.c doesn't work like this. You can
> only pass the number of ports supported not the list of the port you
> want to support. I've checked in the device tree binding documentation
> _and_ also in the code.
Is that a statement about the driver or the h/w? It does not matter what
the driver does. If the h/w can support skipping a port, then the dts
should allow that.
A bitmask would be most appropriate here (and matches how AHCI does the
equivalent).
Rob
^ permalink raw reply
* [GIT PULL] i.MX fixes for -rc
From: Arnd Bergmann @ 2012-10-25 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024075656.GW27665@pengutronix.de>
On Wednesday 24 October 2012, Sascha Hauer wrote:
> The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
>
> Linux 3.6 (2012-09-30 16:47:46 -0700)
>
> are available in the git repository at:
>
> git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-fixes
Pulled into fixes branch now, thanks!
Arnd
^ permalink raw reply
* [PATCH] arm: mvebu: move irq controller driver in drivers/irqchip/
From: Thomas Petazzoni @ 2012-10-25 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50894346.60507@gmail.com>
Rob,
On Thu, 25 Oct 2012 08:48:54 -0500, Rob Herring wrote:
> I don't mean to pick on this specific patch, but this is a common
> problem of moving various low-level pieces like irqchips, cpuidle,
> timers, etc. to drivers/*. If we, just moving the code as is over, we
> still need some hooks between arch/arm and drivers. I think if we keep
> adding ARM SOC specific headers to include/linux, that will be the
> next thing we get yelled at for and will have to clean-up.
>
> For irqchips, the way I see this working is we would have a single
> call to of_irq_init with a match list of all irqchips in
> drivers/irqchips. This contains the init function within
> drivers/irqchips. Then all the machines can just call a generic
> irqchip_init.
Sounds doable indeed.
> The handle_irq ptr would also need to be plugged in at runtime.
However, do you have a more specific idea here? In setup_arch(), the
value of mdesc->handle_irq gets picked up way before the ->init_irq
machine hook is being called.
An option would be to fill this mdesc->handle_irq() field during the
mdesc->init_early() callback (would require moving things around a bit
in setup_arch(), but sounds reasonable). However, at the time of
mdesc->init_early(), I guess we can't call of_irq_init(). So we would
have a two step process: fill in mdesc->handle_irq during
mdesc->init_early(), and call irqchip_init() (which will do the
of_irq_init()) in mdesc->init_irq().
If that's fine with you, I can cook a patch for BCM2835 and MVEBU that
implements this idea.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Peter De Schrijver @ 2012-10-25 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018092440.GS3196@tbergstrom-lnx.Nvidia.com>
On Thu, Oct 18, 2012 at 11:24:40AM +0200, Peter De Schrijver wrote:
> On Tue, Oct 16, 2012 at 07:03:43PM +0200, Stephen Warren wrote:
> > On 10/16/2012 02:06 AM, Peter De Schrijver wrote:
> > >>> Even though we have plan to use coupled cpuidle, I still prefer to go
> > >>> with the LP2 driver first. Then adding one more patch to support coupled
> > >>> cpuidle based on LP2 driver. This is good for history. And if there is
> > >>> any issue, it's more easy to roll back to the stable one.
> > >>
> > >> I don't think that implementing it one way and then changing to a
> > >> different way will benefit history at all. It'll make the history more
> > >> complicated. What exactly is the problem with just using coupled cpuidle
> > >> from the start? If we did merge this implementation now, then switch to
> > >> coupled cpuidle later, when do you think the switch would happen?
> > >
> > > Before we consider doing this, I think we should have some idea on how
> > > frequently we run into the situation where CPU0 is idle but a secondary
> > > core is not. Depending on that we can then decide how useful coupled cpuidle
> > > would be for us.
> >
> > Would it not be 75% of the time where we have 1 of 4 CPUs active? At
> > least, that's assuming that all work is evenly distributed amongst CPUs,
> > and hence it's random which CPU is the last to go idle, but perhaps
> > that's not the case if CPU0 is somehow special workload-wise?
> >
>
> Depends, at least it used to be possible to tune the scheduler to prefer
> CPU0 if the workload can run on a single CPU.
>
I just noticed https://lwn.net/Articles/518834/. If we can configure this to
prefer CPU0 in case all work can be done on a single core, we shouldn't
hit the case were a secondary CPU is the only active CPU for a significant
period of time.
Cheers,
Peter.
^ permalink raw reply
* [PATCH 1/2] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Thomas Petazzoni @ 2012-10-25 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210251346.41596.arnd@arndb.de>
On Thu, 25 Oct 2012 13:46:41 +0000, Arnd Bergmann wrote:
> > Seems like the driver is too lazy and allocates everything coherent
> > to avoid the hassle of doing dma_map/dma_unmap operations when
> > needed, but I haven't looked in details at the driver yet to see if
> > it would be possible to switch those DMA coherent allocations into
> > non-coherent allocations + appropriate calls to the DMA operations.
>
> Using coherent allocations is fine, I was wondering whether they need
> to be atomic or not.
You're raising a good point here: all the dma_pool_alloc()
allocations done by sata_mv are GFP_KERNEL. So why are we having
problems with the /atomic/ coherent pool size? Is it the libata core
that's doing GFP_ATOMIC DMA coherent allocations. It doesn't seem so.
Something's odd.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Gregory CLEMENT @ 2012-10-25 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50894471.9040000@gmail.com>
On 10/25/2012 03:53 PM, Rob Herring wrote:
> On 10/25/2012 08:18 AM, Jason Cooper wrote:
>> On Wed, Oct 24, 2012 at 04:05:45PM +0200, Gregory CLEMENT wrote:
>>> On 10/24/2012 04:01 PM, Thomas Petazzoni wrote:
>>>> Hello,
>>>>
>>>> Shouldn't you split into one commit adding the SATA definition in
>>>> the .dtsi + doing the defconfig change (the "SoC" level modifications),
>>>> and then another commit for the .dts change? I don't really care
>>>> personally, it's really up to Jason/Andrew on this.
>>>>
>>>> Another comment below, though.
>>>>
>>>> On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:
>>>>
>>>>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>>>>> index 94b4b9e..3f08233 100644
>>>>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>>>>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>>>>> @@ -69,6 +69,16 @@
>>>>> compatible = "marvell,armada-addr-decoding-controller";
>>>>> reg = <0xd0020000 0x258>;
>>>>> };
>>>>> +
>>>>> + sata at d00a0000 {
>>>>> + compatible = "marvell,orion-sata";
>>>>> + reg = <0xd00a0000 0x2400>;
>>>>> + interrupts = <55>;
>>>>> + nr-ports = <2>;
>>>>> + clocks = <&coreclk 0>;//, <&coreclk 0>;
>>>>
>>>> Alignment problem + remainings of tests or something like that.
>>>
>>> True I missed this one.
>>>
>>> Jason, Andrew, do you want I split this patch as suggested by Thomas or
>>> are you fine with having one single patch?
>>
>> Yes, please make the defconfig changes a separate patch. Also, please
>> make sure only the minimum is enabled (eq RAID... isn't needed).
>
> What about updating multi_v7_defconfig instead?
About the _instead_, when I proposed to removed mvebu_defconfig Thomas
argued that it was more convenient to build a mvebu-only kernel when
doing kernel development, and Andrew also pointed that this defconfig
should be useful for kisskb.
And about updated both mvebu_defconfig and multi_v7_defconfig, I'm
fine with it.
Gregory
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Kevin Hilman @ 2012-10-25 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023211151.GF1855@beef>
Matt Porter <mporter@ti.com> writes:
> On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
>> Matt Porter <mporter@ti.com> writes:
>>
>> [...]
>>
>> > Ok, very quick update...no need to mess around with the eeprom. I just
>> > received the official word on what will be supported. Since A2 is
>> > pre-release, simply go to http://beagleboard.org/support/rma and fill
>> > out the form to have it replaced with the current revision (A6).
>> >
>> > This applies to *anyone* that received a pre-release A2 board.
>>
>> Hmm, doesn't seem the RMA people are aware of this. They just rejected
>> my request since it's not a "hardware related issue":
>>
>> Kevin,
>>
>> We only work with hardware related issue here. BeagleBone revision A2
>> was not officially released. We recommend you to work with the
>> community for support in Uboot. You can post your questions at the
>> BeagleBoard Google Groups:
>> https://groups.google.com/forum/?fromgroups=#!forum/beagleboard
>>
>> Regards,
>> RMA Team
>
> That's sad considering the beagleboard.org/BeagleBone hardware designer
> specifically said they would be replaced via this route. *sigh*. Ok, I'll
> go back and share this with him.
Just and update...
Something happened behind the scenes (thanks Matt) and they've accepted
my RMA request. I'll be sending back my board in order to get a new
one.
Thanks,
Kevin
^ permalink raw reply
* [PATCH v2 5/7] i2c: omap: wait for transfer completion before sending STP bit
From: Felipe Balbi @ 2012-10-25 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50893846.3020106@ti.com>
HI,
On Thu, Oct 25, 2012 at 06:31:58PM +0530, Santosh Shilimkar wrote:
> On Thursday 25 October 2012 05:55 PM, Felipe Balbi wrote:
> >Later patches will come adding support for
> >reporting amount of bytes transferred so that
> >client drivers can count how many bytes are
> >left to transfer.
> >
> >This is useful mostly in case of NACKs when
> >client driver wants to know exactly which
> >byte got NACKed so it doesn't have to resend
> >all bytes again.
> >
> >In order to make that work with OMAP's I2C
> >controller, we need to prevent sending STP
> >bit until message is transferred. The reason
> >behind that is because OMAP_I2C_CNT_REG gets
> >reset to original value after STP bit is
> >shifted through I2C_SDA line and that would
> >prevent us from reading the correct number of
> >bytes left to transfer.
> >
> >The full programming model suggested by IP
> >owner was the following:
> >
> >- start I2C transfer (without STP bit)
> >- upon completion or NACK, read I2C_CNT register
> >- write STP bit to I2C_CON register
> >- wait for ARDY bit
> >
> >With this patch we're implementing all steps
> >except step #2 which will come in a later
> >patch adding such support.
> >
> Will this not break the bisect since CNT and
> NACK, completion is added in later patch
not really. It keeps current behavior.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/21c17265/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Johannes Stezenbach @ 2012-10-25 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50893389.2090002@gmail.com>
On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
> > On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> >
> >> While v6 can support unaligned accesses, it is optional and current
> >> compilers won't emit unaligned accesses. So we don't clear the A bit for
> >> v6.
> >
> > not true according to the gcc changes page
>
> What are you going to believe: documentation or what the compiler
> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
> support backported and 4.7.2, unaligned accesses are emitted for v7
> only. I guess default here means it is the default unless you change the
> default in your build of gcc.
Since ARMv6 can handle unaligned access in the same way as ARMv7
it seems a clear bug in gcc which might hopefully get fixed.
Thus in this case I think it is reasonable to follow the
gcc documentation, otherwise the code would break for ARMv6
when gcc gets fixed.
Johannes
^ permalink raw reply
* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Russell King - ARM Linux @ 2012-10-25 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025155633.609c5554@endymion.delvare>
On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> > > On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > > > You also miss one very very very big point. This will break every I2C
> > > > using userspace program out there unless it is rebuilt - this change will
> > > > require the exact right version of those userspace programs for the
> > > > kernel that they're being used on.
> > >
> > > How that? The extra field is added in a hole, so we don't change the
> > > struct size nor the relative positions of existing fields. Why would
> > > user-space care?
> >
> > You know the layout of that struct for certain across all Linux supported
> > architectures, including some of the more obscure ones which may not
> > require pointers to be aligned?
>
> No I don't, I naively supposed it would be fine. I would expect gcc to
> always align pointers even when the architecture doesn't need them to
> be, for performance reasons, even when it doesn't have to, as long as
> attribute packed isn't used. After all, integers don't _have_ to be
> aligned on x86, but gcc aligns them.
>
> The original idea of using the hole in the i2c_msg structure is from
> David Brownell, who was apparently familiar with such practice, so I
> assumed it was OK. Actually I still assume it is, until someone comes
> with an supported architecture where it is not.
According to Al Viro, that would be m68k.
^ permalink raw reply
* [PATCH] arm: mvebu: move irq controller driver in drivers/irqchip/
From: Arnd Bergmann @ 2012-10-25 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025160657.57a52658@skate>
On Thursday 25 October 2012, Thomas Petazzoni wrote:
> On Thu, 25 Oct 2012 08:48:54 -0500, Rob Herring wrote:
>
> > I don't mean to pick on this specific patch, but this is a common
> > problem of moving various low-level pieces like irqchips, cpuidle,
> > timers, etc. to drivers/*. If we, just moving the code as is over, we
> > still need some hooks between arch/arm and drivers. I think if we keep
> > adding ARM SOC specific headers to include/linux, that will be the
> > next thing we get yelled at for and will have to clean-up.
> >
> > For irqchips, the way I see this working is we would have a single
> > call to of_irq_init with a match list of all irqchips in
> > drivers/irqchips. This contains the init function within
> > drivers/irqchips. Then all the machines can just call a generic
> > irqchip_init.
>
> Sounds doable indeed.
Agreed. I had the same idea some time ago, but didn't want to be the
one who starts that discussion.
> > The handle_irq ptr would also need to be plugged in at runtime.
>
> However, do you have a more specific idea here? In setup_arch(), the
> value of mdesc->handle_irq gets picked up way before the ->init_irq
> machine hook is being called.
The variouos *_of_init functions to initialize each IRQ controller already
get a pointer to the irq parent.
Maybe we can just change those functions so that any irqchip that can
be a top-level chip and has a NULL parent can also assign the
handle_arch_irq pointer like in the snippet below.
Arnd
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index aa52699..ec7e00b 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -777,6 +777,8 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
if (parent) {
irq = irq_of_parse_and_map(node, 0);
gic_cascade_irq(gic_cnt, irq);
+ } else {
+ handle_arch_irq = gic_handle_irq;
}
gic_cnt++;
return 0;
^ permalink raw reply related
* [PATCH] arm: mvebu: move irq controller driver in drivers/irqchip/
From: Rob Herring @ 2012-10-25 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025160657.57a52658@skate>
On 10/25/2012 09:06 AM, Thomas Petazzoni wrote:
> Rob,
>
> On Thu, 25 Oct 2012 08:48:54 -0500, Rob Herring wrote:
>
>> I don't mean to pick on this specific patch, but this is a common
>> problem of moving various low-level pieces like irqchips, cpuidle,
>> timers, etc. to drivers/*. If we, just moving the code as is over, we
>> still need some hooks between arch/arm and drivers. I think if we keep
>> adding ARM SOC specific headers to include/linux, that will be the
>> next thing we get yelled at for and will have to clean-up.
>>
>> For irqchips, the way I see this working is we would have a single
>> call to of_irq_init with a match list of all irqchips in
>> drivers/irqchips. This contains the init function within
>> drivers/irqchips. Then all the machines can just call a generic
>> irqchip_init.
>
> Sounds doable indeed.
>
>> The handle_irq ptr would also need to be plugged in at runtime.
>
> However, do you have a more specific idea here? In setup_arch(), the
> value of mdesc->handle_irq gets picked up way before the ->init_irq
> machine hook is being called.
>
> An option would be to fill this mdesc->handle_irq() field during the
> mdesc->init_early() callback (would require moving things around a bit
> in setup_arch(), but sounds reasonable). However, at the time of
> mdesc->init_early(), I guess we can't call of_irq_init(). So we would
> have a two step process: fill in mdesc->handle_irq during
> mdesc->init_early(), and call irqchip_init() (which will do the
> of_irq_init()) in mdesc->init_irq().
There's not really any reason I can see that it needs to be setup that
early. You can't really service interrupts before .init_irq completes
anyway. I would export handle_arch_irq and allow the irqchip driver to
set it up.
> If that's fine with you, I can cook a patch for BCM2835 and MVEBU that
> implements this idea.
Great!
Rob
^ permalink raw reply
* [PATCH 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Fabio Estevam @ 2012-10-25 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025114624.7896b5d9@redhat.com>
Hi Sascha,
On Thu, Oct 25, 2012 at 11:46 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
>> As this patch is for arch/arm, I'm understanding that it will be merged
>> via arm tree. So,
>>
>> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> Forgot to comment: as patch 2 relies on this change, the better, IMHO, is
> to send both via the same tree. If you decide to do so, please get arm
> maintainer's ack, instead, and we can merge both via my tree.
Can you please send your Ack to this series so that Mauro can merge it
via his tree?
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH v4] pwm: vt8500: Update vt8500 PWM driver support
From: Arnd Bergmann @ 2012-10-25 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351100330-26072-1-git-send-email-linux@prisktech.co.nz>
On Wednesday 24 October 2012, Tony Prisk wrote:
> This patch updates pwm-vt8500.c to support devicetree probing and
> make use of the common clock subsystem.
>
> A binding document describing the PWM controller found on
> arch-vt8500 is also included.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] MAINTAINERS: Add arm-soc tree entry
From: Arnd Bergmann @ 2012-10-25 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351101629-11826-1-git-send-email-sboyd@codeaurora.org>
On Wednesday 24 October 2012, Stephen Boyd wrote:
> Document the arm-soc tree in the maintainers file so that
> developers know how arm SoC development is structured.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Applied to fixes branch, I think it's reasonable to not have
to wait for 3.8.
Thanks!
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox