* [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Arnd Bergmann @ 2014-02-05 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F20387.3090709@monstr.eu>
On Wednesday 05 February 2014, Michal Simek wrote:
> I am not quite sure what you mean by reports to user space.
> If you mean to get timeout through ioctl for example - then yes it is working
> through standard watchdog ioctl interface and timeout is calculated
> from hardware setup.
Yes, that is what I meant. I believe most other watchdogs let
you program the timeout, but I don't see anything wrong with
having that fixed in the FPGA in your case.
Still, the choice of putting the timeout into DT in terms of
cycles rather than miliseconds wasn't ideal from an interface
perspective and we should change that if/when we do a generic
binding. I can definitely see where it's coming from for your
case, as the cycle count totally makes sense from an FPGA
tool perspective...
Arnd
^ permalink raw reply
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Vinayak Kale @ 2014-02-05 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203111754.GB14112@mudshark.cambridge.arm.com>
On Mon, Feb 3, 2014 at 4:47 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Nico, Russell,
>
> Thanks for the replies.
>
> On Fri, Jan 31, 2014 at 10:48:50AM +0000, Russell King - ARM Linux wrote:
>> On Fri, Jan 31, 2014 at 12:16:48AM +0000, Will Deacon wrote:
>> > On Thu, Jan 30, 2014 at 09:42:29PM +0000, Nicolas Pitre wrote:
>> > > I don't think they would be reordered at all with the
>> > > volatile qualifiers.
>> >
>> > Whilst that may be the case in current compilers (i.e. I've not actually
>> > seen the above sequence get re-ordered), the GCC documentation states that:
>> >
>> > Similarly, you can't expect a sequence of volatile asm instructions to remain
>> > perfectly consecutive. If you want consecutive output, use a single asm. Also,
>> > GCC performs some optimizations across a volatile asm instruction; GCC does not
>> > `forget everything' when it encounters a volatile asm instruction the way some
>> > other compilers do.
>> >
>> > so I really think that the "memory" clobbers are needed to ensure strict
>> > ordering. This matches my understanding from discussions with the compiler
>> > engineers at ARM.
>>
>> What it means is that the compiler may introduce additional instructions
>> between your consecutive asm() statements. So there's no guarantee that
>> the ISB will immediately follow the MSR instruction - there may be other
>> instructions which the compiler may decide to schedule between the two.
>>
>> For example, instructions to load the address of the variable(s) may be
>> inserted between the assembly specified in the asm() statements which
>> may involve loading from a literal pool.
>
> That matches what Nicolas said and, to be honest, makes a lot of sense. I'm
> just slightly concerned that it doesn't match the explanation I received
> from some compiler guys, but I can chase that down separately.
>
> Vinayak: sorry for leading you down the garden path on this. Please can you
> stick with your original patch, but adding something equivalent for
> arch/arm?
I have posted a patch for arch/arm, have tested it for ARM-v7.
>
> Cheers,
>
> Will
^ permalink raw reply
* [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Michal Simek @ 2014-02-05 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402051036.19428.arnd@arndb.de>
On 02/05/2014 10:36 AM, Arnd Bergmann wrote:
> On Wednesday 05 February 2014, Michal Simek wrote:
>> I am not quite sure what you mean by reports to user space.
>> If you mean to get timeout through ioctl for example - then yes it is working
>> through standard watchdog ioctl interface and timeout is calculated
>> from hardware setup.
>
> Yes, that is what I meant. I believe most other watchdogs let
> you program the timeout, but I don't see anything wrong with
> having that fixed in the FPGA in your case.
>
> Still, the choice of putting the timeout into DT in terms of
> cycles rather than miliseconds wasn't ideal from an interface
> perspective and we should change that if/when we do a generic
> binding. I can definitely see where it's coming from for your
> case, as the cycle count totally makes sense from an FPGA
> tool perspective...
Thanks. I take this like ACK for this current binding description.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/a5adb1d4/attachment-0001.sig>
^ permalink raw reply
* [PATCH] clk: add strict of_clk_init dependency check
From: Boris BREZILLON @ 2014-02-05 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391554766-11285-1-git-send-email-gregory.clement@free-electrons.com>
The parent dependency check is only available on the first parent of a given
clk.
Add support for strict dependency check: all parents of a given clk must be
initialized.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
Hello Gregory,
This patch adds support for strict check on clk dependencies (check if all
parents specified by an DT clk node are initialized).
I'm not sure this is what you were expecting (maybe testing the first parent
is what you really want), so please feel free to tell me if I'm wrong.
Best Regards,
Boris
drivers/clk/clk.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index beb0f8b..6849769 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2543,22 +2543,37 @@ static int parent_ready(struct device_node *np)
{
struct of_phandle_args clkspec;
struct of_clk_provider *provider;
+ int num_parents;
+ bool found;
+ int i;
/*
* If there is no clock parent, no need to wait for them, then
* we can consider their absence as being ready
*/
- if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
- &clkspec))
+ num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+ if (num_parents <= 0)
return 1;
- /* Check if we have such a provider in our array */
- list_for_each_entry(provider, &of_clk_providers, link) {
- if (provider->node == clkspec.np)
+ for (i = 0; i < num_parents; i++) {
+ if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
+ &clkspec))
return 1;
+
+ /* Check if we have such a provider in our array */
+ found = false;
+ list_for_each_entry(provider, &of_clk_providers, link) {
+ if (provider->node == clkspec.np) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ return 0;
}
- return 0;
+ return 1;
}
/**
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Heiko Stübner @ 2014-02-05 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140201041051.9977.46568@quantum>
Am Freitag, 31. Januar 2014, 20:10:51 schrieb Mike Turquette:
> Quoting Heiko St?bner (2014-01-30 07:09:04)
>
> > On Thursday, 30. January 2014 18:23:44 Thomas Abraham wrote:
> > > Hi Mike,
> > >
> > > On Wed, Jan 29, 2014 at 12:17 AM, Mike Turquette <mturquette@linaro.org>
> >
> > wrote:
> > > > On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham <ta.omasab@gmail.com>
> >
> > wrote:
> > > >> Hi Mike,
> > > >>
> > > >> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette
> > > >> <mturquette@linaro.org>
> >
> > wrote:
> > > >>> Quoting Thomas Abraham (2014-01-18 04:10:51)
> > > >
> > > > As far as I can tell
> > > > the remux does not happen because it is necessary to generate the
> > > > required clock rate, but because we don't want to run the ARM core out
> > > > of spec for a short time while the PLL relocks. Assuming I have that
> > > > part of it right, I prefer for the parent mux operation to be a part
> > > > of the CPUfreq driver's .target callback instead of hidden away in the
> > > > clock driver.
> > >
> > > The re-parenting is mostly done to keep the ARM CPU clocked while the
> > > PLL is stopped, reprogrammed and restarted. One of the side effects of
> > > that is, the clock speed of the temporary parent could be higher then
> > > what is allowed due to the ARM voltage at the time of re-parenting.
> > > That is the reason to use the safe voltage.
> >
> > The Rockchip-SoCs use something similar, so I'm following quite closely
> > what Thomas is trying to do here, as similar solution would also solve
> > this issue for me.
> >
> > On some Rockchip-SoCs even stuff like pclk and hclk seems to be sourced
> > from the divided armclk, creating additional constraints.
> >
> > But on the RKs (at least in the upstream sources) the armclk is simply
> > equal to the pll output. A divider exists, but is only used to make sure
> > that the armclk stays below the original rate when sourced from the
> > temp-parent, like>
> > if (clk_get_rate(temp_parent) > clk_get_rate(main_parent)
> >
> > set_divider(something so that rate(temp) <= rate(main)
> >
> > clk_set_parent(...)
> >
> > Isn't there a similar possiblity on your platform, as it would remove the
> > need for the safe-voltage?
> >
> >
> > In general I also like the approach of hiding the rate-change logic inside
> > this composite clock, as the depending clocks can be easily kept in sync.
> > As with the Rockchips the depending clocks are different for each of the
> > three Cortex-A9 SoCs I looked at, it would be "interesting" if all of
> > this would need to be done in a cpufreq driver.
>
> I wonder if hiding these details inside of the composite clock
> implementation indicates the lack of some needed feature in the clk
> core? I've discussed the idea of "coordinated rate changes" before. E.g:
>
> _________________________________________________________
>
> | clk | opp-low | opp-mid | opp-fast |
> |
> |pll | 300000 | 600000 | 600000 |
> |
> |div | 150000 | 300000 | 600000 |
> |
> |mpu_clk| 150000 | 300000 | 600000 |
> |
> |periph | 150000 | 150000 | 300000 |
>
> ---------------------------------------------------------
>
> A call to clk_set_rate() against any of those clocks will result in all
> of their dividers being updated. At the implementation level this might
> look something like this extremely simplified pseudocode:
>
> int clk_set_rate(struct clk* clk, unsigned long rate)
> {
> /* trap clks that support coordinated rate changes */
> if (clk->ops->coordinate_rate)
> return clk->ops->coordinate_rate(clk->hw, rate);
> ...
> }
>
> and,
>
> struct coord_rates {
> struct clk_hw *hw;
> struct clk *parent;
> struct clk *rate;
> };
>
> and in the clock driver,
>
> #define PLL 0
> #define DIV 1
> #define MPU 2
> #define PER 3
>
> #define NR_OPP 4
> #define NR_CLK 4
>
> struct coord_rates my_opps[NR_OPP][NR_CLK]; // populated from DT data
>
> int my_coordinate_rate_callback(struct clk_hw *hw, unsigned long rate)
> {
> struct coord_rate **selected_opp;
>
> for(i = 0; i < NR_OPP; i++) {
> for(j = 0; j < NR_CLK; j++) {
> if (my_opps[i][j]->hw == hw &&
> my_opps[i][j]->rate == rate)
> selected_opp = my_opps[i];
> break;
> }
> }
>
> /*
> * order of operations is specific to my hardware and should be
> * managed by my clock driver, not generic code
> */
>
> __clk_set_parent(selected_opp[DIV]->hw, temp_parent);
> __clk_set_rate(selected_opp[PLL]->hw, selected_opp[PLL]->rate);
> __clk_set_parent(selected_opp[DIV]->hw,
> selected_opp[PLL]->hw->clk);
> ...
>
> /*
> * note that the above could be handled by a switch-case or
> * something else
> */
> }
>
> Thoughts? Please forgive any gaps in my logic or abuse of C.
>
> I have long thought that something like the above would someday go into
> a generic dvfs layer instead of the clock framework, but maybe starting
> with the clk framework makes more sense?
Similar to Thomas, this looks like the thing I'd need for my core clocks.
Also to me this really looks like something belonging to the clock framework,
as we at this point really only have some clocks that in all cases need to be
set together, independent of it beeing embedded in some scaling context or
something else.
Heiko
^ permalink raw reply
* [PATCH v2 5/5] of: document bindings for reserved-memory nodes
From: Grant Likely @ 2014-02-05 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-6-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:33 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> From: Grant Likely <grant.likely@linaro.org>
>
> Reserved memory nodes allow for the reservation of static (fixed
> address) regions, or dynamically allocated regions for a specific
> purpose.
>
> [joshc: Based on binding document proposed (in non-patch form) here:
> http://lkml.kernel.org/g/20131030134702.19B57C402A0 at trevor.secretlab.ca
> adapted to support #memory-region-cells]
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> .../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++++++++++
> 1 file changed, 138 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> new file mode 100644
> index 000000000000..a606ce90c9c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -0,0 +1,138 @@
> +*** Reserved memory regions ***
> +
> +Reserved memory is specified as a node under the /reserved-memory node.
> +The operating system shall exclude reserved memory from normal usage
> +one can create child nodes describing particular reserved (excluded from
> +normal use) memory regions. Such memory regions are usually designed for
> +the special usage by various device drivers.
> +
> +Parameters for each memory region can be encoded into the device tree
> +with the following nodes:
> +
> +/reserved-memory node
> +---------------------
> +#address-cells, #size-cells (required) - standard definition
> + - Should use the same values as the root node
> +#memory-region-cells (required) - dictates number of cells used in the child
> + nodes memory-region specifier
I don't think this isn't defined well enough. These reserved regions may
not have a driver attached to them, so there is no central agent to
decide what the specifier means. That leaves the interpretation of
the memory region in the hands of the client drivers. How do you see the
specifier getting parsed and used?
Otherwise the binding looks good to me. Also, please add my s-o-b line
to the patch (instead of a-b because I authored part of the text)
Signed-off-by: Grant Likely <grant.likely@linaro.org>
g.
> +ranges (required) - standard definition
> + - Should be empty
> +
> +/reserved-memory/ child nodes
> +-----------------------------
> +Each child of the reserved-memory node specifies one or more regions of
> +reserved memory. Each child node may either use a 'reg' property to
> +specify a specific range of reserved memory, or a 'size' property with
> +optional constraints to request a dynamically allocated block of memory.
> +
> +Following the generic-names recommended practice, node names should
> +reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
> +address (@<address>) should be appended to the name if the node is a
> +static allocation.
> +
> +Properties:
> +Requires either a) or b) below.
> +a) static allocation
> + reg (required) - standard definition
> +b) dynamic allocation
> + size (required) - length based on parent's #size-cells
> + - Size in bytes of memory to reserve.
> + alignment (optional) - length based on parent's #size-cells
> + - Address boundary for alignment of allocation.
> + alloc-ranges (optional) - prop-encoded-array (address, length pairs).
> + - Specifies regions of memory that are
> + acceptable to allocate from.
> +
> +If both reg and size are present, then the reg property takes precedence
> +and size is ignored.
> +
> +Additional properties:
> +compatible (optional) - standard definition
> + - may contain the following strings:
> + - shared-dma-pool: This indicates a region of memory meant to be
> + used as a shared pool of DMA buffers for a set of devices. It can
> + be used by an operating system to instanciate the necessary pool
> + management subsystem if necessary.
> + - vendor specific string in the form <vendor>,[<device>-]<usage>
> +no-map (optional) - empty property
> + - Indicates the operating system must not create a virtual mapping
> + of the region as part of its standard mapping of system memory,
> + nor permit speculative access to it under any circumstances other
> + than under the control of the device driver using the region.
> +reusable (optional) - empty property
> + - The operating system can use the memory in this region with the
> + limitation that the device driver(s) owning the region need to be
> + able to reclaim it back. Typically that means that the operating
> + system can use that region to store volatile or cached data that
> + can be otherwise regenerated or migrated elsewhere.
> +
> +Linux implementation note:
> +- If a "linux,cma-default" property is present, then Linux will use the
> + region for the default pool of the contiguous memory allocator.
> +
> +Device node references to reserved memory
> +-----------------------------------------
> +Regions in the /reserved-memory node may be referenced by other device
> +nodes by adding a memory-region property to the device node.
> +
> +memory-region (optional) - phandle, specifier pairs to children of /reserved-memory
> +
> +Example
> +-------
> +This example defines 3 contiguous regions are defined for Linux kernel:
> +one default of all device drivers (named linux,cma at 72000000 and 64MiB in size),
> +one dedicated to the framebuffer device (named framebuffer at 78000000, 8MiB), and
> +one for multimedia processing (named multimedia-memory at 77000000, 64MiB).
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + memory {
> + reg = <0x40000000 0x40000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* global autoconfigured region for contiguous allocations */
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + #memory-region-cells = <0>;
> + size = <0x4000000>;
> + alignment = <0x2000>;
> + linux,cma-default;
> + };
> +
> + display_reserved: framebuffer at 78000000 {
> + #memory-region-cells = <0>;
> + reg = <0x78000000 0x800000>;
> + };
> +
> + multimedia_reserved: multimedia at 77000000 {
> + compatible = "acme,multimedia-memory";
> + #memory-region-cells = <1>;
> + reg = <0x77000000 0x4000000>;
> + };
> + };
> +
> + /* ... */
> +
> + fb0: video at 12300000 {
> + memory-region = <&display_reserved>;
> + /* ... */
> + };
> +
> + scaler: scaler at 12500000 {
> + memory-region = <&multimedia_reserved 0xdeadbeef>;
> + /* ... */
> + };
> +
> + codec: codec at 12600000 {
> + memory-region = <&multimedia_reserved 0xfeebdaed>;
> + /* ... */
> + };
> +};
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v2 1/2] arm64: vdso: fix coarse clock handling
From: Will Deacon @ 2014-02-05 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391579584-412-1-git-send-email-nathan_lynch@mentor.com>
On Wed, Feb 05, 2014 at 05:53:04AM +0000, Nathan Lynch wrote:
> When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
> CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
> caller has placed in x2 ("ret x2" to return from the fast path). Fix
> this by saving x30/LR to x2 only in code that will call
> __do_get_tspec, restoring x30 afterward, and using a plain "ret" to
> return from the routine.
>
> Also: while the resulting tv_nsec value for CLOCK_REALTIME and
> CLOCK_MONOTONIC must be computed using intermediate values that are
> left-shifted by cs_shift (x12, set by __do_get_tspec), the results for
> coarse clocks should be calculated using unshifted values
> (xtime_coarse_nsec is in units of actual nanoseconds). The current
> code shifts intermediate values by x12 unconditionally, but x12 is
> uninitialized when servicing a coarse clock. Fix this by setting x12
> to 0 once we know we are dealing with a coarse clock id.
>
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
> ---
Thanks for the quick update Nathan!
Acked-by: Will Deacon <will.deacon@arm.com>
Catalin: both of these are candidates for stable.
Will
^ permalink raw reply
* [PATCH] arm64: add DSB after icache flush in __flush_icache_all()
From: Will Deacon @ 2014-02-05 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391592876-18627-1-git-send-email-vkale@apm.com>
On Wed, Feb 05, 2014 at 09:34:36AM +0000, Vinayak Kale wrote:
> Add DSB after icache flush to complete the cache maintenance operation.
> The function __flush_icache_all() is used only for user space mappings
> and an ISB is not required because of an exception return before executing
> user instructions. An exception return would behave like an ISB.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
> ---
> arch/arm64/include/asm/cacheflush.h | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v2 4/5] ARM: init: add support for reserved memory defined by device tree
From: Grant Likely @ 2014-02-05 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-5-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:32 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Enable reserved memory initialization from device tree.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/init.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 804d61566a53..ebafdb479410 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -17,6 +17,7 @@
> #include <linux/nodemask.h>
> #include <linux/initrd.h>
> #include <linux/of_fdt.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/highmem.h>
> #include <linux/gfp.h>
> #include <linux/memblock.h>
> @@ -323,6 +324,8 @@ void __init arm_memblock_init(struct meminfo *mi,
> if (mdesc->reserve)
> mdesc->reserve();
>
> + early_init_dt_scan_reserved_mem();
> +
The new binding is being made fundamental. If the reserved-memory node
is present, then it needs to be honored, even if the kernel doesn't know
how to use the regions. Therefore, This needs to be unconditional for
all architectures. The hook should be called in early_init_dt_scan()
(drivers/of/fdt.c) immediately after the early_init_dt_scan_memory()
hook.
> /*
> * reserve memory for DMA contigouos allocations,
> * must come from DMA area inside low memory
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH v2 7/7] cpufreq: exynos: remove all exynos specific cpufreq driver support
From: Thomas Abraham @ 2014-02-05 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120090815.39e8c21a@amdc2363>
Hi Lukasz,
On Mon, Jan 20, 2014 at 1:38 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Thomas,
>
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Exynos4210, Exynos4x12 and Exynos5250 based platforms have switched
>> over to use cpufreq-cpu0 driver for cpufreq functionality. So the
>> Exynos specific cpufreq drivers for these platforms can be removed.
>>
<snip>
>> -static unsigned int exynos4x12_volt_table[] = {
>> - 1350000, 1287500, 1250000, 1187500, 1137500, 1087500,
>> 1037500,
>> - 1000000, 987500, 975000, 950000, 925000, 900000, 900000
>> -};
>> -
>> -static struct cpufreq_frequency_table exynos4x12_freq_table[] = {
>> - {CPUFREQ_BOOST_FREQ, 1500 * 1000},
>
> Here, you are removing BOOST support for Exynos4412, without any code,
> which brings back this functionality in the new code.
>
> I'd propose adding new property to cpus node and during
> operating-points parsing mark the entry at the cpufreq_frequency_table
> accordingly.
I tried doing this as you suggested with [1] but looks like that will
not go through at this point. The other alternative would be to use
exynos specific cpufreq drivers only if multiplatform config is not
selected or use cpufreq-cpu0 if multiplatform config is selected (but
this is not something I would want to do). With this, there are issues
like clock blocks encapsulated within the opaque clock type cannot be
removed since exynos specific cpufreq drivers need it and hence it is
not really a clean solution. The other option is to drop the support
for boost on exynos4x12 for now and reintroduce that when the OPP
bindings have been finalized. Would that be okay? Any other
suggestions will also be helpful.
Thanks,
Thomas.
>
>> - {L1, 1400 * 1000},
>> - {L2, 1300 * 1000},
>> - {L3, 1200 * 1000},
>> - {L4, 1100 * 1000},
>> - {L5, 1000 * 1000},
>> - {L6, 900 * 1000},
>> - {L7, 800 * 1000},
>> - {L8, 700 * 1000},
>> - {L9, 600 * 1000},
>> - {L10, 500 * 1000},
>> - {L11, 400 * 1000},
>> - {L12, 300 * 1000},
>> - {L13, 200 * 1000},
>> - {0, CPUFREQ_TABLE_END},
>> -};
>> -
>> -static struct apll_freq *apll_freq_4x12;
>> -
>> -static struct apll_freq apll_freq_4212[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> PCLK_DBG, APLL, CORE2
>> - * clock divider for COPY, HPM, RESERVED
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 2, 0, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 2, 0, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 2, 0, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 2, 0, 125, 3, 0),
>> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 150, 4, 0),
>> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 0),
>> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 175, 3, 1),
>> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 200, 4, 1),
>> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 125, 3, 1),
>> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 2, 0, 100, 3, 1),
>> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 2, 0, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 2, 0, 100, 3, 2),
>> -};
>> -
>> -static struct apll_freq apll_freq_4412[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
>> PCLK_DBG, APLL, CORE2
>> - * clock divider for COPY, HPM, CORES
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1500, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 7, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 3, 7, 0, 6, 1, 2, 0, 6, 0, 6, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 6, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 3, 7, 0, 5, 1, 2, 0, 5, 0, 5, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 6, 0, 4, 1, 2, 0, 4, 0, 5, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 2, 5, 0, 4, 1, 1, 0, 4, 0, 4, 125, 3, 0),
>> - APLL_FREQ(900, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 4, 150, 4, 0),
>> - APLL_FREQ(800, 0, 2, 5, 0, 3, 1, 1, 0, 3, 0, 3, 100, 3, 0),
>> - APLL_FREQ(700, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 3, 175, 3, 1),
>> - APLL_FREQ(600, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 200, 4, 1),
>> - APLL_FREQ(500, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 2, 125, 3, 1),
>> - APLL_FREQ(400, 0, 2, 4, 0, 3, 1, 1, 0, 3, 0, 1, 100, 3, 1),
>> - APLL_FREQ(300, 0, 2, 4, 0, 2, 1, 1, 0, 3, 0, 1, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 3, 0, 1, 1, 1, 0, 3, 0, 0, 100, 3, 2),
>> -};
>> -
>> -static void exynos4x12_set_clkdiv(unsigned int div_index)
>> -{
>> - unsigned int tmp;
>> - unsigned int stat_cpu1;
>> -
>> - /* Change Divider - CPU0 */
>> -
>> - tmp = apll_freq_4x12[div_index].clk_div_cpu0;
>> -
>> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU);
>> -
>> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU) & 0x11111111)
>> - cpu_relax();
>> -
>> - /* Change Divider - CPU1 */
>> - tmp = apll_freq_4x12[div_index].clk_div_cpu1;
>> -
>> - __raw_writel(tmp, EXYNOS4_CLKDIV_CPU1);
>> - if (soc_is_exynos4212())
>> - stat_cpu1 = 0x11;
>> - else
>> - stat_cpu1 = 0x111;
>> -
>> - while (__raw_readl(EXYNOS4_CLKDIV_STATCPU1) & stat_cpu1)
>> - cpu_relax();
>> -}
>> -
>> -static void exynos4x12_set_apll(unsigned int index)
>> -{
>> - unsigned int tmp, freq = apll_freq_4x12[index].freq;
>> -
>> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
>> - clk_set_parent(moutcore, mout_mpll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = (__raw_readl(EXYNOS4_CLKMUX_STATCPU)
>> - >> EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT);
>> - tmp &= 0x7;
>> - } while (tmp != 0x2);
>> -
>> - clk_set_rate(mout_apll, freq * 1000);
>> -
>> - /* MUX_CORE_SEL = APLL */
>> - clk_set_parent(moutcore, mout_apll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = __raw_readl(EXYNOS4_CLKMUX_STATCPU);
>> - tmp &= EXYNOS4_CLKMUX_STATCPU_MUXCORE_MASK;
>> - } while (tmp != (0x1 << EXYNOS4_CLKSRC_CPU_MUXCORE_SHIFT));
>> -}
>> -
>> -static void exynos4x12_set_frequency(unsigned int old_index,
>> - unsigned int new_index)
>> -{
>> - if (old_index > new_index) {
>> - exynos4x12_set_clkdiv(new_index);
>> - exynos4x12_set_apll(new_index);
>> - } else if (old_index < new_index) {
>> - exynos4x12_set_apll(new_index);
>> - exynos4x12_set_clkdiv(new_index);
>> - }
>> -}
>> -
>> -int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
>> -{
>> - unsigned long rate;
>> -
>> - cpu_clk = clk_get(NULL, "armclk");
>> - if (IS_ERR(cpu_clk))
>> - return PTR_ERR(cpu_clk);
>> -
>> - moutcore = clk_get(NULL, "moutcore");
>> - if (IS_ERR(moutcore))
>> - goto err_moutcore;
>> -
>> - mout_mpll = clk_get(NULL, "mout_mpll");
>> - if (IS_ERR(mout_mpll))
>> - goto err_mout_mpll;
>> -
>> - rate = clk_get_rate(mout_mpll) / 1000;
>> -
>> - mout_apll = clk_get(NULL, "mout_apll");
>> - if (IS_ERR(mout_apll))
>> - goto err_mout_apll;
>> -
>> - if (soc_is_exynos4212())
>> - apll_freq_4x12 = apll_freq_4212;
>> - else
>> - apll_freq_4x12 = apll_freq_4412;
>> -
>> - info->mpll_freq_khz = rate;
>> - /* 800Mhz */
>> - info->pll_safe_idx = L7;
>> - info->cpu_clk = cpu_clk;
>> - info->volt_table = exynos4x12_volt_table;
>> - info->freq_table = exynos4x12_freq_table;
>> - info->set_freq = exynos4x12_set_frequency;
>> -
>> - return 0;
>> -
>> -err_mout_apll:
>> - clk_put(mout_mpll);
>> -err_mout_mpll:
>> - clk_put(moutcore);
>> -err_moutcore:
>> - clk_put(cpu_clk);
>> -
>> - pr_debug("%s: failed initialization\n", __func__);
>> - return -EINVAL;
>> -}
>> diff --git a/drivers/cpufreq/exynos5250-cpufreq.c
>> b/drivers/cpufreq/exynos5250-cpufreq.c deleted file mode 100644
>> index 5f90b82..0000000
>> --- a/drivers/cpufreq/exynos5250-cpufreq.c
>> +++ /dev/null
>> @@ -1,183 +0,0 @@
>> -/*
>> - * Copyright (c) 2010-20122Samsung Electronics Co., Ltd.
>> - * http://www.samsung.com
>> - *
>> - * EXYNOS5250 - CPU frequency scaling support
>> - *
>> - * This program is free software; you can redistribute it and/or
>> modify
>> - * it under the terms of the GNU General Public License version 2 as
>> - * published by the Free Software Foundation.
>> -*/
>> -
>> -#include <linux/module.h>
>> -#include <linux/kernel.h>
>> -#include <linux/err.h>
>> -#include <linux/clk.h>
>> -#include <linux/io.h>
>> -#include <linux/slab.h>
>> -#include <linux/cpufreq.h>
>> -
>> -#include <mach/map.h>
>> -
>> -#include "exynos-cpufreq.h"
>> -
>> -static struct clk *cpu_clk;
>> -static struct clk *moutcore;
>> -static struct clk *mout_mpll;
>> -static struct clk *mout_apll;
>> -
>> -static unsigned int exynos5250_volt_table[] = {
>> - 1300000, 1250000, 1225000, 1200000, 1150000,
>> - 1125000, 1100000, 1075000, 1050000, 1025000,
>> - 1012500, 1000000, 975000, 950000, 937500,
>> - 925000
>> -};
>> -
>> -static struct cpufreq_frequency_table exynos5250_freq_table[] = {
>> - {L0, 1700 * 1000},
>> - {L1, 1600 * 1000},
>> - {L2, 1500 * 1000},
>> - {L3, 1400 * 1000},
>> - {L4, 1300 * 1000},
>> - {L5, 1200 * 1000},
>> - {L6, 1100 * 1000},
>> - {L7, 1000 * 1000},
>> - {L8, 900 * 1000},
>> - {L9, 800 * 1000},
>> - {L10, 700 * 1000},
>> - {L11, 600 * 1000},
>> - {L12, 500 * 1000},
>> - {L13, 400 * 1000},
>> - {L14, 300 * 1000},
>> - {L15, 200 * 1000},
>> - {0, CPUFREQ_TABLE_END},
>> -};
>> -
>> -static struct apll_freq apll_freq_5250[] = {
>> - /*
>> - * values:
>> - * freq
>> - * clock divider for ARM, CPUD, ACP, PERIPH, ATB, PCLK_DBG,
>> APLL, ARM2
>> - * clock divider for COPY, HPM, RESERVED
>> - * PLL M, P, S
>> - */
>> - APLL_FREQ(1700, 0, 3, 7, 7, 7, 3, 5, 0, 0, 2, 0, 425, 6, 0),
>> - APLL_FREQ(1600, 0, 3, 7, 7, 7, 1, 4, 0, 0, 2, 0, 200, 3, 0),
>> - APLL_FREQ(1500, 0, 2, 7, 7, 7, 1, 4, 0, 0, 2, 0, 250, 4, 0),
>> - APLL_FREQ(1400, 0, 2, 7, 7, 6, 1, 4, 0, 0, 2, 0, 175, 3, 0),
>> - APLL_FREQ(1300, 0, 2, 7, 7, 6, 1, 3, 0, 0, 2, 0, 325, 6, 0),
>> - APLL_FREQ(1200, 0, 2, 7, 7, 5, 1, 3, 0, 0, 2, 0, 200, 4, 0),
>> - APLL_FREQ(1100, 0, 3, 7, 7, 5, 1, 3, 0, 0, 2, 0, 275, 6, 0),
>> - APLL_FREQ(1000, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 125, 3, 0),
>> - APLL_FREQ(900, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 150, 4, 0),
>> - APLL_FREQ(800, 0, 1, 7, 7, 4, 1, 2, 0, 0, 2, 0, 100, 3, 0),
>> - APLL_FREQ(700, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 175, 3, 1),
>> - APLL_FREQ(600, 0, 1, 7, 7, 3, 1, 1, 0, 0, 2, 0, 200, 4, 1),
>> - APLL_FREQ(500, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 125, 3, 1),
>> - APLL_FREQ(400, 0, 1, 7, 7, 2, 1, 1, 0, 0, 2, 0, 100, 3, 1),
>> - APLL_FREQ(300, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 200, 4, 2),
>> - APLL_FREQ(200, 0, 1, 7, 7, 1, 1, 1, 0, 0, 2, 0, 100, 3, 2),
>> -};
>> -
>> -static void set_clkdiv(unsigned int div_index)
>> -{
>> - unsigned int tmp;
>> -
>> - /* Change Divider - CPU0 */
>> -
>> - tmp = apll_freq_5250[div_index].clk_div_cpu0;
>> -
>> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU0);
>> -
>> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU0) & 0x11111111)
>> - cpu_relax();
>> -
>> - /* Change Divider - CPU1 */
>> - tmp = apll_freq_5250[div_index].clk_div_cpu1;
>> -
>> - __raw_writel(tmp, EXYNOS5_CLKDIV_CPU1);
>> -
>> - while (__raw_readl(EXYNOS5_CLKDIV_STATCPU1) & 0x11)
>> - cpu_relax();
>> -}
>> -
>> -static void set_apll(unsigned int index)
>> -{
>> - unsigned int tmp;
>> - unsigned int freq = apll_freq_5250[index].freq;
>> -
>> - /* MUX_CORE_SEL = MPLL, ARMCLK uses MPLL for lock time */
>> - clk_set_parent(moutcore, mout_mpll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = (__raw_readl(EXYNOS5_CLKMUX_STATCPU) >> 16);
>> - tmp &= 0x7;
>> - } while (tmp != 0x2);
>> -
>> - clk_set_rate(mout_apll, freq * 1000);
>> -
>> - /* MUX_CORE_SEL = APLL */
>> - clk_set_parent(moutcore, mout_apll);
>> -
>> - do {
>> - cpu_relax();
>> - tmp = __raw_readl(EXYNOS5_CLKMUX_STATCPU);
>> - tmp &= (0x7 << 16);
>> - } while (tmp != (0x1 << 16));
>> -}
>> -
>> -static void exynos5250_set_frequency(unsigned int old_index,
>> - unsigned int new_index)
>> -{
>> - if (old_index > new_index) {
>> - set_clkdiv(new_index);
>> - set_apll(new_index);
>> - } else if (old_index < new_index) {
>> - set_apll(new_index);
>> - set_clkdiv(new_index);
>> - }
>> -}
>> -
>> -int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
>> -{
>> - unsigned long rate;
>> -
>> - cpu_clk = clk_get(NULL, "armclk");
>> - if (IS_ERR(cpu_clk))
>> - return PTR_ERR(cpu_clk);
>> -
>> - moutcore = clk_get(NULL, "mout_cpu");
>> - if (IS_ERR(moutcore))
>> - goto err_moutcore;
>> -
>> - mout_mpll = clk_get(NULL, "mout_mpll");
>> - if (IS_ERR(mout_mpll))
>> - goto err_mout_mpll;
>> -
>> - rate = clk_get_rate(mout_mpll) / 1000;
>> -
>> - mout_apll = clk_get(NULL, "mout_apll");
>> - if (IS_ERR(mout_apll))
>> - goto err_mout_apll;
>> -
>> - info->mpll_freq_khz = rate;
>> - /* 800Mhz */
>> - info->pll_safe_idx = L9;
>> - info->cpu_clk = cpu_clk;
>> - info->volt_table = exynos5250_volt_table;
>> - info->freq_table = exynos5250_freq_table;
>> - info->set_freq = exynos5250_set_frequency;
>> -
>> - return 0;
>> -
>> -err_mout_apll:
>> - clk_put(mout_mpll);
>> -err_mout_mpll:
>> - clk_put(moutcore);
>> -err_moutcore:
>> - clk_put(cpu_clk);
>> -
>> - pr_err("%s: failed initialization\n", __func__);
>> - return -EINVAL;
>> -}
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
From: Jim Lin @ 2014-02-05 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203141529.GF19389@tbergstrom-lnx.Nvidia.com>
Please ignore my comment.
I will try to use exported tegra_fuse_readl().
-----Original Message-----
From: Peter De Schrijver [mailto:pdeschrijver at nvidia.com]
Sent: Monday, February 03, 2014 10:15 PM
To: Jim Lin
Cc: linux-arm-kernel at lists.infradead.org; linux-tegra at vger.kernel.org; linux-kernel at vger.kernel.org; Rob Landley; Stephen Warren; Thierry Reding; Grant Likely; Rob Herring; Danny Huang; linux-doc at vger.kernel.org; devicetree at vger.kernel.org
Subject: Re: [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
On Wed, Jan 29, 2014 at 03:26:18AM +0100, Jim Lin wrote:
> On Wed, 2014-01-29 at 07:36 +0800, Peter De Schrijver wrote:
> > Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
> >
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > ---
> > Documentation/ABI/testing/sysfs-driver-tegra-fuse | 8 +
> > drivers/misc/fuse/Makefile | 1 +
> > drivers/misc/fuse/tegra/Makefile | 7 +
> > drivers/misc/fuse/tegra/fuse-tegra.c | 228 ++++++++++++++++
> > drivers/misc/fuse/tegra/fuse-tegra20.c | 136 ++++++++++
> > drivers/misc/fuse/tegra/fuse-tegra30.c | 178 +++++++++++++
> > drivers/misc/fuse/tegra/fuse.h | 82 ++++++
> Could we move this fuse.h to other folder under /include/linux (like
> /include/linux/platform_data) for other driver to include?
I don't think we should expose everything in fuse.h to the world.
> So other driver can invoke function to read fuse data if needed.
Which functionality do you want? Just reading the fuse data exposed in the sysfs file from a driver? exporting tegra_fuse_readl() should do that I think?
Cheers,
Peter.
--nvpublic
^ permalink raw reply
* [PATCH] arm64: add DSB after icache flush in __flush_icache_all()
From: Catalin Marinas @ 2014-02-05 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391592876-18627-1-git-send-email-vkale@apm.com>
On Wed, Feb 05, 2014 at 09:34:36AM +0000, Vinayak Kale wrote:
> Add DSB after icache flush to complete the cache maintenance operation.
> The function __flush_icache_all() is used only for user space mappings
> and an ISB is not required because of an exception return before executing
> user instructions. An exception return would behave like an ISB.
>
> Signed-off-by: Vinayak Kale <vkale@apm.com>
Thanks. Applied.
--
Catalin
^ permalink raw reply
* [PATCH 3/4] ARM: dts: Add support of STid127 Soc.
From: Patrice Chotard @ 2014-02-05 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EB9C03.70009@st.com>
Hi Srinivas
Thanks for reviewing, a V2 serie will be pushed with all required fixes.
Patrice
On 01/31/2014 01:50 PM, srinivas kandagatla wrote:
> Hi Patrice,
>
> On 30/01/14 14:55, Patrice CHOTARD wrote:
>> From: Alexandre TORGUE <alexandre.torgue@st.com>
>>
>> The STid127 integrates all harware components to function as a cable modem
> s/harware/hardware/
>
> s/STid127/STiD127
>
> Please fix other instances too.
>
>> or, in combination with a back end device, as a Gateway set top boxe.
> s/boxe/box/
>> Supported devices:
>> -UART0
>> -UART2
>>
>> Signed-off-by: alexandre torgue <alexandre.torgue@st.com>
>> ---
>> arch/arm/boot/dts/stid127-clock.dtsi | 31 ++++
>> arch/arm/boot/dts/stid127-pinctrl.dtsi | 245 ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/stid127.dtsi | 130 +++++++++++++++++
>> 3 files changed, 406 insertions(+)
>> create mode 100644 arch/arm/boot/dts/stid127-clock.dtsi
>> create mode 100644 arch/arm/boot/dts/stid127-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/stid127.dtsi
>>
>> diff --git a/arch/arm/boot/dts/stid127-clock.dtsi b/arch/arm/boot/dts/stid127-clock.dtsi
>> new file mode 100644
>> index 0000000..c6cafa9
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stid127-clock.dtsi
>> @@ -0,0 +1,31 @@
>> +/*
>> + * Copyright (C) 2013 STMicroelectronics (R&D) Limited
> 2014
>
>> + * Author(s): Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> + * Alexandre Torgue <alexandre.torgue@st.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +/ {Acked-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>> + clocks {
>> + /*
>> + * ARM Peripheral clock for timers
>> + */
>> + arm_periph_clk: arm_periph_clk {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <100000000>;
>> + };
>> + /*
>> + * Bootloader initialized system infrastructure clock for
>> + * serial devices.
>> + */
>> + CLK_IC_LP_HD: clockgenA0 at 29 {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <100000000>;
>> + clock-output-names = "CLK_IC_LP_HD";
>> + };
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/stid127-pinctrl.dtsi b/arch/arm/boot/dts/stid127-pinctrl.dtsi
>> new file mode 100644
>> index 0000000..3fa66f3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stid127-pinctrl.dtsi
>> @@ -0,0 +1,245 @@
>> +/*
>> + * Copyright (C) 2012 STMicroelectronics Limited.
> 2014
>
>> + * Author(s): Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> + * Alexandre Torgue <alexandre.torgue@st.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * publishhed by the Free Software Foundation.
> s/publishhed/published/
>
>> + */
>> +#include "st-pincfg.h"
>> +/ {
>> + aliases {
>> + gpio0 = &PIO0;
>> + gpio1 = &PIO1;
>> + gpio2 = &PIO2;
>> + gpio3 = &PIO3;
>> + gpio4 = &PIO4;
>> + gpio5 = &PIO5;
>> + gpio6 = &PIO6;
>> + gpio7 = &PIO7;
>> + gpio8 = &PIO8;
>> + gpio9 = &PIO9;
>> + gpio10 = &PIO10;
>> + gpio11 = &PIO11;
>> + gpio12 = &PIO12;
>> + gpio13 = &PIO13;
>> + gpio14 = &PIO14;
>> + gpio15 = &PIO15;
>> + gpio16 = &PIO16;
>> + gpio17 = &PIO17;
>> + gpio18 = &PIO18;
>> + gpio19 = &PIO19;
>> + gpio20 = &PIO20;
>> + gpio21 = &PIO21;
>> + gpio22 = &PIO22;
>> +
>> + };
>> +
>> + soc {
>> + pin-controller-pwest {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "st,stid127-pwest-pinctrl";
>> + st,syscfg = <&syscfg_pwest>;
>> + ranges = <0 0xfebe0000 0x8000>;
> Can you add interrupt controller support to the pin controller.
>
> Patches are in : https://lkml.org/lkml/2014/1/16/342
> All these patches are due to be in v3.15.
>
>> +
>> + PIO0: gpio at febe0000 {
>> + gpio-controller;
>> + #gpio-cells = <1>;
>> + reg = <0 0x100>;
>> + interrupts = <0 149 0>;
>> + st,bank-name = "PIO0";
>> + };
>> + rx = <&PIO3 0 ALT2 IN>;
>> + };
>> + };
>> + };
>> +
>> + };
> unnecessary empty line here.
>
>> diff --git a/arch/arm/boot/dts/stid127.dtsi b/arch/arm/boot/dts/stid127.dtsi
>> new file mode 100644
>> index 0000000..a6f0b8fe
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stid127.dtsi
>> @@ -0,0 +1,130 @@
>> +/*
>> + * Copyright (C) 2013 STMicroelectronics Limited.
> 2014
>> + * Author(s): Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> + * Alexandre Torgue <alexandre.torgue@st.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * publishhed by the Free Software Foundation.
> s/publishhed/published/
>
>> + */
>> +#include "stid127-pinctrl.dtsi"
>> +#include "stid127-clock.dtsi"
>> +/ {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <0>;
>> + };
>> + cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <1>;
>> + };
>> + };
>> +
>> + intc: interrupt-controller at fffe1000 {
>> + compatible = "arm,cortex-a9-gic";
>> + #interrupt-cells = <3>;
>> + interrupt-controller;
>> + reg = <0xfffe1000 0x1000>,
>> + <0xfffe0100 0x100>;
>> + };
>> +
>> + scu at fffe0000 {
>> + compatible = "arm,cortex-a9-scu";
>> + reg = <0xfffe0000 0x1000>;
>> + };
>> +
>> + timer at fffe0200 {
>> + interrupt-parent = <&intc>;
>> + compatible = "arm,cortex-a9-global-timer";
>> + reg = <0xfffe0200 0x100>;
>> + interrupts = <1 11 0x04>;
>> + clocks = <&arm_periph_clk>;
> Fix the tab spacing here.
>
> Thanks,
> srini
^ permalink raw reply
* [PATCHv2] arm64: Align CMA sizes to PAGE_SIZE
From: Catalin Marinas @ 2014-02-05 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391555337-25380-1-git-send-email-lauraa@codeaurora.org>
On Tue, Feb 04, 2014 at 11:08:57PM +0000, Laura Abbott wrote:
> dma_alloc_from_contiguous takes number of pages for a size.
> Align up the dma size passed in to page size to avoid truncation
> and allocation failures on sizes less than PAGE_SIZE.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Thanks. Applied.
--
Catalin
^ permalink raw reply
* [PATCH 0/2] clk: shmobile rcar-gen2 fixes
From: Laurent Pinchart @ 2014-02-05 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1591253.8BzYfubhGS@avalon>
Mike,
Ping ?
v3.14-rc1 is out, and those are bug fixes.
On Wednesday 08 January 2014 00:06:39 Laurent Pinchart wrote:
> On Tuesday 07 January 2014 17:59:01 Geert Uytterhoeven wrote:
> > On Tue, Jan 7, 2014 at 5:47 PM, Laurent Pinchart wrote:
> > > Geert, could you please verify that the series fixes your QSPI clock
> > > issues with the Koelsch board ?
> > >
> > > Laurent Pinchart (2):
> > > clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
> > > clk: shmobile: rcar-gen2: Fix qspi divisor
> >
> > Thanks, both:
> >
> > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Thank you.
>
> Mike, could you please pick those patches up for v3.14 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Maxime Ripard @ 2014-02-05 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v659T_QTLChB0NRS0seQvwDBCmTAH6UBEghZng9Ac6uL4g@mail.gmail.com>
On Wed, Feb 05, 2014 at 12:43:18PM +0800, Chen-Yu Tsai wrote:
> On Tue, Feb 4, 2014 at 3:38 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Mon, Feb 03, 2014 at 11:32:26AM +0800, Chen-Yu Tsai wrote:
> >> U-Boot will insert MAC address into the device tree image.
> >> It looks up ethernet[0-5] aliases to find the ethernet nodes.
> >> Alias GMAC as ethernet0, as it is the only ethernet controller used.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> index 65fb8d0..c48fb11 100644
> >> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> >> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> @@ -17,7 +17,7 @@
> >> interrupt-parent = <&gic>;
> >>
> >> aliases {
> >> - ethernet0 = &emac;
> >> + ethernet0 = &gmac;
> >> };
> >
> > I'm not very fond of this patch.
> >
> > People might rely on the fact that ethernet0 is actually the emac, and
> > are expecting u-boot to fill the ethaddr variable to the emac, and not
> > the gmac.
> >
> > Since u-boot is totally able to deal with several ethernet addresses,
> > please add it as ethernet1.
>
> Actually I think we should override this in the board dts.
> The boards we currently support can only use emac or gmac,
> and in our u-boot tree, they have been converted to using
> gmac. If any future boards support both emac and gmac, we
> can address the ordering then. And the ordering should
> match u-boot.
>
> What do you think?
That what u-boot does is not a good argument (especially when it's not
even mainline u-boot we're talking about). Otherwise, I can just cook
up a bootloader of my own, do crazy stuff in it, and use that as an
argument to get crazy things in the kernel.
And you can set eth1addr just fine in u-boot.
But thinking a bit more about your patch, I guess that this patch
makes some kind of sense anyway..
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140205/c90dca1e/attachment-0001.sig>
^ permalink raw reply
* [Linux-kernel] [PATCH 2/3] ARM: shmobile: r8a7790: specify multiple parents for cpg_clks
From: Laurent Pinchart @ 2014-02-05 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F20133.6080107@codethink.co.uk>
Hi Ben,
On Wednesday 05 February 2014 09:15:31 Ben Dooks wrote:
> On 04/02/14 18:17, William Towle wrote:
> > The current drivers/clk/shmobile/clk-rcar-gen2.c uses the
> > extal_clk reference for the parent of all the clocks that
> > it registers. However the lb, qspi, sdh, sd0 and sd1 clocks
> > are all parented to either pll1 or pll1_div2 which means
> > that the clock rates are incorrect.
> >
> > This is part of the fix that corrects the SDHI0 clock
> >
> > rate error where it reports 1MHz instead of 97.5:
> > sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
> >
> > Notes:
> > - May require cross-merge with clk-rcar-gen2.c fix
> > - Also not clear which clock "z" is to fix it.
>
> Laurent, if you could give us an idea of how to fix this then
> it would be helpful to get this patch fully fixed.
I've already sent a patch that fixes this issue.
"clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks"
(http://www.spinics.net/lists/linux-sh/msg27275.html)
I've just pinged Mike to ask him to pick it up for v3.14.
> > [ben.dooks at codethink.co.uk: updated patch description]
> > Signed-off-by: William Towle <william.towle@codethink.co.uk>
> > Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
> > ---
> >
> > arch/arm/boot/dts/r8a7790.dtsi | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/r8a7790.dtsi
> > b/arch/arm/boot/dts/r8a7790.dtsi index ff55c6e..242e6e2 100644
> > --- a/arch/arm/boot/dts/r8a7790.dtsi
> > +++ b/arch/arm/boot/dts/r8a7790.dtsi
> > @@ -446,7 +446,13 @@
> >
> > compatible = "renesas,r8a7790-cpg-clocks",
> >
> > "renesas,rcar-gen2-cpg-clocks";
> >
> > reg = <0 0xe6150000 0 0x1000>;
> >
> > - clocks = <&extal_clk>;
> > + clocks = <&extal_clk>, <&extal_clk>, <&extal_clk>,
<&extal_clk>,
> > + <&cpg_clocks R8A7790_CLK_PLL1>,
> > + <&pll1_div2_clk>,
> > + <&cpg_clocks R8A7790_CLK_PLL1>,
> > + <&cpg_clocks R8A7790_CLK_PLL1>,
> > + <&cpg_clocks R8A7790_CLK_PLL1>
>
> Should we add a pll1_clk node, or leave this as is?
>
> > + /* not known for "z" ...,<> */;
> >
> > #clock-cells = <1>;
> > clock-output-names = "main", "pll0", "pll1", "pll3",
> >
> > "lb", "qspi", "sdh", "sd0", "sd1",
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/2] clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
From: Ben Dooks @ 2014-02-05 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389113273-10364-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On 07/01/14 16:47, Laurent Pinchart wrote:
> The lb, qspi, sdh, sd0 and sd1 clocks have the PLL1 (divided by 2) as
> their parent, not the main clock. Fix it.
William Towle has already sent a patch to move this to device tree
which I think is a better solution for this. Any chance of commenting
on which to take please.
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/clk/shmobile/clk-rcar-gen2.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c b/drivers/clk/shmobile/clk-rcar-gen2.c
> index a59ec21..8c7bcbd 100644
> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
> @@ -186,7 +186,7 @@ rcar_gen2_cpg_register_clock(struct device_node *np, struct rcar_gen2_cpg *cpg,
> const char *name)
> {
> const struct clk_div_table *table = NULL;
> - const char *parent_name = "main";
> + const char *parent_name;
> unsigned int shift;
> unsigned int mult = 1;
> unsigned int div = 1;
> @@ -201,23 +201,31 @@ rcar_gen2_cpg_register_clock(struct device_node *np, struct rcar_gen2_cpg *cpg,
> * the multiplier value.
> */
> u32 value = clk_readl(cpg->reg + CPG_PLL0CR);
> + parent_name = "main";
> mult = ((value >> 24) & ((1 << 7) - 1)) + 1;
> } else if (!strcmp(name, "pll1")) {
> + parent_name = "main";
> mult = config->pll1_mult / 2;
> } else if (!strcmp(name, "pll3")) {
> + parent_name = "main";
> mult = config->pll3_mult;
> } else if (!strcmp(name, "lb")) {
> + parent_name = "pll1_div2";
> div = cpg_mode & BIT(18) ? 36 : 24;
> } else if (!strcmp(name, "qspi")) {
> + parent_name = "pll1_div2";
> div = (cpg_mode & (BIT(3) | BIT(2) | BIT(1))) == BIT(2)
> ? 16 : 20;
> } else if (!strcmp(name, "sdh")) {
> + parent_name = "pll1_div2";
> table = cpg_sdh_div_table;
> shift = 8;
> } else if (!strcmp(name, "sd0")) {
> + parent_name = "pll1_div2";
> table = cpg_sd01_div_table;
> shift = 4;
> } else if (!strcmp(name, "sd1")) {
> + parent_name = "pll1_div2";
> table = cpg_sd01_div_table;
> shift = 0;
> } else if (!strcmp(name, "z")) {
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [Linux-kernel] [PATCH 2/3] ARM: shmobile: r8a7790: specify multiple parents for cpg_clks
From: Ben Dooks @ 2014-02-05 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1565445.R9bPDKl3Py@avalon>
On 05/02/14 10:32, Laurent Pinchart wrote:
> Hi Ben,
>
> On Wednesday 05 February 2014 09:15:31 Ben Dooks wrote:
>> On 04/02/14 18:17, William Towle wrote:
>>> The current drivers/clk/shmobile/clk-rcar-gen2.c uses the
>>> extal_clk reference for the parent of all the clocks that
>>> it registers. However the lb, qspi, sdh, sd0 and sd1 clocks
>>> are all parented to either pll1 or pll1_div2 which means
>>> that the clock rates are incorrect.
>>>
>>> This is part of the fix that corrects the SDHI0 clock
>>>
>>> rate error where it reports 1MHz instead of 97.5:
>>> sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
>>>
>>> Notes:
>>> - May require cross-merge with clk-rcar-gen2.c fix
>>> - Also not clear which clock "z" is to fix it.
>>
>> Laurent, if you could give us an idea of how to fix this then
>> it would be helpful to get this patch fully fixed.
>
> I've already sent a patch that fixes this issue.
>
> "clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks"
>
> (http://www.spinics.net/lists/linux-sh/msg27275.html)
>
> I've just pinged Mike to ask him to pick it up for v3.14.
I just saw and commented on it. I think the DT is the nicer way
of actually doing this, especially if the driver may get re-used
in future.
There's also an issue with SDHI0/1 divider table which has been
posted too.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* [PATCH v2 0/6] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: Maxime Ripard @ 2014-02-05 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204191648.29809.14611.stgit@dizzy-6.o2s.ch>
Hi David,
On Tue, Feb 04, 2014 at 08:24:13PM +0100, David Lanzend?rfer wrote:
> Hello
> The following patchset adds support for the SD/MMC host found in the Allwinner SoCs.
> It contains all the necessary modifications for clock environment and also the device
> tree script modification which add it to all the boards using it.
> The clock environment function needed for phase offset configuration has
> been proposed and implemented by Emilio.
> This patchset is the second attempt to send this driver upstream.
> I'm looking forward to the acceptance of this patchset into mainline.
I have four comments here:
- Read Documentation/SubmittingPatches, especially Section 5 and 12
(hints, you forgot the clock maintainers for your clock patches
and you didn't put any signed-off-by tags)
- You ignored pretty much all the comments that were made during the
review of the first version. Go through
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219339.html
and address the comments that were made.
- Each of your patches should compile. Fix the order of your
patches.
- Submit a v3, with the changes you made. Otherwise we have no way
of knowing what have been fixed and what didn't
Looking forward for the next iteration!
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140205/739e5515/attachment.sig>
^ permalink raw reply
* [PATCH 11/18] extcon: max14577: Add max14577 prefix to muic_irqs
From: Krzysztof Kozlowski @ 2014-02-05 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F18A08.6070409@samsung.com>
On Wed, 2014-02-05 at 09:47 +0900, Chanwoo Choi wrote:
> Hi Krzysztof,
>
> Following patch has conflict on extcon-next branch(Linus 3.14-rc1)
> when apply patchset by using git am.
>
> [PATCH 11/18] extcon: max14577: Add max14577 prefix to muic_irqs
> [PATCH 12/18] extcon: max14577: Choose muic_irqs according to device type
> [PATCH 14/18] extcon: max14577: Add support for max77836
>
> The base commit of this patchset isn't mainline. You need to rebase this patchset
> on extcon-next branch and please resend this patchset.
>
> Thanks,
> Chanwoo Choi
Hi,
This patch patch (along with other) depends on previous rename patches
from this patchset:
[PATCH 07/18] mfd: max14577: Rename and add MAX14577 symbols to prepare
for max77836
http://article.gmane.org/gmane.linux.kernel/1636674
I can resolve the conflict but then they will return on applying patch
7/18.
I think this patch may wait for a little until the rename-like patches
will be accepted.
Can you ACK other patches touch extcon?
- [PATCH 07/18] mfd: max14577: Rename and add MAX14577 symbols...
- [PATCH 08/18] mfd: max14577: Rename state container to maxim_core
- [PATCH 09/18] mfd: max14577: Add "muic" suffix to regmap and irq_chip
Best regards,
Krzysztof
> On 01/28/2014 09:18 PM, Krzysztof Kozlowski wrote:
> > Add max14577 prefix to muic_irqs array. This prepares for max77836
> > support in this extcon driver.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/extcon/extcon-max14577.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
> > index fd48b4909470..fb343f4042d2 100644
> > --- a/drivers/extcon/extcon-max14577.c
> > +++ b/drivers/extcon/extcon-max14577.c
> > @@ -85,7 +85,7 @@ struct max14577_muic_irq {
> > unsigned int virq;
> > };
> >
> > -static struct max14577_muic_irq muic_irqs[] = {
> > +static struct max14577_muic_irq max14577_muic_irqs[] = {
> > { MAXIM_IRQ_INT1_ADC, "muic-ADC" },
> > { MAXIM_IRQ_INT1_ADCLOW, "muic-ADCLOW" },
> > { MAXIM_IRQ_INT1_ADCERR, "muic-ADCError" },
> > @@ -541,9 +541,9 @@ static irqreturn_t max14577_muic_irq_handler(int irq, void *data)
> > * However we only need to know whether it was ADC, charger
> > * or both interrupts so decode IRQ and turn on proper flags.
> > */
> > - for (i = 0; i < ARRAY_SIZE(muic_irqs); i++)
> > - if (irq == muic_irqs[i].virq)
> > - irq_type = muic_irqs[i].irq;
> > + for (i = 0; i < ARRAY_SIZE(max14577_muic_irqs); i++)
> > + if (irq == max14577_muic_irqs[i].virq)
> > + irq_type = max14577_muic_irqs[i].irq;
> >
> > switch (irq_type) {
> > case MAXIM_IRQ_INT1_ADC:
> > @@ -647,8 +647,8 @@ static int max14577_muic_probe(struct platform_device *pdev)
> > INIT_WORK(&info->irq_work, max14577_muic_irq_work);
> >
> > /* Support irq domain for max14577 MUIC device */
> > - for (i = 0; i < ARRAY_SIZE(muic_irqs); i++) {
> > - struct max14577_muic_irq *muic_irq = &muic_irqs[i];
> > + for (i = 0; i < ARRAY_SIZE(max14577_muic_irqs); i++) {
> > + struct max14577_muic_irq *muic_irq = &max14577_muic_irqs[i];
> > unsigned int virq = 0;
> >
> > virq = regmap_irq_get_virq(maxim_core->irq_data_muic,
> >
^ permalink raw reply
* [PATCH 05/18] mfd: max14577: Use of_match_ptr() in i2c_driver
From: Krzysztof Kozlowski @ 2014-02-05 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203093013.GG13529@lee--X1>
On Mon, 2014-02-03 at 09:30 +0000, Lee Jones wrote:
> > Use of_match_ptr() in assignment of i2c_driver.of_match_table.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/mfd/max14577.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> > index 2ac2f2d7cea6..75b37082a3fe 100644
> > --- a/drivers/mfd/max14577.c
> > +++ b/drivers/mfd/max14577.c
> > @@ -224,7 +224,7 @@ static struct i2c_driver max14577_i2c_driver = {
> > .name = "max14577",
> > .owner = THIS_MODULE,
> > .pm = &max14577_pm,
> > - .of_match_table = max14577_dt_match,
> > + .of_match_table = of_match_ptr(max14577_dt_match),
>
> Are you sure this is required?
No, it was my mistake. Please ignore this patch.
Krzysztof
^ permalink raw reply
* [PATCH 07/18] mfd: max14577: Rename and add MAX14577 symbols to prepare for max77836
From: Krzysztof Kozlowski @ 2014-02-05 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203093809.GH13529@lee--X1>
Thanks for ACK.
Dear Chanwoo, Mark and Dmitry, can you ACK this patch and also 8/18 and
9/18:
http://thread.gmane.org/gmane.linux.kernel/1636654/focus=1636674
http://thread.gmane.org/gmane.linux.kernel/1636654/focus=1636674
?
Best regards,
Krzysztof
On Mon, 2014-02-03 at 09:38 +0000, Lee Jones wrote:
> > This patch prepares for adding support for max77836 device to existing
> > max14577 driver:
> > 1. Renames most of symbols and defines prefixed with MAX14577 to MAXIM.
> > 2. Adds prefixes (MAXIM or MAX14577) to defines without any MAX* prefix.
> >
> > This is only a rename-like patch, new code is not added.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/extcon/extcon-max14577.c | 105 ++++-----
> > drivers/mfd/max14577.c | 51 ++---
> > drivers/power/max14577_charger.c | 81 +++----
> > drivers/regulator/max14577.c | 44 ++--
> > include/linux/mfd/max14577-private.h | 399 ++++++++++++++++------------------
> > include/linux/mfd/max14577.h | 2 +-
> > 6 files changed, 333 insertions(+), 349 deletions(-)
>
> I think the name changes instil some clarity here.
>
> I still need the other Acks before applying the patch though.
>
> For now you can have my:
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
^ permalink raw reply
* [PATCH 09/18] mfd: max14577: Add "muic" suffix to regmap and irq_chip
From: Krzysztof Kozlowski @ 2014-02-05 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203094518.GJ13529@lee--X1>
+Cc: Chanwoo, Mark and Dmitry for ACK-s on their subsystems.
Krzysztof Kozlowski
On Mon, 2014-02-03 at 09:45 +0000, Lee Jones wrote:
> > This patch continues the preparation for adding support for max77836
> > device to existing max14577 driver.
> >
> > Add "muic" suffix to regmap and irq_data fields in maxim_core state
> > container to prepare for max77836 support.
> > This is only a rename-like patch, new code is not added.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/extcon/extcon-max14577.c | 17 +++++++++--------
> > drivers/mfd/max14577.c | 22 +++++++++++-----------
> > drivers/power/max14577_charger.c | 8 ++++----
> > drivers/regulator/max14577.c | 2 +-
> > include/linux/mfd/max14577-private.h | 4 ++--
> > 5 files changed, 27 insertions(+), 26 deletions(-)
>
> Happy to apply this with maintainer Acks.
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
^ permalink raw reply
* [PATCH 08/18] mfd: max14577: Rename state container to maxim_core
From: Krzysztof Kozlowski @ 2014-02-05 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203094258.GI13529@lee--X1>
+Cc: Chanwoo, Mark and Dmitry for ACK-s on their subsystems.
Krzysztof Kozlowski
On Mon, 2014-02-03 at 09:42 +0000, Lee Jones wrote:
> > This patch continues the preparation for adding support for max77836
> > device to existing max14577 driver.
> >
> > The patch renames the struct "max14577" state container to "maxim_core".
> > This is only a rename-like patch, new code is not added.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/extcon/extcon-max14577.c | 22 +++++------
> > drivers/mfd/max14577.c | 68 +++++++++++++++++-----------------
> > drivers/power/max14577_charger.c | 16 ++++----
> > drivers/regulator/max14577.c | 6 +--
> > include/linux/mfd/max14577-private.h | 5 ++-
> > 5 files changed, 60 insertions(+), 57 deletions(-)
>
> Need some more maintainer Acks here.
>
> > -struct max14577 {
> > +/*
> > + * State container for max14577-like drivers.
> > + */
>
> I don't think this comment is required.
>
> Besides that, the code looks fine:
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
> > +struct maxim_core {
> > struct device *dev;
> > struct i2c_client *i2c; /* Slave addr = 0x4A */
> >
>
^ 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