On Friday 23 March 2012, Tony Lindgren wrote:
> >
> > +config ARCH_OMAP2_AUTO
> > + bool
> > + depends on !ARCH_OMAP3 && !ARCH_OMAP4
> > + select ARCH_OMAP2
> > + default y
> > + help
> > + At least one of OMAP2/OMAP3/OMAP4 needs to be enabled, this
> > + selects O
On Thursday 22 March 2012, Florian Tobias Schandinat wrote:
> On 03/19/2012 04:24 PM, Arnd Bergmann wrote:
> > I've looked at the specific conflicts again, and it seems that the only
> > conflicting commit in arm-soc is 2e3ee9f45b "ARM: OMAP1: Move most of
> > pla
On Tuesday 20 March 2012, Paul Walmsley wrote:
> Hello Arnd,
>
> On Sat, 17 Mar 2012, Arnd Bergmann wrote:
>
> > I think it's rather pointless, because the option is not going to
> > be user selectable but will get selected by the platform unless I'm
> >
On Wednesday 21 March 2012, Thierry Reding wrote:
> * Arnd Bergmann wrote:
> > On Wednesday 21 March 2012, Bernhard Walle wrote:
> > > Am 20.03.12 23:02, schrieb Arnd Bergmann:
> > > > On Tuesday 20 March 2012, Bernhard Walle wrote:
> > > >>
> &g
On Wednesday 21 March 2012, Bernhard Walle wrote:
> Am 20.03.12 23:02, schrieb Arnd Bergmann:
> > On Tuesday 20 March 2012, Bernhard Walle wrote:
> >>
> >> This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
> >> PWM has been used as mode,
On Tuesday 20 March 2012, Kevin Hilman wrote:
> Maybe it's time that drivers/cpuidle gets a maintainer. With lots of
> discussions of scheduler changes that affect load estimation, I suspect
> we're all going to have a bit of CPUidle work to do in the
> not-so-distant future.
Hmm, according to th
On Tuesday 20 March 2012, Bernhard Walle wrote:
>
> This PWM driver uses the PWM of the TWL4030. The driver for the TWL6030
> PWM has been used as mode, but the PWM registers are different.
>
> The driver can be used and has been tested in conjunction with
> pwm-backlight to control a backlight L
On Tuesday 20 March 2012, Robert Lee wrote:
> This patch series moves various functionality duplicated in platform
> cpuidle drivers to the core cpuidle driver. Also, the platform irq
> disabling was removed as it appears that all calls into
> cpuidle_call_idle will have already called local_irq_
On Tuesday 20 March 2012, Nicolas Ferre wrote:
>
> Add some basic helpers to retrieve a DMA controller device_node and the
> DMA request specifications. By making DMA controllers register a generic
> translation function, we allow the management of any type of DMA requests
> specification.
> The v
On Monday 19 March 2012, Tony Lindgren wrote:
> Let's just keep bb60424af. There are more patches needed to make
> multiple smsc91x instances work, but we need to hear from people
> with such boards first. Then those can be tagged for stable.
>
Ok, I'm just putting that into the fixes branch for
On Monday 19 March 2012, Kevin Hilman wrote:
> > On Wednesday 07 March 2012, Kevin Hilman wrote:
> >> commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
> >> regulators) added regulators which are registered during
> >> gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo)
On Wednesday 07 March 2012, Kevin Hilman wrote:
> commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
> regulators) added regulators which are registered during
> gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
> than one instance of the SMSC911x and result i
On Monday 19 March 2012, Tomi Valkeinen wrote:
> Here are the changes for OMAP DSS driver for v3.4.
>
> There's an issue with the dss driver that appears on arm-soc/for-next
> branch, which I'm still solving
> (http://marc.info/?l=linux-omap&m=133214966902577&w=2). I hope to get
> fix for that rea
On Monday 19 March 2012, Russell King - ARM Linux wrote:
> Firstly, define what you mean by "the DMA parameters". Things like burst
> size, register width, register address? That should all be known by the
> peripheral driver and not be encoded into DT in any way - and this
> information should b
On Monday 19 March 2012, Stephen Warren wrote:
> > Maybe one can use named properties in a new device node in that case,
> > like this:
> >
> > bus {
> > dma: dma-controller {
> > #dma-cells = <1>;
> > };
> >
> > device {
> >
On Monday 19 March 2012, Mark Brown wrote:
> On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
>
> > After implementing both schemes (ie. interrupts+interrupt-names &&
> > [*-]gpios)
> > I definitely prefer the fixed property name plus a separate names property.
> > It is easier to us
On Monday 19 March 2012, Nicolas Ferre wrote:
> > This _xlate is nearly useless as a generic API. It solves the problem for
> > the specific case where the driver is hard-coded to know which DMA engine
> > to talk to, but since the returned data doesn't provide any context, it
> > isn't useful if
On Sunday 18 March 2012, Arnd Bergmann wrote:
> >
> > Is dma_find_device() a new function? How does it look up the dma
> > device?
>
> Yes, it would be similar to the proposed function in Benoit's patch
>
Well, actually we would not even need a new list wit
On Sunday 18 March 2012, Grant Likely wrote:
> > struct dma_channel *of_dma_request_channel(struct of_node*, int index,
> > dma_cap_mask_t *mask,
> > void *driver_data)
> > {
> > struct of_phandle_args dma_spec;
> >
On Saturday 17 March 2012, Grant Likely wrote:
> > +static LIST_HEAD(of_dma_list);
> > +
> > +struct of_dma {
> > + struct list_head of_dma_controllers;
> > + struct device_node *of_node;
> > + int of_dma_n_cells;
> > + int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *dat
On Sunday 18 March 2012, Thierry Reding wrote:
> Not enough information to check signature validity. Show Details
> * Grant Likely wrote:
> > On Thu, 15 Mar 2012 11:27:36 +0100, Thierry Reding
> > wrote:
> > > So if we decide to explicitly allow specifying names, then we can always
> > > add
visible.
I've applied this patch now.
Arnd
commit c173033d154e9792b1b5059783b802f82536d48f
Author: Arnd Bergmann
Date: Sat Mar 17 21:10:51 2012 +
clk: make CONFIG_COMMON_CLK invisible
All platforms that use the common clk infrastructure should select
COMMON_CLK from platform code, an
On Saturday 17 March 2012, Turquette, Mike wrote:
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 2eaf17e..a0a83de 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
> >
> > menuconfig COMMON_CLK
> > - bool "C
On Saturday 17 March 2012, Grant Likely wrote:
> On Thu, 15 Mar 2012 09:26:52 +, Russell King - ARM Linux
> wrote:
> > On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
> > > On Thursday 15 March 2012, Nicolas Ferre wrote:
> > > > Add som
On Friday 16 March 2012, Turquette, Mike wrote:
> On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley wrote:
> > From: Paul Walmsley
> > Date: Fri, 16 Mar 2012 16:06:30 -0600
> > Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
> >
> > Mark the common clk code as depending on CON
On Friday 16 March 2012, Cousson, Benoit wrote:
> And it seems that other ARM SoCs are using it for the same purpose.
> There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
ISA dma api or a platform specific varian
On Thursday 15 March 2012, Nicolas Ferre wrote:
> For legacy reason another API will export the DMA request number into a
> Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
> +/**
> + * of_dma_to_resource - Decode a node's DMA and
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> Thank you both for missing my point.
>
> #define OMAP24XX_DMA_SHA1MD5_RX 13 /* S_DMA_12 */
> #define OMAP34XX_DMA_SHA2MD5_RX 13 /* S_DMA_12 */
>
> #define OMAP242X_DMA_EXT_DMAREQ214 /* S_DMA_13 */
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
> > This was done like IRQ on purpose, because an Interrupt ReQuest line and
> > a DMA Request line are really similar for the HW point of view at IP
> > level.
>
> I'm
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> On Thu, Mar 15, 2012 at 09:22:06AM +0000, Arnd Bergmann wrote:
> > On Thursday 15 March 2012, Nicolas Ferre wrote:
> > > Add some basic helpers to retrieve a DMA controller device_node and the
> > > DMA reques
On Thursday 15 March 2012, Nicolas Ferre wrote:
> Add some basic helpers to retrieve a DMA controller device_node and the
> DMA request specifications. By making DMA controllers register a generic
> translation function, we allow the management of any type of DMA requests
> specification.
> The voi
On Thursday 15 March 2012, Tony Lindgren wrote:
> * Cousson, Benoit [120314 16:41]:
> > Hi Tony,
> >
> > Here are the remaining DTS patches for 3.4.
> >
> > On top of the previous pull request, I just added the MMC DTS since the
> > driver adaptation just got queued.
> >
> > It will be still b
On Wednesday 14 March 2012, Tony Lindgren wrote:
> * Olof Johansson [120310 10:26]:
> > On Thu, Mar 08, 2012 at 12:53:29PM -0800, Tony Lindgren wrote:
> > > Hi Olof,
> > >
> > > Here are two more pre-emptive fixes for upcoming merge
> > > window to pull into arm-soc/next/fixes-non-critical.
> > >
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
> > On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann wrote:
> > > I think 'depends' would be better here, because selecting IOMMU_SUPPORT
> &g
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> On Tue, Mar 06, 2012 at 03:58:34PM +0100, Cousson, Benoit wrote:
> > We added that to avoid cluttering the drivers with a bunch of #ifdef
> > CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation
> > were done having th
On Saturday 03 March 2012, Tony Lindgren wrote:
> Well 85631d2 builds fine, looks like now some more includes of
> plat/hardware.h are now needed.Have not yet tracked down which
> commit triggers the build errors. Eventually those should become
> local headers too..
I've tried building arm-soc/for
On Wednesday 29 February 2012, Tony Lindgren wrote:
> This is mostly changes needed for io.h removal, and one
> patch to remove unused flag for McSPI. Note that these
> are based on RMK's for-armsoc.
>
> Also, these cause a minor merge conflict for mach-omap2/Kconfig
> with the fixes-non-critical
On Wednesday 29 February 2012, Tony Lindgren wrote:
> Benoit Cousson (10):
> arm/dts: OMAP: Remove bootargs node from board files
> ARM: OMAP2+: kconfig: Enable devicetree by default for OMAP2+ systems
> ARM: OMAP2+: board-generic: Remove un-needed .atag_offset for DT_MACHINE
>
On Wednesday 29 February 2012, Tony Lindgren wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap1
>
> Janusz Krzysztofik (7):
> ARM: OMAP1: ams-delta: register latch dependent devices later
> ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
>
On Wednesday 29 February 2012, Tony Lindgren wrote:
>
> This contains two changes that were too late
> for the previous merge window so let's get these
> out of the way first.
>
Pulled into next/soc
Thanks,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" i
On Wednesday 29 February 2012, Tony Lindgren wrote:
> This contains fixes for MMC platform init to allow marking
> functions that should be __init as __init. Also included are
> some randconfig fixes.
>
> Regards,
>
> Tony
>
>
> The following changes since commit 6b21d18ed50c7d145220b0724ea7f26
On Tuesday 28 February 2012, Ohad Ben-Cohen wrote:
> On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux
> wrote:
> > 1. It selects OMAP_IOMMU which may not have its dependencies satisfied.
>
> I'll select IOMMU_SUPPORT too (I prefer selecting here rather than
> depending, because users ma
On Thursday 23 February 2012, Tony Lindgren wrote:
> Please pull omap fixes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
>
> This contains a fix for omap4 to call memblck_steal() from
> .reserve like it should be, and fixes a regression for smsc911x
> using boar
On Thursday 23 February 2012, Mircea Gherzan wrote:
> The PandaBoard features a Texas Instruments WiLink7 Bluetooth
> chip, supported by the "btwilink" driver.
>
> Signed-off-by: Mircea Gherzan
No objections to the patch, but please send it to the maintainer,
not to me. You also misspelled the a
On Wednesday 22 February 2012, Ohad Ben-Cohen wrote:
>
> Hi Arnd,
>
> Please pull:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
> rpmsg-for-3.4
>
> To get the very basic rpmsg+remoteproc core functionality for 3.4.
>
> This is basically the same stuff I sent for 3.3,
On Monday 13 February 2012, Tony Lindgren wrote:
> Hi Arnd and Olof,
>
> Please pull omap fixes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
>
> This contains a DT boot fix that was found sitting in the omap DT branch,
> omap2 related PM fix for serial port, an
On Wednesday 01 February 2012, Ohad Ben-Cohen wrote:
> On Thu, Dec 22, 2011 at 5:22 PM, Arnd Bergmann wrote:
> > If you think you need more Acks or if there are other
> > reasons to have it go through arm-soc, please tell me and I'll try harder
> > to find the time for
On Thursday 19 January 2012, AnilKumar, Chimata wrote:
> Android userspace running on TI AM335x EVM is using the interface
> provided by lis3lv02d. They were asking some more interfaces from
> lis3lvo2d driver.
>
> There are multiple ways we can interface accelerometer to Android layers,
> which i
On Wednesday 18 January 2012, Andi wrote:
> What do you mean with "kernel-wide policy for accelerometer drivers"?
> As far as I know, accelerometer drivers are written between the i2c driver
> and the
> input driver.
> The input driver provides already some accelerometer specific event types,
> A
On Wednesday 18 January 2012, Jonathan Cameron wrote:
> Arnd Bergmann wrote:
>
> >Any opinions where they should live? input, iio or a new subsystem?
> >
> Personal thought is that straight 3d devices very directed at input
> should go there. Iio has a few wrinkle
On Wednesday 18 January 2012, Jean Delvare wrote:
> Hi Arnd and all,
>
> The lis3lv02d driver was moved outside of drivers/hwmon to make it
> clear that we (hwmon/lm-sensors people) are not involved in maintaining
> this driver in any way. So please remove the lm-sensors list (and
> myself) from t
On Tuesday 17 January 2012, AnilKumar, Chimata wrote:
> Hi All,
>
> Recalling the patch, provide the comments if there are any if not please
> include
> this patch to v3.3 kernel.
As Mark and Greg said, 3.4 would be appropriate.
> +static ssize_t lis3lv02d_range_set(struct device *dev,
> +
On Monday 19 December 2011, Tony Lindgren wrote:
> Hi Arnd & Olof,
>
> Please pull omap echi changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap ehci
>
> These are needed for runtime PM support for the usb *hci controllers
> on omap. These depend on the fixes-non-cr
On Monday 19 December 2011, Tony Lindgren wrote:
> Hi Arnd & Olof,
>
> Please pull omap hwmod changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap hwmod
>
> These changes are mostly needed for the USB *HCI support to
> behave. These depend on the fixes-non-critical-p
On Wednesday 21 December 2011, Ohad Ben-Cohen wrote:
> Hi Arnd,
>
> On Mon, Dec 12, 2011 at 1:33 AM, Stephen Rothwell
> wrote:
> > On Fri, 9 Dec 2011 16:55:27 +0200 Ohad Ben-Cohen wrote:
> >>
> >> Can you please add the following remoteproc tree to linux-next ?
> >>
> >> git://git.kernel.org/pu
On Tuesday 06 December 2011 23:45:27 Ming Lei wrote:
> >
> > and it is not difficult to implement it in a generic way so that new
> > array parameters can be supported as 64/32 compatible.
>
> How about the below patch to support 64/32 compatible array parameter?
Looks technically correct to me,
On Tuesday 06 December 2011, Ming Lei wrote:
> > Using an array added to the end of the v4l2_fd_result structure
> > rather than a pointer would really make this easier IMHO.
>
> I have tried to do this, but video_usercopy needs a few changes
> to handle array args if no indirect pointer is passed
On Tuesday 06 December 2011, Ming Lei wrote:
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 073eb4d..8aeaa1e 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -2214,7 +2214,12 @@ struct v4l2_fd_result {
> __u32 buf_index;
>
On Sunday 04 December 2011, Ming Lei wrote:
> >
> > This data structure is not 32/64 bit safe: running a 64 bit kernel with 32
> > bit
> > user space will see an incompatible layout.
>
> I agree that this is not 32/64 bit safe, but I understand lib32 can handle
> this correctly, otherwise many 32
On Friday 02 December 2011 17:12:56 Ming Lei wrote:
> +/**
> + * struct v4l2_fd_result - VIDIOC_G_FD_RESULT argument
> + * @buf_index: entry, index of v4l2_buffer for face detection
> + * @face_cnt: return, how many faces detected from the @buf_index
> + * @fd:return, result of fac
On Tuesday 29 November 2011, Tomi Valkeinen wrote:
> I don't think we need these in 3.1 stable. The omapdss driver in 3.1
> contains hacks to circumvent the HWMOD issues the patches below fix.
> These hacks were removed for 3.2.
>
> Well, the "ARM: OMAP2PLUS: DSS: Ensure DSS works correctly..." pa
On Wednesday 23 November 2011, Tony Lindgren wrote:
> Hi Arnd,
>
> This one has been separated out from the rest of the fixes.
Pulled into the fixes branch now. I'll send out the branch
after testing it on tomorrow's linux-next.
> If some of these need to go to stable, then Tomi should
> do the
On Wednesday 23 November 2011, Tony Lindgren wrote:
> This one has the DSS patches left out, some patches sent to
> stable, and based on -rc2.
Excellent, pulled into fixes now! Thanks for the quick update,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
th
On Wednesday 23 November 2011 14:03:58 Tony Lindgren wrote:
>
> The earlier patches are based on the earlier fixes (while waiting
> for them to get merged). So that's certainly not a random commit.
> Or at least was not at that time I can rebase those too anyways
> now that the earlier fixes are
On Saturday 19 November 2011, Tony Lindgren wrote:
> Please pull omap fixes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
>
> Most of this pull request are fixes needed by Tomi for the
> display driver clocking.
>
Hi Tony,
Sorry for the delay on my side, I've
On Tuesday 22 November 2011 12:19:51 Grant Likely wrote:
> On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette
> wrote:
>
> > Others have requested to have knobs made available for actually
> > performing clk_enable/clk_disable and even clk_set_rate from
> > userspace. I hate this idea and won't im
On Tuesday 22 November 2011, Mark Salter wrote:
>
> On Tue, 2011-11-22 at 13:11 +, Arnd Bergmann wrote:
> > On Tuesday 22 November 2011, Mike Turquette wrote:
> > > +static void clk_hw_gate_set_bit(struct clk *clk)
> > > +{
> > > + struct
On Tuesday 22 November 2011, Mike Turquette wrote:
> +static void clk_hw_gate_set_bit(struct clk *clk)
> +{
> + struct clk_hw_gate *gate = to_clk_hw_gate(clk);
> + u32 reg;
> +
> + reg = __raw_readl(gate->reg);
> + reg |= BIT(gate->bit_idx);
> + __raw_writel(reg, gate-
On Tuesday 22 November 2011, Mike Turquette wrote:
> Introduces kobject support for the common struct clk, exports per-clk
> data via read-only callbacks and models the clk tree topology in sysfs.
>
> Also adds support for generating the clk tree in clk_init and migrating
> nodes when input source
On Saturday 05 November 2011, Russell King - ARM Linux wrote:
> On Sat, Nov 05, 2011 at 05:57:59PM +0100, Thomas Weber wrote:
> > This patch fixes the dependencies for OMAP3_EMU after
> > commit 53eebb0df85e4005
> > ARM: OC_ETM should not select ARM_AMBA
> >
> > When "OMAP3 debugging peripherals"
On Monday 24 October 2011, Tony Lindgren wrote:
> As discussed in the ARM kernel meeting yesterday, here's are
> the pending omap things to pull for v3.2 merge window.
Hi Tony,
I finally got to pull these.
> These would be nice to get still in as other people's work
> such as Nico's map_io chang
On Monday 10 October 2011, Kevin Hilman wrote:
> > I got this build error only now after pulling in the latest omap series, but
> > I cannot tell what caused it. It's also not clear to me if this is the
> > correct
> > solution. Please ack or provide a better fix.
>
> This code was merged for v2.
2/built-in.o: In function `omap44xx_voltagedomains_init':
voltagedomains44xx_data.c:111: undefined reference to
`omap44xx_vdd_mpu_volt_data'
voltagedomains44xx_data.c:111: undefined reference to
`omap44xx_vdd_iva_volt_data'
voltagedomains44xx_data.c:111: undefined reference to
`omap44xx_
On Friday 07 October 2011, Thomas Gleixner wrote:
> For your internal dependecies, yes. But for irq/core you don't have to
> wait. You just need to tell Linus in the pull request that you pulled
> my branch with my ack as it contains modifications which are
> prerequisite for arm/whatever.
>
> Whe
On Friday 07 October 2011, Tony Lindgren wrote:
> Then merge all the -rc fixes for various ARM platforms with:
>
> $ git checkout fixes-for-rc
> $ git reset --hard v3.1-rc9
> $ git merge omap/fixes-for-rc soc foo/fixes-for-rc bar/fixes-for-rc
>
> And then no rebasing is needed. Of course I could
On Monday 03 October 2011, Tony Lindgren wrote:
> Please pull omap fixes from:
>
> git://github.com/tmlind/linux.git fixes
>
> Out of these the first three commits would be nice to get
> into the -rc series with the first two causing boot issues
> and the musb fixing an ugly warning.
>
> Note ho
On Friday 07 October 2011, Kevin Hilman wrote:
> > I've pulled in rmk/devel-stable as a dependency now, thanks for
> > reminding me of that.
> >
> > Thomas, where should I get the irq-core branch (or whichever
> > I should wait for) to pull in as another dependency. Is that
> > branch one that neve
On Thursday 06 October 2011, Tony Lindgren wrote:
> * Rob Herring [111001 13:21]:
> > On 09/30/2011 05:29 PM, Kevin Hilman wrote:
> > > Hi Arnd,
> > >
> > > Kevin Hilman writes:
> > >
> > >> The upcoming OMAP4 PM series from Santosh[1] that we're planning to
> > >> queue for v3.2 has a dependen
On Tuesday 04 October 2011 08:57:52 Tony Lindgren wrote:
> * Arnd Bergmann [111004 00:10]:
> > On Monday 03 October 2011, Tony Lindgren wrote:
> >
> > > Yes please leave out the list so we don't need to constantly update it.
> > > Let's just always build
On Tuesday 04 October 2011, Samuel Ortiz wrote:
> On Sun, Oct 02, 2011 at 04:45:52PM +0200, Arnd Bergmann wrote:
> > We can only have one pwm driver built into the kernel,
> I seem to remember that Bill Gatliff was working on a PWM subsystem that would
> get rid of the current pwm
On Monday 03 October 2011, Tony Lindgren wrote:
> * Arnd Bergmann [111003 02:20]:
> > On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> > > >
> > > > In the long run, I'd hope we can just get rid of these for
> > > > subarchitectures
On Monday 03 October 2011 10:49:10 Santosh Shilimkar wrote:
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 57b66d5..4deeade 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -253,6 +253,8 @@ config MACH_OMAP_ZOOM2
> >
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> >
> > In the long run, I'd hope we can just get rid of these for subarchitectures
> > that support device tree probing and make the device tree based machine
> > description unconditional.
>
> This is really our goal, we will have soon th
On Monday 03 October 2011 09:59:35 Tomi Valkeinen wrote:
> On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote:
> > Four of the LCD panel drivers depend on the backlight class,
> > so add the dependency in Kconfig.
> > Selecting the BACKLIGHT_CLASS_DEVICE symbol does n
On Monday 03 October 2011 09:53:50 Tomi Valkeinen wrote:
> Your patch will conflict with both of those changes. Is it ok for you to
> drop this patch, and I'll make a new one on top of my changes to clean
> up the Makefile in a similar way than you did? The new patch wouldn't
> make it in the next
00
> Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n
>
> arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C
> IP block reset code when CONFIG_I2C_OMAP=n. Fix by unconditionally
> compiling arch/arm/mach-omap2/i2c.o, which is needed on all
On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
> Anyway, I'll take your patches in, but their too late for this merge
> window I already sent my last pull to Greg.
No problem. I need the full set of arm-randconfig patches upstream in order
to make randconfig work in general, and that's no
On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote:
> > The entire set is also available from
> > git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap
> >
> > but I have not yet pulled them into the for-next branch.
> >
> Do you have any scripts to create these randconf
On Monday 03 October 2011 11:39:59 Archit Taneja wrote:
>
> A fix for this is already in the master branch of Mauro's tree:
>
> git://linuxtv.org/media_tree.git
>
> with the commit id:
>
> 5ebbf72dc51bd3b481aa91fea37a7157da5fc548
>
> I am guessing this would during the 3.2 merge window.
Ok, t
On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote:
> > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> > index bb8f4a6..f7ef9f4 100644
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -217,6 +217,11 @@ config OMAP_PM_NOOP
> >
> > en
On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
> > +config MACH_OMAP_AUTO_BOARD
> > + def_bool y
> > + depends on !MACH_OMAP2_TUSB6010
> > + depends on !MACH_OMAP_H4
> > + depends on !MACH_OMAP_APOLLON
> > + depends on !MACH_OMAP_APOLLON
> > + depends on !MACH_O
On Sunday 02 October 2011 21:56:09 Felipe Balbi wrote:
>
> > Unfortunately, even with the dma parts out of the way there is
> > a lot that needs to be done to make musb, ehci or ohci
> > really cross-platform. Right now, you can only have one
> > platform driver glue for each of those drivers, and
On Sunday 02 October 2011 16:53:31 Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> > -#if defined(CONFIG_MENELAUS) &&
> > \
> > - (defined(CONFIG_MMC_OMAP) || d
On Sunday 02 October 2011 21:24:26 Jarkko Nikula wrote:
> Now when I remember we had one build error. Hopefully it was the same
> than you observed?
I think it was something different, but it's possible.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
On Sunday 02 October 2011 20:40:35 Jarkko Nikula wrote:
> Strange. I'm able to build them fine with omap1_defconfig and with two
> supported OMAP1 ASoC machine drivers we have:
>
> CONFIG_SND_OMAP_SOC_AMS_DELTA=y
> CONFIG_SND_OMAP_SOC_OSK5912=y
>
> What's the error you are seeing? I guess there m
On Sunday 02 October 2011 18:34:52 Ohad Ben-Cohen wrote:
>
> The driver has moved to drivers/iommu/ and changed a bit, but this
> patch is still relevant.
>
> The merge conflict will be trivial to resolve, but if you prefer, we
> can prevent it by taking this patch via the iommu tree.
Yes, pleas
On Sunday 02 October 2011 17:14:47 Russell King - ARM Linux wrote:
> On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> > The logic to allow only one DMA driver in MUSB is currently
> > flawed, because it also allows picking no DMA driver at all
> > and also n
start
supporting multiple ARM platforms in a single kernel binary,
because at that point we will actually need to select
multiple DMA drivers and pick the right one at run-time.
Signed-off-by: Arnd Bergmann
Cc: Felipe Balbi
---
drivers/usb/musb/Kconfig | 57
We can only have one pwm driver built into the kernel, so make sure
that this one is only available on omap2 to avoid conflicts with
pwm drivers of other platforms.
Signed-off-by: Arnd Bergmann
Cc: Samuel Ortiz
Cc: Peter Ujfalusi
Cc: Balaji T K
Cc: Hemanth V
---
drivers/mfd/Kconfig |4
built-in.o:(.data+0x154e0): undefined reference to
`omap4430_phy_init'
mach-omap2/built-in.o:(.data+0x154e4): undefined reference to
`omap4430_phy_exit'
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap2/Makefile |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff -
501 - 600 of 755 matches
Mail list logo
