* [PATCH 2/7] s3c-adc: describe features via quirk constants
From: Kukjin Kim @ 2011-10-04 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110021318.42131.heiko@sntech.de>
Heiko St?bner wrote:
>
> Hi Kgene,
>
> Am Sonntag 02 Oktober 2011, 09:38:18 schrieb Kukjin Kim:
> > How about following? I think following is also not bad...
> ok, I don't claim to have the right solution, so if keeping the TYPE_xxx
enum
> is better, I will do a rework of the series according to your solution and
> resend it.
>
Thanks for your understanding and please re-send it :)
> Could I meanwhile interest you in the patches for the S3C2416 armclk and
hsmmc
> (from 28 Sep 2011) :-) ?
>
Sure, will check it soon, maybe tomorrow?
Anyway, if any problems, let you know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
From: Kukjin Kim @ 2011-10-04 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3709260.I9R44Iti1S@wuerfel>
Arnd Bergmann wrote:
>
> On Monday 03 October 2011 21:40:36 Kukjin Kim wrote:
> > Yes, absolutely. As I said, the 'mach-exynos' can support upcoming
> > Samsung EXYNOS SoCs and the way is better than making mach-exynos5.
> >
> > My bigger plan is finally to make current directories to 3 mach- dir.
> > (mach-s3c, mach-s5p, and mach-exynos) and 1 plat-samsung directory. Of
> > course, the mach- directories can be reduced later.
> >
> > Firstly, as you can see, I'm merging plat-s3c24xx and plat-s5p into one
> > plat-samsung directory and actually the <plat/*.h> files and dev-*.c
> > files have been moved into plat-samsung. Maybe I can finish it during
> > 3.2-rc.
>
> Ok, sounds good. So for my understanding: is s5p a completely separate
> line from exynos, or are they more of an evolutionary succession where
> you draw the line between the last uniprocessor and the first SMP
> chip?
>
As you know, Samsung has announced 'EXYNOS' as a new Samsung SoC name then
we have used it. Frankly, I'm not sure the name of 'S5P' will be used later
or not. If any updates let you know.
> > Secondary, upcoming Samsung EXYNOS SoCs will be supported in mach-exynos
> > directory and this patch is required to that. For example, the EXYNOS5
> > SoCs (Cortex A15) will be supported in that with other EXYNOS4 SoCs soon
> > and of course it reduces code duplication
>
> My feeling is that it would be nicer to just add exynos5 to the mach-
exynos4
> directory for now, in the same way that omap3/4/5 are in the mach-omap2
> directory. We can do a big rename later once the reorganization of code
> within those directories that you explained above is complete.
>
> If you still want to do the big rename right now, I would suggest doing
> it at the end of the 3.2 merge window, so that all other patches that
> might need to touch the mach-exynos4 directory can go in first.
>
Thanks for your suggestion.
OK, I will and it will be sent to upstream via arm-soc at the end of the
3.2 merge window.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [GIT PULL] Samsung devel-2 for v3.2
From: Kukjin Kim @ 2011-10-04 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002192950.GB1005@sirena.org.uk>
Mark Brown wrote:
>
> On Sun, Oct 02, 2011 at 06:25:36PM +0900, Kukjin Kim wrote:
>
> > gpio/samsung: gpio-samsung.c to support Samsung GPIOs
>
> As I reported the other day this change breaks the boot early on on the
> Cragganmore S3C6410 based systems (I've not actually fired up my
> SMDK6410 but I suspect it may have issues too). I did make some brief
> attempts to debug but as there's no console output at all and the diff
> is rather large it's not easy to see what's gone wrong.
Hi Mark,
Could you please test on Cragganmore board again only with my for-next-test
branch?
(I have did 'git-revert' some patches which have some dependencies with
other tree to build without others.)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
From: Kukjin Kim @ 2011-10-04 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1957187.UuLfeIqa6D@wuerfel>
Arnd Bergmann wrote:
>
> On Monday 03 October 2011 12:41:22 Kukjin Kim wrote:
> > This patch adds macro SAMSUNG_RES_MEM, SAMSUNG_RES_IRQ
> > and so on to cleanup regarding 'struct resource' by using
> > defined helpers at <linux/ioport.h>.
> >
> > Cc: Ben Dooks <ben-linux@fluff.org>
> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>
> When we introduced those macros, it was specifically so that platforms
> would be migrated to use them instead of providing their own.
>
> > index 8f19241..a506831 100644
> > --- a/arch/arm/plat-samsung/include/plat/devs.h
> > +++ b/arch/arm/plat-samsung/include/plat/devs.h
> > @@ -18,6 +18,17 @@
> >
> > #include <linux/platform_device.h>
> >
> > +#define SAMSUNG_RES_MEM(soc, ip, sz)
> DEFINE_RES_MEM(soc##_PA_##ip, sz)
> > +#define SAMSUNG_RES_IRQ(ip) DEFINE_RES_IRQ(IRQ_##ip)
> > +
> > +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \
> > +
> DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, name)
> > +#define SAMSUNG_RES_IRQ_NAMED(ip, name) \
> > + DEFINE_RES_IRQ_NAMED(IRQ_##ip,
> name)
> > +#define SAMSUNG_RES_DMA_NAMED(ch, name)
> \
> > +
> DEFINE_RES_DMA_NAMED(DMACH_##ch, name)
>
> I think the string concatenation really just obfuscates the code, and
> it does not actually save much at all. When you replace
>
> + [0] = SAMSUNG_RES_MEM(S3C, WDT, SZ_1K),
> + [1] = SAMSUNG_RES_IRQ(WDT),
>
> with
>
> + [0] = DEFINE_RES_MEM(S3C_PA_WDT, SZ_1K),
> + [1] = DEFINE_RES_IRQ(IRQ_WDT),
>
> you need practically no extra space, but you gain the advantages that
>
> * Someone using grep for DEFINE_RES_MEM finds all memory resources without
> having to look up what your macros do an where they are used.
> * Someone using grep to look for S3C_PA_WDT finds the place where it is
used.
> * Someone reading the resource definition immediately knows what the
> macro does if familiar with other platforms using that macro.
Yes, right. But I'm preparing to reduce the 'soc' part to consolidate some
duplicated resources and platform data after this and the new SAMSUNG_RES
macro will be used.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
From: Kukjin Kim @ 2011-10-04 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E89C4B2.605@samsung.com>
Sylwester Nawrocki wrote:
>
> On 10/03/2011 03:13 PM, Kukjin Kim wrote:
> > On 10/03/11 12:53, Kyungmin Park wrote:
> >> On Mon, Oct 3, 2011 at 12:41 PM, Kukjin Kim<kgene.kim@samsung.com>
> wrote:
> >>>
> >>> +#define SAMSUNG_RES_MEM(soc, ip, sz)
> DEFINE_RES_MEM(soc##_PA_##ip, sz)
> >>> +#define SAMSUNG_RES_IRQ(ip) DEFINE_RES_IRQ(IRQ_##ip)
> >>> +
> >>> +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \
> >>> +
> DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, name)
> >>> +#define SAMSUNG_RES_IRQ_NAMED(ip, name)
> \
> >>> + DEFINE_RES_IRQ_NAMED(IRQ_##ip,
> name)
> >>> +#define SAMSUNG_RES_DMA_NAMED(ch, name)
> \
> >>> +
> DEFINE_RES_DMA_NAMED(DMACH_##ch, name)
> >>
> >> It's good for readability. but do you think that it's hard to find out
> >> defined macros are used at real place?
> >> e.g., Now I want to find out the S3C_PA_USB_HSOTG. it's difficult if
> >> you use the SAMSUNG_RES_* series macro.
> >> but if you use the DEFINED_RES_* series directly. it's easy to find
> >> out at real codes.
> >>
> > Well, I don't think so because the XXX_PA_XXX addresses are defined in
each
> > mach/map.h and they are usually used in here so it's not hard to find
it.
>
> Some minor disadvantage is that tagging tools like e.g. gtags don't handle
> these things properly. But I don't think it's really important.
>
> >
> > And now the 'S3C', 'S5P' and 'SAMSUNG' are used in the 'soc' part. I'm
> > preparing to consolidate the name and to remove duplicated resources.
>
> Do you also have any specific plans for supporting single image build for
> multiple SoC's while working on this ?
Hmm, you could see through my plan :)
As you know, we need to sort out resources and platform data to support
single kernel image so I'm preparing it after this.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* unwind and lockdep
From: Harald Gustafsson @ 2011-10-04 12:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I have turned on lockdep on a 2.6.35.7 kernel compiled for mach-ux500
arch with ARM_UNWIND and get some unwind Index not found warnings,
especially during the boot. E.g. the following, see warnings at end:
<7>[ 134.874481] unwind_frame(pc = c033abf0 lr = c033abf0 sp = c06d1fa0)
<7>[ 134.874481] unwind_find_idx(c033abf0)
<7>[ 134.874511] search_index(c033abf0, c06ae000->addr=c002c968, c06cccd8)
<7>[ 134.874542] unwind_find_idx: idx = c06c3488
<7>[ 134.874542] unwind_exec_insn: insn = 00000084
<7>[ 134.874572] unwind_exec_insn: fp = 00000000 sp = c06d1fc0 lr =
c003b6f8 pc = 00000000
<7>[ 134.874603] unwind_exec_insn: insn = 000000b0
<7>[ 134.874603] unwind_exec_insn: fp = 00000000 sp = c06d1fc0 lr =
c003b6f8 pc = c003b6f8
<7>[ 134.874633] unwind_frame(pc = c003b6f8 lr = c003b6f8 sp = c06d1fc0)
<7>[ 134.874664] unwind_find_idx(c003b6f8)
<7>[ 134.874694] search_index(c003b6f8, c06ae000->addr=c002c968, c06cccd8)
<7>[ 134.874694] unwind_find_idx: idx = c06af6b0
<7>[ 134.874725] unwind_exec_insn: insn = 000000ac
<7>[ 134.874755] unwind_exec_insn: fp = 00000000 sp = c06d1fd8 lr =
c0008b70 pc = 00000000
<7>[ 134.874755] unwind_exec_insn: insn = 000000b0
<7>[ 134.874786] unwind_exec_insn: fp = 00000000 sp = c06d1fd8 lr =
c0008b70 pc = c0008b70
<7>[ 134.874816] unwind_frame(pc = c0008b70 lr = c0008b70 sp = c06d1fd8)
<7>[ 134.874816] unwind_find_idx(c0008b70)
<7>[ 134.874847] search_index(c0008b70, c06ae000->addr=c002c968, c06cccd8)
<4>[ 134.874877] unwind: Unknown symbol address c0008b70
<7>[ 134.879760] unwind_find_idx: idx = (null)
<4>[ 134.879791] unwind: Index not found c0008b70
(Where I changed the debug print to also show the addr in the "first"
entry for search_index)
The address c0008b70 is within the addresses that core_kernel_text
checks for (c0008000-c06ae000) and also within init_kernel_text checks
(c0008000-c002c968).
But why is then search_index checking if it is below c002c968 and
bails out if it is?
Anyone that could give me some hints about this? Is this expected?
/Harald
^ permalink raw reply
* [GIT PULL] Samsung devel-2 for v3.2
From: Mark Brown @ 2011-10-04 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <019201cc8293$7776a790$6663f6b0$%kim@samsung.com>
On Tue, Oct 04, 2011 at 09:45:16PM +0900, Kukjin Kim wrote:
> Mark Brown wrote:
> > As I reported the other day this change breaks the boot early on on the
> > Cragganmore S3C6410 based systems (I've not actually fired up my
> > SMDK6410 but I suspect it may have issues too). I did make some brief
> > attempts to debug but as there's no console output at all and the diff
> > is rather large it's not easy to see what's gone wrong.
> Could you please test on Cragganmore board again only with my for-next-test
> branch?
> (I have did 'git-revert' some patches which have some dependencies with
> other tree to build without others.)
Sure - it may be tomorrow morning (so late tomorrow your time) before
I'm sitting in front of a board for long enough to do it.
^ permalink raw reply
* [RFC PATCH] tty/serial: atmel_serial: add device tree support
From: Rob Herring @ 2011-10-04 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8AC171.4020706@atmel.com>
Nicolas,
On 10/04/2011 03:18 AM, Nicolas Ferre wrote:
> On 10/04/2011 03:58 AM, Rob Herring :
>> On 10/03/2011 04:51 AM, Nicolas Ferre wrote:
>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>> ---
>>> Hi,
>>>
>>> Here is a first attempt to add device tree support to atmel_serial driver.
>>> RS485 data are not handled for the moment. My feeling is that they should be
>>> added as a generic DT biding set.
>>
>> Feel free to propose something. :)
>
> Yes, I will have a look and practice my DT understanding on this...
>
>>> .../devicetree/bindings/tty/serial/atmel-usart.txt | 27 +++++++++
>>> drivers/tty/serial/atmel_serial.c | 56 +++++++++++++++++---
>>> 2 files changed, 75 insertions(+), 8 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>>> new file mode 100644
>>> index 0000000..a49d9a1
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
>>> @@ -0,0 +1,27 @@
>>> +* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
>>> +
>>> +Required properties:
>>> +- compatible: Should be "atmel,<chip>-usart"
>>> + The compatible <chip> indicated will be the first SoC to support an
>>> + additional mode or an USART new feature.
>>> +- reg: Should contain registers location and length
>>> +- interrupts: Should contain interrupt
>>> +
>>> +Optional properties:
>>> +- atmel,use-dma-rx: use of PDC or DMA for receiving data
>>> +- atmel,use-dma-tx: use of PDC or DMA for transmitting data
>>
>> Is this an internal DMA or separate DMA controller? If the latter, these
>> should be phandles to a DMA channel/request.
>
> Well, for now it relies on PDC (looks like an internal DMA). There is no
> notion of channel/request so I think it is appropriate to keep it like this.
>
Okay. Although, this is a bit of Linux creeping into DT. DT should
describe the h/w. You should really be describing whether the h/w
supports DMA or not rather than whether you want to use DMA or not.
Since DMA support is really tied to the SOC rather than board, you could
just use the compatible string to distinguish platforms that support DMA
or not. So what is determining this setting? Is it purely user choice?
>>> +<chip> compatible description:
>>> +- at91rm9200: legacy USART support
>>> +- at91sam9260: generic USART implementation for SAM9 SoCs
>>> +
>>> +Example:
>>> +
>>> + usart0: serial at fff8c000 {
>>> + compatible = "atmel,at91sam9260-usart";
>>> + reg = <0xfff8c000 0x4000>;
>>> + interrupts = <7>;
>>> + atmel,use-dma-rx;
>>> + atmel,use-dma-tx;
>>> + };
>>> +
>>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>>> index 453cdb5..65f56c3 100644
>>> --- a/drivers/tty/serial/atmel_serial.c
>>> +++ b/drivers/tty/serial/atmel_serial.c
>>> @@ -33,6 +33,8 @@
>>> #include <linux/sysrq.h>
>>> #include <linux/tty_flip.h>
>>> #include <linux/platform_device.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_device.h>
>>> #include <linux/dma-mapping.h>
>>> #include <linux/atmel_pdc.h>
>>> #include <linux/atmel_serial.h>
>>> @@ -162,6 +164,16 @@ static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
>>> static struct console atmel_console;
>>> #endif
>>>
>>> +#if defined(CONFIG_OF)
>>> +static const struct of_device_id atmel_serial_dt_ids[] = {
>>> + { .compatible = "atmel,at91rm9200-usart" },
>>> + { .compatible = "atmel,at91sam9260-usart" },
>>> + { /* sentinel */ }
>>> +};
>>> +
>>> +MODULE_DEVICE_TABLE(of, atmel_serial_dt_ids);
>>> +#endif
>>
>> This ifdef isn't necessary, but it really depends if long term this
>> driver will be built without OF (and you care about the extra data).
>
> Yes, even in long term, this driver will be built without OF support. It
> is true though that the extra data is not very big...
>
>>> static inline struct atmel_uart_port *
>>> to_atmel_uart_port(struct uart_port *uart)
>>> {
>>> @@ -1413,14 +1425,31 @@ static struct uart_ops atmel_pops = {
>>> static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
>>> struct platform_device *pdev)
>>> {
>>> + struct device_node *np = pdev->dev.of_node;
>>> struct uart_port *port = &atmel_port->uart;
>>> struct atmel_uart_data *pdata = pdev->dev.platform_data;
>>> + int ret;
>>> +
>>> + if (np) {
>>> + ret = of_alias_get_id(np, "serial");
>>> + if (ret >= 0)
>>> + port->line = ret;
>>> + if (of_get_property(np, "atmel,use-dma-rx", NULL))
>>> + atmel_port->use_dma_rx = 1;
>>> + if (of_get_property(np, "atmel,use-dma-tx", NULL))
>>> + atmel_port->use_dma_tx = 1;
>>> + } else {
>>> + port->line = pdata->num;
>>> +
>>> + atmel_port->use_dma_rx = pdata->use_dma_rx;
>>> + atmel_port->use_dma_tx = pdata->use_dma_tx;
>>> + atmel_port->rs485 = pdata->rs485;
>>> + }
>>>
>>> port->iotype = UPIO_MEM;
>>> port->flags = UPF_BOOT_AUTOCONF;
>>> port->ops = &atmel_pops;
>>> port->fifosize = 1;
>>> - port->line = pdata->num;
>>> port->dev = &pdev->dev;
>>> port->mapbase = pdev->resource[0].start;
>>> port->irq = pdev->resource[1].start;
>>> @@ -1430,7 +1459,7 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
>>>
>>> memset(&atmel_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
>>>
>>> - if (pdata->regs) {
>>> + if (pdata && pdata->regs) {
>>> /* Already mapped by setup code */
>>> port->membase = pdata->regs;
>>> } else {
>>> @@ -1447,10 +1476,6 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
>>> /* only enable clock when USART is in use */
>>> }
>>>
>>> - atmel_port->use_dma_rx = pdata->use_dma_rx;
>>> - atmel_port->use_dma_tx = pdata->use_dma_tx;
>>> - atmel_port->rs485 = pdata->rs485;
>>> -
>>> /* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
>>> if (atmel_port->rs485.flags & SER_RS485_ENABLED)
>>> atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
>>> @@ -1710,13 +1735,27 @@ static int atmel_serial_resume(struct platform_device *pdev)
>>> static int __devinit atmel_serial_probe(struct platform_device *pdev)
>>> {
>>> struct atmel_uart_port *port;
>>> + struct device_node *np = pdev->dev.of_node;
>>> struct atmel_uart_data *pdata = pdev->dev.platform_data;
>>> void *data;
>>> int ret;
>>>
>>> BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
>>>
>>> - port = &atmel_ports[pdata->num];
>>> + if (np) {
>>> + ret = of_alias_get_id(np, "serial");
>>
>> I'll defer to Grant on this. There aren't any other drivers using this.
>
> I took the IMX serial driver as an example which is in devicetree/next
> branch (tty/serial/imx.c).
>
> Is it the proper way to use this?
>
Okay, I missed this. It should be fine.
Rob
^ permalink raw reply
* [PATCH v4 06/10] ARM: SoC: convert Exynos4 to SoC descriptor
From: Kukjin Kim @ 2011-10-04 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317663356-5114-7-git-send-email-marc.zyngier@arm.com>
Marc Zyngier wrote:
>
> Convert Exynos4 to use the SoC descriptor to provide its SMP
> and CPU hotplug operations.
>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/mach-exynos4/core.h | 9 +++++++++
> arch/arm/mach-exynos4/cpu.c | 8 ++++++++
> arch/arm/mach-exynos4/hotplug.c | 8 +++++---
> arch/arm/mach-exynos4/mach-armlex4210.c | 3 +++
> arch/arm/mach-exynos4/mach-nuri.c | 3 +++
> arch/arm/mach-exynos4/mach-origen.c | 3 +++
> arch/arm/mach-exynos4/mach-smdk4212.c | 3 +++
> arch/arm/mach-exynos4/mach-smdkv310.c | 4 ++++
> arch/arm/mach-exynos4/mach-universal_c210.c | 3 +++
> arch/arm/mach-exynos4/platsmp.c | 25
> +++++++++++++++++++++----
> 10 files changed, 62 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/core.h
>
> diff --git a/arch/arm/mach-exynos4/core.h b/arch/arm/mach-exynos4/core.h
> new file mode 100644
> index 0000000..ba9fcc8
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/core.h
Is there any reason to add core.h in mach-exynos4 not
mach-exynos4/include/mach?
> @@ -0,0 +1,9 @@
> +#include <asm/soc.h>
> +
> +extern struct arm_soc_smp_init_ops exynos4_soc_smp_init_ops;
> +extern struct arm_soc_smp_ops exynos4_soc_smp_ops;
> +extern struct arm_soc_desc exynos4_soc_desc;
> +
> +extern int exynos4_cpu_kill(unsigned int cpu);
> +extern void exynos4_cpu_die(unsigned int cpu);
> +extern int exynos4_cpu_disable(unsigned int cpu);
> diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
> index 2aa3df0..a15dce8 100644
> --- a/arch/arm/mach-exynos4/cpu.c
> +++ b/arch/arm/mach-exynos4/cpu.c
> @@ -33,6 +33,8 @@
> #include <mach/regs-irq.h>
> #include <mach/regs-pmu.h>
>
> +#include "core.h"
> +
> extern int combiner_init(unsigned int combiner_nr, void __iomem *base,
> unsigned int irq_start);
> extern void combiner_cascade_irq(unsigned int combiner_nr, unsigned int
irq);
> @@ -282,3 +284,9 @@ int __init exynos4_init(void)
>
> return sysdev_register(&exynos4_sysdev);
> }
> +
> +struct arm_soc_desc exynos4_soc_desc __initdata = {
> + .name = "Samsung Exynos4",
If you're ok, I preferred 'Samsung EXYNOS4'
> + soc_smp_init_ops(exynos4_soc_smp_init_ops)
> + soc_smp_ops(exynos4_soc_smp_ops)
> +};
> diff --git a/arch/arm/mach-exynos4/hotplug.c
b/arch/arm/mach-exynos4/hotplug.c
> index da70e7e..15fe884 100644
> --- a/arch/arm/mach-exynos4/hotplug.c
> +++ b/arch/arm/mach-exynos4/hotplug.c
> @@ -19,6 +19,8 @@
>
> #include <mach/regs-pmu.h>
>
> +#include "core.h"
> +
> extern volatile int pen_release;
>
> static inline void cpu_enter_lowpower(void)
> @@ -93,7 +95,7 @@ static inline void platform_do_lowpower(unsigned int
cpu, int
> *spurious)
> }
> }
>
> -int platform_cpu_kill(unsigned int cpu)
> +int exynos4_cpu_kill(unsigned int cpu)
> {
> return 1;
> }
> @@ -103,7 +105,7 @@ int platform_cpu_kill(unsigned int cpu)
> *
> * Called with IRQs disabled
> */
> -void platform_cpu_die(unsigned int cpu)
> +void exynos4_cpu_die(unsigned int cpu)
> {
> int spurious = 0;
>
> @@ -123,7 +125,7 @@ void platform_cpu_die(unsigned int cpu)
> pr_warn("CPU%u: %u spurious wakeup calls\n", cpu, spurious);
> }
>
> -int platform_cpu_disable(unsigned int cpu)
> +int exynos4_cpu_disable(unsigned int cpu)
> {
> /*
> * we don't allow CPU 0 to be shutdown (it is still too special
> diff --git a/arch/arm/mach-exynos4/mach-armlex4210.c b/arch/arm/mach-
> exynos4/mach-armlex4210.c
> index f0ca6c1..8c82c6b 100644
> --- a/arch/arm/mach-exynos4/mach-armlex4210.c
> +++ b/arch/arm/mach-exynos4/mach-armlex4210.c
> @@ -28,6 +28,8 @@
>
> #include <mach/map.h>
>
> +#include "core.h"
> +
> /* Following are default values for UCON, ULCON and UFCON UART registers
*/
> #define ARMLEX4210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> S3C2410_UCON_RXILEVEL | \
> @@ -208,6 +210,7 @@ static void __init armlex4210_machine_init(void)
> MACHINE_START(ARMLEX4210, "ARMLEX4210")
> /* Maintainer: Alim Akhtar <alim.akhtar@samsung.com> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = armlex4210_map_io,
> .init_machine = armlex4210_machine_init,
> diff --git a/arch/arm/mach-exynos4/mach-nuri.c
b/arch/arm/mach-exynos4/mach-
> nuri.c
> index 2204911..5780ee3 100644
> --- a/arch/arm/mach-exynos4/mach-nuri.c
> +++ b/arch/arm/mach-exynos4/mach-nuri.c
> @@ -48,6 +48,8 @@
>
> #include <mach/map.h>
>
> +#include <asm/soc.h>
> +
> /* Following are default values for UCON, ULCON and UFCON UART registers
*/
> #define NURI_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> S3C2410_UCON_RXILEVEL | \
> @@ -1187,6 +1189,7 @@ static void __init nuri_machine_init(void)
> MACHINE_START(NURI, "NURI")
> /* Maintainer: Kyungmin Park <kyungmin.park@samsung.com> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = nuri_map_io,
> .init_machine = nuri_machine_init,
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> index 421294b..06250fc 100644
> --- a/arch/arm/mach-exynos4/mach-origen.c
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -33,6 +33,8 @@
>
> #include <mach/map.h>
>
> +#include "core.h"
> +
> /* Following are default values for UCON, ULCON and UFCON UART registers
*/
> #define ORIGEN_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> S3C2410_UCON_RXILEVEL | \
> @@ -210,6 +212,7 @@ static void __init origen_machine_init(void)
> MACHINE_START(ORIGEN, "ORIGEN")
> /* Maintainer: JeongHyeon Kim <jhkim@insignal.co.kr> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = origen_map_io,
> .init_machine = origen_machine_init,
> diff --git a/arch/arm/mach-exynos4/mach-smdk4212.c b/arch/arm/mach-
> exynos4/mach-smdk4212.c
> index 8c41ae1..cf92514 100644
> --- a/arch/arm/mach-exynos4/mach-smdk4212.c
> +++ b/arch/arm/mach-exynos4/mach-smdk4212.c
> @@ -36,6 +36,8 @@
>
> #include <mach/map.h>
>
> +#include "core.h"
> +
> /* Following are default values for UCON, ULCON and UFCON UART registers
*/
> #define SMDK4212_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> S3C2410_UCON_RXILEVEL | \
> @@ -285,6 +287,7 @@ static void __init smdk4212_machine_init(void)
> MACHINE_START(SMDK4212, "SMDK4212")
> /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = smdk4212_map_io,
> .init_machine = smdk4212_machine_init,
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index cec2afa..525b042 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -43,6 +43,8 @@
>
> #include <mach/map.h>
>
> +#include "core.h"
> +
> /* Following are default values for UCON, ULCON and UFCON UART registers
*/
> #define SMDKV310_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> S3C2410_UCON_RXILEVEL | \
> @@ -373,6 +375,7 @@ MACHINE_START(SMDKV310, "SMDKV310")
> /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
> /* Maintainer: Changhwan Youn <chaos.youn@samsung.com> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = smdkv310_map_io,
> .init_machine = smdkv310_machine_init,
> @@ -383,6 +386,7 @@ MACHINE_END
> MACHINE_START(SMDKC210, "SMDKC210")
> /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = smdkv310_map_io,
> .init_machine = smdkv310_machine_init,
> diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c b/arch/arm/mach-
> exynos4/mach-universal_c210.c
> index a023faa..0c94673 100644
> --- a/arch/arm/mach-exynos4/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
> @@ -47,6 +47,8 @@
> #include <media/s5p_fimc.h>
> #include <media/m5mols.h>
>
> +#include "core.h"
> +
> /* Following are default values for UCON, ULCON and UFCON UART registers
*/
> #define UNIVERSAL_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> S3C2410_UCON_RXILEVEL | \
> @@ -1061,6 +1063,7 @@ static void __init universal_machine_init(void)
> MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
> /* Maintainer: Kyungmin Park <kyungmin.park@samsung.com> */
> .atag_offset = 0x100,
> + .soc = &exynos4_soc_desc,
> .init_irq = exynos4_init_irq,
> .map_io = universal_map_io,
> .init_machine = universal_machine_init,
> diff --git a/arch/arm/mach-exynos4/platsmp.c
b/arch/arm/mach-exynos4/platsmp.c
> index 500453f..1f419fa 100644
> --- a/arch/arm/mach-exynos4/platsmp.c
> +++ b/arch/arm/mach-exynos4/platsmp.c
> @@ -32,6 +32,8 @@
>
> #include <plat/cpu.h>
>
> +#include "core.h"
> +
> extern void exynos4_secondary_startup(void);
>
> #define CPU1_BOOT_REG (samsung_rev() ==
> EXYNOS4210_REV_1_1 ? \
> @@ -89,7 +91,7 @@ static void __cpuinit exynos4_gic_secondary_init(void)
> __raw_writel(1, cpu_base + GIC_CPU_CTRL);
> }
>
> -void __cpuinit platform_secondary_init(unsigned int cpu)
> +static void __cpuinit exynos4_secondary_init(unsigned int cpu)
> {
> /*
> * if any interrupts are already enabled for the primary
> @@ -113,7 +115,7 @@ void __cpuinit platform_secondary_init(unsigned int
cpu)
> set_cpu_online(cpu, true);
> }
>
> -int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
> +static int __cpuinit exynos4_boot_secondary(unsigned int cpu, struct
task_struct
> *idle)
> {
> unsigned long timeout;
>
> @@ -188,7 +190,7 @@ int __cpuinit boot_secondary(unsigned int cpu, struct
> task_struct *idle)
> * which may be present or become present in the system.
> */
>
> -void __init smp_init_cpus(void)
> +static void __init exynos4_smp_init_cpus(void)
> {
> void __iomem *scu_base = scu_base_addr();
> unsigned int i, ncores;
> @@ -210,7 +212,7 @@ void __init smp_init_cpus(void)
> set_smp_cross_call(gic_raise_softirq);
> }
>
> -void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> +static void __init exynos4_smp_prepare_cpus(unsigned int max_cpus)
> {
>
> scu_enable(scu_base_addr());
> @@ -224,3 +226,18 @@ void __init platform_smp_prepare_cpus(unsigned int
> max_cpus)
> __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)),
> CPU1_BOOT_REG);
> }
> +
> +struct arm_soc_smp_init_ops exynos4_soc_smp_init_ops __initdata = {
> + .smp_init_cpus = exynos4_smp_init_cpus,
> + .smp_prepare_cpus = exynos4_smp_prepare_cpus,
> +};
> +
> +struct arm_soc_smp_ops exynos4_soc_smp_ops __initdata = {
> + .smp_secondary_init = exynos4_secondary_init,
> + .smp_boot_secondary = exynos4_boot_secondary,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_kill = exynos4_cpu_kill,
> + .cpu_die = exynos4_cpu_die,
> + .cpu_disable = exynos4_cpu_disable,
> +#endif
> +};
> --
> 1.7.0.4
And could you please re-work this based on latest my for-next because there
are updated board file.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [GIT PULL] Samsung cleanup-2 for v3.2
From: Kukjin Kim @ 2011-10-04 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
This is second cleanup for Samsung stuff for v3.2 and includes cleanup
header files in plat-s3c24xx and plat-s5p to merge into one plat-samsung
directory.
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-cleanup-2
And this is based on previous Samsung cleanup branch, next-samsung-cleanup
which has been merged in arm-soc because of dependency.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit 4c59de052e7167a3bcf3f32c5ea4c9a5ef07386a:
Merge branch 'next/topic-plat-samsung-1' into next-samsung-cleanup
(2011-09-17 11:05:43 +0900)
are available in the git repository at:
git://github.com/kgene/linux-samsung.git next-samsung-cleanup-2
Kukjin Kim (6):
ARM: SAMSUNG: Cleanup mach/clkdev.h
ARM: SAMSUNG: Consolidate plat/pwm-clock.h
ARM: SAMSUNG: Consolidate plat/pll.h
ARM: SAMSUNG: Moving each SoC support header files
ARM: SAMSUNG: Move S3C24XX header files to plat-samsung
ARM: SAMSUNG: Move S5P header files to plat-samsung
Thomas Abraham (1):
ARM: SAMSUNG: remove sdhci default configuration setup platform helper
arch/arm/mach-exynos4/include/mach/clkdev.h | 7 -
arch/arm/mach-exynos4/setup-sdhci.c | 47 ---
arch/arm/mach-s3c2410/mach-h1940.c | 6 +-
arch/arm/mach-s3c2416/clock.c | 1 -
arch/arm/mach-s3c2416/setup-sdhci.c | 37 ---
arch/arm/mach-s3c64xx/clock.c | 5 +-
arch/arm/mach-s3c64xx/cpu.c | 4 +-
arch/arm/mach-s3c64xx/include/mach/clkdev.h | 7 -
arch/arm/mach-s3c64xx/include/mach/pll.h | 45 ---
arch/arm/mach-s3c64xx/include/mach/pwm-clock.h | 56 ----
arch/arm/mach-s3c64xx/mach-anw6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-crag6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-ncp.c | 2 +-
arch/arm/mach-s3c64xx/mach-real6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-smartq5.c | 2 +-
arch/arm/mach-s3c64xx/mach-smartq7.c | 2 +-
arch/arm/mach-s3c64xx/mach-smdk6400.c | 2 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
arch/arm/mach-s3c64xx/s3c6400.c | 2 +-
arch/arm/mach-s3c64xx/s3c6410.c | 4 +-
arch/arm/mach-s3c64xx/setup-sdhci.c | 48 ---
arch/arm/mach-s5p64x0/include/mach/clkdev.h | 7 -
arch/arm/mach-s5p64x0/include/mach/pwm-clock.h | 68 ----
arch/arm/mach-s5pc100/include/mach/clkdev.h | 7 -
arch/arm/mach-s5pc100/include/mach/pwm-clock.h | 56 ----
arch/arm/mach-s5pc100/setup-sdhci.c | 42 ---
arch/arm/mach-s5pv210/include/mach/clkdev.h | 7 -
arch/arm/mach-s5pv210/include/mach/pwm-clock.h | 70 -----
arch/arm/mach-s5pv210/setup-sdhci.c | 41 ---
arch/arm/plat-s3c24xx/include/mach/clkdev.h | 7 -
arch/arm/plat-s3c24xx/include/mach/pwm-clock.h | 55 ----
arch/arm/plat-s3c24xx/include/plat/pll.h | 62 ----
arch/arm/plat-s3c24xx/include/plat/regs-iis.h | 68 ----
arch/arm/plat-s3c24xx/include/plat/regs-spi.h | 81 -----
arch/arm/plat-s5p/include/plat/pll.h | 152 ---------
.../include/plat/audio-simtec.h | 2 +-
.../include/plat/camport.h | 6 +-
.../include/plat/common-smdk.h | 2 +-
.../include/plat/cpu-freq-core.h | 5 +-
.../{plat-s5p => plat-samsung}/include/plat/ehci.h | 6 +-
.../include/plat/exynos4.h | 2 +-
.../include/plat/fiq.h | 2 +-
.../include/plat/irq.h | 25 +-
.../{plat-s5p => plat-samsung}/include/plat/irqs.h | 8 +-
.../include/plat/mci.h | 10 +-
.../{plat-s5p => plat-samsung}/include/plat/mfc.h | 6 +-
.../include/plat/mipi_csis.h | 6 +-
arch/arm/plat-samsung/include/plat/pll.h | 323
++++++++++++++++++++
arch/arm/plat-samsung/include/plat/pll6553x.h | 51 ---
.../mach => plat-samsung/include/plat}/pwm-clock.h | 39 ++-
.../include/plat/regs-dma.h | 112 ++++----
arch/arm/plat-samsung/include/plat/regs-iis.h | 70 +++++
arch/arm/plat-samsung/include/plat/regs-spi.h | 48 +++
.../include/plat/regs-srom.h | 8 +-
.../include/plat/regs-udc.h | 132 ++++----
.../include/plat/reset.h | 8 +-
.../include/plat/s3c2410.h | 2 +-
.../include/plat/s3c2412.h | 2 +-
.../include/plat/s3c2416.h | 2 +-
.../include/plat/s3c2443.h | 2 +-
.../include/plat/s3c244x.h | 2 +-
.../mach => plat-samsung/include/plat}/s3c6400.h | 2 +-
.../mach => plat-samsung/include/plat}/s3c6410.h | 2 +-
.../include/plat/s5p-clock.h | 2 +-
.../include/plat/s5p-time.h | 2 +-
.../include/plat/s5p6440.h | 2 +-
.../include/plat/s5p6450.h | 2 +-
.../include/plat/s5pc100.h | 2 +-
.../include/plat/s5pv210.h | 2 +-
arch/arm/plat-samsung/include/plat/sdhci.h | 57 ----
.../include/plat/sysmmu.h | 6 +-
.../include/plat/system-reset.h | 2 +-
.../include/plat/udc.h | 4 +-
.../include/plat/usb-phy.h | 6 +-
arch/arm/plat-samsung/platformdata.c | 2 -
arch/arm/plat-samsung/pwm-clock.c | 13 +-
78 files changed, 693 insertions(+), 1306 deletions(-)
delete mode 100644 arch/arm/mach-exynos4/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-s3c64xx/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-s3c64xx/include/mach/pll.h
delete mode 100644 arch/arm/mach-s3c64xx/include/mach/pwm-clock.h
delete mode 100644 arch/arm/mach-s5p64x0/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-s5p64x0/include/mach/pwm-clock.h
delete mode 100644 arch/arm/mach-s5pc100/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-s5pc100/include/mach/pwm-clock.h
delete mode 100644 arch/arm/mach-s5pv210/include/mach/clkdev.h
delete mode 100644 arch/arm/mach-s5pv210/include/mach/pwm-clock.h
delete mode 100644 arch/arm/plat-s3c24xx/include/mach/clkdev.h
delete mode 100644 arch/arm/plat-s3c24xx/include/mach/pwm-clock.h
delete mode 100644 arch/arm/plat-s3c24xx/include/plat/pll.h
delete mode 100644 arch/arm/plat-s3c24xx/include/plat/regs-iis.h
delete mode 100644 arch/arm/plat-s3c24xx/include/plat/regs-spi.h
delete mode 100644 arch/arm/plat-s5p/include/plat/pll.h
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/audio-simtec.h
(95%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/camport.h (86%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/common-smdk.h
(87%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/cpu-freq-core.h
(98%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/ehci.h (84%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/exynos4.h (94%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/fiq.h (88%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/irq.h (81%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/irqs.h (96%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/mci.h (90%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/mfc.h (90%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/mipi_csis.h (90%)
create mode 100644 arch/arm/plat-samsung/include/plat/pll.h
delete mode 100644 arch/arm/plat-samsung/include/plat/pll6553x.h
rename arch/arm/{mach-exynos4/include/mach =>
plat-samsung/include/plat}/pwm-clock.h (68%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/regs-dma.h
(58%)
create mode 100644 arch/arm/plat-samsung/include/plat/regs-iis.h
create mode 100644 arch/arm/plat-samsung/include/plat/regs-spi.h
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/regs-srom.h (89%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/regs-udc.h
(51%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/reset.h (66%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/s3c2410.h (93%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/s3c2412.h (92%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/s3c2416.h (92%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/s3c2443.h (96%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/s3c244x.h (94%)
rename arch/arm/{mach-s3c64xx/include/mach =>
plat-samsung/include/plat}/s3c6400.h (94%)
rename arch/arm/{mach-s3c64xx/include/mach =>
plat-samsung/include/plat}/s3c6410.h (93%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/s5p-clock.h (96%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/s5p-time.h (94%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/s5p6440.h (94%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/s5p6450.h (94%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/s5pc100.h (94%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/s5pv210.h (94%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/sysmmu.h (96%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/system-reset.h
(92%)
rename arch/arm/{plat-s3c24xx => plat-samsung}/include/plat/udc.h (95%)
rename arch/arm/{plat-s5p => plat-samsung}/include/plat/usb-phy.h (83%)
^ permalink raw reply
* [GIT PULL] Samsung board-2 for v3.2
From: Kukjin Kim @ 2011-10-04 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
This is a second Samsung board stuff for v3.2 and includes new board,
SMDK4412.
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-board-2
As a note, since supporting SMDK4412 needs previous next-samsung-board
branch so this is based on next-samsung-board which has been already merged
into arm-soc and this includes converting boot_params to atag_offset for
adding/changing boards in this time.
If any problems, please let me know.
One more as a note, the next-samsung-devel and next-samsung-devel-2 will be
sent to you soon after testing ;)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit 2520123382e97271e932377c83bca010c265be55:
Merge branch 'next-samsung-board-v3.1' into next-samsung-board (2011-09-16
17:13:09 +0900)
are available in the git repository at:
git://github.com/kgene/linux-samsung.git next-samsung-board-2
Changhwan Youn (7):
ARM: EXYNOS4: Add support PPI in external GIC
ARM: EXYNOS4: Add support MCT PPI for EXYNOS4212
ARM: EXYNOS4: Add support new EXYNOS4412 SoC
ARM: EXYNOS4: Add support clock for EXYNOS4412
ARM: EXYNOS4: Add functions for gic interrupt handling
ARM: EXYNOS4: Add MCT support for EXYNOS4412
ARM: EXYNOS4: Add support SMDK4412 Board
Tushar Behera (1):
ARM: EXYNOS4: convert boot_params to atag_offset
arch/arm/mach-exynos4/Kconfig | 14 ++
arch/arm/mach-exynos4/Makefile | 3 +-
arch/arm/mach-exynos4/clock.c | 4 +-
arch/arm/mach-exynos4/cpu.c | 21 ++-
arch/arm/mach-exynos4/include/mach/entry-macro.S | 29 +++-
arch/arm/mach-exynos4/include/mach/irqs.h | 2 +
arch/arm/mach-exynos4/include/mach/map.h | 1 -
arch/arm/mach-exynos4/include/mach/regs-mct.h | 5 +-
arch/arm/mach-exynos4/mach-origen.c | 2 +-
.../{mach-smdk4212.c => mach-smdk4x12.c} | 128 ++++++++-------
arch/arm/mach-exynos4/mach-smdkv310.c | 4 +-
arch/arm/mach-exynos4/mct.c | 166
++++++++++++--------
arch/arm/mach-exynos4/platsmp.c | 5 +-
arch/arm/plat-s5p/cpu.c | 9 +
arch/arm/plat-samsung/include/plat/cpu.h | 8 +
15 files changed, 251 insertions(+), 150 deletions(-)
rename arch/arm/mach-exynos4/{mach-smdk4212.c => mach-smdk4x12.c} (61%)
^ permalink raw reply
* [PATCH v4 06/10] ARM: SoC: convert Exynos4 to SoC descriptor
From: Marc Zyngier @ 2011-10-04 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <019701cc8297$c91bd9e0$5b538da0$%kim@samsung.com>
On 04/10/11 14:16, Kukjin Kim wrote:
> Marc Zyngier wrote:
>>
>> Convert Exynos4 to use the SoC descriptor to provide its SMP
>> and CPU hotplug operations.
>>
>> Cc: Kukjin Kim <kgene.kim@samsung.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/mach-exynos4/core.h | 9 +++++++++
>> arch/arm/mach-exynos4/cpu.c | 8 ++++++++
>> arch/arm/mach-exynos4/hotplug.c | 8 +++++---
>> arch/arm/mach-exynos4/mach-armlex4210.c | 3 +++
>> arch/arm/mach-exynos4/mach-nuri.c | 3 +++
>> arch/arm/mach-exynos4/mach-origen.c | 3 +++
>> arch/arm/mach-exynos4/mach-smdk4212.c | 3 +++
>> arch/arm/mach-exynos4/mach-smdkv310.c | 4 ++++
>> arch/arm/mach-exynos4/mach-universal_c210.c | 3 +++
>> arch/arm/mach-exynos4/platsmp.c | 25
>> +++++++++++++++++++++----
>> 10 files changed, 62 insertions(+), 7 deletions(-)
>> create mode 100644 arch/arm/mach-exynos4/core.h
>>
>> diff --git a/arch/arm/mach-exynos4/core.h b/arch/arm/mach-exynos4/core.h
>> new file mode 100644
>> index 0000000..ba9fcc8
>> --- /dev/null
>> +++ b/arch/arm/mach-exynos4/core.h
>
> Is there any reason to add core.h in mach-exynos4 not
> mach-exynos4/include/mach?
No particular reason. If you prefer having that file in include/mach,
I'll move it, though I don't think it makes much more sense.
>> +
>> +struct arm_soc_desc exynos4_soc_desc __initdata = {
>> + .name = "Samsung Exynos4",
>
> If you're ok, I preferred 'Samsung EXYNOS4'
No problem.
> And could you please re-work this based on latest my for-next because there
> are updated board file.
Where is your for-next branch located these days? When it gets picked up
by linux-next, I'll update the board files. As of next-20111004, I seem
to cover them all.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 22/30] mfd: build twl6030 only on omap2
From: Arnd Bergmann @ 2011-10-04 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004104713.GY4118@sortiz-mobl>
On Tuesday 04 October 2011, Samuel Ortiz wrote:
> On Sun, Oct 02, 2011 at 04:45:52PM +0200, Arnd Bergmann wrote:
> > We can only have one pwm driver built into the kernel,
> I seem to remember that Bill Gatliff was working on a PWM subsystem that would
> get rid of the current pwm.h ugliness. Do we have any updates on this one ?
I don't know if the work on the pwm subsystem is progressing right now,
there were at one point two competing patches, but so far neither of them
has made it into linux-next.
> The patch below looks like a hack to me, trying to work around the current
> lack of such subsystem.
Absolutely. I'll clarify this in the patch description when I fix the
bug pointed out by Balaji T Krishnamoorthy.
Arnd
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: G, Manjunath Kondaiah @ 2011-10-04 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110922184614.25419.84606.stgit@ponder>
Hi Grant,
On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
> Allow drivers to report at probe time that they cannot get all the resources
> required by the device, and should be retried at a later time.
>
> This should completely solve the problem of getting devices
> initialized in the right order. Right now this is mostly handled by
> mucking about with initcall ordering which is a complete hack, and
> doesn't even remotely handle the case where device drivers are in
> modules. This approach completely sidesteps the issues by allowing
> driver registration to occur in any order, and any driver can request
> to be retried after a few more other drivers get probed.
>
> v3: - Hold off workqueue scheduling until late_initcall so that the bulk
> of driver probes are complete before we start retrying deferred devices.
> - Tested with simple use cases. Still needs more testing though.
> Using it to get rid of the gpio early_initcall madness, or to replace
> the ASoC internal probe deferral code would be ideal.
> v2: - added locking so it should no longer be utterly broken in that regard
> - remove device from deferred list at device_del time.
> - Still completely untested with any real use case, but has been
> boot tested.
>
> TODO: - Create a separate singlethread_workqueue so that drivers can't
> mess things up by calling flush_work().
> - Maybe this should be wrapped with a kconfig symbol so it can
> be compiled out on systems that don't care.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Greg Kroah-Hartman <greg@kroah.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Dilan Lee <dilee@nvidia.com>
> Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
> ---
>
> Hi Manjunath,
>
> Here's the current state of the patch. The major think that needs to
> be done is to convert it to use a separate workqueue as described in
> the TODO above. It also needs some users adapted to it. One of the
> gpio drivers would work; preferably one of the newer drivers that
> doesn't have a lot of drivers depending on the early_initcall()
> behaviour yet.
I have tested this patch on omap3 beagle board by making:
1. omap-gpio driver init as late_initcall instead of postcore_initcall
2. mmc driver probe will request gpio through gpio_request and gpio driver
returns -EDEFER_PROBE which in turn makes mmc driver to request deferral probe.
3. When deferral probe gets activated, it scans driver entries and it will not
find any match for mmc driver probe.
After step 3, mmc driver probe will not get called due to device and driver
mismatch during "bus_for_each_drv" execution.
The behaviour is no different when it is used with singlethread_workqueue.
Here is bootlog:
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2009.11 (Feb 23 2010 - 15:33:48)
OMAP3530-GP ES3.0, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 128 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Board revision Ax/Bx
Die ID #5ac400030000000004013f8901001001
Hit any key to stop autoboot: 0
mmc0 is available
mmc - MMC sub-system
Usage:
mmc init [dev] - init MMC sub system
mmc device [dev] - show or set current device
reading uImage
3237432 bytes read
## Booting kernel from Legacy Image at 80000000 ...
Image Name: Linux-3.1.0-rc8-00001-g4dc9843-d
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3237368 Bytes = 3.1 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Linux version 3.1.0-rc8-00001-g4dc9843-dirty (manju at manju-desktop) (gcc version 4.5.2 (Ubuntu/Linaro4.5.2-8ubuntu3) ) #7 SMP Tue Oct 4 19:19:49 IST 2011
[ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp)
...
[ 3.554656] driver_probe_device: drv->name: omap_hsmmc
[ 3.560241] omap_hsmmc_probe: ...........Enter *********************
[ 3.566955] omap_hsmmc_gpio_init: ..... enter .........!!!!
[ 3.572906] platform omap_hsmmc.0: Driver omap_hsmmc requests probe deferral
...
[ 3.712097] driver_probe_device: drv->name: omap_gpio
[ 3.717681] omap_device: omap_gpio.0: new worst case activate latency 0: 30517
[ 3.727813] OMAP GPIO hardware version 2.5
[ 3.732421] driver_probe_device: drv->name: omap_gpio
[ 3.739776] driver_probe_device: drv->name: omap_gpio
[ 3.747039] driver_probe_device: drv->name: omap_gpio
[ 3.754241] driver_probe_device: drv->name: omap_gpio
[ 3.761413] driver_probe_device: drv->name: omap_gpio
...
[ 3.800170] platform omap_hsmmc.0: Retrying from deferred list
[ 3.806304] bus_probe_device: device autoprobe
[ 3.811096] device_attach: ...........test-1
[ 3.815643] __device_attach: ...........test-4
[ 3.820312] __device_attach: ...........test-4
[ 3.825012] __device_attach: ...........test-4
[ 3.829681] __device_attach: ...........test-4
[ 3.834411] __device_attach: ...........test-4
[ 3.839111] __device_attach: ...........test-4
[ 3.843749] __device_attach: ...........test-4
[ 3.848480] __device_attach: ...........test-4
[ 3.853118] __device_attach: ...........test-4
[ 3.857818] __device_attach: ...........test-4
[ 3.862548] __device_attach: ...........test-4
[ 3.867218] __device_attach: ...........test-4
[ 3.871917] __device_attach: ...........test-4
[ 3.876556] __device_attach: ...........test-4
[ 3.881286] __device_attach: ...........test-4
[ 3.885986] __device_attach: ...........test-4
[ 3.890655] __device_attach: ...........test-4
[ 3.895355] __device_attach: ...........test-4
[ 3.900024] __device_attach: ...........test-4
[ 3.904724] __device_attach: ...........test-4
[ 3.909423] __device_attach: ...........test-4
[ 3.914093] __device_attach: ...........test-4
[ 3.918792] __device_attach: ...........test-4
[ 3.923461] __device_attach: ...........test-4
[ 3.928192] __device_attach: ...........test-4
[ 3.932891] __device_attach: ...........test-4
[ 3.937530] __device_attach: ...........test-4
[ 3.944458] input: gpio-keys as /devices/platform/gpio-keys/input/input1
[ 3.955657] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:01:59 UTC (946684919)
[ 3.969390] Waiting for root device /dev/mmcblk0p2...
Here it hangs since MMC driver is not ready!
-Manjunath
>
> Mark Brown may also be able to suggest specific examples.
>
> For everyone else; this is the current state of the patch. I think it
> is in pretty good shape other than the TODO item above. I'm turning
> it over to Manjunath to polish up for merging. I would appreciate
> any feedback.
>
> g.
>
>
> drivers/base/base.h | 1
> drivers/base/core.c | 2 +
> drivers/base/dd.c | 134 ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/device.h | 5 ++
> 4 files changed, 141 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/base.h b/drivers/base/base.h
> index a34dca0..9641309 100644
> --- a/drivers/base/base.h
> +++ b/drivers/base/base.h
> @@ -105,6 +105,7 @@ extern void bus_remove_driver(struct device_driver *drv);
>
> extern void driver_detach(struct device_driver *drv);
> extern int driver_probe_device(struct device_driver *drv, struct device *dev);
> +extern void driver_deferred_probe_del(struct device *dev);
> static inline int driver_match_device(struct device_driver *drv,
> struct device *dev)
> {
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index bc8729d..0d37e18 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -588,6 +588,7 @@ void device_initialize(struct device *dev)
> {
> dev->kobj.kset = devices_kset;
> kobject_init(&dev->kobj, &device_ktype);
> + INIT_LIST_HEAD(&dev->deferred_probe);
> INIT_LIST_HEAD(&dev->dma_pools);
> mutex_init(&dev->mutex);
> lockdep_set_novalidate_class(&dev->mutex);
> @@ -1119,6 +1120,7 @@ void device_del(struct device *dev)
> device_remove_file(dev, &uevent_attr);
> device_remove_attrs(dev);
> bus_remove_device(dev);
> + driver_deferred_probe_del(dev);
>
> /*
> * Some platform devices are driven without driver attached
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 6658da7..8be5b33 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -28,6 +28,129 @@
> #include "base.h"
> #include "power/power.h"
>
> +/*
> + * Deferred Probe infrastructure.
> + *
> + * Sometimes driver probe order matters, but the kernel doesn't always have
> + * dependency information which means some drivers will get probed before a
> + * resource it depends on is available. For example, an SDHCI driver may
> + * first need a GPIO line from an i2c GPIO controller before it can be
> + * initialized. If a required resource is not available yet, a driver can
> + * request probing to be deferred by returning -EAGAIN from its probe hook
> + *
> + * Deferred probe maintains two lists of devices, a pending list and an active
> + * list. A driver returning -EAGAIN causes the device to be added to the
> + * pending list.
> + *
> + * The deferred_probe_mutex *must* be held any time the deferred_probe_*_list
> + * of the (struct device*)->deferred_probe pointers are manipulated
> + */
> +static DEFINE_MUTEX(deferred_probe_mutex);
> +static LIST_HEAD(deferred_probe_pending_list);
> +static LIST_HEAD(deferred_probe_active_list);
> +
> +/**
> + * deferred_probe_work_func() - Retry probing devices in the active list.
> + */
> +static void deferred_probe_work_func(struct work_struct *work)
> +{
> + struct device *dev;
> + /*
> + * This bit is tricky. We want to process every device in the
> + * deferred list, but devices can be removed from the list at any
> + * time while inside this for-each loop. There are two things that
> + * need to be protected against:
> + * - if the device is removed from the deferred_probe_list, then we
> + * loose our place in the loop. Since any device can be removed
> + * asynchronously, list_for_each_entry_safe() wouldn't make things
> + * much better. Simplest solution is to restart walking the list
> + * whenever the current device gets removed. Not the most efficient,
> + * but is simple to implement and easy to audit for correctness.
> + * - if the device is unregistered, and freed, then there is a risk
> + * of a null pointer dereference. This code uses get/put_device()
> + * to ensure the device cannot disappear from under our feet.
> + */
> + mutex_lock(&deferred_probe_mutex);
> + while (!list_empty(&deferred_probe_active_list)) {
> + dev = list_first_entry(&deferred_probe_active_list,
> + typeof(*dev), deferred_probe);
> + list_del_init(&dev->deferred_probe);
> +
> + get_device(dev);
> +
> + /* Drop the mutex while probing each device; the probe path
> + * may manipulate the deferred list */
> + mutex_unlock(&deferred_probe_mutex);
> + dev_dbg(dev, "Retrying from deferred list\n");
> + bus_probe_device(dev);
> + mutex_lock(&deferred_probe_mutex);
> +
> + put_device(dev);
> + }
> + mutex_unlock(&deferred_probe_mutex);
> +}
> +static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);
> +
> +static void driver_deferred_probe_add(struct device *dev)
> +{
> + mutex_lock(&deferred_probe_mutex);
> + if (list_empty(&dev->deferred_probe)) {
> + dev_dbg(dev, "Added to deferred list\n");
> + list_add(&dev->deferred_probe, &deferred_probe_pending_list);
> + }
> + mutex_unlock(&deferred_probe_mutex);
> +}
> +
> +void driver_deferred_probe_del(struct device *dev)
> +{
> + mutex_lock(&deferred_probe_mutex);
> + if (!list_empty(&dev->deferred_probe)) {
> + dev_dbg(dev, "Removed from deferred list\n");
> + list_del_init(&dev->deferred_probe);
> + }
> + mutex_unlock(&deferred_probe_mutex);
> +}
> +
> +static bool driver_deferred_probe_enable = false;
> +/**
> + * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> + *
> + * This functions moves all devices from the pending list to the active
> + * list and schedules the deferred probe workqueue to process them. It
> + * should be called anytime a driver is successfully bound to a device.
> + */
> +static void driver_deferred_probe_trigger(void)
> +{
> + if (!driver_deferred_probe_enable)
> + return;
> +
> + /* A successful probe means that all the devices in the pending list
> + * should be triggered to be reprobed. Move all the deferred devices
> + * into the active list so they can be retried by the workqueue */
> + mutex_lock(&deferred_probe_mutex);
> + list_splice_tail_init(&deferred_probe_pending_list,
> + &deferred_probe_active_list);
> + mutex_unlock(&deferred_probe_mutex);
> +
> + /* Kick the re-probe thread. It may already be scheduled, but
> + * it is safe to kick it again. */
> + schedule_work(&deferred_probe_work);
> +}
> +
> +/**
> + * deferred_probe_initcall() - Enable probing of deferred devices
> + *
> + * We don't want to get in the way when the bulk of drivers are getting probed.
> + * Instead, this initcall makes sure that deferred probing is delayed until
> + * late_initcall time.
> + */
> +static int deferred_probe_initcall(void)
> +{
> + driver_deferred_probe_enable = true;
> + driver_deferred_probe_trigger();
> + return 0;
> +}
> +late_initcall(deferred_probe_initcall);
>
> static void driver_bound(struct device *dev)
> {
> @@ -42,6 +165,11 @@ static void driver_bound(struct device *dev)
>
> klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
>
> + /* Make sure the device is no longer in one of the deferred lists
> + * and kick off retrying all pending devices */
> + driver_deferred_probe_del(dev);
> + driver_deferred_probe_trigger();
> +
> if (dev->bus)
> blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> BUS_NOTIFY_BOUND_DRIVER, dev);
> @@ -142,7 +270,11 @@ probe_failed:
> driver_sysfs_remove(dev);
> dev->driver = NULL;
>
> - if (ret != -ENODEV && ret != -ENXIO) {
> + if (ret == -EAGAIN) {
> + /* Driver requested deferred probing */
> + dev_info(dev, "Driver %s requests probe deferral\n", drv->name);
> + driver_deferred_probe_add(dev);
> + } else if (ret != -ENODEV && ret != -ENXIO) {
> /* driver matched but the probe failed */
> printk(KERN_WARNING
> "%s: probe of %s failed with error %d\n",
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c20dfbf..dab93a4 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -506,6 +506,10 @@ struct device_dma_parameters {
> * @mutex: Mutex to synchronize calls to its driver.
> * @bus: Type of bus device is on.
> * @driver: Which driver has allocated this
> + * @deferred_probe: entry in deferred_probe_list which is used to retry the
> + * binding of drivers which were unable to get all the resources
> + * needed by the device; typically because it depends on another
> + * driver getting probed first.
> * @platform_data: Platform data specific to the device.
> * Example: For devices on custom boards, as typical of embedded
> * and SOC based hardware, Linux often uses platform_data to point
> @@ -564,6 +568,7 @@ struct device {
> struct bus_type *bus; /* type of bus device is on */
> struct device_driver *driver; /* which driver has allocated this
> device */
> + struct list_head deferred_probe;
> void *platform_data; /* Platform specific data, device
> core doesn't touch it */
> struct dev_pm_info power;
>
^ permalink raw reply
* [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
From: Arnd Bergmann @ 2011-10-04 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <019301cc8293$79a6f510$6cf4df30$%kim@samsung.com>
On Tuesday 04 October 2011, Kukjin Kim wrote:
> > I think the string concatenation really just obfuscates the code, and
> > it does not actually save much at all. When you replace
> >
> > + [0] = SAMSUNG_RES_MEM(S3C, WDT, SZ_1K),
> > + [1] = SAMSUNG_RES_IRQ(WDT),
> >
> > with
> >
> > + [0] = DEFINE_RES_MEM(S3C_PA_WDT, SZ_1K),
> > + [1] = DEFINE_RES_IRQ(IRQ_WDT),
> >
> > you need practically no extra space, but you gain the advantages that
> >
> > * Someone using grep for DEFINE_RES_MEM finds all memory resources without
> > having to look up what your macros do an where they are used.
> > * Someone using grep to look for S3C_PA_WDT finds the place where it is
> used.
> > * Someone reading the resource definition immediately knows what the
> > macro does if familiar with other platforms using that macro.
>
> Yes, right. But I'm preparing to reduce the 'soc' part to consolidate some
> duplicated resources and platform data after this and the new SAMSUNG_RES
> macro will be used.
Hmm, can't you instead change the names of these constants to be
always the same? That would let you use the regular DEFINE_RES_*
definitions without having to introduce your own.
Arnd
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: Grant Likely @ 2011-10-04 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d3edllum.fsf@ti.com>
On Mon, Oct 3, 2011 at 5:02 PM, Kevin Hilman <khilman@ti.com> wrote:
> Grant Likely <grant.likely@secretlab.ca> writes:
>
>> Allow drivers to report at probe time that they cannot get all the resources
>> required by the device, and should be retried at a later time.
>>
>> This should completely solve the problem of getting devices
>> initialized in the right order. ?Right now this is mostly handled by
>> mucking about with initcall ordering which is a complete hack, and
>> doesn't even remotely handle the case where device drivers are in
>> modules. ?This approach completely sidesteps the issues by allowing
>> driver registration to occur in any order, and any driver can request
>> to be retried after a few more other drivers get probed.
>
> This is great work, thanks!
>
> For the TODO list:
>
> While the proposed patch should solve probe order dependencies, I don't
> think it will solve the suspend/resume ordering dependencies, which are
> typically the same.
>
> Currenly suspend/resume order is based on the order devices are *added*
> (device_add() -> device_pm_add() -> device added to dpm_list), so
> unfortunately, deferring probe isn't going to affect suspend/resume
> ordering.
>
> Extending this to also address suspend/resume ordering by also changing
> when the device is added to the dpm_list (or possibly creating another
> list) should probably be explored as well.
Hmm, yes, I think this is worth exploring. It doesn't help with
runtime pm dependencies, but it has the potential to make PM just work
if the list order is updated each time a device is successfully bound
to a driver. Manjunath, can you investigate what it would take to do
this? (after getting the core deferral patch finalized; I don't want
to block that work)?
g.
^ permalink raw reply
* [PATCH 26/30] ARM: omap: add board autoselection
From: Tony Lindgren @ 2011-10-04 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110040944.13205.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [111004 00:10]:
> On Monday 03 October 2011, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [111003 02:20]:
> > > On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> > > > >
> > > > > In the long run, I'd hope we can just get rid of these for subarchitectures
> > > > > that support device tree probing and make the device tree based machine
> > > > > description unconditional.
> > > >
> > > > This is really our goal, we will have soon the board-generic.c for that,
> > > > someone will just have to migrate these ~30 board files to device tree
> > > > DTS files
> > >
> > > For the purpose of build-time validation using randconfig, there is no
> > > problem in keeping some board files forever, as long as the generic board
> > > file is always built-in.
> >
> > Yes please leave out the list so we don't need to constantly update it.
> > Let's just always build in MACH_OMAP_GENERIC.
>
> That's what I had initially, but now that board file has become
> omap2-specific and no longer works on omap3-only or omap4-only
> configurations.
Will send a pull request for basic DT bootstrap support from Benoit
that fixes that. So maybe let's sort that out first, then always
select it?
Regards,
Tony
^ permalink raw reply
* [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
From: Grant Likely @ 2011-10-04 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111004145148.GA8021@manju-desktop>
On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
>> Hi Manjunath,
>>
>> Here's the current state of the patch. ?The major think that needs to
>> be done is to convert it to use a separate workqueue as described in
>> the TODO above. ?It also needs some users adapted to it. ?One of the
>> gpio drivers would work; preferably one of the newer drivers that
>> doesn't have a lot of drivers depending on the early_initcall()
>> behaviour yet.
>
> I have tested this patch on omap3 beagle board by making:
> 1. omap-gpio driver init as late_initcall instead of postcore_initcall
> 2. mmc driver probe will request gpio through gpio_request and gpio driver
> returns -EDEFER_PROBE which in turn makes mmc driver to request deferral probe.
> 3. When deferral probe gets activated, it scans driver entries and it will not
> find any match for mmc driver probe.
Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
instead of platform_driver_register(). Add the probe hook to the
platform_driver structure and change it to call
platform_driver_register() and it should work. Don't forget to change
mmc_omap_probe from __init to __devinit.
g.
^ permalink raw reply
* [PATCH 0/3] GIC OF bindings
From: Rob Herring @ 2011-10-04 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317410880-24828-1-git-send-email-robherring2@gmail.com>
Grant,
On 09/30/2011 02:27 PM, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Another round of GIC devicetree support.
>
> This moves the tracking of the starting hwirq number into the irq domain
> code. Doing this makes hwirq == GIC interrupt ID and simplifies the GIC
> code removing irq_offset.
>
> The full series is available here. This includes Russell's devel-stable and
> for-next branches and Nico's vmalloc branch:
>
> git://git.jdl.com/software/linux-3.0.git gic-v2
>
> Tested on highbank and Realview 11MPCore qemu (2 GICs).
>
> Rob
>
> Rob Herring (3):
> irq: support domains with non-zero hwirq base
> ARM: gic: add irq_domain support
> ARM: gic: add OF based initialization
>
> Documentation/devicetree/bindings/arm/gic.txt | 55 ++++++++++
> arch/arm/common/Kconfig | 1 +
> arch/arm/common/gic.c | 142 +++++++++++++++++++------
> arch/arm/include/asm/hardware/gic.h | 5 +-
> include/linux/irqdomain.h | 16 +++-
> kernel/irq/irqdomain.c | 12 +-
> 6 files changed, 189 insertions(+), 42 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
Ping. Can you please comment on this series.
Rob
^ permalink raw reply
* [PATCH] virtio: Add platform bus driver for memory mapped virtio device
From: Pawel Moll @ 2011-10-04 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878vp1iqpz.fsf@rustcorp.com.au>
Greetings!
> > +/* The alignment to use between consumer and producer parts of vring.
> > + * Currently hardcoded to page size. */
> > +#define VIRTIO_MMIO_VRING_ALIGN PAGE_SIZE
>
> Really? Shouldn't that just be 4k? I haven't seen the qemu side of
> this, but it seems weird to depend on the kernel's idea of page size...
Well, the Host doesn't really care now, as it's told what the alignment
is:
> + /* Activate the queue */
> + writel(VIRTIO_MMIO_VRING_ALIGN,
> + vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN);
> + writel(virt_to_phys(info->queue) >> PAGE_SHIFT,
> + vm_dev->base + VIRTIO_MMIO_QUEUE_PFN);
And I've just chosen the PAGE_SIZE instead of 4096 following the
suggestion from your original paper ("Note that there is padding such as
to place this structure on a page separate from the available ring and
descriptor array:").
> Note that the seabios/coreboot hackers wanted a smaller ring alignment
> so they didn't have to waste two precious pages per device. You might
> want to consider making this an option in the header (perhaps express
> it as log2, eg. 12 rather than 4096).
I had an impression that you were planning to add some API for the
devices to choose the alignment? If so this #define would simply
disappear... Generally, the Client is in control now.
> > + /* TODO: Write requested queue size to VIRTIO_MMIO_QUEUE_NUM */
> > +
> > + /* Check if queue is either not available or already active. */
> > + num = readl(vm_dev->base + VIRTIO_MMIO_QUEUE_NUM);
> > + if (!num || readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN)) {
>
> Please fix this now, like so:
>
> /* Queue shouldn't already be set up. */
> if (readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN))
> ...
>
> /* Try for a big queue, drop down to a two-page queue. */
> num = VIRTIO_MMIO_MAX_RING;
Ok, but how much would MAX_RING be? 1024? 513? 127? I really wouldn't
like to be a judge here... I was hoping the device would tell me that
(it knows what amounts of data are likely to be processed?)
> for (;;) {
> size = PAGE_ALIGN(vring_size(num, VIRTIO_MMIO_VRING_ALIGN));
> info->queue = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO);
> if (info->queue)
> break;
>
> /* Already smallest possible allocation? */
> if (size == VIRTIO_MMIO_VRING_ALIGN*2) {
> err = -ENOMEM;
> goto error_kmalloc;
> }
> num /= 2;
> }
and then
writel(num, vm_dev->base + VIRTIO_MMIO_QUEUE_NUM);
Can do. This, however, gets us back to this question: can the Host
cowardly refuse the requested queue size? If you really think that it
can't, I'm happy to accept that and change the spec accordingly. If it
can, we'll have to read the size back and potentially re-alloc pages...
Cheers!
Pawe?
^ permalink raw reply
* [RFC PATCH] tty/serial: atmel_serial: add device tree support
From: Grant Likely @ 2011-10-04 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8A6858.6020700@gmail.com>
On Mon, Oct 03, 2011 at 08:58:48PM -0500, Rob Herring wrote:
> On 10/03/2011 04:51 AM, Nicolas Ferre wrote:
> > static int __devinit atmel_serial_probe(struct platform_device *pdev)
> > {
> > struct atmel_uart_port *port;
> > + struct device_node *np = pdev->dev.of_node;
> > struct atmel_uart_data *pdata = pdev->dev.platform_data;
> > void *data;
> > int ret;
> >
> > BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
> >
> > - port = &atmel_ports[pdata->num];
> > + if (np) {
> > + ret = of_alias_get_id(np, "serial");
> > + if (ret < 0)
> > + goto err;
>
> I'll defer to Grant on this. There aren't any other drivers using this.
>
This is the correct thing to do.
One note however; I prefer driver to *not* require an alias to be
present. By all means, use an alias if it is available, but the
driver should auto-enumerate if it is not. There is a patch that
makes of_alias_get_id() do this for you, but it hasn't been mainlined
yet and it is still a bit in flux. There will be something that takes
care of this for you, but be aware that the function name may change.
In the mean time, this patch is okay.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
g.
^ permalink raw reply
* [RFC PATCH] tty/serial: atmel_serial: add device tree support
From: Grant Likely @ 2011-10-04 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8B054B.3060506@gmail.com>
On Tue, Oct 04, 2011 at 08:08:27AM -0500, Rob Herring wrote:
> Nicolas,
>
> On 10/04/2011 03:18 AM, Nicolas Ferre wrote:
> > On 10/04/2011 03:58 AM, Rob Herring :
> >> On 10/03/2011 04:51 AM, Nicolas Ferre wrote:
> >>> +Optional properties:
> >>> +- atmel,use-dma-rx: use of PDC or DMA for receiving data
> >>> +- atmel,use-dma-tx: use of PDC or DMA for transmitting data
> >>
> >> Is this an internal DMA or separate DMA controller? If the latter, these
> >> should be phandles to a DMA channel/request.
> >
> > Well, for now it relies on PDC (looks like an internal DMA). There is no
> > notion of channel/request so I think it is appropriate to keep it like this.
> >
>
> Okay. Although, this is a bit of Linux creeping into DT. DT should
> describe the h/w. You should really be describing whether the h/w
> supports DMA or not rather than whether you want to use DMA or not.
> Since DMA support is really tied to the SOC rather than board, you could
> just use the compatible string to distinguish platforms that support DMA
> or not. So what is determining this setting? Is it purely user choice?
It is okay for a binding to still requires config properties like this
to state if the DMA can be used, even if compatible is enough to
distinquish. However, you're right to bring it up. It is a design
choice that should be made thoughtfully.
g.
^ permalink raw reply
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
From: Grant Likely @ 2011-10-04 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E858D35.50903@ti.com>
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
> On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> >On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> >>On 9/27/2011 8:59 PM, Mark Brown wrote:
> >
> >>>I'm not sure how this should work in a device tree world, I'd *hope*
> >>>we'd get a device tree node for the CPU and could then just make this a
> >>>regular consumer thing but then the cpufreq drivers would need to be
> >>>updated to make use of it. The only reason we allow null devices right
> >>>now is the fact that cpufreq doesn't have a struct device it can use.
> >
> >>That's why we do have a MPU node in OMAP dts, in order to build an
> >>omap_device that will be mainly used for the DVFS on the MPU.
> >
> >>And even before DT migration, we used to build statically some
> >>omap_device to represent the various processors in the system (MPU,
> >>DSP, CortexM3...).
> >
> >Yeah, but that's very OMAP specific - we don't have that in general (in
> >fact it's the only Linux platform I'm aware of that has a device for the
> >CPU).
>
> But isn't this the right thing to do for everyone else too?
>
It is normal to have nodes for each CPU. The /cpus/ node normally
contains cpu@* nodes for each logical cpu core, and I would expect
nodes for each additional DSP and MPU core. Whether or not they
belong in the /cpus/ node is a matter of design (we don't have any
patterns for that yet).
g.
^ permalink raw reply
* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Kevin Hilman @ 2011-10-04 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316844884-21700-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
> suspend (S2R), CPU hotplug and CPUidle.
No need to repost, but can you update the versions in your branch to
have an ARM: prefix in the subject per Arnd's recent request?
Thanks,
Kevin
^ permalink raw reply
* Please help with the OMAP static mapping mess
From: Tony Lindgren @ 2011-10-04 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMQu2gxgRZzb6hh5pOVBgaPUZEizEqBr_e358MBuD_xHJOvX3Q@mail.gmail.com>
* Shilimkar, Santosh <santosh.shilimkar@ti.com> [111003 22:45]:
> On Tue, Oct 4, 2011 at 4:29 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [111003 15:05]:
> >> On Mon, 3 Oct 2011, Nicolas Pitre wrote:
> >>
> >> > On Mon, 3 Oct 2011, Tony Lindgren wrote:
> >> >
> >> > > * Nicolas Pitre <nico@fluxnic.net> [111003 11:26]:
> >> > > >
> >> > > > Furthermore... there is also a static mapping for physical address
> >> > > > 0x4e000000 using virtual address 0xff100000 which is already reserved
> >> > > > for other purposes i.e. the consistent DMA area. ?It is not immediately
> >> > > > obvious where this comes from without being intimate with the OMAP code.
> >> > > > Can this be fixed as well i.e. moved elsewhere please?
> >> > >
> >> > > This sounds like a bug somewhere. Which omap are you seeing this on?
> >> >
> >> > OMAP4430 on a Panda board.
> >> >
> >> > Here are the static mappings I'm seeing:
> >> >
> >> > phys = 0x44000000 virt = 0xf8000000 size = 0x100000
> >> > phys = 0x4a000000 virt = 0xfc000000 size = 0x400000
> >> > phys = 0x50000000 virt = 0xf9000000 size = 0x100000
> >> > phys = 0x4c000000 virt = 0xfd100000 size = 0x100000
> >> > phys = 0x4d000000 virt = 0xfe100000 size = 0x100000
> >> > phys = 0x4e000000 virt = 0xff100000 size = 0x100000 <---
> >> > phys = 0x48000000 virt = 0xfa000000 size = 0x400000
> >> > phys = 0x54000000 virt = 0xfe800000 size = 0x800000
> >>
> >> It looks like this comes from OMAP44XX_DMM_VIRT.
> >>
> >> #define OMAP44XX_DMM_PHYS ? ? ? OMAP44XX_DMM_BASE
> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* 0x4e000000 --> 0xfd300000 */
> >> #define OMAP44XX_DMM_VIRT ? ? ? (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET)
> >> #define OMAP44XX_DMM_SIZE ? ? ? SZ_1M
> >>
> >> The comment suggesting a mapping correspondance is obviously wrong. We have:
> >>
> >> #define OMAP44XX_DMM_BASE ? ? ? 0x4e000000
> >> #define OMAP4_L3_PER_IO_OFFSET ?0xb1100000
> >>
> >> Hence 0x4e000000 + 0xb1100000 = 0xff100000.
> >
> > Seem like it might cause some random patterns in tiler :)
> > Santosh, can youp please check it?
> >
> This is already fixed Tony. You have pulled that patch.
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg55258.html
OK thanks. Yup, looks like it's queued up in l3 branch.
Tony
^ 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