* [PATCH] dt-bindings: qcom: Fix warning with duplicate dt define
From: Mike Turquette @ 2014-01-27 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390007119-4544-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-17 17:05:19)
> arch/arm/boot/dts/include/dt-bindings/clock/qcom,mmcc-msm8974.h:60:0:
> warning: "RBCPR_CLK_SRC" redefined
>
> Rename this to MMSS_RBCPR_CLK_SRC to avoid conflicts with the
> RBCPR clock in the gcc header.
>
> Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Thanks for the fix. I've pulled this into part 2 of my pull request.
Regards,
Mike
> ---
> include/dt-bindings/clock/qcom,mmcc-msm8974.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/clock/qcom,mmcc-msm8974.h b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> index 04d318d1187a..032ed87ef0f3 100644
> --- a/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> +++ b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> @@ -57,7 +57,7 @@
> #define EXTPCLK_CLK_SRC 40
> #define HDMI_CLK_SRC 41
> #define VSYNC_CLK_SRC 42
> -#define RBCPR_CLK_SRC 43
> +#define MMSS_RBCPR_CLK_SRC 43
> #define CAMSS_CCI_CCI_AHB_CLK 44
> #define CAMSS_CCI_CCI_CLK 45
> #define CAMSS_CSI0_AHB_CLK 46
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH RESEND TAKE 3] clk: si5351: remove variant from platform_data
From: Mike Turquette @ 2014-01-27 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390682911-9022-1-git-send-email-sebastian.hesselbarth@gmail.com>
Quoting Sebastian Hesselbarth (2014-01-25 12:48:31)
> Commit 9807362bfe1748d9bb48eecb9261f1b1aaafea1c
> "clk: si5351: declare all device IDs for module loading"
> removed the common i2c_device_id and introduced new ones for each variant
> of the clock generator. Instead of exploiting that information in the driver,
> it still depends on platform_data passing the chips .variant.
>
> This removes the now redundant .variant from the platform_data and puts it in
> i2c_device_id's .driver_data instead.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Mike,
>
> this is the patch I mentioned during ARM summit ;). Still applies to
> pre-v3.14-rc1 cleanly. Maybe it is time to take it now?
Hi Sebastian,
You're right, I overlooked this one. I've taken it in now.
Regards,
Mike
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/clk/clk-si5351.c | 28 ++++++++++++----------------
> drivers/clk/clk-si5351.h | 14 ++++++++++++++
> include/linux/platform_data/si5351.h | 16 ----------------
> 3 files changed, 26 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index c50e837..b95aa09 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -1111,11 +1111,11 @@ static const struct of_device_id si5351_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, si5351_dt_ids);
>
> -static int si5351_dt_parse(struct i2c_client *client)
> +static int si5351_dt_parse(struct i2c_client *client,
> + enum si5351_variant variant)
> {
> struct device_node *child, *np = client->dev.of_node;
> struct si5351_platform_data *pdata;
> - const struct of_device_id *match;
> struct property *prop;
> const __be32 *p;
> int num = 0;
> @@ -1124,15 +1124,10 @@ static int si5351_dt_parse(struct i2c_client *client)
> if (np == NULL)
> return 0;
>
> - match = of_match_node(si5351_dt_ids, np);
> - if (match == NULL)
> - return -EINVAL;
> -
> pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> return -ENOMEM;
>
> - pdata->variant = (enum si5351_variant)match->data;
> pdata->clk_xtal = of_clk_get(np, 0);
> if (!IS_ERR(pdata->clk_xtal))
> clk_put(pdata->clk_xtal);
> @@ -1163,7 +1158,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> break;
> case 1:
> - if (pdata->variant != SI5351_VARIANT_C) {
> + if (variant != SI5351_VARIANT_C) {
> dev_err(&client->dev,
> "invalid parent %d for pll %d\n",
> val, num);
> @@ -1187,7 +1182,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> }
>
> if (num >= 8 ||
> - (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
> + (variant == SI5351_VARIANT_A3 && num >= 3)) {
> dev_err(&client->dev, "invalid clkout %d\n", num);
> return -EINVAL;
> }
> @@ -1226,7 +1221,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> SI5351_CLKOUT_SRC_XTAL;
> break;
> case 3:
> - if (pdata->variant != SI5351_VARIANT_C) {
> + if (variant != SI5351_VARIANT_C) {
> dev_err(&client->dev,
> "invalid parent %d for clkout %d\n",
> val, num);
> @@ -1307,6 +1302,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> static int si5351_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> + enum si5351_variant variant = (enum si5351_variant)id->driver_data;
> struct si5351_platform_data *pdata;
> struct si5351_driver_data *drvdata;
> struct clk_init_data init;
> @@ -1315,7 +1311,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
> u8 num_parents, num_clocks;
> int ret, n;
>
> - ret = si5351_dt_parse(client);
> + ret = si5351_dt_parse(client, variant);
> if (ret)
> return ret;
>
> @@ -1331,7 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, drvdata);
> drvdata->client = client;
> - drvdata->variant = pdata->variant;
> + drvdata->variant = variant;
> drvdata->pxtal = pdata->clk_xtal;
> drvdata->pclkin = pdata->clk_clkin;
>
> @@ -1568,10 +1564,10 @@ static int si5351_i2c_probe(struct i2c_client *client,
> }
>
> static const struct i2c_device_id si5351_i2c_ids[] = {
> - { "si5351a", 0 },
> - { "si5351a-msop", 0 },
> - { "si5351b", 0 },
> - { "si5351c", 0 },
> + { "si5351a", SI5351_VARIANT_A },
> + { "si5351a-msop", SI5351_VARIANT_A3 },
> + { "si5351b", SI5351_VARIANT_B },
> + { "si5351c", SI5351_VARIANT_C },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> index c0dbf26..4d0746b 100644
> --- a/drivers/clk/clk-si5351.h
> +++ b/drivers/clk/clk-si5351.h
> @@ -153,4 +153,18 @@
> #define SI5351_XTAL_ENABLE (1<<6)
> #define SI5351_MULTISYNTH_ENABLE (1<<4)
>
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> + SI5351_VARIANT_A = 1,
> + SI5351_VARIANT_A3 = 2,
> + SI5351_VARIANT_B = 3,
> + SI5351_VARIANT_C = 4,
> +};
> +
> #endif
> diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
> index 5433439..a947ab8 100644
> --- a/include/linux/platform_data/si5351.h
> +++ b/include/linux/platform_data/si5351.h
> @@ -8,20 +8,6 @@
> struct clk;
>
> /**
> - * enum si5351_variant - SiLabs Si5351 chip variant
> - * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> - * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> - * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> - * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> - */
> -enum si5351_variant {
> - SI5351_VARIANT_A = 1,
> - SI5351_VARIANT_A3 = 2,
> - SI5351_VARIANT_B = 3,
> - SI5351_VARIANT_C = 4,
> -};
> -
> -/**
> * enum si5351_pll_src - Si5351 pll clock source
> * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> @@ -115,14 +101,12 @@ struct si5351_clkout_config {
>
> /**
> * struct si5351_platform_data - Platform data for the Si5351 clock driver
> - * @variant: Si5351 chip variant
> * @clk_xtal: xtal input clock
> * @clk_clkin: clkin input clock
> * @pll_src: array of pll source clock setting
> * @clkout: array of clkout configuration
> */
> struct si5351_platform_data {
> - enum si5351_variant variant;
> struct clk *clk_xtal;
> struct clk *clk_clkin;
> enum si5351_pll_src pll_src[2];
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Laura Abbott @ 2014-01-27 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127181836.GH26766@pengutronix.de>
On 1/27/2014 10:18 AM, Uwe Kleine-K?nig wrote:
> On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
>> The dma_mask for a device structure is a pointer. This pointer
>> needs to be set up before the dma mask can actually be set. Most
>> frameworks in the kernel take care of setting this up properly but
>> platform devices that don't follow a regular bus structure may not
>> ever have this set. As a result, checks such as dma_capable will
>> always return false on a raw platform device and dma_set_mask will
>> always return -EIO. Fix this by adding a dma_mask in the
>> platform_device archdata and setting it to be the dma_mask. Devices
>> used in other frameworks can change this as needed.
>>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Suggested-by: Kumar Gala <galak@codeaurora.org>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> Hello,
>
> there is another non-platform dependant approach available, that might
> be worth to evaluate:
>
> http://mid.gmane.org/1390817152-30898-1-git-send-email-ydroneaud at opteya.com
>
That covers dynamically allocated devices but it doesn't look like it
covers devices setup with just platform_device_register like
arch_setup_pdev_archdata does.
>> ---
>> arch/arm64/include/asm/device.h | 1 +
>> arch/arm64/kernel/setup.c | 7 +++++++
>> 2 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
>> index cf98b36..209d40c 100644
>> --- a/arch/arm64/include/asm/device.h
>> +++ b/arch/arm64/include/asm/device.h
>> @@ -24,6 +24,7 @@ struct dev_archdata {
>> };
>>
>> struct pdev_archdata {
>> + u64 dma_mask;
>> };
>>
>> #endif
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index bd9bbd0..f164347 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -41,6 +41,7 @@
>> #include <linux/memblock.h>
>> #include <linux/of_fdt.h>
>> #include <linux/of_platform.h>
>> +#include <linux/dma-mapping.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/elf.h>
>> @@ -337,3 +338,9 @@ const struct seq_operations cpuinfo_op = {
>> .stop = c_stop,
>> .show = c_show
>> };
>> +
>> +void arch_setup_pdev_archdata(struct platform_device *pdev)
>> +{
>> + pdev->archdata.dma_mask = DMA_BIT_MASK(32);
>> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
>> +}
> Is it save to assume a default of DMA_BIT_MASK(32)?
>
This seemed like a reasonable default and matches what powerpc does. Any
device who wants to really guarantee a DMA mask should be setting the
dma mask explicitly and not relying on a default.
> Best regards
> Uwe
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Arnaud Ebalard @ 2014-01-27 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140126143019.09d0b9e0@skate>
Hi Thomas and Sarah,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> On Thu, 23 Jan 2014 09:24:41 +0100, Arnaud Ebalard wrote:
>
>> The various Armada-based devices I have are NAS which do not have PCIe
>> slots to plug additional devices (everything is soldered). I don't know
>> which device Thomas used for its tests. Just in case, I also added Willy
>> in CC: who have various boards and may also have done more test with
>> additional PCIe devices and CONFIG_PCI_MSI enabled on 3.13 kernel.
>
> The device I've used to test MSI is a e1000e PCIe Intel network card.
> It uses one MSI interrupt, so admittedly, the MSI testing is quite
> limited for now.
I had a second thought this WE about a previous question from Sarah: my
platforms do not have a PCIe extension slots to test other devices but
the RN102 does have an additional device connected on the PCIe bus: a
Marvell 88SE9170 SATA Controller. I have put below the output of lspci
-vvv (on a 3.13.0-rc8 kernel w/ CONFIG_PCI_MSI enabled) in case you can
spot something obviously wrong in it:
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00010000-00010fff
Memory behind bridge: e0000000-e00fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: e0100000-e01fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9170 (rev 12) (prog-if 01 [AHCI 1.0])
Subsystem: Marvell Technology Group Ltd. Device 9170
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 105
Region 0: I/O ports at 10010 [size=8]
Region 1: I/O ports at 10020 [size=4]
Region 2: I/O ports at 10018 [size=8]
Region 3: I/O ports at 10024 [size=4]
Region 4: I/O ports at 10000 [size=16]
Region 5: Memory at e0010000 (32-bit, non-prefetchable) [size=512]
Expansion ROM@e0000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: d0020a04 Data: 0f10
Capabilities: [70] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Kernel driver in use: ahci
02:00.0 USB controller: Fresco Logic FL1009 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI])
Subsystem: Fresco Logic Device 0000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 104
Region 0: Memory at e0100000 (64-bit, non-prefetchable) [size=64K]
Region 2: Memory at e0110000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory@e0111000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=8 Masked-
Vector table: BAR=2 offset=00000000
PBA: BAR=4 offset=00000000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Kernel driver in use: xhci_hcd
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Jason Cooper @ 2014-01-27 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6A3B2.6060301@gmail.com>
On Mon, Jan 27, 2014 at 07:21:38PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/14 15:39, Thomas Petazzoni wrote:
> >On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
> >>This patch set fixes clk init order that went upside-down with
> >>v3.14. I haven't really investigated what caused this, but I assume
> >>it is related with DT node reordering by addresses.
> >>
> >>Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> >>registered before core clocks driver. Unfortunately, we cannot
> >>return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
> >>init order for our drivers is always core clocks before clock gating,
> >>we maintain init order ourselves by hooking CLK_OF_DECLARE to one
> >>init function that will register core clocks before clock gating
> >>driver.
> >>
> >>This patch is based on pre-v3.14-rc1 mainline and should go in as
> >>fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
> >>I suggest Jason picks it up as a topic branch.
> >
> >I'm not sure I really like the solution you're proposing here. I'd very
> >much prefer to keep one CLK_OF_DECLARE() per clock type, associated to
> >one function registering only this clock type.
>
> Have you ever had a look at e.g. clk-imx28.c? Not that I really like
> the approach, but it is common practice to do so.
>
> >Instead, shouldn't the clock framework be improved to *not* register a
> >clock until its parent have been registered? If the DT you have the
> >gatable clocks that depend on the core clocks, then the gatable clocks
> >should not be registered if the core clocks have not yet been
> >registered.
> >
> >Do you think this is possible? Am I missing something here?
>
> As I said, clk_of_init does not care about return values from the
> clock init functions. Without it, it cannot decide if a clock
> driver failed horribly, failed because of missing dependencies, or
> successfully installed all clocks. Also, it is early stuff and I guess
> clk_of_init will have to build its own "defered_list" and loop over
> until done.
>
> BTW, this is a fix not an improvement. We should find an acceptable
> solution soon. But I am still open for suggestions, too.
fyi: I suspect this may be the problem currently experienced by Kevin on
mirabox in the boot farm. He sees it on current master. Adding him to
the Cc.
thx,
Jason.
^ permalink raw reply
* [PATCH 05/11] pinctrl: mvebu: fix misdesigned resource allocation
From: Sebastian Hesselbarth @ 2014-01-27 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127154532.4bc3eeef@skate>
On 01/27/14 15:45, Thomas Petazzoni wrote:
> On Sat, 25 Jan 2014 19:34:10 +0100, Sebastian Hesselbarth wrote:
>> Allocating the pinctrl resource in common pinctrl-mvebu was a misdesign,
>> as it does not allow SoC specific parts to access the allocated resource.
>> This moves resource allocation from mvebu_pinctrl_probe to SoC specific
>> _probe functions and passes the base address to common pinctrl driver
>> instead.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>
> I definitely agree with that: I had the same problem several months ago
> when I started doing the pinctrl driver for Orion5x, which has a
> non-linear MPP register set.
>
> However, I'd like this to go a little bit further if possible. See
> below.
Agreed.
>> - return mvebu_pinctrl_probe(pdev);
>> + return mvebu_pinctrl_probe(pdev, base);
>
> I think there is no need to pass "base" to mvebu_pinctrl_probe(). The
> only reason we have this is because the base gets stored in the
> mvebu_pinctrl structure so that the mvebu_common_mpp_get() and
> mvebu_common_mpp_set() functions that are the default behavior
> for mvebu_pinconf_group_get() and mvebu_pinconf_group_set() work
> properly.
>
> Shouldn't we turn these functions mvebu_common_mpp_get() and
> mvebu_common_mpp_set() into helper functions, accessible from the
> per-SoC pinctrl drivers, so that they can easily implement their
> ->mpp_get() and ->mpp_set() callbacks?
Sounds reasonable to do so. I have a look at removing the base address
from common.c completely.
Sebastian
> This way, the "base" thing is completely owned by the per-SoC driver,
> which would be more logical I believe.
^ permalink raw reply
* [RESEND][RFC PATCH 2/2] arm: Get rid of meminfo
From: Laura Abbott @ 2014-01-27 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E13ECC.3070203@ti.com>
Hi, Thanks for the review
On 1/23/2014 8:09 AM, Grygorii Strashko wrote:
...
>>
>> @@ -692,6 +685,12 @@ int __init arm_add_memory(u64 start, u64 size)
>> * Pick out the memory size. We look for mem=size at start,
>> * where start and size are "size[KkMm]"
>> */
>> +
>> +/*
>> + * XXX this is busted when just using memblock. Need to add memblock
>> + * hook to reset.
>> + */
>> +
>> static int __init early_mem(char *p)
>> {
>> static int usermem __initdata = 0;
>> @@ -706,7 +705,6 @@ static int __init early_mem(char *p)
>> */
>> if (usermem == 0) {
>> usermem = 1;
>> - meminfo.nr_banks = 0;
>> }
>
> The below code might work here:
> memblock_remove(memblock_start_of_DRAM(),
> memblock_end_of_DRAM() - memblock_start_of_DRAM());
>
That removes the memory but if we've already reserved any memory then
the memblock state will be inconsistent. I guess we can assume this is
early enough where no reserves will have taken place.
>>
>> start = PHYS_OFFSET;
>> @@ -851,13 +849,6 @@ static void __init reserve_crashkernel(void)
>> static inline void reserve_crashkernel(void) {}
>> #endif /* CONFIG_KEXEC */
>>
>
> [...]
>
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index e0e3968..c6ea491 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -81,24 +81,21 @@ __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>> * initialization functions, as well as show_mem() for the skipping
>> * of holes in the memory map. It is populated by arm_add_memory().
>> */
>> -struct meminfo meminfo;
>> -
>> void show_mem(unsigned int filter)
>> {
>> int free = 0, total = 0, reserved = 0;
>> - int shared = 0, cached = 0, slab = 0, i;
>> - struct meminfo * mi = &meminfo;
>> + int shared = 0, cached = 0, slab = 0;
>> + struct memblock_region *reg;
>>
>> printk("Mem-info:\n");
>> show_free_areas(filter);
>>
>> - for_each_bank (i, mi) {
>> - struct membank *bank = &mi->bank[i];
>> + for_each_memblock (memory, reg) {
>> unsigned int pfn1, pfn2;
>> struct page *page, *end;
>>
>> - pfn1 = bank_pfn_start(bank);
>> - pfn2 = bank_pfn_end(bank);
>> + pfn1 = memblock_region_memory_base_pfn(reg);
>> + pfn2 = memblock_region_memory_end_pfn(reg);
>>
>> page = pfn_to_page(pfn1);
>> end = pfn_to_page(pfn2 - 1) + 1;
>> @@ -130,16 +127,9 @@ void show_mem(unsigned int filter)
>> static void __init find_limits(unsigned long *min, unsigned long
>> *max_low,
>> unsigned long *max_high)
>> {
>> - struct meminfo *mi = &meminfo;
>> - int i;
>> -
>> - /* This assumes the meminfo array is properly sorted */
>> - *min = bank_pfn_start(&mi->bank[0]);
>> - for_each_bank (i, mi)
>> - if (mi->bank[i].highmem)
>> - break;
>> - *max_low = bank_pfn_end(&mi->bank[i - 1]);
>> - *max_high = bank_pfn_end(&mi->bank[mi->nr_banks - 1]);
>> + *max_low = PFN_DOWN(memblock_get_current_limit());
>> + *min = PFN_UP(memblock_start_of_DRAM());
>> + *max_high = PFN_DOWN(memblock_end_of_DRAM());
>
> Just to notify. Above values may have different values after your
> change, because of usage arm_memblock_steal(). Is it ok?
>
Yes, I think so. The memory from arm_memblock_steal isn't really in the
system anyway so it seems incorrect to be treating it as such.
>> }
>>
>> static void __init arm_bootmem_init(unsigned long start_pfn,
>> @@ -327,14 +317,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t
>> size, phys_addr_t align)
>> return phys;
>> }
>>
>> -void __init arm_memblock_init(struct meminfo *mi,
>> - const struct machine_desc *mdesc)
>> +void __init arm_memblock_init(const struct machine_desc *mdesc)
>> {
>> - int i;
>> -
>> - for (i = 0; i < mi->nr_banks; i++)
>> - memblock_add(mi->bank[i].start, mi->bank[i].size);
>> -
>> /* Register the kernel text, kernel data and initrd with
>> memblock. */
>> #ifdef CONFIG_XIP_KERNEL
>> memblock_reserve(__pa(_sdata), _end - _sdata);
>> @@ -466,48 +450,47 @@ free_memmap(unsigned long start_pfn, unsigned
>> long end_pfn)
>> /*
>> * The mem_map array can get very big. Free the unused area of the
>> memory map.
>> */
>> -static void __init free_unused_memmap(struct meminfo *mi)
>> +static void __init free_unused_memmap(void)
>> {
>> - unsigned long bank_start, prev_bank_end = 0;
>> - unsigned int i;
>> + unsigned long start, prev_end = 0;
>> + struct memblock_region *reg;
>>
>> /*
>> * This relies on each bank being in address order.
>> * The banks are sorted previously in bootmem_init().
>> */
>> - for_each_bank(i, mi) {
>> - struct membank *bank = &mi->bank[i];
>> -
>> - bank_start = bank_pfn_start(bank);
>> + for_each_memblock(memory, reg) {
>> + start = __phys_to_pfn(reg->base);
>>
>> #ifdef CONFIG_SPARSEMEM
>> /*
>> * Take care not to free memmap entries that don't exist
>> * due to SPARSEMEM sections which aren't present.
>> */
>> - bank_start = min(bank_start,
>> - ALIGN(prev_bank_end, PAGES_PER_SECTION));
>> + start = min(start,
>> + ALIGN(prev_end, PAGES_PER_SECTION));
>> #else
>> /*
>> * Align down here since the VM subsystem insists that the
>> * memmap entries are valid from the bank start aligned to
>> * MAX_ORDER_NR_PAGES.
>> */
>> - bank_start = round_down(bank_start, MAX_ORDER_NR_PAGES);
>> + start = round_down(start, MAX_ORDER_NR_PAGES);
>> #endif
>> /*
>> * If we had a previous bank, and there is a space
>> * between the current bank and the previous, free it.
>> */
>> - if (prev_bank_end && prev_bank_end < bank_start)
>> - free_memmap(prev_bank_end, bank_start);
>> + if (prev_end && prev_end < start)
>> + free_memmap(prev_end, start);
>>
>> /*
>> * Align up here since the VM subsystem insists that the
>> * memmap entries are valid from the bank end aligned to
>> * MAX_ORDER_NR_PAGES.
>> */
>> - prev_bank_end = ALIGN(bank_pfn_end(bank), MAX_ORDER_NR_PAGES);
>> + prev_end = ALIGN(start + __phys_to_pfn(reg->size),
>> + MAX_ORDER_NR_PAGES);
>> }
>>
>> #ifdef CONFIG_SPARSEMEM
>> @@ -589,7 +572,7 @@ void __init mem_init(void)
>> max_mapnr = pfn_to_page(max_pfn + PHYS_PFN_OFFSET) - mem_map;
>>
>> /* this will put all unused low memory onto the freelists */
>> - free_unused_memmap(&meminfo);
>> + free_unused_memmap();
>> free_all_bootmem();
>>
>> #ifdef CONFIG_SA1111
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index 4f08c13..394701c 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -1043,77 +1043,54 @@ early_param("vmalloc", early_vmalloc);
>>
>> phys_addr_t arm_lowmem_limit __initdata = 0;
>>
>> +static void remove_memblock(phys_addr_t base, phys_addr_t size)
>> +{
>> + memblock_reserve(base, size);
>> + memblock_free(base, size);
>> + memblock_remove(base, size);
>> +}
>
> I think it'll be ok to use just memblock_remove(base, size); below.
>
This was my concern about reserved but I think you are correct that we
should be able to just remove without worrying about reserved areas.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127.144815.1048814583962628826.apm@brigitte.kvy.fi>
On Mon, Jan 27, 2014 at 12:48:15PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > That's why I defined the worst case. How did you implemented it in your
> > idle drivers ? That would help generalize it, after all these bindings
> > are there to simplify drivers upstreaming, feedback welcome.
>
> Currently we do not handle this well downstream either. The problem
> with worst case is that the absolute worst case can be really bad and
> probability of it might be very low. Sorry - no ready answer :-)
Point taken, but these bindings still get us to a point that is much
better than today situation. After all, if the worst case can happen
either we design for worst case or we update parameters at runtime in
the kernel (which is not happening as of now) according to a notification
mechanism.
It is certainly worth investigating, probably we can define OPPs as
generic (ie not tied to the CPU), as performance point or system
operating points. I will think about this.
In the meantime if you have further pieces of feedback please keep them
coming.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Sebastian Hesselbarth @ 2014-01-27 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127153908.4f6f46c2@skate>
On 01/27/14 15:39, Thomas Petazzoni wrote:
> On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
>> This patch set fixes clk init order that went upside-down with
>> v3.14. I haven't really investigated what caused this, but I assume
>> it is related with DT node reordering by addresses.
>>
>> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
>> registered before core clocks driver. Unfortunately, we cannot
>> return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
>> init order for our drivers is always core clocks before clock gating,
>> we maintain init order ourselves by hooking CLK_OF_DECLARE to one
>> init function that will register core clocks before clock gating
>> driver.
>>
>> This patch is based on pre-v3.14-rc1 mainline and should go in as
>> fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
>> I suggest Jason picks it up as a topic branch.
>
> I'm not sure I really like the solution you're proposing here. I'd very
> much prefer to keep one CLK_OF_DECLARE() per clock type, associated to
> one function registering only this clock type.
Have you ever had a look at e.g. clk-imx28.c? Not that I really like
the approach, but it is common practice to do so.
> Instead, shouldn't the clock framework be improved to *not* register a
> clock until its parent have been registered? If the DT you have the
> gatable clocks that depend on the core clocks, then the gatable clocks
> should not be registered if the core clocks have not yet been
> registered.
>
> Do you think this is possible? Am I missing something here?
As I said, clk_of_init does not care about return values from the
clock init functions. Without it, it cannot decide if a clock
driver failed horribly, failed because of missing dependencies, or
successfully installed all clocks. Also, it is early stuff and I guess
clk_of_init will have to build its own "defered_list" and loop over
until done.
BTW, this is a fix not an improvement. We should find an acceptable
solution soon. But I am still open for suggestions, too.
Sebastian
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Uwe Kleine-König @ 2014-01-27 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390845177-2626-1-git-send-email-lauraa@codeaurora.org>
On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
> The dma_mask for a device structure is a pointer. This pointer
> needs to be set up before the dma mask can actually be set. Most
> frameworks in the kernel take care of setting this up properly but
> platform devices that don't follow a regular bus structure may not
> ever have this set. As a result, checks such as dma_capable will
> always return false on a raw platform device and dma_set_mask will
> always return -EIO. Fix this by adding a dma_mask in the
> platform_device archdata and setting it to be the dma_mask. Devices
> used in other frameworks can change this as needed.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Suggested-by: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Hello,
there is another non-platform dependant approach available, that might
be worth to evaluate:
http://mid.gmane.org/1390817152-30898-1-git-send-email-ydroneaud at opteya.com
> ---
> arch/arm64/include/asm/device.h | 1 +
> arch/arm64/kernel/setup.c | 7 +++++++
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
> index cf98b36..209d40c 100644
> --- a/arch/arm64/include/asm/device.h
> +++ b/arch/arm64/include/asm/device.h
> @@ -24,6 +24,7 @@ struct dev_archdata {
> };
>
> struct pdev_archdata {
> + u64 dma_mask;
> };
>
> #endif
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index bd9bbd0..f164347 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -41,6 +41,7 @@
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> #include <linux/of_platform.h>
> +#include <linux/dma-mapping.h>
>
> #include <asm/cputype.h>
> #include <asm/elf.h>
> @@ -337,3 +338,9 @@ const struct seq_operations cpuinfo_op = {
> .stop = c_stop,
> .show = c_show
> };
> +
> +void arch_setup_pdev_archdata(struct platform_device *pdev)
> +{
> + pdev->archdata.dma_mask = DMA_BIT_MASK(32);
> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
> +}
Is it save to assume a default of DMA_BIT_MASK(32)?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Rob Herring @ 2014-01-27 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127163111.GA8358@arm.com>
On Mon, Jan 27, 2014 at 10:31 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
>> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
>> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
>> > based SoC dts files.
>> >
>> > Pankaj Dubey (2):
>> > arm64: dts: use #include for all AppliedMicro device tree files
>> > arm64: dts: use #include for all ARM fast model device tree file
>> >
>> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
>> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
>> > 2 files changed, 2 insertions(+), 2 deletions(-)
>> >
>> Gentle ping.
>
> It would be good to include some rationale behind this change and I'm
> waiting for the DT guys to ack it.
Change this when you actually need it.
Rob
^ permalink raw reply
* [PATCH RFC v3 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
From: Mark Brown @ 2014-01-27 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a16e2a877740942c1742ac0da403013c72ae3727.1390836773.git.jsarha@ti.com>
On Mon, Jan 27, 2014 at 05:37:51PM +0200, Jyri Sarha wrote:
> The referenced clock is used to get codec clock rate and the clock is
> disabled and enabled in startup and shutdown snd_soc_ops call
> backs. The change is also documented in DT bindigs document.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/e1f5b58d/attachment.sig>
^ permalink raw reply
* [PATCH RFC v2 1/2] Documentation: arm: add cache DT bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127125839.GL15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 12:58:39PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote:
> > I do have a worry that because the kernel won't normally use this
> > information, by default it will get pasted between .dts files, won't get
> > tested and will be wrong rather often. It also violates the DT principle
> > that probeable information should not be present in the DT -- ePAPR
> > obviously envisages systems where cache geometry information is not
> > probeable, but that's not the case for architected caches on ARM, except
> > in rare cases where the CLIDR is wrong.
>
> That statement is wrong. There are caches on ARM CPUs where there is no
> CLIDR register. I suggest reading the earlier DDI0100 revisions.
You are right, Dave was referring to the cache geometry properties in the
ePAPRv1.1, and the question on whether to ignore them for ARM. True, some
earlier ARM processors would need DT properties to define cache geometry owing
to the lack of cache type/id registers, but I guess we can work around that
and safely rule cache geometry properties out for ARM (better that than
having people rely on dts files containing wrong copy'n'pasted cache
geometry properties, that's the reasoning). The only reason we are defining
these bindings is to make sure we are able to detect which CPUs share what
caches, we can work around the lack of cache type/id registers to probe
geometry in earlier processors in the kernel.
Thanks,
Lorenzo
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jean-Francois Moine @ 2014-01-27 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E686B2.9060806@ti.com>
On Mon, 27 Jan 2014 18:17:54 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> Support for S16_LE could maybe be added if the tda998x specific codec
> would fiddle with CTS_N predivider-setting (K select) according to the
> used sample width. But it appears Cobox plays all the sample formats
> fine without this change, so the question is if playing around with
> CTS_N predivider would break already working support there (something to
> be tested).
Jyri,
Setting
cts_n = CTS_N_M(3) | CTS_N_K(1);
instead of K(3) in the I2S sequence of tda998x_configure_audio() in the
tda998x driver works fine for me with S16_LE and S24_LE.
Does this solve your problem?
Russell, do you see any problem about this change?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCHv2] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-27 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127095958.GA6547@mudshark.cambridge.arm.com>
On 1/27/2014 1:59 AM, Will Deacon wrote:
> Hi Laura,
>
> On Fri, Jan 24, 2014 at 11:09:15PM +0000, Laura Abbott wrote:
>> arm64 currently lacks support for -fstack-protector. Add
>> similar functionality to arm to detect stack corruption.
>
> [...]
>
>> +/*
>> + * Initialize the stackprotector canary value.
>> + *
>> + * NOTE: this must only be called from functions that never return,
>> + * and it must always be inlined.
>> + */
>> +static __always_inline void boot_init_stack_canary(void)
>> +{
>> + unsigned long canary;
>> +
>> + /* Try to get a semi random initial value. */
>> + get_random_bytes(&canary, sizeof(canary));
>> + canary ^= LINUX_VERSION_CODE;
>> +
>> + current->stack_canary = canary;
>
> Do we actually need this line now?
>
Probably not but it seems strange to not have anything there for the
stack canary. Not sure if 'nothing' is better or worse than a possibly
incorrect stack canary that gets automatically created in fork.
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Michal Simek @ 2014-01-27 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127175231.GU15937@n2100.arm.linux.org.uk>
On 01/27/2014 06:52 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote:
>> Why 0x4000? IRC Linux for ARM is using space for any purpose.
>> Russell knows this much better than I.
>
> Probably because as the kernel is loaded at 0x8000, it will place the
> swapper page table at 0x4000, thus covering from 0x4000 upwards.
Ah yeah swapper.
>
> Thus, the majority of your un-DMA-able memory will be kernel text or
> swapper page tables.
Yes, exactly.
0x0 - 0x4000 - reserving not to be used by DMA
0x4000 - 0x8000 swapper page table
0x8000 - 0x80000 kernel text + up
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/f6b2b00c/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Laura Abbott @ 2014-01-27 17:52 UTC (permalink / raw)
To: linux-arm-kernel
The dma_mask for a device structure is a pointer. This pointer
needs to be set up before the dma mask can actually be set. Most
frameworks in the kernel take care of setting this up properly but
platform devices that don't follow a regular bus structure may not
ever have this set. As a result, checks such as dma_capable will
always return false on a raw platform device and dma_set_mask will
always return -EIO. Fix this by adding a dma_mask in the
platform_device archdata and setting it to be the dma_mask. Devices
used in other frameworks can change this as needed.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
arch/arm64/include/asm/device.h | 1 +
arch/arm64/kernel/setup.c | 7 +++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index cf98b36..209d40c 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -24,6 +24,7 @@ struct dev_archdata {
};
struct pdev_archdata {
+ u64 dma_mask;
};
#endif
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index bd9bbd0..f164347 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -41,6 +41,7 @@
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
+#include <linux/dma-mapping.h>
#include <asm/cputype.h>
#include <asm/elf.h>
@@ -337,3 +338,9 @@ const struct seq_operations cpuinfo_op = {
.stop = c_stop,
.show = c_show
};
+
+void arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+ pdev->archdata.dma_mask = DMA_BIT_MASK(32);
+ pdev->dev.dma_mask = &pdev->archdata.dma_mask;
+}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [Q] block / zynq: DMA bouncing
From: Russell King - ARM Linux @ 2014-01-27 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69B4E.5010604@monstr.eu>
On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote:
> Why 0x4000? IRC Linux for ARM is using space for any purpose.
> Russell knows this much better than I.
Probably because as the kernel is loaded at 0x8000, it will place the
swapper page table at 0x4000, thus covering from 0x4000 upwards.
Thus, the majority of your un-DMA-able memory will be kernel text or
swapper page tables.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 0/9] ARM: dts: imx: remove the use of pingrp macros
From: Olof Johansson @ 2014-01-27 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390668191-20289-1-git-send-email-shawn.guo@linaro.org>
Shawn,
On Sat, Jan 25, 2014 at 8:43 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Hi Rob,
>
> In order to solve a pinctrl data efficiency problem, we introduced
> pingrp macros [1] in this development cycle as the base of board dts
> support. The whole imx-dt-3.14 pull request has been held by Olof for
> a few weeks because he wants to get a general approval from DT folks
> on this change. But unfortunately it appears that you are not fond of
> this change.
>
> I just spent the day to create a patch series against imx-dt-3.14 to
> remove these pingrp macros. May I get your nod on this quick
> turn-around, so that we do not miss the merge window?
>
> Hi Olof,
>
> I guess we do not have to shut the door for imx-dt-3.14 if you and DT
> folks are happy with this patch series, which is a quite straight
> forward search&replace change?
The merge window is halfway over already, the time for us to pick up
large branches like these are long past.
Please rebase (since this is a partial revert of some of the earlier
patches in your dt branch, I think?), and resend after -rc1 for 3.15
inclusion.
Thanks,
-Olof
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Michal Simek @ 2014-01-27 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127170230.GQ15937@n2100.arm.linux.org.uk>
On 01/27/2014 06:02 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote:
>> I'm working on an MMC driver with a DMA capability. All has been working
>> well, until at some point I've got a bus error, when the mmc driver had
>> been handed in a buffer at 0x3000 physical RAM address. The reason is,
>> that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
>> my question: how shall I configure this in software?
>
> You're going to run into all sorts of problems here. Normally, the
> DMA-able memory is limited to the first N bytes of memory, not "you must
> avoid the first N bytes of memory".
>
> Linux has it hard-coded into the memory subsystems that the DMA zone
> is from the start of memory to N, the normal zone is from N to H, and
> high memory is from H upwards - and allocations for high can fall back
> to normal, which can fall back to DMA but not the other way around.
>
> Short of permanently reserving the first 0x80000 bytes of memory, I'm
> not sure that there's much which can be done. You may wish to talk to
> the MM gurus to see whether there's a modern alternative.
We use memblock_reserve for allocation of this space in .reserse phase.
Look at git.xilinx.com - linux repo arch/arm/mach-zynq/common.c
/**
* zynq_memory_init() - Initialize special memory
*
* We need to stop things allocating the low memory as DMA can't work in
* the 1st 512K of memory. Using reserve vs remove is not totally clear yet.
*/
static void __init zynq_memory_init(void)
{
/*
* Reserve the 0-0x4000 addresses (before page tables and kernel)
* which can't be used for DMA
*/
if (!__pa(PAGE_OFFSET))
memblock_reserve(0, 0x4000);
}
DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
...
.reserve = zynq_memory_init,
...
MACHINE_END
I have checked why we are reserving just 0 - 0x4000 when kernel starts from 0x8000
and maybe Russell can help me with this better.
I got answer that using memblock_reserve was recommended in past for that.
Why 0x4000? IRC Linux for ARM is using space for any purpose.
Russell knows this much better than I.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/dfd95526/attachment.sig>
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-27 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127160654.GO15937@n2100.arm.linux.org.uk>
On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 10:45:59AM -0500, Nicolas Pitre wrote:
> > On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> >
> > > On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > > > ARM and ARM64 are the only two architectures implementing
> > > > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> > > >
> > > > We have secondary_start_kernel() already calling local_fiq_enable() and
> > > > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > > > enabling FIQs has nothing to do with idling the CPU to start with.
> > > >
> > > > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > > > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > > > at late_initcall time but this shouldn't make a difference in practice
> > > > i.e. when FIQs are actually used.
> > > >
> > > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > > ---
> > > > arch/arm/kernel/process.c | 5 -----
> > > > arch/arm/kernel/setup.c | 7 +++++++
> > > > 2 files changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > > > index 92f7b15dd2..725b8c95e0 100644
> > > > --- a/arch/arm/kernel/process.c
> > > > +++ b/arch/arm/kernel/process.c
> > > > @@ -142,11 +142,6 @@ static void default_idle(void)
> > > > local_irq_enable();
> > > > }
> > > >
> > > > -void arch_cpu_idle_prepare(void)
> > > > -{
> > > > - local_fiq_enable();
> > > > -}
> > > > -
> > > > void arch_cpu_idle_enter(void)
> > > > {
> > > > ledtrig_cpu(CPU_LED_IDLE_START);
> > > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > > index 987a7f5bce..d027b1a6fe 100644
> > > > --- a/arch/arm/kernel/setup.c
> > > > +++ b/arch/arm/kernel/setup.c
> > > > @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> > > > }
> > > > late_initcall(init_machine_late);
> > > >
> > > > +static int __init init_fiq_boot_cpu(void)
> > > > +{
> > > > + local_fiq_enable();
> > > > + return 0;
> > > > +}
> > > > +late_initcall(init_fiq_boot_cpu);
> > >
> > > arch_cpu_idle_prepare() gets called from the swapper thread, and changes
> > > the swapper thread's CPSR. init_fiq_boot_cpu() gets called from PID1, the
> > > init thread, and changes the init thread's CPSR, which will already have
> > > FIQs enabled by way of how kernel threads are created.
> > >
> > > Hence, the above code fragment has no effect what so ever, and those
> > > platforms using FIQs will not have FIQs delivered if they're idle
> > > (because the swapper will have FIQs masked at the CPU.)
> >
> > You're right.
> >
> > What about moving local_fiq_enable() to trap_init() then?
>
> That's potentially unsafe, as we haven't touched any of the IRQ
> controllers at that point - we can't guarantee what state they'd be
> in. Given that the default FIQ is to just return, a FIQ being raised
> at that point will end up with an infinite loop re-entering the FIQ
> handler.
Okay... I don't see any obvious way to work around that besides adding
another explicit hook, which arch_cpu_idle_prepare() incidentally
already is. So, unless you have a better idea, I'll drop this patch and
leave ARM as the only user of arch_cpu_idle_prepare().
Nicolas
^ permalink raw reply
* [PATCH v5 14/20] watchdog: orion: Add support for Armada 370 and Armada XP SoC
From: Russell King - ARM Linux @ 2014-01-27 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-15-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 12:27:14PM -0300, Ezequiel Garcia wrote:
> +static int armada370_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Setup watchdog input clock */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT),
> + WDT_A370_RATIO_MASK(WDT_A370_RATIO_SHIFT));
> +
> + dev->clk_rate = clk_get_rate(dev->clk) / WDT_A370_RATIO;
> + return 0;
> +}
> +
> +static int armadaxp_wdt_clock_init(struct platform_device *pdev,
> + struct orion_watchdog *dev)
> +{
> + int ret;
> +
> + dev->clk = of_clk_get_by_name(pdev->dev.of_node, "fixed");
> + if (IS_ERR(dev->clk))
> + return PTR_ERR(dev->clk);
> + ret = clk_prepare_enable(dev->clk);
> + if (ret)
> + return ret;
> +
> + /* Enable the fixed watchdog clock input */
> + atomic_io_modify(dev->reg + TIMER_CTRL,
> + WDT_AXP_FIXED_ENABLE_BIT,
> + WDT_AXP_FIXED_ENABLE_BIT);
> +
> + dev->clk_rate = clk_get_rate(dev->clk);
> + return 0;
> +}
Doesn't this result in dev->clk being leaked? Or at least a difference
in the way dev->clk needs to be cleaned up between these two functions?
I think it would be better in this case to use the standard clk_get() in
the first function and always use clk_put()... until there is a devm_*
version of the of_clk_get* functions.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Peter Zijlstra @ 2014-01-27 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127172110.GR15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 05:21:10PM +0000, Russell King - ARM Linux wrote:
> A reviewed-by tag on its own doesn't mean much, as it could mean that
> you've just glanced over the code and decided "yea, it looks okay", or
> it could mean that you've spent all day verifying that the code change
> is indeed correct.
One should use Acked-by for the 'yea, it looks okay' thing.
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Daniel Lezcano @ 2014-01-27 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127172110.GR15937@n2100.arm.linux.org.uk>
On 01/27/2014 06:21 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 06:12:53PM +0100, Daniel Lezcano wrote:
>> On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
>>> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>>>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>>>> ARM and ARM64 are the only two architectures implementing
>>>>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>>>>
>>>>> We have secondary_start_kernel() already calling local_fiq_enable() and
>>>>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>>>>> enabling FIQs has nothing to do with idling the CPU to start with.
>>>>>
>>>>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>>>>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>>>>> at late_initcall time but this shouldn't make a difference in practice
>>>>> i.e. when FIQs are actually used.
>>>>>
>>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>>
>>>> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>
>>> What kind of review did you do when giving that attributation?
>>
>> I did the review to the best of my knowledge and with good will.
>>
>> I read your comment on this patch and I learnt one more thing.
>>
>> Today, I am smarter than yesterday and dumber than tomorrow :)
>
> Just be aware that putting a comment along with the reviewed-by tag
> is always a good idea. I know that's a little more work, but this has
> been raised a number of times by various people over the years.
>
> A reviewed-by tag on its own doesn't mean much, as it could mean that
> you've just glanced over the code and decided "yea, it looks okay", or
> it could mean that you've spent all day verifying that the code change
> is indeed correct.
>
> Consequently, some will ignore emails which just contain a reviewed-by
> attributation.
Thanks for the clarification. I will take care of giving a comment next
time.
-- 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
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Catalin Marinas @ 2014-01-27 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69121.8050500@arm.com>
On Mon, Jan 27, 2014 at 05:02:25PM +0000, Marc Zyngier wrote:
> On 27/01/14 16:57, Catalin Marinas wrote:
> > On Mon, Jan 27, 2014 at 11:16:57AM +0000, Marc Zyngier wrote:
> >> On 24/01/14 23:37, Christoffer Dall wrote:
> >>> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
> >>>> --- a/arch/arm/include/asm/pgtable-3level.h
> >>>> +++ b/arch/arm/include/asm/pgtable-3level.h
> >>>> @@ -120,13 +120,19 @@
> >>>> /*
> >>>> * 2nd stage PTE definitions for LPAE.
> >>>> */
> >>>> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
> >>>> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >>>> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >>>> -
> >>>> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>>> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
> >>>> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
> >>>> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
> >>>> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
> >>>> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
> >>>> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
> >>>> +
> >>>> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
> >>>> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
> >>>> +
> >>>> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
> >>>>
> >>>> /*
> >>>> * Hyp-mode PL2 PTE definitions for LPAE.
> >>
> >> The change makes sense to me. arm64 uses a slightly different approach,
> >> by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
> >>
> >> Russell, Catalin: could you please have a look at this?
> >
> > Do we actually need more than Normal Cacheable and Device for stage 2?
>
> Not so far. As long as these two memory types are enforced as a minimum,
> we're quite happy to let the guest use whatever it decides.
>
> I suppose Christoffer introduces them all here as a matter of
> completeness, but I don't see them as being useful anytime soon.
That would be useful on arm if you want cachepolicy= argument to force
the cacheability of guest Normal memory type.
On arm64, the stage 1 memory type is decided via MAIR and that's how we
handle cachepolicy for Normal memory. But for stage 2 this won't work,
the type is explicitly set in the MemAttr encoding. But I don't think we
need host cachepolicy enforced onto guest.
--
Catalin
^ 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