* [PATCH 04/10] sata: hardreset: retry if phys link is down
From: Bartosz Golaszewski @ 2017-01-13 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
The sata core driver already retries to resume the link because some
controllers ignore writes to the SControl register.
We have a use case with the da850 SATA controller where at PLL0
frequency of 456MHz (needed to properly service the LCD controller)
the chip becomes unstable and the hardreset operation is ignored the
first time 50% of times.
Retrying just the resume operation doesn't work - we need to issue
the phy/wake reset again to make it work.
If ata_phys_link_offline() returns true in sata_link_hardreset(),
retry a couple times before really giving up.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/ata/libata-core.c | 16 ++++++++++++----
include/linux/libata.h | 4 +++-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 9cd0a2d..3b848a3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3985,8 +3985,8 @@ int sata_link_hardreset(struct ata_link *link, const unsigned long *timing,
unsigned long deadline,
bool *online, int (*check_ready)(struct ata_link *))
{
+ int rc, retry = ATA_LINK_RESET_TRIES;
u32 scontrol;
- int rc;
DPRINTK("ENTER\n");
@@ -4009,7 +4009,7 @@ int sata_link_hardreset(struct ata_link *link, const unsigned long *timing,
sata_set_spd(link);
}
-
+retry:
/* issue phy wake/reset */
if ((rc = sata_scr_read(link, SCR_CONTROL, &scontrol)))
goto out;
@@ -4028,9 +4028,17 @@ int sata_link_hardreset(struct ata_link *link, const unsigned long *timing,
rc = sata_link_resume(link, timing, deadline);
if (rc)
goto out;
- /* if link is offline nothing more to do */
- if (ata_phys_link_offline(link))
+
+ if (ata_phys_link_offline(link)) {
+ if (retry--) {
+ ata_link_warn(link,
+ "link still offline after hardreset - retrying\n");
+ goto retry;
+ }
+
+ /* if link is still offline nothing more to do */
goto out;
+ }
/* Link is online. From this point, -ENODEV too is an error. */
if (online)
diff --git a/include/linux/libata.h b/include/linux/libata.h
index c170be5..2c840c0 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -392,8 +392,10 @@ enum {
/* max tries if error condition is still set after ->error_handler */
ATA_EH_MAX_TRIES = 5,
- /* sometimes resuming a link requires several retries */
+ /* sometimes resuming a link requires several retries... */
ATA_LINK_RESUME_TRIES = 5,
+ /* ... and sometimes we need to retry the whole reset procedure */
+ ATA_LINK_RESET_TRIES = 5,
/* how hard are we gonna try to probe/recover devices */
ATA_PROBE_MAX_TRIES = 3,
--
2.9.3
^ permalink raw reply related
* [PATCH 05/10] sata: ahci_da850: add device tree match table
From: Bartosz Golaszewski @ 2017-01-13 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
We're using device tree for da850-lcdk. Add the match table to allow
to probe the driver.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/ata/ahci_da850.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 267a3d3..5930af81 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -105,11 +105,18 @@ static int ahci_da850_probe(struct platform_device *pdev)
static SIMPLE_DEV_PM_OPS(ahci_da850_pm_ops, ahci_platform_suspend,
ahci_platform_resume);
+static const struct of_device_id ahci_da850_of_match[] = {
+ { .compatible = "ti,da850-ahci", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ahci_da850_of_match);
+
static struct platform_driver ahci_da850_driver = {
.probe = ahci_da850_probe,
.remove = ata_platform_remove_one,
.driver = {
.name = DRV_NAME,
+ .of_match_table = ahci_da850_of_match,
.pm = &ahci_da850_pm_ops,
},
};
--
2.9.3
^ permalink raw reply related
* [PATCH 06/10] sata: ahci_da850: implement a softreset quirk
From: Bartosz Golaszewski @ 2017-01-13 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
There's an issue with the da850 SATA controller: if port multiplier
support is compiled in, but we're connecting the drive directly to
the SATA port on the board, the drive can't be detected.
To make SATA work on the da850-lcdk board: first try to softreset
with pmp - if the operation fails with -EBUSY, retry without pmp.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/ata/ahci_da850.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 5930af81..bb9eb4c 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -54,11 +54,31 @@ static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
writel(val, ahci_base + SATA_P0PHYCR_REG);
}
+static int ahci_da850_softreset(struct ata_link *link,
+ unsigned int *class, unsigned long deadline)
+{
+ int pmp, ret;
+
+ pmp = sata_srst_pmp(link);
+
+ ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
+ if (pmp && ret == -EBUSY)
+ return ahci_do_softreset(link, class, 0,
+ deadline, ahci_check_ready);
+
+ return ret;
+}
+
+static struct ata_port_operations ahci_da850_port_ops = {
+ .inherits = &ahci_platform_ops,
+ .softreset = ahci_da850_softreset,
+};
+
static const struct ata_port_info ahci_da850_port_info = {
.flags = AHCI_FLAG_COMMON,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
- .port_ops = &ahci_platform_ops,
+ .port_ops = &ahci_da850_port_ops,
};
static struct scsi_host_template ahci_platform_sht = {
--
2.9.3
^ permalink raw reply related
* [PATCH 07/10] sata: ahci_da850: add support for the da850, clk_multiplier DT property
From: Bartosz Golaszewski @ 2017-01-13 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
Currently the clock multiplier is hardcoded in the driver for
the da850-evm board. Make it configurable over DT, but keep the
previous value as default in case the property is missing.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/ata/ahci_da850.c | 83 +++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 75 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index bb9eb4c..cd04caf 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -28,17 +28,70 @@
#define SATA_PHY_TXSWING(x) ((x) << 19)
#define SATA_PHY_ENPLL(x) ((x) << 31)
+struct da850_sata_mpy_mapping {
+ unsigned int multiplier;
+ unsigned int regval;
+};
+
+static const struct da850_sata_mpy_mapping da850_sata_mpy_table[] = {
+ {
+ .multiplier = 5,
+ .regval = 0x01,
+ },
+ {
+ .multiplier = 6,
+ .regval = 0x02,
+ },
+ {
+ .multiplier = 8,
+ .regval = 0x04,
+ },
+ {
+ .multiplier = 10,
+ .regval = 0x05,
+ },
+ {
+ .multiplier = 12,
+ .regval = 0x06,
+ },
+ /* TODO Add 12.5 multiplier. */
+ {
+ .multiplier = 15,
+ .regval = 0x08,
+ },
+ {
+ .multiplier = 20,
+ .regval = 0x09,
+ },
+ {
+ .multiplier = 25,
+ .regval = 0x0a,
+ }
+};
+
+static const struct da850_sata_mpy_mapping *
+da850_sata_get_mpy(unsigned int multiplier)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(da850_sata_mpy_table); i++)
+ if (da850_sata_mpy_table[i].multiplier == multiplier)
+ return &da850_sata_mpy_table[i];
+
+ return NULL;
+}
+
/*
* The multiplier needed for 1.5GHz PLL output.
*
- * NOTE: This is currently hardcoded to be suitable for 100MHz crystal
- * frequency (which is used by DA850 EVM board) and may need to be changed
- * if you would like to use this driver on some other board.
+ * This is the default value suitable for the 100MHz crystal frequency
+ * used by DA850 EVM board, which doesn't use DT.
*/
-#define DA850_SATA_CLK_MULTIPLIER 7
+#define DA850_SATA_CLK_MULTIPLIER_DEFAULT 15
static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
- void __iomem *ahci_base)
+ void __iomem *ahci_base,
+ const struct da850_sata_mpy_mapping *mpy)
{
unsigned int val;
@@ -47,7 +100,7 @@ static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
val &= ~BIT(0);
writel(val, pwrdn_reg);
- val = SATA_PHY_MPY(DA850_SATA_CLK_MULTIPLIER + 1) | SATA_PHY_LOS(1) |
+ val = SATA_PHY_MPY(mpy->regval) | SATA_PHY_LOS(1) |
SATA_PHY_RXCDR(4) | SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) |
SATA_PHY_ENPLL(1);
@@ -87,10 +140,12 @@ static struct scsi_host_template ahci_platform_sht = {
static int ahci_da850_probe(struct platform_device *pdev)
{
+ const struct da850_sata_mpy_mapping *mpy;
struct device *dev = &pdev->dev;
struct ahci_host_priv *hpriv;
- struct resource *res;
+ unsigned int multiplier;
void __iomem *pwrdn_reg;
+ struct resource *res;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -109,7 +164,19 @@ static int ahci_da850_probe(struct platform_device *pdev)
if (!pwrdn_reg)
goto disable_resources;
- da850_sata_init(dev, pwrdn_reg, hpriv->mmio);
+ rc = of_property_read_u32(dev->of_node,
+ "da850,clk_multiplier", &multiplier);
+ if (rc)
+ multiplier = DA850_SATA_CLK_MULTIPLIER_DEFAULT;
+
+ mpy = da850_sata_get_mpy(multiplier);
+ if (!mpy) {
+ dev_err(dev, "invalid multiplier value: %u\n", multiplier);
+ rc = -EINVAL;
+ goto disable_resources;
+ }
+
+ da850_sata_init(dev, pwrdn_reg, hpriv->mmio, mpy);
rc = ahci_platform_init_host(pdev, hpriv, &ahci_da850_port_info,
&ahci_platform_sht);
--
2.9.3
^ permalink raw reply related
* [PATCH 08/10] ARM: dts: da850: add pinmux settings for the SATA controller
From: Bartosz Golaszewski @ 2017-01-13 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
Add pinmux sub-nodes for all muxed SATA pins.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..1f6a47d 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -78,6 +78,30 @@
0x10 0x00220000 0x00ff0000
>;
};
+ sata_cp_det_pin: pinmux_sata_cp_det_pin {
+ pinctrl-single,bits = <
+ /* SATA_CP_DET */
+ 0x0c 0x00000000 0xf0000000
+ >;
+ };
+ sata_mp_switch_pin: pinmux_sata_mp_switch_pin {
+ pinctrl-single,bits = <
+ /* SATA_MP_SWITCH */
+ 0x0c 0x00000000 0x0f000000
+ >;
+ };
+ sata_cp_pod_pin: pinmux_sata_cp_pod_pin {
+ pinctrl-single,bits = <
+ /* SATA_CP_POD */
+ 0x10 0x40000000 0xf0000000
+ >;
+ };
+ sata_led_pin: pinmux_sata_led_pin {
+ pinctrl-single,bits = <
+ /* SATA_LED */
+ 0x10 0x04000000 0x0f000000
+ >;
+ };
i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,bits = <
/* I2C0_SDA,I2C0_SCL */
--
2.9.3
^ permalink raw reply related
* [PATCH 09/10] ARM: dts: da850: add the SATA node
From: Bartosz Golaszewski @ 2017-01-13 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
Add the SATA node to the da850 device tree.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1f6a47d..f5086b1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -427,6 +427,12 @@
phy-names = "usb-phy";
status = "disabled";
};
+ sata: ahci at 0x218000 {
+ compatible = "ti,da850-ahci";
+ reg = <0x218000 0x2000>, <0x22c018 0x4>;
+ interrupts = <67>;
+ status = "disabled";
+ };
mdio: mdio at 224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
--
2.9.3
^ permalink raw reply related
* [PATCH 10/10] ARM: dts: da850-lcdk: enable the SATA node
From: Bartosz Golaszewski @ 2017-01-13 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski@baylibre.com>
Enable the SATA node for da850-lcdk. We omit the pinctrl property on
purpose - the muxed SATA pins are not hooked up to anything
SATA-related on the lcdk.
The REFCLKN/P rate on the board is 100MHz, so we need a multiplier of
15 for 1.5GHz PLL rate.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..1e638da 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -105,6 +105,11 @@
status = "okay";
};
+&sata {
+ status = "okay";
+ da850,clk_multiplier = <15>;
+};
+
&mdio {
pinctrl-names = "default";
pinctrl-0 = <&mdio_pins>;
--
2.9.3
^ permalink raw reply related
* [RFC PATCH v4 0/5] ARM: Fix dma_alloc_coherent() and friends for NOMMU
From: Robin Murphy @ 2017-01-13 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5c3476e2-fae4-677c-3ed9-7a4eb4263ecb@arm.com>
On 13/01/17 09:12, Vladimir Murzin wrote:
> On 12/01/17 18:07, Robin Murphy wrote:
>> On 12/01/17 17:15, Vladimir Murzin wrote:
>>> On 12/01/17 17:04, Robin Murphy wrote:
>>>> On 12/01/17 16:52, Vladimir Murzin wrote:
>>>>> On 12/01/17 10:55, Benjamin Gaignard wrote:
>>>>>> 2017-01-12 11:35 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
>>>>>>> 2017-01-11 15:34 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>>> On 11/01/17 13:17, Benjamin Gaignard wrote:
>>>>>>>>> 2017-01-10 15:18 GMT+01:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> It seem that addition of cache support for M-class cpus uncovered
>>>>>>>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>>>>>>>> always consistent; however, for R/M classes of cpu memory can be
>>>>>>>>>> covered by MPU which in turn might configure RAM as Normal
>>>>>>>>>> i.e. bufferable and cacheable. It breaks dma_alloc_coherent() and
>>>>>>>>>> friends, since data can stuck in caches now or be buffered.
>>>>>>>>>>
>>>>>>>>>> This patch set is trying to address the issue by providing region of
>>>>>>>>>> memory suitable for consistent DMA operations. It is supposed that
>>>>>>>>>> such region is marked by MPU as non-cacheable. Robin suggested to
>>>>>>>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>>>>>>>> homebrew command line option, and extend dma-coherent to provide
>>>>>>>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>>>>>>>> 2/5). It allows us to offload all bookkeeping on generic coherent DMA
>>>>>>>>>> framework, and it is seems that it might be reused by other
>>>>>>>>>> architectures like c6x and blackfin.
>>>>>>>>>>
>>>>>>>>>> Dedicated DMA region is required for cases other than:
>>>>>>>>>> - MMU/MPU is off
>>>>>>>>>> - cpu is v7m w/o cache support
>>>>>>>>>> - device is coherent
>>>>>>>>>>
>>>>>>>>>> In case one of the above conditions is true dma operations are forced
>>>>>>>>>> to be coherent and wired with dma_noop_ops.
>>>>>>>>>>
>>>>>>>>>> To make life easier NOMMU dma operations are kept in separate
>>>>>>>>>> compilation unit.
>>>>>>>>>>
>>>>>>>>>> Since the issue was reported in the same time as Benjamin sent his
>>>>>>>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>>>>>>>> series (PATCH 1/5 and PATCH 3/5).
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> I have tested this v4 on my setup (stm32f4, no cache, no MPU) and unfortunately
>>>>>>>>> it doesn't work with my drm/kms driver.
>>>>>>>>
>>>>>>>> I guess the same is for fbmem, but would be better to have confirmation since
>>>>>>>> amba-clcd I use has not been ported to drm/kms (yet), so I can't test.
>>>>>>>>
>>>>>>>>> I haven't any errors but nothing is displayed unlike what I have when
>>>>>>>>> using current dma-mapping
>>>>>>>>> code.
>>>>>>>>> I guess the issue is coming from dma-noop where __get_free_pages() is
>>>>>>>>> used instead of alloc_pages()
>>>>>>>>> in dma-mapping.
>>>>>>>>
>>>>>>>> Unless I've missed something bellow is a call stack for both
>>>>>>>>
>>>>>>>> #1
>>>>>>>> __alloc_simple_buffer
>>>>>>>> __dma_alloc_buffer
>>>>>>>> alloc_pages
>>>>>>>> split_page
>>>>>>>> __dma_clear_buffer
>>>>>>>> memset
>>>>>>>> page_address
>>>>>>>>
>>>>>>>> #2
>>>>>>>> __get_free_pages
>>>>>>>> alloc_pages
>>>>>>>> page_address
>>>>>>>>
>>>>>>>> So the difference is that nommu case in dma-mapping.c memzeros memory, handles
>>>>>>>> DMA_ATTR_NO_KERNEL_MAPPING and does optimisation of memory usage.
>>>>>>>>
>>>>>>>> Is something from above critical for your driver?
>>>>>>>
>>>>>>> I have removed all the diff (split_page, __dma_clear_buffer, memset)
>>>>>>> from #1 and it is still working.
>>>>>>> DMA_ATTR_NO_KERNEL_MAPPING flag is not set when allocating the buffer.
>>>>>>>
>>>>>>> I have investigated more and found that dma-noop doesn't take care of
>>>>>>> "dma-ranges" property which is set in DT.
>>>>>>> I believed that is the root cause of my problem with your patches.
>>>>>>
>>>>>> After testing changing virt_to_phys to virt_to_dma in dma-noop.c fix the issue
>>>>>> modetest and fbdemo are now still functional.
>>>>>>
>>>>>
>>>>> Thanks for narrowing it down! I did not noticed that stm32f4 remap its memory,
>>>>> so dma-ranges property is in use.
>>>>>
>>>>> It looks like virt_to_dma is ARM specific, so I probably have to discard idea
>>>>> of reusing dma-noop-ops and switch logic into dma-mapping-nommu.c based on
>>>>> is_device_dma_coherent(dev) check.
>>>>
>>>> dma_pfn_offset is a member of struct device, so it should be OK for
>>>> dma_noop_ops to also make reference to it (and assume it's zero if not
>>>> explicitly set).
>>>>
>>>>> Meanwhile, I'm quite puzzled on how such memory remaping should work together
>>>>> with reserved memory. It seem it doesn't account dma-ranges while reserving
>>>>> memory (it is too early) nor while allocating/mapping/etc.
>>>>
>>>> The reserved memory is described in terms of CPU physical addresses, so
>>>> a device offset shouldn't matter from that perspective. It only comes
>>>> into play at the point you generate the dma_addr_t to hand off to the
>>>> device - only then do you need to transform the CPU physical address of
>>>> the allocated/mapped page into the device's view of that page (i.e.
>>>> subtract the offset).
>>>
>>> Thanks for explanation! So dma-coherent.c should be modified, right? I see
>>> that some architectures provide phys_to_dma/dma_to_phys helpers primary for
>>> swiotlb, is it safe to reuse them given that default implementation is
>>> provided? Nothing under Documentation explains how they supposed to be used,
>>> sorry if asking stupid question.
>>
>> Those are essentially SWIOTLB-specific, so can't be universally relied
>> upon. I think something like this ought to suffice:
>
> Yup, but what about dma-coherent.c? Currently it has
>
> int dma_alloc_from_coherent(struct device *dev, ssize_t size,
> dma_addr_t *dma_handle, void **ret)
> {
> ...
> *dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
> *ret = mem->virt_base + (pageno << PAGE_SHIFT);
> ...
> }
>
> In case reserved memory is described in terms of CPU phys addresses, would not
> we need to take into account dma_pfn_offset? What I'm missing?
Ah yes, I overlooked that one. AFAICS, that's intended to be accounted
for when calling dma_init_coherent_memory (i.e. phys_addr vs.
device_addr), but that's a bit awkward for a global pool.
How utterly disgusting do you think this (or some variant thereof) looks?
/* Apply device-specific offset for the global pool */
if (mem == dma_coherent_default_memory)
*handle += dev->dma_pfn_offset << PAGE_SHIFT;
Robin.
> Thanks
> Vladimir
>
>>
>> ---8<---
>> diff --git a/lib/dma-noop.c b/lib/dma-noop.c
>> index 3d766e78fbe2..fbb1b37750d5 100644
>> --- a/lib/dma-noop.c
>> +++ b/lib/dma-noop.c
>> @@ -8,6 +8,11 @@
>> #include <linux/dma-mapping.h>
>> #include <linux/scatterlist.h>
>>
>> +static dma_addr_t dma_noop_dev_offset(struct device *dev)
>> +{
>> + return (dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT;
>> +}
>> +
>> static void *dma_noop_alloc(struct device *dev, size_t size,
>> dma_addr_t *dma_handle, gfp_t gfp,
>> unsigned long attrs)
>> @@ -16,7 +21,7 @@ static void *dma_noop_alloc(struct device *dev, size_t
>> size,
>>
>> ret = (void *)__get_free_pages(gfp, get_order(size));
>> if (ret)
>> - *dma_handle = virt_to_phys(ret);
>> + *dma_handle = virt_to_phys(ret) - dma_noop_dev_offset(dev);
>> return ret;
>> }
>>
>> @@ -32,7 +37,7 @@ static dma_addr_t dma_noop_map_page(struct device
>> *dev, struct page *page,
>> enum dma_data_direction dir,
>> unsigned long attrs)
>> {
>> - return page_to_phys(page) + offset;
>> + return page_to_phys(page) + offset - dma_noop_dev_offset(dev);
>> }
>>
>> static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl,
>> int nents,
>> @@ -47,7 +52,8 @@ static int dma_noop_map_sg(struct device *dev, struct
>> scatterlist *sgl, int nent
>>
>> BUG_ON(!sg_page(sg));
>> va = sg_virt(sg);
>> - sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
>> + sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va) -
>> + dma_noop_dev_offset(dev);
>> sg_dma_len(sg) = sg->length;
>> }
>> --->8---
>>
>> intentionally whitespace-damaged by copy-pasting off my terminal to
>> emphasise how utterly untested it is ;)
>>
>> Robin.
>>
>
^ permalink raw reply
* [PATCH 0/2] dra7x: dts update for increase in QSPI SPL parttion size
From: Ravi Babu @ 2017-01-13 12:40 UTC (permalink / raw)
To: linux-arm-kernel
This patch updates the SPL partition size for QSPI for
dra7xx platforms.
Ravi Babu (2):
ARM: dts: dra7-evm: increase QSPI SPL partition size
ARM: dts: dra72x-evm: increase QSPI SPL partition size
arch/arm/boot/dts/dra7-evm.dts | 24 ++++++------------------
arch/arm/boot/dts/dra72-evm-common.dtsi | 24 ++++++------------------
2 files changed, 12 insertions(+), 36 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
From: Ravi Babu @ 2017-01-13 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311234-21978-1-git-send-email-ravibabu@ti.com>
The SPL size for DRA74x platform has increased and
is now more than 64KB. Increase QSPI SPL partition
size to 256KB for DRA74x EVM.
QSPI partition numbering changes because of this.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra7-evm.dts | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 132f2be..2784241 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -681,41 +681,29 @@
*/
partition at 0 {
label = "QSPI.SPL";
- reg = <0x00000000 0x000010000>;
+ reg = <0x00000000 0x000040000>;
};
partition at 1 {
- label = "QSPI.SPL.backup1";
- reg = <0x00010000 0x00010000>;
- };
- partition at 2 {
- label = "QSPI.SPL.backup2";
- reg = <0x00020000 0x00010000>;
- };
- partition at 3 {
- label = "QSPI.SPL.backup3";
- reg = <0x00030000 0x00010000>;
- };
- partition at 4 {
label = "QSPI.u-boot";
reg = <0x00040000 0x00100000>;
};
- partition at 5 {
+ partition at 2 {
label = "QSPI.u-boot-spl-os";
reg = <0x00140000 0x00080000>;
};
- partition at 6 {
+ partition at 3 {
label = "QSPI.u-boot-env";
reg = <0x001c0000 0x00010000>;
};
- partition at 7 {
+ partition at 4 {
label = "QSPI.u-boot-env.backup1";
reg = <0x001d0000 0x0010000>;
};
- partition at 8 {
+ partition at 5 {
label = "QSPI.kernel";
reg = <0x001e0000 0x0800000>;
};
- partition at 9 {
+ partition at 6 {
label = "QSPI.file-system";
reg = <0x009e0000 0x01620000>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: dra72x-evm: increase QSPI SPL partition size
From: Ravi Babu @ 2017-01-13 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484311234-21978-1-git-send-email-ravibabu@ti.com>
The SPL size for DRA72x platform has increased and
is now more than 64KB. Increase QSPI SPL partition
size to 256KB for DRA72x EVM.
QSPI partition numbers change because of this.
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index e50fbee..ae1a663 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -439,41 +439,29 @@
*/
partition at 0 {
label = "QSPI.SPL";
- reg = <0x00000000 0x000010000>;
+ reg = <0x00000000 0x000040000>;
};
partition at 1 {
- label = "QSPI.SPL.backup1";
- reg = <0x00010000 0x00010000>;
- };
- partition at 2 {
- label = "QSPI.SPL.backup2";
- reg = <0x00020000 0x00010000>;
- };
- partition at 3 {
- label = "QSPI.SPL.backup3";
- reg = <0x00030000 0x00010000>;
- };
- partition at 4 {
label = "QSPI.u-boot";
reg = <0x00040000 0x00100000>;
};
- partition at 5 {
+ partition at 2 {
label = "QSPI.u-boot-spl-os";
reg = <0x00140000 0x00080000>;
};
- partition at 6 {
+ partition at 3 {
label = "QSPI.u-boot-env";
reg = <0x001c0000 0x00010000>;
};
- partition at 7 {
+ partition at 4 {
label = "QSPI.u-boot-env.backup1";
reg = <0x001d0000 0x0010000>;
};
- partition at 8 {
+ partition at 5 {
label = "QSPI.kernel";
reg = <0x001e0000 0x0800000>;
};
- partition at 9 {
+ partition at 6 {
label = "QSPI.file-system";
reg = <0x009e0000 0x01620000>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-13 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484291609-20195-3-git-send-email-guochun.mao@mediatek.com>
On 01/13/2017 08:13 AM, Guochun Mao wrote:
> Add Mediatek nor flash node.
>
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index 082ca88..85e5ae8 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,31 @@
> };
> };
>
> +&nor_flash {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nor_pins_default>;
> + status = "okay";
> + flash at 0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + };
> +};
> +
> +&pio {
> + nor_pins_default: nor {
> + pins1 {
> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> + drive-strength = <MTK_DRIVE_4mA>;
> + bias-pull-up;
> + };
> + };
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index bdf8954..1eefce4 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -227,6 +227,18 @@
> status = "disabled";
> };
>
> + nor_flash: spi at 11014000 {
> + compatible = "mediatek,mt2701-nor",
> + "mediatek,mt8173-nor";
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2] arm64: errata: Provide macro for major and minor cpu revisions
From: Robert Richter @ 2017-01-13 13:12 UTC (permalink / raw)
To: linux-arm-kernel
Definition of cpu ranges are hard to read if the cpu variant is not
zero. Provide MIDR_CPU_VAR_REV() macro to describe the full hardware
revision of a cpu including variant and (minor) revision.
V2: Renamed macro to MIDR_CPU_VAR_REV()
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/include/asm/cputype.h | 3 +++
arch/arm64/kernel/cpu_errata.c | 15 +++++++++------
arch/arm64/kernel/cpufeature.c | 8 +++-----
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68ddb11c1..5196f0afaabd 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -56,6 +56,9 @@
(0xf << MIDR_ARCHITECTURE_SHIFT) | \
((partnum) << MIDR_PARTNUM_SHIFT))
+#define MIDR_CPU_VAR_REV(var, rev) \
+ (((var) << MIDR_VARIANT_SHIFT) | (rev))
+
#define MIDR_CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
MIDR_ARCHITECTURE_MASK)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917aac46..722284eaf51e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -79,8 +79,9 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
/* Cortex-A57 r0p0 - r1p2 */
.desc = "ARM erratum 832075",
.capability = ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE,
- MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
- (1 << MIDR_VARIANT_SHIFT) | 2),
+ MIDR_RANGE(MIDR_CORTEX_A57,
+ MIDR_CPU_VAR_REV(0, 0),
+ MIDR_CPU_VAR_REV(1, 2)),
},
#endif
#ifdef CONFIG_ARM64_ERRATUM_834220
@@ -88,8 +89,9 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
/* Cortex-A57 r0p0 - r1p2 */
.desc = "ARM erratum 834220",
.capability = ARM64_WORKAROUND_834220,
- MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
- (1 << MIDR_VARIANT_SHIFT) | 2),
+ MIDR_RANGE(MIDR_CORTEX_A57,
+ MIDR_CPU_VAR_REV(0, 0),
+ MIDR_CPU_VAR_REV(1, 2)),
},
#endif
#ifdef CONFIG_ARM64_ERRATUM_845719
@@ -113,8 +115,9 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
/* Cavium ThunderX, T88 pass 1.x - 2.1 */
.desc = "Cavium erratum 27456",
.capability = ARM64_WORKAROUND_CAVIUM_27456,
- MIDR_RANGE(MIDR_THUNDERX, 0x00,
- (1 << MIDR_VARIANT_SHIFT) | 1),
+ MIDR_RANGE(MIDR_THUNDERX,
+ MIDR_CPU_VAR_REV(0, 0),
+ MIDR_CPU_VAR_REV(1, 1)),
},
{
/* Cavium ThunderX, T81 pass 1.0 */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index fdf8f045929f..725d3cf0e95b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -720,13 +720,11 @@ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry,
static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry, int __unused)
{
u32 midr = read_cpuid_id();
- u32 rv_min, rv_max;
/* Cavium ThunderX pass 1.x and 2.x */
- rv_min = 0;
- rv_max = (1 << MIDR_VARIANT_SHIFT) | MIDR_REVISION_MASK;
-
- return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX, rv_min, rv_max);
+ return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
+ MIDR_CPU_VAR_REV(0, 0),
+ MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
}
static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused)
--
2.11.0
^ permalink raw reply related
* [PATCH v3 01/15] ARM: pxa: Don't rely on public mmc header to include leds.h
From: Ulf Hansson @ 2017-01-13 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484313256-25993-1-git-send-email-ulf.hansson@linaro.org>
Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.
Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
I am seeking an ack for this change as following changes for mmc in the
series, has build-dependencies to it.
---
arch/arm/mach-pxa/balloon3.c | 1 +
arch/arm/mach-pxa/colibri-pxa270-income.c | 1 +
arch/arm/mach-pxa/corgi.c | 1 +
arch/arm/mach-pxa/trizeps4.c | 1 +
arch/arm/mach-pxa/vpac270.c | 1 +
arch/arm/mach-pxa/zeus.c | 1 +
arch/arm/mach-pxa/zylonite.c | 1 +
7 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index 8a3c409..d452a49 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/sched.h>
#include <linux/bitops.h>
#include <linux/fb.h>
diff --git a/arch/arm/mach-pxa/colibri-pxa270-income.c b/arch/arm/mach-pxa/colibri-pxa270-income.c
index 8cff770..d7cf47d 100644
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -17,6 +17,7 @@
#include <linux/gpio.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 183cd34..7270f0d 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -19,6 +19,7 @@
#include <linux/major.h>
#include <linux/fs.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/mmc/host.h>
#include <linux/mtd/physmap.h>
#include <linux/pm.h>
diff --git a/arch/arm/mach-pxa/trizeps4.c b/arch/arm/mach-pxa/trizeps4.c
index ea78bc5..3dd13b4 100644
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/export.h>
#include <linux/sched.h>
#include <linux/bitops.h>
diff --git a/arch/arm/mach-pxa/vpac270.c b/arch/arm/mach-pxa/vpac270.c
index c006ee9..70ab3ad 100644
--- a/arch/arm/mach-pxa/vpac270.c
+++ b/arch/arm/mach-pxa/vpac270.c
@@ -15,6 +15,7 @@
#include <linux/irq.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
+#include <linux/leds.h>
#include <linux/gpio.h>
#include <linux/usb/gpio_vbus.h>
#include <linux/mtd/mtd.h>
diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 3b94ecf..ecbcaee 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -13,6 +13,7 @@
#include <linux/cpufreq.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/irq.h>
#include <linux/pm.h>
#include <linux/gpio.h>
diff --git a/arch/arm/mach-pxa/zylonite.c b/arch/arm/mach-pxa/zylonite.c
index 3642389..4268552 100644
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
--
1.9.1
^ permalink raw reply related
* [PATCH v3 02/15] ARM: davinci: Don't rely on public mmc header to include leds.h
From: Ulf Hansson @ 2017-01-13 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484313256-25993-1-git-send-email-ulf.hansson@linaro.org>
Some of the davinci boards, da850-evm, dm644x-evm and neuros-osd2 depends
on leds.h. Explicitly include it instead of relying on the public mmc
header host.h.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
I am seeking an ack for this change as following changes for mmc in the
series, has build-dependencies to it.
---
arch/arm/mach-davinci/board-da850-evm.c | 1 +
arch/arm/mach-davinci/board-dm644x-evm.c | 1 +
arch/arm/mach-davinci/board-neuros-osd2.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index aac3ab1..df3ca38 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -18,6 +18,7 @@
#include <linux/gpio/machine.h>
#include <linux/init.h>
#include <linux/kernel.h>
+#include <linux/leds.h>
#include <linux/i2c.h>
#include <linux/platform_data/at24.h>
#include <linux/platform_data/pca953x.h>
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 521e4097..023480b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -25,6 +25,7 @@
#include <linux/videodev2.h>
#include <linux/v4l2-dv-timings.h>
#include <linux/export.h>
+#include <linux/leds.h>
#include <media/i2c/tvp514x.h>
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index ad10017..0a78388 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -25,6 +25,7 @@
*/
#include <linux/platform_device.h>
#include <linux/gpio.h>
+#include <linux/leds.h>
#include <linux/mtd/partitions.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/platform_data/i2c-davinci.h>
--
1.9.1
^ permalink raw reply related
* [PATCH v3 03/15] ARM: davinci: Don't rely on public mmc header to include interrupt.h
From: Ulf Hansson @ 2017-01-13 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484313256-25993-1-git-send-email-ulf.hansson@linaro.org>
The davinci board omapl138-hawk, depends on interrupt.h. Explicitly include
it instead of relying on the public mmc header host.h.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
I am seeking an ack for this change as following changes for mmc in the
series, has build-dependencies to it.
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 41d5500..a3e7807 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/console.h>
+#include <linux/interrupt.h>
#include <linux/gpio.h>
#include <linux/gpio/machine.h>
#include <linux/platform_data/gpio-davinci.h>
--
1.9.1
^ permalink raw reply related
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Robert Richter @ 2017-01-13 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113091903.GA22538@arm.com>
On 13.01.17 09:19:04, Will Deacon wrote:
> On Thu, Jan 12, 2017 at 07:58:25PM +0100, Robert Richter wrote:
> > On 12.01.17 16:05:36, Will Deacon wrote:
> > > On Mon, Jan 09, 2017 at 12:53:20PM +0100, Robert Richter wrote:
> >
> > > > Kernel compile times (3 runs each):
> > > >
> > > > pfn_valid_within():
> > > >
> > > > real 6m4.088s
> > > > user 372m57.607s
> > > > sys 16m55.158s
> > > >
> > > > real 6m1.532s
> > > > user 372m48.453s
> > > > sys 16m50.370s
> > > >
> > > > real 6m4.061s
> > > > user 373m18.753s
> > > > sys 16m57.027s
> > >
> > > Did you reboot the machine between each build here, or only when changing
> > > kernel? If the latter, do you see variations in kernel build time by simply
> > > rebooting the same Image?
> >
> > I built it in a loop on the shell, so no reboots between builds. Note
> > that I was building the kernel in /dev/shm to not access harddisks. I
> > think build times should be comparable then since there is no fs
> > caching.
>
> I guess I'm really asking what the standard deviation is if you *do* reboot
> between builds, using the same kernel. It's hard to tell whether the numbers
> are due to the patches, or just because of noise incurred by the way things
> happen to initialise.
Ok, I am going to test this.
-Robert
^ permalink raw reply
* [PATCH] ARM: ux500: cut some platform data
From: Linus Walleij @ 2017-01-13 13:16 UTC (permalink / raw)
To: linux-arm-kernel
This platform data is revoked: the drivers are getting the DMA
configuration from the device tree, it has been done like that
since the DMA support was merged and this data has not been used
since. The remaining auxdata is also unused.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-ux500/board-mop500-audio.c | 77 -----------------------------
arch/arm/mach-ux500/board-mop500.h | 17 -------
arch/arm/mach-ux500/cpu-db8500.c | 16 ------
arch/arm/mach-ux500/ste-dma40-db8500.h | 85 --------------------------------
4 files changed, 195 deletions(-)
delete mode 100644 arch/arm/mach-ux500/board-mop500-audio.c
delete mode 100644 arch/arm/mach-ux500/board-mop500.h
delete mode 100644 arch/arm/mach-ux500/ste-dma40-db8500.h
diff --git a/arch/arm/mach-ux500/board-mop500-audio.c b/arch/arm/mach-ux500/board-mop500-audio.c
deleted file mode 100644
index b2a0899e7453..000000000000
--- a/arch/arm/mach-ux500/board-mop500-audio.c
+++ /dev/null
@@ -1,77 +0,0 @@
-/*
- * Copyright (C) ST-Ericsson SA 2010
- *
- * License terms: GNU General Public License (GPL), version 2
- */
-
-#include <linux/platform_device.h>
-#include <linux/init.h>
-#include <linux/gpio.h>
-#include <linux/platform_data/dma-ste-dma40.h>
-
-#include <linux/platform_data/asoc-ux500-msp.h>
-
-#include "ste-dma40-db8500.h"
-#include "board-mop500.h"
-
-static struct stedma40_chan_cfg msp0_dma_rx = {
- .high_priority = true,
- .dir = DMA_DEV_TO_MEM,
- .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-};
-
-static struct stedma40_chan_cfg msp0_dma_tx = {
- .high_priority = true,
- .dir = DMA_MEM_TO_DEV,
- .dev_type = DB8500_DMA_DEV31_MSP0_SLIM0_CH0,
-};
-
-struct msp_i2s_platform_data msp0_platform_data = {
- .id = 0,
- .msp_i2s_dma_rx = &msp0_dma_rx,
- .msp_i2s_dma_tx = &msp0_dma_tx,
-};
-
-static struct stedma40_chan_cfg msp1_dma_rx = {
- .high_priority = true,
- .dir = DMA_DEV_TO_MEM,
- .dev_type = DB8500_DMA_DEV30_MSP3,
-};
-
-static struct stedma40_chan_cfg msp1_dma_tx = {
- .high_priority = true,
- .dir = DMA_MEM_TO_DEV,
- .dev_type = DB8500_DMA_DEV30_MSP1,
-};
-
-struct msp_i2s_platform_data msp1_platform_data = {
- .id = 1,
- .msp_i2s_dma_rx = NULL,
- .msp_i2s_dma_tx = &msp1_dma_tx,
-};
-
-static struct stedma40_chan_cfg msp2_dma_rx = {
- .high_priority = true,
- .dir = DMA_DEV_TO_MEM,
- .dev_type = DB8500_DMA_DEV14_MSP2,
-};
-
-static struct stedma40_chan_cfg msp2_dma_tx = {
- .high_priority = true,
- .dir = DMA_MEM_TO_DEV,
- .dev_type = DB8500_DMA_DEV14_MSP2,
- .use_fixed_channel = true,
- .phy_channel = 1,
-};
-
-struct msp_i2s_platform_data msp2_platform_data = {
- .id = 2,
- .msp_i2s_dma_rx = &msp2_dma_rx,
- .msp_i2s_dma_tx = &msp2_dma_tx,
-};
-
-struct msp_i2s_platform_data msp3_platform_data = {
- .id = 3,
- .msp_i2s_dma_rx = &msp1_dma_rx,
- .msp_i2s_dma_tx = NULL,
-};
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
deleted file mode 100644
index 7c7b0adca582..000000000000
--- a/arch/arm/mach-ux500/board-mop500.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * Copyright (C) ST-Ericsson SA 2010
- *
- * License terms: GNU General Public License (GPL) version 2
- */
-
-#ifndef __BOARD_MOP500_H
-#define __BOARD_MOP500_H
-
-#include <linux/platform_data/asoc-ux500-msp.h>
-
-extern struct msp_i2s_platform_data msp0_platform_data;
-extern struct msp_i2s_platform_data msp1_platform_data;
-extern struct msp_i2s_platform_data msp2_platform_data;
-extern struct msp_i2s_platform_data msp3_platform_data;
-
-#endif
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 46b1da1bf5d2..4d2ed9199641 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -34,7 +34,6 @@
#include "setup.h"
-#include "board-mop500.h"
#include "db8500-regs.h"
static int __init ux500_l2x0_unlock(void)
@@ -142,21 +141,6 @@ static struct arm_pmu_platdata db8500_pmu_platdata = {
static struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
/* Requires call-back bindings. */
OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu", &db8500_pmu_platdata),
- /* Requires DMA bindings. */
- OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80123000,
- "ux500-msp-i2s.0", &msp0_platform_data),
- OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80124000,
- "ux500-msp-i2s.1", &msp1_platform_data),
- OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80117000,
- "ux500-msp-i2s.2", &msp2_platform_data),
- OF_DEV_AUXDATA("stericsson,ux500-msp-i2s", 0x80125000,
- "ux500-msp-i2s.3", &msp3_platform_data),
- /* Requires non-DT:able platform data. */
- OF_DEV_AUXDATA("stericsson,db8500-prcmu", 0x80157000, "db8500-prcmu", NULL),
- OF_DEV_AUXDATA("stericsson,ux500-cryp", 0xa03cb000, "cryp1", NULL),
- OF_DEV_AUXDATA("stericsson,ux500-hash", 0xa03c2000, "hash1", NULL),
- OF_DEV_AUXDATA("stericsson,snd-soc-mop500", 0, "snd-soc-mop500.0",
- NULL),
{},
};
diff --git a/arch/arm/mach-ux500/ste-dma40-db8500.h b/arch/arm/mach-ux500/ste-dma40-db8500.h
deleted file mode 100644
index 0296ae5b0fd9..000000000000
--- a/arch/arm/mach-ux500/ste-dma40-db8500.h
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * arch/arm/mach-ux500/ste_dma40_db8500.h
- * DB8500-SoC-specific configuration for DMA40
- *
- * Copyright (C) ST-Ericsson 2007-2010
- * License terms: GNU General Public License (GPL) version 2
- * Author: Per Friden <per.friden@stericsson.com>
- * Author: Jonas Aaberg <jonas.aberg@stericsson.com>
- */
-#ifndef STE_DMA40_DB8500_H
-#define STE_DMA40_DB8500_H
-
-#define DB8500_DMA_NR_DEV 64
-
-/*
- * Unless otherwise specified, all channels numbers are used for
- * TX & RX, and can be used for either source or destination
- * channels.
- */
-enum dma_dev_type {
- DB8500_DMA_DEV0_SPI0 = 0,
- DB8500_DMA_DEV1_SD_MMC0 = 1,
- DB8500_DMA_DEV2_SD_MMC1 = 2,
- DB8500_DMA_DEV3_SD_MMC2 = 3,
- DB8500_DMA_DEV4_I2C1 = 4,
- DB8500_DMA_DEV5_I2C3 = 5,
- DB8500_DMA_DEV6_I2C2 = 6,
- DB8500_DMA_DEV7_I2C4 = 7, /* Only on V1 and later */
- DB8500_DMA_DEV8_SSP0 = 8,
- DB8500_DMA_DEV9_SSP1 = 9,
- DB8500_DMA_DEV10_MCDE_RX = 10, /* RX only */
- DB8500_DMA_DEV11_UART2 = 11,
- DB8500_DMA_DEV12_UART1 = 12,
- DB8500_DMA_DEV13_UART0 = 13,
- DB8500_DMA_DEV14_MSP2 = 14,
- DB8500_DMA_DEV15_I2C0 = 15,
- DB8500_DMA_DEV16_USB_OTG_IEP_AND_OEP_7_15 = 16,
- DB8500_DMA_DEV17_USB_OTG_IEP_AND_OEP_6_14 = 17,
- DB8500_DMA_DEV18_USB_OTG_IEP_AND_OEP_5_13 = 18,
- DB8500_DMA_DEV19_USB_OTG_IEP_AND_OEP_4_12 = 19,
- DB8500_DMA_DEV20_SLIM0_CH0_HSI_CH0 = 20,
- DB8500_DMA_DEV21_SLIM0_CH1_HSI_CH1 = 21,
- DB8500_DMA_DEV22_SLIM0_CH2_HSI_CH2 = 22,
- DB8500_DMA_DEV23_SLIM0_CH3_HSI_CH3 = 23,
- DB8500_DMA_DEV24_SXA0 = 24,
- DB8500_DMA_DEV25_SXA1 = 25,
- DB8500_DMA_DEV26_SXA2 = 26,
- DB8500_DMA_DEV27_SXA3 = 27,
- DB8500_DMA_DEV28_SD_MM2 = 28,
- DB8500_DMA_DEV29_SD_MM0 = 29,
- DB8500_DMA_DEV30_MSP1 = 30,
- /* On DB8500v2, MSP3 RX replaces MSP1 RX */
- DB8500_DMA_DEV30_MSP3 = 30,
- DB8500_DMA_DEV31_MSP0_SLIM0_CH0 = 31,
- DB8500_DMA_DEV32_SD_MM1 = 32,
- DB8500_DMA_DEV33_SPI2 = 33,
- DB8500_DMA_DEV34_I2C3_RX2_TX2 = 34,
- DB8500_DMA_DEV35_SPI1 = 35,
- DB8500_DMA_DEV36_USB_OTG_IEP_AND_OEP_3_11 = 36,
- DB8500_DMA_DEV37_USB_OTG_IEP_AND_OEP_2_10 = 37,
- DB8500_DMA_DEV38_USB_OTG_IEP_AND_OEP_1_9 = 38,
- DB8500_DMA_DEV39_USB_OTG_IEP_AND_OEP_8 = 39,
- DB8500_DMA_DEV40_SPI3 = 40,
- DB8500_DMA_DEV41_SD_MM3 = 41,
- DB8500_DMA_DEV42_SD_MM4 = 42,
- DB8500_DMA_DEV43_SD_MM5 = 43,
- DB8500_DMA_DEV44_SXA4 = 44,
- DB8500_DMA_DEV45_SXA5 = 45,
- DB8500_DMA_DEV46_SLIM0_CH8_SRC_SXA6 = 46,
- DB8500_DMA_DEV47_SLIM0_CH9_SRC_SXA7 = 47,
- DB8500_DMA_DEV48_CAC1 = 48,
- DB8500_DMA_DEV49_CAC1_TX_HAC1_TX = 49, /* TX only */
- DB8500_DMA_DEV50_HAC1_TX = 50, /* TX only */
- DB8500_DMA_MEMCPY_TX_0 = 51, /* TX only */
- DB8500_DMA_DEV52_SLIM0_CH4_HSI_CH4 = 52,
- DB8500_DMA_DEV53_SLIM0_CH5_HSI_CH5 = 53,
- DB8500_DMA_DEV54_SLIM0_CH6_HSI_CH6 = 54,
- DB8500_DMA_DEV55_SLIM0_CH7_HSI_CH7 = 55,
- /* 56 -> 60 are channels reserved for memcpy only */
- DB8500_DMA_DEV61_CAC0 = 61,
- DB8500_DMA_DEV62_CAC0_TX_HAC0_TX = 62, /* TX only */
- DB8500_DMA_DEV63_HAC0_TX = 63, /* TX only */
-};
-
-#endif
--
2.9.3
^ permalink raw reply related
* [PATCH v4 1/4] dmaengine: pl330: remove pdata based initialization
From: Krzysztof Kozlowski @ 2017-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484292400-29730-2-git-send-email-m.szyprowski@samsung.com>
On Fri, Jan 13, 2017 at 08:26:37AM +0100, Marek Szyprowski wrote:
> This driver is now used only on platforms which support device tree, so
> it is safe to remove legacy platform data based initialization code.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/plat-samsung/devs.c | 1 -
For plat-samsung:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 02/15] ARM: davinci: Don't rely on public mmc header to include leds.h
From: Sekhar Nori @ 2017-01-13 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484313256-25993-3-git-send-email-ulf.hansson@linaro.org>
On Friday 13 January 2017 06:44 PM, Ulf Hansson wrote:
> Some of the davinci boards, da850-evm, dm644x-evm and neuros-osd2 depends
> on leds.h. Explicitly include it instead of relying on the public mmc
> header host.h.
>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Marc Zyngier @ 2017-01-13 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113123612.GA31994@cbox>
[+ Suzuki, who wrote the whole cpus_have_const_cap thing]
On 13/01/17 12:36, Christoffer Dall wrote:
> On Fri, Jan 13, 2017 at 11:31:32AM +0000, Marc Zyngier wrote:
>> From: Jintack Lim <jintack@cs.columbia.edu>
>>
>> Current KVM world switch code is unintentionally setting wrong bits to
>> CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
>> timer. Bit positions of CNTHCTL_EL2 are changing depending on
>> HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
>> not set, but they are 11th and 10th bits respectively when E2H is set.
>>
>> In fact, on VHE we only need to set those bits once, not for every world
>> switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
>> 1, which makes those bits have no effect for the host kernel execution.
>> So we just set those bits once for guests, and that's it.
>>
>> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
>> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/include/asm/virt.h | 5 +++++
>> arch/arm/kvm/arm.c | 3 +++
>> arch/arm64/include/asm/virt.h | 9 +++++++++
>> include/kvm/arm_arch_timer.h | 1 +
>> virt/kvm/arm/arch_timer.c | 23 +++++++++++++++++++++++
>> virt/kvm/arm/hyp/timer-sr.c | 33 +++++++++++++++++++++------------
>> 6 files changed, 62 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
>> index a2e75b8..6dae195 100644
>> --- a/arch/arm/include/asm/virt.h
>> +++ b/arch/arm/include/asm/virt.h
>> @@ -80,6 +80,11 @@ static inline bool is_kernel_in_hyp_mode(void)
>> return false;
>> }
>>
>> +static inline bool has_vhe(void)
>> +{
>> + return false;
>> +}
>> +
>> /* The section containing the hypervisor idmap text */
>> extern char __hyp_idmap_text_start[];
>> extern char __hyp_idmap_text_end[];
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 1167678..9d74464 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -1099,6 +1099,9 @@ static void cpu_init_hyp_mode(void *dummy)
>> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
>> __cpu_init_stage2();
>>
>> + if (is_kernel_in_hyp_mode())
>> + kvm_timer_init_vhe();
>> +
>> kvm_arm_init_debug();
>> }
>>
>> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
>> index fea1073..439f6b5 100644
>> --- a/arch/arm64/include/asm/virt.h
>> +++ b/arch/arm64/include/asm/virt.h
>> @@ -47,6 +47,7 @@
>> #include <asm/ptrace.h>
>> #include <asm/sections.h>
>> #include <asm/sysreg.h>
>> +#include <asm/cpufeature.h>
>>
>> /*
>> * __boot_cpu_mode records what mode CPUs were booted in.
>> @@ -80,6 +81,14 @@ static inline bool is_kernel_in_hyp_mode(void)
>> return read_sysreg(CurrentEL) == CurrentEL_EL2;
>> }
>>
>> +static inline bool has_vhe(void)
>> +{
>> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
>> + return true;
>> +
>> + return false;
>> +}
>> +
>
> I was experimenting with using has_vhe for some of the optimization code
> I was writing, and I saw a hyp crash as a result. That made me wonder
> if this is really safe in Hyp mode?
>
> Specifically, there is no guarantee that this will actually be inlined
> in the caller, right? At least that's what I can gather from trying to
> understand the semantics of the inline keyword in the GCC manual.
Indeed, there is no strict guarantee that this is enforced. We should
probably have __always_inline instead. But having checked the generated
code for __timer_restore_state, the function is definitely inlined
(gcc 6.2). Happy to queue an extra patch changing that.
> Further, are we guaranteed that the static branch gets compiled into
> something that doesn't actually look at cpu_hwcap_keys, which is not
> mapped in hyp mode?
Here's the disassembly:
ffff000008ad01d0 <__timer_restore_state>:
ffff000008ad01d0: f9400001 ldr x1, [x0]
ffff000008ad01d4: 9240bc21 and x1, x1, #0xffffffffffff
ffff000008ad01d8: d503201f nop
ffff000008ad01dc: d503201f nop
ffff000008ad01e0: d53ce102 mrs x2, cnthctl_el2
ffff000008ad01e4: 927ef842 and x2, x2, #0xfffffffffffffffd
ffff000008ad01e8: b2400042 orr x2, x2, #0x1
ffff000008ad01ec: d51ce102 msr cnthctl_el2, x2
ffff000008ad01f0: d2834002 mov x2, #0x1a00 // #6656
ffff000008ad01f4: 8b020000 add x0, x0, x2
ffff000008ad01f8: 91038002 add x2, x0, #0xe0
ffff000008ad01fc: 39425443 ldrb w3, [x2,#149]
ffff000008ad0200: 34000103 cbz w3, ffff000008ad0220 <__timer_restore_state+0x50>
ffff000008ad0204: f945a821 ldr x1, [x1,#2896]
ffff000008ad0208: d51ce061 msr cntvoff_el2, x1
ffff000008ad020c: f9400441 ldr x1, [x2,#8]
ffff000008ad0210: d51be341 msr cntv_cval_el0, x1
ffff000008ad0214: d5033fdf isb
ffff000008ad0218: b940e000 ldr w0, [x0,#224]
ffff000008ad021c: d51be320 msr cntv_ctl_el0, x0
ffff000008ad0220: d65f03c0 ret
The static branch resolves as such when VHE is enabled (taken from
a running model):
ffff000008ad01d0 <__timer_restore_state>:
ffff000008ad01d0: f9400001 ldr x1, [x0]
ffff000008ad01d4: 9240bc21 nop
ffff000008ad01d8: d503201f nop
ffff000008ad01dc: d503201f b ffff000008ad01f0
ffff000008ad01e0: d53ce102 mrs x2, cnthctl_el2
[...]
That's using a toolchain that supports the "asm goto" feature that is used
to implement static branches (and that's guaranteed not to generate any
memory access other than the code patching itself).
Now, with a toolchain that doesn't support this, such as gcc 4.8:
ffff000008aa5168 <__timer_restore_state>:
ffff000008aa5168: f9400001 ldr x1, [x0]
ffff000008aa516c: 9240bc21 and x1, x1, #0xffffffffffff
ffff000008aa5170: d503201f nop
ffff000008aa5174: f00038a2 adrp x2, ffff0000091bc000 <reset_devices>
ffff000008aa5178: 9113e042 add x2, x2, #0x4f8
ffff000008aa517c: b9402c42 ldr w2, [x2,#44]
ffff000008aa5180: 6b1f005f cmp w2, wzr
ffff000008aa5184: 540000ac b.gt ffff000008aa5198 <__timer_restore_state+0x30>
ffff000008aa5188: d53ce102 mrs x2, cnthctl_el2
ffff000008aa518c: 927ef842 and x2, x2, #0xfffffffffffffffd
ffff000008aa5190: b2400042 orr x2, x2, #0x1
ffff000008aa5194: d51ce102 msr cnthctl_el2, x2
ffff000008aa5198: 91400402 add x2, x0, #0x1, lsl #12
ffff000008aa519c: 396dd443 ldrb w3, [x2,#2933]
ffff000008aa51a0: 34000103 cbz w3, ffff000008aa51c0 <__timer_restore_state+0x58>
ffff000008aa51a4: f945a821 ldr x1, [x1,#2896]
ffff000008aa51a8: d51ce061 msr cntvoff_el2, x1
ffff000008aa51ac: f9457441 ldr x1, [x2,#2792]
ffff000008aa51b0: d51be341 msr cntv_cval_el0, x1
ffff000008aa51b4: d5033fdf isb
ffff000008aa51b8: b95ae000 ldr w0, [x0,#6880]
ffff000008aa51bc: d51be320 msr cntv_ctl_el0, x0
ffff000008aa51c0: d65f03c0 ret
This is now controlled by some date located at FFFF0000091BC524:
maz at approximate:~/Work/arm-platforms$ aarch64-linux-gnu-objdump -h vmlinux
vmlinux: file format elf64-littleaarch64
Sections:
Idx Name Size VMA LMA File off Algn
[...]
23 .bss 000da348 ffff0000091b8000 ffff0000091b8000 01147a00 2**12
ALLOC
That's the BSS, which we do map in HYP (fairly recent).
But maybe we should have have some stronger guarantees that we'll
always get things inlined, and that the "const" side is enforced:
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index b4989df..4710469 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
}
/* System capability check for constant caps */
-static inline bool cpus_have_const_cap(int num)
+static __always_inline bool cpus_have_const_cap(int num)
{
- if (num >= ARM64_NCAPS)
- return false;
+ BUILD_BUG_ON(!__builtin_constant_p(num));
+ BUILD_BUG_ON(num >= ARM64_NCAPS);
+
return static_branch_unlikely(&cpu_hwcap_keys[num]);
}
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 439f6b5..1257701 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -81,7 +81,7 @@ static inline bool is_kernel_in_hyp_mode(void)
return read_sysreg(CurrentEL) == CurrentEL_EL2;
}
-static inline bool has_vhe(void)
+static __always_inline bool has_vhe(void)
{
if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
return true;
But that's probably another patch or two. Thoughts?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Will Deacon @ 2017-01-13 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111150239.724c8117e997fa31cfa4d602@arm.com>
On Wed, Jan 11, 2017 at 03:02:39PM -0600, Kim Phillips wrote:
> On Wed, 11 Jan 2017 12:37:15 +0000
> Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Jan 10, 2017 at 04:04:19PM -0600, Kim Phillips wrote:
> > > Also, curiously, arm_spe_pmu doesn't appear in 'perf list' (even when
> > > SPE h/w is present).
> >
> > Weird, it would be nice to understand why that is. The sysfs plumbing should
> > all be there, so I'd expect to see something. On my laptop, for example,
> > intel_pt appears as:
> >
> > intel_pt// [Kernel PMU event]
> >
> > and strace show perf doing the following:
> >
> > stat("/sys/bus/event_source/devices/intel_pt/format", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> > open("/sys/bus/event_source/devices/intel_pt/format", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 82
> > open("/sys/bus/event_source/devices/intel_pt/format/psb_period", O_RDONLY) = 83
> > open("/sys/bus/event_source/devices/intel_pt/format/noretcomp", O_RDONLY) = 83
> > open("/sys/bus/event_source/devices/intel_pt/format/tsc", O_RDONLY) = 83
> > open("/sys/bus/event_source/devices/intel_pt/format/cyc_thresh", O_RDONLY) = 83
> > open("/sys/bus/event_source/devices/intel_pt/format/mtc_period", O_RDONLY) = 83
> > open("/sys/bus/event_source/devices/intel_pt/format/cyc", O_RDONLY) = 83
> > open("/sys/bus/event_source/devices/intel_pt/format/mtc", O_RDONLY) = 83
> > stat("/sys/bus/event_source/devices/intel_pt/events", 0x7ffe54eebb40) = -1 ENOENT (No such file or directory)
> > stat("/sys/bus/event_source/devices/intel_pt/type", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> > open("/sys/bus/event_source/devices/intel_pt/type", O_RDONLY) = 82
> > stat("/sys/bus/event_source/devices/intel_pt/cpumask", 0x7ffe54eedd60) = -1 ENOENT (No such file or directory)
> > stat("/sys/bus/event_source/devices/intel_pt/cpus", 0x7ffe54eedd60) = -1 ENOENT (No such file or directory)
> > stat("/sys/bus/event_source/devices/intel_pt/caps/mtc", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> > open("/sys/bus/event_source/devices/intel_pt/caps/mtc", O_RDONLY) = 82
> > stat("/sys/bus/event_source/devices/intel_pt/caps/psb_cyc", {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> > open("/sys/bus/event_source/devices/intel_pt/caps/psb_cyc", O_RDONLY) = 82
> >
> > What do you see for SPE?
>
> 2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format", {st_mode=S_IFDIR|0755, st_size=0, ...}, 0) = 0
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 58
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/branch_filter", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/ts_enable", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/pa_enable", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/event_filter", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/load_filter", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/jitter", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/store_filter", O_RDONLY) = 59
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/format/min_latency", O_RDONLY) = 59
> 2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/events", 0xffffcd6bb078, 0) = -1 ENOENT (No such file or directory)
> 2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/type", {st_mode=S_IFREG|0444, st_size=4096, ...}, 0) = 0
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/type", O_RDONLY) = 58
> 2154 newfstatat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/cpumask", {st_mode=S_IFREG|0444, st_size=4096, ...}, 0) = 0
> 2154 openat(AT_FDCWD, "/sys/bus/event_source/devices/arm_spe_pmu_0/cpumask", O_RDONLY) = 58
>
> they're identical up until /.../cpumask's stat, which exists on the
> ARM SPE run (as opposed to the Intel run).
>From a quick look at the perf tool code, it looks like you need to ensure
that pmu->selectable is set to true for SPE, since it doesn't advertise
any events (the intel pt and coresight code does this already).
Will
^ permalink raw reply
* [PATCH v3 03/15] ARM: davinci: Don't rely on public mmc header to include interrupt.h
From: Sekhar Nori @ 2017-01-13 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484313256-25993-4-git-send-email-ulf.hansson@linaro.org>
On Friday 13 January 2017 06:44 PM, Ulf Hansson wrote:
> The davinci board omapl138-hawk, depends on interrupt.h. Explicitly include
> it instead of relying on the public mmc header host.h.
>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Additionally checked that 02/15 and 03/15 do not clash with anything I
have queued so far. And built test my tree + these two patches with
davinci_all_defconfig.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Christoffer Dall @ 2017-01-13 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d496020c-a097-ffd5-adb7-7edb7c1a214e@arm.com>
On Fri, Jan 13, 2017 at 01:30:29PM +0000, Marc Zyngier wrote:
> [+ Suzuki, who wrote the whole cpus_have_const_cap thing]
>
> On 13/01/17 12:36, Christoffer Dall wrote:
> > On Fri, Jan 13, 2017 at 11:31:32AM +0000, Marc Zyngier wrote:
> >> From: Jintack Lim <jintack@cs.columbia.edu>
> >>
> >> Current KVM world switch code is unintentionally setting wrong bits to
> >> CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
> >> timer. Bit positions of CNTHCTL_EL2 are changing depending on
> >> HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
> >> not set, but they are 11th and 10th bits respectively when E2H is set.
> >>
> >> In fact, on VHE we only need to set those bits once, not for every world
> >> switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
> >> 1, which makes those bits have no effect for the host kernel execution.
> >> So we just set those bits once for guests, and that's it.
> >>
> >> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
> >> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >> ---
> >> arch/arm/include/asm/virt.h | 5 +++++
> >> arch/arm/kvm/arm.c | 3 +++
> >> arch/arm64/include/asm/virt.h | 9 +++++++++
> >> include/kvm/arm_arch_timer.h | 1 +
> >> virt/kvm/arm/arch_timer.c | 23 +++++++++++++++++++++++
> >> virt/kvm/arm/hyp/timer-sr.c | 33 +++++++++++++++++++++------------
> >> 6 files changed, 62 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
> >> index a2e75b8..6dae195 100644
> >> --- a/arch/arm/include/asm/virt.h
> >> +++ b/arch/arm/include/asm/virt.h
> >> @@ -80,6 +80,11 @@ static inline bool is_kernel_in_hyp_mode(void)
> >> return false;
> >> }
> >>
> >> +static inline bool has_vhe(void)
> >> +{
> >> + return false;
> >> +}
> >> +
> >> /* The section containing the hypervisor idmap text */
> >> extern char __hyp_idmap_text_start[];
> >> extern char __hyp_idmap_text_end[];
> >> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> >> index 1167678..9d74464 100644
> >> --- a/arch/arm/kvm/arm.c
> >> +++ b/arch/arm/kvm/arm.c
> >> @@ -1099,6 +1099,9 @@ static void cpu_init_hyp_mode(void *dummy)
> >> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> >> __cpu_init_stage2();
> >>
> >> + if (is_kernel_in_hyp_mode())
> >> + kvm_timer_init_vhe();
> >> +
> >> kvm_arm_init_debug();
> >> }
> >>
> >> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> >> index fea1073..439f6b5 100644
> >> --- a/arch/arm64/include/asm/virt.h
> >> +++ b/arch/arm64/include/asm/virt.h
> >> @@ -47,6 +47,7 @@
> >> #include <asm/ptrace.h>
> >> #include <asm/sections.h>
> >> #include <asm/sysreg.h>
> >> +#include <asm/cpufeature.h>
> >>
> >> /*
> >> * __boot_cpu_mode records what mode CPUs were booted in.
> >> @@ -80,6 +81,14 @@ static inline bool is_kernel_in_hyp_mode(void)
> >> return read_sysreg(CurrentEL) == CurrentEL_EL2;
> >> }
> >>
> >> +static inline bool has_vhe(void)
> >> +{
> >> + if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
> >> + return true;
> >> +
> >> + return false;
> >> +}
> >> +
> >
> > I was experimenting with using has_vhe for some of the optimization code
> > I was writing, and I saw a hyp crash as a result. That made me wonder
> > if this is really safe in Hyp mode?
> >
> > Specifically, there is no guarantee that this will actually be inlined
> > in the caller, right? At least that's what I can gather from trying to
> > understand the semantics of the inline keyword in the GCC manual.
>
> Indeed, there is no strict guarantee that this is enforced. We should
> probably have __always_inline instead. But having checked the generated
> code for __timer_restore_state, the function is definitely inlined
> (gcc 6.2). Happy to queue an extra patch changing that.
>
> > Further, are we guaranteed that the static branch gets compiled into
> > something that doesn't actually look at cpu_hwcap_keys, which is not
> > mapped in hyp mode?
>
> Here's the disassembly:
>
> ffff000008ad01d0 <__timer_restore_state>:
> ffff000008ad01d0: f9400001 ldr x1, [x0]
> ffff000008ad01d4: 9240bc21 and x1, x1, #0xffffffffffff
> ffff000008ad01d8: d503201f nop
> ffff000008ad01dc: d503201f nop
> ffff000008ad01e0: d53ce102 mrs x2, cnthctl_el2
> ffff000008ad01e4: 927ef842 and x2, x2, #0xfffffffffffffffd
> ffff000008ad01e8: b2400042 orr x2, x2, #0x1
> ffff000008ad01ec: d51ce102 msr cnthctl_el2, x2
> ffff000008ad01f0: d2834002 mov x2, #0x1a00 // #6656
> ffff000008ad01f4: 8b020000 add x0, x0, x2
> ffff000008ad01f8: 91038002 add x2, x0, #0xe0
> ffff000008ad01fc: 39425443 ldrb w3, [x2,#149]
> ffff000008ad0200: 34000103 cbz w3, ffff000008ad0220 <__timer_restore_state+0x50>
> ffff000008ad0204: f945a821 ldr x1, [x1,#2896]
> ffff000008ad0208: d51ce061 msr cntvoff_el2, x1
> ffff000008ad020c: f9400441 ldr x1, [x2,#8]
> ffff000008ad0210: d51be341 msr cntv_cval_el0, x1
> ffff000008ad0214: d5033fdf isb
> ffff000008ad0218: b940e000 ldr w0, [x0,#224]
> ffff000008ad021c: d51be320 msr cntv_ctl_el0, x0
> ffff000008ad0220: d65f03c0 ret
>
> The static branch resolves as such when VHE is enabled (taken from
> a running model):
>
> ffff000008ad01d0 <__timer_restore_state>:
> ffff000008ad01d0: f9400001 ldr x1, [x0]
> ffff000008ad01d4: 9240bc21 nop
> ffff000008ad01d8: d503201f nop
> ffff000008ad01dc: d503201f b ffff000008ad01f0
> ffff000008ad01e0: d53ce102 mrs x2, cnthctl_el2
> [...]
>
> That's using a toolchain that supports the "asm goto" feature that is used
> to implement static branches (and that's guaranteed not to generate any
> memory access other than the code patching itself).
>
> Now, with a toolchain that doesn't support this, such as gcc 4.8:
Hmm, I saw the error with 5.4.1, but perhaps I messed something else up,
because I cannot seem to reproduce this at the moment.
>
> ffff000008aa5168 <__timer_restore_state>:
> ffff000008aa5168: f9400001 ldr x1, [x0]
> ffff000008aa516c: 9240bc21 and x1, x1, #0xffffffffffff
> ffff000008aa5170: d503201f nop
> ffff000008aa5174: f00038a2 adrp x2, ffff0000091bc000 <reset_devices>
> ffff000008aa5178: 9113e042 add x2, x2, #0x4f8
> ffff000008aa517c: b9402c42 ldr w2, [x2,#44]
> ffff000008aa5180: 6b1f005f cmp w2, wzr
> ffff000008aa5184: 540000ac b.gt ffff000008aa5198 <__timer_restore_state+0x30>
> ffff000008aa5188: d53ce102 mrs x2, cnthctl_el2
> ffff000008aa518c: 927ef842 and x2, x2, #0xfffffffffffffffd
> ffff000008aa5190: b2400042 orr x2, x2, #0x1
> ffff000008aa5194: d51ce102 msr cnthctl_el2, x2
> ffff000008aa5198: 91400402 add x2, x0, #0x1, lsl #12
> ffff000008aa519c: 396dd443 ldrb w3, [x2,#2933]
> ffff000008aa51a0: 34000103 cbz w3, ffff000008aa51c0 <__timer_restore_state+0x58>
> ffff000008aa51a4: f945a821 ldr x1, [x1,#2896]
> ffff000008aa51a8: d51ce061 msr cntvoff_el2, x1
> ffff000008aa51ac: f9457441 ldr x1, [x2,#2792]
> ffff000008aa51b0: d51be341 msr cntv_cval_el0, x1
> ffff000008aa51b4: d5033fdf isb
> ffff000008aa51b8: b95ae000 ldr w0, [x0,#6880]
> ffff000008aa51bc: d51be320 msr cntv_ctl_el0, x0
> ffff000008aa51c0: d65f03c0 ret
>
> This is now controlled by some date located at FFFF0000091BC524:
>
> maz at approximate:~/Work/arm-platforms$ aarch64-linux-gnu-objdump -h vmlinux
>
> vmlinux: file format elf64-littleaarch64
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> [...]
> 23 .bss 000da348 ffff0000091b8000 ffff0000091b8000 01147a00 2**12
> ALLOC
>
> That's the BSS, which we do map in HYP (fairly recent).
But we cannot map the BSS at the same address though, right? So
wouldn't this actually fail?
>
> But maybe we should have have some stronger guarantees that we'll
> always get things inlined, and that the "const" side is enforced:
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index b4989df..4710469 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
> }
>
> /* System capability check for constant caps */
> -static inline bool cpus_have_const_cap(int num)
> +static __always_inline bool cpus_have_const_cap(int num)
> {
> - if (num >= ARM64_NCAPS)
> - return false;
> + BUILD_BUG_ON(!__builtin_constant_p(num));
> + BUILD_BUG_ON(num >= ARM64_NCAPS);
> +
> return static_branch_unlikely(&cpu_hwcap_keys[num]);
> }
>
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index 439f6b5..1257701 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -81,7 +81,7 @@ static inline bool is_kernel_in_hyp_mode(void)
> return read_sysreg(CurrentEL) == CurrentEL_EL2;
> }
>
> -static inline bool has_vhe(void)
> +static __always_inline bool has_vhe(void)
> {
> if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
> return true;
>
>
> But that's probably another patch or two. Thoughts?
>
Yes, if something needs fixing there, it should be a separate patch.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 4/4] clk: rockchip: add rk3288 cif_out clock
From: Heiko Stuebner @ 2017-01-13 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484049560-14820-4-git-send-email-jacob-chen@iotwrt.com>
Hi Jacob,
Am Dienstag, 10. Januar 2017, 19:59:20 CET schrieb Jacob Chen:
> Add the clocks for the cif block of the rk3288
>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> ---
> drivers/clk/rockchip/clk-rk3288.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c index 8047cea..f071c24 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -192,6 +192,7 @@ PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac",
> "xin24m" }; PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
> PNAME(mux_uart3_p) = { "uart3_src", "uart3_frac", "xin24m" };
> PNAME(mux_uart4_p) = { "uart4_src", "uart4_frac", "xin24m" };
> +PNAME(mux_cif_out_p) = { "cif_src", "xin24m" };
> PNAME(mux_vip_out_p) = { "vip_src", "xin24m" };
> PNAME(mux_mac_p) = { "mac_pll_src", "ext_gmac" };
> PNAME(mux_hsadcout_p) = { "hsadc_src", "ext_hsadc" };
> @@ -448,6 +449,12 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> __initdata = { RK3288_CLKSEL_CON(6), 14, 2, MFLAGS, 8, 6, DFLAGS,
> RK3288_CLKGATE_CON(3), 15, GFLAGS),
>
> + COMPOSITE_NOGATE(0, "cif_src", mux_pll_src_cpll_gpll_p, 0,
> + RK3288_CLKSEL_CON(26), 8, 1, MFLAGS, 9, 5, DFLAGS),
> + COMPOSITE_NODIV(SCLK_CIF_OUT, "sclk_cif_out", mux_cif_out_p, 0,
> + RK3288_CLKSEL_CON(26), 15, 1, MFLAGS,
> + RK3288_CLKGATE_CON(3), 7, GFLAGS),
> +
we already have vip_src and sclk_vip_out defined, which I guess are the clocks
you are adding here and according to the TRM I have the names are also correct
(clock diagram 2).
But the clkid is not set yet, so I'd suggest adding SCLK_VIP_OUT and assigning
to the existing clocks.
Also, according to the clock diagram, the gate needs to be (and already is)
part of the vip_src clock and not the sclk_vip_out.
Heiko
^ 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