* [PATCH v3 2/2] i2c: change id to let i2c-at91 work
From: Bo Shen @ 2012-10-16 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016083954.GB12801@game.jcrosoft.org>
Hi J,
On 10/16/2012 16:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:13 Tue 16 Oct , Bo Shen wrote:
>> Hi J,
>>
>> On 10/15/2012 23:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 17:30 Mon 15 Oct , Bo Shen wrote:
>>>> The i2c core driver will turn the platform device ID to busnum
>>>> When using platfrom device ID as -1, it means dynamically assigned
>>>> the busnum. When writing code, we need to make sure the busnum,
>>>> and call i2c_register_board_info(int busnum, ...) to register device
>>>> if using -1, we do not know the value of busnum
>>>>
>>>> In order to solve this issue, set the platform device ID as a fix number
>>>> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>>>>
>>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>>> ---
>>>
>>> can you check when this append for the first time to schedule a patch for stable too
>>
>> OK. I will resend it and add linux stable into the cc list.
> no this not how it work
>
> I ask you to check which patch add the regression and then when this is
> applied in the kernel we will request greg to apply it too to the stable
The code is using id = -1 appear 4 years ago. And after dig, I don't
find which patch cause this the regression.
Sorry for that.
> But before do that you MUST foudn the commit responsible
>
> Best Regards,
> J.
>
^ permalink raw reply
* [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
From: Felipe Balbi @ 2012-10-16 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350344998-16328-1-git-send-email-khilman@deeprootsystems.com>
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> The runtime PM framework assumes that the hardware state of devices
> when initialized is disabled. For all omap_devices, we idle/disable
> device by default. However, the console uart uses a "no idle" option
> during omap_device init in order to allow earlyprintk usage to work
> seamlessly during boot.
>
> Because the hardware is left partially enabled after init (whatever
> the bootloader settings were), the omap_device should later be fully
> initialized (including mux) and the runtime PM framework should be
> told that the device is active, and not disabled so that the hardware
> state is in sync with runtime PM state.
>
> To fix, after the device has been created/registered, call
> omap_device_enable() to finialize init and use pm_runtime_set_active()
> to tell the runtime PM core the device is enabled.
>
> Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
> 3730/Beagle-xM, 4460/PandaES.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Sourav Poddar <sourav.poddar@ti.com>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies against v3.7-rc1.
> Fix targetted for v3.7.
>
> I'm still not entirely sure why this has worked up to now on OMAP3/4
> but not on OMAP2. Even so, this fix is needed for all platforms to
> ensure matching hardware state and runtime PM state.
>
> arch/arm/mach-omap2/serial.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 0405c81..37b5dbe 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
> if ((console_uart_id == bdata->id) && no_console_suspend)
> omap_device_disable_idle_on_suspend(pdev);
>
> + if (console_uart_id == bdata->id) {
> + omap_device_enable(pdev);
> + pm_runtime_set_active(&pdev->dev);
> + }
> +
> oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
>
> oh->dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Reviewed-by: Felipe Balbi <balbi@ti.com>
sorry for the issues caused.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/7f249c3b/attachment.sig>
^ permalink raw reply
* [PATCH 00/11] Minimum set of omap serial patches to fix merge window breakage
From: Russell King - ARM Linux @ 2012-10-16 10:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
During the merge window, a series of patches from various people went in,
allegedly fixing various problems with the OMAP serial driver.
Unfortunately, there was not a full understanding of the issues I brought
up here back in April, and so the "fixes", while being individually
correct, result in a worse situation with the driver than before.
Specifically, this patch:
commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
Author: Vikram Pandita <vikram.pandita@ti.com>
Date: Thu Sep 6 15:45:37 2012 +0300
serial: omap: fix software flow control
Software flow control register bits were not defined correctly.
Also clarify the IXON and IXOFF logic to reflect what userspace wants.
does what it says on the tin - it fixes the register definitions so that
we do end up enabling the right two software flow control bits.
The down side is that there are other bugs in this area which have been
exposed. For example:
1. the XON/XOFF registers aren't written to; their address is, but we will
not be writing to the right registers because their access rules are not
respected by the driver. These are by default zero.
This means that with hardware assisted software flow control enabled,
the port will now transmit an 0x00 byte for XON and XOFF events.
2. the driver set_termios function is not called for changes in software
flow control settings if not accompanied by some other change.
3. the there isn't actually a way for the hardware assisted flow control
to be used other than by increasing interrupt latency to cause the
receiver hardware FIFO to fill. This will cause 0x00 bytes to be
transmitted.
There are two options to resolve this. The first one is to revert this
patch to bring the driver back down to the pre-merge window state. The
other is to apply this series of patches, which frankly I don't think
is -rc material, even with the above regressions.
Given that the above regressions were caused by a lack of due care and
correct process (I had declared to TI that I had investigated these
issues back in April), I believe that the right answer is to revert at
least commit 957ee7270d, which should re-hide these other bugs in the
driver.
^ permalink raw reply
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Inki Dae @ 2012-10-16 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016090434.7d5e088152a3e0b0606903c8@nvidia.com>
Hi Hiroshi,
2012/10/16 Hiroshi Doyu <hdoyu@nvidia.com>:
> Hi Inki/Marek,
>
> On Tue, 16 Oct 2012 02:50:16 +0200
> Inki Dae <inki.dae@samsung.com> wrote:
>
>> 2012/10/15 Marek Szyprowski <m.szyprowski@samsung.com>:
>> > Hello,
>> >
>> > Some devices, which have IOMMU, for some use cases might require to
>> > allocate a buffers for DMA which is contiguous in physical memory. Such
>> > use cases appears for example in DRM subsystem when one wants to improve
>> > performance or use secure buffer protection.
>> >
>> > I would like to ask if adding a new attribute, as proposed in this RFC
>> > is a good idea? I feel that it might be an attribute just for a single
>> > driver, but I would like to know your opinion. Should we look for other
>> > solution?
>> >
>>
>> In addition, currently we have worked dma-mapping-based iommu support
>> for exynos drm driver with this patch set so this patch set has been
>> tested with iommu enabled exynos drm driver and worked fine. actually,
>> this feature is needed for secure mode such as TrustZone. in case of
>> Exynos SoC, memory region for secure mode should be physically
>> contiguous and also maybe OMAP but now dma-mapping framework doesn't
>> guarantee physically continuous memory allocation so this patch set
>> would make it possible.
>
> Agree that the contigous memory allocation is necessary for us too.
>
> In addition to those contiguous/discontiguous page allocation, is
> there any way to _import_ anonymous pages allocated by a process to be
> used in dma-mapping API later?
>
> I'm considering the following scenario, an user process allocates a
> buffer by malloc() in advance, and then it asks some driver to convert
> that buffer into IOMMU'able/DMA'able ones later. In this case, pages
> are discouguous and even they may not be yet allocated at
> malloc()/mmap().
>
I'm not sure I understand what you mean but we had already tried this
way and for this, you can refer to below link,
http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg22555.html
but this way had been pointed out by drm guys because the pages could
be used through gem object after that pages had been freed by free()
anyway their pointing was reasonable and I'm trying another way, this
is the way that the pages to user space has same life time with dma
operation. in other word, if dma completed access to that pages then
also that pages will be freed. actually drm-based via driver of
mainline kernel is using same way
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply
* [PATCH 2/2] ARM: unwind: enable dumping stacks for SMP && ARM_UNWIND
From: Dave Martin @ 2012-10-16 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRRpYrOBhaFn5PV5f5J=36Hsj2eZixyD1hXRfRLoyWm1Xg@mail.gmail.com>
On Mon, Oct 15, 2012 at 07:15:31PM -0700, Colin Cross wrote:
> On Fri, Oct 12, 2012 at 3:02 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > On Fri, Oct 12, 2012 at 10:08:07AM +0100, Russell King - ARM Linux wrote:
> >> On Sun, Aug 26, 2012 at 03:46:56PM -0700, Colin Cross wrote:
> >> > Unwinding with CONFIG_ARM_UNWIND is much more complicated than
> >> > unwinding with CONFIG_FRAME_POINTER, but there are only a few points
> >> > that require validation in order to avoid faults or infinite loops.
> >> > Avoiding faults is easy by adding checks to verify that all accesses
> >> > relative to the frame's stack pointer remain inside the stack.
> >> >
> >> > When CONFIG_FRAME_POINTER is not set it is possible for two frames to
> >> > have the same SP, so there is no way to avoid repeated calls to
> >> > unwind_frame continuing forever.
> >>
> >> So here you admit that this patch can cause the unwinder to loop forever,
> >> which would provide no way out of that. Why do you think this patch is
> >> suitable for mainline with such a problem?
> >
> > With CONFIG_FRAME_POINTER we have a straightforward definition of
> > progress: the sp must increase per frame, and cannot increase beyond the
> > limit of the tasks stack. We get this property from the fact that
> > each frame record consumes actual space on the stack. If we parse a
> > frame record which does not both increase the sp and provide a frame
> > address greater than that sp, we know that frame is garbage and we must
> > stop.
> >
> >
> > With CONFIG_ARM_UNWIND, we have no straightforward definition of
> > progress. However, sp must _normally_ still increase, because compiler-
> > generated non-leaf functions must store the lr somewhere, and the
> > compiler always uses the stack. Even if lr is stashed in r4, an ABI
> > compliant would then have needed to save r4 on the stack beforehand.
> >
> > We can assume that we will never parse a garbage unwind table because of
> > the way the table lookup works (though we may parse a valid table which
> > has nothing whatever to do with the code that was executing in the case
> > of a corrupted stack). So we only need to worry about what the unwind
> > tables will look like for valid functions.
> >
> > Nonetheless, tail-call-optimised and manually-annotated functions may
> > have unusual frames which don't consume any stack. Stackless tail-
> > call-optimised functions shouldn't be a problem, since their frames
> > are completely missing from the backtrace and won't dump us into a loop.
> > Stackless assembler functions are overwhelmingly likely to be leaf
> > functions, giving us just one stackless frame.
> >
> >
> > Would it make sense if we place some small sanity limit on the number
> > of frames the unwinder will process with the same sp before giving up?
>
> About half the callers to unwind_frame end up limiting the number of
> frames they will follow before giving up, so I wasn't sure if I should
> put an arbitrary limit in unwind_frame or just make sure all callers
> are bounded. Your idea of limiting same sp frames instead of total
> frames sounds better. I can send a new patch that adds a new field to
> struct stackframe (which will need to be initialized everywhere, the
> struct is usually on the stack) and limits the recursion. Any
> suggestion on the recursion limit? I would never expect to see a real
> situation with more than a few, but on the other hand parsing the
> frames should be pretty fast so a high number (100?) shouldn't cause
> any user visible effect.
Talking to some tools guys about this, it sounds like there really
shouldn't be any stackless frame except for the leaf frame. If there are
stackless functions they will probably not be visible in the frame chain
at all. So it might make sense to have a pretty small limit. Maybe it
could even be 1. Cartainly a small number.
We should also add a check for whether the current and frame and previous
frame appear identical and abort if that's the case, if we don't do that
already.
Cheers
---Dave
^ permalink raw reply
* [PATCH 2/2] ARM: tegra: add tegra_timer clock
From: Sivaram Nair @ 2012-10-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350382116-18024-1-git-send-email-sivaramn@nvidia.com>
From: Sivaram Nair <sivaramn@nvidia.com>
This undoes commit 20f4665831cec65d6e5d33587bba28ffa536b91d by bringing
back the tegra_timer clock. tegra_timer is indeed a clock (hidden by
the PERIPH_CLK macro) which should be added to the tegra_list_clks.
The above commit caused tegra_init_timer() failing to get the clk
reference.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
---
arch/arm/mach-tegra/tegra20_clocks_data.c | 1 +
arch/arm/mach-tegra/tegra30_clocks_data.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/tegra20_clocks_data.c b/arch/arm/mach-tegra/tegra20_clocks_data.c
index cc9b5fd..8d398a3 100644
--- a/arch/arm/mach-tegra/tegra20_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra20_clocks_data.c
@@ -953,6 +953,7 @@ PERIPH_CLK(pcie_xclk, NULL, "pcie_xclk", 74, 0, 26000000, mux_clk_m,
static struct clk *tegra_list_clks[] = {
&tegra_apbdma,
&tegra_rtc,
+ &tegra_timer,
&tegra_i2s1,
&tegra_i2s2,
&tegra_spdif_out,
diff --git a/arch/arm/mach-tegra/tegra30_clocks_data.c b/arch/arm/mach-tegra/tegra30_clocks_data.c
index d92cb55..3d2e553 100644
--- a/arch/arm/mach-tegra/tegra30_clocks_data.c
+++ b/arch/arm/mach-tegra/tegra30_clocks_data.c
@@ -1143,6 +1143,7 @@ struct clk *tegra_list_clks[] = {
&tegra_apbdma,
&tegra_rtc,
&tegra_kbc,
+ &tegra_timer,
&tegra_kfuse,
&tegra_fuse,
&tegra_fuse_burn,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] ARM: tegra: rename tegra system timer
From: Sivaram Nair @ 2012-10-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350382116-18024-1-git-send-email-sivaramn@nvidia.com>
From: Sivaram Nair <sivaramn@nvidia.com>
The timer variable is renamed to avoid confusion and symbol name clash
with the tegra_timer clock.
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
---
arch/arm/mach-tegra/board-dt-tegra20.c | 2 +-
arch/arm/mach-tegra/board-dt-tegra30.c | 2 +-
arch/arm/mach-tegra/board.h | 2 +-
arch/arm/mach-tegra/timer.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c b/arch/arm/mach-tegra/board-dt-tegra20.c
index 57e235f..aa5325c 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -182,7 +182,7 @@ DT_MACHINE_START(TEGRA_DT, "nVidia Tegra20 (Flattened Device Tree)")
.init_early = tegra20_init_early,
.init_irq = tegra_dt_init_irq,
.handle_irq = gic_handle_irq,
- .timer = &tegra_timer,
+ .timer = &tegra_sys_timer,
.init_machine = tegra_dt_init,
.init_late = tegra_dt_init_late,
.restart = tegra_assert_system_reset,
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c b/arch/arm/mach-tegra/board-dt-tegra30.c
index e4a676d..5e92a81 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -89,7 +89,7 @@ DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30 (Flattened Device Tree)")
.init_early = tegra30_init_early,
.init_irq = tegra_dt_init_irq,
.handle_irq = gic_handle_irq,
- .timer = &tegra_timer,
+ .timer = &tegra_sys_timer,
.init_machine = tegra30_dt_init,
.init_late = tegra_init_late,
.restart = tegra_assert_system_reset,
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index f88e514..91fbe73 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -55,5 +55,5 @@ static inline int harmony_pcie_init(void) { return 0; }
void __init tegra_paz00_wifikill_init(void);
-extern struct sys_timer tegra_timer;
+extern struct sys_timer tegra_sys_timer;
#endif
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index eccdce9..d3b8c8e 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -245,7 +245,7 @@ static void __init tegra_init_timer(void)
register_persistent_clock(NULL, tegra_read_persistent_clock);
}
-struct sys_timer tegra_timer = {
+struct sys_timer tegra_sys_timer = {
.init = tegra_init_timer,
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/2] ARM: tegra: bring back tegra_timer clock
From: Sivaram Nair @ 2012-10-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
This patchset fixes a bug introduced by commit
20f4665831cec65d6e5d33587bba28ffa536b91d by bringing back the
tegra_timer clock. The above commit caused tegra_init_timer() failing
to get the clk reference.
The first patch renames the existing tegra_timer object to
tegra_sys_timer and the second patch adds previously-removed tegra_timer
clock object.
Sivaram Nair (2):
ARM: tegra: rename tegra system timer
ARM: tegra: add tegra_timer clock
arch/arm/mach-tegra/board-dt-tegra20.c | 2 +-
arch/arm/mach-tegra/board-dt-tegra30.c | 2 +-
arch/arm/mach-tegra/board.h | 2 +-
arch/arm/mach-tegra/tegra20_clocks_data.c | 1 +
arch/arm/mach-tegra/tegra30_clocks_data.c | 1 +
arch/arm/mach-tegra/timer.c | 2 +-
6 files changed, 6 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Linus Walleij @ 2012-10-16 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350371685.5769.45.camel@sauron.fi.intel.com>
On Tue, Oct 16, 2012 at 9:14 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Mon, 2012-10-15 at 21:51 +0200, Linus Walleij wrote:
>> On Mon, Oct 15, 2012 at 6:27 PM, Brian Norris
>> <computersforpeace@gmail.com> wrote:
>>
>> > I would prefer not building a solution that hopes kmalloc() can get a
>> > large contiguous buffer (remember, eraseblock sizes come as large as
>> > 2MB these days). A real solution like CMA or scatter-gather seems like
>> > a better idea.
>>
>> +1 on that, and as I think I illustrated the MMC subsystem is using
>> the block layer helpers to form scatter-gather lists for it's requests.
>> I don't see why the MTD subsystem need to be very different?
>
> This is good idea, the problem is that it is a bit more work than
> hacking the driver, so most people prefer the latter. By removing all
> kmalloc()'s I basically wish to force people to go this way.
>
> What are the SC functions names you refer?
I'm mainly thinking of blk_rq_map_sg()
from block/blk-merge.c
Yours,
Linus Walleij
^ permalink raw reply
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Catalin Marinas @ 2012-10-16 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016085928.GV21164@n2100.arm.linux.org.uk>
On 16 October 2012 09:59, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Oct 16, 2012 at 09:04:34AM +0300, Hiroshi Doyu wrote:
>> In addition to those contiguous/discontiguous page allocation, is
>> there any way to _import_ anonymous pages allocated by a process to be
>> used in dma-mapping API later?
>>
>> I'm considering the following scenario, an user process allocates a
>> buffer by malloc() in advance, and then it asks some driver to convert
>> that buffer into IOMMU'able/DMA'able ones later. In this case, pages
>> are discouguous and even they may not be yet allocated at
>> malloc()/mmap().
>
> That situation is covered. It's the streaming API you're wanting for that.
> dma_map_sg() - but you may need additional cache handling via
> flush_dcache_page() to ensure that your code is safe for all CPU cache
> architectures.
For user-allocated pages you first need get_user_pages() to make sure
they are in memory (and will stay there). This function also calls
flush_dcache_page(). Then you can build the sg list for dma_map_sg().
--
Catalin
^ permalink raw reply
* [PATCH 6/6] ARM: EXYNOS5: SATA PHY controller driver
From: Tomasz Figa @ 2012-10-16 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK1UHiw8+ebzGyjV53Y9efpMFPbCL9RR_o9ZSw=NTuRw_9gRwg@mail.gmail.com>
Hi Vasanth,
On Tuesday 16 of October 2012 12:03:47 Vasanth Ananthan wrote:
> Hi Tomasz,
>
> On Sat, Oct 13, 2012 at 4:20 AM, Tomasz Figa <tomasz.figa@gmail.com>
wrote:
> > Hi,
> >
> > On Tuesday 09 of October 2012 17:18:52 Vasanth Ananthan wrote:
> >> This patch adds a platform driver and I2C client driver for SATA PHY
> >> controller
> >>
> >> Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
> >> ---
> >>
> >> drivers/ata/Makefile | 2 +-
> >> drivers/ata/sata_exynos_phy.c | 303
> >>
> >> +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 304
> >> insertions(+), 1 deletions(-)
> >>
> >> create mode 100644 drivers/ata/sata_exynos_phy.c
>
> [ ... ]
>
> >> +
> >> + phy->init = sataphy_init;
> >> + phy->shutdown = sataphy_shutdown;
> >> + phy->priv_data = (void *)sataphy;
> >> + phy->dev = &pdev->dev;
> >> +
> >> + ret = sata_add_phy(phy, SATA_PHY_GENERATION3);
> >> + if (ret < 0)
> >> + goto err4;
> >
> > Do you have any warranties that phy callbacks won't get called before
> > i2c device probes and sets i2c_client?
> >
> >> +
> >> + ret = i2c_add_driver(&sataphy_i2c_driver);
> >> + if (ret < 0)
> >> + goto err5;
> >> +
> >> + platform_set_drvdata(pdev, phy);
>
> I shall register my i2c client driver before assigning the SATA PHY
> call backs. Would that guarantee the calling of phy callbacks after
> the i2c device probes?
No. You might still not have the sata phy i2c controller registered at
that time and so the i2c driver will not be probed.
The only definitive solution for this would be to register both platform
and i2c drivers in module init (instead of using module_platform_driver)
and defer the probe of platform driver until i2c device gets registered.
You can defer the probe by returning -EPROBE_DEFER after checking that
i2c_client is still NULL.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/36672b49/attachment-0001.html>
^ permalink raw reply
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Simon Guinot @ 2012-10-16 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015195809.GJ20922@titan.lakedaemon.net>
On Mon, Oct 15, 2012 at 03:58:09PM -0400, Jason Cooper wrote:
> On Mon, Oct 15, 2012 at 09:12:22PM +0200, Simon Guinot wrote:
> > On Mon, Oct 15, 2012 at 01:41:44PM -0400, Jason Cooper wrote:
> > > On Mon, Oct 15, 2012 at 05:34:52PM +0200, Simon Guinot wrote:
> > > > Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
> > > > ---
> > > > .../devicetree/bindings/gpio/leds-ns2.txt | 26 ++++++
> > > > drivers/leds/leds-ns2.c | 84 +++++++++++++++++++-
> > > > 2 files changed, 107 insertions(+), 3 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> > > > new file mode 100644
> > > > index 0000000..1a84969
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
> > > > @@ -0,0 +1,26 @@
> > > > +Binding for dual-GPIO LED found on Network Space v2 (and parents).
> > > > +
> > > > +Required properties:
> > > > +- compatible: "ns2-leds".
> > > > +
> > > > +Each LED is represented as a sub-node of the ns2-leds device.
> > > > +
> > > > +Required sub-node properties:
> > > > +- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
> > > > +- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
> > > > +
> > > > +Optional sub-node properties:
> > > > +- label: Name for this LED. If omitted, the label is taken from the node name.
> > > > +- linux,default-trigger: Trigger assigned to the LED.
> > > > +
> > > > +Example:
> > > > +
> > > > +ns2-leds {
> > > > + compatible = "ns2-leds";
> > > > +
> > > > + blue-sata {
> > > > + label = "ns2:blue:sata";
> > > > + slow-gpio = <&gpio0 29 0>;
> > > > + cmd-gpio = <&gpio0 30 0>;
> > > > + };
> > > > +};
> > > > diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
> > > > index d176ec8..55d199b 100644
> > > > --- a/drivers/leds/leds-ns2.c
> > > > +++ b/drivers/leds/leds-ns2.c
> > > > @@ -30,6 +30,7 @@
> > > > #include <linux/leds.h>
> > > > #include <linux/module.h>
> > > > #include <linux/platform_data/leds-kirkwood-ns2.h>
> > > > +#include <linux/of_gpio.h>
> > > >
> > > > /*
> > > > * The Network Space v2 dual-GPIO LED is wired to a CPLD and can blink in
> > > > @@ -263,6 +264,68 @@ static void delete_ns2_led(struct ns2_led_data *led_dat)
> > > > gpio_free(led_dat->slow);
> > > > }
> > > >
> > > > +#ifdef CONFIG_OF_GPIO
> > > > +/*
> > > > + * Translate OpenFirmware node properties into platform_data.
> > > > + */
> > > > +static int __devinit
> > > > +ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
> > > > +{
> > > > + struct device_node *np = dev->of_node;
> > > > + struct device_node *child;
> > > > + struct ns2_led *leds;
> > > > + int num_leds = 0;
> > > > + int i = 0;
> > > > +
> > > > + num_leds = of_get_child_count(np);
> > > > + if (!num_leds)
> > > > + return -ENODEV;
> > > > +
> > > > + leds = devm_kzalloc(dev, num_leds * sizeof(struct ns2_led),
> > > > + GFP_KERNEL);
> > > > + if (!leds)
> > > > + return -ENOMEM;
> > > > +
> > > > + for_each_child_of_node(np, child) {
> > > > + const char *string;
> > > > + int ret;
> > > > +
> > > > + ret = of_get_named_gpio(child, "cmd-gpio", 0);
> > > > + if (ret < 0)
> > > > + return ret;
> > >
> > > free leds?
> >
> > Maybe I missed something but I though it was the purpose of using devres
> > function as devm_kzalloc.
>
> You are correct. alloc/return involks a visceral reaction, akin to a
> bull seeing red, my mistake. :-)
>
> >
> > >
> > > > + leds[i].cmd = ret;
> > > > + ret = of_get_named_gpio(child, "slow-gpio", 0);
> > > > + if (ret < 0)
> > > > + return ret;
> > >
> > > same here.
> > >
> > > > + leds[i].slow = ret;
> > > > + ret = of_property_read_string(child, "label", &string);
> > > > + leds[i].name = (ret == 0) ? string : child->name;
> > > > + ret = of_property_read_string(child, "linux,default-trigger",
> > > > + &string);
> > > > + if (ret == 0)
> > > > + leds[i].default_trigger = string;
> > > > +
> > > > + i++;
> > > > + }
> > > > +
> > > > + pdata->leds = leds;
> > > > + pdata->num_leds = num_leds;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static const struct of_device_id of_ns2_leds_match[] = {
> > > > + { .compatible = "ns2-leds", },
> > >
> > > Is this LaCie-specific? eg "lacie,ns2-leds"?
> >
> > Yes I think it is LaCie specific.
>
> Ok, please change.
>
> >
> > >
> > > > + {},
> > > > +};
> > > > +#else
> > > > +static int __devinit
> > > > +ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
> > > > +{
> > > > + return -ENODEV;
> > > > +}
> > > > +#endif /* CONFIG_OF_GPIO */
> > >
> > > The above doesn't look right to me. The only time
> > > ns2_leds_get_of_pdata() gets called is when OF_GPIO is enabled. You
> > > should be able to remove the #else block.
> >
> > Yes you are right.
> >
> > >
> > > > +
> > > > static int __devinit ns2_led_probe(struct platform_device *pdev)
> > > > {
> > > > struct ns2_led_platform_data *pdata = pdev->dev.platform_data;
> > > > @@ -270,11 +333,25 @@ static int __devinit ns2_led_probe(struct platform_device *pdev)
> > > > int i;
> > > > int ret;
> > > >
> > > > +#ifdef CONFIG_OF_GPIO
> > > > + if (!pdata) {
> > > > + pdata = devm_kzalloc(&pdev->dev,
> > > > + sizeof(struct ns2_led_platform_data),
> > > > + GFP_KERNEL);
> > > > + if (!pdata)
> > > > + return -ENOMEM;
> > > > +
> > > > + ret = ns2_leds_get_of_pdata(&pdev->dev, pdata);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +#else
> > > > if (!pdata)
> > > > return -EINVAL;
> > > > +#endif /* CONFIG_OF_GPIO */
> > > >
> > > > leds_data = devm_kzalloc(&pdev->dev, sizeof(struct ns2_led_data) *
> > > > - pdata->num_leds, GFP_KERNEL);
> > > > + pdata->num_leds, GFP_KERNEL);
> > > > if (!leds_data)
> > > > return -ENOMEM;
> > > >
> > > > @@ -312,8 +389,9 @@ static struct platform_driver ns2_led_driver = {
> > > > .probe = ns2_led_probe,
> > > > .remove = __devexit_p(ns2_led_remove),
> > > > .driver = {
> > > > - .name = "leds-ns2",
> > > > - .owner = THIS_MODULE,
> > > > + .name = "leds-ns2",
> > > > + .owner = THIS_MODULE,
> > >
> > > nit. whitespace before '=', above two lines.
> >
> > Sorry I don't get it. For the two lines before, I used two tabs before
> > '='. As a result, this lines are aligned with the next one. I got no
> > warnings and no errors from checkpatch.pl.
>
> It's not a checkpatch problem. It's that before your patch, the equals
> signs were lined up. Afterwards, they aren't. In either case, if you
> would like to fix the whitespace (line up all struct elements and the
> equals signs), that should be a separate patch.
The current patch inserts a new field (of_match_table) in the structure.
This new field breaks the equals signs alignment. I think it is correct
to restore the alignment broken by a patch in the same patch context.
Do you really want me to put this in a separate patch ?
>
> >
> > >
> > > > + .of_match_table = of_match_ptr(of_ns2_leds_match),
> > >
> > > Have you tried this with OF_GPIO=n? of_match_ptr() handles CONFIG_OF
> > > being enabled/disabled. Which means the case of CONFIG_OF=y,
> > > CONFIG_OF_GPIO=n appears to be unhandled.
> >
> > Good caught. I guess I have just copied a bug from the driver gpio-fan.
>
> On the next round, please add a separate patch fixing gpio-fan.c.
After a second look, I noticed that several drivers are also mixing up
CONFIG_OF and CONFIG_OF_GPIO checks: gpio-fan, leds-gpio, gpio_keys.c,
i2c-gpio.c, spi-s3c64xx.c, ...
I also noticed that CONFIG_OF_GPIO can't be selected separately from
CONFIG_OF. From Kconfig, CONFIG_OF implies CONFIG_OF_GPIO.
So, I am no longer convinced we have a bug here. But if there is, we
will need more than a single patch to fix it :)
Let me know your advice about that.
Simon
>
> There shouldn't be any harm in moving the struct of_device_id {} outside
> of the #ifdef and just above the struct platform_driver {} declaration.
> That would maintain the convention. _probe() will just return -EINVAL
> if OF_GPIO isn't enabled (without pdata, of course).
>
> thx,
>
> Jason.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121016/2ce47165/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] ASoC: atmel-ssc: use module_platform_driver macro
From: Fabio Porcedda @ 2012-10-16 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350359819-2461-2-git-send-email-voice.shen@atmel.com>
On Tue, Oct 16, 2012 at 5:56 AM, Bo Shen <voice.shen@atmel.com> wrote:
> This patch removes some code duplication by using module_platform_driver
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> drivers/misc/atmel-ssc.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 23dcb76..ac00f83 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -68,7 +68,7 @@ void ssc_free(struct ssc_device *ssc)
> }
> EXPORT_SYMBOL(ssc_free);
>
> -static int __init ssc_probe(struct platform_device *pdev)
> +static int ssc_probe(struct platform_device *pdev)
> {
> struct resource *regs;
> struct ssc_device *ssc;
> @@ -135,24 +135,14 @@ static int __devexit ssc_remove(struct platform_device *pdev)
> }
>
> static struct platform_driver ssc_driver = {
> - .remove = __devexit_p(ssc_remove),
> .driver = {
> .name = "ssc",
> .owner = THIS_MODULE,
> },
> + .probe = ssc_probe,
> + .remove = __devexit_p(ssc_remove),
> };
> -
> -static int __init ssc_init(void)
> -{
> - return platform_driver_probe(&ssc_driver, ssc_probe);
> -}
> -module_init(ssc_init);
> -
> -static void __exit ssc_exit(void)
> -{
> - platform_driver_unregister(&ssc_driver);
> -}
> -module_exit(ssc_exit);
> +module_platform_driver(ssc_driver);
>
> MODULE_AUTHOR("Hans-Christian Egtvedt <hcegtvedt@atmel.com>");
> MODULE_DESCRIPTION("SSC driver for Atmel AVR32 and AT91");
> --
> 1.7.9.5
Maybe the module_platform_driver isn't a substitute of platform_driver_probe,
because module_platform_driver use platform_driver_register/unregister.
Using that macro we lose the advantage of platform_driver_probe,
as stated in:
https://lkml.org/lkml/2012/1/10/335
On Tue, Jan 10, 2012 at 21:47, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> [...]
>Still, setting up platform_driver.probe and removing __init from all probe
>functions is not the right thing to do, as this make (non-__init) kernel code
>size bigger, while none of these devices are hotpluggable and thus cannot
>appear after bootup. That's why we have platform_driver_probe() in the
>first place. So I think all of this should be reverted for non-hotpluggable
>drivers.
> [...]
What do you think?
Best regards
--
Fabio Porcedda
^ permalink raw reply
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Daniel Vetter @ 2012-10-16 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350309832-18461-1-git-send-email-m.szyprowski@samsung.com>
On Mon, Oct 15, 2012 at 4:03 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Some devices, which have IOMMU, for some use cases might require to
> allocate a buffers for DMA which is contiguous in physical memory. Such
> use cases appears for example in DRM subsystem when one wants to improve
> performance or use secure buffer protection.
>
> I would like to ask if adding a new attribute, as proposed in this RFC
> is a good idea? I feel that it might be an attribute just for a single
> driver, but I would like to know your opinion. Should we look for other
> solution?
One thing to consider is that up to know all allocation constraints
have been stored somewhere in struct device, either in the dma
attributes (for the more generic stuff) or somewhere in platform
specific data (e.g. for special cma pools). The design of dma_buf
relies on this: The exporter/buffer allocator only sees all the struct
device *devs that want to take part in sharing a given buffer. With
this proposal some of these allocation constraints get moved to alloc
time and aren't visible in the struct device any more. Now I that
dma_buf isn't really there yet and no one has yet implemented a
generic exporter that would allocate the dma_buf at the right spot for
all cases, but I think we should consider this to not draw ourselves
into an ugly api corner.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 2/2] ASoC: atmel-ssc: use module_platform_driver macro
From: Russell King - ARM Linux @ 2012-10-16 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016084947.GD12801@game.jcrosoft.org>
On Tue, Oct 16, 2012 at 10:49:47AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:07 Tue 16 Oct , Nicolas Ferre wrote:
> > On 10/16/2012 05:56 AM, Bo Shen :
> > > -static int __init ssc_probe(struct platform_device *pdev)
> > > +static int ssc_probe(struct platform_device *pdev)
> >
> > Here you remove the __init altogether, maybe converting to __devinit is
> > the proper replacement for this? I do not know myself but if anybody knows?
> yes __devinit is mandatory
No it isn't. __init is plain buggy. __devinit is better, but there's
plans to remove all __devinit from the kernel. Having nothing there
will make GregKH's life a lot easier when he does come to remove __devinit.
^ permalink raw reply
* [PATCH 2/2] ASoC: atmel-ssc: use module_platform_driver macro
From: Bo Shen @ 2012-10-16 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016084947.GD12801@game.jcrosoft.org>
On 10/16/2012 16:49, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:07 Tue 16 Oct , Nicolas Ferre wrote:
>> On 10/16/2012 05:56 AM, Bo Shen :
>>> This patch removes some code duplication by using module_platform_driver
>>>
>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>
>> Very good simplification but...
>>
>>> ---
>>> drivers/misc/atmel-ssc.c | 18 ++++--------------
>>> 1 file changed, 4 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
>>> index 23dcb76..ac00f83 100644
>>> --- a/drivers/misc/atmel-ssc.c
>>> +++ b/drivers/misc/atmel-ssc.c
>>> @@ -68,7 +68,7 @@ void ssc_free(struct ssc_device *ssc)
>>> }
>>> EXPORT_SYMBOL(ssc_free);
>>>
>>> -static int __init ssc_probe(struct platform_device *pdev)
>>> +static int ssc_probe(struct platform_device *pdev)
>>
>> Here you remove the __init altogether, maybe converting to __devinit is
>> the proper replacement for this? I do not know myself but if anybody knows?
> yes __devinit is mandatory
I will add a small patch to fix this.
Thanks.
BRs,
Bo Shen
>
> Best Regards,
> J.
>
^ permalink raw reply
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Russell King - ARM Linux @ 2012-10-16 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016090434.7d5e088152a3e0b0606903c8@nvidia.com>
On Tue, Oct 16, 2012 at 09:04:34AM +0300, Hiroshi Doyu wrote:
> In addition to those contiguous/discontiguous page allocation, is
> there any way to _import_ anonymous pages allocated by a process to be
> used in dma-mapping API later?
>
> I'm considering the following scenario, an user process allocates a
> buffer by malloc() in advance, and then it asks some driver to convert
> that buffer into IOMMU'able/DMA'able ones later. In this case, pages
> are discouguous and even they may not be yet allocated at
> malloc()/mmap().
That situation is covered. It's the streaming API you're wanting for that.
dma_map_sg() - but you may need additional cache handling via
flush_dcache_page() to ensure that your code is safe for all CPU cache
architectures.
Remember that pages allocated into userspace will be cacheable, so a cache
flush is required before they can be DMA'd. Hence the streaming API.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: hwmod data: Fix wrong lostcontext_mask for OMAP4 l4_abe
From: Benoit Cousson @ 2012-10-16 8:55 UTC (permalink / raw)
To: linux-arm-kernel
The following commit added the support for the lostcontext_mask
along with the usage of the flag for l4_abe.
commit ce80979aedfce937926a8dd40a1f92fd4bc2fd53
Author: Tero Kristo <t-kristo@ti.com>
Date: Sun Sep 23 17:28:19 2012 -0600
ARM: OMAP4: hwmod data: add support for lostcontext_mask
Unfortunately, the l4_abe does not contain this memory and thus
cannot contain that flag.
Remove the flag from the l4_abe hwmod.
Change as well the mask for omap44xx_aess_hwmod to avoid missing
the status in case LOSTMEM_AESSMEM is set. The AESS logic does
not support retention and thus only the memory state is useful.
It is even mandatory to avoid a crash in the case of the AESS
resume.
TBD: Ideally each hwmod should contain an extra entry for memory
context attached to it. The AESS does contain only one, but some
IP like the IVAHD does have three memories with dedicated status.
The granularity is never used, but at least one global information
for all the memory banks is useful.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..c820de2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -203,9 +203,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
- .context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
- .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
},
},
};
@@ -351,7 +349,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_AESS_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTCONTEXT_DFF_MASK,
+ .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ASoC: atmel-ssc: use module_platform_driver macro
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-16 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507D15C2.7000606@atmel.com>
On 10:07 Tue 16 Oct , Nicolas Ferre wrote:
> On 10/16/2012 05:56 AM, Bo Shen :
> > This patch removes some code duplication by using module_platform_driver
> >
> > Signed-off-by: Bo Shen <voice.shen@atmel.com>
>
> Very good simplification but...
>
> > ---
> > drivers/misc/atmel-ssc.c | 18 ++++--------------
> > 1 file changed, 4 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> > index 23dcb76..ac00f83 100644
> > --- a/drivers/misc/atmel-ssc.c
> > +++ b/drivers/misc/atmel-ssc.c
> > @@ -68,7 +68,7 @@ void ssc_free(struct ssc_device *ssc)
> > }
> > EXPORT_SYMBOL(ssc_free);
> >
> > -static int __init ssc_probe(struct platform_device *pdev)
> > +static int ssc_probe(struct platform_device *pdev)
>
> Here you remove the __init altogether, maybe converting to __devinit is
> the proper replacement for this? I do not know myself but if anybody knows?
yes __devinit is mandatory
Best Regards,
J.
^ permalink raw reply
* [PATCH RFC 2/6 v3] gpio: Add sysfs support to block GPIO API
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-16 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZmg4+7Zjm2UJktt1uKvytUW3uaYtKz0nJvLeM2MMSV-Q@mail.gmail.com>
On 22:30 Mon 15 Oct , Linus Walleij wrote:
> I really request Grant to comment on this...too.
>
> On Mon, Oct 15, 2012 at 8:19 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Oct 15, 2012 at 08:07:02PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 21:11 Fri 12 Oct , Roland Stigge wrote:
> >> > This patch adds sysfs support to the block GPIO API.
> >> >
> >> > Signed-off-by: Roland Stigge <stigge@antcom.de>
> >> >
> >> > ---
> >> > Documentation/ABI/testing/sysfs-gpio | 6
> >> > drivers/gpio/gpiolib.c | 226 ++++++++++++++++++++++++++++++++++-
> >> > include/asm-generic/gpio.h | 11 +
> >> > include/linux/gpio.h | 13 ++
> >> > 4 files changed, 254 insertions(+), 2 deletions(-)
> >> I really don't like this sysfs we need to add a specific device with ioctl
> >
> > Why?
>
> I don't like it either, basically because the GPIO sysfs is not
> entirely sound.
>
> Another patch that is circulating concerns edge triggers and similar,
> and it appear that some parts of the GPIO sysfs is for example
> redefining and exporting IRQchip properties like trigger edge
> in sysfs, while the settings of the irqchip actually used by the driver
> is not reflected in the other direction. So you can *set* these things
> by writing in the GPIO sysfs, but never trust what you *read* from
> there. And you can set what edges an IRQ will trigger on a certain
> GPIO, and the way to handle the IRQs from usespace is to poll
> on a value. This is not really documented but well ...
>
> Part of me just want to delete that, but I can't because it's now
> an ABI.
>
> The "devices" that the sysfs files are tied to are not real devices,
> instead the code look like this: whenever a gpio is exported to
> sysfs, the code calls (drivers/gpio/gpiolib.c):
>
> dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0),
> desc, ioname ? ioname : "gpio%u", gpio);
>
> Mock device just to get a sysfs opening. And once device for
> every GPIO with no hierarchical correspondence to anything
> in the system.
>
> The thing is that struct gpio_chip is not a device at all, it's something
> else.
>
> This inconsistency in the GPIO sysfs implementation make me
> fear adding new stuff to it. The other problems need fixing first.
>
> The reason an ioctl() IMO is better suited to do the job is that
> it can properly represent a multiple-value operation on several
> GPIOs at the same time in a struct, and it can conversely inform
> userspace about which GPIOs may be a block of signals that
> can be fired simultaneously instead of going to string parsing
> and binary values in sysfs which look like worse hacks to me.
>
> The last thing I'm a bit softer on though. Mainly I fear of this
> sysfs ABI growing into a beast.
>
> It was all merged prior to Grant becoming maintainer and
> me becoming co-maintainer of it, so this is legacy business.
>
> Sadly the main creator of this ABI is David Brownell who is
> not able to respond nor maintain it from where he is now. But
> we need to think hard about what we shall do with this particular
> piece of legacy. Some of the stuff was added by Daniel
> Gl?ckner so requesting advice from him.
>
> Daniel: are you interested in helping us fixing the GPIOlib
> sysfs ABI and kernel internals? I'm a bit afraid of it.
My 0.02$ too
Best Regards,
J.
^ permalink raw reply
* [PATCH v3 2/2] i2c: change id to let i2c-at91 work
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-16 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507CD0CA.9010006@atmel.com>
On 11:13 Tue 16 Oct , Bo Shen wrote:
> Hi J,
>
> On 10/15/2012 23:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 17:30 Mon 15 Oct , Bo Shen wrote:
> >>The i2c core driver will turn the platform device ID to busnum
> >>When using platfrom device ID as -1, it means dynamically assigned
> >>the busnum. When writing code, we need to make sure the busnum,
> >>and call i2c_register_board_info(int busnum, ...) to register device
> >>if using -1, we do not know the value of busnum
> >>
> >>In order to solve this issue, set the platform device ID as a fix number
> >>Here using 0 to match the busnum used in i2c_regsiter_board_info()
> >>
> >>Signed-off-by: Bo Shen <voice.shen@atmel.com>
> >>---
> >
> >can you check when this append for the first time to schedule a patch for stable too
>
> OK. I will resend it and add linux stable into the cc list.
no this not how it work
I ask you to check which patch add the regression and then when this is
applied in the kernel we will request greg to apply it too to the stable
But before do that you MUST foudn the commit responsible
Best Regards,
J.
^ permalink raw reply
* [PATCH] mm: compaction: Correct the nr_strict_isolated check for CMA
From: Mel Gorman @ 2012-10-16 8:39 UTC (permalink / raw)
To: linux-arm-kernel
Thierry reported that the "iron out" patch for isolate_freepages_block()
had problems due to the strict check being too strict with "mm: compaction:
Iron out isolate_freepages_block() and isolate_freepages_range() -fix1".
It's possible that more pages than necessary are isolated but the check
still fails and I missed that this fix was not picked up before RC1. This
same problem has been identified in 3.7-RC1 by Tony Prisk and should be
addressed by the following patch.
Signed-off-by: Mel Gorman <mgorman@suse.de>
Tested-by: Tony Prisk <linux@prisktech.co.nz>
---
mm/compaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 2c4ce17..9eef558 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -346,7 +346,7 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
* pages requested were isolated. If there were any failures, 0 is
* returned and CMA will fail.
*/
- if (strict && nr_strict_required != total_isolated)
+ if (strict && nr_strict_required > total_isolated)
total_isolated = 0;
if (locked)
^ permalink raw reply related
* [PATCH] mmc: mmci: Fixup and cleanup code for DMA handling
From: Linus Walleij @ 2012-10-16 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFr=aN+MN+VCvbAqNa7mu+fxTTeHdcA1oCv8QWqpdT8MGQ@mail.gmail.com>
On Tue, Oct 16, 2012 at 9:16 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> This code has not been tested on a "legacy" ARM PL180 but only for
> ux500 boards. Even if it should affect DMA handling we should test
> this properly. Would be great if you were able to help out, I guess
> you still have available hardware for these tests?
I can test the Integrator/CP and Realview in IRQ/PIO mode and
the U300 in DMA mode.
I need some help to provoke errorpath in DMA mode though,
so any hints are welcome...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Peter De Schrijver @ 2012-10-16 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRQg3-QwSfvuU1n7mUq1QhtU2Q+yHUpZ7PtRYQot=pijng@mail.gmail.com>
On Tue, Oct 16, 2012 at 12:33:07AM +0200, Colin Cross wrote:
> On Mon, Oct 15, 2012 at 8:59 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 10/15/2012 01:56 AM, Joseph Lo wrote:
> >> There is still one thing you should know. Because we are planning to
> >> upstream "CPUquiet" framework that is a CPU auto hotplug mechanism. It
> >> will auto hotplug the CPUs depends on the system is busy or not. So when
> >> system is idle, there will be only one CPU online (i.e, CPU0). The
> >> secondary CPUs will all be hot plugged (i.e, offline and power gate). We
> >> need to think about do we still need coupled cpuidle on Tegra30 if we
> >> are going to use "CPUquiet".
> >
> > CPUquiet isn't relevant at all. First, a user may presumably disable
> > CPUquiet's Kconfig option (it had better have one, and the system had
> > better work with it disabled). Second, even if CPUquiet is enabled, I
> > don't imagine there is a 100% guarantee that hot(un)plug will happen
> > before cpuidle kicks in, is there? Finally, is there any guarantee that
> > CPUquiet will actually be accepted upstream?
>
> CPUquiet is a glorified hotplug governor, and hotplug governors have
> been widely rejected upstream, so I wouldn't plan on seeing it
> accepted.
Note that nothing in CPUquiet enforces the use of hotplug. It assumes there
is a way to put a CPU in a quiet state which means it doesn't get interrupted,
doesn't do any work and doesn't respond to IPIs. Currently only hotplug
provides this state, but it's possible to provide a driver which uses a
different mechanism to provide the same state. We need this state to be able
to switch to the low power cluster which has only 1 CPU. IPIs to non-existing
cores would hang the system.
Cheers,
Peter.
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: Tony Prisk @ 2012-10-16 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016075835.GF29125@suse.de>
On Tue, 2012-10-16 at 08:58 +0100, Mel Gorman wrote:
> On Tue, Oct 16, 2012 at 07:50:07PM +1300, Tony Prisk wrote:
> > > > > Why it caused a problem on that particular commit I don't know - but it
> > > > > was reproducible by adding/removing it.
> > > > >
> > >
> > > I finally found the link to this patch which caused the problem - and
> > > may still be the cause of my problems :)
> > >
>
> Blast, thanks. This was already identified as being a problem and "fixed"
> in https://lkml.org/lkml/2012/10/5/164 but I missed that the fix did not
> get picked up before RC1 after all the patches got collapsed together. I'm
> very sorry about that, I should have spotted that it didn't make it through.
>
> > Any suggestions on how to fix this?
> >
>
> Can you test this to be sure and if it's fine I'll push it to Andrew.
>
> ---8<---
> mm: compaction: Correct the strict_isolated check for CMA
>
> Thierry reported that the "iron out" patch for isolate_freepages_block()
> had problems due to the strict check being too strict with "mm: compaction:
> Iron out isolate_freepages_block() and isolate_freepages_range() -fix1".
> It's possible that more pages than necessary are isolated but the check
> still fails and I missed that this fix was not picked up before RC1. This
> has also been identified in RC1 by Tony Prisk and should be addressed by
> the following patch.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> compaction.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 2c4ce17..9eef558 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -346,7 +346,7 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
> * pages requested were isolated. If there were any failures, 0 is
> * returned and CMA will fail.
> */
> - if (strict && nr_strict_required != total_isolated)
> + if (strict && nr_strict_required > total_isolated)
> total_isolated = 0;
>
> if (locked)
I don't need to test that again.. thats exactly what I did to fix it
myself :)
Tested-by: Tony Prisk <linux@prisktech.co.nz>
.. if needed.
Nice to know I'm not completely bonkers.
Thanks for your help
Tony P
^ 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