Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
> On 30.07.2015, at 07:36, Stefan Wahren wrote: > > Hi Martin, > > Am 29.07.2015 um 23:16 schrieb Martin Sperl: >> >> >>> On 29.07.2015, at 18:37, Stefan Wahren wrote: >>> >>> Hi Martin, >>> Am 28.07.2015 um 12:48 schrieb Martin Sperl: > On 28.07.2015 08:18, Martin Sperl wrote: > Hi Stephen! > But the bigger question you have not answered is: “where should such an > auxiliar driver go in the kernel tree?” i.e. which directory? One thing: could the "module" be a regulator? >>> >>> IMHO that won't be acceptable. >> Why would it not be acceptable? >> > > first of all, sorry i didn't follow this thread in every detail. My intention > was to give you some ideas. I'm a not maintainer. > > IMU a regulator is a hardware part who controls voltage or current. > > Does it apply in your case? > > Any question: would a user expect this function in the regulator framework? I am just trying to find a solution that will get accepted with the minimum number of reposts/rewrites to avoid frustration, but nobody has an answer which api we really should use. The problem is that we have DT and we have code and as we only want HW being represented in the device tree we need something “sensible”. What about adding “bcrm,bcm2835-aux-enable” to drivers/mfd/syscon.c compatibility? That way we: * have a clean dt that only represents hardware * reuse existing code with minimal modifications * minimal effort That would be a minimal patch to enable this, so we can ask if that is acceptable and if it is not then we can still think of something else, which would be mostly replicating the bit-management portion of syscon. Sometimes I wish there was a way to “extend” compatibility of a driver by just adding something to the device-tree (say compatibility) or define it in the platform config c-files without having to touch the actual drivers to add that compatibility string... Martin -- 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: [RFC] improve binding for linux,wdt-gpio
On 29-07-15 09:35, Uwe Kleine-König wrote: Hello Guenter, On Tue, Jul 28, 2015 at 02:21:55PM -0700, Guenter Roeck wrote: On Tue, Jul 28, 2015 at 10:33:48PM +0200, Uwe Kleine-König wrote: This is just a suggestion up to now, I don't have any code yet to share. Apart from minor rewording to make the document easier to understand and less ambiguous the relevant changes are: - add an "enable-gpio" property. I admit the device I'm currently working with doesn't have this. Still I imagine this to be a common hardware property. I added it mainly to demonstrate the shortcomings of the existing binding. - rename "gpios" to "trigger-gpio" This is more descriptive. And given there is "enable-gpio" now, too, using plain "gpios" seems wrong. - deprecate always-running Apart from the description describing the driver behaviour and not the device property, always-running only seems to make sense in combination with hw_algo = "level" and in reality should only invalidate the sentence: "The watchdog timer is disabled when GPIO is left floating or connected to a three-state buffer." always-running is meant to indicate that the watchdog can not be stopped (meaning a timer has to be used to send keepalives while the watchdog device is closed). The documentation specifically states that. "If the watchdog timer cannot be disabled ..." How would you express that condition without always-running or a similar attribute ? I am also not sure how that relates to hw_algo; I thought those properties are orthogonal. For hw_algo = "level" the inactive level of the gpio disables the watchdog (and resets the counter). So always-running doesn't make sense for this type. Of course, 'always-running' _may_ describe driver behavior, but that doesn't Well in the current state of the binding document we have: add this flag to have the driver keep toggling the signal without a client. Sure it is meant to describe a hardware specific property, but it talks about the driver. I'd go for these properties then: toggle-gpio: the gpio used to stroke the watchdog enable-gpio: optional, the gpio to enable and disable the watchdog disable-on-tri-state: optional, signals that the watchdog can be stopped by setting the trigger-gpio to tri-state. compatible, hw_algo and hw_margin_ms: as before. I think there is no need for a property that signals that the watchdog is unstoppable. For level-gpio-watchdogs you can do it by setting the trigger gpio to inactive, and you cannot stop level-gpio-watchdogs unless enable-gpio or disable-on-tri-state is specified. If we ever feel the need to describe a gpio watchdog with a input that starts the device but cannot stop it, I'd suggest to use "start-gpio" for that one. I don't see any change in the number of properties required to describe things. So the driver just gets more complicated, especially if you want it to be somewhat backward compatible. The way you describe how one could get the "always-running" effect doesn't really sound intuitive. It's much easier to just have a property that plainly explains that the watchdog is unstoppable, than that that is the result of combining a bunch of seemingly unrelated properties together to get the driver to do what needs to be done. have to be the case. There are lots of watchdogs out there which can not be stopped. Some of them run all the time, others can not be stopped once started. Yeah, I'm aware of that. For this driver however I wouldn't expect that you have a dedicated enable-gpio if you cannot disable the device with it. For hw_algo = "level" there is probably no device with an enable input and for hw_algo = "toggle" any sane hardware engineer would simply enable the watchdog once the first toggle is detected on WDI. (OK, assuming hardware engineers being sane turned out to be a weak argument often in the past.) That gets us into the rat-hole of arguing if property X describes driver behavior or the hardware, and of rejecting properties because they may be driver descriptions in some use cases (because 'always-running' can be set even if the hardware doesn't mandate it, making it driver behavior). I'd rather not go there. I think we agree here, that "always-running" is a hardware property. I'd that "always-running" describes both. The driver must be always stroking (what a nice word) the watchdog because the watchdog is always watching. ... Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More maj
Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
Hi Martin, Am 29.07.2015 um 23:16 schrieb Martin Sperl: On 29.07.2015, at 18:37, Stefan Wahren wrote: Hi Martin, Am 28.07.2015 um 12:48 schrieb Martin Sperl: On 28.07.2015 08:18, Martin Sperl wrote: Hi Stephen! But the bigger question you have not answered is: “where should such an auxiliar driver go in the kernel tree?” i.e. which directory? One thing: could the "module" be a regulator? IMHO that won't be acceptable. Why would it not be acceptable? first of all, sorry i didn't follow this thread in every detail. My intention was to give you some ideas. I'm a not maintainer. IMU a regulator is a hardware part who controls voltage or current. Does it apply in your case? Any question: would a user expect this function in the regulator framework? Regards Stefan -- 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 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver
Hi, >> Debug folder node shows up at /sys/kernel/debug/ while the >> MC debug node shows up at /sys/kernel/debug/edac where is >> the driver node name. It would be better if everything shows up at >> /sys/kernel/debug/edac. For this to happen, I need EDAC core change to >> provide an parent node. > > Sure, feel free to add accessors for edac_debugfs from > drivers/edac/edac_mc_sysfs.c which edac drivers can call and thus > receive the top-level debugfs node. Okay... > > For that, you can put all those accessor prototypes into a > drivers/edac/edac-internal.h header which should be included only by > edac drivers. > >> No... each EDAC instance has its own context as we allocated via >> function edac_device_alloc_ctl_info. Per type of instance will use the >> same type function. > > So you have multiple instances running on the system? I don't think > anyone has audited the edac core and whether it can actually handle > that... Let me clarify a bit. I have one top level driver node and multiple instance of subnodes - 4 MC, 4 L2/L1, 1 L3C, and 1 SoC EDAC for now. The L3C many be multiple instance in the future. Just a note, the way EDAC looks up instance is by pointer of struct device. It doesn't need anything more than that. -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 v2 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver
On Wed, Jul 29, 2015 at 04:39:10PM -0700, Loc Ho wrote: > Debug folder node shows up at /sys/kernel/debug/ while the > MC debug node shows up at /sys/kernel/debug/edac where is > the driver node name. It would be better if everything shows up at > /sys/kernel/debug/edac. For this to happen, I need EDAC core change to > provide an parent node. Sure, feel free to add accessors for edac_debugfs from drivers/edac/edac_mc_sysfs.c which edac drivers can call and thus receive the top-level debugfs node. For that, you can put all those accessor prototypes into a drivers/edac/edac-internal.h header which should be included only by edac drivers. > No... each EDAC instance has its own context as we allocated via > function edac_device_alloc_ctl_info. Per type of instance will use the > same type function. So you have multiple instances running on the system? I don't think anyone has audited the edac core and whether it can actually handle that... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 01/22] platform: delay device-driver matches until late_initcall
On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
wrote:
> Delay matches of platform devices until late_initcall, when we are sure
> that all built-in drivers have been registered already. This is needed
> to prevent deferred probes because of some drivers not having registered
> yet.
>
> The reason why only platform devices are delayed is that some other
> devices are expected to be probed earlier than late_initcall, for
> example, the system PNP driver needs to probe its devices in
> fs_initcall.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> Changes in v2:
> - Move delay to platform.c
>
> drivers/base/platform.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 063f0ab15259..fcf654678e27 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -33,6 +33,8 @@
> /* For automatically allocated device IDs */
> static DEFINE_IDA(platform_devid_ida);
>
> +static bool enable_matches;
> +
> struct device platform_bus = {
> .init_name = "platform",
> };
> @@ -839,6 +841,15 @@ static int platform_match(struct device *dev, struct
> device_driver *drv)
> struct platform_device *pdev = to_platform_device(dev);
> struct platform_driver *pdrv = to_platform_driver(drv);
>
> + /*
> +* Delay matches of platform devices until late_initcall, when we are
> +* sure that all built-in drivers have been registered already. This
> +* is needed to prevent deferred probes because of some drivers
> +* not having registered yet.
> +*/
> + if (!enable_matches)
> + return false;
> +
Having this as a global makes me nervous. I think it would be better
to be DT specific or per device some how. Perhaps use OF_POPULATED_BUS
flag as an additional test.
There could be non-DT platforms that rely on the initcall ordering and
moving all probes to late_initcall could change the ordering. I'm not
sure though.
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 v5 2/5] PCI: designware: Add ARM64 support
On 2015/7/30 1:24, Lorenzo Pieralisi wrote:
> On Sat, Jul 25, 2015 at 04:21:23AM +0100, Zhou Wang wrote:
>> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
>> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
>> move related operations to dw_pcie_host_init. Also set pp->root_bus_nr = 0 in
>> each PCIe host driver which is based on pcie-designware. This patch also try
>
> Memory for ports is kzalloc'ed, so there is no need to zero it. I still
> think that you should explain the root_bus_nr setting to 0 a bit
> better, why you make the change and why it is safe.
>
Hi Lorenzo,
This patch deletes dw_pcie_scan_bus and pass root_bus_nr directly to
pci_create_root_bus.
In past, we use:
pci_common_init_dev
-> pcibios_init_hw
-> hw->scan (dw_pcie_scan_bus)
to pass 0 to root_bus_nr in struct pcie_port. so I set root_bus_nr
in each driver which is based on dw to 0.
> [...]
>
>> -int dw_pcie_host_init(struct pcie_port *pp)
>> +int __init dw_pcie_host_init(struct pcie_port *pp)
>> {
>> struct device_node *np = pp->dev->of_node;
>> struct platform_device *pdev = to_platform_device(pp->dev);
>> - struct of_pci_range range;
>> - struct of_pci_range_parser parser;
>> + struct pci_bus *bus;
>> struct resource *cfg_res;
>> - u32 val, na, ns;
>> + LIST_HEAD(res);
>> + u32 val, ns;
>> const __be32 *addrp;
>> int i, index, ret;
>> + struct resource_entry *win;
>>
>> - /* Find the address cell size and the number of cells in order to get
>> -* the untranslated address.
>> -*/
>> - of_property_read_u32(np, "#address-cells", &na);
>> + /* Find the number of cells in order to get the untranslated address
>> */
>> ns = of_n_size_cells(np);
>>
>> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> "config");
>> @@ -392,78 +382,62 @@ int dw_pcie_host_init(struct pcie_port *pp)
>> dev_err(pp->dev, "missing *config* reg space\n");
>> }
>>
>> - if (of_pci_range_parser_init(&parser, np)) {
>> - dev_err(pp->dev, "missing ranges property\n");
>> - return -EINVAL;
>> - }
>> + ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &res,
>> &pp->io_base);
>> + if (ret)
>> + return ret;
>>
>> /* Get the I/O and memory ranges from DT */
>> - for_each_of_pci_range(&parser, &range) {
>> - unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
>> -
>> - if (restype == IORESOURCE_IO) {
>> - of_pci_range_to_resource(&range, np, &pp->io);
>> - pp->io.name = "I/O";
>> - pp->io.start = max_t(resource_size_t,
>> -PCIBIOS_MIN_IO,
>> -range.pci_addr +
>> global_io_offset);
>> - pp->io.end = min_t(resource_size_t,
>> - IO_SPACE_LIMIT,
>> - range.pci_addr + range.size
>> - + global_io_offset - 1);
>> - pp->io_size = resource_size(&pp->io);
>> - pp->io_bus_addr = range.pci_addr;
>> - pp->io_base = range.cpu_addr;
>> -
>> - /* Find the untranslated IO space address */
>> - pp->io_mod_base = of_read_number(parser.range -
>> -parser.np + na, ns);
>> - }
>> - if (restype == IORESOURCE_MEM) {
>> - of_pci_range_to_resource(&range, np, &pp->mem);
>> - pp->mem.name = "MEM";
>> - pp->mem_size = resource_size(&pp->mem);
>> - pp->mem_bus_addr = range.pci_addr;
>> -
>> - /* Find the untranslated MEM space address */
>> - pp->mem_mod_base = of_read_number(parser.range -
>> - parser.np + na,
>> ns);
>> - }
>> - if (restype == 0) {
>> - of_pci_range_to_resource(&range, np, &pp->cfg);
>> - pp->cfg0_size = resource_size(&pp->cfg)/2;
>> - pp->cfg1_size = resource_size(&pp->cfg)/2;
>> - pp->cfg0_base = pp->cfg.start;
>> - pp->cfg1_base = pp->cfg.start + pp->cfg0_size;
>> + resource_list_for_each_entry(win, &res) {
>> + switch (resource_type(win->res)) {
>> + case IORESOURCE_IO:
>> + pp->io = win->res;
>> + pp->io->name = "I/O";
>> + pp->io_size = resource_size(pp->io);
>> + pp->io_bus_addr = p
Re: [PATCH v2 05/22] ACPI: add acpi_dev_get_device()
On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso wrote: > This function is just a getter for struct acpi_device.dev and is needed > in the implementation of the fwnode API when building with !CONFIG_ACPI. > > Signed-off-by: Tomeu Vizoso > --- > > Changes in v2: > - Add acpi_dev_get_device() > > include/linux/acpi.h | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index 01e6770d8e27..d1ad6c20c7e4 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -78,6 +78,11 @@ static inline void acpi_preset_companion(struct device > *dev, > ACPI_COMPANION_SET(dev, acpi_find_child_device(parent, addr, NULL)); > } > > +static inline struct device *acpi_dev_get_device(struct acpi_device *adev) get usually implies reference counting. Perhaps acpi_dev_to_device or acpi_dev_find_device. 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 v8 00/23] usb gadget update for OTG 2.0
On Wed, Jul 29, 2015 at 09:11:41PM -0500, Felipe Balbi wrote: > On Thu, Jul 30, 2015 at 07:24:03AM +0800, Li Jun wrote: > > On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote: > > > On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote: > > > > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote: > > > > > Change for v8: > > > > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for > > > > > patch > > > > > 07, 21~23. > > > > > - Add ci->is_otg condition before enable ci->gadget.is_otg for > > > > > chipidea > > > > > driver in patch 8. > > > > > > > > > > > > > Hi Felipe, > > > > > > > > For chipidea patches in this series, help to queue them in your tree > > > > please, thanks. > > > > > > all there, please make sure they're correct. There were so many versions > > > of this series that I might have picked up the wrong one :-p > > > > > > > Patch [8/23]: "usb: chipidea: set usb otg capabilities", you picked up the > > V7, > > I have a small change for V8, others are correct. > > Can you send an incremental diff, please ? > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 61fde89..c6d1595 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1838,8 +1838,8 @@ static int udc_start(struct ci_hdrc *ci) ci->gadget.name = ci->platdata->name; ci->gadget.otg_caps = otg_caps; - if (otg_caps->hnp_support || otg_caps->srp_support || - otg_caps->adp_support) + if (ci->is_otg && (otg_caps->hnp_support || otg_caps->srp_support || + otg_caps->adp_support)) ci->gadget.is_otg = 1; INIT_LIST_HEAD(&ci->gadget.ep_list); thanks Li Jun > -- > balbi -- 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] usb: chipidea: usbmisc_imx: add unburst setting for imx6
> > On Wed, Jul 29, 2015 at 10:30:22AM +0200, Lothar Waßmann wrote: > > > Hi, > > > > > > > With this setting and AHBBRST at SBUSCFG as "Incremental burst of > > > > unspecified length", each unburst size can be taken as one single > > > > transfer. > > > > It is benefit for unburst size transfer. > > > > > > > What is an 'unburst'? > > > > > > > Assume burst size is 8 dword, unburst size 't' < 8. > > > > With this feature, 't' length payload can be taken as one burst > > transfer, otherwise, the single transfer > > (1 dword) will be used. > > > IMO non-burst would be a better word. > Thanks, will change. Peter
Re: [PATCH v5 06/10] clk: mediatek: mt8173: Fix enabling of critical clocks
Hi Stephen, On Wed, 2015-07-29 at 17:27 -0700, Stephen Boyd wrote: > On 07/29, James Liao wrote: > > From: Sascha Hauer > > > > On the MT8173 the clocks are provided by different units. To enable > > the critical clocks we must be sure that all parent clocks are already > > registered, otherwise the parents of the critical clocks end up being > > unused and get disabled later. > > > > On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED > > PLLs as their parents, so we cannot enable the CLK_TOP critical clocks > > until the CLK_APMIXED clocks have all been registered. > > > > To find a place where all parents are registered we try each time > > after we've registered some clocks if all known providers are present > > now and only then we enable the critical clocks. > > > > Signed-off-by: Sascha Hauer > > Signed-off-by: James Liao > > --- > > Please move up to v4.2-rc2 so that this patch can be dropped. I > already applied this and sent it off to Linus so it's in -rc2. OK. I'll rebase to v4.2-rc2 in next patchset. Best regards, James -- 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 v8 00/23] usb gadget update for OTG 2.0
On Thu, Jul 30, 2015 at 07:24:03AM +0800, Li Jun wrote: > On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote: > > On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote: > > > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote: > > > > Change for v8: > > > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for patch > > > > 07, 21~23. > > > > - Add ci->is_otg condition before enable ci->gadget.is_otg for chipidea > > > > driver in patch 8. > > > > > > > > > > Hi Felipe, > > > > > > For chipidea patches in this series, help to queue them in your tree > > > please, thanks. > > > > all there, please make sure they're correct. There were so many versions > > of this series that I might have picked up the wrong one :-p > > > > Patch [8/23]: "usb: chipidea: set usb otg capabilities", you picked up the V7, > I have a small change for V8, others are correct. Can you send an incremental diff, please ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
Hi,
2015-07-30 0:23 GMT+09:00 Rob Herring :
> On Wed, Jul 29, 2015 at 8:22 AM, Ian Campbell wrote:
>> On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
>>> Hi Ian,
>>>
>>>
>>> 2015-07-27 19:35 GMT+09:00 Ian Campbell :
>>> > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
>>> > LogicTile Express 20MG" added a new dts file to arch/arm64 which
>>> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
>>> > .dtsi supplied by arch/arm.
>>> >
>>> > Unfortunately this causes some issues for the split device tree
>>> > repository[0], since things get moved around there. In that context
>>> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
>>> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
>>> >
>>> > The sharing of the .dtsi is legitimate since the baseboard is the same
>>> > for various vexpress systems whatever processor they use.
>>> >
>>> > Rather than using ../../ tricks to pickup .dtsi files from another
>>> > arch this patch creates a new directory include/dt-dtsi as a
>>> > home for such cross-arch .dtsi files, arranges for it to be in the
>>> > include path when the .dts files are processed by cpp and switches the
>>>
>>>
>>> "include/dt-dtsi/" can be referenced from normal C sources.
>>>
>>> I think another possible home for cross-arch DTSI is "kernel/dts/".
>>> This directory can be hidden from C sources.
>>
>> I suppose, I don't really mind and will follow the direction of the other
>> DTB maintainers. It doesn't seem like a big deal to me.
>
> Seems fine to me. We might think of other things to put here that are
> not includes. Overlays perhaps?
Putting device trees below "include/" seems weird to me.
I thought, kernel/ is a place where we put something common among
architectures.
"kernel/configs/" was created as a home for cross-arch config fragments.
arch/${ARCH}/configs/ - arch-specific *_defconfig and *.config
kernel/configs/- arch-common *.config
Likewise,
arch/${ARCH}/boot/dts - arch-specific *.dts and *.dtsi
kernel/dts - arch-common *.dtsi
This is just a matter of preference, though.
--
Best Regards
Masahiro Yamada
--
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/5] clk: Supply the critical clock {init, enable, disable} framework
Quoting Lee Jones (2015-07-27 01:53:38)
> On Mon, 27 Jul 2015, Maxime Ripard wrote:
>
> > On Wed, Jul 22, 2015 at 02:04:13PM +0100, Lee Jones wrote:
> > > These new API calls will firstly provide a mechanisms to tag a clock as
> > > critical and secondly allow any knowledgeable driver to (un)gate clocks,
> > > even if they are marked as critical.
> > >
> > > Suggested-by: Maxime Ripard
> > > Signed-off-by: Lee Jones
> > > ---
> > > drivers/clk/clk.c| 45
> > >
> > > include/linux/clk-provider.h | 2 ++
> > > include/linux/clk.h | 30 +
> > > 3 files changed, 77 insertions(+)
> > >
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index 61c3fc5..486b1da 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char
> > > *name);
> > >
> > > /***private data structures***/
> > >
> > > +/**
> > > + * struct critical - Provides 'play' over critical clocks. A
> > > clock can be
> > > + * marked as critical, meaning that it should not be
> > > + * disabled. However, if a driver which is aware of the
> > > + * critical behaviour wants to control it, it can do so
> > > + * using clk_enable_critical() and
> > > clk_disable_critical().
> > > + *
> > > + * @enabledIs clock critical? Once set, doesn't change
> > > + * @leave_on Self explanatory. Can be disabled by knowledgeable
> > > drivers
> > > + */
> > > +struct critical {
> > > + bool enabled;
> > > + bool leave_on;
> > > +};
> > > +
> > > struct clk_core {
> > > const char *name;
> > > const struct clk_ops*ops;
> > > @@ -75,6 +90,7 @@ struct clk_core {
> > > struct dentry *dentry;
> > > #endif
> > > struct kref ref;
> > > + struct critical critical;
> > > };
> > >
> > > struct clk {
> > > @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core *clk)
> > > if (WARN_ON(clk->enable_count == 0))
> > > return;
> > >
> > > + /* Refuse to turn off a critical clock */
> > > + if (clk->enable_count == 1 && clk->critical.leave_on)
> > > + return;
> > > +
> >
> > I think it should be handled by a separate counting. Otherwise, if you
> > have two users that marked the clock as critical, and then one of them
> > disable it...
> >
> > > if (--clk->enable_count > 0)
> > > return;
> > >
> > > @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk)
> > > }
> > > EXPORT_SYMBOL_GPL(clk_disable);
> > >
> > > +void clk_disable_critical(struct clk *clk)
> > > +{
> > > + clk->core->critical.leave_on = false;
> >
> > .. you just lost the fact that it was critical in the first place.
>
> I thought about both of these points, which is why I came up with this
> strategy.
>
> Any device which uses the *_critical() API should a) have knowledge of
> what happens when a particular critical clock is gated and b) have
> thought about the consequences.
If this statement above is true then I fail to see the need for a new
api. A driver which has a really great idea of when it is safe or unsafe
to gate a clock should call clk_prepare_enable at probe and then only
call clk_disable_unprepare once it is safe to do so.
The existing bookkeeping in the clock framework will do the rest.
Regards,
Mike
> I don't think we can use reference
> counting, because we'd need as many critical clock owners as there are
> critical clocks. Cast your mind back to the reasons for this critical
> clock API. One of the most important intentions of this API is the
> requirement mitigation for each of the critical clocks to have an owner
> (driver).
>
> With regards to your second point, that's what 'critical.enabled'
> is for. Take a look at clk_enable_critical().
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
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/5] clk: Supply the critical clock {init, enable, disable} framework
Quoting Lee Jones (2015-07-28 06:00:55)
> On Tue, 28 Jul 2015, Maxime Ripard wrote:
>
> > On Mon, Jul 27, 2015 at 09:53:38AM +0100, Lee Jones wrote:
> > > On Mon, 27 Jul 2015, Maxime Ripard wrote:
> > >
> > > > On Wed, Jul 22, 2015 at 02:04:13PM +0100, Lee Jones wrote:
> > > > > These new API calls will firstly provide a mechanisms to tag a clock
> > > > > as
> > > > > critical and secondly allow any knowledgeable driver to (un)gate
> > > > > clocks,
> > > > > even if they are marked as critical.
> > > > >
> > > > > Suggested-by: Maxime Ripard
> > > > > Signed-off-by: Lee Jones
> > > > > ---
> > > > > drivers/clk/clk.c| 45
> > > > >
> > > > > include/linux/clk-provider.h | 2 ++
> > > > > include/linux/clk.h | 30 +
> > > > > 3 files changed, 77 insertions(+)
> > > > >
> > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > > > index 61c3fc5..486b1da 100644
> > > > > --- a/drivers/clk/clk.c
> > > > > +++ b/drivers/clk/clk.c
> > > > > @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char
> > > > > *name);
> > > > >
> > > > > /***private data structures***/
> > > > >
> > > > > +/**
> > > > > + * struct critical - Provides 'play' over critical clocks. A
> > > > > clock can be
> > > > > + * marked as critical, meaning that it should
> > > > > not be
> > > > > + * disabled. However, if a driver which is
> > > > > aware of the
> > > > > + * critical behaviour wants to control it, it
> > > > > can do so
> > > > > + * using clk_enable_critical() and
> > > > > clk_disable_critical().
> > > > > + *
> > > > > + * @enabledIs clock critical? Once set, doesn't change
> > > > > + * @leave_on Self explanatory. Can be disabled by knowledgeable
> > > > > drivers
> > > > > + */
> > > > > +struct critical {
> > > > > + bool enabled;
> > > > > + bool leave_on;
> > > > > +};
> > > > > +
> > > > > struct clk_core {
> > > > > const char *name;
> > > > > const struct clk_ops*ops;
> > > > > @@ -75,6 +90,7 @@ struct clk_core {
> > > > > struct dentry *dentry;
> > > > > #endif
> > > > > struct kref ref;
> > > > > + struct critical critical;
> > > > > };
> > > > >
> > > > > struct clk {
> > > > > @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core
> > > > > *clk)
> > > > > if (WARN_ON(clk->enable_count == 0))
> > > > > return;
> > > > >
> > > > > + /* Refuse to turn off a critical clock */
> > > > > + if (clk->enable_count == 1 && clk->critical.leave_on)
> > > > > + return;
> > > > > +
> > > >
> > > > I think it should be handled by a separate counting. Otherwise, if you
> > > > have two users that marked the clock as critical, and then one of them
> > > > disable it...
> > > >
> > > > > if (--clk->enable_count > 0)
> > > > > return;
> > > > >
> > > > > @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk)
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(clk_disable);
> > > > >
> > > > > +void clk_disable_critical(struct clk *clk)
> > > > > +{
> > > > > + clk->core->critical.leave_on = false;
> > > >
> > > > .. you just lost the fact that it was critical in the first place.
> > >
> > > I thought about both of these points, which is why I came up with this
> > > strategy.
> > >
> > > Any device which uses the *_critical() API should a) have knowledge of
> > > what happens when a particular critical clock is gated and b) have
> > > thought about the consequences.
> >
> > Indeed.
> >
> > > I don't think we can use reference counting, because we'd need as
> > > many critical clock owners as there are critical clocks.
> >
> > Which we can have if we replace the call to clk_prepare_enable you add
> > in your fourth patch in __set_critical_clocks.
>
> What should it be replaced with?
>
> > > Cast your mind back to the reasons for this critical clock API. One
> > > of the most important intentions of this API is the requirement
> > > mitigation for each of the critical clocks to have an owner
> > > (driver).
> > >
> > > With regards to your second point, that's what 'critical.enabled'
> > > is for. Take a look at clk_enable_critical().
> >
> > I don't think this addresses the issue, if you just throw more
> > customers at it, the issue remain with your implementation.
> >
> > If you have three customers that used the critical API, and if on of
> > these calls clk_disable_critical, you're losing leave_on.
>
> That's the idea. See my point above, the one you replied "Indeed"
> to. So when a driver uses clk_disable_critical() it's saying, "I know
> why this clock is a critical clock, and I know that nothing terrible
> will happen if I disable it, as I have that covered". So then if it's
>
Re: [PATCH v7 3/5] clk: Supply the critical clock {init, enable, disable} framework
Hi Lee,
+ linux-clk ml
Quoting Lee Jones (2015-07-22 06:04:13)
> These new API calls will firstly provide a mechanisms to tag a clock as
> critical and secondly allow any knowledgeable driver to (un)gate clocks,
> even if they are marked as critical.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Lee Jones
> ---
> drivers/clk/clk.c| 45
>
> include/linux/clk-provider.h | 2 ++
> include/linux/clk.h | 30 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 61c3fc5..486b1da 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char *name);
>
> /***private data structures***/
>
> +/**
> + * struct critical - Provides 'play' over critical clocks. A clock can be
> + * marked as critical, meaning that it should not be
> + * disabled. However, if a driver which is aware of the
> + * critical behaviour wants to control it, it can do so
> + * using clk_enable_critical() and
> clk_disable_critical().
> + *
> + * @enabledIs clock critical? Once set, doesn't change
> + * @leave_on Self explanatory. Can be disabled by knowledgeable drivers
Not self explanatory. I need this explained to me. What does leave_on
do? Better yet, what would happen if leave_on did not exist?
> + */
> +struct critical {
> + bool enabled;
> + bool leave_on;
> +};
> +
> struct clk_core {
> const char *name;
> const struct clk_ops*ops;
> @@ -75,6 +90,7 @@ struct clk_core {
> struct dentry *dentry;
> #endif
> struct kref ref;
> + struct critical critical;
> };
>
> struct clk {
> @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core *clk)
> if (WARN_ON(clk->enable_count == 0))
> return;
>
> + /* Refuse to turn off a critical clock */
> + if (clk->enable_count == 1 && clk->critical.leave_on)
> + return;
How do we get to this point? clk_enable_critical actually calls
clk_enable, thus incrementing the enable_count. The only time that we
could hit the above case is if,
a) there is an imbalance in clk_enable and clk_disable calls. If this is
the case then the drivers need to be fixed. Or better yet some
infrastructure to catch that, now that we have per-user struct clk
cookies.
b) a driver knowingly calls clk_enable_critical(foo) and then regular,
old clk_disable(foo). But why would a driver do that?
It might be that I am missing the point here, so please feel free to
clue me in.
Regards,
Mike
> +
> if (--clk->enable_count > 0)
> return;
>
> @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk)
> }
> EXPORT_SYMBOL_GPL(clk_disable);
>
> +void clk_disable_critical(struct clk *clk)
> +{
> + clk->core->critical.leave_on = false;
> + clk_disable(clk);
> +}
> +EXPORT_SYMBOL_GPL(clk_disable_critical);
> +
> static int clk_core_enable(struct clk_core *clk)
> {
> int ret = 0;
> @@ -1100,6 +1127,15 @@ int clk_enable(struct clk *clk)
> }
> EXPORT_SYMBOL_GPL(clk_enable);
>
> +int clk_enable_critical(struct clk *clk)
> +{
> + if (clk->core->critical.enabled)
> + clk->core->critical.leave_on = true;
> +
> + return clk_enable(clk);
> +}
> +EXPORT_SYMBOL_GPL(clk_enable_critical);
> +
> static unsigned long clk_core_round_rate_nolock(struct clk_core *clk,
> unsigned long rate,
> unsigned long min_rate,
> @@ -2482,6 +2518,15 @@ fail_out:
> }
> EXPORT_SYMBOL_GPL(clk_register);
>
> +void clk_init_critical(struct clk *clk)
> +{
> + struct critical *critical = &clk->core->critical;
> +
> + critical->enabled = true;
> + critical->leave_on = true;
> +}
> +EXPORT_SYMBOL_GPL(clk_init_critical);
> +
> /*
> * Free memory allocated for a clock.
> * Caller must hold prepare_lock.
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 5591ea7..15ef8c9 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -563,6 +563,8 @@ struct clk *devm_clk_register(struct device *dev, struct
> clk_hw *hw);
> void clk_unregister(struct clk *clk);
> void devm_clk_unregister(struct device *dev, struct clk *clk);
>
> +void clk_init_critical(struct clk *clk);
> +
> /* helper functions */
> const char *__clk_get_name(struct clk *clk);
> struct clk_hw *__clk_get_hw(struct clk *clk);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 8381bbf..9807f3b 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -231,6 +231,19 @@ struct clk *devm_clk_get(struct device *dev, const char
> *id);
> int clk_enable(struct
Re: [PATCH v8 00/23] usb gadget update for OTG 2.0
On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote: > On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote: > > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote: > > > Change for v8: > > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for patch > > > 07, 21~23. > > > - Add ci->is_otg condition before enable ci->gadget.is_otg for chipidea > > > driver in patch 8. > > > > > > > Hi Felipe, > > > > For chipidea patches in this series, help to queue them in your tree > > please, thanks. > > all there, please make sure they're correct. There were so many versions > of this series that I might have picked up the wrong one :-p > Patch [8/23]: "usb: chipidea: set usb otg capabilities", you picked up the V7, I have a small change for V8, others are correct. Li Jun > cheers > > -- > balbi -- 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 v5 06/10] clk: mediatek: mt8173: Fix enabling of critical clocks
On 07/29, James Liao wrote: > From: Sascha Hauer > > On the MT8173 the clocks are provided by different units. To enable > the critical clocks we must be sure that all parent clocks are already > registered, otherwise the parents of the critical clocks end up being > unused and get disabled later. > > On MT8173, for example, it is the CLK_TOP clocks that have CLK_APMIXED > PLLs as their parents, so we cannot enable the CLK_TOP critical clocks > until the CLK_APMIXED clocks have all been registered. > > To find a place where all parents are registered we try each time > after we've registered some clocks if all known providers are present > now and only then we enable the critical clocks. > > Signed-off-by: Sascha Hauer > Signed-off-by: James Liao > --- Please move up to v4.2-rc2 so that this patch can be dropped. I already applied this and sent it off to Linus so it's in -rc2. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] clk: Provide support for always-on clocks
Quoting Lee Jones (2015-07-22 06:04:10)
> Lots of platforms contain clocks which if turned off would prove fatal.
> The only way to recover from these catastrophic failures is to restart
> the board(s). Now, when a clock provider is registered with the
> framework it is possible for a list of critical clocks to be supplied
> which must be kept ungated. Each clock mentioned in the newly
> introduced 'critical-clock' property will be clk_prepare_enable()d
> where the normal references will be taken. This will prevent the
> common clk framework from attempting to gate them during the normal
> clk_disable_unused() and disable_clock() procedures.
>
> Note that it will still be possible for knowledgeable drivers to turn
> these clocks off using clk_{enable,disable}_critical() calls.
Hi Lee,
Thanks for submitting the series.
It has been a little while since v6. It would be helpful to remind me of
why a new api is necessary, versus using the existing clk_prepare_unused
call at the time that a clock is enabled.
I'm looking over the patches in detail now, but one question stands out:
besides the DT use case, would a Linux device driver ever call
clk_enable_critical instead of using clk_enable? If so, why?
Thanks,
Mike
>
> Changelog:
> v6 => v7:
> - Introduce API to enable and disable critical clocks
> - Rename 'always-on-clock' to 'critical-clock'
>
> v5 => v6:
> - Use of_clk_get_from_provider() instead of of_clk_get_by_clkspec()
> - Explicitly describe expected DT values
> - Be pedantic with regards to printk() format specifiers
>
> vX => v5:
> Implementations have changed drastically between versions, thus I
> would like for this set to be thought of independently from its
> predecessors. The only reason for identifying as 'v5' is ease of
> differentiation on the list, which stems from the confusion caused
> by submitting 'v4' as a separate entity.
>
> Lee Jones (5):
> ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
> ARM: sti: stih410-clocks: Identify critical clocks
> clk: Supply the critical clock {init, enable, disable} framework
> clk: Provide critical clock support
> clk: dt: Introduce binding for critical clock support
>
> .../devicetree/bindings/clock/clock-bindings.txt | 39 +++
> arch/arm/boot/dts/stih410-clock.dtsi | 10 +
> drivers/clk/clk-conf.c | 45
> +-
> drivers/clk/clk.c | 45
> ++
> include/dt-bindings/clock/stih407-clks.h | 4 ++
> include/linux/clk-provider.h | 2 +
> include/linux/clk.h| 30 +++
> 7 files changed, 174 insertions(+), 1 deletion(-)
>
> --
> 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 v1 1/7] ARM: dts: ifc6410: Add pwrseq support for WLAN
On Tue 28 Jul 05:53 PDT 2015, Srinivas Kandagatla wrote:
> This patch adds pwrseq for WLAN which resets the WLAN just before the
> SDIO bus is up.
>
Does this mean that we have the !power-of-2 patch in mmc on the way?
> Signed-off-by: Srinivas Kandagatla
> ---
> arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 88d6655..df560cf 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -1,5 +1,6 @@
> #include "qcom-apq8064-v2.0.dtsi"
> #include
> +#include
>
> / {
> model = "Qualcomm APQ8064/IFC6410";
> @@ -206,6 +207,28 @@
> status = "okay";
> };
>
> + qcom,ssbi@50 {
> + pmicintc: pmic@0 {
> + pm8921_gpio: gpio@150 {
These should already be labeled in the apq8064 dtsi (or in a
qcom-pm8921.dtsi).
> + pinctrl-names = "default";
> + pinctrl-0 = <&wlan_default_gpios>;
Please move these to the pwrseq node, as that's the consumer of this.
> + wlan_default_gpios: wlan-gpios {
> + pios {
> + pins = "gpio43";
> + function = "normal";
> + bias-disable;
> + power-source =
> ;
> + };
> + };
> + };
> + };
> + };
Regards,
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
Re: [PATCH RESEND] ARM: shmobile: silk: add Ether DT support
On Wed, Jul 29, 2015 at 01:16:02AM +0300, Sergei Shtylyov wrote: > Define the SILK board dependent part of the Ether device node. > Enable DHCP and NFS root for the kernel booting. > > Based on the original patch by Vladimir Barinov > . > > Signed-off-by: Sergei Shtylyov 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 v3] ARM: shmobile: silk: initial device tree
On Wed, Jul 29, 2015 at 01:14:59AM +0300, Sergei Shtylyov wrote: > Add the initial device tree for the R8A7794 SoC based SILK low cost board. > SCIF2 serial port support is included, so that the serial console can work. > > Based on the original patch by Vladimir Barinov > . > > Signed-off-by: Sergei Shtylyov 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] backlight: pm8941-wled: Add default-brightness property
On Fri 24 Jul 08:29 PDT 2015, Rob Herring wrote: > On Thu, Jul 23, 2015 at 2:52 PM, Bjorn Andersson > wrote: > > Add the possibility of specifying the default brightness in DT. > > > > Signed-off-by: Bjorn Andersson > > --- > > > > This depends on the patch moving pm8941-wled to backlight [1]. The dt > > property > > is used by several other backlight drivers, so I considered this to be a > > "common" property and it's hence not prefixed with "qcom,". > > Well, we have "default-brightness" and "default-brightness-level" used > by 1 driver each. But default-brightness-level is much more commonly > used (in dts files) since it is in the pwm backlight binding, so we > should go with it. I'd like to see this moved to a common backlight > doc. > As I looked at these, the default-brightness used in tps65217 is a value between 0 and 100, so that can be interpreted as a percentage. The pwm binding however uses a separate array of "brightness-levels" and then default-brightness-level is supposed to be an index into that array. As we're trying to specify a default brightness within the range [0, max_brightness) the latter doesn't make much sense. Therefor my suggestion is that we make the "default-brightness" the common property and we define it as a percentage of [0,max_brightness). > Really, I think all the backlight documentation should be merged with > LEDs docs. Things like "default-on" are common. But I won't ask to do > that here. I think the backlight framework should be merged with the LED framework. There's several hw blocks that are split between the two, with an mfd tying them together... Regards, 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
Re: [PATCH v2 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver
Hi Borislav,
>> +
>> +static void xgene_edac_l3_hw_init(struct edac_device_ctl_info *edac_dev,
>> + bool enable)
>
> arg alignment. It should be
>
> function name(arg1, arg2,
> arg3, arg4,
> arg5...
>
> Check your other functions too.
I will check and fix other functions if any. But this function is just
fine. It may be off just by the + extra character with patch
generation only.
>> +{
>> + struct xgene_edac_dev_ctx *ctx = edac_dev->pvt_info;
>> + struct dentry *edac_debugfs;
>> + char name[30];
>> +
>> + if (!IS_ENABLED(CONFIG_EDAC_DEBUG))
>> + return;
>> +
>> + /*
>> + * Todo: Switch to common EDAC debug file system for edac device
>> + * when available.
>> + */
>
> What is that?
Debug folder node shows up at /sys/kernel/debug/ while the
MC debug node shows up at /sys/kernel/debug/edac where is
the driver node name. It would be better if everything shows up at
/sys/kernel/debug/edac. For this to happen, I need EDAC core change to
provide an parent node.
>
>> + if (!ctx->edac->dfs) {
>> + ctx->edac->dfs = debugfs_create_dir(edac_dev->dev->kobj.name,
>> + NULL);
>> + if (!ctx->edac->dfs)
>> + return;
>> + }
>> + sprintf(name, "l3c%d", ctx->edac_idx);
>> + edac_debugfs = debugfs_create_dir(name, ctx->edac->dfs);
>> + if (!edac_debugfs)
>> + return;
>> +
>> + debugfs_create_file("l3_inject_ctrl", S_IWUSR, edac_debugfs, edac_dev,
>> + &xgene_edac_l3_debug_inject_fops);
>> +}
>> +
>> +static int xgene_edac_l3_add(struct xgene_edac *edac, struct device_node
>> *np,
>> + int version)
>> +{
>> + struct edac_device_ctl_info *edac_dev;
>> + struct xgene_edac_dev_ctx *ctx;
>> + struct resource res;
>> + void __iomem *dev_csr;
>> + int edac_idx;
>> + int rc = 0;
>> +
>> + if (!devres_open_group(edac->dev, xgene_edac_l3_add, GFP_KERNEL))
>> + return -ENOMEM;
>> +
>> + rc = of_address_to_resource(np, 0, &res);
>> + if (rc < 0) {
>> + dev_err(edac->dev, "no L3 resource address\n");
>> + goto err;
>> + }
>> + dev_csr = devm_ioremap_resource(edac->dev, &res);
>> + if (IS_ERR(dev_csr)) {
>> + dev_err(edac->dev,
>> + "devm_ioremap_resource failed for L3 resource
>> address\n");
>> + rc = PTR_ERR(dev_csr);
>> + goto err;
>> + }
>>
>> + edac_idx = edac_device_alloc_index();
>> + edac_dev = edac_device_alloc_ctl_info(sizeof(*ctx),
>> + "l3c", 1, "l3c", 1, 0, NULL, 0,
>> + edac_idx);
>> + if (!edac_dev) {
>> + rc = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + ctx = edac_dev->pvt_info;
>> + ctx->dev_csr = dev_csr;
>> + ctx->name = "xgene_l3_err";
>> + ctx->edac_idx = edac_idx;
>> + ctx->edac = edac;
>> + ctx->edac_dev = edac_dev;
>> + ctx->ddev = *edac->dev;
>> + ctx->version = version;
>> + edac_dev->dev = &ctx->ddev;
>> + edac_dev->ctl_name = ctx->name;
>> + edac_dev->dev_name = ctx->name;
>> + edac_dev->mod_name = EDAC_MOD_STR;
>> +
>> + if (edac_op_state == EDAC_OPSTATE_POLL)
>> + edac_dev->edac_check = xgene_edac_l3_check;
>
> So depending on what SoC elements you detect, the last one's check
> function will win?
>
> If xgene_edac loads on multiple SoC elements, you need a global xgene
> check function for which l3, soc, mc, etc register...
No... each EDAC instance has its own context as we allocated via
function edac_device_alloc_ctl_info. Per type of instance will use the
same type function.
>> +
>> +static const char * const *xgene_edac_soc_mem_data(
>> + struct xgene_edac_dev_ctx *ctx)
>> +{
>> + switch (ctx->version) {
>> + case 1:
>> + return soc_mem_err_v1;
>> + default:
>> + return NULL;
>> + }
>> +}
>
> That's one badly formatted function used only once. Just move the logic
> there and kill it.
For format, code looks fine. In any case, I will roll this into the code.
>> +static int xgene_edac_soc_add(struct xgene_edac *edac, struct device_node
>> *np,
>> + int version)
>> +{
>> + struct edac_device_ctl_info *edac_dev;
>> + struct xgene_edac_dev_ctx *ctx;
>> + void __iomem *dev_csr;
>> + struct resource res;
>> + int edac_idx;
>> + int rc = 0;
>> +
>> + if (!devres_open_group(edac->dev, xgene_edac_soc_add, GFP_KERNEL))
>> + return -ENOMEM;
>> +
>> + rc = of_address_to_resource(np, 0, &res);
>> + if (rc < 0) {
>> + dev_err(edac->dev, "no SoC resource address\n");
>> + goto err;
>> + }
>> + dev_csr = devm_ioremap_resource(edac->dev, &res);
>> + if (
Re: [PATCH v1 1/7] ARM: dts: ifc6410: Add pwrseq support for WLAN
On 07/28/2015 05:53 AM, Srinivas Kandagatla wrote:
+
+ sdcc4_pwrseq:pwrseq {
Missing space here between label and node name.
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pm8921_gpio 43 GPIO_ACTIVE_LOW>;
+ };
+
Also this node is not part of the SoC so it should be in the root,
possibly under some sort of power-sequences node so that all the
sequences are grouped in one place.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support
On 07/28/2015 05:54 AM, Srinivas Kandagatla wrote:
+
+ panel_3p3v: panel_3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-0 = <&disp_en_gpios>;
+ pinctrl-names = "default";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "panel_en_3p3v";
+ regulator-type = "voltage";
+ startup-delay-us = <0>;
+ gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-boot-on;
+ };
We should put gpio regulators into their own container in the root of
the tree. Similar to what was done for 8960 gpio regulators.
+
+ backlight: backlight{
+ pinctrl-0 = <&pwm_bl_gpios>;
+ pinctrl-names = "default";
+ compatible = "gpio-backlight";
+ gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+ default-on;
+ };
+
+ panel: auo,b101xtn01 {
+ status = "okay";
+ compatible = "auo,b101xtn01";
+
+ ddc-i2c-bus = <&i2c3>;
+ backlight = <&backlight>;
+ power-supply = <&panel_3p3v>;
};
These two nodes shouldn't be under the SoC node. They don't have
registers so they should be at the root of the tree. And we don't need
to put labels twice on nodes. If we're modifying things in board
specific dtsi files it should be fine to leave the label off if the
label is in the SoC dtsi file.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
On Fri 24 Jul 10:41 PDT 2015, Rob Clark wrote: > On Fri, Jul 24, 2015 at 11:39 AM, Rob Herring wrote: > > On Fri, Jul 24, 2015 at 8:10 AM, Rob Clark wrote: > >> On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson > >> wrote: > >>> Add the possibility of specifying the default brightness in DT. > >>> > >>> Signed-off-by: Bjorn Andersson > >>> --- > >>> > >>> This depends on the patch moving pm8941-wled to backlight [1]. The dt > >>> property > >>> is used by several other backlight drivers, so I considered this to be a > >>> "common" property and it's hence not prefixed with "qcom,". > >>> > >>> [1] https://lkml.org/lkml/2015/7/21/906 > >>> > >>> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 + > >>> drivers/video/backlight/pm8941-wled.c | 4 > >>> > >>> 2 files changed, 5 insertions(+) > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt > >>> b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt > >>> index 424f8444a6cd..37503f8c3620 100644 > >>> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt > >>> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt > >>> @@ -5,6 +5,7 @@ Required properties: > >>> - reg: slave address > >>> > >>> Optional properties: > >>> +- default-brightness: value from: 0-4095 > >>> - label: The name of the backlight device > >>> - qcom,cs-out: bool; enable current sink output > >>> - qcom,cabc: bool; enable content adaptive backlight control > >>> diff --git a/drivers/video/backlight/pm8941-wled.c > >>> b/drivers/video/backlight/pm8941-wled.c > >>> index c704c3236034..b875e58df0fc 100644 > >>> --- a/drivers/video/backlight/pm8941-wled.c > >>> +++ b/drivers/video/backlight/pm8941-wled.c > >>> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device > >>> *pdev) > >>> struct backlight_device *bl; > >>> struct pm8941_wled *wled; > >>> struct regmap *regmap; > >>> + u32 val = 0; > >>> int rc; > >> > >> as discussed on IRC, it would be better if the default read back the > >> current settings (so-as to inherit bootloader splash smoothly.. > >> drm/msm supports a memory-region phandle, for example, so it can take > >> over the bootloader splash-screen as stolen-mem) > >> > >> and it would I think be useful to have a comment in the bindings file > >> explaining that you *should* use the default-brightness property to > >> set a sane default if bootloader isn't putting up a splash, and you > >> should *not* use the property if it is.. > > > > +1 > > > > What if you have neither? Set to max brightness? 75%? > > I did chat w/ Bjorn a bit about that on irc.. his concern was some > arbitrary percentage (like 50%) might be more or less bright depending > on the device (although that implies to me that maybe we should have > min and max bindings as well, rather than just assuming hw limits? > idk) > But this issue could easily be solved by having the boot loader pass an appropriate value to the kernel through the dt property, overriding any default from the implementation. Or in the case when the boot does not touch the backlight the dt writer still have the possibility of picking a better value. > my preference is the default is somehow at least not 0%.. possibly > motivated by the expectation that when people see a dark screen at > boot they assume the display driver is broken :-P > Right > > This could also be used for the bootloader to communicate to the > > kernel what the current level is if it is not readable. I've seen one > > backlight recently which you change the level by doing some number of > > pulses on a gpio and a long pulse to turn off. So there is no way to > > know current level without turning off the backlight (unless you > > hardcode the bootloader's level in the kernel like the vendor did). > > Right and even in the case of this driver I feel it's just adding accidental complexity. 50% would solve Rob's problem and we're through the dt property providing the necessary means of changing this, either to match boot loader set levels or developers preferences. I'll rephrase the binding document and update the driver. Regards, 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
Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
On 07/29, Lee Jones wrote:
> On Tue, 28 Jul 2015, Stephen Boyd wrote:
>
> > On 07/28, Viresh Kumar wrote:
> > > Cc'ing few people (whom I cc'd last time as well :)).
> > >
> > > On 27-07-15, 16:20, Lee Jones wrote:
> > > > + - opp-hz : CPU frequency [Hz] for this OPP [See:
> > > > ./opp.txt]
> > > > + - st,avs : List of available voltages [uV] indexed by
> > > > process code
> > > > + - st,cuts : Cut version this OPP is suitable for [0xFF
> > > > means ALL]
> > > > + - st,substrate: Substrate version this OPP is
> > > > suitable for [0xFF means ALL]
[...]
> > > > +cpu0-opp-list {
> > > > + compatible = "operating-points-v2-sti";
> > > > + st,syscfg = <&syscfg [major_offset]>;
> > > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>;
> > > > +
> > > > + opp0 {
> > > > + opp-hz = <12>;
> > > > + st,avs = <1110 1150 1100 1080 1040 1020 980
> > > > 930>;
> > > > + st,substrate= <0xff>;
> > > > + st,cuts = <0xff>;
> > > > + };
> > > > + opp1 {
> > > > + opp-hz = <15>;
> > > > + st,avs = <1200 1200 1200 1200 1170 1140 1100
> > > > 1070>;
> > > > + st,substrate= <0xff>;
> > > > + st,cuts = <0x2>;
> > > > + };
> > > > +};
> > >
> > > I don't see more problems here, unless we can move some of this to the
> > > generic bindings.
> > >
> > > @Rob/Stephen: Please respond before it is late :)
> >
> > It's interesting to have vendor specific properties like avs,
> > cuts, and substrate. That could replace our planned usage of the
> > opp-names property where we encode similar information (speed
> > bin, revision, etc.) into a string that we look for.
> >
> > So I wonder why the avs/cut/substrate information can't be
> > encoded into the opp name? That would make these properties
> > obsolete, given that all they're used for is to pick out the
> > correct OPP?
>
> You could hack the substrate and cut version into a string, but that's
> exactly what it would be, a hack. I'm struggling how you would do the
> same for 'st,avs', which is an array of u32s.
>
(I don't understand the st,avs property to begin with, so feel
free to ignore the rest of this mail.)
For qcom platforms we have the pvs bin and speed bin, and
sometimes a revision number. Each one of these properties
corresponds to a different set of OPPs (opp table). So we might
have speed1-pvs2-v0 for speed bin 1, pvs bin 2 and version 0. We
fill out an opp table for this and then point the opps property
at the table and have a corresponding opp-name "speed1-pvs2-v0"
in the "consumer" node.
operating-points-v2 = <&speed1_pvs2_v0>;
operating-points-names = "speed1-pvs2-v0";
We have quite a few of these tables because the values are
always different. If the values were the same then we could use
the same table with different names I suppose, but we're not
doing that.
>From a quick read of the st properties (that I admit I don't
understand), it looks like we're trying to compress the OPP
tables by listing all the voltages that could be used for a
particular frequency depending on which avs is present on the
device? And then limiting the frequency voltage pairs depending
on which cut and substrate is present?
So we'd probably have to expand out the tables to be unique per
avs/cut/substrate parameter. Something like:
avs0-cut2 {
compatible = "operating-points-v2";
opp0 {
opp-hz = <12>;
opp-microvolt = <1100>;
};
opp1 {
opp-hz = <15>;
opp-microvolt = <1200>;
};
};
avs1-cut2 {
compatible = "operating-points-v2";
opp0 {
opp-hz = <12>;
opp-microvolt = <1150>;
};
opp1 {
opp-hz = <15>;
opp-microvolt = <1200>;
};
};
And then another copy of these for the devices without cuts != 2
where the top frequency is gone?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range
[+cc Andrew]
On Wed, Jul 29, 2015 at 07:44:18PM +, Gabriele Paoloni wrote:
> > -Original Message-
> > From: Bjorn Helgaas [mailto:bhelg...@google.com]
> > Sent: Wednesday, July 29, 2015 6:21 PM
> > To: Gabriele Paoloni
> > On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> > > From: gabriele paoloni
> > > This patch adds a new field in "struct of_pci_range" to store the
> > > pci bus start address; it fills the field in
> > of_pci_range_parser_one();
> > > in of_pci_get_host_bridge_resources() it retrieves the resource
> > entry
> > > after it is created and added to the resource list and uses
> > > entry->__res.start to store the pci controller address
> >
> > struct of_pci_range is starting to get confusing to non-OF folks like
> > me.
> > It now contains:
> >
> > u32 pci_space;
> > u64 pci_addr;
> > u64 cpu_addr;
> > u64 bus_addr;
> >
> > Can you explain what all these things mean, and maybe even add one-line
> > comments to the structure?
> > pci_space: The only uses I see are to determine whether to print
> > "Prefetch". I don't see any real functionality that uses this.
>
> Looking at the code I agree. it's seems to be used only in powerpc
> and microblaze to print out.
> However from my understanding pci_space is the phys.hi field of the
> ranges property: it defines the properties of the address space associated
> to the PCI address. if you're curious you can find a nice and quick to read
> "guide" in http://devicetree.org/MPC5200:PCI
I think pci_space should be removed and the users should test
"range.flags & IORESOURCE_PREFETCH" instead. That's already set by
of_bus_pci_get_flags(). This is separate from your current patch, of
course.
29b635c00f3e ("of/pci: Provide support for parsing PCI DT ranges
property") added struct of_pci_range, and even at the time,
of_bus_pci_get_flags() set IORESOURCE_PREFETCH in of_pci_range.flags.
654837e8fe8d ("powerpc/pci: Use of_pci_range_parser helper in
pci_process_bridge_OF_ranges") converted powerpc to use
of_pci_range_parser() instead of parsing manually. It converted other
references to look at struct of_pci_range.flags; I'm not sure why it
didn't do that for the prefetch bit.
I copied Andrew in case there's some subtlety here.
> > pci_addr: I assume this is a PCI bus address, like what you would see
> > if
> > you put an analyzer on the bus/link. This address could go in a BAR.
>
> Yes, this is the PCI start address of the range: phys.mid + phys.low in the
> guide mentioned above
>
> > cpu_addr: I assume this is a CPU physical address, like what you would
> > see
> > in /proc/iomem and what you would pass to ioremap().
>
> Yes correct
>
> > bus_addr: ?
>
> According to the guide above, this is the address into which the pci_address
> get translated to and that is passed to the root complex. Between the root
> complex and the CPU there can be intermediate translation layers:
I can't quite parse this, but I do understand how a host bridge can
translate CPU physical addresses to a different range of PCI bus
addresses. What I don't understand is the difference between "pci_addr"
and the "bus_addr" you're adding.
> see that to
> get pci_address we call "of_translate_address"; this will apply all the
> translation layers (ranges in the DT) that it finds till it comes to the root
> node of the DT (thus retrieving the CPU address).
> Now said that, for designware we need the first translated PCI address, that
> we call
> here bus_addr after Rob Herring suggested the name...honestly I cannot think
> of a
> different name
>
>
>
> > I'm trying to imagine how this might be expressed in ACPI. A host
> > bridge
> > ACPI _CRS contains a CPU physical address and applying a _TRA
> > (translation
> > offset) to the CPU address gives you a PCI bus address. I know this
> > code
> > is OF, not ACPI, but I assume that it should be possible to describe
> > your
> > hardware via ACPI as well as by OF.
> > > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> > > index d88e81b..865f96e 100644
> > > --- a/include/linux/of_address.h
> > > +++ b/include/linux/of_address.h
> > > @@ -16,6 +16,7 @@ struct of_pci_range {
> > > u32 pci_space;
> > > u64 pci_addr;
> > > u64 cpu_addr;
> > > + u64 bus_addr;
> > > u64 size;
> > > u32 flags;
> > > };
--
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 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
> On 29.07.2015, at 18:37, Stefan Wahren wrote: > > Hi Martin, > >> Am 28.07.2015 um 12:48 schrieb Martin Sperl: >>> On 28.07.2015 08:18, Martin Sperl wrote: >>> Hi Stephen! >>> But the bigger question you have not answered is: “where should such an >>> auxiliar driver go in the kernel tree?” i.e. which directory? >> One thing: could the "module" be a regulator? > > IMHO that won't be acceptable. Why would it not be acceptable? It provides all sorts of methods and you do not have to implement all of them. Enable and disable would be sufficient. On top it would be a generic interface. Even the mcp251x can driver uses 2 of those to enable/disable the controller chip and the transceiver (and 2 dummy regulators if none are defined) There are also gpio regulators to switch a gpio to enable/disable a power-supply. So with all those features it should be fairly standard to be used for such things. See here for a bit of documentation: http://lxr.free-electrons.com/source/Documentation/power/regulator/design.txt http://lxr.free-electrons.com/source/Documentation/power/regulator/consumer.txt (Especially point 2 about enable/disable) > How about a multifunction device driver (drivers/mfd)? > Other candidates could be drivers/soc or drivers/misc. Also possible... Martin-- 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] ARM: dts: qcom: Add binding for the qcom coincell charger
On Wed, Jul 29, 2015 at 11:12:30AM -0700, Tim Bird wrote: > Greg, > > At this point I've got Reviewed-by from Rob on the binding and dts bits, > and Reviewed-by from Andy Gross on the complete patch series (v3). > > I believe I've addressed all issues raised. Can you please add this > (v3) to drivers/misc? > > Let me know if you want me to re-send anything. Nope, I can take it from here, 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
[PATCH] drm: panel-simple: add URT UMSH-8596MD-xT panel support
This patch adds support for United Radiant Technology
UMSH-8596MD-xT 7.0" WVGA TFT LCD panels
(both LVDS and parallel versions) to DRM
panel-simple driver.
Signed-off-by: Maciej Szmigiero
---
.../devicetree/bindings/panel/urt,umsh-8596md.txt | 11 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
drivers/gpu/drm/panel/panel-simple.c | 42
3 files changed, 54 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
new file mode 100644
index 000..2990e6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
@@ -0,0 +1,11 @@
+United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
+
+Supported are LVDS versions (-11T, -19T) and parallel ones
+(-T, -1T, -7T, -20T).
+
+Required properties:
+- compatible: should be "urt,umsh-8596md-lvds" for LVDS versions,
+ "urt,umsh-8596md-parallel" for parallel ones.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d247994..f2bb617 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -212,6 +212,7 @@ toshiba Toshiba Corporation
toumaz Toumaz
tplink TP-LINK Technologies Co., Ltd.
truly Truly Semiconductors Limited
+urtUnited Radiant Technology Corporation
usiUniversal Scientific Industrial Co., Ltd.
v3 V3 Semiconductor
variscite Variscite Ltd.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..be47fd7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1036,6 +1036,42 @@ static const struct panel_desc shelly_sca07010_bfn_lnn =
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct display_timing urt_umsh_8596md_timing = {
+ .pixelclock = { 3326, 3326, 3326 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 41, 41, 41 },
+ .hback_porch = { 216 - 128, 216 - 128, 216 - 128 },
+ .hsync_len = { 71, 128, 128 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 10, 10, 10 },
+ .vback_porch = { 35 - 2, 35 - 2, 35 - 2 },
+ .vsync_len = { 2, 2, 2 },
+ .flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+ DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc urt_umsh_8596md_lvds = {
+ .timings = &urt_umsh_8596md_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
+static const struct panel_desc urt_umsh_8596md_parallel = {
+ .timings = &urt_umsh_8596md_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1125,6 +1161,12 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
}, {
+ .compatible = "urt,umsh-8596md-lvds",
+ .data = &urt_umsh_8596md_lvds,
+ }, {
+ .compatible = "urt,umsh-8596md-parallel",
+ .data = &urt_umsh_8596md_parallel,
+ }, {
/* sentinel */
}
};
--
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] PCI: Store PCIe bus address in struct of_pci_range
Hi Bjorn
Many Thanks for your reply
I have commented back inline with resolutions from my side.
If you're ok with them I'll send it out a new version in the appropriate
patchset
Cheers
Gab
> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Wednesday, July 29, 2015 6:21 PM
> To: Gabriele Paoloni
> Cc: a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B);
> robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
> of_pci_range
>
> Hi Gabriele,
>
> As far as I can tell, this is not specific to PCIe, so please use "PCI"
> in
> the subject as a generic term that includes both PCI and PCIe.
sure agreed
>
> On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> > From: gabriele paoloni
> >
> > This patch is needed port PCIe designware to new DT parsing API
> > As discussed in
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> > in designware we have a problem as the PCI addresses in the PCIe
> controller
> > address space are required in order to perform correct HW
> operation.
> >
> > In order to solve this problem commit f4c55c5a3 "PCI: designware:
> > Program ATU with untranslated address" added code to read the
> PCIe
>
> Conventional reference is 12-char SHA1, like this:
>
> f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated
> address")
Agreed, will change this
>
> > controller start address directly from the DT ranges.
> >
> > In the new DT parsing API of_pci_get_host_bridge_resources()
> hides the
> > DT parser from the host controller drivers, so it is not possible
> > for drivers to parse values directly from the DT.
> >
> > In http://www.spinics.net/lists/linux-pci/msg42540.html we
> already tried
> > to use the new DT parsing API but there is a bug (obviously) in
> setting
> > the <*>_mod_base addresses
> > Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
>
> By itself, this patch adds something. It would help me understand it
> if
> the *user* of this new something were in the same patch series.
the user is: "[PATCH v5 2/5] PCI: designware: Add ARM64 support"
I will ask Zhou Wang to include this patch in his patchset
>
> > This patch adds a new field in "struct of_pci_range" to store the
> > pci bus start address; it fills the field in
> of_pci_range_parser_one();
> > in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> > after it is created and added to the resource list and uses
> > entry->__res.start to store the pci controller address
>
> struct of_pci_range is starting to get confusing to non-OF folks like
> me.
> It now contains:
>
> u32 pci_space;
> u64 pci_addr;
> u64 cpu_addr;
> u64 bus_addr;
>
> Can you explain what all these things mean, and maybe even add one-line
> comments to the structure?
sure I can add comments inline in the code
>
> pci_space: The only uses I see are to determine whether to print
> "Prefetch". I don't see any real functionality that uses this.
Looking at the code I agree. it's seems to be used only in powerpc
and microblaze to print out.
However from my understanding pci_space is the phys.hi field of the
ranges property: it defines the properties of the address space associated
to the PCI address. if you're curious you can find a nice and quick to read
"guide" in http://devicetree.org/MPC5200:PCI
>
> pci_addr: I assume this is a PCI bus address, like what you would see
> if
> you put an analyzer on the bus/link. This address could go in a BAR.
Yes, this is the PCI start address of the range: phys.mid + phys.low in the
guide mentioned above
>
> cpu_addr: I assume this is a CPU physical address, like what you would
> see
> in /proc/iomem and what you would pass to ioremap().
Yes correct
>
> bus_addr: ?
>
According to the guide above, this is the address into which the pci_address
get translated to and that is passed to the root complex. Between the root
complex and the CPU there can be intermediate translation layers: see that to
get pci_address we call "of_translate_address"; this will apply all the
translation layers (ranges in the DT) that it finds till it comes to the root
node of the DT (thus retrieving the CPU address).
Now said that, for designware we need the first translated PCI address, that we
call
here bus_addr after Rob Herring suggested the name...honestly I cannot think of
a
different name
> I'm trying to imagine how this might be expressed in ACPI. A host
> bridge
> ACPI _CRS contains a CPU physical address and applying a _TRA
> (translation
> offset) to the CPU address gives you a PCI bus address. I know this
> code
> is OF, no
Re: [PATCH 12/17] ARM: dts: am57xx-beagle-x15: Fix regulator populated in MMC1 dt node
On 07/29/2015 06:09 AM, Kishon Vijay Abraham I wrote: > For beagle x15, both the vdd and io lines are connected to the > same regulator (ldo1_reg). However vmmc_aux is populated to vdd_3v3. > Remove it. > > Signed-off-by: Kishon Vijay Abraham I > --- > arch/arm/boot/dts/am57xx-beagle-x15.dts |1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts > b/arch/arm/boot/dts/am57xx-beagle-x15.dts > index a63bf78..d0db5c5 100644 > --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts > +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts > @@ -579,7 +579,6 @@ > pinctrl-0 = <&mmc1_pins_default>; > > vmmc-supply = <&ldo1_reg>; > - vmmc_aux-supply = <&vdd_3v3>; > pbias-supply = <&pbias_mmc_reg>; > bus-width = <4>; > cd-gpios = <&gpio6 27 0>; /* gpio 219 */ > Acked-by: Nishanth Menon -- Regards, Nishanth Menon -- 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 3/5] devicetree: soc: Add Qualcomm SMD based RPM DT binding
On Mon, Jul 27, 2015 at 08:20:31PM -0700, Bjorn Andersson wrote: > Add binding documentation for the Qualcomm Resource Power Manager (RPM) > using shared memory (Qualcomm SMD) as transport mechanism. This is found > in 8974 and newer based devices. > > The binding currently describes the rpm itself and the regulator > subnodes. > > Signed-off-by: Bjorn Andersson > --- Applied, thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] soc: qcom: Add device tree binding for Shared Memory Device
On Mon, Jul 27, 2015 at 08:20:29PM -0700, Bjorn Andersson wrote: > Add device tree binding documentation for the Qualcomm Shared Memory > Device, used for communication between the various CPUs in the Qualcomm > SoCs. > > Signed-off-by: Bjorn Andersson > --- Applied, thanks. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
On Wed, Jul 29, 2015 at 08:21:34PM +0200, Michal Suchanek wrote: > On 29 July 2015 at 19:16, Mark Brown wrote: > >> It will not break anything. It will just spam dmesg. > > I'm confused - if all this change does is to spam dmesg then what's the > > point? > Presumably when your SPI NOR flash fails to probe this message will be > just above and you will look into the binding doc and add the > compatible. If you're looking to add a warning message when the flash device fails to probe then add that in the flash driver when it detects an error, this will cause needless noise for everyone else using this controller purely to work around the broken binding. And like I say compatible really seems like it isn't an appropriate property here. signature.asc Description: Digital signature
Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
On 29 July 2015 at 19:16, Mark Brown wrote: > On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote: >> On 29 July 2015 at 16:00, Mark Brown wrote: > >> > I can't tell from this commit message what the issue you're trying to >> > fix is, sorry. Nodes without compatible strings are entirely normal and >> > don't need compatible strings. It sounds like a bug in whatever other >> > driver is becoming confused. > >> The driver that gets confused is ofpart. > >> The two-line patch to allow it to just ignore controller-data has been >> rejected on the basis that s3c64xx should use a compatible string >> because ofpart monopolizes all nodes without compatible which are >> children of a mtd device. Devicetrees containing such nodes that are >> not partitions are presumably invalid and should be rejected when >> ofpart is compiled into the kernel. > > That seems like an extremely limited binding, the normal thing here > would be to create a specifically named node to contain the collection > of subnodes like many PMICs do for their regulators. As a fix I'd > suggest just silently ignoring nodes it can't understand, or printing a > warning if that's a serious issue. > >> >> + if (!of_get_property(data_np, "compatible", NULL) || >> >> + strcmp(of_get_property(data_np, "compatible", NULL), >> >> +"samsung,s3c-controller-data")) >> >> + dev_err(&spi->dev, "child node 'controller-data' does not >> >> have correct compatible\n"); > >> > This will break all existing users which is not acceptable for >> > mainline, we need to preserve compatibility with existing device trees. > >> It will not break anything. It will just spam dmesg. > > I'm confused - if all this change does is to spam dmesg then what's the > point? Presumably when your SPI NOR flash fails to probe this message will be just above and you will look into the binding doc and add the compatible. Thanks Michal -- 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] ARM: dts: qcom: Add binding for the qcom coincell charger
Greg,
At this point I've got Reviewed-by from Rob on the binding and dts bits,
and Reviewed-by from Andy Gross on the complete patch series (v3).
I believe I've addressed all issues raised. Can you please add this
(v3) to drivers/misc?
Let me know if you want me to re-send anything.
Thanks very much.
-- Tim
On 07/17/2015 08:42 AM, Rob Herring wrote:
> On Thu, Jul 16, 2015 at 6:55 PM, Tim Bird wrote:
>> This binding is used to configure the driver for the coincell charger
>> found in Qualcomm PMICs.
>>
>> Signed-off-by: Tim Bird
>
> Reviewed-by: Rob Herring
>
>> ---
>>
>> Changes in v3:
>> - change charge-enable property to charger-disable
>> Changes in v2:
>> - remove 'qcom,' from example node name
>> - Added reference to parent node pm8941@0 and binding doc for it
>>
>> .../bindings/power/qcom,coincell-charger.txt | 48
>> ++
>> 1 file changed, 48 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/power/qcom,coincell-charger.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/power/qcom,coincell-charger.txt
>> b/Documentation/devicetree/bindings/power/qcom,coincell-charger.txt
>> new file mode 100644
>> index 000..0e6d875
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/qcom,coincell-charger.txt
>> @@ -0,0 +1,48 @@
>> +Qualcomm Coincell Charger:
>> +
>> +The hardware block controls charging for a coincell or capacitor that is
>> +used to provide power backup for certain features of the power management
>> +IC (PMIC)
>> +
>> +- compatible:
>> + Usage: required
>> + Value type:
>> + Definition: must be: "qcom,pm8941-coincell"
>> +
>> +- reg:
>> + Usage: required
>> + Value type:
>> + Definition: base address of the coincell charger registers
>> +
>> +- qcom,rset-ohms:
>> + Usage: required
>> + Value type:
>> + Definition: resistance (in ohms) for current-limiting resistor
>> + must be one of: 800, 1200, 1700, 2100
>> +
>> +- qcom,vset-millivolts:
>> + Usage: required
>> + Value type:
>> + Definition: voltage (in millivolts) to apply for charging
>> + must be one of: 2500, 3000, 3100, 3200
>> +
>> +- qcom,charger-disable:
>> + Usage: optional
>> + Value type:
>> + Definition: definining this property disables charging
>> +
>> +This charger is a sub-node of one of the 8941 PMIC blocks, and is specified
>> +as a child node in DTS of that node. See ../mfd/qcom,spmi-pmic.txt and
>> +../mfd/qcom-pm8xxx.txt
>> +
>> +Example:
>> +
>> + pm8941@0 {
>> + coincell@2800 {
>> + compatible = "qcom,pm8941-coincell";
>> + reg = <0x2800>;
>> +
>> + qcom,rset-ohms = <2100>;
>> + qcom,vset-millivolts = <3000>;
>> + };
>> + };
>> --
>> 1.8.2.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 3/6] pci:host: Add Altera PCIe host controller driver
On Wed, Jul 29, 2015 at 9:19 PM, Lorenzo Pieralisi
wrote:
> On Tue, Jul 28, 2015 at 11:45:42AM +0100, Ley Foon Tan wrote:
>
> [...]
>
>> +static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
>> +{
>> + int err, res_valid = 0;
>> + struct device *dev = &pcie->pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + resource_size_t iobase;
>> + struct resource_entry *win;
>> + int offset = 0;
>> +
>> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
>> + &iobase);
>> + if (err)
>> + return err;
>
> On top of Rob's comments on ARM bios32 dependency removal (ie rewrite
> the driver so that it does not use pci_common_init_dev()), if you need IO
> access you have to map iobase, see pci_remap_iospace() in pci-host-generic.c
Thanks. We doesn't support I/O region.
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 3/6] pci:host: Add Altera PCIe host controller driver
On Wed, Jul 29, 2015 at 4:35 PM, Paul Bolle wrote:
> On di, 2015-07-28 at 18:45 +0800, Ley Foon Tan wrote:
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>
>> +config PCIE_ALTERA
>> + bool "Altera PCIe controller"
>> + depends on ARCH_SOCFPGA
>> + depends on OF
>> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI
>> + help
>> + Say Y here if you want to enable PCIe controller support for Altera
>> + SoCFPGA family of SoCs.
>
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>
>> +obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pcie-altera.c
>
>> +#include
>
>> +static const struct of_device_id altera_pcie_of_match[] = {
>> + { .compatible = "altr,pcie-root-port-1.0", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, altera_pcie_of_match);
>
>
>> +static struct platform_driver altera_pcie_driver = {
>> + [...]
>> + .owner = THIS_MODULE,
>> + ]...]
>> +};
>> +
>> +module_platform_driver(altera_pcie_driver);
>> +
>> +MODULE_AUTHOR("Ley Foon Tan ");
>> +MODULE_DESCRIPTION("Altera PCIe host controller driver");
>> +MODULE_LICENSE("GPL v2");
>
> PCIE_ALTERA is a bool symbol. So pcie-altera.o is built-in only. Yet
> pcie-altera.c uses a number of module-specific constructs. Should
> PCIE_ALTERA perhaps be tristate?
Yes, PCIE_ALTERA can be changed to tristate after we remove call to
pci_common_init_dev to now.
pci_common_init_dev is not a exported symbol.
> Likewise for PCIE_ALTERA_MSI in 4/6.
PCIE_ALTERA_MSI can only be built-in only. It depends on quite a
number of non-exported symbols.
Eg: pci_msi_mask_irq, pci_msi_create_irq_domain, irq_domain_set_info and etc..
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: [RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
On Tue, 2015-07-28 at 11:14PM -0700, Moritz Fischer wrote:
> Hi Sören,
>
> On Tue, Jul 28, 2015 at 3:53 PM, Sören Brinkmann
> wrote:
> > On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote:
> >> Hi Sören,
> >>
> >> thanks for your feedback.
> >>
> >> On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
> >> wrote:
> >> > Hi Moritz,
> >> >
> >> > On Fri, 2015-07-24 at 05:21PM -0700, Moritz Fischer wrote:
> >> >> Signed-off-by: Moritz Fischer
> >> >> ---
> >> >> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13
> >> >> +
> >> >> 1 file changed, 13 insertions(+)
> >> >> create mode 100644
> >> >> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >> >> b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >> >> new file mode 100644
> >> >> index 000..ac4499e
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
> >> >> @@ -0,0 +1,13 @@
> >> >> +Xilinx Zynq PL Reset Manager
> >> >> +
> >> >> +Required properties:
> >> >> +- compatible: "xlnx,zynq-reset-pl"
> >> >> +- syscon <&slcr>;
> >> >> +- #reset-cells: 1
> >> >> +
> >> >> +Example:
> >> >> + rstc: rstc@240 {
> >> >> + #reset-cells = <1>;
> >> >> + compatible = "xlnx,zynq-reset-pl";
> >> >> + syscon = <&slcr>;
> >> >> + };
> >> >
> >> > I think you also have to add the outputs and make them part of the
> >> > binding. Otherwise you'd have to read the implementation to find
> >> > out what device should be hooked up to which output of the
> >> > reset-controller.
> >>
> >> Is something like this what you had in mind? I had that prepared for
> >> the next round of patches:
> >>
> >> Reset outputs:
> >> 0 : soft reset
> >> 32 : ddr reset
> >> 64 : topsw reset
> >> 96 : dmac reset
> >> 128: usb0 reset
> >> 129: usb1 reset
> >> 160: gem0 reset
> >> 161: gem1 reset
> >> 164: gem0 rx reset
> >> 165: gem1 rx reset
> >> 166: gem0 ref reset
> >> 167: gem1 ref reset
> >> 192: sdio0 reset
> >> 193: sdio1 reset
> >> 196: sdio0 ref reset
> >> 197: sdio1 ref reset
> >> 224: spi0 reset
> >> 225: spi1 reset
> >> 226: spi0 ref reset
> >> 227: spi1 ref reset
> >> 256: can0 reset
> >> 257: can1 reset
> >> 258: can0 ref reset
> >> 259: can1 ref reset
> >> 288: i2c0 reset
> >> 289: i2c1 reset
> >> 320: uart0 reset
> >> 321: uart1 reset
> >> 322: uart0 ref reset
> >> 323: uart1 ref reset
> >> 352: gpio reset
> >> 384: lqspi reset
> >> 385: qspi ref reset
> >> 416: smc reset
> >> 417: smc ref reset
> >> 448: ocm reset
> >> 512: fpga0 out reset
> >> 513: fpga1 out reset
> >> 514: fpga2 out reset
> >> 515: fpga3 out reset
> >> 544: a9 reset 0
> >> 545: a9 reset 1
> >> 552: peri reset
> >
> > Basically, yes. I guess the gaps are due to directly mapping this number
> > to bank and bit instead of doing some more complex mapping in between?
> > I'm not sure whether I like this :) I guess if a number is off the
> > driver would still toggle the addressed bit?
>
> My assumption was that people would use a #include
> in their dts. Assuming I got the
> numbers in there right this makes it hard to misuse by accident.
> I'm not saying it's perfect ...
Michal always turned down the #include patches with the argument of
re-using the dts files outside of the Linux sources where those includes
etc may not be available in this form.
>
> > I'm not sure, is it worth
> > to do some explicit mapping from logical outputs to a physical reset? It
> > seems it would be a little safer since it would be easy to check that
> > the addressed reset is valid and there wouldn't be any reserved/invalid
> > bits be toggled. Also, it would make the outputs in here a continuous
> > series of numbers without these gaps. Not sure though whether
> > it's worth the additional complexity in the implementation.
>
> So your suggestion is to have a large switch case kind of thingy? I
> thought about it and it seemed complex as there's quite a bunch of
> resets with gaps. Do you know of a driver that does something similar?
Yeah, that was what I had in mind. Some big switch-case lookup that maps
a logical reset number from DT to the HW.
No, I haven't looked around what other drivers do. So, probably the
right thing is to just do what everybody else does.
I was more thinking about how easy it might be to re-use the driver for
the next-gen device.
> When I wrote this I looked at the other reset drivers and figured they
> all had this kind of bank mapping of sorts so I assumed that's how
> people usually do it.
Yeah, I don't think we should make things overly complicated without a
good reason. So, unless DT or reset folks have any objections, I'm fine
with it.
Thanks,
Sören
--
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://vge
Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
Den 29.07.2015 18:37, skrev Stefan Wahren: Hi Martin, Am 28.07.2015 um 12:48 schrieb Martin Sperl: On 28.07.2015 08:18, Martin Sperl wrote: Hi Stephen! But the bigger question you have not answered is: “where should such an auxiliar driver go in the kernel tree?” i.e. which directory? One thing: could the "module" be a regulator? IMHO that won't be acceptable. How about a multifunction device driver (drivers/mfd)? Other candidates could be drivers/soc or drivers/misc. Could it be a power domain driver? Documentation/devicetree/bindings/power/power_domain.txt There are currently a deferred probing issue that might be a problem depending on the module linking order: https://lkml.org/lkml/2015/3/11/483 Noralf. -- 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 v5 2/5] PCI: designware: Add ARM64 support
On Sat, Jul 25, 2015 at 04:21:23AM +0100, Zhou Wang wrote:
> This patch tries to unify ARM32 and ARM64 PCIe in designware driver. Delete
> function dw_pcie_setup, dw_pcie_scan_bus, dw_pcie_map_irq and struct hw_pci,
> move related operations to dw_pcie_host_init. Also set pp->root_bus_nr = 0 in
> each PCIe host driver which is based on pcie-designware. This patch also try
Memory for ports is kzalloc'ed, so there is no need to zero it. I still
think that you should explain the root_bus_nr setting to 0 a bit
better, why you make the change and why it is safe.
[...]
> -int dw_pcie_host_init(struct pcie_port *pp)
> +int __init dw_pcie_host_init(struct pcie_port *pp)
> {
> struct device_node *np = pp->dev->of_node;
> struct platform_device *pdev = to_platform_device(pp->dev);
> - struct of_pci_range range;
> - struct of_pci_range_parser parser;
> + struct pci_bus *bus;
> struct resource *cfg_res;
> - u32 val, na, ns;
> + LIST_HEAD(res);
> + u32 val, ns;
> const __be32 *addrp;
> int i, index, ret;
> + struct resource_entry *win;
>
> - /* Find the address cell size and the number of cells in order to get
> -* the untranslated address.
> -*/
> - of_property_read_u32(np, "#address-cells", &na);
> + /* Find the number of cells in order to get the untranslated address
> */
> ns = of_n_size_cells(np);
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "config");
> @@ -392,78 +382,62 @@ int dw_pcie_host_init(struct pcie_port *pp)
> dev_err(pp->dev, "missing *config* reg space\n");
> }
>
> - if (of_pci_range_parser_init(&parser, np)) {
> - dev_err(pp->dev, "missing ranges property\n");
> - return -EINVAL;
> - }
> + ret = of_pci_get_host_bridge_resources(np, 0, 0xff, &res,
> &pp->io_base);
> + if (ret)
> + return ret;
>
> /* Get the I/O and memory ranges from DT */
> - for_each_of_pci_range(&parser, &range) {
> - unsigned long restype = range.flags & IORESOURCE_TYPE_BITS;
> -
> - if (restype == IORESOURCE_IO) {
> - of_pci_range_to_resource(&range, np, &pp->io);
> - pp->io.name = "I/O";
> - pp->io.start = max_t(resource_size_t,
> -PCIBIOS_MIN_IO,
> -range.pci_addr +
> global_io_offset);
> - pp->io.end = min_t(resource_size_t,
> - IO_SPACE_LIMIT,
> - range.pci_addr + range.size
> - + global_io_offset - 1);
> - pp->io_size = resource_size(&pp->io);
> - pp->io_bus_addr = range.pci_addr;
> - pp->io_base = range.cpu_addr;
> -
> - /* Find the untranslated IO space address */
> - pp->io_mod_base = of_read_number(parser.range -
> -parser.np + na, ns);
> - }
> - if (restype == IORESOURCE_MEM) {
> - of_pci_range_to_resource(&range, np, &pp->mem);
> - pp->mem.name = "MEM";
> - pp->mem_size = resource_size(&pp->mem);
> - pp->mem_bus_addr = range.pci_addr;
> -
> - /* Find the untranslated MEM space address */
> - pp->mem_mod_base = of_read_number(parser.range -
> - parser.np + na, ns);
> - }
> - if (restype == 0) {
> - of_pci_range_to_resource(&range, np, &pp->cfg);
> - pp->cfg0_size = resource_size(&pp->cfg)/2;
> - pp->cfg1_size = resource_size(&pp->cfg)/2;
> - pp->cfg0_base = pp->cfg.start;
> - pp->cfg1_base = pp->cfg.start + pp->cfg0_size;
> + resource_list_for_each_entry(win, &res) {
> + switch (resource_type(win->res)) {
> + case IORESOURCE_IO:
> + pp->io = win->res;
> + pp->io->name = "I/O";
> + pp->io_size = resource_size(pp->io);
> + pp->io_bus_addr = pp->io->start - win->offset;
> + pp->io_mod_base = win->__res.start;
> + ret = pci_remap_iospace(pp->io, pp->io_base);
> + if (ret) {
> + dev_warn(pp->dev, "error %d: failed to map
> resource %pR\n",
> +ret, pp->io);
> + continue;
> + }
> + break;
> +
Re: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range
Hi Gabriele,
As far as I can tell, this is not specific to PCIe, so please use "PCI" in
the subject as a generic term that includes both PCI and PCIe.
On Mon, Jul 27, 2015 at 11:17:03PM +0800, Gabriele Paoloni wrote:
> From: gabriele paoloni
>
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
>
> In order to solve this problem commit f4c55c5a3 "PCI: designware:
> Program ATU with untranslated address" added code to read the PCIe
Conventional reference is 12-char SHA1, like this:
f4c55c5a3f7f ("PCI: designware: Program ATU with untranslated address")
> controller start address directly from the DT ranges.
>
> In the new DT parsing API of_pci_get_host_bridge_resources() hides the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
>
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already tried
> to use the new DT parsing API but there is a bug (obviously) in setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win->__res.start"
By itself, this patch adds something. It would help me understand it if
the *user* of this new something were in the same patch series.
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
struct of_pci_range is starting to get confusing to non-OF folks like me.
It now contains:
u32 pci_space;
u64 pci_addr;
u64 cpu_addr;
u64 bus_addr;
Can you explain what all these things mean, and maybe even add one-line
comments to the structure?
pci_space: The only uses I see are to determine whether to print
"Prefetch". I don't see any real functionality that uses this.
pci_addr: I assume this is a PCI bus address, like what you would see if
you put an analyzer on the bus/link. This address could go in a BAR.
cpu_addr: I assume this is a CPU physical address, like what you would see
in /proc/iomem and what you would pass to ioremap().
bus_addr: ?
I'm trying to imagine how this might be expressed in ACPI. A host bridge
ACPI _CRS contains a CPU physical address and applying a _TRA (translation
offset) to the CPU address gives you a PCI bus address. I know this code
is OF, not ACPI, but I assume that it should be possible to describe your
hardware via ACPI as well as by OF.
> the patch is based on 4.2-rc1
You can put this after the "---" line because it's not relevant in the
permanent changelog.
> Signed-off-by: Gabriele Paoloni
> Acked-by: Liviu Dudau
> Acked-by: Rob Herring
Please un-indent your changelog.
> ---
> drivers/of/address.c | 2 ++
> drivers/of/of_pci.c| 4
> include/linux/of_address.h | 1 +
> 3 files changed, 7 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
> struct of_pci_range *range)
> {
> const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
>
> if (!range)
> return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
> range->pci_addr = of_read_number(parser->range + 1, ns);
> range->cpu_addr = of_translate_address(parser->node,
> parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
> range->size = of_read_number(parser->range + parser->pna + na, ns);
>
> parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct device_node
> *dev,
>
> pr_debug("Parsing ranges property...\n");
> for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
> /* Read next ranges element */
> if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
> snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct device_node
> *dev,
> }
>
> pci_add_resource_offset(resources, res, res
Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote: > On 29 July 2015 at 16:00, Mark Brown wrote: > > I can't tell from this commit message what the issue you're trying to > > fix is, sorry. Nodes without compatible strings are entirely normal and > > don't need compatible strings. It sounds like a bug in whatever other > > driver is becoming confused. > The driver that gets confused is ofpart. > The two-line patch to allow it to just ignore controller-data has been > rejected on the basis that s3c64xx should use a compatible string > because ofpart monopolizes all nodes without compatible which are > children of a mtd device. Devicetrees containing such nodes that are > not partitions are presumably invalid and should be rejected when > ofpart is compiled into the kernel. That seems like an extremely limited binding, the normal thing here would be to create a specifically named node to contain the collection of subnodes like many PMICs do for their regulators. As a fix I'd suggest just silently ignoring nodes it can't understand, or printing a warning if that's a serious issue. > >> + if (!of_get_property(data_np, "compatible", NULL) || > >> + strcmp(of_get_property(data_np, "compatible", NULL), > >> +"samsung,s3c-controller-data")) > >> + dev_err(&spi->dev, "child node 'controller-data' does not > >> have correct compatible\n"); > > This will break all existing users which is not acceptable for > > mainline, we need to preserve compatibility with existing device trees. > It will not break anything. It will just spam dmesg. I'm confused - if all this change does is to spam dmesg then what's the point? signature.asc Description: Digital signature
Re: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
On Wed, Jul 29, 2015 at 06:19:24PM +0200, Michal Suchanek wrote: > On 29 July 2015 at 16:00, Mark Brown wrote: > > On Wed, Jul 29, 2015 at 12:19:57PM +0200, Michal Suchanek wrote: > > > > Please use subject lines matching the style for the subsytsem so people > > can spot that the patch is in some way relevant. > > > >> The controller-data subnode has no compatible. This can lead to other > >> drivers getting confused by it. Add a compatible to make devicetreee > >> unambiguous. > > > > I can't tell from this commit message what the issue you're trying to > > fix is, sorry. Nodes without compatible strings are entirely normal and > > don't need compatible strings. It sounds like a bug in whatever other > > driver is becoming confused. > > The driver that gets confused is ofpart. > > The two-line patch to allow it to just ignore controller-data has been > rejected on the basis that s3c64xx should use a compatible string It wasn't outright rejected, but it was questioned. > because ofpart monopolizes all nodes without compatible which are > children of a mtd device. Devicetrees containing such nodes that are > not partitions are presumably invalid and should be rejected when > ofpart is compiled into the kernel. That characterization is currently correct. I'm not a fan of what ofpart does in the first place; I'd really like it if its binding was written in a way that made it more precise, but we have to live with what we have. I also didn't like that you were designing your system such that we were now keying off the fact that your node has no 'reg' property. This seemed awfully fragile. (Admittedly, so is ofpart.c.) All in all, if you have better suggestions, I'm all ears. (At first glance, I'm liking your patch 1 to help disambiguate both MTD partitions and the 'controller-data' node going forward.) Brian -- 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: How-to: Uniquely identify a DT node in the driver?
On Tue, Jul 28, 2015 at 08:38:33PM +0100, Lina Iyer wrote:
> Hello,
>
> I am looking to find a way to uniquely identify a device in the driver.
> Here is an example -
>
> big: power-controller@1 {
> compatible = "soc,foo";
> ...
> };
>
> little: power-controller@2 {
> compatible = "soc,foo";
> ...
> };
Ok, so these are two instances of the same block...
> In the driver for the power-controller foo.c, would like to do -
>
> struct xyz {
> const char *name;
> ...
> };
>
> static struct xyz a = {
> .name = "big"; // To be associated with big device
> ...
> };
>
> static struct xyz b = {
> .name = "little"; // To be associated with little device
> ...
> };
... which we're magically assuming things about.
> What would be the best way to associate the power-controller devices 'big'
> and 'little' with 'a' and 'b' respectively? A string comparison would be
> ideal but possibly can work with other ways.
>
> I could think of adding compatibles to achieve this, but was hoping to
> find something more elegant and appropriate. Or, is compatible the
> recommended way to uniquely identify devices by the driver?
There's no recommended way to uniquely idetnify a device, because in
general it doesn't make sense to do so. Doing so implies intimate
knowledge of a particular board and a lack of hardware description in
the DT (otherwise you wouldn't need to associate additional information
with the instance).
Either you need to describe some characteristic of the device with some
properties on each instance, or you need to derive that form the linkage
to other devices.
It looks like you're trying to give different behviours to "big" and
"little" clusters, which doesn't really fit either case. What do you
want to differ? e.g. is it just the set of OPPs?
Thanks,
Mark.
--
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 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
Hi Martin, Am 28.07.2015 um 12:48 schrieb Martin Sperl: On 28.07.2015 08:18, Martin Sperl wrote: Hi Stephen! But the bigger question you have not answered is: “where should such an auxiliar driver go in the kernel tree?” i.e. which directory? One thing: could the "module" be a regulator? IMHO that won't be acceptable. How about a multifunction device driver (drivers/mfd)? Other candidates could be drivers/soc or drivers/misc. Regards Stefan -- 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: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
On 29 July 2015 at 16:00, Mark Brown wrote: > On Wed, Jul 29, 2015 at 12:19:57PM +0200, Michal Suchanek wrote: > > Please use subject lines matching the style for the subsytsem so people > can spot that the patch is in some way relevant. > >> The controller-data subnode has no compatible. This can lead to other >> drivers getting confused by it. Add a compatible to make devicetreee >> unambiguous. > > I can't tell from this commit message what the issue you're trying to > fix is, sorry. Nodes without compatible strings are entirely normal and > don't need compatible strings. It sounds like a bug in whatever other > driver is becoming confused. The driver that gets confused is ofpart. The two-line patch to allow it to just ignore controller-data has been rejected on the basis that s3c64xx should use a compatible string because ofpart monopolizes all nodes without compatible which are children of a mtd device. Devicetrees containing such nodes that are not partitions are presumably invalid and should be rejected when ofpart is compiled into the kernel. > >> + if (!of_get_property(data_np, "compatible", NULL) || >> + strcmp(of_get_property(data_np, "compatible", NULL), >> +"samsung,s3c-controller-data")) >> + dev_err(&spi->dev, "child node 'controller-data' does not have >> correct compatible\n"); > > This will break all existing users which is not acceptable for > mainline, we need to preserve compatibility with existing device trees. It will not break anything. It will just spam dmesg. Thanks Michal -- 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] PCI: Store PCIe bus address in struct of_pci_range
Hi Bjorn
Liviu and Rob already acked, do you think it is ok to merge this?
Cheers
Gab
> -Original Message-
> From: Gabriele Paoloni
> Sent: Monday, July 27, 2015 4:17 PM
> To: Gabriele Paoloni; a...@arndb.de; lorenzo.pieral...@arm.com;
> Wangzhou (B); bhelg...@google.com; robh...@kernel.org;
> james.mo...@arm.com; liviu.du...@arm.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
> qiuzhenfa; Liguozhu (Kenneth)
> Subject: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range
>
> From: gabriele paoloni
>
> This patch is needed port PCIe designware to new DT parsing API
> As discussed in
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> January/317743.html
> in designware we have a problem as the PCI addresses in the PCIe
> controller
> address space are required in order to perform correct HW operation.
>
> In order to solve this problem commit f4c55c5a3 "PCI: designware:
> Program ATU with untranslated address" added code to read the PCIe
> controller start address directly from the DT ranges.
>
> In the new DT parsing API of_pci_get_host_bridge_resources() hides
> the
> DT parser from the host controller drivers, so it is not possible
> for drivers to parse values directly from the DT.
>
> In http://www.spinics.net/lists/linux-pci/msg42540.html we already
> tried
> to use the new DT parsing API but there is a bug (obviously) in
> setting
> the <*>_mod_base addresses
> Applying this patch we can easily set "<*>_mod_base = win-
> >__res.start"
>
> This patch adds a new field in "struct of_pci_range" to store the
> pci bus start address; it fills the field in
> of_pci_range_parser_one();
> in of_pci_get_host_bridge_resources() it retrieves the resource
> entry
> after it is created and added to the resource list and uses
> entry->__res.start to store the pci controller address
>
> the patch is based on 4.2-rc1
>
> Signed-off-by: Gabriele Paoloni
> Acked-by: Liviu Dudau
> Acked-by: Rob Herring
> ---
> drivers/of/address.c | 2 ++
> drivers/of/of_pci.c| 4
> include/linux/of_address.h | 1 +
> 3 files changed, 7 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 8bfda6a..23a5793 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -253,6 +253,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
> struct of_pci_range *range)
> {
> const int na = 3, ns = 2;
> + const int p_ns = of_n_size_cells(parser->node);
>
> if (!range)
> return NULL;
> @@ -265,6 +266,7 @@ struct of_pci_range *of_pci_range_parser_one(struct
> of_pci_range_parser *parser,
> range->pci_addr = of_read_number(parser->range + 1, ns);
> range->cpu_addr = of_translate_address(parser->node,
> parser->range + na);
> + range->bus_addr = of_read_number(parser->range + na, p_ns);
> range->size = of_read_number(parser->range + parser->pna + na,
> ns);
>
> parser->range += parser->np;
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..fe57030 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -198,6 +198,7 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
>
> pr_debug("Parsing ranges property...\n");
> for_each_of_pci_range(&parser, &range) {
> + struct resource_entry *entry;
> /* Read next ranges element */
> if ((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO)
> snprintf(range_type, 4, " IO");
> @@ -240,6 +241,9 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> }
>
> pci_add_resource_offset(resources, res, res->start -
> range.pci_addr);
> + entry = list_last_entry(resources, struct resource_entry,
> node);
> + /* we are using __res for storing the PCI controller
> address */
> + entry->__res.start = range.bus_addr;
> }
>
> return 0;
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index d88e81b..865f96e 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -16,6 +16,7 @@ struct of_pci_range {
> u32 pci_space;
> u64 pci_addr;
> u64 cpu_addr;
> + u64 bus_addr;
> u64 size;
> u32 flags;
> };
> --
> 1.9.1
Re: How-to: Uniquely identify a DT node in the driver?
On Wed, Jul 29 2015 at 03:44 -0600, Sudeep Holla wrote:
On 28/07/15 20:38, Lina Iyer wrote:
Hello,
I am looking to find a way to uniquely identify a device in the driver.
Here is an example -
big: power-controller@1 {
compatible = "soc,foo";
...
};
little: power-controller@2 {
compatible = "soc,foo";
...
};
In the driver for the power-controller foo.c, would like to do -
struct xyz {
const char *name;
...
};
static struct xyz a = {
.name = "big"; // To be associated with big device
...
};
static struct xyz b = {
.name = "little"; // To be associated with little device
...
};
What would be the best way to associate the power-controller devices 'big'
and 'little' with 'a' and 'b' respectively? A string comparison would be
ideal but possibly can work with other ways.
Why do you want to distinguish them within the driver ? IIUC each of
these power controller will get instantiated as separate devices with
unique properties.
Assuming the big and little above are related to CPUs, if each of the
CPUs have phandles to their respective power controller, IMO you need
not distinguish between the big and the little power controllers.
I may be missing something here, one possible reason I can think of for
distinguishing them is both power controllers have same set of
properties in DT, but they differ in the way you access them or program
them(e.g. sequence). In that case have different compatible makes sense.
You are right. My reason for distinguishing between these devices is
something of a device specific action.
I could think of adding compatibles to achieve this, but was hoping to
find something more elegant and appropriate. Or, is compatible the
recommended way to uniquely identify devices by the driver?
If you provide the exact reason for distinguishing them within the
driver, that would help to come up with the solution.
I thought the context would be confusing, so just sent the gist of the
problem. Well anyways, here it is -
I am trying to instantiate generic PM domains for different CPU clusters
commonly. Individual platform code may have different actions for
powering down/up the CPU domain. It could be different set of bucks that
they need to talk to or bunch of devices. The common code would like to
provide the opportunity for the platform code to perform their
activities.
CPUs may be organized into 'n' clusters, the common code would create
genpd for each of these clusters. In a multi machine image, to identify
the right platform driver for the cluster, is a challenge. I am trying
to solve it the same way as CPUidle - using __init section tables. To
uniquely identify a cluster in a SoC, I need a way to match the domain
provider's DT node, with a callback in the driver. Like the 'method'
attribute of the CPUIdle macros. The CPU compatibles are too generic and
could duplicate across SoCs to be used for comparison. For e.g, you
could have two clusters of A53 cores that could use the same compatible
string. Distinguishing the domains for each of these clusters is a pain
(but doable using phandles to the domain referenced by the CPU).
To make it easy for the driver, I could only think of adding an unique
compatible string to the domain node and the platform driver would then
be able to same compatible string to distinguish between domains for the
different clusters.
Alternately, I was exploring a way to use phandles for the device nodes
as unique comparison attributes, but that is more complex and doesnt
provide any better benefit than the compatible.
My RFC post for CPU PM domains is here [1].
Thanks,
Lina
[1].
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352787.html
--
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: [RFC] improve binding for linux,wdt-gpio
Hi Uwe,
On 07/29/2015 12:35 AM, Uwe Kleine-König wrote:
Hello Guenter,
[ ... ]
always-running is meant to indicate that the watchdog can not be stopped
(meaning a timer has to be used to send keepalives while the watchdog
device is closed). The documentation specifically states that.
"If the watchdog timer cannot be disabled ..."
How would you express that condition without always-running or a similar
attribute ? I am also not sure how that relates to hw_algo; I thought
those properties are orthogonal.
For hw_algo = "level" the inactive level of the gpio disables the
watchdog (and resets the counter). So always-running doesn't make sense
for this type.
That is not what is currently implemented. "level" just means that
the watchdog is pinged using a -high-low-high- or -low-high-low-
sequence, while toggle means that the level is changed with each
ping (-low-(wait)-high-(wait)-low-(wait)-high-...).
Of course, 'always-running' _may_ describe driver behavior, but that doesn't
Well in the current state of the binding document we have:
add this flag to have the driver keep toggling the signal
without a client.
Sure it is meant to describe a hardware specific property, but it talks
about the driver.
Then the fix is to update the binding document.
I'd go for these properties then:
toggle-gpio: the gpio used to stroke the watchdog
'toggle' means something different in the current implementation.
enable-gpio: optional, the gpio to enable and disable the watchdog
disable-on-tri-state: optional, signals that the watchdog can
be stopped by setting the trigger-gpio to tri-state.
compatible, hw_algo and hw_margin_ms: as before.
I would agree that a separate 'enable' property would make sense (if you
have a watchdog needing it). Similar to disable-on-tri-state, if there
is some hardware which is implemented that way (mixing up hw_algo==toggle
with that state doesn't seem correct). Deprecating hw_algo and replacing it
with something more sensible might make sense as well ('algorithm' ?).
We have to be careful not to mix up hw_algo and enable, though.
I think there is no need for a property that signals that the watchdog
is unstoppable. For level-gpio-watchdogs you can do it by setting the
trigger gpio to inactive, and you cannot stop level-gpio-watchdogs
unless enable-gpio or disable-on-tri-state is specified.
If we ever feel the need to describe a gpio watchdog with a input that
starts the device but cannot stop it, I'd suggest to use "start-gpio"
for that one.
have to be the case. There are lots of watchdogs out there which can not be
stopped. Some of them run all the time, others can not be stopped once
started.
Yeah, I'm aware of that. For this driver however I wouldn't expect that
you have a dedicated enable-gpio if you cannot disable the device with it.
Why ? There are lots of chips which implement exactly that. There is an
enable bit in some register which can be used to enable the watchdog,
but once enabled it can not be stopped. I don't see why a gpio driven
watchdog would have to be any different.
For hw_algo = "level" there is probably no device with an enable input
Why should that be the case ?
and for hw_algo = "toggle" any sane hardware engineer would simply
enable the watchdog once the first toggle is detected on WDI. (OK,
assuming hardware engineers being sane turned out to be a weak argument
often in the past.)
I still don't see the relationship between enable and the toggle/level
algorithm. Really, those two properties are orthogonal.
I'm aware that using ...-gpios is more common than ...-gpio. I don't
feel strong here, but as only a single gpio makes sense here, having
-gpios seems wrong.
Documentation/devicetree/bindings/gpio/gpio.txt states that gpio pin
references should be named -gpios. It even lists examples such as
enable-gpios = <&gpio2 2>;
I thought this was a hard rule, and I seem to recall requests to change
something-gpio to something-spios, but I may be wrong.
Yeah, I'm aware of that. I talked about that in #armlinux yesterday, and
Mark Brown (added to Cc:) said:
Well, I'd prefer to change the standard TBH and allow singular.
This keeps coming up and causing confusion for no good reason.
Sounds sensible in my ears.
Makes sense to me, but I'd like to see that done first.
Thanks,
Guenter
--
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/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 29/07/15 18:26, nick wrote: > > > On 2015-07-29 11:12 AM, Roger Quadros wrote: >> On 29/07/15 17:08, nick wrote: >>> >>> >>> On 2015-07-29 09:52 AM, Roger Quadros wrote: On 29/07/15 15:13, nick wrote: > > > On 2015-07-29 08:06 AM, Roger Quadros wrote: >> Tony, >> >> On 13/07/15 15:40, Tony Lindgren wrote: >>> * Roger Quadros [150713 03:07]: Tony, On 13/07/15 10:10, Tony Lindgren wrote: > * Roger Quadros [150710 05:26]: >> Since the Interrupt Events are used only by the NAND driver, >> there is no point in managing the Interrupt registers >> in the GPMC driver and complicating it with irqchip modeling. > > I don't think it's a good idea to allow external drivers to > tinker directly with GPMC registers. How about just set up GPMC > as an irqchip for the edge detection interrupts? > > I think we already have devices with multiple NAND chips. And > there's nothing stopping other drivers from using the edge > detection interrupts. OK. The GPMC_IRQ registers manage 2 NAND specific interrupts (terminalcount and fifo) and 'n' WAIT pin edge interrupts. So we can model this as a irqchip with 'n + 2' interrupts. >>> >>> OK >> >> For the wait pins irqchip is not sufficient and it needs to be gpiochip >> with irqchip. Waitpin status can be read from GPIO_STATUS register. >> >> Just getting the interrupt is not enough and we want to know if the >> line is high or low. That is how nand->dev_ready works. >> >> How about having 2 IRQ domains? >> One is irqchip with 2 interrupts (terminalcount and fifo) and second is >> gpiochip + irqchip for the n wait pins. >> >> The nand driver can then be modified to use GPIO to get Read/Busy >> pin status from the wait pin. >> >> cheers, >> -roger >> > Doesn't OMAP boards support shared IRQs and if so why not share them > across one > IRQ domain if possible to save IRQ domains for other hardware that needs > its > own IRQ domain. This is just a suggestion through as I don't have the > hardware > spec sheet on me Roger. IRQ domain is a virtual abstraction introduced to prevent kernel irq number overlapping in a single flat domain. I don't see what you can save by domain reuse. Some memory maybe at most. Shared interrupt is something totally different but we're trying to add real hardware interrupts here. Didn't understand what you will share it with. cheers, -roger >>> My question then is do these hardware interrupts need to be on their own >>> interrupt line >>> for the CPU or can they share a CPU line as my concern is if possible we >>> may be able to >>> save a interrupt line for other use. I known on Intel CPUs this is a very >>> limited resource >>> but not sure on OMAP based boards if not then just avoid my recommendations. >> >> It is like adding an external interrupt controller to expand the number of >> available >> hardware interrupts. >> This interrupt controller will still use the same GPMC IRQ line to propagate >> the >> irq event upwards. >> >> cheers, >> -roger >> > That was my other suggestion for IRQ issues. Would you mind sending me a link > to a spec sheet so > I can review your patches better as you stated you wanted me to do this for > you. Sure. You can pick up any of omap3/4 or 5 Technical Reference Manuals. e.g. omap5 TRM is here http://www.ti.com/product/OMAP5432/technicaldocuments cheers, -roger -- 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] ARM64: zynqmp: Add eeprom memories on i2c bus
On Wed, Jul 29, 2015 at 7:49 PM, Michal Simek wrote:
> Add i2c eeprom memories on i2c bus.
>
Thanks for the patch.
Feel free to add
Reviewed-by: Shubhrajyoti Datta
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - Change eeprom max freq from 100k to 400k
>
> ---
> arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> index c5cc8dbd0968..3b1011169756 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> @@ -50,6 +50,24 @@
> status = "okay";
> };
>
> +&i2c0 {
> + status = "okay";
> + clock-frequency = <40>;
> + eeprom@54 {
> + compatible = "at,24c64";
> + reg = <0x54>;
> + };
> +};
> +
> +&i2c1 {
> + status = "okay";
> + clock-frequency = <40>;
> + eeprom@55 {
> + compatible = "at,24c64";
> + reg = <0x55>;
> + };
> +};
> +
> &sata {
> status = "okay";
> ceva,broken-gen2;
> --
> 2.3.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v4 4/5] tty/serial: at91: add support to FIFOs
Around Wed 29 Jul 2015 17:09:59 +0200 or thereabout, Nicolas Ferre wrote: > Le 29/07/2015 16:51, Andy Shevchenko a écrit : >> On Thu, Jul 2, 2015 at 4:18 PM, Cyrille Pitchen >> wrote: >>> Depending on the hardware, TX and RX FIFOs may be available. The RX >>> FIFO can avoid receive overruns, especially when DMA transfers are >>> not used to read data from the Receive Holding Register. For heavy >>> system load, The CPU is likely not be able to fetch data fast enough >>> from the RHR. >> >> This patch broke avr32 console (as seen in today's linux-next) on ATNGW100. >> Reverting helps. I'm pretty sure the issue is in 8 bit vs. 32 bit I/O access. Highly likely, you can not do I/O read/write in 8-bit operations on AVR32, only 32-bit operations are supported. If you do 8-bit or 16-bit operations you will read and write garbage data. > I would like that we don't revert the patch. > We'll try to blindly find the cause for this issue. > >> # uname -a >> Linux buildroot 4.2.0-rc4-next-20150729+ #97 Wed Jul 29 17:50:11 EEST >> 2015 avr32 GNU/Linux >> >> Do you, guys, have that board (NGW100) or it's officially unsupported? > > Sorry but we don't have AVR32-based board in our office. Hans-Christian > kindly helps us fixing the issues that we find and we tend to rely on > the community for this architecture support... > >> If the latter is the case I would really appreciate if you remove the >> support from the kernel side. > > I won't decide for its removal. Only the maintainers with feedback from > the user base can. I still use my board every now and then, and there are that odd request every now and then. >>> In addition, the RX FIFO can supersede the DMA/PDC to control the RTS >>> line when the Hardware Handshaking mode is enabled. Two thresholds >>> are to be set for that purpose: >>> - When the number of data in the RX FIFO crosses and becomes lower >>> than or equal to the low threshold, the RTS line is set to low >>> level: the remote peer is requested to send data. >>> - When the number of data in the RX FIFO crosses and becomes greater >>> than or equal to the high threshold, the RTS line is set to high >>> level: the remote peer should stop sending new data. >>> - low threshold <= high threshold >>> Once these two thresholds are set properly, this new feature is >>> enabled by setting the FIFO RTS Control bit of the FIFO Mode Register. >>> >>> FIFOs also introduce a new multiple data mode: the USART works either >>> in multiple data mode or in single data (legacy) mode. >>> >>> If MODE9 bit is set into the Mode Register or if USMODE is set to >>> either LIN_MASTER, LIN_SLAVE or LON_MODE, FIFOs operate in single >>> data mode. Otherwise, they operate in multiple data mode. >>> >>> In this new multiple data mode, accesses to the Receive Holding >>> Register or Transmit Holding Register slightly change. >>> >>> Since this driver implements neither the 9bit data feature (MODE9 bit >>> set into the Mode Register) nor LIN modes, the USART works in >>> multiple data mode whenever FIFOs are available and enabled. We also >>> assume that data are 8bit wide. >>> >>> In single data mode, 32bit access CAN be used to read a single data >>> from RHR or write a single data into THR. >>> However in multiple data mode, a 32bit access to RHR now allows us to >>> read four consecutive data from RX FIFO. Also a 32bit access to THR >>> now allows to write four consecutive data into TX FIFO. So we MUST >>> use 8bit access whenever only one data have to be read/written at a >>> time. Hmm, does AVR32 even have this feature? >>> Signed-off-by: Cyrille Pitchen >>> --- >>> drivers/tty/serial/atmel_serial.c | 100 >>> +++--- >>> include/linux/atmel_serial.h | 36 ++ >>> 2 files changed, 130 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/tty/serial/atmel_serial.c >>> b/drivers/tty/serial/atmel_serial.c >>> index e7c337de31d1..87de21f0c7a3 100644 >>> --- a/drivers/tty/serial/atmel_serial.c >>> +++ b/drivers/tty/serial/atmel_serial.c >>> @@ -56,6 +56,15 @@ >>> /* Revisit: We should calculate this based on the actual port settings */ >>> #define PDC_RX_TIMEOUT (3 * 10)/* 3 bytes */ >>> >>> +/* The minium number of data FIFOs should be able to contain */ >>&g
Re: [PATCH v2 04/22] of/platform: add of_platform_device_find()
On Wed, Jul 29, 2015 at 6:20 AM, Tomeu Vizoso wrote: > On 29 July 2015 at 08:14, Tomeu Vizoso wrote: >> On 28 July 2015 at 17:31, Rob Herring wrote: >>> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso >>> wrote: On 28 July 2015 at 15:39, Rob Herring wrote: > On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso > wrote: >> From an arbitrary node in the tree, find the enclosing node that >> corresponds to a platform device, as registered by >> of_platform_populate(). [...] If I had a way to get, say, a i2c device from its fwnode then I would just need to make sure that a device's parent is probed before probing it and everything would be cleaner in the OF case. >>> >>> If you have the struct device from the device_node, then you should be >>> able to do this, right? >> >> Yes, if I could go back from the device_node to the struct device that >> was registered from it, for all buses, then all this would be much >> simpler and more robust. It would basically work like in the ACPI >> case. >> >> I will play with this idea. >> > That is probably not the > most efficient search, but we could fix that. We could add struct > device ptr to struct device_node and check without searching for > example. That would be great, but I thought there was an issue with a OF node being able to be related to more than one struct device (but I haven't found this myself yet). >>> >>> I think it pretty much should be one to one. I'm not aware of any >>> examples where that is not the case. This function would already be >>> broken if you could have more than one struct device. >> >> Well, for platform devices we currently know that there can only be >> one struct device for a given device_node, but that's not so clear for >> other devices. > > Just found this case: > > http://lxr.free-electrons.com/source/drivers/spi/spi-tegra114.c#L1124 > > Looks like SPI master devices point to the same device_node as the > platform device that registers them. I don't think this is a problem. The device ptr would only point to the platform device. Nothing else is going to know about the ptr, modify it nor expect that it points to the same struct device that contains the of_node ptr. So I think any instances of struct device like this are ones you don't care about for purposes of probe dependencies. 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 v2] dtb: Create a common home for cross-architecture dtsi files.
On Wed, Jul 29, 2015 at 8:22 AM, Ian Campbell wrote: > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote: >> Hi Ian, >> >> >> 2015-07-27 19:35 GMT+09:00 Ian Campbell : >> > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on >> > LogicTile Express 20MG" added a new dts file to arch/arm64 which >> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a >> > .dtsi supplied by arch/arm. >> > >> > Unfortunately this causes some issues for the split device tree >> > repository[0], since things get moved around there. In that context >> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts >> > while the include is at src/arm/vexpress-v2m-rs1.dtsi. >> > >> > The sharing of the .dtsi is legitimate since the baseboard is the same >> > for various vexpress systems whatever processor they use. >> > >> > Rather than using ../../ tricks to pickup .dtsi files from another >> > arch this patch creates a new directory include/dt-dtsi as a >> > home for such cross-arch .dtsi files, arranges for it to be in the >> > include path when the .dts files are processed by cpp and switches the >> >> >> "include/dt-dtsi/" can be referenced from normal C sources. >> >> I think another possible home for cross-arch DTSI is "kernel/dts/". >> This directory can be hidden from C sources. > > I suppose, I don't really mind and will follow the direction of the other > DTB maintainers. It doesn't seem like a big deal to me. Seems fine to me. We might think of other things to put here that are not includes. Overlays perhaps? > >> >@@ -223,7 +223,7 @@ Example of a VE tile description (simplified) >> > /* Active high IRQ 0 is connected to GIC's SPI0 */ >> > interrupt-map = <0 0 0 &gic 0 0 4>; >> > >> > - /include/ "vexpress-v2m-rs1.dtsi" >> > + #include >> > }; >> > }; >> >> >> >> You do not have to replace /include/ with #include, >> if you add the include path for DTC. > > Ah, I looked for this but -i is not documented in the man page. > > Is there any reason to prefer one over the other? Yes, so you don't force the use of the C preprocessor. 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 03/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 29/07/15 17:08, nick wrote: > > > On 2015-07-29 09:52 AM, Roger Quadros wrote: >> On 29/07/15 15:13, nick wrote: >>> >>> >>> On 2015-07-29 08:06 AM, Roger Quadros wrote: Tony, On 13/07/15 15:40, Tony Lindgren wrote: > * Roger Quadros [150713 03:07]: >> Tony, >> >> On 13/07/15 10:10, Tony Lindgren wrote: >>> * Roger Quadros [150710 05:26]: Since the Interrupt Events are used only by the NAND driver, there is no point in managing the Interrupt registers in the GPMC driver and complicating it with irqchip modeling. >>> >>> I don't think it's a good idea to allow external drivers to >>> tinker directly with GPMC registers. How about just set up GPMC >>> as an irqchip for the edge detection interrupts? >>> >>> I think we already have devices with multiple NAND chips. And >>> there's nothing stopping other drivers from using the edge >>> detection interrupts. >> >> OK. The GPMC_IRQ registers manage 2 NAND specific interrupts >> (terminalcount and fifo) and 'n' WAIT pin edge interrupts. >> >> So we can model this as a irqchip with 'n + 2' interrupts. > > OK For the wait pins irqchip is not sufficient and it needs to be gpiochip with irqchip. Waitpin status can be read from GPIO_STATUS register. Just getting the interrupt is not enough and we want to know if the line is high or low. That is how nand->dev_ready works. How about having 2 IRQ domains? One is irqchip with 2 interrupts (terminalcount and fifo) and second is gpiochip + irqchip for the n wait pins. The nand driver can then be modified to use GPIO to get Read/Busy pin status from the wait pin. cheers, -roger >>> Doesn't OMAP boards support shared IRQs and if so why not share them across >>> one >>> IRQ domain if possible to save IRQ domains for other hardware that needs >>> its >>> own IRQ domain. This is just a suggestion through as I don't have the >>> hardware >>> spec sheet on me Roger. >> >> IRQ domain is a virtual abstraction introduced to prevent kernel irq number >> overlapping >> in a single flat domain. I don't see what you can save by domain reuse. >> Some memory maybe at most. >> >> Shared interrupt is something totally different but we're trying to add real >> hardware interrupts here. Didn't understand what you will share it with. >> >> cheers, >> -roger >> > My question then is do these hardware interrupts need to be on their own > interrupt line > for the CPU or can they share a CPU line as my concern is if possible we may > be able to > save a interrupt line for other use. I known on Intel CPUs this is a very > limited resource > but not sure on OMAP based boards if not then just avoid my recommendations. It is like adding an external interrupt controller to expand the number of available hardware interrupts. This interrupt controller will still use the same GPMC IRQ line to propagate the irq event upwards. cheers, -roger > Nick >>> Nick > >> We need to take care that if a GPMC chip select needs a >> wait pin then it can't be used as a generic interrupt. >> >> We need to get rid of omap_dev_ready() in nand/omap2.c as >> it accesses the GPMC_STATUS register directly. Plus it is >> hard coded to only monitor wait0 pin. > > OK > >> What is the best map we should use for irqchip? >> Some Socs have 4 WAIT pins, some have 3 and some have 2. >> >> Should we start with 0,1,2, for the wait pins and use the next >> available free one for the NAND? > > Maybe we can just use the bits defined for each SoC in the > GPMC_IRQSTATUS register for the mapping? > Regards, > > Tony > __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- 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 v4 4/5] tty/serial: at91: add support to FIFOs
Hi Andy, On 29/07/2015 at 17:51:38 +0300, Andy Shevchenko wrote : > On Thu, Jul 2, 2015 at 4:18 PM, Cyrille Pitchen > wrote: > > Depending on the hardware, TX and RX FIFOs may be available. The RX > > FIFO can avoid receive overruns, especially when DMA transfers are > > not used to read data from the Receive Holding Register. For heavy > > system load, The CPU is likely not be able to fetch data fast enough > > from the RHR. > > This patch broke avr32 console (as seen in today's linux-next) on ATNGW100. > Reverting helps. I'm pretty sure the issue is in 8 bit vs. 32 bit I/O access. > > # uname -a > Linux buildroot 4.2.0-rc4-next-20150729+ #97 Wed Jul 29 17:50:11 EEST > 2015 avr32 GNU/Linux > > Do you, guys, have that board (NGW100) or it's officially unsupported? > If the latter is the case I would really appreciate if you remove the > support from the kernel side. > The main issue here is that the main atmel arm developers don't have access to any avr32 board. I'd say that everything that is done is best effort to not break avr32 but it is not tested at all. Don't hesitate to submit patches when something breaks... -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 v8 00/23] usb gadget update for OTG 2.0
On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote: > On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote: > > Change for v8: > > - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for patch > > 07, 21~23. > > - Add ci->is_otg condition before enable ci->gadget.is_otg for chipidea > > driver in patch 8. > > > > Hi Felipe, > > For chipidea patches in this series, help to queue them in your tree > please, thanks. all there, please make sure they're correct. There were so many versions of this series that I might have picked up the wrong one :-p cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 4/5] tty/serial: at91: add support to FIFOs
On Thu, Jul 2, 2015 at 4:18 PM, Cyrille Pitchen
wrote:
> Depending on the hardware, TX and RX FIFOs may be available. The RX
> FIFO can avoid receive overruns, especially when DMA transfers are
> not used to read data from the Receive Holding Register. For heavy
> system load, The CPU is likely not be able to fetch data fast enough
> from the RHR.
This patch broke avr32 console (as seen in today's linux-next) on ATNGW100.
Reverting helps. I'm pretty sure the issue is in 8 bit vs. 32 bit I/O access.
# uname -a
Linux buildroot 4.2.0-rc4-next-20150729+ #97 Wed Jul 29 17:50:11 EEST
2015 avr32 GNU/Linux
Do you, guys, have that board (NGW100) or it's officially unsupported?
If the latter is the case I would really appreciate if you remove the
support from the kernel side.
>
> In addition, the RX FIFO can supersede the DMA/PDC to control the RTS
> line when the Hardware Handshaking mode is enabled. Two thresholds
> are to be set for that purpose:
> - When the number of data in the RX FIFO crosses and becomes lower
> than or equal to the low threshold, the RTS line is set to low
> level: the remote peer is requested to send data.
> - When the number of data in the RX FIFO crosses and becomes greater
> than or equal to the high threshold, the RTS line is set to high
> level: the remote peer should stop sending new data.
> - low threshold <= high threshold
> Once these two thresholds are set properly, this new feature is
> enabled by setting the FIFO RTS Control bit of the FIFO Mode Register.
>
> FIFOs also introduce a new multiple data mode: the USART works either
> in multiple data mode or in single data (legacy) mode.
>
> If MODE9 bit is set into the Mode Register or if USMODE is set to
> either LIN_MASTER, LIN_SLAVE or LON_MODE, FIFOs operate in single
> data mode. Otherwise, they operate in multiple data mode.
>
> In this new multiple data mode, accesses to the Receive Holding
> Register or Transmit Holding Register slightly change.
>
> Since this driver implements neither the 9bit data feature (MODE9 bit
> set into the Mode Register) nor LIN modes, the USART works in
> multiple data mode whenever FIFOs are available and enabled. We also
> assume that data are 8bit wide.
>
> In single data mode, 32bit access CAN be used to read a single data
> from RHR or write a single data into THR.
> However in multiple data mode, a 32bit access to RHR now allows us to
> read four consecutive data from RX FIFO. Also a 32bit access to THR
> now allows to write four consecutive data into TX FIFO. So we MUST
> use 8bit access whenever only one data have to be read/written at a
> time.
>
> Signed-off-by: Cyrille Pitchen
> ---
> drivers/tty/serial/atmel_serial.c | 100
> +++---
> include/linux/atmel_serial.h | 36 ++
> 2 files changed, 130 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index e7c337de31d1..87de21f0c7a3 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -56,6 +56,15 @@
> /* Revisit: We should calculate this based on the actual port settings */
> #define PDC_RX_TIMEOUT (3 * 10)/* 3 bytes */
>
> +/* The minium number of data FIFOs should be able to contain */
> +#define ATMEL_MIN_FIFO_SIZE8
> +/*
> + * These two offsets are substracted from the RX FIFO size to define the RTS
> + * high and low thresholds
> + */
> +#define ATMEL_RTS_HIGH_OFFSET 16
> +#define ATMEL_RTS_LOW_OFFSET 20
> +
> #if defined(CONFIG_SERIAL_ATMEL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> #define SUPPORT_SYSRQ
> #endif
> @@ -141,6 +150,9 @@ struct atmel_uart_port {
> struct mctrl_gpios *gpios;
> int gpio_irq[UART_GPIO_MAX];
> unsigned inttx_done_mask;
> + u32 fifo_size;
> + u32 rts_high;
> + u32 rts_low;
> boolms_irq_enabled;
> boolis_usart; /* usart or uart */
> struct timer_list uart_timer; /* uart timer */
> @@ -191,6 +203,16 @@ static inline void atmel_uart_writel(struct uart_port
> *port, u32 reg, u32 value)
> __raw_writel(value, port->membase + reg);
> }
>
> +static inline u8 atmel_uart_readb(struct uart_port *port, u32 reg)
> +{
> + return __raw_readb(port->membase + reg);
> +}
> +
> +static inline void atmel_uart_writeb(struct uart_port *port, u32 reg, u8
> value)
> +{
> + __raw_writeb(value, port->membase + reg);
> +}
> +
> #ifdef CONFIG_SERIAL_AT
Re: [PATCH v2] dtb: Create a common home for cross-architecture dtsi files.
On Wed, 2015-07-29 at 14:27 +0100, Mark Rutland wrote: > On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote: > > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote: > > > Hi Ian, > > > > > > > > > 2015-07-27 19:35 GMT+09:00 Ian Campbell : > > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 > > > > on > > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which > > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a > > > > .dtsi supplied by arch/arm. > > > > > > > > Unfortunately this causes some issues for the split device tree > > > > repository[0], since things get moved around there. In that context > > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts > > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi. > > > > > > > > The sharing of the .dtsi is legitimate since the baseboard is the > > > > same > > > > for various vexpress systems whatever processor they use. > > > > > > > > Rather than using ../../ tricks to pickup .dtsi files from another > > > > arch this patch creates a new directory include/dt-dtsi as a > > > > home for such cross-arch .dtsi files, arranges for it to be in the > > > > include path when the .dts files are processed by cpp and switches > > > > the > > > > > > > > > "include/dt-dtsi/" can be referenced from normal C sources. > > > > > > I think another possible home for cross-arch DTSI is "kernel/dts/". > > > This directory can be hidden from C sources. > > > > I suppose, I don't really mind and will follow the direction of the > > other > > DTB maintainers. It doesn't seem like a big deal to me. > > I don't really have a preference either way. I'm inclined to leave it, "visible to C sources" doesn't seem like that much of an issue and IMHO the cure (kernel/dts/...) is worse than the disease. @@ -223,7 +223,7 @@ Example of a VE tile description (simplified) > > > > /* Active high IRQ 0 is connected to GIC's SPI0 */ > > > > interrupt-map = <0 0 0 &gic 0 0 4>; > > > > > > > > - /include/ "vexpress-v2m-rs1.dtsi" > > > > + #include > > > > }; > > > > }; > > > > > > > > > > > > You do not have to replace /include/ with #include, > > > if you add the include path for DTC. > > > > Ah, I looked for this but -i is not documented in the man page. > > > > Is there any reason to prefer one over the other? > > #include allows you to use CPP in the file you're including, /include/ > does not. > > I would imagine we have to use #include in case the dtsi itself has > #include statements... If it did, yes. I don't think vexpress-v2m-rs1.dtsi does, since it is using /include/ today. I'm inclined to switch back to /include/ unless someone objects. > > > Please add include path for DTC too > > > so that both /include/ and #include are available. > > ... though that does not preclude adding it to the path for /include/. Indeed, I've done that locally already. Ian. -- 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] dmaengine: xgene-dma: Add ACPI support for X-Gene DMA engine driver
On Tuesday 21 July 2015 18:44:39 Rameshwar Prasad Sahu wrote: > This patch adds ACPI support for the APM X-Gene DMA engine driver. > > Signed-off-by: Rameshwar Prasad Sahu > How does a slave driver refer to a channel in case of ACPI? Arnd -- 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 2/3] edac: Add L3/SoC support to the APM X-Gene SoC EDAC driver
On Sat, Jul 25, 2015 at 01:07:42AM -0600, Loc Ho wrote:
> This patch adds EDAC support for the L3 and SoC components.
>
> Signed-off-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c | 804
> +
> 1 files changed, 804 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
> index ba06904..ed99f85 100644
> --- a/drivers/edac/xgene_edac.c
> +++ b/drivers/edac/xgene_edac.c
> @@ -66,6 +66,8 @@ struct xgene_edac {
>
> struct list_headmcus;
> struct list_headpmds;
> + struct list_headl3s;
> + struct list_headsocs;
>
> struct mutexmc_lock;
> int mc_active_mask;
> @@ -1016,10 +1018,783 @@ static int xgene_edac_pmd_remove(struct
> xgene_edac_pmd_ctx *pmd)
> return 0;
> }
>
> +/* L3 Error device */
> +#define L3C_ESR (0x0A * 4)
> +#define L3C_ESR_DATATAG_MASKBIT(9)
> +#define L3C_ESR_MULTIHIT_MASK BIT(8)
> +#define L3C_ESR_UCEVICT_MASKBIT(6)
> +#define L3C_ESR_MULTIUCERR_MASK BIT(5)
> +#define L3C_ESR_MULTICERR_MASK BIT(4)
> +#define L3C_ESR_UCERR_MASK BIT(3)
> +#define L3C_ESR_CERR_MASK BIT(2)
> +#define L3C_ESR_UCERRINTR_MASK BIT(1)
> +#define L3C_ESR_CERRINTR_MASK BIT(0)
> +#define L3C_ECR (0x0B * 4)
> +#define L3C_ECR_UCINTRENBIT(3)
> +#define L3C_ECR_CINTREN BIT(2)
> +#define L3C_UCERREN BIT(1)
> +#define L3C_CERREN BIT(0)
> +#define L3C_ELR (0x0C * 4)
> +#define L3C_ELR_ERRSYN(src) ((src & 0xFF80) >> 23)
> +#define L3C_ELR_ERRWAY(src) ((src & 0x007E) >> 17)
> +#define L3C_ELR_AGENTID(src)((src & 0x0001E000) >> 13)
> +#define L3C_ELR_ERRGRP(src) ((src & 0x0F00) >> 8)
> +#define L3C_ELR_OPTYPE(src) ((src & 0x00F0) >> 4)
> +#define L3C_ELR_PADDRHIGH(src) (src & 0x000F)
> +#define L3C_AELR (0x0D * 4)
> +#define L3C_BELR (0x0E * 4)
> +#define L3C_BELR_BANK(src) (src & 0x000F)
> +
> +struct xgene_edac_dev_ctx {
> + struct list_headnext;
> + struct device ddev;
> + char*name;
> + struct xgene_edac *edac;
> + struct edac_device_ctl_info *edac_dev;
> + int edac_idx;
> + void __iomem*dev_csr;
> + int version;
> +};
> +
> +static void xgene_edac_l3_check(struct edac_device_ctl_info *edac_dev)
> +{
> + struct xgene_edac_dev_ctx *ctx = edac_dev->pvt_info;
> + u32 l3cesr;
> + u32 l3celr;
> + u32 l3caelr;
> + u32 l3cbelr;
> +
> + l3cesr = readl(ctx->dev_csr + L3C_ESR);
> + if (!(l3cesr & (L3C_ESR_UCERR_MASK | L3C_ESR_CERR_MASK)))
> + return;
> +
> + if (l3cesr & L3C_ESR_UCERR_MASK)
> + dev_err(edac_dev->dev, "L3C uncorrectable error\n");
> + if (l3cesr & L3C_ESR_CERR_MASK)
> + dev_warn(edac_dev->dev, "L3C correctable error\n");
> +
> + l3celr = readl(ctx->dev_csr + L3C_ELR);
> + l3caelr = readl(ctx->dev_csr + L3C_AELR);
> + l3cbelr = readl(ctx->dev_csr + L3C_BELR);
> + if (l3cesr & L3C_ESR_MULTIHIT_MASK)
> + dev_err(edac_dev->dev, "L3C multiple hit error\n");
> + if (l3cesr & L3C_ESR_UCEVICT_MASK)
> + dev_err(edac_dev->dev,
> + "L3C dropped eviction of line with error\n");
> + if (l3cesr & L3C_ESR_MULTIUCERR_MASK)
> + dev_err(edac_dev->dev, "L3C multiple uncorrectable error\n");
> + if (l3cesr & L3C_ESR_DATATAG_MASK)
> + dev_err(edac_dev->dev,
> + "L3C data error syndrome 0x%X group 0x%X\n",
> + L3C_ELR_ERRSYN(l3celr), L3C_ELR_ERRGRP(l3celr));
> + else
> + dev_err(edac_dev->dev,
> + "L3C tag error syndrome 0x%X Way of Tag 0x%X Agent ID
> 0x%X Operation type 0x%X\n",
> + L3C_ELR_ERRSYN(l3celr), L3C_ELR_ERRWAY(l3celr),
> + L3C_ELR_AGENTID(l3celr), L3C_ELR_OPTYPE(l3celr));
> + /*
> + * NOTE: Address [41:38] in L3C_ELR_PADDRHIGH(l3celr).
> + * Address [37:6] in l3caelr. Lower 6 bits are zero.
> + */
> + dev_err(edac_dev->dev, "L3C error address 0x%08X.%08X bank %d\n",
> + L3C_ELR_PADDRHIGH(l3celr) << 6 | (l3caelr >> 26),
> + (l3caelr & 0x3FFF) << 6, L3C_BELR_BANK(l3cbelr));
> + dev_err(edac_dev->dev,
> + "L3C error status register value 0x%X\n", l3cesr);
> +
> + /* Clear L3C error interrupt */
> + writel(0, ctx->dev_csr + L3C_ESR);
> +
> + if (ctx->version <= 1) {
> + /*
> + * Version 1 of the L3C has broken single bit c
[PATCH v2 1/3] mmc: sdhci: switch from programmable clock mode to divided one if needed
In programmable mode, if the clock frequency is too high, the divider
can be too small to meet the clock frequency requirement especially to
init the SD card. In this case, switch to the divided clock mode.
Signed-off-by: Ludovic Desroches
---
drivers/mmc/host/sdhci.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index bc14452..32cf274 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1152,6 +1152,7 @@ void sdhci_set_clock(struct sdhci_host *host, unsigned
int clock)
int real_div = div, clk_mul = 1;
u16 clk = 0;
unsigned long timeout;
+ bool switch_base_clk = false;
host->mmc->actual_clock = 0;
@@ -1189,15 +1190,25 @@ void sdhci_set_clock(struct sdhci_host *host, unsigned
int clock)
<= clock)
break;
}
- /*
-* Set Programmable Clock Mode in the Clock
-* Control register.
-*/
- clk = SDHCI_PROG_CLOCK_MODE;
- real_div = div;
- clk_mul = host->clk_mul;
- div--;
- } else {
+ if ((host->max_clk * host->clk_mul / div) <= clock) {
+ /*
+* Set Programmable Clock Mode in the Clock
+* Control register.
+*/
+ clk = SDHCI_PROG_CLOCK_MODE;
+ real_div = div;
+ clk_mul = host->clk_mul;
+ div--;
+ } else {
+ /*
+* Divisor can be too small to reach clock
+* speed requirement. Then use the base clock.
+*/
+ switch_base_clk = true;
+ }
+ }
+
+ if (!host->clk_mul || switch_base_clk) {
/* Version 3.00 divisors must be a multiple of 2. */
if (host->max_clk <= clock)
div = 1;
--
2.5.0
--
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 3/3] MAINTAINERS: add entry for Atmel sdhci-of-at91 driver
Add an entry for Atmel SDMMC device. Signed-off-by: Ludovic Desroches --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e7bdbac..6480ce9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1880,6 +1880,12 @@ L: linux-...@lists.infradead.org S: Supported F: drivers/mtd/nand/atmel_nand* +ATMEL SDMMC DRIVER +M: Ludovic Desroches +L: linux-...@vger.kernel.org +S: Supported +F: drivers/mmc/host/sdhci-of-at91.c + ATMEL SPI DRIVER M: Nicolas Ferre S: Supported -- 2.5.0 -- 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] mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC
Introduce driver for he Atmel SDMMC available on sama5d2. It is a sdhci
compliant controller.
Signed-off-by: Ludovic Desroches
---
.../devicetree/bindings/mmc/sdhci-atmel.txt| 21 +++
drivers/mmc/host/Kconfig | 8 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-at91.c | 192 +
4 files changed, 222 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
create mode 100644 drivers/mmc/host/sdhci-of-at91.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
new file mode 100644
index 000..1b662d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-atmel.txt
@@ -0,0 +1,21 @@
+* Atmel SDHCI controller
+
+This file documents the differences between the core properties in
+Documentation/devicetree/bindings/mmc/mmc.txt and the properties used by the
+sdhci-of-at91 driver.
+
+Required properties:
+- compatible: Must be "atmel,sama5d2-sdhci".
+- clocks: Phandlers to the clocks.
+- clock-names: Must be "hclock", "multclk", "baseclk";
+
+
+Example:
+
+sdmmc0: sdio-host@a000 {
+ compatible = "atmel,sama5d2-sdhci";
+ reg = <0xa000 0x300>;
+ interrupts = <31 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&sdmmc0_hclk>, <&sdmmc0_gclk>, <&main>;
+ clock-names = "hclock", "multclk", "baseclk";
+};
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index fd9a58e..c1c75e8 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -129,6 +129,14 @@ config MMC_SDHCI_OF_ARASAN
If unsure, say N.
+config MMC_SDHCI_OF_AT91
+ tristate "SDHCI OF support for the Atmel SDMMC controller"
+ depends on MMC_SDHCI_PLTFM
+ depends on OF
+ select MMC_SDHCI_IO_ACCESSORS
+ help
+ This selects the Atmel SDMMC driver
+
config MMC_SDHCI_OF_ESDHC
tristate "SDHCI OF support for the Freescale eSDHC controller"
depends on MMC_SDHCI_PLTFM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e928d61..4f3452a 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
obj-$(CONFIG_MMC_SDHCI_OF_ARASAN) += sdhci-of-arasan.o
+obj-$(CONFIG_MMC_SDHCI_OF_AT91)+= sdhci-of-at91.o
obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
new file mode 100644
index 000..7a9f4b1
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -0,0 +1,192 @@
+/*
+ * Atmel SDMMC controller driver.
+ *
+ * Copyright (C) 2015 Atmel,
+ * 2015 Ludovic Desroches
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sdhci-pltfm.h"
+
+#define SDMMC_CACR 0x230
+#defineSDMMC_CACR_CAPWREN BIT(0)
+#defineSDMMC_CACR_KEY (0x46 << 8)
+
+struct sdhci_at91_priv {
+ struct clk *hclock;
+ struct clk *gck;
+ struct clk *mainck;
+};
+
+static const struct sdhci_ops sdhci_at91_sama5d2_ops = {
+ .set_clock = sdhci_set_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+};
+
+static const struct sdhci_pltfm_data soc_data_sama5d2 = {
+ .ops = &sdhci_at91_sama5d2_ops,
+};
+
+static const struct of_device_id sdhci_at91_dt_match[] = {
+ { .compatible = "atmel,sama5d2-sdhci", .data = &soc_data_sama5d2 },
+ {}
+};
+
+static int sdhci_at91_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ const struct sdhci_pltfm_data *soc_data;
+ struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_at91_priv *priv;
+ unsigned intcaps0, caps1;
+ unsigned intclk_base, clk_mul;
+ unsigned intgck_rate, real_gck_rate;
+ int ret;
+
[PATCH v2 0/3] introduce driver for the Atmel SDMMC
Hi, This set of patches introduce a driver for the new Atmel SDMMC device avaible on SAMA5D2 SoC. There is also a resend of an old patch which has not been taken. Ulf asked for some reviews since it could impact all sdhci devices but nobody did it... This patch is not necessary for patch 2/3. It only fixes a special use case. If there are objections about it, drop it, I don't want to delay the Atmel SDMMC driver inclusion only for this patch. Changes: - from v1: - update license Ludovic Desroches (3): mmc: sdhci: switch from programmable clock mode to divided one if needed mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC MAINTAINERS: add entry for Atmel sdhci-of-at91 driver .../devicetree/bindings/mmc/sdhci-atmel.txt| 21 +++ MAINTAINERS| 6 + drivers/mmc/host/Kconfig | 8 + drivers/mmc/host/Makefile | 1 + drivers/mmc/host/sdhci-of-at91.c | 192 + drivers/mmc/host/sdhci.c | 29 +++- 6 files changed, 248 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-atmel.txt create mode 100644 drivers/mmc/host/sdhci-of-at91.c -- 2.5.0 -- 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] ARM64: zynqmp: Add eeprom memories on i2c bus
Add i2c eeprom memories on i2c bus.
Signed-off-by: Michal Simek
---
Changes in v2:
- Change eeprom max freq from 100k to 400k
---
arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index c5cc8dbd0968..3b1011169756 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -50,6 +50,24 @@
status = "okay";
};
+&i2c0 {
+ status = "okay";
+ clock-frequency = <40>;
+ eeprom@54 {
+ compatible = "at,24c64";
+ reg = <0x54>;
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <40>;
+ eeprom@55 {
+ compatible = "at,24c64";
+ reg = <0x55>;
+ };
+};
+
&sata {
status = "okay";
ceva,broken-gen2;
--
2.3.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 v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support
On 29/07/15 06:39, Archit Taneja wrote:
Hi Srini,
On 07/28/2015 06:24 PM, Srinivas Kandagatla wrote:
This patch adds LVDS panel for IFC6410.
Signed-off-by: Rob Clark
[Rob Clark: WIP patch]
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66
++
1 file changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 1ab71f1..3bdac02 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -63,6 +63,12 @@
qcom,switch-mode-frequency = <320>;
};
+pm8921_l2: l2 {
+regulator-min-microvolt = <120>;
+regulator-max-microvolt = <120>;
+bias-pull-down;
+};
+
pm8921_l3: l3 {
regulator-min-microvolt = <305>;
regulator-max-microvolt = <330>;
@@ -96,6 +102,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+pm8921_lvs7: lvs7 {
+bias-pull-down;
+};
};
};
@@ -119,6 +129,41 @@
mdp: qcom,mdp@510 {
status = "okay";
+qcom,lvds-panel = <&panel>;
We're trying to switch to the of_graph way of representing connected
panels. With that, the above phandle will go away. This needs to be
replaced with:
Thanks for the input, I modified the panel support to use graphs which
works perfectly fine.
thanks,
srini
port {
lvds_out: endpoint {
remote_endpoint = <&auo_in>;
};
};
+lvds-vccs-3p3v-supply = <&ext_3p3v>;
+lvds-pll-vdda-supply = <&pm8921_l2>;
+lvds-vdda-supply = <&pm8921_lvs7>;
+};
+
+panel_3p3v: panel_3p3v {
+compatible = "regulator-fixed";
+pinctrl-0 = <&disp_en_gpios>;
+pinctrl-names = "default";
+regulator-min-microvolt = <330>;
+regulator-max-microvolt = <330>;
+regulator-name = "panel_en_3p3v";
+regulator-type = "voltage";
+startup-delay-us = <0>;
+gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+enable-active-high;
+regulator-boot-on;
+};
+
+backlight: backlight{
+pinctrl-0 = <&pwm_bl_gpios>;
+pinctrl-names = "default";
+compatible = "gpio-backlight";
+gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+default-on;
+};
+
+panel: auo,b101xtn01 {
+status = "okay";
+compatible = "auo,b101xtn01";
+
+ddc-i2c-bus = <&i2c3>;
+backlight = <&backlight>;
+power-supply = <&panel_3p3v>;
and for the panel:
port {
auo_in: endpoint {
remote-endpoint = <&lvds_out>;
};
};
Thanks,
Archit
};
gsbi3: gsbi@1620 {
@@ -235,6 +280,27 @@
pm8921_gpio: gpio@150 {
pinctrl-names = "default";
pinctrl-0 = <&wlan_default_gpios>;
+
+pwm_bl_gpios: pwm-bl-gpios {
+pios {
+pins = "gpio26";
+bias-disable;
+function = "normal";
+qcom,drive-strength =
;
+power-source = ;
+};
+};
+
+disp_en_gpios: disp-en-gpios {
+pios {
+pins = "gpio36";
+bias-disable;
+function = "normal";
+qcom,drive-strength =
;
+power-source = ;
+};
+};
+
wlan_default_gpios: wlan-gpios {
pios {
pins = "gpio43";
--
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 v1 3/7] ARM: dts: apq8064-ifc6410: add heart-beat led support.
On 28/07/15 18:36, Andreas Färber wrote:
Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
This patch adds heart-beat led support on IFC6410.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index df560cf..1fc2ea5 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -207,6 +207,19 @@
status = "okay";
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <¬ify_led>;
+
+ led@1 {
+ label = "apq8064:green:user1";
+ gpios = <&pm8921_gpio 18 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
Can we please drop the heartbeat default? While that's nice as proof of
concept, it's annoying to deliver it that way in Linux distros. Users
can enable that trigger with a simple boot script writing to /sys.
Thanks for the input, I will change to be none, Let the users decide the
trigger.
thanks,
srini
Thanks,
Andreas
+ default-state = "on";
+ };
+ };
+
qcom,ssbi@50 {
pmicintc: pmic@0 {
pm8921_gpio: gpio@150 {
[snip]
--
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: [RFC PATCH 2/2] dt: spi: s3c64xx: add compatible to controller-data
On Wed, Jul 29, 2015 at 12:19:57PM +0200, Michal Suchanek wrote: Please use subject lines matching the style for the subsytsem so people can spot that the patch is in some way relevant. > The controller-data subnode has no compatible. This can lead to other > drivers getting confused by it. Add a compatible to make devicetreee > unambiguous. I can't tell from this commit message what the issue you're trying to fix is, sorry. Nodes without compatible strings are entirely normal and don't need compatible strings. It sounds like a bug in whatever other driver is becoming confused. > + if (!of_get_property(data_np, "compatible", NULL) || > + strcmp(of_get_property(data_np, "compatible", NULL), > +"samsung,s3c-controller-data")) > + dev_err(&spi->dev, "child node 'controller-data' does not have > correct compatible\n"); This will break all existing users which is not acceptable for mainline, we need to preserve compatibility with existing device trees. signature.asc Description: Digital signature
Re: [PATCH 2/2] DT: pwm: Add NXP LPC18xx PWM/SCT binding documentation
+devicetree guys
On 28 July 2015 at 20:22, Joachim Eastwood wrote:
> On 29 July 2015 at 00:45, Ezequiel Garcia
> wrote:
>> On 28 July 2015 at 19:37, Joachim Eastwood wrote:
>>> On 27 July 2015 at 06:45, Ariel D'Alessandro
>>> wrote:
Add the devicetree binding document for NXP LPC18xx PWM/SCT.
Signed-off-by: Ariel D'Alessandro
---
.../devicetree/bindings/pwm/lpc1850-pwm.txt | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
b/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
new file mode 100644
index 000..3055429
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
@@ -0,0 +1,20 @@
+* NXP LPC18xx Pulse Width Modulator driver
+
+Required properties:
+ - compatible: Should be "nxp,lpc1850-pwm"
+ - reg: Should contain physical base address and length of pwm registers.
+ - clocks: Must contain an entry for each entry in clock-names.
+See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries.
+- pwm: PWM operating clock.
+ - #pwm-cells: Should be 3. See pwm.txt in this directory for the
description
+of the cells format.
+
+Example:
+ pwm: pwm@4000 {
+compatible = "nxp,lpc1850-pwm";
>>>
>>> I would prefer "nxp,lpc1850-sct" for a couple of reasons. SCT is the
>>> name of hardware block as described in the user manual and while PWM
>>> is the most obvious usage for this block on Linux, the hardware is not
>>> limited to just doing that. So as a bit of future proofing if someone
>>> wants to use this block for more than PWM I would prefer SCT.
>>>
>>
>> Shouldn't we use something like "nxp,lpc1850-sct-pwm"?
>>
>> Sounds like the word PWM should be in the compatible as it describes
>> not only the device, but the device used in a certain way.
>>
>> Otherwise, how would we use "nxp,lpc1850-sct" to distinguish a PWM from
>> e.g. a clocksource/clockevents (we can also use SCT for that)?
>
> I not sure how to best handle dt bindings with such flexible hardware blocks.
>
> But are you suggestion to have multiple drivers for the same hw block?
> ie.: "nxp,lpc1850-sct-pwm" for PWM and for example
> "nxp,lpc1850-sct-clocksource" for clocksource and then use/enable one
> or the other.
>
Yup, I'm suggesting just that. If the hardware is capable, I can't see
why we can't have different drivers for it.
> So I am not sure how to best handle this, but I think we should at
> least consider more than just PWM usage for this hw block. Note that
> not against calling it "lpc1850-sct-pwm", I like that better than just
> "lpc1850-pwm".
>
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 29/07/15 15:13, nick wrote: > > > On 2015-07-29 08:06 AM, Roger Quadros wrote: >> Tony, >> >> On 13/07/15 15:40, Tony Lindgren wrote: >>> * Roger Quadros [150713 03:07]: Tony, On 13/07/15 10:10, Tony Lindgren wrote: > * Roger Quadros [150710 05:26]: >> Since the Interrupt Events are used only by the NAND driver, >> there is no point in managing the Interrupt registers >> in the GPMC driver and complicating it with irqchip modeling. > > I don't think it's a good idea to allow external drivers to > tinker directly with GPMC registers. How about just set up GPMC > as an irqchip for the edge detection interrupts? > > I think we already have devices with multiple NAND chips. And > there's nothing stopping other drivers from using the edge > detection interrupts. OK. The GPMC_IRQ registers manage 2 NAND specific interrupts (terminalcount and fifo) and 'n' WAIT pin edge interrupts. So we can model this as a irqchip with 'n + 2' interrupts. >>> >>> OK >> >> For the wait pins irqchip is not sufficient and it needs to be gpiochip >> with irqchip. Waitpin status can be read from GPIO_STATUS register. >> >> Just getting the interrupt is not enough and we want to know if the >> line is high or low. That is how nand->dev_ready works. >> >> How about having 2 IRQ domains? >> One is irqchip with 2 interrupts (terminalcount and fifo) and second is >> gpiochip + irqchip for the n wait pins. >> >> The nand driver can then be modified to use GPIO to get Read/Busy >> pin status from the wait pin. >> >> cheers, >> -roger >> > Doesn't OMAP boards support shared IRQs and if so why not share them across > one > IRQ domain if possible to save IRQ domains for other hardware that needs its > own IRQ domain. This is just a suggestion through as I don't have the hardware > spec sheet on me Roger. IRQ domain is a virtual abstraction introduced to prevent kernel irq number overlapping in a single flat domain. I don't see what you can save by domain reuse. Some memory maybe at most. Shared interrupt is something totally different but we're trying to add real hardware interrupts here. Didn't understand what you will share it with. cheers, -roger > Nick >>> We need to take care that if a GPMC chip select needs a wait pin then it can't be used as a generic interrupt. We need to get rid of omap_dev_ready() in nand/omap2.c as it accesses the GPMC_STATUS register directly. Plus it is hard coded to only monitor wait0 pin. >>> >>> OK >>> What is the best map we should use for irqchip? Some Socs have 4 WAIT pins, some have 3 and some have 2. Should we start with 0,1,2, for the wait pins and use the next available free one for the NAND? >>> >>> Maybe we can just use the bits defined for each SoC in the >>> GPMC_IRQSTATUS register for the mapping? >>> Regards, >>> >>> Tony >>> >> >> __ >> Linux MTD discussion mailing list >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ >> -- 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] dtb: Create a common home for cross-architecture dtsi files.
On Wed, Jul 29, 2015 at 02:22:54PM +0100, Ian Campbell wrote: > On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote: > > Hi Ian, > > > > > > 2015-07-27 19:35 GMT+09:00 Ian Campbell : > > > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on > > > LogicTile Express 20MG" added a new dts file to arch/arm64 which > > > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a > > > .dtsi supplied by arch/arm. > > > > > > Unfortunately this causes some issues for the split device tree > > > repository[0], since things get moved around there. In that context > > > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts > > > while the include is at src/arm/vexpress-v2m-rs1.dtsi. > > > > > > The sharing of the .dtsi is legitimate since the baseboard is the same > > > for various vexpress systems whatever processor they use. > > > > > > Rather than using ../../ tricks to pickup .dtsi files from another > > > arch this patch creates a new directory include/dt-dtsi as a > > > home for such cross-arch .dtsi files, arranges for it to be in the > > > include path when the .dts files are processed by cpp and switches the > > > > > > "include/dt-dtsi/" can be referenced from normal C sources. > > > > I think another possible home for cross-arch DTSI is "kernel/dts/". > > This directory can be hidden from C sources. > > I suppose, I don't really mind and will follow the direction of the other > DTB maintainers. It doesn't seem like a big deal to me. I don't really have a preference either way. > > >@@ -223,7 +223,7 @@ Example of a VE tile description (simplified) > > > /* Active high IRQ 0 is connected to GIC's SPI0 */ > > > interrupt-map = <0 0 0 &gic 0 0 4>; > > > > > > - /include/ "vexpress-v2m-rs1.dtsi" > > > + #include > > > }; > > > }; > > > > > > > > You do not have to replace /include/ with #include, > > if you add the include path for DTC. > > Ah, I looked for this but -i is not documented in the man page. > > Is there any reason to prefer one over the other? #include allows you to use CPP in the file you're including, /include/ does not. I would imagine we have to use #include in case the dtsi itself has #include statements... > > Please add include path for DTC too > > so that both /include/ and #include are available. ... though that does not preclude adding it to the path for /include/. Thanks, Mark. -- 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] dtb: Create a common home for cross-architecture dtsi files.
On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote:
> Hi Ian,
>
>
> 2015-07-27 19:35 GMT+09:00 Ian Campbell :
> > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> >
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> >
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> >
> > Rather than using ../../ tricks to pickup .dtsi files from another
> > arch this patch creates a new directory include/dt-dtsi as a
> > home for such cross-arch .dtsi files, arranges for it to be in the
> > include path when the .dts files are processed by cpp and switches the
>
>
> "include/dt-dtsi/" can be referenced from normal C sources.
>
> I think another possible home for cross-arch DTSI is "kernel/dts/".
> This directory can be hidden from C sources.
I suppose, I don't really mind and will follow the direction of the other
DTB maintainers. It doesn't seem like a big deal to me.
> >@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
> > /* Active high IRQ 0 is connected to GIC's SPI0 */
> > interrupt-map = <0 0 0 &gic 0 0 4>;
> >
> > - /include/ "vexpress-v2m-rs1.dtsi"
> > + #include
> > };
> > };
>
>
>
> You do not have to replace /include/ with #include,
> if you add the include path for DTC.
Ah, I looked for this but -i is not documented in the man page.
Is there any reason to prefer one over the other?
> Please add include path for DTC too
> so that both /include/ and #include are available.
OK.
I shall await further feedback on what path to use before spinning a v3.
Ian.
>
>
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 79e8661..fc6c06c 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -285,7 +285,7 @@ quiet_cmd_dtc = DTC $@
> cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ;
> \
> $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
> - -i $(dir $<) $(DTC_FLAGS) \
> + -i $(dir $<) -i $(srctree)/kernel/dts $(DTC_FLAGS) \
> -d $(depfile).dtc.tmp $(dtc-tmp) ; \
> cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
>
>
>
>
--
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 3/6] pci:host: Add Altera PCIe host controller driver
On Tue, Jul 28, 2015 at 11:45:42AM +0100, Ley Foon Tan wrote:
[...]
> +static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
> +{
> + int err, res_valid = 0;
> + struct device *dev = &pcie->pdev->dev;
> + struct device_node *np = dev->of_node;
> + resource_size_t iobase;
> + struct resource_entry *win;
> + int offset = 0;
> +
> + err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pcie->resources,
> + &iobase);
> + if (err)
> + return err;
On top of Rob's comments on ARM bios32 dependency removal (ie rewrite
the driver so that it does not use pci_common_init_dev()), if you need IO
access you have to map iobase, see pci_remap_iospace() in pci-host-generic.c
Lorenzo
> +
> + resource_list_for_each_entry(win, &pcie->resources) {
> + struct resource *parent, *res = win->res;
> +
> + switch (resource_type(res)) {
> + case IORESOURCE_MEM:
> + parent = &iomem_resource;
> + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> + cra_writel(pcie, res->start,
> + A2P_ADDR_MAP_LO0 + offset);
> + cra_writel(pcie, 0,
> + A2P_ADDR_MAP_HI0 + offset);
> + offset += ATT_ENTRY_SIZE;
> + break;
> + default:
> + continue;
> + }
> +
> + err = devm_request_resource(dev, parent, res);
> + if (err)
> + goto out_release_res;
> + }
> +
> + if (!res_valid) {
> + dev_err(dev, "non-prefetchable memory resource required\n");
> + err = -EINVAL;
> + goto out_release_res;
> + }
> +
> + return 0;
> +
> +out_release_res:
> + altera_pcie_release_of_pci_ranges(pcie);
> + return err;
> +}
> +
> +static void altera_pcie_free_irq_domain(struct altera_pcie *pcie)
> +{
> + int i;
> + u32 irq;
> +
> + for (i = 0; i < INTX_NUM; i++) {
> + irq = irq_find_mapping(pcie->irq_domain, i);
> + if (irq > 0)
> + irq_dispose_mapping(irq);
> + }
> +
> + irq_domain_remove(pcie->irq_domain);
> +}
> +
> +static int altera_pcie_init_irq_domain(struct altera_pcie *pcie)
> +{
> + struct device *dev = &pcie->pdev->dev;
> + struct device_node *node = dev->of_node;
> +
> + /* Setup INTx */
> + pcie->irq_domain = irq_domain_add_linear(node, INTX_NUM,
> + &intx_domain_ops, pcie);
> + if (!pcie->irq_domain) {
> + dev_err(dev, "Failed to get a INTx IRQ domain\n");
> + return PTR_ERR(pcie->irq_domain);
> + }
> +
> + return 0;
> +}
> +
> +static int altera_pcie_parse_dt(struct altera_pcie *pcie)
> +{
> + struct resource *cra;
> + int ret;
> + struct platform_device *pdev = pcie->pdev;
> +
> + cra = platform_get_resource_byname(pdev, IORESOURCE_MEM, "Cra");
> + pcie->cra_base = devm_ioremap_resource(&pdev->dev, cra);
> + if (IS_ERR(pcie->cra_base)) {
> + dev_err(&pdev->dev, "get Cra resource failed\n");
> + return PTR_ERR(pcie->cra_base);
> + }
> +
> + /* setup IRQ */
> + pcie->hwirq = platform_get_irq(pdev, 0);
> + if (pcie->hwirq <= 0) {
> + dev_err(&pdev->dev, "failed to get IRQ: %d\n", pcie->hwirq);
> + return -EINVAL;
> + }
> + ret = devm_request_irq(&pdev->dev, pcie->hwirq, altera_pcie_isr,
> + IRQF_SHARED, pdev->name, pcie);
> +
> + if (ret) {
> + dev_err(&pdev->dev, "failed to request irq %d\n",
> pcie->hwirq);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int altera_pcie_probe(struct platform_device *pdev)
> +{
> + struct altera_pcie *pcie;
> + int ret;
> +
> + pcie = devm_kzalloc(&pdev->dev, sizeof(*pcie), GFP_KERNEL);
> + if (!pcie)
> + return -ENOMEM;
> +
> + pcie->pdev = pdev;
> +
> + ret = altera_pcie_parse_dt(pcie);
> + if (ret) {
> + dev_err(&pdev->dev, "Parsing DT failed\n");
> + return ret;
> + }
> +
> + INIT_LIST_HEAD(&pcie->resources);
> +
> + ret = altera_pcie_parse_request_of_pci_ranges(pcie);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed add resources\n");
> + return ret;
> + }
> +
> + ret = altera_pcie_init_irq_domain(pcie);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed creating IRQ Domain\n");
> + return ret;
> + }
> +
> + pcie->root_bus_nr = -1;
> +
> + /* clear all interrupts */
> + cra_writel(pcie, P2A_INT_STS_ALL
Re: [PATCH 7/7] ARM64: zynqmp: Add eeprom memories on i2c bus
On 07/27/2015 12:01 PM, Shubhrajyoti Datta wrote:
> Hi,
>
> On Mon, Jul 27, 2015 at 3:18 PM, Michal Simek wrote:
>> Add i2c eeprom memories on i2c bus.
>>
>> Signed-off-by: Michal Simek
>> ---
>>
>> arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
>> b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
>> index 206e18eca2fb..47debdcbefbf 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
>> @@ -36,6 +36,24 @@
>> status = "okay";
>> };
>>
>> +&i2c0 {
>> + status = "okay";
>> + clock-frequency = <10>;
> If I am not wrong eeprom could work at 400k Could we make that as the speed.
I was retesting that and 400k works on this emulation platform too. I
will send v2.
Thanks,
Michal
--
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/7] dt: Add vendor prefix 'holt'
Add Holt Integrated Circuits, Inc. to the list of device tree vendor prefixes Signed-off-by: Vladimir Barinov --- Changes in version 2: - none Changes in version 3: - none Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d444757..bc64cc9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -99,6 +99,7 @@ himax Himax Technologies, Inc. hisilicon Hisilicon Limited. hitHitachi Ltd. hitex Hitex Development Tools +holt Holt Integrated Circuits, Inc. honeywell Honeywell hp Hewlett Packard i2se I2SE GmbH -- 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 4/7] iio: trigger: Add periodic polling to SYSFS trigger
Add periodic polling functionality to SYSFS trigger
Signed-off-by: Vladimir Barinov
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed typos in ABI description
.../ABI/testing/sysfs-bus-iio-trigger-sysfs| 11
drivers/iio/trigger/iio-trig-sysfs.c | 58 ++
2 files changed, 69 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
index 5235e6c..03c18eb 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
+++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
@@ -9,3 +9,14 @@ Description:
automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger.
+
+What: /sys/bus/iio/devices/triggerX/trigger_poll
+KernelVersion: 4.2.0
+Contact: linux-...@vger.kernel.org
+Description:
+ This file is provided by the iio-trig-sysfs stand-alone trigger
+ driver. Writing this file with positive value (in milliseconds)
+ will start periodic event triggering of the driver, associated
+ with this trigger. Writing this file with 0 will stop periodic
+ triggering.
+ X is the IIO index of the trigger.
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c
b/drivers/iio/trigger/iio-trig-sysfs.c
index 3dfab2b..ea79311 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -18,6 +18,8 @@
struct iio_sysfs_trig {
struct iio_trigger *trig;
struct irq_work work;
+ struct delayed_work poll_work;
+ unsigned int poll_interval; /* msec */
int id;
struct list_head l;
};
@@ -110,10 +112,63 @@ static ssize_t iio_sysfs_trigger_poll(struct device *dev,
return count;
}
+static void iio_sysfs_trigger_queue_poll_work(struct iio_sysfs_trig *trig)
+{
+ unsigned long delay;
+
+ delay = msecs_to_jiffies(trig->poll_interval);
+ if (delay >= HZ)
+ delay = round_jiffies_relative(delay);
+
+ queue_delayed_work(system_freezable_wq, &trig->poll_work, delay);
+}
+
+static void iio_sysfs_trigger_poll_work(struct work_struct *work)
+{
+ struct iio_sysfs_trig *trig = container_of(work, struct iio_sysfs_trig,
+ poll_work.work);
+
+ irq_work_queue(&trig->work);
+ iio_sysfs_trigger_queue_poll_work(trig);
+}
+
+static ssize_t iio_sysfs_trigger_get_poll(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+
+ return sprintf(buf, "%d\n", sysfs_trig->poll_interval);
+}
+
+static ssize_t iio_sysfs_trigger_set_poll(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_sysfs_trig *sysfs_trig = iio_trigger_get_drvdata(trig);
+ unsigned int interval;
+ int err;
+
+ err = kstrtouint(buf, 0, &interval);
+ if (err)
+ return err;
+
+ sysfs_trig->poll_interval = interval;
+
+ cancel_delayed_work_sync(&sysfs_trig->poll_work);
+ if (sysfs_trig->poll_interval > 0)
+ iio_sysfs_trigger_queue_poll_work(sysfs_trig);
+
+ return count;
+}
+
static DEVICE_ATTR(trigger_now, S_IWUSR, NULL, iio_sysfs_trigger_poll);
+static DEVICE_ATTR(trigger_poll, S_IRUGO | S_IWUSR, iio_sysfs_trigger_get_poll,
+ iio_sysfs_trigger_set_poll);
static struct attribute *iio_sysfs_trigger_attrs[] = {
&dev_attr_trigger_now.attr,
+ &dev_attr_trigger_poll.attr,
NULL,
};
@@ -164,6 +219,7 @@ static int iio_sysfs_trigger_probe(int id)
iio_trigger_set_drvdata(t->trig, t);
init_irq_work(&t->work, iio_sysfs_trigger_work);
+ INIT_DELAYED_WORK(&t->poll_work, iio_sysfs_trigger_poll_work);
ret = iio_trigger_register(t->trig);
if (ret)
@@ -198,6 +254,8 @@ static int iio_sysfs_trigger_remove(int id)
return -EINVAL;
}
+ cancel_delayed_work_sync(&t->poll_work);
+
iio_trigger_unregister(t->trig);
iio_trigger_free(t->trig);
--
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 5/7] iio: Support triggered events
Support triggered events.
This is useful for chips that don't have their own interrupt sources.
It allows to use generic/standalone iio triggers for those drivers.
Signed-off-by: Vladimir Barinov
---
Changes in version 2:
- initially added
Changes in version 3:
- fixed grammar in patch description
- changed license header to match "GNU Public License v2 or later"
drivers/iio/Kconfig| 6 +++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-core.c| 4 +-
drivers/iio/industrialio-trigger.c | 12 +-
drivers/iio/industrialio-triggered-event.c | 68 ++
include/linux/iio/iio.h| 1 +
include/linux/iio/triggered_event.h| 11 +
7 files changed, 99 insertions(+), 4 deletions(-)
create mode 100644 drivers/iio/industrialio-triggered-event.c
create mode 100644 include/linux/iio/triggered_event.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..8fcc92f 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -58,6 +58,12 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
+config IIO_TRIGGERED_EVENT
+ tristate
+ select IIO_TRIGGER
+ help
+ Provides helper functions for setting up triggered events.
+
source "drivers/iio/accel/Kconfig"
source "drivers/iio/adc/Kconfig"
source "drivers/iio/amplifiers/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..40dc13e 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -9,6 +9,7 @@ industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
+obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 3524b0d..54d71ea 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -948,7 +948,7 @@ static void iio_device_unregister_sysfs(struct iio_dev
*indio_dev)
static void iio_dev_release(struct device *device)
{
struct iio_dev *indio_dev = dev_to_iio_dev(device);
- if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+ if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
iio_device_unregister_sysfs(indio_dev);
@@ -1218,7 +1218,7 @@ int iio_device_register(struct iio_dev *indio_dev)
"Failed to register event set\n");
goto error_free_sysfs;
}
- if (indio_dev->modes & INDIO_BUFFER_TRIGGERED)
+ if (indio_dev->modes & (INDIO_BUFFER_TRIGGERED | INDIO_EVENT_TRIGGERED))
iio_device_register_trigger_consumer(indio_dev);
if ((indio_dev->modes & INDIO_ALL_BUFFER_MODES) &&
diff --git a/drivers/iio/industrialio-trigger.c
b/drivers/iio/industrialio-trigger.c
index d31098e..72b63e7 100644
--- a/drivers/iio/industrialio-trigger.c
+++ b/drivers/iio/industrialio-trigger.c
@@ -345,10 +345,18 @@ static ssize_t iio_trigger_write_current(struct device
*dev,
indio_dev->trig = trig;
- if (oldtrig)
+ if (oldtrig) {
+ if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+ iio_trigger_detach_poll_func(oldtrig,
+indio_dev->pollfunc);
iio_trigger_put(oldtrig);
- if (indio_dev->trig)
+ }
+ if (indio_dev->trig) {
iio_trigger_get(indio_dev->trig);
+ if (indio_dev->currentmode == INDIO_EVENT_TRIGGERED)
+ iio_trigger_attach_poll_func(indio_dev->trig,
+indio_dev->pollfunc);
+ }
return len;
}
diff --git a/drivers/iio/industrialio-triggered-event.c
b/drivers/iio/industrialio-triggered-event.c
new file mode 100644
index 000..1e5ad33
--- /dev/null
+++ b/drivers/iio/industrialio-triggered-event.c
@@ -0,0 +1,68 @@
+ /*
+ * Copyright (C) 2015 Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * iio_triggered_event_setup() - Setup pollfunc for triggered event
+ * @indio_dev: IIO device structure
+ * @pollfunc_bh: Function which will be used as pollfunc bottom half
+ * @pollfunc_th: Function which will be used as pollfunc top half
+ *
+ * This f
[PATCH v3 7/7] iio: Fix typos in ABI documentation
Fix typos in ABI documentation Signed-off-by: Vladimir Barinov --- Changes in version 3: - initially added Documentation/ABI/testing/sysfs-bus-iio | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 65bf49e..71a48b7 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -488,7 +488,7 @@ Contact:linux-...@vger.kernel.org Description: Specifies the output powerdown mode. DAC output stage is disconnected from the amplifier and - 1kohm_to_gnd: connected to ground via an 1kOhm resistor, + 1kohm_to_gnd: connected to ground via an 1kOhm resistor, 6kohm_to_gnd: connected to ground via a 6kOhm resistor, 20kohm_to_gnd: connected to ground via a 20kOhm resistor, 100kohm_to_gnd: connected to ground via an 100kOhm resistor, @@ -498,9 +498,9 @@ Description: outX_powerdown_mode_available. If Y is not present the mode is shared across all outputs. -What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available +What: /sys/.../iio:deviceX/out_voltageY_powerdown_mode_available What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available -What: /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available +What: /sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available KernelVersion: 2.6.38 Contact: linux-...@vger.kernel.org -- 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 6/7] iio: Add ABI documentation for debounce_time
Add ABI documentation for debounce_time Signed-off-by: Vladimir Barinov --- Changes in version 3: - initially added Documentation/ABI/testing/sysfs-bus-iio | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 09eac44..65bf49e 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -539,6 +539,15 @@ Description: specified and unique if the output corresponds to a single channel. +What: /sys/bus/iio/devices/iio:deviceX/debounce_time +Date: July 2015 +KernelVersion: 4.2.0 +Contact: linux-...@vger.kernel.org +Description: + Specifies number of milliseconds in which we perform hardware or + software debouncing. If value is set to 0 then debouncing is + disabled. + What: /sys/bus/iio/devices/iio:deviceX/events KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org -- 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/7] dt: Document Holt HI-8435 bindings
These bindings can be used to register Holt HI-8435 threshold detector
Signed-off-by: Vladimir Barinov
---
Changes in version 2:
- renamed file name hi-843x.txt to hi8435.txt
- removed hi-8436,hi-8436,hi-8437
- removed holt,debounce-soft field
- renamed holt,debounc-soft-delay to holt,debounce-interval
- renamed mr-gpio to reset-gpios
Changes in version 3:
- none
.../devicetree/bindings/iio/adc/hi8435.txt | 25 ++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt
b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
new file mode 100644
index 000..1d33ad0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt
@@ -0,0 +1,25 @@
+Holt Integrated Circuits HI-8435 threshold detector bindings
+
+Required properties:
+ - compatible: should be "holt,hi8435"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - holt,reset-gpios: GPIO used for controlling the reset pin
+ - holt,debounce-interval: software debounce interval in milliseconds
+
+Example:
+sensor@0 {
+ compatible = "holt,hi8435";
+ reg = <0>;
+
+ holt,reset-gpios = <&gpio6 1 0>;
+
+ holt,debounce-interval = <100>;
+
+ spi-max-frequency = <100>;
+};
--
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 1/7] iio: adc: hi8435: Holt HI-8435 threshold detector
Add Holt threshold detector driver for HI-8435 chip Signed-off-by: Vladimir Barinov --- Changes in version 2: - Added file sysfs-bus-iio-adc-hi8435 - Changed naming from "discrete ADC" to "threshold detector" - Replaced swab16p/swab32p with be16_to_cpup/be32_to_cpup - Made *_show and *_store functions static - moved out from iio buffers to iio events - removed hi8436/hi8437 chips from the driver - moved from debounce_soft_delay/enable to debounce_interval via IIO_CHAN_INFO_DEBOUNCE_TIME - added name extention "comparator" - moved threshold/hysteresis setup via generic iio event sysfs - added software mask/unmask channel events - added programming sensor outputs while in test mode via IIO_CHAN_INFO_RAW - added channels .ext_info for programming sensing mode Changes in version 3: - fixed typos - moved to match alphabetic order - fixed missed */event/* prefix in the ABI description - added missed colon in sysfs-bus-iio-adc-hi8435 file after "What" - moved in_voltageY_comparator_thresh_either_en and debounce_time to sysfs-bus-iio file - added error checking for hi8435_write[b|w] Documentation/ABI/testing/sysfs-bus-iio| 1 + Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 | 61 ++ drivers/iio/adc/Kconfig| 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/hi8435.c | 659 + 5 files changed, 742 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 create mode 100644 drivers/iio/adc/hi8435.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 70c9b1a..09eac44 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -572,6 +572,7 @@ What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_r What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_voltageY_comparator_thresh_either_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 new file mode 100644 index 000..c59d81d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 @@ -0,0 +1,61 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_raw +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Read value is a voltage threshold measurement from channel Y. + Could be either 0 if sensor voltage is lower then low voltage + threshold or 1 if sensor voltage is higher then high voltage + threshold. + Write value is a programmed sensor output while in self test + mode. Could be either 0 or 1. The programmed value will be read + back if /sys/bus/iio/devices/iio:deviceX/test_enable is set to 1. + +What: /sys/bus/iio/devices/iio:deviceX/test_enable +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Enable/disable the HI-8435 self test mode. + If enabled the in_voltageY_comparator_raw should be read back + accordingly to written value to in_voltageY_comparator_raw. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_comparator_sensing_mode +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Program sensor type for threshold detector inputs. + Could be either "GND-Open" or "Supply-Open" mode. Y is a + threshold detector input channel. Channels 0..7, 8..15, 16..23 + and 24..31 has common sensor types. + +What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_comparator_thresh_falling_value +Date: July 2015 +KernelVersion: 4.2.0 +Contact: sou...@cogentembedded.com +Description: + Channel Y low voltage threshold. If sensor input voltage goes lower then + this value then the threshold falling event is pushed. + Depending on in_voltageY_comparator_sensing_mode the low voltage threshold + is separately set for "GND-Open" and "Supply-Open" modes. + Channels 0..31 have common low threshold values, but could have different + sensing_modes. + The low voltage threshold range is
[PATCH v3 0/7] iio: adc: hi8435: Add Holt HI-8435 threshold detector
Hello, This adds the folowing: - Holt threshold detector driver for HI-8435 chip - Add Holt vendor prefix - Document HI-8435 DT bindings - Add periodic polling functionality to SYSFS trigger - Support triggered events - Add ABI documentation for debounce_time - Fix typos in sysfs-bus-iio file PDF file can be found here: http://www.holtic.com/products/3081-hi-8435.aspx Vladimir Barinov (7): [1/7] iio: adc: hi8435: Holt HI-8435 threshold detector [2/7] dt: Add vendor prefix 'holt' [3/7] dt: Document Holt HI-8435 bindings [4/7] iio: trigger: Add periodic polling to SYSFS trigger [5/7] iio: Support triggered events [6/7] iio: Add ABI documentation for debounce_time [7/7] iio: Fix typos in ABI documentation --- This patchset is against the 'kernel/git/torvalds/linux.git' repo. Documentation/ABI/testing/sysfs-bus-iio | 16 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435| 61 + Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs | 11 Documentation/devicetree/bindings/iio/adc/hi8435.txt | 25 Documentation/devicetree/bindings/vendor-prefixes.txt |1 drivers/iio/Kconfig |6 drivers/iio/Makefile |1 drivers/iio/adc/Kconfig | 11 drivers/iio/adc/Makefile |1 drivers/iio/adc/hi8435.c | 659 ++ drivers/iio/industrialio-core.c |4 drivers/iio/industrialio-trigger.c| 12 drivers/iio/industrialio-triggered-event.c| 68 + drivers/iio/trigger/iio-trig-sysfs.c | 58 + include/linux/iio/iio.h |1 include/linux/iio/triggered_event.h | 11 16 files changed, 939 insertions(+), 7 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt create mode 100644 drivers/iio/adc/hi8435.c create mode 100644 drivers/iio/industrialio-triggered-event.c create mode 100644 include/linux/iio/triggered_event.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
[PATCH] nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip
Add driver for Samsung S3FWRN5 NFC controller.
S3FWRN5 is using NCI protocol and I2C communication interface.
Signed-off-by: Robert Baldyga
---
.../devicetree/bindings/net/nfc/s3fwrn5.txt| 27 ++
MAINTAINERS| 6 +
drivers/nfc/Kconfig| 1 +
drivers/nfc/Makefile | 1 +
drivers/nfc/s3fwrn5/Kconfig| 22 +
drivers/nfc/s3fwrn5/Makefile | 11 +
drivers/nfc/s3fwrn5/core.c | 232 +
drivers/nfc/s3fwrn5/firmware.c | 522 +
drivers/nfc/s3fwrn5/firmware.h | 111 +
drivers/nfc/s3fwrn5/i2c.c | 367 +++
drivers/nfc/s3fwrn5/nci.c | 364 ++
drivers/nfc/s3fwrn5/nci.h | 101
drivers/nfc/s3fwrn5/s3fwrn5.h | 104
13 files changed, 1869 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
create mode 100644 drivers/nfc/s3fwrn5/Kconfig
create mode 100644 drivers/nfc/s3fwrn5/Makefile
create mode 100644 drivers/nfc/s3fwrn5/core.c
create mode 100644 drivers/nfc/s3fwrn5/firmware.c
create mode 100644 drivers/nfc/s3fwrn5/firmware.h
create mode 100644 drivers/nfc/s3fwrn5/i2c.c
create mode 100644 drivers/nfc/s3fwrn5/nci.c
create mode 100644 drivers/nfc/s3fwrn5/nci.h
create mode 100644 drivers/nfc/s3fwrn5/s3fwrn5.h
diff --git a/Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
b/Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
new file mode 100644
index 000..fb1e75f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nfc/s3fwrn5.txt
@@ -0,0 +1,27 @@
+* Samsung S3FWRN5 NCI NFC Controller
+
+Required properties:
+- compatible: Should be "samsung,s3fwrn5-i2c".
+- reg: address on the bus
+- interrupt-parent: phandle for the interrupt gpio controller
+- interrupts: GPIO interrupt to which the chip is connected
+- s3fwrn5,en-gpios: Output GPIO pin used for enabling/disabling the chip
+- s3fwrn5,fw-gpios: Output GPIO pin used to enter firmware mode and
+ sleep/wakeup control
+
+Example:
+
+&hsi2c_4 {
+ status = "okay";
+ s3fwrn5@27 {
+ compatible = "samsung,s3fwrn5-i2c";
+
+ reg = <0x27>;
+
+ interrupt-parent = <&gpa1>;
+ interrupts = <3 0 0>;
+
+ s3fwrn5,en-gpios = <&gpf1 4 0>;
+ s3fwrn5,fw-gpios = <&gpj0 2 0>;
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 3a4b7cb..72efe7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8586,6 +8586,12 @@ L: linux-me...@vger.kernel.org
S: Supported
F: drivers/media/i2c/s5k5baf.c
+SAMSUNG S3FWRN5 NFC DRIVER
+M: Robert Baldyga
+L: linux-...@lists.01.org (moderated for non-subscribers)
+S: Supported
+F: drivers/nfc/s3fwrn5
+
SAMSUNG SOC CLOCK DRIVERS
M: Sylwester Nawrocki
M: Tomasz Figa
diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
index 722673c..6639cd1 100644
--- a/drivers/nfc/Kconfig
+++ b/drivers/nfc/Kconfig
@@ -74,4 +74,5 @@ source "drivers/nfc/nfcmrvl/Kconfig"
source "drivers/nfc/st21nfca/Kconfig"
source "drivers/nfc/st-nci/Kconfig"
source "drivers/nfc/nxp-nci/Kconfig"
+source "drivers/nfc/s3fwrn5/Kconfig"
endmenu
diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile
index 368b6df..2757fe1 100644
--- a/drivers/nfc/Makefile
+++ b/drivers/nfc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_NFC_TRF7970A)+= trf7970a.o
obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/
obj-$(CONFIG_NFC_ST_NCI) += st-nci/
obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/
+obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/
diff --git a/drivers/nfc/s3fwrn5/Kconfig b/drivers/nfc/s3fwrn5/Kconfig
new file mode 100644
index 000..d1f62e2
--- /dev/null
+++ b/drivers/nfc/s3fwrn5/Kconfig
@@ -0,0 +1,22 @@
+config NFC_S3FWRN5
+ tristate "Samsung S3FWRN5 NFC driver"
+ depends on NFC_NCI
+ default n
+ ---help---
+ Core driver for Samsung S3FWRN5 NFC chip.
+
+ To compile this driver as a module, choose m here. The module will
+ be called s3fwrn5.ko.
+ Say N if unsure.
+
+config NFC_S3FWRN5_I2C
+ tristate "Samsung S3FWRN5 I2C support"
+ depends on NFC_S3FWRN5 && I2C
+ default y
+ ---help---
+ This module adds support for an I2C interface to the S3FWRN5 chip.
+ Select this if your platform is using the I2C bus.
+
+ To compile this driver as a module, choose m here. The module will
+ be called s3fwrn5_i2c.ko.
+ Say N if unsure.
diff --git a/drivers/nfc/s3fwrn5/Makefile b/drivers/nfc/s3fwrn5/Makefile
new file mode 100644
index 000..3381c34
--- /dev/null
+++ b/drivers/nfc/s3fwrn5/Makefile
@@ -0,0 +1,11 @@
+#
+# Makefile for Samsung S3FWRN5 NFC driver
+#
+
+s3fwrn5-objs = core.o firmware.o nci.o
+s3fwrn5_i2c-objs = i2c.o
Re: [PATCH v2 04/22] of/platform: add of_platform_device_find()
On 29 July 2015 at 13:20, Tomeu Vizoso wrote:
> On 29 July 2015 at 08:14, Tomeu Vizoso wrote:
>> On 28 July 2015 at 17:31, Rob Herring wrote:
>>> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso
>>> wrote:
On 28 July 2015 at 15:39, Rob Herring wrote:
> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
> wrote:
>> From an arbitrary node in the tree, find the enclosing node that
>> corresponds to a platform device, as registered by
>> of_platform_populate().
>>
>> This can be used to find out what device needs to be probed so the
>> dependency described by a given node is made available.
>>
>> Signed-off-by: Tomeu Vizoso
>> ---
>>
>> Changes in v2:
>> - Move the logic for finding a platform device from its firmware node to
>> of/platform.c as it's not needed for ACPI nodes.
>>
>> drivers/of/platform.c | 60
>> +
>> include/linux/of_platform.h | 1 +
>> 2 files changed, 61 insertions(+)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index ff27494cda8c..89c5cd513027 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -501,6 +501,66 @@ void of_platform_depopulate(struct device *parent)
>> }
>> EXPORT_SYMBOL_GPL(of_platform_depopulate);
>>
>> +static bool of_is_platform(struct device_node *np)
>> +{
>> + int count;
>> +
>> + count = of_property_count_strings(np, "compatible");
>> +
>> + /* The node has to have a compatible string */
>> + if (!count)
>> + return false;
>> +
>> + /* But it cannot be just a simple memory-mapped bus */
>> + if (count == 1 && of_match_node(of_default_bus_match_table, np))
>> + return false;
>> +
>> + /* But AMBA devices aren't platform devices */
>> + if (of_device_is_compatible(np, "arm,primecell"))
>> + return false;
>> +
>> + /* Node is immediately below root */
>> + if (!np->parent || !np->parent->parent)
>> + return true;
>> +
>> + /* If it's a node in a simple memory-mapped bus */
>> + if (of_match_node(of_default_bus_match_table, np->parent))
>> + return true;
>
> This seems really fragile.
I think this finding logic matches the logic for registering platform
devices in of_platform_populate and also what is documented in
Documentation/devicetree/usage-model.txt.
>>>
>>> Right. So now we have that logic in 2 places. One is descending from
>>> the root and one is walking up from the child. That's an opportunity
>>> for some mismatch.
>>
>> Definitely.
>>
> What about platform devices which are
> children of MFDs but are not "simple-mfd"?
This code should deal fine with those (the boards I tested with do
have them). It probes the mfd master, and that in turn will call
mfd_add_devices causing the target device to be probed.
>>>
>>> I don't see how this function would ever return true in this case
>>> unless you put the MFD at the root level. The only other way to return
>>> true is matching on of_default_bus_match_table for the parent (i.e.
>>> the MFD).
>>
>> Oops, you are right.
>>
> Does of_find_device_by_node not work for you?
Well, the dependencies aren't always platform devices, that's why I
need to go up the tree until I find a node that corresponds to a
platform device that I can query and probe.
If I had a way to get, say, a i2c device from its fwnode then I would
just need to make sure that a device's parent is probed before probing
it and everything would be cleaner in the OF case.
>>>
>>> If you have the struct device from the device_node, then you should be
>>> able to do this, right?
>>
>> Yes, if I could go back from the device_node to the struct device that
>> was registered from it, for all buses, then all this would be much
>> simpler and more robust. It would basically work like in the ACPI
>> case.
>>
>> I will play with this idea.
>>
> That is probably not the
> most efficient search, but we could fix that. We could add struct
> device ptr to struct device_node and check without searching for
> example.
That would be great, but I thought there was an issue with a OF node
being able to be related to more than one struct device (but I haven't
found this myself yet).
>>>
>>> I think it pretty much should be one to one. I'm not aware of any
>>> examples where that is not the case. This function would already be
>>> broken if you could have more than one struct device.
>>
>> Well, for platform devices we currently know that there can only be
>> one struct device for a given device_node, but that's not so clear for
>> other devices.
>
> Just found this case:
>
> http://lxr.free
Re: [PATCH 01/17] mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc
On 07/29/2015 02:09 PM, Kishon Vijay Abraham I wrote:
> Since vmmc can be optional for some platforms, use
> devm_regulator_get_optional() for vmmc. Now return error only
> in the case of -EPROBE_DEFER and for all other cases set
> host->vcc to NULL.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/mmc/host/omap_hsmmc.c |8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 4d12032..b673e59 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -344,11 +344,13 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
> *host)
> struct regulator *reg;
> int ocr_value = 0;
>
> - reg = devm_regulator_get(host->dev, "vmmc");
> + reg = devm_regulator_get_optional(host->dev, "vmmc");
> if (IS_ERR(reg)) {
> - dev_err(host->dev, "unable to get vmmc regulator %ld\n",
> + if (PTR_ERR(reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + host->vcc = NULL;
> + dev_dbg(host->dev, "unable to get vmmc regulator %ld\n",
> PTR_ERR(reg));
> - return PTR_ERR(reg);
I think, It could be unsafe to just drop this return.
regulator_get_optional may return:
1 valid pointer on regulator : success;
2 ERR_PTR(-ENODEV) : regulator is not assigned, can proceed.
3 ERR_PTR(-EPROBE_DEFER) : regulator is assigned, but not ready yet, retry.
4 ERR_PTR(: regulator is assigned, but can't be retrieved,
failure, can't proceed
So, It's allowed to continue with host->vcc = NULL; only in case [2], while
in case [4] probe should fail.
> } else {
> host->vcc = reg;
> ocr_value = mmc_regulator_get_ocrmask(reg);
>
--
regards,
-grygorii
--
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/12] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
Tony, On 13/07/15 15:40, Tony Lindgren wrote: > * Roger Quadros [150713 03:07]: >> Tony, >> >> On 13/07/15 10:10, Tony Lindgren wrote: >>> * Roger Quadros [150710 05:26]: Since the Interrupt Events are used only by the NAND driver, there is no point in managing the Interrupt registers in the GPMC driver and complicating it with irqchip modeling. >>> >>> I don't think it's a good idea to allow external drivers to >>> tinker directly with GPMC registers. How about just set up GPMC >>> as an irqchip for the edge detection interrupts? >>> >>> I think we already have devices with multiple NAND chips. And >>> there's nothing stopping other drivers from using the edge >>> detection interrupts. >> >> OK. The GPMC_IRQ registers manage 2 NAND specific interrupts >> (terminalcount and fifo) and 'n' WAIT pin edge interrupts. >> >> So we can model this as a irqchip with 'n + 2' interrupts. > > OK For the wait pins irqchip is not sufficient and it needs to be gpiochip with irqchip. Waitpin status can be read from GPIO_STATUS register. Just getting the interrupt is not enough and we want to know if the line is high or low. That is how nand->dev_ready works. How about having 2 IRQ domains? One is irqchip with 2 interrupts (terminalcount and fifo) and second is gpiochip + irqchip for the n wait pins. The nand driver can then be modified to use GPIO to get Read/Busy pin status from the wait pin. cheers, -roger > >> We need to take care that if a GPMC chip select needs a >> wait pin then it can't be used as a generic interrupt. >> >> We need to get rid of omap_dev_ready() in nand/omap2.c as >> it accesses the GPMC_STATUS register directly. Plus it is >> hard coded to only monitor wait0 pin. > > OK > >> What is the best map we should use for irqchip? >> Some Socs have 4 WAIT pins, some have 3 and some have 2. >> >> Should we start with 0,1,2, for the wait pins and use the next >> available free one for the NAND? > > Maybe we can just use the bits defined for each SoC in the > GPMC_IRQSTATUS register for the mapping? > Regards, > > Tony > -- 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/RFC 0/3] of/overlay: Update aliases when added or removed
Hi Geert, Hi Grant, On 30 Jun 2015 Grant Likely wroke > Looks good to me. I've made comments on patch 3. Also, you'll need to include > unittests before I can merge it. > [...] >> - Should the OF core handle this itself, by registering a notifier >> using of_reconfig_notifier_register()? >Yes. Let's not add new hooks. Any news on this? Were the patches applied to any public tree or are there follow-up patches that address the issue using of_reconfig_notifier_register? I'm off-list, please CC me. Regards, Robert -- 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 04/22] of/platform: add of_platform_device_find()
On 29 July 2015 at 08:14, Tomeu Vizoso wrote:
> On 28 July 2015 at 17:31, Rob Herring wrote:
>> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso
>> wrote:
>>> On 28 July 2015 at 15:39, Rob Herring wrote:
On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
wrote:
> From an arbitrary node in the tree, find the enclosing node that
> corresponds to a platform device, as registered by
> of_platform_populate().
>
> This can be used to find out what device needs to be probed so the
> dependency described by a given node is made available.
>
> Signed-off-by: Tomeu Vizoso
> ---
>
> Changes in v2:
> - Move the logic for finding a platform device from its firmware node to
> of/platform.c as it's not needed for ACPI nodes.
>
> drivers/of/platform.c | 60
> +
> include/linux/of_platform.h | 1 +
> 2 files changed, 61 insertions(+)
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index ff27494cda8c..89c5cd513027 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -501,6 +501,66 @@ void of_platform_depopulate(struct device *parent)
> }
> EXPORT_SYMBOL_GPL(of_platform_depopulate);
>
> +static bool of_is_platform(struct device_node *np)
> +{
> + int count;
> +
> + count = of_property_count_strings(np, "compatible");
> +
> + /* The node has to have a compatible string */
> + if (!count)
> + return false;
> +
> + /* But it cannot be just a simple memory-mapped bus */
> + if (count == 1 && of_match_node(of_default_bus_match_table, np))
> + return false;
> +
> + /* But AMBA devices aren't platform devices */
> + if (of_device_is_compatible(np, "arm,primecell"))
> + return false;
> +
> + /* Node is immediately below root */
> + if (!np->parent || !np->parent->parent)
> + return true;
> +
> + /* If it's a node in a simple memory-mapped bus */
> + if (of_match_node(of_default_bus_match_table, np->parent))
> + return true;
This seems really fragile.
>>>
>>> I think this finding logic matches the logic for registering platform
>>> devices in of_platform_populate and also what is documented in
>>> Documentation/devicetree/usage-model.txt.
>>
>> Right. So now we have that logic in 2 places. One is descending from
>> the root and one is walking up from the child. That's an opportunity
>> for some mismatch.
>
> Definitely.
>
What about platform devices which are
children of MFDs but are not "simple-mfd"?
>>>
>>> This code should deal fine with those (the boards I tested with do
>>> have them). It probes the mfd master, and that in turn will call
>>> mfd_add_devices causing the target device to be probed.
>>
>> I don't see how this function would ever return true in this case
>> unless you put the MFD at the root level. The only other way to return
>> true is matching on of_default_bus_match_table for the parent (i.e.
>> the MFD).
>
> Oops, you are right.
>
Does of_find_device_by_node not work for you?
>>>
>>> Well, the dependencies aren't always platform devices, that's why I
>>> need to go up the tree until I find a node that corresponds to a
>>> platform device that I can query and probe.
>>>
>>> If I had a way to get, say, a i2c device from its fwnode then I would
>>> just need to make sure that a device's parent is probed before probing
>>> it and everything would be cleaner in the OF case.
>>
>> If you have the struct device from the device_node, then you should be
>> able to do this, right?
>
> Yes, if I could go back from the device_node to the struct device that
> was registered from it, for all buses, then all this would be much
> simpler and more robust. It would basically work like in the ACPI
> case.
>
> I will play with this idea.
>
That is probably not the
most efficient search, but we could fix that. We could add struct
device ptr to struct device_node and check without searching for
example.
>>>
>>> That would be great, but I thought there was an issue with a OF node
>>> being able to be related to more than one struct device (but I haven't
>>> found this myself yet).
>>
>> I think it pretty much should be one to one. I'm not aware of any
>> examples where that is not the case. This function would already be
>> broken if you could have more than one struct device.
>
> Well, for platform devices we currently know that there can only be
> one struct device for a given device_node, but that's not so clear for
> other devices.
Just found this case:
http://lxr.free-electrons.com/source/drivers/spi/spi-tegra114.c#L1124
Looks like SPI master devices point to the same device_node as the
platform device that registers them.
Regards,
Tomeu
[PATCH 04/17] mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator
If the vmmc regulator provides a valid ocrmask, use it. By this even if
the pdata has a valid ocrmask, it will be overwritten with the ocrmask
of the vmmc regulator.
Also remove the unnecessary compatibility check between the ocrmask in
the pdata and the ocrmask from the vmmc regulator.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a78e15e..0e690d7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -352,16 +352,8 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
host->vcc = NULL;
} else {
ocr_value = mmc_regulator_get_ocrmask(host->vcc);
- if (!mmc_pdata(host)->ocr_mask) {
+ if (ocr_value > 0)
mmc_pdata(host)->ocr_mask = ocr_value;
- } else {
- if (!(mmc_pdata(host)->ocr_mask & ocr_value)) {
- dev_err(host->dev, "ocrmask %x is not
supported\n",
- mmc_pdata(host)->ocr_mask);
- mmc_pdata(host)->ocr_mask = 0;
- return -EINVAL;
- }
- }
}
mmc_pdata(host)->set_power = omap_hsmmc_set_power;
--
1.7.9.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 11/17] mmc: host: omap_hsmmc: don't use ->set_power to set initial regulator state
If the regulator is enabled on boot (checked using regulator_is_enabled),
invoke regulator_enable() so that the usecount reflects the correct
state of the regulator and then disable the regulator so that the
initial state of the regulator is disabled. Avoid using ->set_power,
since set_power also takes care of setting the voltages which is not
needed at this point.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 67 +++--
1 file changed, 57 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2e5c7cd..58bda42 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -407,9 +407,63 @@ err_set_voltage:
return ret;
}
+static int omap_hsmmc_disable_boot_regulator(struct regulator *reg)
+{
+ int ret;
+
+ if (!reg)
+ return 0;
+
+ if (regulator_is_enabled(reg)) {
+ ret = regulator_enable(reg);
+ if (ret)
+ return ret;
+
+ ret = regulator_disable(reg);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int omap_hsmmc_disable_boot_regulators(struct omap_hsmmc_host *host)
+{
+ struct mmc_host *mmc = host->mmc;
+ int ret;
+
+ /*
+* disable regulators enabled during boot and get the usecount
+* right so that regulators can be enabled/disabled by checking
+* the return value of regulator_is_enabled
+*/
+ ret = omap_hsmmc_disable_boot_regulator(mmc->supply.vmmc);
+ if (ret) {
+ dev_err(host->dev, "fail to disable boot enabled vmmc reg\n");
+ return ret;
+ }
+
+ ret = omap_hsmmc_disable_boot_regulator(mmc->supply.vqmmc);
+ if (ret) {
+ dev_err(host->dev,
+ "fail to disable boot enabled vmmc_aux reg\n");
+ return ret;
+ }
+
+ ret = omap_hsmmc_disable_boot_regulator(host->pbias);
+ if (ret) {
+ dev_err(host->dev,
+ "failed to disable boot enabled pbias reg\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
int ocr_value = 0;
+ int ret;
struct mmc_host *mmc = host->mmc;
mmc->supply.vmmc = devm_regulator_get_optional(host->dev, "vmmc");
@@ -448,17 +502,10 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
/* For eMMC do not power off when not in sleep state */
if (mmc_pdata(host)->no_regulator_off_init)
return 0;
- /*
-* To disable boot_on regulator, enable regulator
-* to increase usecount and then disable it.
-*/
- if ((mmc->supply.vmmc && regulator_is_enabled(mmc->supply.vmmc) > 0) ||
- (mmc->supply.vqmmc && regulator_is_enabled(mmc->supply.vqmmc))) {
- int vdd = ffs(mmc_pdata(host)->ocr_mask) - 1;
- mmc_pdata(host)->set_power(host->dev, 1, vdd);
- mmc_pdata(host)->set_power(host->dev, 0, 0);
- }
+ ret = omap_hsmmc_disable_boot_regulators(host);
+ if (ret)
+ return ret;
return 0;
}
--
1.7.9.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 08/17] mmc: host: omap_hsmmc: add separate functions for enable/disable supply
No functional change. Cleanup omap_hsmmc_set_power by adding separate
functions for enable/disable supply and invoke it from
omap_hsmmc_set_power.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 101 +++--
1 file changed, 66 insertions(+), 35 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d308552..a0f8c1d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -247,6 +247,65 @@ static int omap_hsmmc_get_cover_state(struct device *dev)
#ifdef CONFIG_REGULATOR
+static int omap_hsmmc_enable_supply(struct mmc_host *mmc, int vdd)
+{
+ int ret;
+
+ if (mmc->supply.vmmc) {
+ ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ if (ret)
+ return ret;
+ }
+
+ /* Enable interface voltage rail, if needed */
+ if (mmc->supply.vqmmc) {
+ ret = regulator_enable(mmc->supply.vqmmc);
+ if (ret) {
+ dev_err(mmc_dev(mmc), "vmmc_aux reg enable failed\n");
+ goto err_vqmmc;
+ }
+ }
+
+ return 0;
+
+err_vqmmc:
+ if (mmc->supply.vmmc)
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
+ return ret;
+}
+
+static int omap_hsmmc_disable_supply(struct mmc_host *mmc)
+{
+ int ret;
+ int status;
+
+ if (mmc->supply.vqmmc) {
+ ret = regulator_disable(mmc->supply.vqmmc);
+ if (ret) {
+ dev_err(mmc_dev(mmc), "vmmc_aux reg disable failed\n");
+ return ret;
+ }
+ }
+
+ if (mmc->supply.vmmc) {
+ ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+ if (ret)
+ goto err_set_ocr;
+ }
+
+ return 0;
+
+err_set_ocr:
+ if (mmc->supply.vqmmc) {
+ status = regulator_enable(mmc->supply.vqmmc);
+ if (status)
+ dev_err(mmc_dev(mmc), "vmmc_aux re-enable failed\n");
+ }
+
+ return ret;
+}
+
static int omap_hsmmc_set_power(struct device *dev, int power_on, int vdd)
{
struct omap_hsmmc_host *host =
@@ -289,36 +348,13 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- if (mmc->supply.vmmc) {
- ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
- if (ret)
- return ret;
- }
-
- /* Enable interface voltage rail, if needed */
- if (mmc->supply.vqmmc) {
- ret = regulator_enable(mmc->supply.vqmmc);
- if (ret) {
- dev_err(dev, "vmmc_aux reg enable failed\n");
- goto err_set_vqmmc;
- }
- }
+ ret = omap_hsmmc_enable_supply(mmc, vdd);
+ if (ret)
+ return ret;
} else {
- /* Shut down the rail */
- if (mmc->supply.vqmmc) {
- ret = regulator_disable(mmc->supply.vqmmc);
- if (ret) {
- dev_err(dev, "vmmc_aux reg disable failed\n");
- return ret;
- }
- }
-
- if (mmc->supply.vmmc) {
- /* Then proceed to shut down the local regulator */
- ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
- if (ret)
- return ret;
- }
+ ret = omap_hsmmc_disable_supply(mmc);
+ if (ret)
+ return ret;
}
if (host->pbias) {
@@ -348,12 +384,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
return 0;
err_set_voltage:
- if (mmc->supply.vqmmc)
- regulator_disable(mmc->supply.vqmmc);
-
-err_set_vqmmc:
- if (mmc->supply.vmmc)
- mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+ omap_hsmmc_disable_supply(mmc);
return ret;
}
--
1.7.9.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 01/17] mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc
Since vmmc can be optional for some platforms, use
devm_regulator_get_optional() for vmmc. Now return error only
in the case of -EPROBE_DEFER and for all other cases set
host->vcc to NULL.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4d12032..b673e59 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -344,11 +344,13 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
struct regulator *reg;
int ocr_value = 0;
- reg = devm_regulator_get(host->dev, "vmmc");
+ reg = devm_regulator_get_optional(host->dev, "vmmc");
if (IS_ERR(reg)) {
- dev_err(host->dev, "unable to get vmmc regulator %ld\n",
+ if (PTR_ERR(reg) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ host->vcc = NULL;
+ dev_dbg(host->dev, "unable to get vmmc regulator %ld\n",
PTR_ERR(reg));
- return PTR_ERR(reg);
} else {
host->vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
--
1.7.9.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 05/17] mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc
No functional change. Instead of using our own vcc and vcc_aux
members, use vmmc and vqmmc present in mmc_host which is present
for the same purpose.
Signed-off-by: Kishon Vijay Abraham I
Reviewed-by: Roger Quadros
---
drivers/mmc/host/omap_hsmmc.c | 63 ++---
1 file changed, 28 insertions(+), 35 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0e690d7..dad1473 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -181,15 +181,6 @@ struct omap_hsmmc_host {
struct mmc_data*data;
struct clk *fclk;
struct clk *dbclk;
- /*
-* vcc == configured supply
-* vcc_aux == optional
-* - MMC1, supply for DAT4..DAT7
-* - MMC2/MMC2, external level shifter voltage supply, for
-* chip (SDIO, eMMC, etc) or transceiver (MMC2 only)
-*/
- struct regulator *vcc;
- struct regulator *vcc_aux;
struct regulator *pbias;
boolpbias_enabled;
void__iomem *base;
@@ -260,13 +251,14 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
{
struct omap_hsmmc_host *host =
platform_get_drvdata(to_platform_device(dev));
+ struct mmc_host *mmc = host->mmc;
int ret = 0;
/*
* If we don't see a Vcc regulator, assume it's a fixed
* voltage always-on regulator.
*/
- if (!host->vcc)
+ if (!mmc->supply.vmmc)
return 0;
if (mmc_pdata(host)->before_set_reg)
@@ -295,23 +287,23 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- if (host->vcc)
- ret = mmc_regulator_set_ocr(host->mmc, host->vcc, vdd);
+ if (mmc->supply.vmmc)
+ ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
/* Enable interface voltage rail, if needed */
- if (ret == 0 && host->vcc_aux) {
- ret = regulator_enable(host->vcc_aux);
- if (ret < 0 && host->vcc)
- ret = mmc_regulator_set_ocr(host->mmc,
- host->vcc, 0);
+ if (ret == 0 && mmc->supply.vqmmc) {
+ ret = regulator_enable(mmc->supply.vqmmc);
+ if (ret < 0 && mmc->supply.vmmc)
+ ret = mmc_regulator_set_ocr(mmc,
+ mmc->supply.vmmc,
+ 0);
}
} else {
/* Shut down the rail */
- if (host->vcc_aux)
- ret = regulator_disable(host->vcc_aux);
- if (host->vcc) {
+ if (mmc->supply.vqmmc)
+ ret = regulator_disable(mmc->supply.vqmmc);
+ if (mmc->supply.vmmc) {
/* Then proceed to shut down the local regulator */
- ret = mmc_regulator_set_ocr(host->mmc,
- host->vcc, 0);
+ ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
}
}
@@ -342,29 +334,30 @@ error_set_power:
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
int ocr_value = 0;
+ struct mmc_host *mmc = host->mmc;
- host->vcc = devm_regulator_get_optional(host->dev, "vmmc");
- if (IS_ERR(host->vcc)) {
- if (PTR_ERR(host->vcc) == -EPROBE_DEFER)
+ mmc->supply.vmmc = devm_regulator_get_optional(host->dev, "vmmc");
+ if (IS_ERR(mmc->supply.vmmc)) {
+ if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_dbg(host->dev, "unable to get vmmc regulator %ld\n",
- PTR_ERR(host->vcc));
- host->vcc = NULL;
+ PTR_ERR(mmc->supply.vmmc));
+ mmc->supply.vmmc = NULL;
} else {
- ocr_value = mmc_regulator_get_ocrmask(host->vcc);
+ ocr_value = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
if (ocr_value > 0)
mmc_pdata(host)->ocr_mask = ocr_value;
}
mmc_pdata(host)->set_power = omap_hsmmc_set_power;
/* Allow an aux regulator */
- host->vcc_aux = devm_regulator_get_optional(host->dev, "vmmc_aux");
- if (IS_ERR(host->vcc_aux)) {
- if (PTR_ERR(host->vcc_aux) == -EPROBE_DEFER)
+ mmc->supply.vqmmc = devm_regulator_get_optional(host->dev, "vmmc_aux");
+ if (IS_ERR(mmc->supply.vqmmc)) {
+
[PATCH 12/17] ARM: dts: am57xx-beagle-x15: Fix regulator populated in MMC1 dt node
For beagle x15, both the vdd and io lines are connected to the same regulator (ldo1_reg). However vmmc_aux is populated to vdd_3v3. Remove it. Signed-off-by: Kishon Vijay Abraham I --- arch/arm/boot/dts/am57xx-beagle-x15.dts |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index a63bf78..d0db5c5 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -579,7 +579,6 @@ pinctrl-0 = <&mmc1_pins_default>; vmmc-supply = <&ldo1_reg>; - vmmc_aux-supply = <&vdd_3v3>; pbias-supply = <&pbias_mmc_reg>; bus-width = <4>; cd-gpios = <&gpio6 27 0>; /* gpio 219 */ -- 1.7.9.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 07/17] mmc: host: omap_hsmmc: return error if any of the regulator APIs fail
Return error if any of the regulator APIs (regulator_enable,
regulator_disable, regulator_set_voltage) fails in
omap_hsmmc_set_power to avoid undefined behavior.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/mmc/host/omap_hsmmc.c | 52 +++--
1 file changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7aee1a0..d308552 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -267,8 +267,11 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
if (host->pbias) {
if (host->pbias_enabled == 1) {
ret = regulator_disable(host->pbias);
- if (!ret)
- host->pbias_enabled = 0;
+ if (ret) {
+ dev_err(dev, "pbias reg disable failed\n");
+ return ret;
+ }
+ host->pbias_enabled = 0;
}
}
@@ -286,23 +289,35 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
* chips/cards need an interface voltage rail too.
*/
if (power_on) {
- if (mmc->supply.vmmc)
+ if (mmc->supply.vmmc) {
ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
+ if (ret)
+ return ret;
+ }
+
/* Enable interface voltage rail, if needed */
- if (ret == 0 && mmc->supply.vqmmc) {
+ if (mmc->supply.vqmmc) {
ret = regulator_enable(mmc->supply.vqmmc);
- if (ret < 0 && mmc->supply.vmmc)
- ret = mmc_regulator_set_ocr(mmc,
- mmc->supply.vmmc,
- 0);
+ if (ret) {
+ dev_err(dev, "vmmc_aux reg enable failed\n");
+ goto err_set_vqmmc;
+ }
}
} else {
/* Shut down the rail */
- if (mmc->supply.vqmmc)
+ if (mmc->supply.vqmmc) {
ret = regulator_disable(mmc->supply.vqmmc);
+ if (ret) {
+ dev_err(dev, "vmmc_aux reg disable failed\n");
+ return ret;
+ }
+ }
+
if (mmc->supply.vmmc) {
/* Then proceed to shut down the local regulator */
ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+ if (ret)
+ return ret;
}
}
@@ -314,19 +329,32 @@ static int omap_hsmmc_set_power(struct device *dev, int
power_on, int vdd)
ret = regulator_set_voltage(host->pbias, VDD_3V0,
VDD_3V0);
if (ret < 0)
- goto error_set_power;
+ goto err_set_voltage;
if (host->pbias_enabled == 0) {
ret = regulator_enable(host->pbias);
- if (!ret)
+ if (ret) {
+ dev_err(dev, "pbias reg enable failed\n");
+ goto err_set_voltage;
+ } else {
host->pbias_enabled = 1;
+ }
}
}
if (mmc_pdata(host)->after_set_reg)
mmc_pdata(host)->after_set_reg(dev, power_on, vdd);
-error_set_power:
+ return 0;
+
+err_set_voltage:
+ if (mmc->supply.vqmmc)
+ regulator_disable(mmc->supply.vqmmc);
+
+err_set_vqmmc:
+ if (mmc->supply.vmmc)
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
return ret;
}
--
1.7.9.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
