* Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Belisko Marek @ 2013-12-10 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131111233152.GR15154@atomide.com>
Hi Tony,
On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Belisko Marek <marek.belisko@gmail.com> [131111 14:01]:
>> Hi Tony,
>>
>> On Mon, Nov 11, 2013 at 5:49 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Marek Belisko <marek@goldelico.com> [131014 14:11]:
>> >> devconf1 reg access is localized only in mach-omap2 and we need to export
>> >> updating of devconf1 from omapdss venc driver (bypass and acbias bits).
>> >> Add simple api call which update only necessary bits.
>> > ...
>> >
>> >> +void update_bypass_acbias(bool bypass, bool acbias)
>> >> +{
>> >> +#ifdef CONFIG_ARCH_OMAP3
>> >> + int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
>> >> +
>> >> + if (bypass)
>> >> + val |= OMAP2_TVOUTBYPASS;
>> >> + else
>> >> + val &= ~OMAP2_TVOUTBYPASS;
>> >> +
>> >> + if (acbias)
>> >> + val |= OMAP2_TVACEN;
>> >> + else
>> >> + val &= ~OMAP2_TVACEN;
>> >> +
>> >> + omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
>> >> +#endif
>> >
>> > If this is truly a pinmux, you could already access this
>> > using pinctrl-single,bits device tree driver.
>> >
>> > But I guess that won't work yet, so it's best to set this
>> > up as a separate driver like we've done for the USB PHY
>> > registers.
>>
>> Can you please point me to that driver directly? I cannot see benefit
>> of new driver as as it will be only dummy driver
>> with export_symbol_gpl of upper function. Can it sit then in dss
>> directory or somewhere else? Thanks.
>
> You can take a look at drivers/usb/phy/phy-omap-control.c.
>
> Then there's a device tree using example for control_devconf0 in
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.
>
> Looks like CONTROL_DEVCONF1 contains a bunch of misc registers,
> and arch/arm/mach-omap2/hsmmc.c seems to be tinkering with it too.
>
> It would be best to set it up as omap-ctrl.c driver under drivers
> somewhere with few functions exported for DSS and MMC drivers.
I create small dummy driver based on phy-omap-control which can be
used but before sending patch (with more updates) I would like to get
some feedback if my direction is correct.
diff --git a/drivers/misc/omap-ctrl.c b/drivers/misc/omap-ctrl.c
new file mode 100644
index 0000000..ca2e576
--- /dev/null
+++ b/drivers/misc/omap-ctrl.c
@@ -0,0 +1,84 @@
+/*
+ * omap-ctrl.c - The part of omap control module.
+ *
+ * Copyright (C) 2013 Goldelico GmbH
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Marek Belisko <marek@goldelico.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+
+static u32 __iomem *devconf1;
+
+void omap_ctrl_tvoutbypass(int on)
+{
+ int val = readl(devconf1);
+
+ if (on)
+ val |= BIT(18);
+ else
+ val &= ~BIT(18);
+
+ writel(val, devconf1);
+}
+EXPORT_SYMBOL_GPL(omap_ctrl_tvoutbypass);
+
+
+void omap_ctrl_acen(int on)
+{
+ int val = readl(devconf1);
+
+ if (on)
+ val |= BIT(11);
+ else
+ val &= ~BIT(11);
+
+ writel(val, devconf1);
+}
+EXPORT_SYMBOL_GPL(omap_ctrl_acen);
+
+
+static int omap_ctrl_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "devconf1");
+ devconf1 = devm_ioremap_resource(
+ &pdev->dev, res);
+ if (IS_ERR(devconf1))
+ return PTR_ERR(devconf1);
+
+ return 0;
+}
+
+struct platform_driver omap_ctrl_driver = {
+ .probe = omap_ctrl_probe,
+ .driver = {
+ .name = "omap-ctrl",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_ctrl_init(void)
+{
+ return platform_driver_register(&omap_ctrl_driver);
+}
+subsys_initcall(omap_ctrl_init);
+
+static void __exit omap_ctrl_exit(void)
+{
+ platform_driver_unregister(&omap_ctrl_driver);
+}
I use that driver with platform device in board file with proper
resources and it works fine. It could be easily added also DT
bindings.
Also you mention somewhere in drivers (but I think misc isn't right
place for that). Any opinion on that? Thanks for feedback.
>
> The reason why it should be a separate driver is that the system
> control module can live a separate runtime PM life from the
> drivers using the CONTROL_DEVCONF register bits.
>
> Regards,
>
> Tony
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply related
* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
From: Tomi Valkeinen @ 2013-12-10 12:18 UTC (permalink / raw)
To: florian.vaussard, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
In-Reply-To: <52A1A492.8090205@epfl.ch>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 2013-12-06 12:18, Florian Vaussard wrote:
> Hello Tomi,
>
> On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
>> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
>> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
>> it as a test.
>>
>
> Looking at the schematics, both seem pretty similar indeed. The main
> difference seems to be the LCD on the palo43, and the HDMI on the Tobi
> (TFP410, as in your patch 21).
>
> I only have a Tobi on my desk, so this is the reason for not supporting
> other boards... We could make a .dtsi with common stuff, then add the
> LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
> support to these boards in the coming days, so I can add this too, at
> least for testing purpose.
I think I'll just drop this patch, as I haven't been able to boot my
overo with nfs root for some time. I don't know if it's my pc or the
board or the kernel, but for some reason the usb gadget ethernet refuses
to work.
If you want to update the tobi.dts for the proper DT data, I'm happy to
include the patch to my series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-12-10 12:10 UTC (permalink / raw)
To: Enric Balletbo Serra, Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CAFqH_517U6vUz7adwaF4h78wvvwPf3v0CYMw93_aFY7_=an1Xg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
On 2013-12-10 12:56, Enric Balletbo Serra wrote:
> Hi all,
>
> 2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>>> Hi Tomi,
>>>>
>>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>>
>>>>>>> + tfp410: encoder@0 {
>>>>>>> + compatible = "ti,tfp410";
>>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>>> +
>>>>>>
>>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>>> numbers, i.e:
>>>>>>
>>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>>
>>>>> Thanks, fixed now (for all .dts files)
>>>>>
>>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>>
>>>>
>>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>>> GPIO_ACTIVE_HIGH as 0.
>>>>
>>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>>> signal inverter but that is a special case. I don't know about the
>>>> Panda board since I haven't looked at its datasheet.
>>>
>>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>>> as it were active-low. The flag is ignored.
>>>
>>
>> How weird, it does work on the IGEPv2 but you are right I just looked
>> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
>> that it indeed just does:
>>
>> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
>> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>>
>> So I don't know how it is working... I'm on the road and won't have
>> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
>> light on this.
>>
>
> On IGEPv2 the GPIO that controls the power-down pin is connected
> through a dual/buffer driver [1]. This driver is only a buffer, not
> inverts the signal (I had told you wrong, sorry Javier ), so the pin
> continues being active low.
>
> As both of you pointed the driver ignores the flag to handle the PD
> GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
> or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
> display for IGEP, to be coherent, the gpio should be defined as
> GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
> works.
>
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
> b/arch/arm/boot/dts/omap3-igep0020.dts
> index 2569d60..d185e06 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -233,7 +233,7 @@
>
> tfp410: encoder@0 {
> compatible = "ti,tfp410";
> - gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
> + gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
>
> ports {
> #address-cells = <1>;
>
>
> [1] http://www.ti.com/product/sn74lvc2g07
Ok, looks good. I have changed the TFP gpios to active-low in my series
for all .dts files, which includes the igep0020.dts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Personal Loan
From: ''Hyde Finance Loan Company'' @ 2013-12-10 11:22 UTC (permalink / raw)
To: Recipients
Loans available at 3%.Contact us for more info if interested.Serious minded only.Contact us Via Email: hydenance@gmail.com
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Enric Balletbo Serra @ 2013-12-10 10:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Tomi Valkeinen, linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CABxcv==2TS00WJduP0EUCmOgLT9x-qzTO+GzyE=R+yooGAmPEA@mail.gmail.com>
Hi all,
2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>> Hi Tomi,
>>>
>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>
>>>>>> + tfp410: encoder@0 {
>>>>>> + compatible = "ti,tfp410";
>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>> +
>>>>>
>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>> numbers, i.e:
>>>>>
>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>
>>>> Thanks, fixed now (for all .dts files)
>>>>
>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>
>>>
>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>> GPIO_ACTIVE_HIGH as 0.
>>>
>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>> signal inverter but that is a special case. I don't know about the
>>> Panda board since I haven't looked at its datasheet.
>>
>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>> as it were active-low. The flag is ignored.
>>
>
> How weird, it does work on the IGEPv2 but you are right I just looked
> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
> that it indeed just does:
>
> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>
> So I don't know how it is working... I'm on the road and won't have
> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
> light on this.
>
On IGEPv2 the GPIO that controls the power-down pin is connected
through a dual/buffer driver [1]. This driver is only a buffer, not
inverts the signal (I had told you wrong, sorry Javier ), so the pin
continues being active low.
As both of you pointed the driver ignores the flag to handle the PD
GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
display for IGEP, to be coherent, the gpio should be defined as
GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
works.
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 2569d60..d185e06 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -233,7 +233,7 @@
tfp410: encoder@0 {
compatible = "ti,tfp410";
- gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
+ gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
ports {
#address-cells = <1>;
[1] http://www.ti.com/product/sn74lvc2g07
Best regards,
Enric
>> Tomi
>>
>>
>
> Thanks a lot and best regards,
> Javier
^ permalink raw reply related
* [PATCH v4 1/5] PCI: pcibus address to resource converting take bus instead of dev
From: Yinghai Lu @ 2013-12-10 6:54 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Guo Chao, linux-pci, linux-kernel, Yinghai Lu, linux-alpha,
linuxppc-dev, sparclinux, linux-pcmcia, linux-scsi, linux-fbdev
In-Reply-To: <1386658484-15774-1-git-send-email-yinghai@kernel.org>
For allocating resource under bus path, we do not have dev to pass along,
and we only have bus to use instead.
-v2: drop pcibios_bus_addr_to_resource().
-v3: drop __* change requested by Bjorn.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: linux-alpha@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparclinux@vger.kernel.org
Cc: linux-pcmcia@lists.infradead.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
---
arch/alpha/kernel/pci-sysfs.c | 4 ++--
arch/powerpc/kernel/pci-common.c | 4 ++--
arch/powerpc/kernel/pci_of_scan.c | 4 ++--
arch/sparc/kernel/pci.c | 6 +++---
drivers/pci/host-bridge.c | 24 +++++++++++-------------
drivers/pci/probe.c | 18 +++++++++---------
drivers/pci/quirks.c | 2 +-
drivers/pci/rom.c | 2 +-
drivers/pci/setup-bus.c | 16 ++++++++--------
drivers/pci/setup-res.c | 2 +-
drivers/pcmcia/i82092.c | 2 +-
drivers/pcmcia/yenta_socket.c | 6 +++---
drivers/scsi/sym53c8xx_2/sym_glue.c | 5 +++--
drivers/video/arkfb.c | 2 +-
drivers/video/s3fb.c | 2 +-
drivers/video/vt8623fb.c | 2 +-
include/linux/pci.h | 4 ++--
17 files changed, 52 insertions(+), 53 deletions(-)
diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
index 2b183b0..99e8d47 100644
--- a/arch/alpha/kernel/pci-sysfs.c
+++ b/arch/alpha/kernel/pci-sysfs.c
@@ -83,7 +83,7 @@ static int pci_mmap_resource(struct kobject *kobj,
if (iomem_is_exclusive(res->start))
return -EINVAL;
- pcibios_resource_to_bus(pdev, &bar, res);
+ pcibios_resource_to_bus(pdev->bus, &bar, res);
vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0));
mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
@@ -139,7 +139,7 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
long dense_offset;
unsigned long sparse_size;
- pcibios_resource_to_bus(pdev, &bar, &pdev->resource[num]);
+ pcibios_resource_to_bus(pdev->bus, &bar, &pdev->resource[num]);
/* All core logic chips have 4G sparse address space, except
CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a1e3e40..d9476c1 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -835,7 +835,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
* at 0 as unset as well, except if PCI_PROBE_ONLY is also set
* since in that case, we don't want to re-assign anything
*/
- pcibios_resource_to_bus(dev, ®, res);
+ pcibios_resource_to_bus(dev->bus, ®, res);
if (pci_has_flag(PCI_REASSIGN_ALL_RSRC) ||
(reg.start = 0 && !pci_has_flag(PCI_PROBE_ONLY))) {
/* Only print message if not re-assigning */
@@ -886,7 +886,7 @@ static int pcibios_uninitialized_bridge_resource(struct pci_bus *bus,
/* Job is a bit different between memory and IO */
if (res->flags & IORESOURCE_MEM) {
- pcibios_resource_to_bus(dev, ®ion, res);
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
/* If the BAR is non-0 then it's probably been initialized */
if (region.start != 0)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index ac0b034..83c26d8 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -111,7 +111,7 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
res->name = pci_name(dev);
region.start = base;
region.end = base + size - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
}
@@ -280,7 +280,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
res->flags = flags;
region.start = of_read_number(&ranges[1], 2);
region.end = region.start + size - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index cb02145..7de8d1f 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -392,7 +392,7 @@ static void apb_fake_ranges(struct pci_dev *dev,
res->flags = IORESOURCE_IO;
region.start = (first << 21);
region.end = (last << 21) + ((1 << 21) - 1);
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
pci_read_config_byte(dev, APB_MEM_ADDRESS_MAP, &map);
apb_calc_first_last(map, &first, &last);
@@ -400,7 +400,7 @@ static void apb_fake_ranges(struct pci_dev *dev,
res->flags = IORESOURCE_MEM;
region.start = (first << 29);
region.end = (last << 29) + ((1 << 29) - 1);
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
static void pci_of_scan_bus(struct pci_pbm_info *pbm,
@@ -491,7 +491,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
res->flags = flags;
region.start = GET_64BIT(ranges, 1);
region.end = region.start + size - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
after_ranges:
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index a68dc61..6bcd233 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -9,22 +9,19 @@
#include "pci.h"
-static struct pci_bus *find_pci_root_bus(struct pci_dev *dev)
+static struct pci_bus *find_pci_root_bus(struct pci_bus *bus)
{
- struct pci_bus *bus;
-
- bus = dev->bus;
while (bus->parent)
bus = bus->parent;
return bus;
}
-static struct pci_host_bridge *find_pci_host_bridge(struct pci_dev *dev)
+static struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
{
- struct pci_bus *bus = find_pci_root_bus(dev);
+ struct pci_bus *root_bus = find_pci_root_bus(bus);
- return to_pci_host_bridge(bus->bridge);
+ return to_pci_host_bridge(root_bus->bridge);
}
void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
@@ -40,10 +37,11 @@ static bool resource_contains(struct resource *res1, struct resource *res2)
return res1->start <= res2->start && res1->end >= res2->end;
}
-void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
- struct resource *res)
+void pcibios_resource_to_bus(struct pci_bus *bus,
+ struct pci_bus_region *region,
+ struct resource *res)
{
- struct pci_host_bridge *bridge = find_pci_host_bridge(dev);
+ struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
struct pci_host_bridge_window *window;
resource_size_t offset = 0;
@@ -68,10 +66,10 @@ static bool region_contains(struct pci_bus_region *region1,
return region1->start <= region2->start && region1->end >= region2->end;
}
-void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
- struct pci_bus_region *region)
+void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
+ struct pci_bus_region *region)
{
- struct pci_host_bridge *bridge = find_pci_host_bridge(dev);
+ struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
struct pci_host_bridge_window *window;
resource_size_t offset = 0;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 38e403d..f049e3f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -269,8 +269,8 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
region.end = l + sz;
}
- pcibios_bus_to_resource(dev, res, ®ion);
- pcibios_resource_to_bus(dev, &inverted_region, res);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
+ pcibios_resource_to_bus(dev->bus, &inverted_region, res);
/*
* If "A" is a BAR value (a bus address), "bus_to_resource(A)" is
@@ -364,7 +364,7 @@ static void pci_read_bridge_io(struct pci_bus *child)
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
region.start = base;
region.end = limit + io_granularity - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
}
}
@@ -386,7 +386,7 @@ static void pci_read_bridge_mmio(struct pci_bus *child)
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
region.start = base;
region.end = limit + 0xfffff;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
}
}
@@ -436,7 +436,7 @@ static void pci_read_bridge_mmio_pref(struct pci_bus *child)
res->flags |= IORESOURCE_MEM_64;
region.start = base;
region.end = limit + 0xfffff;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
}
}
@@ -1084,24 +1084,24 @@ int pci_setup_device(struct pci_dev *dev)
region.end = 0x1F7;
res = &dev->resource[0];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
region.start = 0x3F6;
region.end = 0x3F6;
res = &dev->resource[1];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
if ((progif & 4) = 0) {
region.start = 0x170;
region.end = 0x177;
res = &dev->resource[2];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
region.start = 0x376;
region.end = 0x376;
res = &dev->resource[3];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
}
break;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 3a02717..5cb726c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -339,7 +339,7 @@ static void quirk_io_region(struct pci_dev *dev, int port,
/* Convert from PCI bus to resource space */
bus_region.start = region;
bus_region.end = region + size - 1;
- pcibios_bus_to_resource(dev, res, &bus_region);
+ pcibios_bus_to_resource(dev->bus, res, &bus_region);
if (!pci_claim_resource(dev, nr))
dev_info(&dev->dev, "quirk: %pR claimed by %s\n", res, name);
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index c5d0a08..5d59572 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -31,7 +31,7 @@ int pci_enable_rom(struct pci_dev *pdev)
if (!res->flags)
return -1;
- pcibios_resource_to_bus(pdev, ®ion, res);
+ pcibios_resource_to_bus(pdev->bus, ®ion, res);
pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
rom_addr &= ~PCI_ROM_ADDRESS_MASK;
rom_addr |= region.start | PCI_ROM_ADDRESS_ENABLE;
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 219a410..7933982 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -475,7 +475,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
&bus->busn_res);
res = bus->resource[0];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_IO) {
/*
* The IO resource is allocated a range twice as large as it
@@ -489,7 +489,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
}
res = bus->resource[1];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_IO) {
dev_info(&bridge->dev, " bridge window %pR\n", res);
pci_write_config_dword(bridge, PCI_CB_IO_BASE_1,
@@ -499,7 +499,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
}
res = bus->resource[2];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_MEM) {
dev_info(&bridge->dev, " bridge window %pR\n", res);
pci_write_config_dword(bridge, PCI_CB_MEMORY_BASE_0,
@@ -509,7 +509,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
}
res = bus->resource[3];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_MEM) {
dev_info(&bridge->dev, " bridge window %pR\n", res);
pci_write_config_dword(bridge, PCI_CB_MEMORY_BASE_1,
@@ -546,7 +546,7 @@ static void pci_setup_bridge_io(struct pci_bus *bus)
/* Set up the top and bottom of the PCI I/O segment for this bus. */
res = bus->resource[0];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_IO) {
pci_read_config_dword(bridge, PCI_IO_BASE, &l);
l &= 0xffff0000;
@@ -578,7 +578,7 @@ static void pci_setup_bridge_mmio(struct pci_bus *bus)
/* Set up the top and bottom of the PCI Memory segment for this bus. */
res = bus->resource[1];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_MEM) {
l = (region.start >> 16) & 0xfff0;
l |= region.end & 0xfff00000;
@@ -604,7 +604,7 @@ static void pci_setup_bridge_mmio_pref(struct pci_bus *bus)
/* Set up PREF base/limit. */
bu = lu = 0;
res = bus->resource[2];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_PREFETCH) {
l = (region.start >> 16) & 0xfff0;
l |= region.end & 0xfff00000;
@@ -1422,7 +1422,7 @@ static int iov_resources_unassigned(struct pci_dev *dev, void *data)
if (!r->flags)
continue;
- pcibios_resource_to_bus(dev, ®ion, r);
+ pcibios_resource_to_bus(dev->bus, ®ion, r);
if (!region.start) {
*unassigned = true;
return 1; /* return early from pci_walk_bus() */
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 83c4d3b..5c060b1 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -52,7 +52,7 @@ void pci_update_resource(struct pci_dev *dev, int resno)
if (res->flags & IORESOURCE_PCI_FIXED)
return;
- pcibios_resource_to_bus(dev, ®ion, res);
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
if (res->flags & IORESOURCE_IO)
diff --git a/drivers/pcmcia/i82092.c b/drivers/pcmcia/i82092.c
index 519c4d6..7d47456 100644
--- a/drivers/pcmcia/i82092.c
+++ b/drivers/pcmcia/i82092.c
@@ -608,7 +608,7 @@ static int i82092aa_set_mem_map(struct pcmcia_socket *socket, struct pccard_mem_
enter("i82092aa_set_mem_map");
- pcibios_resource_to_bus(sock_info->dev, ®ion, mem->res);
+ pcibios_resource_to_bus(sock_info->dev->bus, ®ion, mem->res);
map = mem->map;
if (map > 4) {
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index dc18a3a..8485761 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -445,7 +445,7 @@ static int yenta_set_mem_map(struct pcmcia_socket *sock, struct pccard_mem_map *
unsigned int start, stop, card_start;
unsigned short word;
- pcibios_resource_to_bus(socket->dev, ®ion, mem->res);
+ pcibios_resource_to_bus(socket->dev->bus, ®ion, mem->res);
map = mem->map;
start = region.start;
@@ -709,7 +709,7 @@ static int yenta_allocate_res(struct yenta_socket *socket, int nr, unsigned type
region.start = config_readl(socket, addr_start) & mask;
region.end = config_readl(socket, addr_end) | ~mask;
if (region.start && region.end > region.start && !override_bios) {
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
if (pci_claim_resource(dev, PCI_BRIDGE_RESOURCES + nr) = 0)
return 0;
dev_printk(KERN_INFO, &dev->dev,
@@ -1033,7 +1033,7 @@ static void yenta_config_init(struct yenta_socket *socket)
struct pci_dev *dev = socket->dev;
struct pci_bus_region region;
- pcibios_resource_to_bus(socket->dev, ®ion, &dev->resource[0]);
+ pcibios_resource_to_bus(socket->dev->bus, ®ion, &dev->resource[0]);
config_writel(socket, CB_LEGACY_MODE_BASE, 0);
config_writel(socket, PCI_BASE_ADDRESS_0, region.start);
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index bac55f7..6d3ee1a 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -1531,7 +1531,7 @@ static int sym_iomap_device(struct sym_device *device)
struct pci_bus_region bus_addr;
int i = 2;
- pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[1]);
+ pcibios_resource_to_bus(pdev->bus, &bus_addr, &pdev->resource[1]);
device->mmio_base = bus_addr.start;
if (device->chip.features & FE_RAM) {
@@ -1541,7 +1541,8 @@ static int sym_iomap_device(struct sym_device *device)
*/
if (!pdev->resource[i].flags)
i++;
- pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[i]);
+ pcibios_resource_to_bus(pdev->bus, &bus_addr,
+ &pdev->resource[i]);
device->ram_base = bus_addr.start;
}
diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
index a6b29bd..adc4ea2 100644
--- a/drivers/video/arkfb.c
+++ b/drivers/video/arkfb.c
@@ -1014,7 +1014,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_res.flags = IORESOURCE_IO;
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+ pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
par->state.vgabase = (void __iomem *) vga_res.start;
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 968b299..9a3f8f1 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1180,7 +1180,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_res.flags = IORESOURCE_IO;
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+ pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
par->state.vgabase = (void __iomem *) vga_res.start;
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index 8bc6e09..5c7cbc6 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -729,7 +729,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_res.flags = IORESOURCE_IO;
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+ pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
par->state.vgabase = (void __iomem *) vga_res.start;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb8078a..da069fa 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -737,9 +737,9 @@ void pci_fixup_cardbus(struct pci_bus *);
/* Generic PCI functions used internally */
-void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
+void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region,
struct resource *res);
-void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
struct pci_bus_region *region);
void pcibios_scan_specific_bus(int busn);
struct pci_bus *pci_find_bus(int domain, int busnr);
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tony Lindgren @ 2013-12-09 18:04 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <52A5BB65.5050109@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131209 04:46]:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> > from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
OK I've finally pushed a real branch for the mach-omap2 board-*.c file
removal patches at omap-for-v3.14/omap3-board-removal so you can use
that as a base for testing. I did not apply the dpi panel pdata-quirks.c
patch as we discussed earlier.
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
OK thanks. Care to also check that it plays along nicely with the comments
starting at line 3222 in omap_hwmod_3xxx_data.c? We should set up things
so we can eventually remove those kind of hwmod workarounds.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
Yes that's what we want if there is a dependency to the dss_core at the
hardware level and the children cannot be used independently. However,
if the children can be enabled and clocked independently, then they
should not be children of the dss_core.
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
If you need a dev entry created for those where the phandle of that dev
is used to select the output for a board, then it makes sense to have
them. I guess you could also set them as a pinctrl mux controller and
then the board specific .dts file could request those outputs. But there
may be more than just mux involved like regulators.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Javier Martinez Canillas @ 2013-12-09 16:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Enric Balletbo Serra
In-Reply-To: <52A5E230.4010901@ti.com>
Hi Tomi,
On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>
>>>>> + tfp410: encoder@0 {
>>>>> + compatible = "ti,tfp410";
>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>> +
>>>>
>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>> numbers, i.e:
>>>>
>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>
>>> Thanks, fixed now (for all .dts files)
>>>
>>> However... The TFP410 gpio is "power-down". I think we should actually
>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>
>>
>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>> GPIO_ACTIVE_HIGH as 0.
>>
>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>> signal inverter but that is a special case. I don't know about the
>> Panda board since I haven't looked at its datasheet.
>
> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
> as it were active-low. The flag is ignored.
>
How weird, it does work on the IGEPv2 but you are right I just looked
at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
that it indeed just does:
r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
GPIOF_OUT_INIT_LOW, "tfp410 PD");
So I don't know how it is working... I'm on the road and won't have
access to my IGEPv2 to dig further on this. Maybe Enric can shed more
light on this.
> Tomi
>
>
Thanks a lot and best regards,
Javier
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-12-09 15:30 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Enric Balletbo Serra
In-Reply-To: <CABxcv==-aknRfzybA6ify5JSHeiquS9bqAEXumJwhnS6PT0MfA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On 2013-12-09 17:09, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>
>>>> + tfp410: encoder@0 {
>>>> + compatible = "ti,tfp410";
>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>> +
>>>
>>> Please use the constants from include/dt-bindings/ instead of magic
>>> numbers, i.e:
>>>
>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>
>> Thanks, fixed now (for all .dts files)
>>
>> However... The TFP410 gpio is "power-down". I think we should actually
>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>
>
> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
> GPIO_ACTIVE_HIGH as 0.
>
> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
> signal inverter but that is a special case. I don't know about the
> Panda board since I haven't looked at its datasheet.
Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
as it were active-low. The flag is ignored.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Javier Martinez Canillas @ 2013-12-09 15:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Enric Balletbo Serra
In-Reply-To: <52A5BDF4.2070304@ti.com>
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>> +
>>
>> Please use the constants from include/dt-bindings/ instead of magic
>> numbers, i.e:
>>
>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>
> Thanks, fixed now (for all .dts files)
>
> However... The TFP410 gpio is "power-down". I think we should actually
> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Thanks a lot and best regards,
Javier
[0]: http://www.ti.com/lit/ds/slds145b/slds145b.pdf
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-12-09 12:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CABxcv=m+-9V2qwvuQgJavQ3qOb2+fBcAoW9G_Mi33BTHCWE85g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>> +
>
> Please use the constants from include/dt-bindings/ instead of magic
> numbers, i.e:
>
> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is "power-down". I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tomi Valkeinen @ 2013-12-09 12:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <20131205170514.GY26766@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
On 2013-12-05 19:05, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
>
> Description missing.. But other than that can you please check that
> the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> the hwmod data from device" works with this?
>
> The test to do is to remove the related reg, interrupt and dma entries
> from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> from DT properly.
I made a quick test with panda, by applying your patch and reverting
b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
the DISPC IRQ, but that worked fine.
> I don't know if it makes sense to have them as children of dss_core, they
> really all seem to be completely independent devices?
The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are children of the dss_core.
> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> property and do the lookup based on the compatible property instead ;)
> So from that point of view we need to get the device mapping right in
> the .dtsi files, and don't want to start mixing up separate devices into
> single .dtsi entry.
Hmm, was that just a general comment, or something that affects the DSS
DT data I have in my patch? As far as I understand, the DSS nodes
reflect the current hwmods correctly.
With the exception that DPI and SDI do not have a matching hwmod, as
they are really part of dss_core/dispc. They are separate nodes as they
are "video outputs" the same way as the other subnodes.
I could perhaps remove the DPI and SDI nodes, and have them as direct
video ports from DISPC, but... That's easier said than done.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Javier Martinez Canillas @ 2013-12-09 12:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Javier Martinez Canillas, linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Laurent Pinchart, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <52A5B111.3010307@ti.com>
On Mon, Dec 9, 2013 at 1:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-07 06:28, Javier Martinez Canillas wrote:
>
>> Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the right
>> thing for legacy platform data probing but no for DT probing:
>>
>> static int dvic_probe_pdata(struct platform_device *pdev)
>> {
>> ..
>> adapter = i2c_get_adapter(i2c_bus_num);
>> if (!adapter) {
>> dev_err(&pdev->dev,
>> "Failed to get I2C adapter, bus %d\n",
>> i2c_bus_num);
>> return -EPROBE_DEFER;
>> }
>> ..
>> }
>>
>> static int dvic_probe_of(struct platform_device *pdev)
>> {
>> ..
>> adapter = of_find_i2c_adapter_by_node(adapter_node);
>> if (adapter = NULL) {
>> dev_err(&pdev->dev, "failed to parse i2c-bus\n");
>> omap_dss_put_device(ddata->in);
>> return -EINVAL;
>> }
>> ..
>> }
>>
>> The following patch solves the issue if you want to include in your patch-set:
>
> Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
>
Great, thanks a lot for working on this!
I'm very happy that we will have proper display support for IGEPv2 on
v3.14 without any DT hacks or pdata-quirks :-)
> Tomi
Best regards,
Javier
>
>
^ permalink raw reply
* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
From: Javier Martinez Canillas @ 2013-12-09 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <52A5B248.5050303@ti.com>
Hi Tomi,
On Mon, Dec 9, 2013 at 1:06 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:41, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>>> index fa532aaacc68..1ca1932d02aa 100644
>>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>>> @@ -178,3 +178,70 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dpi {
>>> + vdds_dsi-supply = <&vpll2>;
>>> +
>>> + dpi_out: endpoint {
>>> + remote-endpoint = <&tfp410_in>;
>>> + data-lines = <24>;
>>> + };
>>> +};
>>> +
>>> +&venc {
>>> + vdda_dac-supply = <&vdac>;
>>> +
>>> + venc_out: endpoint {
>>> + remote-endpoint = <&tv_connector_in>;
>>> + };
>>> +};
>>> +
>>> +/ {
>>> + aliases {
>>> + display0 = &dvi0;
>>> + display1 = &tv0;
>>> + };
>>> +
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>>> +
>>
>> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
>> from 1 so gpio5 + 10 is GPIO 138.
>
> Yes, you're right. Good catch.
>
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> +
>>> + tfp410_in: endpoint@0 {
>>> + remote-endpoint = <&dpi_out>;
>>> + };
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> +
>>> + tfp410_out: endpoint@1 {
>>> + remote-endpoint = <&dvi_connector_in>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + dvi0: connector@0 {
>>> + compatible = "ti,dvi_connector";
>>> + i2c-bus = <&i2c3>;
>>> +
>>> + dvi_connector_in: endpoint {
>>> + remote-endpoint = <&tfp410_out>;
>>> + };
>>> + };
>>> +
>>> + tv0: connector@1 {
>>> + compatible = "ti,svideo_connector";
>>> +
>>> + tv_connector_in: endpoint {
>>> + remote-endpoint = <&venc_out>;
>>> + };
>>> + };
>>> +};
>>> --
>>> 1.8.3.2
>>>
>>
>> Also I don't see the DSS pinmux set for this board. I guess you need
>> something like the following on top:
>>
>> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
>> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
>> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
>> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
>> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
>> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
>> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
>> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
>> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
>> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
>> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
>> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
>> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
>> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
>> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
>> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
>> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
>> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
>> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
>> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
>> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
>> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
>> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
>> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
>> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
>> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
>> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
>> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
>
> True. I need to add something like this to all the dts files.
>
> You didn't have muxing in the omap3-igep0020 patch you gave. Is the
> muxing already set in some other patch?
>
Your patch-set is based on v3.13-rc1 but I sent a patch-set [0] to fix
a few regressions for IGEPv2 when we moved to DT-only boot. One of
these patches added the needed DSS pinmuxing and these were included
in v3.13-rc2.
So to test your branch I cherry-picked:
d526daeb ("ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices")
50592dc3 ("ARM: dts: omap3-igep0020: Add pinmuxing for DVI output")
Also, for 3.13 I added a DT hack to make dpi_init_regulator() succeed
and find the VDDS_DSI regulator. That patch is mainline comit
2f2befd82 ("ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi")
Now that I think about it, you may want to add a revert for that patch
on your series too since this hack is not needed anymore with your DSS
bindings.
> Tomi
>
Thanks a lot and best regards,
Javier
>
[0]: http://www.spinics.net/lists/linux-omap/msg99970.html
^ permalink raw reply
* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
From: Tomi Valkeinen @ 2013-12-09 12:06 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CABxcv=mgQM6oHf7=-EbryAcmgJm3vf+xXqHW6BCdW8ovS29O0g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4875 bytes --]
On 2013-12-06 10:41, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>> index fa532aaacc68..1ca1932d02aa 100644
>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>> @@ -178,3 +178,70 @@
>> mode = <3>;
>> power = <50>;
>> };
>> +
>> +&dpi {
>> + vdds_dsi-supply = <&vpll2>;
>> +
>> + dpi_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + data-lines = <24>;
>> + };
>> +};
>> +
>> +&venc {
>> + vdda_dac-supply = <&vdac>;
>> +
>> + venc_out: endpoint {
>> + remote-endpoint = <&tv_connector_in>;
>> + };
>> +};
>> +
>> +/ {
>> + aliases {
>> + display0 = &dvi0;
>> + display1 = &tv0;
>> + };
>> +
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>> +
>
> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
> from 1 so gpio5 + 10 is GPIO 138.
Yes, you're right. Good catch.
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint@0 {
>> + remote-endpoint = <&dpi_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint@1 {
>> + remote-endpoint = <&dvi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + dvi0: connector@0 {
>> + compatible = "ti,dvi_connector";
>> + i2c-bus = <&i2c3>;
>> +
>> + dvi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> +
>> + tv0: connector@1 {
>> + compatible = "ti,svideo_connector";
>> +
>> + tv_connector_in: endpoint {
>> + remote-endpoint = <&venc_out>;
>> + };
>> + };
>> +};
>> --
>> 1.8.3.2
>>
>
> Also I don't see the DSS pinmux set for this board. I guess you need
> something like the following on top:
>
> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
True. I need to add something like this to all the dts files.
You didn't have muxing in the omap3-igep0020 patch you gave. Is the
muxing already set in some other patch?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Tomi Valkeinen @ 2013-12-09 12:01 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Laurent Pinchart, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <52A2A3EF.1030306@collabora.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On 2013-12-07 06:28, Javier Martinez Canillas wrote:
> Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the right
> thing for legacy platform data probing but no for DT probing:
>
> static int dvic_probe_pdata(struct platform_device *pdev)
> {
> ..
> adapter = i2c_get_adapter(i2c_bus_num);
> if (!adapter) {
> dev_err(&pdev->dev,
> "Failed to get I2C adapter, bus %d\n",
> i2c_bus_num);
> return -EPROBE_DEFER;
> }
> ..
> }
>
> static int dvic_probe_of(struct platform_device *pdev)
> {
> ..
> adapter = of_find_i2c_adapter_by_node(adapter_node);
> if (adapter == NULL) {
> dev_err(&pdev->dev, "failed to parse i2c-bus\n");
> omap_dss_put_device(ddata->in);
> return -EINVAL;
> }
> ..
> }
>
> The following patch solves the issue if you want to include in your patch-set:
Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Javier Martinez Canillas @ 2013-12-07 4:28 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Laurent Pinchart, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <52A29A82.106@collabora.co.uk>
On 12/07/2013 04:48 AM, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Hi,
>>
>> Here's a new version for DT support to OMAP Display Subsystem. See
>> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
>> previous version, which contains thoughts about the related problems.
>>
>> The major change in this version is the use of V4L2 and CDF style port/endpoint
>> style in the DT data. However, note that even if the DT data contains proper
>> port & endpoint data, the drivers only use the first endpoint. This is to
>> simplify the patches, as adding full support for the ports and endpoints to the
>> drivers will be a big task. This approach still works with more or less all the
>> boards, as the only cases where the simpler model is an issue are the boards
>> with multiple display devices connected to a single output.
>>
>> Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
>> there's anything that's clearly not CDF compatible.
>>
>> The patches can also be found from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>>
>
> I tested your branch on my DM3730 IGEPv2 board by cherry-picking the following
> commits from latest Linus tree on top of your work/dss-dt branch:
>
> d526daeb ("ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices")
> 50592dc3 ("ARM: dts: omap3-igep0020: Add pinmuxing for DVI output")
>
> And adding the display information using your DSS bindings to omap3-igep0020.dts
> [0].
>
> But it failed for me because of a probing order. The problem is that the probing
> order is:
>
> omap_i2c
> pinctrl-single
> OMAP DSS
> connector-dvi
> omapfb
>
> Now DT good practices says that the pinmux setup needed for a device have to be
> initialized in a pin control state for the device using these pins (i.e: i2c3)
> instead of doing globally by being part of a pinctrl state of the pinmux device
> (i.e: omap3_pmx_core).
>
> But due this init order the omap_i2c probe is deferred due pinctrl-single not
> being initialized yet:
>
> [ 0.565246] omap_i2c 48060000.i2c: could not find pctldev for node /ocp/pinmu
>
>
> x@48002030/pinmux_i2c3_pins, deferring probe
>
> This is ok since eventually the pinctrl-single driver will be initialized and
> the next time the omap_i2c probe is called it will succeed. But before omap_i2c
> has a chance to be probed again the connector-dvi driver is probed and fails due
> the i2c bus not being initialized yet:
>
> [ 1.064300] OMAP DSS rev 2.0
> [ 1.073669] connector-dvi connector.12: failed to parse i2c-bus
> [ 1.073730] connector-dvi: probe of connector.12 failed with error -22
> [ 1.078216] omapfb omapfb: no displays
> [ 1.080871] omapfb omapfb: failed to setup omapfb
> [ 1.080932] platform omapfb: Driver omapfb requests probe deferral
> ..
>
> Later the omap_i2c driver probe succees since the pinctrl-single driver was
> initialized but by then it is already too late:
>
> [ 3.293914] omap_i2c 48070000.i2c: bus 0 rev4.4 at 2600 kHz
> [ 3.301940] omap_i2c 48072000.i2c: bus 1 rev4.4 at 400 kHz
> [ 3.310882] omap_i2c 48060000.i2c: bus 2 rev4.4 at 100 kHz
> [ 3.317565] omapfb omapfb: no displays
> [ 3.321716] omapfb omapfb: failed to setup omapfb
> [ 3.326751] platform omapfb: Driver omapfb requests probe deferral
> ..
> [ 3.694915] omapfb omapfb: no displays
> [ 3.699127] omapfb omapfb: failed to setup omapfb
> [ 3.704071] platform omapfb: Driver omapfb requests probe deferral
> ..
>
> If I move the i2c3 pinmux definitions from the i2c3 device node to
> omap3_pmx_core then the display works correctly.
>
> So, I think that we should add deferred probing to drivers/video/omap2/*.c too
> to avoid the scenario I described above.
>
Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the right
thing for legacy platform data probing but no for DT probing:
static int dvic_probe_pdata(struct platform_device *pdev)
{
..
adapter = i2c_get_adapter(i2c_bus_num);
if (!adapter) {
dev_err(&pdev->dev,
"Failed to get I2C adapter, bus %d\n",
i2c_bus_num);
return -EPROBE_DEFER;
}
..
}
static int dvic_probe_of(struct platform_device *pdev)
{
..
adapter = of_find_i2c_adapter_by_node(adapter_node);
if (adapter = NULL) {
dev_err(&pdev->dev, "failed to parse i2c-bus\n");
omap_dss_put_device(ddata->in);
return -EINVAL;
}
..
}
The following patch solves the issue if you want to include in your patch-set:
From c85d46b94c3d27d30218af23a6a8d61e6c7d2ae8 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Sat, 7 Dec 2013 05:18:56 +0100
Subject: [PATCH 1/1] OMAPDSS: connector-dvi: add deferred probing support for
OF path
When booting with Device Trees the order in which device drivers
are probed is not defined so drivers should be able to defer its
probing if a dependency is not found (such as an i2c bus) instead
of just failing.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
drivers/video/omap2/displays-new/connector-dvi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
b/drivers/video/omap2/displays-new/connector-dvi.c
index 8f7e576..f94344a 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -299,7 +299,7 @@ static int dvic_probe_of(struct platform_device *pdev)
if (adapter = NULL) {
dev_err(&pdev->dev, "failed to parse i2c-bus\n");
omap_dss_put_device(ddata->in);
- return -EINVAL;
+ return -EPROBE_DEFER;
}
ddata->i2c_adapter = adapter;
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Javier Martinez Canillas @ 2013-12-07 3:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Laurent Pinchart, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> Here's a new version for DT support to OMAP Display Subsystem. See
> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
> previous version, which contains thoughts about the related problems.
>
> The major change in this version is the use of V4L2 and CDF style port/endpoint
> style in the DT data. However, note that even if the DT data contains proper
> port & endpoint data, the drivers only use the first endpoint. This is to
> simplify the patches, as adding full support for the ports and endpoints to the
> drivers will be a big task. This approach still works with more or less all the
> boards, as the only cases where the simpler model is an issue are the boards
> with multiple display devices connected to a single output.
>
> Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
> there's anything that's clearly not CDF compatible.
>
> The patches can also be found from:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>
I tested your branch on my DM3730 IGEPv2 board by cherry-picking the following
commits from latest Linus tree on top of your work/dss-dt branch:
d526daeb ("ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices")
50592dc3 ("ARM: dts: omap3-igep0020: Add pinmuxing for DVI output")
And adding the display information using your DSS bindings to omap3-igep0020.dts
[0].
But it failed for me because of a probing order. The problem is that the probing
order is:
omap_i2c
pinctrl-single
OMAP DSS
connector-dvi
omapfb
Now DT good practices says that the pinmux setup needed for a device have to be
initialized in a pin control state for the device using these pins (i.e: i2c3)
instead of doing globally by being part of a pinctrl state of the pinmux device
(i.e: omap3_pmx_core).
But due this init order the omap_i2c probe is deferred due pinctrl-single not
being initialized yet:
[ 0.565246] omap_i2c 48060000.i2c: could not find pctldev for node /ocp/pinmu
x@48002030/pinmux_i2c3_pins, deferring probe
This is ok since eventually the pinctrl-single driver will be initialized and
the next time the omap_i2c probe is called it will succeed. But before omap_i2c
has a chance to be probed again the connector-dvi driver is probed and fails due
the i2c bus not being initialized yet:
[ 1.064300] OMAP DSS rev 2.0
[ 1.073669] connector-dvi connector.12: failed to parse i2c-bus
[ 1.073730] connector-dvi: probe of connector.12 failed with error -22
[ 1.078216] omapfb omapfb: no displays
[ 1.080871] omapfb omapfb: failed to setup omapfb
[ 1.080932] platform omapfb: Driver omapfb requests probe deferral
..
Later the omap_i2c driver probe succees since the pinctrl-single driver was
initialized but by then it is already too late:
[ 3.293914] omap_i2c 48070000.i2c: bus 0 rev4.4 at 2600 kHz
[ 3.301940] omap_i2c 48072000.i2c: bus 1 rev4.4 at 400 kHz
[ 3.310882] omap_i2c 48060000.i2c: bus 2 rev4.4 at 100 kHz
[ 3.317565] omapfb omapfb: no displays
[ 3.321716] omapfb omapfb: failed to setup omapfb
[ 3.326751] platform omapfb: Driver omapfb requests probe deferral
..
[ 3.694915] omapfb omapfb: no displays
[ 3.699127] omapfb omapfb: failed to setup omapfb
[ 3.704071] platform omapfb: Driver omapfb requests probe deferral
..
If I move the i2c3 pinmux definitions from the i2c3 device node to
omap3_pmx_core then the display works correctly.
So, I think that we should add deferred probing to drivers/video/omap2/*.c too
to avoid the scenario I described above.
Also, would you mind to include [0] on your patch-set so display continue
working for IGEPv2 after you remove the pdata-quirks and dss-common.c hacks?
Thanks a lot and best regards,
Javier
[0]:
From a9af54a3b63bccade241e056d153d8bf04a6a5d5 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date: Fri, 6 Dec 2013 02:53:38 +0100
Subject: [PATCH 1/1] ARM: dts: omap3-igep0020: add display information
The IGEPv2 has a TFP410 DPI-to-DVI encoder attached
to OMAP's Display SubSystem (DSS). Add DeviceTree
nodes for these devices.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
arch/arm/boot/dts/omap3-igep0020.dts | 51 ++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 76509de..2569d60 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -215,3 +215,54 @@
&usbhsehci {
phys = <&hsusb1_phy>;
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi-connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+};
--
1.8.4.2
^ permalink raw reply related
* [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing unlock in acx565akm_panel_power_on()
From: Wei Yongjun @ 2013-12-06 12:55 UTC (permalink / raw)
To: tomi.valkeinen, plagnioj, aaro.koskinen
Cc: yongjun_wei, linux-omap, linux-fbdev
In-Reply-To: <1383773070-15114-1-git-send-email-aaro.koskinen@iki.fi>
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Add the missing unlock before return from function
acx565akm_panel_power_on() in the error handling case.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/video/omap2/displays-new/panel-sony-acx565akm.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index d94f35d..69aa4a1 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -536,7 +536,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
r = in->ops.sdi->enable(in);
if (r) {
pr_err("%s sdi enable failed\n", __func__);
- return r;
+ goto out;
}
/*FIXME tweak me */
@@ -547,7 +547,8 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
if (ddata->enabled) {
dev_dbg(&ddata->spi->dev, "panel already enabled\n");
- return 0;
+ r = 0;
+ goto out;
}
/*
@@ -571,6 +572,10 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
mutex_unlock(&ddata->mutex);
return acx565akm_bl_update_status(ddata->bl_dev);
+
+out:
+ mutex_unlock(&ddata->mutex);
+ return r;
}
static void acx565akm_panel_power_off(struct omap_dss_device *dssdev)
^ permalink raw reply related
* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
From: Florian Vaussard @ 2013-12-06 10:18 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
In-Reply-To: <1386160133-24026-18-git-send-email-tomi.valkeinen@ti.com>
Hello Tomi,
On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
> it as a test.
>
Looking at the schematics, both seem pretty similar indeed. The main
difference seems to be the LCD on the palo43, and the HDMI on the Tobi
(TFP410, as in your patch 21).
I only have a Tobi on my desk, so this is the reason for not supporting
other boards... We could make a .dtsi with common stuff, then add the
LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
support to these boards in the coming days, so I can add this too, at
least for testing purpose.
Cheers,
Florian
^ permalink raw reply
* Re: [PATCHv13][ 2/4] video: imxfb: Also add p =?UTF-8?B?d21yIGZvciB0aGUgZ
From: Alexander Shiyan @ 2013-12-06 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131206093017.GB24559@pengutronix.de>
PiA+ID4gT24gRnJpLCBEZWMgMDYsIDIwMTMgYXQgMTI6MDM6NTRQTSArMDQwMCwgQWxleGFuZGVy
IFNoaXlhbiB3cm90ZToKPiA+IC4uLgo+ID4gPiA+ID4gPiAgLSBmc2wsZG1hY3I6IERNQSBDb250
cm9sIFJlZ2lzdGVyIHZhbHVlLiBUaGlzIGlzIG9wdGlvbmFsLiBCeSBkZWZhdWx0LCB0aGUKPiA+
ID4gPiA+ID4gIAlyZWdpc3RlciBpcyBub3QgbW9kaWZpZWQgYXMgcmVjb21tZW5kZWQgYnkgdGhl
IGRhdGFzaGVldC4KPiA+ID4gPiA+ID4gKy0gZnNsLHB3bXI6ICBMQ0RDIFBXTSBDb250cmFzdCBD
b250cm9sIFJlZ2lzdGVyIHZhbHVlLiBUaGF0IHByb3BlcnR5IGlzCj4gPiA+ID4gPiA+ICsJb3B0
aW9uYWwsIGJ1dCBkZWZpbmluZyBpdCBpcyBuZWNlc3NhcnkgdG8gZ2V0IHRoZSBiYWNrbGlnaHQg
d29ya2luZy4gSWYgdGhhdAo+ID4gPiA+ID4gPiArCXByb3BlcnR5IGlzIG9tbWl0ZWQsIHRoZSBy
ZWdpc3RlciBpcyB6ZXJvZWQuCj4gPiA+ID4gPiAKPiA+ID4gPiA+IFdoeSBpc24ndCB0aGlzIGlt
cGxlbWVudGVkIGFzIGEgYmFja2xpZ2h0IGRyaXZlcj8gU3RhdGljIGRldmljZXRyZWUKPiA+ID4g
PiA+IHByb3ZpZGVkIHZhbHVlcyBpcyB2ZXJ5IGxpbWl0aW5nLgo+ID4gPiA+IAo+ID4gPiA+IExl
dCdzIHVuZGVyc3RhbmQgdGhlIHRlcm1pbm9sb2d5Lgo+ID4gPiA+IFRoaXMgcmVnaXN0ZXIgc2hv
dWxkIGJlIHJlbmFtZWQgYWNjb3JkaW5nIHRvIHRoZSBkYXRhc2hlZXQsIGkuZS4gTFBDQ1IuCj4g
PiA+ID4gQXMgSSBwb2ludGVkIG91dCBlYXJsaWVyLCBpdCBpcyBOT1QgY29udHJvbCB0aGUgYmFj
a2xpZ2h0LCB0aGlzIGlzIGEgY29udHJhc3QgY29udHJvbC4KPiA+ID4gPiBZZXMsIGl0IHdvcmtz
IGFzIFBXTSwgYnV0IG5vdGhpbmcgZG8gd2l0aCB0aGUgYmFja2xpZ2h0IHN1YnN5c3RlbS4KPiA+
ID4gPiBZZXMsIHdlIGNhbiBtYWtlIGEgZHJpdmVyIGZvciB0aGlzIFBXTSwgYnV0IGhvdyBhcmUg
d2UgZ29pbmcgdG8gY29udHJvbCBpdD8KPiA+ID4gPiBJIG1pc3VuZGVyc3Rvb2Qgc29tZXRoaW5n
Pwo+ID4gPiAKPiA+ID4gSSBzdHVtYmxlZCB1cG9uICdnZXQgdGhlIGJhY2tsaWdodCB3b3JraW5n
JyB3aGljaCBpbXBsaWVkIGZvciBtZSB0aGF0IGl0Cj4gPiA+IHNob3VsZCBiZSBhIGJhY2tsaWdo
dCBkcml2ZXIuIEJ1dCB5b3UncmUgcmlnaHQgYW5kIG5vdyBJIHJlbWVtYmVyIHdlCj4gPiA+IHRh
bGtlZCBhYm91dCB0aGlzIGFscmVhZHkuCj4gPiAKPiA+IEhhbGxlbHVqYWguCj4gPiAKPiA+ID4g
SSBzdGlsbCB0aGluayB0aGlzIHNob3VsZCBiZSBzb21ldGhpbmcgYWRqdXN0YWJsZSwgbm90IHN0
YXRpYyBkYXRhLgo+ID4gPiBNYXliZSB3ZSBjb3VsZCBjaGFuZ2UgdGhlIHdvcmRpbmcgdG8gc29t
ZXRoaW5nIGxpa2UgIlRoaXMgcHJvcGVydHkKPiA+ID4gcHJvdmlkZXMgdGhlIGRlZmF1bHQgdmFs
dWUgZm9yIHRoZSBjb250cmFzdCBjb250cm9sIHJlZ2lzdGVyIiBzaW5jZSBldmVuCj4gPiA+IGlm
IHdlIGFkZCBkcml2ZXIgc3VwcG9ydCBmb3IgY29udHJvbGxpbmcgdGhlIGNvbnRyYXN0IHdlIHN0
aWxsIHdhbnQKPiA+ID4gdG8gaGF2ZSBhIHNhbmUgZGVmYXVsdC4KPiA+IAo+ID4gU291bmRzIGdv
b2QuCj4gPiAKPiA+ID4gQlRXIHRoZSBjb250cmFzdCBjb3VsZCBiZSBjb250cm9sbGVkIHdpdGgg
YSBsY2RfZGV2aWNlIChzZWUKPiA+ID4gbGNkX2RldmljZV9yZWdpc3Rlcikgd2hpY2ggc2VlbXMg
dG8gYmUgdmVyeSBlYXN5IHRvIGltcGxlbWVudC4KPiA+IAo+ID4gQWRkcmVzcyBvZiByZWdpc3Rl
ciBpcyBwbGFjZWQgd2l0aGluIExDRCBhcmVhLCBzbyB3ZSBjYW5ub3QgdXNlIHRoaXMKPiA+IG1l
bW9yeSByZWdpb24sIEkgdGhpbmsgaXMgbm8gc28gZWFzeSBhcyB5b3Ugc2F5Li4uLgo+IAo+IFdl
IGRvIG5vdCBuZWVkIGEgc2VwYXJhdGUgZHJpdmVyIGZvciB0aGlzLiBMb29rIGZvciBleGFtcGxl
IGF0Cj4gZHJpdmVycy92aWRlby9iZjUzNy1scTAzNS5jLCBpdCBqdXN0IGNhbGxzIGxjZF9kZXZp
Y2VfcmVnaXN0ZXIoKQo+IGluIGl0cyBwcm9iZSBmdW5jdGlvbi4KCk5pY2UuIFNlZW1zIHRoaXMg
ZXhhbXBsZSBldmVuIGNhbiBoYW5kbGUgTENEIHBvd2VyCnJlZ3VsYXRvciBmcm9tICJbMS80XSB2
aWRlbzogaW14ZmI6IEludHJvZHVjZSByZWd1bGF0b3Igc3VwcG9ydC4iCgotLS0K
^ permalink raw reply
* Re: [PATCHv13][ 2/4] video: imxfb: Also add pwmr for the device tree.
From: Sascha Hauer @ 2013-12-06 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386318910.581671226@f322.i.mail.ru>
On Fri, Dec 06, 2013 at 12:35:10PM +0400, Alexander Shiyan wrote:
> > On Fri, Dec 06, 2013 at 12:03:54PM +0400, Alexander Shiyan wrote:
> ...
> > > > > - fsl,dmacr: DMA Control Register value. This is optional. By default, the
> > > > > register is not modified as recommended by the datasheet.
> > > > > +- fsl,pwmr: LCDC PWM Contrast Control Register value. That property is
> > > > > + optional, but defining it is necessary to get the backlight working. If that
> > > > > + property is ommited, the register is zeroed.
> > > >
> > > > Why isn't this implemented as a backlight driver? Static devicetree
> > > > provided values is very limiting.
> > >
> > > Let's understand the terminology.
> > > This register should be renamed according to the datasheet, i.e. LPCCR.
> > > As I pointed out earlier, it is NOT control the backlight, this is a contrast control.
> > > Yes, it works as PWM, but nothing do with the backlight subsystem.
> > > Yes, we can make a driver for this PWM, but how are we going to control it?
> > > I misunderstood something?
> >
> > I stumbled upon 'get the backlight working' which implied for me that it
> > should be a backlight driver. But you're right and now I remember we
> > talked about this already.
>
> Hallelujah.
>
> > I still think this should be something adjustable, not static data.
> > Maybe we could change the wording to something like "This property
> > provides the default value for the contrast control register" since even
> > if we add driver support for controlling the contrast we still want
> > to have a sane default.
>
> Sounds good.
>
> > BTW the contrast could be controlled with a lcd_device (see
> > lcd_device_register) which seems to be very easy to implement.
>
> Address of register is placed within LCD area, so we cannot use this
> memory region, I think is no so easy as you say....
We do not need a separate driver for this. Look for example at
drivers/video/bf537-lq035.c, it just calls lcd_device_register()
in its probe function.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Javier Martinez Canillas @ 2013-12-06 8:57 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <1386160133-24026-16-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++++++++++++++++++++++++
> 1 file changed, 102 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 298e85020e1b..51a79756e67e 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -409,3 +409,105 @@
> &usbhsehci {
> phys = <&hsusb1_phy>;
> };
> +
> +&dpi {
> + dpi_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + data-lines = <24>;
> + };
> +};
> +
> +&dsi1 {
> + vdds_dsi-supply = <&vcxio>;
> +};
> +
> +&dsi2 {
> + vdds_dsi-supply = <&vcxio>;
> +};
> +
> +&hdmi {
> + vdda_hdmi_dac-supply = <&vdac>;
> +
> + hdmi_out: endpoint {
> + remote-endpoint = <&tpd12s015_in>;
> + };
> +};
> +
> +/ {
> + aliases {
> + display0 = &dvi0;
> + display1 = &hdmi0;
> + };
> +
> + tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&gpio1 0 0>; /* 0, power-down */
> +
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@1 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + dvi0: connector@0 {
> + compatible = "ti,dvi-connector";
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> +
> + tpd12s015: encoder@1 {
> + compatible = "ti,tpd12s015";
> +
> + gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
> + <&gpio2 9 0>, /* 41, LS OE */
> + <&gpio2 31 0>; /* 63, HPD */
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tpd12s015_in: endpoint@0 {
> + remote-endpoint = <&hdmi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tpd12s015_out: endpoint@1 {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + hdmi0: connector@1 {
> + compatible = "ti,hdmi-connector";
> +
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tpd12s015_out>;
> + };
> + };
> +};
> --
> 1.8.3.2
>
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
From: Javier Martinez Canillas @ 2013-12-06 8:41 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <1386160133-24026-19-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index fa532aaacc68..1ca1932d02aa 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -178,3 +178,70 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&dpi {
> + vdds_dsi-supply = <&vpll2>;
> +
> + dpi_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + data-lines = <24>;
> + };
> +};
> +
> +&venc {
> + vdda_dac-supply = <&vdac>;
> +
> + venc_out: endpoint {
> + remote-endpoint = <&tv_connector_in>;
> + };
> +};
> +
> +/ {
> + aliases {
> + display0 = &dvi0;
> + display1 = &tv0;
> + };
> +
> + tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&gpio5 10 0>; /* 170, power-down */
> +
Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
from 1 so gpio5 + 10 is GPIO 138.
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@1 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + dvi0: connector@0 {
> + compatible = "ti,dvi_connector";
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> +
> + tv0: connector@1 {
> + compatible = "ti,svideo_connector";
> +
> + tv_connector_in: endpoint {
> + remote-endpoint = <&venc_out>;
> + };
> + };
> +};
> --
> 1.8.3.2
>
Also I don't see the DSS pinmux set for this board. I guess you need
something like the following on top:
0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
Best regards,
Javier
^ permalink raw reply
* Re: [PATCHv13][ 2/4] video: imxfb: Also add p =?UTF-8?B?d21yIGZvciB0aGUgZ
From: Alexander Shiyan @ 2013-12-06 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131206081640.GZ24559@pengutronix.de>
PiBPbiBGcmksIERlYyAwNiwgMjAxMyBhdCAxMjowMzo1NFBNICswNDAwLCBBbGV4YW5kZXIgU2hp
eWFuIHdyb3RlOgouLi4KPiA+ID4gPiAgLSBmc2wsZG1hY3I6IERNQSBDb250cm9sIFJlZ2lzdGVy
IHZhbHVlLiBUaGlzIGlzIG9wdGlvbmFsLiBCeSBkZWZhdWx0LCB0aGUKPiA+ID4gPiAgCXJlZ2lz
dGVyIGlzIG5vdCBtb2RpZmllZCBhcyByZWNvbW1lbmRlZCBieSB0aGUgZGF0YXNoZWV0Lgo+ID4g
PiA+ICstIGZzbCxwd21yOiAgTENEQyBQV00gQ29udHJhc3QgQ29udHJvbCBSZWdpc3RlciB2YWx1
ZS4gVGhhdCBwcm9wZXJ0eSBpcwo+ID4gPiA+ICsJb3B0aW9uYWwsIGJ1dCBkZWZpbmluZyBpdCBp
cyBuZWNlc3NhcnkgdG8gZ2V0IHRoZSBiYWNrbGlnaHQgd29ya2luZy4gSWYgdGhhdAo+ID4gPiA+
ICsJcHJvcGVydHkgaXMgb21taXRlZCwgdGhlIHJlZ2lzdGVyIGlzIHplcm9lZC4KPiA+ID4gCj4g
PiA+IFdoeSBpc24ndCB0aGlzIGltcGxlbWVudGVkIGFzIGEgYmFja2xpZ2h0IGRyaXZlcj8gU3Rh
dGljIGRldmljZXRyZWUKPiA+ID4gcHJvdmlkZWQgdmFsdWVzIGlzIHZlcnkgbGltaXRpbmcuCj4g
PiAKPiA+IExldCdzIHVuZGVyc3RhbmQgdGhlIHRlcm1pbm9sb2d5Lgo+ID4gVGhpcyByZWdpc3Rl
ciBzaG91bGQgYmUgcmVuYW1lZCBhY2NvcmRpbmcgdG8gdGhlIGRhdGFzaGVldCwgaS5lLiBMUEND
Ui4KPiA+IEFzIEkgcG9pbnRlZCBvdXQgZWFybGllciwgaXQgaXMgTk9UIGNvbnRyb2wgdGhlIGJh
Y2tsaWdodCwgdGhpcyBpcyBhIGNvbnRyYXN0IGNvbnRyb2wuCj4gPiBZZXMsIGl0IHdvcmtzIGFz
IFBXTSwgYnV0IG5vdGhpbmcgZG8gd2l0aCB0aGUgYmFja2xpZ2h0IHN1YnN5c3RlbS4KPiA+IFll
cywgd2UgY2FuIG1ha2UgYSBkcml2ZXIgZm9yIHRoaXMgUFdNLCBidXQgaG93IGFyZSB3ZSBnb2lu
ZyB0byBjb250cm9sIGl0Pwo+ID4gSSBtaXN1bmRlcnN0b29kIHNvbWV0aGluZz8KPiAKPiBJIHN0
dW1ibGVkIHVwb24gJ2dldCB0aGUgYmFja2xpZ2h0IHdvcmtpbmcnIHdoaWNoIGltcGxpZWQgZm9y
IG1lIHRoYXQgaXQKPiBzaG91bGQgYmUgYSBiYWNrbGlnaHQgZHJpdmVyLiBCdXQgeW91J3JlIHJp
Z2h0IGFuZCBub3cgSSByZW1lbWJlciB3ZQo+IHRhbGtlZCBhYm91dCB0aGlzIGFscmVhZHkuCgpI
YWxsZWx1amFoLgoKPiBJIHN0aWxsIHRoaW5rIHRoaXMgc2hvdWxkIGJlIHNvbWV0aGluZyBhZGp1
c3RhYmxlLCBub3Qgc3RhdGljIGRhdGEuCj4gTWF5YmUgd2UgY291bGQgY2hhbmdlIHRoZSB3b3Jk
aW5nIHRvIHNvbWV0aGluZyBsaWtlICJUaGlzIHByb3BlcnR5Cj4gcHJvdmlkZXMgdGhlIGRlZmF1
bHQgdmFsdWUgZm9yIHRoZSBjb250cmFzdCBjb250cm9sIHJlZ2lzdGVyIiBzaW5jZSBldmVuCj4g
aWYgd2UgYWRkIGRyaXZlciBzdXBwb3J0IGZvciBjb250cm9sbGluZyB0aGUgY29udHJhc3Qgd2Ug
c3RpbGwgd2FudAo+IHRvIGhhdmUgYSBzYW5lIGRlZmF1bHQuCgpTb3VuZHMgZ29vZC4KCj4gQlRX
IHRoZSBjb250cmFzdCBjb3VsZCBiZSBjb250cm9sbGVkIHdpdGggYSBsY2RfZGV2aWNlIChzZWUK
PiBsY2RfZGV2aWNlX3JlZ2lzdGVyKSB3aGljaCBzZWVtcyB0byBiZSB2ZXJ5IGVhc3kgdG8gaW1w
bGVtZW50LgoKQWRkcmVzcyBvZiByZWdpc3RlciBpcyBwbGFjZWQgd2l0aGluIExDRCBhcmVhLCBz
byB3ZSBjYW5ub3QgdXNlIHRoaXMKbWVtb3J5IHJlZ2lvbiwgSSB0aGluayBpcyBubyBzbyBlYXN5
IGFzIHlvdSBzYXkuLi4uCgotLS0K
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox