* [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
From: Kyungmin Park @ 2011-09-14 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1311659456-6659-3-git-send-email-m.szyprowski@samsung.com>
Hi,
It's required for boot universal c210 w/ EVT0 chip.
Can you include it at 3.1 fixed branch?
Thank you,
Kyungmin Park
On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Commit 069d4e743 removed support for local timers and forced to use MCT as
> event source. However MCT is not operating properly on early revision (EVT0)
> of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0, so that
> commit broke support for it. This patch provides a workaround that enables
> UniversalC210 boards to boot again. s5p-timer is used as an event source.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? ? ? | ? ?3 +++
> ?arch/arm/mach-exynos4/mach-universal_c210.c | ? ?4 +++-
> ?2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 9d62e13..2aad73f 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
> ?config MACH_UNIVERSAL_C210
> ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
> ? ? ? ?select CPU_EXYNOS4210
> + ? ? ? select S5P_HRT
> + ? ? ? select CLKSRC_MMIO
> + ? ? ? select HAVE_SCHED_CLOCK
> ? ? ? ?select S5P_GPIO_INT
> ? ? ? ?select S5P_DEV_FIMC0
> ? ? ? ?select S5P_DEV_FIMC1
> diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c b/arch/arm/mach-exynos4/mach-universal_c210.c
> index 0e280d1..ca9e7b7 100644
> --- a/arch/arm/mach-exynos4/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
> @@ -34,6 +34,7 @@
> ?#include <plat/mfc.h>
> ?#include <plat/sdhci.h>
> ?#include <plat/pd.h>
> +#include <plat/s5p-time.h>
>
> ?#include <mach/map.h>
>
> @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
> ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> ? ? ? ?s3c24xx_init_clocks(24000000);
> ? ? ? ?s3c24xx_init_uarts(universal_uartcfgs, ARRAY_SIZE(universal_uartcfgs));
> + ? ? ? s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
> ?}
>
> ?static void __init universal_reserve(void)
> @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
> ? ? ? ?.init_irq ? ? ? = exynos4_init_irq,
> ? ? ? ?.map_io ? ? ? ? = universal_map_io,
> ? ? ? ?.init_machine ? = universal_machine_init,
> - ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
> + ? ? ? .timer ? ? ? ? ?= &s5p_timer,
> ? ? ? ?.reserve ? ? ? ?= &universal_reserve,
> ?MACHINE_END
> --
> 1.7.1.569.g6f426
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v15 11/12] OMAP: dmtimer: extend spinlock to exported APIs
From: DebBarma, Tarun Kanti @ 2011-09-14 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913231540.GI24252@atomide.com>
On Wed, Sep 14, 2011 at 4:45 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Tarun Kanti DebBarma <tarun.kanti@ti.com> [110908 13:36]:
>> Since the exported APIs can be called from interrupt context
>> extend spinlock protection to some more relevant APIs to avoid
>> race condition.
>
> We should have locking for requesting and releasing a timer etc,
> but I don't see need for that for the timer specific functions.
Alright... I will remove locking from timer specific functions.
In that case we have extension of locks to just following two functions:
omap_dm_timer_request()
omap_dm_timer_request_specific()
So, I can modify the patch subject and description accordingly.
>
>> @@ -317,9 +317,11 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
>> ?void omap_dm_timer_start(struct omap_dm_timer *timer)
>> ?{
>> ? ? ? u32 l;
>> + ? ? unsigned long flags;
>>
>> ? ? ? omap_dm_timer_enable(timer);
>>
>> + ? ? spin_lock_irqsave(&dm_timer_lock, flags);
>> ? ? ? if (timer->loses_context) {
>> ? ? ? ? ? ? ? u32 ctx_loss_cnt_after =
>> ? ? ? ? ? ? ? ? ? ? ? timer->get_context_loss_count(&timer->pdev->dev);
>
> Here the caller already owns the timer being started. So there
> should never be multiple users for a single timer. If there are,
> then the caller should take care of locking.
Ok.
>
>> ?void omap_dm_timer_stop(struct omap_dm_timer *timer)
>> ?{
>> - ? ? unsigned long rate = 0;
>> + ? ? unsigned long rate = 0, flags;
>> ? ? ? struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
>> ? ? ? bool is_omap2 = true;
>>
>> + ? ? spin_lock_irqsave(&dm_timer_lock, flags);
>> ? ? ? if (pdata->needs_manual_reset)
>> ? ? ? ? ? ? ? is_omap2 = false;
>> ? ? ? else
>
> Here too.
Right.
>
>> @@ -389,8 +394,10 @@ void omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned int load)
>> ?{
>> ? ? ? u32 l;
>> + ? ? unsigned long flags;
>>
>> ? ? ? omap_dm_timer_enable(timer);
>> + ? ? spin_lock_irqsave(&dm_timer_lock, flags);
>> ? ? ? l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
>> ? ? ? if (autoreload)
>> ? ? ? ? ? ? ? l |= OMAP_TIMER_CTRL_AR;
>
> And here.
Ok.
>
>> @@ -412,9 +420,11 @@ void omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?unsigned int load)
>> ?{
>> ? ? ? u32 l;
>> + ? ? unsigned long flags;
>>
>> ? ? ? omap_dm_timer_enable(timer);
>>
>> + ? ? spin_lock_irqsave(&dm_timer_lock, flags);
>> ? ? ? if (timer->loses_context) {
>> ? ? ? ? ? ? ? u32 ctx_loss_cnt_after =
>> ? ? ? ? ? ? ? ? ? ? ? timer->get_context_loss_count(&timer->pdev->dev);
>
> Not needed here either. And that's the case for all the other functions
> too.
Sure.
--
Tarun
>
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-09-14 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYkuhhR8yNMK1cENan9WX5Fv7o_0qSN3_c3VJQwrvzgjg@mail.gmail.com>
On Sun, 2011-09-11 at 23:27 +0200, Linus Walleij wrote:
> On Thu, Sep 8, 2011 at 11:38 PM, Vinod Koul <vkoul@infradead.org> wrote:
> >
> > Linus W, any progress on that patches you posted??
>
> I haven't written any, and I felt the whole issue was pretty inflamed
> too so I felt bad about it and avoided to think about it even since
> I have no real problem with this in my current setups.
>
> Currently there is a strong coupling between platforms and filter
> functions and I can live with it in the systems I use since they have
> just one DMAC and need only one filter function per device,
> that is specified in platform data for the device. This would likely
> also work for the SiRFprimaII if it has only a single DMAC.
> The people facing an immediate issue with this are IIRC the
> Samsung S5Ps.
>
> If you think this is in need of solving soon and want me to propose
> patches for channel mapping to devices using the approach used in
> clkdev and regulator APIs to create an attributed mapping table
> using struct device * or its string representations, I can
> try it out of course, but if it gets flamy I will just back off again.
Please try at my request. I really would like this problem to be solved.
What we want is API which solves filter function issues (we should be
able to completely do away after proper mapping). Making a simple to
understand/code/maintain scheme which is platform independent.
--
~Vinod
^ permalink raw reply
* [PATCH] ARM: mach-mxs/mx28evk: Only register devices if their GPIO requests succeeded
From: Shawn Guo @ 2011-09-14 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315945519-15178-1-git-send-email-festevam@gmail.com>
On Tue, Sep 13, 2011 at 05:25:19PM -0300, Fabio Estevam wrote:
> Currently framebuffer and MMC devices are registered even if their associated
> GPIO pins fail to be requested.
>
> Change the logic so that the registration of such devices only occurs if their
> GPIO requests succeeded.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-mxs/mach-mx28evk.c | 18 ++++++++++++------
> 1 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> index 3f86e7a..e5c66a2 100644
> --- a/arch/arm/mach-mxs/mach-mx28evk.c
> +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> @@ -353,7 +353,7 @@ static struct mxs_mmc_platform_data mx28evk_mmc_pdata[] __initdata = {
>
> static void __init mx28evk_init(void)
> {
> - int ret;
> + int ret, gpio_lcd_error;
Shouldn't gpio_lcd_error be initialized as 0?
>
> mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
>
> @@ -378,18 +378,23 @@ static void __init mx28evk_init(void)
> }
>
> ret = gpio_request_one(MX28EVK_LCD_ENABLE, GPIOF_DIR_OUT, "lcd-enable");
> - if (ret)
> + if (ret) {
> pr_warn("failed to request gpio lcd-enable: %d\n", ret);
> + gpio_lcd_error = 1;
> + }
> else
> gpio_set_value(MX28EVK_LCD_ENABLE, 1);
Per Documentation/CodingStyle, this should be like the following.
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
>
> ret = gpio_request_one(MX28EVK_BL_ENABLE, GPIOF_DIR_OUT, "bl-enable");
> - if (ret)
> + if (ret) {
> pr_warn("failed to request gpio bl-enable: %d\n", ret);
> + gpio_lcd_error = 1;
> + }
> else
> gpio_set_value(MX28EVK_BL_ENABLE, 1);
Ditto
Otherwise, Acked-by: Shawn Guo <shawn.guo@linaro.org>
Regards,
Shawn
>
> - mx28_add_mxsfb(&mx28evk_mxsfb_pdata);
> + if (!gpio_lcd_error)
> + mx28_add_mxsfb(&mx28evk_mxsfb_pdata);
>
> /* power on mmc slot by writing 0 to the gpio */
> ret = gpio_request_one(MX28EVK_MMC0_SLOT_POWER, GPIOF_OUT_INIT_LOW,
> @@ -402,8 +407,9 @@ static void __init mx28evk_init(void)
> "mmc1-slot-power");
> if (ret)
> pr_warn("failed to request gpio mmc1-slot-power: %d\n", ret);
> - mx28_add_mxs_mmc(1, &mx28evk_mmc_pdata[1]);
> -
> + else
> + mx28_add_mxs_mmc(1, &mx28evk_mmc_pdata[1]);
> +
> gpio_led_register_device(0, &mx28evk_led_data);
> }
>
> --
> 1.7.1
^ permalink raw reply
* [PATCH] ARM: mach-mxs/mx28evk: Only register devices if their GPIO requests succeeded
From: Shawn Guo @ 2011-09-14 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C29LY2_zj3jh1k1ygy+v+m+RioKVdrKGQ46N4=sWA7ig@mail.gmail.com>
On Wed, Sep 14, 2011 at 12:12:40AM -0300, Fabio Estevam wrote:
> On Wed, Sep 14, 2011 at 12:18 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> > On Tue, Sep 13, 2011 at 05:25:19PM -0300, Fabio Estevam wrote:
> >> Currently framebuffer and MMC devices are registered even if their associated
> >> GPIO pins fail to be requested.
> >>
> >> Change the logic so that the registration of such devices only occurs if their
> >> GPIO requests succeeded.
> >>
> >> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> >> ---
> > So the question is whether the gpio request failure is a show-stopper
> > failure for framebuffer and mmc.
>
> If the GPIO that controls LCD enable or backlight enable failed it is
> not very useful to register the framebuffer, do you agree?
>
> Same for MMC.
>
Agreed.
Regards,
Shawn
> You did the same logic for the CAN bus, so I extended it for the
> framebuffer and MMC.
^ permalink raw reply
* [PATCH] ARM: mach-mxs/mx28evk: Only register devices if their GPIO requests succeeded
From: Shawn Guo @ 2011-09-14 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315945519-15178-1-git-send-email-festevam@gmail.com>
On Tue, Sep 13, 2011 at 05:25:19PM -0300, Fabio Estevam wrote:
> Currently framebuffer and MMC devices are registered even if their associated
> GPIO pins fail to be requested.
>
> Change the logic so that the registration of such devices only occurs if their
> GPIO requests succeeded.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
So the question is whether the gpio request failure is a show-stopper
failure for framebuffer and mmc.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] ARM: mach-mxs/mx28evk: Only register devices if their GPIO requests succeeded
From: Fabio Estevam @ 2011-09-14 3:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914031803.GC2368@S2100-06.ap.freescale.net>
On Wed, Sep 14, 2011 at 12:18 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> On Tue, Sep 13, 2011 at 05:25:19PM -0300, Fabio Estevam wrote:
>> Currently framebuffer and MMC devices are registered even if their associated
>> GPIO pins fail to be requested.
>>
>> Change the logic so that the registration of such devices only occurs if their
>> GPIO requests succeeded.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
> So the question is whether the gpio request failure is a show-stopper
> failure for framebuffer and mmc.
If the GPIO that controls LCD enable or backlight enable failed it is
not very useful to register the framebuffer, do you agree?
Same for MMC.
You did the same logic for the CAN bus, so I extended it for the
framebuffer and MMC.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Rob Clark @ 2011-09-14 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000501cc7282$7e7dcb70$7b796250$%dae@samsung.com>
On Tue, Sep 13, 2011 at 9:03 PM, Inki Dae <inki.dae@samsung.com> wrote:
> Hi Thomas.
>
>> -----Original Message-----
>> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
>> Sent: Monday, September 12, 2011 3:32 PM
>> To: Rob Clark
>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
>> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>>
>> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
>> > On 09/10/2011 07:31 PM, Rob Clark wrote:
>> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
>> >> Hellstrom<thomas@shipmail.org> ?wrote:
>> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
>> >>>> This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
>> >>>> only FIMD yet but we will add HDMI support also in the future.
>> >>>>
>> >>>> from now on, I will remove RFC prefix because I think we have got
>> >>>> comments
>> >>>> enough.
>> >>>>
>> >>>> this patch is based on git repository below:
>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
>> >>>> branch name: drm-next
>> >>>> commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
>> >>>>
>> >>>> you can refer to our working repository below:
>> >>>> http://git.infradead.org/users/kmpark/linux-2.6-samsung
>> >>>> branch name: samsung-drm
>> >>>>
>> >>>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
>> >>>> based on Linux framebuffer) but couldn't so because lowlevel codes
>> >>>> of s3c-fb.c are included internally and so FIMD module of this
>> >>>> driver has
>> >>>> its own lowlevel codes.
>> >>>>
>> >>>> We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
>> >>>> for buffer allocation. by using DMA API, we could use CMA later.
>> >>>>
>> >>>> Refer to this link for CMA(Continuous Memory Allocator):
>> >>>> http://lkml.org/lkml/2011/7/20/45
>> >>>>
>> >>>> this driver supports only physically continuous memory(non-iommu).
>> >>>>
>> >>>> Links to previous versions of the patchset:
>> >>>> v1:< ? ?https://lwn.net/Articles/454380/>
>> >>>> v2:< ? ?http://www.spinics.net/lists/kernel/msg1224275.html>
>> >>>> v3:< ? ?http://www.gossamer-threads.com/lists/linux/kernel/1423684>
>> >>>>
>> >>>> Changelog v2:
>> >>>> DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
>> >>>>
>> >>>> ? ? ?this feature maps user address space to physical memory region
>> >>>> ? ? ?once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
>> >>>>
>> >>>> DRM: code clean and add exception codes.
>> >>>>
>> >>>> Changelog v3:
>> >>>> DRM: Support multiple irq.
>> >>>>
>> >>>> ? ? ?FIMD and HDMI have their own irq handler but DRM Framework can
>> >>>> regiter
>> >>>> ? ? ?only one irq handler this patch supports mutiple irq for
>> >>>> Samsung SoC.
>> >>>>
>> >>>> DRM: Consider modularization.
>> >>>>
>> >>>> ? ? ?each DRM, FIMD could be built as a module.
>> >>>>
>> >>>> DRM: Have indenpendent crtc object.
>> >>>>
>> >>>> ? ? ?crtc isn't specific to SoC Platform so this patch gets a crtc
>> >>>> ? ? ?to be used as common object.
>> >>>> ? ? ?created crtc could be attached to any encoder object.
>> >>>>
>> >>>> DRM: code clean and add exception codes.
>> >>>>
>> >>>> Changelog v4:
>> >>>> DRM: remove is_defult from samsung_fb.
>> >>>>
>> >>>> ? ? ?is_default isn't used for default framebuffer.
>> >>>>
>> >>>> DRM: code refactoring to fimd module.
>> >>>> ? ? ?this patch is be considered with multiple display objects and
>> >>>> ? ? ?would use its own request_irq() to register a irq handler
>> >>>> instead of
>> >>>> ? ? ?drm framework's one.
>> >>>>
>> >>>> DRM: remove find_samsung_drm_gem_object()
>> >>>>
>> >>>> DRM: move kernel private data structures and definitions to driver
>> >>>> folder.
>> >>>>
>> >>>> ? ? ?samsung_drm.h would contain only public information for
> userspace
>> >>>> ? ? ?ioctl interface.
>> >>>>
>> >>>> DRM: code refactoring to gem modules.
>> >>>> ? ? ?buffer module isn't dependent of gem module anymore.
>> >>>>
>> >>>> DRM: fixed security issue.
>> >>>>
>> >>>> DRM: remove encoder porinter from specific connector.
>> >>>>
>> >>>> ? ? ?samsung connector doesn't need to have generic encoder.
>> >>>>
>> >>>> DRM: code clean and add exception codes.
>> >>>>
>> >>>> Signed-off-by: Inki Dae<inki.dae@samsung.com>
>> >>>> Signed-off-by: Joonyoung Shim<jy0922.shim@samsung.com>
>> >>>> Signed-off-by: SeungWoo Kim<sw0312.kim@samsung.com>
>> >>>> Signed-off-by: kyungmin.park<kyungmin.park@samsung.com>
>> >>>> ---
>> >>>>
>> >>>> +static struct drm_ioctl_desc samsung_ioctls[] = {
>> >>>> + ? ? ? DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>> >>>> samsung_drm_gem_create_ioctl,
>> >>>> + ? ? ? ? ? ? ? ? ? ? ? DRM_UNLOCKED | DRM_AUTH),
>> >>>>
>> >>> Hi!
>> >>>
>> >>> With reference my previous security comment.
>> >>>
>> >>> Let's say you have a compromised video player running as a DRM
>> >>> client, that
>> >>> tries to repeatedly allocate huge GEM buffers...
>> >>>
>> >>> What will happen when all DMA memory is exhausted? Will this cause
>> >>> other
>> >>> device drivers to see an OOM, or only DRM?
>> >>>
>> >>> The old DRI model basically allowed any authorized DRI client to
>> >>> exhaust
>> >>> video ram or AGP memory, but never system memory. Newer DRI drivers
>> >>> typically only allow DRI masters to do that.
>> >>> as
>> >>>
>> >>> I don't think an authorized DRI client should be able to easily
>> exhaust
>> >>> resources (DMA memory) used by other device drivers causing them to
>> >>> fail.
>> >> I'm not entirely sure what else can be done, other than have a
>> >> threshold on max MB allocatable of buffer memory..
>> >
>> > Yes, I think that's what needs to be done, and that threshold should
>> > be low enough to keep other device drivers running in the worst
>> > allocation case.
>> >
>> >> In the samsung driver case, he is only allocating scanout memory from
>> >> CMA, so the limit will be the CMA region size.. beyond that you can't
>> >> get physically contiguous memory. ?So I think this driver is safe.
>> >
>> > It's not really what well-behaved user-space drivers do that should be
>> > a concern, but what compromized application *might* do that is a
> concern.
>>
>> Hmm. I might have missed your point here. If the buffer allocation ioctl
>> only allows allocating CMA memory, then I agree the driver fits the old
>> DRI security model, as long as no other devices on the platform will
>> ever use CMA.
>>
>> But in that case, there really should be a way for the driver to say
>> "Hey, all CMA memory on this system is mine", in the same way
>> traditional video drivers can claim the VRAM PCI resource.
>>
>
> CMA could reserve memory region for a specific driver so DRM Client could
> request memory allocation from only the region.
>
>> This is to avoid the possibility that future drivers that need CMA will
>> be vulnerable to DOS-attacks from ill-behaved DRI clients.
>>
>
> Thomas, if any application has root authority for ill-purpose then isn't it
> possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
> authority. I know DRM Framework gives any root application DRM_AUTH
> authority for compatibility.
DRM_AUTH just means that the client has authenticated w/ X11 (meaning
that it has permission to connect to x server)..
But I think that since memory allocation is limited to the size of the
CMA region, that this puts a reasonable cap of the memory that can be
allocated by the client. If this is a problem, it certainly isn't the
worst problem. You could still limit via file permissions the users
that can open the DRM device file, so it is really no worse than other
devices like v4l2..
BR,
-R
>> /Thomas
>>
>
>
>
^ permalink raw reply
* [PATCH 01/11] clk: Add a generic clock infrastructure
From: Saravana Kannan @ 2011-09-14 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314191759-16941-1-git-send-email-broonie@opensource.wolfsonmicro.com >
On Wed, August 24, 2011 6:15 am, Mark Brown wrote:
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 1d37f42..93ff870 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> -struct clk;
> +static inline int clk_prepare(struct clk *clk) { return 0; }
> +static inline void clk_unprepare(struct clk *clk) { }
> +
You should add might_sleep() inside these stubs. That way, if any device
driver developers wants to move over to the new APIs before their arch
does, they get to see the warnings when they call prepare/unprepare in
atomic context.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Inki Dae @ 2011-09-14 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E6DA767.9080408@shipmail.org>
Hi Thomas.
> -----Original Message-----
> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
> Sent: Monday, September 12, 2011 3:32 PM
> To: Rob Clark
> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; linux-
> arm-kernel at lists.infradead.org; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>
> On 09/11/2011 11:26 PM, Thomas Hellstrom wrote:
> > On 09/10/2011 07:31 PM, Rob Clark wrote:
> >> On Sat, Sep 10, 2011 at 9:04 AM, Thomas
> >> Hellstrom<thomas@shipmail.org> wrote:
> >>> On 09/09/2011 01:38 PM, Inki Dae wrote:
> >>>> This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
> >>>> only FIMD yet but we will add HDMI support also in the future.
> >>>>
> >>>> from now on, I will remove RFC prefix because I think we have got
> >>>> comments
> >>>> enough.
> >>>>
> >>>> this patch is based on git repository below:
> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
> >>>> branch name: drm-next
> >>>> commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> >>>>
> >>>> you can refer to our working repository below:
> >>>> http://git.infradead.org/users/kmpark/linux-2.6-samsung
> >>>> branch name: samsung-drm
> >>>>
> >>>> We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
> >>>> based on Linux framebuffer) but couldn't so because lowlevel codes
> >>>> of s3c-fb.c are included internally and so FIMD module of this
> >>>> driver has
> >>>> its own lowlevel codes.
> >>>>
> >>>> We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
> >>>> for buffer allocation. by using DMA API, we could use CMA later.
> >>>>
> >>>> Refer to this link for CMA(Continuous Memory Allocator):
> >>>> http://lkml.org/lkml/2011/7/20/45
> >>>>
> >>>> this driver supports only physically continuous memory(non-iommu).
> >>>>
> >>>> Links to previous versions of the patchset:
> >>>> v1:< https://lwn.net/Articles/454380/>
> >>>> v2:< http://www.spinics.net/lists/kernel/msg1224275.html>
> >>>> v3:< http://www.gossamer-threads.com/lists/linux/kernel/1423684>
> >>>>
> >>>> Changelog v2:
> >>>> DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> >>>>
> >>>> this feature maps user address space to physical memory region
> >>>> once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
> >>>>
> >>>> DRM: code clean and add exception codes.
> >>>>
> >>>> Changelog v3:
> >>>> DRM: Support multiple irq.
> >>>>
> >>>> FIMD and HDMI have their own irq handler but DRM Framework can
> >>>> regiter
> >>>> only one irq handler this patch supports mutiple irq for
> >>>> Samsung SoC.
> >>>>
> >>>> DRM: Consider modularization.
> >>>>
> >>>> each DRM, FIMD could be built as a module.
> >>>>
> >>>> DRM: Have indenpendent crtc object.
> >>>>
> >>>> crtc isn't specific to SoC Platform so this patch gets a crtc
> >>>> to be used as common object.
> >>>> created crtc could be attached to any encoder object.
> >>>>
> >>>> DRM: code clean and add exception codes.
> >>>>
> >>>> Changelog v4:
> >>>> DRM: remove is_defult from samsung_fb.
> >>>>
> >>>> is_default isn't used for default framebuffer.
> >>>>
> >>>> DRM: code refactoring to fimd module.
> >>>> this patch is be considered with multiple display objects and
> >>>> would use its own request_irq() to register a irq handler
> >>>> instead of
> >>>> drm framework's one.
> >>>>
> >>>> DRM: remove find_samsung_drm_gem_object()
> >>>>
> >>>> DRM: move kernel private data structures and definitions to driver
> >>>> folder.
> >>>>
> >>>> samsung_drm.h would contain only public information for
userspace
> >>>> ioctl interface.
> >>>>
> >>>> DRM: code refactoring to gem modules.
> >>>> buffer module isn't dependent of gem module anymore.
> >>>>
> >>>> DRM: fixed security issue.
> >>>>
> >>>> DRM: remove encoder porinter from specific connector.
> >>>>
> >>>> samsung connector doesn't need to have generic encoder.
> >>>>
> >>>> DRM: code clean and add exception codes.
> >>>>
> >>>> Signed-off-by: Inki Dae<inki.dae@samsung.com>
> >>>> Signed-off-by: Joonyoung Shim<jy0922.shim@samsung.com>
> >>>> Signed-off-by: SeungWoo Kim<sw0312.kim@samsung.com>
> >>>> Signed-off-by: kyungmin.park<kyungmin.park@samsung.com>
> >>>> ---
> >>>>
> >>>> +static struct drm_ioctl_desc samsung_ioctls[] = {
> >>>> + DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
> >>>> samsung_drm_gem_create_ioctl,
> >>>> + DRM_UNLOCKED | DRM_AUTH),
> >>>>
> >>> Hi!
> >>>
> >>> With reference my previous security comment.
> >>>
> >>> Let's say you have a compromised video player running as a DRM
> >>> client, that
> >>> tries to repeatedly allocate huge GEM buffers...
> >>>
> >>> What will happen when all DMA memory is exhausted? Will this cause
> >>> other
> >>> device drivers to see an OOM, or only DRM?
> >>>
> >>> The old DRI model basically allowed any authorized DRI client to
> >>> exhaust
> >>> video ram or AGP memory, but never system memory. Newer DRI drivers
> >>> typically only allow DRI masters to do that.
> >>> as
> >>>
> >>> I don't think an authorized DRI client should be able to easily
> exhaust
> >>> resources (DMA memory) used by other device drivers causing them to
> >>> fail.
> >> I'm not entirely sure what else can be done, other than have a
> >> threshold on max MB allocatable of buffer memory..
> >
> > Yes, I think that's what needs to be done, and that threshold should
> > be low enough to keep other device drivers running in the worst
> > allocation case.
> >
> >> In the samsung driver case, he is only allocating scanout memory from
> >> CMA, so the limit will be the CMA region size.. beyond that you can't
> >> get physically contiguous memory. So I think this driver is safe.
> >
> > It's not really what well-behaved user-space drivers do that should be
> > a concern, but what compromized application *might* do that is a
concern.
>
> Hmm. I might have missed your point here. If the buffer allocation ioctl
> only allows allocating CMA memory, then I agree the driver fits the old
> DRI security model, as long as no other devices on the platform will
> ever use CMA.
>
> But in that case, there really should be a way for the driver to say
> "Hey, all CMA memory on this system is mine", in the same way
> traditional video drivers can claim the VRAM PCI resource.
>
CMA could reserve memory region for a specific driver so DRM Client could
request memory allocation from only the region.
> This is to avoid the possibility that future drivers that need CMA will
> be vulnerable to DOS-attacks from ill-behaved DRI clients.
>
Thomas, if any application has root authority for ill-purpose then isn't it
possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
authority. I know DRM Framework gives any root application DRM_AUTH
authority for compatibility.
> /Thomas
>
^ permalink raw reply
* [RFC] Kbuild: allow code re-use across different directories
From: Michal Marek @ 2011-09-14 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACqU3MUfJAeur_65i5vDegu1d1VqAdq15EedfX9A3w52J23MPg@mail.gmail.com>
Dne 13.9.2011 23:13, Arnaud Lacombe napsal(a):
> 2011/9/9 Michal Marek <mmarek@suse.cz>:
>> On 20.8.2011 02:37, Arnaud Lacombe wrote:
>>> With the attached patch, we would do:
>>>
>>> arch/foo/boot/Makefile:
>>> LDFLAGS_fancy.o := -DPANTS=30
>>> obj-y += fancy.o
>>> vpath-y += $(srctree)/arch/foo/lib
>>>
>>> and let GNU make do the job.
>>
>> I like this. The only issue I can think of right now, is that if you add
>> a large directory to vpath-y, then it would be easy to accidentally
>> reuse more files from that directory than intended. But that could be
>> easily prevented by isolating those reusable source files.
>>
> I do not think it is that dangerous. We enforce unique access to VPATH
> and we still prioritize $(src) over any other specified path.
>
> That said, what would you want to pull the patch into -next, beside
> kernel.org being up ?
Just post it with a proper signoff. But there won't be any linux-next
until kernel.org is back again.
Michal
^ permalink raw reply
* [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux
From: Barry Song @ 2011-09-14 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdan_g6dBvuXwbAdtHFd14GLkKsKLcHnybTuNGmYiqcStA@mail.gmail.com>
2011/9/13 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Sep 2, 2011 at 6:04 PM, Stephen Warren <swarren@nvidia.com> wrote:
>> Linus Walleij wrote at Friday, September 02, 2011 2:12 AM:
>>> On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>>
>>> >> +static const struct u300_pmx_func u300_pmx_functions[] = {
>>> >> + ? ? {
>>> >> + ? ? ? ? ? ? .name = "power",
>>> >> + ? ? ? ? ? ? .groups = { POWERGRP_INDEX },
>>> >> + ? ? ? ? ? ? /* Mask is N/A */
>>> >> + ? ? },
>>> >
>>> > Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
>>> > to fully represent a chip like Tegra. Can the pinmux core be modified
>>> > such that the group list is an array of names (char*) rather than the
>>> > actual numeric IDs of the groups? Still, perhaps we could use the enum
>>> > we already have for this, so perhaps it isn't a big deal...
>>>
>>> Well I could think about a lot of ways to do this, but it's basically up
>>> to the driver, the U300 is just some simple example of what you can
>>> do, it's just trying to satisfy the API.
>>>
>>> Maybe as part of writing the nVidia driver you find a clever
>>> mechanism for doing this, if it's looking generally useful at that
>>> point then let's move it to the core I'd say.
>>
>> The reason I asked about the pinmux core handling this is because the
>> driver op get_function_groups:
>>
>> + ? ? ? int (*get_function_groups) (struct pinctrl_dev *pctldev,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned selector,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned ** const groups,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned * const num_groups);
>>
>> returns an array of integer indexes. I think the only way to get rid of
>> the index definitions in the drivers is to allow get_function_groups to
>> return an array of strings instead.
>
> OK good idea, I reworked this interface to get an array of strings
> instead, I've been told several times to use strings rather than numbers
> when possible, so I think this is the right thing to do.
>
> Check it out in v7!
well. we'll rebase prima2 pinmux on v7.
>
> Yours,
> Linus Walleij
>
-barry
^ permalink raw reply
* [PATCH] ARM: tegra: Remove redundant change to the CPSR in headsmp.S
From: Colin Cross @ 2011-09-14 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110912165222.GE2020@arm.com>
On Mon, Sep 12, 2011 at 9:52 AM, Dave Martin <dave.martin@linaro.org> wrote:
> Colin, can you comment on this?
>
> On Wed, Sep 07, 2011 at 05:00:53PM +0100, Dave Martin wrote:
>> At secondary_startup, the MSR CPSR_cxsf, #0xd3 is not compatible
>> with Thumb-2 and also unmasks asynchronous aborts (CPSR.A bit
>> forced to zero -- this is probably unintentional).
>>
>> Any remotely sane bootloader should be putting each secondary CPU
>> in the appropriate state _before_ entering the kernel anyway.
>> Otherwise, disabling interrupts on entry to the kernel isn't going
>> to fix it.
>>
>> Therefore this patch just removes the MSR instruction.
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>> ---
>>
>> I make assumptions about the bootloader in this patch. ?If someone with
>> Tegra knowledge can please comment and/or test, that would be much
>> appreciated, thanks.
>>
>> ?arch/arm/mach-tegra/headsmp.S | ? ?1 -
>> ?1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-tegra/headsmp.S b/arch/arm/mach-tegra/headsmp.S
>> index b5349b2..6ec4790 100644
>> --- a/arch/arm/mach-tegra/headsmp.S
>> +++ b/arch/arm/mach-tegra/headsmp.S
>> @@ -48,7 +48,6 @@ ENTRY(v7_invalidate_l1)
>> ?ENDPROC(v7_invalidate_l1)
>>
>> ?ENTRY(tegra_secondary_startup)
>> - ? ? msr ? ? cpsr_fsxc, #0xd3
>> ? ? ? ? ?bl ? ? ?v7_invalidate_l1
>> ? ? ? mrc ? ? p15, 0, r0, c0, c0, 5
>> ? ? ? ? ?and ?r0, r0, #15
>
> My rationale here is that the CPU boots straight into the
> correct mode -- if there is any boot code before we get here,
> then it should already have established the correct mode, otherwise
> we're likely to get problems which "MSR" by itself isn't going to
> fix -- such as stray interrupts for example.
>
> If that feels unsafe however, we should still to be able to write
>
> ? ? ? ?cpsid ? aif, #SVC_MODE
>
> (which is the compact v6/v7-compatible way to set all the interrupt
> mask bits and get into a specific mode)
Tegra boots with one cpu enabled, and the other in reset. The cpu
needs to be initialized from scratch by the kernel. Does cpsid aif,
#SVC_MODE compile to the same instruction as the msr instruction?
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Inki Dae @ 2011-09-14 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E6B6E5E.3010702@shipmail.org>
Hi Thomas.
Sorry for being late.
> -----Original Message-----
> From: Thomas Hellstrom [mailto:thomas at shipmail.org]
> Sent: Saturday, September 10, 2011 11:04 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> sw0312.kim at samsung.com; kyungmin.park at samsung.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
>
> On 09/09/2011 01:38 PM, Inki Dae wrote:
> > This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
> > only FIMD yet but we will add HDMI support also in the future.
> >
> > from now on, I will remove RFC prefix because I think we have got
> comments
> > enough.
> >
> > this patch is based on git repository below:
> > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git,
> > branch name: drm-next
> > commit-id: bcc65fd8e929a9d9d34d814d6efc1d2793546922
> >
> > you can refer to our working repository below:
> > http://git.infradead.org/users/kmpark/linux-2.6-samsung
> > branch name: samsung-drm
> >
> > We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
> > based on Linux framebuffer) but couldn't so because lowlevel codes
> > of s3c-fb.c are included internally and so FIMD module of this driver
> has
> > its own lowlevel codes.
> >
> > We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
> > for buffer allocation. by using DMA API, we could use CMA later.
> >
> > Refer to this link for CMA(Continuous Memory Allocator):
> > http://lkml.org/lkml/2011/7/20/45
> >
> > this driver supports only physically continuous memory(non-iommu).
> >
> > Links to previous versions of the patchset:
> > v1:< https://lwn.net/Articles/454380/>
> > v2:< http://www.spinics.net/lists/kernel/msg1224275.html>
> > v3:< http://www.gossamer-threads.com/lists/linux/kernel/1423684>
> >
> > Changelog v2:
> > DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.
> >
> > this feature maps user address space to physical memory region
> > once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.
> >
> > DRM: code clean and add exception codes.
> >
> > Changelog v3:
> > DRM: Support multiple irq.
> >
> > FIMD and HDMI have their own irq handler but DRM Framework can
> regiter
> > only one irq handler this patch supports mutiple irq for Samsung
SoC.
> >
> > DRM: Consider modularization.
> >
> > each DRM, FIMD could be built as a module.
> >
> > DRM: Have indenpendent crtc object.
> >
> > crtc isn't specific to SoC Platform so this patch gets a crtc
> > to be used as common object.
> > created crtc could be attached to any encoder object.
> >
> > DRM: code clean and add exception codes.
> >
> > Changelog v4:
> > DRM: remove is_defult from samsung_fb.
> >
> > is_default isn't used for default framebuffer.
> >
> > DRM: code refactoring to fimd module.
> > this patch is be considered with multiple display objects and
> > would use its own request_irq() to register a irq handler instead
of
> > drm framework's one.
> >
> > DRM: remove find_samsung_drm_gem_object()
> >
> > DRM: move kernel private data structures and definitions to driver
> folder.
> >
> > samsung_drm.h would contain only public information for userspace
> > ioctl interface.
> >
> > DRM: code refactoring to gem modules.
> > buffer module isn't dependent of gem module anymore.
> >
> > DRM: fixed security issue.
> >
> > DRM: remove encoder porinter from specific connector.
> >
> > samsung connector doesn't need to have generic encoder.
> >
> > DRM: code clean and add exception codes.
> >
> > Signed-off-by: Inki Dae<inki.dae@samsung.com>
> > Signed-off-by: Joonyoung Shim<jy0922.shim@samsung.com>
> > Signed-off-by: SeungWoo Kim<sw0312.kim@samsung.com>
> > Signed-off-by: kyungmin.park<kyungmin.park@samsung.com>
> > ---
> >
> > +static struct drm_ioctl_desc samsung_ioctls[] = {
> > + DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE, samsung_drm_gem_create_ioctl,
> > + DRM_UNLOCKED | DRM_AUTH),
> >
>
> Hi!
>
> With reference my previous security comment.
>
> Let's say you have a compromised video player running as a DRM client,
> that tries to repeatedly allocate huge GEM buffers...
>
> What will happen when all DMA memory is exhausted? Will this cause other
> device drivers to see an OOM, or only DRM?
>
Out driver allocates physically continuous memory from the region reserved
by CMA or DMA Region in case of not using CMA. if all memory is exhausted at
allocation moment, it just returns "Allocation fail" and then the
application would be terminated.
> The old DRI model basically allowed any authorized DRI client to exhaust
> video ram or AGP memory, but never system memory. Newer DRI drivers
> typically only allow DRI masters to do that.
> as
>
I thought it's enough for an authorized DRI client to request memory
allocation. because an authorized DRI client has root authority. I know, in
case of v4l2 based device drivers, the applications can request buffer
allocation through v4l2 interface, REQBUFS. and also if memory allocation is
repeated, we can see any error in the near future. and I wonder why only DRM
master could do that. it might be my missing points so I am happy to you
give me your words?
> I don't think an authorized DRI client should be able to easily exhaust
> resources (DMA memory) used by other device drivers causing them to fail.
>
> /Thomas
>
>
> > + DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_MAP_OFFSET,
> > + samsung_drm_gem_map_offset_ioctl, DRM_UNLOCKED |
> > + DRM_AUTH),
> > + DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_MMAP,
> > + samsung_drm_gem_mmap_ioctl, DRM_UNLOCKED |
DRM_AUTH),
> > +};
> >
> >
>
^ permalink raw reply
* [PATCH 0/3] ARCH: CSR: basic PM suspend/resume support
From: Barry Song @ 2011-09-14 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109131811.28241.arnd@arndb.de>
Hi Arnd,
Thanks!
2011/9/14 Arnd Bergmann <arnd@arndb.de>:
> On Tuesday 13 September 2011, Barry Song wrote:
>>
>> it was in thread "ARM: CSR: add rtciobrg and PM support" before. See:
>> http://www.spinics.net/lists/arm-kernel/msg137375.html
>>
>> Arnd has pulled rtciobrg into arm-soc next branch. PM should be another
>> series.
>
> Looks good to me, feel free to add my Acked-by to the patches, but
> please add a meaningful changelog text to each patch first.
> You can use some of the text that you put in the introductory mail.
>
ok. i will. and thanks.
> In general, I expect even trivial patches to have a changelog of
> one sentence and more text if the patch touches more code.
make sense.
>
> If nobody has other comments on the code, please send me a pull
> request once that is done.
a problem is patch 3/3 depends on Shawn Guo <shawn.guo@linaro.org>'s
[PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from
initialization functions
http://www.spinics.net/lists/arm-kernel/msg139198.html
it seems Russell hasn't given feedback yet. i am not sure Russell's
opinion about how to suspend/resume l2 for SoCs whose l2 cache will
lose in suspend cycle. in my opinion, a complete re-init is simplest.
For imx6q and omap who will not lose l2 in suspend cycle, Russell sent
a patchset about suspend and required l2 re-enabled before cpu_resume
by omap/imx6q platform-specific codes.
>
> ? ? ? ?Arnd
Thanks
barry
^ permalink raw reply
* [patch] ARM: smpboot: Enable interrupts after marking CPU online/active
From: Frank Rowand @ 2011-09-14 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913175312.GB6267@n2100.arm.linux.org.uk>
On 09/13/11 10:53, Russell King - ARM Linux wrote:
> On Tue, Sep 13, 2011 at 07:22:16PM +0200, Vincent Guittot wrote:
>> The assumption done in the 1st patch that smp_store_cpu_info can be
>> delayed is no more true. The smp_store_cpu_info is now also used to
>> store the cpu topology information
>> (https://lkml.org/lkml/2011/7/5/209). This must be done before calling
>> sched_init_smp, which will use this information for building
>> sched_domain.
>> If we move set_cpu_online before smp_store_cpu_info, sched_init_smp
>> can be called before having called smp_store_cpu_info on all cpus.
>
> Right. We hold off returning from cpu_up() by watching for the upcoming
> CPU setting its online bit.
>
> The bug which Thomas' patch introduces is to move the setting of that
> before we've finished bringing the CPU up - specifically, allowing the
> requesting CPU to continue while the brought-up CPU is still calibrating
> loops_per_jiffy, and before it's stored that information and setup the
> scheduler domain information.
>
> The other issue is that moving the marking of the CPU online in the
> way Thomas has means that we then invite the delivery of IPIs to the
> CPU which is still in the process of coming up. Whether that's an
> issue depends on what the IPIs are.
>
> So, we must have the setting of CPU online _after_ we've setup the
> scheduler domain information etc - so the following is a strict
> ordering:
>
> 1. calibrate_delay()
> 2. smp_store_cpu_info()
> 3. set_cpu_online()
>
> Now, the question is do we need interrupts enabled to setup timers
> via percpu_timer_setup() and calibrate delay. Can we move enabling
> interrupts after smp_store_cpu_info(). IOW, instead of moving the
> setting of cpu online before all this, can we move notify_cpu_starting()
> and the enabling of _both_ interrupts after smp_store_cpu_info()...
> No idea at the moment.
Modified the patch from Thomas to move enabling interrupts after
smp_store_cpu_info(), as suggested by Russell.
Tested on RealView (3.0.1, 3.0.1-rt11), Panda (3.0.0, 3.0.3-rt12).
The calibrate_delay() is platform specific, so be aware that there are
more platforms that I did not test.
Note that these kernel versions do not have the store_cpu_topology()
that Vincent pointed out.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/arm/kernel/smp.c | 14 7 + 7 - 0 !
1 file changed, 7 insertions(+), 7 deletions(-)
Index: b/arch/arm/kernel/smp.c
===================================================================
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -303,13 +303,6 @@ asmlinkage void __cpuinit secondary_star
platform_secondary_init(cpu);
/*
- * Enable local interrupts.
- */
- notify_cpu_starting(cpu);
- local_irq_enable();
- local_fiq_enable();
-
- /*
* Setup the percpu timer for this CPU.
*/
percpu_timer_setup();
@@ -328,6 +321,13 @@ asmlinkage void __cpuinit secondary_star
cpu_relax();
/*
+ * Enable local interrupts.
+ */
+ notify_cpu_starting(cpu);
+ local_irq_enable();
+ local_fiq_enable();
+
+ /*
* OK, it's off to the idle thread for us
*/
cpu_idle();
^ permalink raw reply
* [RFC 1/2] virtio: Add AMBA bus driver for virtio device
From: Rusty Russell @ 2011-09-14 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315906832.3297.41.camel@hornet.cambridge.arm.com>
On Tue, 13 Sep 2011 10:40:32 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> > > No problem, I've reserved 128 bits in the modified registers layout (see
> > > RFC v2), I can even change it into "offset/value" interface, which would
> > > give you variable width. One thing I don't get is how to access feature
> > > bits > 31? The get_features() seems
> > > to be limited to 32:
> > >
> > > struct virtio_config_ops {
> > > <...>
> > > u32 (*get_features)(struct virtio_device *vdev);
> > > <...>
> > > }
> >
> > There's a patch for that already :)
>
> Ok, so how about one of the following two options:
>
> 1. 4 * 32-bit words of feature flags, 128 bits in total:
>
> * 0x010 32 HostFeatures0 Features supported by the host, bits 0-31
> * 0x014 32 HostFeatures1 Features supported by the host, bits 32-63
> * 0x018 32 HostFeatures2 Features supported by the host, bits 64-95
> * 0x01c 32 HostFeatures3 Features supported by the host, bits 96-127
>
> * 0x020 32 GuestFeatures0 Features activated by the guest, bits 0-31
> * 0x024 32 GuestFeatures1 Features activated by the guest, bits 32-63
> * 0x028 32 GuestFeatures2 Features activated by the guest, bits 64-95
> * 0x02c 32 GuestFeatures3 Features activated by the guest, bits 96-127
>
> 2. "Select word -> read flags" interface:
>
> * 0x010 32 HostFeaturesFlags Features supported by the host
> * 0x014 32 HostFeaturesWord Set of features to access
>
> * 0x020 32 GuestFeaturesFlags Features activated by the guest
> * 0x024 32 GuestFeaturesWord Set of features to set
>
> In this case the algorithm would be:
>
> writel(0, HostFeaturesWord);
> bits_0_31 = readl(HostFeaturesFlags);
> writel(1, HostFeaturesWord);
> bits_32_63 = readl(HostFeaturesFlags);
> <etc>
>
> The latter seems more "future-proof" to me, if slightly more complex...
> Any other suggestions?
The former is almost certainly sufficient (remember, we can abuse the
final feature bit to indicate there are extended features somewhere
else, if we really have to). But agree the latter is preferable: this
isn't time-critical.
> > We can sort that out later... the Guest may try some ambitious large
> > allocation and fall back if it fails.
>
> So, to my mind, the negotiations could look like this (from the Guest's
> point of view):
>
> 1. (optional) The Guest is asking what size is "suggested" by the Host:
>
> size = readl(QueueNum);
>
> 2. The Guest requests size it would like to use:
>
> writel(optimal_size(size), QueueNum);
>
> 3. The Host does the best it can to accommodate the Guest and the Guest
> checks the effective size:
>
> size = real(QueueNum);
>
> Does it make some sense?
Does Host care? It is sufficient for it to publish min/max values?
You might want to throw the alignment value in there; there has been
talk about adding that to PCI, for really small rings (less than a
page).
Cheers,
Rusty.
^ permalink raw reply
* [PATCH v15 11/12] OMAP: dmtimer: extend spinlock to exported APIs
From: Tony Lindgren @ 2011-09-13 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315516098-29761-12-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110908 13:36]:
> Since the exported APIs can be called from interrupt context
> extend spinlock protection to some more relevant APIs to avoid
> race condition.
We should have locking for requesting and releasing a timer etc,
but I don't see need for that for the timer specific functions.
> @@ -317,9 +317,11 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_trigger);
> void omap_dm_timer_start(struct omap_dm_timer *timer)
> {
> u32 l;
> + unsigned long flags;
>
> omap_dm_timer_enable(timer);
>
> + spin_lock_irqsave(&dm_timer_lock, flags);
> if (timer->loses_context) {
> u32 ctx_loss_cnt_after =
> timer->get_context_loss_count(&timer->pdev->dev);
Here the caller already owns the timer being started. So there
should never be multiple users for a single timer. If there are,
then the caller should take care of locking.
> void omap_dm_timer_stop(struct omap_dm_timer *timer)
> {
> - unsigned long rate = 0;
> + unsigned long rate = 0, flags;
> struct dmtimer_platform_data *pdata = timer->pdev->dev.platform_data;
> bool is_omap2 = true;
>
> + spin_lock_irqsave(&dm_timer_lock, flags);
> if (pdata->needs_manual_reset)
> is_omap2 = false;
> else
Here too.
> @@ -389,8 +394,10 @@ void omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
> unsigned int load)
> {
> u32 l;
> + unsigned long flags;
>
> omap_dm_timer_enable(timer);
> + spin_lock_irqsave(&dm_timer_lock, flags);
> l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
> if (autoreload)
> l |= OMAP_TIMER_CTRL_AR;
And here.
> @@ -412,9 +420,11 @@ void omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
> unsigned int load)
> {
> u32 l;
> + unsigned long flags;
>
> omap_dm_timer_enable(timer);
>
> + spin_lock_irqsave(&dm_timer_lock, flags);
> if (timer->loses_context) {
> u32 ctx_loss_cnt_after =
> timer->get_context_loss_count(&timer->pdev->dev);
Not needed here either. And that's the case for all the other functions
too.
Regards,
Tony
^ permalink raw reply
* [patch] ARM: smpboot: Enable interrupts after marking CPU online/active
From: Russell King - ARM Linux @ 2011-09-13 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1109132247490.2723@ionos>
On Tue, Sep 13, 2011 at 10:48:48PM +0200, Thomas Gleixner wrote:
> The question is whether you really need to calibrate the delay for
> each core or if you simply can take the calibration of the first
> core. That would avoid enabling interrupts all the way.
That depends whether you require all cores in a SMP system to be built
the same way or not (and therefore to have the same performance.) I'm
aware of at least one implementation where that isn't the case, and I
see no reason why that would not become more common.
In that case, we need the individual core delay calibration, and lock
delays to either cores or specific groups of cores, or use hardware
timers (if available, and with enough precision) for them.
^ permalink raw reply
* [PATCH v2 5/6] iommu/intel: announce supported page sizes
From: David Woodhouse @ 2011-09-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315942288-17297-5-git-send-email-ohad@wizery.com>
On Tue, 2011-09-13 at 22:31 +0300, Ohad Ben-Cohen wrote:
> + * Traditionally the IOMMU core just handed us the mappings directly,
> + * after making sure the size is an order of a 4KB page and that the
> + * mapping has natural alignment.
> + *
> + * To retain this behavior, we currently advertise that we support
> + * all page sizes that are an order of 4KB.
This is wrong. We do not support 4000-byte pages. We only support
4096-byte pages. 4KiB, not 4kB.
Please fix.
--
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110913/9925b4a6/attachment.bin>
^ permalink raw reply
* [PATCH 6/6] OMAP2+: id: remove OMAP_REVBITS_* macros
From: Paul Walmsley @ 2011-09-13 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913212638.26161.62284.stgit@dusk>
The OMAP_REVBITS_* macros are just used as otherwise meaningless
aliases for the numbers zero through five, so remove these macros.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/plat-omap/include/plat/cpu.h | 33 ++++++++++-----------------------
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 566975c..0ec90cf 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -60,19 +60,6 @@ struct omap_chip_id {
unsigned int omap_rev(void);
/*
- * Define CPU revision bits
- *
- * Verbose meaning of the revision bits may be different for a silicon
- * family. This difference can be handled separately.
- */
-#define OMAP_REVBITS_00 0x00
-#define OMAP_REVBITS_01 0x01
-#define OMAP_REVBITS_02 0x02
-#define OMAP_REVBITS_03 0x03
-#define OMAP_REVBITS_04 0x04
-#define OMAP_REVBITS_05 0x05
-
-/*
* Get the CPU revision for OMAP devices
*/
#define GET_OMAP_REVISION() ((omap_rev() >> 8) & 0xff)
@@ -379,31 +366,31 @@ IS_OMAP_TYPE(3517, 0x3517)
/* Various silicon revisions for omap2 */
#define OMAP242X_CLASS 0x24200024
#define OMAP2420_REV_ES1_0 OMAP242X_CLASS
-#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (OMAP_REVBITS_01 << 8))
+#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (0x1 << 8))
#define OMAP243X_CLASS 0x24300024
#define OMAP2430_REV_ES1_0 OMAP243X_CLASS
#define OMAP343X_CLASS 0x34300034
#define OMAP3430_REV_ES1_0 OMAP343X_CLASS
-#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (OMAP_REVBITS_01 << 8))
-#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (OMAP_REVBITS_02 << 8))
-#define OMAP3430_REV_ES3_0 (OMAP343X_CLASS | (OMAP_REVBITS_03 << 8))
-#define OMAP3430_REV_ES3_1 (OMAP343X_CLASS | (OMAP_REVBITS_04 << 8))
-#define OMAP3430_REV_ES3_1_2 (OMAP343X_CLASS | (OMAP_REVBITS_05 << 8))
+#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (0x1 << 8))
+#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (0x2 << 8))
+#define OMAP3430_REV_ES3_0 (OMAP343X_CLASS | (0x3 << 8))
+#define OMAP3430_REV_ES3_1 (OMAP343X_CLASS | (0x4 << 8))
+#define OMAP3430_REV_ES3_1_2 (OMAP343X_CLASS | (0x5 << 8))
#define OMAP363X_CLASS 0x36300034
#define OMAP3630_REV_ES1_0 OMAP363X_CLASS
-#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (OMAP_REVBITS_01 << 8))
-#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
+#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (0x1 << 8))
+#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (0x2 << 8))
#define OMAP3517_CLASS 0x35170000
#define OMAP3517_REV_ES1_0 OMAP3517_CLASS
-#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (OMAP_REVBITS_01 << 8))
+#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (0x1 << 8))
#define TI816X_CLASS 0x81600034
#define TI8168_REV_ES1_0 TI816X_CLASS
-#define TI8168_REV_ES1_1 (TI816X_CLASS | (OMAP_REVBITS_01 << 8))
+#define TI8168_REV_ES1_1 (TI816X_CLASS | (0x1 << 8))
#define OMAP443X_CLASS 0x44300044
#define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8))
^ permalink raw reply related
* [PATCH 5/6] OMAP3: id: remove duplicate code for testing SoC ES level
From: Paul Walmsley @ 2011-09-13 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913212638.26161.62284.stgit@dusk>
omap3_cpuinfo() contains essentially duplicated code from
omap3_check_revision(), just for the purpose of determining the chip ES level.
Set the cpu_rev char array pointer in omap3_check_revision() instead,
and drop the now-useless code from omap3_cpuinfo().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/id.c | 80 +++++++++++++---------------------------------
1 files changed, 23 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 18c3797..307e186 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -242,7 +242,7 @@ static void __init ti816x_check_features(void)
omap_features = OMAP3_HAS_NEON;
}
-static void __init omap3_check_revision(void)
+static void __init omap3_check_revision(const char **cpu_rev)
{
u32 cpuid, idcode;
u16 hawkeye;
@@ -259,6 +259,7 @@ static void __init omap3_check_revision(void)
if ((((cpuid >> 4) & 0xfff) == 0xc08) && ((cpuid & 0xf) == 0x0)) {
omap_revision = OMAP3430_REV_ES1_0;
omap_chip.oc |= CHIP_IS_OMAP3430ES1;
+ *cpu_rev = "1.0";
return;
}
@@ -280,18 +281,22 @@ static void __init omap3_check_revision(void)
case 1:
omap_revision = OMAP3430_REV_ES2_0;
omap_chip.oc |= CHIP_IS_OMAP3430ES2;
+ *cpu_rev = "2.0";
break;
case 2:
omap_revision = OMAP3430_REV_ES2_1;
omap_chip.oc |= CHIP_IS_OMAP3430ES2;
+ *cpu_rev = "2.1";
break;
case 3:
omap_revision = OMAP3430_REV_ES3_0;
omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
+ *cpu_rev = "3.0";
break;
case 4:
omap_revision = OMAP3430_REV_ES3_1;
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ *cpu_rev = "3.1";
break;
case 7:
/* FALLTHROUGH */
@@ -301,6 +306,7 @@ static void __init omap3_check_revision(void)
/* REVISIT: Add CHIP_IS_OMAP3430ES3_1_2? */
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ *cpu_rev = "3.1.2";
}
break;
case 0xb868:
@@ -315,11 +321,13 @@ static void __init omap3_check_revision(void)
switch (rev) {
case 0:
omap_revision = OMAP3517_REV_ES1_0;
+ *cpu_rev = "1.0";
break;
case 1:
/* FALLTHROUGH */
default:
omap_revision = OMAP3517_REV_ES1_1;
+ *cpu_rev = "1.1";
}
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
@@ -330,16 +338,19 @@ static void __init omap3_check_revision(void)
switch(rev) {
case 0: /* Take care of early samples */
omap_revision = OMAP3630_REV_ES1_0;
+ *cpu_rev = "1.0";
break;
case 1:
omap_revision = OMAP3630_REV_ES1_1;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
+ *cpu_rev = "1.1";
break;
case 2:
/* FALLTHROUGH */
default:
omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
+ *cpu_rev = "1.2";
}
break;
case 0xb81e:
@@ -348,17 +359,21 @@ static void __init omap3_check_revision(void)
switch (rev) {
case 0:
omap_revision = TI8168_REV_ES1_0;
+ *cpu_rev = "1.0";
break;
case 1:
/* FALLTHROUGH */
default:
omap_revision = TI8168_REV_ES1_1;
+ *cpu_rev = "1.1";
+ break;
}
break;
default:
/* Unknown default to latest silicon rev as default */
- omap_revision = OMAP3630_REV_ES1_2;
+ omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
+ *cpu_rev = "1.2";
pr_warn("Warning: unknown chip type; assuming OMAP3630ES1.2\n");
}
}
@@ -435,10 +450,9 @@ static void __init omap4_check_revision(void)
if (omap3_has_ ##feat()) \
printk(#feat" ");
-static void __init omap3_cpuinfo(void)
+static void __init omap3_cpuinfo(const char *cpu_rev)
{
- u8 rev = GET_OMAP_REVISION();
- const char *cpu_name, *cpu_rev;
+ const char *cpu_name;
/*
* OMAP3430 and OMAP3530 are assumed to be same.
@@ -465,56 +479,6 @@ static void __init omap3_cpuinfo(void)
cpu_name = "OMAP3503";
}
- if (cpu_is_omap3630() || cpu_is_ti816x()) {
- switch (rev) {
- case OMAP_REVBITS_00:
- cpu_rev = "1.0";
- break;
- case OMAP_REVBITS_01:
- cpu_rev = "1.1";
- break;
- case OMAP_REVBITS_02:
- /* FALLTHROUGH */
- default:
- /* Use the latest known revision as default */
- cpu_rev = "1.2";
- }
- } else if (cpu_is_omap3505() || cpu_is_omap3517()) {
- switch (rev) {
- case OMAP_REVBITS_00:
- cpu_rev = "1.0";
- break;
- case OMAP_REVBITS_01:
- /* FALLTHROUGH */
- default:
- /* Use the latest known revision as default */
- cpu_rev = "1.1";
- }
- } else {
- switch (rev) {
- case OMAP_REVBITS_00:
- cpu_rev = "1.0";
- break;
- case OMAP_REVBITS_01:
- cpu_rev = "2.0";
- break;
- case OMAP_REVBITS_02:
- cpu_rev = "2.1";
- break;
- case OMAP_REVBITS_03:
- cpu_rev = "3.0";
- break;
- case OMAP_REVBITS_04:
- cpu_rev = "3.1";
- break;
- case OMAP_REVBITS_05:
- /* FALLTHROUGH */
- default:
- /* Use the latest known revision as default */
- cpu_rev = "3.1.2";
- }
- }
-
/* Print verbose information */
pr_info("%s ES%s (", cpu_name, cpu_rev);
@@ -533,6 +497,8 @@ static void __init omap3_cpuinfo(void)
*/
void __init omap2_check_revision(void)
{
+ const char *cpu_rev;
+
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
@@ -540,7 +506,7 @@ void __init omap2_check_revision(void)
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
- omap3_check_revision();
+ omap3_check_revision(&cpu_rev);
/* TI816X doesn't have feature register */
if (!cpu_is_ti816x())
@@ -548,7 +514,7 @@ void __init omap2_check_revision(void)
else
ti816x_check_features();
- omap3_cpuinfo();
+ omap3_cpuinfo(cpu_rev);
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
^ permalink raw reply related
* [PATCH 4/6] OMAP3: id: add fallthrough warning; fix some CodingStyle issues
From: Paul Walmsley @ 2011-09-13 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913212638.26161.62284.stgit@dusk>
Emit a warning to the console in omap3_check_revision() if that code
cannot determine what type of SoC the system is currently running on.
Remove some extra whitespace, remove some duplicate code, and
add an appropriate comment to a fallthrough case.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
---
arch/arm/mach-omap2/id.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 6810c52..18c3797 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -336,8 +336,9 @@ static void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
break;
case 2:
+ /* FALLTHROUGH */
default:
- omap_revision = OMAP3630_REV_ES1_2;
+ omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
}
break;
@@ -349,16 +350,16 @@ static void __init omap3_check_revision(void)
omap_revision = TI8168_REV_ES1_0;
break;
case 1:
- omap_revision = TI8168_REV_ES1_1;
- break;
+ /* FALLTHROUGH */
default:
- omap_revision = TI8168_REV_ES1_1;
+ omap_revision = TI8168_REV_ES1_1;
}
break;
default:
- /* Unknown default to latest silicon rev as default*/
+ /* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
+ pr_warn("Warning: unknown chip type; assuming OMAP3630ES1.2\n");
}
}
^ permalink raw reply related
* [PATCH 3/6] OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levels
From: Paul Walmsley @ 2011-09-13 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913212638.26161.62284.stgit@dusk>
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
of the OMAP2+ SoCs do in mach-omap2/cpu.c.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
---
arch/arm/mach-omap2/id.c | 10 +++++++++-
arch/arm/plat-omap/include/plat/cpu.h | 3 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 46bc2f9..6810c52 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -312,7 +312,15 @@ static void __init omap3_check_revision(void)
*
* REVISIT: AM3505/AM3517 should have their own CHIP_IS
*/
- omap_revision = OMAP3517_REV(rev);
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3517_REV_ES1_0;
+ break;
+ case 1:
+ /* FALLTHROUGH */
+ default:
+ omap_revision = OMAP3517_REV_ES1_1;
+ }
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index b6bd8f7..566975c 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -398,7 +398,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
#define OMAP3517_CLASS 0x35170000
-#define OMAP3517_REV(v) (OMAP3517_CLASS | (v << 8))
+#define OMAP3517_REV_ES1_0 OMAP3517_CLASS
+#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (OMAP_REVBITS_01 << 8))
#define TI816X_CLASS 0x81600034
#define TI8168_REV_ES1_0 TI816X_CLASS
^ permalink raw reply related
* [PATCH 2/6] OMAP3: id: remove useless strcpy()s
From: Paul Walmsley @ 2011-09-13 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110913212638.26161.62284.stgit@dusk>
omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
---
arch/arm/mach-omap2/id.c | 48 +++++++++++++++++++++-------------------------
1 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 723e2f8..46bc2f9 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -429,84 +429,80 @@ static void __init omap4_check_revision(void)
static void __init omap3_cpuinfo(void)
{
u8 rev = GET_OMAP_REVISION();
- char cpu_name[16], cpu_rev[16];
+ const char *cpu_name, *cpu_rev;
- /* OMAP3430 and OMAP3530 are assumed to be same.
+ /*
+ * OMAP3430 and OMAP3530 are assumed to be same.
*
* OMAP3525, OMAP3515 and OMAP3503 can be detected only based
* on available features. Upon detection, update the CPU id
* and CPU class bits.
*/
if (cpu_is_omap3630()) {
- strcpy(cpu_name, "OMAP3630");
+ cpu_name = "OMAP3630";
} else if (cpu_is_omap3505()) {
- /*
- * AM35xx devices
- */
- if (omap3_has_sgx())
- strcpy(cpu_name, "AM3517");
- else
- strcpy(cpu_name, "AM3505");
+ /* AM35xx devices */
+ cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
- strcpy(cpu_name, "TI816X");
+ cpu_name = "TI816X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
- strcpy(cpu_name, "OMAP3430/3530");
+ cpu_name = "OMAP3430/3530";
} else if (omap3_has_iva()) {
- strcpy(cpu_name, "OMAP3525");
+ cpu_name = "OMAP3525";
} else if (omap3_has_sgx()) {
- strcpy(cpu_name, "OMAP3515");
+ cpu_name = "OMAP3515";
} else {
- strcpy(cpu_name, "OMAP3503");
+ cpu_name = "OMAP3503";
}
if (cpu_is_omap3630() || cpu_is_ti816x()) {
switch (rev) {
case OMAP_REVBITS_00:
- strcpy(cpu_rev, "1.0");
+ cpu_rev = "1.0";
break;
case OMAP_REVBITS_01:
- strcpy(cpu_rev, "1.1");
+ cpu_rev = "1.1";
break;
case OMAP_REVBITS_02:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- strcpy(cpu_rev, "1.2");
+ cpu_rev = "1.2";
}
} else if (cpu_is_omap3505() || cpu_is_omap3517()) {
switch (rev) {
case OMAP_REVBITS_00:
- strcpy(cpu_rev, "1.0");
+ cpu_rev = "1.0";
break;
case OMAP_REVBITS_01:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- strcpy(cpu_rev, "1.1");
+ cpu_rev = "1.1";
}
} else {
switch (rev) {
case OMAP_REVBITS_00:
- strcpy(cpu_rev, "1.0");
+ cpu_rev = "1.0";
break;
case OMAP_REVBITS_01:
- strcpy(cpu_rev, "2.0");
+ cpu_rev = "2.0";
break;
case OMAP_REVBITS_02:
- strcpy(cpu_rev, "2.1");
+ cpu_rev = "2.1";
break;
case OMAP_REVBITS_03:
- strcpy(cpu_rev, "3.0");
+ cpu_rev = "3.0";
break;
case OMAP_REVBITS_04:
- strcpy(cpu_rev, "3.1");
+ cpu_rev = "3.1";
break;
case OMAP_REVBITS_05:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- strcpy(cpu_rev, "3.1.2");
+ cpu_rev = "3.1.2";
}
}
^ permalink raw reply related
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