* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Barry Song @ 2011-09-17 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917150246.GH16381@n2100.arm.linux.org.uk>
2011/9/17 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Fri, Sep 16, 2011 at 02:56:00AM -0700, Barry Song wrote:
>> +static int sirfsoc_dma_slave_config(struct sirfsoc_dma_chan *schan,
>> + ? ? struct dma_slave_config *config)
>> +{
>> + ? ? u32 addr, direction;
>> + ? ? unsigned long flags;
>> +
>> + ? ? switch (config->direction) {
>
> config->direction is deprecated, please don't use it.
ok.
>
>> + ? ? case DMA_FROM_DEVICE:
>> + ? ? ? ? ? ? direction = 0;
>> + ? ? ? ? ? ? addr = config->dst_addr;
>> + ? ? ? ? ? ? break;
>> +
>> + ? ? case DMA_TO_DEVICE:
>> + ? ? ? ? ? ? direction = 1;
>> + ? ? ? ? ? ? addr = config->src_addr;
>> + ? ? ? ? ? ? break;
>> +
>> + ? ? default:
>> + ? ? ? ? ? ? return -EINVAL;
>> + ? ? }
>> +
>> + ? ? if ((config->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES) ||
>> + ? ? ? ? ? ? (config->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES))
>> + ? ? ? ? ? ? return -EINVAL;
>> +
>> + ? ? spin_lock_irqsave(&schan->lock, flags);
>> + ? ? schan->addr = addr;
>> + ? ? schan->direction = direction;
>> + ? ? schan->mode = (config->src_maxburst == 4 ? 1 : 0);
>
> Please store the source address, destination address, and mode separately
> for each direction. ?You should then select from that at prepare time.
the dmac has fixed route. every channel has fixed function. one
channel is for one device and one direction. for example, spi0 can
have two fixed channel: spi0-tx, spi0-rx.
then for every schan, device address is always fixed and we don't care
it at all. we only need to write the memory address to dmac address
register.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-barry
^ permalink raw reply
* [PATCH 16/19] ARM: move iotable mappings within the vmalloc region
From: Russell King - ARM Linux @ 2011-09-17 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316156850-31013-17-git-send-email-nico@fluxnic.net>
On Fri, Sep 16, 2011 at 03:07:27AM -0400, Nicolas Pitre wrote:
> void __init iotable_init(struct map_desc *io_desc, int nr)
> {
> - int i;
> + struct map_desc *md;
> + struct vm_struct *vm;
> +
> + vm = __va(memblock_alloc(sizeof(*vm) * nr, __alignof__(*vm)));
> + memset(vm, 0, sizeof(*vm) * nr);
Any reason not to adapt early_alloc() ?
>
> - for (i = 0; i < nr; i++)
> - create_mapping(io_desc + i);
> + for (md = io_desc; nr; md++, nr--) {
> + create_mapping(md);
> + vm->addr = (void *)(md->virtual & PAGE_MASK);
> + vm->size = PAGE_ALIGN(md->length + (md->virtual & ~PAGE_MASK));
> + vm->phys_addr = __pfn_to_phys(md->pfn);
> + vm->flags = VM_IOREMAP;
> + vm->caller = iotable_init;
> + vm_area_add_early(vm++);
> + }
> }
>
> -static void * __initdata vmalloc_min = (void *)(VMALLOC_END - SZ_128M);
> +static void * __initdata vmalloc_min = (void *)(0xf0000000UL - VMALLOC_OFFSET);
This is silly. You're defining VMALLOC_END to be 0xff000000UL, and
then defining this to be 0xf0000000UL - 8MB. Why hide the 240MB
inside these constants? Why not set it to VMALLOC_END - 240MB -
VMALLOC_OFFSET - making the size in their _explicit_ instead of hidden?
> /*
> * vmalloc=size forces the vmalloc area to be exactly 'size'
> * bytes. This can be used to increase (or decrease) the vmalloc
> - * area - the default is 128m.
> + * area - the default is 240m.
> */
> static int __init early_vmalloc(char *arg)
> {
> @@ -853,6 +866,7 @@ void __init sanity_check_meminfo(void)
> #endif
> meminfo.nr_banks = j;
> memblock_set_current_limit(lowmem_limit);
> + high_memory = __va(lowmem_limit - 1) + 1;
NAK. This ends up initializing this setting twice during the boot,
potentially leading to bugs because they're both done in different ways.
You don't describe why this change is necessary so I assume that it's
part of some debugging you were trying and shouldn't be in this patch.
> @@ -977,6 +991,12 @@ static void __init devicemaps_init(struct machine_desc *mdesc)
> }
>
> /*
> + * Clear the vmalloc area.
> + */
> + for (addr = VMALLOC_START; addr < VMALLOC_END; addr += PGDIR_SIZE)
> + pmd_clear(pmd_off_k(addr));
Why not combine this with the clearance above:
for (addr = VMALLOC_END; addr; addr += PGDIR_SIZE)
pmd_clear(pmd_off_k(addr));
?
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Shawn Guo @ 2011-09-17 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917104518.GD16381@n2100.arm.linux.org.uk>
On Sat, Sep 17, 2011 at 11:45:18AM +0100, Russell King - ARM Linux wrote:
> I'm now starting to think that we don't actually want any resume code
> at the L2 level - most SoCs will be operating in non-secure mode (I
> believe it's only ARM's development platforms which operate in secure
> mode)
On imx6q, I can program PL310 without SMC call at resume entry, which
probably means imx6q is a SoC operating in secure mode.
Regards,
Shawn
> and so most of the generic code which will need to write to the
> L2 control registers on resume will fail.
^ permalink raw reply
* [PATCH 01/19] ARM: sort the meminfo array earlier
From: Russell King - ARM Linux @ 2011-09-17 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316156850-31013-2-git-send-email-nico@fluxnic.net>
On Fri, Sep 16, 2011 at 03:07:12AM -0400, Nicolas Pitre wrote:
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> The meminfo array has to be sorted before sanity_check_meminfo() can work
> properly.
This is unrelated to the patch series, so it should be separate from the
series. I don't see anything in the series depending on it.
^ permalink raw reply
* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Russell King - ARM Linux @ 2011-09-17 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316166960-20964-1-git-send-email-Baohua.Song@csr.com>
On Fri, Sep 16, 2011 at 02:56:00AM -0700, Barry Song wrote:
> +static int sirfsoc_dma_slave_config(struct sirfsoc_dma_chan *schan,
> + struct dma_slave_config *config)
> +{
> + u32 addr, direction;
> + unsigned long flags;
> +
> + switch (config->direction) {
config->direction is deprecated, please don't use it.
> + case DMA_FROM_DEVICE:
> + direction = 0;
> + addr = config->dst_addr;
> + break;
> +
> + case DMA_TO_DEVICE:
> + direction = 1;
> + addr = config->src_addr;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + if ((config->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES) ||
> + (config->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES))
> + return -EINVAL;
> +
> + spin_lock_irqsave(&schan->lock, flags);
> + schan->addr = addr;
> + schan->direction = direction;
> + schan->mode = (config->src_maxburst == 4 ? 1 : 0);
Please store the source address, destination address, and mode separately
for each direction. You should then select from that at prepare time.
^ permalink raw reply
* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Barry Song @ 2011-09-17 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY13Xum=nU2eD+DJ7Uv_8ppE+UKFUA6KD_4CP+eDG5rAaQ@mail.gmail.com>
2011/9/17 Jassi Brar <jassisinghbrar@gmail.com>:
> On Fri, Sep 16, 2011 at 3:26 PM, Barry Song <Baohua.Song@csr.com> wrote:
>
>> +static int sirfsoc_dma_slave_config(struct sirfsoc_dma_chan *schan,
>> + ? ? ? struct dma_slave_config *config)
>> +{
>> + ? ? ? u32 addr, direction;
>> + ? ? ? unsigned long flags;
>> +
>> + ? ? ? switch (config->direction) {
>> + ? ? ? case DMA_FROM_DEVICE:
>> + ? ? ? ? ? ? ? direction = 0;
>> + ? ? ? ? ? ? ? addr = config->dst_addr;
>> + ? ? ? ? ? ? ? break;
>> +
>> + ? ? ? case DMA_TO_DEVICE:
>> + ? ? ? ? ? ? ? direction = 1;
>> + ? ? ? ? ? ? ? addr = config->src_addr;
>> + ? ? ? ? ? ? ? break;
>> +
>> + ? ? ? default:
>> + ? ? ? ? ? ? ? return -EINVAL;
>> + ? ? ? }
>> +
>> + ? ? ? if ((config->src_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES) ||
>> + ? ? ? ? ? ? ? (config->dst_addr_width != DMA_SLAVE_BUSWIDTH_4_BYTES))
>> + ? ? ? ? ? ? ? return -EINVAL;
>> +
>> + ? ? ? spin_lock_irqsave(&schan->lock, flags);
>> + ? ? ? schan->addr = addr;
>> + ? ? ? schan->direction = direction;
>> + ? ? ? schan->mode = (config->src_maxburst == 4 ? 1 : 0);
>> + ? ? ? spin_unlock_irqrestore(&schan->lock, flags);
>> +
>> + ? ? ? return 0;
>> +}
> You don't need to pass as much info via dma_slave_config as you do here.
>
> dmaxfer_template.src_inc ?&& !dmaxfer_template.dst_inc ?=> DMA_TO_DEVICE
> !dmaxfer_template.src_inc ?&& dmaxfer_template.dst_inc ?=> DMA_FROM_DEVICE
it seems direct DMA_TO_DEVICE/DMA_FROM_DEVICE is more feasible and
explict to me. "dmaxfer_template.src_inc &&
!dmaxfer_template.dst_inc" is probably DMA_TO_DEVICE, but it is not
always true for all scenerios to all kinds of devices. anyway, for my
case, they are always true. so i can use them.
>
> Pass addresses using dmaxfer_template.src_start and dmaxfer_template.dst_start
> instead of dma_slave_config.dst_addr and dma_slave_config.src_addr
>
> So, currently you need dma_slave_config only to pass src_addr_width,
> dst_addr_width and src_maxburst to the dmac driver.
i agree that can decrease the calling of config. let the genxfer
decide the address of every transfer should be more flexible.
>
>
>> +
>> +static struct dma_async_tx_descriptor *sirfsoc_dma_prep_slave_sg(
>> + ? ? ? struct dma_chan *chan, struct scatterlist *sgl,
>> + ? ? ? unsigned int sg_len, enum dma_data_direction direction,
>> + ? ? ? unsigned long flags)
>> +{
>> + ? ? ? return NULL;
>> +}
>> +
> In v3 I'll remove the BUG_ON check that requires every SLAVE channel
> provides device_prep_slave_sg, so you should be able to simply discard
> this stub.
ok, that is going to make the api better.
-barry
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Russell King - ARM Linux @ 2011-09-17 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4ysZ7C7PZ7eCLyrLuUGux2U8mVknobaJ4tRdk1g97z-dA@mail.gmail.com>
On Sat, Sep 17, 2011 at 10:41:58PM +0800, Barry Song wrote:
> for aux ctrl, it is really simple. but how about the following:
>
> 393 static void __init pl310_of_setup(const struct device_node *np,
> 394 __u32 *aux_val, __u32 *aux_mask)
> 395 {
> 396 u32 data[3] = { 0, 0, 0 };
> 397 u32 tag[3] = { 0, 0, 0 };
> 398 u32 filter[2] = { 0, 0 };
> 399
> 400 of_property_read_u32_array(np, "arm,tag-latency", tag,
> ARRAY_SIZE(tag));
> 401 if (tag[0] && tag[1] && tag[2])
> 402 writel_relaxed(
> 403 ((tag[0] - 1) << L2X0_LATENCY_CTRL_RD_SHIFT) |
> 404 ((tag[1] - 1) << L2X0_LATENCY_CTRL_WR_SHIFT) |
> 405 ((tag[2] - 1) << L2X0_LATENCY_CTRL_SETUP_SHIFT),
> 406 l2x0_base + L2X0_TAG_LATENCY_CTRL);
> 407
> 408 of_property_read_u32_array(np, "arm,data-latency",
> 409 data, ARRAY_SIZE(data));
> 410 if (data[0] && data[1] && data[2])
> 411 writel_relaxed(
> 412 ((data[0] - 1) << L2X0_LATENCY_CTRL_RD_SHIFT) |
> 413 ((data[1] - 1) << L2X0_LATENCY_CTRL_WR_SHIFT) |
> 414 ((data[2] - 1) << L2X0_LATENCY_CTRL_SETUP_SHIFT),
> 415 l2x0_base + L2X0_DATA_LATENCY_CTRL);
> 416
> 417 of_property_read_u32_array(np, "arm,filter-ranges",
> 418 filter, ARRAY_SIZE(filter));
> 419 if (filter[0] && filter[1]) {
> 420 writel_relaxed(ALIGN(filter[0] + filter[1], SZ_1M),
> 421 l2x0_base + L2X0_ADDR_FILTER_END);
> 422 writel_relaxed((filter[0] & ~(SZ_1M - 1)) |
> L2X0_ADDR_FILTER_EN,
> 423 l2x0_base + L2X0_ADDR_FILTER_START);
> 424 }
> 425 }
>
> not all l2 have all these registers. for example, it seems only prima2
> has L2X0_ADDR_FILTER_START/END by now. and only some platforms set
> latency too.
Save them as normal. If there aren't the values in DT, read them in the
above functions and save the value. Then...
> > and we can do a similar thing when initializing the PL310 and resuming
> > the PL310 - add a new outer_cache callback called 'resume' to be pointed
> > at the relevant resume function which knows which registers to restore.
Do that.
> in my last reply, i also suggested this:
> struct outer_cache_fns {
> void (*inv_range)(unsigned long, unsigned long);
> void (*clean_range)(unsigned long, unsigned long);
> void (*flush_range)(unsigned long, unsigned long);
> void (*flush_all)(void);
> void (*inv_all)(void);
> void (*disable)(void);
> #ifdef CONFIG_OUTER_CACHE_SYNC
> void (*sync)(void);
> #endif
> void (*set_debug)(unsigned long);
> + void (*save)(void);
> + void (*restore)(void);
> };
>
> but it looks we only need resume since we can save all in init phase:
Correct.
> > That's not possible in SoCs operating in non-secure mode from generic
> > code, as some of these registers will not be accessible. ?They can only
> > be programmed from platform specific code due to the complexities of
> > dealing with the abhorrent secure monitor stuff.
> >
> > I'm now starting to think that we don't actually want any resume code
> > at the L2 level - most SoCs will be operating in non-secure mode (I
> > believe it's only ARM's development platforms which operate in secure
> > mode) and so most of the generic code which will need to write to the
> > L2 control registers on resume will fail.
>
> that is probably real. at least our team never get any requirement to
> use secure mode.
So probably the best we can do in generic code is present platform code
with a data structure describing the intended register values which were
used at init time, and we leave it to platform code to do the necessary
reprogramming that's required in the way that's required for the
abhorrent secure monitor on their platform.
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Barry Song @ 2011-09-17 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917104518.GD16381@n2100.arm.linux.org.uk>
2011/9/17 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Fri, Sep 16, 2011 at 11:24:36AM +0800, Barry Song wrote:
>> if we have a save/restore interface, it looks it will be very
>> complicated. different l2 need to save different registers.
>
> Why? ?It's quite simple as far as I can see:
>
> static u32 l2_aux_ctrl;
>
> void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
> {
> ? ? ? ?...
> ? ? ? ?aux = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
>
> ? ? ? ?aux &= aux_mask;
> ? ? ? ?aux |= aux_val;
>
> ? ? ? ?l2_aux_ctrl = aux;
> ? ? ? ?...
> }
>
> void l2x0_resume(void)
> {
> ? ? ? ?bool need_setup = false;
>
> ? ? ? ?if (l2_aux_ctrl != readl_relaxed(l2x0_base + L2X0_AUX_CTRL))
> ? ? ? ? ? ? ? ?need_setup = true;
>
> ? ? ? ?if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
> ? ? ? ? ? ? ? ?/* Make sure that I&D is not locked down when starting */
> ? ? ? ? ? ? ? ?l2x0_unlock(cache_id);
>
> ? ? ? ? ? ? ? ?/* l2x0 controller is disabled */
> ? ? ? ? ? ? ? ?writel_relaxed(l2_aux_ctrl, l2x0_base + L2X0_AUX_CTRL);
>
> ? ? ? ? ? ? ? ?l2x0_inv_all();
>
> ? ? ? ? ? ? ? ?/* enable L2X0 */
> ? ? ? ? ? ? ? ?writel_relaxed(1, l2x0_base + L2X0_CTRL);
> ? ? ? ?}
> }
>
for aux ctrl, it is really simple. but how about the following:
393 static void __init pl310_of_setup(const struct device_node *np,
394 __u32 *aux_val, __u32 *aux_mask)
395 {
396 u32 data[3] = { 0, 0, 0 };
397 u32 tag[3] = { 0, 0, 0 };
398 u32 filter[2] = { 0, 0 };
399
400 of_property_read_u32_array(np, "arm,tag-latency", tag,
ARRAY_SIZE(tag));
401 if (tag[0] && tag[1] && tag[2])
402 writel_relaxed(
403 ((tag[0] - 1) << L2X0_LATENCY_CTRL_RD_SHIFT) |
404 ((tag[1] - 1) << L2X0_LATENCY_CTRL_WR_SHIFT) |
405 ((tag[2] - 1) << L2X0_LATENCY_CTRL_SETUP_SHIFT),
406 l2x0_base + L2X0_TAG_LATENCY_CTRL);
407
408 of_property_read_u32_array(np, "arm,data-latency",
409 data, ARRAY_SIZE(data));
410 if (data[0] && data[1] && data[2])
411 writel_relaxed(
412 ((data[0] - 1) << L2X0_LATENCY_CTRL_RD_SHIFT) |
413 ((data[1] - 1) << L2X0_LATENCY_CTRL_WR_SHIFT) |
414 ((data[2] - 1) << L2X0_LATENCY_CTRL_SETUP_SHIFT),
415 l2x0_base + L2X0_DATA_LATENCY_CTRL);
416
417 of_property_read_u32_array(np, "arm,filter-ranges",
418 filter, ARRAY_SIZE(filter));
419 if (filter[0] && filter[1]) {
420 writel_relaxed(ALIGN(filter[0] + filter[1], SZ_1M),
421 l2x0_base + L2X0_ADDR_FILTER_END);
422 writel_relaxed((filter[0] & ~(SZ_1M - 1)) |
L2X0_ADDR_FILTER_EN,
423 l2x0_base + L2X0_ADDR_FILTER_START);
424 }
425 }
not all l2 have all these registers. for example, it seems only prima2
has L2X0_ADDR_FILTER_START/END by now. and only some platforms set
latency too.
one possible way is that we save one register if we have the related
property in dts. but it can be wrong too. we can't decide whether we
should save one register only according to whether dt has the
property. for example, if bootloader has setup all of them when cold
boot, users maybe don't add these "arm,data-latency" prop in dts at
all.
it seems we need some other ways to know what we should save for
latency ctrl, filter range....
> and we can do a similar thing when initializing the PL310 and resuming
> the PL310 - add a new outer_cache callback called 'resume' to be pointed
> at the relevant resume function which knows which registers to restore.
in my last reply, i also suggested this:
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
void (*flush_range)(unsigned long, unsigned long);
void (*flush_all)(void);
void (*inv_all)(void);
void (*disable)(void);
#ifdef CONFIG_OUTER_CACHE_SYNC
void (*sync)(void);
#endif
void (*set_debug)(unsigned long);
+ void (*save)(void);
+ void (*restore)(void);
};
but it looks we only need resume since we can save all in init phase:
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
void (*flush_range)(unsigned long, unsigned long);
void (*flush_all)(void);
void (*inv_all)(void);
void (*disable)(void);
#ifdef CONFIG_OUTER_CACHE_SYNC
void (*sync)(void);
#endif
void (*set_debug)(unsigned long);
+ void (*resume)(void);
};
>
>> when we resume, we must disable l2 if bootloader has enabled it and
>> restore all registers.
>
> That's not possible in SoCs operating in non-secure mode from generic
> code, as some of these registers will not be accessible. ?They can only
> be programmed from platform specific code due to the complexities of
> dealing with the abhorrent secure monitor stuff.
>
> I'm now starting to think that we don't actually want any resume code
> at the L2 level - most SoCs will be operating in non-secure mode (I
> believe it's only ARM's development platforms which operate in secure
> mode) and so most of the generic code which will need to write to the
> L2 control registers on resume will fail.
that is probably real. at least our team never get any requirement to
use secure mode.
>
> Even re-calling the initialization functions probably does nothing on
> parts operating in secure mode - whether at boot or at resume.
>
-barry
^ permalink raw reply
* [ltt-dev] LTTng 2.0 on ARM
From: Jon Medhurst (Tixy) @ 2011-09-17 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110916162507.GB2100@arm.com>
On Fri, 2011-09-16 at 17:25 +0100, Dave Martin wrote:
> On Wed, Sep 14, 2011 at 05:27:08PM +0100, Jon Medhurst (Tixy) wrote:
> > This is the same issue I found recently with kprobes [1]. There is also
> > an inconsistency as function symbols in loadable module do have bit zero
> > set, but if the module is built-in then bit zero is clear.
>
> Does that mean that some different infrastructure is used to get the module
> symbols compared with kallsyms?
Yes, there's different infrastructure to handle symbols in loadable
modules compared to those in the kernel binary. I mentioned this in [1],
or in your Linaro inbox on 29th Aug ;-)
> That feels nasty -- they should at least
> be consistent...
I agree, getting them consistent would solve half the problem.
--
Tixy
[1] http://www.spinics.net/lists/arm-kernel/msg138283.html
^ permalink raw reply
* READ THIS: the next mach-types update
From: Russell King - ARM Linux @ 2011-09-17 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B03B4C80171@dbde02.ent.ti.com>
On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote:
> But since I had submitted v1 (see [1]) and am working on v2 post review, can you
> please suggest how to go about it as I will need the above for adding support
> for TI8148 EVM?
The answer you require is in this statement:
# This is a cut-down version of the file; it contains only machines that
# are merged into mainline or have been edited in the machine database
# within the last 12 months. References to machine_is_NAME() do not count!
which highlights the policy. The key thing there is "edited".
^ permalink raw reply
* READ THIS: the next mach-types update
From: Pedanekar, Hemant @ 2011-09-17 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915102528.GI6267@n2100.arm.linux.org.uk>
Hello,
linux-arm-kernel-bounces at lists.infradead.org wrote on :
> I'm going to be merging a mach-types update (the cut-down and the
> policy-conforming version) for the next merge window. This will mean
> that things WILL BREAK, and I will not notice that things have broken.
>
> In order to fix this, entries need to be fixed to conform to the
> requirements - where the machine_is_xxx() name is the same as the
> MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
>
> Moreover, entries older than 12 months which have not been merged will
> be removed. It is not possible to automatically check for machine_is_xxx()
> usages as these could conflict with other architectures, and I'm
> certainly NOT checking for them by hand (I estimate that'd take a
> significant amount of manual effort to do.) What that means
> is that it
> is _important_ to get the core platform support in _first_ before any
> drivers which may make use of this.
>
> The following will be deleted from the file this time around are:
[...]
> -ti8148evm MACH_TI8148EVM TI8148EVM 3004
I guess this was removed due to being older than 12 months.
But since I had submitted v1 (see [1]) and am working on v2 post review, can you
please suggest how to go about it as I will need the above for adding support
for TI8148 EVM?
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg53457.html
Thanks.
Hemant
^ permalink raw reply
* [PATCH] ARM: pxa/cm-x300: properly set bt_reset pin
From: Axel Lin @ 2011-09-17 14:15 UTC (permalink / raw)
To: linux-arm-kernel
Fix below build warning and properly set bt_reset pin.
CC arch/arm/mach-pxa/cm-x300.o
arch/arm/mach-pxa/cm-x300.c: In function 'cm_x300_init_wi2wi':
arch/arm/mach-pxa/cm-x300.c:779: warning: unused variable 'wlan_en'
arch/arm/mach-pxa/cm-x300.c:795: warning: 'bt_reset' may be used uninitialized in this function
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
arch/arm/mach-pxa/cm-x300.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-pxa/cm-x300.c b/arch/arm/mach-pxa/cm-x300.c
index 0f00e01..0e18eb9 100644
--- a/arch/arm/mach-pxa/cm-x300.c
+++ b/arch/arm/mach-pxa/cm-x300.c
@@ -776,7 +776,6 @@ static struct gpio cm_x300_wi2wi_gpios[] __initdata = {
static void __init cm_x300_init_wi2wi(void)
{
- int bt_reset, wlan_en;
int err;
if (system_rev < 130) {
@@ -792,12 +791,11 @@ static void __init cm_x300_init_wi2wi(void)
}
udelay(10);
- gpio_set_value(bt_reset, 0);
+ gpio_set_value(cm_x300_wi2wi_gpios[1].gpio, 0);
udelay(10);
- gpio_set_value(bt_reset, 1);
+ gpio_set_value(cm_x300_wi2wi_gpios[1].gpio, 1);
- gpio_free(wlan_en);
- gpio_free(bt_reset);
+ gpio_free_array(ARRAY_AND_SIZE(cm_x300_wi2wi_gpios));
}
/* MFP */
--
1.7.4.1
^ permalink raw reply related
* [PATCH] ARM: kdump: copy kernel relocation code at the kexec prepare stage
From: Lei Wen @ 2011-09-17 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110916054556.GA10298@verge.net.au>
Hi Simon,
On Fri, Sep 16, 2011 at 1:45 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Sep 15, 2011 at 10:32:09PM -0700, Lei Wen wrote:
>> This copy really don't need to do at the very second before the kernel
>> would crash.
>>
>> Signed-off-by: Lei Wen <leiwen@marvell.com>
>
> This seems reasonable to me.
>
> Acked-by: Simon Horman <horms@verge.net.au>
Thanks for acked. :)
BTW, do you know which git tree should this patch be merged?
Best regards,
Lei
^ permalink raw reply
* [PATCH v2 6/6] arm/imx6q: add suspend/resume support
From: Shawn Guo @ 2011-09-17 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917083007.GA26572@S2100-06.ap.freescale.net>
On Sat, Sep 17, 2011 at 04:30:09PM +0800, Shawn Guo wrote:
[...]
> > > +ENTRY(v7_cpu_resume)
> > > + bl v7_invalidate_l1
> > > + bl pl310_resume
> > > + b cpu_resume
> > > +ENDPROC(v7_cpu_resume)
> > > +
> > > +/*
> > > + * The following code is located into the .data section. This is to
> > > + * allow pl310_pbase and pl310_aux_ctrl to be accessed with a relative
> > > + * load as we are running on physical address here.
> > > + */
> > > + .data
> > > + .align
> > > +ENTRY(pl310_resume)
> > > + adr r2, pl310_pbase
> > > + ldmia r2, {r0, r1}
> > > + str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> > > + mov r1, #0x1
> > > + str r1, [r0, #L2X0_CTRL] @ re-enable L2
> > > + mov pc, lr
> > > +ENDPROC(pl310_resume)
> > > +
> > > +pl310_pbase:
> > > + .long 0
> > > +pl310_aux_ctrl:
> > > + .long 0
> >
> > You might want to inline it and avoid the jump.
> >
> One reason that I implemented pl310_resume as a function call is that
> I was trying to minimize the code that we have to put in .data section.
> Now I do not think it's a point that really matters. So following your
> suggestion, here it is. Please let me know it is not what you meant to
> see.
>
> /*
> * The following code is located into the .data section. This is to
> * allow pl310_pbase and pl310_aux_ctrl to be accessed with a relative
> * load as we are running on physical address here.
> */
> .data
> .align
>
> .macro pl310_resume
> adr r2, pl310_pbase
> ldmia r2, {r0, r1}
> str r1, [r0, #L2X0_AUX_CTRL] @ restore aux_ctrl
> mov r1, #0x1
> str r1, [r0, #L2X0_CTRL] @ re-enable L2
> .endm
>
> ENTRY(v7_cpu_resume)
> bl v7_invalidate_l1
> pl310_resume
> b cpu_resume
> ENDPROC(v7_cpu_resume)
>
> .globl
Sorry. This is a left-over of .globl playing, which should not be here.
> pl310_pbase:
> .long 0
> pl310_aux_ctrl:
> .long 0
>
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 2/6] arm/imx6q: add core definitions and low-level debug uart
From: Russell King - ARM Linux @ 2011-09-17 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110912141440.GC7007@n2100.arm.linux.org.uk>
On Mon, Sep 12, 2011 at 03:14:41PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 12, 2011 at 10:44:39AM +0200, Sascha Hauer wrote:
> > I vote to skip params_phys and initrd_phys now. Every recent bootloader
> > does not need them. As the i.MX6 is a new SoC, we have no reason to
> > handle legacy bootloaders.
>
> Can we stop this misunderstanding right now.
>
> It's NOT about legacy boot loaders. It's about the bootp code which
> allows an initrd to be packaged up together with a zImage file as one
> single file.
>
> That's used to be able to boot with an initrd on platforms which can
> only obtain one file from the boot media, and they specify where the
> parameters are expected to be (which can be solved by updating the
> code to use r2) and where to place the initrd image (which can't be
> solved as it would mean encoding memory information for every platform
> into the bootp code.)
>
> An example of a current boot loader which requires this: Simtec's Able
> boot loader.
Here's a patch to reduce the reliance of arch/arm/boot/bootp on having
a correct initrd image location passed from the platform Makefile.boot.
It doesn't get rid of it, as it's required if the platform does not
pass a valid value in r2 to the kernel.
Note - I have a new code for a platform (of the nommu variety) which
requires this to be able to boot. Also note that we're probably going
to have to find a way to make this work with DT too (if not then I may
be submitting this platform without DT any support.)
---
arch/arm/boot/bootp/init.S | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/bootp/init.S b/arch/arm/boot/bootp/init.S
index 78b5080..d1cb5a9 100644
--- a/arch/arm/boot/bootp/init.S
+++ b/arch/arm/boot/bootp/init.S
@@ -16,6 +16,14 @@
* size immediately following the kernel, we could build this into
* a binary blob, and concatenate the zImage using the cat command.
*/
+
+#define ATAG_CORE 0x54410001
+#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2)
+#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2)
+
+#define ATAG_INITRD2 0x54420005
+#define ATAG_INITRD2_SIZE ((4*4) >> 2)
+
.section .start,#alloc,#execinstr
.type _start, #function
.globl _start
@@ -37,13 +45,31 @@ _start: add lr, pc, #-0x8 @ lr = current load addr
@ r8 = initrd end
@ r9 = param_struct address
+/*
+ * Check whether we were given a valid ATAG list from the boot loader.
+ * If it looks like a valid pointer, then use that rather than the
+ * hard-coded value.
+ */
+ tst r2, #3 @ aligned
+ bne 1f
+ ldr r10, [r2, #0] @ get first tag size
+ teq r10, #ATAG_CORE_SIZE
+ teqne r10, #ATAG_CORE_SIZE_EMPTY
+ bne 1f
+ ldr r10, [r2, #4] @ get first tag type
+ teq r10, r5 @ is it ATAG_CORE?
+ bne 1f
+ mov r9, r2
+ b taglist
+
+1: mov r2, r9 @ params for the kernel
ldr r10, [r9, #4] @ get first tag
teq r10, r5 @ is it ATAG_CORE?
/*
* If we didn't find a valid tag list, create a dummy ATAG_CORE entry.
*/
movne r10, #0 @ terminator
- movne r4, #2 @ Size of this entry (2 words)
+ movne r4, #ATAG_CORE_SIZE_EMPTY @ Size of this entry (2 words)
stmneia r9, {r4, r5, r10} @ Size, ATAG_CORE, terminator
/*
@@ -56,7 +82,7 @@ taglist: ldr r10, [r9, #0] @ tag length
addne r9, r9, r10, lsl #2
bne taglist
- mov r5, #4 @ Size of initrd tag (4 words)
+ mov r5, #ATAG_INITRD2_SIZE @ Size of initrd tag (4 words)
stmia r9, {r5, r6, r7, r8, r10}
b kernel_start @ call kernel
@@ -80,8 +106,8 @@ data: .word initrd_start @ source initrd address
.word initrd_phys @ destination initrd address
.word initrd_size @ initrd size
- .word 0x54410001 @ r5 = ATAG_CORE
- .word 0x54420005 @ r6 = ATAG_INITRD2
+ .word ATAG_CORE @ r5
+ .word ATAG_INITRD2 @ r6
.word initrd_phys @ r7
.word initrd_size @ r8
.word params_phys @ r9
^ permalink raw reply related
* [PATCH 3/7] ASoC: edb93xx: convert to use snd_soc_register_card()
From: Alexander Sverdlin @ 2011-09-17 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917065202.GA2759@mwesterb-mobl.ger.corp.intel.com>
Hello!
I've checked mainline linux-next without your patches, it's broken too.
So your patches are not the root cause for that.
On Sat, 2011-09-17 at 09:52 +0300, Mika Westerberg wrote:
> On Fri, Sep 16, 2011 at 06:45:55PM +0200, Alexander Sverdlin wrote:
> >
> > Have you tried the driver on reference boards?
>
> No - I don't have any of those.
>
> > For me it doesn't work any more. Boot messages are ok, as before, but
> > alsa open produces such messages:
> > Jan 1 00:32:19 IPCUn user.err kernel: asoc: can't open platform
> > ep93xx-pcm-audio
>
> Do you have the first patch ("ASoC: ep93xx-pcm: add MODULE_ALIAS") in this
> series applied? Have you tried whether it still works if you compile
> everything in?
>
^ permalink raw reply
* [GIT PULL] davinci features for v3.2 merge windiow
From: Nori, Sekhar @ 2011-09-17 11:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Please pull the following feature for v3.2 merge
window. It adds TI WLAN support on AM18x board.
Thanks,
Sekhar
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linus Torvalds (1):
Linux 3.1-rc6
are available in the git repository at:
git://gitorious.org/linux-davinci/linux-davinci.git v3.2/features
Ido Yariv (4):
ARM: davinci: DA850: Add MMC/SD1 pinmux configuration
ARM: davinci: DA850: Add GPIO pinmux configuration for wl1271
mmc: davinci: Add support for set_power callback
ARM: davinci: AM18x: Add wl1271/wlan support
arch/arm/mach-davinci/Kconfig | 10 +++
arch/arm/mach-davinci/board-da850-evm.c | 114 ++++++++++++++++++++++++++++++
arch/arm/mach-davinci/da850.c | 9 +++
arch/arm/mach-davinci/include/mach/mmc.h | 3 +
arch/arm/mach-davinci/include/mach/mux.h | 10 +++
drivers/mmc/host/davinci_mmc.c | 13 ++++
6 files changed, 159 insertions(+), 0 deletions(-)
^ permalink raw reply
* [GIT PULL] davinci fixes for v3.2 merge window
From: Nori, Sekhar @ 2011-09-17 11:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
Please pull the following two fixes for the v3.2
merge window. They are not applicable to stable
tree and hence the stable tag has not been added.
Thanks,
Sekhar
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linus Torvalds (1):
Linux 3.1-rc6
are available in the git repository at:
git://gitorious.org/linux-davinci/linux-davinci.git v3.2/fixes
Ido Yariv (1):
ARM: davinci: Explicitly set channel controllers' default queues
Thomas Meyer (1):
ARM: davinci: edma: use kzalloc()
arch/arm/mach-davinci/devices-da8xx.c | 3 +++
arch/arm/mach-davinci/devices-tnetv107x.c | 1 +
arch/arm/mach-davinci/dm355.c | 1 +
arch/arm/mach-davinci/dm644x.c | 1 +
arch/arm/mach-davinci/dm646x.c | 1 +
arch/arm/mach-davinci/dma.c | 5 +----
6 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH] arm/dt: Add SoC detection macros
From: Russell King - ARM Linux @ 2011-09-17 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917103457.GP28104@game.jcrosoft.org>
On Sat, Sep 17, 2011 at 12:34:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:28 Sat 17 Sep , Russell King - ARM Linux wrote:
> > One last point to raise here is - and it's quite a fundamental one - do we
> > really want this? If we're making decisions based on the SoC type, that
> > suggests to me that the hardware description in DT is incomplete, and
> > we're hiding stuff in the kernel behind the SoC type. That doesn't sound
> > particularly appealing given the point of DT is to encode the hardware
> > specific information outside the kernel code.
>
> except if a machine can run on 2 soc so detect it will avoid to have 2 Device
> Tree
This code is structured to match the SoC based upon an entry in the DT,
so for tegra2 vs tegra3 it's already having to have two different DTs
to distinguish between them.
However, I still go back to my original point: the point of DT is to
provide a description of the hardware which the kernel is running on -
not only for current hardware but possibly future hardware as well. Eg,
if Tegra4 comes along with more peripherals than Tegra3 but has basic
hardware which the kernel already supports, just wired up differently,
then Tegra4 should just work with a new DT file and no code changes.
What I'm saying is that in that scenario it should not be necessary to
edit the kernel to invent new SoC types, and then teach it that Tegra4
is mostly the same as Tegra3. That information should all be encoded
into the DT rather than the C code in the kernel.
So, I think adding this SoC type stuff is the wrong approach to the
problem.
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Russell King - ARM Linux @ 2011-09-17 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xpc-8zzGkZ9LThqP7in27n6uX4LRGAf+AtoWTM4p=82w@mail.gmail.com>
On Fri, Sep 16, 2011 at 11:24:36AM +0800, Barry Song wrote:
> if we have a save/restore interface, it looks it will be very
> complicated. different l2 need to save different registers.
Why? It's quite simple as far as I can see:
static u32 l2_aux_ctrl;
void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
{
...
aux = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
aux &= aux_mask;
aux |= aux_val;
l2_aux_ctrl = aux;
...
}
void l2x0_resume(void)
{
bool need_setup = false;
if (l2_aux_ctrl != readl_relaxed(l2x0_base + L2X0_AUX_CTRL))
need_setup = true;
if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
/* Make sure that I&D is not locked down when starting */
l2x0_unlock(cache_id);
/* l2x0 controller is disabled */
writel_relaxed(l2_aux_ctrl, l2x0_base + L2X0_AUX_CTRL);
l2x0_inv_all();
/* enable L2X0 */
writel_relaxed(1, l2x0_base + L2X0_CTRL);
}
}
and we can do a similar thing when initializing the PL310 and resuming
the PL310 - add a new outer_cache callback called 'resume' to be pointed
at the relevant resume function which knows which registers to restore.
> when we resume, we must disable l2 if bootloader has enabled it and
> restore all registers.
That's not possible in SoCs operating in non-secure mode from generic
code, as some of these registers will not be accessible. They can only
be programmed from platform specific code due to the complexities of
dealing with the abhorrent secure monitor stuff.
I'm now starting to think that we don't actually want any resume code
at the L2 level - most SoCs will be operating in non-secure mode (I
believe it's only ARM's development platforms which operate in secure
mode) and so most of the generic code which will need to write to the
L2 control registers on resume will fail.
Even re-calling the initialization functions probably does nothing on
parts operating in secure mode - whether at boot or at resume.
^ permalink raw reply
* [PATCH] arm/dt: Add SoC detection macros
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-09-17 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110917102811.GC16381@n2100.arm.linux.org.uk>
On 11:28 Sat 17 Sep , Russell King - ARM Linux wrote:
> On Fri, Sep 09, 2011 at 01:02:19AM -0700, Allen Martin wrote:
> > +#ifdef CONFIG_ARCH_TEGRA_2x_SOC
> > +# ifdef SOC_NAME
> > +# undef MULTI_SOC
> > +# define MULTI_SOC
> > +# else
> > +# define SOC_NAME tegra2
> > +# endif
> > +#endif
> > +#ifdef CONFIG_ARCH_TEGRA_3x_SOC
> > +# ifdef SOC_NAME
> > +# undef MULTI_SOC
> > +# define MULTI_SOC
> > +# else
> > +# define SOC_NAME tegra3
> > +# endif
> > +#endif
> > +
> > +#define soc_is_tegra2() 0
> > +#define soc_is_tegra3() 0
> > +
> > +#if defined(MULTI_SOC)
> > +# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
> > +# undef soc_is_tegra2
> > +# define soc_is_tegra2() is_tegra2()
> > +# endif
> > +# if defined(CONFIG_ARCH_TEGRA_3x_SOC)
> > +# undef soc_is_tegra3
> > +# define soc_is_tegra3() is_tegra3()
> > +# endif
> > +#else /* non-multi, only one architecture is on */
> > +# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
> > +# undef soc_is_tegra2
> > +# define soc_is_tegra2() 1
> > +# elif defined(CONFIG_ARCH_TEGRA_3x_SOC)
> > +# undef soc_is_tegra3
> > +# define soc_is_tegra3() 1
> > +# endif
> > +#endif
>
> This is not the way to do this, especially for a file in asm/*.h. Look
> at the way machine_is_xxx() is dealt with in include/generated/mach-types.h.
>
> #define MULTI_SOC 0
> #undef SOC_SELECTED
>
> #ifdef CONFIG_ARCH_TEGRA_2x_SOC
> # ifdef SOC_SELECTED
> # undef MULTI_SOC
> # define MULTI_SOC 1
> # else
> # define SOC_SELECTED
> # endif
> # define soc_is_tegra2() (!MULTI_SOC || is_tegra2())
> #else
> # define soc_is_tegra2() 0
> #endif
>
> #ifdef CONFIG_ARCH_TEGRA_3x_SOC
> # ifdef SOC_SELECTED
> # undef MULTI_SOC
> # define MULTI_SOC 1
> # else
> # define SOC_SELECTED
> # endif
> # define soc_is_tegra3() (!MULTI_SOC || is_tegra3())
> #else
> # define soc_is_tegra3() 0
> #endif
>
> #undef SOC_SELECTED
>
> The above is nicely extensible - if other SoCs need to extend this they
> just need to add another outer ifdef..endif section to the file.
>
> > +
> > +enum soc_version {
> > + SOC_UNKNOWN = 0,
> > + TEGRA_T20,
> > + TEGRA_T30,
>
> I'd suggest prefixing these with SOC_ to avoid any namespace problems.
>
> > +};
> > +
> > +void soc_init_version(void);
> > +enum soc_version soc_get_version(void);
> > +
> > +static inline int is_tegra2(void)
> > +{
> > + return soc_get_version() == TEGRA_T20;
> > +}
> > +
> > +static inline int is_tegra3(void)
> > +{
> > + return soc_get_version() == TEGRA_T30;
> > +}
>
> If we require all SoCs to provide a value in soc_version, then we can use
> exactly the same method as mach-types.h uses - and while at this, please
> get rid of soc_get_version(). It's far cheaper to access the variable
> directly rather than indirect through a function, just like we do with
> __machine_arch_type. Mark it __read_mostly too.
>
> One last point to raise here is - and it's quite a fundamental one - do we
> really want this? If we're making decisions based on the SoC type, that
> suggests to me that the hardware description in DT is incomplete, and
> we're hiding stuff in the kernel behind the SoC type. That doesn't sound
> particularly appealing given the point of DT is to encode the hardware
> specific information outside the kernel code.
except if a machine can run on 2 soc so detect it will avoid to have 2 Device
Tree
Best Regards,
J.
^ permalink raw reply
* [PATCH] arm/dt: Add SoC detection macros
From: Russell King - ARM Linux @ 2011-09-17 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315555339-12685-1-git-send-email-amartin@nvidia.com>
On Fri, Sep 09, 2011 at 01:02:19AM -0700, Allen Martin wrote:
> +#ifdef CONFIG_ARCH_TEGRA_2x_SOC
> +# ifdef SOC_NAME
> +# undef MULTI_SOC
> +# define MULTI_SOC
> +# else
> +# define SOC_NAME tegra2
> +# endif
> +#endif
> +#ifdef CONFIG_ARCH_TEGRA_3x_SOC
> +# ifdef SOC_NAME
> +# undef MULTI_SOC
> +# define MULTI_SOC
> +# else
> +# define SOC_NAME tegra3
> +# endif
> +#endif
> +
> +#define soc_is_tegra2() 0
> +#define soc_is_tegra3() 0
> +
> +#if defined(MULTI_SOC)
> +# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
> +# undef soc_is_tegra2
> +# define soc_is_tegra2() is_tegra2()
> +# endif
> +# if defined(CONFIG_ARCH_TEGRA_3x_SOC)
> +# undef soc_is_tegra3
> +# define soc_is_tegra3() is_tegra3()
> +# endif
> +#else /* non-multi, only one architecture is on */
> +# if defined(CONFIG_ARCH_TEGRA_2x_SOC)
> +# undef soc_is_tegra2
> +# define soc_is_tegra2() 1
> +# elif defined(CONFIG_ARCH_TEGRA_3x_SOC)
> +# undef soc_is_tegra3
> +# define soc_is_tegra3() 1
> +# endif
> +#endif
This is not the way to do this, especially for a file in asm/*.h. Look
at the way machine_is_xxx() is dealt with in include/generated/mach-types.h.
#define MULTI_SOC 0
#undef SOC_SELECTED
#ifdef CONFIG_ARCH_TEGRA_2x_SOC
# ifdef SOC_SELECTED
# undef MULTI_SOC
# define MULTI_SOC 1
# else
# define SOC_SELECTED
# endif
# define soc_is_tegra2() (!MULTI_SOC || is_tegra2())
#else
# define soc_is_tegra2() 0
#endif
#ifdef CONFIG_ARCH_TEGRA_3x_SOC
# ifdef SOC_SELECTED
# undef MULTI_SOC
# define MULTI_SOC 1
# else
# define SOC_SELECTED
# endif
# define soc_is_tegra3() (!MULTI_SOC || is_tegra3())
#else
# define soc_is_tegra3() 0
#endif
#undef SOC_SELECTED
The above is nicely extensible - if other SoCs need to extend this they
just need to add another outer ifdef..endif section to the file.
> +
> +enum soc_version {
> + SOC_UNKNOWN = 0,
> + TEGRA_T20,
> + TEGRA_T30,
I'd suggest prefixing these with SOC_ to avoid any namespace problems.
> +};
> +
> +void soc_init_version(void);
> +enum soc_version soc_get_version(void);
> +
> +static inline int is_tegra2(void)
> +{
> + return soc_get_version() == TEGRA_T20;
> +}
> +
> +static inline int is_tegra3(void)
> +{
> + return soc_get_version() == TEGRA_T30;
> +}
If we require all SoCs to provide a value in soc_version, then we can use
exactly the same method as mach-types.h uses - and while at this, please
get rid of soc_get_version(). It's far cheaper to access the variable
directly rather than indirect through a function, just like we do with
__machine_arch_type. Mark it __read_mostly too.
One last point to raise here is - and it's quite a fundamental one - do we
really want this? If we're making decisions based on the SoC type, that
suggests to me that the hardware description in DT is incomplete, and
we're hiding stuff in the kernel behind the SoC type. That doesn't sound
particularly appealing given the point of DT is to encode the hardware
specific information outside the kernel code.
^ permalink raw reply
* [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
From: Martin Hostettler @ 2011-09-17 9:34 UTC (permalink / raw)
To: linux-arm-kernel
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler <martin@neutronstar.dyndns.org>
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 183 +++++++++++++++++++++++++++
2 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..8ae3d25 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO) += board-omap3logic.o \
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
+ board-omap3evm-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 0000000..be987d9
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund <gwlund@lundeng.com>
+ * Author: Martin Hostettler <martin@neutronstar.dyndns.org>
+ *
+ * Board intregration for a MT9M032 camera connected to IMAGE_CONN and I2C Bus 2
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+
+#include <linux/gpio.h>
+#include <plat/mux.h>
+#include "mux.h"
+
+#include "../../../drivers/media/video/omap3isp/isp.h"
+#include "media/mt9m032.h"
+
+#include "devices.h"
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL 157
+
+#define MT9M032_I2C_BUS_NUM 2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM board
+ * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err("omap3evm-camera: Invalid mux id #%d\n", mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct mt9m032_platform_data mt9m032_platform_data = {
+ .ext_clock = 13500000,
+ .pll_pre_div = 6,
+ .pll_mul = 120,
+ .pll_out_div = 5,
+ .invert_pixclock = 1,
+};
+
+static struct i2c_board_info camera_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO(MT9M032_NAME, MT9M032_I2C_ADDR),
+ .platform_data = &mt9m032_platform_data,
+ },
+};
+
+static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
+ {
+ .board_info = &camera_i2c_devices[0],
+ .i2c_adapter_id = MT9M032_I2C_BUS_NUM,
+ },
+ {},
+};
+
+static struct isp_v4l2_subdevs_group camera_subdevs[] = {
+ {
+ .subdevs = camera_i2c_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .data_lane_shift = 1,
+ .clk_pol = 0,
+ .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
+ }
+ },
+ },
+ {},
+};
+
+static struct isp_platform_data isp_platform_data = {
+ .subdevs = camera_subdevs,
+};
+
+static int __init camera_init(void)
+{
+ int ret = -EINVAL;
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, "nCAM_VD_SEL") < 0) {
+ pr_err("omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n",
+ nCAM_VD_SEL);
+ goto err;
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) < 0) {
+ pr_err("omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d) direction\n",
+ nCAM_VD_SEL);
+ goto err_vdsel;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 2, "T2_GPIO2") < 0) {
+ pr_err("omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n",
+ EVM_TWL_GPIO_BASE + 2);
+ goto err_vdsel;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) < 0) {
+ pr_err("omap3evm-camera: Failed to set GPIO T2_GPIO2(%d) direction\n",
+ EVM_TWL_GPIO_BASE + 2);
+ goto err_2;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 8, "nCAM_VD_EN") < 0) {
+ pr_err("omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n",
+ EVM_TWL_GPIO_BASE + 8);
+ goto err_2;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) < 0) {
+ pr_err("omap3evm-camera: Failed to set GPIO nCAM_VD_EN(%d) direction\n",
+ EVM_TWL_GPIO_BASE + 8);
+ goto err_8;
+ }
+
+ omap3evm_set_mux(MUX_CAMERA_SENSOR);
+
+
+ ret = omap3_init_camera(&isp_platform_data);
+ if (ret < 0)
+ goto err_8;
+ return 0;
+
+err_8:
+ gpio_free(EVM_TWL_GPIO_BASE + 8);
+err_2:
+ gpio_free(EVM_TWL_GPIO_BASE + 2);
+err_vdsel:
+ gpio_free(nCAM_VD_SEL);
+err:
+ return ret;
+}
+
+device_initcall(camera_init);
--
1.7.2.5
^ permalink raw reply related
* [GIT PULL] Samsung Fixes for v3.1-rc7
From: Arnd Bergmann @ 2011-09-17 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00d801cc74d6$50d93fa0$f28bbee0$%kim@samsung.com>
On Saturday 17 September 2011 10:08:30 Kukjin Kim wrote:
> Arnd Bergmann wrote:
?
> >
> > The patches are currently queued in the stable branch of the arm-soc
> > tree, I haven't forwarded them to Linus yet. I can easily change
> > the changelog before I actually send them on (if you tell me which ones
> > they are, or I can pull an updated set of patches to replace them.
> >
> Arnd, I think, would be better to me if you could not change the
> changelog(commit id) because some my topic branch which is for v3.2 has it.
Ok, no problem.
Arnd
^ permalink raw reply
* [PATCH v2 2/2] ARM: smp_scu: remove __init annotation from scu_enable()
From: Shawn Guo @ 2011-09-17 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315288107-14689-3-git-send-email-shawn.guo@linaro.org>
On Tue, Sep 06, 2011 at 01:48:27PM +0800, Shawn Guo wrote:
> When Cortex-A9 MPCore resumes from Dormant or Shutdown modes,
> SCU needs to be re-enabled. This patch removes __init annotation
> from function scu_enable(), so that platform resume procedure can
> call it to re-enable SCU.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
Hi Russell,
Do you have any comment on this patch? Can I put it into patch tracker?
Regards,
Shawn
> arch/arm/kernel/smp_scu.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index 79ed5e7..5b6d536 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -33,7 +33,7 @@ unsigned int __init scu_get_core_count(void __iomem *scu_base)
> /*
> * Enable the SCU
> */
> -void __init scu_enable(void __iomem *scu_base)
> +void scu_enable(void __iomem *scu_base)
> {
> u32 scu_ctrl;
>
> --
> 1.7.4.1
^ 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