Re: [PATCH 06/19] input: tegra-kbc: enable support for the standard "wakeup-source" property
On Wed, Oct 21, 2015 at 11:10:03AM +0100, Sudeep Holla wrote:
> Though the mmc core driver should/will continue to support the legacy
> "nvidia,wakeup-source" property to enable SDIO as the wakeup source, we
> need to add support for the new standard property "wakeup-source".
>
> This patch adds support for "wakeup-source" property in addition to the
> existing "nvidia,wakeup-source" property.
>
> Cc: Laxman Dewangan
> Cc: Dmitry Torokhov
> Cc: Thierry Reding
> Cc: linux-in...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Sudeep Holla
Applied, thank you.
> ---
> drivers/input/keyboard/tegra-kbc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/tegra-kbc.c
> b/drivers/input/keyboard/tegra-kbc.c
> index f97c73bd14f8..f80c72d4ac8f 100644
> --- a/drivers/input/keyboard/tegra-kbc.c
> +++ b/drivers/input/keyboard/tegra-kbc.c
> @@ -517,7 +517,8 @@ static int tegra_kbc_parse_dt(struct tegra_kbc *kbc)
> if (of_find_property(np, "nvidia,needs-ghost-filter", NULL))
> kbc->use_ghost_filter = true;
>
> - if (of_find_property(np, "nvidia,wakeup-source", NULL))
> + if (of_property_read_bool(np, "wakeup-source") ||
> + of_property_read_bool(np, "nvidia,wakeup-source")) /* legacy */
> kbc->wakeup = true;
>
> if (!of_get_property(np, "nvidia,kbc-row-pins", &proplen)) {
> --
> 1.9.1
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 3/6] pci:host: Add Altera PCIe host controller driver
On Fri, Oct 23, 2015 at 1:31 PM, Bjorn Helgaas wrote:
> Hi Ley,
>
> On Thu, Oct 22, 2015 at 05:27:28PM +0800, Ley Foon Tan wrote:
>> This patch adds the Altera PCIe host controller driver.
>
>> +static void altera_pcie_fixups(struct pci_bus *bus)
>> +{
>> + struct pci_dev *dev;
>> +
>> + list_for_each_entry(dev, &bus->devices, bus_list) {
>> + altera_pcie_retrain(dev);
>> + altera_pcie_fixup_res(dev);
>> + }
>> +}
>
> I'd really like to avoid this particular fixup because it's done
> between pci_scan_root_bus() and pci_assign_unassigned_bus_resources()
> and pci_bus_add_devices(). That path is almost 100% arch-independent,
> and someday we should be able to pull all that out into one PCI core
> interface.
>
> You might be able to do the link retrain fixup as a header quirk.
> That's not really ideal either, but I don't think we have a good
> mechanism of inserting per-host bridge hooks in the enumeration path.
> There are some pcibios_*() hooks, but those are per-arch, not per-host
> bridge, so they're not really what you want here.
Okay, will change the retrain fixup to use *PCI_FIXUP* macro.
By doing this, we need [PATCH v11 2/6] pci: add Altera PCI vendor ID patch.
>
> I think other host drivers have handled the "prevent enumeration of
> root complex resources" problem by adding a similar check in the
> config accessors.
Okay, will handle this in config accessors.
>
>> +static int altera_pcie_cfg_write(struct pci_bus *bus, unsigned int devfn,
>> + int where, int size, u32 value)
>
> This needs a comment to the effect that this hardware can only generate
> 32-bit config accesses. We also need a printk in the probe routine so
> there's a note in dmesg so we have a clue that RW1C bits in config space
> may be corrupted.
I have checked the PCIe/TLP spec, we can use the "First BE" (byte
enable) field in TLP packet to write
specific bytes only. And I have update driver to support this "First
BE" feature.
So, we don't have corrupted RW1C bit issue now.
>
>> +{
>> + struct altera_pcie *pcie = bus->sysdata;
>> + u32 data32;
>> + u32 shift = 8 * (where & 3);
>> + u8 byte_en;
>> +
>> + if (!altera_pcie_valid_config(pcie, bus, PCI_SLOT(devfn)))
>> + return PCIBIOS_DEVICE_NOT_FOUND;
>> +
>> + switch (size) {
>> + case 1:
>> + data32 = (value & 0xff) << shift;
>> + byte_en = 1 << (where & 3);
>> + break;
>> + case 2:
>> + data32 = (value & 0x) << shift;
>> + byte_en = 3 << (where & 3);
>> + break;
>> + default:
>> + data32 = value;
>> + byte_en = 0xf;
>> + break;
>> + }
>> +
>> + return tlp_cfg_dword_write(pcie, bus->number, devfn,
>> + (where & ~DWORD_MASK), byte_en, data32);
>> +}
>
>> +static void altera_pcie_isr(struct irq_desc *desc)
>> +{
>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>> + struct altera_pcie *pcie;
>> + unsigned long status;
>> + u32 bit;
>> + u32 virq;
>> +
>> + chained_irq_enter(chip, desc);
>> + pcie = irq_desc_get_handler_data(desc);
>> +
>> + while ((status = cra_readl(pcie, P2A_INT_STATUS)
>> + & P2A_INT_STS_ALL) != 0) {
>> + for_each_set_bit(bit, &status, INTX_NUM) {
>> + /* clear interrupts */
>> + cra_writel(pcie, 1 << bit, P2A_INT_STATUS);
>> +
>> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
>> + if (virq)
>> + generic_handle_irq(virq);
>> + else
>> + dev_err(&pcie->pdev->dev, "unexpected IRQ\n");
>
> Include the bit number here. A printk string with no % substitutions
> is rarely as useful as it could be.
Okay.
>
>> ...
>> + bus = pci_scan_root_bus(&pdev->dev, pcie->root_bus_nr,
>> &altera_pcie_ops,
>> + pcie, &pcie->resources);
>> + if (!bus)
>> + return -ENOMEM;
>> +
>> + altera_pcie_fixups(bus);
>> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
>> + pci_assign_unassigned_bus_resources(bus);
>> + pci_bus_add_devices(bus);
>> +
>> + /* Configure PCI Express setting. */
>> + list_for_each_entry(child, &bus->children, node)
>> + pcie_bus_configure_settings(child);
>
> This loop should be before pci_bus_add_devices(). When we call
> pci_bus_add_devices(), drivers may claim devices immediately, and the
> PCI core shouldn't be changing device configuration while a driver
> owns the device.
Okay, will move this before pci_bus_add_devices().
Thanks.
Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] dt-bindings: Consolidate SRAM bindings from all vendors
On Fri, Oct 23, 2015 at 10:39:19AM +0900, Krzysztof Kozlowski wrote: > SRAM bindings for various SoCs, using the mmio-sram genalloc > API, are spread over different places - per SoC vendor. Since all of > these are quite similar (they depend on mmio-sram) move them to a common > place. > > Signed-off-by: Krzysztof Kozlowski > Cc: Heiko Stuebner > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Kukjin Kim > Suggested-by: Rob Herring Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v4 0/4] simplefb: Add regulator handling support
On Fri, Oct 23, 2015 at 11:50:37AM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This is v4 of the simplefb regulator support series. This series adds > regulator claiming and enabling support for simplefb. > > Changes since v4: > - Fixed inverted logic when testing the property name. > - Fixed regulator supply name string copy length off by 1. > - Added real world user, MSI Primo 81 dts patches. > > Changes since v3: > - Dropped extra "if" which is always true, leftover from v1. > - Updated commit message of patch 1 > > Sometimes the simplefb display output path consits of external conversion > chips and/or LCD drivers and backlights. These devices normally have > GPIOs to turn them on and/or bring them out of reset, and regulators > supplying power to them. > > While the kernel does not touch unclaimed GPIOs, the regulator core > happily disables unused regulators. Thus we need simplefb to claim > and enable the regulators used throughout the display pipeline. > > The binding supports any named regulator supplies under its device > node. The driver will look through its properties, and claim any > regulators by matching "*-supply", as Mark suggested. > > I've not done a generic helper in the regulator core yet, instead doing > the regulator property handling in the simplefb code for now. > > > Patch 1 adds the regulator properties to the DT binding. > > Patch 2 adds code to the simplefb driver to claim and enable regulators. > Hans, I dropped your Reviewed-by tag from this patch. > > Patch 3 adds labels to the simplefb device nodes in sun6i-a31.dtsi > so we can reference them in the board dts files, like in the next > patch. > > Patch 4 adds a dts file for MSI's Primo 81 tablet. Applied 3 and 4. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] extcon: add MAX3355 driver
On 2015년 10월 21일 03:20, Sergei Shtylyov wrote:
> Hello.
>
> On 12/18/2014 12:58 AM, Sergei Shtylyov wrote:
>
MAX3355E chip integrates a charge pump and comparators to enable a system
with
an integrated USB OTG dual-role transceiver to function as a USB OTG
dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru
the
ID signal from the USB OTG connector. On some Renesas boards, this signal
is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller,
only
host and gadget USB controllers sharing the same USB bus; however, we'd
like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also
wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS#
signal
is controlled by the host controllers, there's also the SHDN# signal
wired to
GPIO, which should be high for normal operation.
>>
Signed-off-by: Sergei Shtylyov
>>
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>>
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
>>
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
>>
>>> Need manufactor information as following :
>>>-> Maxim MAX3355
>>
>> Would be Maxim enough? Or perhaps I should use Maxim Integrated
>> [Products]?
>
>You haven't replied to my questions.
>
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with
an
+integrated USB OTG dual-role transceiver to function as a USB OTG
dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
>>
>>> Kernel already supported the gpio helper function to get gpio from
>>> devicetree.
>>> I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
>>> include/linux/of_gpio.h.
>>
>>> gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
>>
>> OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
>> to insist on using this one...
>
>Moreover, it now says "gpios" isn't allowed for the new bindings. So I
> have to strongly disagree here...
OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
instead of using devm_gpio_request_one() directly as following:
You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.
For example,
data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);
>
> [...]
>
+static irqreturn_t max3355_id_irq(int irq, void *dev_id)
+{
+struct max3355_data *data = dev_id;
+int id = gpio_get_value(data->id_gpio);
+
+extcon_set_cable_state(data->edev, "USB-HOST", !id);
>>
>>> You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
>>> function
>>> and then you would set the cable state according to gpio state and flag.
>>
>> I'm sorry but I just don't see why I have to do it. This is not a generic
>> GPIO driver, and the polarities of the GPIOs are determined solely by the
>> MAX3355 specs.
>
>Again, got not reply...
OK. you don't need to consider the gpio flag from devicetree.
>
>> [...]
+static int max3355_probe(struct platform_device *pdev)
+{
+struct device_node *np = pdev->dev.of_node;
+struct max3355_data *data;
+int gpio, irq, ret;
+
+data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
+GFP_KERNEL);
+if (!data)
+return -ENOMEM;
+
+data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
+if (IS_ERR(data->edev)) {
+dev_err(&pdev->dev, "failed to allocate extcon device\n");
+
[PATCH v3 1/3] leds: rt5033: Add DT binding for RT5033
This patch adds the device tree bindings for RT5033 flash LEDs.
Signed-off-by: Ingi Kim
Acked-by: Rob Herring
---
.../devicetree/bindings/leds/leds-rt5033.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-rt5033.txt
b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
new file mode 100644
index 000..2ef7bdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
@@ -0,0 +1,38 @@
+* Richtek Technology Corporation - RT5033 Flash LED Driver
+
+The RT5033 Flash LED Circuit is designed for one or two LEDs driving
+for torch and strobe applications, it provides an I2C software command
+to trigger the torch and strobe operation.
+
+Required properties:
+- compatible : Must be "richtek,rt5033-led".
+
+A discrete LED element connected to the device must be represented by a child
+node - see Documentation/devicetree/bindings/leds/common.txt.
+
+Required properties of the LED child node:
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-max-microamp : Minimum Threshold for Timer protection
+ is defined internally (Maximum 200mA).
+- flash-max-microamp : Flash LED maximum current
+- flash-max-timeout-us : Flash LED maximum timeout
+
+Optional properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+rt5033 {
+ compatible = "richtek,rt5033";
+
+ led {
+ compatible = "richtek,rt5033-led";
+
+ flash-led {
+ label = "rt5033-flash";
+ led-max-microamp = <20>;
+ flash-max-microamp = <80>;
+ flash-max-timeout-us = <1216000>;
+ };
+ };
+}
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] leds: rt5033: Add RT5033 Flash led device driver
This patch adds device driver of Richtek RT5033 PMIC.
The driver supports a current regulated output to drive
white LEDs for camera flash.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-rt5033.c | 314 +
include/linux/mfd/rt5033-private.h | 49 ++
include/linux/mfd/rt5033.h | 13 ++
5 files changed, 385 insertions(+)
create mode 100644 drivers/leds/leds-rt5033.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 42990f2..29613e3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -345,6 +345,14 @@ config LEDS_PCA963X
LED driver chip accessed via the I2C bus. Supported
devices include PCA9633 and PCA9634
+config LEDS_RT5033
+ tristate "LED support for RT5033 PMIC"
+ depends on LEDS_CLASS_FLASH && OF
+ depends on MFD_RT5033
+ help
+ This option enables support for on-chip LED driver on
+ RT5033 PMIC.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index b503f92..bcc4d93 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE) += leds-sunfire.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
+obj-$(CONFIG_LEDS_RT5033) += leds-rt5033.o
obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
new file mode 100644
index 000..4ba1ec6
--- /dev/null
+++ b/drivers/leds/leds-rt5033.c
@@ -0,0 +1,314 @@
+/*
+ * led driver for RT5033
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Ingi Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RT5033_LED_FLASH_TIMEOUT_MIN 64000
+#define RT5033_LED_FLASH_TIMEOUT_STEP 32000
+#define RT5033_LED_FLASH_BRIGHTNESS_MIN5
+#define RT5033_LED_FLASH_BRIGHTNESS_STEP 25000
+#define RT5033_LED_TORCH_BRIGHTNESS_MIN12500
+#define RT5033_LED_TORCH_BRIGHTNESS_STEP 12500
+
+/* Macro to get offset of rt5033_led_config_data */
+#define RT5033_LED_CONFIG_DATA_OFFSET(val, step, min) (((val) - (min)) \
+ / (step))
+
+struct rt5033_led_config_data {
+ u32 flash_max_microamp;
+ u32 flash_max_timeout;
+ u32 torch_max_microamp;
+};
+
+static struct rt5033_led *flcdev_to_led(
+ struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct rt5033_led, fled_cdev);
+}
+
+static void rt5033_brightness_set(struct rt5033_led *led,
+ enum led_brightness brightness)
+{
+ mutex_lock(&led->lock);
+
+ if (!brightness) {
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
+ RT5033_FLED_FUNC2_MASK, 0x0);
+ } else {
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
+ RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL);
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_CTRL1,
+ RT5033_FLED_CTRL1_MASK,
+ (brightness - 1) << 4);
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
+ RT5033_FLED_FUNC2_MASK, RT5033_FLED_ENFLED);
+ }
+
+ mutex_unlock(&led->lock);
+}
+
+static void rt5033_brightness_set_work(struct work_struct *work)
+{
+ struct rt5033_led *led =
+ container_of(work, struct rt5033_led, work_brightness_set);
+
+ rt5033_brightness_set(led, led->torch_brightness);
+}
+
+static void rt5033_led_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
+ struct rt5033_led *led = flcdev_to_led(fled_cdev);
+
+ led->torch_brightness = brightness;
+ schedule_work(&led->work_brightness_set);
+}
+
+static int rt5033_led_brightness_set_sync(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
+ struct rt5033_l
[PATCH v3 0/3] Add RT5033 Flash LED driver
This patch supports flash led of RT5033 PMIC. Changes since v3: - Use mutex and work queue - Split brightness set func (sync / async) - Add flash API (flash_brightness_set) - Move struct(rt5033_led_config_data) to local area - Code clean Changes since v2: - Split MFC code from rt5033 flash led patch - Fix typo error - Change naming of mfd register back again - Fix compile error Ingi Kim (3): leds: rt5033: Add DT binding for RT5033 mfd: rt5033: Add RT5033 Flash led sub device leds: rt5033: Add RT5033 Flash led device driver .../devicetree/bindings/leds/leds-rt5033.txt | 38 +++ drivers/leds/Kconfig | 8 + drivers/leds/Makefile | 1 + drivers/leds/leds-rt5033.c | 314 + drivers/mfd/rt5033.c | 3 + include/linux/mfd/rt5033-private.h | 49 include/linux/mfd/rt5033.h | 13 + 7 files changed, 426 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt create mode 100644 drivers/leds/leds-rt5033.c -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] mfd: rt5033: Add RT5033 Flash led sub device
This patch adds rt5033-led sub device to support it.
Signed-off-by: Ingi Kim
Acked-by: Lee Jones
---
drivers/mfd/rt5033.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index d60f916..035421c 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -47,6 +47,9 @@ static const struct mfd_cell rt5033_devs[] = {
}, {
.name = "rt5033-battery",
.of_compatible = "richtek,rt5033-battery",
+ }, {
+ .name = "rt5033-led",
+ .of_compatible = "richtek,rt5033-led",
},
};
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 3/6] pci:host: Add Altera PCIe host controller driver
Hi Ley,
On Thu, Oct 22, 2015 at 05:27:28PM +0800, Ley Foon Tan wrote:
> This patch adds the Altera PCIe host controller driver.
> +static void altera_pcie_fixups(struct pci_bus *bus)
> +{
> + struct pci_dev *dev;
> +
> + list_for_each_entry(dev, &bus->devices, bus_list) {
> + altera_pcie_retrain(dev);
> + altera_pcie_fixup_res(dev);
> + }
> +}
I'd really like to avoid this particular fixup because it's done
between pci_scan_root_bus() and pci_assign_unassigned_bus_resources()
and pci_bus_add_devices(). That path is almost 100% arch-independent,
and someday we should be able to pull all that out into one PCI core
interface.
You might be able to do the link retrain fixup as a header quirk.
That's not really ideal either, but I don't think we have a good
mechanism of inserting per-host bridge hooks in the enumeration path.
There are some pcibios_*() hooks, but those are per-arch, not per-host
bridge, so they're not really what you want here.
I think other host drivers have handled the "prevent enumeration of
root complex resources" problem by adding a similar check in the
config accessors.
> +static int altera_pcie_cfg_write(struct pci_bus *bus, unsigned int devfn,
> + int where, int size, u32 value)
This needs a comment to the effect that this hardware can only generate
32-bit config accesses. We also need a printk in the probe routine so
there's a note in dmesg so we have a clue that RW1C bits in config space
may be corrupted.
> +{
> + struct altera_pcie *pcie = bus->sysdata;
> + u32 data32;
> + u32 shift = 8 * (where & 3);
> + u8 byte_en;
> +
> + if (!altera_pcie_valid_config(pcie, bus, PCI_SLOT(devfn)))
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +
> + switch (size) {
> + case 1:
> + data32 = (value & 0xff) << shift;
> + byte_en = 1 << (where & 3);
> + break;
> + case 2:
> + data32 = (value & 0x) << shift;
> + byte_en = 3 << (where & 3);
> + break;
> + default:
> + data32 = value;
> + byte_en = 0xf;
> + break;
> + }
> +
> + return tlp_cfg_dword_write(pcie, bus->number, devfn,
> + (where & ~DWORD_MASK), byte_en, data32);
> +}
> +static void altera_pcie_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct altera_pcie *pcie;
> + unsigned long status;
> + u32 bit;
> + u32 virq;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> +
> + while ((status = cra_readl(pcie, P2A_INT_STATUS)
> + & P2A_INT_STS_ALL) != 0) {
> + for_each_set_bit(bit, &status, INTX_NUM) {
> + /* clear interrupts */
> + cra_writel(pcie, 1 << bit, P2A_INT_STATUS);
> +
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(&pcie->pdev->dev, "unexpected IRQ\n");
Include the bit number here. A printk string with no % substitutions
is rarely as useful as it could be.
> ...
> + bus = pci_scan_root_bus(&pdev->dev, pcie->root_bus_nr, &altera_pcie_ops,
> + pcie, &pcie->resources);
> + if (!bus)
> + return -ENOMEM;
> +
> + altera_pcie_fixups(bus);
> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> + pci_assign_unassigned_bus_resources(bus);
> + pci_bus_add_devices(bus);
> +
> + /* Configure PCI Express setting. */
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
This loop should be before pci_bus_add_devices(). When we call
pci_bus_add_devices(), drivers may claim devices immediately, and the
PCI core shouldn't be changing device configuration while a driver
owns the device.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = &ctrl->controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
This patch also fixes use of node labels in ns2-svk.dts.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
- soc: soc {
- i2c0: i2c@6608 {
- status = "ok";
- };
+&i2c0 {
+ status = "ok";
+};
- i2c1: i2c@660b {
- status = "ok";
- };
+&i2c1 {
+ status = "ok";
+};
+
+&uart3 {
+ status = "ok";
+};
- uart3: serial@6613 {
- status = "ok";
- };
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v3 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 -- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 9 + 3 files changed, 43 insertions(+), 10 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] phy: phy_brcmstb_sata: add support 40nm platforms
2015-10-22 18:44 GMT-07:00 Jaedon Shin :
> Add offsets for 40nm BMIPS based set-top box platforms.
>
> Signed-off-by: Jaedon Shin
> ---
> drivers/phy/phy-brcmstb-sata.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
> index 41c7535d706b..1cc80743b1b6 100644
> --- a/drivers/phy/phy-brcmstb-sata.c
> +++ b/drivers/phy/phy-brcmstb-sata.c
> @@ -30,7 +30,8 @@
> #define MAX_PORTS 2
>
> /* Register offset between PHYs in PCB space */
> -#define SATA_MDIO_REG_SPACE_SIZE 0x1000
> +#define SATA_MDIO_REG_28NM_SPACE_SIZE 0x1000
> +#define SATA_MDIO_REG_40NM_SPACE_SIZE 0x10
>
> struct brcm_sata_port {
> int portnum;
> @@ -47,7 +48,7 @@ struct brcm_sata_phy {
> struct brcm_sata_port phys[MAX_PORTS];
> };
>
> -enum sata_mdio_phy_regs_28nm {
> +enum sata_mdio_phy_regs {
> PLL_REG_BANK_0 = 0x50,
> PLL_REG_BANK_0_PLLCONTROL_0 = 0x81,
>
> @@ -85,7 +86,7 @@ static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank,
> u32 ofs,
> #define FMAX_VAL_DEFAULT 0x3df
> #define FMAX_VAL_SSC 0x83
>
> -static void brcm_sata_cfg_ssc_28nm(struct brcm_sata_port *port)
> +static void brcm_sata_cfg_ssc(struct brcm_sata_port *port)
> {
> void __iomem *base = brcm_sata_phy_base(port);
> struct brcm_sata_phy *priv = port->phy_priv;
> @@ -116,19 +117,25 @@ static int brcm_sata_phy_init(struct phy *phy)
> {
> struct brcm_sata_port *port = phy_get_drvdata(phy);
>
> - brcm_sata_cfg_ssc_28nm(port);
> + brcm_sata_cfg_ssc(port);
>
> return 0;
> }
>
> -static const struct phy_ops phy_ops_28nm = {
> +static const struct phy_ops phy_ops = {
> .init = brcm_sata_phy_init,
> .owner = THIS_MODULE,
> };
>
> static const struct of_device_id brcm_sata_phy_of_match[] = {
> { .compatible = "brcm,bcm7445-sata-phy",
> - .data = (void *)SATA_MDIO_REG_SPACE_SIZE },
> + .data = (void *)SATA_MDIO_REG_28NM_SPACE_SIZE },
> + { .compatible = "brcm,bcm7346-sata-phy",
> + .data = (void *)SATA_MDIO_REG_40NM_SPACE_SIZE },
> + { .compatible = "brcm,bcm7360-sata-phy",
> + .data = (void *)SATA_MDIO_REG_40NM_SPACE_SIZE },
> + { .compatible = "brcm,bcm7362-sata-phy",
> + .data = (void *)SATA_MDIO_REG_40NM_SPACE_SIZE },
Same comment as the AHCI portion, we need to update the Device Tree
binding document to make these new compatible strings documented
there.
Thank you!
> {},
> };
> MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
> @@ -185,7 +192,7 @@ static int brcm_sata_phy_probe(struct platform_device
> *pdev)
> port = &priv->phys[id];
> port->portnum = id;
> port->phy_priv = priv;
> - port->phy = devm_phy_create(dev, child, &phy_ops_28nm);
> + port->phy = devm_phy_create(dev, child, &phy_ops);
> port->ssc_en = of_property_read_bool(child,
> "brcm,enable-ssc");
> if (IS_ERR(port->phy)) {
> dev_err(dev, "failed to create PHY\n");
> --
> 2.6.2
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] phy: phy_brcmstb_sata: add data for phy offset
2015-10-22 18:44 GMT-07:00 Jaedon Shin :
> Add data of device node for phy offset.
Similar comment to the AHCI portion, we could just omit specifying the
offset in the of_device_id.data member, and just assume the current
offset if not defined.
Acked-by: Florian Fainelli
>
> Signed-off-by: Jaedon Shin
> ---
> drivers/phy/phy-brcmstb-sata.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
> index 0be55dafe9ea..41c7535d706b 100644
> --- a/drivers/phy/phy-brcmstb-sata.c
> +++ b/drivers/phy/phy-brcmstb-sata.c
> @@ -42,6 +42,7 @@ struct brcm_sata_port {
> struct brcm_sata_phy {
> struct device *dev;
> void __iomem *phy_base;
> + u32 phy_offset;
>
> struct brcm_sata_port phys[MAX_PORTS];
> };
> @@ -65,7 +66,7 @@ static inline void __iomem *brcm_sata_phy_base(struct
> brcm_sata_port *port)
> {
> struct brcm_sata_phy *priv = port->phy_priv;
>
> - return priv->phy_base + (port->portnum * SATA_MDIO_REG_SPACE_SIZE);
> + return priv->phy_base + (port->portnum * priv->phy_offset);
> }
>
> static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank, u32 ofs,
> @@ -126,7 +127,8 @@ static const struct phy_ops phy_ops_28nm = {
> };
>
> static const struct of_device_id brcm_sata_phy_of_match[] = {
> - { .compatible = "brcm,bcm7445-sata-phy" },
> + { .compatible = "brcm,bcm7445-sata-phy",
> + .data = (void *)SATA_MDIO_REG_SPACE_SIZE },
> {},
> };
> MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
> @@ -135,6 +137,7 @@ static int brcm_sata_phy_probe(struct platform_device
> *pdev)
> {
> struct device *dev = &pdev->dev;
> struct device_node *dn = dev->of_node, *child;
> + const struct of_device_id *of_id = NULL;
> struct brcm_sata_phy *priv;
> struct resource *res;
> struct phy_provider *provider;
> @@ -154,6 +157,12 @@ static int brcm_sata_phy_probe(struct platform_device
> *pdev)
> if (IS_ERR(priv->phy_base))
> return PTR_ERR(priv->phy_base);
>
> + of_id = of_match_node(brcm_sata_phy_of_match, dn);
> + if (!of_id)
> + return -EINVAL;
> +
> + priv->phy_offset = (u32)of_id->data;
> +
> for_each_available_child_of_node(dn, child) {
> unsigned int id;
> struct brcm_sata_port *port;
> --
> 2.6.2
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] phy: phy_brcmstb_sata: remove unused definitions
2015-10-22 18:44 GMT-07:00 Jaedon Shin : > Remove unused definitions. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > drivers/phy/phy-brcmstb-sata.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c > index 8a2cb16a1937..0be55dafe9ea 100644 > --- a/drivers/phy/phy-brcmstb-sata.c > +++ b/drivers/phy/phy-brcmstb-sata.c > @@ -26,8 +26,6 @@ > > #define SATA_MDIO_BANK_OFFSET 0x23c > #define SATA_MDIO_REG_OFFSET(ofs) ((ofs) * 4) > -#define SATA_MDIO_REG_SPACE_SIZE 0x1000 > -#define SATA_MDIO_REG_LENGTH 0x1f00 > > #define MAX_PORTS 2 > > -- > 2.6.2 > -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] phy: phy_brcmstb_sata: make the driver buildable on BMIPS_GENERIC
2015-10-22 18:44 GMT-07:00 Jaedon Shin : > The BCM7xxx ARM and MIPS platforms share a similar hardware block for AHCI > SATA3 PHY. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > drivers/phy/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 47da573d0bab..c83e48661fd7 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -364,11 +364,11 @@ config PHY_TUSB1210 > > config PHY_BRCMSTB_SATA > tristate "Broadcom STB SATA PHY driver" > - depends on ARCH_BRCMSTB > + depends on ARCH_BRCMSTB || BMIPS_GENERIC > depends on OF > select GENERIC_PHY > help > - Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs. > + Enable this to support the SATA3 PHY on 28nm or 40nm Broadcom STB > SoCs. > Likely useful only with CONFIG_SATA_BRCMSTB enabled. > > endmenu > -- > 2.6.2 > -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] ata: ahci_brcmstb: add support 40nm platforms
2015-10-22 18:44 GMT-07:00 Jaedon Shin :
> Add offsets for 40nm BMIPS based set-top box platforms.
>
> Signed-off-by: Jaedon Shin
> ---
> drivers/ata/ahci_brcmstb.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
> index 8cf6f7d4798f..59eb526cf4f6 100644
> --- a/drivers/ata/ahci_brcmstb.c
> +++ b/drivers/ata/ahci_brcmstb.c
> @@ -50,7 +50,8 @@
>#define SATA_TOP_CTRL_2_SW_RST_RXBIT(2)
>#define SATA_TOP_CTRL_2_SW_RST_TXBIT(3)
>#define SATA_TOP_CTRL_2_PHY_GLOBAL_RESET BIT(14)
> - #define SATA_TOP_CTRL_PHY_OFFS0x8
> + #define SATA_TOP_CTRL_28NM_PHY_OFFS 0x8
> + #define SATA_TOP_CTRL_40NM_PHY_OFFS 0x4
> #define SATA_TOP_MAX_PHYS 2
> #define SATA_TOP_CTRL_SATA_TP_OUT 0x1c
> #define SATA_TOP_CTRL_CLIENT_INIT_CTRL 0x20
> @@ -237,7 +238,13 @@ static int brcm_ahci_resume(struct device *dev)
>
> static const struct of_device_id ahci_of_match[] = {
> {.compatible = "brcm,bcm7445-ahci",
> - .data = (void *)SATA_TOP_CTRL_PHY_OFFS},
> + .data = (void *)SATA_TOP_CTRL_28NM_PHY_OFFS},
> + {.compatible = "brcm,bcm7346-ahci",
> + .data = (void *)SATA_TOP_CTRL_40NM_PHY_OFFS},
> + {.compatible = "brcm,bcm7360-ahci",
> + .data = (void *)SATA_TOP_CTRL_40NM_PHY_OFFS},
> + {.compatible = "brcm,bcm7362-ahci",
> + .data = (void *)SATA_TOP_CTRL_40NM_PHY_OFFS},
Since you are introducing new compatible strings, you also need to
update the binding document in Documentation/devicetree/bindings/ata/
We could just use the compatible string for the first 40nm chip that
started featuring such a SATA3 AHCI compliant core, which seems to be
7231. Apart from the existing known workarounds (disabling NCQ, tuning
the PHY) it seems to be largely identical across all 40nm chips.
This is fine either way, and more information cannot hurt, these are
all production chips, so we can actually look back at the history to
know everything about them.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ata: ahch_brcmstb: add data for port offset
2015-10-22 18:44 GMT-07:00 Jaedon Shin :
> Add data of device node for port offset.
Looks good to me, some minor nits below.
>
> Signed-off-by: Jaedon Shin
> ---
> drivers/ata/ahci_brcmstb.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
> index 14b7305d2ba0..8cf6f7d4798f 100644
> --- a/drivers/ata/ahci_brcmstb.c
> +++ b/drivers/ata/ahci_brcmstb.c
> @@ -72,6 +72,7 @@
> struct brcm_ahci_priv {
> struct device *dev;
> void __iomem *top_ctrl;
> + u32 port_offset;
> u32 port_mask;
> };
>
> @@ -110,7 +111,7 @@ static inline void brcm_sata_writereg(u32 val, void
> __iomem *addr)
> static void brcm_sata_phy_enable(struct brcm_ahci_priv *priv, int port)
> {
> void __iomem *phyctrl = priv->top_ctrl + SATA_TOP_CTRL_PHY_CTRL +
> - (port * SATA_TOP_CTRL_PHY_OFFS);
> + (port * priv->port_offset);
> void __iomem *p;
> u32 reg;
>
> @@ -139,7 +140,7 @@ static void brcm_sata_phy_enable(struct brcm_ahci_priv
> *priv, int port)
> static void brcm_sata_phy_disable(struct brcm_ahci_priv *priv, int port)
> {
> void __iomem *phyctrl = priv->top_ctrl + SATA_TOP_CTRL_PHY_CTRL +
> - (port * SATA_TOP_CTRL_PHY_OFFS);
> + (port * priv->port_offset);
> void __iomem *p;
> u32 reg;
>
> @@ -234,6 +235,13 @@ static int brcm_ahci_resume(struct device *dev)
> }
> #endif
>
> +static const struct of_device_id ahci_of_match[] = {
> + {.compatible = "brcm,bcm7445-ahci",
> + .data = (void *)SATA_TOP_CTRL_PHY_OFFS},
We could omit having to specify explicitly the offset here.
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ahci_of_match);
> +
> static struct scsi_host_template ahci_platform_sht = {
> AHCI_SHT(DRV_NAME),
> };
> @@ -241,6 +249,7 @@ static struct scsi_host_template ahci_platform_sht = {
> static int brcm_ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> + const struct of_device_id *of_id = NULL;
> struct brcm_ahci_priv *priv;
> struct ahci_host_priv *hpriv;
> struct resource *res;
> @@ -256,6 +265,12 @@ static int brcm_ahci_probe(struct platform_device *pdev)
> if (IS_ERR(priv->top_ctrl))
> return PTR_ERR(priv->top_ctrl);
>
> + of_id = of_match_node(ahci_of_match, dev->of_node);
> + if (!of_id)
> + return -EINVAL;
> +
> + priv->port_offset = (u32)of_id->data;
And if of_id->data is NULL here, just default to
SATA_TOP_CTRL_PHY_OFFS. But I have no strong preference.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] ata: ahci_brcmstb: make the driver buildable on BMIPS_GENERIC
2015-10-22 18:44 GMT-07:00 Jaedon Shin : > The BCM7xxx ARM and MIPS platforms share a similar hardware block for AHCI > SATA3. > > Signed-off-by: Jaedon Shin Acked-by: Florian Fainelli > --- > drivers/ata/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig > index 15e40ee62a94..8f535a88a0c7 100644 > --- a/drivers/ata/Kconfig > +++ b/drivers/ata/Kconfig > @@ -100,7 +100,7 @@ config SATA_AHCI_PLATFORM > > config AHCI_BRCMSTB > tristate "Broadcom STB AHCI SATA support" > - depends on ARCH_BRCMSTB > + depends on ARCH_BRCMSTB || BMIPS_GENERIC > help > This option enables support for the AHCI SATA3 controller found on > STB SoC's. > -- > 2.6.2 > -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] add support SATA for BMIPS_GENERIC
2015-10-22 20:58 GMT-07:00 Tejun Heo : > On Fri, Oct 23, 2015 at 10:44:13AM +0900, Jaedon Shin wrote: >> Hi all, >> >> This patch series adds support SATA for BMIPS_GENERIC. >> >> Ralf, >> I request you to drop already submitted patches for NAND device nodes. >> It is merge conflicts with this patches. >> http://patchwork.linux-mips.org/patch/10577/ >> http://patchwork.linux-mips.org/patch/10578/ >> http://patchwork.linux-mips.org/patch/10579/ >> http://patchwork.linux-mips.org/patch/10580/ >> >> Jaedon Shin (10): >> ata: ahci_brcmstb: make the driver buildable on BMIPS_GENERIC >> ata: ahch_brcmstb: add data for port offset >> ata: ahci_brcmstb: add support 40nm platforms > > ata part looks fine to me. Let me know when the other parts get in. > I'll apply the ata ones to libata/for-4.4. There are a few comments coming on the ATA and Device Tree part, and I also would like Brian Norris (who submitted the patches) to take a look at these. But overall, this looks great. I think we have a bit too many compatible strings defined, I need to lookup tomorrow when I am back in the office which BCM7xxx started featuring a SATA3 AHCI compliant core, it might be 7420, but I am not sure Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] add support SATA for BMIPS_GENERIC
On Fri, Oct 23, 2015 at 10:44:13AM +0900, Jaedon Shin wrote: > Hi all, > > This patch series adds support SATA for BMIPS_GENERIC. > > Ralf, > I request you to drop already submitted patches for NAND device nodes. > It is merge conflicts with this patches. > http://patchwork.linux-mips.org/patch/10577/ > http://patchwork.linux-mips.org/patch/10578/ > http://patchwork.linux-mips.org/patch/10579/ > http://patchwork.linux-mips.org/patch/10580/ > > Jaedon Shin (10): > ata: ahci_brcmstb: make the driver buildable on BMIPS_GENERIC > ata: ahch_brcmstb: add data for port offset > ata: ahci_brcmstb: add support 40nm platforms ata part looks fine to me. Let me know when the other parts get in. I'll apply the ata ones to libata/for-4.4. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Karsten Merker
The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND,
768x1024 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP
rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer
and rtl8188etv usb wifi. Has "power", "volume+" and "volume-" buttons
(both volume buttons are also connected to the UBOOT_SEL pin). The
external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
OTG and 3.5mm headphone jack.
USB OTG is enabled in host only mode. AXP221 USB power supply and
GPIO support are required for full USB OTG support.
Signed-off-by: Siarhei Siamashka
Signed-off-by: Karsten Merker
Signed-off-by: Chen-Yu Tsai
---
Changes since last submission (was part of Sinlinx SinA31s series)
- Update axp22x.dtsi file name
- Sort regulators
- Drop URL in commit message
- Drop comment for capacitive touch panel
- Add simplefb regulators
- Drop regulator-always-on for regulators that aren't critical
- Fix CPU and GPU regulator supply mix-up
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++
2 files changed, 256 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c00b72e750ab..78ade1a5e886 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-m9.dtb \
sun6i-a31-mele-a1000g-quad.dtb \
sun6i-a31s-cs908.dtb \
+ sun6i-a31s-primo81.dtb \
sun6i-a31s-sina31s.dtb \
sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
new file mode 100644
index ..2d4250b1faf8
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -0,0 +1,255 @@
+/*
+ * Copyright 2014 Siarhei Siamashka
+ * Copyright 2015 Karsten Merker
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun6i-a31s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "MSI Primo81 tablet";
+ compatible = "msi,primo81", "allwinner,sun6i-a31s";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc3>;
+};
+
+&ehci0 {
+ /* rtl8188etv wifi is connected here */
+ status = "okay";
+};
+
+&i2c0 {
+ /* pull-ups and device VDDIO use AXP221 DLDO3 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "failed";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+
+ ctp@5d {
+ pinctrl-names = "default";
+ pinctrl-0 = <>911_int_primo81>;
+ compatible = "goodix,gt911";
+ reg = <0x5d>;
+ interrupt-parent = <&pio>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
+ };
+};
+
+&i2c2
[PATCH v4 0/4] simplefb: Add regulator handling support
Hi everyone, This is v4 of the simplefb regulator support series. This series adds regulator claiming and enabling support for simplefb. Changes since v4: - Fixed inverted logic when testing the property name. - Fixed regulator supply name string copy length off by 1. - Added real world user, MSI Primo 81 dts patches. Changes since v3: - Dropped extra "if" which is always true, leftover from v1. - Updated commit message of patch 1 Sometimes the simplefb display output path consits of external conversion chips and/or LCD drivers and backlights. These devices normally have GPIOs to turn them on and/or bring them out of reset, and regulators supplying power to them. While the kernel does not touch unclaimed GPIOs, the regulator core happily disables unused regulators. Thus we need simplefb to claim and enable the regulators used throughout the display pipeline. The binding supports any named regulator supplies under its device node. The driver will look through its properties, and claim any regulators by matching "*-supply", as Mark suggested. I've not done a generic helper in the regulator core yet, instead doing the regulator property handling in the simplefb code for now. Patch 1 adds the regulator properties to the DT binding. Patch 2 adds code to the simplefb driver to claim and enable regulators. Hans, I dropped your Reviewed-by tag from this patch. Patch 3 adds labels to the simplefb device nodes in sun6i-a31.dtsi so we can reference them in the board dts files, like in the next patch. Patch 4 adds a dts file for MSI's Primo 81 tablet. Regards ChenYu Chen-Yu Tsai (3): dt-bindings: simplefb: Support regulator supply properties simplefb: Claim and enable regulators ARM: dts: sun6i: Add simplefb node labels to reference at board level Karsten Merker (1): ARM: dts: sun6i: Add dts file for MSI Primo81 tablet .../bindings/video/simple-framebuffer.txt | 13 +- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31.dtsi | 4 +- arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 + drivers/video/fbdev/simplefb.c | 120 +- 5 files changed, 386 insertions(+), 7 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] simplefb: Claim and enable regulators
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai
Acked-by: Mark Brown
---
drivers/video/fbdev/simplefb.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..48ccf6db62a2 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(&pdev->dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p == prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void s
[PATCH v4 1/4] dt-bindings: simplefb: Support regulator supply properties
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
.../devicetree/bindings/video/simple-framebuffer.txt| 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+ lcd-supply = <®_dc1sw>;
display = <&lcdc0>;
};
stdout-path = "display0";
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] ARM: dts: sun6i: Add simplefb node labels to reference at board level
Some boards, such as tablets, have regulators providing power to parts
of the display pipeline, like signal converters and LCD panels.
Add labels to the simplefb device nodes so that we can reference them
in the board dts files to add regulator supply properties.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 83c18798cae0..b6ad7850fac6 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -61,7 +61,7 @@
#size-cells = <1>;
ranges;
- framebuffer@0 {
+ simplefb_hdmi: framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
@@ -69,7 +69,7 @@
status = "disabled";
};
- framebuffer@1 {
+ simplefb_lcd: framebuffer@1 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] simplefb: Claim and enable regulators
On Fri, Oct 23, 2015 at 9:31 AM, Chen-Yu Tsai wrote:
> This claims and enables regulators listed in the simple framebuffer dt
> node. This is needed so that regulators powering the display pipeline
> and external hardware, described in the device node and known by the
> kernel code, will remain properly enabled.
>
> Signed-off-by: Chen-Yu Tsai
> Reviewed-by: Hans de Goede
> Acked-by: Mark Brown
> ---
> drivers/video/fbdev/simplefb.c | 120
> -
> 1 file changed, 119 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 52c5c7e63b52..9de34ee15ac0 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -28,7 +28,10 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> +#include
>
> static struct fb_fix_screeninfo simplefb_fix = {
> .id = "simple",
> @@ -174,6 +177,10 @@ struct simplefb_par {
> int clk_count;
> struct clk **clks;
> #endif
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> + u32 regulator_count;
> + struct regulator **regulators;
> +#endif
> };
>
> #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
> @@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par
> *par,
> static void simplefb_clocks_destroy(struct simplefb_par *par) { }
> #endif
>
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> +
> +#define SUPPLY_SUFFIX "-supply"
> +
> +/*
> + * Regulator handling code.
> + *
> + * Here we handle the num-supplies and vin*-supply properties of our
> + * "simple-framebuffer" dt node. This is necessary so that we can make sure
> + * that any regulators needed by the display hardware that the bootloader
> + * set up for us (and for which it provided a simplefb dt node), stay up,
> + * for the life of the simplefb driver.
> + *
> + * When the driver unloads, we cleanly disable, and then release the
> + * regulators.
> + *
> + * We only complain about errors here, no action is taken as the most likely
> + * error can only happen due to a mismatch between the bootloader which set
> + * up simplefb, and the regulator definitions in the device tree. Chances are
> + * that there are no adverse effects, and if there are, a clean teardown of
> + * the fb probe will not help us much either. So just complain and carry on,
> + * and hope that the user actually gets a working fb at the end of things.
> + */
> +static int simplefb_regulators_init(struct simplefb_par *par,
> + struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct property *prop;
> + struct regulator *regulator;
> + const char *p;
> + int count = 0, i = 0, ret;
> +
> + if (dev_get_platdata(&pdev->dev) || !np)
> + return 0;
> +
> + /* Count the number of regulator supplies */
> + for_each_property_of_node(np, prop) {
> + p = strstr(prop->name, SUPPLY_SUFFIX);
> + if (p && p != prop->name)
> + count++;
> + }
> +
> + if (!count)
> + return 0;
> +
> + par->regulators = devm_kcalloc(&pdev->dev, count,
> + sizeof(struct regulator *),
> GFP_KERNEL);
> + if (!par->regulators)
> + return -ENOMEM;
> +
> + /* Get all the regulators */
> + for_each_property_of_node(np, prop) {
> + char name[32]; /* 32 is max size of property name */
> +
> + p = strstr(prop->name, SUPPLY_SUFFIX);
> + if (p && p != prop->name)
Sorry, the test is completely reversed here.
> + continue;
> +
> + strlcpy(name, prop->name,
> + strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
And string length is off by 1 due to using sizeof here.
I'll send a new version. Sorry for the noise.
ChenYu
> + regulator = devm_regulator_get_optional(&pdev->dev, name);
> + if (IS_ERR(regulator)) {
> + if (PTR_ERR(regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(&pdev->dev, "regulator %s not found: %ld\n",
> + name, PTR_ERR(regulator));
> + continue;
> + }
> + par->regulators[i++] = regulator;
> + }
> + par->regulator_count = i;
> +
> + /* Enable all the regulators */
> + for (i = 0; i < par->regulator_count; i++) {
> + ret = regulator_enable(par->regulators[i]);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to enable regulator %d: %d\n",
> + i, ret);
> + devm_regulator_put(par->regulators[i]);
> + par->regulators[i] = NULL;
>
RE: [PATCH v2] EDAC: Add ARM64 EDAC
Hi Steve, Thanks for pointing the link, I have not seen that driver before; I was mainly looking at driver/edac/xgene_edac.c and some other arm edac drivers. My first attempt was to do AMD specific edac driver to log correctable L1/L2 error but based on feedback I worked on v2 generic driver which now looks very similar to your driver, are you planning to upstream your driver ? I can work with you to verify it on my current hardware setup. It seems your driver also handles single-bit and double-bit error which I have no way to test in my current hardware setup. On Seattle platform most of error handling is done through firmware APEI except correctable L1/L2. Let me know your thoughts. -Brijesh From: Stepan Moskovchenko [step...@codeaurora.org] Sent: Thursday, October 22, 2015 8:51 PM To: Singh, Brijeshkumar Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; dougthomp...@xmission.com; b...@alien8.de; mche...@osg.samsung.com; devicetree@vger.kernel.org; guohan...@huawei.com; andre.przyw...@arm.com; a...@arndb.de; linux-ker...@vger.kernel.org; linux-e...@vger.kernel.org Subject: Re: [PATCH v2] EDAC: Add ARM64 EDAC >>> +++ b/drivers/edac/cortex_arm64_edac.c >>> @@ -0,0 +1,457 @@ >>> +/* >>> + * Cortex ARM64 EDAC >>> + * >>> + * Copyright (c) 2015, Advanced Micro Devices >>> + * Author: Brijesh Singh >>> + * >Hi Brijesh, >Your ARM64 EDAC driver seems rather similar to the existing driver that >is linked below. If you have indeed based your driver on this one, can >you please provide the appropriate attribution? >https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] dt-bindings: rockchip-thermal: Add the pinctrl states in this document
The "init" pinctrl is defined we'll set
pinctrl to this state before probe and then "default" after probe.
Add the "init" and "sleep" pinctrl as the OTP gpio state, since we need
switch the pin to gpio state before the TSADC controller is reset.
AFAIK, the TSADC controller is reset, the tshut polarity will be
a *low* signal in a short period of time for some devices.
Says:
The TSADC get the temperature on rockchip thermal.
If T(current temperature) < (setting temperature), the OTP output the
*high* signal.
If T(current temperature) > (setting temperature), the OTP output the
*low* Signal.
In some cases, the OTP pin is connected to the PMIC, maybe the
PMIC can accept the reset response time to avoid this issue.
In other words, the system will be always reboot if we make the
OTP pin is connected the others IC to control the power.
Signed-off-by: Caesar Wang
Reviewed-by: Douglas Anderson
---
Changes in v3:
- Add the pictrl states decription in document.
Changes in v2:
- Add the 'init' pinctrl more decription in commit.
- Fix the subject to make more obvious in PATCH[1/2]
- Resend this patch v2 since fix the subject to be specific.
Changes in v1:
- As the Doug comments, add the 'init' property to sync document.
.../devicetree/bindings/thermal/rockchip-thermal.txt | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..b38200d 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -12,6 +12,11 @@ Required properties:
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the name "tsadc-apb".
+- pinctrl-names : The pin control state names;
+- pinctrl-0 : The "init" pinctrl state, it will be set before device probe.
+- pinctrl-1 : The "default" pinctrl state, it will be set after reset the
+ TSADC controller.
+- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend.
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
@@ -27,8 +32,10 @@ tsadc: tsadc@ff28 {
clock-names = "tsadc", "apb_pclk";
resets = <&cru SRST_TSADC>;
reset-names = "tsadc-apb";
- pinctrl-names = "default";
- pinctrl-0 = <&otp_out>;
+ pinctrl-names = "init", "default", "sleep";
+ pinctrl-0 = <&otp_gpio>;
+ pinctrl-1 = <&otp_out>;
+ pinctrl-2 = <&otp_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
rockchip,hw-tshut-mode = <0>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl
Add the "init" anf "sleep" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.
"init" pinctrl property is defined by Doug's Patch[0].
Patch[0]:
https://patchwork.kernel.org/patch/7454311/
Signed-off-by: Caesar Wang
Reviewed-by: Douglas Anderson
---
Changes in v3:
- Add the "sleep" pinctrl as the gpio state in PATCH[3/3]
Changes in v2:
- Add some commits for more obvious in PATCH[2/2]
Changes in v1:
- As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
- As the Doug's patch to add the 'init' property.
arch/arm/boot/dts/rk3288.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938..13ff09a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -447,8 +447,10 @@
clock-names = "tsadc", "apb_pclk";
resets = <&cru SRST_TSADC>;
reset-names = "tsadc-apb";
- pinctrl-names = "default";
- pinctrl-0 = <&otp_out>;
+ pinctrl-names = "init", "default", "sleep";
+ pinctrl-0 = <&otp_gpio>;
+ pinctrl-1 = <&otp_out>;
+ pinctrl-2 = <&otp_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
status = "disabled";
@@ -1273,6 +1275,10 @@
};
tsadc {
+ otp_gpio: otp-gpio {
+ rockchip,pins = <0 10 RK_FUNC_GPIO
&pcfg_pull_none>;
+ };
+
otp_out: otp-out {
rockchip,pins = <0 10 RK_FUNC_1
&pcfg_pull_none>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] fix the TSHUT issue on rockchip thermal
Thank you all for providing inputs and comments on previous versions of this patchset. Especially thanks to the (Doug, Rob). We need the OTP pin is gpio state before resetting the TSADC controller, since the tshut polarity will generate a high signal. Says: The TSHUT temperature is setting more than 80 degree, the default tshut polarity is HIGH. If T > 80C, the OTP output the High Signal. If T < 80C, the OTP output the Low Signal. On the moment, the TSADC controller is reset, the tshut polarity will be Low in a short period of time. So: If T < 80C, the OTP output the High Signal. If T > 80C, the OTP output the Low Signal. In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can accept the reset response time to avoid this issue. In other words, the system will be always reboot if we make the OTP pin is connected the others IC to control the power. This series patchs are depend on Doug's patch.(https://patchwork.kernel.org/patch/7454311/) This series patchs are based on the Linus master branch. 518cd44 ARM: dts: rockchip: Add the OTP gpio pinctrl 83e0bab dt-bindings: Add the "init" pinctrl in this document 150426c drivers/pinctrl: Add the concept of an "init" state ce1fad2 Merge branch 'keys-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs 1099f86 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 911b79c KEYS: Don't permit request_key() to construct a new keyring 37850e3 net: bcmgenet: Fix early link interrupt enabling afc050d Merge tag 'wireless-drivers-for-davem-2015-10-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers e277de5 tunnels: Don't require remote endpoint or ID during creation. 740dbc2 openvswitch: Scrub skb between namespaces Tested on box board. Changes in v3: - Add the pictrl states decription in document. - Add the pinctrl state for in the suspend/resume. - Add the "sleep" pinctrl as the gpio state in PATCH[3/3] Changes in v2: - Add the 'init' pinctrl more decription in commit. - Fix the subject to make more obvious in PATCH[1/2] - Resend this patch v2 since fix the subject to be specific. - Add some commits for more obvious in PATCH[2/2] Changes in v1: - As the Doug comments, add the 'init' property to sync document. - As the Doug comments, drop the thermal driver patchs since we can with pinctrl changing to work. - As the Doug's patch to add the 'init' property. Caesar Wang (3): dt-bindings: rockchip-thermal: Add the pinctrl states in this document thermal: rockchip: ensure the otp states before resetting the controller ARM: dts: rockchip: Add the OTP gpio pinctrl .../devicetree/bindings/thermal/rockchip-thermal.txt | 11 +-- arch/arm/boot/dts/rk3288.dtsi | 10 -- drivers/thermal/rockchip_thermal.c| 4 3 files changed, 21 insertions(+), 4 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 2/6] pci: add Altera PCI vendor ID
On Fri, Oct 23, 2015 at 6:13 AM, Bjorn Helgaas wrote: > On Thu, Oct 22, 2015 at 05:27:27PM +0800, Ley Foon Tan wrote: >> Signed-off-by: Ley Foon Tan >> --- >> include/linux/pci_ids.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h >> index d9ba49c..08e4462 100644 >> --- a/include/linux/pci_ids.h >> +++ b/include/linux/pci_ids.h >> @@ -1550,6 +1550,8 @@ >> #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227 >> #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408 >> >> +#define PCI_VENDOR_ID_ALTERA 0x1172 >> + > > This doesn't seem to be used anywhere, so I'll drop this patch. Okay. Thanks. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] EDAC: Add ARM64 EDAC
>>> +++ b/drivers/edac/cortex_arm64_edac.c >>> @@ -0,0 +1,457 @@ >>> +/* >>> + * Cortex ARM64 EDAC >>> + * >>> + * Copyright (c) 2015, Advanced Micro Devices >>> + * Author: Brijesh Singh >>> + * Hi Brijesh, Your ARM64 EDAC driver seems rather similar to the existing driver that is linked below. If you have indeed based your driver on this one, can you please provide the appropriate attribution? https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10 Thank you Steve -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] MIPS: BMIPS: brcmstb: add SATA nodes for bcm7346
Add AHCI and PHY device nodes to BMIPS based BCM7346 platform.
Signed-off-by: Jaedon Shin
---
arch/mips/boot/dts/brcm/bcm7346.dtsi | 40 +++
arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 8 +++
2 files changed, 48 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7346.dtsi
b/arch/mips/boot/dts/brcm/bcm7346.dtsi
index d817bb46b934..bf5b2d7a8b75 100644
--- a/arch/mips/boot/dts/brcm/bcm7346.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7346.dtsi
@@ -246,5 +246,45 @@
interrupts = <76>;
status = "disabled";
};
+
+ sata: sata@181000 {
+ compatible = "brcm,bcm7346-ahci", "brcm,sata3-ahci";
+ reg-names = "ahci", "top-ctrl";
+ reg = <0x181000 0xa9c>, <0x180020 0x8>;
+ interrupt-parent = <&periph_intc>;
+ interrupts = <40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ phys = <&sata_phy0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ phys = <&sata_phy1>;
+ };
+ };
+
+ sata_phy: sata-phy@180 {
+ compatible = "brcm,bcm7346-sata-phy", "brcm,phy-sata3";
+ reg = <0x180100 0x0eff>;
+ reg-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sata_phy0: sata-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ sata_phy1: sata-phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
};
};
diff --git a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
index 3fe0445b9d37..e147c61178cc 100644
--- a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
@@ -64,3 +64,11 @@
&ohci3 {
status = "okay";
};
+
+&sata {
+ status = "okay";
+};
+
+&sata_phy {
+ status = "okay";
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] phy: phy_brcmstb_sata: make the driver buildable on BMIPS_GENERIC
The BCM7xxx ARM and MIPS platforms share a similar hardware block for AHCI SATA3 PHY. Signed-off-by: Jaedon Shin --- drivers/phy/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 47da573d0bab..c83e48661fd7 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -364,11 +364,11 @@ config PHY_TUSB1210 config PHY_BRCMSTB_SATA tristate "Broadcom STB SATA PHY driver" - depends on ARCH_BRCMSTB + depends on ARCH_BRCMSTB || BMIPS_GENERIC depends on OF select GENERIC_PHY help - Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs. + Enable this to support the SATA3 PHY on 28nm or 40nm Broadcom STB SoCs. Likely useful only with CONFIG_SATA_BRCMSTB enabled. endmenu -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] phy: phy_brcmstb_sata: add data for phy offset
Add data of device node for phy offset.
Signed-off-by: Jaedon Shin
---
drivers/phy/phy-brcmstb-sata.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
index 0be55dafe9ea..41c7535d706b 100644
--- a/drivers/phy/phy-brcmstb-sata.c
+++ b/drivers/phy/phy-brcmstb-sata.c
@@ -42,6 +42,7 @@ struct brcm_sata_port {
struct brcm_sata_phy {
struct device *dev;
void __iomem *phy_base;
+ u32 phy_offset;
struct brcm_sata_port phys[MAX_PORTS];
};
@@ -65,7 +66,7 @@ static inline void __iomem *brcm_sata_phy_base(struct
brcm_sata_port *port)
{
struct brcm_sata_phy *priv = port->phy_priv;
- return priv->phy_base + (port->portnum * SATA_MDIO_REG_SPACE_SIZE);
+ return priv->phy_base + (port->portnum * priv->phy_offset);
}
static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank, u32 ofs,
@@ -126,7 +127,8 @@ static const struct phy_ops phy_ops_28nm = {
};
static const struct of_device_id brcm_sata_phy_of_match[] = {
- { .compatible = "brcm,bcm7445-sata-phy" },
+ { .compatible = "brcm,bcm7445-sata-phy",
+ .data = (void *)SATA_MDIO_REG_SPACE_SIZE },
{},
};
MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
@@ -135,6 +137,7 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *dn = dev->of_node, *child;
+ const struct of_device_id *of_id = NULL;
struct brcm_sata_phy *priv;
struct resource *res;
struct phy_provider *provider;
@@ -154,6 +157,12 @@ static int brcm_sata_phy_probe(struct platform_device
*pdev)
if (IS_ERR(priv->phy_base))
return PTR_ERR(priv->phy_base);
+ of_id = of_match_node(brcm_sata_phy_of_match, dn);
+ if (!of_id)
+ return -EINVAL;
+
+ priv->phy_offset = (u32)of_id->data;
+
for_each_available_child_of_node(dn, child) {
unsigned int id;
struct brcm_sata_port *port;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] ata: ahci_brcmstb: add support 40nm platforms
Add offsets for 40nm BMIPS based set-top box platforms.
Signed-off-by: Jaedon Shin
---
drivers/ata/ahci_brcmstb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
index 8cf6f7d4798f..59eb526cf4f6 100644
--- a/drivers/ata/ahci_brcmstb.c
+++ b/drivers/ata/ahci_brcmstb.c
@@ -50,7 +50,8 @@
#define SATA_TOP_CTRL_2_SW_RST_RXBIT(2)
#define SATA_TOP_CTRL_2_SW_RST_TXBIT(3)
#define SATA_TOP_CTRL_2_PHY_GLOBAL_RESET BIT(14)
- #define SATA_TOP_CTRL_PHY_OFFS0x8
+ #define SATA_TOP_CTRL_28NM_PHY_OFFS 0x8
+ #define SATA_TOP_CTRL_40NM_PHY_OFFS 0x4
#define SATA_TOP_MAX_PHYS 2
#define SATA_TOP_CTRL_SATA_TP_OUT 0x1c
#define SATA_TOP_CTRL_CLIENT_INIT_CTRL 0x20
@@ -237,7 +238,13 @@ static int brcm_ahci_resume(struct device *dev)
static const struct of_device_id ahci_of_match[] = {
{.compatible = "brcm,bcm7445-ahci",
- .data = (void *)SATA_TOP_CTRL_PHY_OFFS},
+ .data = (void *)SATA_TOP_CTRL_28NM_PHY_OFFS},
+ {.compatible = "brcm,bcm7346-ahci",
+ .data = (void *)SATA_TOP_CTRL_40NM_PHY_OFFS},
+ {.compatible = "brcm,bcm7360-ahci",
+ .data = (void *)SATA_TOP_CTRL_40NM_PHY_OFFS},
+ {.compatible = "brcm,bcm7362-ahci",
+ .data = (void *)SATA_TOP_CTRL_40NM_PHY_OFFS},
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] MIPS: BMIPS: brcmstb: add SATA nodes for bcm7362
Add AHCI and PHY device nodes to BMIPS based BCM7362 platform.
Signed-off-by: Jaedon Shin
---
arch/mips/boot/dts/brcm/bcm7362.dtsi | 40
arch/mips/boot/dts/brcm/bcm97362svmb.dts | 8 +++
2 files changed, 48 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7362.dtsi
b/arch/mips/boot/dts/brcm/bcm7362.dtsi
index 6e65db86fc61..51c58a41d2b5 100644
--- a/arch/mips/boot/dts/brcm/bcm7362.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7362.dtsi
@@ -189,5 +189,45 @@
interrupts = <66>;
status = "disabled";
};
+
+ sata: sata@181000 {
+ compatible = "brcm,bcm7362-ahci", "brcm,sata3-ahci";
+ reg-names = "ahci", "top-ctrl";
+ reg = <0x181000 0xa9c>, <0x180020 0x8>;
+ interrupt-parent = <&periph_intc>;
+ interrupts = <86>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ phys = <&sata_phy0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ phys = <&sata_phy1>;
+ };
+ };
+
+ sata_phy: sata-phy@180 {
+ compatible = "brcm,bcm7362-sata-phy", "brcm,phy-sata3";
+ reg = <0x180100 0x0eff>;
+ reg-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sata_phy0: sata-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ sata_phy1: sata-phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
};
};
diff --git a/arch/mips/boot/dts/brcm/bcm97362svmb.dts
b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
index 739c2ef5663b..ef9a69b79bc4 100644
--- a/arch/mips/boot/dts/brcm/bcm97362svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
@@ -40,3 +40,11 @@
&ohci0 {
status = "okay";
};
+
+&sata {
+ status = "okay";
+};
+
+&sata_phy {
+ status = "okay";
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] MIPS: BMIPS: brcmstb: add SATA nodes for bcm7360
Add AHCI and PHY device nodes to BMIPS based BCM7360 platform.
Signed-off-by: Jaedon Shin
---
arch/mips/boot/dts/brcm/bcm7360.dtsi | 40
arch/mips/boot/dts/brcm/bcm97360svmb.dts | 8 +++
2 files changed, 48 insertions(+)
diff --git a/arch/mips/boot/dts/brcm/bcm7360.dtsi
b/arch/mips/boot/dts/brcm/bcm7360.dtsi
index 9e1e571ba346..1f5c99e9d0d1 100644
--- a/arch/mips/boot/dts/brcm/bcm7360.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7360.dtsi
@@ -183,5 +183,45 @@
interrupts = <66>;
status = "disabled";
};
+
+ sata: sata@181000 {
+ compatible = "brcm,bcm7360-ahci", "brcm,sata3-ahci";
+ reg-names = "ahci", "top-ctrl";
+ reg = <0x181000 0xa9c>, <0x180020 0x8>;
+ interrupt-parent = <&periph_intc>;
+ interrupts = <86>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sata0: sata-port@0 {
+ reg = <0>;
+ phys = <&sata_phy0>;
+ };
+
+ sata1: sata-port@1 {
+ reg = <1>;
+ phys = <&sata_phy1>;
+ };
+ };
+
+ sata_phy: sata-phy@180 {
+ compatible = "brcm,bcm7360-sata-phy", "brcm,phy-sata3";
+ reg = <0x180100 0x0eff>;
+ reg-names = "phy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ sata_phy0: sata-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ sata_phy1: sata-phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
};
};
diff --git a/arch/mips/boot/dts/brcm/bcm97360svmb.dts
b/arch/mips/boot/dts/brcm/bcm97360svmb.dts
index eee8b0e32681..0088925cc36a 100644
--- a/arch/mips/boot/dts/brcm/bcm97360svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97360svmb.dts
@@ -40,3 +40,11 @@
&ohci0 {
status = "okay";
};
+
+&sata {
+ status = "okay";
+};
+
+&sata_phy {
+ status = "okay";
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] ata: ahci_brcmstb: make the driver buildable on BMIPS_GENERIC
The BCM7xxx ARM and MIPS platforms share a similar hardware block for AHCI SATA3. Signed-off-by: Jaedon Shin --- drivers/ata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 15e40ee62a94..8f535a88a0c7 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -100,7 +100,7 @@ config SATA_AHCI_PLATFORM config AHCI_BRCMSTB tristate "Broadcom STB AHCI SATA support" - depends on ARCH_BRCMSTB + depends on ARCH_BRCMSTB || BMIPS_GENERIC help This option enables support for the AHCI SATA3 controller found on STB SoC's. -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] add support SATA for BMIPS_GENERIC
Hi all, This patch series adds support SATA for BMIPS_GENERIC. Ralf, I request you to drop already submitted patches for NAND device nodes. It is merge conflicts with this patches. http://patchwork.linux-mips.org/patch/10577/ http://patchwork.linux-mips.org/patch/10578/ http://patchwork.linux-mips.org/patch/10579/ http://patchwork.linux-mips.org/patch/10580/ Jaedon Shin (10): ata: ahci_brcmstb: make the driver buildable on BMIPS_GENERIC ata: ahch_brcmstb: add data for port offset ata: ahci_brcmstb: add support 40nm platforms phy: phy_brcmstb_sata: make the driver buildable on BMIPS_GENERIC phy: phy_brcmstb_sata: remove unused definitions phy: phy_brcmstb_sata: add data for phy offset phy: phy_brcmstb_sata: add support 40nm platforms MIPS: BMIPS: brcmstb: add SATA nodes for bcm7346 MIPS: BMIPS: brcmstb: add SATA nodes for bcm7360 MIPS: BMIPS: brcmstb: add SATA nodes for bcm7362 arch/mips/boot/dts/brcm/bcm7346.dtsi | 40 +++ arch/mips/boot/dts/brcm/bcm7360.dtsi | 40 +++ arch/mips/boot/dts/brcm/bcm7362.dtsi | 40 +++ arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 8 +++ arch/mips/boot/dts/brcm/bcm97360svmb.dts | 8 +++ arch/mips/boot/dts/brcm/bcm97362svmb.dts | 8 +++ drivers/ata/Kconfig | 2 +- drivers/ata/ahci_brcmstb.c| 34 +++--- drivers/phy/Kconfig | 4 ++-- drivers/phy/phy-brcmstb-sata.c| 34 ++ 10 files changed, 196 insertions(+), 22 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] ata: ahch_brcmstb: add data for port offset
Add data of device node for port offset.
Signed-off-by: Jaedon Shin
---
drivers/ata/ahci_brcmstb.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/ata/ahci_brcmstb.c b/drivers/ata/ahci_brcmstb.c
index 14b7305d2ba0..8cf6f7d4798f 100644
--- a/drivers/ata/ahci_brcmstb.c
+++ b/drivers/ata/ahci_brcmstb.c
@@ -72,6 +72,7 @@
struct brcm_ahci_priv {
struct device *dev;
void __iomem *top_ctrl;
+ u32 port_offset;
u32 port_mask;
};
@@ -110,7 +111,7 @@ static inline void brcm_sata_writereg(u32 val, void __iomem
*addr)
static void brcm_sata_phy_enable(struct brcm_ahci_priv *priv, int port)
{
void __iomem *phyctrl = priv->top_ctrl + SATA_TOP_CTRL_PHY_CTRL +
- (port * SATA_TOP_CTRL_PHY_OFFS);
+ (port * priv->port_offset);
void __iomem *p;
u32 reg;
@@ -139,7 +140,7 @@ static void brcm_sata_phy_enable(struct brcm_ahci_priv
*priv, int port)
static void brcm_sata_phy_disable(struct brcm_ahci_priv *priv, int port)
{
void __iomem *phyctrl = priv->top_ctrl + SATA_TOP_CTRL_PHY_CTRL +
- (port * SATA_TOP_CTRL_PHY_OFFS);
+ (port * priv->port_offset);
void __iomem *p;
u32 reg;
@@ -234,6 +235,13 @@ static int brcm_ahci_resume(struct device *dev)
}
#endif
+static const struct of_device_id ahci_of_match[] = {
+ {.compatible = "brcm,bcm7445-ahci",
+ .data = (void *)SATA_TOP_CTRL_PHY_OFFS},
+ {},
+};
+MODULE_DEVICE_TABLE(of, ahci_of_match);
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
@@ -241,6 +249,7 @@ static struct scsi_host_template ahci_platform_sht = {
static int brcm_ahci_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ const struct of_device_id *of_id = NULL;
struct brcm_ahci_priv *priv;
struct ahci_host_priv *hpriv;
struct resource *res;
@@ -256,6 +265,12 @@ static int brcm_ahci_probe(struct platform_device *pdev)
if (IS_ERR(priv->top_ctrl))
return PTR_ERR(priv->top_ctrl);
+ of_id = of_match_node(ahci_of_match, dev->of_node);
+ if (!of_id)
+ return -EINVAL;
+
+ priv->port_offset = (u32)of_id->data;
+
brcm_sata_init(priv);
priv->port_mask = brcm_ahci_get_portmask(pdev, priv);
@@ -299,12 +314,6 @@ static int brcm_ahci_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id ahci_of_match[] = {
- {.compatible = "brcm,bcm7445-ahci"},
- {},
-};
-MODULE_DEVICE_TABLE(of, ahci_of_match);
-
static SIMPLE_DEV_PM_OPS(ahci_brcm_pm_ops, brcm_ahci_suspend,
brcm_ahci_resume);
static struct platform_driver brcm_ahci_driver = {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] phy: phy_brcmstb_sata: remove unused definitions
Remove unused definitions. Signed-off-by: Jaedon Shin --- drivers/phy/phy-brcmstb-sata.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c index 8a2cb16a1937..0be55dafe9ea 100644 --- a/drivers/phy/phy-brcmstb-sata.c +++ b/drivers/phy/phy-brcmstb-sata.c @@ -26,8 +26,6 @@ #define SATA_MDIO_BANK_OFFSET 0x23c #define SATA_MDIO_REG_OFFSET(ofs) ((ofs) * 4) -#define SATA_MDIO_REG_SPACE_SIZE 0x1000 -#define SATA_MDIO_REG_LENGTH 0x1f00 #define MAX_PORTS 2 -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] phy: phy_brcmstb_sata: add support 40nm platforms
Add offsets for 40nm BMIPS based set-top box platforms.
Signed-off-by: Jaedon Shin
---
drivers/phy/phy-brcmstb-sata.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
index 41c7535d706b..1cc80743b1b6 100644
--- a/drivers/phy/phy-brcmstb-sata.c
+++ b/drivers/phy/phy-brcmstb-sata.c
@@ -30,7 +30,8 @@
#define MAX_PORTS 2
/* Register offset between PHYs in PCB space */
-#define SATA_MDIO_REG_SPACE_SIZE 0x1000
+#define SATA_MDIO_REG_28NM_SPACE_SIZE 0x1000
+#define SATA_MDIO_REG_40NM_SPACE_SIZE 0x10
struct brcm_sata_port {
int portnum;
@@ -47,7 +48,7 @@ struct brcm_sata_phy {
struct brcm_sata_port phys[MAX_PORTS];
};
-enum sata_mdio_phy_regs_28nm {
+enum sata_mdio_phy_regs {
PLL_REG_BANK_0 = 0x50,
PLL_REG_BANK_0_PLLCONTROL_0 = 0x81,
@@ -85,7 +86,7 @@ static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank,
u32 ofs,
#define FMAX_VAL_DEFAULT 0x3df
#define FMAX_VAL_SSC 0x83
-static void brcm_sata_cfg_ssc_28nm(struct brcm_sata_port *port)
+static void brcm_sata_cfg_ssc(struct brcm_sata_port *port)
{
void __iomem *base = brcm_sata_phy_base(port);
struct brcm_sata_phy *priv = port->phy_priv;
@@ -116,19 +117,25 @@ static int brcm_sata_phy_init(struct phy *phy)
{
struct brcm_sata_port *port = phy_get_drvdata(phy);
- brcm_sata_cfg_ssc_28nm(port);
+ brcm_sata_cfg_ssc(port);
return 0;
}
-static const struct phy_ops phy_ops_28nm = {
+static const struct phy_ops phy_ops = {
.init = brcm_sata_phy_init,
.owner = THIS_MODULE,
};
static const struct of_device_id brcm_sata_phy_of_match[] = {
{ .compatible = "brcm,bcm7445-sata-phy",
- .data = (void *)SATA_MDIO_REG_SPACE_SIZE },
+ .data = (void *)SATA_MDIO_REG_28NM_SPACE_SIZE },
+ { .compatible = "brcm,bcm7346-sata-phy",
+ .data = (void *)SATA_MDIO_REG_40NM_SPACE_SIZE },
+ { .compatible = "brcm,bcm7360-sata-phy",
+ .data = (void *)SATA_MDIO_REG_40NM_SPACE_SIZE },
+ { .compatible = "brcm,bcm7362-sata-phy",
+ .data = (void *)SATA_MDIO_REG_40NM_SPACE_SIZE },
{},
};
MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
@@ -185,7 +192,7 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
port = &priv->phys[id];
port->portnum = id;
port->phy_priv = priv;
- port->phy = devm_phy_create(dev, child, &phy_ops_28nm);
+ port->phy = devm_phy_create(dev, child, &phy_ops);
port->ssc_en = of_property_read_bool(child, "brcm,enable-ssc");
if (IS_ERR(port->phy)) {
dev_err(dev, "failed to create PHY\n");
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] EDAC: Add ARM64 EDAC
Hi Brijesh,
On 2015/10/22 22:46, Brijesh Singh wrote:
> Hi Andre,
>
> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>> On 21/10/15 21:41, Brijesh Singh wrote:
>>> Add support for Cortex A57 and A53 EDAC driver.
>> Hi Brijesh,
>>
>> thanks for the quick update! Some comments below.
>>
>>> Signed-off-by: Brijesh Singh
>>> CC: robh...@kernel.org
>>> CC: pawel.m...@arm.com
>>> CC: mark.rutl...@arm.com
>>> CC: ijc+devicet...@hellion.org.uk
>>> CC: ga...@codeaurora.org
>>> CC: dougthomp...@xmission.com
>>> CC: b...@alien8.de
>>> CC: mche...@osg.samsung.com
>>> CC: devicetree@vger.kernel.org
>>> CC: guohan...@huawei.com
>>> CC: andre.przyw...@arm.com
>>> CC: a...@arndb.de
>>> CC: linux-ker...@vger.kernel.org
>>> CC: linux-e...@vger.kernel.org
>>> ---
>>>
>>> v2:
>>> * convert into generic arm64 edac driver
>>> * remove AMD specific references from dt binding
>>> * remove poll_msec property from dt binding
>>> * add poll_msec as a module param, default is 100ms
>>> * update copyright text
>>> * define macro mnemonics for L1 and L2 RAMID
>>> * check L2 error per-cluster instead of per core
>>> * update function names
>>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register
>>> read hotplug-safe
>>> * add error check in probe routine
>>>
>>> .../devicetree/bindings/edac/armv8-edac.txt| 15 +
>>> drivers/edac/Kconfig | 6 +
>>> drivers/edac/Makefile | 1 +
>>> drivers/edac/cortex_arm64_edac.c | 457
>>> +
>>> 4 files changed, 479 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> create mode 100644 drivers/edac/cortex_arm64_edac.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> new file mode 100644
>>> index 000..dfd128f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> @@ -0,0 +1,15 @@
>>> +* ARMv8 L1/L2 cache error reporting
>>> +
>>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>>> +Register can be used for checking L1 and L2 memory errors.
>>> +
>>> +The following section describes the ARMv8 EDAC DT node binding.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "arm,armv8-edac"
>>> +
>>> +Example:
>>> + edac {
>>> + compatible = "arm,armv8-edac";
>>> + };
>>> +
>> So if there is nothing in here, why do we need the DT binding at all (I
>> think Mark hinted at that already)?
>> Can't we just use the MIDR as already suggested by others?
>> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
>> specific and not architectural.
>>
> Yes, I was going with Mark suggestion to remove DT binding but then came
> across these cases which kind of hinted to keep DT binding:
>
> * Without DT binding, the driver will always be loaded on arm64 unless its
> blacklisted.
> * Its possible that other SoC's might handle single-bit and double-bit errors
> differently compare to
> Seattle platform. In Seattle platform both errors are handled by firmware
> but if other SoC
> wants OS to handle these errors then they might need DT binding to provide
> the irq numbers etc.
I totally agree with you here, thanks for putting them together.
Different SoCs may handle the error in different ways, we need
bindings to specialize them, irq number is a good example :)
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] dt-bindings: EXYNOS: Document compatibles from other vendors
Document compatibles used on other Exynos-based boards (non-Samsung): FriendlyARM, Google, Hardkernel and Insignal. Signed-off-by: Krzysztof Kozlowski Cc: Kukjin Kim Cc: Javier Martinez Canillas Cc: Hakjoo Kim Reviewed-by: Javier Martinez Canillas --- Changes since v2: 1. None Changes since v1: 1. Added Javier's reviewed-by --- .../bindings/arm/samsung/samsung-boards.txt| 44 +- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt index 43589d2466a7..da078702ae73 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -16,7 +16,49 @@ Required root node properties: - "samsung,sd5v1" - for Exynos5440-based Samsung board. - "samsung,ssdk5440"- for Exynos5440-based Samsung board. -Optional: +* Other companies Exynos SoC based + * FriendlyARM +- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM +TINY4412 board. + + * Google +- "google,pi" - for Exynos5800-based Google Peach Pi +Rev 10+ board, + also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14", + "google,pi-rev13", "google,pi-rev12", "google,pi-rev11", +"google,pi-rev10", "google,peach". + +- "google,pit"- for Exynos5420-based Google Peach Pit +Rev 6+ (Exynos5420), + also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14", +"google,pit-rev13", "google,pit-rev12", "google,pit-rev11", +"google,pit-rev10", "google,pit-rev9", "google,pit-rev8", +"google,pit-rev7", "google,pit-rev6", "google,peach". + +- "google,snow-rev4" - for Exynos5250-based Google Snow board, + also: "google,snow" +- "google,snow-rev5" - for Exynos5250-based Google Snow +Rev 5+ board. +- "google,spring" - for Exynos5250-based Google Spring board. + + * Hardkernel +- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3. +- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X. +- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2. +- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3. +- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel + Odroid XU3 Lite board. +- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4. + + * Insignal +- "insignal,arndale" - for Exynos5250-based Insignal Arndale board. +- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale +Octa board. +- "insignal,origen" - for Exynos4210-based Insignal Origen board. +- "insignal,origen4412- for Exynos4412-based Insignal Origen board. + + +Optional nodes: - firmware node, specifying presence and type of secure firmware: - compatible: only "samsung,secure-firmware" is currently supported - reg: address of non-secure SYSRAM used for communication with firmware -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] dt-bindings: Consolidate Exynos SoC bindings
Exynos SoC Device Tree bindings are spread over arm/exynos/ and
arm/samsung/ directories. There is no need for that separation and it
actually confuses. Put power domain bindings under power/ and
remaining samsung-boards.txt under arm/samsung/.
Signed-off-by: Krzysztof Kozlowski
Cc: Kukjin Kim
Reviewed-by: Javier Martinez Canillas
---
Changes since v2:
1. Update path pointing to pd-samsung.txt in samsung,sysmmu.txt.
Changes since v1:
1. Move power_domain.txt to power/pd-samsung.txt.
2. The smp-sysram.txt is moved in previous patch to sram/ directory
(Suggested by Rob Herring).
3. Added Javier's reviewed-by. Although there are some differences since
v1 but this is merely re-organization. Please let me know if the
review tag is no longer valid.
---
Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt | 0
Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt | 2 +-
.../bindings/{arm/exynos/power_domain.txt => power/pd-samsung.txt} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt
(100%)
rename Documentation/devicetree/bindings/{arm/exynos/power_domain.txt =>
power/pd-samsung.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/samsung-boards.txt
rename to Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index 729543c47046..bc620fe32a70 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -47,7 +47,7 @@ Required properties:
- clocks: Required if the System MMU is needed to gate its clock.
- power-domains: Required if the System MMU is needed to gate its power.
Please refer to the following document:
- Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+ Documentation/devicetree/bindings/power/pd-samsung.txt
Examples:
gsc_0: gsc@13e0 {
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/power/pd-samsung.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/exynos/power_domain.txt
rename to Documentation/devicetree/bindings/power/pd-samsung.txt
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC
On 2015/10/21 17:35, Borislav Petkov wrote: > On Wed, Oct 21, 2015 at 09:55:43AM +0800, Hanjun Guo wrote: >> So I think the meaning of those error register is the same, but the way >> of handle it may different from SoCs, for single bit error: >> >> - SoC may trigger a interrupt; >> - SoC may just keep silent so we need to scan the registers using poll >>mechanism. >> >> For Double bit error: >> - SoC may also keep silent >> - Trigger a interrupt >> - Trigger a SEI (system error) >> >> Any suggestion to cover those cases? > Well, I guess we can implement all those and have them configurable > in the sense that a single driver loads, it has all functionality and > dependent on the vendor detection, it does only what the vendor wants > like trigger an interrupt or remain silent or ... Hmm, so we need to keep the DT bindings for different SoCs which have different ways of handling the errors. Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] dt-bindings: Consolidate SRAM bindings from all vendors
SRAM bindings for various SoCs, using the mmio-sram genalloc
API, are spread over different places - per SoC vendor. Since all of
these are quite similar (they depend on mmio-sram) move them to a common
place.
Signed-off-by: Krzysztof Kozlowski
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Kukjin Kim
Suggested-by: Rob Herring
---
Changes since v2:
1. Update paths to sram.txt.
Changes since v1:
1. New patch. Extended suggestion from Rob.
---
Documentation/devicetree/bindings/arm/arm,scpi.txt | 2 +-
.../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt} | 0
.../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt} | 2 +-
.../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt} | 2 +-
Documentation/devicetree/bindings/{misc => sram}/sram.txt | 0
.../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 2 +-
6 files changed, 4 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt =>
sram/rockchip-pmu-sram.txt} (100%)
rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt =>
sram/rockchip-smp-sram.txt} (92%)
rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt =>
sram/samsung-sram.txt} (95%)
rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt =>
sram/sunxi-sram.txt} (97%)
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index 86302de67c2c..313dabdc14f9 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -63,7 +63,7 @@ Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
-found in ../../misc/sysram.txt
+found in ../../sram/sram.txt
Each sub-node represents the reserved area for SCPI.
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
similarity index 92%
rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
index d9416fb8db6f..800701ecffca 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
+++ b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
@@ -12,7 +12,7 @@ Required sub-node properties:
- compatible : should be "rockchip,rk3066-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
Example:
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
b/Documentation/devicetree/bindings/sram/samsung-sram.txt
similarity index 95%
rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
index 4a0a4f70a0ce..6bc474b2b885 100644
--- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
+++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt
@@ -15,7 +15,7 @@ Required sub-node properties:
"samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sysram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
Example:
diff --git a/Documentation/devicetree/bindings/misc/sram.txt
b/Documentation/devicetree/bindings/sram/sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/sram.txt
rename to Documentation/devicetree/bindings/sram/sram.txt
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
similarity index 97%
rename from Documentation/devicetree/bindings/soc/sunxi/sram.txt
rename to Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 067698112f5f..8d5665468fe7 100644
--- a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -16,7 +16,7 @@ SRAM nodes
--
Each SRAM is described using the mmio-sram bindings documented in
-Documentation/devicetree/bindings/misc/sram.txt
+Documentation/devicetree/bindings/sram/sram.txt
Each SRAM will have SRAM sections that are going to be handled by the
SRAM controller as subnodes. These sections are represented following
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
th
Re: [PATCH v2 1/3] ARM: sunxi: Introduce Allwinner for A83T support
On Fri, Oct 23, 2015 at 7:46 AM, Vishnu Patekar wrote: > Allwinner A83T is octa-core cortex-a7 based SoC. > It's clock control unit and prcm, pinmux are different from previous sun8i > series. > Its processor cores are arragned in two clusters 4 cores each, > similar to A80. > > Signed-off-by: Vishnu Patekar Could you also update Documentation/arm/sunxi/README, so it says A83T is supported? Otherwise, Acked-by: Chen-Yu Tsai -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] dt-bindings: simplefb: Support regulator supply properties
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
.../devicetree/bindings/video/simple-framebuffer.txt| 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+ lcd-supply = <®_dc1sw>;
display = <&lcdc0>;
};
stdout-path = "display0";
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] simplefb: Add regulator handling support
Hi everyone, This is v3 of the simplefb regulator support series. This series adds regulator claiming and enabling support for simplefb. Changes since v3: - Dropped extra "if" which is always true, leftover from v1. - Updated commit message of patch 1 Sometimes the simplefb display output path consits of external conversion chips and/or LCD drivers and backlights. These devices normally have GPIOs to turn them on and/or bring them out of reset, and regulators supplying power to them. While the kernel does not touch unclaimed GPIOs, the regulator core happily disables unused regulators. Thus we need simplefb to claim and enable the regulators used throughout the display pipeline. The binding supports any named regulator supplies under its device node. The driver will look through its properties, and claim any regulators by matching "*-supply", as Mark suggested. I've not done a generic helper in the regulator core yet, instead doing the regulator property handling in the simplefb code for now. Patch 1 adds the regulator properties to the DT binding. Patch 2 adds code to the simplefb driver to claim and enable regulators. Regards ChenYu Chen-Yu Tsai (2): dt-bindings: simplefb: Support regulator supply properties simplefb: Claim and enable regulators .../bindings/video/simple-framebuffer.txt | 13 ++- drivers/video/fbdev/simplefb.c | 120 - 2 files changed, 128 insertions(+), 5 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] simplefb: Claim and enable regulators
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
drivers/video/fbdev/simplefb.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..9de34ee15ac0 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(&pdev->dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) {
Re: [PATCH 1/2] ARM: shmobile: r8a7790: fix "gpio-ranges" props
On Thu, Oct 22, 2015 at 02:04:41AM +0300, Sergei Shtylyov wrote: > On R8A7790, GPIO banks 1 and 2 are missing pins 30 and 31. Correct the > "gpio-ranges" properties of the corresponding device nodes. > > Signed-off-by: Sergei Shtylyov > > --- > This patch is against the 'renesas-devel-20151019-v4.3-rc6' of Simon Horman's > 'renesas.git' repo. Thanks, I have queued this up. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: shmobile: r8a7791: fix "gpio-ranges" props
On Thu, Oct 22, 2015 at 01:06:02PM +0200, Geert Uytterhoeven wrote: > On Thu, Oct 22, 2015 at 1:05 AM, Sergei Shtylyov > wrote: > > On R8A7791, GPIO banks 1 and 7 are missing pins 26 to 31. Correct the > > "gpio-ranges" properties of the GPIO1 node (GPIO7 is already correct). > > > > Signed-off-by: Sergei Shtylyov > > LEDs and keys on r8a7791/koelsch (which are connected to a higher gpio) > still work fine. > > Tested-by: Geert Uytterhoeven Thanks, I have queued this up. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/19] ARM: dts: shmobile/r8a7xxx: replace gpio-key,wakeup with wakeup-source property
On Thu, Oct 22, 2015 at 10:37:54AM +0100, Sudeep Holla wrote: > > > On 22/10/15 01:50, Simon Horman wrote: > >On Wed, Oct 21, 2015 at 11:23:03AM +0100, Sudeep Holla wrote: > >> > >> > >>On 21/10/15 11:18, Geert Uytterhoeven wrote: > >>>On Wed, Oct 21, 2015 at 12:10 PM, Sudeep Holla > >>>wrote: > Though the keyboard driver for GPIO buttons(gpio-keys) will continue to > check for/support the legacy "gpio-key,wakeup" boolean property to > enable gpio buttons as wakeup source, "wakeup-source" is the new > standard binding. > > This patch replaces the legacy "gpio-key,wakeup" with the unified > "wakeup-source" property in order to avoid any futher copy-paste > duplication. > >>> > >>>Thanks! > >>> > >>>I made the same changes to my local tree a few weeks ago, but never found > >>>time to send them out... > >>> > >> > >>Ah OK, even I had these changes for long. I waited until I fixed all the > >>binding documents(which was boring ;)) > >> > Cc: Simon Horman > Cc: Magnus Damm > Cc: linux...@vger.kernel.org > Signed-off-by: Sudeep Holla > >>> > >>>Acked-by: Geert Uytterhoeven > > > >Can I clarify that you would like me to pick up this patch? > >If so I'm happy to do so. > > > > Yes you can pick up this patch as it has no dependency on driver changes. Thanks, I have queued this up for v4.5. It should appear in the devel branch of the renesas tree some time today. I will include it in the next branch, which is included in the linux-next tree, once v4.4-rc1 has been released. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node
On Thu, Oct 22, 2015 at 03:03:37PM +0200, Tomeu Vizoso wrote: > On 22 October 2015 at 03:06, Rafael J. Wysocki wrote: > > Same question as from Greg: How does a subsystem know whether or not to use > > this function? > Maybe I don't understand the comment, but as the commit message says, > subsystems can use this when looking up resources for drivers. Or you > mean that this information should be in the API docs? I'm pretty sure what he's suggesting here is changing to "should always" (ie, explain the situations when a subsystem would do this, including decision criteria if it's optional). signature.asc Description: PGP signature
[PATCH v2 1/3] ARM: sunxi: Introduce Allwinner for A83T support
Allwinner A83T is octa-core cortex-a7 based SoC.
It's clock control unit and prcm, pinmux are different from previous sun8i
series.
Its processor cores are arragned in two clusters 4 cores each,
similar to A80.
Signed-off-by: Vishnu Patekar
---
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
drivers/clk/sunxi/clk-sunxi.c | 6 ++
3 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
b/Documentation/devicetree/bindings/arm/sunxi.txt
index bb9b0faa..7e79fcc 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -11,5 +11,6 @@ using one of the following compatible strings:
allwinner,sun7i-a20
allwinner,sun8i-a23
allwinner,sun8i-a33
+ allwinner,sun8i-a83t
allwinner,sun8i-h3
allwinner,sun9i-a80
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 8583a9c..d64e92d 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -69,6 +69,7 @@ MACHINE_END
static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
+ "allwinner,sun8i-a83t",
"allwinner,sun8i-h3",
NULL,
};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 9c79af0c..1632201 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1213,6 +1213,12 @@ CLK_OF_DECLARE(sun6i_a31s_clk_init,
"allwinner,sun6i-a31s", sun6i_init_clocks);
CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
+static void __init sun8i_a83t_init_clocks(struct device_node *node)
+{
+ sunxi_init_clocks(NULL, 0);
+}
+CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t",
sun8i_a83t_init_clocks);
+
static void __init sun9i_init_clocks(struct device_node *node)
{
sunxi_init_clocks(NULL, 0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi
Allwinner A83T is new octa-core cortex-a7 SOC.
This adds the basic dtsi, the clocks differs from
earlier sun8i SOCs.
Signed-off-by: Vishnu Patekar
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 247 ++
1 file changed, 247 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-a83t.dtsi
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
new file mode 100644
index 000..e85995f
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -0,0 +1,247 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ *
+ * Vishnu Patekar
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+
+ */
+
+#include "skeleton.dtsi"
+
+#include
+
+#include
+
+/ {
+ interrupt-parent = <&gic>;
+
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <1>;
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <2>;
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <3>;
+ };
+ cpu@100 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <4>;
+ };
+
+ cpu@101 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <5>;
+ };
+ cpu@102 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <6>;
+ };
+
+ cpu@103 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <7>;
+ };
+ };
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = ,
+,
+,
+;
+ clock-frequency = <2400>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2400>
[PATCH v2 3/3] ARM: dts: sun8i: Add A83T HomletV2 Board by Allwinner
H8Homlet Proto v2.0 Board is A83T Dev Board by Allwinner.
It has UART, ethernet, USB, HDMI, etc ports on it.
A83T patches are tested on this board.
It has UART, ethernet, USB, HDMI, etc ports on it.
For FEL mode it needs USB A-A(Male) cable. I used uart0 which
is multiplexed to microsd pins PF2 and PF4.
Enabled UART0 Header(PB9, PB10 pins).
Signed-off-by: Vishnu Patekar
---
.../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 64 ++
1 file changed, 64 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
new file mode 100644
index 000..342e1d3
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
@@ -0,0 +1,64 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ * Vishnu Patekar
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a83t.dtsi"
+
+/ {
+ model = "Allwinner A83T H8Homlet Proto Dev Board v2.0";
+ compatible = "allwinner,h8homlet-v2", "allwinner,sun8i-a83t";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_b>;
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Add basic support for Allwinner A83T SOC
This patch series adds very basic support for Allwinner A83T SOC. Clock, peripherals, smp support will be added later. Allwinner A83T is octa-core cortex-a7 based SoC. It's clock control unit and prcm, pinmux are different from previous sun8i series. Its processor cores are arragned in two clusters 4 cores each, similar to A80. Note: A83T pincontroller patch is already applied by Linus, so not added in this patch. changes from v1->v2: 1. used UART0 header with PB9, PB10 pins. 2. removed unnecessary includes and comments from dtsi. 3. arranged nodes in alphabatical order. 4. arrnaged compatible in alphabatical order. 5. changed cpu nodes to use cpu@100 -cpu@-103. 6. changed dts filename. Vishnu Patekar (3): ARM: sunxi: Introduce Allwinner for A83T support ARM: dts: sun8i: Add Allwinner A83T dtsi ARM: dts: sun8i: Add A83T HomletV2 Board by Allwinner Documentation/devicetree/bindings/arm/sunxi.txt| 1 + .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 64 ++ arch/arm/boot/dts/sun8i-a83t.dtsi | 247 + arch/arm/mach-sunxi/sunxi.c| 1 + drivers/clk/sunxi/clk-sunxi.c | 6 + 5 files changed, 319 insertions(+) create mode 100644 arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts create mode 100644 arch/arm/boot/dts/sun8i-a83t.dtsi -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] dt-binding: Add ngpios property to GPIO controller node
On Thu, Oct 22, 2015 at 1:52 PM, Ray Jui wrote: > > > On 10/22/2015 11:43 AM, Rob Herring wrote: >> >> On Mon, Oct 19, 2015 at 12:43 AM, Pramod Kumar >> wrote: >>> >>> Add ngpios property to the gpio controller's DT node so that controller >>> driver extracts total number of gpio lines present in controller >>> from DT and removes dependency on driver. >>> >>> Signed-off-by: Pramod Kumar >>> Reviewed-by: Ray Jui >>> Reviewed-by: Scott Branden >>> --- >>> Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 5 >>> + >>> 1 file changed, 5 insertions(+) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt >>> b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt >>> index f92b833..655a8d7 100644 >>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt >>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt >>> @@ -10,6 +10,9 @@ Required properties: >>> Define the base and range of the I/O address space that contains >>> the Cygnus >>> GPIO/PINCONF controller registers >>> >>> +- ngpios: >>> +Total number of GPIOs the controller provides >> >> >> This must be optional for compatibility and the driver needs to handle >> it not present. >> > > You meant to be compatible with existing Cygnus devices, correct? > > Just to clarify, here you suggest we still leave the existing hard coded > ngpios in the driver, in order to be compatible with all existing Cygnus > devices (while the Cygnus device tree changes to use ngpio is still being > merged and through different maintainer), and have all new iProc SoCs switch > to use ngpios from device tree, right? Yes, an existing dtb should continue to work with a new kernel. You can add the DT property to the older devices too and then eventually remove the hard coded values some time in the future. That could be immediately (don't care about compatibility at all), a couple of kernel cycles, never... It all depends on users of the impacted platforms. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] regulator: axp20x: Support new AXP223 PMIC
On Thu, Oct 15, 2015 at 12:32:20AM +0800, Chen-Yu Tsai wrote: > The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. > It is functionally identical to AXP221; only the regulator default > voltage/status and the external host interface are different. Reviwed-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH RFC v2 0/2] simplefb: Add regulator handling support
On Wed, Oct 21, 2015 at 01:58:59PM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This is v2 of the simplefb regulator support series. This series adds > regulator claiming and enabling support for simplefb. This approach seems reasonable Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong. Someone post the verifiable data showing that > there is a problem to be solved here. > Someone show what the specific failure cases are that are hampering > vendors moving forwards. Someone show the long boot times by way of > kernel message log. Someone show some evidence of the problems that > have been alluded to. > If no one can show some evidence, there isn't a problem here. :) Yeah, I'm not convinced the timing is *such* a big deal either - I do think that the log spam is a real problem but I think something much less invasive like the interface you proposed is good for addressing that. signature.asc Description: PGP signature
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:
> Something like this. I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?) See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> + if (driver_deferred_probe_report) {
> + struct va_format vaf;
> + va_list ap;
> +
> + va_start(ap, fmt);
> + vaf.fmt = fmt;
> + vaf.va = ≈
> +
> + dev_warn(dev, "deferring probe: %pV", &vaf);
> + va_end(ap);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);
I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error. That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly. The best I can think of is something
like
void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)
which requires the caller to pass in err twice to get it logged. That's
not a thing of beauty but it gets the job done... but perhaps your
original interface is better, it's a bit cleaner.
signature.asc
Description: PGP signature
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On Fri, Sep 11, 2015 at 05:31:57PM +0530, Viresh Kumar wrote: > +- supply-names: This is a required property, only if multiple supplies are > + available for the device. Otherwise it is optional. > + > + This list is used to pass names of all the device supplies. The order of > names > + present here is important, as that should match the order in which values > are > + present in 'opp-microvolt' and 'opp-microamp' properties. If we were going to add something like this (which I'm really not that thrilled about due to their encouragement of bad practice as previously discussed) it seems wrong to add it at the level of a specific binding rather than as a general facility. I think I'm not entirely sold on this use case though, I'll follow up to a later message in this thread... signature.asc Description: PGP signature
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On Thu, Oct 01, 2015 at 03:37:53PM -0500, Andrew F. Davis wrote:
> +static const struct of_device_id tps65912_regulator_of_match_table[] = {
> + { .compatible = "ti,tps65912-regulator", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, tps65912_regulator_of_match_table);
Does this IP block exist outside of the tps65912? If not why is it
directly represented in DT? It seems like this is describing how Linux
loads drivers not how the hardware is constructed but DT should describe
the hardware.
signature.asc
Description: PGP signature
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On Sat, Oct 17, 2015 at 09:40:55AM +0530, Viresh Kumar wrote: > Okay here is the problem statement: > We have two supplies for a device and the device node will have > something like: > name1-supply = <&supply1>; > name2-supply = <&supply2>; > And the OPP node needs to have voltages for both of them: > opp-microvolt = , ; > Where XYZ(1) are for supply1 and XYZ(2) are for supply2. > Now we need to identify the supplies for which the values are present > here and their order as well. How do we do that? > The way I am suggesting is to add a property in opp node which will > keep "name1" and "name2" in it. When we start doing this we also start having to worry about things like the sequencing of the updates between the various supplies and end up in full on power sequencing (or at least baking some sequencing into the DT which will doubtless need extending at some point). I'm not sure that's a place we want to end up just yet, I think it's safer to just have a little bit of code in the kernel that glues things together in the cases where this is needed. signature.asc Description: PGP signature
Re: [PATCH v2 2/3] regulator: arizona: Add regulator specific device tree binding document
On Thu, Oct 15, 2015 at 02:47:07PM +0100, Charles Keepax wrote: > +This document lists regulator specific bindings, see the primary binding > +document: > + ../mfd/arizona.txt > + > +Required properties: > + > + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, > +as covered in regulator.txt > + > + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, > +wm5110, wm8280, wm8998, wm1814) > + > + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, > +wm5110, wm8280, wm8998, wm1814) > + > + - SPKVDD-supply : Speaker driver power supply (wm8997) > + I'd expect these to be on the MFD since they're (with the exception of AVDD which supplies the regulators IIRC) not part of the regulator component of the device and are core for bringing it online. > +Optional properties: > + - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA > + > +Optional subnodes: > + - ldo1 : Initial data for the LDO1 regulator, as covered in > +Documentation/devicetree/bindings/regulator/regulator.txt > + - micvdd : Initial data for the MICVDD regulator, as covered in > +Documentation/devicetree/bindings/regulator/regulator.txt These are the properties for the regulator itself. > +++ b/MAINTAINERS > @@ -11381,6 +11381,7 @@ W: > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices > S: Supported > F: Documentation/hwmon/wm83?? > F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt > +F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt > F: arch/arm/mach-s3c64xx/mach-crag6410* > F: drivers/clk/clk-wm83*.c > F: drivers/extcon/extcon-arizona.c I'd suggest moving this to a separate patch which adds all the new files together to make it easier to merge things. signature.asc Description: PGP signature
Re: [PATCH v2 3/3] ASoC: cs47l24: Add driver for Cirrus Logic CS47L24 and WM1831 codecs
On Mon, Oct 19, 2015 at 03:13:47PM +0100, Richard Fitzgerald wrote: > @@ -134,6 +134,7 @@ config SND_SOC_ALL_CODECS > select SND_SOC_WM5100 if I2C > select SND_SOC_WM5102 if MFD_WM5102 > select SND_SOC_WM5110 if MFD_WM5110 > + select SND_SOC_CS47L24 if MFD_CS47L24 > select SND_SOC_WM8350 if MFD_WM8350 > select SND_SOC_WM8400 if MFD_WM8400 > select SND_SOC_WM8510 if SND_SOC_I2C_AND_SPI Please keep the Makefile and Kconfig sorted. > +config SND_SOC_CS47L24 > + tristate "TEST cs47l24" > + This isn't a good help text for the symbol. Otherwise the code looks good. signature.asc Description: PGP signature
Re: [PATCH] regulator, dt: add dt support for tps6502x regulator
On Thu, Oct 22, 2015 at 06:51:49AM +0200, Heiko Schocher wrote:
> Am 21.10.2015 um 18:17 schrieb Mark Brown:
> >>arch/arm/boot/dts/tps65217.dtsi
> >>but, okay, removed.
> >That too is broken and should be removed :(
> Ok, I have a board which uses this regulator ... can you give me a hint,
> how to remove it correctly?
> I would do:
> move from arch/arm/boot/dts/tps65217.dtsi into board dts
> &tps {
> + compatible = "ti,tps65217";
> [...]
> and the reg and "regulator-compatible" into the corresponding
> nodes ...
> dcdc1_reg: regulator@0 {
> +reg = <0>;
> +regulator-compatible = "dcdc1";
Yes, you should just put everything directly into the board DT.
signature.asc
Description: PGP signature
Re: [PATCH] extcon: add MAX3355 driver
Hello. On 10/21/2015 05:57 AM, Chanwoo Choi wrote: I think this patch is too much delay. I recommend you better to develop this driver based on latest extcon-next branch[1]. [1] https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next I would really appreciate if you answer my questions, I think most of them are still valid... MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms
Hi Murali, >> >> >> Again, there's other SoCs out there which have serdes. Adding 2.5k of >> lines for vendor serdes implementations does not scale - this needs to >> be re-thought in a way which reduces the code maintanence burden. >> >> Other SoCs like Marvell Armada have serdes links which can be configured >> between SATA, PCIe and Gbe. Should Armada end up adding another 2.5k >> lines to support their device too? What happens when we have 10 of >> these, and we have 25k lines of code here? >> >> Again, this does not scale. Please look at what can be done to reduce >> the code size when other implementations come along. > > > Well, per our understanding, this driver is a Generic phy driver and we have > implemented a device driver based on Generic Phy API. This driver is > expected to support all of the 3 peripherals :- PCIe, 1G and 10G Ethernet. > You have mentioned about Marvell & Armada . Did Marvell post any patch > already? Without seeing their code, how will we be able to investigate what > can be factored out to a generic serdes core driver? By making this > statement, I assume you are still considering using the Generic Phy driver > framework for SerDes drivers. Don't you? > > I did a search in the phy folder and these are the top ones that came out in > terms of number of lines of code after Phy-core.c. > > ls *.[ch] | xargs wc -l | sort -n > >943 phy-core.c > 1279 phy-miphy28lp.c > 1735 phy-xgene.c > 2367 phy-keystone-serdes.c > > So focusing on the top 3 drivers (including keystone serdes) under phy. > > phy-xgene.c > --- > > Looking at other drivers under drivers/phy, I could find phy-xgene.c which > is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose > PHY driver. It defines following mode per the driver code > > MODE_SATA = 0,/* List them for simple reference */ > MODE_SGMII = 1, > MODE_PCIE = 2, > MODE_USB= 3, > MODE_XFI= 4, > > But seems to support only MODE_SATA. From the code, it appears, this driver > is expected to be enhanced in the future to support additional modes. I have > copied the author to this email to participate in this discussion. Let me comment on this APM X-Gene driver. This driver is dead and won't be supported in near or foreseeable future. And someday, it will be ripped out. Based on experience, this solution (having PHY driver in Linux) can't be supported across boards and etc as it is just too much maintenance. And therefore, we followed Arnd B guidance and move all this into the boot loader. From Linux or OS perspective, it only cares about the interface in which its interface with. This is just your reference and may be this will help you as well. -Loc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms
+ Alexandre Torgue (Owner of phy-miphy28lp.c) + Loc Ho (Owner of phy-miphy28lp.c) On 10/22/2015 05:56 PM, Murali Karicheri wrote: On 10/22/2015 01:48 PM, Russell King - ARM Linux wrote: On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote: On 10/21/2015 08:56 AM, WingMan Kwok wrote: On TI's Keystone platforms, several peripherals such as the gbe ethernet switch, 10gbe ethernet switch and PCIe controller require the use of a SerDes for converting SoC parallel data into serialized data that can be output over a high-speed electrical interface, and also converting high-speed serial input data into parallel data that can be processed by the SoC. The SerDeses used by those peripherals, though they may be different, are largely similar in functionality and setup. Cut- Documentation/devicetree/bindings/phy/ti-phy.txt | 239 +++ drivers/pci/host/pci-keystone.c | 24 +- drivers/pci/host/pci-keystone.h |1 + drivers/phy/Kconfig |8 + drivers/phy/Makefile |1 + drivers/phy/phy-keystone-serdes.c| 2366 ++ 6 files changed, 2629 insertions(+), 10 deletions(-) create mode 100644 drivers/phy/phy-keystone-serdes.c Kishon, Bjorn Who will pick this up? Do we have time to get this in 4.4? I've been avoiding this since my initial comments, but if you're wanting to get it into v4.4, then I have to say something. Russell, I saw you have raised this point earlier against v1 of the patch series. I have responded as below (cut-n-pasted from that email) "The serdes on K2 are re-used on multiple hardware blocks as already indicated in this thread. It has got multiple lanes, each lane can be enabled/disabled, shutdown etc. Isn't generic phy framework added to support this type of hardware block? I see some enhancements needed for K2 serdes to support monitoring the serdes link and providing a status to the higher layer device. So I am not clear what different way you would like to handle serdes drivers? Why do you need a new framework? " KISHON VIJAY had responded saying "The PHY framework (in drivers/phy/) already provides a standard interface to be used by the controller drivers no?" But I have not seen your response to these questions from us. v2 and v3 has gone by and since all of the outstanding comments have been addressed and you have not responded to our questions, I thought this can be merged for 4.4. Good to see you have responded now :) Again, there's other SoCs out there which have serdes. Adding 2.5k of lines for vendor serdes implementations does not scale - this needs to be re-thought in a way which reduces the code maintanence burden. Other SoCs like Marvell Armada have serdes links which can be configured between SATA, PCIe and Gbe. Should Armada end up adding another 2.5k lines to support their device too? What happens when we have 10 of these, and we have 25k lines of code here? Again, this does not scale. Please look at what can be done to reduce the code size when other implementations come along. Well, per our understanding, this driver is a Generic phy driver and we have implemented a device driver based on Generic Phy API. This driver is expected to support all of the 3 peripherals :- PCIe, 1G and 10G Ethernet. You have mentioned about Marvell & Armada . Did Marvell post any patch already? Without seeing their code, how will we be able to investigate what can be factored out to a generic serdes core driver? By making this statement, I assume you are still considering using the Generic Phy driver framework for SerDes drivers. Don't you? I did a search in the phy folder and these are the top ones that came out in terms of number of lines of code after Phy-core.c. ls *.[ch] | xargs wc -l | sort -n 943 phy-core.c 1279 phy-miphy28lp.c 1735 phy-xgene.c 2367 phy-keystone-serdes.c So focusing on the top 3 drivers (including keystone serdes) under phy. phy-xgene.c --- Looking at other drivers under drivers/phy, I could find phy-xgene.c which is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose PHY driver. It defines following mode per the driver code MODE_SATA = 0,/* List them for simple reference */ MODE_SGMII = 1, MODE_PCIE = 2, MODE_USB= 3, MODE_XFI= 4, But seems to support only MODE_SATA. From the code, it appears, this driver is expected to be enhanced in the future to support additional modes. I have copied the author to this email to participate in this discussion. Keystone SerDes supports following modes KSERDES_PHY_SGMII, KSERDES_PHY_XGE, KSERDES_PHY_PCIE, KSERDES_PHY_HYPERLINK, KSERDES_PHY_SRIO And phy-miphy28lp.c - +#define PHY_TYPE_SATA
Re: [PATCH v11 2/6] pci: add Altera PCI vendor ID
On Thu, Oct 22, 2015 at 05:27:27PM +0800, Ley Foon Tan wrote: > Signed-off-by: Ley Foon Tan > --- > include/linux/pci_ids.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h > index d9ba49c..08e4462 100644 > --- a/include/linux/pci_ids.h > +++ b/include/linux/pci_ids.h > @@ -1550,6 +1550,8 @@ > #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227 > #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408 > > +#define PCI_VENDOR_ID_ALTERA 0x1172 > + This doesn't seem to be used anywhere, so I'll drop this patch. > #define PCI_VENDOR_ID_SBE0x1176 > #define PCI_DEVICE_ID_SBE_WANXL100 0x0301 > #define PCI_DEVICE_ID_SBE_WANXL200 0x0302 > -- > 1.8.2.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms
On 10/22/2015 01:48 PM, Russell King - ARM Linux wrote: On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote: On 10/21/2015 08:56 AM, WingMan Kwok wrote: On TI's Keystone platforms, several peripherals such as the gbe ethernet switch, 10gbe ethernet switch and PCIe controller require the use of a SerDes for converting SoC parallel data into serialized data that can be output over a high-speed electrical interface, and also converting high-speed serial input data into parallel data that can be processed by the SoC. The SerDeses used by those peripherals, though they may be different, are largely similar in functionality and setup. Cut- Documentation/devicetree/bindings/phy/ti-phy.txt | 239 +++ drivers/pci/host/pci-keystone.c | 24 +- drivers/pci/host/pci-keystone.h |1 + drivers/phy/Kconfig |8 + drivers/phy/Makefile |1 + drivers/phy/phy-keystone-serdes.c| 2366 ++ 6 files changed, 2629 insertions(+), 10 deletions(-) create mode 100644 drivers/phy/phy-keystone-serdes.c Kishon, Bjorn Who will pick this up? Do we have time to get this in 4.4? I've been avoiding this since my initial comments, but if you're wanting to get it into v4.4, then I have to say something. Russell, I saw you have raised this point earlier against v1 of the patch series. I have responded as below (cut-n-pasted from that email) "The serdes on K2 are re-used on multiple hardware blocks as already indicated in this thread. It has got multiple lanes, each lane can be enabled/disabled, shutdown etc. Isn't generic phy framework added to support this type of hardware block? I see some enhancements needed for K2 serdes to support monitoring the serdes link and providing a status to the higher layer device. So I am not clear what different way you would like to handle serdes drivers? Why do you need a new framework? " KISHON VIJAY had responded saying "The PHY framework (in drivers/phy/) already provides a standard interface to be used by the controller drivers no?" But I have not seen your response to these questions from us. v2 and v3 has gone by and since all of the outstanding comments have been addressed and you have not responded to our questions, I thought this can be merged for 4.4. Good to see you have responded now :) Again, there's other SoCs out there which have serdes. Adding 2.5k of lines for vendor serdes implementations does not scale - this needs to be re-thought in a way which reduces the code maintanence burden. Other SoCs like Marvell Armada have serdes links which can be configured between SATA, PCIe and Gbe. Should Armada end up adding another 2.5k lines to support their device too? What happens when we have 10 of these, and we have 25k lines of code here? Again, this does not scale. Please look at what can be done to reduce the code size when other implementations come along. Well, per our understanding, this driver is a Generic phy driver and we have implemented a device driver based on Generic Phy API. This driver is expected to support all of the 3 peripherals :- PCIe, 1G and 10G Ethernet. You have mentioned about Marvell & Armada . Did Marvell post any patch already? Without seeing their code, how will we be able to investigate what can be factored out to a generic serdes core driver? By making this statement, I assume you are still considering using the Generic Phy driver framework for SerDes drivers. Don't you? I did a search in the phy folder and these are the top ones that came out in terms of number of lines of code after Phy-core.c. ls *.[ch] | xargs wc -l | sort -n 943 phy-core.c 1279 phy-miphy28lp.c 1735 phy-xgene.c 2367 phy-keystone-serdes.c So focusing on the top 3 drivers (including keystone serdes) under phy. phy-xgene.c --- Looking at other drivers under drivers/phy, I could find phy-xgene.c which is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose PHY driver. It defines following mode per the driver code MODE_SATA = 0,/* List them for simple reference */ MODE_SGMII = 1, MODE_PCIE = 2, MODE_USB= 3, MODE_XFI= 4, But seems to support only MODE_SATA. From the code, it appears, this driver is expected to be enhanced in the future to support additional modes. I have copied the author to this email to participate in this discussion. Keystone SerDes supports following modes KSERDES_PHY_SGMII, KSERDES_PHY_XGE, KSERDES_PHY_PCIE, KSERDES_PHY_HYPERLINK, KSERDES_PHY_SRIO And phy-miphy28lp.c - +#define PHY_TYPE_SATA 1 +#define PHY_TYPE_PCIE 2 +#define PHY_TYPE_USB2 3 +#define PHY_TYPE_U
Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices
On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote: > On 22 October 2015 at 00:51, Scott Wood wrote: > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote: > > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood > > > wrote: > > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote: > > > > > Instead of trying to match and probe platform and AMBA devices right > > > > > after each is registered, delay their probes until > > > > > device_initcall_sync. > > > > > > > > > > This means that devices will start probing once all built-in drivers > > > > > have registered, and after all platform and AMBA devices from the DT > > > > > have been registered already. > > > > > > > > > > This allows us to prevent deferred probes by probing dependencies on > > > > > demand. > > > > > > > > > > Signed-off-by: Tomeu Vizoso > > > > > --- > > > > > > > > > > Changes in v4: > > > > > - Also defer probes of AMBA devices registered from the DT as they > > > > > can > > > > > also request resources. > > > > > > > > > > drivers/of/platform.c | 11 --- > > > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > > > > > This breaks arch/powerpc/sysdev/fsl_pci.c. The PCI bus is an OF > > > > platform > > > > device, and it must be probed before pcibios_init() which is a > > > > subsys_initcall(), or else the PCI bus never gets scanned. > > > > > > Thanks for the report. This is probably getting dropped, but it could > > > be disabled for PPC. > > > > I don't think that adding another arbitrary arch difference would be the > > right solution. > > I think Rob meant temporarily disable it while things get fixed. At > least, So, what is the permanent fix for the swiotlb issue (or more generally, the inability to have a late_initcall that runs after non-module, non-hotplug platform devices have been probed)? > I don't see any reason why PPC wouldn't benefit from this > series. It's not clear to me what the benefit of this is at all, much less for PPC. What is the fundamental problem with deferred probes? In the cover letter you say this change saves 2.3 seconds, but where is that time being consumed? Are the drivers taking too long in their probe function trying to initialize and then deferring, rather than checking for dependencies up front? Or are there really so many devices and such a pessimal ordering that most of the time is spent iterating through and reordering the list, with each defer happening quickly? Even if something different does need to be done at this level, forcing all OF platform devices to be probed at the late_initcall level seems quite intrusive. You limited it to OF because people complained that other things will break. Things still broke. Surely there's a better way to address the problem. Can't the delay be requested by drivers that might otherwise need to defer (which could be done incrementally, focusing on the worst performance problems), rather than enabling it for everything? -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants
* Andrew F. Davis [151022 09:21]:
> Using constants for pinctrl allows better readability and removes
> redundancy with comments.
You should use the include/dt-bindings/pinctrl/omap.h macro
AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching
the same things again later on.
Regards,
Tony
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/boot/dts/am335x-boneblack.dts | 44
> +-
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index eadbba3..a540a10 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -36,32 +36,32 @@
> &am33xx_pinmux {
> nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
> pinctrl-single,pins = <
> - 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
> AM33XX_PIN_OUTPUT */
> - 0xa0 0x08 /* lcd_data0.lcd_data0, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa4 0x08 /* lcd_data1.lcd_data1, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa8 0x08 /* lcd_data2.lcd_data2, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xac 0x08 /* lcd_data3.lcd_data3, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb0 0x08 /* lcd_data4.lcd_data4, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb4 0x08 /* lcd_data5.lcd_data5, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb8 0x08 /* lcd_data6.lcd_data6, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xbc 0x08 /* lcd_data7.lcd_data7, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc0 0x08 /* lcd_data8.lcd_data8, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc4 0x08 /* lcd_data9.lcd_data9, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc8 0x08 /* lcd_data10.lcd_data10,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xcc 0x08 /* lcd_data11.lcd_data11,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd0 0x08 /* lcd_data12.lcd_data12,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd4 0x08 /* lcd_data13.lcd_data13,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd8 0x08 /* lcd_data14.lcd_data14,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xdc 0x08 /* lcd_data15.lcd_data15,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xe0 0x00 /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT */
> - 0xe4 0x00 /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT */
> - 0xe8 0x00 /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 |
> AM33XX_PIN_OUTPUT */
> - 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> + 0x1b0 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
> xdma_event_intr0 */
> + 0xa0 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data0.lcd_data0 */
> + 0xa4 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data1.lcd_data1 */
> + 0xa8 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data2.lcd_data2 */
> + 0xac (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data3.lcd_data3 */
> + 0xb0 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data4.lcd_data4 */
> + 0xb4 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data5.lcd_data5 */
> + 0xb8 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data6.lcd_data6 */
> + 0xbc (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data7.lcd_data7 */
> + 0xc0 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data8.lcd_data8 */
> + 0xc4 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data9.lcd_data9 */
> + 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data10.lcd_data10 */
> + 0xcc (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data11.lcd_data11 */
> + 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data12.lcd_data12 */
> + 0xd4 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data13.lcd_data13 */
> + 0xd8 (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data14.lcd_data14 */
> + 0xdc (PIN_OUTPUT | MUX_MODE0) /*
> lcd_data15.lcd_data15 */
> + 0xe0 (PIN_O
[PATCH] power: qcom_smbb: Add otg regulator for control of vbus
Add a regulator to control the OTG chargepath switch. The OTG
switch gets its power from pm8941_5vs1, and that should be expressed
as an usb_otg_in-supply property in the DT node for the charger driver.
The regulator name is "otg". This is used by USB code to control VBUS
direction.
Signed-off-by: Tim Bird
---
.../devicetree/bindings/power_supply/qcom_smbb.txt | 20 ++
drivers/power/qcom_smbb.c | 74 ++
2 files changed, 94 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
index 65b88fa..dc0f91d 100644
--- a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
+++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
@@ -105,6 +105,23 @@ PROPERTIES
regulation must be done externally to fully comply with
the JEITA safety guidelines if this flag is set.
+- usb_otg_in-supply:
+ Usage: optional
+ Value type:
+ Description: Reference to the regulator supplying power to the USB_OTG_IN
+ pin.
+
+child nodes:
+- otg:
+ Usage: optional
+ Description: This node is used to define a regulator which is used by
+ other parts of the system to control the direction of VBUS
+ voltage - specifically: whether to supply voltage to VBUS for
+ host mode operation of the OTG port. The driver registers a
+ regulator with this name, which can be looked up by string.
+ Alternatively, you can add a DT label, which can then be
+ referenced by phandle.
+
EXAMPLE
charger@1000 {
compatible = "qcom,pm8941-charger";
@@ -128,4 +145,7 @@ charger@1000 {
qcom,fast-charge-current-limit = <100>;
qcom,dc-charge-current-limit = <100>;
+ usb_otg_in-supply = <&pm8941_5vs1>;
+
+ otg {};
};
diff --git a/drivers/power/qcom_smbb.c b/drivers/power/qcom_smbb.c
index 0dabfe8..fa2983a 100644
--- a/drivers/power/qcom_smbb.c
+++ b/drivers/power/qcom_smbb.c
@@ -34,6 +34,9 @@
#include
#include
#include
+#include
+#include
+#include
#define SMBB_CHG_VMAX 0x040
#define SMBB_CHG_VSAFE 0x041
@@ -71,6 +74,8 @@
#define BTC_CTRL_HOT_EXT_N BIT(0)
#define SMBB_USB_IMAX 0x344
+#define SMBB_USB_OTG_CTL 0x348
+#define OTG_CTL_EN BIT(0)
#define SMBB_USB_ENUM_TIMER_STOP 0x34e
#define ENUM_TIMER_STOPBIT(0)
#define SMBB_USB_SEC_ACCESS0x3d0
@@ -123,6 +128,9 @@ struct smbb_charger {
struct power_supply *dc_psy;
struct power_supply *bat_psy;
struct regmap *regmap;
+
+ struct regulator_desc otg_rdesc;
+ struct regulator_dev *otg_reg;
};
static int smbb_vbat_weak_fn(unsigned int index)
@@ -778,12 +786,56 @@ static const struct power_supply_desc dc_psy_desc = {
.property_is_writeable = smbb_charger_writable_property,
};
+static int smbb_chg_otg_enable(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+ OTG_CTL_EN, OTG_CTL_EN);
+ if (rc)
+ dev_err(chg->dev, "failed to update OTG_CTL\n");
+ return rc;
+}
+
+static int smbb_chg_otg_disable(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ int rc;
+
+ rc = regmap_update_bits(chg->regmap, chg->addr + SMBB_USB_OTG_CTL,
+ OTG_CTL_EN, 0);
+ if (rc)
+ dev_err(chg->dev, "failed to update OTG_CTL\n");
+ return rc;
+}
+
+static int smbb_chg_otg_is_enabled(struct regulator_dev *rdev)
+{
+ struct smbb_charger *chg = rdev_get_drvdata(rdev);
+ unsigned int value = 0;
+ int rc;
+
+ rc = regmap_read(chg->regmap, chg->addr + SMBB_USB_OTG_CTL, &value);
+ if (rc)
+ dev_err(chg->dev, "failed to read OTG_CTL\n");
+
+ return !!(value & OTG_CTL_EN);
+}
+
+static struct regulator_ops smbb_chg_otg_ops = {
+ .enable = smbb_chg_otg_enable,
+ .disable = smbb_chg_otg_disable,
+ .is_enabled = smbb_chg_otg_is_enabled,
+};
+
static int smbb_charger_probe(struct platform_device *pdev)
{
struct power_supply_config bat_cfg = {};
struct power_supply_config usb_cfg = {};
struct power_supply_config dc_cfg = {};
struct smbb_charger *chg;
+ struct regulator_config config = { };
int rc, i;
chg = devm_kzalloc(&pdev->dev, sizeof(*chg), GFP_KERNEL);
@@ -884,6 +936,28 @@ static int smbb_charger_probe(struct platform_device *pdev)
}
}
+ /*
+* otg regulator is used to control VBUS voltage direction
+* when USB switches between host and gadget mode
+*/
+ chg->otg_rdesc.id = -1;
+ chg->otg_rdesc.name = "otg";
Re: [PATCH 3/3] i2c: uniphier: add bindings for UniPhier I2C controllers
On Thu, Jul 30, 2015 at 05:12:22PM +0900, Masahiro Yamada wrote: > Device Tree bindings for two I2C controllers embedded in > UniPhier SoCs. > > Signed-off-by: Masahiro Yamada Please split this into two files with filenames matching those of the drivers. I know they will be very similar but I'd like to keep consistent. signature.asc Description: Digital signature
Re: [PATCH v7 2/6] of: overlay: global sysfs enable attribute
Hi Greg,
> On Oct 22, 2015, at 23:19 , Greg Kroah-Hartman
> wrote:
>
> On Thu, Oct 22, 2015 at 10:50:23PM +0300, Pantelis Antoniou wrote:
>> A throw once master enable switch to protect against any
>> further overlay applications if the administrator desires so.
>>
>> A kernel command line option is provided as well.
>>
>> Signed-off-by: Pantelis Antoniou
>> ---
>> drivers/of/overlay.c | 50 +-
>> 1 file changed, 49 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>> index 12c3e47..91f10ed 100644
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -21,6 +21,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "of_private.h"
>>
>> @@ -55,8 +56,19 @@ struct of_overlay {
>> struct kobject kobj;
>> };
>>
>> +/* master enable switch; once set to 0 can't be re-enabled */
>> +static atomic_t ov_enable = ATOMIC_INIT(1);
>> +
>> +static int __init of_overlay_disable_setup(char *str __always_unused)
>> +{
>> +atomic_set(&ov_enable, 0);
>> +return 1;
>> +}
>> +__setup("of_overlay_disable", of_overlay_disable_setup);
>> +
>> static int of_overlay_apply_one(struct of_overlay *ov,
>> struct device_node *target, const struct device_node *overlay);
>> +static int overlay_removal_is_ok(struct of_overlay *ov);
>>
>> static int of_overlay_apply_single_property(struct of_overlay *ov,
>> struct device_node *target, struct property *prop)
>> @@ -339,6 +351,35 @@ void of_overlay_release(struct kobject *kobj)
>> kfree(ov);
>> }
>>
>> +static ssize_t enable_show(struct kobject *kobj,
>> +struct kobj_attribute *attr, char *buf)
>> +{
>> +return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&ov_enable));
>
> Minor nit, you never need to care about the size of the buffer for a
> sysfs file, if you do, you are doing something wrong. So this can just
> be:
> return sprintf(buf, "%d\n", atomic_read(&ov_enable));
>
>
Nice to know; I have a ingrained habit to avoid standard sprintf, so..
> Anyway, nothing worth keeping this from being merged:
>
Thanks!
> Acked-by: Greg Kroah-Hartman
>
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 6/6] Documentation: ABI: overlays - per overlay docs
On Thu, Oct 22, 2015 at 10:50:27PM +0300, Pantelis Antoniou wrote: > Documentation for the per-overlay attributes. > > Signed-off-by: Pantelis Antoniou Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/6] of: overlay: add per overlay sysfs attributes
On Thu, Oct 22, 2015 at 10:50:26PM +0300, Pantelis Antoniou wrote:
> * A per overlay can_remove sysfs attribute that reports whether
> the overlay can be removed or not due to another overlapping overlay.
>
> * A target sysfs attribute listing the target of each fragment,
> in a group named after the name of the fragment.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/overlay.c | 103
> +--
> 1 file changed, 99 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 91f10ed..6398810 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -25,8 +25,23 @@
>
> #include "of_private.h"
>
> +/* fwd. decl */
> +struct of_overlay;
> +struct of_overlay_info;
> +
> +/* an attribute for each fragment */
> +struct fragment_attribute {
> + struct attribute attr;
> + ssize_t (*show)(struct kobject *kobj, struct fragment_attribute *fattr,
> + char *buf);
> + ssize_t (*store)(struct kobject *kobj, struct fragment_attribute *fattr,
> + const char *buf, size_t count);
> + struct of_overlay_info *ovinfo;
> +};
> +
> /**
> * struct of_overlay_info - Holds a single overlay info
> + * @info:info node that contains the target and overlay
> * @target: target of the overlay operation
> * @overlay: pointer to the overlay contents node
> *
> @@ -34,8 +49,13 @@
> * records.
> */
> struct of_overlay_info {
> + struct of_overlay *ov;
> + struct device_node *info;
> struct device_node *target;
> struct device_node *overlay;
> + struct attribute_group attr_group;
> + struct attribute *attrs[2];
> + struct fragment_attribute target_attr;
> };
>
> /**
> @@ -52,6 +72,7 @@ struct of_overlay {
> struct list_head node;
> int count;
> struct of_overlay_info *ovinfo_tab;
> + const struct attribute_group **attr_groups;
> struct of_changeset cset;
> struct kobject kobj;
> };
> @@ -252,6 +273,8 @@ static int of_fill_overlay_info(struct of_overlay *ov,
> if (ovinfo->target == NULL)
> goto err_fail;
>
> + ovinfo->info = of_node_get(info_node);
> +
> return 0;
>
> err_fail:
> @@ -262,6 +285,17 @@ err_fail:
> return -EINVAL;
> }
>
> +static ssize_t target_show(struct kobject *kobj,
> + struct fragment_attribute *fattr, char *buf)
> +{
> + struct of_overlay_info *ovinfo = fattr->ovinfo;
> +
> + return snprintf(buf, PAGE_SIZE, "%s\n",
> + of_node_full_name(ovinfo->target));
Same minor nit here, but really not a big deal, nice job overall with
this, sorry working with 'raw' kobjects is so messy.
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/6] Documentation: document of_overlay_disable parameter
On Thu, Oct 22, 2015 at 10:50:25PM +0300, Pantelis Antoniou wrote: > Document the of_overlay_disable parameter. > > Signed-off-by: Pantelis Antoniou Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/6] Documentation: ABI: overlays - global attributes
On Thu, Oct 22, 2015 at 10:50:24PM +0300, Pantelis Antoniou wrote: > Documentation ABI entry for overlays sysfs entries. > > Signed-off-by: Pantelis Antoniou Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/6] of: overlay: global sysfs enable attribute
On Thu, Oct 22, 2015 at 10:50:23PM +0300, Pantelis Antoniou wrote:
> A throw once master enable switch to protect against any
> further overlay applications if the administrator desires so.
>
> A kernel command line option is provided as well.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/of/overlay.c | 50 +-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 12c3e47..91f10ed 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "of_private.h"
>
> @@ -55,8 +56,19 @@ struct of_overlay {
> struct kobject kobj;
> };
>
> +/* master enable switch; once set to 0 can't be re-enabled */
> +static atomic_t ov_enable = ATOMIC_INIT(1);
> +
> +static int __init of_overlay_disable_setup(char *str __always_unused)
> +{
> + atomic_set(&ov_enable, 0);
> + return 1;
> +}
> +__setup("of_overlay_disable", of_overlay_disable_setup);
> +
> static int of_overlay_apply_one(struct of_overlay *ov,
> struct device_node *target, const struct device_node *overlay);
> +static int overlay_removal_is_ok(struct of_overlay *ov);
>
> static int of_overlay_apply_single_property(struct of_overlay *ov,
> struct device_node *target, struct property *prop)
> @@ -339,6 +351,35 @@ void of_overlay_release(struct kobject *kobj)
> kfree(ov);
> }
>
> +static ssize_t enable_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&ov_enable));
Minor nit, you never need to care about the size of the buffer for a
sysfs file, if you do, you are doing something wrong. So this can just
be:
return sprintf(buf, "%d\n", atomic_read(&ov_enable));
Anyway, nothing worth keeping this from being merged:
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/6] of: overlay: kobjectify overlay objects
On Thu, Oct 22, 2015 at 10:50:22PM +0300, Pantelis Antoniou wrote: > We are going to need the overlays to appear on sysfs with runtime > global properties (like master enable) so turn them into kobjects. > > They have to be in sysfs so that people can have information about the > overlays applied in the system, i.e. where their targets are and whether > removal is possible. In a future more attributes can be added > in a backwards compatible manner. > > Signed-off-by: Pantelis Antoniou Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: of_mdiobus_register_phy() and deferred probe
Hello.
On 10/22/2015 04:31 PM, Geert Uytterhoeven wrote:
Due to a probe deferral of an interrupt controller[1], the Micrel
Ethernet PHY on
r8a7791/koelsch started failing to get its IRQ:
no irq domain found for /interrupt-controller@e61c !
However, of_mdiobus_register_phy() uses irq_of_parse_and_map(), which plainly
ignores EPROBE_DEFER, and it just continues.
Later I get:
sh-eth ee70.ethernet eth0: attached PHY 1 (IRQ -1) to driver
Micrel KSZ8041RNLI
instead of
sh-eth ee70.ethernet eth0: attached PHY 1 (IRQ 408) to driver
Micrel KSZ8041RNLI
Ethernet still works, as the interrupt seems to be unneeded(?).
Yes, the phylib uses PHY polling anyway, IRQ isn't strictly necessary.
Has anyone already looked into fixing of_mdio to handle deferred probing?
It's the first time I hear about that. Will have to look into this...
Gr{oetje,eeting}s,
Geert
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/6] of: overlay: kobjectify overlay objects
We are going to need the overlays to appear on sysfs with runtime
global properties (like master enable) so turn them into kobjects.
They have to be in sysfs so that people can have information about the
overlays applied in the system, i.e. where their targets are and whether
removal is possible. In a future more attributes can be added
in a backwards compatible manner.
Signed-off-by: Pantelis Antoniou
---
drivers/of/base.c | 7 +++
drivers/of/of_private.h | 9 +
drivers/of/overlay.c| 50 +++--
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8b5a187..31c0c8f 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -192,6 +192,7 @@ int __of_attach_node_sysfs(struct device_node *np)
void __init of_core_init(void)
{
struct device_node *np;
+ int ret;
/* Create the kset, and register existing nodes */
mutex_lock(&of_mutex);
@@ -208,6 +209,12 @@ void __init of_core_init(void)
/* Symlink in /proc as required by userspace ABI */
if (of_root)
proc_symlink("device-tree", NULL,
"/sys/firmware/devicetree/base");
+
+ ret = of_overlay_init();
+ if (ret != 0)
+ pr_warn("of_init: of_overlay_init failed!\n");
+
+ return 0;
}
static struct property *__of_find_property(const struct device_node *np,
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8e882e7..120eb44 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -90,4 +90,13 @@ extern void __of_detach_node_sysfs(struct device_node *np);
#define for_each_transaction_entry_reverse(_oft, _te) \
list_for_each_entry_reverse(_te, &(_oft)->te_list, node)
+#if defined(CONFIG_OF_OVERLAY)
+extern int of_overlay_init(void);
+#else
+static inline int of_overlay_init(void)
+{
+ return 0;
+}
+#endif
+
#endif /* _LINUX_OF_PRIVATE_H */
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 24e025f..12c3e47 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "of_private.h"
@@ -51,6 +52,7 @@ struct of_overlay {
int count;
struct of_overlay_info *ovinfo_tab;
struct of_changeset cset;
+ struct kobject kobj;
};
static int of_overlay_apply_one(struct of_overlay *ov,
@@ -325,6 +327,24 @@ static int of_free_overlay_info(struct of_overlay *ov)
static LIST_HEAD(ov_list);
static DEFINE_IDR(ov_idr);
+static inline struct of_overlay *kobj_to_overlay(struct kobject *kobj)
+{
+ return container_of(kobj, struct of_overlay, kobj);
+}
+
+void of_overlay_release(struct kobject *kobj)
+{
+ struct of_overlay *ov = kobj_to_overlay(kobj);
+
+ kfree(ov);
+}
+
+static struct kobj_type of_overlay_ktype = {
+ .release = of_overlay_release,
+};
+
+static struct kset *ov_kset;
+
/**
* of_overlay_create() - Create and apply an overlay
* @tree: Device node containing all the overlays
@@ -350,6 +370,9 @@ int of_overlay_create(struct device_node *tree)
of_changeset_init(&ov->cset);
+ /* initialize kobject */
+ kobject_init(&ov->kobj, &of_overlay_ktype);
+
mutex_lock(&of_mutex);
id = idr_alloc(&ov_idr, ov, 0, 0, GFP_KERNEL);
@@ -385,6 +408,14 @@ int of_overlay_create(struct device_node *tree)
goto err_revert_overlay;
}
+ ov->kobj.kset = ov_kset;
+ err = kobject_add(&ov->kobj, NULL, "%d", id);
+ if (err != 0) {
+ pr_err("%s: kobject_add() failed for tree@%s\n",
+ __func__, tree->full_name);
+ goto err_cancel_overlay;
+ }
+
/* add to the tail of the overlay list */
list_add_tail(&ov->node, &ov_list);
@@ -392,6 +423,8 @@ int of_overlay_create(struct device_node *tree)
return id;
+err_cancel_overlay:
+ of_changeset_revert(&ov->cset);
err_revert_overlay:
err_abort_trans:
of_free_overlay_info(ov);
@@ -512,7 +545,8 @@ int of_overlay_destroy(int id)
of_free_overlay_info(ov);
idr_remove(&ov_idr, id);
of_changeset_destroy(&ov->cset);
- kfree(ov);
+
+ kobject_put(&ov->kobj);
err = 0;
@@ -542,7 +576,7 @@ int of_overlay_destroy_all(void)
of_changeset_revert(&ov->cset);
of_free_overlay_info(ov);
idr_remove(&ov_idr, ov->id);
- kfree(ov);
+ kobject_put(&ov->kobj);
}
mutex_unlock(&of_mutex);
@@ -550,3 +584,15 @@ int of_overlay_destroy_all(void)
return 0;
}
EXPORT_SYMBOL_GPL(of_overlay_destroy_all);
+
+/* called from of_init() */
+int of_overlay_init(void)
+{
+ int rc;
+
+ ov_kset = kset_create_and_add("overlays", NULL, &of_kset->kobj);
+ if (!ov_kset)
+ return -ENOMEM;
+
+ return 0;
+}
--
1.7.12
--
To unsubsc
[PATCH v7 2/6] of: overlay: global sysfs enable attribute
A throw once master enable switch to protect against any
further overlay applications if the administrator desires so.
A kernel command line option is provided as well.
Signed-off-by: Pantelis Antoniou
---
drivers/of/overlay.c | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 12c3e47..91f10ed 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "of_private.h"
@@ -55,8 +56,19 @@ struct of_overlay {
struct kobject kobj;
};
+/* master enable switch; once set to 0 can't be re-enabled */
+static atomic_t ov_enable = ATOMIC_INIT(1);
+
+static int __init of_overlay_disable_setup(char *str __always_unused)
+{
+ atomic_set(&ov_enable, 0);
+ return 1;
+}
+__setup("of_overlay_disable", of_overlay_disable_setup);
+
static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay);
+static int overlay_removal_is_ok(struct of_overlay *ov);
static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop)
@@ -339,6 +351,35 @@ void of_overlay_release(struct kobject *kobj)
kfree(ov);
}
+static ssize_t enable_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&ov_enable));
+}
+
+static ssize_t enable_store(struct kobject *kobj,
+ struct kobj_attribute *attr, const char *buf, size_t count)
+{
+ int ret;
+ bool new_enable;
+
+ ret = strtobool(buf, &new_enable);
+ if (ret != 0)
+ return ret;
+ /* if we've disabled it, no going back */
+ if (atomic_read(&ov_enable) == 0)
+ return -EPERM;
+ atomic_set(&ov_enable, (int)new_enable);
+ return count;
+}
+
+static struct kobj_attribute enable_attr = __ATTR_RW(enable);
+
+static const struct attribute *overlay_global_attrs[] = {
+ &enable_attr.attr,
+ NULL
+};
+
static struct kobj_type of_overlay_ktype = {
.release = of_overlay_release,
};
@@ -360,6 +401,10 @@ int of_overlay_create(struct device_node *tree)
struct of_overlay *ov;
int err, id;
+ /* administratively disabled */
+ if (!atomic_read(&ov_enable))
+ return -EPERM;
+
/* allocate the overlay structure */
ov = kzalloc(sizeof(*ov), GFP_KERNEL);
if (ov == NULL)
@@ -594,5 +639,8 @@ int of_overlay_init(void)
if (!ov_kset)
return -ENOMEM;
- return 0;
+ rc = sysfs_create_files(&ov_kset->kobj, overlay_global_attrs);
+ WARN(rc, "%s: error adding global attributes\n", __func__);
+
+ return rc;
}
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/6] Documentation: document of_overlay_disable parameter
Document the of_overlay_disable parameter. Signed-off-by: Pantelis Antoniou --- Documentation/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 22a4b68..8ca89d9 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -90,6 +90,7 @@ parameter is applicable: NET Appropriate network support is enabled. NUMANUMA support is enabled. NFS Appropriate NFS support is enabled. + OF Open Firmware support (device tree) is enabled. OSS OSS sound support is enabled. PV_OPS A paravirtualized kernel is enabled. PARIDE The ParIDE (parallel port IDE) subsystem is enabled. @@ -2579,6 +2580,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. This can be set from sysctl after boot. See Documentation/sysctl/vm.txt for details. + of_overlay_disable [OF] Disable device tree overlays at boot time. + ohci1394_dma=early [HW] enable debugging via the ohci1394 driver. See Documentation/debugging-via-ohci1394.txt for more info. -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/6] of: overlay: kobject & sysfs'ation
The first patch puts the overlays as objects in the sysfs in /sys/firmware/devicetree/overlays. The #2 adds a master overlay enable switch (that once is set to disabled can't be re-enabled), while the one after that introduces a number of default per overlay attributes. The patch following is the ABI docs for the sysfs entries of #2, while the next one updates the doc entry for the kernel parameter of_overlay_disable. Patch #5 add per overlay sysfs attributes, and the next one is documentation about it. The patchset is against linus's tree as of today. Changes since v6: * Updated changelogs as per maintainer suggestion. * Fixed documentation entries and split them up * Added command line parameter docs. Changes since v5: * Does a single kobject_put that suffices * A per-fragment sysfs directory and a single value target. * Update in the ABI documention. Changes since v4: * Rebased against latest mainline. Changes since v3: * Used strtobool instead of kstrtoul * ABI Documentation includes a pointer to the discussion that requested the sysfs property. Changes since v2: * Removed the unittest patch. * Split the sysfs attribute patch to a global and a per-overlay patch. * Dropped binary attributes using textual kobj_attributes instead. Changes since v1: * Maintainer requested changes. * Documented the sysfs entries * Per overlay sysfs attributes. Pantelis Antoniou (6): of: overlay: kobjectify overlay objects of: overlay: global sysfs enable attribute Documentation: ABI: overlays - global attributes Documentation: document of_overlay_disable parameter of: overlay: add per overlay sysfs attributes Documentation: ABI: overlays - per overlay docs .../ABI/testing/sysfs-firmware-devicetree-overlays | 52 ++ Documentation/kernel-parameters.txt| 3 + drivers/of/base.c | 7 + drivers/of/of_private.h| 9 + drivers/of/overlay.c | 201 - 5 files changed, 266 insertions(+), 6 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 6/6] Documentation: ABI: overlays - per overlay docs
Documentation for the per-overlay attributes. Signed-off-by: Pantelis Antoniou --- .../ABI/testing/sysfs-firmware-devicetree-overlays | 28 ++ 1 file changed, 28 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays index e938f44..88d1549 100644 --- a/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays +++ b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays @@ -22,3 +22,31 @@ Description: to be a high-level one-way "off" switch for the interface so that systems that have this interface can choose to turn it off during initial boot, etc." + +What: /sys/firmware/devicetree/overlays/ +Date: October 2015 +Contact: Pantelis Antoniou +Description: + Each directory represents an applied overlay, containing + the following attribute files. + +What: /sys/firmware/devicetree/overlays//can_remove +Date: October 2015 +Contact: Pantelis Antoniou +Description: + The attribute set to 1 means that the overlay can be removed, + while 0 means that the overlay is being overlapped therefore + removal is prohibited. + +What: /sys/firmware/devicetree/overlays/// +Date: October 2015 +Contact: Pantelis Antoniou +Description: + Each of these directories contain information about of the + particular overlay fragment. + +What: /sys/firmware/devicetree/overlays///target +Date: October 2015 +Contact: Pantelis Antoniou +Description: + The full-path of the target of the fragment -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 5/6] of: overlay: add per overlay sysfs attributes
* A per overlay can_remove sysfs attribute that reports whether
the overlay can be removed or not due to another overlapping overlay.
* A target sysfs attribute listing the target of each fragment,
in a group named after the name of the fragment.
Signed-off-by: Pantelis Antoniou
---
drivers/of/overlay.c | 103 +--
1 file changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 91f10ed..6398810 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -25,8 +25,23 @@
#include "of_private.h"
+/* fwd. decl */
+struct of_overlay;
+struct of_overlay_info;
+
+/* an attribute for each fragment */
+struct fragment_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct kobject *kobj, struct fragment_attribute *fattr,
+ char *buf);
+ ssize_t (*store)(struct kobject *kobj, struct fragment_attribute *fattr,
+const char *buf, size_t count);
+ struct of_overlay_info *ovinfo;
+};
+
/**
* struct of_overlay_info - Holds a single overlay info
+ * @info: info node that contains the target and overlay
* @target:target of the overlay operation
* @overlay: pointer to the overlay contents node
*
@@ -34,8 +49,13 @@
* records.
*/
struct of_overlay_info {
+ struct of_overlay *ov;
+ struct device_node *info;
struct device_node *target;
struct device_node *overlay;
+ struct attribute_group attr_group;
+ struct attribute *attrs[2];
+ struct fragment_attribute target_attr;
};
/**
@@ -52,6 +72,7 @@ struct of_overlay {
struct list_head node;
int count;
struct of_overlay_info *ovinfo_tab;
+ const struct attribute_group **attr_groups;
struct of_changeset cset;
struct kobject kobj;
};
@@ -252,6 +273,8 @@ static int of_fill_overlay_info(struct of_overlay *ov,
if (ovinfo->target == NULL)
goto err_fail;
+ ovinfo->info = of_node_get(info_node);
+
return 0;
err_fail:
@@ -262,6 +285,17 @@ err_fail:
return -EINVAL;
}
+static ssize_t target_show(struct kobject *kobj,
+ struct fragment_attribute *fattr, char *buf)
+{
+ struct of_overlay_info *ovinfo = fattr->ovinfo;
+
+ return snprintf(buf, PAGE_SIZE, "%s\n",
+ of_node_full_name(ovinfo->target));
+}
+
+static const struct fragment_attribute target_template_attr =
__ATTR_RO(target);
+
/**
* of_build_overlay_info() - Build an overlay info array
* @ov Overlay to build
@@ -279,7 +313,7 @@ static int of_build_overlay_info(struct of_overlay *ov,
{
struct device_node *node;
struct of_overlay_info *ovinfo;
- int cnt, err;
+ int i, cnt, err;
/* worst case; every child is a node */
cnt = 0;
@@ -300,14 +334,45 @@ static int of_build_overlay_info(struct of_overlay *ov,
/* if nothing filled, return error */
if (cnt == 0) {
- kfree(ovinfo);
- return -ENODEV;
+ err = -ENODEV;
+ goto err_free_ovinfo;
}
ov->count = cnt;
ov->ovinfo_tab = ovinfo;
+ ov->attr_groups = kcalloc(cnt + 1,
+ sizeof(struct attribute_group *), GFP_KERNEL);
+ if (ov->attr_groups == NULL) {
+ err = -ENOMEM;
+ goto err_free_ovinfo;
+ }
+
+ for (i = 0; i < cnt; i++) {
+ ovinfo = &ov->ovinfo_tab[i];
+
+ ov->attr_groups[i] = &ovinfo->attr_group;
+
+ ovinfo->target_attr = target_template_attr;
+ /* make lockdep happy */
+ sysfs_attr_init(&ovinfo->target_attr.attr);
+ ovinfo->target_attr.ovinfo = ovinfo;
+
+ ovinfo->attrs[0] = &ovinfo->target_attr.attr;
+ ovinfo->attrs[1] = NULL;
+
+ /* NOTE: direct reference to the full_name */
+ ovinfo->attr_group.name = kbasename(ovinfo->info->full_name);
+ ovinfo->attr_group.attrs = ovinfo->attrs;
+
+ }
+ ov->attr_groups[i] = NULL;
+
return 0;
+
+err_free_ovinfo:
+ kfree(ovinfo);
+ return err;
}
/**
@@ -324,12 +389,16 @@ static int of_free_overlay_info(struct of_overlay *ov)
struct of_overlay_info *ovinfo;
int i;
+ /* free attribute groups space */
+ kfree(ov->attr_groups);
+
/* do it in reverse */
for (i = ov->count - 1; i >= 0; i--) {
ovinfo = &ov->ovinfo_tab[i];
of_node_put(ovinfo->target);
of_node_put(ovinfo->overlay);
+ of_node_put(ovinfo->info);
}
kfree(ov->ovinfo_tab);
@@ -380,8 +449,25 @@ static const struct attribute *overlay_global_attrs[] = {
NULL
};
+static ssize_t can_remove_show(struct kobject *kobj,
+ struct kobj_attribute *a
[PATCH v7 3/6] Documentation: ABI: overlays - global attributes
Documentation ABI entry for overlays sysfs entries. Signed-off-by: Pantelis Antoniou --- .../ABI/testing/sysfs-firmware-devicetree-overlays | 24 ++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays diff --git a/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays new file mode 100644 index 000..e938f44 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-devicetree-overlays @@ -0,0 +1,24 @@ +What: /sys/firmware/devicetree/overlays/ +Date: October 2015 +Contact: Pantelis Antoniou +Description: + This directory contains the applied device tree overlays of + the running system, as directories of the overlay id. + +What: /sys/firmware/devicetree/overlays/enable +Date: October 2015 +Contact: Pantelis Antoniou +Description: + The master enable switch, by default is 1, and when + set to 0 it cannot be re-enabled for security reasons. + + The discussion about this switch takes place in: + http://comments.gmane.org/gmane.linux.drivers.devicetree/101871 + + Kees Cook: + "Coming from the perspective of drawing a bright line between + kernel and the root user (which tends to start with disabling + kernel module loading), I would say that there at least needs + to be a high-level one-way "off" switch for the interface so + that systems that have this interface can choose to turn it off + during initial boot, etc." -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > >> But that's moot currently because Greg believes that the time spent > >> probing devices at boot time could be reduced enough so that the order > >> in which devices are probed becomes irrelevant. IME that would have to > >> be under 200ms so that the user doesn't notice and that's unicorn-far > >> from any bootlog I have ever seen. > > > > But as no one has actually produced a bootlog, how do you know that? > > Where exactly is your time being spent? What driver is causing long > > delays? Why is the long-delay-drivers not being done in their own > > thread? And most importantly, why are you ignoring the work that people > > did back in 2008 to solve the issue on other hardware platforms? > > > >> Given that downstreams are already carrying as many hacks as they > >> could think of to speed total boot up, I think this is effectively > >> telling them to go away. > > > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > > solve-the-random-issue-i'm-having type patch by putting random calls in > > semi-random subsystems all over the kernel. > > > > And when I ask for real data, you respond with the fact that you aren't > > trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I agree, there might be some small numbers that this is a problem for, and if so, great, show us the boot logs where things are taking up all of the time, and we can work on resolving those issues. But without hard numbers / details, this all is just random hand-waving, and I don't like making core kernel changes on that basis. And no one else should ever want us to do that either. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-nfc] [PATCH v2 3/9] NFC: nfcmrvl: add firmware download support
Hi Samuel,
> Le 22 oct. 2015 à 17:44, Samuel Ortiz a écrit :
>
...
+enum nfcmrvl_phy {
+NFCMRVL_PHY_USB= 0,
+NFCMRVL_PHY_UART= 1,
+NFCMRVL_PHY_I2C= 2,
+NFCMRVL_PHY_SPI= 3,
+};
>>> Why is that part of the fw_dld header ?
>>
>> Because this information is given by the FW header inside the firmware
>> binary. This is used to ensure that the firmaware used was configured for
>> the current phy interface.
> Sure. But can we keep it in the nfcmrvl.h header ?
Ok.
@@ -185,6 +202,11 @@ int nfcmrvl_nci_recv_frame(struct nfcmrvl_private
*priv, struct sk_buff *skb)
}
}
+if (priv->ndev->nfc_dev->fw_download_in_progress) {
>>> Who's setting that flag to true ?
>>
>> This is done by core code (check nfc_fw_download function in net/nfc/core.c).
> Duh. Sorry for the brain fart...
No problem
Br,
--
Vincent--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH V2 06/10] ASoC: img: Add driver for parallel output controller
On 19/10/15 19:07, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 01:40:33PM +0100, Damien Horsley wrote:
>
>> +spin_lock_irqsave(&prl->lock, flags);
>> +reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
>> +ucontrol->value.integer.value[0] = !!(reg & IMG_PRL_OUT_CTL_EDGE_MASK);
>> +spin_unlock_irqrestore(&prl->lock, flags);
>
> Do you need to lock a single register read?
>
Between the calls to reset_control_assert and reset_control_deassert,
the block is held in reset. During this time, no register access will
succeed. All register access that may occur concurrently with the reset
needs to be locked
>> +static struct snd_kcontrol_new img_prl_out_controls[] = {
>> +{
>> +.iface = SNDRV_CTL_ELEM_IFACE_PCM,
>> +.name = "Parallel Out Edge Falling",
>> +.info = img_prl_out_edge_info,
>> +.get = img_prl_out_get_edge,
>> +.put = img_prl_out_set_edge
>> +}
>> +};
>
> If this is a boolean control (it looked like one) it should be called
> Switch but it's not clear to me what exactly is being controlled here or
> why it's something that should be exposed to userspace.
>
This controls the edge (rising/falling) of the frame clock that the
samples are generated on. Should I create a set_fmt function and use
SND_SOC_DAIFMT_NB_NF / SND_SOC_DAIFMT_NB_IF to set this instead? I
wasn't sure if those formats were just for I2S or not
>> +switch (cmd) {
>> +case SNDRV_PCM_TRIGGER_START:
>> +case SNDRV_PCM_TRIGGER_RESUME:
>> +case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> +reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
>> +reg |= IMG_PRL_OUT_CTL_ME_MASK;
>> +img_prl_out_writel(prl, reg, IMG_PRL_OUT_CTL);
>> +prl->active = true;
>> +break;
>> +case SNDRV_PCM_TRIGGER_STOP:
>> +case SNDRV_PCM_TRIGGER_SUSPEND:
>> +case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
>> +img_prl_out_reset(prl);
>> +prl->active = false;
>> +break;
>
> No need for locking on the reset (and doesn't this mean that the control
> state is going to be changed underneath userspace)?
>
The reset function restores the setting after the reset
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
