Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1516224
| From | John Garry <john.garry@huawei.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver |
| Date | 2016-11-07 15:20 +0100 |
| Message-ID | <sASWd-4ht-15@gated-at.bofh.it> (permalink) |
| References | <sz5Xz-87s-3@gated-at.bofh.it> <sz5XA-87s-33@gated-at.bofh.it> <sAS9R-3GK-43@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 07/11/2016 13:26, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
>> From: Tan Xiaojun <tanxiaojun@huawei.com>
>>
>> The Hisilicon Djtag is an independent component which connects
>> with some other components in the SoC by Debug Bus. This driver
>> can be configured to access the registers of connecting components
>> (like L3 cache) during real time debugging.
>
> The formatting of the text seems odd, please remove the leading spaces.
>
My only response is at the bottom (I will not snip the code for early
referencing convenience).
Anurup/Tan can respond to the rest.
>> drivers/soc/Kconfig | 1 +
>> drivers/soc/Makefile | 1 +
>> drivers/soc/hisilicon/Kconfig | 12 +
>> drivers/soc/hisilicon/Makefile | 1 +
>> drivers/soc/hisilicon/djtag.c | 639 ++++++++++++++++++++++++++++++++++++
>> include/linux/soc/hisilicon/djtag.h | 38 +++
>
> Do you expect other drivers to be added that reference this interface?
> If not, or if you are unsure, just put all of it under drivers/perf
> so we don't introduce a global API that has only one user.
>
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/init.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include <asm-generic/delay.h>
>
> Never include files from asm-generic directly except from
> an architecture specific asm/*.h header file.
>
>
>> +DEFINE_IDR(djtag_hosts_idr);
>
> make this static
>
>> +static void djtag_read32_relaxed(void __iomem *regs_base, u32 off, u32 *value)
>> +{
>> + void __iomem *reg_addr = regs_base + off;
>> +
>> + *value = readl_relaxed(reg_addr);
>> +}
>> +
>> +static void djtag_write32(void __iomem *regs_base, u32 off, u32 val)
>> +{
>> + void __iomem *reg_addr = regs_base + off;
>> +
>> + writel(val, reg_addr);
>> +}
>
> This looks like an odd combination of interfaces.
> Why can the reads be "relaxed" when the writes can not?
>
> Generally speaking, I'd advise to always use non-relaxed accessors
> unless there is a strong performance reason, and in that case there
> should be a comment explaining the use at each of the callers
> of a relaxed accessor.
>
>> + /* ensure the djtag operation is done */
>> + do {
>> + djtag_read32_relaxed(regs_base, SC_DJTAG_MSTR_START_EN_EX, &rd);
>> +
>> + if (!(rd & DJTAG_MSTR_START_EN_EX))
>> + break;
>> +
>> + udelay(1);
>> + } while (timeout--);
>
> This one is obviously not performance critical at all, so use a non-relaxed
> accessor. Same for the other two in this function.
>
> Are these functions ever called from atomic context? If yes, please document
> from what context they can be called, otherwise please consider changing
> the udelay calls into sleeping waits.
>
>> +int hisi_djtag_writel(struct hisi_djtag_client *client, u32 offset, u32 mod_sel,
>> + u32 mod_mask, u32 val)
>> +{
>> + void __iomem *reg_map = client->host->sysctl_reg_map;
>> + unsigned long flags;
>> + int ret = 0;
>> +
>> + spin_lock_irqsave(&client->host->lock, flags);
>> + ret = client->host->djtag_readwrite(reg_map, offset, mod_sel, mod_mask,
>> + true, val, 0, NULL);
>> + if (ret)
>> + pr_err("djtag_writel: error! ret=%d\n", ret);
>> + spin_unlock_irqrestore(&client->host->lock, flags);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hisi_djtag_writel);
>
> That would of course imply changing the spinlock to a mutex here as well.
>
>> +static const struct of_device_id djtag_of_match[] = {
>> + /* for hip05(D02) cpu die */
>> + { .compatible = "hisilicon,hip05-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip05(D02) io die */
>> + { .compatible = "hisilicon,hip05-io-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) cpu die */
>> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) io die */
>> + { .compatible = "hisilicon,hip06-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + /* for hip07(D05) cpu die */
>> + { .compatible = "hisilicon,hip07-cpu-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + /* for hip07(D05) io die */
>> + { .compatible = "hisilicon,hip07-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + {},
>> +};
>
> If these are backwards compatible, just mark them as compatible in DT,
> e.g. hip06 can use
>
> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
>
> so you can tell the difference if you need to, but the driver only has to
> list the oldest one here.
>
> What is the difference between the cpu and io djtag interfaces?
>
> I think you can also drop the '(void *)'.
>
>> +static void djtag_register_devices(struct hisi_djtag_host *host)
>> +{
>> + struct device_node *node;
>> + struct hisi_djtag_client *client;
>> +
>> + if (!host->of_node)
>> + return;
>> +
>> + for_each_available_child_of_node(host->of_node, node) {
>> + if (of_node_test_and_set_flag(node, OF_POPULATED))
>> + continue;
>> + client = hisi_djtag_of_register_device(host, node);
>> + list_add(&client->next, &host->client_list);
>> + }
>> +}
>
> Can you explain your thoughts behind creating a new bus type
> and adding the child devices manually rather than using
> platform_device structures with of_platform_populate()?
>
> Do you expect to see other implementations of this bus type
> with incompatible bus drivers?
>
> Arnd
>
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
driver arch, where we have a host bus adapter and child devices attached
to the bus. The child devices are bus driver devices and have bus
addresses. We think of the djtag as a separate bus, so we are modelling
it as such.
The bus driver offers a simple host interface for clients to read/write
to the djtag bus: bus accesses are hidden from the client, the host
drives the bus.
> Do you expect to see other implementations of this bus type
> with incompatible bus drivers?
Maybe, not sure.
Cheers,
John
>
> .
>
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v1 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 09/11] perf: hisi: Miscellanous node(MN) event counting in perf Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 06/11] perf: hisi: Update Kconfig for Hisilicon PMU support Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 10/11] perf: hisi: Support for Hisilicon DDRC PMU. Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 08/11] perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 04/11] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting. Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 01/11] arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-07 14:30 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver John Garry <john.garry@huawei.com> - 2016-11-07 15:20 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-07 21:10 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver John Garry <john.garry@huawei.com> - 2016-11-08 12:40 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-08 12:50 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver John Garry <john.garry@huawei.com> - 2016-11-08 15:00 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-08 16:20 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver John Garry <john.garry@huawei.com> - 2016-11-08 16:20 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-09 12:00 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-08 17:00 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver John Garry <john.garry@huawei.com> - 2016-11-09 10:10 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-11 11:40 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Tan Xiaojun <tanxiaojun@huawei.com> - 2016-11-08 08:10 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-08 08:40 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-08 12:50 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-08 14:50 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-08 16:20 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-09 05:30 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Arnd Bergmann <arnd@arndb.de> - 2016-11-09 22:50 +0100
Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M <anurupvasu@gmail.com> - 2016-11-11 11:30 +0100
[PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
[PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU Anurup M <anurupvasu@gmail.com> - 2016-11-02 16:50 +0100
csiph-web