* [PATCH 0/8] OMAP2+: hwmod/clockevent: allow late-init of individual hwmods
From: Tony Lindgren @ 2011-03-02 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6B845A.9000900@ti.com>
> On 2/28/2011 3:31 AM, Paul Walmsley wrote:
> >Tony, I guess the omap-for-linus branch will probably need to get rebuilt
> >to drop that patch, once this series is merged...
Let's rather apply a fix or revert instead than start messing with
omap-for-linus. That branch is supposed to be a stable base for others
to base their branches on.
Tony
^ permalink raw reply
* [PATCH 4/8 resend] dw_dmac: calling dwc_scan_descriptors from dwc_tx_status() after taking lock
From: Koul, Vinod @ 2011-03-02 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <725d9e629bce9f79d87bdab4596a5088b70ea416.1298889267.git.viresh.kumar@st.com>
On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> drivers/dma/dw_dmac.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 3bf4772..5cc5abf 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -830,7 +830,9 @@ dwc_tx_status(struct dma_chan *chan,
>
> ret = dma_async_is_complete(cookie, last_complete, last_used);
> if (ret != DMA_SUCCESS) {
> + spin_lock_bh(&dwc->lock);
> dwc_scan_descriptors(to_dw_dma(chan->device), dwc);
> + spin_unlock_bh(&dwc->lock);
>
> last_complete = dwc->completed;
> last_used = chan->cookie;
Please always add a short description in the patch, helps in long run
Shouldnt you be doing this for dwc_handle_error() as well? I see thats
called without taking the lock....
--
~Vinod
^ permalink raw reply
* [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
From: Tony Lindgren @ 2011-03-02 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=MJigLvbJrRJ4CpyDcGd8sZXB7-1nFYup6EeDm@mail.gmail.com>
* Govindraj <govindraj.ti@gmail.com> [110302 02:05]:
>
> >>>>+static struct omap_device_pad default_serial1_pads[] __initdata = {
> >>>>+ ? ? ?{
> >>>>+ ? ? ? ? ? ? ?.name ? = "uart2_rx.uart2_rx",
> >>>>+ ? ? ? ? ? ? ?.flags ?= OMAP_DEVICE_PAD_REMUX |
> > OMAP_DEVICE_PAD_WAKEUP,
> >>>>+ ? ? ? ? ? ? ?.enable = OMAP_MUX_MODE0,
> >>>>+ ? ? ?},
...
AFAIK you should only need the OMAP_DEVICE_PAD_REMUX option for
omap24xx. And if you use that option, you also need the .idle
value.
Tony
^ permalink raw reply
* [PATCH] EDB93xx: Add support for CS4271 SPI-connected CODEC
From: H Hartley Sweeten @ 2011-03-02 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298706181.22098.8.camel@r60e>
On Saturday, February 26, 2011 12:43 AM, Alexander Sverdlin wrote:
>
> Add support for CS4271 SPI-connected CODEC to EDB93xx.
>
> Signed-off-by: Alexander Sverdlin <subaparts@yandex.ru>
>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Acked-by: liam Girdwood <lrg@slimlogic.co.uk>
Looks good. Please submit the patch to Russell's patch tracker.
Regards,
Hartley
^ permalink raw reply
* [PATCH 6/8 resend] dw_dmac: Mark all tx_descriptors with DMA_CRTL_ACK after xfer finish
From: Koul, Vinod @ 2011-03-02 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82027aa0c6446df3f7fb8e3c5fbdc28f60ea33b7.1298889267.git.viresh.kumar@st.com>
On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
> dwc_desc_get checks all descriptors for DMA_CTRL_ACK before allocating them for
> transfers. And descriptors are not marked with DMA_CRTL_ACK after transfer
> finishes. Thus descriptor once used is not usable again. This patch marks
> descriptors with DMA_CRTL_ACK after dma xfer finishes
>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> drivers/dma/dw_dmac.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index c40b89f..01f783d 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -196,6 +196,7 @@ dwc_descriptor_complete(struct dw_dma_chan *dwc, struct dw_desc *desc)
> dma_async_tx_callback callback;
> void *param;
> struct dma_async_tx_descriptor *txd = &desc->txd;
> + struct dw_desc *child;
Please align this with previous ones....
--
~Vinod
^ permalink raw reply
* [PATCH 7/8 resend] dw_dmac.c: Pass Channel Allocation Order from platform_data
From: Koul, Vinod @ 2011-03-02 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffc35e090243231bf0b3808f2b722c69be2ce36f.1298889267.git.viresh.kumar@st.com>
On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
> In SPEAr Platform channels 4-7 have more Fifo depth. So we must get better
> channel first. This patch introduces concept of channel allocation order in
> dw_dmac. If user doesn't paas anything or 0, than normal (ascending) channel
pass?
> allocation will follow, else channels will be allocated in descending order.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> drivers/dma/dw_dmac.c | 6 +++++-
> include/linux/dw_dmac.h | 3 +++
> 2 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 01f783d..37ffd2c 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1314,7 +1314,11 @@ static int __init dw_probe(struct platform_device *pdev)
> dwc->chan.device = &dw->dma;
> dwc->chan.cookie = dwc->completed = 1;
> dwc->chan.chan_id = i;
> - list_add_tail(&dwc->chan.device_node, &dw->dma.channels);
> + if (pdata->chan_allocation_order == CHAN_ALLOCATION_ASCENDING)
> + list_add_tail(&dwc->chan.device_node,
> + &dw->dma.channels);
> + else
> + list_add(&dwc->chan.device_node, &dw->dma.channels);
>
> dwc->ch_regs = &__dw_regs(dw)->CHAN[i];
> spin_lock_init(&dwc->lock);
> diff --git a/include/linux/dw_dmac.h b/include/linux/dw_dmac.h
> index c8aad71..057e883 100644
> --- a/include/linux/dw_dmac.h
> +++ b/include/linux/dw_dmac.h
> @@ -19,6 +19,9 @@
> */
> struct dw_dma_platform_data {
> unsigned int nr_channels;
> +#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
> +#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
Can you add these defines outside of this struct?
> + unsigned int chan_allocation_order;
> };
>
> /**
--
~Vinod
^ permalink raw reply
* [patch v2 0/2] Get watchdog reboot working on efika smartbook
From: Arnaud Patard (Rtp) @ 2011-03-02 18:45 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
With current patches in Sascha Hauer's tree, the efika smartbook is powering
off when rebooting. The cause of this bug is the default behaviour of the
mc13892 pmic. This patchset allows to configure the mc13892 to reboot the
system as expected by imx system.c throught platform_data and enables the
watchdog on the efika mx/sb systems.
Arnaud
v2:
- make the mc13892 behaviour configurable
- modify main mc13xxx driver instead of mc13892 regulator
- reorder Kconfig entry.
^ permalink raw reply
* [patch v2 1/2] mc13892: reboot on wdi event
From: Arnaud Patard (Rtp) @ 2011-03-02 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302184512.512010086@rtp-net.org>
An embedded and charset-unspecified text was scrubbed...
Name: mc13892_wdog_reboot.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110302/91e77fbc/attachment.ksh>
^ permalink raw reply
* [patch v2 2/2] efika mx/sb: enable watchdog
From: Arnaud Patard (Rtp) @ 2011-03-02 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302184512.512010086@rtp-net.org>
An embedded and charset-unspecified text was scrubbed...
Name: wdt.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110302/2afe7697/attachment.ksh>
^ permalink raw reply
* [PATCH 8/8 resend] dw_dmac.c: Pass Channel Priority from platform_data
From: Koul, Vinod @ 2011-03-02 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12a1cd2df6804fbd27adf57d73b5fb0c0fb6145c.1298889267.git.viresh.kumar@st.com>
On Mon, 2011-02-28 at 16:11 +0530, Viresh Kumar wrote:
> In Synopsys designware, channel priority is programmable. This patch adds
> support for passing channel priority through platform data. By default Ascending
> channel priority will be followed, i.e. channel 0 will get highest priority and
> channel 7 will get lowest.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> drivers/dma/dw_dmac.c | 11 ++++++++++-
> drivers/dma/dw_dmac_regs.h | 3 +++
> include/linux/dw_dmac.h | 4 +++-
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 37ffd2c..edb3d3b 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -896,8 +896,11 @@ static int dwc_alloc_chan_resources(struct dma_chan *chan)
> BUG_ON(!dws->dma_dev || dws->dma_dev != dw->dma.dev);
>
> cfghi = dws->cfg_hi;
> - cfglo = dws->cfg_lo;
> + cfglo = dws->cfg_lo & ~DWC_CFGL_CH_PRIOR_MASK;
> }
> +
> + cfglo |= DWC_CFGL_CH_PRIOR(dwc->priority);
> +
> channel_writel(dwc, CFG_LO, cfglo);
> channel_writel(dwc, CFG_HI, cfghi);
>
> @@ -1320,6 +1323,12 @@ static int __init dw_probe(struct platform_device *pdev)
> else
> list_add(&dwc->chan.device_node, &dw->dma.channels);
>
> + /* 7 is highest priority & 0 is lowest. */
> + if (pdata->chan_priority == CHAN_PRIORITY_ASCENDING)
> + dwc->priority = 7 - i;
> + else
> + dwc->priority = i;
> +
> dwc->ch_regs = &__dw_regs(dw)->CHAN[i];
> spin_lock_init(&dwc->lock);
> dwc->mask = 1 << i;
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index d9a939f..6a8e6d3 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -101,6 +101,8 @@ struct dw_dma_regs {
> #define DWC_CTLH_BLOCK_TS_MASK 0x00000fff
>
> /* Bitfields in CFG_LO. Platform-configurable bits are in <linux/dw_dmac.h> */
> +#define DWC_CFGL_CH_PRIOR_MASK (0x7 << 5) /* priority mask */
> +#define DWC_CFGL_CH_PRIOR(x) ((x) << 5) /* priority */
> #define DWC_CFGL_CH_SUSP (1 << 8) /* pause xfer */
> #define DWC_CFGL_FIFO_EMPTY (1 << 9) /* pause xfer */
> #define DWC_CFGL_HS_DST (1 << 10) /* handshake w/dst */
> @@ -134,6 +136,7 @@ struct dw_dma_chan {
> struct dma_chan chan;
> void __iomem *ch_regs;
> u8 mask;
> + u8 priority;
>
> spinlock_t lock;
>
> diff --git a/include/linux/dw_dmac.h b/include/linux/dw_dmac.h
> index 057e883..53072c8 100644
> --- a/include/linux/dw_dmac.h
> +++ b/include/linux/dw_dmac.h
> @@ -22,6 +22,9 @@ struct dw_dma_platform_data {
> #define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
> unsigned int chan_allocation_order;
> +#define CHAN_PRIORITY_ASCENDING 0 /* chan0 highest */
> +#define CHAN_PRIORITY_DESCENDING 1 /* chan7 highest */
How about generic CHAN_ORDER_ASCENDING which you can use in both?
> + unsigned int chan_priority;
> };
>
> /**
> @@ -65,7 +68,6 @@ struct dw_dma_slave {
> #define DWC_CFGH_DST_PER(x) ((x) << 11)
>
> /* Platform-configurable bits in CFG_LO */
> -#define DWC_CFGL_PRIO(x) ((x) << 5) /* priority */
> #define DWC_CFGL_LOCK_CH_XFER (0 << 12) /* scope of LOCK_CH */
> #define DWC_CFGL_LOCK_CH_BLOCK (1 << 12)
> #define DWC_CFGL_LOCK_CH_XACT (2 << 12)
--
~Vinod
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Russell King - ARM Linux @ 2011-03-02 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103021015110.2701@localhost6.localdomain6>
On Wed, Mar 02, 2011 at 10:25:02AM +0100, Thomas Gleixner wrote:
> On Wed, 2 Mar 2011, Russell King - ARM Linux wrote:
> > On Tue, Mar 01, 2011 at 10:29:37PM +0100, Thomas Gleixner wrote:
> > > Errm. I did never say that we disable the parent interrupt by any
> > > means except when the chained handler explicitely wants to do that,
> > > which is pretty much pointlesss nowadays, as we run all interrupt
> > > handlers with interrupts disabled.
> >
> > And that's now why some platforms struggle to work, and we're having
> > to bodge around this - like the ARM platforms with MMC support. Like
>
> Whats the problem for MMC?
The FIFO interrupt gets completely buggered by USB interrupts such that
we can't read data fast enough. With the old IRQF_DISABLED system,
the FIFO interrupt was marked IRQF_DISABLED as it was *fast* and needed
not to be interrupted. Other interrupts didn't have IRQF_DISABLED set.
That means such interrupts can be handled while other longer interrupts
are in progress. All that's gone out of the window now that all IRQ
handlers are run with IRQs permanently disabled.
And when this kind of behaviour becomes system specific (eg, the USB
device driver doesn't have this problem on x86 so why should it change)
then it all becomes impossible. There's hardware modifications in
progress to add deeper FIFOs (which need to be extended to something
idiotic like 512 32-bit words to work around the problem) and adaptive
clocking schemes which retry transfers at slower clock rates in the hope
that the IRQ handler can keep up.
It's a complete mess.
Another example - a platform I've worked on requires tight timings from
I2C in order for the CPU not to be spontaneously rebooted. A timeout
on I2C will cause this. We managed to get this platform to work reliably
by using IRQF_DISABLED and having the standard behaviour (IRQs enabled
during other interrupts). Now - god knows if it'll work reliably anymore,
my guess is that with latest kernels it'll be impossibly unreliable.
> > some other platforms where having IRQs disabled during IDE prevents
> > interrupts being recevied for long periods of time (longer than the
> > 100Hz tick period).
>
> That was discussed to death already and the general agreement was that
> those handlers should either enable interrupts themself, when it's
> required, or being converted to threaded handlers. An interrupt
> handler or any other code section which runs more than 10ms with
> interrupts disabled is a bug by definition.
I haven't noticed PATA getting this support. So how do platforms force
device drivers which turn out to be problematical to conform to their
timing issues when there wasn't a problem with previous kernels?
> > I *violently* disagree with the direction that genirq is heading. It's
> > *actively* breaking stuff. What's really annoying is that problems like
> > the above I did point out, but you seem happy to completely ignore them.
> > The result is that more and more ARM platforms *are* becoming utterly
> > useless, or requiring additional complexity being shoved into subsystems
> > to cope with this crap.
> >
> > What we need is a *decent* IRQ support system. Not something created out
> > of religious arguments which is what we have now.
>
> I'm not religious about it, at least not more than you with your total
> refusement to distinguish between special case oddball FPGA demux and
> bog standard functional irq chips.
Clearly you don't want to know about the problems all this stuff is
causing. Maybe you like being responsible for breaking the most ARM
platforms with your changes - are you trying for an entry in the
Guiness Book of World Records for this, because I think that's where
you're heading.
I don't agree with the distinction that you're trying to make. It only
works for a simple subset of cases - but it seems you're overall attitude
is that you only care about a small subset of easy cases and to hell
with everything else.
^ permalink raw reply
* [PATCHv1] ARM: imx: Add support for low power suspend on MX51.
From: Arnaud Patard (Rtp) @ 2011-03-02 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299086278-12131-1-git-send-email-Dinh.Nguyen@freescale.com>
<Dinh.Nguyen@freescale.com> writes:
Hi,
> From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
>
> Adds initial low power suspend functionality to MX51.
> Supports "mem" and "standby" modes.
I've very quickly tried suspend to mem on my system and despite having set
some irq as wakeup source, it doesn't wake up. Is there some extra step
to be done in order to test your patch ?
Moreover, the code I've seen for suspend is very different. It's seems
to handle some cpufreq stuff and seems to be copying some code into some
special ram. Is all this stuff unneeded ?
Arnaud
^ permalink raw reply
* [PATCHv1] ARM: imx: Add support for low power suspend on MX51.
From: Nguyen Dinh-R00091 @ 2011-03-02 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8762s1xqmj.fsf@lebrac.rtp-net.org>
Hi Arnaud,
>-----Original Message-----
From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-
>bounces at lists.infradead.org] On Behalf Of Arnaud Patard
>Sent: Wednesday, March 02, 2011 1:35 PM
>To: Nguyen Dinh-R00091
>Cc: linux at arm.linux.org.uk; s.hauer at pengutronix.de; linux-kernel at vger.kernel.org; u.kleine-
>koenig at pengutronix.de; Zhang Lily-R58066; linux-arm-kernel at lists.infradead.org
>Subject: Re: [PATCHv1] ARM: imx: Add support for low power suspend on MX51.
>
><Dinh.Nguyen@freescale.com> writes:
>
>Hi,
>
>> From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
>>
>> Adds initial low power suspend functionality to MX51.
>> Supports "mem" and "standby" modes.
>
>I've very quickly tried suspend to mem on my system and despite having set
>some irq as wakeup source, it doesn't wake up. Is there some extra step
>to be done in order to test your patch ?
>
>Moreover, the code I've seen for suspend is very different. It's seems
>to handle some cpufreq stuff and seems to be copying some code into some
>special ram. Is all this stuff unneeded ?
I am able to wakeup using gpio-key on my mx51-babbage system if I comment out the most of the drivers except for the gpio-keys driver. Yes, there are additional cpufreq and code that needs to get run in IRAM for mx51, which I will add on to this patch. This is just the initial patch to put the SoC in to suspend and have other developers add to it.
Thanks,
Dinh
>
>Arnaud
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [patch v2 1/2] mc13892: reboot on wdi event
From: Uwe Kleine-König @ 2011-03-02 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302185000.369378760@rtp-net.org>
Hello Arnaud,
On Wed, Mar 02, 2011 at 07:45:13PM +0100, Arnaud Patard wrote:
> By default, on wdi (watchdog input) event the mc13892 is powering off.
> This patch allows to change this behaviour throught platform_data.
>
> v2:
> - move to mc13xxx-core
> - make it configurable
>
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>
> Index: linux-2.6-submit/drivers/mfd/mc13xxx-core.c
> ===================================================================
> --- linux-2.6-submit.orig/drivers/mfd/mc13xxx-core.c 2011-03-01 22:26:40.000000000 +0100
> +++ linux-2.6-submit/drivers/mfd/mc13xxx-core.c 2011-03-02 12:24:30.000000000 +0100
> @@ -136,6 +136,9 @@
> #define MC13XXX_REVISION_FAB (0x03 << 11)
> #define MC13XXX_REVISION_ICIDCODE (0x3f << 13)
>
> +#define MC13892_POWERCTL2 15
> +#define MC13892_POWERCTL2_WDIRESET (1<<12)
> +
> #define MC13783_ADC1 44
> #define MC13783_ADC1_ADEN (1 << 0)
> #define MC13783_ADC1_RAND (1 << 1)
> @@ -715,6 +718,7 @@
> struct mc13xxx_platform_data *pdata = dev_get_platdata(&spi->dev);
> enum mc13xxx_id id;
> int ret;
> + unsigned int val;
>
> mc13xxx = kzalloc(sizeof(*mc13xxx), GFP_KERNEL);
> if (!mc13xxx)
> @@ -734,6 +738,15 @@
> if (ret || id == MC13XXX_ID_INVALID)
> goto err_revision;
>
> + if ((id == MC13XXX_ID_MC13892) && pdata->wdi_reboot) {
> + /* allows to reboot on wdi event */
> + ret = mc13xxx_reg_read(mc13xxx, MC13892_POWERCTL2, &val);
> + if (!ret) {
> + val |= MC13892_POWERCTL2_WDIRESET;
> + mc13xxx_reg_write(mc13xxx, MC13892_POWERCTL2, val);
> + }
> + }
> +
> /* mask all irqs */
> ret = mc13xxx_reg_write(mc13xxx, MC13XXX_IRQMASK0, 0x00ffffff);
> if (ret)
> Index: linux-2.6-submit/include/linux/mfd/mc13xxx.h
> ===================================================================
> --- linux-2.6-submit.orig/include/linux/mfd/mc13xxx.h 2011-03-01 22:30:59.000000000 +0100
> +++ linux-2.6-submit/include/linux/mfd/mc13xxx.h 2011-03-01 22:31:27.000000000 +0100
> @@ -149,6 +149,8 @@
git diff provide some info about the context after the @@ hunk header.
I consider this really useful. GNU diff is able to do this, too (option
-p).
> int num_regulators;
> struct mc13xxx_regulator_init_data *regulators;
> struct mc13xxx_leds_platform_data *leds;
> +
> + unsigned int wdi_reboot;
there is already a member .flags. What about defining another bit for
that?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [patch v2 1/2] mc13892: reboot on wdi event
From: Arnaud Patard (Rtp) @ 2011-03-02 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302194716.GH22310@pengutronix.de>
Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> writes:
Hi,
> Hello Arnaud,
>
> On Wed, Mar 02, 2011 at 07:45:13PM +0100, Arnaud Patard wrote:
>> By default, on wdi (watchdog input) event the mc13892 is powering off.
>> This patch allows to change this behaviour throught platform_data.
>>
>> v2:
>> - move to mc13xxx-core
>> - make it configurable
>>
>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>>
>> Index: linux-2.6-submit/drivers/mfd/mc13xxx-core.c
>> ===================================================================
>> --- linux-2.6-submit.orig/drivers/mfd/mc13xxx-core.c 2011-03-01 22:26:40.000000000 +0100
>> +++ linux-2.6-submit/drivers/mfd/mc13xxx-core.c 2011-03-02 12:24:30.000000000 +0100
>> @@ -136,6 +136,9 @@
>> #define MC13XXX_REVISION_FAB (0x03 << 11)
>> #define MC13XXX_REVISION_ICIDCODE (0x3f << 13)
>>
>> +#define MC13892_POWERCTL2 15
>> +#define MC13892_POWERCTL2_WDIRESET (1<<12)
>> +
>> #define MC13783_ADC1 44
>> #define MC13783_ADC1_ADEN (1 << 0)
>> #define MC13783_ADC1_RAND (1 << 1)
>> @@ -715,6 +718,7 @@
>> struct mc13xxx_platform_data *pdata = dev_get_platdata(&spi->dev);
>> enum mc13xxx_id id;
>> int ret;
>> + unsigned int val;
>>
>> mc13xxx = kzalloc(sizeof(*mc13xxx), GFP_KERNEL);
>> if (!mc13xxx)
>> @@ -734,6 +738,15 @@
>> if (ret || id == MC13XXX_ID_INVALID)
>> goto err_revision;
>>
>> + if ((id == MC13XXX_ID_MC13892) && pdata->wdi_reboot) {
>> + /* allows to reboot on wdi event */
>> + ret = mc13xxx_reg_read(mc13xxx, MC13892_POWERCTL2, &val);
>> + if (!ret) {
>> + val |= MC13892_POWERCTL2_WDIRESET;
>> + mc13xxx_reg_write(mc13xxx, MC13892_POWERCTL2, val);
>> + }
>> + }
>> +
>> /* mask all irqs */
>> ret = mc13xxx_reg_write(mc13xxx, MC13XXX_IRQMASK0, 0x00ffffff);
>> if (ret)
>> Index: linux-2.6-submit/include/linux/mfd/mc13xxx.h
>> ===================================================================
>> --- linux-2.6-submit.orig/include/linux/mfd/mc13xxx.h 2011-03-01 22:30:59.000000000 +0100
>> +++ linux-2.6-submit/include/linux/mfd/mc13xxx.h 2011-03-01 22:31:27.000000000 +0100
>> @@ -149,6 +149,8 @@
> git diff provide some info about the context after the @@ hunk header.
> I consider this really useful. GNU diff is able to do this, too (option
> -p).
>
hmm... I forgot to configure quilt to do that. sorry.
>> int num_regulators;
>> struct mc13xxx_regulator_init_data *regulators;
>> struct mc13xxx_leds_platform_data *leds;
>> +
>> + unsigned int wdi_reboot;
> there is already a member .flags. What about defining another bit for
> that?
>
I thought that using the .flags member for that was kind of misusing it
as for now, it's only used to enable or disable some mc13xxx sub device.
Arnaud
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Ryan Mallon @ 2011-03-02 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6E04DF.3070905@stericsson.com>
On 03/02/2011 09:50 PM, Maxime Coquelin wrote:
> On 03/02/2011 04:54 AM, Ryan Mallon wrote:
>> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>>> The only real objection I have to adding the SoC family information is
>>>> basically to discourage it being abused by userspace. I can see it
>>>> being
>>>> useful in debug situations, but I can also see stupid userspace
>>>> applications explicitly testing for some particular SoC, rather than
>>>> more correctly (IMHO) checking for presence of certain drivers etc.
>>> True, but so many other things could be misused by stupid userspace
>>> programs. When there are legitimate usecases, I think we shouldn't
>>> prevent them just because we think a stupid userspace program could
>>> misuse it.
>>>
>>> Again, although you might not be gung-ho about this, I think I have at
>>> least made you indifferent/mildly supportive to adding socinfo. If you
>>> don't mind, I would like to wait for others to chime in before
>>> continuing this discussion.
>> Agreed.
>>
>> In general I am in support of having the SoC information exposed
>> somewhere. I think we just want to be careful that it doesn't become a
>> dumping ground for anything and everything SoC related whether the
>> information is useful or not. I think each piece of exposed information
>> should have a genuine use case, not just "because we can".
> I definitely agree we should not export every SoC-related information
> just because we can do it.
> The first goal of this interface was to export some SoCs IDs, as we need
> this kind of information for some user-space tools.
> Does someone need to export other information than the mach name and
> some IDs?
>
> As proposed in my previous mail, do you agree to have a unified file for
> all vendors, which exports the unique silicon ID of the chip?
As mentioned earlier, on ep93xx we would like to export the Maverick
Crunch ID, which is a unique identifier for the chip.
I think the ABI should specify a minimum set of values which are
guaranteed to be provided on all SoCs, but allow individual SoCs to
provide additional information as necessary.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: Hans J. Koch @ 2011-03-02 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299065886-30099-2-git-send-email-pratheesh@ti.com>
On Wed, Mar 02, 2011 at 05:08:06PM +0530, Pratheesh Gangadhar wrote:
> This patch implements PRUSS (Programmable Real-time Unit Sub System)
> UIO driver which exports SOC resources associated with PRUSS like
> I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> processors which is efficient in performing embedded tasks that
> require manipulation of packed memory mapped data structures and
> handling system events that have tight real time constraints. This
> driver is currently supported on Texas Instruments DA850, AM18xx and
> OMAP-L138 devices.
> For example, PRUSS runs firmware for real-time critical industrial
> communication data link layer and communicates with application stack
> running in user space via shared memory and IRQs.
>
> Signed-off-by: Pratheesh Gangadhar <pratheesh@ti.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/uio/Kconfig | 17 ++++
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_pruss.c | 226 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 244 insertions(+), 0 deletions(-)
> create mode 100644 drivers/uio/uio_pruss.c
That looks good now, I don't see any further issues. But you should
address Arnd's comment about that __iomem stuff. It's a bit nit-picking,
but he's right, ioremap() returns void __iomem *, and uio_mem.internal_addr
also has that type.
> +static struct uio_info *info;
> +static dma_addr_t sram_paddr, ddr_paddr;
> +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
So the correct thing would be
static void __iomem *prussio_vaddr;
static void *sram_vaddr, *ddr_vaddr;
Thanks,
Hans
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: Arnd Bergmann @ 2011-03-02 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302200956.GB23818@local>
On Wednesday 02 March 2011 21:09:56 Hans J. Koch wrote:
> > +static struct uio_info *info;
> > +static dma_addr_t sram_paddr, ddr_paddr;
> > +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
>
> So the correct thing would be
>
> static void __iomem *prussio_vaddr;
> static void *sram_vaddr, *ddr_vaddr;
I also commented that it should not be a global variable at
all, but a dynamic data structure referenced from the device.
Not important, but Pratheesh said he'd change it. If it stays
a global variable, I'd at least expect an explanation why
the static variable is considered better in this case.
Arnd
^ permalink raw reply
* [RFC PATCH 13/20] ARM: msm: dynamically register local timer setup function
From: David Brown @ 2011-03-02 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299084806-16546-14-git-send-email-marc.zyngier@arm.com>
On Wed, Mar 02 2011, Marc Zyngier wrote:
> ---
> arch/arm/mach-msm/timer.c | 22 +++++++++++++++++++---
> 1 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
> index 56f920c..e029363 100644
> --- a/arch/arm/mach-msm/timer.c
> +++ b/arch/arm/mach-msm/timer.c
> @@ -228,6 +243,8 @@ static void __init msm_timer_init(void)
> writel(DGT_CLK_CTL_DIV_4, MSM_TMR_BASE + DGT_CLK_CTL);
> #endif
>
> + percpu_timer_register(msm_timer_ops_ptr);
> +
> for (i = 0; i < ARRAY_SIZE(msm_clocks); i++) {
> struct msm_clock *clock = &msm_clocks[i];
> struct clock_event_device *ce = &clock->clockevent;
I'm having difficulty figuring out what tree/branch these patches are
based off of, so I haven't been able to test this, yet. But, so far,
the MSM changes look coherent.
If you can give me a ref for your source tree, I can try to do some
testing of these changes to make sure nothing is broken by it.
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [patch 1/1] t5325: add audio support
From: Arnaud Patard (Rtp) @ 2011-03-02 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110118072802.620728772@rtp-net.org>
Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
Hi,
> This patch declares the i2c audio codec and initialise audio.
> It's adding the alc5621 codec in the i2c board info and is calling
> kirkwood_audio_init() to initialize kirkwood audio.
Please, can someone tell me what's wrong in this patch ? I'd like to see
this patch merged so if something needs to be fixed, please tell it to
me.
Thanks,
Arnaud
^ permalink raw reply
* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Thomas Gleixner @ 2011-03-02 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302191744.GA13179@n2100.arm.linux.org.uk>
On Wed, 2 Mar 2011, Russell King - ARM Linux wrote:
> On Wed, Mar 02, 2011 at 10:25:02AM +0100, Thomas Gleixner wrote:
> > On Wed, 2 Mar 2011, Russell King - ARM Linux wrote:
> > > On Tue, Mar 01, 2011 at 10:29:37PM +0100, Thomas Gleixner wrote:
> > > > Errm. I did never say that we disable the parent interrupt by any
> > > > means except when the chained handler explicitely wants to do that,
> > > > which is pretty much pointlesss nowadays, as we run all interrupt
> > > > handlers with interrupts disabled.
> > >
> > > And that's now why some platforms struggle to work, and we're having
> > > to bodge around this - like the ARM platforms with MMC support. Like
> >
> > Whats the problem for MMC?
>
> The FIFO interrupt gets completely buggered by USB interrupts such that
> we can't read data fast enough. With the old IRQF_DISABLED system,
> the FIFO interrupt was marked IRQF_DISABLED as it was *fast* and needed
> not to be interrupted. Other interrupts didn't have IRQF_DISABLED set.
>
> That means such interrupts can be handled while other longer interrupts
> are in progress. All that's gone out of the window now that all IRQ
> handlers are run with IRQs permanently disabled.
>
> And when this kind of behaviour becomes system specific (eg, the USB
> device driver doesn't have this problem on x86 so why should it change)
I wouldn't say that. USB is known to be a trouble spot even on
x86. And Linus argued for enforcing IRQ_DISABLED to weed out such
crap. Anything which runs longer than a few micro seconds in the hard
interrupt context needs to be fixed.
> I haven't noticed PATA getting this support. So how do platforms force
> device drivers which turn out to be problematical to conform to their
> timing issues when there wasn't a problem with previous kernels?
As I said above. PATA was talked about going threaded for years, but
nobody cared as the irq enabled vs. IRQ_DISABLED mode made things
magically work most of the time, except when you added some other
random driver, which required IRQ_DISABLED as well and spent a
millisecond and more in its handler. I know that pain and I wasted
enough time with the wreckage caused by long running handlers.
So at some point we had to make a decision:
Either let the status quo, which is not satisfying at all and causes
headache left and right, or create a situation which enforces that
shit gets cleaned up.
The general consensus was that enforcing the shit to be cleaned up is
the better long term strategy even when it causes some short term
irritation.
If that hits ARM full force, sorry, but it's not my lonely decision in
order to get an Guinness Book entry.
I assume, you know which drivers are responsible for this kind of
wreckage. Could you provide a list?
> > > I *violently* disagree with the direction that genirq is heading. It's
> > > *actively* breaking stuff. What's really annoying is that problems like
> > > the above I did point out, but you seem happy to completely ignore them.
> > > The result is that more and more ARM platforms *are* becoming utterly
> > > useless, or requiring additional complexity being shoved into subsystems
> > > to cope with this crap.
> > >
> > > What we need is a *decent* IRQ support system. Not something created out
> > > of religious arguments which is what we have now.
> >
> > I'm not religious about it, at least not more than you with your total
> > refusement to distinguish between special case oddball FPGA demux and
> > bog standard functional irq chips.
>
> Clearly you don't want to know about the problems all this stuff is
> causing. Maybe you like being responsible for breaking the most ARM
I want to hear about problems and I'm the least person who refuses to
help. And you are very well aware of that.
Let's take it the other way around. Do you want to know about the pain
of maintaining generic infrastructure like this and being blocked to
change a few things in the core code just because nobody is talking to
you and takes it for granted, that fiddling in the guts of the generic
code by circumventing it (and I'm not talking about chained handlers
here) is a good idea, just because the header files are public
accessible via include/linux ?
> platforms with your changes - are you trying for an entry in the
> Guiness Book of World Records for this, because I think that's where
> you're heading.
Didn't know that they have a category for that. Can you point me to
the website where to apply?
> I don't agree with the distinction that you're trying to make. It only
> works for a simple subset of cases - but it seems you're overall attitude
> is that you only care about a small subset of easy cases and to hell
> with everything else.
That's not true at all. I said more than once that I understand why
you want to keep the original concept of those chained handlers and
I'm not going to change anything about them. I saw it a bit too
simplistic at the beginning of the discussion and admitted that and
corrected my POV right away.
I'm merily trying to help and provide infrastructure for repeating
patterns. If those patterns happen to be the simple ones, then we
still want to avoid copied and duplicated code all over the place.
Again, I'm not trying to kill the current chained handlers at all
neither do I believe that everything is nail because we have a
hammer. I'm trying to understand the problems instead of being fixated
on a method which turned out to solve one of them.
Thanks,
tglx
^ permalink raw reply
* about MISC_DEVICES not being enabled in many defconfigs
From: Uwe Kleine-König @ 2011-03-02 20:48 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
while working on an defconfig (arm/mx27) I noticed that just updating
it[1] results in removing CONFIG_EEPROM_AT24=y. The reason is that
since commit
v2.6.36-5965-g5f2365d (misc devices: do not enable by default)
MISC_DEVICES isn't enabled anymore by default. So all defconfigs that
have CONFIG_SOME_SYMBOL=y (or =m) (with SOME_SYMBOL depending on
MISC_DEVICES) but not CONFIG_MISC_DEVICES=y suffer from the same
problem.
As a defconfig that was reduced before 5f2365d obviously didn't have
CONFIG_MISC_DEVICES=y many defconfigs have that problem.
I did the following to (hopefully) find all affected defconfigs:
$ git describe
v2.6.38-rc7
$ git ls-files drivers/misc | grep Kconfig | xargs grep -h ^config | sed 's/config \(.*\)/CONFIG_\1=/' > miscsymbols
$ git ls-files *defconfig | xargs grep -L CONFIG_MISC_DEVICES= | xargs grep -F -f miscsymbols
arch/arm/configs/afeb9260_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/afeb9260_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/at572d940hfek_defconfig:CONFIG_ATMEL_TCLIB=y
arch/arm/configs/at572d940hfek_defconfig:CONFIG_ATMEL_SSC=m
arch/arm/configs/at572d940hfek_defconfig:CONFIG_SENSORS_TSL2550=m
arch/arm/configs/at572d940hfek_defconfig:CONFIG_DS1682=m
arch/arm/configs/at91cap9adk_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/at91rm9200_defconfig:CONFIG_ATMEL_TCLIB=y
arch/arm/configs/at91rm9200_defconfig:CONFIG_EEPROM_LEGACY=m
arch/arm/configs/at91sam9260ek_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/at91sam9261ek_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/at91sam9263ek_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/at91sam9g20ek_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/at91sam9rlek_defconfig:CONFIG_ATMEL_SSC=y
arch/arm/configs/da8xx_omapl_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/davinci_all_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/ep93xx_defconfig:CONFIG_EEPROM_LEGACY=y
arch/arm/configs/ixp2000_defconfig:CONFIG_EEPROM_LEGACY=y
arch/arm/configs/ixp23xx_defconfig:CONFIG_EEPROM_LEGACY=y
arch/arm/configs/ixp4xx_defconfig:CONFIG_EEPROM_LEGACY=y
arch/arm/configs/mini2440_defconfig:CONFIG_SENSORS_TSL2550=m
arch/arm/configs/mx27_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/mx3_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/neocore926_defconfig:CONFIG_ATMEL_PWM=y
arch/arm/configs/neocore926_defconfig:CONFIG_ATMEL_TCLIB=y
arch/arm/configs/omap2plus_defconfig:CONFIG_EEPROM_LEGACY=y
arch/arm/configs/pcontrol_g20_defconfig:CONFIG_ATMEL_TCLIB=y
arch/arm/configs/pcontrol_g20_defconfig:CONFIG_EEPROM_AT24=m
arch/arm/configs/pnx4008_defconfig:CONFIG_EEPROM_LEGACY=m
arch/arm/configs/raumfeld_defconfig:CONFIG_ISL29003=y
arch/arm/configs/raumfeld_defconfig:CONFIG_TI_DAC7512=y
arch/arm/configs/realview-smp_defconfig:CONFIG_ARM_CHARLCD=y
arch/arm/configs/realview_defconfig:CONFIG_ARM_CHARLCD=y
arch/arm/configs/s3c2410_defconfig:CONFIG_EEPROM_AT25=m
arch/arm/configs/s3c2410_defconfig:CONFIG_EEPROM_LEGACY=m
arch/arm/configs/s3c2410_defconfig:CONFIG_EEPROM_93CX6=m
arch/arm/configs/s3c6400_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/s5pc100_defconfig:CONFIG_EEPROM_AT24=y
arch/arm/configs/versatile_defconfig:CONFIG_EEPROM_LEGACY=m
arch/arm/configs/zeus_defconfig:CONFIG_EEPROM_AT24=m
arch/avr32/configs/atngw100_mrmt_defconfig:CONFIG_ATMEL_PWM=y
arch/avr32/configs/favr-32_defconfig:CONFIG_ATMEL_PWM=m
arch/avr32/configs/favr-32_defconfig:CONFIG_ATMEL_TCLIB=y
arch/avr32/configs/favr-32_defconfig:CONFIG_ATMEL_SSC=m
arch/avr32/configs/hammerhead_defconfig:CONFIG_ATMEL_TCLIB=y
arch/avr32/configs/merisc_defconfig:CONFIG_ATMEL_PWM=y
arch/avr32/configs/merisc_defconfig:CONFIG_ATMEL_SSC=y
arch/avr32/configs/mimc200_defconfig:CONFIG_ATMEL_TCLIB=y
arch/avr32/configs/mimc200_defconfig:CONFIG_EEPROM_AT24=y
arch/avr32/configs/mimc200_defconfig:CONFIG_EEPROM_AT25=y
arch/blackfin/configs/BlackStamp_defconfig:CONFIG_EEPROM_AT25=y
arch/blackfin/configs/H8606_defconfig:CONFIG_EEPROM_AT25=y
arch/blackfin/configs/SRV1_defconfig:CONFIG_EEPROM_AT25=m
arch/ia64/configs/generic_defconfig:CONFIG_SGI_IOC4=y
arch/ia64/configs/generic_defconfig:CONFIG_SGI_XP=m
arch/ia64/configs/gensparse_defconfig:CONFIG_SGI_IOC4=y
arch/mips/configs/bigsur_defconfig:CONFIG_SGI_IOC4=m
arch/mips/configs/bigsur_defconfig:CONFIG_EEPROM_LEGACY=y
arch/mips/configs/bigsur_defconfig:CONFIG_EEPROM_MAX6875=y
arch/mips/configs/gpr_defconfig:CONFIG_TIFM_CORE=m
arch/mips/configs/ip32_defconfig:CONFIG_SGI_IOC4=y
arch/mips/configs/markeins_defconfig:CONFIG_SGI_IOC4=m
arch/mips/configs/pnx8550-jbs_defconfig:CONFIG_SGI_IOC4=m
arch/mips/configs/rm200_defconfig:CONFIG_SGI_IOC4=m
arch/mips/configs/sb1250-swarm_defconfig:CONFIG_SGI_IOC4=m
arch/mips/configs/wrppmc_defconfig:CONFIG_SGI_IOC4=m
arch/mips/configs/yosemite_defconfig:CONFIG_SGI_IOC4=m
arch/powerpc/configs/44x/warp_defconfig:CONFIG_EEPROM_AT24=y
arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/86xx/gef_ppc9a_defconfig:CONFIG_DS1682=y
arch/powerpc/configs/86xx/gef_sbc310_defconfig:CONFIG_DS1682=y
arch/powerpc/configs/86xx/gef_sbc610_defconfig:CONFIG_DS1682=y
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/e55xx_smp_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/linkstation_defconfig:CONFIG_EEPROM_LEGACY=m
arch/powerpc/configs/mpc512x_defconfig:CONFIG_EEPROM_AT24=y
arch/powerpc/configs/mpc5200_defconfig:CONFIG_EEPROM_AT24=y
arch/powerpc/configs/mpc85xx_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/mpc85xx_smp_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/mpc86xx_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/pasemi_defconfig:CONFIG_EEPROM_LEGACY=y
arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ENCLOSURE_SERVICES=m
arch/powerpc/configs/ppc6xx_defconfig:CONFIG_SENSORS_TSL2550=m
arch/powerpc/configs/ppc6xx_defconfig:CONFIG_EEPROM_AT24=m
arch/powerpc/configs/ppc6xx_defconfig:CONFIG_EEPROM_LEGACY=m
arch/powerpc/configs/ppc6xx_defconfig:CONFIG_EEPROM_MAX6875=m
arch/powerpc/configs/ppc6xx_defconfig:CONFIG_EEPROM_93CX6=m
arch/sh/configs/se7206_defconfig:CONFIG_EEPROM_93CX6=y
(For those wondering about the commands above: A line
arch/$arch/configs/xyz_defconfig:CONFIG_SOME_DEVICE=y
means here, that running
make ARCH=$arch xyz_defconfig
results in a config without SOME_DEVICE.
I don't know if that bothers you, but if it does, you should add
CONFIG_MISC_DEVICES=y
to your defconfig.
Just to let you know ...
Best regards
Uwe
[1] make mx27_defconfig
make savedefconfig
mv defconfig arch/arm/configs/mx27_defconfig
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: Thomas Gleixner @ 2011-03-02 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201103022123.38050.arnd@arndb.de>
On Wed, 2 Mar 2011, Arnd Bergmann wrote:
> On Wednesday 02 March 2011 21:09:56 Hans J. Koch wrote:
> > > +static struct uio_info *info;
> > > +static dma_addr_t sram_paddr, ddr_paddr;
> > > +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
> >
> > So the correct thing would be
> >
> > static void __iomem *prussio_vaddr;
> > static void *sram_vaddr, *ddr_vaddr;
>
> I also commented that it should not be a global variable at
> all, but a dynamic data structure referenced from the device.
>
> Not important, but Pratheesh said he'd change it. If it stays
> a global variable, I'd at least expect an explanation why
> the static variable is considered better in this case.
I did not pick at that, because there is no indicator that we'll see
more than one PRUSS unit per SoC in the forseeable future.
Thanks,
tglx
^ permalink raw reply
* [patch 1/1] t5325: add audio support
From: Nicolas Pitre @ 2011-03-02 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tyflw98o.fsf@lebrac.rtp-net.org>
On Wed, 2 Mar 2011, Arnaud Patard wrote:
> Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
>
> Hi,
>
> > This patch declares the i2c audio codec and initialise audio.
> > It's adding the alc5621 codec in the i2c board info and is calling
> > kirkwood_audio_init() to initialize kirkwood audio.
>
> Please, can someone tell me what's wrong in this patch ? I'd like to see
> this patch merged so if something needs to be fixed, please tell it to
> me.
I don't know. Could you make sure it still applies to the latest tree
and repost it?
Nicolas
^ permalink raw reply
* [PATCH 0/4] Initial patches for MSM display update
From: Carl Vanderlip @ 2011-03-02 21:15 UTC (permalink / raw)
To: linux-arm-kernel
These are the first series of a set of patches to update the MSM display
drivers to support newer MDP versions and display modes (while also providing
a base for future display development). The original source for these patches
is the Google Android kernel tree located here:
http://android.git.kernel.org/kernel/msm.git
Arve Hj?nnev?g (1):
[ARM] msm_fb: Fix framebuffer console
Dima Zavin (3):
video: msmfb: Put the partial update magic value into the fix_screen
struct.
[ARM] msm: mdp: Add support for RGBX 8888 image format.
[ARM] msm: mdp: Set the correct pack pattern for XRGB/ARGB
drivers/video/msm/mdp_hw.h | 11 +++++++++--
drivers/video/msm/mdp_ppp.c | 1 +
drivers/video/msm/msm_fb.c | 16 ++++++++++++++--
include/linux/msm_mdp.h | 1 +
4 files changed, 25 insertions(+), 4 deletions(-)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ 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