Re: [PATCHv0 2/3] rtc: Add support for Abracon AB-RTCMC-32.768kHz-B5ZE-S3 I2C RTC chip
Hi Andrew, Andrew Morton writes: > On Wed, 14 Jan 2015 16:55:57 -0800 Andrew Morton > wrote: > >> Something like this? > > Leading to changes in [3/3]. Please have a think about where we should > be calling device_init_wakeup(dev, false) on the error recovery path. > > Let me know if I should just drop it all and await a v2... I'll work on a v2 to handle your comments and suggestions. I will also take into account the other comment I got regarding the use of "abracon" instead of "abcn" as vendor prefix for Abracon Corporation. Thanks for the review. a+ -- 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] i.MX6-SabreAuto: EIM: pull PAD_EIM_D18 low for NOR probe
On Wed, Jan 14, 2015 at 04:03:34PM -0800, Brian Norris wrote: > + linux-arm-kernel, maintainers, devicetree > > Shawn, Sascha: should this driver be listed under the Freescale IMX > MAINTAINERS entry? This driver is purely i.MX, so yes, that would be good. > > On Wed, Jan 14, 2015 at 03:36:49PM -0800, ali...@she-devel.com wrote: > > From: Alison Chaiken > > > > PAD_EIM_D18 must be pulled low at boot in order for the parallel NOR > > connected to the EIM switch to probe properly. Otherwise > > cfi_qry_present() may return "U-V-]" rather than "Q-R-Y" if the > > PAD_EIM_D18 is high. Add a nor-gpios property to the nor node in the > > SabreAuto device-tree and add a function to the imx-weim probe to set > > GPIO5 to drive the pad. > > > > Signed-off-by: Alison Chaiken > > --- > > arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 1 + > > drivers/bus/imx-weim.c | 43 > > > > 2 files changed, 44 insertions(+) > > > > diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi > > b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi > > index 009abd6..dd5e3bc 100644 > > --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi > > +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi > > @@ -454,5 +454,6 @@ > > bank-width = <2>; > > fsl,weim-cs-timing = <0x00620081 0x0001 0x1c022000 > > 0xc000 0x1404a38e 0x>; > > + nor-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>; > > Such a binding needs to be documented. Also, if it's going to be named > generically like that, it needs to be generically useful and supported > under MTD code, not platform-specific bus code. > > So what pin is this, exactly? A write-protect pin? An address pin? A > toaster control, where the toaster is keeping the flash too hot? Yeah, the gpio should probably be named after the input pin on the flash where it's connected to. Otherwise people just use this property for any GPIO they need to put in a certain direction. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 1/5] rtc: armada38x: Add the device tree binding documentation
Hi Thomas,
On 14/01/2015 20:22, Thomas Petazzoni wrote:
> Dear Gregory CLEMENT,
>
> On Wed, 14 Jan 2015 18:39:11 +0100, Gregory CLEMENT wrote:
>
>> +Required properties:
>> +- compatible : Should be "marvell,armada-380-rtc"
>> +- reg: physical base address of the controller and length of memory
>> + mapped region, associated to the reg-name "rtc". The other entry is
>> + related to the interrupt control from the SoC, associated to the
>> + reg-name "soc-interrupt".
>
> soc-interrupt or...
I changed all the name from soc-interrupt to soc-int except here.
I will fix it.
>
>> +- reg-names: names of the mapped memory regions listed in regs
>> +property in the same order: "rtc" and "soc-int".
>
> soc-int ?
>
>> +rtc@a3800 {
>> +compatible = "marvell,armada-380-rtc";
>> +reg = <0xa3800 0x20>, <0x184a0 0x0c>;
>
> Any reason to use <0x184A0 0xC> instead of <0x184A8 0x4> ? According to
> the datasheet, there is only this 184A8 register for RTC stuff.
Yes but according to the code I saw there were other registers related to the
RTC
from 0x184A0. Even if we don't use them now I prefer having an accurate mapping
from
the beginning for avoiding using negative offset as we needed to do in the past.
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 1/3] input: tsc2007: Add pre-calibration, flipping and rotation
Hi, Am 15.01.2015 um 01:59 schrieb Dmitry Torokhov : > On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote: >> Ping for input maintainer. DT changes was acked. Thanks. >> >> On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko wrote: >>> This patch adds new parameters that allow to address typical hardware >>> design differences: touch screens may be wired or oriented differently >>> (portrait or landscape). And usually the active area of the touch is a >>> little larger than the active area of the LCD. This results in the touch >>> coordinates that have some significant deviation from LCD coordinates. >>> Usually this is addressed in user space by a calibration tool (e.g. tslib >>> or xinput-calibrator) but some systems don't have these tools or require >>> that the screen is already roughly calibrated (e.g. Replicant) to operate >>> the device until a better calibration can be done. And, some systems >>> react very strangely if the touch event stream reports coordinates >>> outside of the active area. >>> >>> This makes it necessry to be able to configure: >>> 1. swapping x and y wires (coordinate values) >>> 2. flipping of x (left - right) or y (top - bottom) or even both >>> 3. define an active area so that an uncalibrated screen already >>> roughly matches the LCD to be useful. >>> 4. clip reported coordinates to the active area. >>> >>> If none of the new parameters is defined (in DT) or set in a board file, >>> the driver behaves the same as without this patch. >>> >>> Author (1&2): H. Nikolaus Schaller >>> Author (3&4): Paul Kocialkowski >>> >>> Signed-off-by: H. Nikolaus Schaller > > OK, I was hesitant of adding these as normally we have tslib to perform > the conversion, but maybe it is time to allow it in the kernel and > standardize users. Well, tslib isn’t a good replacement for this problem any more and pre-initializing tslib makes some deep hardware dependency visible in user space (each board needs a different tslib config and pointercal default - and on some user spaces tslib is broken with Xorg). But the issue to be solved is more hardware related, i.e. if the Y- and Y+ pins of the controller are connected in a swapped way to the resistor ends of the panel. Hence in a DT based system, this must IMHO be described by the DT and can not be left to some user-space functions any more. > However, this seems like a general issue and we > should: > > 1. Perform conversion in input core rather than individual drivers. I > think we should allocate a new bitmaps for some transformations and have > the code do X/Y flip/clip of the coordinates. Do you have a suggestion where this should be (I have no clue how the input system works or is structured - we just know how to extend a driver that uses it)? > > 2. Standardize on bindings. We already have of-touchscreen.c doing > rudimentary parsing, we shoudl look into extending it rather than > creating myriad of driver-specific bindings. Ok, looks reasonable. > > Also, do we need swap and flip or do we simply need rotation (like the > proposed Broadcom iproc driver has)? Well, since the DT should describe hardware, there are 3 sets of wires which can have a cross-over: X+ and X-, Y+ and Y-, X and Y. So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an interpretation of the result of these connections in combination with some panel the touch is glued to and should therefore not be represented in the DT. As a result we have proposed a scheme without explicit rotation. We specify what coordinates X- and X+ should report at their ends (min, max) because the DT programmer has to specify them anyways. Flipping is a result of defining these coordinates in an ascending or descending way. Only swapping of the X and Y wires can’t be implicitly defined so it has its own property. So the scheme we have proposed tries to optimize the efforts needed to adapt new boards and write DTs and focus the DT on hardware description. As a bonus we also specify the min and max value to be reported for the touch pressure (Z axis) using the same basic principle. And it is a pure add-on on top of the existing driver so that it attempts not to break existing device trees. Maybe could you accept it as a first step for this specific driver (and let’s do the big standardization work later on)? — hns -- 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: at91: dts: sama5d3/sama5d4: reduce NFC command registers memory region
To get NFC status, we need to read the NFC command registers, which is a 256M memory mapping address. To check the status, you just read such address from NFC command registers. For example, to check NFCBUSY (bit 27), you need to read 0x0800 (bit 27 is set to 1) of the NFC command register. If you want to check NFCBUSY (bit 27) and NFCWR (bit 26) in same time, you need to read 0x0c00 (bit 27 and bit 26 are set to 1). But mapping such huge memory address only for multiple NFC status check is not very economic. The economic way is we check the NFC status one bit a time, then we don't have to mapping such huge address. Now we reduce the memory mapping from 256M to 128M+4 (include 0x0800), the only difference is NFCBUSY (bit 27) status. You cannot check NFCBUSY bit with other NFC status bit. Since current atmel_nand driver check the NFCBUSY status without combine other bits, so this change (reduce 256M to 128M+4) will not be harmful. Signed-off-by: Josh Wu --- arch/arm/boot/dts/sama5d3.dtsi | 2 +- arch/arm/boot/dts/sama5d4.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi index d701ddd..d243732 100644 --- a/arch/arm/boot/dts/sama5d3.dtsi +++ b/arch/arm/boot/dts/sama5d3.dtsi @@ -1426,7 +1426,7 @@ #address-cells = <1>; #size-cells = <1>; reg = < - 0x7000 0x1000 /* NFC Command Registers */ + 0x7000 0x0804 /* NFC Command Registers */ 0xc000 0x0070 /* NFC HSMC regs */ 0x0020 0x0010 /* NFC SRAM banks */ >; diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi index 0a2477f..05b096b 100644 --- a/arch/arm/boot/dts/sama5d4.dtsi +++ b/arch/arm/boot/dts/sama5d4.dtsi @@ -288,7 +288,7 @@ #address-cells = <1>; #size-cells = <1>; reg = < - 0x9000 0x1000 /* NFC Command Registers */ + 0x9000 0x0804 /* NFC Command Registers */ 0xfc05c000 0x0070 /* NFC HSMC regs */ 0x0010 0x0010 /* NFC SRAM banks */ >; -- 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 v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
On Wed, Jan 14, 2015 at 09:44:39PM -0800, Scott Branden wrote:
> On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
> >Hi Jonathan,
> >
> >On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> >>+ if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
> >>+ if (val < 1 || val > 256) {
> >>+ dev_err(dev, "scanning_period must be [1-256]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.scanning_period = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
> >>+ if (val < 0 || val > 255) {
> >>+ dev_err(dev, "debounce_timeout must be [0-255]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.debounce_timeout = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
> >>+ if (val < 0 || val > 11) {
> >>+ dev_err(dev, "settling_timeout must be [0-11]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.settling_timeout = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
> >>+ if (val < 0 || val > 255) {
> >>+ dev_err(dev, "touch_timeout must be [0-255]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.touch_timeout = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "average_data", &val) >= 0) {
> >>+ if (val < 0 || val > 8) {
> >>+ dev_err(dev, "average_data must be [0-8]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.average_data = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
> >>+ if (val < 0 || val > 31) {
> >>+ dev_err(dev, "fifo_threshold must be [0-31]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.fifo_threshold = val;
> >>+ }
> >
> >I think these are dveice specific and thus should have "brcm," prefix.
> I'm confused as to why we need the brcm prefix? Other device tree
> bindings we have for other drivers do not need such prefix.
Properties that are not standard on the system (reg, interrupts,
clkocks, etc) or subsystem level customarily carry the vendor prefix so
that they do not clash with newly added global or subsystem properties.
> Is this
> convention documented somewhere?
Not sure. I glanced through Documentation/devicetree and do not see it
spelled out. Device tree overlords, what say you?
> >
> >>+
> >>+ priv->ts_rotation = TS_ROTATION_0;
> >>+ if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
> >>+ priv->ts_rotation = val;
> >>+ dev_dbg(dev, "ts rotation [%d] degrees\n",
> >>+ 90 * priv->ts_rotation);
> >>+ }
> >
> >This I am not quite sure about - if we want rotation or swap+invert. You
> >are CCed on another email (tsc2007) that talks about need of generic
> >touchscreen transforms in input core/of bindings.
> Does such generic binding exist today? If not, I would like to go
> with this implementation and update to the new binding if/when it
> exists?
Not yet but there several people interested. I think we have enough time
till 3.20 to hash it out properly.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] clk: samsung: exynos7: add clocks for audio block
Hi Vivek, On 1/13/15, Vivek Gautam wrote: > Hi Padma, > > > On Fri, Dec 19, 2014 at 6:53 PM, Padmavathi Venna > wrote: >> Add required clk support for I2S,PCM amd SPDIF >> >> Signed-off-by: Padmavathi Venna >> --- > > verified from Exynos7 datasheet. The patch looks good. > Reviewed-by: Vivek Gautam > Thanks for the review. Hi Sylwester, I posted patches after re-basing on your tree and after incorporating all comments from Vivek. Below is the link http://www.spinics.net/lists/linux-samsung-soc/msg40992.html Can you pick the patches? Thanks Padma -- 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 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
Hi Jonathan,
On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
+ if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
+ if (val < 1 || val > 256) {
+ dev_err(dev, "scanning_period must be [1-256]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.scanning_period = val;
+ }
+
+ if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
+ if (val < 0 || val > 255) {
+ dev_err(dev, "debounce_timeout must be [0-255]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.debounce_timeout = val;
+ }
+
+ if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
+ if (val < 0 || val > 11) {
+ dev_err(dev, "settling_timeout must be [0-11]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.settling_timeout = val;
+ }
+
+ if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
+ if (val < 0 || val > 255) {
+ dev_err(dev, "touch_timeout must be [0-255]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.touch_timeout = val;
+ }
+
+ if (of_property_read_u32(np, "average_data", &val) >= 0) {
+ if (val < 0 || val > 8) {
+ dev_err(dev, "average_data must be [0-8]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.average_data = val;
+ }
+
+ if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
+ if (val < 0 || val > 31) {
+ dev_err(dev, "fifo_threshold must be [0-31]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.fifo_threshold = val;
+ }
I think these are dveice specific and thus should have "brcm," prefix.
I'm confused as to why we need the brcm prefix? Other device tree
bindings we have for other drivers do not need such prefix. Is this
convention documented somewhere?
+
+ priv->ts_rotation = TS_ROTATION_0;
+ if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
+ priv->ts_rotation = val;
+ dev_dbg(dev, "ts rotation [%d] degrees\n",
+ 90 * priv->ts_rotation);
+ }
This I am not quite sure about - if we want rotation or swap+invert. You
are CCed on another email (tsc2007) that talks about need of generic
touchscreen transforms in input core/of bindings.
Does such generic binding exist today? If not, I would like to go with
this implementation and update to the new binding if/when it exists?
Thanks.
--
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 net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
On Wed, 2015-01-14 at 14:34 +0800, Ding Tianhong wrote:
> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
Mostly trivial comments:
> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
[]
> +#define GMAC_MAX_PKT_LEN 1516
[]
> +static int hip04_rx_poll(struct napi_struct *napi, int budget)
> +{
[]
> + while (cnt && !last) {
[]
> + desc = (struct rx_desc *)skb->data;
> + len = be16_to_cpu(desc->pkt_len);
> + err = be32_to_cpu(desc->pkt_err);
> +
> + if (0 == len) {
> + dev_kfree_skb_any(skb);
> + last = true;
> + } else if ((err & RX_PKT_ERR) || (len >= GMAC_MAX_PKT_LEN)) {
Is this ">=" correct? Maybe it should be ">" ?
[]
> +static irqreturn_t hip04_mac_interrupt(int irq, void *dev_id)
> +{
> + struct net_device *ndev = (struct net_device *)dev_id;
Unnecessary cast of void *
[]
> +static int hip04_set_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *ec)
> +{
> + struct hip04_priv *priv = netdev_priv(netdev);
> +
> + /* Check not supported parameters */
> + if ((ec->rx_max_coalesced_frames) || (ec->rx_coalesce_usecs_irq) ||
> + (ec->rx_max_coalesced_frames_irq) || (ec->tx_coalesce_usecs_irq) ||
> + (ec->use_adaptive_rx_coalesce) || (ec->use_adaptive_tx_coalesce) ||
> + (ec->pkt_rate_low) || (ec->rx_coalesce_usecs_low) ||
> + (ec->rx_max_coalesced_frames_low) || (ec->tx_coalesce_usecs_high) ||
> + (ec->tx_max_coalesced_frames_low) || (ec->pkt_rate_high) ||
> + (ec->tx_coalesce_usecs_low) || (ec->rx_coalesce_usecs_high) ||
> + (ec->rx_max_coalesced_frames_high) || (ec->rx_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_irq) ||
> + (ec->stats_block_coalesce_usecs) ||
> + (ec->tx_max_coalesced_frames_high) || (ec->rate_sample_interval))
> + return -EOPNOTSUPP;
Rather than a somewhat haphazard mix of these values,
this might be simpler to read as something like:
/* Check not supported parameters */
if (ec->pkt_rate_low ||
ec->pkt_rate_high ||
ec->use_adaptive_rx_coalesce ||
ec->rx_coalesce_usecs ||
ec->rx_coalesce_usecs_low ||
ec->rx_coalesce_usecs_high ||
ec->rx_coalesce_usecs_irq ||
ec->rx_max_coalesced_frames ||
ec->rx_max_coalesced_frames_low ||
ec->rx_max_coalesced_frames_high ||
ec->rx_max_coalesced_frames_irq ||
ec->use_adaptive_tx_coalesce ||
ec->tx_coalesce_usecs_low ||
ec->tx_coalesce_usecs_high ||
ec->tx_max_coalesced_frames_low ||
ec->tx_max_coalesced_frames_high ||
ec->tx_max_coalesced_frames_irq ||
ec->stats_block_coalesce_usecs ||
ec->rate_sample_interval)
return -EOPNOTSUPP;
> +static void hip04_free_ring(struct net_device *ndev, struct device *d)
> +{
> + struct hip04_priv *priv = netdev_priv(ndev);
> + int i;
> +
> + for (i = 0; i < RX_DESC_NUM; i++)
> + if (priv->rx_buf[i])
> + put_page(virt_to_head_page(priv->rx_buf[i]));
It's generally nicer to use braces around
for loops with single ifs.
> +
> + for (i = 0; i < TX_DESC_NUM; i++)
> + if (priv->tx_skb[i])
> + dev_kfree_skb_any(priv->tx_skb[i]);
--
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 mtd] mtd:devices: Add Altera EPCQ Driver
Hi Brian,
For Altera EPCQ flashes, almost operations are performed underline hardware.
Software only able to perform the following through registers:
- read status register
- read id
- write status registers bit SR_BP0,SR_BP1, SR_BP2,SR_BP3, SR_TB
(http://www.altera.com.my/literature/hb/cfg/cfg_cf52012.pdf)
For read/write data: all the operations like QUAD_READ/WRITE, FAST_READ/WRITE
are handled by hardware as well. From software point of view, there is no
difference between these 2 modes.
That is why if rewrite the drivers to follow spi-nor structure, it will require
extra decoding works for the only few used opcodes.
Thanks,
Viet Nga
-Original Message-
From: Brian Norris [mailto:computersforpe...@gmail.com]
Sent: Tuesday, January 13, 2015 11:33 AM
To: Viet Nga Dao
Cc: dw...@infradead.org; linux-...@lists.infradead.org;
linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; ngach...@gmail.com
Subject: Re: [PATCH mtd] mtd:devices: Add Altera EPCQ Driver
On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote:
> From: Viet Nga Dao
>
> Altera EPCQ Controller is a soft IP which enables access to Altera
> EPCQ and EPCS flash chips. This patch adds driver for these devices.
>
> Signed-off-by: Viet Nga Dao
This drivers seems awfully similar to (and so I infer it is likely
copy-and-pasted from) m25p80.c / spi-nor.c. Do you think it can be rewritten as
a SPI NOR driver, under drivers/mtd/spi-nor/ ? It looks like these flash share
most (all?) the same basic opcodes.
> ---
> .../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
> drivers/mtd/devices/Kconfig| 12 +
> drivers/mtd/devices/Makefile |2 +-
> drivers/mtd/devices/altera_epcq.c | 804
>
> drivers/mtd/devices/altera_epcq.h | 130
> 5 files changed, 992 insertions(+), 1 deletions(-) create mode
> 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
> create mode 100644 drivers/mtd/devices/altera_epcq.c create mode
> 100644 drivers/mtd/devices/altera_epcq.h
>
> diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
> b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
> new file mode 100644
> index 000..d14f50e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
> @@ -0,0 +1,45 @@
> +* MTD Altera EPCQ driver
> +
> +Required properties:
> +- compatible: Should be "altr,epcq-1.0"
> +- reg: Address and length of the register set for the device. It
> +contains
> + the information of registers in the same order as described by
> +reg-names
> +- reg-names: Should contain the reg names
> + "csr_base": Should contain the register configuration base address
> + "data_base": Should contain the data base address
> +- is-epcs: boolean type.
> + If present, the device contains EPCS flashes.
> + Otherwise, it contains EPCQ flashes.
> +- #address-cells: Must be <1>.
> +- #size-cells: Must be <0>.
> +- flash device tree subnode, there must be a node with the following fields:
These subnodes definitely require a 'compatible' string. Perhaps they should be
used to differentiate EPCS vs. EPCQ. Does "is-epcs" really need to be in the
top-level controller node?
> + - reg: Should contain the flash id
Should, or must? (This question is relevant, because you seem to make it
optional in your code.) And what does the "flash ID" mean? It seems like you're
using as a chip-select or bank index.
> + - #address-cells: please refer to /mtd/partition.txt
> + - #size-cells: please refer to /mtd/partition.txt
> + For partitions inside each flash, please refer to /mtd/partition.txt
> +
> +Example:
> +
> + epcq_controller_0: epcq@0x0 {
> + compatible = "altr,epcq-1.0";
> + reg = <0x0001 0x 0x0020>,
> + <0x 0x 0x0200>;
> + reg-names = "csr_base", "data_base";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + flash0: epcq256@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + /* 16 MB for raw data. */
> + label = "EPCQ Flash 0 raw data";
> + reg = <0x0 0x100>;
> + };
> + partition@100 {
> + /* 16 MB for jffs2 data. */
> + label = "EPCQ Flash 0 JFFS 2";
> +
Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
On 2015/1/14 16:06, Joe Perches wrote:
> On Wed, 2015-01-14 at 14:34 +0800, Ding Tianhong wrote:
>> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
>> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
>
> Single comment:
>
>> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c
>> b/drivers/net/ethernet/hisilicon/hip04_eth.c
> []
>> +static int hip04_rx_poll(struct napi_struct *napi, int budget)
>> +{
> []
>> +while (cnt && !last) {
>> +buf = priv->rx_buf[priv->rx_head];
>> +skb = build_skb(buf, priv->rx_buf_size);
>> +if (unlikely(!skb))
>> +net_dbg_ratelimited("build_skb failed\n");
>> +
>> +dma_unmap_single(&ndev->dev, priv->rx_phys[priv->rx_head],
>> + RX_BUF_SIZE, DMA_FROM_DEVICE);
>> +priv->rx_phys[priv->rx_head] = 0;
>> +
>> +desc = (struct rx_desc *)skb->data;
>
> Perhaps if (!skb) is possible, there shouldn't be
> a dereference of that known null here.
>
Yes, we should return and do something to avoid oops, thanks.
Ding
>
>
> .
>
--
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 net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
On 2015/1/14 16:53, Arnd Bergmann wrote: > On Wednesday 14 January 2015 14:34:14 Ding Tianhong wrote: >> +#define HIP04_MAX_TX_COALESCE_USECS200 >> +#define HIP04_MIN_TX_COALESCE_USECS100 >> +#define HIP04_MAX_TX_COALESCE_FRAMES 200 >> +#define HIP04_MIN_TX_COALESCE_FRAMES 100 > > It's not important, but in case you are creating another version of the > patch, maybe the allowed range can be extended somewhat. The example values > I picked when I sent my suggestion were really made up. It's great if > they work fine, but users might want to tune this far more depending on > their workloads, How about these > > #define HIP04_MAX_TX_COALESCE_USECS10 > #define HIP04_MIN_TX_COALESCE_USECS1 > #define HIP04_MAX_TX_COALESCE_FRAMES (TX_DESC_NUM - 1) > #define HIP04_MIN_TX_COALESCE_FRAMES 1 > Is it really ok that the so big range may break the driver and hip04 could not work fine? I am not sure it is ok, I will fix it in next version. Ding > 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
[PATCH 0/3] add support for Firefly-RK3288 and Rayeager PX2 boards
This series adds support for following Rockchip SoC based boards. - Firefly, Firefly-RK3288 (both beta and mass production version) - ChipSPARK, Rayeager PX2 FUKAUMI Naoki (3): dt-bindings: add vendor prefix and root compatible property for Rockchip boards ARM: dts: rockchip: add dts for Firefly Firefly-RK3288 boards ARM: dts: rockchip: add dts for ChipSPARK Rayeager PX2 board Documentation/devicetree/bindings/arm/rockchip.txt | 8 + .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/arm/boot/dts/Makefile | 5 +- arch/arm/boot/dts/rk3066a-rayeager.dts | 457 +++ arch/arm/boot/dts/rk3288-firefly-beta.dts | 70 +++ arch/arm/boot/dts/rk3288-firefly.dts | 70 +++ arch/arm/boot/dts/rk3288-firefly.dtsi | 498 + 7 files changed, 1109 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/rk3066a-rayeager.dts create mode 100644 arch/arm/boot/dts/rk3288-firefly-beta.dts create mode 100644 arch/arm/boot/dts/rk3288-firefly.dts create mode 100644 arch/arm/boot/dts/rk3288-firefly.dtsi -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: rockchip: add dts for Firefly Firefly-RK3288 boards
Signed-off-by: FUKAUMI Naoki
---
arch/arm/boot/dts/Makefile| 4 +-
arch/arm/boot/dts/rk3288-firefly-beta.dts | 70 +
arch/arm/boot/dts/rk3288-firefly.dts | 70 +
arch/arm/boot/dts/rk3288-firefly.dtsi | 498 ++
4 files changed, 641 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/rk3288-firefly-beta.dts
create mode 100644 arch/arm/boot/dts/rk3288-firefly.dts
create mode 100644 arch/arm/boot/dts/rk3288-firefly.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cb686e6..fb03a2b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -447,7 +447,9 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-marsboard.dtb \
rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
- rk3288-evb-rk808.dtb
+ rk3288-evb-rk808.dtb \
+ rk3288-firefly-beta.dtb \
+ rk3288-firefly.dtb
dtb-$(CONFIG_ARCH_S3C24XX) += \
s3c2416-smdk2416.dtb
dtb-$(CONFIG_ARCH_S3C64XX) += \
diff --git a/arch/arm/boot/dts/rk3288-firefly-beta.dts
b/arch/arm/boot/dts/rk3288-firefly-beta.dts
new file mode 100644
index 000..d640569
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-firefly-beta.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2014, 2015 FUKAUMI Naoki
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3288-firefly.dtsi"
+
+/ {
+ model = "Firefly-RK3288 Beta";
+};
+
+&ir {
+ gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pinctrl {
+ ir {
+ ir_int: ir-int {
+ rockchip,pins = <7 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ act8846 {
+ pmic_vsel: pmic-vsel {
+ rockchip,pins = <7 1 RK_FUNC_GPIO &pcfg_output_low>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/rk3288-firefly.dts
b/arch/arm/boot/dts/rk3288-firefly.dts
new file mode 100644
index 000..0bdc37c
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-firefly.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2014, 2015 FUKAUMI Naoki
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ *
[PATCH 3/3] ARM: dts: rockchip: add dts for ChipSPARK Rayeager PX2 board
Signed-off-by: FUKAUMI Naoki
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3066a-rayeager.dts | 457 +
2 files changed, 458 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3066a-rayeager.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fb03a2b..4c56746 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -445,6 +445,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
+ rk3066a-rayeager.dtb \
rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts
b/arch/arm/boot/dts/rk3066a-rayeager.dts
new file mode 100644
index 000..729a039
--- /dev/null
+++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2014, 2015 FUKAUMI Naoki
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3066a.dtsi"
+
+/ {
+ model = "Rayeager PX2";
+ compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
+
+ memory {
+ reg = <0x6000 0x4000>;
+ };
+
+ ir: ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio6 1 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_int>;
+ };
+
+ keys: gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ button@0 {
+ gpio-key,wakeup = <1>;
+ gpios = <&gpio6 2 GPIO_ACTIVE_LOW>;
+ label = "GPIO Power";
+ linux,code = <116>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_key>;
+ };
+ };
+
+ vsys: vsys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_otg: usb-otg-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&otg_drv>;
+ regulator-name = "vcc_otg";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ vcc_host: usb-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_drv>;
+ regulator-name = "host-pwr";
+ regulator-min-microvolt = <500>
[PATCH 1/3] dt-bindings: add vendor prefix and root compatible property for Rockchip boards
this adds vendor prefix and root compatible property for following boards - Firefly, Firefly-RK3288 board - ChipSPARK, Rayeager PX2 board PX2 SoC is fully compatible with RK3066. Signed-off-by: FUKAUMI Naoki --- Documentation/devicetree/bindings/arm/rockchip.txt| 8 Documentation/devicetree/bindings/vendor-prefixes.txt | 2 ++ 2 files changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index eaa3d1a..7cc1cecd 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -9,6 +9,14 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "mundoreader,bq-curie2", "rockchip,rk3066a"; +- ChipSPARK Rayeager PX2 board: +Required root node properties: + - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a"; + - Radxa Rock board: Required root node properties: - compatible = "radxa,rock", "rockchip,rk3188"; + +- Firefly Firefly-RK3288 board: +Required root node properties: + - compatible = "firefly,firefly-rk3288", "rockchip,rk3288"; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 5d2251a..0d37f5f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -32,6 +32,7 @@ capella Capella Microsystems, Inc cavium Cavium, Inc. cdns Cadence Design Systems Inc. chipidea Chipidea, Inc +chipspark ChipSPARK chrp Common Hardware Reference Platform chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. @@ -62,6 +63,7 @@ everest Everest Semiconductor Co. Ltd. everspin Everspin Technologies, Inc. excito Excito fcsFairchild Semiconductor +fireflyFirefly fslFreescale Semiconductor GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc. gefGE Fanuc Intelligent Platforms Embedded Systems, Inc. -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
On 2015/1/15 3:25, Brian Norris wrote:
> On Wed, Jan 14, 2015 at 08:34:39PM +0800, Zhou Wang wrote:
>> On 2015/1/13 11:58, Brian Norris wrote:
>>> On Mon, Jan 12, 2015 at 03:28:53PM +0800, Zhou Wang wrote:
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ chip->IO_ADDR_R = chip->IO_ADDR_W = devm_ioremap_resource(dev, res);
>>>
>>> Hmm, do you really have to reuse IO_ADDR_{R,W} here? Those are only
>>> targeted for NAND systems which have a direct MMIO mapping to the NAND
>>> I/O pins. See nand_base's {read,write}_buf() and read_{byte,word}()
>>> implementations. But you override those.
>>
>> There is a hardware buffer in this NAND controller, and the buffer can be
>> accessed as MMIO.
>
> Sure.
>
>> IO_ADDR_R/W just indicates the base address of this buffer.
>
> But I was noting that IO_ADDR_{R,W} actually serve a very particular
> purpose in nand_base.c, which seems distinct from your HW buffer.
>
>> Maybe I need to use a void __iomem pointer stored in my host struct to use
>> this buffer instead of IO_ADDR_R/W as you said below here?
>
> Yes, I think that would be better.
OK, I will do as this in next version, Thanks!
>
>>> It's best if it's obvious if nand_base is somehow inadvertently using
>>> these pointers. So leaving them NULL is helpful.
>>>
>>> As an alternative, you can just stash another private void __iomem
>>> pointer in you your host struct.
>
> Thanks,
> Brian
Thanks for your reply!
Zhou Wang
>
> .
>
--
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 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
On 19/12/14 15:03, Jonathan Richardson wrote:
> On 14-12-19 02:26 PM, Joe Perches wrote:
>> On Fri, 2014-12-19 at 14:17 -0800, Jonathan Richardson wrote:
>>> Add initial version of the Broadcom touchscreen driver.
>>
>> more trivia:
>>
>>> diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c
>>> b/drivers/input/touchscreen/bcm_iproc_tsc.c
>> []
>>> +static int get_tsc_config(struct device_node *np, struct iproc_ts_priv
>>> *priv)
>>> +{
>>> + u32 val;
>> []
>>> + if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
>>> + if (val < 0 || val > 255) {
>>> + dev_err(dev, "debounce_timeout must be [0-255]\n");
>>> + return -EINVAL;
>>> + }
>>> + priv->cfg_params.debounce_timeout = val;
BTW, common practice for DT properties is to use a dash instead of an
underscore for multi-worded properties.
>>
>> Doesn't the compiler generate a warning message
>> about an impossible "unsigned < 0" test for all
>> of these "val < 0" uses?
>>
>
> Actually no it doesn't. The gcc output shows that neither -Wtype-limits
> nor -Wextra are used to compile that file. I assume this is because
> there would be just too many warnings.
>
>
>>> + }
>>> +
>>> + if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
>>> + if (val < 0 || val > 11) {
>> []
>>> + if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
>>> + if (val < 0 || val > 255) {
>> []
>>> + if (of_property_read_u32(np, "average_data", &val) >= 0) {
>>> + if (val < 0 || val > 8) {
>> []
>>> + if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
>>> + if (val < 0 || val > 31) {
>>
>>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors
From: Kevin Hilman
The odroid-xu3 has 4 INA231 current sensors on board which can be
accessed from the Linux via the hwmon interface.
There is one sensor for each of these power rails:
- A15 cluster: VDD_ARM
- A7 cluster: VDD_KFC
- GPU: VDD_G3D
- memory: VDD_MEM
In addition to adding the sensors, LDO26 from the PMIC needs to be
enabled because it's powering these sensor.
Cc: Javier Martinez Canillas
Cc: Sjoerd Simons
Signed-off-by: Kevin Hilman
---
v2: use "ti,ina231" as compatible string.
Applies on top of "ARM: dts: Add dts file for odroid XU3 board" from Sjoerd
Simons.
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 ++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index c29123c0734d..50353d023225 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -174,6 +174,13 @@
regulator-always-on;
};
+ ldo26_reg: LDO26 {
+ regulator-name = "vdd_ldo26";
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-always-on;
+ };
+
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <80>;
@@ -257,6 +264,38 @@
};
};
+ i2c_0: i2c@12C6 {
+ status = "okay";
+
+ /* A15 cluster: VDD_ARM */
+ ina231@40 {
+ compatible = "ti,ina231";
+ reg = <0x40>;
+ shunt-resistor = <1>;
+ };
+
+ /* memory: VDD_MEM */
+ ina231@41 {
+ compatible = "ti,ina231";
+ reg = <0x41>;
+ shunt-resistor = <1>;
+ };
+
+ /* GPU: VDD_G3D */
+ ina231@44 {
+ compatible = "ti,ina231";
+ reg = <0x44>;
+ shunt-resistor = <1>;
+ };
+
+ /* A7 cluster: VDD_KFC */
+ ina231@45 {
+ compatible = "ti,ina231";
+ reg = <0x45>;
+ shunt-resistor = <1>;
+ };
+ };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
--
2.1.3
--
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: [PATCHv2 2/2] spi: orion: Add multiple chip select support to spi-orion
On 15/01/15 06:06, Mark Brown wrote: On Mon, Jan 12, 2015 at 01:14:00PM +1000, Ken Wilson wrote: +- num-cs : The total number of chip selects used by this platform. + If unset, this defaults to 1. So, this is intended to be the number of hardware chip selects that can be configured but the first commit mentioned GPIOs as an option too so we should at least say that this is specifically the controller supported ones. However... +#define ORION_SPI_CS_MASK 0x1C +#define ORION_SPI_CS_SHIFT 2 +#define ORION_SPI_CS(cs) ((cs << ORION_SPI_CS_SHIFT) & \ + ORION_SPI_CS_MASK) ...given that we have a fixed bitfield here which we know and doesn't appear to depend on configuration do we even need this to be configurable - given that we're going to need an explicit node for any slave can't we just accept any sane chip select for a slave without extending the binding? The different implementations that use this driver (Marvell Kirkwood, Armada 370/375) all have a different number of supported chip selects, that fit into this bit mask. There are also multiple SPI controllers on each SoC which support different numbers of chip selects. For example, on the Armada 375, SPI0 supports 3 chip selects, while SPI1 only has 1. I agree that we could support any sane chip select for a slave, since the slave addresses do need to be explicitly defined. I'm happy with whatever your preference is. Thanks, Ken -- 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: [PATCHv0 2/3] rtc: Add support for Abracon AB-RTCMC-32.768kHz-B5ZE-S3 I2C RTC chip
On Wed, 14 Jan 2015 16:55:57 -0800 Andrew Morton
wrote:
> Something like this?
Leading to changes in [3/3]. Please have a think about where we should
be calling device_init_wakeup(dev, false) on the error recovery path.
Let me know if I should just drop it all and await a v2...
@@ -655,24 +896,28 @@ static int abb5zes3_probe(struct i2c_cli
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C |
I2C_FUNC_SMBUS_BYTE_DATA |
-I2C_FUNC_SMBUS_I2C_BLOCK))
- return -ENODEV;
+I2C_FUNC_SMBUS_I2C_BLOCK)) {
+ ret = -ENODEV;
+ goto out;
+ }
regmap = devm_regmap_init_i2c(client, &abb5zes3_rtc_regmap_config);
if (IS_ERR(regmap)) {
ret = PTR_ERR(regmap);
dev_err(dev, "%s: regmap allocation failed: %d\n",
__func__, ret);
- return ret;
+ goto out;
}
ret = abb5zes3_i2c_validate_chip(regmap);
if (ret)
- return ret;
+ goto out;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
mutex_init(&data->lock);
data->regmap = regmap;
@@ -680,7 +925,7 @@ static int abb5zes3_probe(struct i2c_cli
ret = abb5zes3_rtc_check_setup(dev);
if (ret)
- return ret;
+ goto out;
if (client->irq > 0) {
ret = devm_request_threaded_irq(dev, client->irq, NULL,
@@ -695,7 +940,7 @@ static int abb5zes3_probe(struct i2c_cli
} else {
dev_err(dev, "%s: irq %d unavailable (%d)\n",
__func__, client->irq, ret);
- return ret;
+ goto out;
}
}
@@ -705,29 +950,23 @@ static int abb5zes3_probe(struct i2c_cli
if (ret) {
dev_err(dev, "%s: unable to register RTC device (%d)\n",
__func__, ret);
- goto err;
+ goto out_deinit_wakeup;
}
- /*
-* AB-B5Z5E only supports a coarse granularity alarm (one minute
-* resolution up to one month) so we cannot support UIE mode
-* using the device's alarm. Note it should be feasible to support
-* such a feature using one of the two timers the device provides.
-*/
- data->rtc->uie_unsupported = 1;
-
/* Enable battery low detection interrupt if battery not already low */
if (!data->battery_low && data->irq) {
ret = _abb5zes3_rtc_battery_low_irq_enable(regmap, true);
if (ret) {
dev_err(dev, "%s: enabling battery low interrupt "
"generation failed (%d)\n", __func__, ret);
- goto err;
+ goto out_deinit_wakeup;
}
}
+out:
return ret;
-err:
+
+out_deinit_wakeup:
device_init_wakeup(dev, false);
return ret;
}
_
--
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 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
Hi Jonathan,
On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> + if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
> + if (val < 1 || val > 256) {
> + dev_err(dev, "scanning_period must be [1-256]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.scanning_period = val;
> + }
> +
> + if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
> + if (val < 0 || val > 255) {
> + dev_err(dev, "debounce_timeout must be [0-255]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.debounce_timeout = val;
> + }
> +
> + if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
> + if (val < 0 || val > 11) {
> + dev_err(dev, "settling_timeout must be [0-11]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.settling_timeout = val;
> + }
> +
> + if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
> + if (val < 0 || val > 255) {
> + dev_err(dev, "touch_timeout must be [0-255]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.touch_timeout = val;
> + }
> +
> + if (of_property_read_u32(np, "average_data", &val) >= 0) {
> + if (val < 0 || val > 8) {
> + dev_err(dev, "average_data must be [0-8]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.average_data = val;
> + }
> +
> + if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
> + if (val < 0 || val > 31) {
> + dev_err(dev, "fifo_threshold must be [0-31]\n");
> + return -EINVAL;
> + }
> + priv->cfg_params.fifo_threshold = val;
> + }
I think these are dveice specific and thus should have "brcm," prefix.
> +
> + priv->ts_rotation = TS_ROTATION_0;
> + if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
> + priv->ts_rotation = val;
> + dev_dbg(dev, "ts rotation [%d] degrees\n",
> + 90 * priv->ts_rotation);
> + }
This I am not quite sure about - if we want rotation or swap+invert. You
are CCed on another email (tsc2007) that talks about need of generic
touchscreen transforms in input core/of bindings.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] power: rt5033_battery: Add RT5033 Fuel gauge device driver
Hi, On Fri, Jan 09, 2015 at 05:45:11PM +0900, Beomho Seo wrote: > This patch adds device driver of Richtek PMIC. > The driver support battery fuel gange. Fuel gauge calculates and determines > the > battery state of charge(SOC) according to battery open circuit voltage(OCV). > Also, this driver provides battery average voltage, voltage and bettery > present > property. Thanks, applied: http://git.infradead.org/battery-2.6.git/commit/3cfb56d7ff013762a17b6a1b78bb3b0e4a6a6588 -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation
On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote: > Ping for input maintainer. DT changes was acked. Thanks. > > On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko wrote: > > This patch adds new parameters that allow to address typical hardware > > design differences: touch screens may be wired or oriented differently > > (portrait or landscape). And usually the active area of the touch is a > > little larger than the active area of the LCD. This results in the touch > > coordinates that have some significant deviation from LCD coordinates. > > Usually this is addressed in user space by a calibration tool (e.g. tslib > > or xinput-calibrator) but some systems don't have these tools or require > > that the screen is already roughly calibrated (e.g. Replicant) to operate > > the device until a better calibration can be done. And, some systems > > react very strangely if the touch event stream reports coordinates > > outside of the active area. > > > > This makes it necessry to be able to configure: > > 1. swapping x and y wires (coordinate values) > > 2. flipping of x (left - right) or y (top - bottom) or even both > > 3. define an active area so that an uncalibrated screen already > > roughly matches the LCD to be useful. > > 4. clip reported coordinates to the active area. > > > > If none of the new parameters is defined (in DT) or set in a board file, > > the driver behaves the same as without this patch. > > > > Author (1&2): H. Nikolaus Schaller > > Author (3&4): Paul Kocialkowski > > > > Signed-off-by: H. Nikolaus Schaller OK, I was hesitant of adding these as normally we have tslib to perform the conversion, but maybe it is time to allow it in the kernel and standardize users. However, this seems like a general issue and we should: 1. Perform conversion in input core rather than individual drivers. I think we should allocate a new bitmaps for some transformations and have the code do X/Y flip/clip of the coordinates. 2. Standardize on bindings. We already have of-touchscreen.c doing rudimentary parsing, we shoudl look into extending it rather than creating myriad of driver-specific bindings. Also, do we need swap and flip or do we simply need rotation (like the proposed Broadcom iproc driver has)? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv0 2/3] rtc: Add support for Abracon AB-RTCMC-32.768kHz-B5ZE-S3 I2C RTC chip
On Mon, 12 Jan 2015 09:16:36 +0100 Arnaud Ebalard wrote:
> This patch adds support for Abracon AB-RTCMC-32.768kHz-B5ZE-S3
> RTC/Calendar module w/ I2C interface.
>
> This supports includes RTC time reading and setting, Alarm (1 minute
> accuracy) reading and setting, and battery low detection. The device
> also supports frequency adjustment and two timers but those features
> are currently not implemented in this driver. Due to alarm accuracy
> limitation (and current lack of timer support in the driver), UIE
> mode is not supported.
>
> ...
>
> +static int abb5zes3_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + struct abb5zes3_rtc_data *data;
> + struct regmap *regmap;
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C |
> + I2C_FUNC_SMBUS_BYTE_DATA |
> + I2C_FUNC_SMBUS_I2C_BLOCK))
> + return -ENODEV;
> +
> + regmap = devm_regmap_init_i2c(client, &abb5zes3_rtc_regmap_config);
> + if (IS_ERR(regmap)) {
> + ret = PTR_ERR(regmap);
> + dev_err(dev, "%s: regmap allocation failed: %d\n",
> + __func__, ret);
> + return ret;
> + }
> +
> + ret = abb5zes3_i2c_validate_chip(regmap);
> + if (ret)
> + return ret;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + mutex_init(&data->lock);
> + data->regmap = regmap;
> + dev_set_drvdata(dev, data);
> +
> + ret = abb5zes3_rtc_check_setup(dev);
> + if (ret)
> + return ret;
> +
> + if (client->irq > 0) {
> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + _abb5zes3_rtc_interrupt,
> + IRQF_SHARED|IRQF_ONESHOT,
> + DRV_NAME, client);
> + if (!ret) {
> + device_init_wakeup(dev, true);
> + data->irq = client->irq;
> + dev_dbg(dev, "%s: irq %d used by RTC\n", __func__,
> + client->irq);
> + } else {
> + dev_err(dev, "%s: irq %d unavailable (%d)\n",
> + __func__, client->irq, ret);
> + }
> + }
> +
> + data->rtc = devm_rtc_device_register(dev, DRV_NAME, &rtc_ops,
> + THIS_MODULE);
> + ret = PTR_ERR_OR_ZERO(data->rtc);
If devm_request_threaded_irq() returned an error, we just wiped that
out here. I'd suggest consistently adding a few "return ret;"
statements in this function.
Something like this?
---
a/drivers/rtc/rtc-ab-b5ze-s3.c~rtc-add-support-for-abracon-ab-rtcmc-32768khz-b5ze-s3-i2c-rtc-chip-fix
+++ a/drivers/rtc/rtc-ab-b5ze-s3.c
@@ -695,6 +695,7 @@ static int abb5zes3_probe(struct i2c_cli
} else {
dev_err(dev, "%s: irq %d unavailable (%d)\n",
__func__, client->irq, ret);
+ return ret;
}
}
@@ -704,7 +705,7 @@ static int abb5zes3_probe(struct i2c_cli
if (ret) {
dev_err(dev, "%s: unable to register RTC device (%d)\n",
__func__, ret);
- device_init_wakeup(dev, false);
+ goto err;
}
/*
@@ -718,12 +719,17 @@ static int abb5zes3_probe(struct i2c_cli
/* Enable battery low detection interrupt if battery not already low */
if (!data->battery_low && data->irq) {
ret = _abb5zes3_rtc_battery_low_irq_enable(regmap, true);
- if (ret)
+ if (ret) {
dev_err(dev, "%s: enabling battery low interrupt "
"generation failed (%d)\n", __func__, ret);
+ goto err;
+ }
}
return ret;
+err:
+ device_init_wakeup(dev, false);
+ return ret;
}
static int abb5zes3_remove(struct i2c_client *client)
_
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 00/13] ltc2952 modernization and new functionality
Hi, On Wed, Jan 14, 2015 at 09:15:33AM +0100, Frans Klaver wrote: > Here's a resend of an earlier cleanup and improvement series for > the ltc2952 driver. > > This series implements devm_* usage, reduction of globals, some > cleanup and finally makes the input trigger optional. > > From the changes to the previous submissions I did not include > renaming kill to poweroff. The name poweroff is already used a > lot. Besides that, the control is referred to as kill in the > ltc2952 datasheet. Thanks for the cleanup, applied: http://git.infradead.org/battery-2.6.git/commit/d84ba07c27fafca3cc77b25a1e204383a4b5af91 -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] i.MX6-SabreAuto: EIM: pull PAD_EIM_D18 low for NOR probe
+ linux-arm-kernel, maintainers, devicetree
Shawn, Sascha: should this driver be listed under the Freescale IMX
MAINTAINERS entry?
On Wed, Jan 14, 2015 at 03:36:49PM -0800, ali...@she-devel.com wrote:
> From: Alison Chaiken
>
> PAD_EIM_D18 must be pulled low at boot in order for the parallel NOR
> connected to the EIM switch to probe properly. Otherwise
> cfi_qry_present() may return "U-V-]" rather than "Q-R-Y" if the
> PAD_EIM_D18 is high. Add a nor-gpios property to the nor node in the
> SabreAuto device-tree and add a function to the imx-weim probe to set
> GPIO5 to drive the pad.
>
> Signed-off-by: Alison Chaiken
> ---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 1 +
> drivers/bus/imx-weim.c | 43
>
> 2 files changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 009abd6..dd5e3bc 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -454,5 +454,6 @@
> bank-width = <2>;
> fsl,weim-cs-timing = <0x00620081 0x0001 0x1c022000
> 0xc000 0x1404a38e 0x>;
> + nor-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
Such a binding needs to be documented. Also, if it's going to be named
generically like that, it needs to be generically useful and supported
under MTD code, not platform-specific bus code.
So what pin is this, exactly? A write-protect pin? An address pin? A
toaster control, where the toaster is keeping the flash too hot?
> };
> };
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 0958b69..b3c2ca6 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> struct imx_weim_devtype {
> unsigned intcs_count;
> @@ -108,6 +110,40 @@ err:
> return -EINVAL;
> }
>
> +/* set the GPIO to control PAD_EIM_D18 so cfi_qry_present() works properly */
> +static int __init nor_gpio_setup(struct device_node *np, struct device
> *parent)
> +{
> + unsigned nor_gpio, level;
> + enum of_gpio_flags of_flags;
> + int ret;
> +
> + nor_gpio = of_get_named_gpio_flags(np, "nor-gpios", 0, &of_flags);
> +
> + /* this child is not a NOR chip */
> + if (!nor_gpio)
> + return 0;
> +
> + if (gpio_is_valid(nor_gpio)) {
> + ret = devm_gpio_request_one(parent, nor_gpio,
> + GPIOF_DIR_OUT, "nor-gpio");
> + } else {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + if (ret < 0)
> + goto out;
> +
> + level = ((of_flags == OF_GPIO_ACTIVE_LOW) ? 0 : 1);
> +
> + gpio_set_value(nor_gpio, level);
> +
> + return 0;
> +out:
> + dev_err(parent, "Unable to request EIM_D18 GPIO for NOR.\n");
> + return ret;
> +}
> +
> /* Parse and set the timing for this device. */
> static int __init weim_timing_setup(struct device_node *np, void __iomem
> *base,
> const struct imx_weim_devtype *devtype)
> @@ -160,6 +196,13 @@ static int __init weim_parse_dt(struct platform_device
> *pdev,
> child->full_name);
> return ret;
> }
> +
> + ret = nor_gpio_setup(child, &pdev->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "%s gpios setup failed.\n",
> + child->full_name);
> + return ret;
> + }
> }
>
> ret = of_platform_populate(pdev->dev.of_node,
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: shmobile: Add DT support for memory controllers
On Wed, Jan 14, 2015 at 12:12:58PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series adds DT binding documentation and devices nodes to > describe memory-controllers in R-Mobile and SH-Mobile SoCs. > > Currently memory controller device nodes are used only to reference PM > domains, and prevent these PM domains from being powered down, which > would crash the system. > > As such this series is a prerequisite for adding DT PM domain support to > sh73a0 (SH-Mobile AG5) and r7a73a4 (R-Mobile APE6). > For r8a7740 (R-Mobile A1), this wasn't a hard prerequisite for PM > domain support, as the A4S PM domain is never turned off anyway > because its child PM domain A3SM contains the CPU core. > > The patches for sh73a0 and r8a7740 have been sent before as part of > (patches in) the series "[PATCH RFC 0/7] ARM: shmobile: sh73a0: DT PM > domain support" (https://lkml.org/lkml/2014/11/19/404). > > "ARM: shmobile: r8a7740 dtsi: Add memory-controller node" depends on > the DT R-Mobile PM Domain support for r8a7740 that's queued up in > Simon's tree under tag renesas-dt-pm-for-v3.20, as the > memory-controller node already contains a power-domains property. > > The two other dtsi patches do not add power-domains properties yet. > These will be added when adding PM domain support for sh73a0 resp. > r8a73a4. > > Thanks! Thanks Geert, I have queued these up. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] ARM: shmobile: sh73a0: DT PM domain support
Hi Geert,
On Wed, Jan 14, 2015 at 01:11:18PM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> This patch series enables DT support for PM domains on the Renesas
> SH-Mobile AG5 (sh73a0) SoC.
>
> This series builds further on the DT PM Domain support for R-Mobile A1
> (r8a7740). Due to the similarity of the SYSC System-Controller on the
> various SH-Mobile/R-Mobile SoCs, and the abstraction of PM domains in
> DT, the same driver can handle sh73a0 after some small modifications,
> without changing the DT bindings.
>
> Compared to r8a7740, the only significant change is the move of the
> memory-controller(s) to separate PM domains on sh73a0 (and also on
> R-Mobile APE6 (r8a73a4)). Hence a provision must be made to not turn off
> these PM domains inadvertently, cfr. the series "[PATCH 0/4] ARM:
> shmobile: Add DT support for memory controllers" I've just sent.
>
> This series has been sent before, as part of the series "[PATCH RFC
> 0/7] ARM: shmobile: sh73a0: DT PM domain support"
> (https://lkml.org/lkml/2014/11/19/404).
> Changes since v1 (more detailed changelogs in the individual patches):
> - Factored out addition of the memory-controller in a separate
> series.
>
> Dependencies:
> 1. Patches 1-4 (DT binding doc, C code) depend on:
>a. The R-Mobile DT PM Domain work for r8a7740, queued in tag
> renesas-dt-pm-for-v3.20 of Simon's repository,
In response to a request from Olof renesas-dt-pm-for-v3.20 has been
withdrawn and the patches split between the soc-for-v3.20 and dt-for-v3.20
branches. I am assuming that the patches that 1-4 depend on are
now all in the soc-for-v3.20 branch. Could you check?
>b. "ARM: shmobile: R-Mobile: Fix DT refcount bugs in PM domain
> code"
> (http://www.spinics.net/lists/arm-kernel/msg391084.html),
FWIW, I have squashed that patch into the patch that adds the problem
and the result is in the soc-for-v3.20. I will to push that result
a little later today.
> 2. Patch 5 (dtsi) depends on:
>a. The multiplatform work for sh73a0, queued in branch
> sh73a0-multiplatform-for-v3.20 of Simon's repository,
>b. Series "[PATCH 0/4] ARM: shmobile: Add DT support for memory
> controllers"
> (http://marc.info/?l=linux-sh&m=142123399414888).
This may be awkward to get into v3.20 unless we can adopt a looser approach
to the dependencies.
To that end I suggest that it could be queued up in the branch that has the
multiplatform work (a) but not the memory controller work (b) as the latter
seems to more naturally fit into the dt branch. What I am hoping that such
an approach would lead to code that compiles and boots in both branches.
And that new functionality becomes available when the branched are combined
(e.g. in v3.20-rcX).
If this is not possible then I can merge the pre-requisites and put
patch 5 on top. But I feel that the ARM SoC maintainers would prefer
that I didn't do that unless it is absolutely necessary.
In case you are wondering: branch gymnastics are not my favourite pass time :^)
> 3. Patch 6 (drivers/sh) depends on all of the above.
That part is clear enough :)
My intention here is to send a pull request to Linus for this change
once all the other patches have hit his tree. With a bit of luck that
would be around v3.20-rc2.
> This was tested on kzm9g-multiplatform.
>
> Thanks!
>
> Geert Uytterhoeven (6):
> PM / Domains: R-Mobile SYSC: Document SH-Mobile AG5 (sh73a0) binding
> ARM: shmobile: R-Mobile: Consolidate rmobile_pd_suspend_*()
> ARM: shmobile: R-Mobile: Generalize adding/looking up special PM
> domains
> ARM: shmobile: R-Mobile: Special-case PM domains with
> memory-controllers
> ARM: shmobile: sh73a0 dtsi: Add PM domain support
> drivers: sh: Disable PM runtime for multi-platform sh73a0 with genpd
>
> .../bindings/power/renesas,sysc-rmobile.txt| 1 +
> arch/arm/boot/dts/sh73a0.dtsi | 144 ++-
> arch/arm/mach-shmobile/pm-rmobile.c| 155
> +
> drivers/sh/pm_runtime.c| 4 +-
> 4 files changed, 242 insertions(+), 62 deletions(-)
>
> --
> 1.9.1
>
> 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 linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Re: [RFC PATCH v3 3/4] arm64:thunder: Add initial dts for Cavium's Thunder SoC in 2 Node topology.
On Wed, Jan 14, 2015 at 06:48:32PM +, Ganapatrao Kulkarni wrote:
> Hi Lorenzo,
>
> On Wed, Jan 14, 2015 at 11:06 PM, Lorenzo Pieralisi
> wrote:
> > On Wed, Jan 07, 2015 at 08:18:50AM +, Arnd Bergmann wrote:
> >> On Wednesday 07 January 2015 12:37:51 Ganapatrao Kulkarni wrote:
> >> > Hi Arnd,
> >> >
> >> > On Wed, Jan 7, 2015 at 1:32 AM, Arnd Bergmann wrote:
> >> > > On Tuesday 06 January 2015 15:04:26 Ganapatrao Kulkarni wrote:
> >> > >> On Sat, Jan 3, 2015 at 2:47 AM, Arnd Bergmann wrote:
> >> > >> > On Wednesday 31 December 2014 13:03:27 Ganapatrao Kulkarni wrote:
> >> > >> >> + cpu@00f {
> >> > >> >> + device_type = "cpu";
> >> > >> >> + compatible = "cavium,thunder", "arm,armv8";
> >> > >> >> + reg = <0x0 0x00f>;
> >> > >> >> + enable-method = "psci";
> >> > >> >> + arm,associativity = <0 0 0x00f>;
> >> > >> >> + };
> >> > >> >> + cpu@100 {
> >> > >> >> + device_type = "cpu";
> >> > >> >> + compatible = "cavium,thunder", "arm,armv8";
> >> > >> >> + reg = <0x0 0x100>;
> >> > >> >> + enable-method = "psci";
> >> > >> >> + arm,associativity = <0 0 0x100>;
> >> > >> >> + };
> >> > >> >
> >> > >> > What is the 0x100 offset in the last-level topology field? Does
> >> > >> > this have
> >> > >> > no significance to topology at all? I would expect that to be
> >> > >> > something
> >> > >> > like cluster number that is relevant to caching and should be
> >> > >> > represented
> >> > >> > as a separate level.
> >> > >>
> >> > >> i did not understand, can you please explain little more about "
> >> > >> should be represented as a separate level."
> >> > >> at present, i have put the hwid of a cpu.
> >> > >
> >> > > From what I undertand, the hwid of the CPU contains the "cluster"
> >> > > number in
> >> > > this bit position, so you typically have a shared L2 or L3 cache
> >> > > between
> >> > > all cores within a cluster, but separate caches in other clusters.
> >> > >
> >> > > If this is the case, there will be a measurable difference in
> >> > > performance
> >> > > between two processes sharing memory when running on the same cluster,
> >> > > or when running on different clusters on the same socket. If the
> >> > > performance difference is relevant, it should be described as a
> >> > > separate
> >> > > level in the associativity property.
> >> > you mean, the associativity as array of
> >>
> >> No, that would leave out the core number, which is required to identify
> >> the individual thread. I meant adding an extra level such as
> >>
> >>
> >>
> >> A lot of machines will leave out the number because they are
> >> built with SoCs that don't have a long-distance coherency protocol.
> >
> > Can't we use phandles to cpu-map nodes instead of a list of numbers (and
> > yet another topology binding description) ?
> cpu-map describes only a cpu topology.
> infact, i have tried initially(in v1 patch set) to use topology for
> the numa mapping.
> However, for numa, we need to define association of cpu, memory and IOs.
> arm,associativity is a generic node property and can be used in any dt nodes.
I understand that, I was advising to define "arm,associativity" as a
phandle in cpu nodes AND all devices.
Why can't you make it point at a phandle in the cpu-map instead of adding
a t-uple doing the same thing. Am I missing something here ?
cpu-map allows you to describe the system hierarchy and can expand beyond
clusters (several layers of clusterings, above core it is just a way to
define the system hierarchy, leaves node will always be cores or threads).
On a side note, one of the reasons cpu-map was devised for was exactly
that, to allow mappings of resources (ie IRQs but it is valid for caches
and other devices too) to groups of CPUs.
Is there anything that you can't do by using cpu-map phandles to
describe devices associativity ?
We have to add bindings that allow to compute the distance as you
do by using the reference points (I am reading the code to figure
out how it is used), but that's feasible as a binding update.
Lorenzo
--
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/2 v3 RESEND] mtd: fsl_upm: Support NAND ECC DTS properties
From: Jordan Friendshuh
Support the generic nand-ecc-mode, nand-ecc-strength, and
nand-ecc-step-size device-tree properties with the Freescale UPM NAND
driver.
This patch preserves the default software ECC mode while adding the
ability to use BCH ECC for larger NAND devices.
Signed-off-by: Jordan Friendshuh
Signed-off-by: Aaron Sierra
---
v2:
* Now using ECC mode and strength helpers from of_mtd.h
* ECC mode and strength checking is more robust
v3 (resent due to [PATCH 1/2] v2 update):
* Require nand-ecc-step-size for soft_bch.
* Simplify mode/strength/step parameter checking.
.../devicetree/bindings/mtd/fsl-upm-nand.txt | 32 +++
drivers/mtd/nand/Kconfig | 1 +
drivers/mtd/nand/fsl_upm.c | 66 --
3 files changed, 94 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
index fce4894..3643ee1 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
@@ -18,6 +18,9 @@ Optional properties:
- chip-delay : chip dependent delay for transferring data from array to
read registers (tR). Required if property "gpios" is not used
(R/B# pins not connected).
+- nand-ecc-mode : as defined by nand.txt ("soft" and "soft_bch", only).
+- nand-ecc-strength : as defined by nand.txt.
+- nand-ecc-step-size : as defined by nand.txt.
Each flash chip described may optionally contain additional sub-nodes
describing partitions of the address space. See partition.txt for more
@@ -65,3 +68,32 @@ upm@3,0 {
};
};
};
+
+/*
+ * Micron MT29F32G08AFABA (M62B)
+ * 32 Gb (4 GiB), 2 chipselect
+ */
+upm@2,0 {
+ #address-cells = <0>;
+ #size-cells = <0>;
+ compatible = "fsl,upm-nand";
+ reg = <2 0x0 0x8>;
+ fsl,upm-addr-line-cs-offsets = <0x0 0x1>;
+ fsl,upm-addr-offset = <0x10>;
+ fsl,upm-cmd-offset = <0x08>;
+ fsl,upm-wait-flags = <0x1>;
+ chip-delay = <50>;
+
+ nand@0 {
+ #address-cells = <1>;
+ #size-cells = <2>;
+ nand-ecc-mode = "soft_bch";
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partition@0 {
+ label = "NAND filesystem";
+ reg = <0x0 0x1 0x>;
+ };
+ };
+};
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index e5e3343..4c85daf 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -444,6 +444,7 @@ config MTD_NAND_FSL_UPM
tristate "Support for NAND on Freescale UPM"
depends on PPC_83xx || PPC_85xx
select FSL_LBC
+ select MTD_NAND_ECC_BCH
help
Enables support for NAND Flash chips wired onto Freescale PowerPC
processor localbus with User-Programmable Machine support.
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 72755d7..053d8bf 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -160,6 +161,11 @@ static int fun_chip_init(struct fsl_upm_nand *fun,
int ret;
struct device_node *flash_np;
struct mtd_part_parser_data ppdata;
+ int mode, strength, step_size;
+
+ flash_np = of_get_next_child(upm_np, NULL);
+ if (!flash_np)
+ return -ENODEV;
fun->chip.IO_ADDR_R = fun->io_base;
fun->chip.IO_ADDR_W = fun->io_base;
@@ -168,7 +174,61 @@ static int fun_chip_init(struct fsl_upm_nand *fun,
fun->chip.read_byte = fun_read_byte;
fun->chip.read_buf = fun_read_buf;
fun->chip.write_buf = fun_write_buf;
- fun->chip.ecc.mode = NAND_ECC_SOFT;
+
+ /*
+* Support NAND_ECC_SOFT and NAND_ECC_SOFT_BCH, error otherwise.
+*/
+ mode = of_get_nand_ecc_mode(flash_np);
+ strength = of_get_nand_ecc_strength(flash_np);
+ step_size = of_get_nand_ecc_step_size(flash_np);
+ if (mode < 0) {
+ dev_info(fun->dev, "ECC mode defaulting to 'soft'");
+ mode = NAND_ECC_SOFT;
+ } else if (mode != NAND_ECC_SOFT && mode != NAND_ECC_SOFT_BCH) {
+ dev_err(fun->dev, "ECC mode in device tree is unsupported");
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /*
+* In NAND_ECC_SOFT_BCH, require strength >= 1 and step >= 1.
+* In NAND_ECC_SOFT:
+* a. ignore strength (1 implied)
+* b. step < 0, step = 256, or step = 512.
+*/
+ if (mode == NAND_ECC_SOFT_BCH) {
+ if (strength < 1)
+ dev_err(fun->dev, "invalid nand-ecc-strength for BCH");
+
+ if (step_size < 1)
+
Re: [PATCH] ARM: shmobile: R-Mobile: Fix DT refcount bugs in PM domain code
On Wed, Jan 14, 2015 at 11:50:48AM +0100, Geert Uytterhoeven wrote:
> Fix two DT refcount imbalances in the PM domain code that scans the DT
> topology:
>
> 1. Add missing of_node_put() after of_find_compatible_node().
>
> 2. If CONFIG_OF_DYNAMIC=y:
>
> ERROR: Bad of_node_put() on /system-controller@e618
>
>
> of_find_node_by_name() calls of_node_put() on its "from" parameter,
> which must not be done on the for_each_compatible_node() iterator,
> as it causes a zero refcount later.
> Use of_get_child_by_name() instead to fix this.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Fixes: d7a3a10c8391fdcd ("ARM: shmobile: R-Mobile: Add DT support for PM
> domains")
> in Simon's git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> tag renesas-dt-pm-for-v3.20
Thanks.
As the patch above is not in the ARM SoC tree yet I have decided
to squash this patch into it.
> ---
> arch/arm/mach-shmobile/pm-rmobile.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/pm-rmobile.c
> b/arch/arm/mach-shmobile/pm-rmobile.c
> index 07fb4ea4d8e94258..85a7fdd9823bc5a6 100644
> --- a/arch/arm/mach-shmobile/pm-rmobile.c
> +++ b/arch/arm/mach-shmobile/pm-rmobile.c
> @@ -270,8 +270,10 @@ static void __init get_special_pds(void)
>
> /* PM domain containing Coresight-ETM */
> np = of_find_compatible_node(NULL, NULL, "arm,coresight-etm3x");
> - if (np)
> + if (np) {
> debug_pd = of_parse_phandle(np, "power-domains", 0);
> + of_node_put(np);
> + }
> }
>
> static void __init put_special_pds(void)
> @@ -363,7 +365,7 @@ static int __init rmobile_init_pm_domains(void)
> continue;
> }
>
> - pmd = of_find_node_by_name(np, "pm-domains");
> + pmd = of_get_child_by_name(np, "pm-domains");
> if (!pmd) {
> pr_warn("%s lacks pm-domains node\n", np->full_name);
> continue;
> --
> 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
[PATCHv3 2/2] leds: tlc59116: Driver for the TI 16 Channel i2c LED driver
The TLC59116 is an I2C bus controlled 16-channel LED driver. Each LED
output has its own 8-bit fixed-frequency PWM controller to control the
brightness of the LED.
This is based on a driver from Belkin, but has been extensively
rewritten.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile| 1 +
drivers/leds/leds-tlc59116.c | 252 +++
3 files changed, 261 insertions(+)
create mode 100644 drivers/leds/leds-tlc59116.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a6c3d2f153f3..8fc283c01673 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -457,6 +457,14 @@ config LEDS_TCA6507
LED driver chips accessed via the I2C bus.
Driver support brightness control and hardware-assisted blinking.
+config LEDS_TLC59116
+ tristate "LED driver for TLC59116F controllers"
+ depends on LEDS_CLASS && I2C
+ select REGMAP_I2C
+ help
+ This option enables support for Texas Instruments TLC59116F
+ LED controller.
+
config LEDS_MAX8997
tristate "LED support for MAX8997 PMIC"
depends on LEDS_CLASS && MFD_MAX8997
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a191d907..8e7d20acfa7b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_LEDS_LP8501) += leds-lp8501.o
obj-$(CONFIG_LEDS_LP8788) += leds-lp8788.o
obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
obj-$(CONFIG_LEDS_TCA6507) += leds-tca6507.o
+obj-$(CONFIG_LEDS_TLC59116)+= leds-tlc59116.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_IPAQ_MICRO) += leds-ipaq-micro.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
diff --git a/drivers/leds/leds-tlc59116.c b/drivers/leds/leds-tlc59116.c
new file mode 100644
index ..fddad1f45c87
--- /dev/null
+++ b/drivers/leds/leds-tlc59116.c
@@ -0,0 +1,252 @@
+/*
+ * Copyright 2014 Belkin Inc.
+ * Copyright 2014 Andrew Lunn
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TLC59116_LEDS 16
+
+#define TLC59116_REG_MODE1 0x00
+#define MODE1_RESPON_ADDR_MASK 0xF0
+#define MODE1_NORMAL_MODE (0 << 4)
+#define MODE1_SPEED_MODE (1 << 4)
+
+#define TLC59116_REG_MODE2 0x01
+#define MODE2_DIM (0 << 5)
+#define MODE2_BLINK(1 << 5)
+#define MODE2_OCH_STOP (0 << 3)
+#define MODE2_OCH_ACK (1 << 3)
+
+#define TLC59116_REG_PWM(x)(0x02 + (x))
+
+#define TLC59116_REG_GRPPWM0x12
+#define TLC59116_REG_GRPFREQ 0x13
+
+/* LED Driver Output State, determine the source that drives LED outputs */
+#define TLC59116_REG_LEDOUT(x) (0x14 + ((x) >> 2))
+#define TLC59116_LED_OFF 0x0 /* Output LOW */
+#define TLC59116_LED_ON0x1 /* Output HI-Z */
+#define TLC59116_DIM 0x2 /* Dimming */
+#define TLC59116_BLINK 0x3 /* Blinking */
+#define LED_MASK 0x3
+
+#define ldev_to_led(c) container_of(c, struct tlc59116_led, ldev)
+#define work_to_led(work) container_of(work, struct tlc59116_led, work)
+
+struct tlc59116_led {
+ bool active;
+ struct regmap *regmap;
+ unsigned int led_no;
+ struct led_classdev ldev;
+ struct work_struct work;
+};
+
+struct tlc59116_priv {
+ struct tlc59116_led leds[TLC59116_LEDS];
+};
+
+static int
+tlc59116_set_mode(struct regmap *regmap, u8 mode)
+{
+ int err;
+ u8 val;
+
+ if ((mode != MODE2_DIM) && (mode != MODE2_BLINK))
+ mode = MODE2_DIM;
+
+ /* Configure MODE1 register */
+ err = regmap_write(regmap, TLC59116_REG_MODE1, MODE1_NORMAL_MODE);
+ if (err)
+ return err;
+
+ /* Configure MODE2 Reg */
+ val = MODE2_OCH_STOP | mode;
+
+ return regmap_write(regmap, TLC59116_REG_MODE2, val);
+}
+
+static int
+tlc59116_set_led(struct tlc59116_led *led, u8 val)
+{
+ struct regmap *regmap = led->regmap;
+ unsigned int i = (led->led_no % 4) * 2;
+ unsigned int addr = TLC59116_REG_LEDOUT(led->led_no);
+ unsigned int mask = LED_MASK << i;
+
+ val = val << i;
+
+ return regmap_update_bits(regmap, addr, mask, val);
+}
+
+static void
+tlc59116_led_work(struct work_struct *work)
+{
+ struct tlc59116_led *led = work_to_led(work);
+ struct regmap *regmap = led->regmap;
+ int err;
+ u8 pwm;
+
+ pwm = TLC59116_REG_PWM(led->led_no);
+ err = regmap_write(regmap, pwm, led->ldev.brightness);
+ if (err)
+ dev_err(led->ldev.dev, "Failed setting brightn
[PATCHv3 1/2] leds: tlc59116: Document binding for the TI 16 Channel i2c LED driver
Document the binding for the TLC59116 LED driver.
Signed-off-by: Andrew Lunn
Cc: matthew.fathe...@belkin.com
---
.../devicetree/bindings/leds/leds-tlc59116.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-tlc59116.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-tlc59116.txt
b/Documentation/devicetree/bindings/leds/leds-tlc59116.txt
new file mode 100644
index ..45c2123774d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-tlc59116.txt
@@ -0,0 +1,40 @@
+LEDs connected to tcl59116
+
+Required properties
+- compatible: should be "ti,tlc59116"
+- #address-cells: must be 1
+- #size-cells: must be 0
+- reg: typically 0x68
+
+Each led is represented as a sub-node of the ti,,tlc59116.
+See Documentation/devicetree/bindings/leds/common.txt
+
+LED sub-node properties:
+- reg: number of LED line, 0 to 15
+- label: (optional) name of LED
+- linux,default-trigger : (optional)
+
+Examples:
+
+tlc59116@68 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,tlc59116";
+ reg = <0x68>;
+
+ wan@0 {
+ label = "wrt1900ac:amber:wan";
+ reg = <0x0>;
+ };
+
+ 2g@2 {
+ label = "wrt1900ac:white:2g";
+ reg = <0x2>;
+ };
+
+ alive@9 {
+ label = "wrt1900ac:green:alive";
+ reg = <0x9>;
+ linux,default_trigger = "heartbeat";
+ };
+};
--
2.1.4
--
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
[PATCHv3 0/2] Driver for TI tlc59116 16 Channel i2c LED driver
This patchset is a driver for the TI tlc59116 16 Channel i2c LED driver. This driver is used on the Belkin WRT1900AC access point and the C code is derived from code Belkin contributed to OpenWRT. However it has been extensively re-written, and a device tree binding added to replace platform data. Cc: matthew.fathe...@belkin.com Since v2: Remove incorrect /* Mode register ? */ comment Parenthesis around the macro arguments Converted many signed variables into unsigned Saved an initialization Since v1: s/uint8_t/u8/g Remove empty line Removed #gpio-cells Added select REGMAP_I2C Sorted #includes into alphabetic order Added missing MODULE_DEVICE_TABLE(of, ...) Check return value of regmap_write() Simplified tlc59116_set_mode() Andrew Lunn (2): leds: tlc59116: Document binding for the TI 16 Channel i2c LED driver leds: tlc59116: Driver for the TI 16 Channel i2c LED driver .../devicetree/bindings/leds/leds-tlc59116.txt | 41 drivers/leds/Kconfig | 7 + drivers/leds/Makefile | 1 + drivers/leds/leds-tlc59116.c | 253 + 4 files changed, 302 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-tlc59116.txt create mode 100644 drivers/leds/leds-tlc59116.c -- 2.1.3 -- 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 1/5] irqchip: add dumb demultiplexer implementation
Hi Rob, On Wed, 14 Jan 2015 16:24:32 -0600 Rob Herring wrote: > On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner wrote: > > On Tue, 13 Jan 2015, Rob Herring wrote: > >> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon > >> wrote: > >> > 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. > >> > >> This really seems like a work-around for how IRQF_SHARED works. It > > > > It's a workaround for a short coming of IRQF_SHARED. > > > > IRQF_SHARED has a massive short coming versus suspend and wakeup > > interrupts. If one of the demultiplexed interrupts is a valid wakeup > > source then we have no sane way to express this with IRQF_SHARED > > simply because the drivers need to be aware whether they run on stupid > > or well designed hardware. > > Unfortunately, the drivers will still have to know this. They cannot > assume that they can call disable_irq and their device irq state does > not matter. > > Perhaps we need a debug feature such that disable_irq/enable_irq are > nops with IRQF_SHARED? > > >> seems like what is really desired is just per handler disabling. It is > > > > So you want a magic API like disable/enable_irq_action()? > > > > Certainly not. > > Agreed. > > > You'd open just another can of worms which will bring us abuse and > > hard to debug problems because driver writers think it's a good idea > > to use it for random purposes. > > > > Aside of that it would add another conditional into the interrupt > > delivery hotpath which is not desired either. > > > >> fragile in that devices can deadlock the system if the drivers don't > >> disable the interrupt source before calling disable_irq. But unlike > > > > Any misdesigned driver can do that for you. > > > >> IRQF_SHARED, there is nothing explicit in the driver indicating it is > >> designed to work properly with a shared interrupt line. > > > > IRQF_SHARED is a pretty bad indicator. Look at all the drivers which > > slap this flag onto request_irq() and have no single line of code > > which makes sure that the driver would ever work on a shared line. > > > > If it's just for annotational purposes, we can add a new IRQF flag, > > which is required to request such a interrupt line. > > > >> I see no reason to accept this into DT either. We already can support > >> shared lines and modeling an OR gate as an interrupt controller is > >> pointless. > > > > It's absolutely not pointless. > > > > All attempts to work around that have resulted in horrible bandaids so > > far. That's why I guided Boris to implement this dummy demultiplexing > > mechanism. It solves the problem at hand nicely without adding nasty > > hackarounds into the suspend/resume code and inflicting platform > > knowledge on multi-platform device drivers. > > This change will break on old kernels with a new dtb. Would you be > happy if a BIOS update required a new kernel? Fixing this for any > platform requires a dtb update which may not be possible on some > platforms. I don't have a problem with this breakage for 1 platform > and the at91 guys may not care, but we'd ultimately be changing how > all shared irqs are specified for all DT. Maybe we decide that this is > how we want to describe things, but that needs much wider discussion > and agreement. I tried really hard on finding a DT representation that would not break the DT ABI, but didn't find any easy solution. How about keeping all platforms with the shared irq pattern, except for those that really have an irq line shared by a timer and several other devices (not sure yet, but at91 seems to be the only impacted platform so far). > > > If you have a proper solution for the problem at hand which > > > >- avoids the demux dummy > > > >- works straight forward with suspend/resume/wakeup > > > >- does not add horrible new APIs > > > >- does not add conditionals to the interrupt hotpath > > > >- does not inflict platform knowledge about interrupt chip details > > on drivers > > > > then I'm happy to take it. > > > > But as long as you can't come up with anything sane, the demux dummy > > is the best solution for this problem we've seen so far. > > What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a > suspended action list? This would leave only the actions with > IRQF_NO_SUSPEND set in the active action list. The cost would be a > pointer in irq_desc an
Re: [PATCH v2 1/5] irqchip: add dumb demultiplexer implementation
On Wed, Jan 14, 2015 at 4:36 AM, Thomas Gleixner wrote: > On Tue, 13 Jan 2015, Rob Herring wrote: >> On Tue, Jan 13, 2015 at 12:46 PM, Boris Brezillon >> wrote: >> > 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. >> >> This really seems like a work-around for how IRQF_SHARED works. It > > It's a workaround for a short coming of IRQF_SHARED. > > IRQF_SHARED has a massive short coming versus suspend and wakeup > interrupts. If one of the demultiplexed interrupts is a valid wakeup > source then we have no sane way to express this with IRQF_SHARED > simply because the drivers need to be aware whether they run on stupid > or well designed hardware. Unfortunately, the drivers will still have to know this. They cannot assume that they can call disable_irq and their device irq state does not matter. Perhaps we need a debug feature such that disable_irq/enable_irq are nops with IRQF_SHARED? >> seems like what is really desired is just per handler disabling. It is > > So you want a magic API like disable/enable_irq_action()? > > Certainly not. Agreed. > You'd open just another can of worms which will bring us abuse and > hard to debug problems because driver writers think it's a good idea > to use it for random purposes. > > Aside of that it would add another conditional into the interrupt > delivery hotpath which is not desired either. > >> fragile in that devices can deadlock the system if the drivers don't >> disable the interrupt source before calling disable_irq. But unlike > > Any misdesigned driver can do that for you. > >> IRQF_SHARED, there is nothing explicit in the driver indicating it is >> designed to work properly with a shared interrupt line. > > IRQF_SHARED is a pretty bad indicator. Look at all the drivers which > slap this flag onto request_irq() and have no single line of code > which makes sure that the driver would ever work on a shared line. > > If it's just for annotational purposes, we can add a new IRQF flag, > which is required to request such a interrupt line. > >> I see no reason to accept this into DT either. We already can support >> shared lines and modeling an OR gate as an interrupt controller is >> pointless. > > It's absolutely not pointless. > > All attempts to work around that have resulted in horrible bandaids so > far. That's why I guided Boris to implement this dummy demultiplexing > mechanism. It solves the problem at hand nicely without adding nasty > hackarounds into the suspend/resume code and inflicting platform > knowledge on multi-platform device drivers. This change will break on old kernels with a new dtb. Would you be happy if a BIOS update required a new kernel? Fixing this for any platform requires a dtb update which may not be possible on some platforms. I don't have a problem with this breakage for 1 platform and the at91 guys may not care, but we'd ultimately be changing how all shared irqs are specified for all DT. Maybe we decide that this is how we want to describe things, but that needs much wider discussion and agreement. > If you have a proper solution for the problem at hand which > >- avoids the demux dummy > >- works straight forward with suspend/resume/wakeup > >- does not add horrible new APIs > >- does not add conditionals to the interrupt hotpath > >- does not inflict platform knowledge about interrupt chip details > on drivers > > then I'm happy to take it. > > But as long as you can't come up with anything sane, the demux dummy > is the best solution for this problem we've seen so far. What if during suspend you move all actions w/o IRQF_NO_SUSPEND to a suspended action list? This would leave only the actions with IRQF_NO_SUSPEND set in the active action list. The cost would be a pointer in irq_desc and moving the actions during suspend and resume. There are probably ways to do this demux irqchip without a DT change. Since we can't just move Linux irq numbers to different irq_chips during request_irq, we would have to parse the DT up front to find all shared interrupts and create a demux irqchip for them. That wouldn't be very efficient, but is straight-forward. Then we'd have to handle the translation into Linux irq numbers correctly which is probably the more difficult part. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org Mor
[PATCH v4 3/3] ARM: dts: add I2C device nodes for Broadcom Cygnus
Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5126f9e..f7d6c1d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -70,6 +70,26 @@
};
};
+ i2c0: i2c@18008000 {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x18008000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@1800b000 {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x1800b000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
uart0: serial@1802 {
compatible = "snps,dw-apb-uart";
reg = <0x1802 0x100>;
--
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 1/3] i2c: iProc: define Broadcom iProc I2C binding
Document the I2C device tree binding for Broadcom iProc family of
SoCs
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
new file mode 100644
index 000..81f982c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
@@ -0,0 +1,37 @@
+Broadcom iProc I2C controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,iproc-i2c"
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+I2C controller registers
+
+- interrupts:
+Should contain the I2C interrupt
+
+- clock-frequency:
+This is the I2C bus clock. Need to be either 10 or 40
+
+- #address-cells:
+Always 1 (for I2C addresses)
+
+- #size-cells:
+Always 0
+
+Example:
+ i2c0: i2c@18008000 {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x18008000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+
+ codec: wm8750@1a {
+ compatible = "wlf,wm8750";
+ reg = <0x1a>;
+ };
+ };
--
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/3] i2c: iproc: Add Broadcom iProc I2C Driver
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-bcm-iproc.c | 503
3 files changed, 514 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 31e8308..af76d23 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -372,6 +372,16 @@ config I2C_BCM2835
This support is also available as a module. If so, the module
will be called i2c-bcm2835.
+config I2C_BCM_IPROC
+ tristate "Broadcom iProc I2C controller"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
+ help
+ If you say yes to this option, support will be included for the
+ Broadcom iProc I2C controller.
+
+ If you don't know what to do here, say N.
+
config I2C_BCM_KONA
tristate "BCM Kona I2C adapter"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 56388f6..d93b509 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o
+obj-$(CONFIG_I2C_BCM_IPROC)+= i2c-bcm-iproc.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
obj-$(CONFIG_I2C_CADENCE) += i2c-cadence.o
obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
new file mode 100644
index 000..7d9ed4e
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -0,0 +1,503 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 CFG_OFFSET 0x00
+#define CFG_RESET_SHIFT 31
+#define CFG_EN_SHIFT 30
+#define CFG_M_RETRY_CNT_SHIFT16
+#define CFG_M_RETRY_CNT_MASK 0x0f
+
+#define TIM_CFG_OFFSET 0x04
+#define TIME_CFG_MODE_400_SHIFT 31
+
+#define M_FIFO_CTRL_OFFSET 0x0c
+#define M_FIFO_RX_FLUSH_SHIFT31
+#define M_FIFO_TX_FLUSH_SHIFT30
+#define M_FIFO_RX_CNT_SHIFT 16
+#define M_FIFO_RX_CNT_MASK 0x7f
+#define M_FIFO_RX_THLD_SHIFT 8
+#define M_FIFO_RX_THLD_MASK 0x3f
+
+#define M_CMD_OFFSET 0x30
+#define M_CMD_START_BUSY_SHIFT 31
+#define M_CMD_STATUS_SHIFT 25
+#define M_CMD_STATUS_MASK0x07
+#define M_CMD_STATUS_SUCCESS 0x0
+#define M_CMD_STATUS_LOST_ARB0x1
+#define M_CMD_STATUS_NACK_ADDR 0x2
+#define M_CMD_STATUS_NACK_DATA 0x3
+#define M_CMD_STATUS_TIMEOUT 0x4
+#define M_CMD_PROTOCOL_SHIFT 9
+#define M_CMD_PROTOCOL_MASK 0xf
+#define M_CMD_PROTOCOL_BLK_WR0x7
+#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PEC_SHIFT 8
+#define M_CMD_RD_CNT_SHIFT 0
+#define M_CMD_RD_CNT_MASK0xff
+
+#define IE_OFFSET0x38
+#define IE_M_RX_FIFO_FULL_SHIFT 31
+#define IE_M_RX_THLD_SHIFT 30
+#define IE_M_START_BUSY_SHIFT28
+
+#define IS_OFFSET0x3c
+#define IS_M_RX_FIFO_FULL_SHIFT 31
+#define IS_M_RX_THLD_SHIFT 30
+#define IS_M_START_BUSY_SHIFT28
+
+#define M_TX_OFFSET 0x40
+#define M_TX_WR_STATUS_SHIFT 31
+#define M_TX_DATA_SHIFT 0
+#define M_TX_DATA_MASK 0xff
+
+#define M_RX_OFFSET 0x44
+#define M_RX_STATUS_SHIFT30
+#define M_RX_STATUS_MASK 0x03
+#define M_RX_PEC_ERR_SHIFT 29
+#define M_RX_DATA_SHIFT 0
+#define M_RX_DATA_MASK 0xff
+
+#define I2C_TIMEOUT_MESC 100
+#define M_TX_RX_FIFO_SIZE64
+
+enum bus_speed_index {
+ I2C_SPD_100K = 0,
+ I2C_SPD_400K,
+};
+
+struct bcm_iproc_i2c_dev {
+
[PATCH v4 0/3] Add I2C support to Broadcom iProc
This patchset contains the initial I2C support for Broadcom iProc family of SoCs. The iProc I2C controller has separate internal TX and RX FIFOs, each has a size of 64 bytes. The iProc I2C controller supports two bus speeds including standard mode (100 kHz) and fast mode (400 kHz) Changes from v3: - Add config dependency to COMPILE_TEST to allow the driver to be build tested by other platforms - Improve CPU utilization efficiency in the loop of waiting for bus to idle - Add more comment in the driver to clarify the way how the "start busy" interrupt is triggered from the I2C controller - Fix inconsistent coding style and format - Improve the bus speed validation logic in the driver - Add code to free the interrupt line in driver's remove function. Also change to use non-devm API to request the interrupt line - Other miscellaneous improvements and fixes Changes from v2: - Have the I2C driver default to y so it does not need to be selected from ARCH_BCM_IPROC. This also helps to get rid of one patch. The driver still depends on ARCH_BCM_IPROC - Get rid of redundant check on resource returned by platform_get_resource Changes from v1: - Fix function argument parenthesis - Get rid of redundant driver owner field Ray Jui (3): i2c: iProc: define Broadcom iProc I2C binding i2c: iproc: Add Broadcom iProc I2C Driver ARM: dts: add I2C device nodes for Broadcom Cygnus .../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37 ++ arch/arm/boot/dts/bcm-cygnus.dtsi | 20 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-bcm-iproc.c | 503 5 files changed, 571 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt create mode 100644 drivers/i2c/busses/i2c-bcm-iproc.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
Re: [RFC PATCH 0/2] clk: rockchip: leave npll for DCLK_VOP0(HDMI) only
Quoting Heiko Stübner (2015-01-08 14:30:01) > Hi Kever, > > Am Montag, 17. November 2014, 22:55:36 schrieb Kever Yang: > > To support all kinds of frequency requirement for HDMI on rk3288, > > we need a PLL that can change rate at run time. > > > > There are some discussion before at [0], I think we can just leave > > the npll for HDMI(DCLK_VOP0) used to make it simple. > > > > Comments are welcome. > > I think I said it in private somewhere already, but just so it's also > available publically: > > I don't think customizing/limiting the clock usage like this will fly, > especially as this would require each and every rk3288 board to use vop0 for > hdmi and vop1 for other stuff. > > With the new rk3288 Firefly devboard this concern already becomes reality. > There a vga converter is connected to VOP0, which leaves only vop1 for hdmi > if > one wants to support the vga connection. > > > From our discussion about this problem I remember that the missing clock > frequencies only affected more esotheric screen resolutions, so personally > I'm > not this much concerned an would like to wait till we find a better solution > to > the problem. Ack. We shouldn't have to limit the possible hardware configurations in software just to keep things simple. This points to a deficiency in the clock framework. This is a common concern: how to change a clock frequency for one user without exploding all of the other users. Do you think Tomeu's constraints API[0] might be a step in the right direction for you? [0] http://lkml.kernel.org/r/<1421071809-17402-3-git-send-email-tomeu.viz...@collabora.com> Regards, Mike > > > Heiko -- 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] dm9000: Add regulator and reset support to dm9000
From: Zubair Lutfullah Kakakhel
Date: Wed, 14 Jan 2015 10:36:17 +
> + power = devm_regulator_get(dev, "vcc");
> + if (PTR_ERR(power) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + if (IS_ERR(power)) {
> + dev_dbg(dev, "no regulator provided\n");
I know it may seem silly, but to me it is more logical to always
guard PTR_ERR() uses with IS_ERR().
Therefore could you please restructure this as:
if (IS_ERR(power)) {
if (PTR_ERR(power) == -EPROBE_DEFER)
return -EPROBE_DEFER;
else
dev_dbg(dev, "no regulator provided\n");
} else {
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: at91: allow disabled gpio controllers
On 17:49 Fri 28 Nov , Ludovic Desroches wrote:
> This patch allows to have gpio controller with status set to disabled.
>
> gpio_banks represents all the gpio banks available on the device whereas
> nbanks represents the gpio banks used. Having a disabled gpio controller
> involves that nbanks value is lower than gpio_banks and that some
> pointers in the gpio_chips array are NULL. This patch deals with these
> specific cases.
>
> Signed-off-by: Ludovic Desroches
> ---
>
> Hi,
>
> Without this patch, pinctrl is broken on sama5d4 because pinctrl-at91 doesn't
> support unused gpio bank.
the problem is different
The current code does support this partially
but need to have few by using gpio_banks for the pinctrl part instead of
info->banks
as we already known the last enabled bank
>
>
> drivers/pinctrl/pinctrl-at91.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index 94643bb..95ae122 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -981,7 +981,8 @@ static void at91_pinctrl_child_count(struct at91_pinctrl
> *info,
>
> for_each_child_of_node(np, child) {
> if (of_device_is_compatible(child, gpio_compat)) {
> - info->nbanks++;
> + if (of_device_is_available(child))
> + info->nbanks++;
> } else {
> info->nfunctions++;
> info->ngroups += of_get_child_count(child);
> @@ -1003,11 +1004,11 @@ static int at91_pinctrl_mux_mask(struct at91_pinctrl
> *info,
> }
>
> size /= sizeof(*list);
> - if (!size || size % info->nbanks) {
> + if (!size || size % gpio_banks) {
> dev_err(info->dev, "wrong mux mask array should be by %d\n",
> info->nbanks);
> return -EINVAL;
> }
> - info->nmux = size / info->nbanks;
> + info->nmux = size / gpio_banks;
>
> info->mux_mask = devm_kzalloc(info->dev, sizeof(u32) * size,
> GFP_KERNEL);
> if (!info->mux_mask) {
> @@ -1185,7 +1186,7 @@ static int at91_pinctrl_probe(struct platform_device
> *pdev)
> {
> struct at91_pinctrl *info;
> struct pinctrl_pin_desc *pdesc;
> - int ret, i, j, k;
> + int ret, i, j, k, ngpio_chips_enabled = 0;
>
> info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> if (!info)
> @@ -1200,12 +1201,14 @@ static int at91_pinctrl_probe(struct platform_device
> *pdev)
>* to obtain references to the struct gpio_chip * for them, and we
>* need this to proceed.
>*/
> - for (i = 0; i < info->nbanks; i++) {
> - if (!gpio_chips[i]) {
> - dev_warn(&pdev->dev, "GPIO chip %d not registered
> yet\n", i);
> - devm_kfree(&pdev->dev, info);
> - return -EPROBE_DEFER;
> - }
> + for (i = 0; i < gpio_banks; i++) {
> + if (gpio_chips[i])
> + ngpio_chips_enabled++;
> + }
> + if (ngpio_chips_enabled < info->nbanks) {
> + dev_warn(&pdev->dev, "All GPIO chips are not registered yet\n");
> + devm_kfree(&pdev->dev, info);
> + return -EPROBE_DEFER;
> }
>
> at91_pinctrl_desc.name = dev_name(&pdev->dev);
> @@ -1234,8 +1237,9 @@ static int at91_pinctrl_probe(struct platform_device
> *pdev)
> }
>
> /* We will handle a range of GPIO pins */
> - for (i = 0; i < info->nbanks; i++)
> - pinctrl_add_gpio_range(info->pctl, &gpio_chips[i]->range);
> + for (i = 0; i < gpio_banks; i++)
> + if (gpio_chips[i])
> + pinctrl_add_gpio_range(info->pctl,
> &gpio_chips[i]->range);
>
> dev_info(&pdev->dev, "initialized AT91 pinctrl driver\n");
>
> @@ -1681,6 +1685,8 @@ static void at91_gpio_probe_fixup(void)
>
> for (i = 0; i < gpio_banks; i++) {
> at91_gpio = gpio_chips[i];
> + if (!at91_gpio)
> + continue;
here Nack
as if you disable ANY of the bank that use pioc you break the IRQ support
attached a patch we the idea how to handle the current issue
only compiled not tested (too late here)
Best Regards,
J.
>
> /*
>* GPIO controller are grouped on some SoC:
> --
> 2.0.3
>
>From c94cb27d4d4feb2d3af8d7eeffa34f8ea9484db7 Mon Sep 17 00:00:00 2001
From: Jean-Christophe PLAGNIOL-VILLARD
Date: Thu, 15 Jan 2015 04:00:46 +0800
Subject: [PATCH 1/1] pinctrl: at91: allow to have disable gpio bank
Today we expect that all the bank are enabled, and count the number of banks
used by the pinctrl based on it instead of using the last bank id enabled.
So switch to it
And set the chained IRQ at runtime based on enabled banks
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
drivers/pinctrl/pinctrl-at91.c | 94 +
[PATCH] ARM: dts: OMAP: Add hwlock-base-id property to hwspinlock nodes
Add the generic property "hwlock-base-id" to the hwspinlock DT nodes on all applicable OMAP SoCS (OMAP4, OMAP5, DRA7, AM33xx and AM43xx). This common property is required by the hwspinlock core to be able to translate client locks properly. All the current OMAP SoCs only have a single instance of the IP, and so will use a common value of 0. Cc: Ohad Ben-Cohen Signed-off-by: Suman Anna --- This is required for the OMAP Hwspinlock driver with the latest DT series, http://marc.info/?l=linux-omap&m=142126914027417&w=2 arch/arm/boot/dts/am33xx.dtsi | 1 + arch/arm/boot/dts/am4372.dtsi | 1 + arch/arm/boot/dts/dra7.dtsi | 1 + arch/arm/boot/dts/omap4.dtsi | 1 + arch/arm/boot/dts/omap5.dtsi | 1 + 5 files changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index acd37057bca9..9ee1f44f0f4b 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -334,6 +334,7 @@ compatible = "ti,omap4-hwspinlock"; reg = <0x480ca000 0x1000>; ti,hwmods = "spinlock"; + hwlock-base-id = <0>; #hwlock-cells = <1>; }; diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index b62a1cd776cd..98eebedb1430 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -371,6 +371,7 @@ compatible = "ti,omap4-hwspinlock"; reg = <0x480ca000 0x1000>; ti,hwmods = "spinlock"; + hwlock-base-id = <0>; #hwlock-cells = <1>; }; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 22771bc1643a..cf7ebdc95b4a 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -752,6 +752,7 @@ compatible = "ti,omap4-hwspinlock"; reg = <0x4a0f6000 0x1000>; ti,hwmods = "spinlock"; + hwlock-base-id = <0>; #hwlock-cells = <1>; }; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 074147cebae4..77197e5454e8 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -344,6 +344,7 @@ compatible = "ti,omap4-hwspinlock"; reg = <0x4a0f6000 0x1000>; ti,hwmods = "spinlock"; + hwlock-base-id = <0>; #hwlock-cells = <1>; }; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index b321fdf42c9f..c2fc81724308 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -393,6 +393,7 @@ compatible = "ti,omap4-hwspinlock"; reg = <0x4a0f6000 0x1000>; ti,hwmods = "spinlock"; + hwlock-base-id = <0>; #hwlock-cells = <1>; }; -- 2.2.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 v7 0/4] hwspinlock core & omap dt support
Hi Ohad, This is an updated version of the hwspinlock dt support series, rebased onto v3.19-rc3 and mainly addresses the continued discussion on the need to maintain a list of registered spinlock banks [1]. I have removed this patch as per your wish, and as a result the burden of the spinlock validation and deferred probing is pushed onto the hwspinlock clients. Sorry for the delay in refreshing this series, hopefully this can be the last revision. Following are the main changes in v7 w.r.t v6: - Dropped the patch "hwspinlock/core: maintain a list of registered hwspinlock banks" - Updated generic hwspinlock bindings to make hwlock-base-id property mandatory. - Updated the OMAP hwspinlock binding and DT support patches to correct for the mandatory hwlock-base-id property. - Updated the common OF helpers patch to move the of_hwspin_lock_get_base_id() and of_hwspin_lock_get_num_locks() functions into the internal header, these are no longer exported, but available for platform implementations. of_hwspin_lock_get_id() is also simplified now. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://slexy.org/view/s21Mh1SqP8 OMAP5 - http://slexy.org/view/s21TYWxoKu DRA74x - http://slexy.org/view/s2dQdghLPr DRA72x - http://slexy.org/view/s2QajhhWYu AM33xx - http://slexy.org/view/s21DvKQOpa AM43xx - http://slexy.org/view/s21L3YB95Q The above logs are generated with some additional test patches staged here for reference, https://github.com/sumananna/omap-kernel/commits/hwspinlock/test/3.19-rc3-dt-v7 The test branch also includes a required patch that adds the hwlock-base-id to all the OMAP hwspinlock DT nodes (will submit that patch separately for Tony to pick it up). Bjorn, I didn't add your Tested-by: or Reviewed-by as I have modified the series a bit. Care to give those once again, thanks. regards Suman [1] https://patchwork.kernel.org/patch/4898041/ --- v6: http://marc.info/?l=linux-omap&m=141055365213895&w=2 - of_hwspin_lock_request_specific() is replaced with of_hwspin_lock_get_id(). of_hwspin_lock_simple_xlate() is made internal, and of_hwspin_lock_get_base_id() is added. - Updated the OMAP hwspinlock DT support patch to assign base-id from DT if present - RFC patches adding the concept of reserved locks and return code change convention dropped. v5: http://marc.info/?l=linux-omap&m=139890478402807&w=2 - Rebased v4 patches plus additional RFC patches. - Added back the patch to support DT-based hwlock-base-id property, for registration purposes. - RFC patches introducing the concept of reserved locks. - Staged patches for converting return convention to better support deferred probing of client drivers. v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells - Fixed a registration issue with repeated module installation and removal. - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions. The OMAP adaptation patch is updated to use the default translate function - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. - Added build support for AM335x, AM43xx and DRA7xx http://marc.info/?l=linux-omap&m=138965904015225&w=2 v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omap&m=138143992932197&w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omap&m=137944644112727&w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omap&m=137823082308009&w=2 --- Suman Anna (4): Documentation: dt: add common bindings for hwspinlock Documentation: dt: add the omap hwspinlock bindings document hwspinlock/core: add common OF helpers hwspinlock/omap: add support for dt nodes .../devicetree/bindings/hwlock/hwlock.txt | 55 ++ .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++ Documentation/hwspinlock.txt | 25 + MAINTAINERS| 1 - arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/hwspinlock.c | 60 drivers/hwspinlock/hwspinlock_core.c | 65 ++ drivers/hwspinlock/hwspinlock_internal.h | 47 driv
[PATCH v7 4/4] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren
---
v7: hwlock-base-id is no longer optional, probe will fail now
if property is absent.
MAINTAINERS | 1 -
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
drivers/hwspinlock/omap_hwspinlock.c | 22 ++---
4 files changed, 17 insertions(+), 69 deletions(-)
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8d32b3..3de03037e90a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6861,7 +6861,6 @@ M:Ohad Ben-Cohen
L: linux-o...@vger.kernel.org
S: Maintained
F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
OMAP MMC SUPPORT
M: Jarkko Lavinen
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d27dfdef66b..6fa36846d5b4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -282,9 +282,6 @@ obj-y += $(nand-m)
$(nand-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175acaeaa2..
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que
- * Hari Kanigeri
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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 "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = "spinlock";
- const char *dev_name = "omap_hwspinlock";
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err("Can't build omap_device for %s:%s\n", dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 47a275c6ece1..18edb3b4ab32 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2015 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que
* Hari Kanigeri
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include "hwspinlock_internal.h"
@@ -80,16 +81,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
+ struct device_node *node = pdev->dev.of_node;
struct hwspinlock_device *bank;
struct hwspinlock *hwlock;
struct resource *res;
void __iomem *io_base;
- int num_locks, i, ret;
+ int num_locks, i, ret, base_id;
- if (!pdata)
+ if (!node)
return -ENODEV;
+ base_id =
[PATCH v7 3/4] hwspinlock/core: add common OF helpers
This patch adds two new OF helper functions for platform
implementations and one new API to use/request locks from a
hwspinlock device instantiated through a device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common OF helper
function to read the 'hwlock-num-locks' property.
2. The of_hwspin_lock_get_base_id() is a common OF helper
function to read the 'hwlock-base-id' property.
3. The of_hwspin_lock_get_id() API can be used by hwspinlock
clients to get the id for a specific lock using the phandle
+ args specifier, so that it can be requested using the
available hwspin_lock_request_specific() API.
Signed-off-by: Suman Anna
---
v7:
- Moved of_hwspin_lock_get_base_id() and of_hwspin_lock_get_num_locks
into hwspinlock_internal.h
- Simplified of_hwspin_lock_get_id(), removed deferred probing and
args specifier validation
- updated comments and documentation
Documentation/hwspinlock.txt | 25
drivers/hwspinlock/hwspinlock_core.c | 65
drivers/hwspinlock/hwspinlock_internal.h | 47 +++
include/linux/hwspinlock.h | 7
4 files changed, 144 insertions(+)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4ea6e26..a29bb47e4637 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,16 @@ independent, drivers.
ids for predefined purposes.
Should be called from a process context (might sleep).
+ int of_hwspin_lock_get_id(struct device_node *np, int index);
+ - retrieve the global lock id for an OF phandle-based specific lock.
+ This function provides a means for DT users of a hwspinlock module
+ to get the global lock id of a specific hwspinlock, so that it can
+ be requested using the normal hwspin_lock_request_specific() API.
+ The function returns a lock id number on success, or other error
+ values. The function does not perform any validation of the args
+ specifier lock values, this burden is placed on the user.
+ Should be called from a process context (might sleep).
+
int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +253,21 @@ int hwspinlock_example2(void)
Returns the address of hwspinlock on success, or NULL on error (e.g.
if the hwspinlock is still in use).
+ int of_hwspin_lock_get_num_locks(struct device_node *dn);
+ - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the number of locks supported within a hwspinlock
+ bank as a device tree node property. This function should be called by
+ needed implementations before registering a hwspinlock device with the
+ hwspinlock core.
+
+ int of_hwspin_lock_get_base_id(struct device_node *dn);
+ - is a common OF helper function that can be used by the underlying
+ vendor-specific implementations. This function should be called by
+ implementations to retrieve the base index for a block of locks present
+ within a hwspinlock device for registering that device with the
+ hwspinlock core.
+
5. Important structs
struct hwspinlock_device is a device which usually contains a bank
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d739d75..8f107bc34281 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "hwspinlock_internal.h"
@@ -257,6 +258,70 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock);
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a relative index of the lock within a specified bank on success,
+ * or -EINVAL on invalid specifier cell count.
+ */
+static inline int
+of_hwspin_lock_simple_xlate(const struct of_phandle_args *hwlock_spec)
+{
+ if (WARN_ON(hwlock_spec->args_count != 1))
+ return -EINVAL;
+
+ return hwlock_spec->args[0];
+}
+
+/**
+ * of_hwspin_lock_get_id() - get lock id for an OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @index: index of the hwlock in the list of values
+ *
+ * This function provides a means for DT users of the hwspinlock module to
+ * get the global lock id of a specific hwspinlock using the phandle of the
+ * hwspinlock device, so that it can be requested using
[PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. This base id
needs to be unique across multiple IP instances of a hwspinlock
device, so that each hwlock can be represented uniquely in a
system.
The number of locks is represented by 'hwlock-num-locks' property,
and the base id is represented by the 'hwlock-base-id' property.
The args specifier length is dependent on each vendor-specific
implementation and is represented through the '#hwlock-cells'
property. Client users need to use the property 'hwlocks' for
requesting specific lock(s).
Note that the document is named hwlock.txt deliberately to keep
it a bit more generic.
Cc: Rob Herring
Signed-off-by: Suman Anna
---
v7: Revised binding info for hwlock-base-id, it is mandatory now
.../devicetree/bindings/hwlock/hwlock.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index ..8de7aaf878f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,55 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if an optional property is used. Please also look through the individual
+platform specific hwlock binding documentations for identifying the applicable
+properties.
+
+Common properties:
+- #hwlock-cells: Specifies the number of cells needed to represent a
+ specific lock. This property is mandatory for all
+ platform implementations.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
+- hwlock-base-id: An unique base Id for the locks for a particular hwlock
+ device. This property is mandatory for all platform
+ implementations.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using the property
+"hwlocks", each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = <&hwlock1 2>;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+ node {
+ ...
+ hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
+ ...
+ };
--
2.2.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 v7 2/4] Documentation: dt: add the omap hwspinlock bindings document
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring
Signed-off-by: Suman Anna
---
v7: Added information about hwlock-base-id and updated example to use it
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index ..935173ec6b58
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,28 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be "ti,omap4-hwspinlock" for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+- hwlock-base-id: Should be 0 for the first IP block instance, or a proper
+ positive value for any subsequent instance (if present)
+ of the IP block.
+- #hwlock-cells: Should be 1. The OMAP hwspinlock users will use a
+ 0-indexed relative hwlock number as the argument
+ specifier value for requesting a specific hwspinlock
+ within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = "ti,omap4-hwspinlock";
+ reg = <0x4a0f6000 0x1000>;
+ ti,hwmods = "spinlock";
+ hwlock-base-id = <0>;
+ #hwlock-cells = <1>;
+};
--
2.2.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 v2 2/5] drivers/rtc/rtc-armada38x: Add a new RTC driver for recent mvebu SoCs
Hi Gregory,
Gregory CLEMENT writes:
> The new mvebu SoCs come with a new RTC driver. This patch adds the
> support for this new IP which is currently found in the Armada 38x
> SoCs.
>
> This RTC provides two alarms, but only the first one is used in the
> driver. The RTC also allows using periodic interrupts.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/rtc/Kconfig | 10 ++
> drivers/rtc/Makefile| 1 +
> drivers/rtc/rtc-armada38x.c | 319
>
> 3 files changed, 330 insertions(+)
> create mode 100644 drivers/rtc/rtc-armada38x.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index f15cddfeb897..de42ebd4b626 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1269,6 +1269,16 @@ config RTC_DRV_MV
> This driver can also be built as a module. If so, the module
> will be called rtc-mv.
>
> +config RTC_DRV_ARMADA38X
> + tristate "Armada 38x Marvell SoC RTC"
> + depends on ARCH_MVEBU
> + help
> + If you say yes here you will get support for the in-chip RTC
> + that can be found in the Armada 38x Marvell's SoC device
> +
> + This driver can also be built as a module. If so, the module
> + will be called armada38x-rtc.
> +
> config RTC_DRV_PS3
> tristate "PS3 RTC"
> depends on PPC_PS3
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index c8ef3e1e6ccd..03fe5629c464 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_RTC_DRV_88PM860X) += rtc-88pm860x.o
> obj-$(CONFIG_RTC_DRV_88PM80X)+= rtc-88pm80x.o
> obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
> obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
> +obj-$(CONFIG_RTC_DRV_ARMADA38X) += rtc-armada38x.o
> obj-$(CONFIG_RTC_DRV_AS3722) += rtc-as3722.o
> obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
> obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
> diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
> new file mode 100644
> index ..30bae27e828c
> --- /dev/null
> +++ b/drivers/rtc/rtc-armada38x.c
> @@ -0,0 +1,319 @@
> +/*
> + * RTC driver for the Armada 38x Marvell SoCs
> + *
> + * Copyright (C) 2015 Marvell
> + *
> + * Gregory Clement
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define RTC_STATUS 0x0
> +#define RTC_STATUS_ALARM1BIT(0)
> +#define RTC_STATUS_ALARM2BIT(1)
> +#define RTC_IRQ1_CONF0x4
> +#define RTC_IRQ1_AL_EN BIT(0)
> +#define RTC_IRQ1_FREQ_EN BIT(1)
> +#define RTC_IRQ1_FREQ_1HZBIT(2)
> +#define RTC_TIME 0xC
> +#define RTC_ALARM1 0x10
> +
> +#define SOC_RTC_INTERRUPT 0x8
> +#define SOC_RTC_ALARM1 BIT(0)
> +#define SOC_RTC_ALARM2 BIT(1)
> +#define SOC_RTC_ALARM1_MASK BIT(2)
> +#define SOC_RTC_ALARM2_MASK BIT(3)
> +
> +struct armada38x_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem*regs;
> + void __iomem*regs_soc;
> + spinlock_t lock;
> + int irq;
> +};
> +
> +/*
> + * According to the datasheet, we need to wait for 5us only between
> + * two consecutive writes
> + */
> +static void rtc_delayed_write(u32 val, struct armada38x_rtc *rtc, int offset)
> +{
> + writel(val, rtc->regs + offset);
> + udelay(5);
> +}
The thing I do not get is how you can guarantee that an undelayed
writel() in a function will not be followed less than 5µs later by
another writel() in another function. For instance:
1) a call to set_alarm() followed by a call to alarm_irq_enable().
2) some writel() or even rtc_udelayed_write() w/ sth asynchronous
occuring like your interrupt handler just after that.
I guess it may be possible to make assumptions on the fact that the
amount of code before a writel() or rtc_udelayed_write() may prevent
such scenario but it's difficult to tell, all the more w/ a spinlock
before the writel() in irq_enable().
Considering the description of the bug, why not doing the following:
1) implement rtc_delayed_write() a bit differently:
static inline void rtc_delayed_write(u32 val, struct armada38x_rtc *rtc,
int offset)
{
udelay(5);
writel(val, rtc->regs + offset);
}
2) remove all writel() in the driver and use rtc_delayed_write()
everywhere.
All writes being under the protection of your spinlock, this will
guarantee the 5µs delay in all cases.
> +static int armada38x_rtc_read_time(struct device *dev, struct rtc_time *tm)
> +{
> + struct armada38x_rtc *rtc = dev_get_drvdata(dev);
> + unsigned long time, time_check,
Re: [PATCHv2 2/2] spi: orion: Add multiple chip select support to spi-orion
On Mon, Jan 12, 2015 at 01:14:00PM +1000, Ken Wilson wrote: > +- num-cs : The total number of chip selects used by this platform. > + If unset, this defaults to 1. So, this is intended to be the number of hardware chip selects that can be configured but the first commit mentioned GPIOs as an option too so we should at least say that this is specifically the controller supported ones. However... > +#define ORION_SPI_CS_MASK0x1C > +#define ORION_SPI_CS_SHIFT 2 > +#define ORION_SPI_CS(cs) ((cs << ORION_SPI_CS_SHIFT) & \ > + ORION_SPI_CS_MASK) ...given that we have a fixed bitfield here which we know and doesn't appear to depend on configuration do we even need this to be configurable - given that we're going to need an explicit node for any slave can't we just accept any sane chip select for a slave without extending the binding? signature.asc Description: Digital signature
Re: [PATCH v3 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 1/13/2015 11:51 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
>>> irq == 0 should be handled as error, too.
>>>
>> Ah. I thought zero is a valid global interrupt number, and I see other
>> drivers checking against < 0 as well. Is my understanding incorrect?
> These are wrong, too. 0 should never be a valid interrupt number. There
> are some exceptions but mostly for historic reasons. The right handling
> is used for example in drivers/i2c/busses/i2c-efm32.c.
>
Okay. Will check against <= 0. Thanks.
+ dev_err(dev->device, "no irq resource\n");
+ return irq;
+ }
>> [...]
+static int bcm_iproc_i2c_remove(struct platform_device *pdev)
+{
+ struct bcm_iproc_i2c_dev *dev = platform_get_drvdata(pdev);
+
+ i2c_del_adapter(&dev->adapter);
+ bcm_iproc_i2c_disable(dev);
>>> I think you have a problem here if bcm_iproc_i2c_remove is called while
>>> an irq is still being serviced. I'm not sure how to prevent this
>>> properly for a shared interrupt.
>>>
>> Can I grab i2c_lock_adapter to ensure the bus is locked (so there's no
>> outstanding transactions or IRQs by the time we remove the adapter)? But
>> I see no I2C bus driver does this in their remove function...
> The problem I pointed out is the reason for some driver authors not to
> use devm_request_irq. If you use plain request_irq and the matching
> free_irq in the .remove callback you can be sure that the irq isn't
> running any more as soon as free_irq returns.
>
Okay. Will change to use request_irq and make sure that it's freed in
the remove function. Also, the interrupt is dedicated to the I2C
controller, so I'll remove the IRQF_SHARED flag.
> BTW, if you use vim, you can add
>
> set cinoptions=(,:
> if has("autocmd")
> filetype plugin indent on
> endif
>
> to your .vimrc. Then while typing vim does the indention right and
> consistent, and with the = command you can reindent.
>
Wow this is excellent! Just tried and it works perfectly. Thanks a lot!!!
> Best regards
> Uwe
>
--
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 1/3] ARM: dts: sun4i: Add dts file for Chuwi V7 CW0825 tablet
On Tue, Jan 13, 2015 at 11:44:30AM +0100, Hans de Goede wrote:
> The Chuwi V7 is an A10 (sun4i) based tablet with 1G of RAM, 16G of nand flash,
> microsd slot, 7" 1024x768 lvds ips panel, mini hdmi out, headphones out,
> stereo speakers, front & back camera and usb wifi.
>
> It is clearly marked "CHUWI", "V7" and "Model: CW0825" on the back of the
> tablet.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> - Use cpp style includes
> - Use GPIO header for the GPIO flags
> - Address nodes by reference rather then by their full dt path
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 99
> +
> 2 files changed, 100 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a86f232..548520f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -445,6 +445,7 @@ dtb-$(CONFIG_ARCH_STI)+= stih407-b2120.dtb \
> dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-a1000.dtb \
> sun4i-a10-ba10-tvbox.dtb \
> + sun4i-a10-chuwi-v7-cw0825.dtb \
> sun4i-a10-cubieboard.dtb \
> sun4i-a10-mini-xplus.dtb \
> sun4i-a10-hackberry.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> new file mode 100644
> index 000..0654d30
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> @@ -0,0 +1,99 @@
> +/*
> + * 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"
> +
> +/ {
> + model = "Chuwi V7 CW0825";
> + compatible = "chuwi,v7-cw0825", "allwinner,sun4i-a10";
> +};
> +
> +&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";
> +};
MMC0 base address: 01c0f000
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> +};
UART0 base address: 0x01c28000
> +&usbphy {
> + usb2_vbus-supply = <®_usb2_vbus>;
> + status = "okay";
> +};
USB PHY base address: 01c13400
See what I meant?
I'm not blaming anyone, it's just a fact. If you made that mistake, as
experienced as you are, we can expect from all the newcomers to do it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH V3 13/15] ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update
On Wed, Jan 14, 2015 at 07:42:40PM +0100, Sylwester Nawrocki wrote: > Clock related properties are added to the Exynos4 I2S device nodes > so they can be referred to as clock providers. Missing i2s_opclk1 > clock is added to the I2S0 node and clock properties are added > to the MAX98090 codec node to allow it to control/read frequency > of the MCLK clock directly. Sorry, I should've said - I applied the ASoC patches, not these. signature.asc Description: Digital signature
Re: [PATCH V3 00/15] ASoC: samsung: Add clk provider for I2S internal clocks
On Wed, Jan 14, 2015 at 07:42:27PM +0100, 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. The upside is we can switch > Odroid X2/U3 to the simple-card, once the CDCLK clock is taken care of by > the clk core and DT. Applied all, thanks. signature.asc Description: Digital signature
Re: [PATCH v2 2/5] irqchip: Add DT binding doc for dumb demuxer chips
On Wed, Jan 14, 2015 at 08:08:09PM +0100, Boris Brezillon wrote: > Hi Jason, > > On Wed, 14 Jan 2015 13:56:19 -0500 > Jason Cooper wrote: > > > Hey Boris, > > > > On Tue, Jan 13, 2015 at 09:52:07PM +0100, Boris Brezillon wrote: > > > On Tue, 13 Jan 2015 14:00:50 -0500 Jason Cooper > > > wrote: > > > > On Tue, Jan 13, 2015 at 07:46:18PM +0100, Boris Brezillon wrote: > > > > > Add documentation for the dumb demuxer. > > > > > > > > > > Signed-off-by: Boris Brezillon > > > > > --- > > > > > .../bindings/interrupt-controller/dumb-demux.txt | 34 > > > > > ++ > > > > > 1 file changed, 34 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..1c777ef > > > > > --- /dev/null > > > > > +++ > > > > > b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt > > > > > @@ -0,0 +1,34 @@ > > > > > +* Generic Dumb Interrupt Demultiplexer > > > > > + > > > > > +This Dumb demultiplixer simply forward all incoming interrupts to its > > > > > +enabled/unmasked children. > > > > > > > > Please forgive the potentially naïve question, but what hardware is this > > > > describing? > > > > > > That's not a real hardware per se, but on some hardware (like at91 SoCs) > > > some IRQ line are shared by several peripherals, and this dumb > > > demultiplex is here to represent such shared irq lines which cannot be > > > easily demultiplexed (because they do not provide a 'cause' > > > register). > > > > > > You can see it as a virtual irqchip provided to address broken hardware > > > designs. > > > > Hmm. Well, given tglx's recent reply, I suppose I'll *not* go down the > > rabbit hole of "the DT is for describing hardware." :-P > > Actually I'm a bit surprised no one else already mentioned that :-) (I > thought this would be the first complain regarding this dumb irq > demux chip). > > Anyway, IMHO, this can be considered as hardware description since > these irq-lines are really multiplexed into a single one... True, I think the issue is more that the DT node doesn't strictly represent a block of IP. We just need a way to make that clear in the binding doc. > > However, it would probably be a lot more palatable to the DT maintainers > > if we at least change the compatible to prepend "linux,". This way, if > > someone does come up with a better solution down the road, it will be > > much easier to deprecate the binding. > > > > I would also be amenable to "virt,", or "hack,", or even > > "work-around-piss-poor-hw,". Basically, anything that would indicate to > > consumers of the DT that this is not a true reflection of the hardware, > > and that it may be superseded by a better solution later. > > Actually I thought about changing it to "virtual,dumb-irq-demux" :-). Works for me. :) thx, Jason. -- 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 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
On Wed, Jan 14, 2015 at 08:34:39PM +0800, Zhou Wang wrote:
> On 2015/1/13 11:58, Brian Norris wrote:
> > On Mon, Jan 12, 2015 at 03:28:53PM +0800, Zhou Wang wrote:
> >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> >> + chip->IO_ADDR_R = chip->IO_ADDR_W = devm_ioremap_resource(dev, res);
> >
> > Hmm, do you really have to reuse IO_ADDR_{R,W} here? Those are only
> > targeted for NAND systems which have a direct MMIO mapping to the NAND
> > I/O pins. See nand_base's {read,write}_buf() and read_{byte,word}()
> > implementations. But you override those.
>
> There is a hardware buffer in this NAND controller, and the buffer can be
> accessed as MMIO.
Sure.
> IO_ADDR_R/W just indicates the base address of this buffer.
But I was noting that IO_ADDR_{R,W} actually serve a very particular
purpose in nand_base.c, which seems distinct from your HW buffer.
> Maybe I need to use a void __iomem pointer stored in my host struct to use
> this buffer instead of IO_ADDR_R/W as you said below here?
Yes, I think that would be better.
> > It's best if it's obvious if nand_base is somehow inadvertently using
> > these pointers. So leaving them NULL is helpful.
> >
> > As an alternative, you can just stash another private void __iomem
> > pointer in you your host struct.
Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] rtc: armada38x: Add the device tree binding documentation
Dear Gregory CLEMENT,
On Wed, 14 Jan 2015 18:39:11 +0100, Gregory CLEMENT wrote:
> +Required properties:
> +- compatible : Should be "marvell,armada-380-rtc"
> +- reg: physical base address of the controller and length of memory
> + mapped region, associated to the reg-name "rtc". The other entry is
> + related to the interrupt control from the SoC, associated to the
> + reg-name "soc-interrupt".
soc-interrupt or...
> +- reg-names: names of the mapped memory regions listed in regs
> +property in the same order: "rtc" and "soc-int".
soc-int ?
> +rtc@a3800 {
> + compatible = "marvell,armada-380-rtc";
> + reg = <0xa3800 0x20>, <0x184a0 0x0c>;
Any reason to use <0x184A0 0xC> instead of <0x184A8 0x4> ? According to
the datasheet, there is only this 184A8 register for RTC stuff.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: add bindings document for altera fpga manager
On Tue, 13 Jan 2015, Rob Herring wrote:
> On Fri, Jan 9, 2015 at 1:00 PM, wrote:
> > From: Alan Tull
> >
> > New bindings document for Altera fpga manager.
> >
> > Signed-off-by: Alan Tull
> > Acked-by: Rob Herring
>
> Applied for 3.20. Thanks.
Thanks!
Alan
>
> > ---
> > v5 : Move bindings to drivers/staging/fpga/Documentation/bindings
> >
> > v6 : No change in this patch for v6 of the patch set
> >
> > v7 : No change in this patch for v7 of the patch set
> >
> > v8 : Make compatible string and name of bindings doc more chip
> > specific
> >
> > v9 : Move bindings document from drivers/staging to Documentation
> > ---
> > .../bindings/fpga/altera-socfpga-fpga-mgr.txt | 17 +
> > 1 file changed, 17 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> > b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> > new file mode 100644
> > index 000..9b027a6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> > @@ -0,0 +1,17 @@
> > +Altera SOCFPGA FPGA Manager
> > +
> > +Required properties:
> > +- compatible : should contain "altr,socfpga-fpga-mgr"
> > +- reg: base address and size for memory mapped io.
> > + - The first index is for FPGA manager register access.
> > + - The second index is for writing FPGA configuration data.
> > +- interrupts : interrupt for the FPGA Manager device.
> > +
> > +Example:
> > +
> > + hps_0_fpgamgr: fpgamgr@0xff706000 {
> > + compatible = "altr,socfpga-fpga-mgr";
> > + reg = <0xFF706000 0x1000
> > + 0xFFB9 0x1000>;
> > + interrupts = <0 175 4>;
> > + };
> > --
> > 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
>
--
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/5] irqchip: Add DT binding doc for dumb demuxer chips
Hi Jason, On Wed, 14 Jan 2015 13:56:19 -0500 Jason Cooper wrote: > Hey Boris, > > On Tue, Jan 13, 2015 at 09:52:07PM +0100, Boris Brezillon wrote: > > On Tue, 13 Jan 2015 14:00:50 -0500 Jason Cooper > > wrote: > > > On Tue, Jan 13, 2015 at 07:46:18PM +0100, Boris Brezillon wrote: > > > > Add documentation for the dumb demuxer. > > > > > > > > Signed-off-by: Boris Brezillon > > > > --- > > > > .../bindings/interrupt-controller/dumb-demux.txt | 34 > > > > ++ > > > > 1 file changed, 34 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..1c777ef > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt > > > > @@ -0,0 +1,34 @@ > > > > +* Generic Dumb Interrupt Demultiplexer > > > > + > > > > +This Dumb demultiplixer simply forward all incoming interrupts to its > > > > +enabled/unmasked children. > > > > > > Please forgive the potentially naïve question, but what hardware is this > > > describing? > > > > That's not a real hardware per se, but on some hardware (like at91 SoCs) > > some IRQ line are shared by several peripherals, and this dumb > > demultiplex is here to represent such shared irq lines which cannot be > > easily demultiplexed (because they do not provide a 'cause' > > register). > > > > You can see it as a virtual irqchip provided to address broken hardware > > designs. > > Hmm. Well, given tglx's recent reply, I suppose I'll *not* go down the > rabbit hole of "the DT is for describing hardware." :-P Actually I'm a bit surprised no one else already mentioned that :-) (I thought this would be the first complain regarding this dumb irq demux chip). Anyway, IMHO, this can be considered as hardware description since these irq-lines are really multiplexed into a single one... > > However, it would probably be a lot more palatable to the DT maintainers > if we at least change the compatible to prepend "linux,". This way, if > someone does come up with a better solution down the road, it will be > much easier to deprecate the binding. > > I would also be amenable to "virt,", or "hack,", or even > "work-around-piss-poor-hw,". Basically, anything that would indicate to > consumers of the DT that this is not a true reflection of the hardware, > and that it may be superseded by a better solution later. Actually I thought about changing it to "virtual,dumb-irq-demux" :-). > > It would also be helpful to explain the situation more fully in the > binding document. Sure, I'll add a few lines to describe what this irqchip really is. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
Hi Jason, > On Jan 14, 2015, at 20:12 , Jason Gunthorpe > wrote: > > On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote: > >> and I think you effectively have the user usage covered here for such >> things. It much like GPIO pins - we can describe them but we can also >> declare they are not visible to the user. > > A missing element in mainline is a kind of VFIO scheme to let user > space access the FPGA registers designated for user space use. > > We have been using these patches since 2.6.16 to allow user space to > access the FPGA register resources via a PCI like /sys/../resource0 > mmapable: > > > https://github.com/jgunthorpe/linux/commit/59d5d13ddeffa8980ccc6248ebb5f1678ccb23f4 > > https://github.com/jgunthorpe/linux/commit/7c29c4344627be8a3906d64d32db533bc131df86 > > https://github.com/jgunthorpe/linux/commit/e41bb4a197368a9d505d66b627aee82f2d2b8895 > > We deliberately split up the FPGA registers and the assign user space > permissions to the resource0 files in a way that makes sense for our > app. Typically there are 10-20 FPGA register regions. User space does > not access register regions that control DMA. > Interesting. >> The swappable case mostly comes out of the /dev node. Once you have the >> dev node it becomes a detail of the OS not the FPGA driver as to who may >> open it, and how it is handed about. It might be an FPU manager daemon it >> might not. > > Right, but the thing that scares me about the swappable case is the > kernel side support.. The FPGA has to connect to the CPU in some way, > it must have some address assigned, etc. Swapping needs to take care > of all those details in some way. > > A fixed bus interface block and dynamic reconfiguration for the > remainder is probably the way to manage that. But, that implies that > even a family of swappable FPGAs will have a DT overlay associated > with it. > > Ideally, I could see wanting to have a file format that combines the > overlay and FPGA bitfile. A loader tool would use the /dev/ interface > to setup both elements. That would be much more robust than the > current scheme I see (eg Xilinx) using where the bitfile and DT bit > live in completely different places and have to be perfectly matched. > A single DT property can be 4 gigs of binary data (cheating a bit, the whole blob can be 4 gigs). You can conceivably include the whole bitfile in the DT blob. Whether this is a perversion or not it’s left to the reader. The bitfile does describe the hardware though. > Jason 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] ARM: shmobile: r8a7791: fix MSTP8 input clocks
Hello.
On 01/13/2015 03:36 AM, Simon Horman wrote:
I made a mistake when rebasing Andrey Gusakov's patch adding MLB+ clock to the
R8A7791 device tree, inserting <&hp_clk> into the "clocks" property of the
MSTP8 node at a wrong position, so that the input clocks for MLB+ and IPMMU-SGX
got swapped...
Fixes: 7408d3061d2f ("ARM: shmobile: r8a7791: add MLB+ clock")
Signed-off-by: Sergei Shtylyov
---
The patch is against 'renesas-devel-20150108v2-v3.19-rc3' tag of Simon Horman's
'renesas.git' repo.
Thanks, I have queued this up.
Thank you! I've just noticed that this patch was atop of several other
patches in my tree, so there might have been an offset when you applied it.
Sorry about that... :-<
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] irqchip: Add DT binding doc for dumb demuxer chips
Hey Boris, On Tue, Jan 13, 2015 at 09:52:07PM +0100, Boris Brezillon wrote: > On Tue, 13 Jan 2015 14:00:50 -0500 Jason Cooper wrote: > > On Tue, Jan 13, 2015 at 07:46:18PM +0100, Boris Brezillon wrote: > > > Add documentation for the dumb demuxer. > > > > > > Signed-off-by: Boris Brezillon > > > --- > > > .../bindings/interrupt-controller/dumb-demux.txt | 34 > > > ++ > > > 1 file changed, 34 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..1c777ef > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt > > > @@ -0,0 +1,34 @@ > > > +* Generic Dumb Interrupt Demultiplexer > > > + > > > +This Dumb demultiplixer simply forward all incoming interrupts to its > > > +enabled/unmasked children. > > > > Please forgive the potentially naïve question, but what hardware is this > > describing? > > That's not a real hardware per se, but on some hardware (like at91 SoCs) > some IRQ line are shared by several peripherals, and this dumb > demultiplex is here to represent such shared irq lines which cannot be > easily demultiplexed (because they do not provide a 'cause' > register). > > You can see it as a virtual irqchip provided to address broken hardware > designs. Hmm. Well, given tglx's recent reply, I suppose I'll *not* go down the rabbit hole of "the DT is for describing hardware." :-P However, it would probably be a lot more palatable to the DT maintainers if we at least change the compatible to prepend "linux,". This way, if someone does come up with a better solution down the road, it will be much easier to deprecate the binding. I would also be amenable to "virt,", or "hack,", or even "work-around-piss-poor-hw,". Basically, anything that would indicate to consumers of the DT that this is not a true reflection of the hardware, and that it may be superseded by a better solution later. It would also be helpful to explain the situation more fully in the binding document. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 3/4] arm64:thunder: Add initial dts for Cavium's Thunder SoC in 2 Node topology.
Hi Lorenzo,
On Wed, Jan 14, 2015 at 11:06 PM, Lorenzo Pieralisi
wrote:
> On Wed, Jan 07, 2015 at 08:18:50AM +, Arnd Bergmann wrote:
>> On Wednesday 07 January 2015 12:37:51 Ganapatrao Kulkarni wrote:
>> > Hi Arnd,
>> >
>> > On Wed, Jan 7, 2015 at 1:32 AM, Arnd Bergmann wrote:
>> > > On Tuesday 06 January 2015 15:04:26 Ganapatrao Kulkarni wrote:
>> > >> On Sat, Jan 3, 2015 at 2:47 AM, Arnd Bergmann wrote:
>> > >> > On Wednesday 31 December 2014 13:03:27 Ganapatrao Kulkarni wrote:
>> > >> >> + cpu@00f {
>> > >> >> + device_type = "cpu";
>> > >> >> + compatible = "cavium,thunder", "arm,armv8";
>> > >> >> + reg = <0x0 0x00f>;
>> > >> >> + enable-method = "psci";
>> > >> >> + arm,associativity = <0 0 0x00f>;
>> > >> >> + };
>> > >> >> + cpu@100 {
>> > >> >> + device_type = "cpu";
>> > >> >> + compatible = "cavium,thunder", "arm,armv8";
>> > >> >> + reg = <0x0 0x100>;
>> > >> >> + enable-method = "psci";
>> > >> >> + arm,associativity = <0 0 0x100>;
>> > >> >> + };
>> > >> >
>> > >> > What is the 0x100 offset in the last-level topology field? Does this
>> > >> > have
>> > >> > no significance to topology at all? I would expect that to be
>> > >> > something
>> > >> > like cluster number that is relevant to caching and should be
>> > >> > represented
>> > >> > as a separate level.
>> > >>
>> > >> i did not understand, can you please explain little more about "
>> > >> should be represented as a separate level."
>> > >> at present, i have put the hwid of a cpu.
>> > >
>> > > From what I undertand, the hwid of the CPU contains the "cluster" number
>> > > in
>> > > this bit position, so you typically have a shared L2 or L3 cache between
>> > > all cores within a cluster, but separate caches in other clusters.
>> > >
>> > > If this is the case, there will be a measurable difference in performance
>> > > between two processes sharing memory when running on the same cluster,
>> > > or when running on different clusters on the same socket. If the
>> > > performance difference is relevant, it should be described as a separate
>> > > level in the associativity property.
>> > you mean, the associativity as array of
>>
>> No, that would leave out the core number, which is required to identify
>> the individual thread. I meant adding an extra level such as
>>
>>
>>
>> A lot of machines will leave out the number because they are
>> built with SoCs that don't have a long-distance coherency protocol.
>
> Can't we use phandles to cpu-map nodes instead of a list of numbers (and
> yet another topology binding description) ?
cpu-map describes only a cpu topology.
infact, i have tried initially(in v1 patch set) to use topology for
the numa mapping.
However, for numa, we need to define association of cpu, memory and IOs.
arm,associativity is a generic node property and can be used in any dt nodes.
>
> Is arm,associativity used solely to map "devices" (inclusive of caches)
> to a set of cpus ?
>
> cpu-map misses a notion of distance between hierarchy layers, but we can
> add to that.
>
> Lorenzo
thanks
ganapat
--
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 13/15] ARM: dts: Exynos4 and Odroid X2/U3 sound device nodes update
Clock related properties are added to the Exynos4 I2S device nodes
so they can be referred to as clock providers. Missing i2s_opclk1
clock is added to the I2S0 node and clock properties are added
to the MAX98090 codec node to allow it to control/read frequency
of the MCLK clock directly.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4.dtsi |6 ++
arch/arm/boot/dts/exynos4412-odroid-common.dtsi |8 ++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..38d8f68 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -61,6 +61,8 @@
reg = <0x0383 0x100>;
clocks = <&clock_audss EXYNOS_I2S_BUS>;
clock-names = "iis";
+ #clock-cells = <1>;
+ clock-output-names = "i2s_cdclk0";
dmas = <&pdma0 12>, <&pdma0 11>, <&pdma0 10>;
dma-names = "tx", "rx", "tx-sec";
samsung,idma-addr = <0x0300>;
@@ -372,6 +374,8 @@
reg = <0x1396 0x100>;
clocks = <&clock CLK_I2S1>;
clock-names = "iis";
+ #clock-cells = <1>;
+ clock-output-names = "i2s_cdclk1";
dmas = <&pdma1 12>, <&pdma1 11>;
dma-names = "tx", "rx";
status = "disabled";
@@ -382,6 +386,8 @@
reg = <0x1397 0x100>;
clocks = <&clock CLK_I2S2>;
clock-names = "iis";
+ #clock-cells = <1>;
+ clock-output-names = "i2s_cdclk2";
dmas = <&pdma0 14>, <&pdma0 13>;
dma-names = "tx", "rx";
status = "disabled";
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3fbf588..c26b9fb 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -7,6 +7,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include "exynos4412.dtsi"
@@ -37,8 +38,9 @@
pinctrl-names = "default";
status = "okay";
clocks = <&clock_audss EXYNOS_I2S_BUS>,
-<&clock_audss EXYNOS_DOUT_AUD_BUS>;
- clock-names = "iis", "i2s_opclk0";
+<&clock_audss EXYNOS_DOUT_AUD_BUS>,
+<&clock_audss EXYNOS_SCLK_I2S>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
};
sound: sound {
@@ -373,6 +375,8 @@
reg = <0x10>;
interrupt-parent = <&gpx0>;
interrupts = <0 0>;
+ clocks = <&i2s0 CLK_I2S_CDCLK>;
+ clock-names = "mclk";
};
};
--
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 V3 12/15] ASoC: samsung: i2s: Add clock provider for the I2S internal clocks
This patch adds clock provider (currently only for DT platforms) for
the CODECLKO (CDCLK) gate, RCLKSRC mux and RCLK pre-scaler divider
divider clock. Those all tree clock are only available in the IIS
Multi Audio Interface (I2S0), the regular IIS Bus Interface has only
CDCLK gate clock.
The motivation behind this patch is to expose the I2S internal clocks
which are currently controlled through set_sysclk() through the clk
API, so dedicated sound machine driver per each board can be avoided.
The intention is also to fix the CDCLK gating issue reported by
Daniel Drake:
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081753.html
This patch also reverts commit b97c60abf9a561f86ae71bd741add02673cc1
("ASoC: samsung-i2s: Maintain CDCLK settings across i2s_{shutdown/
startup}") The problem that commit attempted to solve only affects
the Odroid X2/U3, which doesn't configure the CDCLK clock in
struct snd_soc_dai_ops hw_params callback and the issue should be
now resolved by using clk API, i.e. having the codec enabling/
disabling the CDCLK clock as required.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 113 ++-
1 file changed, 93 insertions(+), 20 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 05fc2f0..b92ab40 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -10,9 +10,11 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -81,8 +83,6 @@ struct i2s_dai {
#define DAI_OPENED (1 << 0) /* Dai is opened */
#define DAI_MANAGER(1 << 1) /* Dai is the manager */
unsigned mode;
- /* CDCLK pin direction: 0 - input, 1 - output */
- unsigned int cdclk_out:1;
/* Driver for this DAI */
struct snd_soc_dai_driver i2s_dai_drv;
/* DMA parameters */
@@ -98,6 +98,10 @@ struct i2s_dai {
/* Spinlock protecting access to the device's registers */
spinlock_t spinlock;
spinlock_t *lock;
+
+ /* Below fields are only valid if this is the primary FIFO */
+ struct clk *clk_table[3];
+ struct clk_onecell_data clk_data;
};
/* Lock for cross i/f checks */
@@ -774,9 +778,6 @@ static int i2s_startup(struct snd_pcm_substream *substream,
spin_unlock_irqrestore(&lock, flags);
- if (!is_opened(other) && i2s->cdclk_out)
- i2s_set_sysclk(dai, SAMSUNG_I2S_CDCLK,
- 0, SND_SOC_CLOCK_OUT);
return 0;
}
@@ -786,31 +787,20 @@ static void i2s_shutdown(struct snd_pcm_substream
*substream,
struct i2s_dai *i2s = to_info(dai);
struct i2s_dai *other = get_other_dai(i2s);
unsigned long flags;
- const struct samsung_i2s_variant_regs *i2s_regs = i2s->variant_regs;
spin_lock_irqsave(&lock, flags);
i2s->mode &= ~DAI_OPENED;
i2s->mode &= ~DAI_MANAGER;
- if (is_opened(other)) {
+ if (is_opened(other))
other->mode |= DAI_MANAGER;
- } else {
- u32 mod = readl(i2s->addr + I2SMOD);
- i2s->cdclk_out = !(mod & (1 << i2s_regs->cdclkcon_off));
- if (other)
- other->cdclk_out = i2s->cdclk_out;
- }
+
/* Reset any constraint on RFS and BFS */
i2s->rfs = 0;
i2s->bfs = 0;
spin_unlock_irqrestore(&lock, flags);
-
- /* Gate CDCLK by default */
- if (!is_opened(other))
- i2s_set_sysclk(dai, SAMSUNG_I2S_CDCLK,
- 0, SND_SOC_CLOCK_IN);
}
static int config_setup(struct i2s_dai *i2s)
@@ -1147,6 +1137,87 @@ static int i2s_runtime_resume(struct device *dev)
}
#endif /* CONFIG_PM */
+static void i2s_unregister_clocks(struct i2s_dai *i2s)
+{
+ int i;
+
+ for (i = 0; i < i2s->clk_data.clk_num; i++) {
+ if (!IS_ERR(i2s->clk_table[i]))
+ clk_unregister(i2s->clk_table[i]);
+ }
+}
+
+static void i2s_unregister_clock_provider(struct platform_device *pdev)
+{
+ struct i2s_dai *i2s = dev_get_drvdata(&pdev->dev);
+
+ of_clk_del_provider(pdev->dev.of_node);
+ i2s_unregister_clocks(i2s);
+}
+
+static int i2s_register_clock_provider(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct i2s_dai *i2s = dev_get_drvdata(dev);
+ const char *clk_name[2] = { "i2s_opclk0", "i2s_opclk1" };
+ const char *p_names[2] = { NULL };
+ const struct samsung_i2s_variant_regs *reg_info = i2s->variant_regs;
+ struct clk *rclksrc;
+ int ret, i;
+
+ /* Register the clock provider only if it's expected in the DTB */
+ if (!of_find_property(dev->of_node, "#clock-cells", NULL))
+ return 0;
+
+ /* Get the RCLKSRC mux clock parent clock names */
+ for (i = 0; i < ARRAY_SIZE(p_names); i++) {
+
[PATCH V3 14/15] ARM: dts: Switch Odroid X2/U2 to simple-audio-card
Now when the CDCLK I2S output clock can be handled through the clock
API the Odroid X2/U3 can be switched to the simple-audio-card DT binding.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4.dtsi |3 +++
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 19 ---
arch/arm/boot/dts/exynos4412-odroidu3.dts |8 +---
arch/arm/boot/dts/exynos4412-odroidx2.dts |8 ++--
4 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 38d8f68..0cffe39 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -66,6 +66,7 @@
dmas = <&pdma0 12>, <&pdma0 11>, <&pdma0 10>;
dma-names = "tx", "rx", "tx-sec";
samsung,idma-addr = <0x0300>;
+ #sound-dai-cells = <1>;
status = "disabled";
};
@@ -378,6 +379,7 @@
clock-output-names = "i2s_cdclk1";
dmas = <&pdma1 12>, <&pdma1 11>;
dma-names = "tx", "rx";
+ #sound-dai-cells = <1>;
status = "disabled";
};
@@ -390,6 +392,7 @@
clock-output-names = "i2s_cdclk2";
dmas = <&pdma0 14>, <&pdma0 13>;
dma-names = "tx", "rx";
+ #sound-dai-cells = <1>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index c26b9fb..abd6336 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -44,9 +44,7 @@
};
sound: sound {
- compatible = "samsung,odroidx2-audio";
- samsung,i2s-controller = <&i2s0>;
- samsung,audio-codec = <&max98090>;
+ compatible = "simple-audio-card";
assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
<&clock_audss EXYNOS_MOUT_I2S>,
<&clock_audss EXYNOS_DOUT_SRP>,
@@ -57,6 +55,20 @@
<0>,
<19200>,
<1920>;
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&link0_codec>;
+ simple-audio-card,frame-master = <&link0_codec>;
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0 0>;
+ system-clock-frequency = <1920>;
+ };
+
+ link0_codec: simple-audio-card,codec {
+ sound-dai = <&max98090>;
+ clocks = <&i2s0 CLK_I2S_CDCLK>;
+ };
};
mmc@1255 {
@@ -377,6 +389,7 @@
interrupts = <0 0>;
clocks = <&i2s0 CLK_I2S_CDCLK>;
clock-names = "mclk";
+ #sound-dai-cells = <0>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index c8a64be..44684e5 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -49,9 +49,11 @@
};
&sound {
- compatible = "samsung,odroidu3-audio";
- samsung,model = "Odroid-U3";
- samsung,audio-routing =
+ simple-audio-card,name = "Odroid-U3";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Speakers", "Speakers";
+ simple-audio-card,routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"Headphone Jack", "MICBIAS",
diff --git a/arch/arm/boot/dts/exynos4412-odroidx2.dts
b/arch/arm/boot/dts/exynos4412-odroidx2.dts
index 96b43f4..6e33678 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx2.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx2.dts
@@ -23,8 +23,12 @@
};
&sound {
- samsung,model = "Odroid-X2";
- samsung,audio-routing =
+ simple-audio-card,name = "Odroid-X2";
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Microphone", "Mic Jack",
+ "Microphone", "DMIC";
+ simple-audio-card,routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"IN1", "Mic Jack",
--
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 V3 09/15] ASoC: samsung: i2s: Protect more registers with a spinlock
Ensure the I2SMOD, I2SPSR registers, which are also exposed through
clk API are only accessed with the i2s->spinlock spinlock held.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 81 +--
1 file changed, 51 insertions(+), 30 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 20cc51f..05fc2f0 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -472,17 +472,22 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
{
struct i2s_dai *i2s = to_info(dai);
struct i2s_dai *other = get_other_dai(i2s);
- u32 mod = readl(i2s->addr + I2SMOD);
const struct samsung_i2s_variant_regs *i2s_regs = i2s->variant_regs;
unsigned int cdcon_mask = 1 << i2s_regs->cdclkcon_off;
unsigned int rsrc_mask = 1 << i2s_regs->rclksrc_off;
+ u32 mod, mask, val = 0;
+
+ spin_lock(i2s->lock);
+ mod = readl(i2s->addr + I2SMOD);
+ spin_unlock(i2s->lock);
switch (clk_id) {
case SAMSUNG_I2S_OPCLK:
- mod &= ~MOD_OPCLK_MASK;
- mod |= dir;
+ mask = MOD_OPCLK_MASK;
+ val = dir;
break;
case SAMSUNG_I2S_CDCLK:
+ mask = 1 << i2s_regs->cdclkcon_off;
/* Shouldn't matter in GATING(CLOCK_IN) mode */
if (dir == SND_SOC_CLOCK_IN)
rfs = 0;
@@ -499,15 +504,15 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
}
if (dir == SND_SOC_CLOCK_IN)
- mod |= 1 << i2s_regs->cdclkcon_off;
- else
- mod &= ~(1 << i2s_regs->cdclkcon_off);
+ val = 1 << i2s_regs->cdclkcon_off;
i2s->rfs = rfs;
break;
case SAMSUNG_I2S_RCLKSRC_0: /* clock corrsponding to IISMOD[10] := 0 */
case SAMSUNG_I2S_RCLKSRC_1: /* clock corrsponding to IISMOD[10] := 1 */
+ mask = 1 << i2s_regs->rclksrc_off;
+
if ((i2s->quirks & QUIRK_NO_MUXPSR)
|| (clk_id == SAMSUNG_I2S_RCLKSRC_0))
clk_id = 0;
@@ -557,18 +562,19 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
return 0;
}
- if (clk_id == 0)
- mod &= ~(1 << i2s_regs->rclksrc_off);
- else
- mod |= 1 << i2s_regs->rclksrc_off;
-
+ if (clk_id == 1)
+ val = 1 << i2s_regs->rclksrc_off;
break;
default:
dev_err(&i2s->pdev->dev, "We don't serve that!\n");
return -EINVAL;
}
+ spin_lock(i2s->lock);
+ mod = readl(i2s->addr + I2SMOD);
+ mod = (mod & ~mask) | val;
writel(mod, i2s->addr + I2SMOD);
+ spin_unlock(i2s->lock);
return 0;
}
@@ -577,9 +583,8 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
{
struct i2s_dai *i2s = to_info(dai);
- u32 mod = readl(i2s->addr + I2SMOD);
int lrp_shift, sdf_shift, sdf_mask, lrp_rlow, mod_slave;
- u32 tmp = 0;
+ u32 mod, tmp = 0;
lrp_shift = i2s->variant_regs->lrp_off;
sdf_shift = i2s->variant_regs->sdf_off;
@@ -639,12 +644,15 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
return -EINVAL;
}
+ spin_lock(i2s->lock);
+ mod = readl(i2s->addr + I2SMOD);
/*
* Don't change the I2S mode if any controller is active on this
* channel.
*/
if (any_active(i2s) &&
((mod & (sdf_mask | lrp_rlow | mod_slave)) != tmp)) {
+ spin_unlock(i2s->lock);
dev_err(&i2s->pdev->dev,
"%s:%d Other DAI busy\n", __func__, __LINE__);
return -EAGAIN;
@@ -653,6 +661,7 @@ static int i2s_set_fmt(struct snd_soc_dai *dai,
mod &= ~(sdf_mask | lrp_rlow | mod_slave);
mod |= tmp;
writel(mod, i2s->addr + I2SMOD);
+ spin_unlock(i2s->lock);
return 0;
}
@@ -661,16 +670,16 @@ static int i2s_hw_params(struct snd_pcm_substream
*substream,
struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
{
struct i2s_dai *i2s = to_info(dai);
- u32 mod = readl(i2s->addr + I2SMOD);
+ u32 mod, mask = 0, val = 0;
if (!is_secondary(i2s))
- mod &= ~(MOD_DC2_EN | MOD_DC1_EN);
+ mask |= (MOD_DC2_EN | MOD_DC1_EN);
switch (params_channels(params)) {
case 6:
- mod |= MOD_DC2_EN;
+ val |= MOD_DC2_EN;
case 4:
- mod |= MOD_DC1_EN;
+ val |= MOD_DC1_EN;
break;
case 2:
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -692,44 +701,49 @@ static int i2s_hw_params(struct snd_p
[PATCH V3 10/15] ASoC: samsung: odroidx2: Handle I2S CDCLK clock conditionally
In order to support old DTs we check the codec device node if it
contains "clocks" property and only if it doesn't (which indicates
an old DT) we proceed with enabling the CDCLK clock by means of
the set_sysclk() callback. For new DTs which use the common clock
bindings for CDCLK that clock is supposed to be handled outside
the sound machine driver.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/odroidx2_max98090.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/samsung/odroidx2_max98090.c
b/sound/soc/samsung/odroidx2_max98090.c
index fa4f1d2..596f118 100644
--- a/sound/soc/samsung/odroidx2_max98090.c
+++ b/sound/soc/samsung/odroidx2_max98090.c
@@ -21,6 +21,8 @@ struct odroidx2_drv_data {
/* The I2S CDCLK output clock frequency for the MAX98090 codec */
#define MAX98090_MCLK 1920
+static struct snd_soc_dai_link odroidx2_dai[];
+
static int odroidx2_late_probe(struct snd_soc_card *card)
{
struct snd_soc_dai *codec_dai = card->rtd[0].codec_dai;
@@ -29,7 +31,9 @@ static int odroidx2_late_probe(struct snd_soc_card *card)
ret = snd_soc_dai_set_sysclk(codec_dai, 0, MAX98090_MCLK,
SND_SOC_CLOCK_IN);
- if (ret < 0)
+
+ if (ret < 0 || of_find_property(odroidx2_dai[0].codec_of_node,
+ "clocks", NULL))
return ret;
/* Set the cpu DAI configuration in order to use CDCLK */
--
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 V3 15/15] ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs
I2S1, I2S2 on Exynos4 SoC series have limited functionality compared
to I2S0, "samsung,s3c6410-i2s" compatible should be used for them.
Cc: sta...@vger.kernel.org
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4.dtsi |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0cffe39..cb60010 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -371,7 +371,7 @@
};
i2s1: i2s@1396 {
- compatible = "samsung,s5pv210-i2s";
+ compatible = "samsung,s3c6410-i2s";
reg = <0x1396 0x100>;
clocks = <&clock CLK_I2S1>;
clock-names = "iis";
@@ -384,7 +384,7 @@
};
i2s2: i2s@1397 {
- compatible = "samsung,s5pv210-i2s";
+ compatible = "samsung,s3c6410-i2s";
reg = <0x1397 0x100>;
clocks = <&clock CLK_I2S2>;
clock-names = "iis";
--
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 V3 11/15] ASoC: samsung: i2s: Add clk provider DT binding documentation
The new DT properties required for the I2S device node to be referred
as a clock provider and corresponding clock indices definition is added.
Signed-off-by: Sylwester Nawrocki
---
.../devicetree/bindings/sound/samsung-i2s.txt | 22
include/dt-bindings/sound/samsung-i2s.h|8 +++
2 files changed, 30 insertions(+)
create mode 100644 include/dt-bindings/sound/samsung-i2s.h
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index d188296..09e0e18 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -33,6 +33,25 @@ Required SoC Specific Properties:
"iis" is the i2s bus clock and i2s_opclk0, i2s_opclk1 are sources of the root
clk. i2s0 has internal mux to select the source of root clk and i2s1 and i2s2
doesn't have any such mux.
+- #clock-cells: should be 1, this property must be present if the I2S device
+ is a clock provider in terms of the common clock bindings, described in
+ ../clock/clock-bindings.txt.
+- clock-output-names: from the common clock bindings, names of the CDCLK
+ I2S output clocks, suggested values are "i2s_cdclk0", "i2s_cdclk1",
+ "i2s_cdclk3" for the I2S0, I2S1, I2S2 devices recpectively.
+
+There are following clocks available at the I2S device nodes:
+ CLK_I2S_CDCLK- the CDCLK (CODECLKO) gate clock,
+ CLK_I2S_RCLK_PSR - the RCLK prescaler divider clock (corresponding to the
+ IISPSR register),
+ CLK_I2S_RCLK_SRC - the RCLKSRC mux clock (corresponding to RCLKSRC bit in
+ IISMOD register).
+
+Refer to the SoC datasheet for availability of the above clocks.
+The CLK_I2S_RCLK_PSR and CLK_I2S_RCLK_SRC clocks are usually only available
+in the IIS Multi Audio Interface (I2S0).
+Note: Old DTs may not have the #clock-cells, clock-output-names properties
+and then not use the I2S node as a clock supplier.
Optional SoC Specific Properties:
@@ -41,6 +60,7 @@ Optional SoC Specific Properties:
- pinctrl-0: Should specify pin control groups used for this controller.
- pinctrl-names: Should contain only one value - "default".
+
Example:
i2s0: i2s@0383 {
@@ -54,6 +74,8 @@ i2s0: i2s@0383 {
<&clock_audss EXYNOS_I2S_BUS>,
<&clock_audss EXYNOS_SCLK_I2S>;
clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+ #clock-cells;
+ clock-output-names = "i2s_cdclk0";
samsung,idma-addr = <0x0300>;
pinctrl-names = "default";
pinctrl-0 = <&i2s0_bus>;
diff --git a/include/dt-bindings/sound/samsung-i2s.h
b/include/dt-bindings/sound/samsung-i2s.h
new file mode 100644
index 000..0c69818d
--- /dev/null
+++ b/include/dt-bindings/sound/samsung-i2s.h
@@ -0,0 +1,8 @@
+#ifndef _DT_BINDINGS_SAMSUNG_I2S_H
+#define _DT_BINDINGS_SAMSUNG_I2S_H
+
+#define CLK_I2S_CDCLK 0
+#define CLK_I2S_RCLK_SRC 1
+#define CLK_I2S_RCLK_PSR 2
+
+#endif /* _DT_BINDINGS_SAMSUNG_I2S_H */
--
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 V3 08/15] ASoC: samsung: i2s: Add spinlock in place of local_irq_* calls
It seems this driver hasn't been updated for SMP, as local_irq_save/
local_irq_restore don't provide proper protection of read/modify/write
of the device's registers on such systems. Introduce a spinlock
serializing access to the register region, it will be helpful later
when I2SMOD, I2SPSR registers are made also accessible through the
clk API.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 2bac719..20cc51f 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -94,6 +94,10 @@ struct i2s_dai {
u32 suspend_i2scon;
u32 suspend_i2spsr;
const struct samsung_i2s_variant_regs *variant_regs;
+
+ /* Spinlock protecting access to the device's registers */
+ spinlock_t spinlock;
+ spinlock_t *lock;
};
/* Lock for cross i/f checks */
@@ -867,10 +871,10 @@ static int i2s_trigger(struct snd_pcm_substream
*substream,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- local_irq_save(flags);
+ spin_lock_irqsave(i2s->lock, flags);
if (config_setup(i2s)) {
- local_irq_restore(flags);
+ spin_unlock_irqrestore(i2s->lock, flags);
return -EINVAL;
}
@@ -879,12 +883,12 @@ static int i2s_trigger(struct snd_pcm_substream
*substream,
else
i2s_txctrl(i2s, 1);
- local_irq_restore(flags);
+ spin_unlock_irqrestore(i2s->lock, flags);
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- local_irq_save(flags);
+ spin_lock_irqsave(i2s->lock, flags);
if (capture) {
i2s_rxctrl(i2s, 0);
@@ -894,7 +898,7 @@ static int i2s_trigger(struct snd_pcm_substream *substream,
i2s_fifo(i2s, FIC_TXFLUSH);
}
- local_irq_restore(flags);
+ spin_unlock_irqrestore(i2s->lock, flags);
break;
}
@@ -1157,6 +1161,9 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ spin_lock_init(&pri_dai->spinlock);
+ pri_dai->lock = &pri_dai->spinlock;
+
if (!np) {
res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!res) {
@@ -1234,6 +1241,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ sec_dai->lock = &pri_dai->spinlock;
sec_dai->variant_regs = pri_dai->variant_regs;
sec_dai->dma_playback.dma_addr = regs_base + I2STXDS;
sec_dai->dma_playback.ch_name = "tx-sec";
--
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 V3 06/15] ASoC: samsung: i2s: Add get_other_dai helper function
The code to get pointer to the other DAI is repeated multiple
times. Add a helper function and use it instead.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index f75c19e..cab2a2a 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -130,10 +130,16 @@ static inline bool tx_active(struct i2s_dai *i2s)
return active ? true : false;
}
+/* Return pointer to the other DAI */
+static inline struct i2s_dai *get_other_dai(struct i2s_dai *i2s)
+{
+ return i2s->pri_dai ? : i2s->sec_dai;
+}
+
/* If the other interface of the controller is transmitting data */
static inline bool other_tx_active(struct i2s_dai *i2s)
{
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
return tx_active(other);
}
@@ -160,7 +166,7 @@ static inline bool rx_active(struct i2s_dai *i2s)
/* If the other interface of the controller is receiving data */
static inline bool other_rx_active(struct i2s_dai *i2s)
{
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
return rx_active(other);
}
@@ -461,7 +467,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
int clk_id, unsigned int rfs, int dir)
{
struct i2s_dai *i2s = to_info(dai);
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
u32 mod = readl(i2s->addr + I2SMOD);
const struct samsung_i2s_variant_regs *i2s_regs = i2s->variant_regs;
unsigned int cdcon_mask = 1 << i2s_regs->cdclkcon_off;
@@ -733,7 +739,7 @@ static int i2s_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct i2s_dai *i2s = to_info(dai);
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
unsigned long flags;
spin_lock_irqsave(&lock, flags);
@@ -760,7 +766,7 @@ static void i2s_shutdown(struct snd_pcm_substream
*substream,
struct snd_soc_dai *dai)
{
struct i2s_dai *i2s = to_info(dai);
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
unsigned long flags;
const struct samsung_i2s_variant_regs *i2s_regs = i2s->variant_regs;
@@ -791,7 +797,7 @@ static void i2s_shutdown(struct snd_pcm_substream
*substream,
static int config_setup(struct i2s_dai *i2s)
{
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
unsigned rfs, bfs, blc;
u32 psr;
@@ -899,7 +905,7 @@ static int i2s_set_clkdiv(struct snd_soc_dai *dai,
int div_id, int div)
{
struct i2s_dai *i2s = to_info(dai);
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
switch (div_id) {
case SAMSUNG_I2S_DIV_BCLK:
@@ -968,7 +974,7 @@ static int i2s_resume(struct snd_soc_dai *dai)
static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
{
struct i2s_dai *i2s = to_info(dai);
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
+ struct i2s_dai *other = get_other_dai(i2s);
if (is_secondary(i2s)) { /* If this is probe on the secondary DAI */
samsung_asoc_init_dma_data(dai, &other->sec_dai->dma_playback,
@@ -1271,7 +1277,7 @@ static int samsung_i2s_remove(struct platform_device
*pdev)
struct i2s_dai *i2s, *other;
i2s = dev_get_drvdata(&pdev->dev);
- other = i2s->pri_dai ? : i2s->sec_dai;
+ other = get_other_dai(i2s);
if (other) {
other->pri_dai = 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 V3 02/15] ASoC: samsung: i2s: Add return value checks in probe()
These functions may fail so let's properly report any errors. Signed-off-by: Sylwester Nawrocki --- sound/soc/samsung/i2s.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index e5473ee..aa52b41 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -1173,11 +1173,13 @@ static int samsung_i2s_probe(struct platform_device *pdev) dev_err(&pdev->dev, "Unable to get drvdata\n"); return -EFAULT; } - devm_snd_soc_register_component(&sec_dai->pdev->dev, + ret = devm_snd_soc_register_component(&sec_dai->pdev->dev, &samsung_i2s_component, &sec_dai->i2s_dai_drv, 1); - samsung_asoc_dma_platform_register(&pdev->dev); - return 0; + if (ret != 0) + return ret; + + return samsung_asoc_dma_platform_register(&pdev->dev); } pri_dai = i2s_alloc_dai(pdev, false); @@ -1290,7 +1292,9 @@ static int samsung_i2s_probe(struct platform_device *pdev) pm_runtime_enable(&pdev->dev); - samsung_asoc_dma_platform_register(&pdev->dev); + ret = samsung_asoc_dma_platform_register(&pdev->dev); + if (ret != 0) + return ret; return 0; err: -- 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 V3 03/15] ASoC: samsung: i2s: Request memory region in driver probe()
The memory mapped registers region is common for both DAIs so request
it in the I2S platform device driver's probe for the platform device
corresponding to the primary DAI, rather than in the ASoC DAI's probe
callback. While at it switch to devm_ioremap_resource(). This also
drops the hard coded (0x100) register region size in the driver.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 45 +++--
1 file changed, 7 insertions(+), 38 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index aa52b41..366b720 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -59,10 +59,8 @@ struct samsung_i2s_dai_data {
struct i2s_dai {
/* Platform device for this DAI */
struct platform_device *pdev;
- /* IOREMAP'd SFRs */
+ /* Memory mapped SFR region */
void __iomem*addr;
- /* Physical base address of SFRs */
- u32 base;
/* Rate of RCLK source clock */
unsigned long rclk_srcrate;
/* Frame Clock */
@@ -979,16 +977,9 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
goto probe_exit;
}
- i2s->addr = ioremap(i2s->base, 0x100);
- if (i2s->addr == NULL) {
- dev_err(&i2s->pdev->dev, "cannot ioremap registers\n");
- return -ENXIO;
- }
-
i2s->clk = clk_get(&i2s->pdev->dev, "iis");
if (IS_ERR(i2s->clk)) {
dev_err(&i2s->pdev->dev, "failed to get i2s_clock\n");
- iounmap(i2s->addr);
return PTR_ERR(i2s->clk);
}
@@ -1001,7 +992,6 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
samsung_asoc_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture);
if (other) {
- other->addr = i2s->addr;
other->clk = i2s->clk;
}
@@ -1043,8 +1033,6 @@ static int samsung_i2s_dai_remove(struct snd_soc_dai *dai)
clk_disable_unprepare(i2s->clk);
clk_put(i2s->clk);
-
- iounmap(i2s->addr);
}
i2s->clk = NULL;
@@ -1162,7 +1150,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
u32 regs_base, quirks = 0, idma_addr = 0;
struct device_node *np = pdev->dev.of_node;
const struct samsung_i2s_dai_data *i2s_dai_data;
- int ret = 0;
/* Call during Seconday interface registration */
i2s_dai_data = samsung_i2s_get_driver_data(pdev);
@@ -1229,16 +1216,10 @@ static int samsung_i2s_probe(struct platform_device
*pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Unable to get I2S SFR address\n");
- return -ENXIO;
- }
+ pri_dai->addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pri_dai->addr))
+ return PTR_ERR(pri_dai->addr);
- if (!request_mem_region(res->start, resource_size(res),
- "samsung-i2s")) {
- dev_err(&pdev->dev, "Unable to request SFR region\n");
- return -EBUSY;
- }
regs_base = res->start;
pri_dai->dma_playback.dma_addr = regs_base + I2STXD;
@@ -1247,7 +1228,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
pri_dai->dma_capture.ch_name = "rx";
pri_dai->dma_playback.dma_size = 4;
pri_dai->dma_capture.dma_size = 4;
- pri_dai->base = regs_base;
pri_dai->quirks = quirks;
pri_dai->variant_regs = i2s_dai_data->i2s_variant_regs;
@@ -1258,8 +1238,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai = i2s_alloc_dai(pdev, true);
if (!sec_dai) {
dev_err(&pdev->dev, "Unable to alloc I2S_sec\n");
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
sec_dai->variant_regs = pri_dai->variant_regs;
@@ -1273,7 +1252,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
}
sec_dai->dma_playback.dma_size = 4;
- sec_dai->base = regs_base;
+ sec_dai->addr = pri_dai->addr;
sec_dai->quirks = quirks;
sec_dai->idma_playback.dma_addr = idma_addr;
sec_dai->pri_dai = pri_dai;
@@ -1282,8 +1261,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
if (i2s_pdata && i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
dev_err(&pdev->dev, "Unable to configure gpio\n");
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
devm_snd_soc_register_component(&pri_dai->pdev->dev,
@@ -1297,17 +1275,11 @@ static int samsung_i2s_probe(struct platform_device
*pdev)
return ret;
[PATCH V3 05/15] ASoC: samsung: i2s: Move clk enable to the platform driver probe()
The clk_prepare_enable() call on the "iis" clock is moved to happen earlier
in the DAI platform device driver's probe() callback, so the I2S registers
can be safely accessed through the clk API, after the clk supplier is
registered in the platform device probe().
After this patch the "iis" clock is kept enabled since the (primary) I2S
platform device probe() and until the platform device driver remove() call.
This is similar to gating the clock in the snd_soc_dai probe() and remove()
callbacks.
Normally, in addition to that we should mark the device as PM runtime active,
so if runtime PM is enabled it can idle the device by turning off the clock.
Correcting this issue is left for a separate patch series, as we need to
ensure the BUSCLK clock is always enabled when required.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index a854ffc..f75c19e 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -969,7 +969,6 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
{
struct i2s_dai *i2s = to_info(dai);
struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
- int ret;
if (is_secondary(i2s)) { /* If this is probe on the secondary DAI */
samsung_asoc_init_dma_data(dai, &other->sec_dai->dma_playback,
@@ -977,12 +976,6 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
goto probe_exit;
}
- ret = clk_prepare_enable(i2s->clk);
- if (ret != 0) {
- dev_err(&i2s->pdev->dev, "failed to enable clock: %d\n", ret);
- return ret;
- }
-
samsung_asoc_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture);
if (i2s->quirks & QUIRK_NEED_RSTCLR)
@@ -1014,18 +1007,12 @@ probe_exit:
static int samsung_i2s_dai_remove(struct snd_soc_dai *dai)
{
struct i2s_dai *i2s = snd_soc_dai_get_drvdata(dai);
- struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
-
- if (!other || !other->clk) {
+ if (!is_secondary(i2s)) {
if (i2s->quirks & QUIRK_NEED_RSTCLR)
writel(0, i2s->addr + I2SCON);
-
- clk_disable_unprepare(i2s->clk);
}
- i2s->clk = NULL;
-
return 0;
}
@@ -1139,6 +1126,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
u32 regs_base, quirks = 0, idma_addr = 0;
struct device_node *np = pdev->dev.of_node;
const struct samsung_i2s_dai_data *i2s_dai_data;
+ int ret;
/* Call during Seconday interface registration */
i2s_dai_data = samsung_i2s_get_driver_data(pdev);
@@ -1216,6 +1204,12 @@ static int samsung_i2s_probe(struct platform_device
*pdev)
dev_err(&pdev->dev, "Failed to get iis clock\n");
return PTR_ERR(pri_dai->clk);
}
+
+ ret = clk_prepare_enable(pri_dai->clk);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "failed to enable clock: %d\n", ret);
+ return ret;
+ }
pri_dai->dma_playback.dma_addr = regs_base + I2STXD;
pri_dai->dma_capture.dma_addr = regs_base + I2SRXD;
pri_dai->dma_playback.ch_name = "tx";
@@ -1286,6 +1280,9 @@ static int samsung_i2s_remove(struct platform_device
*pdev)
pm_runtime_disable(&pdev->dev);
}
+ if (!is_secondary(i2s))
+ clk_disable_unprepare(i2s->clk);
+
i2s->pri_dai = NULL;
i2s->sec_dai = 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
Re: [PATCH 2/3] leds: leds-mc13783: Use of_get_child_by_name() instead of refcount hack
On Wed, Jan 14, 2015 at 5:51 AM, Geert Uytterhoeven wrote: > of_find_node_by_name() calls of_node_put() on its "from" parameter. > To counter this, mc13xxx_led_probe_dt() calls of_node_get() first. > > Use of_get_child_by_name() instead to get rid of the refcount hack. > > Signed-off-by: Geert Uytterhoeven > Cc: linux-l...@vger.kernel.org Looks good, applied to my tree. Thanks, -Bryan > --- > Compile-tested only > --- > drivers/leds/leds-mc13783.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/leds/leds-mc13783.c b/drivers/leds/leds-mc13783.c > index 85c3714e1b5aabba..e2b847fe22a1c934 100644 > --- a/drivers/leds/leds-mc13783.c > +++ b/drivers/leds/leds-mc13783.c > @@ -134,9 +134,7 @@ static struct mc13xxx_leds_platform_data __init > *mc13xxx_led_probe_dt( > if (!pdata) > return ERR_PTR(-ENOMEM); > > - of_node_get(dev->parent->of_node); > - > - parent = of_find_node_by_name(dev->parent->of_node, "leds"); > + parent = of_get_child_by_name(dev->parent->of_node, "leds"); > if (!parent) > goto out_node_put; > > -- > 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 04/15] ASoC: samsung: i2s: Move clk_get() to platform driver probe()
Acquire the I2S interface clock in driver probe() callback
as it's a per-device not a per-DAI clock. While at it switch
to the resource managed clk_get().
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 366b720..a854ffc 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -971,18 +971,12 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
int ret;
- if (other && other->clk) { /* If this is probe on secondary */
+ if (is_secondary(i2s)) { /* If this is probe on the secondary DAI */
samsung_asoc_init_dma_data(dai, &other->sec_dai->dma_playback,
NULL);
goto probe_exit;
}
- i2s->clk = clk_get(&i2s->pdev->dev, "iis");
- if (IS_ERR(i2s->clk)) {
- dev_err(&i2s->pdev->dev, "failed to get i2s_clock\n");
- return PTR_ERR(i2s->clk);
- }
-
ret = clk_prepare_enable(i2s->clk);
if (ret != 0) {
dev_err(&i2s->pdev->dev, "failed to enable clock: %d\n", ret);
@@ -991,10 +985,6 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
samsung_asoc_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture);
- if (other) {
- other->clk = i2s->clk;
- }
-
if (i2s->quirks & QUIRK_NEED_RSTCLR)
writel(CON_RSTCLR, i2s->addr + I2SCON);
@@ -1032,7 +1022,6 @@ static int samsung_i2s_dai_remove(struct snd_soc_dai *dai)
writel(0, i2s->addr + I2SCON);
clk_disable_unprepare(i2s->clk);
- clk_put(i2s->clk);
}
i2s->clk = NULL;
@@ -1222,6 +1211,11 @@ static int samsung_i2s_probe(struct platform_device
*pdev)
regs_base = res->start;
+ pri_dai->clk = devm_clk_get(&pdev->dev, "iis");
+ if (IS_ERR(pri_dai->clk)) {
+ dev_err(&pdev->dev, "Failed to get iis clock\n");
+ return PTR_ERR(pri_dai->clk);
+ }
pri_dai->dma_playback.dma_addr = regs_base + I2STXD;
pri_dai->dma_capture.dma_addr = regs_base + I2SRXD;
pri_dai->dma_playback.ch_name = "tx";
@@ -1253,6 +1247,7 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai->dma_playback.dma_size = 4;
sec_dai->addr = pri_dai->addr;
+ sec_dai->clk = pri_dai->clk;
sec_dai->quirks = quirks;
sec_dai->idma_playback.dma_addr = idma_addr;
sec_dai->pri_dai = pri_dai;
--
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 V3 07/15] ASoC: samsung: i2s: Remove an unneeded goto usage
The usage of this goto seems unjustified, use if/else statement instead.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index cab2a2a..2bac719 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -979,19 +979,18 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
if (is_secondary(i2s)) { /* If this is probe on the secondary DAI */
samsung_asoc_init_dma_data(dai, &other->sec_dai->dma_playback,
NULL);
- goto probe_exit;
- }
-
- samsung_asoc_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture);
+ } else {
+ samsung_asoc_init_dma_data(dai, &i2s->dma_playback,
+ &i2s->dma_capture);
- if (i2s->quirks & QUIRK_NEED_RSTCLR)
- writel(CON_RSTCLR, i2s->addr + I2SCON);
+ if (i2s->quirks & QUIRK_NEED_RSTCLR)
+ writel(CON_RSTCLR, i2s->addr + I2SCON);
- if (i2s->quirks & QUIRK_SUPPORTS_IDMA)
- idma_reg_addr_init(i2s->addr,
+ if (i2s->quirks & QUIRK_SUPPORTS_IDMA)
+ idma_reg_addr_init(i2s->addr,
i2s->sec_dai->idma_playback.dma_addr);
+ }
-probe_exit:
/* Reset any constraint on RFS and BFS */
i2s->rfs = 0;
i2s->bfs = 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 01/15] ASoC: samsung: i2s: samsung_i2s_get_driver_data() cleanup
Tidy up the samsung_i2s_get_driver_data() function by using
IS_ENABLE() instead of #ifdef and add missing braces for
the 'else' part. Also ensure we are not dereferencing NULL
'match' pointer.
Signed-off-by: Sylwester Nawrocki
---
sound/soc/samsung/i2s.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 86491c9..e5473ee 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1123,15 +1123,14 @@ static const struct of_device_id exynos_i2s_match[];
static inline const struct samsung_i2s_dai_data *samsung_i2s_get_driver_data(
struct platform_device *pdev)
{
-#ifdef CONFIG_OF
- if (pdev->dev.of_node) {
+ if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
const struct of_device_id *match;
match = of_match_node(exynos_i2s_match, pdev->dev.of_node);
- return match->data;
- } else
-#endif
+ return match ? match->data : NULL;
+ } else {
return (struct samsung_i2s_dai_data *)
platform_get_device_id(pdev)->driver_data;
+ }
}
#ifdef CONFIG_PM
--
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 V3 00/15] ASoC: samsung: Add clk provider for I2S internal clocks
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. The upside is we can switch Odroid X2/U3 to the simple-card, once the CDCLK clock is taken care of by the clk core and DT. Changes since v2: - skipped the first, already merged patch, - modified description of the patch moving clk_prepare_enable() from DAI to the platform device probe(), - the last patch marked for stable. The patch series has been created on top of branch: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/samsung Changes since the first 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 (15): 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| 361 sound/soc/samsung/odroidx2_max98090.c |6 +- 8 files changed, 295 insertions(+), 158 deletions(-) create mode 100644 include/dt-bindings/sound/samsung-i2s.h -- 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 00/13] Add ACPI _DSD and unified device properties support
I'm looking again at updating of_serial to work with ACPI properties.
Specifically, I want to support a serial port with a non-standard baud
rate, something like this:
Device(COM1) {
Name(_HID, EisaId("PNP0501"))
Name(_CID, EisaId("PRP0001"))
Name(_DSD, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", Package () {"ns16550a"}},
Package () {"clock-frequency", 2457600},
}
})
...
}
Firstly, the of_serial driver doesn't even get *invoked* unless I do
this:
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 0d08373..eb1201a 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2083,6 +2086,8 @@ static int acpi_add_single_object(struct acpi_device
**child,
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Added %s [%s] parent %s\n",
dev_name(&device->dev), (char *) buffer.pointer,
device->parent ? dev_name(&device->parent->dev) : "(null)"));
+ if (device->data.of_compatible)
+ acpi_create_platform_device(device);
kfree(buffer.pointer);
*child = device;
return 0;
Now it doesn't work because it uses of_match_device() to look the device
up and find the corresponding *data* for that entry in its match table.
And without CONFIG_OF, I don't *have* of_match_device().
We've talked about the fact that the platform bus probe function doesn't
pass you the match ID. Is that something we could potentially fix now
that things are a little more unified?
Or do we expect drivers still to have to use something like
of_match_id() to do the lookup again for themselves... and in that case
should we make of_match_id() available or produce a new
device_match_id() that they are expected to switch to?
--
dwmw2
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index c79b43c..65cf850 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1114,14 +1114,14 @@ config SERIAL_NETX_CONSOLE
you can make it the console by answering Y to this option.
config SERIAL_OF_PLATFORM
- tristate "Serial port on Open Firmware platform bus"
- depends on OF
+ tristate "Serial port on firmware platform bus"
+ depends on OF || ACPI
depends on SERIAL_8250 || SERIAL_OF_PLATFORM_NWPSERIAL
help
- If you have a PowerPC based system that has serial ports
- on a platform specific bus, you should enable this option.
- Currently, only 8250 compatible ports are supported, but
- others can easily be added.
+ If you have a system which advertises its serial ports through
+ devicetree or ACPI, you should enable this option. Currently
+ only 8250 compatible and NWP ports and are supported, but others
+ can easily be added.
config SERIAL_OMAP
tristate "OMAP serial port support"
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 64f1bab..54110e6 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -15,8 +15,7 @@
#include
#include
#include
-#include
-#include
+#include
#include
#include
#include
@@ -54,22 +53,22 @@ static inline void tegra_serial_handle_break(struct uart_port *port)
/*
* Fill a struct uart_port for a given device node
*/
-static int of_platform_serial_setup(struct platform_device *ofdev,
+static int of_platform_serial_setup(struct platform_device *pdev,
int type, struct uart_port *port,
struct of_serial_info *info)
{
- struct resource resource;
- struct device_node *np = ofdev->dev.of_node;
u32 clk, spd, prop;
- int ret;
+ int iotype = -1;
+ u32 res_start;
+ int ret, i;
memset(port, 0, sizeof *port);
- if (of_property_read_u32(np, "clock-frequency", &clk)) {
+ if (device_property_read_u32(&pdev->dev, "clock-frequency", &clk)) {
/* Get clk rate through clk driver if present */
- info->clk = clk_get(&ofdev->dev, NULL);
+ info->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(info->clk)) {
- dev_warn(&ofdev->dev,
+ dev_warn(&pdev->dev,
"clk or clock-frequency not defined\n");
return PTR_ERR(info->clk);
}
@@ -78,57 +77,63 @@ static int of_platform_serial_setup(struct platform_device *ofdev,
clk = clk_get_rate(info->clk);
}
/* If current-speed was set, then try not to change it. */
- if (of_property_read_u32(np, "current-speed", &spd) == 0)
+ if (device_property_read_u32(&pdev->dev, "current-speed", &spd) == 0)
port->custom_divisor = clk / (16 * spd);
- ret = of_address_to_resource(np, 0, &resource);
- if (ret) {
- dev_warn(&ofdev->dev, "invalid address\n");
+ /* Check for shifted address mapping */
+ if (device_property_read_u32(&pdev->dev, "reg-offset", &prop) != 0)
+ prop = 0;
+
+ for (i = 0; iotype == -1 && i < pdev->num_resources; i++) {
+ struct resource *resource = &pdev->resource[i];
+ if (resource_type(resource) == IORESOURCE_MEM) {
+ iotype = UPIO_MEM;
+ port->mapbase = res_start +
Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
On Wed, Jan 14, 2015 at 04:01:06PM +0100, Lukasz Majewski wrote:
> Hi Eduardo,
>
> > On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
> > > On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
> > > > Odroid U3 fan can work without being registered as OF cooling
> > > > device (with CONFIG_THERMAL_OF disabled).
> > > > In this situation it can be controlled via PWM entry at
> > > > /sys/class/hwmon/hwmon0/pwm1.
> > > >
> > > > Therefore, the thermal_of_cooling_device_register() function
> > > > needs a stub to allow clean compilation.
> > > >
> > > > Signed-off-by: Lukasz Majewski
> > >
> > > Acked-by: Eduardo Valentin
> >
> > Sorry, too fast,
> >
> > This is actually
> > Nacked-by: Eduardo Valentin
> >
> > :-)
> >
> > I get this error:
> > drivers/thermal/thermal_core.c:1210:1: error: redefinition of
> > ‘thermal_of_cooling_device_register’
> > thermal_of_cooling_device_register(struct device_node *np,
> > ^
> > In file included from drivers/thermal/thermal_core.c:34:0:
> > include/linux/thermal.h:321:1: note: previous definition of
> > ‘thermal_of_cooling_device_register’ was here
> >thermal_of_cooling_device_register(struct device_node *np,
> > ^
> >
> >
> > We provide the function in thermal core even if CONFIG_THERMAL_OF is
> > not set.
>
> Unfortunately the PWM fan subsystem can work perfectly fine without
> CONFIG_THERMAL.
>
Now I understand what you are trying to do.
> I think that it would be enough to make something like this in
> the ./include/linux/thermal.h:
>
> #ifdef CONFIG_THERMAL
Well, I think it should be the opposite here:
#ifndef CONFIG_THERMAL
that is, if no config thermal, then you provide the stub not the other
way around.
> static inline struct thermal_cooling_device *
> thermal_of_cooling_device_register(struct device_node
> *np, char *type, void *devdata,
> const struct
> thermal_cooling_device_ops *ops) {
> return NULL;
> }
> #else
> [ already present declaration of
> thermal_of_cooling_device_register() ]
> #endif /* CONFIG_THERMAL */
>
>
>
> > >
> > > > ---
> > > > Changes for v2:
> > > > - None
> > > > ---
> > > > include/linux/thermal.h | 14 +++---
> > > > 1 file changed, 11 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > > > index 2de3d9e..871123c 100644
> > > > --- a/include/linux/thermal.h
> > > > +++ b/include/linux/thermal.h
> > > > @@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct
> > > > device *dev, int id, void *data, const struct
> > > > thermal_zone_of_device_ops *ops); void
> > > > thermal_zone_of_sensor_unregister(struct device *dev, struct
> > > > thermal_zone_device *tz); +struct thermal_cooling_device *
> > > > +thermal_of_cooling_device_register(struct device_node *np,
> > > > + char *type, void *devdata,
> > > > + const struct
> > > > thermal_cooling_device_ops *); #else
> > > > static inline struct thermal_zone_device *
> > > > thermal_zone_of_sensor_register(struct device *dev, int id, void
> > > > *data, @@ -342,6 +346,13 @@ void
> > > > thermal_zone_of_sensor_unregister(struct device *dev, {
> > > > }
> > > >
> > > > +static inline struct thermal_cooling_device *
> > > > +thermal_of_cooling_device_register(struct device_node *np,
> > > > + char *type, void *devdata,
> > > > + const struct
> > > > thermal_cooling_device_ops *ops) +{
> > > > + return NULL;
> > > > +}
> > > > #endif
> > > > struct thermal_zone_device *thermal_zone_device_register(const
> > > > char *, int, int, void *, struct thermal_zone_device_ops *,
> > > > @@ -357,9 +368,6 @@ void thermal_zone_device_update(struct
> > > > thermal_zone_device *);
> > > > struct thermal_cooling_device
> > > > *thermal_cooling_device_register(char *, void *, const struct
> > > > thermal_cooling_device_ops *); -struct thermal_cooling_device *
> > > > -thermal_of_cooling_device_register(struct device_node *np, char
> > > > *, void *,
> > > > - const struct
> > > > thermal_cooling_device_ops *); void
> > > > thermal_cooling_device_unregister(struct thermal_cooling_device
> > > > *); struct thermal_zone_device
> > > > *thermal_zone_get_zone_by_name(const char *name); int
> > > > thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
> > > > long *temp); -- 2.0.0.rc2
> > > >
> >
> >
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
signature.asc
Description: Digital signature
Re: [PATCH v2 2/8] thermal: Provide stub for thermal_cdev_update() function
On Wed, Jan 14, 2015 at 04:07:53PM +0100, Lukasz Majewski wrote:
> Hi Eduardo,
>
> > On Mon, Dec 22, 2014 at 05:27:42PM +0100, Lukasz Majewski wrote:
> > > Odroid U3 fan can work without being registered as OF cooling device
> > > (with CONFIG_THERMAL_OF disabled).
> > > In this situation it can be controlled via PWM entry at
> > > /sys/class/hwmon/hwmon0/pwm1.
> > >
> > > Therefore, the thermal_cdev_update() function needs a stub
> > > to allow clean compilation.
> >
> > I am not sure I understand what you are attempting to do here. What is
> > the relation that you see between CONFIG_OF_THERMAL and
> > thermal_cdev_update?
>
> It should be CONFIG_THERMAL, not CONFIG_OF_THERMAL.
>
> The thermal_cdev_update() is necessary since pwm-fan code can be
> run without THERMAL subsystem (and such configuration is perfectly
> valid).
OK. Now I understand. Then, please resend this one using CONFIG_THERMAL.
Thanks,
Eduardo Valentin
>
> >
> > >
> > > Signed-off-by: Lukasz Majewski
> > > ---
> > > Changes for v2:
> > > - New patch
> > > ---
> > > include/linux/thermal.h | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> > > index 871123c..b3515b5 100644
> > > --- a/include/linux/thermal.h
> > > +++ b/include/linux/thermal.h
> > > @@ -332,6 +332,7 @@ struct thermal_cooling_device *
> > > thermal_of_cooling_device_register(struct device_node *np,
> > > char *type, void *devdata,
> > > const struct
> > > thermal_cooling_device_ops *); +void thermal_cdev_update(struct
> > > thermal_cooling_device *); #else
> > > static inline struct thermal_zone_device *
> > > thermal_zone_of_sensor_register(struct device *dev, int id, void
> > > *data, @@ -353,6 +354,10 @@
> > > thermal_of_cooling_device_register(struct device_node *np, {
> > > return NULL;
> > > }
> > > +
> > > +static inline void thermal_cdev_update(struct
> > > thermal_cooling_device *cdev) +{
> > > +}
> > > #endif
> > > struct thermal_zone_device *thermal_zone_device_register(const
> > > char *, int, int, void *, struct thermal_zone_device_ops *,
> > > @@ -375,7 +380,6 @@ int thermal_zone_get_temp(struct
> > > thermal_zone_device *tz, unsigned long *temp); int
> > > get_tz_trend(struct thermal_zone_device *, int); struct
> > > thermal_instance *get_thermal_instance(struct thermal_zone_device
> > > *, struct thermal_cooling_device *, int); -void
> > > thermal_cdev_update(struct thermal_cooling_device *); void
> > > thermal_notify_framework(struct thermal_zone_device *, int);
> > > #ifdef CONFIG_NET
> > > --
> > > 2.0.0.rc2
> > >
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
signature.asc
Description: Digital signature
Re: [PATCH v8 2/4] fpga manager: add sysfs interface document
On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote: > and I think you effectively have the user usage covered here for such > things. It much like GPIO pins - we can describe them but we can also > declare they are not visible to the user. A missing element in mainline is a kind of VFIO scheme to let user space access the FPGA registers designated for user space use. We have been using these patches since 2.6.16 to allow user space to access the FPGA register resources via a PCI like /sys/../resource0 mmapable: https://github.com/jgunthorpe/linux/commit/59d5d13ddeffa8980ccc6248ebb5f1678ccb23f4 https://github.com/jgunthorpe/linux/commit/7c29c4344627be8a3906d64d32db533bc131df86 https://github.com/jgunthorpe/linux/commit/e41bb4a197368a9d505d66b627aee82f2d2b8895 We deliberately split up the FPGA registers and the assign user space permissions to the resource0 files in a way that makes sense for our app. Typically there are 10-20 FPGA register regions. User space does not access register regions that control DMA. > The swappable case mostly comes out of the /dev node. Once you have the > dev node it becomes a detail of the OS not the FPGA driver as to who may > open it, and how it is handed about. It might be an FPU manager daemon it > might not. Right, but the thing that scares me about the swappable case is the kernel side support.. The FPGA has to connect to the CPU in some way, it must have some address assigned, etc. Swapping needs to take care of all those details in some way. A fixed bus interface block and dynamic reconfiguration for the remainder is probably the way to manage that. But, that implies that even a family of swappable FPGAs will have a DT overlay associated with it. Ideally, I could see wanting to have a file format that combines the overlay and FPGA bitfile. A loader tool would use the /dev/ interface to setup both elements. That would be much more robust than the current scheme I see (eg Xilinx) using where the bitfile and DT bit live in completely different places and have to be perfectly matched. Jason -- 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] Added support for pogoplug e02 (pink/gray)
On Tue, Jan 13, 2015 at 09:49:29PM -0700, Christoph Junghans wrote: > The pogoplug differs from the SheevaPlug only by a > few details, but especially in the led assignments. > This patch was tested under Gentoo Linux and is > based on dts files from Arch Linux ARM and OpenWrt. > > Suggested-by: Felix Kaechele > Suggested-by: Oleg Rakhmanov > Signed-off-by: Christoph Junghans > --- > > V1: initial patch > V2: added GPL-2 header > dropped earlyprintk from bootargs > added stdout-path > change leds name to scheme "devicename:colour:function" > V3: rebase on v3.19-rc4 > fixed stdout-path to be &uart0 > fixed compiling issue by using pin-controller > V4: moved ocp@f100 block into &uart and &pinctrl Hi Christoph Thanks for these last changes. It looks good now, and i've added it to mvebu/dt. So long as there are no more comments, i will pass it upstream soon. Thanks Andrew -- 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] clockevents: rockchip: Add rockchip timer for rk3288
Hi Daniel,
Am Mittwoch, 14. Januar 2015, 17:10:24 schrieb Daniel Lezcano:
> On 01/13/2015 12:20 AM, Heiko Stübner wrote:
> >> +- clock-frequency: the frequency the timer is running
> >> +
> >> +Example:
> >> + timer: timer@ff81 {
> >> + compatible = "rockchip,rk3288-timer";
> >> + reg = <0xff81 0x20>;
> >> + interrupts = ;
> >> + clock-frequency = <2400>;
> >
> > wouldn't it make sense to use the actual supplying clock?
> >
> > For the timer you want to use it is just the non-gateable &xin24m, but the
> > timers in the other block (timer0-5) actually do have gateable clocks.
> >
> > Similarly there is a pclk_timer supplying at least one of the two actual
> > blocks. I'll try to inquire how the blocks are actually supplied.
>
> Ok, are you suggesting I should use another timer so we can gate it for
> power efficiency ?
As you want a timer that is running during suspend, I think the one you're
using right now is the correct one ... the others (timer0-5) are in the cpu-
domain instead of the alive-domain
My intention was more to not have a clock-frequency property, but to simply
use the correct cock frequency.
clocks = <&xin24m>, <&cru PCLK_TIMER>;
clock-names = "timer", "pclk";
[same binding as dw_apb_timer]
rockchip_timer.c:
tclk = of_clk_get_by_name(np, "timer");
clk_prepare_enable(tclk);
bc_timer.freq = clk_get_rate(tclk);
etc...
essentially like db_apb_timer_of.c does it :-)
We currently don't implement the gates Jack mentioned, but as they're open
anyway we can just use xin24m directly for now.
And the pclk should probably be enabled too, as with 3.19-rc it gets disabled
when unused.
Heiko
--
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/5] rtc: armada38x: Add the device tree binding documentation
The Armada 38x SoCs come with a new RTC which differs from the one
used in the other mvebu SoCs until now. This patch describes the
binding of this RTC.
Signed-off-by: Gregory CLEMENT
---
.../devicetree/bindings/rtc/armada-380-rtc.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
b/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
new file mode 100644
index ..5a58aa94cfc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/armada-380-rtc.txt
@@ -0,0 +1,22 @@
+* Real Time Clock of te Armada 38x SoCs
+
+RTC controller for the Armada 38x SoCs
+
+Required properties:
+- compatible : Should be "marvell,armada-380-rtc"
+- reg: physical base address of the controller and length of memory
+ mapped region, associated to the reg-name "rtc". The other entry is
+ related to the interrupt control from the SoC, associated to the
+ reg-name "soc-interrupt".
+- reg-names: names of the mapped memory regions listed in regs
+property in the same order: "rtc" and "soc-int".
+- interrupts: IRQ line for the RTC.
+
+Example:
+
+rtc@a3800 {
+ compatible = "marvell,armada-380-rtc";
+ reg = <0xa3800 0x20>, <0x184a0 0x0c>;
+ reg-names = "rtc", "soc-int";
+ interrupts = ;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Add a new RTC driver for recent mvebu SoCs
Hi, The Marvell Armada 38x SoCs contains an RTC which differs from the RTC used in the other mvebu SoCs until now. This second version of the patch set adds support for this new IP and enable it in the Device Tree of the Armada 38x SoC. Thanks, Gr??gory Changelog v1 -> v2: - Used reg-names to identify the registers in the device tree - Changed the space into tab in the MAINTAINERS file - Emphasized that the 5s wait was only needed between two consecutive writes - Reduced the wait in the set_time function, 100ms were enough - If no interrupt was available, then disable the alarm related functions - Fixed the critical sections - Updated the mvebu_v7_defconfig by enabling the new RTC support Gregory CLEMENT (5): rtc: armada38x: Add the device tree binding documentation drivers/rtc/rtc-armada38x: Add a new RTC driver for recent mvebu SoCs MAINTAINERS: Add the RTC driver for the Armada38x ARM: mvebu: add Device Tree description of RTC on Armada 38x ARM: mvebu: enable Armada 38x RTC driver in mvebu_v7_defconfig .../devicetree/bindings/rtc/armada-380-rtc.txt | 22 ++ MAINTAINERS| 1 + arch/arm/boot/dts/armada-38x.dtsi | 7 + arch/arm/configs/mvebu_v7_defconfig| 1 + drivers/rtc/Kconfig| 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-armada38x.c| 319 + 7 files changed, 361 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/armada-380-rtc.txt create mode 100644 drivers/rtc/rtc-armada38x.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 4/5] ARM: mvebu: add Device Tree description of RTC on Armada 38x
The Marvell Armada 38x SoCs contains an RTC which differs from the RTC
used in the other mvebu SoCs until now. This commit adds the Device
Tree description of this interface at the SoC level.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-38x.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 04fe80d101f8..36c1d35873dd 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -466,6 +466,13 @@
clocks = <&gateclk 4>;
};
+ rtc@a3800 {
+ compatible = "marvell,armada-380-rtc";
+ reg = <0xa3800 0x20>, <0x184a0 0x0c>;
+ reg-names = "rtc", "soc-int";
+ interrupts = ;
+ };
+
sata@a8000 {
compatible = "marvell,armada-380-ahci";
reg = <0xa8000 0x2000>;
--
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 3/5] MAINTAINERS: Add the RTC driver for the Armada38x
Put it in the mvebu entry. Signed-off-by: Gregory CLEMENT --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddb9ac8d32b3..393f158a64e8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1157,6 +1157,7 @@ M:Sebastian Hesselbarth L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-mvebu/ +F: drivers/rtc/armada38x-rtc ARM/Marvell Berlin SoC support M: Sebastian Hesselbarth -- 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/5] drivers/rtc/rtc-armada38x: Add a new RTC driver for recent mvebu SoCs
The new mvebu SoCs come with a new RTC driver. This patch adds the
support for this new IP which is currently found in the Armada 38x
SoCs.
This RTC provides two alarms, but only the first one is used in the
driver. The RTC also allows using periodic interrupts.
Signed-off-by: Gregory CLEMENT
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile| 1 +
drivers/rtc/rtc-armada38x.c | 319
3 files changed, 330 insertions(+)
create mode 100644 drivers/rtc/rtc-armada38x.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index f15cddfeb897..de42ebd4b626 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1269,6 +1269,16 @@ config RTC_DRV_MV
This driver can also be built as a module. If so, the module
will be called rtc-mv.
+config RTC_DRV_ARMADA38X
+ tristate "Armada 38x Marvell SoC RTC"
+ depends on ARCH_MVEBU
+ help
+ If you say yes here you will get support for the in-chip RTC
+ that can be found in the Armada 38x Marvell's SoC device
+
+ This driver can also be built as a module. If so, the module
+ will be called armada38x-rtc.
+
config RTC_DRV_PS3
tristate "PS3 RTC"
depends on PPC_PS3
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c8ef3e1e6ccd..03fe5629c464 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_RTC_DRV_88PM860X) += rtc-88pm860x.o
obj-$(CONFIG_RTC_DRV_88PM80X) += rtc-88pm80x.o
obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
+obj-$(CONFIG_RTC_DRV_ARMADA38X)+= rtc-armada38x.o
obj-$(CONFIG_RTC_DRV_AS3722) += rtc-as3722.o
obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
new file mode 100644
index ..30bae27e828c
--- /dev/null
+++ b/drivers/rtc/rtc-armada38x.c
@@ -0,0 +1,319 @@
+/*
+ * RTC driver for the Armada 38x Marvell SoCs
+ *
+ * Copyright (C) 2015 Marvell
+ *
+ * Gregory Clement
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RTC_STATUS 0x0
+#define RTC_STATUS_ALARM1 BIT(0)
+#define RTC_STATUS_ALARM2 BIT(1)
+#define RTC_IRQ1_CONF 0x4
+#define RTC_IRQ1_AL_EN BIT(0)
+#define RTC_IRQ1_FREQ_EN BIT(1)
+#define RTC_IRQ1_FREQ_1HZ BIT(2)
+#define RTC_TIME 0xC
+#define RTC_ALARM1 0x10
+
+#define SOC_RTC_INTERRUPT 0x8
+#define SOC_RTC_ALARM1 BIT(0)
+#define SOC_RTC_ALARM2 BIT(1)
+#define SOC_RTC_ALARM1_MASKBIT(2)
+#define SOC_RTC_ALARM2_MASKBIT(3)
+
+struct armada38x_rtc {
+ struct rtc_device *rtc_dev;
+ void __iomem*regs;
+ void __iomem*regs_soc;
+ spinlock_t lock;
+ int irq;
+};
+
+/*
+ * According to the datasheet, we need to wait for 5us only between
+ * two consecutive writes
+ */
+static void rtc_delayed_write(u32 val, struct armada38x_rtc *rtc, int offset)
+{
+ writel(val, rtc->regs + offset);
+ udelay(5);
+}
+
+static int armada38x_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct armada38x_rtc *rtc = dev_get_drvdata(dev);
+ unsigned long time, time_check, flags;
+
+ spin_lock_irqsave(&rtc->lock, flags);
+
+ time = readl(rtc->regs + RTC_TIME);
+ /*
+* WA for failing time set attempts. As stated in HW ERRATA if
+* more than one second between two time reads is detected
+* then read once again.
+*/
+ time_check = readl(rtc->regs + RTC_TIME);
+ if ((time_check - time) > 1)
+ time_check = readl(rtc->regs + RTC_TIME);
+
+ spin_unlock_irqrestore(&rtc->lock, flags);
+
+ rtc_time_to_tm(time_check, tm);
+
+ return 0;
+}
+
+static int armada38x_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct armada38x_rtc *rtc = dev_get_drvdata(dev);
+ int ret = 0;
+ unsigned long time, flags;
+
+ ret = rtc_tm_to_time(tm, &time);
+
+ if (ret)
+ goto out;
+ /*
+* Setting the RTC time not always succeeds. According to the
+* errata we need to first write on the status register and
+* then wait for 100ms before writing to the time register to be
+* sure that the data will be taken into account.
+*/
+ spin_lock_irqsave(&rtc->lock, flags);
+
+ writel(0, rtc->regs + RTC_STATUS);
+
+ spin_unlock_irqrestore(&rtc->lock, flags);
+
+ msleep(100);
+
+ spin_lock_irqsave(
[PATCH v2 5/5] ARM: mvebu: enable Armada 38x RTC driver in mvebu_v7_defconfig
Now that the Armada 38x RTC driver has been pushed, let's enable it in mvebu_v7_defconfig. Signed-off-by: Gregory CLEMENT --- arch/arm/configs/mvebu_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig index 627accea72fb..2400b9f52403 100644 --- a/arch/arm/configs/mvebu_v7_defconfig +++ b/arch/arm/configs/mvebu_v7_defconfig @@ -112,6 +112,7 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_S35390A=y CONFIG_RTC_DRV_MV=y +CONFIG_RTC_DRV_ARMADA38X=y CONFIG_DMADEVICES=y CONFIG_MV_XOR=y # CONFIG_IOMMU_SUPPORT is not set -- 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: [RFC PATCH v3 3/4] arm64:thunder: Add initial dts for Cavium's Thunder SoC in 2 Node topology.
On Wed, Jan 07, 2015 at 08:18:50AM +, Arnd Bergmann wrote:
> On Wednesday 07 January 2015 12:37:51 Ganapatrao Kulkarni wrote:
> > Hi Arnd,
> >
> > On Wed, Jan 7, 2015 at 1:32 AM, Arnd Bergmann wrote:
> > > On Tuesday 06 January 2015 15:04:26 Ganapatrao Kulkarni wrote:
> > >> On Sat, Jan 3, 2015 at 2:47 AM, Arnd Bergmann wrote:
> > >> > On Wednesday 31 December 2014 13:03:27 Ganapatrao Kulkarni wrote:
> > >> >> + cpu@00f {
> > >> >> + device_type = "cpu";
> > >> >> + compatible = "cavium,thunder", "arm,armv8";
> > >> >> + reg = <0x0 0x00f>;
> > >> >> + enable-method = "psci";
> > >> >> + arm,associativity = <0 0 0x00f>;
> > >> >> + };
> > >> >> + cpu@100 {
> > >> >> + device_type = "cpu";
> > >> >> + compatible = "cavium,thunder", "arm,armv8";
> > >> >> + reg = <0x0 0x100>;
> > >> >> + enable-method = "psci";
> > >> >> + arm,associativity = <0 0 0x100>;
> > >> >> + };
> > >> >
> > >> > What is the 0x100 offset in the last-level topology field? Does this
> > >> > have
> > >> > no significance to topology at all? I would expect that to be something
> > >> > like cluster number that is relevant to caching and should be
> > >> > represented
> > >> > as a separate level.
> > >>
> > >> i did not understand, can you please explain little more about "
> > >> should be represented as a separate level."
> > >> at present, i have put the hwid of a cpu.
> > >
> > > From what I undertand, the hwid of the CPU contains the "cluster" number
> > > in
> > > this bit position, so you typically have a shared L2 or L3 cache between
> > > all cores within a cluster, but separate caches in other clusters.
> > >
> > > If this is the case, there will be a measurable difference in performance
> > > between two processes sharing memory when running on the same cluster,
> > > or when running on different clusters on the same socket. If the
> > > performance difference is relevant, it should be described as a separate
> > > level in the associativity property.
> > you mean, the associativity as array of
>
> No, that would leave out the core number, which is required to identify
> the individual thread. I meant adding an extra level such as
>
>
>
> A lot of machines will leave out the number because they are
> built with SoCs that don't have a long-distance coherency protocol.
Can't we use phandles to cpu-map nodes instead of a list of numbers (and
yet another topology binding description) ?
Is arm,associativity used solely to map "devices" (inclusive of caches)
to a set of cpus ?
cpu-map misses a notion of distance between hierarchy layers, but we can
add to that.
Lorenzo
--
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: [PATCHv2 1/2] spi: orion: Change spi-orion to use transfer_one() semantics for SPI transfers
On Mon, Jan 12, 2015 at 01:13:59PM +1000, Ken Wilson wrote: > This commit changes spi-orion to provide setup, set_cs, and transfer_one > functions instead of transfer_one_message. This allows chip select support > for both native and GPIO chip selects to be added. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/5] mfd: tps65218: make INT[12] and STATUS registers volatile
* Felipe Balbi [150112 08:50]: > Hi, > > On Thu, Jan 08, 2015 at 10:25:12AM -0600, Felipe Balbi wrote: > > On Tue, Jan 06, 2015 at 11:37:34AM -0600, Felipe Balbi wrote: > > > On Fri, Dec 26, 2014 at 01:28:20PM -0600, Felipe Balbi wrote: > > > > STATUS register can be modified by the HW, so we > > > > should bypass cache because of that. > > > > > > > > In the case of INT[12] registers, they are the ones > > > > that actually clear the IRQ source at the time they > > > > are read. If we rely on the cache for them, we will > > > > never be able to clear the interrupt, which will cause > > > > our IRQ line to be disabled due to IRQ throttling. > > > > > > > > Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC > > > > Cc: # v3.15+ > > > > Cc: Keerthy > > > > Cc: Lee Jones > > > > Signed-off-by: Felipe Balbi > > > > > > ping > > > > another ping. Without this and the following patch TPS65218 power button > > driver which was already applied by Dmitry, won't work. > > Anybody ? -rc4 is out and tps65218 is still broken because nobody has > acted on these two patches. All other patches which are meant for 3.20 > merge window are applied and because of these pending, those patches > won't work. Lee, are you planning to pick these two drivers/mfd patches? 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 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
Hi,
On Wed, Jan 14, 2015 at 03:08:43PM +0800, Sneeker Yeh wrote:
> Hi Felipe:
>
> thanks for suggestion,
>
> 2015-01-13 1:20 GMT+08:00 Felipe Balbi :
>
> > Hi,
> >
> > On Sun, Jan 11, 2015 at 11:19:55PM +0800, Sneeker Yeh wrote:
> > > > > > enable the quirk only for you. Isn't there a better way of
> > enabling the
> > > > > > quirk based off of revision detection couple with a look on
> > GHWPARAMS*
> > > > > > registers ?
> > > > > >
> > > > > > What's tricking me is this claim that only config-free PHYs would
> > be
> > > > > > affected, why ?
> > > > > >
> > > > >
> > > > > i'm still struggling now to try to get more information about this.
> > > > > some security policy inside Fujitsu make me unable to access full
> > > > > information of this errata today.
> > > > >
> > > > > Someday after i get enough information,
> > > > > i shall take your suggestion here that seems better to incur quirk
> > > > > dynamically via GHWPARAMS,
> > > > > and then send it here again.
> > > >
> > > > ok, hopefully you'll find a way ;-)
> > > >
> > > > I got some update information here finally~
> > > in case i express unclearly i also put a pdf:
> > > https://drive.google.com/file/d/0B18MmcvvKjNNbDF6eEdHSzZCazA/view
> > >
> > > This issue is defined by a two-way race at disconnect, between
> > > 1) class driver interrupt endpoint resheduling attempts if the ISR gave
> > an
> > > ep error event due to device detach (it would try 3 times)
> > > 2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
> > > asynchronously
> > > 3) The hardware IP was configured in silicon with
> > >- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 (this is an IP configuration
> >
> > yeah, aparently this is another configuration which is not exposed on
> > HWPARAMS registers. Paul, can you confirm for us ? I couldn't find it on
> > Databook on any of the HWPARAMS registers.
> >
> > > port whose state cannot be checked from software)
> > >- Synopsys IP version is < 3.00a
> >
> > heh, so pretty much everybody :-)
> >
>
> yeah, and I'm really lucky to encounter this @@
>
>
> >
> > >The IP will auto-suspend itself on device detach with some
> > > phy-specific interval after CSC is cleared by 2)
> > >
> > > If 2) and 3) complete before 1), the interrupts it expects will not be
> > > generated by the autosuspended IP, leading to a deadlock. Even later
> > > disconnection procedure would detect that corresponding urb is still
> > > in-progress and issue a ep stop command, auto-suspended IP still won't
> > > respond to that command.
> > >
> > > this defect would result in this when device detached:
> > > ---
> > > [ 99.603544] usb 4-1: USB disconnect, device number 2
> > > [ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
> > > endpoint command.
> > > [ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting
> > > host.
> > > [ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
> > > microseconds.
> > > [ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
> > > halting.
> > > [ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
> > > [ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
> > >
> > > As a result, when device detached, we desired to postpone "PORTCSC clear"
> > > behind "disable slot". it's found that all executed ep command related to
> > > disconnetion, are executed before "disable slot".
> >
> > Now this is all great information and they should all be part of your
> > commit log and probably a big comment should be added to code as well.
> >
>
> I see, thanks.
>
>
> >
> > Thanks for going after all these details, now let's figure out a way to
> > pass dwc3 revision to xhci, or maybe we pass just a flag for the quirk,
> > something like:
> >
> > if (dwc->revision < 3.00a && dwc->has_suspend_on_disconnect)
> > xhci_pdata.delay_portcsc_clear = true;
> >
> > or something similar to that.
> >
>
> Sure, how about i write these like this, that i learn from the way dwc3
> inject XHCI_LPM_SUPPORT to xhci via platform data:
>
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
> pdata.usb3_lpm_capable = 1;
> #endif
>
> + if ((dwc->revision < DWC3_REVISION_300A) &&
> + dwc->suspend_on_disconnect_quirk)
> + pdata.delay_portcsc_clear = 1;
> +
> ret = platform_device_add_data(xhci, &pdata, sizeof(pdata));
> if (ret) {
> dev_err(dwc->dev, "couldn't add platform data to xHCI
> device\n");
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
> (pdata && pdata->usb3_lpm_capable))
> xhci->quirks |= XH
Re: [PATCH v3] ARM: dts: add bcm2835-pwm bindings
On 01/14/2015 02:18 AM, Bart Tanghe wrote: To probe the bcm2835-pwm driver properly, this dts bindings has to be added to the bcm2835 dtsi file. In expectation of a bcm2835 clock driver, I've added fixed-clock clock binding. --- Changes in v3: - node added by reg value The pwm node still seems to be in the wrong place. Sorting by reg value, it should be after i2c@20205000 and before sdhci@7e30, as I mentioned before. -- 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 net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
On Wed, 2015-01-14 at 14:34 +0800, Ding Tianhong wrote: > Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller. > The controller has no tx done interrupt, reclaim xmitted buffer in the poll. > > v13: Fix the problem of alignment parameters for function and checkpatch > warming. > > v12: According Alex's suggestion, modify the changelog and add > MODULE_DEVICE_TABLE > for hip04 ethernet. > > v11: Add ethtool support for tx coalecse getting and setting, the xmit_more > is not supported for this patch, but I think it could work for hip04, > will support it later after some tests for performance better. > > Here are some performance test results by ping and iperf(add > tx_coalesce_frames/users), > it looks that the performance and latency is more better by > tx_coalesce_frames/usecs. > > - Before: > $ ping 192.168.1.1 ... > === 192.168.1.1 ping statistics === > 24 packets transmitted, 24 received, 0% packet loss, time 22999ms > rtt min/avg/max/mdev = 0.180/0.202/0.403/0.043 ms > > $ iperf -c 192.168.1.1 ... > [ ID] Interval Transfer Bandwidth > [ 3] 0.0- 1.0 sec 115 MBytes 945 Mbits/sec > > - After: > $ ping 192.168.1.1 ... > === 192.168.1.1 ping statistics === > 24 packets transmitted, 24 received, 0% packet loss, time 22999ms > rtt min/avg/max/mdev = 0.178/0.190/0.380/0.041 ms > > $ iperf -c 192.168.1.1 ... > [ ID] Interval Transfer Bandwidth > [ 3] 0.0- 1.0 sec 115 MBytes 965 Mbits/sec > > v10: According David Miller and Arnd Bergmann's suggestion, add some > modification > for v9 version > - drop the workqueue > - batch cleanup based on tx_coalesce_frames/usecs for better throughput > - use a reasonable default tx timeout (200us, could be shorted >based on measurements) with a range timer > - fix napi poll function return value > - use a lockless queue for cleanup > > Signed-off-by: Zhangfei Gao > Signed-off-by: Arnd Bergmann > Signed-off-by: Ding Tianhong > --- > drivers/net/ethernet/hisilicon/Makefile| 2 +- > drivers/net/ethernet/hisilicon/hip04_eth.c | 969 > + > 2 files changed, 970 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/ethernet/hisilicon/hip04_eth.c > > diff --git a/drivers/net/ethernet/hisilicon/Makefile > b/drivers/net/ethernet/hisilicon/Makefile > index 40115a7..6c14540 100644 > --- a/drivers/net/ethernet/hisilicon/Makefile > +++ b/drivers/net/ethernet/hisilicon/Makefile > @@ -3,4 +3,4 @@ > # > > obj-$(CONFIG_HIX5HD2_GMAC) += hix5hd2_gmac.o > -obj-$(CONFIG_HIP04_ETH) += hip04_mdio.o > +obj-$(CONFIG_HIP04_ETH) += hip04_mdio.o hip04_eth.o > diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c > b/drivers/net/ethernet/hisilicon/hip04_eth.c > new file mode 100644 > index 000..525214e > --- /dev/null > +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c > @@ -0,0 +1,969 @@ > + > +/* Copyright (c) 2014 Linaro Ltd. > + * Copyright (c) 2014 Hisilicon Limited. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PPE_CFG_RX_ADDR 0x100 > +#define PPE_CFG_POOL_GRP 0x300 > +#define PPE_CFG_RX_BUF_SIZE 0x400 > +#define PPE_CFG_RX_FIFO_SIZE 0x500 > +#define PPE_CURR_BUF_CNT 0xa200 > + > +#define GE_DUPLEX_TYPE 0x08 > +#define GE_MAX_FRM_SIZE_REG 0x3c > +#define GE_PORT_MODE 0x40 > +#define GE_PORT_EN 0x44 > +#define GE_SHORT_RUNTS_THR_REG 0x50 > +#define GE_TX_LOCAL_PAGE_REG 0x5c > +#define GE_TRANSMIT_CONTROL_REG 0x60 > +#define GE_CF_CRC_STRIP_REG 0x1b0 > +#define GE_MODE_CHANGE_REG 0x1b4 > +#define GE_RECV_CONTROL_REG 0x1e0 > +#define GE_STATION_MAC_ADDRESS 0x210 > +#define PPE_CFG_CPU_ADD_ADDR 0x580 > +#define PPE_CFG_MAX_FRAME_LEN_REG0x408 > +#define PPE_CFG_BUS_CTRL_REG 0x424 > +#define PPE_CFG_RX_CTRL_REG 0x428 > +#define PPE_CFG_RX_PKT_MODE_REG 0x438 > +#define PPE_CFG_QOS_VMID_GEN 0x500 > +#define PPE_CFG_RX_PKT_INT 0x538 > +#define PPE_INTEN0x600 > +#define PPE_INTSTS 0x608 > +#define PPE_RINT 0x604 > +#define PPE_CFG_STS_MODE 0x700 > +#define PPE_HIS_RX_PKT_CNT 0x804 > + > +/* REG_INTERRUPT */ > +#define RCV_INT BIT(10) > +#define RCV_NOBUFBIT(8) > +#defin
