Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
On Fri, 23 Jan 2015 19:13:43 + Mark Brown wrote: > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote: > > > A card builder is a device which > > - scans the graph of ports, > > - fills the struct snd_soc_card according to the links between the > > ports and their properties, > > - and, eventually, calls snd_soc_register_card(). > > > The simple card builder, 'dt-card' (maybe a better name would have been > > 'graph-card'), acts just like the simple-card except that it does not > > appear in the DT. Its creation is done by an audio controller. > > Which audio controller? There may be several CPU side audio interfaces > in the same card. For example people often want to have both low > latency and high latency audio paths from the CPU into the hardware (low > latency tends to increase power burn). SoC centric system designs do > sometimes also have PDM I/O, expecting to be directly connected to DMICs > and so on, which results in a relatively large number of CPU interfaces. The audio controller which creates the card depends on the complexity of the card. When there are many controllers, it is up to the designer to define either a master audio controller or to instantiate a 'card' device via the DT for doing the job. > > > > With a DT graph, each CPU/CODEC would know exactly the widgets and > > > > routes it has to define. > > > > Which widgets/routes do you mean? > > > Well, forget about this. I never clearly understood why some widgets > > and routes had to be defined at card level. > > Please do try to understand the idea of representing simple components > on the board and analogue interconects between devices - it's really > important and not something that can be neglected. The problem is that this understanding would stay abstract: I have no such a hardware. Anyway, if the representation can be done with the simple-card, it may also be done with a graph of ports. > > > I'd agree if this was some kind of kernel internal stuff, but this is > > > creating ABI and we have to maintain it forever. Rushing this in without > > > proper discussion and consideration of the more complex use-cases is in > > > my > > > opinion not a good idea. > > > Using a graph of port to describe the audio subsystem has been pushed > > forwards by many people for a long time, as shown by the creation of > > the document Documentation/devicetree/bindings/graph.txt. > > That DT binding was done entirely in the context of video applications > IIRC, this is the first time it's been discussed in this context. http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] i2c: Mark instantiated device nodes with OF_POPULATE
Mark (and unmark) device nodes with the POPULATE flag as appropriate.
This is required to avoid multi probing when using I2C and device
overlays containing a mux.
This patch is also more careful with the release of the adapter device
which caused a deadlock with muxes, and does not break the build
on !OF since the node flag accessors are not defined then.
Signed-off-by: Pantelis Antoniou
---
drivers/i2c/i2c-core.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 39d25a8..8c32ee3 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1122,6 +1122,8 @@ EXPORT_SYMBOL_GPL(i2c_new_device);
*/
void i2c_unregister_device(struct i2c_client *client)
{
+ if (client->dev.of_node)
+ of_node_clear_flag(client->dev.of_node, OF_POPULATED);
device_unregister(&client->dev);
}
EXPORT_SYMBOL_GPL(i2c_unregister_device);
@@ -1441,8 +1443,11 @@ static void of_i2c_register_devices(struct i2c_adapter
*adap)
dev_dbg(&adap->dev, "of_i2c: walking child nodes\n");
- for_each_available_child_of_node(adap->dev.of_node, node)
+ for_each_available_child_of_node(adap->dev.of_node, node) {
+ if (of_node_test_and_set_flag(node, OF_POPULATED))
+ continue;
of_i2c_register_device(adap, node);
+ }
}
static int of_dev_node_match(struct device *dev, void *data)
@@ -1976,6 +1981,11 @@ static int of_i2c_notify(struct notifier_block *nb,
unsigned long action,
if (adap == NULL)
return NOTIFY_OK; /* not for us */
+ if (of_node_test_and_set_flag(rd->dn, OF_POPULATED)) {
+ put_device(&adap->dev);
+ return NOTIFY_OK;
+ }
+
client = of_i2c_register_device(adap, rd->dn);
put_device(&adap->dev);
@@ -1986,6 +1996,10 @@ static int of_i2c_notify(struct notifier_block *nb,
unsigned long action,
}
break;
case OF_RECONFIG_CHANGE_REMOVE:
+ /* already depopulated? */
+ if (!of_node_check_flag(rd->dn, OF_POPULATED))
+ return NOTIFY_OK;
+
/* find our device by node */
client = of_find_i2c_device_by_node(rd->dn);
if (client == NULL)
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Mark instantiated device nodes with OF_POPULATE
Hi Wolfram, > On Jan 24, 2015, at 06:26 , Wolfram Sang wrote: > > >> Feel free to apply it for 3.19 with my ack. You then want to pick up >> v1 of this patch. > > Sigh, I give up, this is too confusing. I don't know which one is V1, > they are not numbered in any way. And I have been holding back my pull > request for too long already. > > I'll drop this patch. Whatever should be applied should be resent, > mentioning the release it is aimed for and how the planning/dependency > on the DT patch is. > No! This is a bugfix for 3.19 :) I’m resending the original patch; the dependency is on "of: Empty node & property flag accessors when !OF” https://lkml.org/lkml/2015/1/21/602 Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: Mark instantiated device nodes with OF_POPULATE
> Feel free to apply it for 3.19 with my ack. You then want to pick up > v1 of this patch. Sigh, I give up, this is too confusing. I don't know which one is V1, they are not numbered in any way. And I have been holding back my pull request for too long already. I'll drop this patch. Whatever should be applied should be resent, mentioning the release it is aimed for and how the planning/dependency on the DT patch is. signature.asc Description: Digital signature
Re: [PATCH 3/4] clk: ti: 43xx: add debugss clocks to DT_CLK() table
On Fri, Jan 23, 2015 at 05:11:43PM -0600, Felipe Balbi wrote:
> without these entries, omap_hwmod will not be
> able to find debugss clocks.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/clk/ti/clk-43xx.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
> index 3795fce8a830..46a597c815c9 100644
> --- a/drivers/clk/ti/clk-43xx.c
> +++ b/drivers/clk/ti/clk-43xx.c
> @@ -83,6 +83,12 @@ static struct ti_dt_clk am43xx_clks[] = {
> DT_CLK(NULL, "gfx_fck_div_ck", "gfx_fck_div_ck"),
> DT_CLK(NULL, "timer_32k_ck", "clkdiv32k_ick"),
> DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
> + DT_CLK(NULL, "trace_clk_div_ck", "trace_clk_div_ck"),
> + DT_CLK(NULL, "trace_pm_clk_mux_ck", "trace_pm_clk_mux_ck"),
hmmm, this should be trace_pmd_clk_mux_ck. How did this even work ? I'll
fix and retest.
Won't resend until tomorrow though.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 00/16] ASoC: samsung: Add clk provider for I2S internal clocks
Hello, I've tested the series on my X2 and so far I haven't encountered any obvious issues with it. I have a small question though. With the move to simple-audio-card the old driver (selected by SND_SOC_ODROIDX2) is probably going away after some time. Currently SND_SOC_ODROIDX2 also selects SND_SOC_MAX98090 and SND_SAMSUNG_I2S, which I believe (correct me if I'm wrong) are necessary to use the sound subsystem even with simple-audio-card (since the max98090 codec has to be built at least). I've found no way of selecting these two manually, so at the moment I need both CONFIG_SND_SIMPLE_CARD and SND_SOC_ODROIDX2 enabled to use sound. Is this intended behaviour? And while I'm at it. I'm booting the board with an upstream u-boot version which sets the MPLL to 800MHz, which AFAIK is the clocking rate that makes less 'trouble' (but at the expense of performance). I was wondering if anyone can comment on whether the recent rework has any influence on the behaviour when booting with the vendor u-boot (which sets the MPLL to 880MHz). IIRC then clock rounding issues arose there. It would be interesting to know if this series gets us closer to drive the MPLL with the recommended (?) higher clocking rate. With best wishes, Tobias Sylwester Nawrocki wrote: > This series is an attempt to resolve the CDCLK clock gating issue on Odroid > X2/U3 as reported by Daniel Drake [1], by exposing the CDCLK gate clock > (and the two other clocks) through clk API. > > Changes since previous version: > - removed check for the i2s_opclk1 mux input clock while creating the mux >and div clocks, > - the DT binding documentation changes reworked (addressing review comments), > - added include/dt-bindings/sound/samsung-i2s.h header file defining >the clk indices, it's been put into a separate patch together with the I2S >DT binding documentation updates to make merging of the ASoC and the dts >patches separately easier, > - a patch fixing compatible strings of I2S1, I2S2 in exynos4.dtsi is included >in this series. > > This whole series may need more testing on other SoCs, so far I only tested > it on Odroid Exynos4412 X2, with the I2S working in slave mode. > > [1] > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081753.html > > Sylwester Nawrocki (16): > ASoC: samsung: i2s: Remove unused gpios field from struct i2s > ASoC: samsung: i2s: samsung_i2s_get_driver_data() cleanup > ASoC: samsung: i2s: Add return value checks in probe() > ASoC: samsung: i2s: Request memory region in driver probe() > ASoC: samsung: i2s: Move clk_get() to platform driver probe() > ASoC: samsung: i2s: Move clk enable to the platform driver probe() > ASoC: samsung: i2s: Add get_other_dai helper function > ASoC: samsung: i2s: Remove an unneeded goto usage > ASoC: samsung: i2s: Add spinlock in place of local_irq_* calls > ASoC: samsung: i2s: Protect more registers with a spinlock > ASoC: samsung: odroidx2: Handle I2S CDCLK clock conditionally > ASoC: samsung: i2s: Add clk provider DT binding documentation > ASoC: samsung: i2s: Add clock provider for the I2S internal clocks > ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update > ARM: dts: Switch Odroid X2/U2 to simple-audio-card > ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs > > .../devicetree/bindings/sound/samsung-i2s.txt | 22 ++ > arch/arm/boot/dts/exynos4.dtsi | 13 +- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 27 +- > arch/arm/boot/dts/exynos4412-odroidu3.dts |8 +- > arch/arm/boot/dts/exynos4412-odroidx2.dts |8 +- > include/dt-bindings/sound/samsung-i2s.h|8 + > sound/soc/samsung/i2s.c| 362 > > sound/soc/samsung/odroidx2_max98090.c |6 +- > 8 files changed, 295 insertions(+), 159 deletions(-) > create mode 100644 include/dt-bindings/sound/samsung-i2s.h > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
On Fri, Jan 23, 2015 at 4:54 PM, Bjorn Andersson
wrote:
> From: Courtney Cavin
>
> This adds support for the WLED ('White' LED) block on Qualcomm's
> PM8941 PMICs.
>
> Signed-off-by: Courtney Cavin
> Signed-off-by: Bjorn Andersson
> ---
Sorry, I missed the change log.
Changed since v1:
* Replace enum blob with defines
* Merged wled_context and wled structs
* Some style updates
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 12/13] ARM: dts: omap3-gta04: uart4 is not connected, so mark it "disabled"
* NeilBrown [150123 14:31]:
> On Thu, 22 Jan 2015 13:40:53 -0800 Tony Lindgren wrote:
> > >
> > > +&uart4 {
> > > + status = "disabled";
> > > +};
> > > +
> >
> > This you probably want to avoid from PM point of view. Depending on
> > bootloader state of uart4, Linux may or may not be able to hit any
> > deeper power states.
> >
> > Marking something with status = "disabled" in dts causes the device
> > entry not even to be created. That means hwmod won't be able to reset
> > and idle this device during boot.
> >
> > The uart4 device is there for sure even if not muxed and in incomplete
> > state. You may want to also check other places where you're using
> > status = "disabled" for the same reasons.
>
> That's ... unfortunate. Would that apply to the MCBSPs too? They are
> disabled by default so you would need to explicitly enable them all for
> sensible behaviour
Yeah that applies to all the SoC integrated devices that the bus code
(hwmod) is supposed to reset and idle if unused. Basically anything
that depends on the dev entry being created.
> Hopefully there is some way to mark as device as "this is not used, make sure
> it is turned off and stays off" ???
Not currently that I know of :) To do that, we should add something
like status = "incomplete" where the dev entry gets created but the
driver is never probed. And incomplete here meaning that the device
is missing some parts like pins that would make it work properly.
> Thanks for the heads-up. I'll have a look and see exactly what is happening.
OK
> BTW, on the topic of OMAP UARTs and power saving...
> I note that there are now two drivers for the OMAP3 UART - omap-serial and
> 8250_omap.
> I also note that your commit:
>
> commit a2fc36613ac1af2e92cbed7af80bc72d8114dd50
> ARM: OMAP3: Use manual idle for UARTs because of DMA errata
>
> is incompatible with omap-serial. In particular, if I enable runtime
> suspend of the serial port by setting the autosuspend_timeout, then incoming
> characters will no longer wake the port (if I revert your patch incoming
> chars do wake the port).
> This could (I think) be fixed by enabling the RX/CTS interrupt. However if
> omap-serial is being deprecated, then there probably isn't any point.
>
> So: what is the longer term expectation for these drivers? Should we be
> switching over to 8250?
Yeah you should alredy be able to do it. Hopefully we'll have some
translation layer and the old omap-serial.c can be mostly removed
now that we have 8250 support with runtime PM :)
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 4/9] pci: add DT based ARM Versatile PCI host driver
On Tue, Dec 30, 2014 at 10:58:00PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 December 2014 13:28:33 Rob Herring wrote:
> > + list_for_each_entry(win, res, list) {
> > + struct resource *parent, *res = win->res;
> > +
> > + switch (resource_type(res)) {
> > + case IORESOURCE_IO:
> > + parent = &ioport_resource;
> > + err = pci_remap_iospace(res, iobase);
> > + if (err) {
> > + dev_warn(dev, "error %d: failed to map resource
> > %pR\n",
> > +err, res);
> > + continue;
> > + }
> > + break;
> > + case IORESOURCE_MEM:
> > + parent = &iomem_resource;
> > + res_valid |= !(res->flags & IORESOURCE_PREFETCH);
> > +
> > + writel(res->start >> 28, PCI_IMAP(mem));
> > + writel(PHYS_OFFSET >> 28, PCI_SMAP(mem));
> > + mem++;
> > +
> > + break;
> > + case IORESOURCE_BUS:
> > + default:
> > + continue;
> > + }
> > +
> > + err = devm_request_resource(dev, parent, res);
> > + if (err)
> > + goto out_release_res;
> > + }
>
> I wonder if we should also request the physical resource for the I/O space
> window to have it show up in /proc/iomem. We are rather inconsistent in this
> regard between drivers.
I'd like that. We are inconsistent, but I think it's useful to have this
information in /proc/iomem. After all, it is physical address space that
we can't use for anything else, so I guess you could argue that it's
actually a bug to omit it.
> > + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> > +
> > + bus = pci_scan_root_bus(&pdev->dev, 0, &pci_versatile_ops, &sys,
> > &pci_res);
> > + if (!bus)
> > + return -ENOMEM;
> > +
> > + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> > + pci_assign_unassigned_bus_resources(bus);
> > +
> > + return 0;
>
> One general question, mainly for Bjorn: pci_scan_root_bus adds all the devices
> at the Linux driver level by calling pci_bus_add_devices(), but then we call
> pci_fixup_irqs and pci_assign_unassigned_bus_resources after that, which will
> change the devices again. Is this how it's meant to work? How do we ensure
> that we have the correct irq number and resources by the time we enter the
> probe() function of the PCI device driver that gets bound to a device here?
Nope, that isn't how it's meant to work. After pci_bus_add_devices()
completes, drivers can be already bound to the device, and the PCI core
should keep its mitts off things the driver could be using. But I think
we've had this problem for a long time, and I haven't looked at it recently
to see how hard it would be to fix.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] leds: add DT binding for Qualcomm PM8941 WLED block
From: Courtney Cavin
This adds device tree binding documentation for the WLED ('White' LED)
block on Qualcomm's PM8941 PMICs.
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
.../devicetree/bindings/leds/leds-pm8941-wled.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
new file mode 100644
index 000..a85a964
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
@@ -0,0 +1,43 @@
+Binding for Qualcomm PM8941 WLED driver
+
+Required properties:
+- compatible: should be "qcom,pm8941-wled"
+- reg: slave address
+
+Optional properties:
+- label: The label for this led
+ See Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger: Default trigger assigned to the LED
+ See Documentation/devicetree/bindings/leds/common.txt
+- qcom,cs-out: bool; enable current sink output
+- qcom,cabc: bool; enable content adaptive backlight control
+- qcom,ext-gen: bool; use externally generated modulator signal to dim
+- qcom,current-limit: mA; per-string current limit; value from 0 to 25
+ default: 20mA
+- qcom,current-boost-limit: mA; boost current limit; one of:
+ 105, 385, 525, 805, 980, 1260, 1400, 1680
+ default: 805mA
+- qcom,switching-freq: kHz; switching frequency; one of:
+ 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
+ 1600, 1920, 2400, 3200, 4800, 9600,
+ default: 1600kHz
+- qcom,ovp: V; Over-voltage protection limit; one of:
+ 27, 29, 32, 35
+ default: 29V
+- qcom,num-strings: #; number of led strings attached; value from 1 to 3
+ default: 2
+
+Example:
+
+pm8941-wled@d800 {
+ compatible = "qcom,pm8941-wled";
+ reg = <0xd800>;
+ label = "backlight";
+
+ qcom,cs-out;
+ qcom,current-limit = <20>;
+ qcom,current-boost-limit = <805>;
+ qcom,switching-freq = <1600>;
+ qcom,ovp = <29>;
+ qcom,num-strings = <2>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] leds: add Qualcomm PM8941 WLED driver
From: Courtney Cavin
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
drivers/leds/Kconfig| 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pm8941-wled.c | 459
3 files changed, 468 insertions(+)
create mode 100644 drivers/leds/leds-pm8941-wled.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a6c3d2f..901b21a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -516,6 +516,14 @@ config LEDS_VERSATILE
This option enabled support for the LEDs on the ARM Versatile
and RealView boards. Say Y to enabled these.
+config LEDS_PM8941_WLED
+ tristate "LED support for the Qualcomm PM8941 WLED block"
+ depends on LEDS_CLASS
+ select REGMAP
+ help
+ This option enables support for the 'White' LED block
+ on Qualcomm PM8941 PMICs.
+
comment "LED Triggers"
source "drivers/leds/trigger/Kconfig"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..4325e49 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
new file mode 100644
index 000..beaa7de
--- /dev/null
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -0,0 +1,459 @@
+/* Copyright (c) 2015, Sony Mobile Communications, AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+
+#define PM8941_WLED_REG_VAL_BASE 0x40
+#define PM8941_WLED_REG_VAL_MAX 0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
+
+#define PM8941_WLED_REG_SYNC 0x47
+#define PM8941_WLED_REG_SYNC_MASK 0x07
+#define PM8941_WLED_REG_SYNC_LED1 BIT(0)
+#define PM8941_WLED_REG_SYNC_LED2 BIT(1)
+#define PM8941_WLED_REG_SYNC_LED3 BIT(2)
+#define PM8941_WLED_REG_SYNC_ALL 0x07
+#define PM8941_WLED_REG_SYNC_CLEAR0x00
+
+#define PM8941_WLED_REG_FREQ 0x4c
+#define PM8941_WLED_REG_FREQ_MASK 0x0f
+
+#define PM8941_WLED_REG_OVP0x4d
+#define PM8941_WLED_REG_OVP_MASK 0x03
+
+#define PM8941_WLED_REG_BOOST 0x4e
+#define PM8941_WLED_REG_BOOST_MASK0x07
+
+#define PM8941_WLED_REG_SINK 0x4f
+#define PM8941_WLED_REG_SINK_MASK 0xe0
+#define PM8941_WLED_REG_SINK_SHFT 0x05
+
+/* Per-'string' registers below */
+#define PM8941_WLED_REG_STR_OFFSET 0x10
+
+#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
+#define PM8941_WLED_REG_STR_MOD_MASK BIT(7)
+#define PM8941_WLED_REG_STR_MOD_ENBIT(7)
+
+#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
+#define PM8941_WLED_REG_STR_SCALE_MASK0x1f
+
+#define PM8941_WLED_REG_STR_MOD_SRC_BASE 0x63
+#define PM8941_WLED_REG_STR_MOD_SRC_MASK 0x01
+#define PM8941_WLED_REG_STR_MOD_SRC_INT 0x00
+#define PM8941_WLED_REG_STR_MOD_SRC_EXT 0x01
+
+#define PM8941_WLED_REG_STR_CABC_BASE 0x66
+#define PM8941_WLED_REG_STR_CABC_MASK BIT(7)
+#define PM8941_WLED_REG_STR_CABC_EN BIT(7)
+
+struct pm8941_wled_config {
+ u32 i_boost_limit;
+ u32 ovp;
+ u32 switch_freq;
+ u32 num_strings;
+ u32 i_limit;
+ bool cs_out_en;
+ bool ext_gen;
+ bool cabc_en;
+};
+
+struct pm8941_wled {
+ struct regmap *regmap;
+ u16 addr;
+
+ struct led_classdev cdev;
+
+ struct pm8941_wled_config cfg;
+};
+
+static int pm8941_wled_set(struct led_classdev *cdev,
+ enum led_brightness value)
+{
+ struct pm8941_wled *wled;
+ u8 ctrl = 0;
+ u16 val;
+ int rc;
+ int i;
+
+ wled = container_of(cdev, struct pm8941_wled, cdev);
+
+ if (value != 0)
+ ctrl = PM8941_WLED_REG_
Re: [PATCH 4/9] pci: add DT based ARM Versatile PCI host driver
Sorry for the late reply; maybe this has already been queued up somewhere,
so this might be moot.
I usually capitalize the "PCI" and first letter of the subject, like:
PCI: Add DT based ARM Versatile PCI host driver
And I try to ask for MAINTAINER updates since these drivers are under
drivers/pci, but I can't maintain them all myself.
On Tue, Dec 30, 2014 at 01:28:33PM -0600, Rob Herring wrote:
> From: Rob Herring
>
> This converts the Versatile PCI host code to a platform driver using
> the commom DT parsing and setup. The driver uses only an empty ARM
> pci_sys_data struct and does not use pci_common_init_dev init function.
> The old host code will be removed in a subsequent commit when Versatile
> is completely converted to DT.
>
> I've tested this on QEMU with the sym53c8xx driver in both i/o and
> memory mapped modes.
>
> Signed-off-by: Rob Herring
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: Russell King
> Cc: Linus Walleij
> Cc: Peter Maydell
Looks fine to me.
Acked-by: Bjorn Helgaas
> +++ b/drivers/pci/host/pci-versatile.c
> ...
> + /*
> + * We need to discover the PCI core first to configure itself
> + * before the main PCI probing is performed
Unusual to have two spaces between the "*" and the comments here.
> +MODULE_LICENSE("GPLv2");
This needs to be "GPL v2" per license_is_gpl_compatible().
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Qualcomm PM8941 power key driver
These patches add dt bindings and a device driver for the power key block in the Qualcomm PM8941 pmic. Changes since v1: * Use a reboot_notifier to set power off/reboot mode * Use irq flags from devicetree * Some style fixes Courtney Cavin (2): input: Add Qualcomm PM8941 power key driver input: pm8941-pwrkey: Add DT binding documentation .../bindings/input/qcom,pm8941-pwrkey.txt | 43 drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile| 1 + drivers/input/misc/pm8941-pwrkey.c | 281 + 4 files changed, 337 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt create mode 100644 drivers/input/misc/pm8941-pwrkey.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] input: Add Qualcomm PM8941 power key driver
From: Courtney Cavin
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile| 1 +
drivers/input/misc/pm8941-pwrkey.c | 281 +
3 files changed, 294 insertions(+)
create mode 100644 drivers/input/misc/pm8941-pwrkey.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..3306592 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -105,6 +105,18 @@ config INPUT_PCSPKR
To compile this driver as a module, choose M here: the
module will be called pcspkr.
+config INPUT_PM8941_PWRKEY
+ tristate "Qualcomm PM8941 power key support"
+ depends on MFD_SPMI_PMIC
+ help
+ Say Y here if you want support for the power key usually found
+ on boards using a Qualcomm PM8941 compatible PMIC.
+
+ If unsure, say Y.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pm8941-pwrkey.
+
config INPUT_PM8XXX_VIBRATOR
tristate "Qualcomm PM8XXX vibrator support"
depends on MFD_PM8XXX
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..c44f6c2 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
obj-$(CONFIG_INPUT_PCF8574)+= pcf8574_keypad.o
obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
+obj-$(CONFIG_INPUT_PM8941_PWRKEY) += pm8941-pwrkey.o
obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR)+= pm8xxx-vibrator.o
obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)+= pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
diff --git a/drivers/input/misc/pm8941-pwrkey.c
b/drivers/input/misc/pm8941-pwrkey.c
new file mode 100644
index 000..bc7ba8f
--- /dev/null
+++ b/drivers/input/misc/pm8941-pwrkey.c
@@ -0,0 +1,281 @@
+/* Copyright (c) 2010-2011, Code Aurora Forum. All rights reserved.
+ * Copyright (c) 2014, Sony Mobile Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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
+#include
+#include
+#include
+
+#define PON_REV2 0x01
+
+#define PON_RT_STS 0x10
+#define PON_KPDPWR_N_SET BIT(0)
+
+#define PON_PS_HOLD_RST_CTL0x5a
+#define PON_PS_HOLD_RST_CTL2 0x5b
+#define PON_PS_HOLD_ENABLEBIT(7)
+#define PON_PS_HOLD_TYPE_MASK 0x0f
+#define PON_PS_HOLD_TYPE_SHUTDOWN 4
+#define PON_PS_HOLD_TYPE_HARD_RESET 7
+
+#define PON_PULL_CTL 0x70
+#define PON_KPDPWR_PULL_UPBIT(1)
+
+#define PON_DBC_CTL0x71
+#define PON_DBC_DELAY_MASK0x7
+
+
+struct pm8941_pwrkey {
+ struct device *dev;
+ int irq;
+ u32 baseaddr;
+ struct regmap *regmap;
+ struct input_dev *input;
+
+ unsigned int revision;
+ struct notifier_block reboot_notifier;
+};
+
+static int pm8941_reboot_notify(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+ struct pm8941_pwrkey *pwrkey = container_of(nb, struct pm8941_pwrkey,
+ reboot_notifier);
+ unsigned int enable_reg;
+ unsigned int reset_type;
+ int rc;
+
+ /* PMICs with revision 0 have the enable bit in same register as ctrl */
+ if (pwrkey->revision == 0)
+ enable_reg = PON_PS_HOLD_RST_CTL;
+ else
+ enable_reg = PON_PS_HOLD_RST_CTL2;
+
+ rc = regmap_update_bits(pwrkey->regmap, pwrkey->baseaddr + enable_reg,
+ PON_PS_HOLD_ENABLE, 0);
+ if (rc)
+ dev_err(pwrkey->dev, "unable to clear ps hold reset enable\n");
+
+ /*
+* Updates of PON_PS_HOLD_ENABLE requires 3 sleep cycles between
+* writes.
+*/
+ usleep_range(100, 1000);
+
+ switch (code) {
+ case SYS_HALT:
+ case SYS_POWER_OFF:
+ reset_type = PON_PS_HOLD_TYPE_SHUTDOWN;
+ break;
+ case SYS_RESTART:
+ default:
+ reset_type = PON_PS_HOLD_TYPE_HARD_RESET;
+ break;
+ };
+
+ rc = regmap_update_bits(pwrkey->regmap,
+ pwrkey->baseaddr + PON_PS_HOLD_RST_CTL,
+
[PATCH v2 2/2] input: pm8941-pwrkey: Add DT binding documentation
From: Courtney Cavin
Signed-off-by: Courtney Cavin
Signed-off-by: Bjorn Andersson
---
.../bindings/input/qcom,pm8941-pwrkey.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
new file mode 100644
index 000..07bf55f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
@@ -0,0 +1,43 @@
+Qualcomm PM8941 PMIC Power Key
+
+PROPERTIES
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,pm8941-pwrkey"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: base address of registers for block
+
+- interrupts:
+ Usage: required
+ Value type:
+ Definition: key change interrupt; The format of the specifier is
+ defined by the binding document describing the node's
+ interrupt parent.
+
+- debounce:
+ Usage: optional
+ Value type:
+ Definition: time in microseconds that key must be pressed or released
+ for state change interrupt to trigger.
+
+- bias-pull-up:
+ Usage: optional
+ Value type:
+ Definition: presence of this property indicates that the KPDPWR_N pin
+ should be configured for pull up.
+
+EXAMPLE
+
+ pwrkey@800 {
+ compatible = "qcom,pm8941-pwrkey";
+ reg = <0x800>;
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ };
--
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 v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration
On Fri, Jan 23, 2015 at 05:32:37PM -0500, Murali Karicheri wrote:
> Add of_pci_dma_configure() to allow updating the dma configuration
> of the pci device using the configuration from DT of the parent of
> the root bridge device.
>
> Cc: Joerg Roedel
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Bjorn Helgaas
> Cc: Will Deacon
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: Suravee Suthikulpanit
>
> Signed-off-by: Murali Karicheri
> ---
> drivers/of/of_pci.c| 39 +++
> include/linux/of_pci.h | 12
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 88471d3..34878c9 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -2,6 +2,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -229,6 +230,44 @@ parse_failed:
> return err;
> }
> EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> +
> +/**
> + * of_get_pci_root_bridge_parent - get the OF node of the root bridge's
> parent
> + * @dev: ptr to pci_dev struct of the pci device
> + *
> + * This function will traverse the bus up to the root bus starting with
> + * the child and return the OF node ptr to root bridge device's parent
> device.
> + */
> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
I'm not an OF person, but this interface seems like it might be too
special-purpose. Maybe it would be enough to add
"of_get_pci_root_bridge()", and the caller could do this:
struct device *bridge = of_get_pci_root_bridge(dev);
struct device_node *parent_np = bridge->parent->of_node;
Also, the name "of_get_..." suggests that it increments a refcount, as
of_get_parent() does. But you aren't doing anything with the refcount.
But I guess an "of_get_pci_root_bridge()" isn't doing anything OF-related,
so maybe we should just add a "pci_get_host_bridge(struct pci_dev *)"
to PCI instead.
Bjorn
> +{
> + struct pci_bus *bus = dev->bus;
> + struct device *bridge;
> +
> + while (!pci_is_root_bus(bus))
> + bus = bus->parent;
> + bridge = bus->bridge;
> +
> + return bridge->parent->of_node;
> +}
> +EXPORT_SYMBOL_GPL(of_get_pci_root_bridge_parent);
> +
> +/**
> + * of_pci_dma_configure - Setup DMA configuration
> + * @dev: ptr to pci_dev struct of the pci device
> + *
> + * Function to update PCI devices's DMA configuration using the same
> + * info from the OF node of root host bridge's parent.
> + */
> +void of_pci_dma_configure(struct pci_dev *pci_dev)
> +{
> + struct device *dev = &pci_dev->dev;
> + struct device_node *parent_np;
> +
> + parent_np = of_get_pci_root_bridge_parent(pci_dev);
> + of_dma_configure(dev, parent_np);
> +}
> +EXPORT_SYMBOL_GPL(of_pci_dma_configure);
> +
> #endif /* CONFIG_OF_ADDRESS */
>
> #ifdef CONFIG_PCI_MSI
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index ce0e5ab..0465a2a 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -16,6 +16,8 @@ int of_pci_get_devfn(struct device_node *np);
> int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
> int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
> int of_get_pci_domain_nr(struct device_node *node);
> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev);
> +void of_pci_dma_configure(struct pci_dev *pci_dev);
> #else
> static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct
> of_phandle_args *out_irq)
> {
> @@ -50,6 +52,16 @@ of_get_pci_domain_nr(struct device_node *node)
> {
> return -1;
> }
> +
> +static inline struct device_node
> +*of_get_pci_root_bridge_parent(struct pci_dev *dev)
> +{
> + return NULL;
> +}
> +
> +static inline void of_pci_dma_configure(struct pci_dev *pci_dev)
> +{
> +}
> #endif
>
> #if defined(CONFIG_OF_ADDRESS)
> --
> 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
Re: [PATCH v4 5/6] PCI: update dma configuration from DT
On Fri, Jan 23, 2015 at 05:32:38PM -0500, Murali Karicheri wrote: > If there is a DT node available for the root bridge's parent device, > use the dma configuration from that device node. For example, keystone > PCI devices would require dma_pfn_offset to be set correctly in the > device structure of the pci device in order to have the correct dma mask. > The DT node will have dma-ranges defined for this. Also support using > the DT property dma-coherent to allow coherent DMA operation by the > PCI device. > > This patch use the new helper function of_pci_dma_configure() to update > the device dma configuration. > > Cc: Joerg Roedel > Cc: Grant Likely > Cc: Rob Herring > Cc: Bjorn Helgaas > Cc: Will Deacon > Cc: Russell King > Cc: Arnd Bergmann > Cc: Suravee Suthikulpanit > > Signed-off-by: Murali Karicheri I assume this series will be merged via some non-PCI tree, so: Acked-by: Bjorn Helgaas > --- > drivers/pci/probe.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index 23212f8..d7dcd6c 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus > *bus) > dev->dev.dma_mask = &dev->dma_mask; > dev->dev.dma_parms = &dev->dma_parms; > dev->dev.coherent_dma_mask = 0xull; > + of_pci_dma_configure(dev); > > pci_set_dma_max_seg_size(dev, 65536); > pci_set_dma_seg_boundary(dev, 0x); > -- > 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 2/4] arm: dts: am4372: add missing debugss clocks
These clocks are needed so that OMAP HWMOD can
control them when we're using performance
monitors.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 51
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index c7dc9dab93a4..9000a5c5b719 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -362,6 +362,57 @@
clock-div = <1>;
};
+ dbg_sysclk_ck: dbg_sysclk_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&sys_clkin_ck>;
+ ti,bit-shift = <8>;
+ reg = <0x20>;
+ };
+
+ dbg_clka_ck: dbg_clka_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&sys_clkin_ck>;
+ ti,bit-shift = <9>;
+ reg = <0x20>;
+ };
+
+ dbg_clkb_ck: dbg_clkb_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&sys_clkin_ck>;
+ ti,bit-shift = <10>;
+ reg = <0x20>;
+ };
+
+ dbg_clkc_ck: dbg_clkc_ck {
+ #clock-cells = <0>;
+ compatible = "ti,gate-clock";
+ clocks = <&sys_clkin_ck>;
+ ti,bit-shift = <11>;
+ reg = <0x20>;
+ };
+
+ trace_pmd_clk_mux_ck: trace_pmd_clk_mux_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&dbg_sysclk_ck>, <&dbg_clka_ck>,
+ <&dbg_clkb_ck>, <&dbg_clkc_ck>;
+ ti,bit-shift = <22>;
+ reg = <0x20>;
+ };
+
+ trace_clk_div_ck: trace_clk_div_ck {
+ #clock-cells = <0>;
+ compatible = "ti,divider-clock";
+ clocks = <&trace_pmd_clk_mux_ck>;
+ ti,bit-shift = <24>;
+ ti,max-div = <4>;
+ reg = <0x20>;
+ ti,index-power-of-two;
+ };
+
pruss_ocp_gclk: pruss_ocp_gclk {
#clock-cells = <0>;
compatible = "ti,mux-clock";
--
2.3.0-rc1
--
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 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Without hwmod data for DebugSS, performance monitors
have no chance of running on AM43xx devices.
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 ++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 41 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c8410160e..6709704dd5b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,7 @@
#include "omap_hwmod.h"
#include "omap_hwmod_33xx_43xx_common_data.h"
#include "prcm43xx.h"
+#include "prm44xx.h"
#include "omap_hwmod_common_data.h"
@@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
.rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets),
};
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
+ { .role = "dbg_sysclk", .clk = "dbg_sysclk_ck" },
+ { .role = "dbg_clka", .clk = "dbg_clka_ck", },
+ { .role = "dbg_clkb", .clk = "dbg_clkb_ck", },
+ { .role = "dbg_clkc", .clk = "dbg_clkc_ck", },
+};
+
+static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
+ .name = "debugss",
+};
+
+/* debugss */
+static struct omap_hwmod am43xx_debugss_hwmod = {
+ .name = "debugss",
+ .class = &am43xx_debugss_hwmod_class,
+ .clkdm_name = "l3_aon_clkdm",
+ .main_clk = "trace_clk_div_ck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
+ },
+ },
+ .opt_clks = am43xx_debugss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am43xx_debugss_opt_clks),
+};
+
+/* debugss -> l3_main_2 */
+static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = {
+ .master = &am43xx_debugss_hwmod,
+ .slave = &am33xx_l3_main_hwmod,
+ .clk= "sys_clkin_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod am43xx_control_hwmod = {
.name = "control",
.class = &am33xx_control_hwmod_class,
@@ -875,6 +914,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
&am33xx_l3_main__tptc1,
&am33xx_l3_main__tptc2,
&am33xx_l3_main__ocmc,
+ &am43xx_debugss__l3_main,
&am43xx_l4_hs__cpgmac0,
&am33xx_cpgmac0__mdio,
&am33xx_l3_main__sha0,
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..bb42cd80526d 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -93,6 +93,7 @@
#define AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET0x0548
#define AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET0x0550
#define AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET0x0558
+#define AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET0x0020
#define AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET 0x0228
#define AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET 0x0360
#define AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET 0x0350
--
2.3.0-rc1
--
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 0/4] arm: am43xx: add PMU support
Hi all, with these patches we can use perf with AM43xx devices and get actual statistics. Full boot logs: http://hastebin.com/yoxaxurohu Felipe Balbi (4): arm: omap: hwmod: 43xx: add DebugSS hwmod data arm: dts: am4372: add missing debugss clocks clk: ti: 43xx: add debugss clocks to DT_CLK() table arm: dts: am4372: add pmu DT data arch/arm/boot/dts/am4372.dtsi | 8 + arch/arm/boot/dts/am43xx-clocks.dtsi | 51 ++ arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40 +++ arch/arm/mach-omap2/prcm43xx.h | 1 + drivers/clk/ti/clk-43xx.c | 6 5 files changed, 106 insertions(+) -- 2.3.0-rc1 -- 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 4/4] arm: dts: am4372: add pmu DT data
with this patch, performance monitors work
and show sensible data on AM43xx devices:
~# perf stat sleep 5
Performance counter stats for 'sleep 5':
6.079585 task-clock (msec) #0.001 CPUs utilized
3 context-switches #0.493 K/sec
0 cpu-migrations#0.000 K/sec
35 page-faults #0.006 M/sec
5888256 cycles#0.969 GHz
1458715 stalled-cycles-frontend # 24.77% frontend cycles
idle
4632019 stalled-cycles-backend# 78.67% backend cycles
idle
1892556 instructions #0.32 insns per cycle
#2.45 stalled cycles per
insn
141832 branches # 23.329 M/sec
56093 branch-misses # 39.55% of all branches
5.018813000 seconds time elapsed
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am4372.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 861f127dfead..ea103aa970f1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -51,6 +51,14 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ reg = <0x4b00 0x80>;
+ interrutps = ,
+ ;
+ ti,hwmods = "debugss";
+ };
+
gic: interrupt-controller@48241000 {
compatible = "arm,cortex-a9-gic";
interrupt-controller;
--
2.3.0-rc1
--
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 3/4] clk: ti: 43xx: add debugss clocks to DT_CLK() table
without these entries, omap_hwmod will not be
able to find debugss clocks.
Signed-off-by: Felipe Balbi
---
drivers/clk/ti/clk-43xx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 3795fce8a830..46a597c815c9 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -83,6 +83,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, "gfx_fck_div_ck", "gfx_fck_div_ck"),
DT_CLK(NULL, "timer_32k_ck", "clkdiv32k_ick"),
DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
+ DT_CLK(NULL, "trace_clk_div_ck", "trace_clk_div_ck"),
+ DT_CLK(NULL, "trace_pm_clk_mux_ck", "trace_pm_clk_mux_ck"),
+ DT_CLK(NULL, "dbg_sysclk_ck", "dbg_sysclk_ck"),
+ DT_CLK(NULL, "dbg_clka_ck", "dbg_clka_ck"),
+ DT_CLK(NULL, "dbg_clkb_ck", "dbg_clkb_ck"),
+ DT_CLK(NULL, "dbg_clkc_ck", "dbg_clkc_ck"),
DT_CLK(NULL, "sysclk_div", "sysclk_div"),
DT_CLK(NULL, "disp_clk", "disp_clk"),
DT_CLK(NULL, "clk_32k_mosc_ck", "clk_32k_mosc_ck"),
--
2.3.0-rc1
--
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: Associating nodes with phandles for pci devices
On 23/01/15 11:38, Chris Packham wrote: > > Hi Arnd, > > Thanks for the quick response (and sorry for the horribly formatted > message, travelling with only a webmail interface at the moment). > > On Fri, 23 Jan 2015, Arnd Bergmann wrote: > >> On Friday 23 January 2015 19:02:33 Chris Packham wrote: >>> Hi, >>> >>> I'm working on a new board that has a marvell,dsa switch. Similar to >>> the kirkwood-mv88f6281gtw-ge board. However the major difference is >>> that instead of being connected to an integrated Ethernet port it is >>> connected via a PCI-e Ethernet port (basically a NIC hardwired onto >>> the board). >>> >>> Generally you don't need to define PCI devices in the .dts because >>> the bus is scanned at run time and the method for identifying devices >>> is well defined. But to satisfy the marvell,dsa binding[1] I need to >>> tell it the Ethernet port it is connected to. The answer might be in >>> the PCI bindings but the urls in the documentation[2] don't appear to >>> be valid anymore. >>> >>> Is it possible to enumerate PCI devices in the .dts? Or is there a >>> way of satisfying the dsa requirements without knowing the Ethernet >>> device? >>> >> >> In general, it is possible, and we do that on PowerPC, but it may be that >> there are parts missing on ARM and you have to try it out. >> >> In particular, you need to know the address of the PCI device and then >> create a device node that will be associated with the >> pci_dev->dev.of_node >> pointer. > > Encouraging to know. I think I can figure out the relevant addresses for > my device based on the run-time scan. BTW, one thing that is high in my TODO list regarding DSA is to stop using this platform device/driver architecture and use the actual device driver model. Your switch driver entry point would be a pci_drive probe's function where you end-up registering a switch the DSA. This should solve portions of your problem although this is a long shot as we need to convert existing drivers as well. > > Can you think of a good example. I found a few ppc boards that have an > PCI-ISA bridge that get's enumerated in the .dts. I think I can make sense > of them but because they are bridges there's a lot of extra stuff for > the down stream devices. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()
Function of_iommu_configure() is called from of_dma_configure() to
setup iommu ops using DT property. This API is currently used for
platform devices for which DMA configuration (including iommu ops)
may come from device's parent. To extend this functionality for PCI
devices, this API need to take a parent node ptr as an argument
instead of assuming device's parent. This is needed since for PCI, the
dma configuration may be defined in the DT node of the root bus bridge's
parent device. Currently only dma-range is used for PCI and iommu is not
supported. So return error if the device is PCI.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit
Signed-off-by: Murali Karicheri
---
drivers/iommu/of_iommu.c | 10 --
drivers/of/platform.c|2 +-
include/linux/of_iommu.h |6 --
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index af1dc6a..439235b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct device_node *np)
return ops;
}
-struct iommu_ops *of_iommu_configure(struct device *dev)
+struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *iommu_np)
{
struct of_phandle_args iommu_spec;
struct device_node *np;
struct iommu_ops *ops = NULL;
int idx = 0;
+ if (dev_is_pci(dev)) {
+ dev_err(dev, "iommu is currently not supported for PCI\n");
+ return NULL;
+ }
+
/*
* We don't currently walk up the tree looking for a parent IOMMU.
* See the `Notes:' section of
* Documentation/devicetree/bindings/iommu/iommu.txt
*/
- while (!of_parse_phandle_with_args(dev->of_node, "iommus",
+ while (!of_parse_phandle_with_args(iommu_np, "iommus",
"#iommu-cells", idx,
&iommu_spec)) {
np = iommu_spec.np;
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index a54ec10..7675b79 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -196,7 +196,7 @@ static void of_dma_configure(struct device *dev)
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
- iommu = of_iommu_configure(dev);
+ iommu = of_iommu_configure(dev, dev->of_node);
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 16c7554..a97e5bd 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -12,7 +12,8 @@ extern int of_get_dma_window(struct device_node *dn, const
char *prefix,
size_t *size);
extern void of_iommu_init(void);
-extern struct iommu_ops *of_iommu_configure(struct device *dev);
+extern struct iommu_ops *of_iommu_configure(struct device *dev,
+ struct device_node *iommu_np);
#else
@@ -24,7 +25,8 @@ static inline int of_get_dma_window(struct device_node *dn,
const char *prefix,
}
static inline void of_iommu_init(void) { }
-static inline struct iommu_ops *of_iommu_configure(struct device *dev)
+static inline struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *iommu_np)
{
return NULL;
}
--
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 v4 5/6] PCI: update dma configuration from DT
If there is a DT node available for the root bridge's parent device, use the dma configuration from that device node. For example, keystone PCI devices would require dma_pfn_offset to be set correctly in the device structure of the pci device in order to have the correct dma mask. The DT node will have dma-ranges defined for this. Also support using the DT property dma-coherent to allow coherent DMA operation by the PCI device. This patch use the new helper function of_pci_dma_configure() to update the device dma configuration. Cc: Joerg Roedel Cc: Grant Likely Cc: Rob Herring Cc: Bjorn Helgaas Cc: Will Deacon Cc: Russell King Cc: Arnd Bergmann Cc: Suravee Suthikulpanit Signed-off-by: Murali Karicheri --- drivers/pci/probe.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 23212f8..d7dcd6c 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include @@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus) dev->dev.dma_mask = &dev->dma_mask; dev->dev.dma_parms = &dev->dma_parms; dev->dev.coherent_dma_mask = 0xull; + of_pci_dma_configure(dev); pci_set_dma_max_seg_size(dev, 65536); pci_set_dma_seg_boundary(dev, 0x); -- 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 v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration
Add of_pci_dma_configure() to allow updating the dma configuration
of the pci device using the configuration from DT of the parent of
the root bridge device.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit
Signed-off-by: Murali Karicheri
---
drivers/of/of_pci.c| 39 +++
include/linux/of_pci.h | 12
2 files changed, 51 insertions(+)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 88471d3..34878c9 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
#include
@@ -229,6 +230,44 @@ parse_failed:
return err;
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_get_pci_root_bridge_parent - get the OF node of the root bridge's parent
+ * @dev: ptr to pci_dev struct of the pci device
+ *
+ * This function will traverse the bus up to the root bus starting with
+ * the child and return the OF node ptr to root bridge device's parent device.
+ */
+struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
+{
+ struct pci_bus *bus = dev->bus;
+ struct device *bridge;
+
+ while (!pci_is_root_bus(bus))
+ bus = bus->parent;
+ bridge = bus->bridge;
+
+ return bridge->parent->of_node;
+}
+EXPORT_SYMBOL_GPL(of_get_pci_root_bridge_parent);
+
+/**
+ * of_pci_dma_configure - Setup DMA configuration
+ * @dev: ptr to pci_dev struct of the pci device
+ *
+ * Function to update PCI devices's DMA configuration using the same
+ * info from the OF node of root host bridge's parent.
+ */
+void of_pci_dma_configure(struct pci_dev *pci_dev)
+{
+ struct device *dev = &pci_dev->dev;
+ struct device_node *parent_np;
+
+ parent_np = of_get_pci_root_bridge_parent(pci_dev);
+ of_dma_configure(dev, parent_np);
+}
+EXPORT_SYMBOL_GPL(of_pci_dma_configure);
+
#endif /* CONFIG_OF_ADDRESS */
#ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index ce0e5ab..0465a2a 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,8 @@ int of_pci_get_devfn(struct device_node *np);
int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
int of_get_pci_domain_nr(struct device_node *node);
+struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev);
+void of_pci_dma_configure(struct pci_dev *pci_dev);
#else
static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct
of_phandle_args *out_irq)
{
@@ -50,6 +52,16 @@ of_get_pci_domain_nr(struct device_node *node)
{
return -1;
}
+
+static inline struct device_node
+*of_get_pci_root_bridge_parent(struct pci_dev *dev)
+{
+ return NULL;
+}
+
+static inline void of_pci_dma_configure(struct pci_dev *pci_dev)
+{
+}
#endif
#if defined(CONFIG_OF_ADDRESS)
--
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 v4 0/6] PCI: get DMA configuration from parent device
PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch add capability to set the dma configuration such as dma-mask, dma_pfn_offset, and dma ops etc using the information from DT. The prior RFCs and discussions are available at [1] and [2] below. [2] : https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg790244.html [1] : http://www.gossamer-threads.com/lists/linux/kernel/2024591 Change history: v4 - moved size adjustments in of_iommu_configure() to a separate patch - consistent node name comment from Rob - patch 6 added for dma_mask adjustment and iommu mapping size limiting. v3 - addressed comments to re-use of_dma_configure() for PCI - To help re-use, change of_iommu_configure() function argument - Move of_dma_configure to of/device.c - Limit the of_iommu_configure to non pci devices v2 - update size to coherent_dma_mask + 1 if dma-range info is missing - also check the np for null. v1 - updates based on the comments against initial RFC. - Added a helper function to get the OF node of the parent - Added an API in of_pci.c to update DMA configuration of the pci device. Cc: Joerg Roedel Cc: Grant Likely Cc: Rob Herring Cc: Bjorn Helgaas Cc: Will Deacon Cc: Russell King Cc: Arnd Bergmann Cc: Suravee Suthikulpanit Murali Karicheri (6): of: iommu: add ptr to OF node arg to of_iommu_configure() of: move of_dma_configure() to device.c to help re-use of: fix size when dma-range is not used of/pci: add of_pci_dma_configure() update dma configuration PCI: update dma configuration from DT arm: dma-mapping: updates to limit dma_mask and iommu mapping size arch/arm/mm/dma-mapping.c | 10 +++ drivers/iommu/of_iommu.c | 10 +-- drivers/of/device.c | 71 + drivers/of/of_pci.c | 39 + drivers/of/platform.c | 58 ++-- drivers/pci/probe.c |2 ++ include/linux/of_device.h |2 ++ include/linux/of_iommu.h |6 ++-- include/linux/of_pci.h| 12 9 files changed, 150 insertions(+), 60 deletions(-) -- 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 v4 2/6] of: move of_dma_configure() to device.c to help re-use
Move of_dma_configure() to device.c so that same function can be re-used
for PCI devices to obtain DMA configuration from DT. Also add a second
argument so that for PCI, DT node of root bus host bridge can be used to
obtain the DMA configuration for the slave PCI device.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit
Signed-off-by: Murali Karicheri
---
drivers/of/device.c | 59 +
drivers/of/platform.c | 58 ++--
include/linux/of_device.h |2 ++
3 files changed, 63 insertions(+), 56 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 46d6c75c..2de320d 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -2,6 +2,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -66,6 +69,62 @@ int of_device_add(struct platform_device *ofdev)
return device_add(&ofdev->dev);
}
+/**
+ * of_dma_configure - Setup DMA configuration
+ * @dev: Device to apply DMA configuration
+ * @np:ptr to of node having dma configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * In case if platform code need to use own special DMA configuration,it
+ * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
+ * to fix up DMA configuration.
+ */
+void of_dma_configure(struct device *dev, struct device_node *np)
+{
+ u64 dma_addr, paddr, size;
+ int ret;
+ bool coherent;
+ unsigned long offset;
+ struct iommu_ops *iommu;
+
+ /*
+* Set default dma-mask to 32 bit. Drivers are expected to setup
+* the correct supported dma_mask.
+*/
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+ /*
+* Set it to coherent_dma_mask by default if the architecture
+* code has not set it.
+*/
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+
+ ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ if (ret < 0) {
+ dma_addr = offset = 0;
+ size = dev->coherent_dma_mask;
+ } else {
+ offset = PFN_DOWN(paddr - dma_addr);
+ dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
+ }
+
+ dev->dma_pfn_offset = offset;
+
+ coherent = of_dma_is_coherent(np);
+ dev_dbg(dev, "device is%sdma coherent\n",
+ coherent ? " " : " not ");
+
+ iommu = of_iommu_configure(dev, np);
+ dev_dbg(dev, "device is%sbehind an iommu\n",
+ iommu ? " " : " not ");
+
+ arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+}
+EXPORT_SYMBOL_GPL(of_dma_configure);
+
int of_device_register(struct platform_device *pdev)
{
device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 7675b79..6403501 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -150,59 +149,6 @@ struct platform_device *of_device_alloc(struct device_node
*np,
}
EXPORT_SYMBOL(of_device_alloc);
-/**
- * of_dma_configure - Setup DMA configuration
- * @dev: Device to apply DMA configuration
- *
- * Try to get devices's DMA configuration from DT and update it
- * accordingly.
- *
- * In case if platform code need to use own special DMA configuration,it
- * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
- * to fix up DMA configuration.
- */
-static void of_dma_configure(struct device *dev)
-{
- u64 dma_addr, paddr, size;
- int ret;
- bool coherent;
- unsigned long offset;
- struct iommu_ops *iommu;
-
- /*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
-*/
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
- /*
-* Set it to coherent_dma_mask by default if the architecture
-* code has not set it.
-*/
- if (!dev->dma_mask)
- dev->dma_mask = &dev->coherent_dma_mask;
-
- ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
- if (ret < 0) {
- dma_addr = offset = 0;
- size = dev->coherent_dma_mask;
- } else {
- offset = PFN_DOWN(paddr - dma_addr);
- dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
- }
- dev->dma_pfn_offset = offset;
-
- coherent = of_dma_is_coherent(dev->of_node);
- dev_dbg(dev, "device is%sdma coherent\n",
- coherent ? " " : " not ");
-
- iommu = of_iommu_configure(dev, dev->of_node);
- dev_dbg(dev, "device is%sbehind an iommu\n",
- iommu ? " " : " not ");
-
- arch_setup_d
[PATCH v4 3/6] of: fix size when dma-range is not used
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev->coherent_dma_mask + 1 instead of dev->coherent_dma_mask. To detect
overflow when mask is set to max of u64, add a check, log error and return.
Some platform use mask format for size in DTS. So add a work around to
catch this and fix.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit
Signed-off-by: Murali Karicheri
---
drivers/of/device.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 2de320d..0a5ff54 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,12 +105,24 @@ void of_dma_configure(struct device *dev, struct
device_node *np)
ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
if (ret < 0) {
dma_addr = offset = 0;
- size = dev->coherent_dma_mask;
+ size = dev->coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
+ /*
+* Add a work around to treat the size as mask + 1 in case
+* it is defined in DT as a mask.
+*/
+ if (size & 1)
+ size = size + 1;
dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
}
+ /* if size is 0, we have an overflow of u64 */
+ if (!size) {
+ dev_err(dev, "invalid size\n");
+ return;
+ }
+
dev->dma_pfn_offset = offset;
coherent = of_dma_is_coherent(np);
--
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 v4 6/6] arm: dma-mapping: updates to limit dma_mask and iommu mapping size
Limit the dma_mask to minimum of dma_mask and dma_base + size - 1.
Also arm_iommu_create_mapping() has size parameter of size_t and
arm_setup_iommu_dma_ops() can take a value higher than that. So
limit the size to SIZE_MAX.
Signed-off-by: Murali Karicheri
---
arch/arm/mm/dma-mapping.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 7864797..a1f9030 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2004,6 +2004,13 @@ static bool arm_setup_iommu_dma_ops(struct device *dev,
u64 dma_base, u64 size,
if (!iommu)
return false;
+ /*
+* currently arm_iommu_create_mapping() takes a max of size_t
+* for size param. So check this limit for now.
+*/
+ if (size > SIZE_MAX)
+ return false;
+
mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
if (IS_ERR(mapping)) {
pr_warn("Failed to create %llu-byte IOMMU mapping for device
%s\n",
@@ -2053,6 +2060,9 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
{
struct dma_map_ops *dma_ops;
+ /* limit dma_mask to the lower of the two values */
+ *dev->dma_mask = min((*dev->dma_mask), (dma_base + size - 1));
+
dev->archdata.dma_coherent = coherent;
if (arm_setup_iommu_dma_ops(dev, dma_base, size, iommu))
dma_ops = arm_get_iommu_dma_map_ops(coherent);
--
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
Re: [PATCH 12/13] ARM: dts: omap3-gta04: uart4 is not connected, so mark it "disabled"
On Thu, 22 Jan 2015 13:40:53 -0800 Tony Lindgren wrote:
> * Marek Belisko [150122 12:42]:
> > From: NeilBrown
> >
> > Signed-off-by: NeilBrown
> > ---
> > arch/arm/boot/dts/omap3-gta04.dtsi | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
> > b/arch/arm/boot/dts/omap3-gta04.dtsi
> > index 228e79b..8d2b0a1 100644
> > --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> > +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> > @@ -357,6 +357,10 @@
> > pinctrl-0 = <&uart3_pins>;
> > };
> >
> > +&uart4 {
> > + status = "disabled";
> > +};
> > +
>
> This you probably want to avoid from PM point of view. Depending on
> bootloader state of uart4, Linux may or may not be able to hit any
> deeper power states.
>
> Marking something with status = "disabled" in dts causes the device
> entry not even to be created. That means hwmod won't be able to reset
> and idle this device during boot.
>
> The uart4 device is there for sure even if not muxed and in incomplete
> state. You may want to also check other places where you're using
> status = "disabled" for the same reasons.
That's ... unfortunate. Would that apply to the MCBSPs too? They are
disabled by default so you would need to explicitly enable them all for
sensible behaviour
Hopefully there is some way to mark as device as "this is not used, make sure
it is turned off and stays off" ???
Thanks for the heads-up. I'll have a look and see exactly what is happening.
BTW, on the topic of OMAP UARTs and power saving...
I note that there are now two drivers for the OMAP3 UART - omap-serial and
8250_omap.
I also note that your commit:
commit a2fc36613ac1af2e92cbed7af80bc72d8114dd50
ARM: OMAP3: Use manual idle for UARTs because of DMA errata
is incompatible with omap-serial. In particular, if I enable runtime
suspend of the serial port by setting the autosuspend_timeout, then incoming
characters will no longer wake the port (if I revert your patch incoming
chars do wake the port).
This could (I think) be fixed by enabling the RX/CTS interrupt. However if
omap-serial is being deprecated, then there probably isn't any point.
So: what is the longer term expectation for these drivers? Should we be
switching over to 8250?
Thanks,
NeilBrown
pgpZRekRGOPFM.pgp
Description: OpenPGP digital signature
Re: [PATCH] arm64: dts: add baud rate to Juno stdout-path
On Thu, Jan 22, 2015 at 11:21:32AM +, Robin Murphy wrote: > Without explicit command-line parameters, the Juno UART ends up running > at 57600 baud in the kernel, which is at odds with the 115200 baud used > by the rest of the firmware. Since commit 7914a7c5651a5161 now lets us > fix this by specifying default options in stdout-path, do so. > > Acked-by: Mark Rutland > Signed-off-by: Robin Murphy Thanks, applied as a fix for 3.19. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: sun4i: Add initial dts for Gemei G9 tablet
On Fri, 2015-01-23 at 22:22 +0100, Maxime Ripard wrote:
> On Fri, Jan 23, 2015 at 10:36:49PM +0200, Priit Laes wrote:
> > Gemei G9 is an A10 based tablet, with 1G RAM, 16G NAND, 1024x768
> > IPS LCD display, stereo speakers, 1.3MP front camera and 5 MP
> > rear camera, 8000mAh battery, GT901 2+1 touchscreen, Bosch BMA250
> > accelerometer and RTL8188CUS USB wifi. It also has MicroSD slot,
> > miniHDMI, 1 x MicroUSB OTG port and 1 x MicroUSB host port and
> > 3.5mm headphone jack.
> > More details are available at: http://linux-sunxi.org/Gemei_G9
> >
[..]
> >
> > +/ {
> > +model = "Gemei G9 Tablet";
> > +compatible = "gemei,g9", "allwinner,sun4i-a10";
> > +};
> > +
> > +/*
> > + * http://linux-sunxi.org/Gemei_G9
>
> Please don't put URL in the DT. This is very likely to change in the
> future, and won't be valid anymore.
OK! The URL in commit message is ok to stay?
>
> > + *
> > + * TODO:
> > + * 2x cameras via CSI
> > + * AXP battery management
> > + * AXP power enable key
> > + * Keys (LRADC)
> > + * NAND
> > + * OTG
> > + * Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
> > + */
> > +
> > +
> > +&ehci0 {
> > +status = "okay";
> > +};
>
> Indentation with one tabulation please.
Oops.. will do.
>
>
> > +&ehci1 {
> > +status = "okay";
> > +};
> > +
> > +&i2c0 {
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&i2c0_pins_a>;
> > +status = "okay";
> > +
> > +axp209: pmic@34 {
> > +compatible = "x-powers,axp209";
> > +reg = <0x34>;
> > +interrupts = <0>;
> > +
> > +interrupt-controller;
> > +#interrupt-cells = <1>;
> > +};
> > +};
> > +
> > +&i2c1 {
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&i2c1_pins_a>;
> > +status = "okay";
> > +
> > +/* Accelerometer */
> > +bma250@18 {
> > +compatible = "bosch,bma250";
> > +reg = <0x18>;
>
> Is there a driver for this? It looks weird that it doesn't need more
> properties than that.
Yes, it's supported by drivers/iio/accel/bma180.c though I have to
admit that this name is a bit misleading. (bosch-bma.c would
better, I guess).
And I was a bit surprised that it worked out of the box too, but the
device was present under /sys and I was able to read x, y, z and
temperature values.
> > +};
> > +};
> > +
> > +®_usb1_vbus {
> > +status = "okay";
> > +};
> > +
> > +®_usb2_vbus {
> > +status = "okay";
> > +};
> > +
> > +&mmc0 {
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> > +vmmc-supply = <®_vcc3v3>;
> > +bus-width = <4>;
> > +cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH01 */
> > +cd-inverted;
> > +status = "okay";
> > +};
> > +
> > +
>
> Remove that extra new line.
Will do.
>
> > +&uart0 {
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&uart0_pins_a>;
> > +status = "okay";
> > +};
> > +
> > +&usbphy {
> > +usb1_vbus-supply = <®_usb1_vbus>;
> > +usb2_vbus-supply = <®_usb2_vbus>;
> > +status = "okay";
> > +};
> > --
> > 2.2.2
> >
>
> Looks good otherwise, thanks! Maxime
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: sun4i: Add initial dts for Gemei G9 tablet
On Fri, Jan 23, 2015 at 10:36:49PM +0200, Priit Laes wrote:
> Gemei G9 is an A10 based tablet, with 1G RAM, 16G NAND, 1024x768
> IPS LCD display, stereo speakers, 1.3MP front camera and 5 MP
> rear camera, 8000mAh battery, GT901 2+1 touchscreen, Bosch BMA250
> accelerometer and RTL8188CUS USB wifi. It also has MicroSD slot,
> miniHDMI, 1 x MicroUSB OTG port and 1 x MicroUSB host port and
> 3.5mm headphone jack.
> More details are available at: http://linux-sunxi.org/Gemei_G9
>
> Signed-off-by: Priit Laes
> ---
> arch/arm/boot/dts/Makefile | 6 +-
> arch/arm/boot/dts/sun4i-a10-gemei-g9.dts | 138
> +++
> 2 files changed, 142 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7df26a2..a2e05fc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -447,12 +447,14 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-ba10-tvbox.dtb \
> sun4i-a10-chuwi-v7-cw0825.dtb \
> sun4i-a10-cubieboard.dtb \
> + sun4i-a10-gemei-g9.dtb \
> + sun4i-a10-hackberry.dtb \
> + sun4i-a10-inet97fv2.dtb \
> sun4i-a10-marsboard.dtb \
> sun4i-a10-mini-xplus.dtb \
> sun4i-a10-mk802.dtb \
> sun4i-a10-mk802ii.dtb \
> - sun4i-a10-hackberry.dtb \
> - sun4i-a10-inet97fv2.dtb \
> + sun4i-a10-mini-xplus.dtb \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb
> dtb-$(CONFIG_MACH_SUN5I) += \
> diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> new file mode 100644
> index 000..46700b8
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> @@ -0,0 +1,138 @@
> +/*
> + * Copyright 2015 Priit Laes
> + *
> + * Priit Laes
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this file; if not, write to the Free
> + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
> + * MA 02110-1301 USA
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun4i-a10.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +#include
> +
> +/ {
> +model = "Gemei G9 Tablet";
> +compatible = "gemei,g9", "allwinner,sun4i-a10";
> +};
> +
> +/*
> + * http://linux-sunxi.org/Gemei_G9
Please don't put URL in the DT. This is very likely to change in the
future, and won't be valid anymore.
> + *
> + * TODO:
> + * 2x cameras via CSI
> + * AXP battery management
> + * AXP power enable key
> + * Keys (LRADC)
> + * NAND
> + * OTG
> + * Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
> + */
> +
> +
> +&ehci0 {
> +status = "okay";
> +};
Indentation with one tabulation please.
> +&ehci1 {
> +status = "okay";
> +};
> +
> +&i2c0 {
> +pinctrl-names = "default";
> +pinctrl-0 = <&i2c0_pins_a>;
> +status = "okay";
> +
> +axp209: pmic@34 {
> +
Re: [PATCH] ARM: dts: sun4i: Add Hyundau A7HD board
On Fri, Jan 23, 2015 at 04:39:23PM +0100, Hans de Goede wrote: > The Hyundai A7HD is a 7" 16:9 A10 powered tablet featuring 1G RAM, 8G > nand, 1024x600 IPS screen, a mini hdmi port, mini usb receptacle and a > headphones port for details see: http://linux-sunxi.org/Hyundai_A7HD > > Cc: Mark Janssen > Signed-off-by: Hans de Goede Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH] ARM: dts: sun4i: Add initial dts for Gemei G9 tablet
Gemei G9 is an A10 based tablet, with 1G RAM, 16G NAND, 1024x768
IPS LCD display, stereo speakers, 1.3MP front camera and 5 MP
rear camera, 8000mAh battery, GT901 2+1 touchscreen, Bosch BMA250
accelerometer and RTL8188CUS USB wifi. It also has MicroSD slot,
miniHDMI, 1 x MicroUSB OTG port and 1 x MicroUSB host port and
3.5mm headphone jack.
More details are available at: http://linux-sunxi.org/Gemei_G9
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/Makefile | 6 +-
arch/arm/boot/dts/sun4i-a10-gemei-g9.dts | 138 +++
2 files changed, 142 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7df26a2..a2e05fc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -447,12 +447,14 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-ba10-tvbox.dtb \
sun4i-a10-chuwi-v7-cw0825.dtb \
sun4i-a10-cubieboard.dtb \
+ sun4i-a10-gemei-g9.dtb \
+ sun4i-a10-hackberry.dtb \
+ sun4i-a10-inet97fv2.dtb \
sun4i-a10-marsboard.dtb \
sun4i-a10-mini-xplus.dtb \
sun4i-a10-mk802.dtb \
sun4i-a10-mk802ii.dtb \
- sun4i-a10-hackberry.dtb \
- sun4i-a10-inet97fv2.dtb \
+ sun4i-a10-mini-xplus.dtb \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
new file mode 100644
index 000..46700b8
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
@@ -0,0 +1,138 @@
+/*
+ * Copyright 2015 Priit Laes
+ *
+ * Priit Laes
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include
+
+/ {
+model = "Gemei G9 Tablet";
+compatible = "gemei,g9", "allwinner,sun4i-a10";
+};
+
+/*
+ * http://linux-sunxi.org/Gemei_G9
+ *
+ * TODO:
+ * 2x cameras via CSI
+ * AXP battery management
+ * AXP power enable key
+ * Keys (LRADC)
+ * NAND
+ * OTG
+ * Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
+ */
+
+
+&ehci0 {
+status = "okay";
+};
+
+&ehci1 {
+status = "okay";
+};
+
+&i2c0 {
+pinctrl-names = "default";
+pinctrl-0 = <&i2c0_pins_a>;
+status = "okay";
+
+axp209: pmic@34 {
+compatible = "x-powers,axp209";
+reg = <0x34>;
+interrupts = <0>;
+
+interrupt-controller;
+#interrupt-cells = <1>;
+};
+};
+
+&i2c1 {
+pinctrl-names = "default";
+pinctrl-0 = <&i2c1_pins_a>;
+status = "okay";
+
+/* Accelerometer */
+bma250@18 {
+compatible = "bosch,bma250";
+reg = <0x18>;
+};
+};
+
+®_usb1_vbus {
+status = "okay";
+};
+
+®_usb2_vbus {
+
[PATCH] ARM: shmobile: henninger: rename board to Porter
Renesas has made some changes to the Henninger low cost board hardware and at
the same time decided to rename the board to Porter.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20150123-v3.19-rc5' tag of Simon Horman's
'renesas.git' repo.
arch/arm/boot/dts/Makefile | 2 +-
.../arm/boot/dts/{r8a7791-henninger.dts => r8a7791-porter.dts} | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
rename arch/arm/boot/dts/{r8a7791-henninger.dts => r8a7791-porter.dts} (96%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 59e79e9..3cc8ba5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -419,8 +419,8 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += eme
r8a7740-armadillo800eva.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
- r8a7791-henninger.dtb \
r8a7791-koelsch.dtb \
+ r8a7791-porter.dtb \
r8a7794-alt.dtb \
sh73a0-kzm9g.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_arria5_socdk.dtb \
diff --git a/arch/arm/boot/dts/r8a7791-henninger.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
similarity index 96%
rename from arch/arm/boot/dts/r8a7791-henninger.dts
rename to arch/arm/boot/dts/r8a7791-porter.dts
index d2ebf11..4a616dc 100644
--- a/arch/arm/boot/dts/r8a7791-henninger.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -1,8 +1,8 @@
/*
- * Device Tree Source for the Henninger board
+ * Device Tree Source for the Porter board
*
- * Copyright (C) 2014 Renesas Solutions Corp.
- * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Copyright (C) 2014-2015 Renesas Solutions Corp.
+ * Copyright (C) 2014-2015 Cogent Embedded, Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -14,8 +14,8 @@
#include
/ {
- model = "Henninger";
- compatible = "renesas,henninger", "renesas,r8a7791";
+ model = "Porter";
+ compatible = "renesas,porter", "renesas,r8a7791";
aliases {
serial0 = &scif0;
--
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: Associating nodes with phandles for pci devices
Hi Arnd, Thanks for the quick response (and sorry for the horribly formatted message, travelling with only a webmail interface at the moment). On Fri, 23 Jan 2015, Arnd Bergmann wrote: On Friday 23 January 2015 19:02:33 Chris Packham wrote: Hi, I'm working on a new board that has a marvell,dsa switch. Similar to the kirkwood-mv88f6281gtw-ge board. However the major difference is that instead of being connected to an integrated Ethernet port it is connected via a PCI-e Ethernet port (basically a NIC hardwired onto the board). Generally you don't need to define PCI devices in the .dts because the bus is scanned at run time and the method for identifying devices is well defined. But to satisfy the marvell,dsa binding[1] I need to tell it the Ethernet port it is connected to. The answer might be in the PCI bindings but the urls in the documentation[2] don't appear to be valid anymore. Is it possible to enumerate PCI devices in the .dts? Or is there a way of satisfying the dsa requirements without knowing the Ethernet device? In general, it is possible, and we do that on PowerPC, but it may be that there are parts missing on ARM and you have to try it out. In particular, you need to know the address of the PCI device and then create a device node that will be associated with the pci_dev->dev.of_node pointer. Encouraging to know. I think I can figure out the relevant addresses for my device based on the run-time scan. Can you think of a good example. I found a few ppc boards that have an PCI-ISA bridge that get's enumerated in the .dts. I think I can make sense of them but because they are bridges there's a lot of extra stuff for the down stream devices. -- 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: Associating nodes with phandles for pci devices
On Friday 23 January 2015 19:02:33 Chris Packham wrote: > Hi, > > I'm working on a new board that has a marvell,dsa switch. Similar to the > kirkwood-mv88f6281gtw-ge board. However the major difference is that instead > of being connected to an integrated Ethernet port it is connected via a PCI-e > Ethernet port (basically a NIC hardwired onto the board). > > Generally you don't need to define PCI devices in the .dts because the bus is > scanned at run time and the method for identifying devices is well defined. > But to satisfy the marvell,dsa binding[1] I need to tell it the Ethernet port > it is connected to. The answer might be in the PCI bindings but the urls in > the documentation[2] don't appear to be valid anymore. > > Is it possible to enumerate PCI devices in the .dts? Or is there a way of > satisfying the dsa requirements without knowing the Ethernet device? > In general, it is possible, and we do that on PowerPC, but it may be that there are parts missing on ARM and you have to try it out. In particular, you need to know the address of the PCI device and then create a device node that will be associated with the pci_dev->dev.of_node pointer. 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: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote: > A card builder is a device which > - scans the graph of ports, > - fills the struct snd_soc_card according to the links between the > ports and their properties, > - and, eventually, calls snd_soc_register_card(). > The simple card builder, 'dt-card' (maybe a better name would have been > 'graph-card'), acts just like the simple-card except that it does not > appear in the DT. Its creation is done by an audio controller. Which audio controller? There may be several CPU side audio interfaces in the same card. For example people often want to have both low latency and high latency audio paths from the CPU into the hardware (low latency tends to increase power burn). SoC centric system designs do sometimes also have PDM I/O, expecting to be directly connected to DMICs and so on, which results in a relatively large number of CPU interfaces. > > > With a DT graph, each CPU/CODEC would know exactly the widgets and > > > routes it has to define. > > Which widgets/routes do you mean? > Well, forget about this. I never clearly understood why some widgets > and routes had to be defined at card level. Please do try to understand the idea of representing simple components on the board and analogue interconects between devices - it's really important and not something that can be neglected. > > I'd agree if this was some kind of kernel internal stuff, but this is > > creating ABI and we have to maintain it forever. Rushing this in without > > proper discussion and consideration of the more complex use-cases is in my > > opinion not a good idea. > Using a graph of port to describe the audio subsystem has been pushed > forwards by many people for a long time, as shown by the creation of > the document Documentation/devicetree/bindings/graph.txt. That DT binding was done entirely in the context of video applications IIRC, this is the first time it's been discussed in this context. signature.asc Description: Digital signature
Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
Hi,
A few general things below (I'll leave the actual networking bits for
others to comment about).
On Friday 23 January 2015 10:07:01 Stathis Voukelatos wrote:
> ---
> .../bindings/net/linn-ether-packet-sniffer.txt | 27 ++
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> MAINTAINERS| 7 +
> drivers/net/Kconfig| 2 +
> drivers/net/Makefile | 1 +
> drivers/net/pkt-sniffer/Kconfig| 23 ++
> drivers/net/pkt-sniffer/Makefile | 8 +
> drivers/net/pkt-sniffer/backends/ether/channel.c | 366 ++
> drivers/net/pkt-sniffer/backends/ether/channel.h | 76
> drivers/net/pkt-sniffer/backends/ether/hw.h| 46 +++
> drivers/net/pkt-sniffer/backends/ether/platform.c | 231 +++
> drivers/net/pkt-sniffer/core/dev_table.c | 124 ++
> drivers/net/pkt-sniffer/core/module.c | 37 ++
> drivers/net/pkt-sniffer/core/nl.c | 427
> +
> drivers/net/pkt-sniffer/core/nl.h | 34 ++
> drivers/net/pkt-sniffer/core/snf_core.h| 64 +++
> include/linux/pkt_sniffer.h| 89 +
Probably worth splitting this up a bit into a series of multiple
logically separate patches. E.g. the vendor prefix, the core, the ether
backend and dt bindings.
> diff --git a/drivers/net/pkt-sniffer/Kconfig b/drivers/net/pkt-sniffer/Kconfig
> new file mode 100644
> index 000..26b4f98
> --- /dev/null
> +++ b/drivers/net/pkt-sniffer/Kconfig
> @@ -0,0 +1,23 @@
> +menuconfig PKT_SNIFFER
> +tristate "Linn packet sniffer support"
Should the kconfig symbol have linn in the name, or should the prompt
not have lin in the name?
> +---help---
> +Say Y to add support for Linn packet sniffer drivers.
> +
> +The core driver can also be built as a module. If so, the module
> +will be called snf_core.
> +
> +if PKT_SNIFFER
Just make PKT_SNIFFER_ETHER depend first on PKT_SNIFFER, then it'll
appear nested within it in menuconfig.
> +
> +config PKT_SNIFFER_ETHER
> +tristate "Ethernet packet sniffer"
> +depends on MIPS
worth adding || COMPILE_TEST to get compile coverage on x86 allmodconfig
builds, or does it have hard dependencies on the MIPS arch?
> +default n
No need, n is default
> +help
> +Say Y here if you want to use the Linn Ethernet packet sniffer
> +module. It can be found in the upcoming Pistachio SoC by
> +Imagination Technologies.
> +
> +The driver can also be built as a module. If so, the module
> +will be called snf_ether.
> +
> +endif # PKT_SNIFFER
> +/* Called when the packet sniffer device is bound with the driver */
> +static int esnf_driver_probe(struct platform_device *pdev)
> +{
> + struct ether_snf *esnf;
> + struct resource *res;
> + int ret, irq;
> + u32 fifo_blk_words;
> + void __iomem *regs;
> + struct device_node *ofn = pdev->dev.of_node;
> +
> + /* Allocate the device data structure */
> + esnf = devm_kzalloc(&pdev->dev, sizeof(*esnf), GFP_KERNEL);
> + if (!esnf)
> + return -ENOMEM;
> +
> + /* Retrieve and remap register memory space */
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> + if (!res)
> + return -ENODEV;
No need for this check. devm_ioremap_resource does it for you.
> +
> + regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
> +
> +static const struct of_device_id esnf_of_match_table[] = {
> + { .compatible = "linn,eth-sniffer", .data = NULL },
Nit: not strictly necessary to initialise .data since it's static.
Cheers
James
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, esnf_of_match_table);
> +
> +static struct platform_driver esnf_platform_driver = {
> + .driver = {
> + .name = esnf_driver_name,
> + .of_match_table = esnf_of_match_table,
> + },
> + .probe = esnf_driver_probe,
> + .remove = esnf_driver_remove,
> +};
> +
> +module_platform_driver(esnf_platform_driver);
> +
> +MODULE_DESCRIPTION("Linn Ethernet Packet Sniffer");
> +MODULE_AUTHOR("Linn Products Ltd");
> +MODULE_LICENSE("GPL v2");
--
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
Associating nodes with phandles for pci devices
Hi, I'm working on a new board that has a marvell,dsa switch. Similar to the kirkwood-mv88f6281gtw-ge board. However the major difference is that instead of being connected to an integrated Ethernet port it is connected via a PCI-e Ethernet port (basically a NIC hardwired onto the board). Generally you don't need to define PCI devices in the .dts because the bus is scanned at run time and the method for identifying devices is well defined. But to satisfy the marvell,dsa binding[1] I need to tell it the Ethernet port it is connected to. The answer might be in the PCI bindings but the urls in the documentation[2] don't appear to be valid anymore. Is it possible to enumerate PCI devices in the .dts? Or is there a way of satisfying the dsa requirements without knowing the Ethernet device? Thanks, Chris -- [1] - http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/dsa/dsa.txt [2] - http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/pci.txt-- 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] SATA: OCTEON: support SATA on OCTEON platform
The OCTEON SATA controller is currently found on cn71XX devices.
Signed-off-by: David Daney
Signed-off-by: Vinita Gupta
Signed-off-by: Aleksey Makarov
---
Version 1:
https://lkml.kernel.org/g/<1421681040-3392-1-git-send-email-aleksey.maka...@auriga.com>
Changes in v2:
- The driver was rewritten as a driver for the UCTL SATA controller glue.
It allowed to get rid of the most changes in ahci_platform.c
- Documentation for the device tree bindings was fixed.
.../devicetree/bindings/ata/ahci-platform.txt | 1 +
.../devicetree/bindings/mips/cavium/sata-uctl.txt | 28
drivers/ata/Kconfig| 9 ++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_platform.c| 1 +
drivers/ata/sata_octeon.c | 157 +
6 files changed, 197 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
create mode 100644 drivers/ata/sata_octeon.c
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 4ab09f2..1a5d3be 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -11,6 +11,7 @@ Required properties:
- compatible: compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "hisilicon,hisi-ahci"
+ - "cavium,octeon-7130-ahci"
- "ibm,476gtr-ahci"
- "marvell,armada-380-ahci"
- "snps,dwc-ahci"
diff --git a/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
new file mode 100644
index 000..59e86a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
@@ -0,0 +1,28 @@
+* UCTL SATA controller glue
+
+Properties:
+- compatible: "cavium,octeon-7130-sata-uctl"
+
+ Compatibility with the cn7130 SOC.
+
+- reg: The base address of the UCTL register bank.
+
+- #address-cells, #size-cells, and ranges must be present and hold
+ suitable values to map all child nodes.
+
+Example:
+
+ uctl@118006c00 {
+ compatible = "cavium,octeon-7130-sata-uctl";
+ reg = <0x11800 0x6c00 0x0 0x100>;
+ ranges; /* Direct mapping */
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ sata: sata@16c00 {
+ compatible = "cavium,octeon-7130-ahci";
+ reg = <0x16c00 0x 0x0 0x200>;
+ interrupt-parent = <&cibsata>;
+ interrupts = <2 4>; /* Bit: 2, level */
+ };
+ };
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a3a1360..28a11fe 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -188,6 +188,15 @@ config SATA_SIL24
If unsure, say N.
+config SATA_OCTEON
+ tristate "Cavium Octeon Soc Serial ATA"
+ depends on SATA_AHCI_PLATFORM && CAVIUM_OCTEON_SOC
+ default y
+ help
+ This option enables support for Cavium Octeon SoC Serial ATA.
+
+ If unsure, say N.
+
config ATA_SFF
bool "ATA SFF support (for legacy IDE and PATA)"
default y
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index ae41107..4a0e5e3 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o
libahci_platform.o
obj-$(CONFIG_AHCI_ST) += ahci_st.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_TEGRA) += ahci_tegra.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_XGENE) += ahci_xgene.o libahci.o libahci_platform.o
+obj-$(CONFIG_SATA_OCTEON) += sata_octeon.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 18d5398..adaa8c5 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -67,6 +67,7 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
{ .compatible = "hisilicon,hisi-ahci", },
+ { .compatible = "cavium,octeon-7130-ahci", },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
diff --git a/drivers/ata/sata_octeon.c b/drivers/ata/sata_octeon.c
new file mode 100644
index 000..59211f2
--- /dev/null
+++ b/drivers/ata/sata_octeon.c
@@ -0,0 +1,157 @@
+/*
+ * SATA glue for Cavium Octeon III SOCs.
+ *
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2010-2015 Cavium Networks
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * cvmx_sata_uctl_shim_cfg
+ * from cvmx-sata-defs.h
+ *
+ * Accessible by: only when A_CLKDIV_EN
Re: [PATCH v3 2/4] of: move of_dma_configure() to device,c to help re-use
On Fri, Jan 23, 2015 at 12:19 PM, Murali Karicheri wrote:
> On 01/09/2015 10:34 AM, Rob Herring wrote:
>>
>> On Thu, Jan 8, 2015 at 4:24 PM, Arnd Bergmann wrote:
>>>
>>> On Thursday 08 January 2015 14:26:36 Murali Karicheri wrote:
On 01/08/2015 03:40 AM, Arnd Bergmann wrote:
>
> On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:
>>
>> On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri
>> wrote:
>>
>>> + ret = of_dma_get_range(np,&dma_addr,&paddr,&size);
>>> + if (ret< 0) {
>>> + dma_addr = offset = 0;
>>> + size = dev->coherent_dma_mask + 1;
>>
>>
>> If coherent_dma_mask is DMA_BIT_MASK(64), then you will overflow and
>> have a size of 0. There may also be a problem when the mask is only
>> 32-bit type.
>
>
> The mask is always a 64-bit type, it's not optional. But you are right,
> the 64-bit mask case is broken, so I guess we have to fix it
> differently
> by always passing the smaller value into arch_setup_dma_ops and
> adapting that function instead.
Arnd,
What is the smaller value you are referring to in the below code?
between *dev->dma_mask and size from DT? But overflow can still happen
when size is to be calculated in arch_setup_dma_ops() for Non DT case or
when DT size is configured to be equivalent of DMA_BIT_MASK(64) + 1. Can
we discuss the code change you have in mind when you get a chance?
>>>
>>>
>>> I meant changing every function that the size values gets passed into
>>> to take a mask like 0x instead of a size like 0x1, so
>>> we can represent a 64-bit capable bus correctly.
>>
>>
>> Or you could special case a size of 0 to mean all/max? I'm not sure if
>> we need to handle size=0 for other reasons beyond just wrong DT data.
>>
>>> This means we also need to adapt the value returned from
>>> of_dma_get_range.
>>> A minor complication here is that the DT properties sometimes already
>>> contain the mask value, in particular when we want to represent a
>>> full mapping like
>>>
>>> bus {
>>> #address-cells =<1>;
>>> #size-cells =<1>;
>>> dma-ranges =<0 0 0x>; /* all 4 GB,
>>> DMA_BIT_MASK(32) */
>>
>>
>> This is wrong though, right? The DT should be size. Certainly, this
>> could be a valid size, but that would not make the mask 0xfffe. We
>> would still want it to be 0x.
>>
>> We could do a fixup for these cases adding 1 if bit 0 is set (or not
>> subtracting 1 if we want the mask).
>>
>> Rob
>
> Arnd, Rob, et all,
>
> Do we have preference one way or other for the size format? If we need to
> follow the mask format, all of the calling functions below and the
> arm_iommu_create_mapping() has to change as well to use this changed format.
>
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:mapping =
> arm_iommu_create_mapping(&platform_bus_type, 0x,
> drivers/gpu/drm/exynos/exynos_drm_iommu.c: mapping =
> arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
> drivers/media/platform/omap3isp/isp.c: mapping =
> arm_iommu_create_mapping(&platform_bus_type, SZ_1G, SZ_2G);
> drivers/iommu/shmobile-iommu.c: mapping =
> arm_iommu_create_mapping(&platform_bus_type, 0,
> drivers/iommu/ipmmu-vmsa.c: mapping =
> arm_iommu_create_mapping(&platform_bus_type,
>
> So IMO, keeping current convention of size and taking care of exception in
> DT handling is the right thing to do instead of changing all of the above
> functions. i.e in of_dma_configure(), if DT provide a mask for size (lsb
> set), we will check that and add 1 to it. Only case in DTS that I can see
> this usage is
>
> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi: dma-ranges = <0x80
> 0x0 0x80 0x0 0x7f 0x>;
> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi: dma-ranges =
> <0x4300 0x80 0x0 0x80 0x0 0x7f 0x>;
This should be fixed regardless. I doubt anyone is worried about 512GB
quite yet.
> This logic should take care of setting the size to ox80_ for these
> cases. if dma_coherent_mask is set to max of u64, then this will result in a
> zero size (both DT case and non DT case). So treat a size of zero as error
> being overflow.
I think this would work, but I really need to see patches.
> Also arm_iommu_create_mapping() currently accept a size of type size_t which
> means, this function expect the size to be max of 0x. So in
> arm_setup_iommu_dma_ops(), we need to check if size if >0x and
> return an error. If in future this function support u64 for size, this check
> can be removed.
The aim is to get rid of this function I believe.
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: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
On Fri, 23 Jan 2015 14:56:04 +0100 Lars-Peter Clausen wrote: > On 01/23/2015 01:15 PM, Jean-Francois Moine wrote: > [...] > > The DT should describe the hardware, and the simple-card mixes hardware > > and software. > > For example, the kirkwood controller may create 2 CPU DAIs. With the > > simple-card, the DT contains a number to reference these DAIs (for > > example, implicitly, references the I2S output). So, what if > > the controller creates only one DAI, or, what if the FreeBSD/OpenBSD/.. > > driver does not set the same references to these DAIs? > > The graph of port fixes this problem. > > Even with the simple-card bindings there are no software specific bits. The > DAI that is referenced in your example is the physical DAI as it exists in > the hardware. Which DAI maps to which specifier is defined in the devicetree > bindings definition for the hardware unit. There is no first or second output in the kirkwood controller; there are I2S and S/PDIF outputs. Their hardware controls are done by bits in the different registers. Then, the driver may define its DAIs in any order and assign any DAI ID to these DAIs. So, for a given DAI, there is no relation between its type (I2s or S/PDIF), index in the dai driver (= asoc component index) and ID. In the simple-card DT, the CPU DAI (as the CODEC DAI) is referenced by a phandle (the audio-controller) and a number which should identify the DAI. This number is translated to a DAI name thanks to the function snd_soc_get_dai_name(). This function scans the components and returns the name of the DAI (component) supported by the audio controller with the searched number equal to the component index (there is no 'xlate' function). So, with the simple-card, the CPU or CODEC DAI binding (phandle + number) identifies what the software has put in its table, but not a hardware entity. > > More: a simple audio card may easily be created from a graph of ports > > as the simple-card does, but by the audio-controller (sorry, I also > > forgot the kirkwood patch for this in my previous patch request). > > In case of complex cards, the links and properties of this graph may > > also be used by board specific card devices. > > > >> One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is > >> a > >> bus and can have more than one reader/writer. > >> > >> The second issue is how to describe the clock and frame master > >> relationships. Multiple different buses can share the same clock and frame > >> generator. E.g. typically the capture and playback stream are linked in > >> this > >> way. > > > > The ports and endpoints may contain properties to describe these > > configurations. Complex cases should be handled by specific card > > builders. > > Could you describe in detail what a card builder is and how to decide when > and how a card builder is executed? A card builder is a device which - scans the graph of ports, - fills the struct snd_soc_card according to the links between the ports and their properties, - and, eventually, calls snd_soc_register_card(). The simple card builder, 'dt-card' (maybe a better name would have been 'graph-card'), acts just like the simple-card except that it does not appear in the DT. Its creation is done by an audio controller. For complex cards, a card builder would be the same as an actual card driver, but with the capability to know about the board thanks to the graph of ports. Its creation could be done by a compatible device in the DT (as actually) or by the unique or a 'master' audio controller. A card builder is subject to a PROBE_DEFER after calling snd_soc_register_card(), so, when it is created by an audio controller, this last one should have created its own resources. An audio controller does the following: - initialize the hardware and software, - create the DAIs from: - the graph of ports or - default values - register these DAIs and - if the DAIs where created by a graph of port, create the card builder. > > On the other hand, where would this information appear in the graph? > > As I understood, on card creation, the widgets and routes, which appear > > at the card level, redefine the CPU and CODEC DAI definitions. > > What do you mean by "redefine the CPU and CODEC DAI definitions". > > > > > With a DT graph, each CPU/CODEC would know exactly the widgets and > > routes it has to define. > > Which widgets/routes do you mean? Well, forget about this. I never clearly understood why some widgets and routes had to be defined at card level. > >> Your example is a relative simple one where you do not have any additional > >> audio fabric on the board itself. > > > > Right, and that's why I'd be glad to have quickly something in the > > kernel. More properties could be added later as there would be requests. > > I'd agree if this was some kind of kernel internal stuff, but this is > creating ABI and we have to maintain it forever. Rushing this in without > prop
Re: [PATCH v3 2/4] of: move of_dma_configure() to device,c to help re-use
On 01/09/2015 10:34 AM, Rob Herring wrote:
On Thu, Jan 8, 2015 at 4:24 PM, Arnd Bergmann wrote:
On Thursday 08 January 2015 14:26:36 Murali Karicheri wrote:
On 01/08/2015 03:40 AM, Arnd Bergmann wrote:
On Wednesday 07 January 2015 17:37:56 Rob Herring wrote:
On Wed, Jan 7, 2015 at 12:49 PM, Murali Karicheri wrote:
+ ret = of_dma_get_range(np,&dma_addr,&paddr,&size);
+ if (ret< 0) {
+ dma_addr = offset = 0;
+ size = dev->coherent_dma_mask + 1;
If coherent_dma_mask is DMA_BIT_MASK(64), then you will overflow and
have a size of 0. There may also be a problem when the mask is only
32-bit type.
The mask is always a 64-bit type, it's not optional. But you are right,
the 64-bit mask case is broken, so I guess we have to fix it differently
by always passing the smaller value into arch_setup_dma_ops and
adapting that function instead.
Arnd,
What is the smaller value you are referring to in the below code?
between *dev->dma_mask and size from DT? But overflow can still happen
when size is to be calculated in arch_setup_dma_ops() for Non DT case or
when DT size is configured to be equivalent of DMA_BIT_MASK(64) + 1. Can
we discuss the code change you have in mind when you get a chance?
I meant changing every function that the size values gets passed into
to take a mask like 0x instead of a size like 0x1, so
we can represent a 64-bit capable bus correctly.
Or you could special case a size of 0 to mean all/max? I'm not sure if
we need to handle size=0 for other reasons beyond just wrong DT data.
This means we also need to adapt the value returned from of_dma_get_range.
A minor complication here is that the DT properties sometimes already
contain the mask value, in particular when we want to represent a
full mapping like
bus {
#address-cells =<1>;
#size-cells =<1>;
dma-ranges =<0 0 0x>; /* all 4 GB, DMA_BIT_MASK(32) */
This is wrong though, right? The DT should be size. Certainly, this
could be a valid size, but that would not make the mask 0xfffe. We
would still want it to be 0x.
We could do a fixup for these cases adding 1 if bit 0 is set (or not
subtracting 1 if we want the mask).
Rob
Arnd, Rob, et all,
Do we have preference one way or other for the size format? If we need
to follow the mask format, all of the calling functions below and the
arm_iommu_create_mapping() has to change as well to use this changed format.
drivers/gpu/drm/rockchip/rockchip_drm_drv.c: mapping =
arm_iommu_create_mapping(&platform_bus_type, 0x,
drivers/gpu/drm/exynos/exynos_drm_iommu.c: mapping =
arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
drivers/media/platform/omap3isp/isp.c: mapping =
arm_iommu_create_mapping(&platform_bus_type, SZ_1G, SZ_2G);
drivers/iommu/shmobile-iommu.c: mapping =
arm_iommu_create_mapping(&platform_bus_type, 0,
drivers/iommu/ipmmu-vmsa.c: mapping =
arm_iommu_create_mapping(&platform_bus_type,
So IMO, keeping current convention of size and taking care of exception
in DT handling is the right thing to do instead of changing all of the
above functions. i.e in of_dma_configure(), if DT provide a mask for
size (lsb set), we will check that and add 1 to it. Only case in DTS
that I can see this usage is
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi: dma-ranges = <0x80 0x0
0x80 0x0 0x7f 0x>;
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi: dma-ranges = <0x4300
0x80 0x0 0x80 0x0 0x7f 0x>;
This logic should take care of setting the size to ox80_ for
these cases. if dma_coherent_mask is set to max of u64, then this will
result in a zero size (both DT case and non DT case). So treat a size of
zero as error being overflow.
Also arm_iommu_create_mapping() currently accept a size of type size_t
which means, this function expect the size to be max of 0x. So
in arm_setup_iommu_dma_ops(), we need to check if size if >0x
and return an error. If in future this function support u64 for size,
this check can be removed.
I will update the series with this change and post it if we have an
agreement on this. Please repond.
Thanks
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
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] arm64: dts: Add initial device tree support for Tegra132
On 01/23/2015 10:34 AM, Mark Rutland wrote:
On Fri, Jan 23, 2015 at 04:57:19PM +, Stephen Warren wrote:
On 01/23/2015 04:31 AM, Paul Walmsley wrote:
+ Arto, Terje for comments on the host1x section
+ Stephen Warren for comments on the serial DT data
On Wed, 21 Jan 2015, Mark Rutland wrote:
As mentioned in my reply to the DT list patch [1], there are a couple of
bits I'd like to see cleaned up first, but in the meantime I have some
comments from my first pass of the dtsi below. Some of these may equally
apply to existing dts(i) files.
I see a few undocumented compatible strings (at least when comparing
against mainline). If there are other series or trees I should be
looking at, any pointers would be appreciated. If not, documentation
updates would be nice (checkpatch should complain otherwise).
On Fri, Jan 16, 2015 at 11:45:29AM +, Paul Walmsley wrote:
Add an initial device tree file for the Tegra132 SoC. The DT file is
based on arch/arm/boot/dts/tegra124.dtsi and
arch/arm/boot/dts/tegra114.dtsi, with the following significant
changes:
- Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster
- Devices are arranged by bus, rather than in a flat topology
- No polling delays have been defined for the thermal zones. I don't
believe that this is a property of the SoC hardware, but rather of a
given use-case.
diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi
b/arch/arm64/boot/dts/tegra/tegra132.dtsi
+ /*
+* There are two serial drivers: an 8250 based simple
+* serial driver and an APB DMA based serial driver
+* for higher baudrate and performance. To enable the
+* 8250 based driver, the compatible string is
+* "nvidia,tegra132-uart", "nvidia,tegra124-uart",
+* "nvidia,tegra20-uart" and to enable the APB DMA
+* based serial driver, the compatible string is
+* "nvidia,tegra132-hsuart", "nvidia,tegra124-hsuart",
+* "nvidia,tegra30-hsuart".
+*/
Is there any reason to continue with this split?
Surely if the only difference is DMA, the presence of dmas and dma-names
should be sufficient to get the driver to do the right thing, and if you
need to disable DMA for debugging that could be a command-line option.
I vaguely recall asking for the DMA support to be integrated into the
regular 8250 driver instead when the separate DMA-capable driver was
first added. I /think/ there was resistance to this because adding lots
of different SoC-specific ways to do DMA into the existing 8250 driver
would complicate it even more, and hence be unmaintainable.
I assume that reasoning is still valid.
Perhaps what we need is more fine-grained driver selection, not just
based on compatible value. Something like:
if compatible == nvidia,tegra20-uart:
if node.has_prop("enable-dma"):
driver = Tegra-specfic DMA capable UART driver
else:
driver = Common 8250 driver
Surely we should assume that if the DMAs are listed (and not disabled)
they are usable?
I would assume so, yes.
> I'm not sure I see the point in an additional property
to force Linux-internal driver selection in this way.
I think it comes down to whether you want to use DMA for that UART or
not. I don't recall the exact reason why this might be important.
Perhaps it's one/more of:
- The Tegra-specific DMA-capable driver can't be used for early debug
but the core 8250 driver can. I don't know if this is true though.
- There are a limited number of DMA channels on Tegra. If all ports
blindly used DMA simply because the dmas property was included, then
we'd risk running out of DMA channels for cases where it absolutely had
to be used; e.g. a low-volume debug console might prevent a high-volume
MODEM or BT UART from using DMA if they probed in the "wrong" order.
Laxman might be able to shed more light on this.
What happens if we have a driver for a particular string, but fail to
probe? Can we fall back to a more generic driver?
At least in this case, I'd assume so, yes.
Is that something that of_serial.c could/should be enhanced to do? That
said, the whole reasoning behind separate compatible properties before
was that compatible is supposed to "drive" driver selection. At least,
that's what I was told then.
The compatible string is meant to describe the programming interface the
device is compatible with. The kernel should then choose the most
appropriate driver it knows can handle that HW programming interface.
Considering it as a way to choose the driver is backwards. I'd expect
the device node to have both strings (with the DMA capable string first)
unless it really doesn't have any DMAs.
That's a subtly different interpretation of DT compatible usage than was
given (I think it was by Mitch Bradley???) when this driver was
introduced. In the conversation then, it was asserted that using
different
Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
On Fri, Jan 23, 2015 at 02:56:04PM +0100, Lars-Peter Clausen wrote: > On 01/23/2015 01:15 PM, Jean-Francois Moine wrote: > >>Your example is a relative simple one where you do not have any additional > >>audio fabric on the board itself. > >Right, and that's why I'd be glad to have quickly something in the > >kernel. More properties could be added later as there would be requests. > I'd agree if this was some kind of kernel internal stuff, but this is > creating ABI and we have to maintain it forever. Rushing this in without > proper discussion and consideration of the more complex use-cases is in my > opinion not a good idea. Just to repeat myself again: *please* try to provide more explanation for your commits, the concerns Lars is raising above are among the things that I'd have expected to be covered in a high quality changelog. There is no explanation at all in the changelog regarding the goal here, just statements that this is a graph based card without an actual card node. signature.asc Description: Digital signature
Re: [PATCH] arm64: dts: Add initial device tree support for Tegra132
On Fri, Jan 23, 2015 at 04:57:19PM +, Stephen Warren wrote:
> On 01/23/2015 04:31 AM, Paul Walmsley wrote:
> > + Arto, Terje for comments on the host1x section
> > + Stephen Warren for comments on the serial DT data
>
> > On Wed, 21 Jan 2015, Mark Rutland wrote:
> >
> >> As mentioned in my reply to the DT list patch [1], there are a couple of
> >> bits I'd like to see cleaned up first, but in the meantime I have some
> >> comments from my first pass of the dtsi below. Some of these may equally
> >> apply to existing dts(i) files.
> >>
> >> I see a few undocumented compatible strings (at least when comparing
> >> against mainline). If there are other series or trees I should be
> >> looking at, any pointers would be appreciated. If not, documentation
> >> updates would be nice (checkpatch should complain otherwise).
>
> >> On Fri, Jan 16, 2015 at 11:45:29AM +, Paul Walmsley wrote:
> >>>
> >>> Add an initial device tree file for the Tegra132 SoC. The DT file is
> >>> based on arch/arm/boot/dts/tegra124.dtsi and
> >>> arch/arm/boot/dts/tegra114.dtsi, with the following significant
> >>> changes:
> >>>
> >>> - Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster
> >>> - Devices are arranged by bus, rather than in a flat topology
> >>> - No polling delays have been defined for the thermal zones. I don't
> >>>believe that this is a property of the SoC hardware, but rather of a
> >>>given use-case.
>
> >>> diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi
> >>> b/arch/arm64/boot/dts/tegra/tegra132.dtsi
> >>> + /*
> >>> +* There are two serial drivers: an 8250 based simple
> >>> +* serial driver and an APB DMA based serial driver
> >>> +* for higher baudrate and performance. To enable the
> >>> +* 8250 based driver, the compatible string is
> >>> +* "nvidia,tegra132-uart", "nvidia,tegra124-uart",
> >>> +* "nvidia,tegra20-uart" and to enable the APB DMA
> >>> +* based serial driver, the compatible string is
> >>> +* "nvidia,tegra132-hsuart", "nvidia,tegra124-hsuart",
> >>> +* "nvidia,tegra30-hsuart".
> >>> +*/
> >>
> >> Is there any reason to continue with this split?
> >>
> >> Surely if the only difference is DMA, the presence of dmas and dma-names
> >> should be sufficient to get the driver to do the right thing, and if you
> >> need to disable DMA for debugging that could be a command-line option.
>
> I vaguely recall asking for the DMA support to be integrated into the
> regular 8250 driver instead when the separate DMA-capable driver was
> first added. I /think/ there was resistance to this because adding lots
> of different SoC-specific ways to do DMA into the existing 8250 driver
> would complicate it even more, and hence be unmaintainable.
>
> I assume that reasoning is still valid.
>
> Perhaps what we need is more fine-grained driver selection, not just
> based on compatible value. Something like:
>
> if compatible == nvidia,tegra20-uart:
>if node.has_prop("enable-dma"):
> driver = Tegra-specfic DMA capable UART driver
>else:
> driver = Common 8250 driver
Surely we should assume that if the DMAs are listed (and not disabled)
they are usable? I'm not sure I see the point in an additional property
to force Linux-internal driver selection in this way.
What happens if we have a driver for a particular string, but fail to
probe? Can we fall back to a more generic driver?
> Is that something that of_serial.c could/should be enhanced to do? That
> said, the whole reasoning behind separate compatible properties before
> was that compatible is supposed to "drive" driver selection. At least,
> that's what I was told then.
The compatible string is meant to describe the programming interface the
device is compatible with. The kernel should then choose the most
appropriate driver it knows can handle that HW programming interface.
Considering it as a way to choose the driver is backwards. I'd expect
the device node to have both strings (with the DMA capable string first)
unless it really doesn't have any DMAs.
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
[PATCH v3 3/5] irqchip: Add DT binding doc for dumb demuxer chips
Add documentation for the dumb demuxer.
Signed-off-by: Boris Brezillon
Acked-by: Nicolas Ferre
---
.../bindings/interrupt-controller/dumb-demux.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
new file mode 100644
index 000..6199923
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
@@ -0,0 +1,41 @@
+* Generic Dumb Interrupt Demultiplexer
+
+This Dumb demultiplexer simply forward all incoming interrupts to its
+enabled/unmasked children.
+It is only intended to be used by hardware that do not provide a proper way
+to demultiplex a source interrupt, and thus have to wake all their children
+up so that they can possibly handle the interrupt (if needed).
+This can be seen as an alternative to shared interrupts when at least one
+of the interrupt children is a timer (and require the irq to be stay enabled
+on suspend) while others are not. This will prevent calling irq handlers of
+non timer devices while they are suspended.
+
+Required properties:
+- compatible: Should be "virtual,dumb-irq-demux".
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupts-extended or interrupt-parent and interrupts: Reference the source
+ interrupt connected to this dumb demuxer.
+- #interrupt-cells: The number of cells to define the interrupts (should be 1).
+ The only cell is the IRQ number.
+- irqs: u32 bitfield specifying the interrupts provided by the demuxer.
+
+Examples:
+ /*
+* Dumb demuxer controller
+*/
+ dumb_irq1_demux: dumb-irq-demux@1 {
+ compatible = "virtual,dumb-irq-demux";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts-extended = <&aic 1 IRQ_TYPE_LEVEL_HIGH 7>;
+ irqs = <0x3f>;
+ };
+
+ /*
+* Device connected on this dumb demuxer
+*/
+ dma: dma-controller@ec00 {
+ compatible = "atmel,at91sam9g45-dma";
+ reg = <0xec00 0x200>;
+ interrupts-extended = <&dumb_irq1_demux 0>;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] genirq: Authorize chained handlers to remain disabled when initialized
Currently there is no way to keep a chained handler disabled when
registering it.
This might be annoying for irq demuxer that want to keep the source irq
disabled until at least one of their child irq is requested.
Replace the is_chained argument of __irq_set_handler by an enum, thus
adding a new CHAINED_NOSTARTUP mode which explicitly ask for the
interruption to remain disabled.
Update all __irq_set_handler users to use the enum value instead of a
numerical one and add a new irq_set_chained_handler_nostartup helper
function (as done for irq_set_handler and irq_set_chained_handler).
Signed-off-by: Boris Brezillon
---
include/linux/irq.h| 26 ++
kernel/irq/chip.c | 12 +++-
kernel/irq/irqdomain.c | 2 +-
kernel/irq/msi.c | 3 ++-
4 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index d09ec7a..247b2d1 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -489,25 +489,43 @@ static inline void irq_set_chip_and_handler(unsigned int
irq, struct irq_chip *c
extern int irq_set_percpu_devid(unsigned int irq);
+enum chained_mode {
+ IRQ_CHAINED_NONE,
+ IRQ_CHAINED_STARTUP,
+ IRQ_CHAINED_NOSTARTUP,
+};
+
extern void
-__irq_set_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained,
+__irq_set_handler(unsigned int irq, irq_flow_handler_t handle,
+ enum chained_mode chained_mode,
const char *name);
static inline void
irq_set_handler(unsigned int irq, irq_flow_handler_t handle)
{
- __irq_set_handler(irq, handle, 0, NULL);
+ __irq_set_handler(irq, handle, IRQ_CHAINED_NONE, NULL);
}
/*
* Set a highlevel chained flow handler for a given IRQ.
- * (a chained handler is automatically enabled and set to
+ * (this chained handler is automatically enabled and set to
* IRQ_NOREQUEST, IRQ_NOPROBE, and IRQ_NOTHREAD)
*/
static inline void
irq_set_chained_handler(unsigned int irq, irq_flow_handler_t handle)
{
- __irq_set_handler(irq, handle, 1, NULL);
+ __irq_set_handler(irq, handle, IRQ_CHAINED_STARTUP, NULL);
+}
+
+/*
+ * Set a highlevel chained flow handler for a given IRQ without starting it.
+ * (this chained handler is kept disabled and set to IRQ_NOREQUEST,
+ * IRQ_NOPROBE, and IRQ_NOTHREAD)
+ */
+static inline void
+irq_set_chained_handler_nostartup(unsigned int irq, irq_flow_handler_t handle)
+{
+ __irq_set_handler(irq, handle, IRQ_CHAINED_NOSTARTUP, NULL);
}
void irq_modify_status(unsigned int irq, unsigned long clr, unsigned long set);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6f1c7a5..5de82dc0 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -719,7 +719,8 @@ void handle_percpu_devid_irq(unsigned int irq, struct
irq_desc *desc)
}
void
-__irq_set_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained,
+__irq_set_handler(unsigned int irq, irq_flow_handler_t handle,
+ enum chained_mode chained_mode,
const char *name)
{
unsigned long flags;
@@ -748,7 +749,7 @@ __irq_set_handler(unsigned int irq, irq_flow_handler_t
handle, int is_chained,
* and the interrrupt supposed to be started
* right away.
*/
- if (WARN_ON(is_chained))
+ if (WARN_ON(chained_mode != IRQ_CHAINED_NONE))
goto out;
/* Try the parent */
irq_data = irq_data->parent_data;
@@ -768,11 +769,12 @@ __irq_set_handler(unsigned int irq, irq_flow_handler_t
handle, int is_chained,
desc->handle_irq = handle;
desc->name = name;
- if (handle != handle_bad_irq && is_chained) {
+ if (handle != handle_bad_irq && chained_mode != IRQ_CHAINED_NONE) {
irq_settings_set_noprobe(desc);
irq_settings_set_norequest(desc);
irq_settings_set_nothread(desc);
- irq_startup(desc, true);
+ if (chained_mode == IRQ_CHAINED_STARTUP)
+ irq_startup(desc, true);
}
out:
irq_put_desc_busunlock(desc, flags);
@@ -784,7 +786,7 @@ irq_set_chip_and_handler_name(unsigned int irq, struct
irq_chip *chip,
irq_flow_handler_t handle, const char *name)
{
irq_set_chip(irq, chip);
- __irq_set_handler(irq, handle, 0, name);
+ __irq_set_handler(irq, handle, IRQ_CHAINED_NONE, name);
}
EXPORT_SYMBOL_GPL(irq_set_chip_and_handler_name);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 7fac311..d5aee6c 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -943,7 +943,7 @@ void irq_domain_set_info(struct irq_domain *domain,
unsigned int virq,
void *handler_data, const char *handler_name)
{
irq_domain_set_hwirq_and_chip(domain, virq, hwirq, ch
[PATCH v3 2/5] irqchip: add dumb demultiplexer implementation
Some interrupt controllers are multiplexing several peripheral IRQs on
a single interrupt line.
While this is not a problem for most IRQs (as long as all peripherals
request the interrupt with IRQF_SHARED flag set), multiplexing timers and
other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
and !IRQF_NO_SUSPEND is prohibited).
Create a dumb irq demultiplexer which simply forwards interrupts to all
peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
and !IRQF_NO_SUSPEND mix on a given interrupt.
Signed-off-by: Boris Brezillon
Acked-by: Nicolas Ferre
---
drivers/irqchip/Kconfig | 4 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-dumb-demux.c | 72
include/linux/irq.h | 38 +++
include/linux/irqdomain.h| 1 +
kernel/irq/Kconfig | 5 ++
kernel/irq/Makefile | 1 +
kernel/irq/chip.c| 41
kernel/irq/dumb-demux-chip.c | 140 +++
kernel/irq/handle.c | 31 -
kernel/irq/internals.h | 3 +
11 files changed, 335 insertions(+), 2 deletions(-)
create mode 100644 drivers/irqchip/irq-dumb-demux.c
create mode 100644 kernel/irq/dumb-demux-chip.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index cc79d2a..8a9df88 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -70,6 +70,10 @@ config BRCMSTB_L2_IRQ
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
+config DUMB_DEMUX_IRQ
+ bool
+ select DUMB_IRQ_DEMUX_CHIP
+
config DW_APB_ICTL
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 9516a32..77f3c51 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_MVEBU)+= irq-armada-370-xp.o
obj-$(CONFIG_ARCH_MXS) += irq-mxs.o
obj-$(CONFIG_ARCH_S3C24XX) += irq-s3c24xx.o
obj-$(CONFIG_DW_APB_ICTL) += irq-dw-apb-ictl.o
+obj-$(CONFIG_DUMB_DEMUX_IRQ) += irq-dumb-demux.o
obj-$(CONFIG_METAG)+= irq-metag-ext.o
obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
obj-$(CONFIG_ARCH_MOXART) += irq-moxart.o
diff --git a/drivers/irqchip/irq-dumb-demux.c b/drivers/irqchip/irq-dumb-demux.c
new file mode 100644
index 000..e4b8905
--- /dev/null
+++ b/drivers/irqchip/irq-dumb-demux.c
@@ -0,0 +1,72 @@
+/*
+ * Dumb irq demux chip driver
+ *
+ * Copyright (C) 2015 Atmel
+ *
+ * Author: Boris Brezillon
+ *
+ * This file is licensed under GPLv2.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include "irqchip.h"
+
+static int __init dumb_irq_demux_of_init(struct device_node *node,
+struct device_node *parent)
+{
+ struct irq_chip_dumb_demux *demux;
+ unsigned int irq;
+ u32 valid_irqs;
+ int ret;
+
+ irq = irq_of_parse_and_map(node, 0);
+ if (!irq) {
+ pr_err("Failed to retrieve dumb irq demuxer source\n");
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(node, "irqs", &valid_irqs);
+ if (ret) {
+ pr_err("Invalid of missing 'irqs' property\n");
+ return ret;
+ }
+
+ demux = irq_alloc_dumb_demux_chip(irq, valid_irqs,
+ IRQ_NOREQUEST | IRQ_NOPROBE |
+ IRQ_NOAUTOEN, 0);
+ if (!demux) {
+ pr_err("Failed to allocate dumb irq demuxer struct\n");
+ return -ENOMEM;
+ }
+
+ demux->domain = irq_domain_add_linear(node, BITS_PER_LONG,
+ &irq_dumb_demux_domain_ops,
+ demux);
+ if (!demux->domain) {
+ ret = -ENOMEM;
+ goto err_free_demux;
+ }
+
+ ret = irq_set_handler_data(irq, demux);
+ if (ret) {
+ pr_err("Failed to assign handler data\n");
+ goto err_free_domain;
+ }
+
+ irq_set_chained_handler_nostartup(irq, irq_dumb_demux_handler);
+
+ return 0;
+
+err_free_domain:
+ irq_domain_remove(demux->domain);
+
+err_free_demux:
+ kfree(demux);
+
+ return ret;
+}
+IRQCHIP_DECLARE(dumb_irq_demux, "virtual,dumb-irq-demux",
dumb_irq_demux_of_init);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 247b2d1..281bed7 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -445,6 +445,10 @@ extern void handle_fasteoi_irq(unsigned int irq, struct
irq_desc *desc);
extern void handle_edge_irq(unsigned int irq, struct irq_desc *desc);
extern void handle_edge_eoi_irq(unsigned int irq, struct irq_desc *desc);
extern void handle_simple_irq(unsigned int irq, stru
[PATCH v3 5/5] ARM: at91/dt: define a dumb irq demultiplexer chip connected on irq1
IRQ is multiplexing several peripheral IRQs, but there's no way to
properly demultiplex those IRQs.
Use a dumb irq demux chip to achieve this demultiplexing operation.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/at91rm9200.dtsi | 20 +---
arch/arm/boot/dts/at91sam9260.dtsi | 26 +-
arch/arm/boot/dts/at91sam9261.dtsi | 26 +-
arch/arm/boot/dts/at91sam9263.dtsi | 29 +++--
arch/arm/boot/dts/at91sam9g45.dtsi | 29 +++--
arch/arm/boot/dts/at91sam9n12.dtsi | 25 +
arch/arm/boot/dts/at91sam9rl.dtsi | 29 +++--
arch/arm/boot/dts/at91sam9x5.dtsi | 26 +-
8 files changed, 170 insertions(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index 6c97d4a..9612d7c 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -94,7 +94,7 @@
pmc: pmc@fc00 {
compatible = "atmel,at91rm9200-pmc";
reg = <0xfc00 0x100>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 0>;
interrupt-controller;
#address-cells = <1>;
#size-cells = <0>;
@@ -353,7 +353,7 @@
st: timer@fd00 {
compatible = "atmel,at91rm9200-st";
reg = <0xfd00 0x100>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 1>;
};
tcb0: timer@fffa {
@@ -820,7 +820,7 @@
dbgu: serial@f200 {
compatible = "atmel,at91rm9200-usart";
reg = <0xf200 0x200>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dbgu>;
clocks = <&mck>;
@@ -944,4 +944,18 @@
#size-cells = <0>;
status = "disabled";
};
+
+ dumb_irq1_demux: dumb-irq-demux@1 {
+ compatible = "virtual,dumb-irq-demux";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ /*
+* Interrupt lines:
+* 0: PMC
+* 1: ST
+* 2: DBGU
+*/
+ irqs = <0x7>;
+ };
};
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index dd1313c..2cc31a3 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -97,7 +97,7 @@
pmc: pmc@fc00 {
compatible = "atmel,at91sam9260-pmc";
reg = <0xfc00 0x100>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 0>;
interrupt-controller;
#address-cells = <1>;
#size-cells = <0>;
@@ -364,7 +364,7 @@
pit: timer@fd30 {
compatible = "atmel,at91sam9260-pit";
reg = <0xfd30 0xf>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 1>;
clocks = <&mck>;
};
@@ -750,7 +750,7 @@
dbgu: serial@f200 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf200 0x200>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dbgu>;
clocks = <&mck>;
@@ -959,7 +959,7 @@
rtc@fd20 {
compatible = "atmel,at91sam9260-rtt";
reg = <0xfd20 0x10>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupts-extended = <&dumb_irq1_demux 3>;
clocks = <&clk32k>;
[PATCH v3 0/5] ARM: at91: fix irq_pm_install_action WARNING
Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON test which triggers a WARNING backtrace on at91 platforms. While this WARN_ON is absolutely necessary to warn users that they should not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs, there is no easy way to solve this issue on at91 platforms. The main reason is that the init timer is often using a shared irq line and thus request this irq with IRQF_NO_SUSPEND flag set, while other peripherals request the same irq line without this flag. As suggested by Thomas, the first 3 patches of this series add a dumb demultiplexer irqchip implementation. This demuxer registers to a source interrupt and then forwards all received interrupts to its children (it they are enabled). The last two patches rework at91 DTs and config to make use of this dumb demuxer implementation. Rob, I know you were not in favor of exposing this in the DT but we really need to quickly a solution: more and more people complain about this warning. If you see a better way to handle this case please share it. Best Regards, Boris Changes since v2: - removed unneeded dumb demux flags passed to irq_alloc_dumb_demux_chip - set nested lockdep class for all requested irqs - add some explanation to the DT binding doc - change the compatible string to clearly show that this chip is purely virtual - added dumb demuxer to all at91 impacted SoCs Changes since v1: - went for an dumb irq demuxer approach instead of trying to fix the current shared irq code Boris Brezillon (5): genirq: Authorize chained handlers to remain disabled when initialized irqchip: add dumb demultiplexer implementation irqchip: Add DT binding doc for dumb demuxer chips ARM: at91/dt: select DUMB_IRQ_DEMUX for all at91 SoCs ARM: at91/dt: define a dumb irq demultiplexer chip connected on irq1 .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ arch/arm/boot/dts/at91rm9200.dtsi | 20 ++- arch/arm/boot/dts/at91sam9260.dtsi | 26 +++- arch/arm/boot/dts/at91sam9261.dtsi | 26 +++- arch/arm/boot/dts/at91sam9263.dtsi | 29 - arch/arm/boot/dts/at91sam9g45.dtsi | 29 - arch/arm/boot/dts/at91sam9n12.dtsi | 25 +++- arch/arm/boot/dts/at91sam9rl.dtsi | 29 - arch/arm/boot/dts/at91sam9x5.dtsi | 26 +++- arch/arm/mach-at91/Kconfig | 2 + drivers/irqchip/Kconfig| 4 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-dumb-demux.c | 72 +++ include/linux/irq.h| 64 +- include/linux/irqdomain.h | 1 + kernel/irq/Kconfig | 5 + kernel/irq/Makefile| 1 + kernel/irq/chip.c | 53 +++- kernel/irq/dumb-demux-chip.c | 140 + kernel/irq/handle.c| 31 - kernel/irq/internals.h | 3 + kernel/irq/irqdomain.c | 2 +- kernel/irq/msi.c | 3 +- 23 files changed, 580 insertions(+), 53 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt create mode 100644 drivers/irqchip/irq-dumb-demux.c create mode 100644 kernel/irq/dumb-demux-chip.c -- 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/5] ARM: at91/dt: select DUMB_IRQ_DEMUX for all at91 SoCs
Older at91 SoCs need a virtual dumb irq demuxer to gracefully support the fact that irq1 is shared by several devices and a timer. Signed-off-by: Boris Brezillon Acked-by: Nicolas Ferre --- arch/arm/mach-at91/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 2395c68..8ff2c2a 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -28,6 +28,7 @@ config HAVE_AT91_H32MX config SOC_AT91SAM9 bool select ATMEL_AIC_IRQ + select DUMB_DEMUX_IRQ select COMMON_CLK_AT91 select CPU_ARM926T select GENERIC_CLOCKEVENTS @@ -98,6 +99,7 @@ if SOC_SAM_V4_V5 config SOC_AT91RM9200 bool "AT91RM9200" select ATMEL_AIC_IRQ + select DUMB_DEMUX_IRQ select COMMON_CLK_AT91 select CPU_ARM920T select GENERIC_CLOCKEVENTS -- 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 V4 4/4] mmc: pwrseq_simple: Add support for a reset GPIO pin
Hello Ulf, On Fri, Jan 23, 2015 at 6:01 PM, Ulf Hansson wrote: >> >> Any reason to not use the devm_gpiod_get_index() managed version instead? > > This struct device don't have a bound driver to it. Thus this device > won't be freed automagically from the ->remove() or failed ->probe() > path. > Right, I missed that. Thanks a lot for the clarification. Best regards, Javier -- 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/4] mmc: pwrseq_simple: Add support for a reset GPIO pin
On 23 January 2015 at 16:56, Javier Martinez Canillas
wrote:
> Hello Ulf,
>
> On Mon, Jan 19, 2015 at 10:13 AM, Ulf Hansson wrote:
>>
>> int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
>> {
>> struct mmc_pwrseq_simple *pwrseq;
>> + int ret = 0;
>>
>> pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
>> if (!pwrseq)
>> return -ENOMEM;
>>
>> + pwrseq->reset_gpio = gpiod_get_index(dev, "reset", 0,
>> GPIOD_OUT_HIGH);
>
> Any reason to not use the devm_gpiod_get_index() managed version instead?
This struct device don't have a bound driver to it. Thus this device
won't be freed automagically from the ->remove() or failed ->probe()
path.
>
> AFAICT mmc_free_host() will free the device so in that case you won't
> need to call gpiod_put() in mmc_pwrseq_simple_free().
>
> This will also make easier to extend pwrseq_simple to support multiple
> GPIOs like the DT binding implies.
>
Kind regards
Uffe
--
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] arm64: dts: Add initial device tree support for Tegra132
On 01/23/2015 04:31 AM, Paul Walmsley wrote:
+ Arto, Terje for comments on the host1x section
+ Stephen Warren for comments on the serial DT data
On Wed, 21 Jan 2015, Mark Rutland wrote:
As mentioned in my reply to the DT list patch [1], there are a couple of
bits I'd like to see cleaned up first, but in the meantime I have some
comments from my first pass of the dtsi below. Some of these may equally
apply to existing dts(i) files.
I see a few undocumented compatible strings (at least when comparing
against mainline). If there are other series or trees I should be
looking at, any pointers would be appreciated. If not, documentation
updates would be nice (checkpatch should complain otherwise).
On Fri, Jan 16, 2015 at 11:45:29AM +, Paul Walmsley wrote:
Add an initial device tree file for the Tegra132 SoC. The DT file is
based on arch/arm/boot/dts/tegra124.dtsi and
arch/arm/boot/dts/tegra114.dtsi, with the following significant
changes:
- Tegra132 uses a Denver CPU cluster rather than an ARMv7 CPU cluster
- Devices are arranged by bus, rather than in a flat topology
- No polling delays have been defined for the thermal zones. I don't
believe that this is a property of the SoC hardware, but rather of a
given use-case.
diff --git a/arch/arm64/boot/dts/tegra/tegra132.dtsi
b/arch/arm64/boot/dts/tegra/tegra132.dtsi
+ /*
+* There are two serial drivers: an 8250 based simple
+* serial driver and an APB DMA based serial driver
+* for higher baudrate and performance. To enable the
+* 8250 based driver, the compatible string is
+* "nvidia,tegra132-uart", "nvidia,tegra124-uart",
+* "nvidia,tegra20-uart" and to enable the APB DMA
+* based serial driver, the compatible string is
+* "nvidia,tegra132-hsuart", "nvidia,tegra124-hsuart",
+* "nvidia,tegra30-hsuart".
+*/
Is there any reason to continue with this split?
Surely if the only difference is DMA, the presence of dmas and dma-names
should be sufficient to get the driver to do the right thing, and if you
need to disable DMA for debugging that could be a command-line option.
I vaguely recall asking for the DMA support to be integrated into the
regular 8250 driver instead when the separate DMA-capable driver was
first added. I /think/ there was resistance to this because adding lots
of different SoC-specific ways to do DMA into the existing 8250 driver
would complicate it even more, and hence be unmaintainable.
I assume that reasoning is still valid.
Perhaps what we need is more fine-grained driver selection, not just
based on compatible value. Something like:
if compatible == nvidia,tegra20-uart:
if node.has_prop("enable-dma"):
driver = Tegra-specfic DMA capable UART driver
else:
driver = Common 8250 driver
Is that something that of_serial.c could/should be enhanced to do? That
said, the whole reasoning behind separate compatible properties before
was that compatible is supposed to "drive" driver selection. At least,
that's what I was told then.
Does the binding and/or driver support aliases so you can get consistent
numbering? It would be nice to have.
I believe either the serial core or serial driver(s) support DT aliases
now, yes.
Do these UARTs work with earlycon?
I do not know.
It would be nice to have a /chosen/stdout-path (ideally with rate) so as
to get output consistently without command line options being required.
Stephen Warren might be the best person to directly respond to these
issues. This is all legacy DT data from previous Tegra SoCs.
+ uarta: serial@0,70006000 {
+ compatible = "nvidia,tegra132-uart", "nvidia,tegra124-uart",
"nvidia,tegra20-uart";
+ reg = <0x0 0x70006000 0x0 0x40>;
+ reg-shift = <2>;
+ interrupts = ;
+ clocks = <&tegra_car TEGRA124_CLK_UARTA>;
+ resets = <&tegra_car 6>;
+ reset-names = "serial";
+ dmas = <&apbdma 8>, <&apbdma 8>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
--
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] ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node
Instead of hardcoding the values of the interrupt flags, use the
macros provided by
and for the
Armada 38x SDHCI node.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-38x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 79c4acf186e2..71d4eca5b497 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -516,7 +516,7 @@
sdhci@d8000 {
compatible = "marvell,armada-380-sdhci";
reg = <0xd8000 0x1000>, <0xdc000 0x100>;
- interrupts = <0 25 0x4>;
+ interrupts = ;
clocks = <&gateclk 17>;
mrvl,clk-delay-cycles = <0x1F>;
status = "disabled";
--
2.1.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 v3 4/7] mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes
From: Marcin Wojtas
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register.
This commit add the support of this register and for SDR50 or DDR50
mode use it as suggested by the erratum:
- Set the SDIO3 Clock Inv field in SDIO3 Configuration register to not
inverted.
- Set the Sample FeedBack Clock field to 0x1
[gregory.clem...@free-electrons.com: port from 3.10]
Signed-off-by: Gregory CLEMENT
---
drivers/mmc/host/sdhci-pxav3.c | 60 --
1 file changed, 52 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index cf017fc39143..a3ebb4404849 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -62,6 +62,7 @@ struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
u8 power_mode;
+ void __iomem *sdio3_conf_reg;
};
/*
@@ -72,6 +73,14 @@ struct sdhci_pxa {
#define SDHCI_WINDOW_BASE(i) (0x84 + ((i) << 3))
#define SDHCI_MAX_WIN_NUM 8
+/*
+ * Fields below belong to SDIO3 Configuration Register (third register
+ * region for the Armada 38x flavor)
+ */
+
+#define SDIO3_CONF_CLK_INV BIT(0)
+#define SDIO3_CONF_SD_FB_CLK BIT(2)
+
static int mv_conf_mbus_windows(struct platform_device *pdev,
const struct mbus_dram_target_info *dram)
{
@@ -122,16 +131,31 @@ static int armada_38x_quirks(struct platform_device *pdev,
struct sdhci_host *host)
{
struct device_node *np = pdev->dev.of_node;
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host->priv;
+ struct resource *res;
host->quirks |= SDHCI_QUIRK_MISSING_CAPS;
- /*
-* According to erratum 'FE-2946959' both SDR50 and DDR50
-* modes require specific clock adjustments in SDIO3
-* Configuration register, if the adjustment is not done,
-* remove them from the capabilities.
-*/
- host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
- host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "conf-sdio3");
+ if (res) {
+ pxa->sdio3_conf_reg = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pxa->sdio3_conf_reg))
+ return PTR_ERR(pxa->sdio3_conf_reg);
+ } else {
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+
+ dev_warn(&pdev->dev, "conf-sdio3 register not found\n");
+ dev_warn(&pdev->dev, "disabling SDR50 and DDR50 modes\n");
+ dev_warn(&pdev->dev, "consider updating your dtb\n");
+ }
/*
* According to erratum 'ERR-7878951' Armada 38x SDHCI
@@ -226,6 +250,8 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host
*host, u8 power_mode)
static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host->priv;
u16 ctrl_2;
/*
@@ -255,6 +281,24 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
break;
}
+ /*
+* Update SDIO3 Configuration register according to erratum
+* FE-2946959
+*/
+ if (pxa->sdio3_conf_reg) {
+ u8 reg_val = readb(pxa->sdio3_conf_reg);
+
+ if (uhs == MMC_TIMING_UHS_SDR50 ||
+ uhs == MMC_TIMING_UHS_DDR50) {
+ reg_val &= ~SDIO3_CONF_CLK_INV;
+ reg_val |= SDIO3_CONF_SD_FB_CLK;
+ } else {
+ reg_val |= SDIO3_CONF_CLK_INV;
+ reg_val &= ~SDIO3_CONF_SD_FB_CLK;
+ }
+ writeb(reg_val, pxa->sdio3_conf_reg);
+ }
+
sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
--
2.1.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 v3 6/7] ARM: mvebu: Update the SDHCI node on Armada 38x
The binding of the armada-380-sdhci has been extended with a new
register in order to be able to use the SDR50 and DDR50 mode. This
commit add the resource associated to this new register for the
Armada 38x.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-38x.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 71d4eca5b497..474b2ebf4a82 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -515,7 +515,10 @@
sdhci@d8000 {
compatible = "marvell,armada-380-sdhci";
- reg = <0xd8000 0x1000>, <0xdc000 0x100>;
+ reg-names = "sdhci", "mbus", "conf-sdio3";
+ reg = <0xd8000 0x1000>,
+ <0xdc000 0x100>,
+ <0x18454 0x4>;
interrupts = ;
clocks = <&gateclk 17>;
mrvl,clk-delay-cycles = <0x1F>;
--
2.1.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 v3 7/7] ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD
The Device Tree description of SDHCI on Armada 388 RD board was
missing. This commit adds the node for it.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-388-rd.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-rd.dts
b/arch/arm/boot/dts/armada-388-rd.dts
index c98a8f8d01a9..7dfede145ea3 100644
--- a/arch/arm/boot/dts/armada-388-rd.dts
+++ b/arch/arm/boot/dts/armada-388-rd.dts
@@ -51,6 +51,16 @@
clock-frequency = <10>;
};
+ sdhci@d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ broken-cd;
+ no-1-8-v;
+ wp-inverted;
+ bus-width = <8>;
+ status = "okay";
+ };
+
serial@12000 {
status = "okay";
};
--
2.1.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 v3 0/7] Fixes and improvements for SDHCI on Armada 38x
Hi, this series brings fixes and improvements for the SDHCI controller of the Armada 38x SoCs. The changes for this third version was done on the second patch, see the changelog for the details. The first two patches are fixes and should be also applied on the stable branch (I added stable in copy for this). The first one removes the SDR50 and DDR50 mode timing from the capabilities of the controller because the current implementation doesn't support it. The second one fix controller's caps according to the limitation of the hardware. The third one extends the Device Tree binding of the Armada 38x. It allows using the SDIO3 configuration register. The forth patch adds the support of this new register in the driver. Thanks to this one, specific clock adjustments can be done in order to support the SDR50 and DDR50 modes timing. The fifth patch is device tree clean-up. The sixth patch update the SDHCI node on Armada 38x in order to use the new register and then to be able to support the SDR50 and DDR50 modes timing. Finally, the seventh patch add the description of SDHCI for the Armada 388 RD board which was missing. Patches 1 to 4 should be merged through the mmc tree and patches 5 to 7 should be merged through mvebu and then arm-soc. Patch 4 depend on patch 2. Patch 2 depend on patch 1. And patch 1 depend on commit aa8165f91442 "mmc: sdhci-pxav3: do the mbus window configuration after enabling clocks" which have been merged. But as all this patch should be merged through the same tree it would not be a problem The patches 5 to 7 depend on the patches already merged in mvebu. As they are fixes, patches 1 and 2 should be merged in 3.18-rc or at least in 3.19 and then they will be part of 3.18.1. For the other patches it would be nice if they could be part of 3.19. Thanks, Gregory Changelog: v2 -> v3: - Use of_property_read_bool() instead of of_get_property - Brace the else case according to the Documentation/CodingStyle - Move the setting of MMC_CAP_1_8V_DDR before the armada_38x_quirks calls v1 -> v2: - Put back Marcin as author of patch 2 and 3 - Removed MMC_CAP_1_8V_DDR in the probe function Gregory CLEMENT (5): mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node ARM: mvebu: Update the SDHCI node on Armada 38x ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD Marcin Wojtas (2): mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes .../devicetree/bindings/mmc/sdhci-pxa.txt | 15 +++- arch/arm/boot/dts/armada-388-rd.dts| 10 +++ arch/arm/boot/dts/armada-38x.dtsi | 7 +- drivers/mmc/host/sdhci-pxav3.c | 86 +- 4 files changed, 109 insertions(+), 9 deletions(-) -- 2.1.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 v3 3/7] mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x
The SDHCI unit used on the Armada 38x needs using an extra register to
do specific clock adjustments in order to support the SDR50 and DDR50
modes. This patch extends the binding to allow using this register.
Signed-off-by: Gregory CLEMENT
---
Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 4dd6deb90719..3d1b449d6097 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -9,9 +9,13 @@ Required properties:
- reg:
* for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for
the SDHCI registers.
- * for "marvell,armada-380-sdhci", two register areas. The first one
-for the SDHCI registers themselves, and the second one for the
-AXI/Mbus bridge registers of the SDHCI unit.
+
+ * for "marvell,armada-380-sdhci", three register areas. The first
+one for the SDHCI registers themselves, the second one for the
+AXI/Mbus bridge registers of the SDHCI unit, the third one for the
+SDIO3 Configuration register
+- reg names: should be "sdhci", "mbus", "conf-sdio3". only mandatory
+ for "marvell,armada-380-sdhci"
- clocks: Array of clocks required for SDHCI; requires at least one for
I/O clock.
- clock-names: Array of names corresponding to clocks property; shall be
@@ -35,7 +39,10 @@ sdhci@d4280800 {
sdhci@d8000 {
compatible = "marvell,armada-380-sdhci";
- reg = <0xd8000 0x1000>, <0xdc000 0x100>;
+ reg-names = "sdhci", "mbus", "conf-sdio3";
+ reg = <0xd8000 0x1000>,
+ <0xdc000 0x100>;
+ <0x18454 0x4>;
interrupts = <0 25 0x4>;
clocks = <&gateclk 17>;
clock-names = "io";
--
2.1.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 v3 1/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register. However,
this register was not part of the device tree binding. Even if the
binding can (and will) be extended we still need handling the case
where this register was not available. In this case we use the
SDHCI_QUIRK_MISSING_CAPS quirk remove them from the capabilities.
This commit is based on the work done by Marcin Wojtas
Fixes: 5491ce3f79ee ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI
controller")
Cc: # v3.15+
Signed-off-by: Gregory CLEMENT
Signed-off-by: Marcin Wojtas
---
drivers/mmc/host/sdhci-pxav3.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index ca3424e7ef71..7b07325b4fba 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -118,6 +118,20 @@ static int mv_conf_mbus_windows(struct platform_device
*pdev,
return 0;
}
+static int armada_38x_quirks(struct sdhci_host *host)
+{
+ host->quirks |= SDHCI_QUIRK_MISSING_CAPS;
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ return 0;
+}
+
static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
@@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
clk_prepare_enable(pxa->clk_core);
if (of_device_is_compatible(np, "marvell,armada-380-sdhci")) {
+ ret = armada_38x_quirks(host);
+ if (ret < 0)
+ goto err_quirks;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
if (ret < 0)
goto err_mbus_win;
@@ -400,6 +417,7 @@ err_mbus_win:
if (!IS_ERR(pxa->clk_core))
clk_disable_unprepare(pxa->clk_core);
err_clk_get:
+err_quirks:
sdhci_pltfm_free(pdev);
return ret;
}
--
2.1.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 v3 2/7] mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951
From: Marcin Wojtas
According to erratum 'ERR-7878951' Armada 38x SDHCI controller has
different capabilities than the ones shown in its registers:
- it doesn't support the voltage switching: it can work either with
3.3V or 1.8V supply
- it doesn't support the SDR104 mode
- SDR50 mode doesn't need tuning
The SDHCI_QUIRK_MISSING_CAPS quirk is used for updating the
capabilities accordingly.
[gregory.clem...@free-electrons.com: port from 3.10]
Fixes: 5491ce3f79ee ("mmc: sdhci-pxav3: add support for the Armada 38x SDHCI
controller")
Cc: # v3.15+
Signed-off-by: Gregory CLEMENT
---
drivers/mmc/host/sdhci-pxav3.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 7b07325b4fba..cf017fc39143 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -118,8 +118,11 @@ static int mv_conf_mbus_windows(struct platform_device
*pdev,
return 0;
}
-static int armada_38x_quirks(struct sdhci_host *host)
+static int armada_38x_quirks(struct platform_device *pdev,
+struct sdhci_host *host)
{
+ struct device_node *np = pdev->dev.of_node;
+
host->quirks |= SDHCI_QUIRK_MISSING_CAPS;
/*
* According to erratum 'FE-2946959' both SDR50 and DDR50
@@ -129,6 +132,21 @@ static int armada_38x_quirks(struct sdhci_host *host)
*/
host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+
+ /*
+* According to erratum 'ERR-7878951' Armada 38x SDHCI
+* controller has different capabilities than the ones shown
+* in its registers
+*/
+ host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+ if (of_property_read_bool(np, "no-1-8-v")) {
+ host->caps &= ~SDHCI_CAN_VDD_180;
+ host->mmc->caps &= ~MMC_CAP_1_8V_DDR;
+ } else {
+ host->caps &= ~SDHCI_CAN_VDD_330;
+ }
+ host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_USE_SDR50_TUNING);
+
return 0;
}
@@ -332,8 +350,11 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
if (!IS_ERR(pxa->clk_core))
clk_prepare_enable(pxa->clk_core);
+ /* enable 1/8V DDR capable */
+ host->mmc->caps |= MMC_CAP_1_8V_DDR;
+
if (of_device_is_compatible(np, "marvell,armada-380-sdhci")) {
- ret = armada_38x_quirks(host);
+ ret = armada_38x_quirks(pdev, host);
if (ret < 0)
goto err_quirks;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
@@ -341,9 +362,6 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
goto err_mbus_win;
}
- /* enable 1/8V DDR capable */
- host->mmc->caps |= MMC_CAP_1_8V_DDR;
-
match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), &pdev->dev);
if (match) {
ret = mmc_of_parse(host->mmc);
--
2.1.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
Re: [PATCH v2 RESEND 1/8] dt: bindings: Supply shared ST IRQ defines
On Fri, 23 Jan 2015, Thomas Gleixner wrote: > On Thu, 22 Jan 2015, Lee Jones wrote: > > > These defines are used to allow values used for configuration to be > > easily human readable and will lessen the chance of logical mistakes. > > > > Signed-off-by: Lee Jones > > --- > > include/dt-bindings/interrupt-controller/irq-st.h | 30 > > +++ > > 1 file changed, 30 insertions(+) > > create mode 100644 include/dt-bindings/interrupt-controller/irq-st.h > > > > diff --git a/include/dt-bindings/interrupt-controller/irq-st.h > > b/include/dt-bindings/interrupt-controller/irq-st.h > > new file mode 100644 > > index 000..4c59ace > > --- /dev/null > > +++ b/include/dt-bindings/interrupt-controller/irq-st.h > > @@ -0,0 +1,30 @@ > > +/* > > + * include/linux/irqchip/irq-st.h > > Copy & Paste? > > Can we please stop adding these pointless filenames all over the > place? They are useless and wrong in a lot of cases. Less of a copy and paste and more and a `mv` without fixing up the file names. I guess they are silly, but they are rife, so someone must think they're a good idea. :) for file in `find drivers -name *.c`; do head $file | grep "\.c$"; done > Aside of that, this needs an ack from the DT folks. I think you'll be lucky. I haven't seen a DT review for some time now. Perhaps, as it's you, this might be different. ;) -- 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 v2 RESEND 2/8] irqchip: Supply new driver for STi based devices
On Fri, 23 Jan 2015, Thomas Gleixner wrote: > On Thu, 22 Jan 2015, Lee Jones wrote: > > > This driver is used to enable System Configuration Register controlled > > External, CTI (Core Sight), PMU (Performance Management), and PL310 L2 > > Cache IRQs prior to use. > > I'm wondering how this is related to irq_chip, It doesn't really. At least, it doesn't make use of the framework. It was the most relevant subsystem. > but well, I don't mind it being parked here. Thanks Thomas. I was hoping for that response. > Though I really cannot say anything about this DT translation > machinery for a single sysconfig register, other than it looks > completely overengineered to me. I understnad where you're coming from, but don't all drivers just 'twiddle some register bits'? > The only technical comment I have is: shouldn't all the stuff except > the resume function be marked __init or is any of this required post > init? It's not common to mark functions invoked at and affter *_probe() as __init. At least, not as far as I'm aware. -- 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 v2 3/5] usb: dwc3: Add quirk for Synopsis device disconnection errata
Hi,
On Wed, Jan 21, 2015 at 05:02:57PM +0800, Sneeker Yeh wrote:
> Hi Felipe:
>
> Thanks for reviewing these,
>
> 2015-01-19 22:50 GMT+08:00 Felipe Balbi :
> > Hi,
> >
> > On Mon, Jan 19, 2015 at 03:56:47PM +0800, Sneeker Yeh wrote:
> >> Synopsis Designware USB3 IP earlier than v3.00a which is configured in
> >> silicon
> >> with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to
> >> prevent
> >> xhci host controller from dying when device is disconnected.
> >>
> >> Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP configuration whose state
> >> cannot be checked from software in runtime, it has to be enabled via
> >> platform
> >> data or device tree.
> >>
> >> Signed-off-by: Sneeker Yeh
> >> ---
> >> Documentation/devicetree/bindings/usb/dwc3.txt | 17 +
> >> drivers/usb/dwc3/core.c|6 ++
> >> drivers/usb/dwc3/core.h|1 +
> >> drivers/usb/dwc3/host.c|4
> >> drivers/usb/dwc3/platform_data.h |1 +
> >> 5 files changed, 29 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> index cd7f045..1b78b29 100644
> >> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> @@ -37,6 +37,23 @@ Optional properties:
> >> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
> >> utmi_l1_suspend_n, false when asserts utmi_sleep_n
> >> - snps,hird-threshold: HIRD threshold
> >> + - snps,has_suspend_on_disconnect: true when IP is configured in silicon
> >> with
> >> + DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, it can inject a
> >> + specific quirk to prevent xhci host controller from
> >> + dying when usb device is disconnected from root hub.
> >> + Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP
> >> + configuration whose state cannot be checked from
> >> + software in runtime, it has to be enabled via
> >> platform
> >> + data or device tree.
> >> +
> >> + xhci host dying symptom here is caused by that
> >> + DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
> >> + configuration makes IP auto-suspended after PORTCSC
> >> is
> >> + cleared when usb device detached, then an
> >> asynchronous
> >> + disconnection procedure might fail using endpoint
> >> + command that suspened IP won't have any response to.
> >> +
> >> + this issue is fixed when IP version >= 3.00a.
> >>
> >> This is usually a subnode to DWC3 glue to which it is connected.
> >>
> >> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> >> index 25ddc39..fbceab1 100644
> >> --- a/drivers/usb/dwc3/core.c
> >> +++ b/drivers/usb/dwc3/core.c
> >> @@ -838,6 +838,9 @@ static int dwc3_probe(struct platform_device *pdev)
> >> "snps,tx_de_emphasis_quirk");
> >> of_property_read_u8(node, "snps,tx_de_emphasis",
> >> &tx_de_emphasis);
> >> +
> >> + dwc->suspend_on_disconnect_quirk =
> >> of_property_read_bool(node,
> >> + "snps,has_suspend_on_disconnect");
> >> } else if (pdata) {
> >> dwc->maximum_speed = pdata->maximum_speed;
> >> dwc->has_lpm_erratum = pdata->has_lpm_erratum;
> >> @@ -864,6 +867,9 @@ static int dwc3_probe(struct platform_device *pdev)
> >> dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
> >> if (pdata->tx_de_emphasis)
> >> tx_de_emphasis = pdata->tx_de_emphasis;
> >> +
> >> + dwc->suspend_on_disconnect_quirk =
> >> + pdata->has_suspend_on_disconnect;
> >> }
> >>
> >> /* default to superspeed if no maximum_speed passed */
> >> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> >> index 8090249..d7458ff 100644
> >> --- a/drivers/usb/dwc3/core.h
> >> +++ b/drivers/usb/dwc3/core.h
> >> @@ -832,6 +832,7 @@ struct dwc3 {
> >>
> >> unsignedtx_de_emphasis_quirk:1;
> >> unsignedtx_de_emphasis:2;
> >> + unsignedsuspend_on_disconnect_quirk:1;
> >
> > you're missing the comment on the structure and these should be
> > alphabetically sorted.
>
> okay, I see, I'll change it like this:
>
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -692,6 +692,9 @@ struct dwc3_scratchpad_array {
> * @resize_fifos: tells us it's ok to reconfigure our TxFIFO sizes.
> * @setup_packet_pending: true when there's a Setup Packet in FIFO.
> Workaround
> * @start_config_issued: true when StartConfig command has been issued
> +
Re: [PATCH 0/5] extcon: usb: Introduce USB GPIO extcon driver. Fix DRA7 USB.
On Fri, Jan 23, 2015 at 09:26:56AM +0200, Roger Quadros wrote: > Felipe, > > On 22/01/15 22:29, Felipe Balbi wrote: > > On Thu, Jan 22, 2015 at 04:57:56PM +0200, Roger Quadros wrote: > >> > >> On 22/01/15 15:32, Roger Quadros wrote: > >>> Felipe, > >>> > >>> On 20/01/15 21:02, Felipe Balbi wrote: > On Mon, Jan 19, 2015 at 07:52:17PM +0200, Roger Quadros wrote: > > Hi, > > > > On DRA7 EVMs the USB ID pin is connected to a GPIO line. The USB drivers > > (dwc3 + dwc3-omap) depend on extcon framework to get the USB cable state > > (USB or USB-Host) to put the controller in the right mode. > > > > There were earlier attempts [1] to get this working by trying to patch > > up > > the existing GPIO extcon driver. > > > > This series attemts to take a different approach by introducing a new > > USB specific extcon driver to handle the USB ID GPIO pin and > > interpret a right USB cable state. > > > > The reasoning to introduce this new driver is: > > 1) The existing GPIO extcon driver doesn't understand USB cable states > > and it can't handle more than one cable per instance. > > > > For the USB case we need to handle at least 2 cable states. > > a) USB (attach/detach) > > b) USB-Host (attach/detach) > > and could possible include more states like > > c) Fast-charger (attach/detach) > > d) Slow-charger (attach/detach) > > > > 2) This USB specific driver can be easily updated in the future to > > handle VBUS events, or charger detect events, in case it happens > > to be available on GPIO for any platform. > > > > 3) The DT implementation is very easy. You just need one extcon node > > per USB > > instead of one extcon node per cable state as in case of [1]. > > > > 4) The cable state string doesn't need to be encoded in the device tree > > as in case of [1]. > > > > 5) With only ID event available, you can simulate a USB-peripheral > > attach > > when USB-Host is detacted instead of hacking the USB driver to do the > > same. > > > > Tested on DRA7-evm and DRA72-evm. > > while at that, you might want to patch X15 too. > > >>> USB2 port is meant for peripheral use only. ID pin from USB port is not > >>> connected to GPIO. > >>> > >> > >> OK answering myself here :). > >> Peripheral mode doesn't work on x15-bb as the USB driver (dwc3-omap) > >> doesn't set the mailbox correctly even when dwc3 node is set as otg = > >> "peripheral". > >> > >> Looks like we need to implement usb-gpio-extcon for x15 even though ID is > >> hard coded. > > > > right, another option is to have dwc3-omap read the child's DTS to check > > dr_mode and hardcode things based on that. > > > I think that option is better as it doesn't require a GPIO line to be > reserved for ID when USB is not meant for dual-role use. yeah, let's implement that for 3.21. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4] of: i2c: Add i2c-mux-idle-disconnect DT property to PCA954x mux driver
On Fri, Jan 23, 2015 at 04:41:29PM +0100, Alexander Sverdlin wrote: > of: i2c: Add i2c-mux-idle-disconnect DT property to PCA954x mux driver > > Add i2c-mux-idle-disconnect device tree property to PCA954x mux driver. The > new > property forces the multiplexer to disconnect child buses in idle state. This > is > used, for example, when there are several multiplexers on the same bus and the > devices on the underlying buses might have same I2C addresses. > > Signed-off-by: Alexander Sverdlin Applied to for-next, thanks! Added a newline after declaring idle_disconnect_pd. signature.asc Description: Digital signature
[PATCH 1/2] of: Allow selection of OF_DYNAMIC and OF_OVERLAY if OF_UNITTEST
Currently OF_DYNAMIC and OF_OVERLAY are not visible to the user, and are selected automatically only when needed. Allow them to be enabled manually to improve device tree unit test coverage. Signed-off-by: Geert Uytterhoeven --- drivers/of/Kconfig | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig index 38d1c51f58b108db..e9301686493933cc 100644 --- a/drivers/of/Kconfig +++ b/drivers/of/Kconfig @@ -34,7 +34,11 @@ config OF_PROMTREE # Hardly any platforms need this. It is safe to select, but only do so if you # need it. config OF_DYNAMIC - bool + bool "Support for dynamic device trees" if OF_UNITTEST + help + On some platforms, the device tree can be manipulated at runtime. + While this option is selected automatically on such platforms, you + can enable it manually to improve device tree unit test coverage. config OF_ADDRESS def_bool y @@ -84,9 +88,14 @@ config OF_RESOLVE bool config OF_OVERLAY - bool + bool "Support for device tree overlays" if OF_UNITTEST depends on OF select OF_DYNAMIC select OF_RESOLVE + help + Overlays are a method to dynamically modify part of the kernel's + device tree with dynamically loaded data. + While this option is selected automatically when needed, you can + enable it manually to improve device tree unit test coverage. endmenu # OF -- 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 RFC 2/2] of/unittest: Add reference count tests
Add tests to detect reference count imbalances. The tests use a fixed
list of paths to devices nodes (required device nodes in a minimal DTS,
and device nodes present in unittest-data).
These tests are executed only if CONFIG_OF_DYNAMIC=y.
Signed-off-by: Geert Uytterhoeven
---
drivers/of/unittest.c | 155 ++
1 file changed, 155 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 7aa1d6dae5ba72af..464703c6e7021760 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -1383,6 +1383,154 @@ out:
static inline void __init of_selftest_overlay(void) { }
#endif
+#ifdef CONFIG_OF_DYNAMIC
+static struct {
+ const char *path;
+ int refcnt;
+} refcnt_tests[] __initdata = {
+ /* required nodes */
+ { "/" },
+ { "/aliases" },
+ { "/chosen" },
+ { "/cpus" },
+ { "/cpus/cpu@0" },
+ { "/testcase-data" },
+ /* unittest-data */
+ { "/testcase-data/interrupts" },
+ { "/testcase-data/interrupts/intc0" },
+ { "/testcase-data/interrupts/intc1" },
+ { "/testcase-data/interrupts/intc2" },
+ { "/testcase-data/interrupts/interrupts0" },
+ { "/testcase-data/interrupts/interrupts1" },
+ { "/testcase-data/interrupts/interrupts-extended0" },
+ { "/testcase-data/interrupts/intmap0" },
+ { "/testcase-data/interrupts/intmap1" },
+ { "/testcase-data/platform-tests" },
+ { "/testcase-data/platform-tests/test-device@0" },
+ { "/testcase-data/platform-tests/test-device@0/dev@100" },
+ { "/testcase-data/platform-tests/test-device@1" },
+ { "/testcase-data/platform-tests/test-device@1/dev@100" },
+ { "/testcase-data/phandle-tests" },
+ { "/testcase-data/phandle-tests/consumer-a" },
+ { "/testcase-data/phandle-tests/provider0" },
+ { "/testcase-data/phandle-tests/provider1" },
+ { "/testcase-data/phandle-tests/provider2" },
+ { "/testcase-data/phandle-tests/provider3" },
+ { "/testcase-data/match-node" },
+ { "/testcase-data/match-node/a" },
+ { "/testcase-data/match-node/a/name2" },
+ { "/testcase-data/match-node/b" },
+ { "/testcase-data/match-node/b/name2" },
+ { "/testcase-data/match-node/c" },
+ { "/testcase-data/match-node/c/name2" },
+ { "/testcase-data/match-node/name0" },
+ { "/testcase-data/match-node/name1" },
+ { "/testcase-data/match-node/name3" },
+ { "/testcase-data/match-node/name4" },
+ { "/testcase-data/match-node/name5" },
+ { "/testcase-data/match-node/name6" },
+ { "/testcase-data/match-node/name7" },
+ { "/testcase-data/match-node/name8" },
+ { "/testcase-data/match-node/name9" },
+ { "/testcase-data/changeset" },
+ { "/testcase-data/changeset/node-remove" },
+ { "/testcase-data/overlay-node" },
+ { "/testcase-data/overlay-node/test-bus" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest100" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest101" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest0" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest1" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest2" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest3" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest5" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest6" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest7" },
+ { "/testcase-data/overlay-node/test-bus/test-selftest8" },
+ { "/testcase-data/overlay0" },
+ { "/testcase-data/overlay0/fragment@0" },
+ { "/testcase-data/overlay0/fragment@0/__overlay__" },
+ { "/testcase-data/overlay1" },
+ { "/testcase-data/overlay1/fragment@0" },
+ { "/testcase-data/overlay1/fragment@0/__overlay__" },
+ { "/testcase-data/overlay2" },
+ { "/testcase-data/overlay2/fragment@0" },
+ { "/testcase-data/overlay2/fragment@0/__overlay__" },
+ { "/testcase-data/overlay3" },
+ { "/testcase-data/overlay3/fragment@0" },
+ { "/testcase-data/overlay3/fragment@0/__overlay__" },
+ { "/testcase-data/overlay4" },
+ { "/testcase-data/overlay4/fragment@0" },
+ { "/testcase-data/overlay4/fragment@0/__overlay__" },
+ { "/testcase-data/overlay4/fragment@0/__overlay__/test-selftest4" },
+ { "/testcase-data/overlay5" },
+ { "/testcase-data/overlay5/fragment@0" },
+ { "/testcase-data/overlay5/fragment@0/__overlay__" },
+ { "/testcase-data/overlay6" },
+ { "/testcase-data/overlay6/fragment@0" },
+ { "/testcase-data/overlay6/fragment@0/__overlay__" },
+ { "/testcase-data/overlay7" },
+ { "/testcase-data/overlay7/fragment@0" },
+ { "/testcase-data/overlay7/fragment@0/__overlay__" },
+ { "/testcase-data/overlay8" },
+ { "/testcase-data/overlay8/fr
Re: [PATCH v2 RESEND 2/8] irqchip: Supply new driver for STi based devices
On Thu, 22 Jan 2015, Lee Jones wrote: > This driver is used to enable System Configuration Register controlled > External, CTI (Core Sight), PMU (Performance Management), and PL310 L2 > Cache IRQs prior to use. I'm wondering how this is related to irq_chip, but well, I don't mind it being parked here. Though I really cannot say anything about this DT translation machinery for a single sysconfig register, other than it looks completely overengineered to me. The only technical comment I have is: shouldn't all the stuff except the resume function be marked __init or is any of this required post init? Thanks, tglx -- 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 RFC 0/2] of/unittest: Add reference count tests
Hi Grant, Rob, This patch series adds tests to detect reference count imbalances. The tests use a fixed list of paths to devices nodes (required device nodes in a minimal DTS, and device nodes present in unittest-data). I considered scanning for all present device node instead, but these are more likely to change while running the test. These tests are executed only if CONFIG_OF_DYNAMIC=y. Patches are against devicetree/next, with "[PATCH] of: Add missing of_node_put() in of_find_node_by_path()" (or the alternative proposed by Grant) applied. Note that it shows 44 failures, which I haven't investigated yet: ### dt-test ### start of selftest - you will see error messages ### dt-test ### FAIL of_selftest_refcnt():1512 /testcase-data/duplicate-name#1: not found ### dt-test ### FAIL of_selftest_refcnt():1512 /testcase-data/duplicate-name#1: not found ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data: expected:23 got:25 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/interrupts/intc0: expected:2 got:19 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/interrupts/intc1: expected:2 got:9 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/interrupts/intc2: expected:2 got:8 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/interrupts/intmap0: expected:4 got:7 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/interrupts/intmap1: expected:4 got:5 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/platform-tests: expected:4 got:5 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/phandle-tests/consumer-a: expected:4 got:6 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/phandle-tests/provider0: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/phandle-tests/provider1: expected:2 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/phandle-tests/provider2: expected:2 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/phandle-tests/provider3: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/a/name2: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/b/name2: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/c/name2: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name0: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name1: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name3: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name4: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name5: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name6: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name7: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name8: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/match-node/name9: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay-node/test-bus: expected:12 got:16 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay-node/test-bus/test-selftest100: expected:2 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay-node/test-bus/test-selftest0: expected:2 got:6 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay-node/test-bus/test-selftest1: expected:2 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay-node/test-bus/test-selftest2: expected:2 got:6 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay-node/test-bus/test-selftest3: expected:2 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay0/fragment@0/__overlay__: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay1/fragment@0/__overlay__: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay2/fragment@0/__overlay__: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay3/fragment@0/__overlay__: expected:2 got:3 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay4/fragment@0/__overlay__: expected:3 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay6: expected:3 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay7: expected:3 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay8: expected:3 got:4 ### dt-test ### FAIL of_selftest_refcnt():1522 /testcase-data/overlay9: expected:3 got:4 ### dt-test ### FAIL of_selftest_refcnt():1512 /testcase-data/duplicate-name#1: not found ### dt-test ### FAIL of_selfte
Re: [PATCH] ARM: dts: Add sd0_rst pinctrl node to exynos5420
Hello Sjoerd, On Fri, Jan 23, 2015 at 4:47 PM, Sjoerd Simons wrote: >> >> If this pin is used by the Odroid XU3 board, shouldn't be defined in >> the exynos5422-odroidxu3.dts instead? > > It's not just used by the XU3 though, it's also hooked up on the peach > pi chromebook for example and i would expect it to be hooked up on most > board with an eMMC > > This change is consistent with most of the special purpose GPIO pins > defined in that file, so i don't see the problem with including it in > that pinctrl file In that case I completely agree that it should be defined in the .dtsi but that is not what the commit message said though :-) Best regards, Javier -- 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 RESEND 1/8] dt: bindings: Supply shared ST IRQ defines
On Thu, 22 Jan 2015, Lee Jones wrote: > These defines are used to allow values used for configuration to be > easily human readable and will lessen the chance of logical mistakes. > > Signed-off-by: Lee Jones > --- > include/dt-bindings/interrupt-controller/irq-st.h | 30 > +++ > 1 file changed, 30 insertions(+) > create mode 100644 include/dt-bindings/interrupt-controller/irq-st.h > > diff --git a/include/dt-bindings/interrupt-controller/irq-st.h > b/include/dt-bindings/interrupt-controller/irq-st.h > new file mode 100644 > index 000..4c59ace > --- /dev/null > +++ b/include/dt-bindings/interrupt-controller/irq-st.h > @@ -0,0 +1,30 @@ > +/* > + * include/linux/irqchip/irq-st.h Copy & Paste? Can we please stop adding these pointless filenames all over the place? They are useless and wrong in a lot of cases. Aside of that, this needs an ack from the DT folks. Thanks, tglx -- 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/4] mmc: pwrseq_simple: Add support for a reset GPIO pin
Hello Ulf,
On Mon, Jan 19, 2015 at 10:13 AM, Ulf Hansson wrote:
>
> int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
> {
> struct mmc_pwrseq_simple *pwrseq;
> + int ret = 0;
>
> pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
> if (!pwrseq)
> return -ENOMEM;
>
> + pwrseq->reset_gpio = gpiod_get_index(dev, "reset", 0, GPIOD_OUT_HIGH);
Any reason to not use the devm_gpiod_get_index() managed version instead?
AFAICT mmc_free_host() will free the device so in that case you won't
need to call gpiod_put() in mmc_pwrseq_simple_free().
This will also make easier to extend pwrseq_simple to support multiple
GPIOs like the DT binding implies.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add sd0_rst pinctrl node to exynos5420
On Fri, 2015-01-23 at 23:23 +0900, Jaehoon Chung wrote:
> Add sd0_rst node to exynos5420-pinctrl.dtsi.
> (It's used on odroid-xu3 board)
>
> Signed-off-by: Jaehoon Chung
> ---
> arch/arm/boot/dts/exynos5420-pinctrl.dtsi |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> index ba686e4..315cad7 100644
> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> @@ -194,6 +194,11 @@
> samsung,pin-drv = <3>;
> };
>
> + sd0_rst: sd0-rst {
> + samsung,pins = "gpd1-0";
> + samsung,pin-function = <1>;
I think this should be samsung,pin-function = <2>; for that
functionality.
--
Sjoerd Simons
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] ARM: dts: Add sd0_rst pinctrl node to exynos5420
On Fri, 2015-01-23 at 15:36 +0100, Javier Martinez Canillas wrote: > Hello Jaehoon, > > On Fri, Jan 23, 2015 at 3:23 PM, Jaehoon Chung wrote: > > Add sd0_rst node to exynos5420-pinctrl.dtsi. > > (It's used on odroid-xu3 board) > > > > It would be good to mention which device needs this pinctrl line. > > > Signed-off-by: Jaehoon Chung > > --- > > arch/arm/boot/dts/exynos5420-pinctrl.dtsi |5 + > > If this pin is used by the Odroid XU3 board, shouldn't be defined in > the exynos5422-odroidxu3.dts instead? It's not just used by the XU3 though, it's also hooked up on the peach pi chromebook for example and i would expect it to be hooked up on most board with an eMMC This change is consistent with most of the special purpose GPIO pins defined in that file, so i don't see the problem with including it in that pinctrl file -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
[PATCH v4] of: i2c: Add i2c-mux-idle-disconnect DT property to PCA954x mux driver
of: i2c: Add i2c-mux-idle-disconnect DT property to PCA954x mux driver
Add i2c-mux-idle-disconnect device tree property to PCA954x mux driver. The new
property forces the multiplexer to disconnect child buses in idle state. This is
used, for example, when there are several multiplexers on the same bus and the
devices on the underlying buses might have same I2C addresses.
Signed-off-by: Alexander Sverdlin
---
Changes in v4:
- fix compilation warnings
Changes in v3:
- preserve legacy platform data deselect_on_exit flag
- change property name to i2c-mux-idle-disconnect
Changes in v2:
- dropped idle-state binding
- headers in alphabetical order
- removed old platform data deselect_on_exit flag
.../devicetree/bindings/i2c/i2c-mux-pca954x.txt|3 +++
drivers/i2c/muxes/i2c-mux-pca954x.c| 10 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
index 34a3fb6..cf53d5f 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -16,6 +16,9 @@ Required Properties:
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the reset input.
+ - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
+children in idle state. This is necessary for example, if there are several
+multiplexers on the bus and the devices behind them use same I2C addresses.
Example:
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index ec11b40..b81f888 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -186,6 +187,8 @@ static int pca954x_probe(struct i2c_client *client,
{
struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
struct pca954x_platform_data *pdata = dev_get_platdata(&client->dev);
+ struct device_node *of_node = client->dev.of_node;
+ bool idle_disconnect_dt;
struct gpio_desc *gpio;
int num, force, class;
struct pca954x *data;
@@ -217,8 +220,12 @@ static int pca954x_probe(struct i2c_client *client,
data->type = id->driver_data;
data->last_chan = 0; /* force the first selection */
+ idle_disconnect_dt = of_node &&
+ of_property_read_bool(of_node, "i2c-mux-idle-disconnect");
+
/* Now create an adapter for each channel */
for (num = 0; num < chips[data->type].nchans; num++) {
+ bool idle_disconnect_pd = false;
force = 0;/* dynamic adap number */
class = 0;/* no class by default */
if (pdata) {
@@ -229,12 +236,13 @@ static int pca954x_probe(struct i2c_client *client,
} else
/* discard unconfigured channels */
break;
+ idle_disconnect_pd = pdata->modes[num].deselect_on_exit;
}
data->virt_adaps[num] =
i2c_add_mux_adapter(adap, &client->dev, client,
force, num, class, pca954x_select_chan,
- (pdata && pdata->modes[num].deselect_on_exit)
+ (idle_disconnect_pd || idle_disconnect_dt)
? pca954x_deselect_mux : NULL);
if (data->virt_adaps[num] == NULL) {
--
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] ARM: dts: sun4i: Add Hyundau A7HD board
The Hyundai A7HD is a 7" 16:9 A10 powered tablet featuring 1G RAM, 8G
nand, 1024x600 IPS screen, a mini hdmi port, mini usb receptacle and a
headphones port for details see: http://linux-sunxi.org/Hyundai_A7HD
Cc: Mark Janssen
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts | 105 +++
2 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a3f58cf..851feae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -451,6 +451,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-mk802.dtb \
sun4i-a10-mk802ii.dtb \
sun4i-a10-hackberry.dtb \
+ sun4i-a10-hyundai-a7hd.dtb \
sun4i-a10-inet97fv2.dtb \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb
diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
new file mode 100644
index 000..c88382a
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
@@ -0,0 +1,105 @@
+/*
+ * Copyright 2015 Hans de Goede
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include
+
+/ {
+ model = "Hyundai A7HD";
+ compatible = "hyundai,a7hd", "allwinner,sun4i-a10";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+®_usb2_vbus {
+ gpio = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&usb2_vbus_pin_a {
+ allwinner,pins = "PH6";
+};
+
+&usbphy {
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
--
2.1.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
Re: [PATCH] ARM: dts: Add sd0_rst pinctrl node to exynos5420
Hello Jaehoon, On Fri, Jan 23, 2015 at 3:23 PM, Jaehoon Chung wrote: > Add sd0_rst node to exynos5420-pinctrl.dtsi. > (It's used on odroid-xu3 board) > It would be good to mention which device needs this pinctrl line. > Signed-off-by: Jaehoon Chung > --- > arch/arm/boot/dts/exynos5420-pinctrl.dtsi |5 + If this pin is used by the Odroid XU3 board, shouldn't be defined in the exynos5422-odroidxu3.dts instead? Best regards, Javier -- 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/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
On Fri, Jan 23, 2015 at 01:46:35PM +, Arnd Bergmann wrote: > On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> new file mode 100644 > > >> index ..d03abf7fd8e3997a > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > > >> @@ -0,0 +1,52 @@ > > >> +Simple Power-Managed Bus > > >> + > > >> + > > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > > >> +driver, as it's typically initialized by the boot loader. > > >> + > > >> +However, its bus controller is part of a PM domain, or under the > > >> control of a > > >> +functional clock. Hence, the bus controller's PM domain and/or clock > > >> must be > > >> +enabled for child devices connected to the bus (either on-SoC or > > >> externally) > > >> +to function. > > >> + > > >> + > > >> +Generic compatible values and properties > > >> + > > >> + > > >> +Required properties: > > >> + - compatible: Must be at least one of the vendor-specific compatible > > >> values > > >> + from a vendor-specific section below, and "simple-bus" as a > > >> + fallback. > > > > > > What happened to the idea of using something like "simple-pm-bus"? > > > > I think that's a decision to make by the (successor of the) ePAPR committee. > > At least it would be nice to get some feedback from the DT review team > > about this. > > > > If we go that road, the vendor-specific compatible value should still be > > documented, else checkpatch will complain when encountering it in a DTS. > > Then, should it become > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > > "simple-bus"; > > > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > > can drop "simple-bus" from the list in the DTS: > > > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; > > I was thinking of the reverse: drop "simple-bus" bus from the list here, > but not add "simple-pm-bus" to of_default_bus_match_table. This will > cause child devices to no longer be probed automatically, and you will > have to call of_platform_populate() from simple_pm_bus_probe(), after > pm_runtime_enable(). I am in complete agreement. > This seems like a cleaner model to me, for two reasons: > > - In the binding, claiming compatibility with "simple-bus" feels > wrong to me, because you have a bus that is not as simple as others Well, it depends. If you _can_ handle it as a "simple-bus" (i.e. it's in a sane state by default and you can ignore the bus details entirely), then "simple-bus" is appropriate. However, I don't think that we can always rely on this, because the state is highly dependent on the FW, bootloader, and the rest of the kernel. We have clock/regulator/whatever controller drivers which disable unused outputs (for power saving and/or flushing out FW bugs). The dtb has no idea about all of these in-kernel details. If the kernel probes the bus as a "simple-bus" (with no pm at all), then the bus may have been inadvertently disabled already (or may become so later). If the kernel is in control of the providers of inputs, then the kernel _must_ explicitly handle those inputs (which requires the bus to be probed as "simple-pm-bus" and not "simple-bus"). > - The ordering between pm_runtime_enable() and the probing of the > child devices is guaranteed, which I think it is not with your > current code. There's also kexec to consider. You'd need to ensure that the bus is re-initialised prior to exit from the kernel to keep the bus "simple-bus" compatible for the next user. I imagine that enabling a device prior to exit from the kernel is the opposite of what the PM code does. Just having "simple-pm-bus" (and requiring the simple-pm-bus driver to do sub-node probing _after_ initialisation of the PM'd bus) is much more robust. That way if the OS can't acquire all the necessary resources (and guarantee the bus will work), it won't start trying to probe the children and hang/explode. > Does this make sense, or am I missing an important reason why there > has to be a "simple-bus" compatible string here? The only reason to have it would be to enable an old kernel to use a new DT. However, for the reasons above I believe that would be broken anyway, so I do not think that "simple-bus" is an appropriate compatible fallback. 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
[PATCH] ARM: dts: exynos4412-trats2: Add max77693 charger node
Add to Trats2 DTS new node for configuring the max77693 charger driver.
Only the maxim,constant-microvolt differs from default value but set all
of the optional properties anyway.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b452643..496a05faca37 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -549,6 +549,16 @@
haptic-supply = <&ldo26_reg>;
pwms = <&pwm 0 38022 0>;
};
+
+ charger {
+ compatible = "maxim,max77693-charger";
+
+ maxim,constant-microvolt = <435>;
+ maxim,min-system-microvolt = <360>;
+ maxim,thermal-regulation-celsius = <100>;
+ maxim,battery-overcurrent-microamp = <350>;
+ maxim,charge-input-threshold-microvolt =
<430>;
+ };
};
};
--
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] ARM: dts: Add sd0_rst pinctrl node to exynos5420
Add sd0_rst node to exynos5420-pinctrl.dtsi.
(It's used on odroid-xu3 board)
Signed-off-by: Jaehoon Chung
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index ba686e4..315cad7 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -194,6 +194,11 @@
samsung,pin-drv = <3>;
};
+ sd0_rst: sd0-rst {
+ samsung,pins = "gpd1-0";
+ samsung,pin-function = <1>;
+ };
+
sd1_clk: sd1-clk {
samsung,pins = "gpc1-0";
samsung,pin-function = <2>;
--
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
Re: [PATCH v2 2/7] mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951
Hi Marcin,
On 23/01/2015 12:33, Marcin Wojtas wrote:
> Dear Gregory,
>
>
>> @@ -118,8 +118,11 @@ static int mv_conf_mbus_windows(struct platform_device
>> *pdev,
>> return 0;
>> }
>>
>> -static int armada_38x_quirks(struct sdhci_host *host)
>> +static int armada_38x_quirks(struct platform_device *pdev,
>> +struct sdhci_host *host)
>> {
>> + struct device_node *np = pdev->dev.of_node;
>> +
>> host->quirks |= SDHCI_QUIRK_MISSING_CAPS;
>> /*
>> * According to erratum 'FE-2946959' both SDR50 and DDR50
>> @@ -129,6 +132,20 @@ static int armada_38x_quirks(struct sdhci_host *host)
>> */
>> host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
>> host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
>> +
>> + /*
>> +* According to erratum 'ERR-7878951' Armada 38x SDHCI
>> +* controller has different capabilities than the ones shown
>> +* in its registers
>> +*/
>> + host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
>> + if (of_get_property(np, "no-1-8-v", NULL)) {
>> + host->caps &= ~SDHCI_CAN_VDD_180;
>> + host->mmc->caps &= ~MMC_CAP_1_8V_DDR;
>> + } else
>> + host->caps &= ~SDHCI_CAN_VDD_330;
>
> In this "else" there is one thing missing
> host->mmc->caps |= MMC_CAP_1_8V_DDR;
> because it's not set by default, however it's not a must - please see
> my remark below.
>
>> + host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_USE_SDR50_TUNING);
>> +
>> return 0;
>> }
>>
>> @@ -333,7 +350,7 @@ static int sdhci_pxav3_probe(struct platform_device
>> *pdev)
>> clk_prepare_enable(pxa->clk_core);
>>
>> if (of_device_is_compatible(np, "marvell,armada-380-sdhci")) {
>> - ret = armada_38x_quirks(host);
>> + ret = armada_38x_quirks(pdev, host);
>> if (ret < 0)
>> goto err_quirks;
>> ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
>> @@ -341,9 +358,6 @@ static int sdhci_pxav3_probe(struct platform_device
>> *pdev)
>> goto err_mbus_win;
>> }
>>
>> - /* enable 1/8V DDR capable */
>> - host->mmc->caps |= MMC_CAP_1_8V_DDR;
>> -
>
> Now, with this change MMC_CAP_1_8V_DDR is disabled for devices other
> than Armada 38x, that use sdhci-pxav3. There are two options:
> 1. Move those lines above the place where armada_38x_quirks is called
> (IMO the easiest option - 'else' in this function would not need to be
> supplemented, as I pointed above)
> 2. Leave it "as is" here, but a condition below is needed (+
> supplementation of 'else' in armada_38x_quirks)
> if (!of_device_is_compatible(np, "marvell,armada-380-sdhci"))
>
I will take the first option.
A third version is coming soon addressing also Mark's comments.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
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 v3/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
Hi Arnd,
On Fri, Jan 23, 2015 at 2:46 PM, Arnd Bergmann wrote:
> On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote:
>> >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
>> >> b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
>> >> new file mode 100644
>> >> index ..d03abf7fd8e3997a
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
>> >> @@ -0,0 +1,52 @@
>> >> +Simple Power-Managed Bus
>> >> +
>> >> +
>> >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real
>> >> +driver, as it's typically initialized by the boot loader.
>> >> +
>> >> +However, its bus controller is part of a PM domain, or under the control
>> >> of a
>> >> +functional clock. Hence, the bus controller's PM domain and/or clock
>> >> must be
>> >> +enabled for child devices connected to the bus (either on-SoC or
>> >> externally)
>> >> +to function.
>> >> +
>> >> +
>> >> +Generic compatible values and properties
>> >> +
>> >> +
>> >> +Required properties:
>> >> + - compatible: Must be at least one of the vendor-specific compatible
>> >> values
>> >> + from a vendor-specific section below, and "simple-bus" as a
>> >> + fallback.
>> >
>> > What happened to the idea of using something like "simple-pm-bus"?
>>
>> I think that's a decision to make by the (successor of the) ePAPR committee.
>> At least it would be nice to get some feedback from the DT review team
>> about this.
>>
>> If we go that road, the vendor-specific compatible value should still be
>> documented, else checkpatch will complain when encountering it in a DTS.
>> Then, should it become
>>
>> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus",
>> "simple-bus";
>>
>> or should "simple-bus" just be added to of_default_bus_match_table[], so we
Sorry, FTR, I meant "simple-pm-bus" here.
>> can drop "simple-bus" from the list in the DTS:
>>
>> compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus";
>
> I was thinking of the reverse: drop "simple-bus" bus from the list here,
> but not add "simple-pm-bus" to of_default_bus_match_table. This will
> cause child devices to no longer be probed automatically, and you will
> have to call of_platform_populate() from simple_pm_bus_probe(), after
> pm_runtime_enable(). This seems like a cleaner model to me, for two
> reasons:
>
> - In the binding, claiming compatibility with "simple-bus" feels
> wrong to me, because you have a bus that is not as simple as others
>
> - The ordering between pm_runtime_enable() and the probing of the
> child devices is guaranteed, which I think it is not with your
> current code.
The ordering is indeed a good argument. Will update.
Hence:
- The DTS will claim a compatibility with
"renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus".
- The driver will match against "simple-pm-bus".
Note that if we ever have a real driver for "renesas,bsc", we'll have to
be careful about binding ordering. "simple-bus" is handled by core code,
and doesn't prevent a more specific driver to take precedence.
"simple-pm-bus" is handled by a driver, so if it binds first, a more specific
driver cannot take over.
> Does this make sense, or am I missing an important reason why there
> has to be a "simple-bus" compatible string here?
Yes, it makes sense. I had the "simple-bus" compatible entry there because of
the "most generic first", "least generic last" rule. If you don't use the
extra features (i.e. don't touch the clocks or PM domains in the SoC), it is
compatible with "simple-bus". That's more or less how it was in
r8a73a4-ape6evm-reference.dts before the advent of CCF and PM domains.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v4 2/3] ASoC: samsung: Document Trats2 audio subsystem bindings
On 23/01/15 06:03, Inha Song wrote: > This patch add Trats2 audio subsystem bindings document. > > Signed-off-by: Inha Song Reviewed-by: Sylwester Nawrocki -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v4 3/3] ARM: dts: Add sound nodes for exynos4412-trats2
On 23/01/15 06:03, Inha Song wrote: > This patch add WM1811 audio codec, I2S interface and the sound > machine nodes to enable audio on exynos4412-trats2 board. > > Signed-off-by: Inha Song Reviewed-by: Sylwester Nawrocki -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 3/3] ASoC: add generic dt-card support
On 01/23/2015 01:15 PM, Jean-Francois Moine wrote: [...] The DT should describe the hardware, and the simple-card mixes hardware and software. For example, the kirkwood controller may create 2 CPU DAIs. With the simple-card, the DT contains a number to reference these DAIs (for example, implicitly, references the I2S output). So, what if the controller creates only one DAI, or, what if the FreeBSD/OpenBSD/.. driver does not set the same references to these DAIs? The graph of port fixes this problem. Even with the simple-card bindings there are no software specific bits. The DAI that is referenced in your example is the physical DAI as it exists in the hardware. Which DAI maps to which specifier is defined in the devicetree bindings definition for the hardware unit. More: a simple audio card may easily be created from a graph of ports as the simple-card does, but by the audio-controller (sorry, I also forgot the kirkwood patch for this in my previous patch request). In case of complex cards, the links and properties of this graph may also be used by board specific card devices. One issue is how to deal with multi-point-to-multi-point links. I2S/TDM is a bus and can have more than one reader/writer. The second issue is how to describe the clock and frame master relationships. Multiple different buses can share the same clock and frame generator. E.g. typically the capture and playback stream are linked in this way. The ports and endpoints may contain properties to describe these configurations. Complex cases should be handled by specific card builders. Could you describe in detail what a card builder is and how to decide when and how a card builder is executed? How are we going to handle bus specific properties. Properties which are neither a property of either of the endpoints on the link, but of the link itself. This is already the case for the bus types of the kirkwood controller, I2S or S/PDIF. Such properties may appear in either local or remote port, or in both. BTW, the graph of port should also contain pieces of the audio specific hardware information as the ones found in the simple-card (clock, GPIO, ...). This information could be written as generic device node properties. i.e without any prefix. I was also wondering about some of these properties, as widgets and routing. They seem to be software information and Linux specific. Must these properties appear in the DTs? Well last time I checked the speaker on my board was hardware not software and wasn't Linux specific either ;) Those widgets and routing represent the (typically analog) audio fabric on the board and are part of the hardware description. This is not even ASoC or devicetree specific, e.g. HDA uses a similar concept where the BIOS provides a description of which pins of the audio CODEC is connected to which speaker, microphone, etc. And especially on embedded boards the audio fabric can become quite complex. OK. I looked if the widgets and routes could also be described in a graph, but, it complexifies the syntax. So, this information could have the same syntax as in the simple-card. Yea, using the graph syntax for the analog pins would result in a lot of boiler-plate. On the other hand, where would this information appear in the graph? As I understood, on card creation, the widgets and routes, which appear at the card level, redefine the CPU and CODEC DAI definitions. What do you mean by "redefine the CPU and CODEC DAI definitions". With a DT graph, each CPU/CODEC would know exactly the widgets and routes it has to define. Which widgets/routes do you mean? Your example is a relative simple one where you do not have any additional audio fabric on the board itself. Right, and that's why I'd be glad to have quickly something in the kernel. More properties could be added later as there would be requests. I'd agree if this was some kind of kernel internal stuff, but this is creating ABI and we have to maintain it forever. Rushing this in without proper discussion and consideration of the more complex use-cases is in my opinion not a good idea. - Lars -- 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/resend 3/4] drivers: bus: Add Simple Power-Managed Bus DT Bindings
On Friday 23 January 2015 09:56:51 Geert Uytterhoeven wrote: > >> diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> new file mode 100644 > >> index ..d03abf7fd8e3997a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt > >> @@ -0,0 +1,52 @@ > >> +Simple Power-Managed Bus > >> + > >> + > >> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real > >> +driver, as it's typically initialized by the boot loader. > >> + > >> +However, its bus controller is part of a PM domain, or under the control > >> of a > >> +functional clock. Hence, the bus controller's PM domain and/or clock > >> must be > >> +enabled for child devices connected to the bus (either on-SoC or > >> externally) > >> +to function. > >> + > >> + > >> +Generic compatible values and properties > >> + > >> + > >> +Required properties: > >> + - compatible: Must be at least one of the vendor-specific compatible > >> values > >> + from a vendor-specific section below, and "simple-bus" as a > >> + fallback. > > > > What happened to the idea of using something like "simple-pm-bus"? > > I think that's a decision to make by the (successor of the) ePAPR committee. > At least it would be nice to get some feedback from the DT review team > about this. > > If we go that road, the vendor-specific compatible value should still be > documented, else checkpatch will complain when encountering it in a DTS. > Then, should it become > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus", > "simple-bus"; > > or should "simple-bus" just be added to of_default_bus_match_table[], so we > can drop "simple-bus" from the list in the DTS: > > compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus"; I was thinking of the reverse: drop "simple-bus" bus from the list here, but not add "simple-pm-bus" to of_default_bus_match_table. This will cause child devices to no longer be probed automatically, and you will have to call of_platform_populate() from simple_pm_bus_probe(), after pm_runtime_enable(). This seems like a cleaner model to me, for two reasons: - In the binding, claiming compatibility with "simple-bus" feels wrong to me, because you have a bus that is not as simple as others - The ordering between pm_runtime_enable() and the probing of the child devices is guaranteed, which I think it is not with your current code. Does this make sense, or am I missing an important reason why there has to be a "simple-bus" compatible string here? 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 v7 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On Fri, Jan 23, 2015 at 9:31 PM, Peter Hurley wrote:
> Hi Chunyan,
>
> Just the minor fix to zeroing the stack local in sprd_set_termios()
> and using dev_get_drvdata() in sprd_suspend()/sprd_resume().
>
ok, I see.
> Regards,
> Peter Hurley
>
> On 01/23/2015 08:01 AM, Chunyan Zhang wrote:
>> Add a full sc9836-uart driver for SC9836 SoC which is based on the
>> spreadtrum sharkl64 platform.
>> This driver also support earlycon.
>
> [...]
>
>> +static void sprd_set_termios(struct uart_port *port,
>> + struct ktermios *termios,
>> + struct ktermios *old)
>> +{
>> + unsigned int baud, quot;
>> + unsigned int lcr, fc;
>
> unsigned int lcr = 0, fc;
>
>> + unsigned long flags;
>> +
>> + /* ask the core to calculate the divisor for us */
>> + baud = uart_get_baud_rate(port, termios, old, 0, SPRD_BAUD_IO_LIMIT);
>> +
>> + quot = (unsigned int)((port->uartclk + baud / 2) / baud);
>> +
>> + /* set data length */
>> + switch (termios->c_cflag & CSIZE) {
>> + case CS5:
>> + lcr |= SPRD_LCR_DATA_LEN5;
>> + break;
>> + case CS6:
>> + lcr |= SPRD_LCR_DATA_LEN6;
>> + break;
>> + case CS7:
>> + lcr |= SPRD_LCR_DATA_LEN7;
>> + break;
>> + case CS8:
>> + default:
>> + lcr |= SPRD_LCR_DATA_LEN8;
>> + break;
>> + }
>> +
>> + /* calculate stop bits */
>> + lcr &= ~(SPRD_LCR_STOP_1BIT | SPRD_LCR_STOP_2BIT);
>> + if (termios->c_cflag & CSTOPB)
>> + lcr |= SPRD_LCR_STOP_2BIT;
>> + else
>> + lcr |= SPRD_LCR_STOP_1BIT;
>> +
>> + /* calculate parity */
>> + lcr &= ~SPRD_LCR_PARITY;
>> + termios->c_cflag &= ~CMSPAR;/* no support mark/space */
>> + if (termios->c_cflag & PARENB) {
>> + lcr |= SPRD_LCR_PARITY_EN;
>> + if (termios->c_cflag & PARODD)
>> + lcr |= SPRD_LCR_ODD_PAR;
>> + else
>> + lcr |= SPRD_LCR_EVEN_PAR;
>> + }
>
> [...]
>
>> +static int sprd_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res;
>> + struct uart_port *up;
>> + struct clk *clk;
>> + int irq;
>> + int index;
>> + int ret;
>> +
>> + for (index = 0; index < ARRAY_SIZE(sprd_port); index++)
>> + if (sprd_port[index] == NULL)
>> + break;
>> +
>> + if (index == ARRAY_SIZE(sprd_port))
>> + return -EBUSY;
>> +
>> + index = sprd_probe_dt_alias(index, &pdev->dev);
>> +
>> + sprd_port[index] = devm_kzalloc(&pdev->dev,
>> + sizeof(*sprd_port[index]), GFP_KERNEL);
>> + if (!sprd_port[index])
>> + return -ENOMEM;
>> +
>> + pdev->id = index;
>
> see my recent reply regarding this and sprd_suspend/sprd_resume.
>
>> +
>> + up = &sprd_port[index]->port;
>> + up->dev = &pdev->dev;
>> + up->line = index;
>> + up->type = PORT_SPRD;
>> + up->iotype = SERIAL_IO_PORT;
>> + up->uartclk = SPRD_DEF_RATE;
>> + up->fifosize = SPRD_FIFO_SIZE;
>> + up->ops = &serial_sprd_ops;
>> + up->flags = UPF_BOOT_AUTOCONF;
>> +
>> + clk = devm_clk_get(&pdev->dev, NULL);
>> + if (!IS_ERR(clk))
>> + up->uartclk = clk_get_rate(clk);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + dev_err(&pdev->dev, "not provide mem resource\n");
>> + return -ENODEV;
>> + }
>> + up->mapbase = res->start;
>> + up->membase = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(up->membase))
>> + return PTR_ERR(up->membase);
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq < 0) {
>> + dev_err(&pdev->dev, "not provide irq resource\n");
>> + return -ENODEV;
>> + }
>> + up->irq = irq;
>> +
>> + if (!sprd_ports_num) {
>> + ret = uart_register_driver(&sprd_uart_driver);
>> + if (ret < 0) {
>> + pr_err("Failed to register SPRD-UART driver\n");
>> + return ret;
>> + }
>> + }
>> + sprd_ports_num++;
>> +
>> + ret = uart_add_one_port(&sprd_uart_driver, up);
>> + if (ret) {
>> + sprd_port[index] = NULL;
>> + sprd_remove(pdev);
>> + }
>> +
>> + platform_set_drvdata(pdev, up);
>> +
>> + return ret;
>> +}
>> +
>> +static int sprd_suspend(struct device *dev)
>> +{
>> + int id = to_platform_device(dev)->id;
>> + struct uart_port *port = &sprd_port[id]->port;
>> +
>> + uart_suspend_port(&sprd_uart_driver, port);
>
> same comment: see my recent reply using dev_get_drvdata().
>
ok, i see. thanks!
Chunyan
>> +
>> + return 0;
>> +}
>> +
>> +static int sprd_resume(struct device *dev)
>> +{
>> + int id = to_platform_device(dev)->id;
>> + struct uart_port *port = &sprd_port[id]->port;
>> +
>> + uart
Re: [PATCH v6 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On Fri, Jan 23, 2015 at 9:12 PM, Peter Hurley wrote:
> On 01/23/2015 02:23 AM, Lyra Zhang wrote:
>> Hi, Peter
>>
>> Many thanks to you for reviewing so carefully and giving us so many
>> suggestions and so clear explanations.
>
> :)
>
>> I'll address all of your comments and send an updated patch soon.
>>
>> On Fri, Jan 23, 2015 at 11:57 AM, Peter Hurley
>> wrote:
>
> [...]
>
+static void sprd_set_termios(struct uart_port *port,
+ struct ktermios *termios,
+ struct ktermios *old)
+{
+ unsigned int baud, quot;
+ unsigned int lcr, fc;
+ unsigned long flags;
+
+ /* ask the core to calculate the divisor for us */
+ baud = uart_get_baud_rate(port, termios, old, 1200, 300);
>>> ^^
>>>mabye derive these from uartclk?
>>
>> I'm afraid I can't understand very clearly, Could you explain more
>> details please?
>
> Is the fixed clock divider == 8 and the uartclk == 2600 ?
> If so,
> baud = uartclk / 8 = 325
>
> I see now this is clamping baud inside the maximum, so this is fine.
> Please disregard my comment.
>
> [...]
>
>
+static int sprd_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct uart_port *up;
+ struct clk *clk;
+ int irq;
+ int index;
+ int ret;
+
+ for (index = 0; index < ARRAY_SIZE(sprd_port); index++)
+ if (sprd_port[index] == NULL)
+ break;
+
+ if (index == ARRAY_SIZE(sprd_port))
+ return -EBUSY;
+
+ index = sprd_probe_dt_alias(index, &pdev->dev);
+
+ sprd_port[index] = devm_kzalloc(&pdev->dev,
+ sizeof(*sprd_port[index]), GFP_KERNEL);
+ if (!sprd_port[index])
+ return -ENOMEM;
+
+ up = &sprd_port[index]->port;
+ up->dev = &pdev->dev;
+ up->line = index;
+ up->type = PORT_SPRD;
+ up->iotype = SERIAL_IO_PORT;
+ up->uartclk = SPRD_DEF_RATE;
+ up->fifosize = SPRD_FIFO_SIZE;
+ up->ops = &serial_sprd_ops;
+ up->flags = ASYNC_BOOT_AUTOCONF;
>>> ^
>>> UPF_BOOT_AUTOCONF
>>>
>>> sparse will catch errors like this. See Documentation/sparse.txt
>>
>> you mean we should use UPF_BOOT_AUTOCONF, right?
>
> Yes. Only UPF_* flag definitions should be used with the uart_port.flags
> field.
>
> My comment regarding the sparse tool and documentation is because the
> flags field and UPF_* definitions use a type mechanism to generate
> warnings using the sparse tool if regular integer values are used
> with the flags field.
>
> The type mechanism was specifically introduced to catch using ASYNC_*
> definitions with the uart_port.flags field.
>
> [...]
>
+static int sprd_suspend(struct device *dev)
+{
+ int id = to_platform_device(dev)->id;
+ struct uart_port *port = &sprd_port[id]->port;
>>>
>>> I'm a little confused regarding the port indexing;
>>> is platform_device->id == line ? Where did that happen?
>>>
>>
>> Oh, I'll change to assign platform_device->id with port->line in probe()
>
> I apologize; I should have made my comment clearer.
>
> The ->id should not be assigned.
>
> Replace
>
> int id = to_platform_device(dev)->id;
> struct uart_port *port = &sprd_port[id]->port;
>
> uart_suspend_port(&sprd_uart_driver, port);
>
> with
>
> struct sprd_uart_port *sup = dev_get_drvdata(dev);
>
> uart_suspend_port(&sprd_uart_driver, &sup->port);
>
>
> I know it's not obvious but platform_get/set_drvdata() is really
> dev_get/set_drvdata() using the embedded struct device dev.
>
I've just sent the v7 before I saw your this email, but I'll address
this point in the next version.
Thanks a lot,
Chunyan
>>
>>>
+
+ uart_suspend_port(&sprd_uart_driver, port);
+
+ return 0;
+}
+
+static int sprd_resume(struct device *dev)
+{
+ int id = to_platform_device(dev)->id;
+ struct uart_port *port = &sprd_port[id]->port;
+
+ uart_resume_port(&sprd_uart_driver, port);
>
> same here
>
+ return 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
Re: [PATCH v7 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
Hi Chunyan,
Just the minor fix to zeroing the stack local in sprd_set_termios()
and using dev_get_drvdata() in sprd_suspend()/sprd_resume().
Regards,
Peter Hurley
On 01/23/2015 08:01 AM, Chunyan Zhang wrote:
> Add a full sc9836-uart driver for SC9836 SoC which is based on the
> spreadtrum sharkl64 platform.
> This driver also support earlycon.
[...]
> +static void sprd_set_termios(struct uart_port *port,
> + struct ktermios *termios,
> + struct ktermios *old)
> +{
> + unsigned int baud, quot;
> + unsigned int lcr, fc;
unsigned int lcr = 0, fc;
> + unsigned long flags;
> +
> + /* ask the core to calculate the divisor for us */
> + baud = uart_get_baud_rate(port, termios, old, 0, SPRD_BAUD_IO_LIMIT);
> +
> + quot = (unsigned int)((port->uartclk + baud / 2) / baud);
> +
> + /* set data length */
> + switch (termios->c_cflag & CSIZE) {
> + case CS5:
> + lcr |= SPRD_LCR_DATA_LEN5;
> + break;
> + case CS6:
> + lcr |= SPRD_LCR_DATA_LEN6;
> + break;
> + case CS7:
> + lcr |= SPRD_LCR_DATA_LEN7;
> + break;
> + case CS8:
> + default:
> + lcr |= SPRD_LCR_DATA_LEN8;
> + break;
> + }
> +
> + /* calculate stop bits */
> + lcr &= ~(SPRD_LCR_STOP_1BIT | SPRD_LCR_STOP_2BIT);
> + if (termios->c_cflag & CSTOPB)
> + lcr |= SPRD_LCR_STOP_2BIT;
> + else
> + lcr |= SPRD_LCR_STOP_1BIT;
> +
> + /* calculate parity */
> + lcr &= ~SPRD_LCR_PARITY;
> + termios->c_cflag &= ~CMSPAR;/* no support mark/space */
> + if (termios->c_cflag & PARENB) {
> + lcr |= SPRD_LCR_PARITY_EN;
> + if (termios->c_cflag & PARODD)
> + lcr |= SPRD_LCR_ODD_PAR;
> + else
> + lcr |= SPRD_LCR_EVEN_PAR;
> + }
[...]
> +static int sprd_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + struct uart_port *up;
> + struct clk *clk;
> + int irq;
> + int index;
> + int ret;
> +
> + for (index = 0; index < ARRAY_SIZE(sprd_port); index++)
> + if (sprd_port[index] == NULL)
> + break;
> +
> + if (index == ARRAY_SIZE(sprd_port))
> + return -EBUSY;
> +
> + index = sprd_probe_dt_alias(index, &pdev->dev);
> +
> + sprd_port[index] = devm_kzalloc(&pdev->dev,
> + sizeof(*sprd_port[index]), GFP_KERNEL);
> + if (!sprd_port[index])
> + return -ENOMEM;
> +
> + pdev->id = index;
see my recent reply regarding this and sprd_suspend/sprd_resume.
> +
> + up = &sprd_port[index]->port;
> + up->dev = &pdev->dev;
> + up->line = index;
> + up->type = PORT_SPRD;
> + up->iotype = SERIAL_IO_PORT;
> + up->uartclk = SPRD_DEF_RATE;
> + up->fifosize = SPRD_FIFO_SIZE;
> + up->ops = &serial_sprd_ops;
> + up->flags = UPF_BOOT_AUTOCONF;
> +
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (!IS_ERR(clk))
> + up->uartclk = clk_get_rate(clk);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "not provide mem resource\n");
> + return -ENODEV;
> + }
> + up->mapbase = res->start;
> + up->membase = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(up->membase))
> + return PTR_ERR(up->membase);
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(&pdev->dev, "not provide irq resource\n");
> + return -ENODEV;
> + }
> + up->irq = irq;
> +
> + if (!sprd_ports_num) {
> + ret = uart_register_driver(&sprd_uart_driver);
> + if (ret < 0) {
> + pr_err("Failed to register SPRD-UART driver\n");
> + return ret;
> + }
> + }
> + sprd_ports_num++;
> +
> + ret = uart_add_one_port(&sprd_uart_driver, up);
> + if (ret) {
> + sprd_port[index] = NULL;
> + sprd_remove(pdev);
> + }
> +
> + platform_set_drvdata(pdev, up);
> +
> + return ret;
> +}
> +
> +static int sprd_suspend(struct device *dev)
> +{
> + int id = to_platform_device(dev)->id;
> + struct uart_port *port = &sprd_port[id]->port;
> +
> + uart_suspend_port(&sprd_uart_driver, port);
same comment: see my recent reply using dev_get_drvdata().
> +
> + return 0;
> +}
> +
> +static int sprd_resume(struct device *dev)
> +{
> + int id = to_platform_device(dev)->id;
> + struct uart_port *port = &sprd_port[id]->port;
> +
> + uart_resume_port(&sprd_uart_driver, port);
> +
> + return 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
Re: [PATCH v6 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On 01/23/2015 02:23 AM, Lyra Zhang wrote:
> Hi, Peter
>
> Many thanks to you for reviewing so carefully and giving us so many
> suggestions and so clear explanations.
:)
> I'll address all of your comments and send an updated patch soon.
>
> On Fri, Jan 23, 2015 at 11:57 AM, Peter Hurley
> wrote:
[...]
>>> +static void sprd_set_termios(struct uart_port *port,
>>> + struct ktermios *termios,
>>> + struct ktermios *old)
>>> +{
>>> + unsigned int baud, quot;
>>> + unsigned int lcr, fc;
>>> + unsigned long flags;
>>> +
>>> + /* ask the core to calculate the divisor for us */
>>> + baud = uart_get_baud_rate(port, termios, old, 1200, 300);
>> ^^
>>mabye derive these from uartclk?
>
> I'm afraid I can't understand very clearly, Could you explain more
> details please?
Is the fixed clock divider == 8 and the uartclk == 2600 ?
If so,
baud = uartclk / 8 = 325
I see now this is clamping baud inside the maximum, so this is fine.
Please disregard my comment.
[...]
>>> +static int sprd_probe(struct platform_device *pdev)
>>> +{
>>> + struct resource *res;
>>> + struct uart_port *up;
>>> + struct clk *clk;
>>> + int irq;
>>> + int index;
>>> + int ret;
>>> +
>>> + for (index = 0; index < ARRAY_SIZE(sprd_port); index++)
>>> + if (sprd_port[index] == NULL)
>>> + break;
>>> +
>>> + if (index == ARRAY_SIZE(sprd_port))
>>> + return -EBUSY;
>>> +
>>> + index = sprd_probe_dt_alias(index, &pdev->dev);
>>> +
>>> + sprd_port[index] = devm_kzalloc(&pdev->dev,
>>> + sizeof(*sprd_port[index]), GFP_KERNEL);
>>> + if (!sprd_port[index])
>>> + return -ENOMEM;
>>> +
>>> + up = &sprd_port[index]->port;
>>> + up->dev = &pdev->dev;
>>> + up->line = index;
>>> + up->type = PORT_SPRD;
>>> + up->iotype = SERIAL_IO_PORT;
>>> + up->uartclk = SPRD_DEF_RATE;
>>> + up->fifosize = SPRD_FIFO_SIZE;
>>> + up->ops = &serial_sprd_ops;
>>> + up->flags = ASYNC_BOOT_AUTOCONF;
>> ^
>> UPF_BOOT_AUTOCONF
>>
>> sparse will catch errors like this. See Documentation/sparse.txt
>
> you mean we should use UPF_BOOT_AUTOCONF, right?
Yes. Only UPF_* flag definitions should be used with the uart_port.flags
field.
My comment regarding the sparse tool and documentation is because the
flags field and UPF_* definitions use a type mechanism to generate
warnings using the sparse tool if regular integer values are used
with the flags field.
The type mechanism was specifically introduced to catch using ASYNC_*
definitions with the uart_port.flags field.
[...]
>>> +static int sprd_suspend(struct device *dev)
>>> +{
>>> + int id = to_platform_device(dev)->id;
>>> + struct uart_port *port = &sprd_port[id]->port;
>>
>> I'm a little confused regarding the port indexing;
>> is platform_device->id == line ? Where did that happen?
>>
>
> Oh, I'll change to assign platform_device->id with port->line in probe()
I apologize; I should have made my comment clearer.
The ->id should not be assigned.
Replace
int id = to_platform_device(dev)->id;
struct uart_port *port = &sprd_port[id]->port;
uart_suspend_port(&sprd_uart_driver, port);
with
struct sprd_uart_port *sup = dev_get_drvdata(dev);
uart_suspend_port(&sprd_uart_driver, &sup->port);
I know it's not obvious but platform_get/set_drvdata() is really
dev_get/set_drvdata() using the embedded struct device dev.
>
>>
>>> +
>>> + uart_suspend_port(&sprd_uart_driver, port);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int sprd_resume(struct device *dev)
>>> +{
>>> + int id = to_platform_device(dev)->id;
>>> + struct uart_port *port = &sprd_port[id]->port;
>>> +
>>> + uart_resume_port(&sprd_uart_driver, port);
same here
>>> + return 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
Re: [PATCH v2] Removes OF_UNITTEST dependency on OF_DYNAMIC config symbol
On Sun, Jan 11, 2015 at 8:19 AM, Gaurav Minocha
wrote:
> This patch intends to remove the unittests dependency on
> the functions defined in dynamic.c. So, rather than calling
> of_attach_node defined in dynamic.c, minimal functionality
> required to attach a new node is re-defined in unittest.c.
> Also, now after executing the tests the test data is not
> removed from the device tree so there is no need to call
> of_detach_node.
Could there be unwanted side effects of not removing the test data?
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -1475,9 +1432,6 @@ static int __init of_selftest(void)
> of_selftest_platform_populate();
> of_selftest_overlay();
>
> - /* removing selftest data from live tree */
> - selftest_data_remove();
> -
> /* Double check linkage after removing testcase data */
You forgot to remove the comment above.
> of_selftest_check_tree_linkage();
Is this test still relevant now the testcase data has been removed?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
Add a full sc9836-uart driver for SC9836 SoC which is based on the spreadtrum sharkl64 platform. This driver also support earlycon. Originally-by: Lanqing Liu Signed-off-by: Orson Zhai Signed-off-by: Chunyan Zhang Acked-by: Arnd Bergmann --- drivers/tty/serial/Kconfig | 18 + drivers/tty/serial/Makefile |1 + drivers/tty/serial/sprd_serial.c | 799 ++ include/uapi/linux/serial_core.h |3 + 4 files changed, 821 insertions(+) create mode 100644 drivers/tty/serial/sprd_serial.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index c79b43c..13211f7 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1577,6 +1577,24 @@ config SERIAL_MEN_Z135 This driver can also be build as a module. If so, the module will be called men_z135_uart.ko +config SERIAL_SPRD + tristate "Support for Spreadtrum serial" + depends on ARCH_SPRD + select SERIAL_CORE + help + This enables the driver for the Spreadtrum's serial. + +config SERIAL_SPRD_CONSOLE + bool "Spreadtrum UART console support" + depends on SERIAL_SPRD=y + select SERIAL_CORE_CONSOLE + select SERIAL_EARLYCON + help + Support for early debug console using Spreadtrum's serial. This enables + the console before standard serial driver is probed. This is enabled + with "earlycon" on the kernel command line. The console is + enabled when early_param is processed. + endmenu config SERIAL_MCTRL_GPIO diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 9a548ac..4801aca 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -93,6 +93,7 @@ obj-$(CONFIG_SERIAL_ARC) += arc_uart.o obj-$(CONFIG_SERIAL_RP2) += rp2.o obj-$(CONFIG_SERIAL_FSL_LPUART)+= fsl_lpuart.o obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o +obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o # GPIOLIB helpers for modem control lines obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c new file mode 100644 index 000..e4b0793 --- /dev/null +++ b/drivers/tty/serial/sprd_serial.c @@ -0,0 +1,799 @@ +/* + * Copyright (C) 2012-2015 Spreadtrum Communications Inc. + * + * 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 +#include +#include +#include +#include +#include +#include + +/* device name */ +#define UART_NR_MAX8 +#define SPRD_TTY_NAME "ttyS" +#define SPRD_FIFO_SIZE 128 +#define SPRD_DEF_RATE 2600 +#define SPRD_BAUD_IO_LIMIT 300 +#define SPRD_TIMEOUT 256 + +/* the offset of serial registers and BITs for them */ +/* data registers */ +#define SPRD_TXD 0x +#define SPRD_RXD 0x0004 + +/* line status register and its BITs */ +#define SPRD_LSR 0x0008 +#define SPRD_LSR_OEBIT(4) +#define SPRD_LSR_FEBIT(3) +#define SPRD_LSR_PEBIT(2) +#define SPRD_LSR_BIBIT(7) +#define SPRD_LSR_TX_OVER BIT(15) + +/* data number in TX and RX fifo */ +#define SPRD_STS1 0x000C + +/* interrupt enable register and its BITs */ +#define SPRD_IEN 0x0010 +#define SPRD_IEN_RX_FULL BIT(0) +#define SPRD_IEN_TX_EMPTY BIT(1) +#define SPRD_IEN_BREAK_DETECT BIT(7) +#define SPRD_IEN_TIMEOUT BIT(13) + +/* interrupt clear register */ +#define SPRD_ICLR 0x0014 + +/* line control register */ +#define SPRD_LCR 0x0018 +#define SPRD_LCR_STOP_1BIT 0x10 +#define SPRD_LCR_STOP_2BIT 0x30 +#define SPRD_LCR_DATA_LEN (BIT(2) | BIT(3)) +#define SPRD_LCR_DATA_LEN5 0x0 +#define SPRD_LCR_DATA_LEN6 0x4 +#define SPRD_LCR_DATA_LEN7 0x8 +#define SPRD_LCR_DATA_LEN8 0xc +#define SPRD_LCR_PARITY(BIT(0) | BIT(1)) +#define SPRD_LCR_PARITY_EN 0x2 +#define SPRD_LCR_EVEN_PAR 0x0 +#define SPRD_LCR_ODD_PAR 0x1 + +/* control register 1 */ +#define SPRD_CTL1 0x001C +#define RX_HW_FLOW_CTL_THLDBIT(6) +#define RX_HW_FLOW_CTL_EN BIT(7) +#define TX_HW_FLOW_CTL_EN BIT(8) +#define RX_TOUT_THLD_DEF 0x3E00 +#define RX_HFC_THLD_DEF0x40 + +/* fifo threshold register */ +#define SPRD_CTL2 0x0020 +#define THLD_TX_EMPTY 0x40 +#define THLD_RX_FULL 0x40 + +/* config baud rate reg
[PATCH v7 1/2] Documentation: DT: Add bindings for Spreadtrum SoC Platform
Adds Spreadtrum's prefix "sprd" to vendor-prefixes file. Adds the devicetree binding documentations for Spreadtrum's sc9836-uart and SC9836 SoC based on the Sharkl64 Platform which is a 64-bit SoC Platform of Spreadtrum. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/arm/sprd.txt | 11 +++ .../devicetree/bindings/serial/sprd-uart.txt |7 +++ .../devicetree/bindings/vendor-prefixes.txt|1 + 3 files changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/sprd.txt create mode 100644 Documentation/devicetree/bindings/serial/sprd-uart.txt diff --git a/Documentation/devicetree/bindings/arm/sprd.txt b/Documentation/devicetree/bindings/arm/sprd.txt new file mode 100644 index 000..31a629d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sprd.txt @@ -0,0 +1,11 @@ +Spreadtrum SoC Platforms Device Tree Bindings + + +Sharkl64 is a Spreadtrum's SoC Platform which is based +on ARM 64-bit processor. + +SC9836 openphone board with SC9836 SoC based on the +Sharkl64 Platform shall have the following properties. + +Required root node properties: +- compatible = "sprd,sc9836-openphone", "sprd,sc9836"; diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt b/Documentation/devicetree/bindings/serial/sprd-uart.txt new file mode 100644 index 000..2aff0f2 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt @@ -0,0 +1,7 @@ +* Spreadtrum serial UART + +Required properties: +- compatible: must be "sprd,sc9836-uart" +- reg: offset and length of the register set for the device +- interrupts: exactly one interrupt specifier +- clocks: phandles to input clocks. diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b1df0ad..0a8384f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -153,6 +153,7 @@ snpsSynopsys, Inc. solidrun SolidRun sony Sony Corporation spansion Spansion Inc. +sprd Spreadtrum Communications Inc. st STMicroelectronics steST-Ericsson stericsson ST-Ericsson -- 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 v7 0/2] Add Spreadtrum SoC bindings and serial driver support
This patch-set split the last version, and addressed the review comments from
last version on serial driver code.
Changes from v6:
- Setted SPRD_TIMEOUT with 256 rather than 2048
- Used u32 instead of uint32_t
- Removed inline of handle_lsr_errors which is a single call site
function
- Removed unused parameter of sprd_tx & sprd_rx
- Used spin_lock_irqsave in sprd_startup() instead of spin_lock
- Added a check for port->sysrq in sprd_console_write()
- Used a global counter as a condition of calling
uart_{un}register_driver
- Added pdev->id assignment in probe()
- Setted port->flags with UPF_BOOT_AUTOCONF instead of
ASYNC_BOOT_AUTOCONF
Changes from v5:
- Used Spreadtrum instead of SPRD in menus
- Changed TTY name to 'ttyS'
- Moved uart_register_driver() to probe()
- Added spinlock as needed
- Removed register states saving and restoring in suspend() and resume()
Chunyan Zhang (2):
Documentation: DT: Add bindings for Spreadtrum SoC Platform
tty/serial: Add Spreadtrum sc9836-uart driver support
Documentation/devicetree/bindings/arm/sprd.txt | 11 +
.../devicetree/bindings/serial/sprd-uart.txt |7 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/sprd_serial.c | 799
include/uapi/linux/serial_core.h |3 +
7 files changed, 840 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/sprd.txt
create mode 100644 Documentation/devicetree/bindings/serial/sprd-uart.txt
create mode 100644 drivers/tty/serial/sprd_serial.c
--
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
