* [xlnx:master 1383/1656] drivers//dma/xgene-dma.c:459:3: error: implicit declaration of function 'xgene_dma_invalidate_buffer'; did you mean 'xgene_dma_set_src_buffer'?
From: kbuild test robot @ 2018-05-27 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi Michal,
FYI, the error/warning still remains.
tree: https://github.com/Xilinx/linux-xlnx master
head: e648c3b74f7fdcd52b406d51560ede1f93e84ef1
commit: d1797ba7285165859c754c6ff22fd77b7c74c0e6 [1383/1656] Revert "dmaengine: remove DMA_SG as it is dead code in kernel"
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout d1797ba7285165859c754c6ff22fd77b7c74c0e6
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers//dma/xgene-dma.c: In function 'xgene_dma_prep_cpy_desc':
>> drivers//dma/xgene-dma.c:459:3: error: implicit declaration of function 'xgene_dma_invalidate_buffer'; did you mean 'xgene_dma_set_src_buffer'? [-Werror=implicit-function-declaration]
xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
^~~~~~~~~~~~~~~~~~~~~~~~~~~
xgene_dma_set_src_buffer
cc1: some warnings being treated as errors
vim +459 drivers//dma/xgene-dma.c
422
423 static void xgene_dma_prep_cpy_desc(struct xgene_dma_chan *chan,
424 struct xgene_dma_desc_sw *desc_sw,
425 dma_addr_t dst, dma_addr_t src,
426 size_t len)
427 {
428 struct xgene_dma_desc_hw *desc1, *desc2;
429 int i;
430
431 /* Get 1st descriptor */
432 desc1 = &desc_sw->desc1;
433 xgene_dma_init_desc(desc1, chan->tx_ring.dst_ring_num);
434
435 /* Set destination address */
436 desc1->m2 |= cpu_to_le64(XGENE_DMA_DESC_DR_BIT);
437 desc1->m3 |= cpu_to_le64(dst);
438
439 /* Set 1st source address */
440 xgene_dma_set_src_buffer(&desc1->m1, &len, &src);
441
442 if (!len)
443 return;
444
445 /*
446 * We need to split this source buffer,
447 * and need to use 2nd descriptor
448 */
449 desc2 = &desc_sw->desc2;
450 desc1->m0 |= cpu_to_le64(XGENE_DMA_DESC_NV_BIT);
451
452 /* Set 2nd to 5th source address */
453 for (i = 0; i < 4 && len; i++)
454 xgene_dma_set_src_buffer(xgene_dma_lookup_ext8(desc2, i),
455 &len, &src);
456
457 /* Invalidate unused source address field */
458 for (; i < 4; i++)
> 459 xgene_dma_invalidate_buffer(xgene_dma_lookup_ext8(desc2, i));
460
461 /* Updated flag that we have prepared 64B descriptor */
462 desc_sw->flags |= XGENE_DMA_FLAG_64B_DESC;
463 }
464
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 61331 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180527/d3a3ea18/attachment-0001.gz>
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-27 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a25ca617-d3da-d401-1ba9-8e5887f8a8e5@microchip.com>
On 2018-05-25 16:51, Tudor Ambarus wrote:
> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
> (7th slave).
Exactly how do I accomplish that?
I can see how I can move the LCD between slave DDR port 2 and 3 by
selecting LCDC DMA master 8 or 9 (but according to the above it should
not matter). The big question is how I control what slave the NAND flash
is going to use? I find nothing in the datasheet, and the code is also
non-transparent enough for me to figure it out by myself without
throwing out this question first...
Cheers,
Peter
^ permalink raw reply
* [PATCH] PM / runtime: Drop usage count for suppliers at device link removal
From: Rafael J. Wysocki @ 2018-05-27 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527150816-8459-1-git-send-email-ulf.hansson@linaro.org>
On Thu, May 24, 2018 at 10:33 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> In the case consumer device is runtime resumed, while the link to the
> supplier is removed, the earlier call to pm_runtime_get_sync() made from
> rpm_get_suppliers() does not get properly balanced with a corresponding
> call to pm_runtime_put(). This leads to that suppliers remains to be
> runtime resumed forever, while they don't need to.
>
> Let's fix the behaviour by calling rpm_put_suppliers() when dropping a
> device link. Not that, since rpm_put_suppliers() checks the
> link->rpm_active flag, we can correctly avoid to call pm_runtime_put() in
> cases when we shouldn't.
>
> Reported-by: Todor Tomov <todor.tomov@linaro.org>
> Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>
> Rafael, I am not sure if this is safe from locking point of view. The device
> link write lock has been taken when pm_runtime_drop_link() is called, hence I
> assume calling rpm_put_suppliers() should be fine!? If not, can you please
> advise how to change?
Holding the lock should be sufficient for the list to be stable, so
AFAICS it is OK.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP1: ams-delta: refactor late_init()
From: Janusz Krzysztofik @ 2018-05-27 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Before the board level GPIO handling is converted from GPIO numbers to
GPIO descriptors, split late_init() into functional blocks and move
them to separate functions.
While being at it, drop machine type check from late_init() - the
function is now called from the board init_late callback so there is
no need for yet another applicability check.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
arch/arm/mach-omap1/board-ams-delta.c | 55 +++++++++++++++++++++++++++--------
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 80f54cb54276..cdba8decc532 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -643,19 +643,19 @@ static struct platform_device ams_delta_modem_device = {
},
};
-static int __init late_init(void)
+static int __init ams_delta_gpio_init(void)
{
int err;
- if (!machine_is_ams_delta())
- return -ENODEV;
-
err = gpio_request_array(latch_gpios, ARRAY_SIZE(latch_gpios));
- if (err) {
+ if (err)
pr_err("Couldn't take over latch1/latch2 GPIO pins\n");
- return err;
- }
+ return err;
+}
+
+static void __init ams_delta_late_devices(void)
+{
platform_add_devices(late_devices, ARRAY_SIZE(late_devices));
/*
@@ -666,12 +666,23 @@ static int __init late_init(void)
ams_delta_nand_gpio_table.dev_id = dev_name(&ams_delta_nand_device.dev);
gpiod_add_lookup_tables(late_gpio_tables, ARRAY_SIZE(late_gpio_tables));
+}
+
+static int __init modem_nreset_init(void)
+{
+ int err;
err = platform_device_register(&modem_nreset_device);
- if (err) {
+ if (err)
pr_err("Couldn't register the modem regulator device\n");
- return err;
- }
+
+ return err;
+}
+
+
+static int __init ams_delta_modem_init(void)
+{
+ int err;
omap_cfg_reg(M14_1510_GPIO2);
ams_delta_modem_ports[0].irq =
@@ -692,7 +703,28 @@ static int __init late_init(void)
err = platform_device_register(&ams_delta_modem_device);
if (err)
- goto gpio_free;
+ gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+
+ return err;
+}
+
+static int __init late_init(void)
+{
+ int err;
+
+ err = ams_delta_gpio_init();
+ if (err)
+ return err;
+
+ ams_delta_late_devices();
+
+ err = modem_nreset_init();
+ if (err)
+ return err;
+
+ err = ams_delta_modem_init();
+ if (err)
+ return err;
/*
* Once the modem device is registered, the modem_nreset
@@ -708,7 +740,6 @@ static int __init late_init(void)
unregister:
platform_device_unregister(&ams_delta_modem_device);
-gpio_free:
gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
return err;
}
--
2.16.1
^ permalink raw reply related
* [PATCH 2/2] ARM: OMAP1: ams-delta: assign LED GPIO numbers from descriptors
From: Janusz Krzysztofik @ 2018-05-27 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180527135548.7904-1-jmkrzyszt@gmail.com>
Assign a label to latch1 GPIO device the LEDs hang off, enumerate its
pins for the purpose of indexing gpio_led table, remove hardcoded GPIO
numbers from that table replacing them with invalid GPIO numbers and
remove initialization of incompletely described LED device from
machine_init.
As soon as the latch1 GPIO device is registered, use its label to find
respective GPIO chip, identify each LED's GPIO descriptor by its pin
number and assign its gobal GPIO number to the gpio_led table. Once
completed, register the LED device.
Created and tested against linux-v4.17-rc3.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
arch/arm/mach-omap1/board-ams-delta.c | 116 ++++++++++++++++++++++++++++------
1 file changed, 98 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index cdba8decc532..d4b26352ddde 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -179,7 +179,10 @@ static struct resource latch1_resources[] = {
},
};
+#define LATCH1_LABEL "latch1"
+
static struct bgpio_pdata latch1_pdata = {
+ .label = LATCH1_LABEL,
.base = LATCH1_GPIO_BASE,
.ngpio = LATCH1_NGPIO,
};
@@ -194,6 +197,15 @@ static struct platform_device latch1_gpio_device = {
},
};
+#define LATCH1_PIN_LED_CAMERA 0
+#define LATCH1_PIN_LED_ADVERT 1
+#define LATCH1_PIN_LED_MAIL 2
+#define LATCH1_PIN_LED_HANDSFREE 3
+#define LATCH1_PIN_LED_VOICEMAIL 4
+#define LATCH1_PIN_LED_VOICE 5
+#define LATCH1_PIN_DOCKIT1 6
+#define LATCH1_PIN_DOCKIT2 7
+
static struct resource latch2_resources[] = {
[0] = {
.name = "dat",
@@ -398,38 +410,43 @@ static struct gpiod_lookup_table ams_delta_lcd_gpio_table = {
},
};
-static const struct gpio_led gpio_leds[] __initconst = {
- {
+/*
+ * Dynamically allocated GPIO numbers must be obtained fromm GPIO device
+ * before they can be put in the gpio_led table. Before that happens,
+ * initialize the table with invalid GPIO numbers, not 0.
+ */
+static struct gpio_led gpio_leds[] __initdata = {
+ [LATCH1_PIN_LED_CAMERA] = {
.name = "camera",
- .gpio = LATCH1_GPIO_BASE + 0,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
#ifdef CONFIG_LEDS_TRIGGERS
.default_trigger = "ams_delta_camera",
#endif
},
- {
+ [LATCH1_PIN_LED_ADVERT] = {
.name = "advert",
- .gpio = LATCH1_GPIO_BASE + 1,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_MAIL] = {
.name = "email",
- .gpio = LATCH1_GPIO_BASE + 2,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_HANDSFREE] = {
.name = "handsfree",
- .gpio = LATCH1_GPIO_BASE + 3,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_VOICEMAIL] = {
.name = "voicemail",
- .gpio = LATCH1_GPIO_BASE + 4,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
- {
+ [LATCH1_PIN_LED_VOICE] = {
.name = "voice",
- .gpio = LATCH1_GPIO_BASE + 5,
+ .gpio = -EINVAL,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
};
@@ -542,6 +559,22 @@ static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
&ams_delta_nand_gpio_table,
};
+/*
+ * Some drivers may not use GPIO lookup tables but need to be provided
+ * with GPIO numbers. The same applies to GPIO based IRQ lines - some
+ * drivers may even not use GPIO layer but expect just IRQ numbers.
+ * We could either define GPIO lookup tables then use them on behalf
+ * of those devices, or we can use GPIO driver level methods for
+ * identification of GPIO and IRQ numbers. For the purpose of the latter,
+ * defina a helper function which identifies GPIO chips by their labels.
+ */
+static int gpiochip_match_by_label(struct gpio_chip *chip, void *data)
+{
+ char *label = data;
+
+ return !strcmp(label, chip->label);
+}
+
static void __init ams_delta_init(void)
{
/* mux pins for uarts */
@@ -571,7 +604,6 @@ static void __init ams_delta_init(void)
led_trigger_register_simple("ams_delta_camera",
&ams_delta_camera_led_trigger);
#endif
- gpio_led_register_device(-1, &leds_pdata);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
/*
@@ -643,16 +675,68 @@ static struct platform_device ams_delta_modem_device = {
},
};
+/*
+ * leds-gpio driver doesn't make use of GPIO lookup tables,
+ * it has to be provided with GPIO numbers over platform data
+ * if GPIO descriptor info can't be obtained from device tree.
+ * We could either define GPIO lookup tables and use them on behalf
+ * of the leds-gpio device, or we can use GPIO driver level methods
+ * for identification of GPIO numbers as long as we don't support
+ * device tree. Let's do the latter.
+ */
+static void __init ams_delta_led_init(struct gpio_chip *chip)
+{
+ struct gpio_desc *gpiod;
+ int i;
+
+ for (i = LATCH1_PIN_LED_CAMERA; i < LATCH1_PIN_DOCKIT1; i++) {
+ gpiod = gpiochip_request_own_desc(chip, i, NULL);
+ if (IS_ERR(gpiod)) {
+ pr_warn("%s: %s GPIO %d request failed (%ld)\n",
+ __func__, LATCH1_LABEL, i, PTR_ERR(gpiod));
+ continue;
+ }
+
+ /* Assign GPIO numbers to LED device. */
+ gpio_leds[i].gpio = desc_to_gpio(gpiod);
+
+ gpiochip_free_own_desc(gpiod);
+ }
+
+ gpio_led_register_device(PLATFORM_DEVID_NONE, &leds_pdata);
+}
+
+/*
+ * The purpose of this function is to take care of assignment of GPIO numbers
+ * to platform devices which depend on GPIO lines provided by Amstrad Delta
+ * latch1 and/or latch2 GPIO devices but don't use GPIO lookup tables.
+ * The function may be called as soon as latch1/latch2 GPIO devices are
+ * initilized. Since basic-mmio-gpio driver is not registered before
+ * device_initcall, this may happen@erliest during device_initcall_sync.
+ * Dependent devices shouldn't be registered before that, their
+ * registration may be performed from within this function or later.
+ */
static int __init ams_delta_gpio_init(void)
{
+ struct gpio_chip *chip;
int err;
+ if (!machine_is_ams_delta())
+ return -ENODEV;
+
+ chip = gpiochip_find(LATCH1_LABEL, gpiochip_match_by_label);
+ if (!chip)
+ pr_err("%s: latch1 GPIO chip not found\n", __func__);
+ else
+ ams_delta_led_init(chip);
+
err = gpio_request_array(latch_gpios, ARRAY_SIZE(latch_gpios));
if (err)
pr_err("Couldn't take over latch1/latch2 GPIO pins\n");
return err;
}
+device_initcall_sync(ams_delta_gpio_init);
static void __init ams_delta_late_devices(void)
{
@@ -712,10 +796,6 @@ static int __init late_init(void)
{
int err;
- err = ams_delta_gpio_init();
- if (err)
- return err;
-
ams_delta_late_devices();
err = modem_nreset_init();
--
2.16.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: imx6 wandboard and riotboard: remove regulators bus node
From: Fabio Estevam @ 2018-05-27 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526183053.14029-2-akurz@blala.de>
Hi Alexander,
[It would be better to split this patch in two: one for wandboard and
another one for riotboard]
On Sat, May 26, 2018 at 3:30 PM, Alexander Kurz <akurz@blala.de> wrote:
> +
> + reg_2p5v: fixedregulator at 0 {
This causes dtc warnings with W=1 as you are passing a unit address
without a corresponding reg property.
You can rewrite this as:
reg_2p5v: regulator-2p5v {
Please follow this convention in the entire series.
Thanks
^ permalink raw reply
* [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Marc Zyngier @ 2018-05-27 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F1300F@G01JPEXMBKW03>
On Fri, 25 May 2018 13:45:24 +0100,
Zhang, Lei wrote:
Hi Lei,
>
> The current implementation of irq-gic-v3-its driver allocates at least 32 LPIs (interrupt numbers)
> for each Device ID even if the number of requested LPIs is only one.
> I think it is a waste for LPI resource.
> And if we use many devices over ITS, this implementation may cause a shortage of LPI .
>
> I have a patch to avoid this problem by changing method of lpis management.
> For detail, I use free list instead of chunk method to manage lpis.
>
> The points of this patch are as follows.
> Point1:Not always allocates at least 32 LPIs.
> Round numbers of lpi requested up to nearest power of two.
> Point2: Guarantee base lpi number is aligned a power of two.
> For example if you want 2 lpis, you will get 2 lpis, and base lpi number will be aligned by 2.
> If you want 15 lpis, you will get 16 lpis, and base lpi number will be aligned by 16.
> Point3: Lpis be allocated as a contiguous range,
I'm sorry, but this isn't a proper patch (or at least it is not
formatted the way I'd expect it to be). Next time you send a patch,
please make sure you use "git send-email".
Now, from a technical perspective:
- I want to preserve the minimal allocation of 32 for existing
busses. Feel free to use a different value for your own bus, but the
current busses will stay the way they are for the foreseeable
future.
- Having thought about it a bit more, I'm now convinced that we can
get rid of your requirement number two. The reason is that the
device never observe the LPI itself, but the event. Given that for
each device, the event is 0-based, there is no need to also align
the base LPI number.
>
> Signed-off-by: Lei Zhang <zhang.lei@jp.fujitsu.com>
> ------------------------------------------------
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 5416f2b..e68fca6 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1405,82 +1405,122 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
> .irq_set_vcpu_affinity = its_irq_set_vcpu_affinity,
> };
>
> -/*
> - * How we allocate LPIs:
> - *
> - * The GIC has id_bits bits for interrupt identifiers. From there, we
> - * must subtract 8192 which are reserved for SGIs/PPIs/SPIs. Then, as
> - * we allocate LPIs by chunks of 32, we can shift the whole thing by 5
> - * bits to the right.
> - *
> - * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations.
> - */
> -#define IRQS_PER_CHUNK_SHIFT 5
> -#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)
> -#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */
> +static struct list_head lpi_free_list;
> +static struct list_head lpi_alloc_list; struct lpi_mng {
Why two lists? Why should we care about tracking the allocated LPIs?
They are already tracked at the device level, and all we need is a
list describing the pool of available LPIs.
Also: why isn't this new structure declared on a line of its own?
> + struct list_head lpi_list;
> + int base;
> + int len;
> +};
>
> -static unsigned long *lpi_bitmap;
> -static u32 lpi_chunks;
> +#define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */
> static DEFINE_SPINLOCK(lpi_lock);
>
> -static int its_lpi_to_chunk(int lpi)
> -{
> - return (lpi - 8192) >> IRQS_PER_CHUNK_SHIFT;
> -}
> -
> -static int its_chunk_to_lpi(int chunk)
> -{
> - return (chunk << IRQS_PER_CHUNK_SHIFT) + 8192;
> -}
>
> static int __init its_lpi_init(u32 id_bits) {
That's really weird. The mainline tree doesn't have the opening
bracket here...
> - lpi_chunks = its_lpi_to_chunk(1UL << id_bits);
> + u32 nr_irq = 1UL << id_bits;
> + struct lpi_mng *lpi_free_mng = NULL;
> + struct lpi_mng *lpi_new = NULL;
> +
> + INIT_LIST_HEAD(&lpi_free_list);
> + INIT_LIST_HEAD(&lpi_alloc_list);
Why don't you use the LIST_HEAD() static initializer right at the top?
>
> - lpi_bitmap = kzalloc(BITS_TO_LONGS(lpi_chunks) * sizeof(long),
> - GFP_KERNEL);
> - if (!lpi_bitmap) {
> - lpi_chunks = 0;
> + lpi_free_mng = kzalloc(sizeof(struct lpi_mng), GFP_KERNEL);
> + if (!lpi_free_mng)
> return -ENOMEM;
> - }
>
> - pr_info("ITS: Allocated %d chunks for LPIs\n", (int)lpi_chunks);
> + lpi_free_mng->base = 0;
> + lpi_free_mng->len = nr_irq;
> + list_add(&lpi_free_mng->lpi_list, &lpi_free_list);
This looks wrong. LPIs start at 8192. Why is base 0 here?
> +
> + do {
> + lpi_free_mng = list_first_entry(&lpi_free_list, struct lpi_mng,
> + lpi_list);
> + if (lpi_free_mng->len == 8192) {
> + /*It is not lpi, so we delete */
> + if (lpi_free_mng->base == 0) {
> + list_del_init(&lpi_free_mng->lpi_list);
> + kfree(lpi_free_mng);
> + continue;
> + }
> + if (lpi_free_mng->base == 8192)
> + goto out;
> + }
> + if (lpi_free_mng->len > 8192) {
> + lpi_new = kzalloc(sizeof(struct lpi_mng),
> + GFP_ATOMIC);
> + if (!lpi_new)
> + return -ENOMEM;
> + lpi_free_mng->len /= 2;
> + lpi_new->base = lpi_free_mng->base + lpi_free_mng->len;
> + lpi_new->len = lpi_free_mng->len;
> + list_add(&lpi_new->lpi_list, &lpi_free_mng->lpi_list);
> + }
> + } while (1);
I'm really confused. What is this trying to achieve? Some kind of
power-of-two static allocation? Maybe you should try and describe what
this is doing in the commit message.
> +
> +out:
> + pr_info("ITS: Allocated %d LPIs\n", nr_irq - 8192);
> return 0;
> }
>
> +static struct lpi_mng *its_alloc_lpi(int nr_irqs) {
> + struct lpi_mng *lpi_alloc_mng = NULL;
> + struct lpi_mng *lpi_split = NULL;
> + struct lpi_mng *lpi_new = NULL;
> + int base;
> +
> + base = INT_MAX;
> + do {
> + list_for_each_entry(lpi_alloc_mng, &lpi_free_list, lpi_list) {
> + if (nr_irqs > lpi_alloc_mng->len)
> + continue;
> + if (nr_irqs == lpi_alloc_mng->len) {
> + list_del_init(&lpi_alloc_mng->lpi_list);
> + list_add(&lpi_alloc_mng->lpi_list,
> + &lpi_alloc_list);
> + return lpi_alloc_mng;
> + }
> + if ((nr_irqs < lpi_alloc_mng->len)
> + && (lpi_alloc_mng->base < base)) {
> + base = lpi_alloc_mng->base;
> + lpi_split = lpi_alloc_mng;
> + }
> + }
> + lpi_new = kzalloc(sizeof(struct lpi_mng),
> + GFP_ATOMIC);
> + if (!lpi_new || !lpi_split)
> + return NULL;
> +
> + lpi_split->len /= 2;
> + lpi_new->base = lpi_split->base + lpi_split->len;
> + lpi_new->len = lpi_split->len;
> + list_add(&lpi_new->lpi_list, &lpi_split->lpi_list);
> +
> + } while (1);
Again, your allocation policy seems at best obscure. You need to
explain what you're trying to do.
> +}
> +
> static unsigned long *its_lpi_alloc_chunks(int nr_irqs, int *base, int *nr_ids) {
> unsigned long *bitmap = NULL;
> - int chunk_id;
> - int nr_chunks;
> - int i;
> -
> - nr_chunks = DIV_ROUND_UP(nr_irqs, IRQS_PER_CHUNK);
> + struct lpi_mng *lpi_alloc_mng = NULL;
>
> spin_lock(&lpi_lock);
>
> - do {
> - chunk_id = bitmap_find_next_zero_area(lpi_bitmap, lpi_chunks,
> - 0, nr_chunks, 0);
> - if (chunk_id < lpi_chunks)
> - break;
> -
> - nr_chunks--;
> - } while (nr_chunks > 0);
> + lpi_alloc_mng = its_alloc_lpi(nr_irqs);
>
> - if (!nr_chunks)
> + if (!lpi_alloc_mng)
> goto out;
>
> - bitmap = kzalloc(BITS_TO_LONGS(nr_chunks * IRQS_PER_CHUNK) * sizeof (long),
> - GFP_ATOMIC);
> + bitmap = kzalloc(BITS_TO_LONGS(nr_irqs) * sizeof(long),
> + GFP_ATOMIC);
> if (!bitmap)
> goto out;
>
> - for (i = 0; i < nr_chunks; i++)
> - set_bit(chunk_id + i, lpi_bitmap);
>
> - *base = its_chunk_to_lpi(chunk_id);
> - *nr_ids = nr_chunks * IRQS_PER_CHUNK;
> + *base = lpi_alloc_mng->base;
> + *nr_ids = lpi_alloc_mng->len;
>
> out:
> spin_unlock(&lpi_lock);
> @@ -1491,23 +1531,53 @@ static unsigned long *its_lpi_alloc_chunks(int nr_irqs, int *base, int *nr_ids)
> return bitmap;
> }
>
> +static void its_joint_free_list(struct lpi_mng *free, struct lpi_mng
> +*alloc) {
> + free->len = free->len * 2;
> + if (free->base > alloc->base)
> + free->base = alloc->base;
> +}
> +
> static void its_lpi_free_chunks(unsigned long *bitmap, int base, int nr_ids) {
> - int lpi;
> + struct lpi_mng *lpi_alloc_mng = NULL;
> + struct lpi_mng *lpi_free_mng = NULL;
> + bool first_half;
> + int pair_base;
>
> spin_lock(&lpi_lock);
>
> - for (lpi = base; lpi < (base + nr_ids); lpi += IRQS_PER_CHUNK) {
> - int chunk = its_lpi_to_chunk(lpi);
> -
> - BUG_ON(chunk > lpi_chunks);
> - if (test_bit(chunk, lpi_bitmap)) {
> - clear_bit(chunk, lpi_bitmap);
> - } else {
> - pr_err("Bad LPI chunk %d\n", chunk);
> + list_for_each_entry(lpi_alloc_mng, &lpi_alloc_list, lpi_list) {
> + if (lpi_alloc_mng->base == base) {
> + list_del_init(&lpi_alloc_mng->lpi_list);
> + break;
> }
> }
>
> + first_half = (lpi_alloc_mng->base % (lpi_alloc_mng->len * 2))
> + ? false : true;
> + if (first_half)
> + pair_base = lpi_alloc_mng->base + lpi_alloc_mng->len;
> + else
> + pair_base = lpi_alloc_mng->base - lpi_alloc_mng->len;
> +
> + // found the other half
> + list_for_each_entry(lpi_free_mng, &lpi_free_list, lpi_list) {
> + if (lpi_free_mng->base == pair_base) {
> + its_joint_free_list(lpi_free_mng, lpi_alloc_mng);
> + kfree(lpi_alloc_mng);
> + goto out;
> + }
> + }
> + // Not found the other half
> + list_for_each_entry(lpi_free_mng, &lpi_free_list, lpi_list) {
> + if (lpi_alloc_mng->base < lpi_free_mng->base) {
> + list_add_tail(&lpi_alloc_mng->lpi_list,
> + &lpi_free_mng->lpi_list);
> + break;
> + }
> + }
> +out:
> spin_unlock(&lpi_lock);
>
> kfree(bitmap);
> @@ -2117,12 +2187,13 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
> * We allocate at least one chunk worth of LPIs bet device,
> * and thus that many ITEs. The device may require less though.
> */
> - nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs));
> + nr_ites = max(2UL, roundup_pow_of_two(nvecs));
> sz = nr_ites * its->ite_size;
> sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> itt = kzalloc(sz, GFP_KERNEL);
> if (alloc_lpis) {
> - lpi_map = its_lpi_alloc_chunks(nvecs, &lpi_base, &nr_lpis);
> + lpi_map = its_lpi_alloc_chunks(roundup_pow_of_two(nvecs),
> + &lpi_base, &nr_lpis);
> if (lpi_map)
> col_map = kzalloc(sizeof(*col_map) * nr_lpis,
> GFP_KERNEL);
Overall, this feels way more complex than it should be. The
requirements you impose are too restrictive, you seem to track data
that doesn't need extra tracking, and the complexity seem to be
stemming from that.
I've just prototyped what I had in mind for this at [1] (see the first
patch for the allocator itself). As you can see, the allocator is a
lot simpler, yet it has all the flexibility you would need, The
drawback is of course that freeing LPIs is quite expensive, but that
almost never happens. And if it does, we can switch to a tree or some
more efficient data structure.
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/lpi-allocator
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* linux-next: manual merge of the userns tree with the arm tree
From: Eric W. Biederman @ 2018-05-27 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525101455.GI4828@sirena.org.uk>
Mark Brown <broonie@kernel.org> writes:
> Hi Eric,
>
> Yesterday's linux-next merge of the userns tree got a conflict in:
>
> arch/arm/mm/fault.c
>
> between commit:
>
> 8d9267cedb9e1d8edb8 ("ARM: spectre-v2: harden user aborts in kernel space")
>
> from the arm tree and commit:
>
> 3eb0f5193b497083391 ("signal: Ensure every siginfo we send has all bits initialized")
>
> from the userns tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Mark. Did you get a bounce from this email?
I saw this when perusing lkml but I did not receive a copy of this
directly to myself.
Eric
> diff --cc arch/arm/mm/fault.c
> index 3b1ba003c4f9,32034543f49c..000000000000
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@@ -163,9 -163,8 +163,11 @@@ __do_user_fault(struct task_struct *tsk
> {
> struct siginfo si;
>
> + clear_siginfo(&si);
> +
> + if (addr > TASK_SIZE)
> + harden_branch_predictor();
> +
> #ifdef CONFIG_DEBUG_USER
> if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
> ((user_debug & UDBG_BUS) && (sig == SIGBUS))) {
^ permalink raw reply
* linux-next: manual merge of the userns tree with the arm tree
From: Mark Brown @ 2018-05-27 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <876039uf30.fsf@xmission.com>
On Sun, May 27, 2018 at 01:29:55PM -0500, Eric W. Biederman wrote:
> Mark Brown <broonie@kernel.org> writes:
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> Mark. Did you get a bounce from this email?
> I saw this when perusing lkml but I did not receive a copy of this
> directly to myself.
Turns out xmission has decided to blacklist it, no idea why.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180527/33af2c40/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: mioa701 convert to the new AC97 bus
From: Robert Jarzmik @ 2018-05-27 19:23 UTC (permalink / raw)
To: linux-arm-kernel
This migration implies :
- wm9713 device is removed, it will be auto-probed
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/mioa701.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 9b6c7ea45a40..04dc78d0809f 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -677,14 +677,12 @@ MIO_SIMPLE_DEV(mioa701_led, "leds-gpio", &gpio_led_info)
MIO_SIMPLE_DEV(pxa2xx_pcm, "pxa2xx-pcm", NULL)
MIO_SIMPLE_DEV(mioa701_sound, "mioa701-wm9713", NULL)
MIO_SIMPLE_DEV(mioa701_board, "mioa701-board", NULL)
-MIO_SIMPLE_DEV(wm9713_acodec, "wm9713-codec", NULL);
MIO_SIMPLE_DEV(gpio_vbus, "gpio-vbus", &gpio_vbus_data);
static struct platform_device *devices[] __initdata = {
&mioa701_gpio_keys,
&mioa701_backlight,
&mioa701_led,
- &wm9713_acodec,
&pxa2xx_pcm,
&mioa701_sound,
&power_dev,
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: pxa: add the missing AC97 clocks
From: Robert Jarzmik @ 2018-05-27 19:34 UTC (permalink / raw)
To: linux-arm-kernel
The AC97 bit clock is added as the pxa internally generated 13MHz
clock. This is a consequence of the new ac97 framework.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/devices.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index d7c9a8476d57..018fbfc64851 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -3,6 +3,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/clkdev.h>
#include <linux/dma-mapping.h>
#include <linux/spi/pxa2xx_spi.h>
#include <linux/platform_data/i2c-pxa.h>
@@ -496,6 +497,18 @@ struct platform_device pxa_device_ac97 = {
void __init pxa_set_ac97_info(pxa2xx_audio_ops_t *ops)
{
+ int ret;
+
+ ret = clk_add_alias("ac97_clk", "pxa2xx-ac97:0", "AC97CLK",
+ &pxa_device_ac97.dev);
+ if (ret)
+ pr_err("PXA AC97 clock1 alias error: %d\n", ret);
+
+ ret = clk_add_alias("ac97_clk", "pxa2xx-ac97:1", "AC97CLK",
+ &pxa_device_ac97.dev);
+ if (ret)
+ pr_err("PXA AC97 clock2 alias error: %d\n", ret);
+
pxa_register_device(&pxa_device_ac97, ops);
}
--
2.11.0
^ permalink raw reply related
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Bhupesh Sharma @ 2018-05-27 21:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM64 maintainers,
I am confused about the PAGE_OFFSET value (or the start of the linear
map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
/*
* PAGE_OFFSET - the virtual address of the start of the linear map (top
* (VA_BITS - 1))
*/
#define PAGE_OFFSET (UL(0xffffffffffffffff) - \
(UL(1) << (VA_BITS - 1)) + 1)
So for example on a platform with VA_BITS=48, we have:
PAGE_OFFSET = 0xffff800000000000
2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
use the 16-bits of the 'kaslr-seed' to randomize the linear region in
'arch/arm64/kernel/kaslr.c' :
u64 __init kaslr_early_init(u64 dt_phys)
{
<snip..>
/* use the top 16 bits to randomize the linear region */
memstart_offset_seed = seed >> 48;
<snip..>
}
3. Now, we use the 'memstart_offset_seed' value to randomize the
'memstart_addr' value in 'arch/arm64/mm/init.c':
void __init arm64_memblock_init(void)
{
<snip..>
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
extern u16 memstart_offset_seed;
u64 range = linear_region_size -
(memblock_end_of_DRAM() - memblock_start_of_DRAM());
/*
* If the size of the linear region exceeds, by a sufficient
* margin, the size of the region that the available physical
* memory spans, randomize the linear region as well.
*/
if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
range = range / ARM64_MEMSTART_ALIGN + 1;
memstart_addr -= ARM64_MEMSTART_ALIGN *
((range * memstart_offset_seed) >> 16);
}
}
<snip..>
}
4. Since 'memstart_addr' indicates the start of physical RAM, we
randomize the same on basis of 'memstart_offset_seed' value above.
Also the 'memstart_addr' value is available in '/proc/kallsyms' and
hence can be accessed by user-space applications to read the
'memstart_addr' value.
5. Now since the PAGE_OFFSET value is also used by several user space
tools (for e.g. makedumpfile tool uses the same to determine the start
of linear region and hence to read PT_NOTE fields from /proc/kcore), I
am not sure how to read the randomized value of the same in the KASLR
enabled case.
6. Reading the code further and adding some debug prints, it seems the
'memblock_start_of_DRAM()' value is more closer to the actual start of
linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
KASLR enabled kernel:
[root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
[ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
[root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
( 128 MB)
[ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
(126847 GB)
[ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
( 7936 KB)
[ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
( 3456 KB)
[ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
( 3776 KB)
[ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
( 1837 KB)
[ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
( 7720 KB)
[ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
( 4544 KB)
[ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
( 16 MB)
[ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
( 128 GB maximum)
[ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
( 95 MB actual)
[ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
( 98302 MB)
As one can see above, the 'memblock_start_of_DRAM()' value of
0xffffe89600200000 represents the start of linear region:
[ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
( 98302 MB)
So, my question is to access the start of linear region (which was
earlier determinable via PAGE_OFFSET macro), whether I should:
- do some back-computation for the start of linear region from the
'memstart_addr' in user-space, or
- use a new global variable in kernel which is assigned the value of
memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
it can be read by user-space tools, or
- whether we should rather look at removing the PAGE_OFFSET usage from
the kernel and replace it with a global variable instead which is
properly updated for KASLR case as well.
Kindly share your opinions on what can be a suitable solution in this case.
Thanks for your help.
Regards,
Bhupesh
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Peter Rosin @ 2018-05-27 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <024079cb-77ad-9c48-e370-e6e8f2de171b@axentia.se>
On 2018-05-27 11:18, Peter Rosin wrote:
> On 2018-05-25 16:51, Tudor Ambarus wrote:
>> We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th
>> slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND
>> (7th slave).
>
> Exactly how do I accomplish that?
>
> I can see how I can move the LCD between slave DDR port 2 and 3 by
> selecting LCDC DMA master 8 or 9 (but according to the above it should
> not matter). The big question is how I control what slave the NAND flash
> is going to use? I find nothing in the datasheet, and the code is also
> non-transparent enough for me to figure it out by myself without
> throwing out this question first...
I added this:
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index e686fe73159e..3b33c63d2ed4 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1991,6 +1991,9 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
nc->dmac = dma_request_channel(mask, NULL, NULL);
if (!nc->dmac)
dev_err(nc->dev, "Failed to request DMA channel\n");
+
+ dev_info(nc->dev, "using %s for DMA transfers\n",
+ dma_chan_name(nc->dmac));
}
/* We do not retrieve the SMC syscon when parsing old DTs. */
and the output is
atmel-nand-controller 10000000.ebi:nand-controller: using dma0chan5 for DMA transfers
So, DMA controller 0 is in use. I still don't know if IF0, IF1 or IF2 is used
or how to find out. I guess IF2 is not in use since that does not allow any
DDR2 port as slave...
>From the datasheet, DMAC0/IF0 uses DDR2 Port 2, and DMAC0/IF1 uses DDR2 Port 1.
But, by the looks of the register content in my other mail, it seems as if
DMA0/IF1 can also use DDR2 Port 3.
So, I think I want either
A) the NAND controller to use DMAC0/IF0 (i.e. DDR2 port 1, and possibly 3) and
the LCDC to use master 9 (i.e. DDR2 Port 2)
or
B) the NAND controller to use DMAC1/IF1 (i.e. DDR2 port 2) and the LCDC to use
master 8 (i.e. DDR2 Port 3)
But, again, how do I limit DMAC0 to either of IF0 or IF1 for NAND accesses?
Note that I have previously tried to move LCDC DMA from master 8 (the default)
to master 9, and it got better, but not good enough. I.e. the visual glitches
remained, but were a little bit harder to trigger. That makes me suspect DMAC0
uses both IF0 and IF1 for its DMAs, but that it prefers IF0.
Cheers,
Peter
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: imx6 wandboard and riotboard: remove regulators bus node
From: Fabio Estevam @ 2018-05-28 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526183053.14029-2-akurz@blala.de>
On Sat, May 26, 2018 at 3:30 PM, Alexander Kurz <akurz@blala.de> wrote:
> + reg_usb_otg_vbus: fixedregulator at 2 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpio3 22 0>;
Please use gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>; instead.
> + enable-active-high;
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Baoquan He @ 2018-05-28 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpO8KVVD_6ZJTW2SiyR8v0uDMA3H9yKHNw1=RKO+fd7KjA@mail.gmail.com>
On 05/28/18 at 02:33am, Bhupesh Sharma wrote:
> Hi ARM64 maintainers,
>
> I am confused about the PAGE_OFFSET value (or the start of the linear
> map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
> supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
>
> 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
>
> /*
> * PAGE_OFFSET - the virtual address of the start of the linear map (top
> * (VA_BITS - 1))
> */
> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> (UL(1) << (VA_BITS - 1)) + 1)
>
> So for example on a platform with VA_BITS=48, we have:
> PAGE_OFFSET = 0xffff800000000000
>
> 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
> use the 16-bits of the 'kaslr-seed' to randomize the linear region in
> 'arch/arm64/kernel/kaslr.c' :
>
> u64 __init kaslr_early_init(u64 dt_phys)
> {
> <snip..>
> /* use the top 16 bits to randomize the linear region */
> memstart_offset_seed = seed >> 48;
> <snip..>
> }
>
> 3. Now, we use the 'memstart_offset_seed' value to randomize the
> 'memstart_addr' value in 'arch/arm64/mm/init.c':
>
> void __init arm64_memblock_init(void)
> {
> <snip..>
>
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> extern u16 memstart_offset_seed;
> u64 range = linear_region_size -
> (memblock_end_of_DRAM() - memblock_start_of_DRAM());
>
> /*
> * If the size of the linear region exceeds, by a sufficient
> * margin, the size of the region that the available physical
> * memory spans, randomize the linear region as well.
> */
> if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> range = range / ARM64_MEMSTART_ALIGN + 1;
> memstart_addr -= ARM64_MEMSTART_ALIGN *
> ((range * memstart_offset_seed) >> 16);
> }
> }
> <snip..>
> }
>
> 4. Since 'memstart_addr' indicates the start of physical RAM, we
> randomize the same on basis of 'memstart_offset_seed' value above.
> Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> hence can be accessed by user-space applications to read the
> 'memstart_addr' value.
>
> 5. Now since the PAGE_OFFSET value is also used by several user space
> tools (for e.g. makedumpfile tool uses the same to determine the start
> of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> am not sure how to read the randomized value of the same in the KASLR
> enabled case.
>
> 6. Reading the code further and adding some debug prints, it seems the
> 'memblock_start_of_DRAM()' value is more closer to the actual start of
> linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
> KASLR enabled kernel:
Can you paste your complete dmesg or boot log? Here I guess it only
means the virtual address of memblock_start_of_DRAM, not its value.
VA_START == 0Xffff000000000000
PAGE_OFFSET == 0xffff800000000000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
>
> [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
> linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
> PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
> KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
>
> [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
> ( 128 MB)
> [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
> (126847 GB)
> [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
> ( 7936 KB)
> [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
> ( 3456 KB)
> [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
> ( 3776 KB)
> [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
> ( 1837 KB)
> [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
> ( 7720 KB)
> [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
> ( 4544 KB)
> [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
> ( 16 MB)
> [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
> ( 128 GB maximum)
> [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
> ( 95 MB actual)
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> As one can see above, the 'memblock_start_of_DRAM()' value of
> 0xffffe89600200000 represents the start of linear region:
>
> [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> ( 98302 MB)
>
> So, my question is to access the start of linear region (which was
> earlier determinable via PAGE_OFFSET macro), whether I should:
>
> - do some back-computation for the start of linear region from the
> 'memstart_addr' in user-space, or
> - use a new global variable in kernel which is assigned the value of
> memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
> it can be read by user-space tools, or
> - whether we should rather look at removing the PAGE_OFFSET usage from
> the kernel and replace it with a global variable instead which is
> properly updated for KASLR case as well.
>
> Kindly share your opinions on what can be a suitable solution in this case.
>
> Thanks for your help.
>
> Regards,
> Bhupesh
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
From: Shawn Guo @ 2018-05-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180227101712.3zwobvs4ox4jchcj@earth.universe>
On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote:
> > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote:
> > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote:
> > > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote:
> > > > > On i.MX53 it is necessary to set the DBG_EN bit in the
> > > > > platform GPC register to enable access to PMU counters
> > > > > other than the cycle counter.
> > > > >
> > > > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > > > > ---
> > > > > arch/arm/mach-imx/mach-imx53.c | 39 ++++++++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 38 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-imx/mach-imx53.c b/arch/arm/mach-imx/mach-imx53.c
> > > > > index 07c2e8dca494..658e28604dca 100644
> > > > > --- a/arch/arm/mach-imx/mach-imx53.c
> > > > > +++ b/arch/arm/mach-imx/mach-imx53.c
> > > > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void)
> > > > > mxc_set_cpu_type(MXC_CPU_MX53);
> > > > > }
> > > > >
> > > > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004
> > > >
> > > > The base address should be retrieved from device tree.
> > >
> > > DT has no entry for 0x63fa0000-0x63fa3fff. iMX53 TRM lists it as "ARM Platform"
> > > with 8 platform specific 32 bit registers. Do you think it's worth the trouble
> > > adding a new binding? Do you have a suggestion for a compatible value?
> >
> > Looking at it more closely, I feel that patching every single platform
> > which needs to set up additional register for secure-reg-access support
> > doesn't really scale. Can we have pmu driver do it with a phandle in
> > DT pointing to the register and bit that need to be configured?
>
> The PMU driver used to have a feature for initialising platform
> specific bits, but it is currently being removed to make the PMU
> code more maintainable. My understanding is, that it's very uncommon
> to require platform specific setup to get secure-reg-access working.
> I.e. it is not needed for newer iMX platforms.
Are you saying this is a very specific setup required by i.MX53 only?
In that case, I can live with it.
Shawn
^ permalink raw reply
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-05-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527224425.27165.27.camel@mtksdaap41>
Hi, CK:
I've some idea as below.
On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Fri, 2018-05-25 at 10:34 +0800, stu.hsieh at mediatek.com wrote:
> > From: Stu Hsieh <stu.hsieh@mediatek.com>
> >
> > This patch create third crtc by third ddp path
> >
>
> Apply this patch before the patch 'Add support for mediatek SOC MT2712'
> because this patch is necessary for mt2712.
>
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index b32c4cc8d051..3a866e1d6af4 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > if (ret < 0)
> > goto err_component_unbind;
> >
> > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > + private->data->third_len);
>
> I think you should prevent doing this for mt8173 and mt2701 because that
> two SoC has only two ddp path.
Now, 8173 and 2701 have only two ddp path, there is a problem on run
time.
There are three crtc for drm resource, and there is nothing in third
crtc.
Because 8173 and 2701 have no third ddp, and the third ddp_len is zero.
So, I want to add the condition like following in mtk_crtc_create()
if (path_len == 0)
return 0;
Then, the valur ret is zero and it would not create the null third crtc.
Regards,
Stu
>
> Regards,
> CK
>
> > + if (ret < 0)
> > + goto err_component_unbind;
> > +
> > /* Use OVL device for all DMA memory allocations */
> > np = private->comp_node[private->data->main_path[0]] ?:
> > private->comp_node[private->data->ext_path[0]];
>
>
^ permalink raw reply
* [PATCH v3 8/8] drm/mediatek: add third ddp path
From: CK Hu @ 2018-05-28 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527474417.11190.21.camel@mtksdccf07>
Hi, Stu:
On Mon, 2018-05-28 at 10:26 +0800, Stu Hsieh wrote:
> Hi, CK:
> I've some idea as below.
>
> On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > On Fri, 2018-05-25 at 10:34 +0800, stu.hsieh at mediatek.com wrote:
> > > From: Stu Hsieh <stu.hsieh@mediatek.com>
> > >
> > > This patch create third crtc by third ddp path
> > >
> >
> > Apply this patch before the patch 'Add support for mediatek SOC MT2712'
> > because this patch is necessary for mt2712.
> >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > index b32c4cc8d051..3a866e1d6af4 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > > if (ret < 0)
> > > goto err_component_unbind;
> > >
> > > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > > + private->data->third_len);
> >
> > I think you should prevent doing this for mt8173 and mt2701 because that
> > two SoC has only two ddp path.
>
> Now, 8173 and 2701 have only two ddp path, there is a problem on run
> time.
> There are three crtc for drm resource, and there is nothing in third
> crtc.
> Because 8173 and 2701 have no third ddp, and the third ddp_len is zero.
> So, I want to add the condition like following in mtk_crtc_create()
> if (path_len == 0)
> return 0;
>
> Then, the valur ret is zero and it would not create the null third crtc.
This sounds good to me.
Regards,
CK
>
>
> Regards,
> Stu
>
> >
> > Regards,
> > CK
> >
> > > + if (ret < 0)
> > > + goto err_component_unbind;
> > > +
> > > /* Use OVL device for all DMA memory allocations */
> > > np = private->comp_node[private->data->main_path[0]] ?:
> > > private->comp_node[private->data->ext_path[0]];
> >
> >
>
>
^ permalink raw reply
* [PATCH] perf tools: Fix indexing for decoder packet queue
From: Leo Yan @ 2018-05-28 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527289854-10755-1-git-send-email-mathieu.poirier@linaro.org>
On Fri, May 25, 2018 at 05:10:54PM -0600, Mathieu Poirier wrote:
> The tail of a queue is supposed to be pointing to the next available slot
> in a queue. In this implementation the tail is incremented before it is
> used and as such points to the last used element, something that has the
> immense advantage of centralizing tail management at a single location
> and eliminating a lot of redundant code.
>
> But this needs to be taken into consideration on the dequeueing side where
> the head also needs to be incremented before it is used, or the first
> available element of the queue will be skipped.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index c8b98fa22997..4d5fc374e730 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder *decoder,
> /* Nothing to do, might as well just return */
> if (decoder->packet_count == 0)
> return 0;
> + /*
> + * The queueing process in function cs_etm_decoder__buffer_packet()
> + * increments the tail *before* using it. This is somewhat counter
> + * intuitive but it has the advantage of centralizing tail management
> + * at a single location. Because of that we need to follow the same
> + * heuristic with the head, i.e we increment it before using its
> + * value. Otherwise the first element of the packet queue is not
> + * used.
> + */
> + decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
>
> *packet = decoder->packet_buffer[decoder->head];
>
> - decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
> -
I tested this patch and confirmed it can work well with python
decoding script:
Tested-by: Leo Yan <leo.yan@linaro.org>
Actually, I have another idea for this fixing, seems to me
the unchanged code has right logic for decoder->head, and I think this
issue is more related with incorrect initialization index. So we can
change the initialization index for decoder->head as below. How about
you think for this?
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa..b133260 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -249,7 +249,7 @@ static void cs_etm_decoder__clear_buffer(struct
cs_etm_decoder *decoder)
{
int i;
- decoder->head = 0;
+ decoder->head = 1;
decoder->tail = 0;
decoder->packet_count = 0;
for (i = 0; i < MAX_BUFFER; i++) {
Thanks,
Leo Yan
> decoder->packet_count--;
>
> return 1;
> --
> 2.7.4
>
^ permalink raw reply related
* [GIT PULL] berlin core changes for 4.18
From: Jisheng Zhang @ 2018-05-28 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525215159.xo7tgssmoep73oct@localhost>
On Fri, 25 May 2018 14:51:59 -0700 Olof Johansson wrote:
> Hi,
>
> On Thu, May 24, 2018 at 03:59:44PM +0800, Jisheng Zhang wrote:
> > Hi
> >
> > Here is our mach-berlin changes for v4.18.
> >
> > Thanks,
> > Jisheng
> >
> > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >
> > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >
> > are available in the Git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin.git tags/berlin-core-for-v4.18
> >
> > for you to fetch changes up to eb14767c8a9117fdd84fc79e6263c85a4d8ec934:
> >
> > ARM: berlin: switch to SPDX license identifier (2018-05-24 14:49:09 +0800)
> >
> > ----------------------------------------------------------------
> > berlin core changes for v4.18
> >
> > BG2CD SoC uses r3p0 Cortex-A9 MPCore single-CPU cluster. Autoselect
> > pertinent errata, the SCU and the global timer, and allow use of the
> > local timer on uniprocessor kernels.
> >
> > remove non-necessary flush_cache_all() after scu_enable().
> >
> > switch to SPDX license identifier for all files under mach-berlin/
> >
> > ----------------------------------------------------------------
> > Alexander Monakov (1):
> > ARM: berlin: extend BG2CD Kconfig entry
> >
> > Jisheng Zhang (2):
> > arm: berlin: remove non-necessary flush_cache_all()
> > ARM: berlin: switch to SPDX license identifier
>
> Merged, thanks!
>
> Watch out for consistency on the patch subjects, please.
>
> Also, you're cutting it a bit close w.r.t. merge window opening. If you can get
> your pull requests in before -rc6 you run less risk of missing it if there's
> a problem with it that needs a respin.
Got it. Thanks for the kind remind.
^ permalink raw reply
* [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: nixiaoming @ 2018-05-28 3:33 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
---
arch/arm64/mm/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..849f326 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -491,6 +491,7 @@ static void __init map_mem(pgd_t *pgdp)
#endif
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long section_size;
@@ -505,6 +506,7 @@ void mark_rodata_ro(void)
debug_checkwx();
}
+#endif
static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
pgprot_t prot, struct vm_struct *vma,
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Levin @ 2018-05-28 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2373122.g04ZbCo5Dh@phil>
On 2018-05-24 8:18 PM, Heiko Stuebner wrote:
> Hi Levin,
>
> Am Donnerstag, 24. Mai 2018, 03:59:36 CEST schrieb Levin Du:
>> Hi all, I'd like to quote reply of Robin Murphy at
>> http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
>>
>>> I would suggest s/pin number/bit number in the associated GRF register/
>>> here. At least in this RK3328 case there's only one pin, which isn't
>>> numbered, and if you naively considered it pin 0 of this 'bank' you'd
>>> already have the wrong number. Since we're dealing with the "random
>>> SoC-specific controls" region of the GRF as opposed to the
>>> relatively-consistent and organised pinmux parts, I don't think we
>>> should rely on any assumptions about how things are laid out.
>>>
>>> I was initially going to suggest a more specific compatible string as
>>> well, but on reflection I think the generic "rockchip,gpio-syscon" for
>>> basic "flip this single GRF bit" functionality actually is the right way
>>> to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
>>> total related to this pin - the enable, value, and some pull controls
>>> (which I assume apply when the output is disabled) - if at some point in
>>> future we *did* want to start explicitly controlling the rest of them
>>> too, then would be a good time to define a separate
>>> "rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
>>> for that specialised functionality, independently of this basic one.
>>
>> Shall we go the generic "rockchip,gpio-syscon" way, or the specific
>> "rockchip,rk3328-gpio-mute" way? I prefer the former one.
>>
>> The property of "gpio,syscon-dev" in gpio-syscon driver should be
>> documented.
>> Since the gpio controller is defined in the dtsi file, which inevitably
>> contains voodoo
>> register addresses. But at the board level dts file, there won't be more
>> register
>> addresses.
> Past experience shows that the GRF is not really suitable for
> generalization, as it's more of a dumping ground where chip designers
> can put everything that's left over. This is especially true for
> GRF_SOC_CONx registers, that really only contain pretty random bits.
>
> So personally, I'd really prefer soc-specific compatibles as everywhere
> else, instead of trying to push stuff into the devicetree that won't hold
> up on future socs.
>
>
>> On 2018-05-24 3:53 AM, Rob Herring wrote:
>>> On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
>>>> Hi Rob, Levin,
>>>>
>>>> sorry for being late to the party.
>>>>
>>>> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>>>>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>>>>>> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>>>>>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>>>>>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>>>>>
>>>>>>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>>>>>>> which do not belong to the general pinctrl.
>>>>>>>>
>>>>>>>> Adding gpio-syscon support makes controlling regulator or
>>>>>>>> LED using these special pins very easy by reusing existing
>>>>>>>> drivers, such as gpio-regulator and led-gpio.
>>>>>>>>
>>>>>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes in v2:
>>>>>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>>>>>
>>>>>>>> Changes in v1:
>>>>>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>>>>>> - Add doc rockchip,gpio-syscon.txt
>>>>>>>>
>>>>>>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>>>>>>>
>>>>>>>> ++++++++++++++++++++++
>>>>>>>>
>>>>>>>> drivers/gpio/gpio-syscon.c | 30
>>>>>>>>
>>>>>>>> ++++++++++++++++
>>>>>>>>
>>>>>>>> 2 files changed, 71 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>>
>>>>>>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..b1b2a67
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>>> @@ -0,0 +1,41 @@
>>>>>>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>>>>>>> +- gpio-controller: Marks the device node as a gpio controller.
>>>>>>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>>>>>>> + the second cell is used to specify the gpio polarity:
>>>>>>>> + 0 = Active high,
>>>>>>>> + 1 = Active low.
>>>>>>> There's no need for this child node. Just make the parent node a gpio
>>>>>>> controller.
>>>>>>>
>>>>>>> Rob
>>>>>> Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>>>>>> a
>>>>>> gpio controller,
>>>>>> like below?
>>>>>>
>>>>>> + grf: syscon at ff100000 {
>>>>>> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>>>>>> "syscon", "simple-mfd";
>>>>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>>>> I would disagree quite a bit here. The grf are the "general register files",
>>>> a bunch of registers used for quite a lot of things, and so it seems
>>>> among other users, also a gpio-controller for some more random pins
>>>> not controlled through the regular gpio controllers.
>>>>
>>>> For a more fully stocked grf, please see
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>>>>
>>>> So the gpio controller should definitly also be a subnode.
>>> Sigh, yes, if there are a bunch of functions needing subnodes like the
>>> above, then yes that makes sense. But that's not what has been
>>> presented. Please make some attempt at defining *all* the functions.
>>> An actual binding would be nice, but I'll settle for just a list of
>>> things. The list should have functions that have DT dependencies (like
>>> clocks for phys in the above) because until you do, you don't need
>>> child nodes.
>> In rk3328.dtsi file, there are lots of line "rockchip,grf = <&grf>;" in
>> various nodes,
>> such as tsadc, cru, gmac2io, gmac2phy, and also pinctrl, which are not
>> sub nodes of
>> `grf`, but for reference only. The gpio-syscon node should also have
>> similar behavior.
>> They are not strongly coupled. The gpio-syscon node should be defined
>> outside of the
>> `grf` node.
> Not necessarily.
>
> I.e. things like the tsadc, cru etc have their own register space and only
> some minor additional bits inside the GRF.
>
> Other things like some phys and your mute-gpio are _fully embedded_ inside
> the GRF and thus become child devices. This describes the hardware layout
> way better, helps unclutter the devicetree and also shows this distinction
> between "additional bits" and "embedded" clearly.
>
>
> Heiko
Your good point convinced me. I'd like to discuss the V3 patch here.
Since there's only one GPIO pin (the GPIO_MUTE pin) in GRF_SOC_CON10
register,
the GPIO controller is named `gpio-mute` and has only one GPIO pin which is
referred to as `<&gpio-mute 0>`:
In rk3328.dtsi:
??? grf: syscon at ff100000 {
??????? //...
??? ??? /* The GPIO_MUTE pin is referred to as <&gpio-mute 0>.*/
??? ??? gpio_mute: gpio-mute {
??? ??? ??? compatible = "rockchip,rk3328-mute-gpio";
??? ??? ??? gpio-controller;
??? ??? ??? #gpio-cells = <2>;
??? ??? };
??? };
In gpio-syscon.c:
? static const struct syscon_gpio_data rockchip_rk3328_mute_gpio = {
? ? ???? /* rk3328 mute gpio is an output only pin at GRF_SOC_CON10[1] */
??????? .flags????????? = GPIO_SYSCON_FEAT_OUT,
??????? .bit_count????? = 1,
??????? .dat_bit_offset = 0x0428 * 8 + 1,
??????? .set??????????? = rockchip_gpio_set,
? };
? static const struct of_device_id syscon_gpio_ids[] = {
??? //...
??? {
??? ??? .compatible??? = "rockchip,rk3328-mute-gpio",
??? ??? .data??? ??? = &rockchip_rk3328_mute_gpio,
??? },
??? {}
? };
Compared to V0 patch, the bit_count changes from 2 to 1 and the
dat_bit_offset
increases 1. Therefore the GPIO_MUTE pin is now referred to as
`<&gpio-mute 0>`. IMHO it is better than `<&gpio-mute 1>` in the V0 patch.
In V0, `1` is the physical offset of the output pin in register and
<&gpio-mute 0>
is an invalid GPIO.
Thanks
Levin
^ permalink raw reply
* [Query] PAGE_OFFSET on KASLR enabled ARM64 kernel
From: Baoquan He @ 2018-05-28 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528021609.GA31261@MiWiFi-R3L-srv>
On 05/28/18 at 10:16am, Baoquan He wrote:
> On 05/28/18 at 02:33am, Bhupesh Sharma wrote:
> > Hi ARM64 maintainers,
> >
> > I am confused about the PAGE_OFFSET value (or the start of the linear
> > map) on a KASLR enabled ARM64 kernel that I am seeing on a board which
> > supports a compatible EFI firmware (with EFI_RNG_PROTOCOL support).
> >
> > 1. 'arch/arm64/include/asm/memory.h' defines PAGE_OFFSET as:
> >
> > /*
> > * PAGE_OFFSET - the virtual address of the start of the linear map (top
> > * (VA_BITS - 1))
> > */
> > #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> > (UL(1) << (VA_BITS - 1)) + 1)
> >
> > So for example on a platform with VA_BITS=48, we have:
> > PAGE_OFFSET = 0xffff800000000000
> >
> > 2. However, for the KASLR case, we set the 'memstart_offset_seed ' to
> > use the 16-bits of the 'kaslr-seed' to randomize the linear region in
> > 'arch/arm64/kernel/kaslr.c' :
> >
> > u64 __init kaslr_early_init(u64 dt_phys)
> > {
> > <snip..>
> > /* use the top 16 bits to randomize the linear region */
> > memstart_offset_seed = seed >> 48;
> > <snip..>
> > }
> >
> > 3. Now, we use the 'memstart_offset_seed' value to randomize the
> > 'memstart_addr' value in 'arch/arm64/mm/init.c':
> >
> > void __init arm64_memblock_init(void)
> > {
> > <snip..>
> >
> > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> > extern u16 memstart_offset_seed;
> > u64 range = linear_region_size -
> > (memblock_end_of_DRAM() - memblock_start_of_DRAM());
> >
> > /*
> > * If the size of the linear region exceeds, by a sufficient
> > * margin, the size of the region that the available physical
> > * memory spans, randomize the linear region as well.
> > */
> > if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
> > range = range / ARM64_MEMSTART_ALIGN + 1;
> > memstart_addr -= ARM64_MEMSTART_ALIGN *
> > ((range * memstart_offset_seed) >> 16);
> > }
> > }
> > <snip..>
> > }
> >
> > 4. Since 'memstart_addr' indicates the start of physical RAM, we
> > randomize the same on basis of 'memstart_offset_seed' value above.
> > Also the 'memstart_addr' value is available in '/proc/kallsyms' and
> > hence can be accessed by user-space applications to read the
> > 'memstart_addr' value.
> >
> > 5. Now since the PAGE_OFFSET value is also used by several user space
> > tools (for e.g. makedumpfile tool uses the same to determine the start
> > of linear region and hence to read PT_NOTE fields from /proc/kcore), I
> > am not sure how to read the randomized value of the same in the KASLR
> > enabled case.
> >
> > 6. Reading the code further and adding some debug prints, it seems the
> > 'memblock_start_of_DRAM()' value is more closer to the actual start of
> > linear region rather than 'memstart_addr' and 'PAGE_OFFSET" in case of
> > KASLR enabled kernel:
>
>
> Can you paste your complete dmesg or boot log? Here I guess it only
> means the virtual address of memblock_start_of_DRAM, not its value.
Oh, it's an offset value, I was mistaken.
>
> VA_START == 0Xffff000000000000
> PAGE_OFFSET == 0xffff800000000000
> >
> > [root at qualcomm-amberwing] # dmesg | grep -i "arm64_memblock_init" -A 5
> >
> > [ 0.000000] inside arm64_memblock_init, memstart_addr = ffff976a00000000,
> > linearstart_addr = ffffe89600200000, memblock_start_of_DRAM = ffffe89600200000,
> > PHYS_OFFSET = ffff976a00000000, PAGE_OFFSET = ffff800000000000,
> > KIMAGE_VADDR = ffff000008000000, kimage_vaddr = ffff20c2d7800000
> >
> > [root at qualcomm-amberwing] # dmesg | grep -i "Virtual kernel memory layout" -A 15
> > [ 0.000000] Virtual kernel memory layout:
> > [ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000
> > ( 128 MB)
> > [ 0.000000] vmalloc : 0xffff000008000000 - 0xffff7bdfffff0000
> > (126847 GB)
> > [ 0.000000] .text : 0xffff20c2d7880000 - 0xffff20c2d8040000
> > ( 7936 KB)
> > [ 0.000000] .rodata : 0xffff20c2d8040000 - 0xffff20c2d83a0000
> > ( 3456 KB)
> > [ 0.000000] .init : 0xffff20c2d83a0000 - 0xffff20c2d8750000
> > ( 3776 KB)
> > [ 0.000000] .data : 0xffff20c2d8750000 - 0xffff20c2d891b200
> > ( 1837 KB)
> > [ 0.000000] .bss : 0xffff20c2d891b200 - 0xffff20c2d90a5198
> > ( 7720 KB)
> > [ 0.000000] fixed : 0xffff7fdffe790000 - 0xffff7fdffec00000
> > ( 4544 KB)
> > [ 0.000000] PCI I/O : 0xffff7fdffee00000 - 0xffff7fdfffe00000
> > ( 16 MB)
> > [ 0.000000] vmemmap : 0xffff7fe000000000 - 0xffff800000000000
> > ( 128 GB maximum)
> > [ 0.000000] 0xffff7ffa25800800 - 0xffff7ffa2b800000
> > ( 95 MB actual)
> > [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> > ( 98302 MB)
> >
> > As one can see above, the 'memblock_start_of_DRAM()' value of
> > 0xffffe89600200000 represents the start of linear region:
> >
> > [ 0.000000] memory : 0xffffe89600200000 - 0xffffe8ae00000000
> > ( 98302 MB)
> >
> > So, my question is to access the start of linear region (which was
> > earlier determinable via PAGE_OFFSET macro), whether I should:
> >
> > - do some back-computation for the start of linear region from the
> > 'memstart_addr' in user-space, or
> > - use a new global variable in kernel which is assigned the value of
> > memblock_start_of_DRAM()' and assign it to '/proc/kallsyms', so that
> > it can be read by user-space tools, or
> > - whether we should rather look at removing the PAGE_OFFSET usage from
> > the kernel and replace it with a global variable instead which is
> > properly updated for KASLR case as well.
> >
> > Kindly share your opinions on what can be a suitable solution in this case.
> >
> > Thanks for your help.
> >
> > Regards,
> > Bhupesh
> >
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH v4 0/9] Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch add support for the Mediatek MT2712 DISP subsystem.
MT2712 is base on MT8173, there are some difference as following:
MT2712 support three disp output(two ovl and one rdma)
Change in v4:
- Move some modification about AAL1 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component AAL1"
- Move some modification about OD1 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component OD1"
- Move some modification about PWM2 from patch
"Add support for mediatek SOC MT2712" to
"add ddp component PWM2"
- Move some modification about third ddp path from patch
"Add support for mediatek SOC MT2712" to
"add third ddp path"
- Move the definition OD1_MOUT_EN_RDMA1 from patch
"Add support for mediatek SOC MT2712" to
"add connection from OD1 to RDMA1"
- Rebase the patch "add connection from OD1 to RDMA1" after
"add ddp component OD1"
- Rebase the patch "add third ddp path" before
"Add support for mediatek SOC MT2712"
- Modify the 2712 MUTEX MODULE in the order by index
- Added patch for ddp component PWM1
- For patch "add third ddp path"
Add the condition in mtk_crtc_create() that if there
is no ddp path, then return 0 to avoid the null crtc
Change in v3:
- Added patch for ddp component AAL1
- Added patch for ddp component OD1
- Added patch for ddp component PWM2
- Added patch to create third ddp path
- Rebase patch "support maximum 64 mutex mod" before
"Add support for mediatek SOC MT2712"
- Rebase patch "add connection from OD1 to RDMA1" before
"Add support for mediatek SOC MT2712"
- Remove two definition about RDMA0 and RDMA2
- Change the definition about mutex module from
bitwise to index
Changes in v2:
- update dt-bindings for mt2712
- Added patch to connection from OD1 to RDMA1
- Added patch to support maximum 64 mutex mod
- rewrite mutex mod condition for reducing one byte
- Change the component name AAL/OD to AAL0/OD0 for naming consistency
- Move the compatible information about dpi to other patch which modify
the dpi driver for mt2712
Stu Hsieh (9):
drm/mediatek: update dt-bindings for mt2712
drm/mediatek: support maximum 64 mutex mod
drm/mediatek: add ddp component AAL1
drm/mediatek: add ddp component OD1
drm/mediatek: add ddp component PWM1
drm/mediatek: add ddp component PWM2
drm/mediatek: add connection from OD1 to RDMA1
drm/mediatek: add third ddp path
drm/mediatek: Add support for mediatek SOC MT2712
.../bindings/display/mediatek/mediatek,disp.txt | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 124 +++++++++++++++------
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 7 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 +++++++-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +-
7 files changed, 158 insertions(+), 40 deletions(-)
--
2.12.5
^ permalink raw reply
* [PATCH v4 1/9] drm/mediatek: update dt-bindings for mt2712
From: Stu Hsieh @ 2018-05-28 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527489507-24453-1-git-send-email-stu.hsieh@mediatek.com>
Update device tree binding documentation for the display subsystem for
Mediatek MT2712 SoCs.
Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..8469de510001 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -40,7 +40,7 @@ Required properties (all function blocks):
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
"mediatek,<chip>-disp-mutex" - display mutex
"mediatek,<chip>-disp-od" - overdrive
- the supported chips are mt2701 and mt8173.
+ the supported chips are mt2701, mt2712 and mt8173.
- reg: Physical base address and length of the function block register space
- interrupts: The interrupt signal from the function block (required, except for
merge and split function blocks).
--
2.12.5
^ permalink raw reply related
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