* [PATCH linux dev-4.10 4/6] Documentation: dt-bindings: Add a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-10 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1qiD1sWj0oQ=WbvpEDhtcYbzCxjg7t1iPs45WamfUVgw@mail.gmail.com>
On 1/10/2018 4:20 AM, Arnd Bergmann wrote:
> On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
> <jae.hyun.yoo@linux.intel.com> wrote:
>> This commit add a dt-bindings document for a generic PECI hwmon
>> driver.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> ---
>> .../devicetree/bindings/hwmon/peci-hwmon.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt b/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
>> new file mode 100644
>> index 0000000..20b86f5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
>> @@ -0,0 +1,33 @@
>> +* Generic PECI (Platform Environment Control Interface) hwmon driver.
>> +
>> +Dependency:
>> +- This driver uses a PECI misc driver as a controller interface so one of PECI
>> + misc drivers which provides compatible ioctls has to be enabled.
>
> The binding should only explain how we describe the hardware in an
> operating-system
> independent way, but not talk about how an OS is supposed to implement those
> drivers.
>
> Having multiple drivers each provide an exported function is not possible
> in Linux: it immediately breaks building an 'allyesconfig' kernel, and prevents
> you from running the same kernel across multiple implementations, so that
> has to be redesigned anyway.
>
Agreed, I'll consider redesigning of it.
>> +Required properties:
>> +- compatible: "peci-hwmon"
>> +- cpu-id: Should contain CPU socket ID
>> + - 0 ~ 7
>> +
>> +Optional properties:
>> +- show-core: If this protperty is defined, core tmeperature attrubites will be
>
> s/protperty/property/
> s/tmeperature/temperature/
> s/attrubites/attributes/
>
Oops! I made this many typos in this single line. Thanks for your
pointing it out. Will fix these.
>> + enumerated.
>> +- dimm-nums: Should contain the number of DIMM slots that attached to each CPU
>> + which is indicated by cpu-id.
>> + 0 ~ 16 (default: 16)
>> + In case of 0, DIMM temperature attrubites will not be enumerated.
>
> Is this only an initial list that you expect to be extended in the
> future, or is this
> a complete list of sensors that can ever be connected to PECI?
>
> Should this be PECI version specific?
>
> Arnd
>
The maximum supportable number of dimm slots is not PECI version
specific but depends on CPU architecture. Currently IA supports up to 16
slot as the maximum but it could vary in the future architecture.
Thanks,
Jae
^ permalink raw reply
* [PATCH linux dev-4.10 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Jae Hyun Yoo @ 2018-01-10 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a31+9HGQ=fQby5Zi1RZ671hKraZP_2ggLTMX3qvOiTx0w@mail.gmail.com>
On 1/10/2018 4:29 AM, Arnd Bergmann wrote:
> On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
> <jae.hyun.yoo@linux.intel.com> wrote:
>> This commit adds driver implementation for a generic PECI hwmon.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>
>> +static int xfer_peci_msg(int cmd, void *pmsg)
>> +{
>> + int rc;
>> +
>> + mutex_lock(&peci_hwmon_lock);
>> + rc = peci_ioctl(NULL, cmd, (unsigned long)pmsg);
>> + mutex_unlock(&peci_hwmon_lock);
>> +
>> + return rc;
>> +}
>
> I said earlier that peci_ioctl() looked unused, that was obviously
> wrong, but what you have here
> is not a proper way to abstract a bus.
>
> Maybe this can be done more like an i2c bus: make the peci controller
> a bus device
> and register all known target/index pairs as devices with the peci bus
> type, and have
> them probed from DT. The driver can then bind to each of those individually.
> Not sure if that is getting to granular at that point, I'd have to
> understand better
> how it is expected to get used, and what the variances are between
> implementations.
>
> Arnd
>
Thanks for sharing your opinion. In fact, this was also suggested by
openbmc community so I should consider of redesigning it. I'm currently
thinking about adding a new PECI device class as an abstract layer and
any BMC chipset specific driver could be attached to the PECI class
driver. Then, each CPU client could be registered as an individual
device as you suggested. Will consider your suggestion.
Thanks a lot!
Jae
^ permalink raw reply
* [PATCH 3/9] soc: samsung: pmu: Add the PMU data of exynos5433 to support low-power state
From: Chanwoo Choi @ 2018-01-10 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0adffb4c-019f-a637-881c-d919c67cdbcf@arm.com>
On 2018? 01? 10? 19:53, Sudeep Holla wrote:
>
>
> On 10/01/18 01:46, Chanwoo Choi wrote:
>> On 2018? 01? 09? 23:11, Sudeep Holla wrote:
>>>
>>>
>>> On 09/01/18 07:59, Chanwoo Choi wrote:
>>>> This patch adds the PMU (Power Management Unit) data of exynos5433 SoC
>>>> in order to support the various power modes. Each power mode has
>>>> the different value for reducing the power-consumption.
>>>>
>>>> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
>>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> ---
>>>> arch/arm/mach-exynos/common.h | 2 -
>>>> drivers/soc/samsung/Makefile | 3 +-
>>>> drivers/soc/samsung/exynos-pmu.c | 1 +
>>>> drivers/soc/samsung/exynos-pmu.h | 2 +
>>>> drivers/soc/samsung/exynos5433-pmu.c | 286 ++++++++++++++++++++++++++++
>>>> include/linux/soc/samsung/exynos-regs-pmu.h | 148 ++++++++++++++
>>>> 6 files changed, 439 insertions(+), 3 deletions(-)
>>>> create mode 100644 drivers/soc/samsung/exynos5433-pmu.c
>>>>
>>>
>>>> diff --git a/drivers/soc/samsung/exynos5433-pmu.c b/drivers/soc/samsung/exynos5433-pmu.c
>>>> new file mode 100644
>>>> index 000000000000..2571e61522f0
>>>> --- /dev/null
>>>> +++ b/drivers/soc/samsung/exynos5433-pmu.c
>>>> @@ -0,0 +1,286 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +//
>>>> +// Copyright (c) 2018 Samsung Electronics Co., Ltd.
>>>> +// Copyright (c) Jonghwa Lee <jonghwa3.lee@samsung.com>
>>>> +// Copyright (c) Chanwoo Choi <cw00.choi@samsung.com>
>>>> +//
>>>> +// EXYNOS5433 - CPU PMU (Power Management Unit) support
>>>> +
>>>> +#include <linux/soc/samsung/exynos-regs-pmu.h>
>>>> +#include <linux/soc/samsung/exynos-pmu.h>
>>>> +
>>>> +#include "exynos-pmu.h"
>>>> +
>>>> +static struct exynos_pmu_conf exynos5433_pmu_config[] = {
>>>> + /* { .offset = address, .val = { AFTR, LPA, SLEEP } } */
>>>> + { EXYNOS5433_ATLAS_CPU0_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_ATLAS_CPU0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_ATLAS_CPU1_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_ATLAS_CPU1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_ATLAS_CPU2_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_ATLAS_CPU2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_ATLAS_CPU3_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_ATLAS_CPU3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_APOLLO_CPU0_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_APOLLO_CPU0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_APOLLO_CPU1_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_APOLLO_CPU1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_APOLLO_CPU2_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_APOLLO_CPU2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_APOLLO_CPU3_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_DIS_IRQ_APOLLO_CPU3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0 } },
>>>> + { EXYNOS5433_ATLAS_NONCPU_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>> + { EXYNOS5433_APOLLO_NONCPU_SYS_PWR_REG, { 0x0, 0x0, 0x8 } },
>>>
>>>
>>> 1. First of all why do you need any of these CPU related PMU config
>>> registers in kernel ? From the information I gathered this is ARM64
>>> SoC using PSCI. These are needed just in PSCI implementation and not
>>> in kernel. So can you elaborate on why there are present here ?
>>
>> The 32bit Exynos used the 'smc' call to enter the suspend mode
>> and need to handle the PMU registers.
>>
>
> OK
>
>> Even if PSCI replaces the 'smc' call on the Exynos5433,
>> the Exynos5433's document requires the handling of PMU config
>> related to CPU for the suspend mode.
>>
>
> OK but does it state it needs to be in kernel ?(i.e. in EL1 NS)
>
>> IMHO, If the secure OS implemented the all something related to CPU,
>> it might be unnecessary to handle the PMU registers. I think that
>> it depend on how to design the SoC by H/W Architect. This is just my opinion.
>>
>
> Even if it can be accessed in kernel, better to keep all these in PSCI
> implementation that does the actual power state management. Mixing them
> in both kernel and PSCI implementation is just a mess TBH and not easy
> to maintain the platform if some issues pop up.
>
>>>
>>> 2. Are there any public documents that these names map to ?
>>
>> There is no public document. It is confidential.
>>
>
> I guessed so and hence raised to remove it.
>
>>> If there is none, please replace these codenames(ATLAS, APOLLO) with
>>> appropriately.
>>
>> In the Exynos5433, 'apollo' indicates the LITTLE cores (cpu0-3, cortex-a53)
>> and 'atlas' indicates the big cores (cpu4-7, cortex-a57)
>>
>> Exynos5433 already used the 'apollo' and 'atlas' on clk-exynos5433.c driver
>> and thermal device-tree node. It is better to use the original register name
>> in the document in order to reduce the confusion of the change of register name
>> even if document is not public.
>>
>> Also, exynos7 used the 'atlas' word for big cores.
>>
>
> I disagree. If you don't have any public documents, then better use
> names other developers are used to and not some code names which
> otherwise is not seen in any other part of the code base. Grepping
> just shows Exynos using these code names which are generally restricted
I mentioned, these words were already used on other device drivers.
Exynos5433 used them to indicate the big.LITTLE cores consistently.
They are an alias for big.LITTLE. Latest Exynos SoC must use these words continuously.
I think that each vendor SoC could define the alias or expression for their SoC.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [GIT PULL] updates to soc/fsl drivers for v4.16
From: Li Yang @ 2018-01-10 23:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi arm-soc maintainer,
Please merge the following tag to get updates to the soc/fsl/guts driver
for support of additional SoCs and more error path handling.
Thanks,
Leo
The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:
Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc-fsl-for-4.16
for you to fetch changes up to 00ce0a2304014c73c2b7915215c7b3c73e2a25aa:
soc: fsl: guts: Add a NULL check for devm_kasprintf() (2018-01-10 16:54:26 -0600)
----------------------------------------------------------------
FSL/NXP SoC drivers updates for 4.16
This adds new SoC support and more error path handling to the guts
driver.
----------------------------------------------------------------
Fabio Estevam (1):
soc: fsl: guts: Add a NULL check for devm_kasprintf()
yangbo lu (1):
soc: fsl: guts: add support for ls1012a and ls1046a
drivers/soc/fsl/guts.c | 8 ++++++++
1 file changed, 8 insertions(+)
^ permalink raw reply
* [nomadik:gemini-ethernet 18/18] drivers/net/ethernet/cortina/gemini.c:1410:63: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int'
From: kbuild test robot @ 2018-01-11 0:03 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git gemini-ethernet
head: de0cb586c9e534c926cd7c74c92dc3d4104ea569
commit: de0cb586c9e534c926cd7c74c92dc3d4104ea569 [18/18] net: ethernet: Add a driver for Gemini gigabit ethernet
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout de0cb586c9e534c926cd7c74c92dc3d4104ea569
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/net/ethernet/cortina/gemini.c: In function 'gmac_rx':
>> drivers/net/ethernet/cortina/gemini.c:1410:63: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
dev_err(geth->dev, "could not find mapping %08x (page = %08x, page off = %08x)\n",
~~~^
%08lx
In file included from drivers/net/ethernet/cortina/gemini.c:16:0:
drivers/net/ethernet/cortina/gemini.c: At top level:
include/linux/module.h:129:42: error: redefinition of '__inittest'
static inline initcall_t __maybe_unused __inittest(void) \
^
include/linux/device.h:1513:1: note: in expansion of macro 'module_init'
module_init(__driver##_init); \
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:129:42: note: previous definition of '__inittest' was here
static inline initcall_t __maybe_unused __inittest(void) \
^
include/linux/device.h:1513:1: note: in expansion of macro 'module_init'
module_init(__driver##_init); \
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:131:6: error: redefinition of 'init_module'
int init_module(void) __attribute__((alias(#initfn)));
^
include/linux/device.h:1513:1: note: in expansion of macro 'module_init'
module_init(__driver##_init); \
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:131:6: note: previous definition of 'init_module' was here
int init_module(void) __attribute__((alias(#initfn)));
^
include/linux/device.h:1513:1: note: in expansion of macro 'module_init'
module_init(__driver##_init); \
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:135:42: error: redefinition of '__exittest'
static inline exitcall_t __maybe_unused __exittest(void) \
^
include/linux/device.h:1518:1: note: in expansion of macro 'module_exit'
module_exit(__driver##_exit);
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:135:42: note: previous definition of '__exittest' was here
static inline exitcall_t __maybe_unused __exittest(void) \
^
include/linux/device.h:1518:1: note: in expansion of macro 'module_exit'
module_exit(__driver##_exit);
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:137:7: error: redefinition of 'cleanup_module'
void cleanup_module(void) __attribute__((alias(#exitfn)));
^
include/linux/device.h:1518:1: note: in expansion of macro 'module_exit'
module_exit(__driver##_exit);
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
include/linux/module.h:137:7: note: previous definition of 'cleanup_module' was here
void cleanup_module(void) __attribute__((alias(#exitfn)));
^
include/linux/device.h:1518:1: note: in expansion of macro 'module_exit'
module_exit(__driver##_exit);
^~~~~~~~~~~
include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver'
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro 'module_platform_driver'
module_platform_driver(gemini_ethernet_port_driver);
vim +1410 drivers/net/ethernet/cortina/gemini.c
1359
1360 static unsigned int gmac_rx(struct net_device *netdev, unsigned int budget)
1361 {
1362 struct gemini_ethernet_port *port = netdev_priv(netdev);
1363 unsigned short m = (1 << port->rxq_order) - 1;
1364 struct gemini_ethernet *geth = port->geth;
1365 void __iomem *ptr_reg = port->rxq_rwptr;
1366 unsigned int frame_len, frag_len;
1367 struct gmac_rxdesc *rx = NULL;
1368 struct gmac_queue_page *gpage;
1369 static struct sk_buff *skb;
1370 union gmac_rxdesc_0 word0;
1371 union gmac_rxdesc_1 word1;
1372 union gmac_rxdesc_3 word3;
1373 struct page *page = NULL;
1374 unsigned int page_offs;
1375 unsigned short r, w;
1376 union dma_rwptr rw;
1377 dma_addr_t mapping;
1378 int frag_nr = 0;
1379
1380 rw.bits32 = readl(ptr_reg);
1381 /* Reset interrupt as all packages until here are taken into account */
1382 writel(DEFAULT_Q0_INT_BIT << netdev->dev_id,
1383 geth->base + GLOBAL_INTERRUPT_STATUS_1_REG);
1384 r = rw.bits.rptr;
1385 w = rw.bits.wptr;
1386
1387 while (budget && w != r) {
1388 rx = port->rxq_ring + r;
1389 word0 = rx->word0;
1390 word1 = rx->word1;
1391 mapping = rx->word2.buf_adr;
1392 word3 = rx->word3;
1393
1394 r++;
1395 r &= m;
1396
1397 frag_len = word0.bits.buffer_size;
1398 frame_len = word1.bits.byte_count;
1399 page_offs = mapping & ~PAGE_MASK;
1400
1401 if (!mapping) {
1402 netdev_err(netdev,
1403 "rxq[%u]: HW BUG: zero DMA desc\n", r);
1404 goto err_drop;
1405 }
1406
1407 /* Freeq pointers are one page off */
1408 gpage = gmac_get_queue_page(geth, port, mapping + PAGE_SIZE);
1409 if (!gpage) {
> 1410 dev_err(geth->dev, "could not find mapping %08x (page = %08x, page off = %08x)\n",
1411 mapping, mapping & PAGE_MASK, page_offs);
1412 continue;
1413 }
1414 page = gpage->page;
1415
1416 if (word3.bits32 & SOF_BIT) {
1417 if (skb) {
1418 napi_free_frags(&port->napi);
1419 port->stats.rx_dropped++;
1420 }
1421
1422 skb = gmac_skb_if_good_frame(port, word0, frame_len);
1423 if (!skb)
1424 goto err_drop;
1425
1426 page_offs += NET_IP_ALIGN;
1427 frag_len -= NET_IP_ALIGN;
1428 frag_nr = 0;
1429
1430 } else if (!skb) {
1431 put_page(page);
1432 continue;
1433 }
1434
1435 if (word3.bits32 & EOF_BIT)
1436 frag_len = frame_len - skb->len;
1437
1438 /* append page frag to skb */
1439 if (frag_nr == MAX_SKB_FRAGS)
1440 goto err_drop;
1441
1442 if (frag_len == 0)
1443 netdev_err(netdev, "Received fragment with len = 0\n");
1444
1445 skb_fill_page_desc(skb, frag_nr, page, page_offs, frag_len);
1446 skb->len += frag_len;
1447 skb->data_len += frag_len;
1448 skb->truesize += frag_len;
1449 frag_nr++;
1450
1451 if (word3.bits32 & EOF_BIT) {
1452 napi_gro_frags(&port->napi);
1453 skb = NULL;
1454 --budget;
1455 }
1456 continue;
1457
1458 err_drop:
1459 if (skb) {
1460 napi_free_frags(&port->napi);
1461 skb = NULL;
1462 }
1463
1464 if (mapping)
1465 put_page(page);
1466
1467 port->stats.rx_dropped++;
1468 }
1469
1470 writew(r, ptr_reg);
1471 return budget;
1472 }
1473
---
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: 62432 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/cd79a02e/attachment-0001.gz>
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Kim Phillips @ 2018-01-11 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513356299-26274-1-git-send-email-mathieu.poirier@linaro.org>
On Fri, 15 Dec 2017 09:44:49 -0700
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> This patchset adds support for per-thread CoreSight trace decoding from the
> "perf report" interface. It is largely modelled on what has been done for
> intelPT traces and currently targets the ETMv4 architecture. Support for
> cpu-wide scenarios and ETMv3/PTMv1.1 will follow shortly.
>
> The trace decoding support is done using the Open CoreSight Decoding
> Library (openCSD), a stand alone open source project available here [1].
> Integration of the openCSD library with the perf tools follow what has
> been done for other support libraries. If the library has been installed
> on a system the build scripts will include support for CoreSight trace
> decoding:
>
> ... zlib: [ on ]
> ... lzma: [ OFF ]
> ... get_cpuid: [ on ]
> ... bpf: [ on ]
> ... libopencsd: [ on ] <------
>
> Instructions on how to build and install the openCSD library are provided
> in the HOWTO.md of the project repository.
Usually when a perf builder sees something they need "on," they - or,
at least I - start querying the host's package manager for something
that provides it (e.g., apt search/install libopencsd), but since no
distro provides libopencsd, this is bad because it misleads the user.
> We elected to keep the decoder
> library independent of the kernel tree as it is also used outside of the
> perf toolset and various non-linux projects.
Where? Not that that won't mean it can't be included in the kernel
source tree anyway: Doing so would enable support without burdening
the linux perf user with adding any external custom library
dependencies.
Keeping the library external will also inevitably introduce more
source level synchronization problems because the perf sources being
built may not be compatible with their version of the library, whether
due to new features like new trace hardware support, or API changes.
As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
be able to be done the same way the dtc is incorporated into the
kernel, where only its relevant sources are included and updated as
needed: see linux/scripts/dtc/update-dtc-source.sh.
Hopefully the upstream maintainers (acme, etc.) can chime in with
their opinion on how to include the library, if at all? It's
essentially the same type of code as the Intel-PT decoder code,
currently found under tools/perf/util/intel-pt-decoder, except we're
trying to keep some sense of connection to the parent project ("Intel
(R) Processor Trace Decoder Library" in Intel's case [1]) alive.
Thanks,
Kim
[1] https://github.com/01org/processor-trace
^ permalink raw reply
* [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
From: Jolly Shah @ 2018-01-11 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbe4ccad-993b-76d7-bf7a-9ef0eb284459@arm.com>
Hi Sudeep,
Thanks for the review,
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Tuesday, January 09, 2018 6:40 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; michal.simek at xilinx.com
> Cc: Sudeep Holla <sudeep.holla@arm.com>; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Jolly Shah
> <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
>
>
>
> On 08/01/18 22:07, Jolly Shah wrote:
> > This patch is adding communication layer with firmware.
> > Firmware driver provides an interface to firmware APIs.
> > Interface APIs can be used by any driver to communicate to
> > PMUFW(Platform Management Unit). All requests go through ATF.
> > Firmware-debug provides debugfs interface to all APIs.
> > Firmware-ggs provides read/write interface to global storage
> > registers.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
> > .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 16 +
> > arch/arm64/Kconfig.platforms | 1 +
> > drivers/firmware/Kconfig | 1 +
> > drivers/firmware/Makefile | 1 +
> > drivers/firmware/xilinx/Kconfig | 4 +
> > drivers/firmware/xilinx/Makefile | 4 +
> > drivers/firmware/xilinx/zynqmp/Kconfig | 23 +
> > drivers/firmware/xilinx/zynqmp/Makefile | 5 +
> > drivers/firmware/xilinx/zynqmp/firmware-debug.c | 540 +++++++++++
> > drivers/firmware/xilinx/zynqmp/firmware-ggs.c | 298 ++++++
> > drivers/firmware/xilinx/zynqmp/firmware.c | 1024
> ++++++++++++++++++++
> > .../linux/firmware/xilinx/zynqmp/firmware-debug.h | 32 +
> > include/linux/firmware/xilinx/zynqmp/firmware.h | 573 +++++++++++
> > 13 files changed, 2522 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware
> > .txt create mode 100644 drivers/firmware/xilinx/Kconfig create mode
> > 100644 drivers/firmware/xilinx/Makefile create mode 100644
> > drivers/firmware/xilinx/zynqmp/Kconfig
> > create mode 100644 drivers/firmware/xilinx/zynqmp/Makefile
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-debug.c
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-ggs.c
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware.c
> > create mode 100644
> > include/linux/firmware/xilinx/zynqmp/firmware-debug.h
> > create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmwa
> > re.txt
> > b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmwa
> > re.txt
> > new file mode 100644
> > index 0000000..ace111c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-fi
> > +++ rmware.txt
> > @@ -0,0 +1,16 @@
> > +Xilinx Zynq MPSoC Firmware Device Tree Bindings
> > +
> > +The zynqmp-firmware node describes the interface to platform firmware.
> > +
> > +Required properties:
> > + - compatible: Must contain: "xlnx,zynqmp-firmware"
> > + - method: The method of calling the PM-API firmware layer.
> > + Permitted values are:
> > + - "smc" : To be used in configurations without a hypervisor
> > + - "hvc" : To be used when hypervisor is present
> > +
>
> If we are having a mailbox using smc/hvc, then it can be made generic rather
> than xilinx specific. I can see other user of the same. As Jassi pointed out in
> some other thread, Andre has some generic implementation.
> Please see how it can be reused.
>
Andre's mailbox implementation in not in kernel yet. We can change later if it
satisfies our use case.
> Also please keep any bindings separate from the driver changes so that it can be
> reviewed separately.
Sure. Will do it in next version.
>
> > +Examples:
> > + firmware: firmware {
> > + compatible = "xlnx,zynqmp-firmware";
> > + method = "smc";
>
> Ideally this should point to mailbox if we move to using smc/hvc based mailbox.
>
> [...]
>
> > +
> > +config ZYNQMP_FIRMWARE_DEBUG
> > + bool "Enable Xilinx Zynq MPSoC firmware debug APIs"
> > + depends on ARCH_ZYNQMP && DEBUG_FS
>
> Do you need a separate Kconfig option, can't you just use DEBUG_FS ?
>
> [...]
>
As its zynqmp specific, we wanted to keep an option to enable/disable it separately.
It can be combined as ZYNQMP FIRMWARE+DEBUG_FS instead of a separate Kconfig.
> > +
> > + if (strncasecmp(pm_api_req, "REQUEST_SUSPEND", 15) == 0)
> > + pm_id = REQUEST_SUSPEND;
> > + else if (strncasecmp(pm_api_req, "SELF_SUSPEND", 12) == 0)
> > + pm_id = SELF_SUSPEND;
> > + else if (strncasecmp(pm_api_req, "FORCE_POWERDOWN", 15) == 0)
> > + pm_id = FORCE_POWERDOWN;
> > + else if (strncasecmp(pm_api_req, "ABORT_SUSPEND", 13) == 0)
> > + pm_id = ABORT_SUSPEND;
>
>
> Can this be changed to a loop with a static structure array containing {pm_id,
> pm_string, strlen(pm_string)} ?
Will fix it in next version
>
> Also I see hard-coded string length is wrong in some cases like IOCTL.
> Isn't it better to just use strlen("..") instead ?
>
Will fix it in next version
> I will stop here as the patch can be easily split and several features can be added
> incrementally making the base patch simpler and shorter.
Sure. Will break it into a few patches in next version
Thanks,
Jolly Shah
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH] usb: mtu3: fix ssusb_wakeup_set dummy
From: Chunfeng Yun @ 2018-01-11 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110164530.1399750-1-arnd@arndb.de>
On Wed, 2018-01-10 at 17:45 +0100, Arnd Bergmann wrote:
> Changing from ssusb_wakeup_enable/disable to ssusb_wakeup_set was done
> in only one of two places in the kernel, the other one now causes a
> build failure:
>
> drivers/usb/mtu3/mtu3_plat.c: In function 'mtu3_suspend':
> drivers/usb/mtu3/mtu3_plat.c:462:2: error: implicit declaration of function 'ssusb_wakeup_set'; did you mean 'ssusb_wakeup_disable'? [-Werror=implicit-function-declaration]
>
> This adapts the dummy helpers the same way that the extern declarations
> were.
>
> Fixes: f0ede2c6282b ("usb: mtu3: supports remote wakeup for mt2712 with two SSUSB IPs")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/usb/mtu3/mtu3_dr.h | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/usb/mtu3/mtu3_dr.h b/drivers/usb/mtu3/mtu3_dr.h
> index ae1598d76e02..50702fdcde28 100644
> --- a/drivers/usb/mtu3/mtu3_dr.h
> +++ b/drivers/usb/mtu3/mtu3_dr.h
> @@ -48,12 +48,7 @@ static inline int ssusb_host_disable(struct ssusb_mtk *ssusb, bool suspend)
> return 0;
> }
>
> -static inline int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
> -{
> - return 0;
> -}
> -
> -static inline void ssusb_wakeup_disable(struct ssusb_mtk *ssusb)
> +static inline void ssusb_wakeup_set(struct ssusb_mtk *ssusb, bool enable)
> {}
>
> #endif
Forgot to make it change,
Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Thanks a lot
^ permalink raw reply
* [PATCH] arm64: dts: add #cooling-cells to CPU nodes
From: Chunfeng Yun @ 2018-01-11 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110210706.2331225-1-arnd@arndb.de>
On Wed, 2018-01-10 at 22:06 +0100, Arnd Bergmann wrote:
> dtc complains about the lack of #coolin-cells properties for the
> CPU nodes that are referred to as "cooling-device":
>
> arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu at 0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map at 0:cooling-device[0])
> arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu at 100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map at 1:cooling-device[0])
>
> Apparently this property must be '<2>' to match the binding.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> If this looks ok, I'd apply it directly to the fixes branch
> for 4.15, as the warning is one that was introduced in this
> release.
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index b477ad790071..9fbe4705ee88 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -155,6 +155,7 @@
> reg = <0x000>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SLEEP_0>;
> + #cooling-cells = <2>;
> clocks = <&infracfg CLK_INFRA_CA53SEL>,
> <&apmixedsys CLK_APMIXED_MAINPLL>;
> clock-names = "cpu", "intermediate";
> @@ -179,6 +180,7 @@
> reg = <0x100>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SLEEP_0>;
> + #cooling-cells = <2>;
> clocks = <&infracfg CLK_INFRA_CA57SEL>,
> <&apmixedsys CLK_APMIXED_MAINPLL>;
> clock-names = "cpu", "intermediate";
Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
^ permalink raw reply
* [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
From: Jolly Shah @ 2018-01-11 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109121911.GA18770@mordor.localdomain>
Thanks Aishwarya for the review,
> -----Original Message-----
> From: Aishwarya Pant [mailto:aishpant at gmail.com]
> Sent: Tuesday, January 09, 2018 4:19 AM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: ard.biesheuvel at linaro.org; mingo at kernel.org;
> gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> sudeep.holla at arm.com; hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; michal.simek at xilinx.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Jolly Shah
> <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
>
> On Mon, Jan 08, 2018 at 02:07:07PM -0800, Jolly Shah wrote:
> > This patch is adding communication layer with firmware.
> > Firmware driver provides an interface to firmware APIs.
> > Interface APIs can be used by any driver to communicate to
> > PMUFW(Platform Management Unit). All requests go through ATF.
> > Firmware-debug provides debugfs interface to all APIs.
> > Firmware-ggs provides read/write interface to
> > global storage registers.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
> > .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 16 +
> > arch/arm64/Kconfig.platforms | 1 +
> > drivers/firmware/Kconfig | 1 +
> > drivers/firmware/Makefile | 1 +
> > drivers/firmware/xilinx/Kconfig | 4 +
> > drivers/firmware/xilinx/Makefile | 4 +
> > drivers/firmware/xilinx/zynqmp/Kconfig | 23 +
> > drivers/firmware/xilinx/zynqmp/Makefile | 5 +
> > drivers/firmware/xilinx/zynqmp/firmware-debug.c | 540 +++++++++++
> > drivers/firmware/xilinx/zynqmp/firmware-ggs.c | 298 ++++++
> > drivers/firmware/xilinx/zynqmp/firmware.c | 1024
> ++++++++++++++++++++
> > .../linux/firmware/xilinx/zynqmp/firmware-debug.h | 32 +
> > include/linux/firmware/xilinx/zynqmp/firmware.h | 573 +++++++++++
> > 13 files changed, 2522 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
> > create mode 100644 drivers/firmware/xilinx/Kconfig
> > create mode 100644 drivers/firmware/xilinx/Makefile
> > create mode 100644 drivers/firmware/xilinx/zynqmp/Kconfig
> > create mode 100644 drivers/firmware/xilinx/zynqmp/Makefile
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-debug.c
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-ggs.c
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware.c
> > create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware-debug.h
> > create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware.h
> >
> > +static ssize_t ggs_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf,
> > + size_t count,
> > + u32 reg)
> > +{
> > + if (!dev || !attr || !buf || !count || reg >= GSS_NUM_REGS)
> > + return -EINVAL;
> > +
> > + return write_register(buf, count, IOCTL_WRITE_GGS, reg);
> > +}
> > +
> > +/* GGS register show functions */
> > +#define GGS0_SHOW(N) \
> > + ssize_t ggs##N##_show(struct device *dev, \
> > + struct device_attribute *attr, \
> > + char *buf) \
> > + { \
> > + return ggs_show(dev, attr, buf, N); \
> > + }
> > +
> > +static GGS0_SHOW(0);
> > +static GGS0_SHOW(1);
> > +static GGS0_SHOW(2);
> > +static GGS0_SHOW(3);
> > +
> > +/* GGS register store function */
> > +#define GGS0_STORE(N) \
> > + ssize_t ggs##N##_store(struct device *dev, \
> > + struct device_attribute *attr, \
> > + const char *buf, \
> > + size_t count) \
> > + { \
> > + return ggs_store(dev, attr, buf, count, N); \
> > + }
> > +
> > +static GGS0_STORE(0);
> > +static GGS0_STORE(1);
> > +static GGS0_STORE(2);
> > +static GGS0_STORE(3);
> > +
> > +/* GGS register device attributes */
> > +static DEVICE_ATTR_RW(ggs0);
> > +static DEVICE_ATTR_RW(ggs1);
> > +static DEVICE_ATTR_RW(ggs2);
> > +static DEVICE_ATTR_RW(ggs3);
>
> Hi
>
> You added some files to the sysfs ABI. These interfaces should be documented in
> Documentation/ABI.
>
Sure. Will add it in next version.
Thanks,
Jolly Shah
^ permalink raw reply
* [nomadik:gemini-ethernet 9/18] ERROR: "of_irq_count" [net/dsa/dsa_core.ko] undefined!
From: kbuild test robot @ 2018-01-11 1:00 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git gemini-ethernet
head: de0cb586c9e534c926cd7c74c92dc3d4104ea569
commit: 8ba4fbd39429b98be7df94669b332ac295b94b1a [9/18] RFC: net/dsa: Allow DSA PHYs to define link IRQs
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 8ba4fbd39429b98be7df94669b332ac295b94b1a
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
WARNING: modpost: missing MODULE_LICENSE() in drivers/auxdisplay/img-ascii-lcd.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-ath79.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/iio/accel/kxsd9-i2c.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/iio/adc/qcom-vadc-common.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/media/platform/tegra-cec/tegra_cec.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/pinctrl/pxa/pinctrl-pxa2xx.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/power/reset/zx-reboot.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/staging/comedi/drivers/ni_atmio.o
see include/linux/module.h for more information
>> ERROR: "of_irq_count" [net/dsa/dsa_core.ko] undefined!
ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!
ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined!
---
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: 49782 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/0939326a/attachment-0001.gz>
^ permalink raw reply
* [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
From: Jolly Shah @ 2018-01-11 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5fbe8626-63be-02c4-b3e5-ba6c99a8d67c@arm.com>
Hi Julien,
Thanks for the review,
> -----Original Message-----
> From: Julien Thierry [mailto:julien.thierry at arm.com]
> Sent: Tuesday, January 09, 2018 6:07 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> sudeep.holla at arm.com; hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; michal.simek at xilinx.com
> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Jolly
> Shah <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [PATCH] drivers: firmware: xilinx: Add ZynqMP firmware driver
>
> Hi Jolly,
>
> On 08/01/18 22:07, Jolly Shah wrote:
> > This patch is adding communication layer with firmware.
> > Firmware driver provides an interface to firmware APIs.
> > Interface APIs can be used by any driver to communicate to
> > PMUFW(Platform Management Unit). All requests go through ATF.
> > Firmware-debug provides debugfs interface to all APIs.
> > Firmware-ggs provides read/write interface to
> > global storage registers.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
> > .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 16 +
> > arch/arm64/Kconfig.platforms | 1 +
> > drivers/firmware/Kconfig | 1 +
> > drivers/firmware/Makefile | 1 +
> > drivers/firmware/xilinx/Kconfig | 4 +
> > drivers/firmware/xilinx/Makefile | 4 +
> > drivers/firmware/xilinx/zynqmp/Kconfig | 23 +
> > drivers/firmware/xilinx/zynqmp/Makefile | 5 +
> > drivers/firmware/xilinx/zynqmp/firmware-debug.c | 540 +++++++++++
> > drivers/firmware/xilinx/zynqmp/firmware-ggs.c | 298 ++++++
> > drivers/firmware/xilinx/zynqmp/firmware.c | 1024
> ++++++++++++++++++++
> > .../linux/firmware/xilinx/zynqmp/firmware-debug.h | 32 +
> > include/linux/firmware/xilinx/zynqmp/firmware.h | 573 +++++++++++
> > 13 files changed, 2522 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt
> > create mode 100644 drivers/firmware/xilinx/Kconfig
> > create mode 100644 drivers/firmware/xilinx/Makefile
> > create mode 100644 drivers/firmware/xilinx/zynqmp/Kconfig
> > create mode 100644 drivers/firmware/xilinx/zynqmp/Makefile
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-debug.c
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware-ggs.c
> > create mode 100644 drivers/firmware/xilinx/zynqmp/firmware.c
> > create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware-
> debug.h
> > create mode 100644 include/linux/firmware/xilinx/zynqmp/firmware.h
> >
>
> > +
> > +static u32 pm_api_version;
> > +
> > +/**
> > + * zynqmp_pm_get_api_version - Get version number of PMU PM firmware
> > + * @version: Returned version value
> > + *
> > + * Return: Returns status, either success or error+reason
> > + */
> > +static int zynqmp_pm_get_api_version(u32 *version)
> > +{
> > + u32 ret_payload[PAYLOAD_ARG_CNT];
> > +
> > + if (!version)
> > + return zynqmp_pm_ret_code(XST_PM_CONFLICT);
> > +
> > + /* Check is PM API version already verified */
> > + if (pm_api_version > 0) {
> > + *version = pm_api_version;
> > + return XST_PM_SUCCESS;
> > + }
> > + invoke_pm_fn(GET_API_VERSION, 0, 0, 0, 0, ret_payload);
> > + *version = ret_payload[1];
> > +
>
> I think you forgot to save the result to pm_api_version, unless I am
> missing something.
>
Pm_api_version is initialized in init routine. So no need to save it again as version will remain same.
Rest all comments will be fixed in next version.
Thanks,
Jolly Shah
^ permalink raw reply
* [PATCH v2 0/3] ARM: mvebu: dts: updates to enable EDAC
From: Chris Packham @ 2018-01-11 1:59 UTC (permalink / raw)
To: linux-arm-kernel
I've split this off from my earlier series[1] this is just the dts changes that
will enable support for the EDAC series when it lands.
The Armada 38x as well as the 98dx3236 and similar switch chips with integrated
CPUs use the same SDRAM controller block as the Armada XP. The key difference
is the width of the DDR interface.
[1] - https://marc.info/?l=linux-kernel&m=151545124505964&w=2
Changes in v2:
- update commit message
- add labels to dts
Chris Packham (3):
ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
ARM: dts: armada-xp: add label to sdram-controller node
ARM: dts: mvebu: add sdram controller node to Armada-38x
arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +++++
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
4 files changed, 12 insertions(+), 2 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
From: Chris Packham @ 2018-01-11 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111015903.11322-1-chris.packham@alliedtelesis.co.nz>
Enable L2 cache parity and ECC on the db-xc3-24g4xg board so that cache
operations are protected and errors can be flagged to the EDAC
subsystem.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Changes in v2:
- Update commit message
arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index 06fce35d7491..00ca489fc788 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -70,6 +70,11 @@
};
};
+&L2 {
+ arm,parity-enable;
+ marvell,ecc-enable;
+};
+
&devbus_bootcs {
status = "okay";
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: armada-xp: add label to sdram-controller node
From: Chris Packham @ 2018-01-11 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111015903.11322-1-chris.packham@alliedtelesis.co.nz>
Add the label "sdramc" to the sdram-controller nodes for the Armada-XP
and 98dx3236 SoCs.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Changes in v2:
- New
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index bdd4c7a45fbf..fe54e9d7cc90 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -127,7 +127,7 @@
};
internal-regs {
- sdramc at 1400 {
+ sdramc: sdramc at 1400 {
compatible = "marvell,armada-xp-sdram-controller";
reg = <0x1400 0x500>;
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index fa1e881266ac..3bb6e5e59fcc 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -73,7 +73,7 @@
};
internal-regs {
- sdramc at 1400 {
+ sdramc: sdramc at 1400 {
compatible = "marvell,armada-xp-sdram-controller";
reg = <0x1400 0x500>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: mvebu: add sdram controller node to Armada-38x
From: Chris Packham @ 2018-01-11 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111015903.11322-1-chris.packham@alliedtelesis.co.nz>
The Armada-38x uses an SDRAM controller that is compatible with the
Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
is 32/16). The SDRAM controller registers are the same between the two
SoCs.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Changes in v2:
- Add label to sdram-controller node
arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index 00ff549d4e39..f9008c4ddd7d 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -138,6 +138,11 @@
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
+ sdramc: sdramc at 1400 {
+ compatible = "marvell,armada-xp-sdram-controller";
+ reg = <0x1400 0x500>;
+ };
+
L2: cache-controller at 8000 {
compatible = "arm,pl310-cache";
reg = <0x8000 0x1000>;
--
2.15.1
^ permalink raw reply related
* [PATCH 33/38] arm64: Implement thread_struct whitelist for hardened usercopy
From: Kees Cook @ 2018-01-11 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515636190-24061-1-git-send-email-keescook@chromium.org>
This whitelists the FPU register state portion of the thread_struct for
copying to userspace, instead of the default entire structure.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: zijun_hu <zijun_hu@htc.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/processor.h | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a93339f5178f..c84477e6a884 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -90,6 +90,7 @@ config ARM64
select HAVE_ARCH_MMAP_RND_BITS
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_THREAD_STRUCT_WHITELIST
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
select HAVE_ARCH_VMAP_STACK
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 023cacb946c3..e58a5864ec89 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -113,6 +113,14 @@ struct thread_struct {
struct debug_info debug; /* debugging */
};
+/* Whitelist the fpsimd_state for copying to userspace. */
+static inline void arch_thread_struct_whitelist(unsigned long *offset,
+ unsigned long *size)
+{
+ *offset = offsetof(struct thread_struct, fpsimd_state);
+ *size = sizeof(struct fpsimd_state);
+}
+
#ifdef CONFIG_COMPAT
#define task_user_tls(t) \
({ \
--
2.7.4
^ permalink raw reply related
* [PATCH 34/38] arm: Implement thread_struct whitelist for hardened usercopy
From: Kees Cook @ 2018-01-11 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515636190-24061-1-git-send-email-keescook@chromium.org>
ARM does not carry FPU state in the thread structure, so it can declare
no usercopy whitelist at all.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/processor.h | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 51c8df561077..3ea00d65f35d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -50,6 +50,7 @@ config ARM
select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
+ select HAVE_ARCH_THREAD_STRUCT_WHITELIST
select HAVE_ARCH_TRACEHOOK
select HAVE_ARM_SMCCC if CPU_V7
select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 338cbe0a18ef..01a41be58d43 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -45,6 +45,13 @@ struct thread_struct {
struct debug_info debug;
};
+/* Nothing needs to be usercopy-whitelisted from thread_struct. */
+static inline void arch_thread_struct_whitelist(unsigned long *offset,
+ unsigned long *size)
+{
+ *offset = *size = 0;
+}
+
#define INIT_THREAD { }
#define start_thread(regs,pc,sp) \
--
2.7.4
^ permalink raw reply related
* [PATCH V6 Resend 00/13] drivers: Boot Constraint core
From: Chen-Yu Tsai @ 2018-01-11 2:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+CtWCKENTQmiveoubxU4cDi9QBcpgvYZVfxPNsT-VX+g@mail.gmail.com>
On Thu, Jan 11, 2018 at 7:13 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Tue, Jan 9, 2018 at 9:47 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> Hi Greg,
>>
>> I am re-sending V6 as you suggested. There is no change from the patches
>> sent on 14/15th of December, apart from rebasing on driver-core-next.
>>
>> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX
>> stuff was earlier tested by Sascha (Pengutronix) on i.MX6 and Qualcomm
>> stuff was earlier tested by Rajendra (Qualcomm) on Dragonboard 410C
>> (This required some more patches related to display driver which
>> Rajendra should be sending separately later on).
>>
>>
>> Problem statement:
>>
>> Some devices are powered ON by the bootloader before the bootloader
>> handovers control to Linux. It maybe important for those devices to keep
>> working until the time a Linux device driver probes the device and
>> reconfigure its resources.
>
> Some devices are powered on by a bootloader, but only a small few have
> to be maintained thru booting. Most you can just re-initialized.
>
>> A typical example of that can be the LCD controller, which is used by
>> the bootloaders to show image(s) while the platform is booting into
>> Linux. The LCD controller can be using some resources, like clk,
>> regulators, etc, that are shared between several devices. These shared
>> resources should be configured to satisfy need of all the users. If
>> another device's (X) driver gets probed before the LCD controller driver
>> in this case, then it may end up disabling or reconfiguring these
>> resources to ranges satisfying the current users (only device X) and
>> that can make the LCD screen unstable.
>
> We already have simple fb and a binding for it. It only handles clocks
> I think, but could be extended to other things. I rather not extend
> it, but it is there already and we don't need different solutions for
> this.
simplefb also handles regulators. This was added quite a while ago to
keep LCD displays powered on Allwinner tablets. However in general it
only grabs references to these resources and enables them so the kernel
frameworks don't think they are unused and turn them off. It doesn't
do clock rate or voltage constraints which Viresh wants. It should be
easy to do for regulators, and AFAIK there is a clock rate protection
mechanism for the clk framework in the works.
ChenYu
>> Another case can be a debug serial port enabled from the bootloader.
>
> I looked at your case with HiKey some. As far as the PL011
> driver/console is concerned, it should work as the clock is never
> enabled/disabled and then probe deferred (IMO, doing any h/w init
> before all resources are acquired is a driver error). The problem is
> the AMBA bus enabling apb_pclk (which has a dedicated clk gate) and
> then disabling it on deferred probe. The AMBA bus is fairly odd in
> this regard. We could solve this just with an initcall to find
> stdout-path node and enable all the clocks in the node and then a late
> initcall to disable those clocks. Kind of hacky, but so is this
> series.
>
> Really, I think the clock framework is broken in that we leave clocks
> in a mismatched state (reset state or whatever the bootloader decided)
> until the end of booting. Then we are left with dealing with these
> various platform specific issues. We should either not actually
> disable clocks until the end of boot (just defer until we turn off all
> unused clocks) or start requiring the clock drivers to turn off all
> the clocks except the ones needed to continue booting (or otherwise
> known to be constraints). The former should be easy to implement
> because the code to turn off clocks is already there. We just need a
> boot done flag and check that flag in disable function.
^ permalink raw reply
* [PATCH v3 0/5] ARM64: dts: meson-axg: UART DT updates
From: Yixun Lan @ 2018-01-11 2:33 UTC (permalink / raw)
To: linux-arm-kernel
HI Kevin
These are the UART DT updates for the Meson-AXG platform.
The patch 1 is a general fix.
Other patches are about adding clock & pinctrl info, then using them.
Last patch enable UART_A which connect to a BT module on the S400 board.
Note:
This series depend on previous UART_AO clock switch patch[1]
also, these patch request clocks, so they need the
tag:meson-clk-for-v4.16-2 from clk-meson's tree in order to compile.
Changes since v2 at [3]:
-- add Jerome's Reviewed-by to patch 1
-- adjust commit message, drop snip of code
-- drop extra blank line
Changes since v1 at [2]:
-- fix address range for all platform
-- squash patch 1, 3 (drop compatible & add clock)
-- fix typo in pinctrl info
-- add Jerome's Ack
[3]
http://lkml.kernel.org/r/20180106001044.108163-1-yixun.lan at amlogic.com
[2]
http://lkml.kernel.org/r/20180105095621.196472-1-yixun.lan at amlogic.com
[1]
http://lkml.kernel.org/r/20171215141741.175985-1-yixun.lan at amlogic.com
Yixun Lan (5):
ARM64: dts: meson: uart: fix address space range
ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
ARM64: dts: meson-axg: uart: Add the pinctrl info description
ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
ARM64: dts: meson-axg: enable the UART_A controller
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 9 +++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 108 ++++++++++++++++++++++++-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +--
3 files changed, 118 insertions(+), 9 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v3 1/5] ARM64: dts: meson: uart: fix address space range
From: Yixun Lan @ 2018-01-11 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111023401.125658-1-yixun.lan@amlogic.com>
The address space range is actually 0x18, fixed here.
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +++++-----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a80632641b39..70c776ef7aa7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -165,14 +165,14 @@
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
- reg = <0x0 0x24000 0x0 0x14>;
+ reg = <0x0 0x24000 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_B: serial at 23000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
- reg = <0x0 0x23000 0x0 0x14>;
+ reg = <0x0 0x23000 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 6cb3c2a52baf..4ee2e7951482 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -235,14 +235,14 @@
uart_A: serial at 84c0 {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84c0 0x0 0x14>;
+ reg = <0x0 0x84c0 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_B: serial at 84dc {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84dc 0x0 0x14>;
+ reg = <0x0 0x84dc 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
@@ -287,7 +287,7 @@
uart_C: serial at 8700 {
compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x8700 0x0 0x14>;
+ reg = <0x0 0x8700 0x0 0x18>;
interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
@@ -404,14 +404,14 @@
uart_AO: serial at 4c0 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
- reg = <0x0 0x004c0 0x0 0x14>;
+ reg = <0x0 0x004c0 0x0 0x18>;
interrupts = <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
uart_AO_B: serial at 4e0 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
- reg = <0x0 0x004e0 0x0 0x14>;
+ reg = <0x0 0x004e0 0x0 0x18>;
interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v3 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Yixun Lan @ 2018-01-11 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111023401.125658-1-yixun.lan@amlogic.com>
When update the clock info for the UART controller in the EE domain,
the driver explicitly require 'pclk' in order to work properly.
With current logic of the code, the driver will go for the legacy clock probe
routine if it find current compatible string match to 'amlogic,meson-uart',
which result in not requesting the 'pclk' clock, thus break the driver in the end.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 70c776ef7aa7..644d0f9eaf8c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -164,17 +164,21 @@
};
uart_A: serial at 24000 {
- compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
+ compatible = "amlogic,meson-gx-uart";
reg = <0x0 0x24000 0x0 0x18>;
interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
+ clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
uart_B: serial at 23000 {
- compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
+ compatible = "amlogic,meson-gx-uart";
reg = <0x0 0x23000 0x0 0x18>;
interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
status = "disabled";
+ clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v3 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description
From: Yixun Lan @ 2018-01-11 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111023401.125658-1-yixun.lan@amlogic.com>
Describe the pinctrl info for the UART controller which is found
in the Meson-AXG SoCs.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 96 ++++++++++++++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 644d0f9eaf8c..6cd28045e89c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -448,6 +448,70 @@
function = "spi1";
};
};
+
+ uart_a_pins: uart_a {
+ mux {
+ groups = "uart_tx_a",
+ "uart_rx_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_a_cts_rts_pins: uart_a_cts_rts {
+ mux {
+ groups = "uart_cts_a",
+ "uart_rts_a";
+ function = "uart_a";
+ };
+ };
+
+ uart_b_x_pins: uart_b_x {
+ mux {
+ groups = "uart_tx_b_x",
+ "uart_rx_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_x_cts_rts_pins: uart_b_x_cts_rts {
+ mux {
+ groups = "uart_cts_b_x",
+ "uart_rts_b_x";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_pins: uart_b_z {
+ mux {
+ groups = "uart_tx_b_z",
+ "uart_rx_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_b_z_cts_rts_pins: uart_b_z_cts_rts {
+ mux {
+ groups = "uart_cts_b_z",
+ "uart_rts_b_z";
+ function = "uart_b";
+ };
+ };
+
+ uart_ao_b_z_pins: uart_ao_b_z {
+ mux {
+ groups = "uart_ao_tx_b_z",
+ "uart_ao_rx_b_z";
+ function = "uart_ao_b_gpioz";
+ };
+ };
+
+ uart_ao_b_z_cts_rts_pins: uart_ao_b_z_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b_z",
+ "uart_ao_rts_b_z";
+ function = "uart_ao_b_gpioz";
+ };
+ };
};
};
@@ -498,6 +562,38 @@
function = "remote_input_ao";
};
};
+
+ uart_ao_a_pins: uart_ao_a {
+ mux {
+ groups = "uart_ao_tx_a",
+ "uart_ao_rx_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
+ mux {
+ groups = "uart_ao_cts_a",
+ "uart_ao_rts_a";
+ function = "uart_ao_a";
+ };
+ };
+
+ uart_ao_b_pins: uart_ao_b {
+ mux {
+ groups = "uart_ao_tx_b",
+ "uart_ao_rx_b";
+ function = "uart_ao_b";
+ };
+ };
+
+ uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
+ mux {
+ groups = "uart_ao_cts_b",
+ "uart_ao_rts_b";
+ function = "uart_ao_b";
+ };
+ };
};
pwm_AO_ab: pwm at 7000 {
--
2.15.1
^ permalink raw reply related
* [PATCH v3 4/5] ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
From: Yixun Lan @ 2018-01-11 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111023401.125658-1-yixun.lan@amlogic.com>
Explictly request the pinctrl info for the UART_AO_A controller,
otherwise we may need to rely on bootloader for the initialization.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 447b98d30921..9c1b78028ccb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -26,6 +26,8 @@
&uart_AO {
status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
};
&ir {
--
2.15.1
^ permalink raw reply related
* [PATCH v3 5/5] ARM64: dts: meson-axg: enable the UART_A controller
From: Yixun Lan @ 2018-01-11 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111023401.125658-1-yixun.lan@amlogic.com>
The UART_A is connected to a BT module on the S400 board.
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 9c1b78028ccb..d56894dbb209 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -14,6 +14,7 @@
aliases {
serial0 = &uart_AO;
+ serial1 = &uart_A;
};
};
@@ -24,6 +25,12 @@
pinctrl-names = "default";
};
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>;
+ pinctrl-names = "default";
+};
+
&uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
--
2.15.1
^ 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