* Re: [PATCH v6 01/10] arm64: dts: rockchip: Enable edp disaplay on kevin
From: Heiko Stuebner @ 2017-12-04 17:59 UTC (permalink / raw)
To: Jeffy Chen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
briannorris-F7+t8E8rja9g9hUCZPvPmw,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, dianders-F7+t8E8rja9g9hUCZPvPmw,
tfiga-F7+t8E8rja9g9hUCZPvPmw, Matthias Kaehlcke, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Yao,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon,
Mark Rutland, Caesar Wang, Catalin Marinas
In-Reply-To: <20171019034812.13768-2-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Donnerstag, 19. Oktober 2017, 11:48:03 CET schrieb Jeffy Chen:
> Add edp panel and enable related nodes on kevin.
>
> Signed-off-by: Jeffy Chen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Reviewed-by: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
applied for 4.16 with Enric's Tested-tag and after also
seeing a bit of output on the edp.
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V3 2/2] ARM64: tegra: limit PCIe config space mapping to 4K for T186
From: Vidya Sagar @ 2017-12-04 17:53 UTC (permalink / raw)
To: treding-DDmLM1+adcrQT0dZR+AlfA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, kthota-DDmLM1+adcrQT0dZR+AlfA,
mmaddireddy-DDmLM1+adcrQT0dZR+AlfA, vidyas-DDmLM1+adcrQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512410030-21038-1-git-send-email-vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
reduces PCIe config space mapping size from its current 256MB
to 4K to have only 4K of virtual memory mapping and to be
in line with driver implementation
Signed-off-by: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
V3:
* no change in this patch
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 46d1f287fb0f..62fa3bef3e18 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -363,7 +363,7 @@
device_type = "pci";
reg = <0x0 0x10003000 0x0 0x00000800 /* PADS registers */
0x0 0x10003800 0x0 0x00000800 /* AFI registers */
- 0x0 0x40000000 0x0 0x10000000>; /* configuration space */
+ 0x0 0x40000000 0x0 0x00001000>; /* configuration space */
reg-names = "pads", "afi", "cs";
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
@@ -381,9 +381,9 @@
ranges = <0x82000000 0 0x10000000 0x0 0x10000000 0 0x00001000 /* port 0 configuration space */
0x82000000 0 0x10001000 0x0 0x10001000 0 0x00001000 /* port 1 configuration space */
0x82000000 0 0x10004000 0x0 0x10004000 0 0x00001000 /* port 2 configuration space */
- 0x81000000 0 0x0 0x0 0x50000000 0 0x00010000 /* downstream I/O (64 KiB) */
- 0x82000000 0 0x50100000 0x0 0x50100000 0 0x07F00000 /* non-prefetchable memory (127 MiB) */
- 0xc2000000 0 0x58000000 0x0 0x58000000 0 0x28000000>; /* prefetchable memory (640 MiB) */
+ 0x81000000 0 0x0 0x0 0x40001000 0 0x00010000 /* downstream I/O (64 KiB) */
+ 0x82000000 0 0x40100000 0x0 0x40100000 0 0x07F00000 /* non-prefetchable memory (127 MiB) */
+ 0xc2000000 0 0x48000000 0x0 0x48000000 0 0x38000000>; /* prefetchable memory (896 MiB) */
clocks = <&bpmp TEGRA186_CLK_AFI>,
<&bpmp TEGRA186_CLK_PCIE>,
--
2.7.4
^ permalink raw reply related
* [PATCH V3 1/2] PCI: tegra: refactor config space mapping code
From: Vidya Sagar @ 2017-12-04 17:53 UTC (permalink / raw)
To: treding-DDmLM1+adcrQT0dZR+AlfA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, kthota-DDmLM1+adcrQT0dZR+AlfA,
mmaddireddy-DDmLM1+adcrQT0dZR+AlfA, vidyas-DDmLM1+adcrQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512410030-21038-1-git-send-email-vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
use only 4K space from available 1GB PCIe aperture to access
end points configuration space by dynamically moving AFI_AXI_BAR
base address and always making sure that the desired location
to be accessed for generating required config space access falls
in the 4K space reserved for this purpose. This would give more
space for mapping end point device's BARs on some of Tegra platforms
Signed-off-by: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
V3:
* added a new soc_data entry 'use_4k_conf_space' to decide whether to use first 4K chunk (T20, T186)
* or last 4K chunk (T30, T124, T132 and T210) of the available 256MB region
V2:
* restored tegra_pcie_conf_offset() after extending it to include bus number
* removed tegra_pcie_bus_alloc() and merged some of its contents with tegra_pcie_add_bus()
* replaced ioremap() with devm_ioremap()
drivers/pci/host/pci-tegra.c | 125 ++++++++++++++-----------------------------
1 file changed, 40 insertions(+), 85 deletions(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index f9d3960dc39f..eb9c443c8ba6 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -257,6 +257,7 @@ struct tegra_pcie_soc {
bool has_gen2;
bool force_pca_enable;
bool program_uphy;
+ bool use_4k_conf_space;
};
static inline struct tegra_msi *to_tegra_msi(struct msi_controller *chip)
@@ -274,6 +275,8 @@ struct tegra_pcie {
struct list_head buses;
struct resource *cs;
+ void __iomem *cfg_va_base;
+
struct resource io;
struct resource pio;
struct resource mem;
@@ -322,7 +325,6 @@ struct tegra_pcie_port {
};
struct tegra_pcie_bus {
- struct vm_struct *area;
struct list_head list;
unsigned int nr;
};
@@ -362,69 +364,17 @@ static inline u32 pads_readl(struct tegra_pcie *pcie, unsigned long offset)
*
* Mapping the whole extended configuration space would require 256 MiB of
* virtual address space, only a small part of which will actually be used.
- * To work around this, a 1 MiB of virtual addresses are allocated per bus
- * when the bus is first accessed. When the physical range is mapped, the
- * the bus number bits are hidden so that the extended register number bits
- * appear as bits [19:16]. Therefore the virtual mapping looks like this:
- *
- * [19:16] extended register number
- * [15:11] device number
- * [10: 8] function number
- * [ 7: 0] register number
- *
- * This is achieved by stitching together 16 chunks of 64 KiB of physical
- * address space via the MMU.
+ * To work around this, a 4K of region is used to generate required
+ * configuration transaction with relevant B:D:F values. This is achieved by
+ * dynamically programming base address and size of AFI_AXI_BAR used for
+ * end point config space mapping to make sure that the address (access to
+ * which generates correct config transaction) falls in this 4K region
*/
-static unsigned long tegra_pcie_conf_offset(unsigned int devfn, int where)
-{
- return ((where & 0xf00) << 8) | (PCI_SLOT(devfn) << 11) |
- (PCI_FUNC(devfn) << 8) | (where & 0xfc);
-}
-
-static struct tegra_pcie_bus *tegra_pcie_bus_alloc(struct tegra_pcie *pcie,
- unsigned int busnr)
+static unsigned long tegra_pcie_conf_offset(unsigned char b, unsigned int devfn,
+ int where)
{
- struct device *dev = pcie->dev;
- pgprot_t prot = pgprot_noncached(PAGE_KERNEL);
- phys_addr_t cs = pcie->cs->start;
- struct tegra_pcie_bus *bus;
- unsigned int i;
- int err;
-
- bus = kzalloc(sizeof(*bus), GFP_KERNEL);
- if (!bus)
- return ERR_PTR(-ENOMEM);
-
- INIT_LIST_HEAD(&bus->list);
- bus->nr = busnr;
-
- /* allocate 1 MiB of virtual addresses */
- bus->area = get_vm_area(SZ_1M, VM_IOREMAP);
- if (!bus->area) {
- err = -ENOMEM;
- goto free;
- }
-
- /* map each of the 16 chunks of 64 KiB each */
- for (i = 0; i < 16; i++) {
- unsigned long virt = (unsigned long)bus->area->addr +
- i * SZ_64K;
- phys_addr_t phys = cs + i * SZ_16M + busnr * SZ_64K;
-
- err = ioremap_page_range(virt, virt + SZ_64K, phys, prot);
- if (err < 0) {
- dev_err(dev, "ioremap_page_range() failed: %d\n", err);
- goto unmap;
- }
- }
-
- return bus;
-
-unmap:
- vunmap(bus->area->addr);
-free:
- kfree(bus);
- return ERR_PTR(err);
+ return (b << 16) | (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) |
+ (((where & 0xf00) >> 8) << 24) | (where & 0xff);
}
static int tegra_pcie_add_bus(struct pci_bus *bus)
@@ -433,10 +383,13 @@ static int tegra_pcie_add_bus(struct pci_bus *bus)
struct tegra_pcie *pcie = pci_host_bridge_priv(host);
struct tegra_pcie_bus *b;
- b = tegra_pcie_bus_alloc(pcie, bus->number);
- if (IS_ERR(b))
+ b = kzalloc(sizeof(*b), GFP_KERNEL);
+ if (!b)
return PTR_ERR(b);
+ INIT_LIST_HEAD(&b->list);
+ b->nr = bus->number;
+
list_add_tail(&b->list, &pcie->buses);
return 0;
@@ -450,7 +403,6 @@ static void tegra_pcie_remove_bus(struct pci_bus *child)
list_for_each_entry_safe(bus, tmp, &pcie->buses, list) {
if (bus->nr == child->number) {
- vunmap(bus->area->addr);
list_del(&bus->list);
kfree(bus);
break;
@@ -464,8 +416,9 @@ static void __iomem *tegra_pcie_map_bus(struct pci_bus *bus,
{
struct pci_host_bridge *host = pci_find_host_bridge(bus);
struct tegra_pcie *pcie = pci_host_bridge_priv(host);
- struct device *dev = pcie->dev;
void __iomem *addr = NULL;
+ u32 val = 0;
+ u32 offset = 0;
if (bus->number == 0) {
unsigned int slot = PCI_SLOT(devfn);
@@ -478,19 +431,11 @@ static void __iomem *tegra_pcie_map_bus(struct pci_bus *bus,
}
}
} else {
- struct tegra_pcie_bus *b;
-
- list_for_each_entry(b, &pcie->buses, list)
- if (b->nr == bus->number)
- addr = (void __iomem *)b->area->addr;
-
- if (!addr) {
- dev_err(dev, "failed to map cfg. space for bus %u\n",
- bus->number);
- return NULL;
- }
-
- addr += tegra_pcie_conf_offset(devfn, where);
+ offset = tegra_pcie_conf_offset(bus->number, devfn, where);
+ addr = pcie->cfg_va_base + (offset & (SZ_4K - 1));
+ val = offset & ~(SZ_4K - 1);
+ afi_writel(pcie, pcie->cs->start - val, AFI_AXI_BAR0_START);
+ afi_writel(pcie, (val + SZ_4K) >> 12, AFI_AXI_BAR0_SZ);
}
return addr;
@@ -744,10 +689,6 @@ static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
/* Bar 0: type 1 extended configuration space */
fpci_bar = 0xfe100000;
- size = resource_size(pcie->cs);
- axi_address = pcie->cs->start;
- afi_writel(pcie, axi_address, AFI_AXI_BAR0_START);
- afi_writel(pcie, size >> 12, AFI_AXI_BAR0_SZ);
afi_writel(pcie, fpci_bar, AFI_FPCI_BAR0);
/* Bar 1: downstream IO bar */
@@ -1304,6 +1245,7 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
struct platform_device *pdev = to_platform_device(dev);
struct resource *pads, *afi, *res;
const struct tegra_pcie_soc *soc = pcie->soc;
+ u32 axi_addr = 0;
int err;
err = tegra_pcie_clocks_get(pcie);
@@ -1353,13 +1295,21 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
goto poweroff;
}
- pcie->cs = devm_request_mem_region(dev, res->start,
- resource_size(res), res->name);
+ axi_addr = pcie->soc->use_4k_conf_space ?
+ res->start : res->end - SZ_4K + 1;
+ pcie->cs = devm_request_mem_region(dev, axi_addr, SZ_4K, res->name);
if (!pcie->cs) {
err = -EADDRNOTAVAIL;
goto poweroff;
}
+ pcie->cfg_va_base = devm_ioremap(dev, pcie->cs->start, SZ_4K);
+ if (!pcie->cfg_va_base) {
+ dev_err(pcie->dev, "failed to ioremap config space\n");
+ err = -EADDRNOTAVAIL;
+ goto poweroff;
+ }
+
/* request interrupt */
err = platform_get_irq_byname(pdev, "intr");
if (err < 0) {
@@ -2150,6 +2100,7 @@ static const struct tegra_pcie_soc tegra20_pcie = {
.has_gen2 = false,
.force_pca_enable = false,
.program_uphy = true,
+ .use_4k_conf_space = true,
};
static const struct tegra_pcie_soc tegra30_pcie = {
@@ -2166,6 +2117,7 @@ static const struct tegra_pcie_soc tegra30_pcie = {
.has_gen2 = false,
.force_pca_enable = false,
.program_uphy = true,
+ .use_4k_conf_space = false,
};
static const struct tegra_pcie_soc tegra124_pcie = {
@@ -2181,6 +2133,7 @@ static const struct tegra_pcie_soc tegra124_pcie = {
.has_gen2 = true,
.force_pca_enable = false,
.program_uphy = true,
+ .use_4k_conf_space = false,
};
static const struct tegra_pcie_soc tegra210_pcie = {
@@ -2196,6 +2149,7 @@ static const struct tegra_pcie_soc tegra210_pcie = {
.has_gen2 = true,
.force_pca_enable = true,
.program_uphy = true,
+ .use_4k_conf_space = false,
};
static const struct tegra_pcie_soc tegra186_pcie = {
@@ -2212,6 +2166,7 @@ static const struct tegra_pcie_soc tegra186_pcie = {
.has_gen2 = true,
.force_pca_enable = false,
.program_uphy = false,
+ .use_4k_conf_space = true,
};
static const struct of_device_id tegra_pcie_of_match[] = {
--
2.7.4
^ permalink raw reply related
* [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring
From: Vidya Sagar @ 2017-12-04 17:53 UTC (permalink / raw)
To: treding-DDmLM1+adcrQT0dZR+AlfA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, kthota-DDmLM1+adcrQT0dZR+AlfA,
mmaddireddy-DDmLM1+adcrQT0dZR+AlfA, vidyas-DDmLM1+adcrQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
PCIe host controller in Tegra SoCs has 1GB of aperture available
for mapping end points config space, IO and BARs. In that, currently
256MB is being reserved for mapping end points configuration space
which leaves less memory space available for mapping end points BARs
on some of the platforms.
This patch series attempts to map only 4K space from 1GB aperture to
access end points configuration space.
Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
to use for BAR mapping) physical space as well as kernel virtual mapping space,
it saves only kernel virtual address space in T30, T124, T132 and T210.
NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
For older platforms (T20, T30, T124, T132, T210), this change works fine without any
DT modifications
Testing Done on T124, T210 & T186:
Enumeration and basic functionality of immediate devices
Enumeration of devices behind a PCIe switch
Complete 4K configuration space access
Vidya Sagar (2):
PCI: tegra: refactor config space mapping code
ARM64: tegra: limit PCIe config space mapping to 4K for T186
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 8 +-
drivers/pci/host/pci-tegra.c | 125 ++++++++++---------------------
2 files changed, 44 insertions(+), 89 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 6/6] ARM: configs: keystone_defconfig: Enable few peripheral drivers
From: Santosh Shilimkar @ 2017-12-04 17:36 UTC (permalink / raw)
To: Vignesh R, Santosh Shilimkar
Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel
In-Reply-To: <76a88f69-dd0b-8823-ae31-bd39b1abae87@ti.com>
On 12/4/2017 1:00 AM, Vignesh R wrote:
> Hi,
>
> On Sunday 03 December 2017 09:30 AM, santosh.shilimkar@oracle.com wrote:
>> On 11/22/17 11:51 PM, Vignesh R wrote:
>>> Enable drivers for QSPI, LEDS, gpio-decoder that are present on 66AK2G
>>> EVM
>>> and 66AK2G ICE boards.
>>>
>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>> ---
>> Please submit a patch also to enable all these peripherals
>> in multi-v7 config. Just enable all remainder
>> options enabled in keystone config also in multi-v7.
>
> K2 Platforms don't boot out of multi_v7_defconfig by default, because K2
> platforms require CONFIG_ARM_LPAE(which is disabled in multi-v7).
>
> If the intention is to just have all drivers enabled in
> keystone_defconfig to be added to multi_v7, I can prepare a patch for
> that and test with local patch to enable LPAE.
>
Yes. Please send a patch for it.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v6 0/2] memory: Introduce ti-emif-sram driver
From: Santosh Shilimkar @ 2017-12-04 17:35 UTC (permalink / raw)
To: Tony Lindgren
Cc: Dave Gerlach, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Russell King,
Keerthy J, Johan Hovold
In-Reply-To: <20171203163632.GU28152-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 12/3/2017 8:36 AM, Tony Lindgren wrote:
> * santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org <santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> [171203 04:03]:
>>
>>
>> On 11/30/17 2:56 PM, Dave Gerlach wrote:
>>> This is a resend of v5 of this series found here [1]. It introduces
>>> relocatable PM handlers for the emif that are copied to sram and
>>> run from there during low power mode entry.
>>>
>>> The patches still have the previous ACKs but have a small change to
>>> accomodate a change made by Tony in commit cd57dc5a2099 ("ARM: dts:
>>> Add missing hwmod related nodes for am33xx"). If there are objections
>>> to this let me know ASAP.
>>>
>>> Now that a hwmod is present for the am335x EMIF, on probe fail the call to
>>> pm_runtime_put_sync causes the board to hang. In fact, this emif driver should
>>> never alter the PM state of the hardware at all through normal kernel calls, it
>>> is the job of the suspend handlers that are added, that is the whole point of
>>> this driver. Because of this, I have dropped all runtime pm calls, as any
>>> change to the PM state while the kernel is running is dangerous as we may shut
>>> of the memory controller. It makes the most sense just to drop runtime PM from
>>> the driver entirely. Besides that patch is unchanged.
>>>
>>> This code is required for low-power modes to work on AM335x and AM437x and a
>>> forthcoming PM series for those platforms will depend on this series. After
>>> both this and the PM series are reviewed I will send the necessary device tree
>>> changes for both, but in the meantime all remaining patches for am335x and
>>> am437x PM can be found here [2].
>>>
>> Applied
>
> OK, do you have some immutable commit for these I can pull in too for
> the related SoC changes?
>
Hopefully I don't have do any changes to below branch.
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
for_4.16/drivers-soc
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/5] media: i2c: Add TDA1997x HDMI receiver driver
From: Tim Harvey @ 2017-12-04 17:30 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shawn Guo,
Steve Longerbeam, Philipp Zabel, Hans Verkuil,
Mauro Carvalho Chehab
In-Reply-To: <1a1be5d7-caed-6cba-c97a-dbb70e119fa3-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Mon, Dec 4, 2017 at 4:50 AM, Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> wrote:
> Hi Tim,
>
> Found a few more small issues. After that's fixed and you have the Ack for the
> bindings this can be merged I think.
Hans,
Thanks. Can you weigh in on the bindings? Rob was hoping for some
discussion on making some generic bus format types for video and I'm
not familiar with the other video encoders/decoders enough to know if
there is enough commonality.
>
> On 11/29/2017 10:19 PM, Tim Harvey wrote:
<snip>
>> +
>> +/* parse an infoframe and do some sanity checks on it */
>> +static unsigned int
>> +tda1997x_parse_infoframe(struct tda1997x_state *state, u16 addr)
>> +{
>> + struct v4l2_subdev *sd = &state->sd;
>> + union hdmi_infoframe frame;
>> + u8 buffer[40];
>> + u8 reg;
>> + int len, err;
>> +
>> + /* read data */
>> + len = io_readn(sd, addr, sizeof(buffer), buffer);
>> + err = hdmi_infoframe_unpack(&frame, buffer);
>> + if (err) {
>> + v4l_err(state->client,
>> + "failed parsing %d byte infoframe: 0x%04x/0x%02x\n",
>> + len, addr, buffer[0]);
>> + return err;
>> + }
>> + hdmi_infoframe_log(KERN_INFO, &state->client->dev, &frame);
>> + switch (frame.any.type) {
>> + /* Audio InfoFrame: see HDMI spec 8.2.2 */
>> + case HDMI_INFOFRAME_TYPE_AUDIO:
>> + /* sample rate */
>> + switch (frame.audio.sample_frequency) {
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_32000:
>> + state->audio_samplerate = 32000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_44100:
>> + state->audio_samplerate = 44100;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_48000:
>> + state->audio_samplerate = 48000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_88200:
>> + state->audio_samplerate = 88200;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_96000:
>> + state->audio_samplerate = 96000;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_176400:
>> + state->audio_samplerate = 176400;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_192000:
>> + state->audio_samplerate = 192000;
>> + break;
>> + default:
>> + case HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM:
>> + break;
>> + }
>> +
>> + /* sample size */
>> + switch (frame.audio.sample_size) {
>> + case HDMI_AUDIO_SAMPLE_SIZE_16:
>> + state->audio_samplesize = 16;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_20:
>> + state->audio_samplesize = 20;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_24:
>> + state->audio_samplesize = 24;
>> + break;
>> + case HDMI_AUDIO_SAMPLE_SIZE_STREAM:
>> + default:
>> + break;
>> + }
>> +
>> + /* Channel Count */
>> + state->audio_channels = frame.audio.channels;
>> + if (frame.audio.channel_allocation &&
>> + frame.audio.channel_allocation != state->audio_ch_alloc) {
>> + /* use the channel assignment from the infoframe */
>> + state->audio_ch_alloc = frame.audio.channel_allocation;
>> + tda1997x_configure_audout(sd, state->audio_ch_alloc);
>> + /* reset the audio FIFO */
>> + tda1997x_hdmi_info_reset(sd, RESET_AUDIO, false);
>> + }
>> + break;
>> +
>> + /* Auxiliary Video information (AVI) InfoFrame: see HDMI spec 8.2.1 */
>> + case HDMI_INFOFRAME_TYPE_AVI:
>> + state->colorspace = frame.avi.colorspace;
>> + state->colorimetry = frame.avi.colorimetry;
>> + state->content = frame.avi.content_type;
>> + /* Quantization Range */
>> + switch (state->rgb_quantization_range) {
>> + case V4L2_DV_RGB_RANGE_AUTO:
>> + state->range = frame.avi.quantization_range;
>> + break;
>> + case V4L2_DV_RGB_RANGE_LIMITED:
>> + state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
>> + break;
>> + case V4L2_DV_RGB_RANGE_FULL:
>> + state->range = HDMI_QUANTIZATION_RANGE_FULL;
>> + break;
>> + }
>> + if (state->range == HDMI_QUANTIZATION_RANGE_DEFAULT) {
>> + if (frame.avi.video_code <= 1)
>> + state->range = HDMI_QUANTIZATION_RANGE_FULL;
>> + else
>> + state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
>> + }
>> + /*
>> + * If colorimetry not specified, conversion depends on res type:
>> + * - SDTV: ITU601 for SD (480/576/240/288 line resolution)
>> + * - HDTV: ITU709 for HD (720/1080 line resolution)
>> + * - PC: sRGB
>> + * see HDMI specification section 6.7
>> + */
>> + if ((state->colorspace == HDMI_COLORSPACE_YUV422 ||
>> + state->colorspace == HDMI_COLORSPACE_YUV444) &&
>> + (state->colorimetry == HDMI_COLORIMETRY_EXTENDED ||
>> + state->colorimetry == HDMI_COLORIMETRY_NONE)) {
>> + if (is_sd(state->timings.bt.height))
>> + state->colorimetry = HDMI_COLORIMETRY_ITU_601;
>> + else if (is_hd(state->timings.bt.height))
>> + state->colorimetry = HDMI_COLORIMETRY_ITU_709;
>> + else
>> + state->colorimetry = HDMI_COLORIMETRY_NONE;
>> + }
>> + v4l_dbg(1, debug, state->client,
>> + "colorspace=%d colorimetry=%d range=%d content=%d\n",
>> + state->colorspace, state->colorimetry, state->range,
>> + state->content);
>> +
>> + /* configure upsampler: 0=bypass 1=repeatchroma 2=interpolate */
>> + reg = io_read(sd, REG_PIX_REPEAT);
>> + reg &= ~PIX_REPEAT_MASK_UP_SEL;
>> + if (state->colorspace == HDMI_COLORSPACE_YUV422)
>> + reg |= (PIX_REPEAT_CHROMA << PIX_REPEAT_SHIFT);
>> + io_write(sd, REG_PIX_REPEAT, reg);
>> +
>> + /* ConfigurePixelRepeater: repeat n-times each pixel */
>> + reg = io_read(sd, REG_PIX_REPEAT);
>> + reg &= ~PIX_REPEAT_MASK_REP;
>> + reg |= frame.avi.pixel_repeat;
>> + io_write(sd, REG_PIX_REPEAT, reg);
>> +
>> + /* configure the receiver with the new colorspace */
>> + tda1997x_configure_csc(sd);
>> + break;
>> + default:
>> + break;
>> + }
>> + return 0;
>> +}
>> +
<snip>
>> +
>> +static int tda1997x_fill_format(struct tda1997x_state *state,
>> + struct v4l2_mbus_framefmt *format)
>> +{
>> + const struct v4l2_bt_timings *bt;
>> +
>> + v4l_dbg(1, debug, state->client, "%s\n", __func__);
>> +
>> + if (!state->detected_timings)
>> + return -EINVAL;
>> + bt = &state->detected_timings->bt;
>> + memset(format, 0, sizeof(*format));
>> +
>> + format->width = bt->width;
>> + format->height = bt->height;
>> + format->field = V4L2_FIELD_NONE;
>> + format->colorspace = V4L2_COLORSPACE_SRGB;
>> + if (bt->flags & V4L2_DV_FL_IS_CE_VIDEO)
>> + format->colorspace = (bt->height <= 576) ?
>> + V4L2_COLORSPACE_SMPTE170M : V4L2_COLORSPACE_REC709;
>
> Close. What is missing is a check of the AVI InfoFrame: if it has an explicit
> colorimetry then use that. E.g. check for HDMI_COLORIMETRY_ITU_601 or ITU_709
> and set the colorspace accordingly. Otherwise fall back to what you have here.
>
This function currently matches adv7604/adv7842 where they don't look
at colorimetry (but I do see a TODO in adv748x_hdmi_fill_format to
look at this) so I don't have an example and may not understand.
Do you mean:
format->colorspace = V4L2_COLORSPACE_SRGB;
if (bt->flags & V4L2_DV_FL_IS_CE_VIDEO) {
if ((state->colorimetry == HDMI_COLORIMETRY_ITU_601) ||
(state->colorimetry == HDMI_COLORIMETRY_ITU_709))
format->colorspace = state->colorspace;
else
format->colorspace = is_sd(bt->height) ?
V4L2_COLORSPACE_SMPTE170M :
V4L2_COLORSPACE_REC709;
}
Also during more testing I've found that I'm not capturing interlaced
properly and know I at least need:
- format->field = V4L2_FIELD_NONE;
+ format->field = (bt->interlaced) ?
+ V4L2_FIELD_ALTERNATE : V4L2_FIELD_NONE;
I'm still not quite capturing interlaced yet but I think its an issue
of setting up the media pipeline improperly.
> Make a note that we ignore HDMI_COLORIMETRY_EXTENDED as we don't properly
> support that anyway. For the record: I know that the colorimetry field in the
> AVI InfoFrame can change dynamically, so this is just a snapshot in time. We
> don't have good support for dynamic colorimetry changes. Or to be precise: we
> never got around to implement it.
>
>> +
>> + return 0;
>> +}
>> +
<snip>
>> +
>> +static int tda1997x_s_ctrl(struct v4l2_ctrl *ctrl)
>> +{
>> + struct v4l2_subdev *sd = to_sd(ctrl);
>> + struct tda1997x_state *state = to_state(sd);
>> +
>> + switch (ctrl->id) {
>> + /* allow overriding the default RGB quantization range */
>> + case V4L2_CID_DV_RX_RGB_RANGE:
>> + state->range = ctrl->val;
>
> This should be assigned to state->rgb_quantization_range!
oops... thanks!
>
>> + tda1997x_configure_csc(sd);
>> + return 0;
>> + }
>> +
>> + return -EINVAL;
>> +};
>> +
Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 13/13] ASoC: stm32: add DFSDM DAI support
From: Mark Brown @ 2017-12-04 16:58 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Mark Rutland, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, Lars-Peter Clausen, Maxime Coquelin,
Liam Girdwood, linux-iio@vger.kernel.org, Takashi Iwai,
Jaroslav Kysela, Rob Herring,
linux-arm-kernel@lists.infradead.org, Peter Meerwald-Stadler,
Hartmut Knaack, Jonathan Cameron, Alexandre TORGUE
In-Reply-To: <bd2ba77f-2d91-efb7-d89a-3f8cdeb941f7@st.com>
[-- Attachment #1.1: Type: text/plain, Size: 740 bytes --]
On Mon, Dec 04, 2017 at 09:58:42AM +0100, Arnaud Pouliquen wrote:
> On 12/02/2017 04:09 PM, Jonathan Cameron wrote:
> > Mark, given this set is moderately invasive on the IIO side and
> > should just drop in cleanly on the sound side of things, either
> > I could take it via IIO or one of us can do an immutable branch
> > and we take it through both trees.
> Don't know if you saw the reply from Mark on V5:
> "This is basically fine, if someone could send me a pull request and the
> relevant patches when the IIO stuff is sorted out I'll give it a final
> check and apply then."
Yup, I figure that a shared branch with the IIO changes in will be the
easiest thing (Morimoto-san is donig a bunch of subsystem wide ASoC
cleanups ATM).
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: increase bus frequency for MHL chip
From: Krzysztof Kozlowski @ 2017-12-04 16:51 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-samsung-soc, devicetree, Marek Szyprowski, dri-devel,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171201113351.16361-1-a.hajda@samsung.com>
On Fri, Dec 01, 2017 at 12:33:51PM +0100, Andrzej Hajda wrote:
> sii8620 supports 1MHz clock, it allows faster transmissions and according
> to extensive tests allows to mitigate some obscure bugs in I2C client
> logic of the chip.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
Thanks, applied.
Best regards,
Krzysztof
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 08/19] ASoC: tlv320aic31xx: Switch GPIO handling to use gpiod_* API
From: Andrew F. Davis @ 2017-12-04 16:47 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Benoît Cousson, Tony Lindgren
Cc: devicetree, alsa-devel, linux-kernel
In-Reply-To: <20171129213300.20021-9-afd@ti.com>
On 11/29/2017 03:32 PM, Andrew F. Davis wrote:
> Move to using newer gpiod_* GPIO handling functions. This simplifies
> the code and eases dropping platform data in the next patch. Also
> remember GPIO are active low, so set "1" to reset.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
Kbuild bot seems mad a this one, looks like I need to include
linux/gpio/consumer.h, will fix for v3.
> sound/soc/codecs/tlv320aic31xx.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
> index c84febd991a0..ab03a19f6aaa 100644
> --- a/sound/soc/codecs/tlv320aic31xx.c
> +++ b/sound/soc/codecs/tlv320aic31xx.c
> @@ -157,6 +157,7 @@ struct aic31xx_priv {
> u8 i2c_regs_status;
> struct device *dev;
> struct regmap *regmap;
> + struct gpio_desc *gpio_reset;
> struct aic31xx_pdata pdata;
> struct regulator_bulk_data supplies[AIC31XX_NUM_SUPPLIES];
> struct aic31xx_disable_nb disable_nb[AIC31XX_NUM_SUPPLIES];
> @@ -1020,8 +1021,8 @@ static int aic31xx_regulator_event(struct notifier_block *nb,
> * Put codec to reset and as at least one of the
> * supplies was disabled.
> */
> - if (gpio_is_valid(aic31xx->pdata.gpio_reset))
> - gpio_set_value(aic31xx->pdata.gpio_reset, 0);
> + if (aic31xx->gpio_reset)
> + gpiod_set_value(aic31xx->gpio_reset, 1);
>
> regcache_mark_dirty(aic31xx->regmap);
> dev_dbg(aic31xx->dev, "## %s: DISABLE received\n", __func__);
> @@ -1073,8 +1074,8 @@ static int aic31xx_power_on(struct snd_soc_codec *codec)
> if (ret)
> return ret;
>
> - if (gpio_is_valid(aic31xx->pdata.gpio_reset)) {
> - gpio_set_value(aic31xx->pdata.gpio_reset, 1);
> + if (aic31xx->gpio_reset) {
> + gpiod_set_value(aic31xx->gpio_reset, 0);
> udelay(100);
> }
> regcache_cache_only(aic31xx->regmap, false);
> @@ -1334,15 +1335,11 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c,
> else if (aic31xx->dev->of_node)
> aic31xx_pdata_from_of(aic31xx);
>
> - if (aic31xx->pdata.gpio_reset) {
> - ret = devm_gpio_request_one(aic31xx->dev,
> - aic31xx->pdata.gpio_reset,
> - GPIOF_OUT_INIT_HIGH,
> - "aic31xx-reset-pin");
> - if (ret < 0) {
> - dev_err(aic31xx->dev, "not able to acquire gpio\n");
> - return ret;
> - }
> + aic31xx->gpio_reset = devm_gpiod_get_optional(aic31xx->dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(aic31xx->gpio_reset)) {
> + dev_err(aic31xx->dev, "not able to acquire gpio\n");
> + return PTR_ERR(aic31xx->gpio_reset);
> }
>
> for (i = 0; i < ARRAY_SIZE(aic31xx->supplies); i++)
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Fix dm814x missing phy-cells property
From: Tony Lindgren @ 2017-12-04 16:27 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171204162718.11222-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
We have phy-cells for usb_phy0, but it's missing for usb_phy1 and we get:
Warning (phys_property): Missing property '#phy-cells' in node
/ocp/l4ls@48000000/control@140000/usb-phy@1b00 or bad phandle
(referred from /ocp/usb@47400000/usb@47401800:phys[0])
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/dm814x.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -386,6 +386,7 @@
reg = <0x1b00 0x100>;
reg-names = "phy";
ti,ctrl_mod = <&usb_ctrl_mod>;
+ #phy-cells = <0>;
};
};
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] ARM: dts: Fix elm interrupt compiler warning
From: Tony Lindgren @ 2017-12-04 16:27 UTC (permalink / raw)
To: linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA
Looks like the interrupt property is missing the controller and level
information causing:
Warning (interrupts_property): interrupts size is (4), expected multiple
of 12 in /ocp/elm@48078000
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -398,7 +398,7 @@
elm: elm@48078000 {
compatible = "ti,am3352-elm";
reg = <0x48078000 0x2000>;
- interrupts = <4>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "elm";
status = "disabled";
};
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 4/7] OF: properties: Implement get_match_data() callback
From: Rob Herring @ 2017-12-04 16:23 UTC (permalink / raw)
To: Sinan Kaya
Cc: open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM, Timur Tabi,
devicetree@vger.kernel.org, linux-arm-msm,
linux-arm-kernel@lists.infradead.org, Frank Rowand, open list
In-Reply-To: <1512188864-773-5-git-send-email-okaya@codeaurora.org>
On Fri, Dec 1, 2017 at 10:27 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Now that we have a get_match_data() callback as part of the firmware node,
> implement the OF specific piece for it.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/of/property.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 264c355..adcde1a 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -981,6 +981,22 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> return 0;
> }
>
> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
> + const struct device_driver *drv)
> +{
> + const struct device_node *node = to_of_node(fwnode);
> + const struct of_device_id *match;
> +
> + if (!node)
> + return NULL;
of_match_node checks this.
> +
> + match = of_match_node(drv->of_match_table, node);
> + if (!match)
> + return NULL;
> +
> + return (void *)match->data;
Don't need a cast here.
of_device_get_match_data() already does most of this, but getting a
device ptr from fwnode_handle may not be possible?
Rob
^ permalink raw reply
* Re: [PATCH v4.1] phylib: Add device reset GPIO support
From: Richard Leitner @ 2017-12-04 16:20 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Andrew Lunn,
Florian Fainelli, Simon Horman, Magnus Damm
Cc: Sergei Shtylyov, Rob Herring, Mark Rutland, Nicolas Ferre, netdev,
devicetree, linux-renesas-soc, linux-kernel
In-Reply-To: <1512390905-28094-1-git-send-email-geert+renesas@glider.be>
On 12/04/2017 01:35 PM, Geert Uytterhoeven wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> The PHY devices sometimes do have their reset signal (maybe even power
> supply?) tied to some GPIO and sometimes it also does happen that a boot
> loader does not leave it deasserted. So far this issue has been attacked
> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
> the GPIO in question; that solution, when applied to the device trees, led
> to adding the PHY reset GPIO properties to the MAC device node, with one
> exception: Cadence MACB driver which could handle the "reset-gpios" prop
> in a PHY device subnode. I believe that the correct approach is to teach
> the 'phylib' to get the MDIO device reset GPIO from the device tree node
> corresponding to this device -- which this patch is doing...
>
> Note that I had to modify the AT803x PHY driver as it would stop working
> otherwise -- it made use of the reset GPIO for its own purposes...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Acked-by: Rob Herring <robh@kernel.org>
> [geert: Propagate actual errors from fwnode_get_named_gpiod()]
> [geert: Avoid destroying initial setup]
> [geert: Consolidate GPIO descriptor acquiring code]
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Successfully tested this patch on a i.MX6SOLO based board containing a
LAN8710 PHY:
Tested-by: Richard Leitner <richard.leitner@skidata.com>
^ permalink raw reply
* [PATCH v13 5/5] dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver
From: Andrey Smirnov @ 2017-12-04 16:11 UTC (permalink / raw)
To: Lee Jones
Cc: Andrey Smirnov, linux-kernel, devicetree, linux-watchdog, cphealy,
Lucas Stach, Nikita Yushchenko, Greg Kroah-Hartman, Pavel Machek,
Andy Shevchenko, Guenter Roeck, Rob Herring, Johan Hovold,
Mark Rutland, Sebastian Reichel
In-Reply-To: <20171204161118.19558-1-andrew.smirnov@gmail.com>
Add Device Tree bindings for RAVE SP watchdog drvier - an MFD cell of
parent RAVE SP driver (documented in
Documentation/devicetree/bindings/mfd/zii,rave-sp.txt).
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: cphealy@gmail.com
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
.../bindings/watchdog/zii,rave-sp-wdt.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
new file mode 100644
index 000000000000..ab16659e781d
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
@@ -0,0 +1,39 @@
+Zodiac Inflight Innovations RAVE Supervisory Processor Watchdog Bindings
+
+RAVE SP watchdog device is a "MFD cell" device corresponding to
+watchdog functionality of RAVE Supervisory Processor. It is expected
+that its Device Tree node is specified as a child of the node
+corresponding to the parent RAVE SP device (as documented in
+Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
+
+Required properties:
+- compatible: Should be "zii,rave-sp-watchdog"
+
+Optional properties:
+
+- wdt-timeout: Two byte nvmem cell specified as per
+ Documentation/devicetree/bindings/nvmem/nvmem.txt
+
+Example:
+
+ rave-sp {
+ compatible = "zii,rave-sp-rdu1";
+ current-speed = <38400>;
+
+ eeprom {
+ compatible = "zii,pic-main-eeprom";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ wdt_timeout: wdt-timeout@8E {
+ reg = <0x8E 2>;
+ };
+ };
+
+ watchdog {
+ compatible = "zii,rave-sp-watchdog";
+ nvmem-cells = <&wdt_timeout>;
+ nvmem-cell-names = "wdt-timeout";
+ };
+ }
+
--
2.14.3
^ permalink raw reply related
* [PATCH v13 0/5] ZII RAVE platform driver
From: Andrey Smirnov @ 2017-12-04 16:11 UTC (permalink / raw)
To: Lee Jones
Cc: Andrey Smirnov, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Guenter Roeck, Rob Herring, Mark Rutland,
Johan Hovold, devicetree-u79uwXL29TY76Z2rM5mHXA,
Sebastian Reichel
Lee:
This patch set has been marinating out there for a while now and
yours, I belive, is that last signature I need to start pushing it for
inclusion. I'd really appreciate if you could spare some of your time
to give it a look. Thanks!
Everyone:
This patch series is v13 of the driver for supervisory processor found
on RAVE series of devices from ZII. Supervisory processor is a PIC
microcontroller connected to various electrical subsystems on RAVE
devices whose firmware implements protocol to command/qery them.
NOTE:
* This driver dependends on crc_ccitt_false(), added by
2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
was pulled in by Andrew Morton and is currently avaiting users, so
this series might have to go in through Andrew's tree
Changes since [v12]:
- Minor comment inconsistencies fixes in rave-sp.c
Changes since [v11]:
- Fix incorrect include in rave-sp-wdt.c as uncoverd by kernel
test robot
Changes since [v10]:
- Collected Acked-by from Rob and Reviewed-by from Guenter
- Incorporated watchdog driver feedback from Gunter and Johan
- Incorporated Johan's feedback for the rest of the code
Changes since [v9]:
- Converted watchdog driver to use watchdog_active() instead of
watchdog_hw_running() and replaced WARN_ON with a regular error
message as per feedback from Guenter
- Changed rave_sp_wdt_start() to set WDOG_HW_RUNNING only if
communicating with hardware was sucessful
- Collected Reviewd-by from Sebastian (for serdev related patches)
- Collected Acked-by from Rob (for watchdog DT bindings)
Changes since [v8]:
- Driver moved from drivers/platform to drivers/mfd
- Collected Reviewed-by from Guenter (for patches 1, 2 and 3)
- Incorporated feedback from Guenter into watchdog driver
- Incorporated feedback from Rob into watchdog DT bindings
- Removed struct rave_sp_rsp_status, which was a leftover from v5
-> v6 code removal.
- Fixed minor problems reported by checkpatch
Changes since [v7]:
- Added watchdog driver to the patchset, so it would be easier to
understand how parent/children drivers are tied together
- Added serdev patches to implement devm_serdev_device_open() and make .remove optional
- "Added" missing serdev_device_close() by converting the driver
to use devm_serdev_device_open()
- Converted the driver to use devm_of_platform_populate()
- Removed needless dependency on MFD_CORE
- Removed dependency on SERIAL_DEV_CTRL_TTYPORT
Changes since [v6]:
- Patch 2/2 has been applied by Lee so it is no longer a part of the series
- Removed all sysfs and debugfs attribute to reduce the scope of
the driver propsed for inclusion. This is not a critical to have
feature and can be added/discussed later.
Changes since [v5]:
- Fixed a build break, introduced by a last minute change in [v5]
- Moved majority of attributes that were exposed over sysfs to debugfs
- Document remaining sysfs attributes in Documentation/ABI/testing/sysfs-platform-rave-sp
Changes since [v4]:
- Replaced usage of DEVICE_ATTR with DEVICE_ATTR_RW
- Fixed a number of warnings produces by sparse tool
- Incorporated event more feedback from Andy Shevchenko
- Collected Reviewed-by from Andy
Changes since [v3]:
- Re-collected lost Acked-by from Rob
- Incorporated further feedback from Andy Shevchenko
- Dropped useless change (stray newline) to drivers/mfd/Makefile
Changes since [v2]:
- Fixed swapped command codes in rave_sp_common_get_boot_source()
and rave_sp_common_set_boot_source() revealed by further testing
of the code
- Incorporated feedback from Andy Shevchenko
Changes since [v1]:
- Updated wording in DT-bindings as per Rob's request.
- Collected Rob's Acked-by for patch 2/2
Feedback is greatly appreciated!
Thanks,
Andrey Smirnov
[v12] lkml.kernel.org/r/20171109160556.17018-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v11] lkml.kernel.org/r/20171106152935.16920-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v10] lkml.kernel.org/r/20171031163656.24552-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v9] lkml.kernel.org/r/20171025190421.18415-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v8] lkml.kernel.org/r/20171018170136.12347-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v7] lkml.kernel.org/r/20171013061321.31252-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v6] lkml.kernel.org/r/20170828163131.24815-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v5] lkml.kernel.org/r/20170728142704.11156-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v4] lkml.kernel.org/r/20170725184450.13171-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Andrey Smirnov (5):
serdev: Make .remove in struct serdev_device_driver optional
serdev: Introduce devm_serdev_device_open()
mfd: Add driver for RAVE Supervisory Processor
watchdog: Add RAVE SP watchdog driver
dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver
.../bindings/watchdog/zii,rave-sp-wdt.txt | 39 ++
Documentation/driver-model/devres.txt | 3 +
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 2 +
drivers/mfd/rave-sp.c | 660 +++++++++++++++++++++
drivers/tty/serdev/core.c | 31 +-
drivers/watchdog/Kconfig | 7 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/rave-sp-wdt.c | 357 +++++++++++
include/linux/mfd/rave-sp.h | 56 ++
include/linux/serdev.h | 1 +
11 files changed, 1164 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
create mode 100644 drivers/mfd/rave-sp.c
create mode 100644 drivers/watchdog/rave-sp-wdt.c
create mode 100644 include/linux/mfd/rave-sp.h
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] Move DP phy switch to PHY driver
From: Doug Anderson @ 2017-12-04 16:08 UTC (permalink / raw)
To: Heiko Stübner
Cc: Mark Rutland, David Airlie, Catalin Marinas, Shawn Lin,
Will Deacon, Kever Yang, dri-devel, Guenter Roeck, Chris Zhong,
Brian Norris, Kishon Vijay Abraham I,
open list:ARM/Rockchip SoC..., Jianqun Xu, Caesar Wang,
devicetree, Elaine Zhang, Rob Herring, William wu, Linux ARM,
LKML, Tomasz Figa, David Wu,
Enric Balletbo i Serra <enric.balletb>
In-Reply-To: <4091462.xo23GTqF41@diego>
Hi,
On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner <heiko@sntech.de> wrote:
> Hi Chris,
>
> Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
>> On 2017年12月02日 05:58, Heiko Stuebner wrote:
>> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
>> >> Hi,
>> >>
>> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong <zyw@rock-chips.com> wrote:
>> >>> Hi Doug
>> >>>
>> >>> Thank you for mentioning this patch.
>> >>>
>> >>> I think the focus of the discussion is: can we put the grf control bit
>> >>> to
>> >>> dts.
>> >>>
>> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
>> >>> "uphy_dp_sel"
>> >>>
>> >>> can help to switch these 2 phy. So I think this bit can be considered as
>> >>> a
>> >>> part of
>> >>>
>> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
>> >>> (such as "pipe-status").
>> >>>
>> >>> Put them to DTS file might be a accepted practice.
>> >>
>> >> I guess the first step would be finding the person to make a decision.
>> >> Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few
>> >> options:
>> >>
>> >> 1. Land this series as-is. This makes the new bit work just like all
>> >> the other ones next to it. If anyone happens to try to use an old
>> >> device tree on a new kernel they'll break. Seems rather unlikely
>> >> given that the whole type C PHY is not really fully functional
>> >> upstream, but technically this is a no-no from a device tree
>> >> perspective.
>> >>
>> >> 2. Change the series to make this property optional. If it's not
>> >> there then the code behaves like it always did. This would address
>> >> the "compatibility" problem but likely wouldn't actually help any real
>> >> people, and it would be extra work.
>> >>
>> >> 3. Redo the driver to deprecate all the old offsets / bits and just
>> >> put the table in the driver, keyed off the compatible string and base
>> >> address if the IO memory.
>> >>
>> >>
>> >> I can't make this decision. It's up to those folks who would be
>> >> landing the patch and I'd be happy with any of them. What I'm less
>> >> happy with, however, is the indecision preventing forward progress.
>> >> We should pick one of the above things and land it. My own personal
>> >> bias is #1: just land the series. No real people will be hurt and
>> >> it's just adding another property that matches the ones next to it.
>> >
>> > I'd second that #1 . That whole type-c phy thingy never fully worked in
>> > the past (some for the never used dp output), so personally I don't have
>> > issues with going that route.
>> >
>> >> From a long term perspective (AKA how I'd write the next driver like
>> >>
>> >> this) I personally lean towards to "tables in the driver, not in the
>> >> device tree" but quite honestly I'm happy to take whatever direction
>> >> the maintainers give.
>> >
>> > It looks like we're in agreement here :-) . GRF stuff should not leak into
>> > the devicetree, as it causes endless headaches later. But I guess we'll
>> > need to live with the ones that happened so far.
>>
>> So, the first step is: move all the private property of tcphy to
>> drivers/phy/rockchip/phy-rockchip-typec.c.
>> Second step: new a member: uphy-dp-sel.
>> In my mind, we should have discussed these properties before, and then I
>> moved them all into DTS.
>
> Actually, I was agreeing with Doug, that we probably don't need to rework the
> type-c phy driver. As most properties for it are in the devicetree right now
> we'll need to support them for backwards-compatiblity anyway.
>
> And yes, there probably was discussion over dts vs. driver-table when the
> type-c driver was introduced, but I either missed it or wasn't firm enough
> back then ;-) .
>
> Hence the "we'll need to live with it" for the type-c phy, but should not
> do similar things in future drivers.
So I guess now we're just waiting for some agreement from Kishon that
he's willing to land the PHY change? Heiko: presumably you could
apply the DP change to drm-misc? ...or is there some other process
needed there?
-Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Timur Tabi @ 2017-12-04 15:49 UTC (permalink / raw)
To: Adam Wallis, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Matthias Brugger, Mathias Nyman, Chunfeng Yun,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <2b252975-bf1f-7468-071e-f4a4aa2430a0-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 12/04/2017 09:48 AM, Adam Wallis wrote:
> As noted in the patch description, xhci-plat devices will use a default of
> 40,000, while MTK devices will use a default of 5,000. This is also documented
> in the probe for each relevant driver. This is further confirmed in the
> description for each driver's binding TXT file.
Serves me right for reviewing patches before I've had my morning coffee.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-04 15:48 UTC (permalink / raw)
To: Timur Tabi, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Matthias Brugger, Mathias Nyman, Chunfeng Yun,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <9cb2e5fc-1bec-c19c-c04e-fe56e5c1bc16-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Timur
On 12/4/2017 9:58 AM, Timur Tabi wrote:
> On 12/4/17 8:27 AM, Adam Wallis wrote:
>> If no interval is specified, the default of 40,000ns (IMOD=160) will be
>> used.
>
> ...
>
>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>
> ...
>
>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>
> ...
>
>> + xhci->imod_interval = 5000;
>
> ...
>
>> + xhci->imod_interval = 40000;
>
> ...
>
>> + xhci->imod_interval = 40000;
>
> Is the default 5,000 or 40,000? I can't tell.
>
As noted in the patch description, xhci-plat devices will use a default of
40,000, while MTK devices will use a default of 5,000. This is also documented
in the probe for each relevant driver. This is further confirmed in the
description for each driver's binding TXT file.
Adam
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/2] of: overlay: Fix cleanup order in of_overlay_apply()
From: Geert Uytterhoeven @ 2017-12-04 15:47 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand
Cc: Colin King, Dan Carpenter, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <1512402456-8176-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
The special overlay mutex is taken first, hence it should be released
last in the error path.
Move "mutex_lock(&of_mutex)" up, as suggested by Frank, as
free_overlay_changeset() should be called with that mutex held if any
non-trivial cleanup is to be done.
Merge the two tail statements of the success and error paths, now they
became identical.
Fixes: f948d6d8b792bb90 ("of: overlay: avoid race condition between applying multiple overlays")
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
This is v2 of commit bd80e2555c5c9d45 ("of: overlay: Fix cleanup order
in of_overlay_apply()"), which was dropped by Rob.
---
drivers/of/overlay.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 312cd658bec0083b..0ddb7748ac85498f 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -705,12 +705,11 @@ int of_overlay_apply(struct device_node *tree, int *ovcs_id)
}
of_overlay_mutex_lock();
+ mutex_lock(&of_mutex);
ret = of_resolve_phandles(tree);
if (ret)
- goto err_overlay_unlock;
-
- mutex_lock(&of_mutex);
+ goto err_free_overlay_changeset;
ret = init_overlay_changeset(ovcs, tree);
if (ret)
@@ -754,17 +753,13 @@ int of_overlay_apply(struct device_node *tree, int *ovcs_id)
ret = ret_tmp;
}
- mutex_unlock(&of_mutex);
- of_overlay_mutex_unlock();
-
- goto out;
+ goto out_unlock;
err_free_overlay_changeset:
free_overlay_changeset(ovcs);
+out_unlock:
mutex_unlock(&of_mutex);
-
-err_overlay_unlock:
of_overlay_mutex_unlock();
out:
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/2] of: overlay: Fix memory leak in of_overlay_apply() error path
From: Geert Uytterhoeven @ 2017-12-04 15:47 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand
Cc: Colin King, Dan Carpenter, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <1512402456-8176-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
If of_resolve_phandles() fails, free_overlay_changeset() is called in
the error path. However, that function returns early if the list hasn't
been initialized yet, before freeing the object.
Explicitly calling kfree() instead would solve that issue. However, that
complicates matter, by having to consider which of two different methods
to use to dispose of the same object.
Hence make free_overlay_changeset() consider initialization state of the
different parts of the object, making it always safe to call (once!) to
dispose of a (partially) initialized overlay_changeset:
- Only destroy the changeset if the list was initialized,
- Ignore uninitialized IDs (zero).
Reported-by: Colin King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Fixes: f948d6d8b792bb90 ("of: overlay: avoid race condition between applying multiple overlays")
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
drivers/of/overlay.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 3b7a3980ff50d6bf..312cd658bec0083b 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -630,11 +630,10 @@ static void free_overlay_changeset(struct overlay_changeset *ovcs)
{
int i;
- if (!ovcs->cset.entries.next)
- return;
- of_changeset_destroy(&ovcs->cset);
+ if (ovcs->cset.entries.next)
+ of_changeset_destroy(&ovcs->cset);
- if (ovcs->id)
+ if (ovcs->id > 0)
idr_remove(&ovcs_idr, ovcs->id);
for (i = 0; i < ovcs->count; i++) {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/2] of: overlay: Fix of_overlay_apply() error path
From: Geert Uytterhoeven @ 2017-12-04 15:47 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand
Cc: Colin King, Dan Carpenter, devicetree, linux-kernel,
Geert Uytterhoeven
Hi Pantelis, Rob, Frank,
Here's a replacement for commit bd80e2555c5c9d45 ("of: overlay: Fix
cleanup order in of_overlay_apply()"), which was applied by Rob, and
dropped later.
The first patch fixes the memory leak reported by Colin.
The second patch is a replacement for the bad dropped commit, and
depends on the first patch for proper cleanup.
All OF unittests pass.
Thanks!
Geert Uytterhoeven (2):
of: overlay: Fix memory leak in of_overlay_apply() error path
of: overlay: Fix cleanup order in of_overlay_apply()
drivers/of/overlay.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 1/1] at24: support eeproms that do not auto-rollover reads.
From: Sven Van Asbroeck @ 2017-12-04 15:36 UTC (permalink / raw)
To: svendev, robh+dt, mark.rutland, wsa, brgl, nsekhar, sakari.ailus,
david, javier, divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c, Sven Van Asbroeck
In-Reply-To: <1512401778-20366-1-git-send-email-svendev@arcx.com>
From: Sven Van Asbroeck <svenv@arcx.com>
Some multi-address eeproms in the at24 family may not automatically
roll-over reads to the next slave address. On those eeproms, reads
that straddle slave boundaries will not work correctly.
Solution:
Mark such eeproms with a flag that prevents reads straddling
slave boundaries. Add the AT24_FLAG_NO_RDROL flag to the eeprom
entry in the device_id table, or add 'no-read-rollover' to the
eeprom devicetree entry.
Note that I have not personally enountered an at24 chip that
does not support read rollovers. They may or may not exist.
However, my hardware requires this functionality because of
a quirk.
It's up to the Linux community to decide if this patch is useful/
general enough to warrant merging.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
---
.../devicetree/bindings/eeprom/eeprom.txt | 5 +++
drivers/misc/eeprom/at24.c | 37 +++++++++++++++-------
include/linux/platform_data/at24.h | 2 ++
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 27f2bc1..a1764f8 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -38,6 +38,11 @@ Optional properties:
- size: total eeprom size in bytes
+ - no-read-rollover: supported on the at24 eeprom family only.
+ This parameterless property indicates that the multi-address
+ eeprom does not automatically roll over reads to the next
+ slave address. Please consult the manual of your device.
+
Example:
eeprom@52 {
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 625b001..33bca28 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -251,15 +251,6 @@ struct at24_data {
* Slave address and byte offset derive from the offset. Always
* set the byte address; on a multi-master board, another master
* may have changed the chip's "current" address pointer.
- *
- * REVISIT some multi-address chips don't rollover page reads to
- * the next slave address, so we may need to truncate the count.
- * Those chips might need another quirk flag.
- *
- * If the real hardware used four adjacent 24c02 chips and that
- * were misconfigured as one 24c08, that would be a similar effect:
- * one "eeprom" file not four, but larger reads would fail when
- * they crossed certain pages.
*/
static struct at24_client *at24_translate_offset(struct at24_data *at24,
unsigned int *offset)
@@ -277,6 +268,28 @@ static struct at24_client *at24_translate_offset(struct at24_data *at24,
return &at24->client[i];
}
+static size_t at24_adjust_read_count(struct at24_data *at24,
+ unsigned int offset, size_t count)
+{
+ unsigned int bits;
+ size_t remainder;
+ /*
+ * In case of multi-address chips that don't rollover reads to
+ * the next slave address: truncate the count to the slave boundary,
+ * so that the read never straddles slaves.
+ */
+ if (at24->chip.flags & AT24_FLAG_NO_RDROL) {
+ bits = (at24->chip.flags & AT24_FLAG_ADDR16) ? 16 : 8;
+ remainder = BIT(bits) - offset;
+ if (count > remainder)
+ count = remainder;
+ }
+ if (count > io_limit)
+ count = io_limit;
+
+ return count;
+}
+
static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
unsigned int offset, size_t count)
{
@@ -289,9 +302,7 @@ static ssize_t at24_regmap_read(struct at24_data *at24, char *buf,
at24_client = at24_translate_offset(at24, &offset);
regmap = at24_client->regmap;
client = at24_client->client;
-
- if (count > io_limit)
- count = io_limit;
+ count = at24_adjust_read_count(at24, offset, count);
/* adjust offset for mac and serial read ops */
offset += at24->offset_adj;
@@ -457,6 +468,8 @@ static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
if (device_property_present(dev, "read-only"))
chip->flags |= AT24_FLAG_READONLY;
+ if (device_property_present(dev, "no-read-rollover"))
+ chip->flags |= AT24_FLAG_NO_RDROL;
err = device_property_read_u32(dev, "size", &val);
if (!err)
diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
index 271a4e2..841bb28 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -50,6 +50,8 @@ struct at24_platform_data {
#define AT24_FLAG_TAKE8ADDR BIT(4) /* take always 8 addresses (24c00) */
#define AT24_FLAG_SERIAL BIT(3) /* factory-programmed serial number */
#define AT24_FLAG_MAC BIT(2) /* factory-programmed mac address */
+#define AT24_FLAG_NO_RDROL BIT(1) /* does not auto-rollover reads to */
+ /* the next slave address */
void (*setup)(struct nvmem_device *nvmem, void *context);
void *context;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/1] at24: support eeproms that do not auto-rollover reads.
From: Sven Van Asbroeck @ 2017-12-04 15:36 UTC (permalink / raw)
To: svendev, robh+dt, mark.rutland, wsa, brgl, nsekhar, sakari.ailus,
david, javier, divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c, Sven Van Asbroeck
From: Sven Van Asbroeck <svenv@arcx.com>
v3:
rebased against at24 maintainer's devel staging branch:
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git at24/devel
clarified some of the comments and wording
v2:
kbuild test robot feedback: correct
"warning: comparison of distinct pointer types lacks a cast"
build warning on some compilers / architectures.
v1:
original patch
Sven Van Asbroeck (1):
at24: support eeproms that do not auto-rollover reads.
.../devicetree/bindings/eeprom/eeprom.txt | 5 +++
drivers/misc/eeprom/at24.c | 37 +++++++++++++++-------
include/linux/platform_data/at24.h | 2 ++
3 files changed, 32 insertions(+), 12 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-04 15:31 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Crt Mori
Add device tree bindings for MLX90632 IR temperature sensor.
Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
new file mode 100644
index 000000000000..0b05812001f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
@@ -0,0 +1,28 @@
+* Melexis MLX90632 contactless Infra Red temperature sensor
+
+Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+There are various applications for the Infra Red contactless temperature sensor
+and MLX90632 is most suitable for consumer applications where measured object
+temperature is in range between -20 to 200 degrees Celsius with relative error
+of measurement below 1 degree Celsius in object temperature range for
+industrial applications. Since it can operate and measure ambient temperature
+in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
+
+Be aware that electronics surrounding the sensor can increase ambient
+temperature. MLX90632 can be calibrated to reduce the housing effect via
+already existing EEPROM parameters.
+
+Since measured object emissivity effects Infra Red energy emitted, emissivity
+should be set before requesting the object temperature.
+
+Required properties:
+ - compatible: should be "melexis,mlx90632"
+ - reg: the I2C address of the sensor (default 0x3a)
+
+Example:
+
+mlx90632@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+};
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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