* [PATCHv6 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
From: Arnd Bergmann @ 2014-07-18 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405663186-26464-2-git-send-email-cw00.choi@samsung.com>
On Friday 18 July 2014 14:59:43 Chanwoo Choi wrote:
> This patchset add 'exynos_adc_data' structure which includes some functions
> to control ADC operation and specific data according to ADC version (v1 or v2).
>
This new structure makes a lot of sense for covering the exynos specific
versions, but it will likely give a little more complexity for the
older models. We'll have to deal with that later then, no need to
hold up your patch. Interestingly, the version numbers seem weird. The
old driver uses
{
.name = "s3c24xx-adc",
.driver_data = TYPE_ADCV1,
}, {
.name = "s3c2443-adc",
.driver_data = TYPE_ADCV11,
}, {
.name = "s3c2416-adc",
.driver_data = TYPE_ADCV12,
}, {
.name = "s3c64xx-adc",
.driver_data = TYPE_ADCV2,
}, {
.name = "samsung-adc-v3",
.driver_data = TYPE_ADCV3,
}
Where TYPE_ADCV3 seems to be the same as the new ADC_V1 used in this
driver. Do you have an explanation for that?
Arnd
^ permalink raw reply
* [RFC] PCI: pci-imx6: Add delay to workaround kernel hang
From: Marek Vasut @ 2014-07-18 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675599.6072.8.camel@weser.hi.pengutronix.de>
On Friday, July 18, 2014 at 11:26:39 AM, Lucas Stach wrote:
> Hi Tim,
>
> Am Donnerstag, den 26.06.2014, 17:29 -0700 schrieb Tim Harvey:
> [...]
>
> > Shawn / Richard,
> >
> > I am also affected by this issue on IMX6 boards that I support. If I
> > enable PCI in the bootloader I see similar hangs.
> >
> > I have the following hardware configurations on my bench:
> > 1. IMX6DL + i210 (same PCI setup as Fabio's above, but DL instead of Q)
> > 2. IMX6Q + ath9k device
> > 3. IMX6DL + PLX PEX860x PCIe-to-PCIe bridge with various devices
> >
> > behind the bridge, using a clock buffer from IMX6 PCIe clock
> >
> > 4. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> >
> > behind the bridge, using a clock buffer from IMX6 PCIe clock
> >
> > 5. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> >
> > behind the bridge using a clock generator (always on, ignoring the
> > PCIe clock)
> >
> > For all of the above I have no PCI issues using
> > 3.14/3.15/3.16-rc2/vendor 3.10.17_1.0.0_ga unless I enable PCI in the
> > bootloader. When I do so, all of the above configurations hang
> > somewhere around PCI init/enumeration. The same occurs with the most
> > recent vendor kernel 3.10.17_1.0.0_ga kernel (works when PCI is
> > disabled in the bootloader, hangs otherwise).
> >
> > When I apply Fabio's patch above to the 3.16-rc2 kernel I find that
> > scenarios #4 and #5 above then work, #3 boots but the PLX bridge fails
> > all config cycles (0xff's), #2 boots but with no PCIe link, and #1
> > above still hangs. Previously, when I have dug into this particular
> > 'hang' issue on 3.15 I found that the delay needed to be between
> > imx6_pcie_probe() requesting and asserting reset_gpio low, and before
> > setting IOMUX_GPR1:18 to power down the PCIe PHY (note here, that the
> > PHY is currently enabled in the bootloader when PCI is enabled there).
> >
> > When I apply Fabio's patch above to the most recent vendor kernel
> > 3.10.17_1.0.0_ga I still hang in all cases.
> >
> > So while I agree there is something horribly wrong with IMX6 PCI
> > still, I don't think Fabio's patch is the right solution and I don't
> > have anything better at this point in time. I'm happy to share any
> > hardware with anyone that can work through this issue.
>
> Can you try if the attached patch makes any difference?
>
> Regards,
> Lucas
> ------------------------------>8---------------------------------
> From 0e2fc443c760290166f6371d50813e6c30a678da Mon Sep 17 00:00:00 2001
> From: Lucas Stach <l.stach@pengutronix.de>
> Date: Thu, 17 Jul 2014 18:54:44 +0200
> Subject: [PATCH] try forcing LTSSM into detect state
>
> ---
> drivers/pci/host/pci-imx6.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index a568efaa331c..afa450c54aba 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -215,6 +215,8 @@ static int imx6_pcie_assert_core_reset(struct pcie_port
> *pp) {
> struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
>
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> + IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
Tried this, among many other things, but please let someone else also re-verify
this. What I observed is that the LTSSM cannot leave the POLLING phase .
^ permalink raw reply
* [PATCH v10 5/7] arm: add basic support for Mediatek MT6589 boards
From: Daniel Lezcano @ 2014-07-18 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404745988-32558-6-git-send-email-matthias.bgg@gmail.com>
On 07/07/2014 05:13 PM, Matthias Brugger wrote:
> This adds a generic devicetree board file and a dtsi for boards
> based on MT6589 SoCs from Mediatek.
>
> Apart from the generic parts (gic, clocks) the only component
> currently supported are the timers.
>
> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
> --
I will take this patchset through my tree but this patch touches an area
I am not handling.
Olof, Arnd, do you mind to ack this patch ?
Thanks !
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCHv6 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Arnd Bergmann @ 2014-07-18 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405663186-26464-3-git-send-email-cw00.choi@samsung.com>
On Friday 18 July 2014 14:59:44 Chanwoo Choi wrote:
> This patch control special clock for ADC in Exynos series's FSYS block.
> If special clock of ADC is registerd on clock list of common clk framework,
> Exynos ADC drvier have to control this clock.
>
> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
> - 'adc' clock: bus clock for ADC
>
> Exynos3250 has additional 'sclk_adc' clock as following:
> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>
> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
> clock in FSYS_BLK.
Do you know if any of the older ADC blocks have an "sclk" input as well?
Further, why is it called "sclk_adc" rather than just "sclk"?
> @@ -199,13 +262,20 @@ static void exynos_adc_v2_start_conv(struct exynos_adc *info,
> writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
> }
>
> +#define __EXYNOS_ADC_V2_DATA \
> + .num_channels = MAX_ADC_V2_CHANNELS, \
> + .init_hw = exynos_adc_v2_init_hw, \
> + .exit_hw = exynos_adc_v2_exit_hw, \
> + .clear_irq = exynos_adc_v2_clear_irq, \
> + .start_conv = exynos_adc_v2_start_conv, \
> +
> static struct exynos_adc_data const exynos_adc_v2_data = {
> - .num_channels = MAX_ADC_V2_CHANNELS,
> + __EXYNOS_ADC_V2_DATA
> +};
>
> - .init_hw = exynos_adc_v2_init_hw,
> - .exit_hw = exynos_adc_v2_exit_hw,
> - .clear_irq = exynos_adc_v2_clear_irq,
> - .start_conv = exynos_adc_v2_start_conv,
> +static struct exynos_adc_data const exynos3250_adc_v2_data = {
> + __EXYNOS_ADC_V2_DATA
> + .needs_sclk = true,
> };
I think the macro hurts readability. Please just duplicate the definition
here.
> static const struct of_device_id exynos_adc_match[] = {
> @@ -215,6 +285,9 @@ static const struct of_device_id exynos_adc_match[] = {
> }, {
> .compatible = "samsung,exynos-adc-v2",
> .data = (void *)&exynos_adc_v2_data,
> + }, {
> + .compatible = "samsung,exynos3250-adc-v2",
> + .data = (void *)&exynos3250_adc_v2_data,
> },
> {},
Remove the '(void *)' cast here and mark the structure as 'const'.
We intentionally use a 'const void *' type here to verify that
the driver doesn't modify the per-device type data at runtime,
which would be bad if you ever have multiple device instances.
Arnd
^ permalink raw reply
* [GIT PULL] Mediatek basic support for v3.17
From: Matthias Brugger @ 2014-07-18 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqK-jJ-yCyMm=DXx=T9xjHQa3ZNefEco+fEi4ju_LO_Vtg@mail.gmail.com>
2014-07-16 16:40 GMT+02:00 Rob Herring <robherring2@gmail.com>:
> On Wed, Jul 16, 2014 at 8:47 AM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
>> 2014-07-15 17:17 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
>>> On Tuesday 15 July 2014 06:59:13 Greg KH wrote:
>>>> On Tue, Jul 15, 2014 at 01:11:42PM +0200, Matthias Brugger wrote:
>>>> > The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>>>> >
>>>> > Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>>>> >
>>>> > are available in the git repository at:
>>>> >
>>>> > https://github.com/mbgg/linux-mediatek.git tags/v3.17-next-basic-support
>>>>
>>>> As these are only 7 patches, why do a git pull? And I know I can't take
>>>> pull requests from github, I'm not sure what the rules are for the ARM
>>>> SoC developers either...
>>>>
>>>> Just send patches, it's easier that way.
>>>
>>> We generally prefer pull requests, but patches also work for us.
>>>
>>> However, one note about the text in the pull request: Matthias,
>>> please always try to be explicit about who you want to pull or
>>> merge things when you are ready and list in the pull request the
>>> other maintainers that have agreed to merging it (or whether they
>>> have not sent an Ack yet, which is even more important).
>>
>> Ok, thank you for the advice. I will do so in the next pull request.
>>
>>>
>>> In this case, the clocksource driver needs an Ack from the clocksource
>>> maintainers, and the drivers/of/address.c changes need an Ack from the
>>> OF maintainers. I assume you have those, but I'd have to first look
>>> at the patches to be sure.
>>>
>>> arnd
>>
>> For the drivers/of/address.c patch I used to have an Ack [1] from
>> Grant Likely who told me to merge it through arm-soc. But I deleted
>> the Ack after changing the patch because of some comments from Russel
>> King [2].
>> So at the moment I don't have any Ack anymore.
>>
>> I have an Ack for the clocksource driver from Thomas [0]. Daniel
>> wanted to merge it through his branch, but because of the changes in
>> the OF patch he never did.
>>
>> So I suppose I have to get some comments from the OF maintainer about
>> the patch, before we can go on with the pull request.
>
> I've now acked the patch in question. If there's no other change to
> the pull req, there's no reason to respin the branch to add the ack.
I talked with Daniel Lezcano on IRC and he told me, that he will take
the clocksource patches through his repository.
For the rest of the patches I will send a new pull request.
Best regards,
Matthias
>
> Rob
--
motzblog.wordpress.com
^ permalink raw reply
* [PATCH v2 6/7] ARM: dts: rockchip: add core rk3288 dtsi
From: Heiko Stübner @ 2014-07-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718093551.GE25180@leverpostej>
Hi Mark,
Am Freitag, 18. Juli 2014, 10:35:52 schrieb Mark Rutland:
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu at 500 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a12";
> > + reg = <0x500>;
> > + };
> > + cpu at 501 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a12";
> > + reg = <0x501>;
> > + };
> > + cpu at 502 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a12";
> > + reg = <0x502>;
> > + };
> > + cpu at 503 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a12";
> > + reg = <0x503>;
>
> I take it that we can only use one of these for the moment? I didn't see
> the addition of any SMP code.
>
> Or did I miss that?
>
> [...]
>
> > + timer {
> > + compatible = "arm,armv7-timer";
> > + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |
> > IRQ_TYPE_LEVEL_HIGH)>, + <GIC_PPI 14
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, +
> > <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, +
> > <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
> > IRQ_TYPE_LEVEL_HIGH)>; + clock-frequency = <24000000>;
> > + };
>
> Please say you don't need this clock-frequency property.
>
> It's a work-around at best, and you won't be able to use Hyp properly.
> I'd really like to discourage use of this property, especially as people
> seem to set it regardless of whether the hardware's correct...
>
> What's the state of CNTFREQ and CNTVOFF, and is there any chance that
> these are sane?
Both issues you mention are actually connected - timer-issues in smp context
due to CNTVOFF not being set correctly and CNTFREQ currently not being
initialized.
I'm very hopeful that both should be resolved in the near future and Will
should also be able to tell you more about this :-).
So for the short-term I guess the clock-frequency is needed, but we should be
able to remove it again in the future, once the bootloader is doing the right
thing.
Heiko
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Arnd Bergmann @ 2014-07-18 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405663186-26464-4-git-send-email-cw00.choi@samsung.com>
On Friday 18 July 2014 14:59:45 Chanwoo Choi wrote:
> Must be "samsung,exynos-adc-v2" for
> future controllers.
It would be good to change 'future controllers' to something else now.
Presumably that word was used before the actual products were announced,
but now they are publically known.
> + Must be "samsung,exynos3250-adc-v2" for
> + controllers compatible with ADC of Exynos3250.
Doesn't this version have a specific name as well? The ADC block
seems to use version numbers, so better put those in here to avoid
confusion when another Exynos7890 comes out that uses the same
ADC as exynos3250.
Arnd
^ permalink raw reply
* [PATCH] ARM: zynq: dt: Add GPIO node
From: Michal Simek @ 2014-07-18 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405018418-23396-1-git-send-email-soren.brinkmann@xilinx.com>
On 07/10/2014 08:53 PM, Soren Brinkmann wrote:
> Add node describing Zynq's GPIO controller.
>
> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> ---
> The GPIO driver and binding documentation is staged in Linus' GPIO tree.
>
> S?ren
>
> arch/arm/boot/dts/zynq-7000.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Applied for zynq dt-next when gpio driver is in mainline.
Thanks,
Michal
^ permalink raw reply
* [PATCH 1/2] clk: samsung: exynos4x12: Enable ARMCLK down feature
From: Krzysztof Kozlowski @ 2014-07-18 9:53 UTC (permalink / raw)
To: linux-arm-kernel
Enable ARMCLK down and up features on Exynos4212 and 4412 SoCs. The
frequency of ARMCLK will be reduced upon entering idle mode (WFI or
WFE). Additionally upon exiting from idle mode the divider for ARMCLK
will be brought back to 1.
These are exactly the same settings as for Exynos5250
(clk-exynos5250.c), except of Exynos4412 where ARMCLK down is enabled
for all 4 cores.
Tested on Trats2 board (Exynos4412) and Samsung Gear 1 (Exynos4212).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
drivers/clk/samsung/clk-exynos4.c | 53 +++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 7f4a473a7ad7..b8ea37b23984 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -114,11 +114,34 @@
#define DIV_CPU1 0x14504
#define GATE_SCLK_CPU 0x14800
#define GATE_IP_CPU 0x14900
+#define PWR_CTRL1 0x15020
+#define PWR_CTRL2 0x15024
#define E4X12_DIV_ISP0 0x18300
#define E4X12_DIV_ISP1 0x18304
#define E4X12_GATE_ISP0 0x18800
#define E4X12_GATE_ISP1 0x18804
+/* Below definitions are used for PWR_CTRL settings */
+#define PWR_CTRL1_CORE2_DOWN_RATIO (7 << 28)
+#define PWR_CTRL1_CORE1_DOWN_RATIO (7 << 16)
+#define PWR_CTRL1_DIV2_DOWN_EN (1 << 9)
+#define PWR_CTRL1_DIV1_DOWN_EN (1 << 8)
+#define PWR_CTRL1_USE_CORE3_WFE (1 << 7)
+#define PWR_CTRL1_USE_CORE2_WFE (1 << 6)
+#define PWR_CTRL1_USE_CORE1_WFE (1 << 5)
+#define PWR_CTRL1_USE_CORE0_WFE (1 << 4)
+#define PWR_CTRL1_USE_CORE3_WFI (1 << 3)
+#define PWR_CTRL1_USE_CORE2_WFI (1 << 2)
+#define PWR_CTRL1_USE_CORE1_WFI (1 << 1)
+#define PWR_CTRL1_USE_CORE0_WFI (1 << 0)
+
+#define PWR_CTRL2_DIV2_UP_EN (1 << 25)
+#define PWR_CTRL2_DIV1_UP_EN (1 << 24)
+#define PWR_CTRL2_DUR_STANDBY2_VAL (1 << 16)
+#define PWR_CTRL2_DUR_STANDBY1_VAL (1 << 8)
+#define PWR_CTRL2_CORE2_UP_RATIO (1 << 4)
+#define PWR_CTRL2_CORE1_UP_RATIO (1 << 0)
+
/* the exynos4 soc type */
enum exynos4_soc {
EXYNOS4210,
@@ -1164,6 +1187,34 @@ static struct samsung_pll_clock exynos4x12_plls[nr_plls] __initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+static void __init exynos4_core_down_clock(void)
+{
+ unsigned int tmp;
+
+ /*
+ * Enable arm clock down (in idle) and set arm divider
+ * ratios in WFI/WFE state.
+ */
+ tmp = (PWR_CTRL1_CORE2_DOWN_RATIO | PWR_CTRL1_CORE1_DOWN_RATIO |
+ PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
+ PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
+ PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
+ if (of_machine_is_compatible("samsung,exynos4412"))
+ tmp |= PWR_CTRL1_USE_CORE3_WFE | PWR_CTRL1_USE_CORE2_WFE |
+ PWR_CTRL1_USE_CORE3_WFI | PWR_CTRL1_USE_CORE2_WFI;
+ __raw_writel(tmp, reg_base + PWR_CTRL1);
+
+ /*
+ * Enable arm clock up (on exiting idle). Set arm divider
+ * ratios when not in idle along with the standby duration
+ * ratios.
+ */
+ tmp = (PWR_CTRL2_DIV2_UP_EN | PWR_CTRL2_DIV1_UP_EN |
+ PWR_CTRL2_DUR_STANDBY2_VAL | PWR_CTRL2_DUR_STANDBY1_VAL |
+ PWR_CTRL2_CORE2_UP_RATIO | PWR_CTRL2_CORE1_UP_RATIO);
+ __raw_writel(tmp, reg_base + PWR_CTRL2);
+}
+
/* register exynos4 clocks */
static void __init exynos4_clk_init(struct device_node *np,
enum exynos4_soc soc)
@@ -1250,6 +1301,8 @@ static void __init exynos4_clk_init(struct device_node *np,
samsung_clk_register_alias(ctx, exynos4_aliases,
ARRAY_SIZE(exynos4_aliases));
+ if (exynos4_soc == EXYNOS4X12)
+ exynos4_core_down_clock();
exynos4_clk_sleep_init();
pr_info("%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n"
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] clk: samsung: exynos3250: Enable ARMCLK down feature
From: Krzysztof Kozlowski @ 2014-07-18 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405677186-18678-1-git-send-email-k.kozlowski@samsung.com>
Enable ARMCLK down and up features on Exynos3250 SoC. The
frequency of ARMCLK will be reduced upon entering idle mode (WFI or
WFE). Additionally upon exiting from idle mode the divider for ARMCLK
will be brought back to 1.
These are exactly the same settings as for Exynos5250
(clk-exynos5250.c).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
drivers/clk/samsung/clk-exynos3250.c | 50 ++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c
index 7a17bd40d1dd..c80140270931 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -87,6 +87,29 @@
#define SRC_CPU 0x14200
#define DIV_CPU0 0x14500
#define DIV_CPU1 0x14504
+#define PWR_CTRL1 0x15020
+#define PWR_CTRL2 0x15024
+
+/* Below definitions are used for PWR_CTRL settings */
+#define PWR_CTRL1_CORE2_DOWN_RATIO (7 << 28)
+#define PWR_CTRL1_CORE1_DOWN_RATIO (7 << 16)
+#define PWR_CTRL1_DIV2_DOWN_EN (1 << 9)
+#define PWR_CTRL1_DIV1_DOWN_EN (1 << 8)
+#define PWR_CTRL1_USE_CORE3_WFE (1 << 7)
+#define PWR_CTRL1_USE_CORE2_WFE (1 << 6)
+#define PWR_CTRL1_USE_CORE1_WFE (1 << 5)
+#define PWR_CTRL1_USE_CORE0_WFE (1 << 4)
+#define PWR_CTRL1_USE_CORE3_WFI (1 << 3)
+#define PWR_CTRL1_USE_CORE2_WFI (1 << 2)
+#define PWR_CTRL1_USE_CORE1_WFI (1 << 1)
+#define PWR_CTRL1_USE_CORE0_WFI (1 << 0)
+
+#define PWR_CTRL2_DIV2_UP_EN (1 << 25)
+#define PWR_CTRL2_DIV1_UP_EN (1 << 24)
+#define PWR_CTRL2_DUR_STANDBY2_VAL (1 << 16)
+#define PWR_CTRL2_DUR_STANDBY1_VAL (1 << 8)
+#define PWR_CTRL2_CORE2_UP_RATIO (1 << 4)
+#define PWR_CTRL2_CORE1_UP_RATIO (1 << 0)
/* list of PLLs to be registered */
enum exynos3250_plls {
@@ -748,6 +771,31 @@ static struct samsung_pll_clock exynos3250_plls[nr_plls] __initdata = {
UPLL_LOCK, UPLL_CON0, NULL),
};
+static void __init exynos3_core_down_clock(void)
+{
+ unsigned int tmp;
+
+ /*
+ * Enable arm clock down (in idle) and set arm divider
+ * ratios in WFI/WFE state.
+ */
+ tmp = (PWR_CTRL1_CORE2_DOWN_RATIO | PWR_CTRL1_CORE1_DOWN_RATIO |
+ PWR_CTRL1_DIV2_DOWN_EN | PWR_CTRL1_DIV1_DOWN_EN |
+ PWR_CTRL1_USE_CORE1_WFE | PWR_CTRL1_USE_CORE0_WFE |
+ PWR_CTRL1_USE_CORE1_WFI | PWR_CTRL1_USE_CORE0_WFI);
+ __raw_writel(tmp, reg_base + PWR_CTRL1);
+
+ /*
+ * Enable arm clock up (on exiting idle). Set arm divider
+ * ratios when not in idle along with the standby duration
+ * ratios.
+ */
+ tmp = (PWR_CTRL2_DIV2_UP_EN | PWR_CTRL2_DIV1_UP_EN |
+ PWR_CTRL2_DUR_STANDBY2_VAL | PWR_CTRL2_DUR_STANDBY1_VAL |
+ PWR_CTRL2_CORE2_UP_RATIO | PWR_CTRL2_CORE1_UP_RATIO);
+ __raw_writel(tmp, reg_base + PWR_CTRL2);
+}
+
static void __init exynos3250_cmu_init(struct device_node *np)
{
struct samsung_clk_provider *ctx;
@@ -775,6 +823,8 @@ static void __init exynos3250_cmu_init(struct device_node *np)
samsung_clk_register_div(ctx, div_clks, ARRAY_SIZE(div_clks));
samsung_clk_register_gate(ctx, gate_clks, ARRAY_SIZE(gate_clks));
+ exynos3_core_down_clock();
+
exynos3250_clk_sleep_init();
}
CLK_OF_DECLARE(exynos3250_cmu, "samsung,exynos3250-cmu", exynos3250_cmu_init);
--
1.9.1
^ permalink raw reply related
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Will Deacon @ 2014-07-18 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718092744.GA19850@arm.com>
On Fri, Jul 18, 2014 at 10:27:44AM +0100, Catalin Marinas wrote:
> On Thu, Jul 17, 2014 at 06:28:58PM +0100, Will Deacon wrote:
> > On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote:
> > > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote:
> > > > On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote:
> > > > > We're not denying the possibility of heterogeneity, we're trying to expose a
> > > > > consistent view of the system to userspace. Differences between cores should
> > > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly
> > > > > passed off to userspace.
> > > >
> > > > On that basis, why report anything at all about invididual cores?
> > > > Just have /proc/cpuinfo report "number of processors: 4" and
> > > > no per-CPU information at all...
> > >
> > > We lost a lot of time on this already (given the internal threads). So
> > > my proposal is to go ahead with Mark's patch with per-CPU features. They
> > > currently just include the same elf_hwcap multiple times. If we ever
> > > need to present different features, the conditions would be:
> > >
> > > 1. Never report more than elf_hwcap
> > > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a
> > > way to transparently handle migration or emulation
> >
> > ... making the point of a per-cpu field entirely pointless ;)
>
> Well, if we can support such features in a transparent way,
> /proc/cpuinfo becomes more informative (e.g. user wondering why a
> process runs only on certain CPUs).
>
> But to be clear (and I think we are aligned), I don't trust user space
> to parse all processors in /proc/cpuinfo and make an informed selection
> of CPU affinity to avoid SIGILL.
>
> Yet another option would be to have a single features/hwcap line and
> present the extra features in a human (and only human) readable form
> (e.g. some haiku that changes with every kernel release ;)).
Or just have the single features line, then the per-cpu line can be called
`flags' or something, like Ard suggested. If userspace decides to parse
flags, it deserves all the pain that it gets.
Will
^ permalink raw reply
* [PATCHv6 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
From: Chanwoo Choi @ 2014-07-18 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6485839.CnzmD0SeQj@wuerfel>
Hi Arnd,
On 07/18/2014 06:47 PM, Arnd Bergmann wrote:
> On Friday 18 July 2014 14:59:44 Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
>> clock in FSYS_BLK.
>
> Do you know if any of the older ADC blocks have an "sclk" input as well?
No, I didn't check older ADC blocks. I only checked it on Exynos3250,
Exynos4210/4212/4412, Exynos5250/5420.
>
> Further, why is it called "sclk_adc" rather than just "sclk"?
The sclk means 'special clock' in Exynos TRM. Exynos SoC has varisou sclk clocks.
'sclk_adc' is only used for ADC IP.
>
>> @@ -199,13 +262,20 @@ static void exynos_adc_v2_start_conv(struct exynos_adc *info,
>> writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
>> }
>>
>> +#define __EXYNOS_ADC_V2_DATA \
>> + .num_channels = MAX_ADC_V2_CHANNELS, \
>> + .init_hw = exynos_adc_v2_init_hw, \
>> + .exit_hw = exynos_adc_v2_exit_hw, \
>> + .clear_irq = exynos_adc_v2_clear_irq, \
>> + .start_conv = exynos_adc_v2_start_conv, \
>> +
>> static struct exynos_adc_data const exynos_adc_v2_data = {
>> - .num_channels = MAX_ADC_V2_CHANNELS,
>> + __EXYNOS_ADC_V2_DATA
>> +};
>>
>> - .init_hw = exynos_adc_v2_init_hw,
>> - .exit_hw = exynos_adc_v2_exit_hw,
>> - .clear_irq = exynos_adc_v2_clear_irq,
>> - .start_conv = exynos_adc_v2_start_conv,
>> +static struct exynos_adc_data const exynos3250_adc_v2_data = {
>> + __EXYNOS_ADC_V2_DATA
>> + .needs_sclk = true,
>> };
>
> I think the macro hurts readability. Please just duplicate the definition
> here.
OK, I'll fix it.
>
>> static const struct of_device_id exynos_adc_match[] = {
>> @@ -215,6 +285,9 @@ static const struct of_device_id exynos_adc_match[] = {
>> }, {
>> .compatible = "samsung,exynos-adc-v2",
>> .data = (void *)&exynos_adc_v2_data,
>> + }, {
>> + .compatible = "samsung,exynos3250-adc-v2",
>> + .data = (void *)&exynos3250_adc_v2_data,
>> },
>> {},
>
> Remove the '(void *)' cast here and mark the structure as 'const'.
> We intentionally use a 'const void *' type here to verify that
> the driver doesn't modify the per-device type data at runtime,
> which would be bad if you ever have multiple device instances.
OK, I'll remove it.
Thanks,
Chanwoo Choi
^ permalink raw reply
* [PATCH v3 0/3] Clean up ACPI core to prepare for running ACPI on ARM64
From: Hanjun Guo @ 2014-07-18 10:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch set have no function change for x86 and ia64 and
just do some clean up to prepare for running ACPI on ARM64.
This patch set is splited out from the patch set [1]
"[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig" and hope it
can be merged first before ARM64 ACPI core patches.
[1]: https://lkml.org/lkml/2014/6/26/627
update from v2:
Don not select ACPI_LEGACY_TABLES_LOOKUP on IA64 which
is catched by Peter.
update from v1:
1. Drop "Make EC debugfs depend on X86 || IA64 in Kconfig";
2. Rename ACPI_SCAN_BIOS_NOT_EFI to ACPI_LEGACY_TABLES_LOOKUP
suggested by Rafael;
3. Rename ARCH_HAS_ACPI_PDC to ARCH_MIGHT_HAVE_ACPI_PDC suggested by Rafael;
4. Remove the help for ARCH_MIGHT_HAVE_ACPI_PDC because it can't be selected;
5. Rename acpi_arch_is_smp() to acpi_has_cpu_in_madt() to be more
explicit and easy understanding.
Graeme Gregory (2):
ACPI: ARM64 does not have a BIOS add config for BIOS table scan.
ACPI: Don't use acpi_lapic in ACPI core code
Hanjun Guo (1):
ACPI / processor: Introduce ARCH_HAS_ACPI_PDC
arch/ia64/Kconfig | 1 +
arch/ia64/include/asm/acpi.h | 5 +
arch/x86/Kconfig | 2 +
arch/x86/include/asm/acpi.h | 5 +
drivers/acpi/Kconfig | 6 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_processor.c | 2 +-
drivers/acpi/internal.h | 5 +
drivers/acpi/osl.c | 4 +-
drivers/acpi/processor_core.c | 198 ---------------------------------------
drivers/acpi/processor_pdc.c | 206 +++++++++++++++++++++++++++++++++++++++++
11 files changed, 235 insertions(+), 200 deletions(-)
create mode 100644 drivers/acpi/processor_pdc.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v3 1/3] ACPI: ARM64 does not have a BIOS add config for BIOS table scan.
From: Hanjun Guo @ 2014-07-18 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405677774-16787-1-git-send-email-hanjun.guo@linaro.org>
From: Graeme Gregory <graeme.gregory@linaro.org>
With the addition of ARM64 that does not have a traditional BIOS to
scan, add a config option which is selected on x86 (ia64 doesn't need
it either, it is EFI/UEFI based system) to do the traditional BIOS
scanning for tables.
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/x86/Kconfig | 1 +
drivers/acpi/Kconfig | 3 +++
drivers/acpi/osl.c | 4 +++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a8f749e..6d9f1d8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -131,6 +131,7 @@ config X86
select HAVE_CC_STACKPROTECTOR
select GENERIC_CPU_AUTOPROBE
select HAVE_ARCH_AUDITSYSCALL
+ select ACPI_LEGACY_TABLES_LOOKUP if ACPI
config INSTRUCTION_DECODER
def_bool y
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index a34a228..970524c 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -42,6 +42,9 @@ menuconfig ACPI
if ACPI
+config ACPI_LEGACY_TABLES_LOOKUP
+ bool
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index bad25b0..3abe9b2 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -259,12 +259,14 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
"System description tables not found\n");
return 0;
}
- } else {
+ } else if (IS_ENABLED(CONFIG_ACPI_LEGACY_TABLES_LOOKUP)) {
acpi_physical_address pa = 0;
acpi_find_root_pointer(&pa);
return pa;
}
+
+ return 0;
}
/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/3] ACPI: Don't use acpi_lapic in ACPI core code
From: Hanjun Guo @ 2014-07-18 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405677774-16787-1-git-send-email-hanjun.guo@linaro.org>
From: Graeme Gregory <graeme.gregory@linaro.org>
Now ARM64 support is being added to ACPI so architecture specific
values can not be used in core ACPI code.
Following on the patch "ACPI / processor: Check if LAPIC is present
during initialization" which uses acpi_lapic in acpi_processor.c,
on ARM64 platform, GIC is used instead of local APIC, so acpi_lapic
is not a suitable value for ARM64.
What is actually important at this point is if there is/are CPU
entry/entries (Local APIC/SAPIC, GICC) in MADT, so introduce
acpi_has_cpu_in_madt() to be arch specific and generic.
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/ia64/include/asm/acpi.h | 5 +++++
arch/x86/include/asm/acpi.h | 5 +++++
drivers/acpi/acpi_processor.c | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index 75dc59a..a1d91ab 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -40,6 +40,11 @@ extern int acpi_lapic;
#define acpi_noirq 0 /* ACPI always enabled on IA64 */
#define acpi_pci_disabled 0 /* ACPI PCI always enabled on IA64 */
#define acpi_strict 1 /* no ACPI spec workarounds on IA64 */
+
+static inline bool acpi_has_cpu_in_madt(void)
+{
+ return !!acpi_lapic;
+}
#endif
#define acpi_processor_cstate_check(x) (x) /* no idle limits on IA64 :) */
static inline void disable_acpi(void) { }
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index e06225e..0ab4f9f 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -121,6 +121,11 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
}
+static inline bool acpi_has_cpu_in_madt(void)
+{
+ return !!acpi_lapic;
+}
+
#else /* !CONFIG_ACPI */
#define acpi_lapic 0
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 1c08574..1fdf5e0 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -268,7 +268,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
pr->apic_id = apic_id;
cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
- if (!cpu0_initialized && !acpi_lapic) {
+ if (!cpu0_initialized && !acpi_has_cpu_in_madt()) {
cpu0_initialized = 1;
/* Handle UP system running SMP kernel, with no LAPIC in MADT */
if ((cpu_index == -1) && (num_online_cpus() == 1))
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/3] ACPI / processor: Introduce ARCH_HAS_ACPI_PDC
From: Hanjun Guo @ 2014-07-18 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405677774-16787-1-git-send-email-hanjun.guo@linaro.org>
The use of _PDC is deprecated in ACPI 3.0 in favor of _OSC,
as ARM platform is supported only in ACPI 5.0 or higher version,
_PDC will not be used in ARM platform, so make Make _PDC only for
platforms with Intel CPUs.
Introduce ARCH_MIGHT_HAVE_ACPI_PDC and move _PDC related code in
ACPI processor driver into a single file processor_pdc.c, make x86
and ia64 select it when ACPI is enabled.
This patch also use pr_* to replace printk to fix the checkpatch
warning and factor acpi_processor_alloc_pdc() a little bit to
avoid duplicate pr_err() code.
Suggested-by: Robert Richter <rric@kernel.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/ia64/Kconfig | 1 +
arch/x86/Kconfig | 1 +
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/internal.h | 5 +
drivers/acpi/processor_core.c | 198 ---------------------------------------
drivers/acpi/processor_pdc.c | 206 +++++++++++++++++++++++++++++++++++++++++
7 files changed, 217 insertions(+), 198 deletions(-)
create mode 100644 drivers/acpi/processor_pdc.c
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 2f3abcf..44a6915 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -10,6 +10,7 @@ config IA64
select ARCH_MIGHT_HAVE_PC_SERIO
select PCI if (!IA64_HP_SIM)
select ACPI if (!IA64_HP_SIM)
+ select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select PM if (!IA64_HP_SIM)
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6d9f1d8..6fd5d66 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -21,6 +21,7 @@ config X86_64
### Arch settings
config X86
def_bool y
+ select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 970524c..3f5f745 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -45,6 +45,9 @@ if ACPI
config ACPI_LEGACY_TABLES_LOOKUP
bool
+config ARCH_MIGHT_HAVE_ACPI_PDC
+ bool
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index ea55e01..505d4d7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -36,6 +36,7 @@ acpi-y += scan.o
acpi-y += resource.o
acpi-y += acpi_processor.o
acpi-y += processor_core.o
+acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 151f3e7..4c5cf77 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -106,7 +106,12 @@ int acpi_power_transition(struct acpi_device *device, int state);
int acpi_device_update_power(struct acpi_device *device, int *state_p);
int acpi_wakeup_device_init(void);
+
+#ifdef CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC
void acpi_early_processor_set_pdc(void);
+#else
+static inline void acpi_early_processor_set_pdc(void) {}
+#endif
/* --------------------------------------------------------------------------
Embedded Controller
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 71e2065..00f48d1 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -4,17 +4,11 @@
*
* Alex Chiang <achiang@hp.com>
* - Unified x86/ia64 implementations
- * Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
- * - Added _PDC for platforms with Intel CPUs
*/
#include <linux/export.h>
-#include <linux/dmi.h>
-#include <linux/slab.h>
#include <linux/acpi.h>
#include <acpi/processor.h>
-#include "internal.h"
-
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
ACPI_MODULE_NAME("processor_core");
@@ -208,195 +202,3 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32 acpi_id)
return acpi_map_cpuid(apic_id, acpi_id);
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
-
-static bool __init processor_physically_present(acpi_handle handle)
-{
- int cpuid, type;
- u32 acpi_id;
- acpi_status status;
- acpi_object_type acpi_type;
- unsigned long long tmp;
- union acpi_object object = { 0 };
- struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
-
- status = acpi_get_type(handle, &acpi_type);
- if (ACPI_FAILURE(status))
- return false;
-
- switch (acpi_type) {
- case ACPI_TYPE_PROCESSOR:
- status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
- if (ACPI_FAILURE(status))
- return false;
- acpi_id = object.processor.proc_id;
- break;
- case ACPI_TYPE_DEVICE:
- status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
- if (ACPI_FAILURE(status))
- return false;
- acpi_id = tmp;
- break;
- default:
- return false;
- }
-
- type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
- cpuid = acpi_get_cpuid(handle, type, acpi_id);
-
- if (cpuid == -1)
- return false;
-
- return true;
-}
-
-static void acpi_set_pdc_bits(u32 *buf)
-{
- buf[0] = ACPI_PDC_REVISION_ID;
- buf[1] = 1;
-
- /* Enable coordination with firmware's _TSD info */
- buf[2] = ACPI_PDC_SMP_T_SWCOORD;
-
- /* Twiddle arch-specific bits needed for _PDC */
- arch_acpi_set_pdc_bits(buf);
-}
-
-static struct acpi_object_list *acpi_processor_alloc_pdc(void)
-{
- struct acpi_object_list *obj_list;
- union acpi_object *obj;
- u32 *buf;
-
- /* allocate and initialize pdc. It will be used later. */
- obj_list = kmalloc(sizeof(struct acpi_object_list), GFP_KERNEL);
- if (!obj_list) {
- printk(KERN_ERR "Memory allocation error\n");
- return NULL;
- }
-
- obj = kmalloc(sizeof(union acpi_object), GFP_KERNEL);
- if (!obj) {
- printk(KERN_ERR "Memory allocation error\n");
- kfree(obj_list);
- return NULL;
- }
-
- buf = kmalloc(12, GFP_KERNEL);
- if (!buf) {
- printk(KERN_ERR "Memory allocation error\n");
- kfree(obj);
- kfree(obj_list);
- return NULL;
- }
-
- acpi_set_pdc_bits(buf);
-
- obj->type = ACPI_TYPE_BUFFER;
- obj->buffer.length = 12;
- obj->buffer.pointer = (u8 *) buf;
- obj_list->count = 1;
- obj_list->pointer = obj;
-
- return obj_list;
-}
-
-/*
- * _PDC is required for a BIOS-OS handshake for most of the newer
- * ACPI processor features.
- */
-static acpi_status
-acpi_processor_eval_pdc(acpi_handle handle, struct acpi_object_list *pdc_in)
-{
- acpi_status status = AE_OK;
-
- if (boot_option_idle_override == IDLE_NOMWAIT) {
- /*
- * If mwait is disabled for CPU C-states, the C2C3_FFH access
- * mode will be disabled in the parameter of _PDC object.
- * Of course C1_FFH access mode will also be disabled.
- */
- union acpi_object *obj;
- u32 *buffer = NULL;
-
- obj = pdc_in->pointer;
- buffer = (u32 *)(obj->buffer.pointer);
- buffer[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
-
- }
- status = acpi_evaluate_object(handle, "_PDC", pdc_in, NULL);
-
- if (ACPI_FAILURE(status))
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "Could not evaluate _PDC, using legacy perf. control.\n"));
-
- return status;
-}
-
-void acpi_processor_set_pdc(acpi_handle handle)
-{
- struct acpi_object_list *obj_list;
-
- if (arch_has_acpi_pdc() == false)
- return;
-
- obj_list = acpi_processor_alloc_pdc();
- if (!obj_list)
- return;
-
- acpi_processor_eval_pdc(handle, obj_list);
-
- kfree(obj_list->pointer->buffer.pointer);
- kfree(obj_list->pointer);
- kfree(obj_list);
-}
-
-static acpi_status __init
-early_init_pdc(acpi_handle handle, u32 lvl, void *context, void **rv)
-{
- if (processor_physically_present(handle) == false)
- return AE_OK;
-
- acpi_processor_set_pdc(handle);
- return AE_OK;
-}
-
-#if defined(CONFIG_X86) || defined(CONFIG_IA64)
-static int __init set_no_mwait(const struct dmi_system_id *id)
-{
- pr_notice(PREFIX "%s detected - disabling mwait for CPU C-states\n",
- id->ident);
- boot_option_idle_override = IDLE_NOMWAIT;
- return 0;
-}
-
-static struct dmi_system_id processor_idle_dmi_table[] __initdata = {
- {
- set_no_mwait, "Extensa 5220", {
- DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"),
- DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "0100"),
- DMI_MATCH(DMI_BOARD_NAME, "Columbia") }, NULL},
- {},
-};
-
-static void __init processor_dmi_check(void)
-{
- /*
- * Check whether the system is DMI table. If yes, OSPM
- * should not use mwait for CPU-states.
- */
- dmi_check_system(processor_idle_dmi_table);
-}
-#else
-static inline void processor_dmi_check(void) {}
-#endif
-
-void __init acpi_early_processor_set_pdc(void)
-{
- processor_dmi_check();
-
- acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
- ACPI_UINT32_MAX,
- early_init_pdc, NULL, NULL, NULL);
- acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, early_init_pdc, NULL, NULL);
-}
diff --git a/drivers/acpi/processor_pdc.c b/drivers/acpi/processor_pdc.c
new file mode 100644
index 0000000..e5dd808
--- /dev/null
+++ b/drivers/acpi/processor_pdc.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) 2005 Intel Corporation
+ * Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
+ *
+ * Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
+ * - Added _PDC for platforms with Intel CPUs
+ */
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
+#include <linux/dmi.h>
+#include <linux/slab.h>
+#include <linux/acpi.h>
+#include <acpi/processor.h>
+
+#include "internal.h"
+
+#define _COMPONENT ACPI_PROCESSOR_COMPONENT
+ACPI_MODULE_NAME("processor_pdc");
+
+static bool __init processor_physically_present(acpi_handle handle)
+{
+ int cpuid, type;
+ u32 acpi_id;
+ acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long tmp;
+ union acpi_object object = { 0 };
+ struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
+
+ status = acpi_get_type(handle, &acpi_type);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = object.processor.proc_id;
+ break;
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, &tmp);
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = tmp;
+ break;
+ default:
+ return false;
+ }
+
+ type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
+ cpuid = acpi_get_cpuid(handle, type, acpi_id);
+
+ if (cpuid == -1)
+ return false;
+
+ return true;
+}
+
+static void acpi_set_pdc_bits(u32 *buf)
+{
+ buf[0] = ACPI_PDC_REVISION_ID;
+ buf[1] = 1;
+
+ /* Enable coordination with firmware's _TSD info */
+ buf[2] = ACPI_PDC_SMP_T_SWCOORD;
+
+ /* Twiddle arch-specific bits needed for _PDC */
+ arch_acpi_set_pdc_bits(buf);
+}
+
+static struct acpi_object_list *acpi_processor_alloc_pdc(void)
+{
+ struct acpi_object_list *obj_list;
+ union acpi_object *obj;
+ u32 *buf;
+
+ /* allocate and initialize pdc. It will be used later. */
+ obj_list = kmalloc(sizeof(struct acpi_object_list), GFP_KERNEL);
+ if (!obj_list)
+ goto out;
+
+ obj = kmalloc(sizeof(union acpi_object), GFP_KERNEL);
+ if (!obj) {
+ kfree(obj_list);
+ goto out;
+ }
+
+ buf = kmalloc(12, GFP_KERNEL);
+ if (!buf) {
+ kfree(obj);
+ kfree(obj_list);
+ goto out;
+ }
+
+ acpi_set_pdc_bits(buf);
+
+ obj->type = ACPI_TYPE_BUFFER;
+ obj->buffer.length = 12;
+ obj->buffer.pointer = (u8 *) buf;
+ obj_list->count = 1;
+ obj_list->pointer = obj;
+
+ return obj_list;
+out:
+ pr_err("Memory allocation error\n");
+ return NULL;
+}
+
+/*
+ * _PDC is required for a BIOS-OS handshake for most of the newer
+ * ACPI processor features.
+ */
+static acpi_status
+acpi_processor_eval_pdc(acpi_handle handle, struct acpi_object_list *pdc_in)
+{
+ acpi_status status = AE_OK;
+
+ if (boot_option_idle_override == IDLE_NOMWAIT) {
+ /*
+ * If mwait is disabled for CPU C-states, the C2C3_FFH access
+ * mode will be disabled in the parameter of _PDC object.
+ * Of course C1_FFH access mode will also be disabled.
+ */
+ union acpi_object *obj;
+ u32 *buffer = NULL;
+
+ obj = pdc_in->pointer;
+ buffer = (u32 *)(obj->buffer.pointer);
+ buffer[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
+
+ }
+ status = acpi_evaluate_object(handle, "_PDC", pdc_in, NULL);
+
+ if (ACPI_FAILURE(status))
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "Could not evaluate _PDC, using legacy perf. control.\n"));
+
+ return status;
+}
+
+void acpi_processor_set_pdc(acpi_handle handle)
+{
+ struct acpi_object_list *obj_list;
+
+ if (arch_has_acpi_pdc() == false)
+ return;
+
+ obj_list = acpi_processor_alloc_pdc();
+ if (!obj_list)
+ return;
+
+ acpi_processor_eval_pdc(handle, obj_list);
+
+ kfree(obj_list->pointer->buffer.pointer);
+ kfree(obj_list->pointer);
+ kfree(obj_list);
+}
+
+static acpi_status __init
+early_init_pdc(acpi_handle handle, u32 lvl, void *context, void **rv)
+{
+ if (processor_physically_present(handle) == false)
+ return AE_OK;
+
+ acpi_processor_set_pdc(handle);
+ return AE_OK;
+}
+
+static int __init set_no_mwait(const struct dmi_system_id *id)
+{
+ pr_notice("%s detected - disabling mwait for CPU C-states\n",
+ id->ident);
+ boot_option_idle_override = IDLE_NOMWAIT;
+ return 0;
+}
+
+static struct dmi_system_id processor_idle_dmi_table[] __initdata = {
+ {
+ set_no_mwait, "Extensa 5220", {
+ DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"),
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "0100"),
+ DMI_MATCH(DMI_BOARD_NAME, "Columbia") }, NULL},
+ {},
+};
+
+static void __init processor_dmi_check(void)
+{
+ /*
+ * Check whether the system is DMI table. If yes, OSPM
+ * should not use mwait for CPU-states.
+ */
+ dmi_check_system(processor_idle_dmi_table);
+}
+
+void __init acpi_early_processor_set_pdc(void)
+{
+ processor_dmi_check();
+
+ acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+ ACPI_UINT32_MAX,
+ early_init_pdc, NULL, NULL, NULL);
+ acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, early_init_pdc, NULL, NULL);
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCHv6 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
From: Naveen Krishna Ch @ 2014-07-18 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6186153.TIYp5NXPIq@wuerfel>
Hello Arnd,
On 18 July 2014 15:12, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 18 July 2014 14:59:43 Chanwoo Choi wrote:
>> This patchset add 'exynos_adc_data' structure which includes some functions
>> to control ADC operation and specific data according to ADC version (v1 or v2).
>>
>
> This new structure makes a lot of sense for covering the exynos specific
> versions, but it will likely give a little more complexity for the
> older models. We'll have to deal with that later then, no need to
> hold up your patch. Interestingly, the version numbers seem weird. The
> old driver uses
>
> {
> .name = "s3c24xx-adc",
> .driver_data = TYPE_ADCV1,
> }, {
> .name = "s3c2443-adc",
> .driver_data = TYPE_ADCV11,
> }, {
> .name = "s3c2416-adc",
> .driver_data = TYPE_ADCV12,
> }, {
> .name = "s3c64xx-adc",
> .driver_data = TYPE_ADCV2,
> }, {
> .name = "samsung-adc-v3",
> .driver_data = TYPE_ADCV3,
> }
>
> Where TYPE_ADCV3 seems to be the same as the new ADC_V1 used in this
> driver. Do you have an explanation for that?
As per suggestion from Doug Anderson,
I've implemented IIO based ADC driver to work with Exynos5250.
keeping the plat-samsung/adc.c unchanged.
Assuming Exynos5250 is the one using the driver for the first time.
i've named it v1 and so on.
Now, This seems to cause a lot of confusion.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shine bright,
(: Nav :)
^ permalink raw reply
* [PATCHv6 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Naveen Krishna Ch @ 2014-07-18 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <59765980.V0Hsx6tyKd@wuerfel>
Hello Arnd,
On 18 July 2014 15:08, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 18 July 2014 14:59:42 Chanwoo Choi wrote:
>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>> Exynos3250 has additional special clock for ADC IP.
>>
>
> by coincidence, I have just looked at the same driver in order to
> add support for s3c24xx and s3c64xx, so we can remove the plat-samsung
> adc framework they still use. Those changes would naturally conflict
> with yours, but I think it makes sense for your patches to come first.
>
> I'll comment a bit more on the individual patches. I didn't have
> interest in them earlier, so I didn't comment so far.
>
> Another aspect that came up is the touchscreen support. Right now,
> there is drivers/input/touchscreen/s3c2410_ts.c which is intimately
> tied to arch/arm/plat-samsung/adc.c. The best way forward (as discussed
> on IRC as few days ago) seems to be to integrate support for that into
> the exynos_adc driver. Can you comment on which parts actually support
> touchscreen? Did touchscreen support get dropped in the exynos hardware,
> or is the driver just missing at the moment?
SoCs from Samsung before Exynos4 had and ADC based Touch screen
and the driver under arch/arm/plat-samsung/adc.c and
drivers/input/touchscreen/s3c2410_ts.c used to work together.
Infact, the interrupt routine and priorities in plat-samsung/adc.c
driver as written keeping the Touchscreen in mind.
After Exynos4, ADC IP remained. But, the touch screen was removed in hardware.
As per suggestion from Doug Anderson, I've implemented IIO based ADC
driver started to support from exynos5250.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shine bright,
(: Nav :)
^ permalink raw reply
* [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
From: Will Deacon @ 2014-07-18 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrXG6nL4K=Er+kv5-CXBDVa0TLg9yR6iePnMyE2ufXgKkw@mail.gmail.com>
On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > The core mm code will provide a default gate area based on
> > FIXADDR_USER_START and FIXADDR_USER_END if
> > !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
> >
> > This default is only useful for ia64. arm64, ppc, s390, sh, tile,
> > 64-bit UML, and x86_32 have their own code just to disable it. arm,
> > 32-bit UML, and x86_64 have gate areas, but they have their own
> > implementations.
> >
> > This gets rid of the default and moves the code into ia64.
> >
> > This should save some code on architectures without a gate area: it's
> > now possible to inline the gate_area functions in the default case.
>
> Can one of you pull this somewhere? Otherwise I can put it somewhere
> stable and ask for -next inclusion, but that seems like overkill for a
> single patch.
I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
changes (or changes to other archs) to go via our tree.
I'm not sure what the best approach is if you want to send this via a single
tree. Maybe you could ask akpm nicely?
Will
^ permalink raw reply
* [PATCHv6 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Naveen Krishna Ch @ 2014-07-18 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHfPSqBiDZXxSVaK3PHrGhDQxi4TU=szKA06Odm9yeB8a5rDFw@mail.gmail.com>
Hello All,
On 18 July 2014 15:43, Naveen Krishna Ch <naveenkrishna.ch@gmail.com> wrote:
> Hello Arnd,
>
> On 18 July 2014 15:08, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Friday 18 July 2014 14:59:42 Chanwoo Choi wrote:
>>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>>> Exynos3250 has additional special clock for ADC IP.
>>>
>>
>> by coincidence, I have just looked at the same driver in order to
>> add support for s3c24xx and s3c64xx, so we can remove the plat-samsung
>> adc framework they still use. Those changes would naturally conflict
>> with yours, but I think it makes sense for your patches to come first.
>>
>> I'll comment a bit more on the individual patches. I didn't have
>> interest in them earlier, so I didn't comment so far.
>>
>> Another aspect that came up is the touchscreen support. Right now,
>> there is drivers/input/touchscreen/s3c2410_ts.c which is intimately
>> tied to arch/arm/plat-samsung/adc.c. The best way forward (as discussed
>> on IRC as few days ago) seems to be to integrate support for that into
>> the exynos_adc driver. Can you comment on which parts actually support
>> touchscreen? Did touchscreen support get dropped in the exynos hardware,
>> or is the driver just missing at the moment?
>
> SoCs from Samsung before Exynos4 had and ADC based Touch screen
> and the driver under arch/arm/plat-samsung/adc.c and
> drivers/input/touchscreen/s3c2410_ts.c used to work together.
>
> Infact, the interrupt routine and priorities in plat-samsung/adc.c
> driver as written keeping the Touchscreen in mind.
>
> After Exynos4, ADC IP remained. But, the touch screen was removed in hardware.
At least on Exynos4210> i'm not sure about the other Exynos4 series.
I will try to verify the user manuals.
>
> As per suggestion from Doug Anderson, I've implemented IIO based ADC
> driver started to support from exynos5250.
>
>>
>> Arnd
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Shine bright,
> (: Nav :)
--
Shine bright,
(: Nav :)
^ permalink raw reply
* [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
From: Richard Weinberger @ 2014-07-18 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718101416.GB1818@arm.com>
Am 18.07.2014 12:14, schrieb Will Deacon:
> On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
>> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> The core mm code will provide a default gate area based on
>>> FIXADDR_USER_START and FIXADDR_USER_END if
>>> !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
>>>
>>> This default is only useful for ia64. arm64, ppc, s390, sh, tile,
>>> 64-bit UML, and x86_32 have their own code just to disable it. arm,
>>> 32-bit UML, and x86_64 have gate areas, but they have their own
>>> implementations.
>>>
>>> This gets rid of the default and moves the code into ia64.
>>>
>>> This should save some code on architectures without a gate area: it's
>>> now possible to inline the gate_area functions in the default case.
>>
>> Can one of you pull this somewhere? Otherwise I can put it somewhere
>> stable and ask for -next inclusion, but that seems like overkill for a
>> single patch.
For the um bits:
Acked-by: Richard Weinberger <richard@nod.at>
> I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
> changes (or changes to other archs) to go via our tree.
>
> I'm not sure what the best approach is if you want to send this via a single
> tree. Maybe you could ask akpm nicely?
Going though Andrew's tree sounds sane to me.
Thanks,
//richard
^ permalink raw reply
* [PATCH] cpufreq: tests: Providing cpufreq regression test
From: Lukasz Majewski @ 2014-07-18 10:23 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds first regression test "cpufreq_freq_test.sh" for the
cpufreq subsystem.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
---
drivers/cpufreq/tests/README | 23 +++++
drivers/cpufreq/tests/cpufreq_freq_test.sh | 149 +++++++++++++++++++++++++++++
2 files changed, 172 insertions(+)
create mode 100644 drivers/cpufreq/tests/README
create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh
diff --git a/drivers/cpufreq/tests/README b/drivers/cpufreq/tests/README
new file mode 100644
index 0000000..66638d2
--- /dev/null
+++ b/drivers/cpufreq/tests/README
@@ -0,0 +1,23 @@
+This file contains list of cpufreq's available regression tests with a short
+usage description.
+
+1. cpufreq_freq_test.sh
+
+Description:
+------------
+This test is supposed to test if cpufreq attributes exported by sysfs are
+exposing a correct values.
+
+It can work with or without boost enabled and helps spotting errors related to
+cpufreq and common clock framework.
+
+Used attributes:
+----------------
+- "scaling_available_frequencies"
+- "cpuinfo_cur_freq"
+- "scaling_governor"
+
+Target devices:
+---------------
+
+All devices which exports mentioned above sysfs attributes.
\ No newline at end of file
diff --git a/drivers/cpufreq/tests/cpufreq_freq_test.sh b/drivers/cpufreq/tests/cpufreq_freq_test.sh
new file mode 100755
index 0000000..53156ca
--- /dev/null
+++ b/drivers/cpufreq/tests/cpufreq_freq_test.sh
@@ -0,0 +1,149 @@
+#!/bin/bash
+#
+# This file provides a simple mean to test if all declared freqs at
+# "scaling_available_frequencies" can be set and if "cpuinfo_cur_freq"
+# returns this value.
+#
+# Usage: ./cpufreq_freq_test.sh
+# Requisite: Compile in "performance" governor
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, you can access it online at
+# http://www.gnu.org/licenses/gpl-2.0.html.
+#
+# Copyright (C) Samsung Electronics, 2014
+#
+# Author: Lukasz Majewski <l.majewski@samsung.com>
+
+set +x
+
+COLOUR_RED="\33[31m"
+COLOUR_BLUE="\33[34m"
+COLOUR_GREEN="\33[32m"
+COLOUR_DEFAULT="\33[0m"
+
+T_PATCH=/sys/devices/system/cpu/cpu0/cpufreq
+BOOST_PATCH=/sys/devices/system/cpu/cpufreq
+
+if [ ! -d "$T_PATCH" ]; then
+ printf " $COLOUR_RED No patch to CPUFREQ $COLOUR_DEFAULT\n"
+ exit 1
+fi
+
+ERRORS=0
+
+OLD_GOV=`cat $T_PATCH/scaling_governor`
+echo "CURRENT GOVERNOR: $OLD_GOV"
+echo "SET GOVERNOR: performance"
+echo "performance" > $T_PATCH/scaling_governor
+
+function test_freqs1 {
+ FREQS=`cat $1`
+ for I in $FREQS; do
+ cpufreq_set_freq $I
+ if [ "$2" ]; then
+ printf "$COLOUR_BLUE BOOST $COLOUR_DEFAULT" $I
+ fi
+ cpufreq_test_freq $I
+ done
+}
+
+function test_freqs2 {
+ FREQ=`cat $1`
+ FREQS_ARRAY=($FREQ)
+
+ for freq in ${FREQS_ARRAY[@]}
+ do
+ echo "REFERENCE FREQ: $freq"
+ for f in ${FREQS_ARRAY[@]}
+ do
+ cpufreq_set_freq $freq
+ echo -n "----> "
+ cpufreq_set_freq $f
+ cpufreq_test_freq $f
+ done
+ done
+}
+
+function restore {
+ if [ -f $BOOST_PATCH/boost ]; then
+ cpufreq_boost_state $BOOST_STATE
+ fi
+
+ echo "SET GOVERNOR: $OLD_GOV"
+ echo $OLD_GOV > $T_PATCH/scaling_governor
+}
+
+function die {
+ printf " $COLOUR_RED FAILED $COLOUR_DEFAULT\n"
+ restore_gov
+ exit 1
+}
+
+function cpufreq_test_freq {
+ gzip < /dev/urandom > /dev/null &
+ pid=$!
+ sleep 0.1
+ CURR_FREQ=`cat $T_PATCH/cpuinfo_cur_freq`
+ if [ $1 -eq $CURR_FREQ ]; then
+ printf "\t$COLOUR_GREEN OK $COLOUR_DEFAULT\n"
+ else
+ printf "$COLOUR_RED CURRENT $CURR_FREQ $COLOUR_DEFAULT\n"
+ ERRORS=`expr $ERRORS + 1`
+ #die
+ fi
+ kill -9 $pid
+ wait $! 2>/dev/null
+}
+
+function cpufreq_set_freq {
+ echo $1 > $T_PATCH/scaling_max_freq || die $?
+ printf "FREQ:$COLOUR_GREEN %s $COLOUR_DEFAULT" $1
+}
+
+function cpufreq_boost_state {
+ echo $1 > $BOOST_PATCH/boost
+}
+
+function cpufreq_boost_status {
+ cat $BOOST_PATCH/boost
+}
+
+if [ -f $BOOST_PATCH/boost ]; then
+ echo "######################################"
+ echo "TEST BOOST OPERATION"
+ echo "######################################"
+
+ BOOST_STATE=$(cpufreq_boost_status)
+ if [ $BOOST_STATE -eq 0 ]; then
+ cpufreq_boost_state 1
+ fi
+ test_freqs1 $T_PATCH/scaling_boost_frequencies 1
+fi
+
+echo "######################################"
+echo "TEST AVAILABLE FREQS"
+echo "######################################"
+test_freqs1 $T_PATCH/scaling_available_frequencies
+
+echo "######################################"
+echo "TEST FREQS SWITCHING"
+echo "######################################"
+test_freqs2 $T_PATCH/scaling_available_frequencies
+
+echo "######################################"
+echo "ERRORS: $ERRORS"
+echo "######################################"
+
+restore
+exit 0
--
2.0.0.rc2
^ permalink raw reply related
* [PATCH v5 7/8] ata: Add support for the Tegra124 SATA controller
From: Hans de Goede @ 2014-07-18 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405667550-7707-1-git-send-email-mperttunen@nvidia.com>
Hi,
On 07/18/2014 09:12 AM, Mikko Perttunen wrote:
> This adds support for the integrated AHCI-compliant Serial ATA
> controller present on the NVIDIA Tegra124 system-on-chip.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> v5: let ahci_platform handle sata clock and also handle it ourselves.
> this allows use of ahci_platform while having a special sequence
> for the clock.
Thanks, I like this one, much better then what we had before.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
>
> drivers/ata/Kconfig | 9 ++
> drivers/ata/Makefile | 1 +
> drivers/ata/ahci_tegra.c | 377 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 387 insertions(+)
> create mode 100644 drivers/ata/ahci_tegra.c
>
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index b0d5b5a..e1b9278 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -142,6 +142,15 @@ config AHCI_SUNXI
>
> If unsure, say N.
>
> +config AHCI_TEGRA
> + tristate "NVIDIA Tegra124 AHCI SATA support"
> + depends on ARCH_TEGRA
> + help
> + This option enables support for the NVIDIA Tegra124 SoC's
> + onboard AHCI SATA.
> +
> + If unsure, say N.
> +
> config AHCI_XGENE
> tristate "APM X-Gene 6.0Gbps AHCI SATA host controller support"
> depends on PHY_XGENE
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index 5a02aee..ae41107 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o libahci_platform.o
> obj-$(CONFIG_AHCI_MVEBU) += ahci_mvebu.o libahci.o libahci_platform.o
> obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o libahci_platform.o
> obj-$(CONFIG_AHCI_ST) += ahci_st.o libahci.o libahci_platform.o
> +obj-$(CONFIG_AHCI_TEGRA) += ahci_tegra.o libahci.o libahci_platform.o
> obj-$(CONFIG_AHCI_XGENE) += ahci_xgene.o libahci.o libahci_platform.o
>
> # SFF w/ custom DMA
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> new file mode 100644
> index 0000000..d30bb21
> --- /dev/null
> +++ b/drivers/ata/ahci_tegra.c
> @@ -0,0 +1,377 @@
> +/*
> + * drivers/ata/ahci_tegra.c
> + *
> + * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
> + *
> + * Author:
> + * Mikko Perttunen <mperttunen@nvidia.com>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/ahci_platform.h>
> +#include <linux/reset.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/tegra-powergate.h>
> +#include <linux/regulator/consumer.h>
> +#include "ahci.h"
> +
> +#define SATA_CONFIGURATION_0 0x180
> +#define SATA_CONFIGURATION_EN_FPCI BIT(0)
> +
> +#define SCFG_OFFSET 0x1000
> +
> +#define T_SATA0_CFG_1 0x04
> +#define T_SATA0_CFG_1_IO_SPACE BIT(0)
> +#define T_SATA0_CFG_1_MEMORY_SPACE BIT(1)
> +#define T_SATA0_CFG_1_BUS_MASTER BIT(2)
> +#define T_SATA0_CFG_1_SERR BIT(8)
> +
> +#define T_SATA0_CFG_9 0x24
> +#define T_SATA0_CFG_9_BASE_ADDRESS_SHIFT 13
> +
> +#define SATA_FPCI_BAR5 0x94
> +#define SATA_FPCI_BAR5_START_SHIFT 4
> +
> +#define SATA_INTR_MASK 0x188
> +#define SATA_INTR_MASK_IP_INT_MASK BIT(16)
> +
> +#define T_SATA0_AHCI_HBA_CAP_BKDR 0x300
> +
> +#define T_SATA0_BKDOOR_CC 0x4a4
> +
> +#define T_SATA0_CFG_SATA 0x54c
> +#define T_SATA0_CFG_SATA_BACKDOOR_PROG_IF_EN BIT(12)
> +
> +#define T_SATA0_CFG_MISC 0x550
> +
> +#define T_SATA0_INDEX 0x680
> +
> +#define T_SATA0_CHX_PHY_CTRL1_GEN1 0x690
> +#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_MASK 0xff
> +#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_SHIFT 0
> +#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_MASK (0xff << 8)
> +#define T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_SHIFT 8
> +
> +#define T_SATA0_CHX_PHY_CTRL1_GEN2 0x694
> +#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_AMP_MASK 0xff
> +#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_AMP_SHIFT 0
> +#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_PEAK_MASK (0xff << 12)
> +#define T_SATA0_CHX_PHY_CTRL1_GEN2_TX_PEAK_SHIFT 12
> +
> +#define T_SATA0_CHX_PHY_CTRL2 0x69c
> +#define T_SATA0_CHX_PHY_CTRL2_CDR_CNTL_GEN1 0x23
> +
> +#define T_SATA0_CHX_PHY_CTRL11 0x6d0
> +#define T_SATA0_CHX_PHY_CTRL11_GEN2_RX_EQ (0x2800 << 16)
> +
> +#define FUSE_SATA_CALIB 0x124
> +#define FUSE_SATA_CALIB_MASK 0x3
> +
> +struct sata_pad_calibration {
> + u8 gen1_tx_amp;
> + u8 gen1_tx_peak;
> + u8 gen2_tx_amp;
> + u8 gen2_tx_peak;
> +};
> +
> +static const struct sata_pad_calibration tegra124_pad_calibration[] = {
> + {0x18, 0x04, 0x18, 0x0a},
> + {0x0e, 0x04, 0x14, 0x0a},
> + {0x0e, 0x07, 0x1a, 0x0e},
> + {0x14, 0x0e, 0x1a, 0x0e},
> +};
> +
> +struct tegra_ahci_priv {
> + struct platform_device *pdev;
> + void __iomem *sata_regs;
> + struct reset_control *sata_rst;
> + struct reset_control *sata_oob_rst;
> + struct reset_control *sata_cold_rst;
> + /* Needs special handling, cannot use ahci_platform */
> + struct clk *sata_clk;
> + struct regulator_bulk_data supplies[5];
> +};
> +
> +static int tegra_ahci_power_on(struct ahci_host_priv *hpriv)
> +{
> + struct tegra_ahci_priv *tegra = hpriv->plat_data;
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(tegra->supplies),
> + tegra->supplies);
> + if (ret)
> + return ret;
> +
> + ret = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_SATA,
> + tegra->sata_clk,
> + tegra->sata_rst);
> + if (ret)
> + goto disable_regulators;
> +
> + reset_control_assert(tegra->sata_oob_rst);
> + reset_control_assert(tegra->sata_cold_rst);
> +
> + ret = ahci_platform_enable_resources(hpriv);
> + if (ret)
> + goto disable_power;
> +
> + reset_control_deassert(tegra->sata_cold_rst);
> + reset_control_deassert(tegra->sata_oob_rst);
> +
> + return 0;
> +
> +disable_power:
> + clk_disable_unprepare(tegra->sata_clk);
> +
> + tegra_powergate_power_off(TEGRA_POWERGATE_SATA);
> +
> +disable_regulators:
> + regulator_bulk_disable(ARRAY_SIZE(tegra->supplies), tegra->supplies);
> +
> + return ret;
> +}
> +
> +static void tegra_ahci_power_off(struct ahci_host_priv *hpriv)
> +{
> + struct tegra_ahci_priv *tegra = hpriv->plat_data;
> +
> + ahci_platform_disable_resources(hpriv);
> +
> + reset_control_assert(tegra->sata_rst);
> + reset_control_assert(tegra->sata_oob_rst);
> + reset_control_assert(tegra->sata_cold_rst);
> +
> + clk_disable_unprepare(tegra->sata_clk);
> + tegra_powergate_power_off(TEGRA_POWERGATE_SATA);
> +
> + regulator_bulk_disable(ARRAY_SIZE(tegra->supplies), tegra->supplies);
> +}
> +
> +static int tegra_ahci_controller_init(struct ahci_host_priv *hpriv)
> +{
> + struct tegra_ahci_priv *tegra = hpriv->plat_data;
> + int ret;
> + unsigned int val;
> + struct sata_pad_calibration calib;
> +
> + ret = tegra_ahci_power_on(hpriv);
> + if (ret) {
> + dev_err(&tegra->pdev->dev,
> + "failed to power on AHCI controller: %d\n", ret);
> + return ret;
> + }
> +
> + val = readl(tegra->sata_regs + SATA_CONFIGURATION_0);
> + val |= SATA_CONFIGURATION_EN_FPCI;
> + writel(val, tegra->sata_regs + SATA_CONFIGURATION_0);
> +
> + /* Pad calibration */
> +
> + /* FIXME Always use calibration 0. Change this to read the calibration
> + * fuse once the fuse driver has landed. */
> + val = 0;
> +
> + calib = tegra124_pad_calibration[val & FUSE_SATA_CALIB_MASK];
> +
> + writel(BIT(0), tegra->sata_regs + SCFG_OFFSET + T_SATA0_INDEX);
> +
> + val = readl(tegra->sata_regs +
> + SCFG_OFFSET + T_SATA0_CHX_PHY_CTRL1_GEN1);
> + val &= ~T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_MASK;
> + val &= ~T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_MASK;
> + val |= calib.gen1_tx_amp <<
> + T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_SHIFT;
> + val |= calib.gen1_tx_peak <<
> + T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_SHIFT;
> + writel(val, tegra->sata_regs + SCFG_OFFSET +
> + T_SATA0_CHX_PHY_CTRL1_GEN1);
> +
> + val = readl(tegra->sata_regs +
> + SCFG_OFFSET + T_SATA0_CHX_PHY_CTRL1_GEN2);
> + val &= ~T_SATA0_CHX_PHY_CTRL1_GEN2_TX_AMP_MASK;
> + val &= ~T_SATA0_CHX_PHY_CTRL1_GEN2_TX_PEAK_MASK;
> + val |= calib.gen2_tx_amp <<
> + T_SATA0_CHX_PHY_CTRL1_GEN1_TX_AMP_SHIFT;
> + val |= calib.gen2_tx_peak <<
> + T_SATA0_CHX_PHY_CTRL1_GEN1_TX_PEAK_SHIFT;
> + writel(val, tegra->sata_regs + SCFG_OFFSET +
> + T_SATA0_CHX_PHY_CTRL1_GEN2);
> +
> + writel(T_SATA0_CHX_PHY_CTRL11_GEN2_RX_EQ,
> + tegra->sata_regs + SCFG_OFFSET + T_SATA0_CHX_PHY_CTRL11);
> + writel(T_SATA0_CHX_PHY_CTRL2_CDR_CNTL_GEN1,
> + tegra->sata_regs + SCFG_OFFSET + T_SATA0_CHX_PHY_CTRL2);
> +
> + writel(0, tegra->sata_regs + SCFG_OFFSET + T_SATA0_INDEX);
> +
> + /* Program controller device ID */
> +
> + val = readl(tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_SATA);
> + val |= T_SATA0_CFG_SATA_BACKDOOR_PROG_IF_EN;
> + writel(val, tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_SATA);
> +
> + writel(0x01060100, tegra->sata_regs + SCFG_OFFSET + T_SATA0_BKDOOR_CC);
> +
> + val = readl(tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_SATA);
> + val &= ~T_SATA0_CFG_SATA_BACKDOOR_PROG_IF_EN;
> + writel(val, tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_SATA);
> +
> + /* Enable IO & memory access, bus master mode */
> +
> + val = readl(tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_1);
> + val |= T_SATA0_CFG_1_IO_SPACE | T_SATA0_CFG_1_MEMORY_SPACE |
> + T_SATA0_CFG_1_BUS_MASTER | T_SATA0_CFG_1_SERR;
> + writel(val, tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_1);
> +
> + /* Program SATA MMIO */
> +
> + writel(0x10000 << SATA_FPCI_BAR5_START_SHIFT,
> + tegra->sata_regs + SATA_FPCI_BAR5);
> +
> + writel(0x08000 << T_SATA0_CFG_9_BASE_ADDRESS_SHIFT,
> + tegra->sata_regs + SCFG_OFFSET + T_SATA0_CFG_9);
> +
> + /* Unmask SATA interrupts */
> +
> + val = readl(tegra->sata_regs + SATA_INTR_MASK);
> + val |= SATA_INTR_MASK_IP_INT_MASK;
> + writel(val, tegra->sata_regs + SATA_INTR_MASK);
> +
> + return 0;
> +}
> +
> +static void tegra_ahci_controller_deinit(struct ahci_host_priv *hpriv)
> +{
> + tegra_ahci_power_off(hpriv);
> +}
> +
> +static void tegra_ahci_host_stop(struct ata_host *host)
> +{
> + struct ahci_host_priv *hpriv = host->private_data;
> +
> + tegra_ahci_controller_deinit(hpriv);
> +}
> +
> +static struct ata_port_operations ahci_tegra_port_ops = {
> + .inherits = &ahci_ops,
> + .host_stop = tegra_ahci_host_stop,
> +};
> +
> +static const struct ata_port_info ahci_tegra_port_info = {
> + .flags = AHCI_FLAG_COMMON,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = &ahci_tegra_port_ops,
> +};
> +
> +static const struct of_device_id tegra_ahci_of_match[] = {
> + { .compatible = "nvidia,tegra124-ahci" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, tegra_ahci_of_match);
> +
> +static int tegra_ahci_probe(struct platform_device *pdev)
> +{
> + struct ahci_host_priv *hpriv;
> + struct tegra_ahci_priv *tegra;
> + struct resource *res;
> + int ret;
> +
> + hpriv = ahci_platform_get_resources(pdev);
> + if (IS_ERR(hpriv))
> + return PTR_ERR(hpriv);
> +
> + tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
> + if (!tegra)
> + return -ENOMEM;
> +
> + hpriv->plat_data = tegra;
> +
> + tegra->pdev = pdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + tegra->sata_regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(tegra->sata_regs))
> + return PTR_ERR(tegra->sata_regs);
> +
> + tegra->sata_rst = devm_reset_control_get(&pdev->dev, "sata");
> + if (IS_ERR(tegra->sata_rst)) {
> + dev_err(&pdev->dev, "Failed to get sata reset\n");
> + return PTR_ERR(tegra->sata_rst);
> + }
> +
> + tegra->sata_oob_rst = devm_reset_control_get(&pdev->dev, "sata-oob");
> + if (IS_ERR(tegra->sata_oob_rst)) {
> + dev_err(&pdev->dev, "Failed to get sata-oob reset\n");
> + return PTR_ERR(tegra->sata_oob_rst);
> + }
> +
> + tegra->sata_cold_rst = devm_reset_control_get(&pdev->dev, "sata-cold");
> + if (IS_ERR(tegra->sata_cold_rst)) {
> + dev_err(&pdev->dev, "Failed to get sata-cold reset\n");
> + return PTR_ERR(tegra->sata_cold_rst);
> + }
> +
> + tegra->sata_clk = devm_clk_get(&pdev->dev, "sata");
> + if (IS_ERR(tegra->sata_clk)) {
> + dev_err(&pdev->dev, "Failed to get sata clock\n");
> + return PTR_ERR(tegra->sata_clk);
> + }
> +
> + tegra->supplies[0].supply = "avdd";
> + tegra->supplies[1].supply = "hvdd";
> + tegra->supplies[2].supply = "vddio";
> + tegra->supplies[3].supply = "target-5v";
> + tegra->supplies[4].supply = "target-12v";
> +
> + ret = devm_regulator_bulk_get(&pdev->dev, ARRAY_SIZE(tegra->supplies),
> + tegra->supplies);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to get regulators\n");
> + return ret;
> + }
> +
> + ret = tegra_ahci_controller_init(hpriv);
> + if (ret)
> + return ret;
> +
> + ret = ahci_platform_init_host(pdev, hpriv, &ahci_tegra_port_info,
> + 0, 0, 0);
> + if (ret)
> + goto deinit_controller;
> +
> + return 0;
> +
> +deinit_controller:
> + tegra_ahci_controller_deinit(hpriv);
> +
> + return ret;
> +};
> +
> +static struct platform_driver tegra_ahci_driver = {
> + .probe = tegra_ahci_probe,
> + .remove = ata_platform_remove_one,
> + .driver = {
> + .name = "tegra-ahci",
> + .of_match_table = tegra_ahci_of_match,
> + },
> + /* LP0 suspend support not implemented */
> +};
> +module_platform_driver(tegra_ahci_driver);
> +
> +MODULE_AUTHOR("Mikko Perttunen <mperttunen@nvidia.com>");
> +MODULE_DESCRIPTION("Tegra124 AHCI SATA driver");
> +MODULE_LICENSE("GPL v2");
>
^ permalink raw reply
* [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding
From: Hans de Goede @ 2014-07-18 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405667500-7402-1-git-send-email-mperttunen@nvidia.com>
Hi,
On 07/18/2014 09:11 AM, Mikko Perttunen wrote:
> This patch adds device tree binding documentation for the SATA
> controller found on NVIDIA Tegra SoCs.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> v5: remove ordering requirement again
Acked-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
>
> .../devicetree/bindings/ata/tegra-sata.txt | 30 ++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ata/tegra-sata.txt
>
> diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt b/Documentation/devicetree/bindings/ata/tegra-sata.txt
> new file mode 100644
> index 0000000..946f207
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/tegra-sata.txt
> @@ -0,0 +1,30 @@
> +Tegra124 SoC SATA AHCI controller
> +
> +Required properties :
> +- compatible : "nvidia,tegra124-ahci".
> +- reg : Should contain 2 entries:
> + - AHCI register set (SATA BAR5)
> + - SATA register set
> +- interrupts : Defines the interrupt used by SATA
> +- clocks : Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names : Must include the following entries:
> + - sata
> + - sata-oob
> + - cml1
> + - pll_e
> +- resets : Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> +- reset-names : Must include the following entries:
> + - sata
> + - sata-oob
> + - sata-cold
> +- phys : Must contain an entry for each entry in phy-names.
> + See ../phy/phy-bindings.txt for details.
> +- phy-names : Must include the following entries:
> + - sata-phy : XUSB PADCTL SATA PHY
> +- hvdd-supply : Defines the SATA HVDD regulator
> +- vddio-supply : Defines the SATA VDDIO regulator
> +- avdd-supply : Defines the SATA AVDD regulator
> +- target-5v-supply : Defines the SATA 5V power regulator
> +- target-12v-supply : Defines the SATA 12V power regulator
>
^ permalink raw reply
* [PATCH v5 1/8] of: Add NVIDIA Tegra SATA controller binding
From: Hans de Goede @ 2014-07-18 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C8C9BD.3070709@nvidia.com>
Hi,
On 07/18/2014 09:16 AM, Mikko Perttunen wrote:
> So here's v5: this time, as suggested, I handle the sata clock myself and let ahci_platform handle it too, leading it to be prepared+enabled twice. This works fine, and allows us to remove the DT ordering requirement.
>
> I also have in the works a patchset that adds the name-based ahci_platform_get_resources function, but that is not quite ready yet, even if it is quite far along. Also, I am going on vacation and returning on 28.7., so if this v5 is acceptable maybe it could be merged for 3.17 and I could work on the new get_resources scheme after I get back from vacation?
Yes that works for me v3 of all the patches with no newer version +
v5 of patch 1 and 7 are pretty clean and can go into 3.17 from my pov,
Tejun can you pick these up for 3.17 please?
And thanks for working on a name-based ahci_platform_get_resources function
since what we've now in v5 is quite clean already I think it will be good
to take our time to get this right, so postponing this to 3.18 is fine
with me.
Regards,
Hans
^ 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