* Re: [PATCH v4 4/7] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: David Lanzendörfer @ 2014-02-10 11:35 UTC (permalink / raw)
To: Priit Laes
Cc: devicetree, Ulf Hansson, Laurent Pinchart, Mike Turquette,
Simon Baatz, H Hartley Sweeten, Emilio López, linux-mmc,
Chris Ball, linux-kernel, Hans de Goede, linux-sunxi, Tejun Heo,
Maxime Ripard, Guennadi Liakhovetski, linux-arm-kernel
In-Reply-To: <dac5ec28-3a6d-428f-8ab6-c8f2bb53168f@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 591 bytes --]
Hi
> > + (cmd->opcode == 5 || cmd->opcode == 52))
> Aren't these the ones defined in linux/mmc/sdio.h:
> 5 - SD_IO_SEND_OP_COND
> 52 - SD_IO_RW_DIRECT
Yes. They are...
Changed that.
Also I removed the camel cases and the defines within the struct definition.
> > +struct sunxi_mmc_clk_dly {
> > + u32 mode;
> > + u32 oclk_dly;
> > + u32 sclk_dly;
> Do these members have to be u32? They all seem to be smaller than 10.
Yes. Because of situations where it gets used in bit operations, and shorter
types mess things up and prevent the driver from working ;-)
cheer
david
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/7] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: David Lanzendörfer @ 2014-02-10 11:35 UTC (permalink / raw)
To: Priit Laes
Cc: linux-sunxi, devicetree, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc, Chris Ball, linux-kernel, H Hartley Sweeten, Tejun Heo,
Maxime Ripard, Guennadi Liakhovetski, linux-arm-kernel
In-Reply-To: <dac5ec28-3a6d-428f-8ab6-c8f2bb53168f@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi
> > + (cmd->opcode == 5 || cmd->opcode == 52))
> Aren't these the ones defined in linux/mmc/sdio.h:
> 5 - SD_IO_SEND_OP_COND
> 52 - SD_IO_RW_DIRECT
Yes. They are...
Changed that.
Also I removed the camel cases and the defines within the struct definition.
> > +struct sunxi_mmc_clk_dly {
> > + u32 mode;
> > + u32 oclk_dly;
> > + u32 sclk_dly;
> Do these members have to be u32? They all seem to be smaller than 10.
Yes. Because of situations where it gets used in bit operations, and shorter
types mess things up and prevent the driver from working ;-)
cheer
david
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/7] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: David Lanzendörfer @ 2014-02-10 11:35 UTC (permalink / raw)
To: Priit Laes
Cc: linux-sunxi, devicetree, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc, Chris Ball, linux-kernel, H Hartley Sweeten, Tejun Heo,
Maxime Ripard, Guennadi Liakhovetski, linux-arm-kernel
In-Reply-To: <dac5ec28-3a6d-428f-8ab6-c8f2bb53168f@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi
> > + (cmd->opcode == 5 || cmd->opcode == 52))
> Aren't these the ones defined in linux/mmc/sdio.h:
> 5 - SD_IO_SEND_OP_COND
> 52 - SD_IO_RW_DIRECT
Yes. They are...
Changed that.
Also I removed the camel cases and the defines within the struct definition.
> > +struct sunxi_mmc_clk_dly {
> > + u32 mode;
> > + u32 oclk_dly;
> > + u32 sclk_dly;
> Do these members have to be u32? They all seem to be smaller than 10.
Yes. Because of situations where it gets used in bit operations, and shorter
types mess things up and prevent the driver from working ;-)
cheer
david
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/7] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: David Lanzendörfer @ 2014-02-10 11:35 UTC (permalink / raw)
To: Priit Laes
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten, Tejun Heo,
Maxime Ripard, Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <dac5ec28-3a6d-428f-8ab6-c8f2bb53168f-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
Hi
> > + (cmd->opcode == 5 || cmd->opcode == 52))
> Aren't these the ones defined in linux/mmc/sdio.h:
> 5 - SD_IO_SEND_OP_COND
> 52 - SD_IO_RW_DIRECT
Yes. They are...
Changed that.
Also I removed the camel cases and the defines within the struct definition.
> > +struct sunxi_mmc_clk_dly {
> > + u32 mode;
> > + u32 oclk_dly;
> > + u32 sclk_dly;
> Do these members have to be u32? They all seem to be smaller than 10.
Yes. Because of situations where it gets used in bit operations, and shorter
types mess things up and prevent the driver from working ;-)
cheer
david
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 11:20 UTC (permalink / raw)
To: Lukasz Majewski, Thomas Abraham
Cc: Sudeep.Holla, Nishanth Menon, Mark Rutland,
devicetree@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Pawel Moll, linux-pm@vger.kernel.org, viresh.kumar@linaro.org,
t.figa@samsung.com, Ian Campbell, rjw@rjwysocki.net, Rob Herring,
kgene.kim@samsung.com, thomas.ab@samsung.com, Kumar Gala,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20140210085305.641e6de5@amdc2363>
On 10/02/14 07:53, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
>
>> On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
>>> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla
>>> <Sudeep.Holla@arm.com> wrote:
>>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>>> <Sudeep.Holla@arm.com> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>>> userspace(list of frequencies and the boost parameters are
>>>>>> exposed through sysfs)
>>>>>
>>>>> That will be a different problem -> as currently every single
>>>>> frequency in the cpufreq list has ability to be marked as boost
>>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>>> the userspace :D
>>>>>
>>>>
>>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>>> gives the list of frequencies based on the state of the boost
>>>> feature at anytime.
>>>>
>>>> Intuitively the list without boost shouldn't have any frequency
>>>> above the range when it's enabled :), that's what I was referring
>>>> to. So I am not talking about any issue with user-space
>>>> maintenance.
>>> Fair enough - but i still think it has nothing to do with dt binding
>>> itself -> and i think the discussion we've had should be good for
>>> the binding provided in this patch.. I hope.. if documentation
>>> needs a bit of better explanation to prevent a repeat of the same
>>> discussion at a later point of time, now might be a good time to
>>> add it in.
>>
Nishanth, though I am not convinced that it should be list, since you have a
valid point that this should not prevent in having this feature, I am fine with
the list.
>> The term boost and over-clocking have been described in the bindings
>> document as being the same. Since the term over-clocking refers to
>> running a CPU beyond normal operating frequencies, I tend to agree
>> with Sudeep that it is not intuitive if a normal operating frequency
>> is greater than a boost mode frequency.
>>
>> Otherwise, when userspace does "echo 1 >
>> /sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
>> think the original intent of boost mode patches was to allow CPU to
>> operate at frequencies greater than the normal operating frequencies.
>>
>> Lukasz, how would you want this to be handled?
>
> Please consider an example:
>
> normal-freqs: 1400000, 1200000, 1000000, 800000, 600000, 400000, 200000
> [1]
> boost-freqs: 1700000, 1600000, 1500000. [2]
>
> All those freqs shall be represented as OPPs freq and voltage tuple.
>
> Best would be to specify all the boost-freqs as:
> boost-freqs = <1700000 1600000 1500000> to be prepared for future
> quirks or problems (or special cases which might show up latter).
> If anybody can foresee any potential threads - like platform on which
> boost freqs are 1700000 and 1500000, but not 1600000, then please share
> this information.
>
If that's the case then why should it be included in the list of OPPs.
I know Nishanth had a valid point in other thread previously(like including
SoC.dtsi having OPPs in platform files), but that's different problem.
> However, I think that it would be also acceptable to specify only:
> boost-freq = <1500000> and mark all freqs greater or equal to it as
> CPUFREQ_BOOST_FREQ.
>
> If there aren't any potential problems, then I think the second option
> would be a good solution (we would have only one BOOST attribute stored
> at CPUs DTS node).
>
Yes I prefer this to keep it simple and as per the definition of overclocking
or turbo boost in hardware terms if possible.
Just another thought, not sure how much this is true for real platforms, sharing
it anyway. IIUC these boost frequencies have certain constraints like thermal
and can't be sustained all the processors for long time.
So does it make sense to specify normal max frequency instead of boost-frequency
which by definition would be: "The maximum frequency that all processors are can
sustain simultaneously without any thermal constraints".
Ignore this if this is not the definition of boost on real platforms.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register
From: Naveen Krishna Ch @ 2014-02-10 11:09 UTC (permalink / raw)
To: Mark Rutland
Cc: Naveen Krishna Chatradhi,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
eduardo.valentin-l0cyMroinI0@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
amit.daniel-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
cpgs-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
In-Reply-To: <20140210110723.GV25314-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
Hello Mark,
On 10 February 2014 16:37, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Mon, Feb 10, 2014 at 10:50:01AM +0000, Naveen Krishna Ch wrote:
>> Hello Mark,
>>
>> On 10 February 2014 16:03, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Thu, Nov 07, 2013 at 12:42:34PM +0000, Naveen Krishna Chatradhi wrote:
>> >> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
>> >> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
>> >> should be acompanied by enabling the respective clock.
>> >>
>> >> This patch which allow for a "clk_sec" clock to be specified in the
>> >> device-tree which will be ungated when accessing the TRIMINFO register.
>> >
>> > Missing binding document update? Or was "clk_sec" originally in the
>> > binding but unused?
>> >
>> > The code seems to expect "tmu_apbif_sec" as the clock name in the DT,
>> > but this isn't mentioned in the commit message.
>> >
>> > I grepped Documentation/devicetree in mainline, but found no reference
>> > of either.
>> >
>> > Thanks,
>> > Mark.
>> This CL is to be abandoned.
>
> Ok.
>
>>
>> As mentioned in the previous replies to this patch.
>> The changes in this patched were merged with
>> http://www.spinics.net/lists/devicetree/msg15165.html
>>
>> The latest patch set can be found at.
>> 1. http://www.spinics.net/lists/devicetree/msg15163.html
>> 2. http://www.spinics.net/lists/devicetree/msg15164.html
>> 3. http://www.spinics.net/lists/devicetree/msg15165.html
>> 4. http://www.spinics.net/lists/devicetree/msg15165.html
>
> I responded here because of your ping message on 2014-02-07. The latest
> patches seem to have been posted before that. Was the ping misplaced or
> have I misunderstood?
It was my bad, I replied to the patches in that series and i myself forgot that
it was abandoned patch. Sorry.
>
> Thanks,
> Mark
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register
From: Mark Rutland @ 2014-02-10 11:07 UTC (permalink / raw)
To: Naveen Krishna Ch
Cc: Naveen Krishna Chatradhi, linux-pm@vger.kernel.org,
rui.zhang@intel.com, eduardo.valentin@ti.com,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
amit.daniel@samsung.com, kgene.kim@samsung.com,
devicetree@vger.kernel.org, b.zolnierkie@samsung.com,
cpgs@samsung.com
In-Reply-To: <CAHfPSqANMKSW=dFKUXXM1pXAr3+rmFz8v3rpksbf4Bzc+XSNOw@mail.gmail.com>
On Mon, Feb 10, 2014 at 10:50:01AM +0000, Naveen Krishna Ch wrote:
> Hello Mark,
>
> On 10 February 2014 16:03, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Thu, Nov 07, 2013 at 12:42:34PM +0000, Naveen Krishna Chatradhi wrote:
> >> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
> >> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
> >> should be acompanied by enabling the respective clock.
> >>
> >> This patch which allow for a "clk_sec" clock to be specified in the
> >> device-tree which will be ungated when accessing the TRIMINFO register.
> >
> > Missing binding document update? Or was "clk_sec" originally in the
> > binding but unused?
> >
> > The code seems to expect "tmu_apbif_sec" as the clock name in the DT,
> > but this isn't mentioned in the commit message.
> >
> > I grepped Documentation/devicetree in mainline, but found no reference
> > of either.
> >
> > Thanks,
> > Mark.
> This CL is to be abandoned.
Ok.
>
> As mentioned in the previous replies to this patch.
> The changes in this patched were merged with
> http://www.spinics.net/lists/devicetree/msg15165.html
>
> The latest patch set can be found at.
> 1. http://www.spinics.net/lists/devicetree/msg15163.html
> 2. http://www.spinics.net/lists/devicetree/msg15164.html
> 3. http://www.spinics.net/lists/devicetree/msg15165.html
> 4. http://www.spinics.net/lists/devicetree/msg15165.html
I responded here because of your ping message on 2014-02-07. The latest
patches seem to have been posted before that. Was the ping misplaced or
have I misunderstood?
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v11] gpio: add a driver for the Synopsys DesignWare APB GPIO block
From: Linus Walleij @ 2014-02-10 11:06 UTC (permalink / raw)
To: Alan Tull
Cc: Linus Walleij, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org, Jamie Iles,
devicetree@vger.kernel.org, Mark Rutland, Grant Likely,
Rob Herring, Steffen Trumtrar, Sebastian Hesselbarth,
Heiko Stuebner, Alan Tull, Dinh Nguyen, Yves Vandervennet
In-Reply-To: <1391724370-30589-1-git-send-email-delicious.quinoa@gmail.com>
Hi Alan, this is starting to look good. I's like an ACK from a DT
maintainer on the bindings but can't see anything really controversial
about them.
On Thu, Feb 6, 2014 at 11:06 PM, Alan Tull <delicious.quinoa@gmail.com> wrote:
> +static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
> +{
> + struct bgpio_chip *bgc = to_bgpio_chip(gc);
> + struct dwapb_gpio_port *port = container_of(bgc, struct
> + dwapb_gpio_port, bgc);
> + struct dwapb_gpio *gpio = port->gpio;
> +
> + return irq_create_mapping(gpio->domain, offset);
> +}
I think you want to call irq_find_mapping() here. irq_create_mapping()
should be called for all valid IRQs on probe() instead.
> + ct = irq_gc->chip_types;
> + ct->chip.irq_ack = irq_gc_ack_set_bit;
> + ct->chip.irq_mask = irq_gc_mask_set_bit;
> + ct->chip.irq_unmask = irq_gc_mask_clr_bit;
> + ct->chip.irq_set_type = dwapb_irq_set_type;
> + ct->chip.irq_enable = dwapb_irq_enable;
> + ct->chip.irq_disable = dwapb_irq_disable;
> + ct->regs.ack = GPIO_PORTA_EOI;
> + ct->regs.mask = GPIO_INTMASK;
Please add .startup() and .shutdown() callbacks marking the
respective lines as IRQs, compare to recent patches in the
GPIO subsystem such as this:
http://marc.info/?l=linux-gpio&m=138546100215235&w=2
You probably want to call irq_create_mapping() for each
valid IRQ after registering the chip in this function.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Mark Rutland @ 2014-02-10 10:58 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
pantelis.antoniou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1392006451-7818-2-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Feb 10, 2014 at 04:27:30AM +0000, Matt Ranostay wrote:
> Document compatible string, required and optional DT properties for
> AS3935 chipset driver.
>
> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/iio/proximity/as3935.txt | 27 ++++++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> 2 files changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> new file mode 100644
> index 0000000..0453254
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> @@ -0,0 +1,27 @@
> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
> +
> +Required properties:
> + - compatible: must be "ams,as3935"
> + - reg: SPI chip select number for the device
> + - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
> + slave node bindings.
> + - interrupt-parent : should be the phandle for the interrupt controller
> + - interrupts : interrupt mapping
Nit: Please don't use the term "interrupt mapping", as it's undefined
and clashes with the "interrupt-map" property on an interrupt nexus.
There are a lot of bindings using it, and it would be nice to get them
fixed up too.
As interrupts can be described in a couple of ways it probably doesn't
make sense to state the exact format here, but could this be something
like the following instead:
- interrupts: the sole interrupt generated by the device.
> +
> + Refer to interrupt-controller/interrupts.txt for generic
> + interrupt client node bindings.
> +
> +Optional properties:
> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 120pF.
> + This will require using the calibration data from the manufacturer.
I think "tune-cap" is a little terse. Also "cap" is used as an
abbreviation for "capability" elsewhere, and it would be nice to make
it clear that in this case it means "capacitor".
Could this be "ams,tuning-capacitor-pf" instead? That would make it
clear at a glance what the value is and the units (though people would
still ahve to refer to documentation to figure out precisely what this
means).
> +
> +Example:
> +
> +as3935@0 {
> + compatible = "ams,as3935";
> + reg = <0>;
> + spi-cpha;
> + interrupt-parent = <&gpio1>;
> + interrupts = <16 1>;
> + ams,tune-cap = <80>;
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index e9d19e2..03e50ff 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -11,6 +11,7 @@ ak Asahi Kasei Corp.
> allwinner Allwinner Technology Co., Ltd.
> altr Altera Corp.
> amcc Applied Micro Circuits Corporation (APM, formally AMCC)
> +ams AMS AG
The vendor-prefix addition looks fine to me.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 10:51 UTC (permalink / raw)
To: Lukasz Majewski, Thomas Abraham
Cc: Sudeep.Holla, Nishanth Menon, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <20140210083836.44b519bf@amdc2363>
On 10/02/14 07:38, Lukasz Majewski wrote:
> Hi Thomas, Sudeep,
>
>> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com>
>> wrote:
>>> On 07/02/14 17:37, Nishanth Menon wrote:
>>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla
>>>> <Sudeep.Holla@arm.com> wrote:
>>>
>>> [...]
>>>
>>>>> Yes I think its counter-intuitive as it's visible to the
>>>>> userspace(list of frequencies and the boost parameters are
>>>>> exposed through sysfs)
>>>>
>>>> That will be a different problem -> as currently every single
>>>> frequency in the cpufreq list has ability to be marked as boost
>>>> frequency - if userspace does not maintain that, then, IMHO, fix
>>>> the userspace :D
>>>>
>>>
>>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>>> gives the list of frequencies based on the state of the boost
>>> feature at anytime.
>>
>> The list of frequencies in
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
>> does not change based in the state of the boost feature (enabled or
>> disabled). But the scaling_max_frequency and scaling_min_frequency are
>> updated based on the set of available + boost frequencies available.
>
> With boost intended behavior is as follow:
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies [1]
>
> shows the non boost frequencies no matter if boost is enabled or not.
> Those are the "normal" frequencies.
>
> When boost is supported (by enabling the CONFIG_CPU_FREQ_BOOST_SW)
> extra sysfs attribute shows up:
>
> /sys/devices/system/cpu/cpu0/cpufreq/scaling_boost_frequencies [2]
> in which are listed only the boost frequencies.
>
Correct, sorry I misunderstood this to dynamic change in
scaling_available_frequencies based on state of boot.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register
From: Naveen Krishna Ch @ 2014-02-10 10:50 UTC (permalink / raw)
To: Mark Rutland
Cc: Naveen Krishna Chatradhi, linux-pm@vger.kernel.org,
rui.zhang@intel.com, eduardo.valentin@ti.com,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
amit.daniel@samsung.com, kgene.kim@samsung.com,
devicetree@vger.kernel.org, b.zolnierkie@samsung.com,
cpgs@samsung.com
In-Reply-To: <20140210103354.GT25314@e106331-lin.cambridge.arm.com>
Hello Mark,
On 10 February 2014 16:03, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Nov 07, 2013 at 12:42:34PM +0000, Naveen Krishna Chatradhi wrote:
>> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
>> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
>> should be acompanied by enabling the respective clock.
>>
>> This patch which allow for a "clk_sec" clock to be specified in the
>> device-tree which will be ungated when accessing the TRIMINFO register.
>
> Missing binding document update? Or was "clk_sec" originally in the
> binding but unused?
>
> The code seems to expect "tmu_apbif_sec" as the clock name in the DT,
> but this isn't mentioned in the commit message.
>
> I grepped Documentation/devicetree in mainline, but found no reference
> of either.
>
> Thanks,
> Mark.
This CL is to be abandoned.
As mentioned in the previous replies to this patch.
The changes in this patched were merged with
http://www.spinics.net/lists/devicetree/msg15165.html
The latest patch set can be found at.
1. http://www.spinics.net/lists/devicetree/msg15163.html
2. http://www.spinics.net/lists/devicetree/msg15164.html
3. http://www.spinics.net/lists/devicetree/msg15165.html
4. http://www.spinics.net/lists/devicetree/msg15165.html
Thanks for your time.
>
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
>> ---
>> drivers/thermal/samsung/exynos_tmu.c | 24 +++++++++++++++++++++++-
>> 1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
>> index b54825a..33edd1a 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -47,6 +47,7 @@
>> * @irq_work: pointer to the irq work structure.
>> * @lock: lock to implement synchronization.
>> * @clk: pointer to the clock structure.
>> + * @clk_sec: pointer to the clock structure for accessing the base_second.
>> * @temp_error1: fused value of the first point trim.
>> * @temp_error2: fused value of the second point trim.
>> * @regulator: pointer to the TMU regulator structure.
>> @@ -61,7 +62,7 @@ struct exynos_tmu_data {
>> enum soc_type soc;
>> struct work_struct irq_work;
>> struct mutex lock;
>> - struct clk *clk;
>> + struct clk *clk, *clk_sec;
>> u8 temp_error1, temp_error2;
>> struct regulator *regulator;
>> struct thermal_sensor_conf *reg_conf;
>> @@ -152,6 +153,8 @@ static int exynos_tmu_initialize(struct platform_device *pdev)
>>
>> mutex_lock(&data->lock);
>> clk_enable(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_enable(data->clk_sec);
>>
>> if (TMU_SUPPORTS(pdata, READY_STATUS)) {
>> status = readb(data->base + reg->tmu_status);
>> @@ -306,6 +309,8 @@ skip_calib_data:
>> out:
>> clk_disable(data->clk);
>> mutex_unlock(&data->lock);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_disable(data->clk_sec);
>>
>> return ret;
>> }
>> @@ -457,12 +462,16 @@ static void exynos_tmu_work(struct work_struct *work)
>> const struct exynos_tmu_registers *reg = pdata->registers;
>> unsigned int val_irq, val_type;
>>
>> + if (!IS_ERR(data->clk_sec))
>> + clk_enable(data->clk_sec);
>> /* Find which sensor generated this interrupt */
>> if (reg->tmu_irqstatus) {
>> val_type = readl(data->base_second + reg->tmu_irqstatus);
>> if (!((val_type >> data->id) & 0x1))
>> goto out;
>> }
>> + if (!IS_ERR(data->clk_sec))
>> + clk_disable(data->clk_sec);
>>
>> exynos_report_trigger(data->reg_conf);
>> mutex_lock(&data->lock);
>> @@ -641,6 +650,15 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> + data->clk_sec = devm_clk_get(&pdev->dev, "tmu_apbif_sec");
>> + if (!IS_ERR(data->clk_sec)) {
>> + ret = clk_prepare(data->clk_sec);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to get clock\n");
>> + return PTR_ERR(data->clk_sec);
>> + }
>> + }
>> +
>> if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>> pdata->type == SOC_ARCH_EXYNOS4412 ||
>> pdata->type == SOC_ARCH_EXYNOS5250 ||
>> @@ -713,6 +731,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>> return 0;
>> err_clk:
>> clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>> return ret;
>> }
>>
>> @@ -725,6 +745,8 @@ static int exynos_tmu_remove(struct platform_device *pdev)
>> exynos_unregister_thermal(data->reg_conf);
>>
>> clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>
>> if (!IS_ERR(data->regulator))
>> regulator_disable(data->regulator);
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
--
Shine bright,
(: Nav :)
^ permalink raw reply
* RE: [PATCH v2 2/8] ASoC: da9055: Add DT support for CODEC
From: Opensource [Adam Thomson] @ 2014-02-10 10:48 UTC (permalink / raw)
To: Mark Brown, Opensource [Adam Thomson]
Cc: Lee Jones, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Rob Herring, Linus Walleij, Dmitry Torokhov, Alessandro Zummo,
Guenter Roeck
In-Reply-To: <20140207162649.GQ32298@sirena.org.uk>
On Fri, Feb 07, 2014 at 04:27:17PM +0000, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 04:25:04PM +0000, Mark Brown wrote:
> > On Thu, Feb 06, 2014 at 06:03:09PM +0000, Adam Thomson wrote:
> > > Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
> >
> > This doesn't apply against my current for-next or v3.14-rc1, can you
> > please check and resend?
>
> Ugh, sorry - it'll be due to patch 1 of course which I'd skipped due to
> the MFD bit. If you need to resend it's probably easier all round to
> just send the MFD and ASoC bits of that separately since there's no
> direct dependency.
Ok, no problem. Will see what Lee comes back and go from there.
^ permalink raw reply
* [PATCH 4/7] ARM: shmobile: lager dts: Add QSPI nodes
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392029254-15400-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
From: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Add pinctrl and SPI devices for QSPI on Lager.
Add Spansion s25fl512s SPI FLASH and MTD partitions.
Signed-off-by: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
arch/arm/boot/dts/r8a7790-lager.dts | 36 +++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 1081c5e91ac4..adff2dc4012d 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -80,6 +80,11 @@
renesas,groups = "mmc1_data8", "mmc1_ctrl";
renesas,function = "mmc1";
};
+
+ qspi_pins: spi {
+ renesas,groups = "qspi_ctrl", "qspi_data4";
+ renesas,function = "qspi";
+ };
};
&mmcif1 {
@@ -95,3 +100,34 @@
&sata1 {
status = "okay";
};
+
+&spi {
+ pinctrl-0 = <&qspi_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25fl512s";
+ reg = <0>;
+ spi-max-frequency = <30000000>;
+ m25p,fast-read;
+
+ partition@0 {
+ label = "loader";
+ reg = <0x00000000 0x00040000>;
+ read-only;
+ };
+ partition@40000 {
+ label = "user";
+ reg = <0x00040000 0x00400000>;
+ read-only;
+ };
+ partition@440000 {
+ label = "flash";
+ reg = <0x00440000 0x03bc0000>;
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/7] ARM: shmobile: r8a7790 dtsi: Add QSPI node
From: Geert Uytterhoeven @ 2014-02-10 10:47 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-sh, linux-arm-kernel, linux-kernel, Geert Uytterhoeven,
devicetree, linux-spi
In-Reply-To: <1392029254-15400-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Cc: devicetree@vger.kernel.org
Cc: linux-spi@vger.kernel.org
---
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 54ab318af712..16bc116e0df4 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -775,4 +775,16 @@
"rcan1", "rcan0", "qspi_mod", "i2c3", "i2c2", "i2c1", "i2c0";
};
};
+
+ spi: spi@e6b10000 {
+ compatible = "renesas,qspi-r8a7790", "renesas,qspi";
+ reg = <0 0xe6b10000 0 0x2c>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp9_clks R8A7790_CLK_QSPI_MOD>;
+ num-cs = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Sudeep Holla @ 2014-02-10 10:46 UTC (permalink / raw)
To: Thomas Abraham
Cc: Sudeep.Holla, Nishanth Menon, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <CAJuA9agcpbKYocaQUBr2-VCXcXAo3r3urFF=+G_+ib2jCZqvwg@mail.gmail.com>
On 08/02/14 06:47, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
>
> The list of frequencies in
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
> does not change based in the state of the boost feature (enabled or
> disabled). But the scaling_max_frequency and scaling_min_frequency are
> updated based on the set of available + boost frequencies available.
>
Ah ok, sorry just glanced the code and misunderstood it. It make sense to update
only max_frequency.
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree
From: Sudeep Holla @ 2014-02-10 10:40 UTC (permalink / raw)
To: Thomas Abraham
Cc: Sudeep.Holla, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Nishanth Menon
In-Reply-To: <CAJuA9agT4PC6YOmhCwKQ=58qaGEr1qSuhTpX57ro1pEuk++Miw@mail.gmail.com>
On 08/02/14 05:10, Thomas Abraham wrote:
> On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 15:19, Thomas Abraham wrote:
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>>> support for CPU boost mode. This patch adds support for finding available
>>> boost frequencies from device tree and marking them as usable in boost mode.
>>>
>>> Cc: Nishanth Menon <nm@ti.com>
>>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>> ---
>>> drivers/base/power/opp.c | 34 +++++++++++++++++++++++++++++++++-
>>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>>> index fa41874..b636826 100644
>>> --- a/drivers/base/power/opp.c
>>> +++ b/drivers/base/power/opp.c
>>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>> struct device_opp *dev_opp;
>>> struct dev_pm_opp *opp;
>>> struct cpufreq_frequency_table *freq_table;
>>> - int i = 0;
>>> + int i = 0, j, len, ret;
>>> + u32 *boost_freqs = NULL;
>>>
>>> /* Pretend as if I am an updater */
>>> mutex_lock(&dev_opp_list_lock);
>>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>>> return -ENOMEM;
>>> }
>>>
>>> + if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>>> + if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>>> + dev_err(dev, "%s: invalid boost frequency\n", __func__);
>>> + ret = -EINVAL;
>>> + goto err_boost;
>>> + }
>>> +
>>> + boost_freqs = kzalloc(len, GFP_KERNEL);
>>> + if (!boost_freqs) {
>>> + dev_warn(dev, "%s: no memory for boost freq table\n",
>>> + __func__);
>>> + ret = -ENOMEM;
>>> + goto err_boost;
>>> + }
>>> + of_property_read_u32_array(dev->of_node, "boost-frequency",
>>> + boost_freqs, len / sizeof(u32));
>>> + }
>>> +
>>> list_for_each_entry(opp, &dev_opp->opp_list, node) {
>>> if (opp->available) {
>>> freq_table[i].driver_data = i;
>>> freq_table[i].frequency = opp->rate / 1000;
>>> + for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>>> + if (boost_freqs[j] == freq_table[i].frequency) {
>>> + freq_table[i].driver_data =
>>> + CPUFREQ_BOOST_FREQ;
>>> + break;
>>> + }
>>> + }
>>> i++;
>>> }
>>> }
>> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
>> this change seems to be cpufreq only.
>
> Yes, but as you have initiated the discussion on extending the OPP
> binding, this has been limited to cpufreq only. If the new OPP library
> has support for listing boost frequency, this can be migrated to the
> new OPP libaray.
>
Fair enough, just wanted to check as I couldn't get the info following the
thread. I might have missed it.
Regards,
Sudeep
^ permalink raw reply
* [PATCH v4 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
All Allwinner A20 boards we support can only use either EMAC or GMAC,
as they share the same pins. As we have switched all supported to
GMAC, we should alias GMAC (the active controller) as ethernet0,
so u-boot will insert the MAC address for the correct controller.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.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 68c889c..1b5fb88 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;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 7/8] ARM: dts: sun7i: a20-olinuxino-micro: Enable GMAC instead of EMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +++++++++++--------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index ead3013..b02a796 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -19,21 +19,6 @@
compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
soc@01c00000 {
- emac: ethernet@01c0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <&emac_pins_a>;
- phy = <&phy1>;
- status = "okay";
- };
-
- mdio@01c0b080 {
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
- };
-
pinctrl@01c20800 {
led_pins_olinuxino: led_pins@0 {
allwinner,pins = "PH2";
@@ -78,6 +63,18 @@
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c50000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_mii_a>;
+ phy = <&phy1>;
+ phy-mode = "mii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 6/8] ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 5c51cb8..7bf4935 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -19,21 +19,6 @@
compatible = "cubietech,cubieboard2", "allwinner,sun7i-a20";
soc@01c00000 {
- emac: ethernet@01c0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <&emac_pins_a>;
- phy = <&phy1>;
- status = "okay";
- };
-
- mdio@01c0b080 {
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
- };
-
pinctrl@01c20800 {
led_pins_cubieboard2: led_pins@0 {
allwinner,pins = "PH20", "PH21";
@@ -60,6 +45,18 @@
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c50000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_mii_a>;
+ phy = <&phy1>;
+ phy-mode = "mii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 5/8] ARM: dts: sun7i: cubietruck: Enable the GMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The CubieTruck uses the GMAC with an RGMII phy.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index f9dcb61..025ce52 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -51,6 +51,18 @@
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c50000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii_a>;
+ phy = <&phy1>;
+ phy-mode = "rgmii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 4/8] ARM: dts: sun7i: Add pin muxing options for the GMAC
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The A20 has EMAC and GMAC muxed on the same pins.
Add pin sets with gmac function for MII and RGMII mode to the DTSI.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 8eb4d54..68c889c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -484,6 +484,32 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ gmac_pins_mii_a: gmac_mii@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA9", "PA10",
+ "PA11", "PA12", "PA13", "PA14",
+ "PA15", "PA16";
+ allwinner,function = "gmac";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ gmac_pins_rgmii_a: gmac_rgmii@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA10",
+ "PA11", "PA12", "PA13",
+ "PA15", "PA16";
+ allwinner,function = "gmac";
+ /*
+ * data lines in RGMII mode use DDR mode
+ * and need a higher signal drive strength
+ */
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 3/8] ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index dd567ea..8eb4d54 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -645,6 +645,21 @@
status = "disabled";
};
+ gmac: ethernet@01c50000 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x01c50000 0x10000>;
+ interrupts = <0 85 4>;
+ interrupt-names = "macirq";
+ clocks = <&ahb_gates 49>, <&gmac_tx_clk>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ snps,pbl = <2>;
+ snps,fixed-burst;
+ snps,force_sf_dma_mode;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
hstimer@01c60000 {
compatible = "allwinner,sun7i-a20-hstimer";
reg = <0x01c60000 0x1000>;
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The GMAC uses 1 of 2 sources for its transmit clock, depending on the
PHY interface mode. Add both sources as dummy clocks, and as parents
to the GMAC clock node.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4fbe530..dd567ea 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -322,6 +322,34 @@
};
/*
+ * The following two are dummy clocks, placeholders used in the gmac_tx
+ * clock. The gmac driver will choose one parent depending on the PHY
+ * interface mode, using clk_set_rate auto-reparenting.
+ * The actual TX clock rate is not controlled by the gmac_tx clock.
+ */
+ mii_phy_tx_clk: clk@2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "mii_phy_tx";
+ };
+
+ gmac_int_tx_clk: clk@3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "gmac_int_tx";
+ };
+
+ gmac_tx_clk: clk@01c20164 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x01c20164 0x4>;
+ clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+ clock-output-names = "gmac_tx";
+ };
+
+ /*
* Dummy clock used by output clocks
*/
osc24M_32k: clk@1 {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The Allwinner A20/A31 clock module controls the transmit clock source
and interface type of the GMAC ethernet controller. Model this as
a single clock for GMAC drivers to use.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/clock/sunxi.txt | 30 +++++++
drivers/clk/sunxi/clk-sunxi.c | 97 +++++++++++++++++++++++
2 files changed, 127 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 0cf679b..28421d2 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -37,6 +37,7 @@ Required properties:
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
"allwinner,sun7i-a20-out-clk" - for the external output clocks
+ "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -50,6 +51,9 @@ Required properties for all clocks:
If the clock module only has one output, the name shall be the
module name.
+For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
+dummy clocks at 25 MHz and 125 MHz, respectively. See example.
+
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
@@ -96,3 +100,29 @@ mmc0_clk: clk@01c20088 {
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mmc0";
};
+
+mii_phy_tx_clk: clk@2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "mii_phy_tx";
+};
+
+gmac_int_tx_clk: clk@3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "gmac_int_tx";
+};
+
+gmac_clk: clk@01c20164 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x01c20164 0x4>;
+ /*
+ * The first clock must be fixed at 25MHz;
+ * the second clock must be fixed at 125MHz
+ */
+ clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+ clock-output-names = "gmac";
+};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 736fb60..da1d5cc 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -379,6 +379,103 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
/**
+ * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
+ *
+ * This clock looks something like this
+ * ________________________
+ * MII TX clock from PHY >-----|___________ _________|----> to GMAC core
+ * GMAC Int. RGMII TX clk >----|___________\__/__gate---|----> to PHY
+ * Ext. 125MHz RGMII TX clk >--|__divider__/ |
+ * |________________________|
+ *
+ * The external 125 MHz reference is optional, i.e. GMAC can use its
+ * internal TX clock just fine. The A31 GMAC clock module does not have
+ * the divider controls for the external reference.
+ *
+ * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
+ * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
+ * select the appropriate source and gate/ungate the output to the PHY.
+ *
+ * Only the GMAC should use this clock. Altering the clock so that it doesn't
+ * match the GMAC's operation parameters will result in the GMAC not being
+ * able to send traffic out. The GMAC driver should set the clock rate and
+ * enable/disable this clock to configure the required state. The clock
+ * driver then responds by auto-reparenting the clock.
+ */
+
+#define SUN7I_A20_GMAC_GPIT 2
+#define SUN7I_A20_GMAC_MASK 0x3
+#define SUN7I_A20_GMAC_PARENTS 2
+
+static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_mux *mux;
+ struct clk_gate *gate;
+ const char *clk_name = node->name;
+ const char *parents[SUN7I_A20_GMAC_PARENTS];
+ void *reg;
+ int i = 0;
+
+ if (of_property_read_string(node, "clock-output-names", &clk_name))
+ return;
+
+ /* allocate mux and gate clock structs */
+ mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+ if (!mux)
+ return;
+
+ gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+ if (!gate)
+ goto free_mux;
+
+ /* gmac clock requires exactly 2 parents */
+ parents[0] = of_clk_get_parent_name(node, 0);
+ parents[1] = of_clk_get_parent_name(node, 1);
+ if (!parents[0] || !parents[1])
+ goto free_gate;
+
+ reg = of_iomap(node, 0);
+ if (!reg)
+ goto free_gate;
+
+ /* set up gate and fixed rate properties */
+ gate->reg = reg;
+ gate->bit_idx = SUN7I_A20_GMAC_GPIT;
+ gate->lock = &clk_lock;
+ mux->reg = reg;
+ mux->mask = SUN7I_A20_GMAC_MASK;
+ mux->flags = CLK_MUX_INDEX_BIT;
+ mux->lock = &clk_lock;
+
+ clk = clk_register_composite(NULL, clk_name,
+ parents, SUN7I_A20_GMAC_PARENTS,
+ &mux->hw, &clk_mux_ops,
+ NULL, NULL,
+ &gate->hw, &clk_gate_ops,
+ 0);
+
+ if (IS_ERR(clk))
+ goto iounmap_reg;
+
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ clk_register_clkdev(clk, clk_name, NULL);
+
+ return;
+
+iounmap_reg:
+ iounmap(reg);
+free_gate:
+ kfree(gate);
+free_mux:
+ kfree(mux);
+}
+CLK_OF_DECLARE(sun7i_a20_gmac, "allwinner,sun7i-a20-gmac-clk",
+ sun7i_a20_gmac_clk_setup);
+
+
+
+/**
* sunxi_factors_clk_setup() - Setup function for factor clocks
*/
--
1.9.rc1
^ permalink raw reply related
* [PATCH v4 0/8] Add Allwinner A20 GMAC ethernet support
From: Chen-Yu Tsai @ 2014-02-10 10:35 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi,
This is the v4 of the remaining Allwinner A20 GMAC glue layer patches.
The stmmac driver changes have been merged through net-next. The
remaining bits are clock and DT patches. The patches should be applied
over my clock renaming patches.
The Allwinner A20 SoC integrates an early version of dwmac
IP from Synopsys. On top of that is a hardware glue layer.
This layer needs to be configured before the dwmac can be
used.
Part of the glue layer is a clock mux, which controls the
source and direction of the TX clock used by GMAC.
Changes since v3:
* Rework error checking in GMAC clock driver
* Clarify required parent clock order for GMAC clock in DT bindings
* Rewrite commit log for "ARM: dts: sun7i: Add ethernet alias for GMAC"
* Corrected "a20-olinuxino-micro" in commit message
* Rewrite comments in sun7i dtsi to clarify purpose of dummy clocks
* Rebase onto Maxime's sunxi-next branch
Changes since v2:
* Added more comments on GMAC clock driver
* Drop CLK_SET_PARENT_GATE in GMAC clock driver
* Use macro for max clock parents
* Line wrapping
Changes since v1:
* Added optional reset control to stmmac driver core
* Added non CONFIG_RESET_CONROLLER routines for the above change
* Extended callback API, as discussed with Srinivas
* Used new stmmac_of_data to pass features and callbacks,
instead of platform data, as discussed
* Seperated clock module glue layer into clock driver
Cheers,
ChenYu
Chen-Yu Tsai (8):
clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
ARM: dts: sun7i: Add pin muxing options for the GMAC
ARM: dts: sun7i: cubietruck: Enable the GMAC
ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
ARM: dts: sun7i: a20-olinuxino-micro: Enable GMAC instead of EMAC
ARM: dts: sun7i: Add ethernet alias for GMAC
Documentation/devicetree/bindings/clock/sunxi.txt | 30 +++++++
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 27 +++----
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12 +++
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +++----
arch/arm/boot/dts/sun7i-a20.dtsi | 71 ++++++++++++++++-
drivers/clk/sunxi/clk-sunxi.c | 97 +++++++++++++++++++++++
6 files changed, 233 insertions(+), 31 deletions(-)
--
1.9.rc1
^ 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