* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Olof Johansson @ 2016-11-21 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUhpeiOj6Mjhgt=9R3yuV-HwOAy5AAsDSTDjagRRDtYCw@mail.gmail.com>
On Mon, Nov 21, 2016 at 8:27 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Olof,
>
> On Mon, Nov 21, 2016 at 5:19 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Mon, Nov 21, 2016 at 1:31 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Nov 19, 2016 at 2:28 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
>>>>> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>>>
>>>>> * Basic support for r8a7745 SoC
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Sergei Shtylyov (2):
>>>>> ARM: shmobile: r8a7745: basic SoC support
>>>>> ARM: shmobile: document SK-RZG1E board
>>>>
>>>> Is there a reason you're adding a config option per SoC?
>>>>
>>>> I think you'd be better off not adding these config options, and just adding
>>>> support for the SoCs through compatibles (and adding the drivers to defconfigs,
>>>> etc).
>>>
>>> Yes there is a reason: kernel size.
>>> The main offenders are the pinctrl tables, which add ca. 20-50 KiB per
>>> supported SoC.
>>
>> So don't turn on that pinctrl driver unless you have that SoC?
>
> The enablement of the pinctrl driver (and the clock driver, FWIW) is controlled
> by the SoC Kconfig symbol. If you want support for the SoC, you want the
> pinctrl driver, too.
>
Oh, that's trivial to fix! Do as almost all other SoCs do, and don't
use silent options.
-Olof
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-21 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F927053@lhreml507-mbx>
On Mon, Nov 21, 2016 at 08:52:52AM +0000, Gabriele Paoloni wrote:
> Hi Bjorn
>
> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> > Sent: 18 November 2016 17:54
> > To: Gabriele Paoloni
> > Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> > acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> > Subject: Re: [PATCH] PCI: Add information about describing PCI in ACPI
> >
> > On Fri, Nov 18, 2016 at 05:17:34PM +0000, Gabriele Paoloni wrote:
> > > > -----Original Message-----
> > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > > owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> > > > Sent: 17 November 2016 18:00
> >
> > > > +Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms
> > for
> > > > +reserving address space! The static tables are for things the OS
> > > > +needs to know early in boot, before it can parse the ACPI
> > namespace.
> > > > +If a new table is defined, an old OS needs to operate correctly
> > even
> > > > +though it ignores the table. _CRS allows that because it is
> > generic
> > > > +and understood by the old OS; a static table does not.
> > >
> > > Right so if my understanding is correct you are saying that resources
> > > described in the MCFG table should also be declared in PNP0C02
> > devices
> > > so that the PNP driver can reserve these resources.
> >
> > Yes.
> >
> > > On the other side the PCI Root bridge driver should not reserve such
> > > resources.
> > >
> > > Well if my understanding is correct I think we have a problem here:
> > > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L74
> > >
> > > As you can see pci_ecam_create() will conflict with the pnp driver
> > > as it will try to reserve the resources from the MCFG table...
> > >
> > > Maybe we need to rework pci_ecam_create() ?
> >
> > I think it's OK as it is.
> >
> > The pnp/system.c driver does try to reserve PNP0C02 resources, and it
> > marks them as "not busy". That way they appear in /proc/iomem and
> > won't be allocated for anything else, but they can still be requested
> > by drivers, e.g., pci/ecam.c, which will mark them "busy".
> >
> > This is analogous to what the PCI core does in pci_claim_resource().
> > This is really a function of the ACPI/PNP *core*, which should reserve
> > all _CRS resources for all devices (not just PNP0C02 devices). But
> > it's done by pnp/system.c, and only for PNP0C02, because there's a
> > bunch of historical baggage there.
> >
> > You'll also notice that in this case, things are out of order:
> > logically the pnp/system.c reservation should happen first, but in
> > fact the pci/ecam.c request happens *before* the pnp/system.c one.
> > That means the pnp/system.c one might fail and complain "[mem ...]
> > could not be reserved".
>
> Correct me if I am wrong...
>
> So currently we are relying on the fact that pci_ecam_create() is called
> before the pnp driver.
> If the pnp driver came first we would end up in pci_ecam_create() failing
> here:
> http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L76
>
> I am not sure but it seems to me like a bit weak condition to rely on...
> what about removing the error condition in pci_ecam_create() and logging
> just a dev_info()?
Huh. I'm confused. I *thought* it would be safe to reverse the
order, which would effectively be this:
system_pnp_probe
reserve_resources_of_dev
reserve_range
request_mem_region([mem 0xb0000000-0xb1ffffff])
...
pci_ecam_create
request_resource_conflict([mem 0xb0000000-0xb1ffffff])
but I experimented with the patch below on qemu, and it failed as you
predicted:
** res test **
requested [mem 0xa0000000-0xafffffff]
can't claim ECAM area [mem 0xa0000000-0xafffffff]: conflict with ECAM PNP [mem 0xa0000000-0xafffffff]
I expected the request_resource_conflict() to succeed since it's
completely contained in the "ECAM PNP" region. But I guess I don't
understand kernel/resource.c well enough.
I'm not sure we need to fix anything yet, since we currently do the
ecam.c request before the system.c one, and any change there would be
a long ways off. If/when that *does* change, I think the correct fix
would be to change ecam.c so its request succeeds (by changing the way
it does the request, fixing kernel/resource.c, or whatever) rather
than to reduce the log level and ignore the failure.
Bjorn
diff --git a/arch/x86/pci/init.c b/arch/x86/pci/init.c
index adb62aa..5a35638 100644
--- a/arch/x86/pci/init.c
+++ b/arch/x86/pci/init.c
@@ -7,6 +7,8 @@
in the right sequence from here. */
static __init int pci_arch_init(void)
{
+ struct resource *res, *conflict;
+ static struct resource cfg;
#ifdef CONFIG_PCI_DIRECT
int type = 0;
@@ -39,6 +41,26 @@ static __init int pci_arch_init(void)
dmi_check_skip_isa_align();
+ printk("\n** res test **\n");
+
+ res = request_mem_region(0xa0000000, 0x10000000, "ECAM PNP");
+ printk("requested %pR\n", res);
+ if (!res)
+ return 0;
+ res->flags &= ~IORESOURCE_BUSY;
+
+ cfg.start = 0xa0000000;
+ cfg.end = 0xafffffff;
+ cfg.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+ cfg.name = "PCI ECAM";
+
+ conflict = request_resource_conflict(&iomem_resource, &cfg);
+ if (conflict)
+ printk("can't claim ECAM area %pR: conflict with %s %pR\n",
+ &cfg, conflict->name, conflict);
+
+ printk("\n");
+
return 0;
}
arch_initcall(pci_arch_init);
^ permalink raw reply related
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Andrew Lunn @ 2016-11-21 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479744993.17538.85.camel@baylibre.com>
> What I did not realize when doing this patch for the realtek driver is
> that there is already 6 valid modes defined in the kernel
>
> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
> 100TX EEE cap */
> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
> 1000T EEE cap */
> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
> */
> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
> */
> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
> */
>
> I took care of only 2 in the case of realtek.c since it only support
> MDIO_EEE_100TX and MDIO_EEE_1000T.
>
> Defining a property for each is certainly doable but it does not look
> very nice either. If it extends in the future, it will get even more
> messier, especially if you want to disable everything.
Yes, agreed.
> What do you think about keeping a single mask value but use the define
> above in the DT ? It would be more readable than hex and easy to
> extend, don't you think ?
>
> These defines are already part of the uapi so I guess we can use those
> in the DT bindings ?
I don't think they are accessible from the dtc include path. You will
need to make a copy, in include/dt-bindings/net/phy.h
But yes, using these defines is a good idea.
Andrew
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Bartosz Golaszewski @ 2016-11-21 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a309a738-7fa7-3aab-4457-f7d693e6b37f@ti.com>
2016-11-21 17:33 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>> +{
>> + const struct da8xx_ddrctl_config_knob *knob;
>> + const struct da8xx_ddrctl_setting *setting;
>> + struct device_node *node;
>> + struct resource *res;
>> + void __iomem *ddrctl;
>> + struct device *dev;
>> + u32 reg;
>> +
>> + dev = &pdev->dev;
>> + node = dev->of_node;
>> +
>> + setting = da8xx_ddrctl_get_board_settings();
>> + if (!setting) {
>> + dev_err(dev, "no settings for board '%s'\n",
>> + of_flat_dt_get_machine_name());
>> + return -EINVAL;
>> + }
>
> This causes a section mismatch because of_flat_dt_get_machine_name()
> has an __init annotation. I did not notice that before, sorry.
>
> It can be fixed with a patch like below:
>
> ---8<---
> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
> index a20e7bbbcbe0..9ca5aab3ac54 100644
> --- a/drivers/memory/da8xx-ddrctl.c
> +++ b/drivers/memory/da8xx-ddrctl.c
> @@ -102,6 +102,18 @@ static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
> return NULL;
> }
>
> +static const char* da8xx_ddrctl_get_machine_name(void)
> +{
> + const char *str;
> + int ret;
> +
> + ret = of_property_read_string(of_root, "model", &str);
> + if (ret)
> + ret = of_property_read_string(of_root, "compatible", &str);
> +
> + return str;
> +}
> +
> static int da8xx_ddrctl_probe(struct platform_device *pdev)
> {
> const struct da8xx_ddrctl_config_knob *knob;
> @@ -118,7 +130,7 @@ static int da8xx_ddrctl_probe(struct platform_device *pdev)
> setting = da8xx_ddrctl_get_board_settings();
> if (!setting) {
> dev_err(dev, "no settings for board '%s'\n",
> - of_flat_dt_get_machine_name());
> + da8xx_ddrctl_get_machine_name());
> return -EINVAL;
> }
> ---8<---
>
> A similar fix is required for the other driver in this series (patch
> 2/5). I need some advise on whether I should introduce a common
> function to get the machine name post kernel boot-up (I cannot see an
> existing one). If yes, any advise on which file it should go into?
>
Hi Sekhar,
thanks for spotting that.
I think we should introduce this function right away, rather than
having two static functions doing the same thing. If you don't mind,
I'll try to find a good spot for it and send a follow-up series fixing
the issue.
Best regards,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-21 16:49 UTC (permalink / raw)
To: linux-arm-kernel
UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
and uart pins along power in one connector and are found on most,
if not all, Olimex boards.
The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
those two connectors.
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 36 ++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
index 23aacce..e879c119 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -116,6 +116,18 @@
};
};
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
&lradc {
vref-supply = <®_vcc3v0>;
status = "okay";
@@ -284,12 +296,36 @@
status = "okay";
};
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins_a>,
+ <&spi1_cs0_pins_a>;
+};
+
+&spi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pins_a>,
+ <&spi2_cs0_pins_a>;
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+&uart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart6_pins_a>;
+ status = "okay";
+};
+
+&uart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart7_pins_a>;
+ status = "okay";
+};
+
&usb_otg {
dr_mode = "otg";
status = "okay";
--
2.9.2
^ permalink raw reply related
* [RESEND PATCH 0/3] ARM: davinci: OHCI: Use a regulator instead of callbacks
From: Axel Haslam @ 2016-11-21 16:53 UTC (permalink / raw)
To: linux-arm-kernel
With the ultimate goal to able to probe the ohci driver form DT,
convert users of OHCI pdata to use a regulator instead of
passing platform function pointers. This will help to remove the
platform callbacks in a future series.
These patches were included in previous series[1], im sending them again
to claify that it should go through the devinci tree, and to update
the dependencies.
[1] https://www.spinics.net/lists/linux-usb/msg148884.html
DEPENDENCIES:
1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
https://lkml.org/lkml/2016/11/21/558
2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
https://lkml.org/lkml/2016/11/4/465
3. [PATCH v2 0/3] davinci: ohci: fix usb ohci device name
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1263999.html
Axel Haslam (3):
ARM: davinci: da830: Handle vbus with a regulator
ARM: davinci: hawk: Remove vbus and over current gpios
ARM: davinci: remove ohci platform usage
arch/arm/mach-davinci/board-da830-evm.c | 108 ++++++++++------------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 99 ++-----------------------
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 3 +-
4 files changed, 44 insertions(+), 168 deletions(-)
--
2.9.3
^ permalink raw reply
* [RESEND PATCH 1/3] ARM: davinci: da830: Handle vbus with a regulator
From: Axel Haslam @ 2016-11-21 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165349.29128-1-ahaslam@baylibre.com>
The usb driver can now take a regulator instead of the platform
callbacks for vbus handling. Lets use a regulator so we can remove
the callbacks in a later patch.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 108 +++++++++++---------------------
1 file changed, 38 insertions(+), 70 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 5db0901..16a401a 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -14,6 +14,7 @@
#include <linux/console.h>
#include <linux/interrupt.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
#include <linux/i2c/pcf857x.h>
@@ -28,6 +29,7 @@
#include <linux/platform_data/spi-davinci.h>
#include <linux/platform_data/usb-davinci.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -38,72 +40,48 @@
#include <mach/da8xx.h>
#define DA830_EVM_PHY_ID ""
-/*
- * USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
- */
-#define ON_BD_USB_DRV GPIO_TO_PIN(1, 15)
-#define ON_BD_USB_OVC GPIO_TO_PIN(2, 4)
static const short da830_evm_usb11_pins[] = {
DA830_GPIO1_15, DA830_GPIO2_4,
-1
};
-static da8xx_ocic_handler_t da830_evm_usb_ocic_handler;
-
-static int da830_evm_usb_set_power(unsigned port, int on)
-{
- gpio_set_value(ON_BD_USB_DRV, on);
- return 0;
-}
+static struct regulator_consumer_supply usb_ohci_consumer_supply =
+ REGULATOR_SUPPLY("vbus", "ohci-da8xx");
-static int da830_evm_usb_get_power(unsigned port)
-{
- return gpio_get_value(ON_BD_USB_DRV);
-}
-
-static int da830_evm_usb_get_oci(unsigned port)
-{
- return !gpio_get_value(ON_BD_USB_OVC);
-}
-
-static irqreturn_t da830_evm_usb_ocic_irq(int, void *);
-
-static int da830_evm_usb_ocic_notify(da8xx_ocic_handler_t handler)
-{
- int irq = gpio_to_irq(ON_BD_USB_OVC);
- int error = 0;
-
- if (handler != NULL) {
- da830_evm_usb_ocic_handler = handler;
-
- error = request_irq(irq, da830_evm_usb_ocic_irq,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
- "OHCI over-current indicator", NULL);
- if (error)
- pr_err("%s: could not request IRQ to watch over-current indicator changes\n",
- __func__);
- } else
- free_irq(irq, NULL);
-
- return error;
-}
+static struct regulator_init_data usb_ohci_initdata = {
+ .consumer_supplies = &usb_ohci_consumer_supply,
+ .num_consumer_supplies = 1,
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+};
-static struct da8xx_ohci_root_hub da830_evm_usb11_pdata = {
- .set_power = da830_evm_usb_set_power,
- .get_power = da830_evm_usb_get_power,
- .get_oci = da830_evm_usb_get_oci,
- .ocic_notify = da830_evm_usb_ocic_notify,
+static struct fixed_voltage_config usb_ohci_config = {
+ .supply_name = "vbus",
+ .microvolts = 5000000,
+ .gpio = GPIO_TO_PIN(1, 15),
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = &usb_ohci_initdata,
+};
- /* TPS2065 switch @ 5V */
- .potpgt = (3 + 1) / 2, /* 3 ms max */
+static struct platform_device da8xx_usb11_regulator = {
+ .name = "reg-fixed-voltage",
+ .id = 0,
+ .dev = {
+ .platform_data = &usb_ohci_config,
+ },
};
-static irqreturn_t da830_evm_usb_ocic_irq(int irq, void *dev_id)
-{
- da830_evm_usb_ocic_handler(&da830_evm_usb11_pdata, 1);
- return IRQ_HANDLED;
-}
+static struct gpiod_lookup_table usb11_gpios_table = {
+ .dev_id = "reg-fixed-voltage.0",
+ .table = {
+ /* gpio chip 1 contains gpio range 32-63 */
+ GPIO_LOOKUP("davinci_gpio.1", 4, "over-current",
+ GPIO_ACTIVE_LOW),
+ },
+};
static __init void da830_evm_usb_init(void)
{
@@ -145,23 +123,13 @@ static __init void da830_evm_usb_init(void)
return;
}
- ret = gpio_request(ON_BD_USB_DRV, "ON_BD_USB_DRV");
- if (ret) {
- pr_err("%s: failed to request GPIO for USB 1.1 port power control: %d\n",
- __func__, ret);
- return;
- }
- gpio_direction_output(ON_BD_USB_DRV, 0);
+ gpiod_add_lookup_table(&usb11_gpios_table);
- ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC");
- if (ret) {
- pr_err("%s: failed to request GPIO for USB 1.1 port over-current indicator: %d\n",
- __func__, ret);
- return;
- }
- gpio_direction_input(ON_BD_USB_OVC);
+ ret = platform_device_register(&da8xx_usb11_regulator);
+ if (ret)
+ pr_warn("fail to add ohci regulator\n");
- ret = da8xx_register_usb11(&da830_evm_usb11_pdata);
+ ret = da8xx_register_usb11(NULL);
if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
}
--
2.9.3
^ permalink raw reply related
* [RESEND PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios
From: Axel Haslam @ 2016-11-21 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165349.29128-1-ahaslam@baylibre.com>
The hawk board VBUS is fixed to a 5v source, and the over
current pin is actually not connected to the SoC.
Do not reseve these gpios for OHCI as they are not related
to usb.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 99 ++---------------------------
1 file changed, 4 insertions(+), 95 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a4e8726..a252404 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -28,9 +28,6 @@
#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12)
#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
-#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
-#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
-
static short omapl138_hawk_mii_pins[] __initdata = {
DA850_MII_TXEN, DA850_MII_TXCLK, DA850_MII_COL, DA850_MII_TXD_3,
DA850_MII_TXD_2, DA850_MII_TXD_1, DA850_MII_TXD_0, DA850_MII_RXER,
@@ -181,76 +178,10 @@ static __init void omapl138_hawk_mmc_init(void)
gpio_free(DA850_HAWK_MMCSD_CD_PIN);
}
-static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
-static da8xx_ocic_handler_t hawk_usb_ocic_handler;
-
-static const short da850_hawk_usb11_pins[] = {
- DA850_GPIO2_4, DA850_GPIO6_13,
- -1
-};
-
-static int hawk_usb_set_power(unsigned port, int on)
-{
- gpio_set_value(DA850_USB1_VBUS_PIN, on);
- return 0;
-}
-
-static int hawk_usb_get_power(unsigned port)
-{
- return gpio_get_value(DA850_USB1_VBUS_PIN);
-}
-
-static int hawk_usb_get_oci(unsigned port)
-{
- return !gpio_get_value(DA850_USB1_OC_PIN);
-}
-
-static int hawk_usb_ocic_notify(da8xx_ocic_handler_t handler)
-{
- int irq = gpio_to_irq(DA850_USB1_OC_PIN);
- int error = 0;
-
- if (handler != NULL) {
- hawk_usb_ocic_handler = handler;
-
- error = request_irq(irq, omapl138_hawk_usb_ocic_irq,
- IRQF_TRIGGER_RISING |
- IRQF_TRIGGER_FALLING,
- "OHCI over-current indicator", NULL);
- if (error)
- pr_err("%s: could not request IRQ to watch "
- "over-current indicator changes\n", __func__);
- } else {
- free_irq(irq, NULL);
- }
- return error;
-}
-
-static struct da8xx_ohci_root_hub omapl138_hawk_usb11_pdata = {
- .set_power = hawk_usb_set_power,
- .get_power = hawk_usb_get_power,
- .get_oci = hawk_usb_get_oci,
- .ocic_notify = hawk_usb_ocic_notify,
- /* TPS2087 switch @ 5V */
- .potpgt = (3 + 1) / 2, /* 3 ms max */
-};
-
-static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id)
-{
- hawk_usb_ocic_handler(&omapl138_hawk_usb11_pdata, 1);
- return IRQ_HANDLED;
-}
-
static __init void omapl138_hawk_usb_init(void)
{
int ret;
- ret = davinci_cfg_reg_list(da850_hawk_usb11_pins);
- if (ret) {
- pr_warn("%s: USB 1.1 PinMux setup failed: %d\n", __func__, ret);
- return;
- }
-
ret = da8xx_register_usb20_phy_clk(false);
if (ret)
pr_warn("%s: USB 2.0 PHY CLK registration failed: %d\n",
@@ -266,34 +197,12 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB PHY registration failed: %d\n",
__func__, ret);
- ret = gpio_request_one(DA850_USB1_VBUS_PIN,
- GPIOF_DIR_OUT, "USB1 VBUS");
- if (ret < 0) {
- pr_err("%s: failed to request GPIO for USB 1.1 port "
- "power control: %d\n", __func__, ret);
- return;
- }
-
- ret = gpio_request_one(DA850_USB1_OC_PIN,
- GPIOF_DIR_IN, "USB1 OC");
- if (ret < 0) {
- pr_err("%s: failed to request GPIO for USB 1.1 port "
- "over-current indicator: %d\n", __func__, ret);
- goto usb11_setup_oc_fail;
- }
-
- ret = da8xx_register_usb11(&omapl138_hawk_usb11_pdata);
- if (ret) {
- pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
- goto usb11_setup_fail;
- }
+ ret = da8xx_register_usb11(NULL);
+ if (ret)
+ pr_warn("%s: USB 1.1 registration failed: %d\n",
+ __func__, ret);
return;
-
-usb11_setup_fail:
- gpio_free(DA850_USB1_OC_PIN);
-usb11_setup_oc_fail:
- gpio_free(DA850_USB1_VBUS_PIN);
}
static __init void omapl138_hawk_init(void)
--
2.9.3
^ permalink raw reply related
* [RESEND PATCH 3/3] ARM: davinci: remove ohci platform usage
From: Axel Haslam @ 2016-11-21 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165349.29128-1-ahaslam@baylibre.com>
As all users of ohci platform data have been converted
to use a regulator, we dont need to pass platform
data to register the ohci device anymore.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 3 +--
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 16a401a..cb67885 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -129,7 +129,7 @@ static __init void da830_evm_usb_init(void)
if (ret)
pr_warn("fail to add ohci regulator\n");
- ret = da8xx_register_usb11(NULL);
+ ret = da8xx_register_usb11();
if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n", __func__, ret);
}
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a252404..cbe7324 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -197,7 +197,7 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB PHY registration failed: %d\n",
__func__, ret);
- ret = da8xx_register_usb11(NULL);
+ ret = da8xx_register_usb11();
if (ret)
pr_warn("%s: USB 1.1 registration failed: %d\n",
__func__, ret);
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 85ff218..b21ef07 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -91,7 +91,7 @@ int da8xx_register_spi_bus(int instance, unsigned num_chipselect);
int da8xx_register_watchdog(void);
int da8xx_register_usb_phy(void);
int da8xx_register_usb20(unsigned mA, unsigned potpgt);
-int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
+int da8xx_register_usb11(void);
int da8xx_register_usb_refclkin(int rate);
int da8xx_register_usb20_phy_clk(bool use_usb_refclkin);
int da8xx_register_usb11_phy_clk(bool use_usb_refclkin);
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index c6feecf..4ea91bb 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -119,9 +119,8 @@ static struct platform_device da8xx_usb11_device = {
.resource = da8xx_usb11_resources,
};
-int __init da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata)
+int __init da8xx_register_usb11(void)
{
- da8xx_usb11_device.dev.platform_data = pdata;
return platform_device_register(&da8xx_usb11_device);
}
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: Axel Haslam @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
This adds the DT node for the ohci controller and
enables it for the omapl138-lckd platform.
DEPENDENCIES:
1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
https://lkml.org/lkml/2016/11/21/558
2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
https://lkml.org/lkml/2016/11/4/465
Axel Haslam (2):
ARM: dts: da850: Add usb device node
ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 8 ++++++++
2 files changed, 16 insertions(+)
--
2.9.3
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: Add usb device node
From: Axel Haslam @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-1-ahaslam@baylibre.com>
Add the usb1 device node for the da850 soc.
This will allow boards to use the usb1 port
when booting through DT.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..fbd50d6 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -406,6 +406,14 @@
>;
status = "disabled";
};
+ usb1: usb at 225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio at 226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
From: Axel Haslam @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-1-ahaslam@baylibre.com>
Enable the usb1 controller (ohci) and phy for the lcdk board
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..a739603 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -86,6 +86,14 @@
};
};
+&usb_phy {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
&serial2 {
pinctrl-names = "default";
pinctrl-0 = <&serial2_rxtx_pins>;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 1/5] drm: sun8i: Add a basic DRM driver for Allwinner DE2
From: Rob Herring @ 2016-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff2140c86ea3b06406c77d9e8746474b6f8400c4.1479641523.git.moinejf@free.fr>
On Sun, Nov 20, 2016 at 10:53:25AM +0100, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../bindings/display/sunxi/sun8i-de2.txt | 83 +++
It's preferred to split bindings to a separate patch.
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/sun8i/Kconfig | 19 +
> drivers/gpu/drm/sun8i/Makefile | 7 +
> drivers/gpu/drm/sun8i/de2_crtc.c | 440 +++++++++++++
> drivers/gpu/drm/sun8i/de2_crtc.h | 50 ++
> drivers/gpu/drm/sun8i/de2_drm.h | 48 ++
> drivers/gpu/drm/sun8i/de2_drv.c | 379 +++++++++++
> drivers/gpu/drm/sun8i/de2_plane.c | 712 +++++++++++++++++++++
> 10 files changed, 1741 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> create mode 100644 drivers/gpu/drm/sun8i/Kconfig
> create mode 100644 drivers/gpu/drm/sun8i/Makefile
> create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_crtc.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_drm.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_drv.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_plane.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt b/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> new file mode 100644
> index 0000000..b9edd4b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun8i-de2.txt
> @@ -0,0 +1,83 @@
> +Allwinner sun8i Display Engine 2 subsystem
> +==========================================
> +
> +The Allwinner DE2 subsystem contains a display controller (DE2),
> +one or two LCD controllers (TCON) and their external interfaces.
> +
> +Display controller
> +==================
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "allwinner,sun8i-a83t-display-engine"
> + "allwinner,sun8i-h3-display-engine"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + "gate": DE bus gate
> + "clock": DE clock
> +
> +- resets: phandle to the reset of the device
> +
> +- ports: phandle's to the LCD ports
This should use OF graph to describe the connection from the DE to the
LCD controllers like the sun4i binding does.
No registers for the DE?
> +
> +LCD controller
> +==============
> +
> +Required properties:
> +
> +- compatible: should be
> + "allwinner,sun8i-a83t-tcon"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + "gate": TCON bus gate
> + "clock": TCON pixel clock
> +
> +- resets: phandle to the reset of the device
> +
> +- port: port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
Need to specify how many ports and endpoints.
> +
> +Example:
> +
> + de: de-controller at 01000000 {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + ...
What are you not showing?
> + clocks = <&&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
> + clock-names = "gate", "clock";
> + resets = <&ccu RST_BUS_DE>;
> + ports = <&lcd0_p>;
> + };
> +
> + lcd0: lcd-controller at 01c0c000 {
> + compatible = "allwinner,sun8i-a83t-tcon";
> + ...
ditto.
> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
> + clock-names = "gate", "clock";
> + resets = <&ccu RST_BUS_TCON0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcd0_p: port {
> + lcd0_ep: endpoint {
> + remote-endpoint = <&hdmi_ep>;
> + };
> + };
> + };
> +
> + hdmi: hdmi at 01ee0000 {
> + ...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port {
> + hdmi_ep: endpoint {
> + remote-endpoint = <&lcd0_ep>;
> + };
> + };
> + };
> +
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: Enable OHCI as module
From: Axel Haslam @ 2016-11-21 17:01 UTC (permalink / raw)
To: linux-arm-kernel
Enable the davinci ohci driver as a module for usb
tested with the omap138-lcdk hawk board.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..b9bbbbd 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -157,6 +157,7 @@ CONFIG_HID_SONY=m
CONFIG_HID_SUNPLUS=m
CONFIG_USB=m
CONFIG_USB_MON=m
+CONFIG_USB_OHCI_HCD=m
CONFIG_USB_STORAGE=m
CONFIG_USB_MUSB_HDRC=m
CONFIG_MUSB_PIO_ONLY=y
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: davinvi: da850 add ohci DT nodes
From: David Lechner @ 2016-11-21 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121165920.29809-1-ahaslam@baylibre.com>
On 11/21/2016 10:59 AM, Axel Haslam wrote:
> This adds the DT node for the ohci controller and
> enables it for the omapl138-lckd platform.
>
> DEPENDENCIES:
>
> 1. [PATCH v6 0/5] USB: ohci-da8xx: Add device tree support
> https://lkml.org/lkml/2016/11/21/558
>
> 2. [PATCH v3 0/2] regulator: handling of error conditions for usb drivers
> https://lkml.org/lkml/2016/11/4/465
>
> Axel Haslam (2):
> ARM: dts: da850: Add usb device node
> ARM: dts: da850-lcdk: Enable ohci for omapl138 lcdk
>
> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 2 files changed, 16 insertions(+)
>
It does not look like you rebased these patches. Sekhar pushed the musb
counterpart to v4.10/dt yesterday, which will cause conflicts with this
series.
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v4.10/dt
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-21 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-2-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> This commit renames the gxl-s905d-p23x DTSI in a common file for
> S905D p20x and S912 q20x boards.
>
> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.txt | 6 +
> arch/arm64/boot/dts/amlogic/Makefile | 2 +
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 190 +++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 19 +++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 7 +
> .../boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 +-
> .../boot/dts/amlogic/meson-gxl-s905d-p231.dts | 3 +-
> .../boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi | 188 --------------------
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 77 +++++++++
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 58 +++++++
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 114 +++++++++++++
> 11 files changed, 477 insertions(+), 190 deletions(-)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> delete mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p23x.dtsi
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
Applied.
Git tip: for future reference, set 'git config diff.renames true' so and
the diffstat shows a better summary when files are moved/renamed.
e.g, rather than the large ++ and -- above, you'd see:
...gxl-s905d-p23x.dtsi => meson-gx-p23x-q20x.dtsi} | 4 +-
Which is much more comforting to a maintainer than a bunch of
(potentially unrelated) adds and removes.
Thanks,
Kevin
^ permalink raw reply
* [PATCH v6 2/5] drm: sun8i: add HDMI video support to A83T and H3
From: Rob Herring @ 2016-11-21 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cea6a5397664213c6a917028ec2e429d25972490.1479641523.git.moinejf@free.fr>
On Sun, Nov 20, 2016 at 10:56:23AM +0100, Jean-Francois Moine wrote:
> This patch adds a HDMI video driver to the Allwinner's SoCs A83T and H3.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> .../devicetree/bindings/display/sunxi/hdmi.txt | 53 ++
> drivers/gpu/drm/sun8i/Kconfig | 7 +
> drivers/gpu/drm/sun8i/Makefile | 2 +
> drivers/gpu/drm/sun8i/de2_hdmi.c | 394 ++++++++++
> drivers/gpu/drm/sun8i/de2_hdmi.h | 51 ++
> drivers/gpu/drm/sun8i/de2_hdmi_io.c | 839 +++++++++++++++++++++
> 6 files changed, 1346 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.c
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi.h
> create mode 100644 drivers/gpu/drm/sun8i/de2_hdmi_io.c
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/hdmi.txt b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> new file mode 100644
> index 0000000..85709ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/hdmi.txt
> @@ -0,0 +1,53 @@
> +Allwinner HDMI Transmitter
> +==========================
> +
> +The Allwinner HDMI transmitters are included in the SoCs.
> +They support audio and video.
> +
> +Required properties:
> + - #address-cells : should be <1>
> + - #size-cells : should be <0>
> + - compatible : should be one of
> + "allwinner,sun8i-a83t-hdmi"
> + "allwinner,sun8i-h3-hdmi"
> + - clocks : phandles to the HDMI clocks as described in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + - clock-names : must be
> + "gate" : bus gate
> + "clock" : streaming clock
> + "ddc-clock" : DDC clock
> + - resets : One or two phandles to the HDMI resets
> + - reset-names : when 2 phandles, must be
> + "hdmi0" and "hdmi1"
> +
> +Required nodes:
> + - port: Audio and video input port nodes with endpoint definitions
> + as defined in Documentation/devicetree/bindings/graph.txt.
> + port at 0 is video and port at 1 is audio.
This should probably also have an output port to the hdmi-connector
binding. It is not needed so much if this block handles DDC and HPD
itself, but if those are a separate I2C controller and GPIO,
respectively, then you need it for sure. There's also power on the
connector or other connectors like muxed on Type-C.
> +
> +Example:
> +
> + hdmi: hdmi at 01ee0000 {
> + compatible = "allwinner,sun8i-a83t-hdmi";
> + reg = <0x01ee0000 0x20000>;
> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
> + <&ccu CLK_HDMI_DDC>;
> + clock-names = "gate", "clock", "ddc-clock";
> + resets = <&ccu RST_HDMI0>, <&ccu RST_HDMI1>;
> + reset-names = "hdmi0", "hdmi1";
> + ...
Please show all properties in example.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 0 { /* video */
> + reg = <0>;
> + hdmi_lcd1: endpoint {
> + remote-endpoint = <&lcd1_hdmi>;
> + };
> + };
> + port at 1 { /* audio */
> + reg = <1>;
> + hdmi_i2s2: endpoint {
> + remote-endpoint = <&i2s2_hdmi>;
> + };
> + };
> + };
^ permalink raw reply
* [PATCH v2 3/3] usb: ohci-da8xx: rename driver to ohci-da8xx
From: Axel Haslam @ 2016-11-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103160308.29588-4-ahaslam@baylibre.com>
Hi Greg,
On Thu, Nov 3, 2016 at 5:03 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> The davinci ohci driver name (currently "ohci") is too generic.
> To be consistent with other usb dirvers, append the "-da8xx" postfix
> to the name.
>
if there are no objections, would it be possible to pick up this patch?
the corresponding phy patch was merged and the platform changes
are ack'ed, and will we taken by the davinci maintainer once this patch
gets in.
i can resend stand-alone if its preferred.
Regards
Axel
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> drivers/usb/host/ohci-da8xx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index 30c4878..429d58b 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -27,7 +27,7 @@
> #include "ohci.h"
>
> #define DRIVER_DESC "DA8XX"
> -#define DRV_NAME "ohci"
> +#define DRV_NAME "ohci-da8xx"
>
> static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
>
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH 0/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-21 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162905.14285-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The new Amlogic GXM SoC (S912) is part of the Meson GX family and is nearly
> identical to GXM but with a second Quad-A53 core cluster.
>
> The GXM dtsi includes the GXL dtsi and the p20x dtsi is refactored in a
> common p20x/q20x to support the GXM Q200 and Q201 board that uses the exact
> same board layout since the S905D and S912 are pinout compatible.
>
> The last patch adds support for the Nexbox A1 Set-Top-Box based on the S912.
>
> Changes since RFC :
> - Refactor the p20x/q20x dtsi into a single common file
> - Add support for Nexbox A1
Thanks for refactoring. Looks great.
Applied.
Kevin
^ permalink raw reply
* [PATCH v4 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC
From: Rob Herring @ 2016-11-21 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479638740-20520-2-git-send-email-hao5781286@gmail.com>
On Sun, Nov 20, 2016 at 06:45:38PM +0800, Hao Zhang wrote:
> This add the property of Allwinner sun50i A64 dma.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
While debugging the drm_bridge support for revision 1 I noticed the
driver was selecting the 1024x768 resolution as default from the set
retrieved from EDID. The following patch reduces the max_width for
rev1 in tilcdc.
Bartosz Golaszewski (1):
drm: tilcdc: reduce max_width for revision 1
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Bartosz Golaszewski @ 2016-11-21 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479748590-3962-1-git-send-email-bgolaszewski@baylibre.com>
It has been determined that the highest resolution supported correctly
by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
crtc_max_width().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index dfe3dd0..9081de5 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -683,7 +683,7 @@ int tilcdc_crtc_max_width(struct drm_crtc *crtc)
int max_width = 0;
if (priv->rev == 1)
- max_width = 1024;
+ max_width = 800;
else if (priv->rev == 2)
max_width = 2048;
--
2.9.3
^ permalink raw reply related
* [PATCH] coresight: perf: Add a missing call to etm_free_aux
From: Mathieu Poirier @ 2016-11-21 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119174124.20136-1-lambert.quentin@gmail.com>
On Sat, Nov 19, 2016 at 06:41:24PM +0100, Quentin Lambert wrote:
> Most error branches following the call to alloc_event_data contain a call to
> etm_free_aux. This patch add a call to etm_free_aux to an error branch
> that does not call it.
>
> This issue was found with Hector.
>
> Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
> ---
> drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -215,7 +215,7 @@ static void *etm_setup_aux(int event_cpu
> */
> sink = coresight_get_enabled_sink(true);
> if (!sink)
> - return NULL;
> + goto err;
>
> INIT_WORK(&event_data->work, free_event_data);
>
Applied, after wrapping the commit log to 75 characters or less.
Please run checkpatch.pl on your next submission and compiling
your work before sending a patches is highly suggested.
Thanks,
Mathieu
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Gabriele Paoloni @ 2016-11-21 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121164700.GL25762@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn
> -----Original Message-----
> From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-
> owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> Sent: 21 November 2016 16:47
> To: Gabriele Paoloni
> Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> Subject: Re: [PATCH] PCI: Add information about describing PCI in ACPI
>
> On Mon, Nov 21, 2016 at 08:52:52AM +0000, Gabriele Paoloni wrote:
> > Hi Bjorn
> >
> > > -----Original Message-----
> > > From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> > > Sent: 18 November 2016 17:54
> > > To: Gabriele Paoloni
> > > Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; linux-
> > > acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > > kernel at lists.infradead.org; linaro-acpi at lists.linaro.org
> > > Subject: Re: [PATCH] PCI: Add information about describing PCI in
> ACPI
> > >
> > > On Fri, Nov 18, 2016 at 05:17:34PM +0000, Gabriele Paoloni wrote:
> > > > > -----Original Message-----
> > > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > > > owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> > > > > Sent: 17 November 2016 18:00
> > >
> > > > > +Static tables like MCFG, HPET, ECDT, etc., are *not*
> mechanisms
> > > for
> > > > > +reserving address space! The static tables are for things the
> OS
> > > > > +needs to know early in boot, before it can parse the ACPI
> > > namespace.
> > > > > +If a new table is defined, an old OS needs to operate
> correctly
> > > even
> > > > > +though it ignores the table. _CRS allows that because it is
> > > generic
> > > > > +and understood by the old OS; a static table does not.
> > > >
> > > > Right so if my understanding is correct you are saying that
> resources
> > > > described in the MCFG table should also be declared in PNP0C02
> > > devices
> > > > so that the PNP driver can reserve these resources.
> > >
> > > Yes.
> > >
> > > > On the other side the PCI Root bridge driver should not reserve
> such
> > > > resources.
> > > >
> > > > Well if my understanding is correct I think we have a problem
> here:
> > > > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L74
> > > >
> > > > As you can see pci_ecam_create() will conflict with the pnp
> driver
> > > > as it will try to reserve the resources from the MCFG table...
> > > >
> > > > Maybe we need to rework pci_ecam_create() ?
> > >
> > > I think it's OK as it is.
> > >
> > > The pnp/system.c driver does try to reserve PNP0C02 resources, and
> it
> > > marks them as "not busy". That way they appear in /proc/iomem and
> > > won't be allocated for anything else, but they can still be
> requested
> > > by drivers, e.g., pci/ecam.c, which will mark them "busy".
> > >
> > > This is analogous to what the PCI core does in
> pci_claim_resource().
> > > This is really a function of the ACPI/PNP *core*, which should
> reserve
> > > all _CRS resources for all devices (not just PNP0C02 devices). But
> > > it's done by pnp/system.c, and only for PNP0C02, because there's a
> > > bunch of historical baggage there.
> > >
> > > You'll also notice that in this case, things are out of order:
> > > logically the pnp/system.c reservation should happen first, but in
> > > fact the pci/ecam.c request happens *before* the pnp/system.c one.
> > > That means the pnp/system.c one might fail and complain "[mem ...]
> > > could not be reserved".
> >
> > Correct me if I am wrong...
> >
> > So currently we are relying on the fact that pci_ecam_create() is
> called
> > before the pnp driver.
> > If the pnp driver came first we would end up in pci_ecam_create()
> failing
> > here:
> > http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L76
> >
> > I am not sure but it seems to me like a bit weak condition to rely
> on...
> > what about removing the error condition in pci_ecam_create() and
> logging
> > just a dev_info()?
>
> Huh. I'm confused. I *thought* it would be safe to reverse the
> order, which would effectively be this:
>
> system_pnp_probe
> reserve_resources_of_dev
> reserve_range
> request_mem_region([mem 0xb0000000-0xb1ffffff])
> ...
> pci_ecam_create
> request_resource_conflict([mem 0xb0000000-0xb1ffffff])
>
>
> but I experimented with the patch below on qemu, and it failed as you
> predicted:
>
> ** res test **
> requested [mem 0xa0000000-0xafffffff]
> can't claim ECAM area [mem 0xa0000000-0xafffffff]: conflict with ECAM
> PNP [mem 0xa0000000-0xafffffff]
>
> I expected the request_resource_conflict() to succeed since it's
> completely contained in the "ECAM PNP" region. But I guess I don't
> understand kernel/resource.c well enough.
I think it fails because effectively the PNP driver is populating the
iomem_resource resource tree and therefore pci_ecam_create() finds that
it cannot add the cfg resource to the same hierarchy as it is already
there...
>
> I'm not sure we need to fix anything yet, since we currently do the
> ecam.c request before the system.c one, and any change there would be
> a long ways off. If/when that *does* change, I think the correct fix
> would be to change ecam.c so its request succeeds (by changing the way
> it does the request, fixing kernel/resource.c, or whatever) rather
> than to reduce the log level and ignore the failure.
Well in my mind I didn't want just to make the error disappear...
If all the resources should be reserved by the PNP driver then ideally
we could take away request_resource_conflict() from pci_ecam_create(),
but this would make buggy some systems with an already shipped BIOS
that relied on pci_ecam_create() reservation rather than PNP reservation.
Just removing the error condition and converting dev_err() into
dev_info() seems to me like accommodating already shipped BIOS images
and flagging a reservation that is already done by somebody else
without compromising the functionality of the PCI Root bridge driver
(so far the only reason why I can see the error condition there is
to catch a buggy MCFG with overlapping addresses; so if this is the
case maybe we need to have a different diagnostic check to make sure
that the MCFG table is alright)
BTW if you think that so far we can keep this as it is I am ok.
Many Thanks
Gab
>
> Bjorn
>
>
> diff --git a/arch/x86/pci/init.c b/arch/x86/pci/init.c
> index adb62aa..5a35638 100644
> --- a/arch/x86/pci/init.c
> +++ b/arch/x86/pci/init.c
> @@ -7,6 +7,8 @@
> in the right sequence from here. */
> static __init int pci_arch_init(void)
> {
> + struct resource *res, *conflict;
> + static struct resource cfg;
> #ifdef CONFIG_PCI_DIRECT
> int type = 0;
>
> @@ -39,6 +41,26 @@ static __init int pci_arch_init(void)
>
> dmi_check_skip_isa_align();
>
> + printk("\n** res test **\n");
> +
> + res = request_mem_region(0xa0000000, 0x10000000, "ECAM PNP");
> + printk("requested %pR\n", res);
> + if (!res)
> + return 0;
> + res->flags &= ~IORESOURCE_BUSY;
> +
> + cfg.start = 0xa0000000;
> + cfg.end = 0xafffffff;
> + cfg.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + cfg.name = "PCI ECAM";
> +
> + conflict = request_resource_conflict(&iomem_resource, &cfg);
> + if (conflict)
> + printk("can't claim ECAM area %pR: conflict with %s %pR\n",
> + &cfg, conflict->name, conflict);
> +
> + printk("\n");
> +
> return 0;
> }
> arch_initcall(pci_arch_init);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] drm: tilcdc: reduce max_width for revision 1
From: Jyri Sarha @ 2016-11-21 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479748590-3962-2-git-send-email-bgolaszewski@baylibre.com>
On 11/21/16 19:16, Bartosz Golaszewski wrote:
> It has been determined that the highest resolution supported correctly
> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
> crtc_max_width().
>
I don't think this is the right way to limit the supported video modes.
There is technically there is no such limit, is there?
If memory bandwidth is limiting the functionality of higher resolutions,
you should use "max-bandwidth" tilcdc device-tree property [1].
Cheers,
Jyri
[1] In "Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt":
Optional properties:
- max-bandwidth: The maximum pixels per second that the memory
interface / lcd controller combination can sustain
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index dfe3dd0..9081de5 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -683,7 +683,7 @@ int tilcdc_crtc_max_width(struct drm_crtc *crtc)
> int max_width = 0;
>
> if (priv->rev == 1)
> - max_width = 1024;
> + max_width = 800;
> else if (priv->rev == 2)
> max_width = 2048;
>
>
^ 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